🛡️C-A-R 协议 · 如何用你的 AI（Claude Code、Codex、NeuralOS）构建零 bug 的软件

从现在起，对所有非琐碎的工作（新功能、重构、跨文件改动）应用「构建-审计-反思」（C-A-R）协议。只有在一行的琐碎修复，或我明确要求时，才跳过它。

=== 阶段 1 · 构建 ===
带着创造力去构建。写代码之前先研究竞品的标准。做边界清晰的架构。一边推进一边自测。
完成后，停下来给我一份报告：
- 创建/修改的文件和关键决定
- 你在标准之上加了哪些改进
- 测试结果（type-check、build、tests）
- 有什么没做以及为什么（范围边界）
然后等待。这个回合里不要审计。不要把审计和构建混在一起。

=== 阶段 2 · 审计（独立回合 · 需要我批准）===
等我说「开始审计」。然后：
1. 用审计者的头脑（清醒、悲观）重读每个文件
2. 分类记录发现：
   - 关键项：真正的 bug（内存泄漏、竞态条件、安全漏洞、无障碍缺陷、语义错误、数据损坏）
   - 改进项：健壮性、性能、UX 打磨
3. 为每个发现配一条回归测试来固定住修复——没有测试，修复就不算完成
4. 跑激进的边界用例测试：unicode、边界值、事件刷屏、并发操作、取消路径
5. 四重验证：type-check + build + 现有 tests + 新 tests，全绿了才收尾

=== 阶段 3 · 反思（随审计一起）===
写一份经验教训文档：每个发现连同它的根因（我在构建者模式下漏掉了什么？）、元教训，以及为下一次构建更新的检查清单。这份文档随每一轮循环成长，是项目的记忆。

规则：
- 永远不要在构建的同一回合里审计。
- 永远不要在没对新代码跑过一次真正审计的情况下声称「没有 bug」。
- 永远不要跳过审计修复的回归测试。
- 根因，绝不打补丁。如果一个值到达时是空的，就找出为什么；不要用一个默认值把它盖过去。

=== 循环收尾 · GITHUB ===
在审计全绿之后（type-check + build + 冒烟测试全部通过），在把工作视为完成之前：
1. 如果我们还没跑冒烟测试，提醒我去跑。
2. 做一次 commit，写一条清晰描述我们成果的信息。
3. push 到 GitHub，把好的节点存到云端。
绝不在没把进度备份好的情况下收尾一个循环。

=== 审计的深层上下文 ===
审计之前，查询项目的知识图谱（Graphify）或 RAG，理解我改动的东西如何与其余部分连接。审计时要理解对**整个系统**的影响，而不只是我改的那个文件。问自己：还有哪些部分依赖它？可能级联地弄坏了什么？

=== 循环收尾 · 全栈 ===
当审计全绿时，按这个顺序把整个循环闭上：
1. 冒烟测试 → 全绿。
2. commit + push 到 GitHub（存好节点）。
3. 重建 / 更新知识图谱（Graphify）让它反映新改动，这样下一次审计就有新鲜的上下文。
4. 把审计的经验教训存进项目的记忆文档。
5. 确保 C-A-R 协议仍写在 CLAUDE.md 里，以免忘记。
这个循环在每个 sprint 或每一段重要的开发之后应用。