用途：Code Polish 是一个基于约束的协议，用于规范化代码注释并做安全的非语义清理，让代码达到专业级文档水平而不触碰行为。适用于用户要求“清理”“专业化”“润色”现有代码、代码即将进入评审/交接/开源/文档化、文件混有人写与 AI 写注释需统一语气，或注释过时、缺失、冗余、口语化（吐槽、占位符、内部玩笑）时；用户想改进注释但明确不想动逻辑时也适用。不适用于修 bug、改行为、完整重写或架构重构、只加新功能。
主要能力：分阶段执行。Phase 0 全量通读，先阅读整个文件或相关模块，识别语言惯用注释约定（JSDoc、Python docstring、Rust ///、XML doc comment 等）、项目已有风格，以及携带非显而易见信息的注释（竞态、外部 bug 规避、勿重排警告、业务规则依据），且不在阅读过程中边读边改。Phase 1 注释审计，把每条注释分类：垃圾/吐槽、占位符、死代码注释、冗余、过时/错误、有价值但非正式、缺失，并对应处理（去除语气并提取真实信息、转为规范 TODO 或删除、移除注释掉的代码除非明确有意保留、删除冗余、按当前行为重写并告知过时、保留信息重写语气、为复杂逻辑或公开 API 补充）。Phase 2 非语义清理，仅限不会改变行为的内容：一致缩进与空白、与周围文件一致的花括号风格、明确无歧义时移除死代码并汇报、拆分过长行、仅对私有/局部名称做无歧义改名，公开或跨文件引用不得擅自改名。Phase 3 注释重写/新增，要求解释 why 而非 what、使用该语言惯用文档格式、简洁、无口语化、无 AI 腔与破折号、不编造行为。Phase 4 验证，确认逻辑与原始版本行为一致，仅允许注释与空白差异加上有限的 Phase 2 清理；完整复读 diff；若重写丢失原有信息（即使非正式表达）视为失败。Phase 5 汇报，说明改写/新增/删除注释数量与原因、被标记的“非正式但含真实警告”注释、删除的死代码或过时注释、不确定而保留未动的内容。
限制：无法验证运行时行为，Phase 4 只是通读 diff 检查而非跑测试，用户仍应运行测试套件。对歧义情况默认标记而非猜测。不能替代 linter 或格式化工具，Phase 2 清理刻意保守，不会强制完整风格指南。注释质量受限于从上下文可推断的真实意图；若 why 确实无法恢复，就只写 what，不编造理由。大文件或不熟悉的代码库会增加 Phase 0 漏读上下文的风险，应在汇报中标注不确定性。不改变程序逻辑、控制流或算法行为，不重构代码，未经确认不改公开/导出/交叉引用名称。安装方式暂未提供。