什么时候该新建一条 AI rule？

本章五个触发条件：(1) 同一新技术 / pattern 出现在 3 个及以上文件；(2) 一类常见 bug 用规则可预防；(3) Code review 反复出现同一反馈；(4) 新的安全或性能模式出现；(5) 复杂任务需要一致方法。低于 3 处的偶发模式不写规则，否则规则库会被噪声淹没。

什么时候是更新规则而不是新建？

五个信号：(1) codebase 出现更好的示例；(2) 发现新的 edge case；(3) 相关规则被更新过需要联动；(4) 实现细节变了；(5) 用户反馈说原规则有歧义。这些都是「现有规则不够用」而不是「缺少新规则」，硬拆成新规则会导致同一主题分裂在多处。

一条合格的 rule 应该包含哪几节？

本章模板五节：Purpose（这条规则解决什么）、When to Apply（适用场景 / 触发条件 / 前置条件）、Implementation（Basic Pattern + Advanced Pattern 各一段最小可跑示例）、Common Pitfalls（已知陷阱与规避）、References（关联规则 + 外部文档链接）。质量清单六条：Actionable / Specific / Tested / Complete / Current / Linked。

怎么衡量一条规则的真实效果？

本章列了四类指标：usage_count（被引用次数）、error_prevention（实际避免的 bug 数）、time_saved（每周节省工时）、user_feedback（团队评分 4.2/5 这种）。只看 usage_count 容易被"加载量"误导，真正的价值锚点是 error_prevention 和 time_saved，季度 review 时拿来淘汰低 ROI 规则。

废弃规则该怎么处理才不影响现有代码？

本章给的 deprecation 模板：状态标 "Deprecated as of v2.0.0"、Migration 链接到新规则、Removal Date 写明 6 个月后、原始内容保留供参考。不能直接删 — 团队还在引用它的代码 / PR template；先 deprecate 留过渡窗口，到期再移除，并跟 changelog 联动通知。

AI 规则持续改进

看完了，下一步

技能AI Engineer 全部章节回到这个方向的目录，按顺序把剩下的章节学完。看全部章节 →
技能在互动 Lab 里动手练选一个 Lab，在页面里把刚学的方法实际做一遍。去做练习 →
定位AI Engineer 学习路线图按阶段看这个方向要学什么、先学什么、学到哪一步算够用。看路线图 →