黄金原则

要解决什么问题

AI 辅助写代码后，团队里常见三类重复劳动：Review 里一遍遍说「别用 var」「异步错误要处理」；某类 bug 在多个 PR 里以同样方式被修；还有人定期手工「打扫」AI 生成的不一致风格。这些不是架构级不变量，而是习惯与品味——若只靠人工提醒，偏差会堆几个月，直到某次大清理才还债。

本技能把「人类判断说一次、之后每行代码都对照检查」当作目标：从真实信号（Review 评论、重复 bug、重构 PR）蒸馏 Golden Principles，能写成 lint 的优先 lint，其余记作文档化品味原则；再由固定节奏的扫描发现模式漂移，产出可在约一分钟内审完的小粒度 fix PR，而不是一次性吞掉整个技术债。

技能如何工作

• 蒸馏原则：从「这次怎么修」抽象成「以后应怎么做」；禁止凭空编规则，每条原则应对应具体 Review/缺陷信号。
• 扫描节奏：初始化期可每日扫；稳态建议每周一早晨扫一轮，每轮 fix PR 只覆盖 3～5 种偏差类型；紧急修复后对相关原则补扫；季度审计淘汰零触发、合并重叠检查。
• 执行边界：纯机械改动（重命名、抽公共方法、换标准 SDK）可配置 [GC-auto] 自动合并；涉及行为变更必须人工 Review。
• 产出与记账：扫描报告写入 docs/quality-reports/golden-principles-scan.md；本轮未处理的发现必须记入 docs/exec-plans/tech-debt-tracker.md，避免「扫完即忘」。

与 architecture-boundaries 的分工要清楚：结构约束是合并前 CI 红线；品味原则是合并后的周期性清扫，不要把品味做成 merge blocker，否则吞吐下降且团队会绕过机制。

适用边界与注意点

• 需要依赖方向、数据边界等结构性约束时，应使用 architecture-boundaries，而非本技能。
• 项目极小、几乎没有重复模式时，周期性扫描意义不大。
• 用户只想了解现有规则、或明确表示不做扫描/不建规则时，不要强行启动扫描周期。
• 大规模存量违反新原则时：增量采纳（按模块/文件类型/模式分批），全量清单进 tech-debt-tracker，切忌一次扫平。
• 某条原则在多个周期里频繁触发，通常说明缺共享工具包或需要根本性重构，而不是「多扫几次就好」。