Impeccable polish 收尾指南在提交前完成一次有据可依、绝不越界的精细化打磨【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本篇指南解读 impeccable 技能体系中polish [target]命令的完整操作规范依据 .trae/skills/impeccable/reference/polish.md。polish属于 impeccable 命令体系中的Refine细化类命令其定位见 skill/scripts/command-metadata.json「执行一次最终质量收尾修复对齐、间距、一致性与微细节问题用于发布之前——当用户提到 polish、收尾、pre-launch review、看起来不对劲或想让作品从好变成优秀时」。读完本文你将掌握如何在既有视觉系统内对一条完整用户路径做证据驱动的缺陷分类与修复如何用critique-storage命令消费上一轮 critique 的优先级问题P0/P1并正确地关闭快照以及如何在收尾时做到「整条路径一致完成」而不是单点修补。一、先立规矩Polish 是细化绝不是隐蔽的重设计polish 流程的第一条硬性约束是划清「细化」与「重设计」的边界保留在位的一切既有的视觉世界incumbent visual world、内容、行为以及一切不在本次范围内的事物都必须原样保留概念本身错了就直说如果问题出在概念层面信息架构、产品定位应当明确建议走bolder或重设计路线见 .trae/skills/impeccable/reference/bolder.md——bolder 是「对已上线表面做放大强化」的细化命令而不是把替换方案偷偷塞进 polish 流程里检测结果是缺陷证据不是质量证明impeccable detect的扫描输出只说明哪里可能有缺陷必须亲自检查渲染后的真实体验与真实交互路径才能判断质量。这条原则与 impeccable 的世界变更语义一致见 skill/SKILL.src.md细化保留在位者重设计才替换。polish 永远站在保留这一侧。二、第 1 步建立系统Establish the system动手改任何东西之前先建立什么是对的的参照系阅读项目的DESIGN.md以及有代表性的 token、共享组件、既有模式与相邻流程如果项目没有正式的设计系统就以连贯的项目约定coherent project conventions作为参照无法从证据推断出具有约束力的系统原则时直接向用户提问不要擅自假设。然后把每一处偏离drift先分类再决定修法分类含义处理方向missing token缺 token系统需要一个可复用的值沉淀为系统 tokenone-off implementation一次性实现已有共享组件/模式可以取代它替换为共享实现conceptual mismatch概念错位流程、信息架构或层级与同类产品区域不一致修正到系统所表达的心智模型local defect局部缺陷实现本身不完整或不一致在局部补完修复层级原则在最窄且正确的层级修复原因——能改组件就不改页面能改 token 就不改组件修复手法不能比问题本身更宽泛。三、第 2 步收集证据Gather the evidence3.1 在真实尺寸上走一遍必须亲自在代表性的尺寸上使用该功能Web桌面与移动两种代表性尺寸原生平台ios/android/adaptive在模拟器、真机或硬件上按对应平台参考ios.md、android.md、adapt.native.md的 Verifying the build 章节采集证据。观察过程中需要确认四件事这条路径是否功能完整预期质量线quality bar与可用时间已知约束或有意未完成的部分用户真实会遇到的状态、内容长度、角色与输入方式。3.2 读取上一轮 critiquecritique-storage latest如果存在上一轮 critique 快照将其作为输入之一它只是输入之一不是唯一输入.trae/skills/impeccable/scripts/impeccable critique-storage latest resolved target --json这条命令由 Rust 引擎实现核心代码在 crates/context/src/critique_storage.rsrun函数位于 crates/context/src/critique_storage.rs#L441-L702CLI 启动器为 skill/scripts/impeccable。理解它的语义才能正确用它退出码语义Exit 0返回最新快照的body完整 critique 报告正文与精确的snapshot_file身份标识JSON 模式下--json输出{snapshot_file: ..., body: ...}。必须把snapshot_file保留到本轮结束它是最后关闭快照的凭证Exit 2表示不存在快照或目标已变化见下方指纹机制或快照已关闭。本地文件目标的指纹校验机制对于本地文件目标helper 会把文件当前内容的精确指纹与 critique 快照时记录的指纹sha256:hex见 crates/context/src/critique_storage.rs#L229-L238 的fingerprint_target进行比较内容未变包括 staged、unstaged、untracked 任意一种未变状态→ 快照仍然 current任何字节变化、删除、或文件被替换为非文件 → 该快照识别的积压事项被自动关闭closed: true写入 frontmatter见close_snapshot与insert_closed_flagcrates/context/src/critique_storage.rs#L290-L334同时保留其趋势历史命令以exit 2退出。也就是说文件被改过上一轮的缺陷清单就不再算数——这正是检测结果是缺陷证据在存储层的体现。URL 目标URL 目标没有本地指纹is_http判定后不计算指纹crates/context/src/critique_storage.rs#L199-L203因此一直保持 current直到被显式关闭。无论何种情况当快照 current 时把body中相关的P0/P1发现纳入本轮修复并明确说出读了哪个快照exit 2 时同样要独立完成一轮自己的检查——上一轮 critique 只是输入不是免检凭证。快照的存储形态便于理解身份机制目录project_root/.impeccable/critique/见get_critique_dircrates/context/src/critique_storage.rs#L12-L14文件名UTC时间戳[~碰撞后缀]__slug.md形如2026-05-12T18-30-00Z__app-tsx.mdis_snapshot_name校验crates/context/src/critique_storage.rs#L140-L180目标身份本地文件为file:绝对路径URL 为url:originpathnameresolve_target_identitycrates/context/src/critique_storage.rs#L214-L227写入 frontmatter 的target_identity快照 frontmatter 携带slug、timestamp、target_identity、target_fingerprint、target_path与布尔closed标记frontmatter 解析见 crates/context/src/critique_storage.rs#L87-L133。四、第 3 步分诊Triage——先修功能缺陷再修美观问题把缺陷分成功能缺陷与美观缺陷两类并按以下顺序修复已破坏或被阻塞的任务、数据丢失、误导性状态、不可达路径最高优先级P0 级别缺失的状态loading、empty空态、error错误态、success成功态、disabled禁用态、permission权限态流程、层级、响应式与设计系统偏离视觉与动效不一致代码与资源清理。同时遵守一条平衡铁律不要把某个角落修到完美而让其余部分低于同一质量线。整条路径必须齐平而不是单点闪耀。五、第 4 步细化整条路径Polish the whole path5.1 流程与层级Flow and hierarchy与相邻产品的心理模型、术语、信息揭示disclosure、路由、保存行为、乐观/悲观更新模式保持一致让主要任务与当前状态显而易见——但不要把所有元素压成同等权重确保到达路径、过渡路径、空路径、恢复路径相互衔接而不是各自孤立成屏。5.2 布局与排版Layout and type对齐到项目的网格与间距刻度既要修数学对齐也要修光学对齐相关内容紧凑分组不同内容组之间慷慨留白同角色的排版保持一致测试 measure行长、换行、本地化扩展、缩放与字体加载验证每一个受支持的视口而不是只修当前截图。5.3 颜色、图像与图标Color, imagery, and icons使用语义化 token并保证各主题下颜色含义稳定在每个状态下验证文本、控件与焦点的对比度图标家族、描边/字重、尺寸与光学对齐保持一致防止图片布局偏移layout shift正确的宽高比、响应式图片来源、有意义的 alt 文本。5.4 交互与状态Interaction and state每个控件都需要恰当的 default、hover、focus、active、disabled、loading、error、success 行为保留可见键盘焦点、逻辑 Tab 顺序、标签与平台合适的触摸目标touch target动效保持连贯、可中断、高性能不要为了让 polish 可见而添加动画在产品可能遇到的场景中验证长内容、缺失内容、本地化、离线、慢网、权限受限的内容。5.5 内容与代码Content and code术语、大小写、标点与事实性文案保持一致修改事实性声明前先问用户移除调试输出、死代码、未使用的 import、废弃样式与 polish 过程中产生的重复用共享组件替换自定义实现——只要系统拥有该模式把真正可复用的值提升为 token不要为单一局部例外创建一个系统抽象回到第 1 步的 missing token vs one-off 判断。六、第 5 步验证与收尾Verify and finish6.1 完整路径走查再次用鼠标、键盘与触摸如适用走完整条路径检查布局Web 的 mobile / intermediate / wide 三档原生两种支持方向下的 phone 与 tablet 尺寸级别状态loading、empty、error、success、disabled、long-content、missing-content可访问性缩放、对比度、焦点、语义与屏幕阅读器名称运行环境控制台错误、布局偏移、交互延迟、图片加载——Web 在所有受支持浏览器上原生在受支持 OS 版本上同时检查运行时警告与掉帧一致性与 DESIGN.md、相邻功能以及用户界定的范围是否一致。6.2 质量指导与 QA 命令遵循impeccable context与 hooks 提供的质量指导再运行其他相关 QA 命令关于手动扫描有一个重要边界只有当没有任何自动检测器在运行时context 才要求手动扫描永远不要追加一轮 detector pass只修复真实缺陷只对极窄的、有意的例外做文档化记录扫描干净 ≠ 视觉合格——干净的扫描不能替代视觉判断。6.3 以源码 diff 收尾移除意外改动accidental churn、孤儿代码、冗余值、临时产物只有当功能在整条路径上功能完整且一致完成时才允许发布。6.4 关闭快照critique-storage close当本轮清除了它从快照中承接的全部 Priority Issue 时关闭该快照.trae/skills/impeccable/scripts/impeccable critique-storage close resolved target snapshot_file returned by latest关闭的语义源码见 crates/context/src/critique_storage.rs#L292-L334 与测试 crates/context/src/critique_storage.rs#L825-L863关闭动作把closed: true写入快照 frontmatter幂等已关闭的快照重复 close 是静默 no-op退出码 2只关闭本轮实际处理的那一个快照如果期间有新 critique 落盘它的积压事项仍然保持活跃不同 UTC 秒内的写入通过~0000~9999固定宽度碰撞后缀共存历史不会被覆盖见 write 子命令 crates/context/src/critique_storage.rs#L506-L536在以下情况不得关闭没有读过任何快照、没有保留snapshot_file、或仍存在 Priority Issue 未清除。七、与 critique 的协作闭环快照的完整生命周期polish 不是孤立的动作它与critique构成一个可审计的闭环完整流程见 .trae/skills/impeccable/reference/critique.mdcritique 写入critique 运行结束后把完整报告启发式评分表、设计特异性结论、Priority Issues、Persona 红旗等通过IMPECCABLE_CRITIQUE_META环境变量携带结构化元数据total_score、max_score、na_heuristics、p0_count、p1_count调用critique-storage write resolved target body-file落盘为快照并记录内容的精确 SHA-256 指纹使 polish 无需依赖 Git 状态或时间戳即可判断评的是哪些字节polish 读取进入 polish 时用critique-storage latest承接 P0/P1 积压事项polish 关闭全部清完后用critique-storage close关闭该快照。关于 Priority Issue 的等级定义见 .trae/skills/impeccable/reference/critique.mdP0是阻塞级完全阻止任务完成立即修复P1是重大造成显著困难或困惑发布前修复P2是次要恼人但有绕过方案P3是 polish 级锦上添花。polish 流程承接的正是 P0/P1 这些发布前必须清掉的事项。八、实战自查清单开始 polish 之前把这五条当作门禁范围在位视觉世界、内容、行为、范围外的一切是否原样保留概念错了是否已直说并建议 bolder/重设计证据是否在代表尺寸上亲自走完路径上一轮 critique 是否已读取latest并在收尾时关闭close分类每处 drift 是否已归类为 missing token / one-off / conceptual mismatch / local defect并在最窄正确层级修复齐平整条路径是否处于同一质量线而非一个角落完美、其余低于标准收尾source diff 是否干净只在无残留 Priority Issue 且持有snapshot_file时才关闭快照把 polish 当作发布前的最后一道关卡它不创造新的视觉世界而是让已存在的世界在整条路径上完整、一致、无残留地交付。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Impeccable polish 收尾指南：在提交前完成一次有据可依、绝不越界的精细化打磨
Impeccable polish 收尾指南在提交前完成一次有据可依、绝不越界的精细化打磨【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本篇指南解读 impeccable 技能体系中polish [target]命令的完整操作规范依据 .trae/skills/impeccable/reference/polish.md。polish属于 impeccable 命令体系中的Refine细化类命令其定位见 skill/scripts/command-metadata.json「执行一次最终质量收尾修复对齐、间距、一致性与微细节问题用于发布之前——当用户提到 polish、收尾、pre-launch review、看起来不对劲或想让作品从好变成优秀时」。读完本文你将掌握如何在既有视觉系统内对一条完整用户路径做证据驱动的缺陷分类与修复如何用critique-storage命令消费上一轮 critique 的优先级问题P0/P1并正确地关闭快照以及如何在收尾时做到「整条路径一致完成」而不是单点修补。一、先立规矩Polish 是细化绝不是隐蔽的重设计polish 流程的第一条硬性约束是划清「细化」与「重设计」的边界保留在位的一切既有的视觉世界incumbent visual world、内容、行为以及一切不在本次范围内的事物都必须原样保留概念本身错了就直说如果问题出在概念层面信息架构、产品定位应当明确建议走bolder或重设计路线见 .trae/skills/impeccable/reference/bolder.md——bolder 是「对已上线表面做放大强化」的细化命令而不是把替换方案偷偷塞进 polish 流程里检测结果是缺陷证据不是质量证明impeccable detect的扫描输出只说明哪里可能有缺陷必须亲自检查渲染后的真实体验与真实交互路径才能判断质量。这条原则与 impeccable 的世界变更语义一致见 skill/SKILL.src.md细化保留在位者重设计才替换。polish 永远站在保留这一侧。二、第 1 步建立系统Establish the system动手改任何东西之前先建立什么是对的的参照系阅读项目的DESIGN.md以及有代表性的 token、共享组件、既有模式与相邻流程如果项目没有正式的设计系统就以连贯的项目约定coherent project conventions作为参照无法从证据推断出具有约束力的系统原则时直接向用户提问不要擅自假设。然后把每一处偏离drift先分类再决定修法分类含义处理方向missing token缺 token系统需要一个可复用的值沉淀为系统 tokenone-off implementation一次性实现已有共享组件/模式可以取代它替换为共享实现conceptual mismatch概念错位流程、信息架构或层级与同类产品区域不一致修正到系统所表达的心智模型local defect局部缺陷实现本身不完整或不一致在局部补完修复层级原则在最窄且正确的层级修复原因——能改组件就不改页面能改 token 就不改组件修复手法不能比问题本身更宽泛。三、第 2 步收集证据Gather the evidence3.1 在真实尺寸上走一遍必须亲自在代表性的尺寸上使用该功能Web桌面与移动两种代表性尺寸原生平台ios/android/adaptive在模拟器、真机或硬件上按对应平台参考ios.md、android.md、adapt.native.md的 Verifying the build 章节采集证据。观察过程中需要确认四件事这条路径是否功能完整预期质量线quality bar与可用时间已知约束或有意未完成的部分用户真实会遇到的状态、内容长度、角色与输入方式。3.2 读取上一轮 critiquecritique-storage latest如果存在上一轮 critique 快照将其作为输入之一它只是输入之一不是唯一输入.trae/skills/impeccable/scripts/impeccable critique-storage latest resolved target --json这条命令由 Rust 引擎实现核心代码在 crates/context/src/critique_storage.rsrun函数位于 crates/context/src/critique_storage.rs#L441-L702CLI 启动器为 skill/scripts/impeccable。理解它的语义才能正确用它退出码语义Exit 0返回最新快照的body完整 critique 报告正文与精确的snapshot_file身份标识JSON 模式下--json输出{snapshot_file: ..., body: ...}。必须把snapshot_file保留到本轮结束它是最后关闭快照的凭证Exit 2表示不存在快照或目标已变化见下方指纹机制或快照已关闭。本地文件目标的指纹校验机制对于本地文件目标helper 会把文件当前内容的精确指纹与 critique 快照时记录的指纹sha256:hex见 crates/context/src/critique_storage.rs#L229-L238 的fingerprint_target进行比较内容未变包括 staged、unstaged、untracked 任意一种未变状态→ 快照仍然 current任何字节变化、删除、或文件被替换为非文件 → 该快照识别的积压事项被自动关闭closed: true写入 frontmatter见close_snapshot与insert_closed_flagcrates/context/src/critique_storage.rs#L290-L334同时保留其趋势历史命令以exit 2退出。也就是说文件被改过上一轮的缺陷清单就不再算数——这正是检测结果是缺陷证据在存储层的体现。URL 目标URL 目标没有本地指纹is_http判定后不计算指纹crates/context/src/critique_storage.rs#L199-L203因此一直保持 current直到被显式关闭。无论何种情况当快照 current 时把body中相关的P0/P1发现纳入本轮修复并明确说出读了哪个快照exit 2 时同样要独立完成一轮自己的检查——上一轮 critique 只是输入不是免检凭证。快照的存储形态便于理解身份机制目录project_root/.impeccable/critique/见get_critique_dircrates/context/src/critique_storage.rs#L12-L14文件名UTC时间戳[~碰撞后缀]__slug.md形如2026-05-12T18-30-00Z__app-tsx.mdis_snapshot_name校验crates/context/src/critique_storage.rs#L140-L180目标身份本地文件为file:绝对路径URL 为url:originpathnameresolve_target_identitycrates/context/src/critique_storage.rs#L214-L227写入 frontmatter 的target_identity快照 frontmatter 携带slug、timestamp、target_identity、target_fingerprint、target_path与布尔closed标记frontmatter 解析见 crates/context/src/critique_storage.rs#L87-L133。四、第 3 步分诊Triage——先修功能缺陷再修美观问题把缺陷分成功能缺陷与美观缺陷两类并按以下顺序修复已破坏或被阻塞的任务、数据丢失、误导性状态、不可达路径最高优先级P0 级别缺失的状态loading、empty空态、error错误态、success成功态、disabled禁用态、permission权限态流程、层级、响应式与设计系统偏离视觉与动效不一致代码与资源清理。同时遵守一条平衡铁律不要把某个角落修到完美而让其余部分低于同一质量线。整条路径必须齐平而不是单点闪耀。五、第 4 步细化整条路径Polish the whole path5.1 流程与层级Flow and hierarchy与相邻产品的心理模型、术语、信息揭示disclosure、路由、保存行为、乐观/悲观更新模式保持一致让主要任务与当前状态显而易见——但不要把所有元素压成同等权重确保到达路径、过渡路径、空路径、恢复路径相互衔接而不是各自孤立成屏。5.2 布局与排版Layout and type对齐到项目的网格与间距刻度既要修数学对齐也要修光学对齐相关内容紧凑分组不同内容组之间慷慨留白同角色的排版保持一致测试 measure行长、换行、本地化扩展、缩放与字体加载验证每一个受支持的视口而不是只修当前截图。5.3 颜色、图像与图标Color, imagery, and icons使用语义化 token并保证各主题下颜色含义稳定在每个状态下验证文本、控件与焦点的对比度图标家族、描边/字重、尺寸与光学对齐保持一致防止图片布局偏移layout shift正确的宽高比、响应式图片来源、有意义的 alt 文本。5.4 交互与状态Interaction and state每个控件都需要恰当的 default、hover、focus、active、disabled、loading、error、success 行为保留可见键盘焦点、逻辑 Tab 顺序、标签与平台合适的触摸目标touch target动效保持连贯、可中断、高性能不要为了让 polish 可见而添加动画在产品可能遇到的场景中验证长内容、缺失内容、本地化、离线、慢网、权限受限的内容。5.5 内容与代码Content and code术语、大小写、标点与事实性文案保持一致修改事实性声明前先问用户移除调试输出、死代码、未使用的 import、废弃样式与 polish 过程中产生的重复用共享组件替换自定义实现——只要系统拥有该模式把真正可复用的值提升为 token不要为单一局部例外创建一个系统抽象回到第 1 步的 missing token vs one-off 判断。六、第 5 步验证与收尾Verify and finish6.1 完整路径走查再次用鼠标、键盘与触摸如适用走完整条路径检查布局Web 的 mobile / intermediate / wide 三档原生两种支持方向下的 phone 与 tablet 尺寸级别状态loading、empty、error、success、disabled、long-content、missing-content可访问性缩放、对比度、焦点、语义与屏幕阅读器名称运行环境控制台错误、布局偏移、交互延迟、图片加载——Web 在所有受支持浏览器上原生在受支持 OS 版本上同时检查运行时警告与掉帧一致性与 DESIGN.md、相邻功能以及用户界定的范围是否一致。6.2 质量指导与 QA 命令遵循impeccable context与 hooks 提供的质量指导再运行其他相关 QA 命令关于手动扫描有一个重要边界只有当没有任何自动检测器在运行时context 才要求手动扫描永远不要追加一轮 detector pass只修复真实缺陷只对极窄的、有意的例外做文档化记录扫描干净 ≠ 视觉合格——干净的扫描不能替代视觉判断。6.3 以源码 diff 收尾移除意外改动accidental churn、孤儿代码、冗余值、临时产物只有当功能在整条路径上功能完整且一致完成时才允许发布。6.4 关闭快照critique-storage close当本轮清除了它从快照中承接的全部 Priority Issue 时关闭该快照.trae/skills/impeccable/scripts/impeccable critique-storage close resolved target snapshot_file returned by latest关闭的语义源码见 crates/context/src/critique_storage.rs#L292-L334 与测试 crates/context/src/critique_storage.rs#L825-L863关闭动作把closed: true写入快照 frontmatter幂等已关闭的快照重复 close 是静默 no-op退出码 2只关闭本轮实际处理的那一个快照如果期间有新 critique 落盘它的积压事项仍然保持活跃不同 UTC 秒内的写入通过~0000~9999固定宽度碰撞后缀共存历史不会被覆盖见 write 子命令 crates/context/src/critique_storage.rs#L506-L536在以下情况不得关闭没有读过任何快照、没有保留snapshot_file、或仍存在 Priority Issue 未清除。七、与 critique 的协作闭环快照的完整生命周期polish 不是孤立的动作它与critique构成一个可审计的闭环完整流程见 .trae/skills/impeccable/reference/critique.mdcritique 写入critique 运行结束后把完整报告启发式评分表、设计特异性结论、Priority Issues、Persona 红旗等通过IMPECCABLE_CRITIQUE_META环境变量携带结构化元数据total_score、max_score、na_heuristics、p0_count、p1_count调用critique-storage write resolved target body-file落盘为快照并记录内容的精确 SHA-256 指纹使 polish 无需依赖 Git 状态或时间戳即可判断评的是哪些字节polish 读取进入 polish 时用critique-storage latest承接 P0/P1 积压事项polish 关闭全部清完后用critique-storage close关闭该快照。关于 Priority Issue 的等级定义见 .trae/skills/impeccable/reference/critique.mdP0是阻塞级完全阻止任务完成立即修复P1是重大造成显著困难或困惑发布前修复P2是次要恼人但有绕过方案P3是 polish 级锦上添花。polish 流程承接的正是 P0/P1 这些发布前必须清掉的事项。八、实战自查清单开始 polish 之前把这五条当作门禁范围在位视觉世界、内容、行为、范围外的一切是否原样保留概念错了是否已直说并建议 bolder/重设计证据是否在代表尺寸上亲自走完路径上一轮 critique 是否已读取latest并在收尾时关闭close分类每处 drift 是否已归类为 missing token / one-off / conceptual mismatch / local defect并在最窄正确层级修复齐平整条路径是否处于同一质量线而非一个角落完美、其余低于标准收尾source diff 是否干净只在无残留 Priority Issue 且持有snapshot_file时才关闭快照把 polish 当作发布前的最后一道关卡它不创造新的视觉世界而是让已存在的世界在整条路径上完整、一致、无残留地交付。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考