拓冰网站定制 
Impeccable polish 全流程指南发布前的质量打磨、漂移分类与 Critique 快照闭环【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable/impeccable polish是 Impeccable 设计语言体系中面向发布前最后一公里的 Refine 命令用于对已经成型的功能做最终质量打磨。本指南基于 polish.md 原文结合仓库内 critique 存储的 Rust 实现、设计检测钩子与配套参考文档完整讲解 polish 的执行纪律、五种打磨维度、可复制的命令行操作以及critique 产出快照 → polish 消费快照 → 全清后关闭快照的闭环机制。读完你将掌握一套可直接照做的发布前 QA 流程并理解其底层数据指纹与退出码语义。一、第一性原理精修是打磨不是偷换的重设计polish 的底线在文档开篇就用两句话钉死这两句话也是整篇流程的最高约束Polish is refinement, never concealed redesign.精修是细化绝不是暗中重设计。必须保留既有的视觉世界、内容、行为以及所有不在范围内的事物。如果概念本身是错的应当明说并建议重设计或改用/impeccable bolder而不是借打磨之机夹带一个替换方案。A detector result is defect evidence, not proof of quality.检测器结果是缺陷证据不是质量证明。自动检测只能证明没有检出规则命中不能证明体验好必须亲自检查渲染后的真实效果和真实交互路径。从 SKILL.md 的命令表中可以看到 polish 属于 Refine 类别与bolder、quieter、distill、harden、onboard并列它的定位是ship 前的最终质量通道Final quality pass before shipping。与之互补的是概念层面真的错了 → 走 bolder.md 做定向放大或走 new-work 做重设计机械层面的硬指标 → 由设计检测钩子见 hooks.md在每次编辑后自动执行手感与质感底线 → 在编辑 UI 前加载 craft-floor.md。polish 只处理实现没有到达既定质量线的问题而且必须用系统自己的语言去修不是引入新东西。二、Step 1建立系统Establish the system动手之前先确认这个产品的系统是什么。具体做法阅读DESIGN.md项目设计规范文档阅读代表性 token、共享组件、模式与相邻流程neighboring flows如果项目没有正式的设计系统则以项目内一致的自有约定coherent project conventions为系统。建立系统之后先给每处漂移drift分类再决定怎么修。polish 定义了四种漂移类型漂移类型含义正确的修复层级missing token系统缺少一个可复用的值向设计系统补充可复用 tokenone-off implementation已存在共享组件/模式却被临时实现替代用系统已有的共享组件或模式替换conceptual mismatch流程、信息架构或层级与同类产品区域不一致修正概念层面而非打补丁local defect实现只是单纯不完整或不一致在最窄的正确层级修复关键纪律是Fix the cause at the narrowest correct level在最窄的正确层级修复根因能用局部修复解决的绝不上升到系统层面反之亦然——「把某个局部特例抽象成系统级概念」与「用临时实现绕过系统」同样是错误。当无法从现有材料推断出具有约束力的系统原则时必须询问用户而不是自行发明规则。三、Step 2收集证据Gather the evidencepolish 要求以真实用户的身份在代表性尺寸上使用该功能Web桌面端 移动端原生平台ios/android/adaptive在模拟器、仿真器或真机上覆盖已发布的设备类别按平台参考文档中的 Verifying the build 一节执行见 ios.md 与 android.md 中的对应章节。需要确定的事实包括路径在功能上是否完整预期质量线与可用时间已知约束或刻意未完成的工作用户实际会遇到的状态、内容长度、角色与输入方式。3.1 继承上一次 critique 快照如果之前对该目标跑过/impeccable critiquepolish 会把那份评审作为输入之一通过critique-storage latest读取最新快照.qoder/skills/impeccable/scripts/impeccable critique-storage latest resolved target --json退出码 0 时返回 JSON其中包含最新快照的body与精确的snapshot_file身份。snapshot_file必须保留到本次 pass 结束它是第 5 步关闭快照的凭证。3.2 快照的新鲜度判定指纹语义这里值得展开源码级细节critique 快照并非永远有效polish 读取它之前要判断这份评审还适不适用于现在的代码。实现位于 critique_storage.rs本地文件目标写快照时helper 会计算文件当前内容的精确指纹sha256:hex见 fingerprint_target并与 critique 捕获时记录的target_fingerprint比对。内容保持不变的 staged / unstaged / untracked 内容均视为仍然当前任何字节变化、删除、或被非文件替换都会关闭这份快照所标记的待办同时保留其趋势历史并让latest以退出码 2 返回见 latest 分支。URL 目标没有本地指纹快照会一直保持当前直到被显式关闭。身份标识目标身份被规范化为file:resolved-path或url:origin/pathname见 resolve_target_identity确保close不会误关其他目标或历史 slug 撞名的快照。当快照有效时将body中的相关P0/P1 发现纳入本次打磨并在回复中说明读取了该快照。退出码 2 表示不存在快照或目标已变更——无论哪种情况都必须独立执行一遍完整 pass不能因为快照缺失就跳过打磨。四、Step 3分诊Triage把功能缺陷与外观缺陷分开按以下顺序修复阻断性问题被破坏或被阻塞的任务、数据丢失、误导性状态、不可达的路径无障碍路径——P0 级别先修缺失状态loading、empty、error、success、disabled、permission 等状态缺失系统性漂移流程、层级、响应式、设计系统一致性漂移视觉与动效不一致代码与资源清理。纪律是不要把一个角落打磨到完美而让其余部分低于同一质量线Do not perfect one corner while leaving the rest below the same quality bar。打磨是整条路径的均匀交付不是单点炫技。这里的优先级框架与 critique.md 中的 P0–P3 严重度定义一致P0 阻止任务完成必须立即修P1 造成明显困难须在发布前修P2 小麻烦下一轮修P3 纯打磨型问题有时间再修。五、Step 4打磨整条路径Polish the whole path这是 polish 的正文覆盖五个维度。每个维度都要落实到检查 修正而不是感觉。5.1 流程与层级Flow and hierarchy与相邻模块对齐心智模型术语、信息披露disclosure、路由、保存行为、乐观/悲观更新模式optimistic/pessimistic patterns让主任务与当前状态显而易见但不要把所有元素压成同等的视觉权重确保到达arrival、过渡transition、空态empty、恢复recovery各路径之间是连通的而不是彼此孤立的屏幕。5.2 布局与排版Layout and type对齐项目的栅格与间距刻度同时修正光学对齐optical alignment与数学对齐相关内容紧凑成组不同组之间慷慨留白同一角色的排版保持一致性检查行长measure、换行wrapping、本地化扩展、缩放zoom与字体加载验证每一个受支持的视口而不是只修当前截图里的问题。5.3 色彩、图像与图标Color, imagery, and icons使用语义 token且颜色含义在各主题间保持稳定在每个状态下验证文本、控件与焦点的对比度图标家族、描边/字重、尺寸与光学对齐保持一致防止图片布局偏移正确的宽高比、响应式源、有意义的 alt 文本。5.4 交互与状态Interaction and state每个控件都需要恰当的 default / hover / focus / active / disabled / loading / error / success 行为保留可见的键盘焦点、逻辑 Tab 顺序、标签与平台合适的触控目标touch targets动效保持一致、可中断、性能良好——不要为了让打磨可见而加动画在产品可能遇到的地方验证长内容、缺失内容、本地化、离线、慢网络、权限受限场景。5.5 内容与代码Content and code保持术语、大小写、标点与事实性文案一致改动事实性声明前必须询问用户删除调试输出、死代码、未使用的 import、过时样式以及打磨过程中产生的重复系统拥有该模式的地方用共享组件替换自定义实现把真正可复用的值提升为 token——不要为单个局部特例创建系统级抽象。六、Step 5验证与收尾Verify and finish6.1 多模态走查在可行处用鼠标、键盘、触控完整走一遍路径检查布局Web 的移动 / 中间 / 宽屏原生两种方向下的手机与平板尺寸类别状态loading、empty、error、success、disabled、长内容、缺失内容无障碍缩放、对比度、焦点、语义、读屏器名称性能与稳定性控制台错误、布局偏移、交互延迟、各处图片加载Web 上覆盖受支持浏览器原生上覆盖受支持 OS 版本、运行时警告与掉帧一致性与 DESIGN.md、相邻功能、用户划定范围的吻合度。6.2 质量指令与 QA 命令遵循impeccable context与钩子提供的质量指令quality guidance然后运行其他相关 QA 命令。这里有一条容易被忽略的规则只有没有自动检测器在运行时context 才要求手动扫描一次绝不额外增加一次检测器 pass。这与 context_cli.rs 中MANUAL_DETECTOR_REQUIRED指令的生成逻辑对应——当会话没有激活的自动设计钩子时context 会输出该指令要求结束后对变更的 Web UI 运行一次impeccable detect --json changed targets见 append_detector_fallback若自动钩子处于per-edit或stop模式判定逻辑见 automatic_hook_mode则不产生该指令。检测器双轨机制详见 hooks.mdper-edit 轨只跑即时层级——机械、明确、值得打断一次编辑的问题坏图、溢出/裁切、对比度与可读性失败、渐变文字、发光阴影、设计系统漂移Stop 深扫轨在会话结束时对本次会话触碰的所有 UI 文件跑完整规则集与 per-edit 已报结果去重后一次性呈现其余发现copy 节奏、调色板与排版品味、布局节奏。修复真实缺陷只记录狭窄且有意的例外。一次干净的扫描不能替代视觉判断A clean scan does not replace visual judgment。6.3 源码 diff 收尾结束前做一次源码 diff移除意外改动accidental churn、孤儿代码、冗余值、临时产物。只有当功能在整条路径上功能完整且一致完成时才允许交付。6.4 关闭快照闭环的最后一环当本次 pass 把从快照中接手的所有 Priority Issue 全部清掉后关闭该快照.qoder/skills/impeccable/scripts/impeccable critique-storage close resolved target snapshot_file returned by latest关闭语义源码见 critique_storage.rs该命令只关闭本次 pass 实际处理的那份快照如果期间又有更新的 critique 写入那份新快照的待办保持存活close在快照 frontmatter 中写入closed: true见 insert_closed_flag之后latest对已关闭快照返回退出码 2以下情况不得关闭本次 pass 没有读取任何快照、snapshot_file未被保留、或仍有 Priority Issue 未解决。这保证了 critique → polish 的循环是认领 → 消化 → 归档的完整账目趋势历史保留可用critique-storage trend target 5查看最近 5 次评分见 critique.md已闭环的待办归档为closed新待办继续存活。七、闭环全景critique → polish → close 的一次完整运转把上面的五步串起来一次标准的 polish pass 长这样1. impeccable context # 装载 PRODUCT.md / DESIGN.md / surface brief / 质量指令 2. critique-storage latest target --json # 退出码 0 → 读取 body 中的 P0/P1保留 snapshot_file # 退出码 2 → 无快照或目标已变更独立完成整轮 pass 3. 建立系统 分类漂移missing token / one-off / conceptual / local 4. 代表性尺寸实机走查Web 桌面移动原生按平台 Verifying the build 5. 分诊功能缺陷 → 缺失状态 → 系统漂移 → 视觉动效 → 清理 6. 沿整条路径打磨流程层级 / 布局排版 / 色彩图像 / 交互状态 / 内容代码 7. 多模态复验 执行 context/hooks 给出的 QA 指令不新增检测器 pass 8. 源码 diff 收尾确认功能完整、路径一致完成 9. 全部 Priority Issue 清除 → critique-storage close target snapshot_file这一循环的产物是可追溯的.impeccable/critique/目录下的快照文件以2026-05-12T18-30-00Z__slug.md命名同一 UTC 秒内多次写入会用~0001固定宽度后缀避免覆盖历史见 write 分支本地文件目标携带 SHA-256 内容指纹URL 目标携带规范化身份。这些都是 polish 判断快照是否仍然有效的底层依据。八、配套参考与适用边界何时该用别的命令概念方向错误 → 建议重设计或bolderbolder.md 要求范围至上只动被点名的目标不引入新颜色、新字体、新系统原语否则手写/impeccable polish机械硬指标 → 交给设计检测钩子手感底线 → craft-floor.md 的 Verify / Refuse 清单。有界验证纪律SKILL.md 强调bounded passes, not a loop——批量一轮Web 桌面移动同批原生覆盖出货设备类别按一轮结果一次性修完最多再确认一轮即停止打磨。无休止的自我 QA 是在用更差的效果烧用户的钱这正是 finish 交接polish 属于该类要避免的。命令入口在 shell 中通过.qoder/skills/impeccable/scripts/impeccable verb调用Windows 无 sh 时用同目录的impeccable.cmd。启动器是自包含的启动脚本优先执行随附的平台二进制其次走版本固定的用户缓存最后才按需下载全程不需要 Node 或其他运行时并以 engine-probe 握手防住旧版 npm CLI 的二进制冲突。最终记住 polish 的判据打磨交付的是系统内的一致性完成度而不是孤立的完美角落检测器只提供证据视觉与交互判断永远属于人。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Impeccable polish 全流程指南：发布前的质量打磨、漂移分类与 Critique 快照闭环
Impeccable polish 全流程指南发布前的质量打磨、漂移分类与 Critique 快照闭环【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable/impeccable polish是 Impeccable 设计语言体系中面向发布前最后一公里的 Refine 命令用于对已经成型的功能做最终质量打磨。本指南基于 polish.md 原文结合仓库内 critique 存储的 Rust 实现、设计检测钩子与配套参考文档完整讲解 polish 的执行纪律、五种打磨维度、可复制的命令行操作以及critique 产出快照 → polish 消费快照 → 全清后关闭快照的闭环机制。读完你将掌握一套可直接照做的发布前 QA 流程并理解其底层数据指纹与退出码语义。一、第一性原理精修是打磨不是偷换的重设计polish 的底线在文档开篇就用两句话钉死这两句话也是整篇流程的最高约束Polish is refinement, never concealed redesign.精修是细化绝不是暗中重设计。必须保留既有的视觉世界、内容、行为以及所有不在范围内的事物。如果概念本身是错的应当明说并建议重设计或改用/impeccable bolder而不是借打磨之机夹带一个替换方案。A detector result is defect evidence, not proof of quality.检测器结果是缺陷证据不是质量证明。自动检测只能证明没有检出规则命中不能证明体验好必须亲自检查渲染后的真实效果和真实交互路径。从 SKILL.md 的命令表中可以看到 polish 属于 Refine 类别与bolder、quieter、distill、harden、onboard并列它的定位是ship 前的最终质量通道Final quality pass before shipping。与之互补的是概念层面真的错了 → 走 bolder.md 做定向放大或走 new-work 做重设计机械层面的硬指标 → 由设计检测钩子见 hooks.md在每次编辑后自动执行手感与质感底线 → 在编辑 UI 前加载 craft-floor.md。polish 只处理实现没有到达既定质量线的问题而且必须用系统自己的语言去修不是引入新东西。二、Step 1建立系统Establish the system动手之前先确认这个产品的系统是什么。具体做法阅读DESIGN.md项目设计规范文档阅读代表性 token、共享组件、模式与相邻流程neighboring flows如果项目没有正式的设计系统则以项目内一致的自有约定coherent project conventions为系统。建立系统之后先给每处漂移drift分类再决定怎么修。polish 定义了四种漂移类型漂移类型含义正确的修复层级missing token系统缺少一个可复用的值向设计系统补充可复用 tokenone-off implementation已存在共享组件/模式却被临时实现替代用系统已有的共享组件或模式替换conceptual mismatch流程、信息架构或层级与同类产品区域不一致修正概念层面而非打补丁local defect实现只是单纯不完整或不一致在最窄的正确层级修复关键纪律是Fix the cause at the narrowest correct level在最窄的正确层级修复根因能用局部修复解决的绝不上升到系统层面反之亦然——「把某个局部特例抽象成系统级概念」与「用临时实现绕过系统」同样是错误。当无法从现有材料推断出具有约束力的系统原则时必须询问用户而不是自行发明规则。三、Step 2收集证据Gather the evidencepolish 要求以真实用户的身份在代表性尺寸上使用该功能Web桌面端 移动端原生平台ios/android/adaptive在模拟器、仿真器或真机上覆盖已发布的设备类别按平台参考文档中的 Verifying the build 一节执行见 ios.md 与 android.md 中的对应章节。需要确定的事实包括路径在功能上是否完整预期质量线与可用时间已知约束或刻意未完成的工作用户实际会遇到的状态、内容长度、角色与输入方式。3.1 继承上一次 critique 快照如果之前对该目标跑过/impeccable critiquepolish 会把那份评审作为输入之一通过critique-storage latest读取最新快照.qoder/skills/impeccable/scripts/impeccable critique-storage latest resolved target --json退出码 0 时返回 JSON其中包含最新快照的body与精确的snapshot_file身份。snapshot_file必须保留到本次 pass 结束它是第 5 步关闭快照的凭证。3.2 快照的新鲜度判定指纹语义这里值得展开源码级细节critique 快照并非永远有效polish 读取它之前要判断这份评审还适不适用于现在的代码。实现位于 critique_storage.rs本地文件目标写快照时helper 会计算文件当前内容的精确指纹sha256:hex见 fingerprint_target并与 critique 捕获时记录的target_fingerprint比对。内容保持不变的 staged / unstaged / untracked 内容均视为仍然当前任何字节变化、删除、或被非文件替换都会关闭这份快照所标记的待办同时保留其趋势历史并让latest以退出码 2 返回见 latest 分支。URL 目标没有本地指纹快照会一直保持当前直到被显式关闭。身份标识目标身份被规范化为file:resolved-path或url:origin/pathname见 resolve_target_identity确保close不会误关其他目标或历史 slug 撞名的快照。当快照有效时将body中的相关P0/P1 发现纳入本次打磨并在回复中说明读取了该快照。退出码 2 表示不存在快照或目标已变更——无论哪种情况都必须独立执行一遍完整 pass不能因为快照缺失就跳过打磨。四、Step 3分诊Triage把功能缺陷与外观缺陷分开按以下顺序修复阻断性问题被破坏或被阻塞的任务、数据丢失、误导性状态、不可达的路径无障碍路径——P0 级别先修缺失状态loading、empty、error、success、disabled、permission 等状态缺失系统性漂移流程、层级、响应式、设计系统一致性漂移视觉与动效不一致代码与资源清理。纪律是不要把一个角落打磨到完美而让其余部分低于同一质量线Do not perfect one corner while leaving the rest below the same quality bar。打磨是整条路径的均匀交付不是单点炫技。这里的优先级框架与 critique.md 中的 P0–P3 严重度定义一致P0 阻止任务完成必须立即修P1 造成明显困难须在发布前修P2 小麻烦下一轮修P3 纯打磨型问题有时间再修。五、Step 4打磨整条路径Polish the whole path这是 polish 的正文覆盖五个维度。每个维度都要落实到检查 修正而不是感觉。5.1 流程与层级Flow and hierarchy与相邻模块对齐心智模型术语、信息披露disclosure、路由、保存行为、乐观/悲观更新模式optimistic/pessimistic patterns让主任务与当前状态显而易见但不要把所有元素压成同等的视觉权重确保到达arrival、过渡transition、空态empty、恢复recovery各路径之间是连通的而不是彼此孤立的屏幕。5.2 布局与排版Layout and type对齐项目的栅格与间距刻度同时修正光学对齐optical alignment与数学对齐相关内容紧凑成组不同组之间慷慨留白同一角色的排版保持一致性检查行长measure、换行wrapping、本地化扩展、缩放zoom与字体加载验证每一个受支持的视口而不是只修当前截图里的问题。5.3 色彩、图像与图标Color, imagery, and icons使用语义 token且颜色含义在各主题间保持稳定在每个状态下验证文本、控件与焦点的对比度图标家族、描边/字重、尺寸与光学对齐保持一致防止图片布局偏移正确的宽高比、响应式源、有意义的 alt 文本。5.4 交互与状态Interaction and state每个控件都需要恰当的 default / hover / focus / active / disabled / loading / error / success 行为保留可见的键盘焦点、逻辑 Tab 顺序、标签与平台合适的触控目标touch targets动效保持一致、可中断、性能良好——不要为了让打磨可见而加动画在产品可能遇到的地方验证长内容、缺失内容、本地化、离线、慢网络、权限受限场景。5.5 内容与代码Content and code保持术语、大小写、标点与事实性文案一致改动事实性声明前必须询问用户删除调试输出、死代码、未使用的 import、过时样式以及打磨过程中产生的重复系统拥有该模式的地方用共享组件替换自定义实现把真正可复用的值提升为 token——不要为单个局部特例创建系统级抽象。六、Step 5验证与收尾Verify and finish6.1 多模态走查在可行处用鼠标、键盘、触控完整走一遍路径检查布局Web 的移动 / 中间 / 宽屏原生两种方向下的手机与平板尺寸类别状态loading、empty、error、success、disabled、长内容、缺失内容无障碍缩放、对比度、焦点、语义、读屏器名称性能与稳定性控制台错误、布局偏移、交互延迟、各处图片加载Web 上覆盖受支持浏览器原生上覆盖受支持 OS 版本、运行时警告与掉帧一致性与 DESIGN.md、相邻功能、用户划定范围的吻合度。6.2 质量指令与 QA 命令遵循impeccable context与钩子提供的质量指令quality guidance然后运行其他相关 QA 命令。这里有一条容易被忽略的规则只有没有自动检测器在运行时context 才要求手动扫描一次绝不额外增加一次检测器 pass。这与 context_cli.rs 中MANUAL_DETECTOR_REQUIRED指令的生成逻辑对应——当会话没有激活的自动设计钩子时context 会输出该指令要求结束后对变更的 Web UI 运行一次impeccable detect --json changed targets见 append_detector_fallback若自动钩子处于per-edit或stop模式判定逻辑见 automatic_hook_mode则不产生该指令。检测器双轨机制详见 hooks.mdper-edit 轨只跑即时层级——机械、明确、值得打断一次编辑的问题坏图、溢出/裁切、对比度与可读性失败、渐变文字、发光阴影、设计系统漂移Stop 深扫轨在会话结束时对本次会话触碰的所有 UI 文件跑完整规则集与 per-edit 已报结果去重后一次性呈现其余发现copy 节奏、调色板与排版品味、布局节奏。修复真实缺陷只记录狭窄且有意的例外。一次干净的扫描不能替代视觉判断A clean scan does not replace visual judgment。6.3 源码 diff 收尾结束前做一次源码 diff移除意外改动accidental churn、孤儿代码、冗余值、临时产物。只有当功能在整条路径上功能完整且一致完成时才允许交付。6.4 关闭快照闭环的最后一环当本次 pass 把从快照中接手的所有 Priority Issue 全部清掉后关闭该快照.qoder/skills/impeccable/scripts/impeccable critique-storage close resolved target snapshot_file returned by latest关闭语义源码见 critique_storage.rs该命令只关闭本次 pass 实际处理的那份快照如果期间又有更新的 critique 写入那份新快照的待办保持存活close在快照 frontmatter 中写入closed: true见 insert_closed_flag之后latest对已关闭快照返回退出码 2以下情况不得关闭本次 pass 没有读取任何快照、snapshot_file未被保留、或仍有 Priority Issue 未解决。这保证了 critique → polish 的循环是认领 → 消化 → 归档的完整账目趋势历史保留可用critique-storage trend target 5查看最近 5 次评分见 critique.md已闭环的待办归档为closed新待办继续存活。七、闭环全景critique → polish → close 的一次完整运转把上面的五步串起来一次标准的 polish pass 长这样1. impeccable context # 装载 PRODUCT.md / DESIGN.md / surface brief / 质量指令 2. critique-storage latest target --json # 退出码 0 → 读取 body 中的 P0/P1保留 snapshot_file # 退出码 2 → 无快照或目标已变更独立完成整轮 pass 3. 建立系统 分类漂移missing token / one-off / conceptual / local 4. 代表性尺寸实机走查Web 桌面移动原生按平台 Verifying the build 5. 分诊功能缺陷 → 缺失状态 → 系统漂移 → 视觉动效 → 清理 6. 沿整条路径打磨流程层级 / 布局排版 / 色彩图像 / 交互状态 / 内容代码 7. 多模态复验 执行 context/hooks 给出的 QA 指令不新增检测器 pass 8. 源码 diff 收尾确认功能完整、路径一致完成 9. 全部 Priority Issue 清除 → critique-storage close target snapshot_file这一循环的产物是可追溯的.impeccable/critique/目录下的快照文件以2026-05-12T18-30-00Z__slug.md命名同一 UTC 秒内多次写入会用~0001固定宽度后缀避免覆盖历史见 write 分支本地文件目标携带 SHA-256 内容指纹URL 目标携带规范化身份。这些都是 polish 判断快照是否仍然有效的底层依据。八、配套参考与适用边界何时该用别的命令概念方向错误 → 建议重设计或bolderbolder.md 要求范围至上只动被点名的目标不引入新颜色、新字体、新系统原语否则手写/impeccable polish机械硬指标 → 交给设计检测钩子手感底线 → craft-floor.md 的 Verify / Refuse 清单。有界验证纪律SKILL.md 强调bounded passes, not a loop——批量一轮Web 桌面移动同批原生覆盖出货设备类别按一轮结果一次性修完最多再确认一轮即停止打磨。无休止的自我 QA 是在用更差的效果烧用户的钱这正是 finish 交接polish 属于该类要避免的。命令入口在 shell 中通过.qoder/skills/impeccable/scripts/impeccable verb调用Windows 无 sh 时用同目录的impeccable.cmd。启动器是自包含的启动脚本优先执行随附的平台二进制其次走版本固定的用户缓存最后才按需下载全程不需要 Node 或其他运行时并以 engine-probe 握手防住旧版 npm CLI 的二进制冲突。最终记住 polish 的判据打磨交付的是系统内的一致性完成度而不是孤立的完美角落检测器只提供证据视觉与交互判断永远属于人。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考