通过明确的个人规则和禁区，建立起有理有据的结对编程，让辅助永远不会沦为依赖。
在 Kodokon 中打开本课永久性辅助所带来的职业风险，在人因工程里有一个名字：自动化自满。航空公司的飞行员对此深有体会——自动化越可靠，人就检查得越少，其手动技能也就在不知不觉中越发退化。对开发者而言，症状很具体：你接受的建议越来越长、审阅得越来越少，等到有一天 AI 不可用，或者在某个细微之处出了错，你才发现自己已经不知道该怎么独立完成了。应对之道不是禁欲，而是一份明确的使用契约——白纸黑字写下来、由你强加给自己。
这份契约的核心规则用四个字就能概括：我写，它审。你自己先写出代码，写出初稿，不借助辅助；AI 只在之后介入，作为审阅者。这个先后顺序的颠倒改变了一切：生产的努力——那种能建立并维持技能的努力——留在了你这里，而 AI 贡献它最擅长的东西，即对你成果那种详尽而不知疲倦的审视。这与那种主流的条件反射（让它生成，然后草草审一遍）恰好相反，后者颠倒了认知负荷：模型负责生产，你却继承了最难的角色——去评判一段并非由你想清楚的代码。
你是一位资深代码审阅者，要求严格但支持鼓励。我刚刚亲手写了这段代码，我想要的是一份帮助我进步的审阅，而不是一次重写。
背景：[语言、项目约束、这段代码本应做什么]。
[粘贴你的代码]
审阅规则：
1. 绝不完整重写代码，哪怕只是一个完整的函数也不行。
2. 给每条意见分类：可能的 bug / 生产风险 / 可读性 / 风格。
3. 对每一个可能的 bug，描述触发它的确切输入场景，但不要给出修复方案——我想自己找出来。
4. 最后，就我做出的某个在你看来值得商榷的设计选择向我提问。
格式：编号列表，最严重的意见排在最前面。最多 8 条意见。契约的第二条：禁区。事先划定项目中那些无论如何 AI 都绝不写下一行代码的部分。有三类是必不可少的。首先是安全关键的代码——身份认证、会话管理、加密、数据迁移——在这些地方，一个看似合理却错误的答案代价太高。其次是业务核心，也就是让你的产品有价值的那套逻辑：那正是你必须了如指掌的东西。最后，也是最不直观的一点，任何对新概念的初次接触：如果你让 AI 写你的第一个 Mutex、你的第一个 saga 或你的第一个 worker，你就永远学不会它。在这些禁区里，AI 仍保留一个角色：解释、追问、审阅。绝不生产。
你是我结对编程中的领航员：你引导，我驾驶。我卡在这个问题上：
[描述问题 + 粘贴错误信息或相关代码片段]
绝对规则：
1. 禁止给我超过一行的代码。
2. 用苏格拉底式的提问推进：帮我形成假设，然后设计能验证这些假设的测试。
3. 如果我走错了方向，明确指出并解释原因，但让我自己找到正确的方向。
4. 当我找到答案后，要求我用两句话复述根本原因，如果我的措辞不精确就纠正它。
先问我已经尝试过什么，以及我从中得出了什么结论。最后一条：度量。一份没有指标的契约撑不过六周。合适的指标不是提示词的数量，而是你的理解债务：本周提交到代码库中、你却无法凭记忆重写或详细解释的代码块的数量。每个周五都诚实地记下这个数字。如果它连续两周上升，就收紧契约：扩大禁区，回到严格的“我写，它审”。终极的检验方式和航空业一样：每周有一天关掉自动化，然后观察你还能做到什么。