数据库客户端后端前端CLI桌面应用数据可视化AI 应用【免费下载链接】whodbWhere data access meets operational intelligence项目地址https://gitcode.com/gh_mirrors/wh/whodb点击查看免费下载在 WhoDB 仓库中.agents/skills/impeccable/目录内置了一套名为 Impeccable 的前端设计技能其polish命令承担发布前最后一道质量闸的职责。本文以 polish 参考文档 为主线完整拆解其建立系统 → 收集证据 → 分诊 → 打磨整条路径 → 验证收口的五阶段工作流并结合仓库中的 DESIGN.md、critique-storage.mjs 等源码佐证各阶段的落点读完你可以掌握一套可复现的 UI 收尾检查方法如何区分四类视觉漂移、按什么优先级修复缺陷、以及怎样用快照与检测器完成闭环验证。1. polish 的定位是精修不是换设计文档开篇给出两条总纲它们决定了整个工作流的边界Polish is refinement, never concealed redesign.保留既有的视觉世界、内容、行为以及作用域之外的一切。如果问题出在概念本身应直说并建议走redesign或bolder而不是偷偷夹带一次替换。第二条同样关键检测器的输出只是缺陷证据不是质量的证明。你必须亲自检查渲染后的体验与真实的交互路径。这与 SKILL.md 中命令表的定位一致polish [target]属于 Refine 类描述为 Final quality pass before shipping发布前的最终质量检查。在 WhoDB 这种 Operate 模式用户完成具体任务的工具型界面的产品里一致性、可扫描性和原生预期优先于视觉表达因此 polish 的重心天然落在整条任务路径的一致性而非单屏美观上。2. 建立系统先读懂既有设计系统再动手阶段 1 要求先阅读DESIGN.md以及代表性的 tokens、共享组件、既有模式和邻近流程如果项目没有正式设计系统就退而使用一致的项目约定。在 WhoDB 仓库中这一步有明确的对象——DESIGN.md 声明了完整的设计系统Quiet Confidence 创意北极星、Paper浅色/ Ink深色双主题、Signal Blue 作为唯一产品强调色、Hanken Grotesk作为唯一生效的 UI 字体并明确拒绝遗留数据库工具的杂乱美学。其中两条命名规则对 polish 尤其重要The One-Accent Rule同一表面同一时刻只允许一个强调色相蓝色主导产品 UI橙色只用于品牌时刻两者不得在同一卡片或横幅上混用The Density-Tier Rule字号、圆角、间距都存在 small/medium/large 档位由 Settings 中的密度系统切换存在var(--font-size-*)/var(--radius-*)/var(--spacing-*)token 时禁止硬编码像素值——硬编码会让该元素在密度切换时失效。进入 frontend/src/index.css 可以看到这套 token 的真实落点:root下定义了--font-size-xs到--font-size-3xl的字号变量index.css#L670-L679注释标明它们将被 theme-customization.ts 覆盖body上的字体栈Hanken Grotesk, Inter, var(--font-sans)...与 DESIGN.md 的 Typography 章节逐字对应。这正是 polish 阶段判断某处写法是否漂移的参照系。漂移四分类文档要求在修复之前先对每处漂移分类共四类分类含义修复思路missing token缺失 token系统需要一个可复用的值提升为 token纳入设计系统one-off implementation一次性实现本应使用既有共享组件或模式用共享组件替换定制实现conceptual mismatch概念错位流程、信息架构或层级与同类产品区域不一致对齐邻近区域的既有模式local defect局部缺陷实现就是不完整或不一致就地修复原则是在最窄的正确层级上修复根因而当某个约束性系统原则无法从代码推断时应停下来询问而不是自行猜测。3. 收集证据真实使用 历史评审快照阶段 2 要求你在有代表性的桌面和移动尺寸下亲自使用这个功能并回答四个问题任务路径是否功能完整预期的质量标准和可用时间是多少有哪些已知约束或刻意未完成的工作用户实际会遇到的状态、内容长度、角色和输入方式是什么如果此前存在评审critique结果把它当作输入之一而非全部依据node .agents/skills/impeccable/scripts/critique-storage.mjs latest resolved target退出码 0表示返回最新快照应将其中的 P0/P1 发现纳入修复清单并在产出中说明你读取了哪个快照退出码 2表示不存在任何快照。无论哪种情况都要再做一遍独立的检查。从源码看这套快照机制的实现非常紧凑critique-storage.mjs每次 critique 运行会把快照写入.impeccable/critique/timestamp__slug.md头部是携带分数与 P0/P1 计数的小型 YAML frontmatter见 writeSnapshotL60-L73slug 从已解析的具体目标文件路径或 URL机械派生而不是从用户的自然语言描述派生——跨运行的 slug 稳定性正是趋势trend统计能工作的前提latest子命令取时间序上最后一条快照L179-L182读不到时process.exit(2)与文档中的退出码约定严格对应。文件头注释还特意说明polish 工作流在开始时读取最新匹配快照作为修复积压fix backlog其他技能不会自动读取 critique 输出。4. 分诊先修功能再谈美观阶段 3 的核心是把功能缺陷和纯外观缺陷分开并按以下顺序修复被破坏或阻塞的任务、数据丢失、误导性状态、不可达的路径缺失的 loading / empty / error / success / disabled / 权限状态流程、层级、响应式与设计系统的漂移视觉与动效的不一致代码与资产清理。文档特别警告不要只把某个角落打磨到完美却让其余部分停留在更低的水平——质量必须沿整条路径均匀达标。5. 打磨整条路径五个维度的检查清单阶段 4 是全文最长的部分把polish拆成五个可执行维度。以下内容完整继承原文档的每一项要求。5.1 流程与层级Flow and hierarchy与邻近区域对齐心智模型、术语、信息展开方式、路由、保存行为以及乐观/悲观更新模式让主要任务与当前状态显而易见但不要把所有元素压成同等权重拉平本身就是问题确保到达、转场、空态和恢复路径彼此衔接而不是各页面像孤岛一样孤立。5.2 布局与字体Layout and type对齐项目的网格与间距刻度同时修正光学对齐和数学对齐数字、图标、斜体等需要按视觉而非坐标对齐相关内容紧密分组不同组之间留足间隙同一角色的排版保持一致验证行长measure、换行、本地化文本膨胀、缩放与字体加载验证每一个受支持的视口而不是只修当前截图里出问题的尺寸。WhoDB 的 index.css 里就有针对超宽视口的成组缩放规则min-width: 1800px/2400px/3000px三档 body zoom 及对应的--ce-popper-zoom补偿见 index.css#L694-L708——这正是验证每个受支持视口要覆盖的真实场景之一。5.3 颜色、图像与图标Color, imagery, and icons使用语义 token并保证颜色含义跨主题稳定在每一种状态下验证文本、控件与焦点的对比度图标族保持一致线条粗细/字重、尺寸、光学对齐防止图片引起布局偏移正确的宽高比、响应式图源、有用的 alt 文本。对照 DESIGN.md 的 Colors 章节这些要求有具体的验收口径muted foreground 的深色值#9BA5B3曾专门上调因为它是对着文本实际所在的表面--card而非--background按 WCAG AA 实测后才通过的——polish 检查对比度时必须对着真实表面而不是页面背景。5.4 交互与状态Interaction and state每个控件都需要完整的 default / hover / focus / active / disabled / loading / error / success 行为保留可见的键盘焦点、合理的 Tab 顺序、标签以及平台合适的触控目标尺寸动效要连贯、可中断、性能好。不要为了让 polish 可见而添加动画——这是一条反炫技条款在产品可能遇到的地方验证超长内容、缺失内容、本地化内容、离线、慢速网络与权限受限场景。5.5 内容与代码Content and code术语、大小写、标点与事实性文案保持一致修改事实性表述前必须先询问删除调试输出、死代码、未使用的 import、过时样式以及polish 过程自身产生的重复代码当系统拥有该模式时用共享组件替换定制实现——在 WhoDB 中共享组件的注册入口是 component-registry.tsCE 端只渲染已注册的组件把真正可复用的值提升为 token但不要为单个局部例外创建系统级抽象——这是第 2 节漂移四分类在 token 层的双向约束该提升的提升不该提升的克制。6. 验证与收口把扫描、走查和 diff 三件事做完阶段 5 要求用鼠标、键盘以及触控如适用完整再走一遍整条路径并核对四组事项移动端、中间尺寸与宽屏布局loading / empty / error / success / disabled / 超长内容 / 缺失内容状态缩放、对比度、焦点、语义与屏幕阅读器名称控制台错误、布局偏移、交互延迟、图片加载与受支持浏览器与DESIGN.md、邻近功能和用户作用域保持一致。在检测器detector的使用上文档给出一条克制原则跟随context.mjs与 hooks 提供的质量指引然后运行其他相关的 QA 命令context.mjs只在没有自动检测器激活时要求一次手动扫描绝不额外增加检测器轮次。干净的扫描结果不能替代视觉判断只修真实缺陷并把有意保留的例外窄范围地记录下来。这一条与 hooks.md 的机制互相印证hook 采用双层规则——每次编辑只上报即时层破损图片、溢出裁切、对比度失败、渐变文字、光晕阴影、设计系统漂移等机械可判定的问题其余规则推迟到会话Stop事件的全量深扫一次去重上报没有接 hook 的会话则会从context.mjs收到一条MANUAL_DETECTOR_REQUIRED指令要求结束时跑一次手动扫描。polish 阶段不额外加扫描的约束正是为了不干扰这套已编排好的检测节奏。最后以源码 diff 收口移除意外改动churn、孤儿代码、冗余值和临时产物。只有当功能完整、且沿整条路径质量一致时才允许交付。7. 在 WhoDB 仓库中执行 polish 的典型路径把上面的流程落到本仓库的实际工作流大致是这样的读系统以 DESIGN.md 为参照系双主题 token 表、One-Accent Rule、Density-Tier Rule并抽查 frontend/src/index.css 中:root的--font-size-*变量与字体栈确认你面对的视觉世界取证据对目标页面/路由真实走查若目标此前被 critique 过用critique-storage.mjs latest resolved target拉取最新快照退出码 0 读取、2 表示无快照把其中 P0/P1 并入自己的独立检查分诊按功能缺陷 → 状态缺失 → 设计漂移 → 视觉动效 → 代码清理的顺序修复每处漂移先归类为 missing token / one-off / conceptual mismatch / local defect 再动手按五维度打磨流程层级、布局字体、颜色图像图标、交互状态、内容代码逐项过 5.1–5.5 的清单验证收口多视口 全状态 键盘/屏幕阅读器走查配合 hooks 的既有检测节奏不额外加扫描最后清理 diff确认整条路径一致达标后再交付。这套工作流的可取之处不在任何单条规则而在于它的顺序性与证据性先建立系统参照、再收集证据、然后分诊、逐维度打磨、最后用 diff 收口。它把polish从一个模糊的主观词汇变成了一份可复查、可交接、可被下一次 critique 快照接续的质量流程。赞分享数据库客户端后端前端CLI桌面应用数据可视化AI 应用【免费下载链接】whodbWhere data access meets operational intelligence项目地址https://gitcode.com/gh_mirrors/wh/whodb点击查看免费下载相关推荐Impeccable Finish ReviewerAI 设计交付前的最后一道验收闸门与四词裁决体系Impeccable Finish ReviewerAI 设计交付前的最后一道验收闸门与四词裁决体系 在 Impeccable 的设计工作流中构建线程buAI 技能前端CLIdsh-pluginImpeccable polish 精修实战指南发布前最后一个质量关卡Impeccable polish 精修实战指南发布前最后一个质量关卡 Impeccable 的 polish 是 Refine精修类别下的收尾命令定位AI 技能前端CLIdsh-pluginimpeccable polish 指南发布前最后一轮全路径质量打磨impeccable polish 指南发布前最后一轮全路径质量打磨 Polish 是 impeccable 技能体系中的收尾型命令它承接 critiqueAI 技能前端CLIdsh-plugin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
