保持人类在环：验证、测试并审查一切
AI 会非常乐意产出看起来煞有介事但可能有误的代码，你必须对质量负责——始终进行彻底的审查和测试。
我的核心准则之一是：永远不要盲目信任 LLM 的输出。正如 Simon Willison 所言，要把 LLM 结对程序员看作是“过度自信且容易犯错”的伙伴。
事实上，我将测试编织进了工作流本身。我早期的规划阶段通常包括为每一步生成测试列表或测试计划。如果我使用 Claude Code 这样的工具，我会指示它在完成任务后运行测试套件，并在出现失败时进行调试。这种紧密的反馈循环（编写代码 → 运行测试 → 修复）是 AI 擅长的领域，前提是测试已经存在。
毫不奇怪，那些从编程智能体中获益最多的人，往往是那些拥有强大测试实践的人。有了优秀的测试套件作为安全网，像 Claude 这样的智能体可以在项目中“飞翔”。如果没有测试，智能体可能会盲目地认为一切正常（“没问题，全搞定了！”），而实际上它已经破坏了好几处功能。所以，请投资于测试——它能放大 AI 的效用，并增强你对结果的信心。
除了自动化测试，还要进行代码审查——包括人工审查和 AI 辅助审查。我会定期停下来，逐行审查生成的代码。有时我会开启第二个 AI 会话（或使用不同的模型），要求它对第一个模型产出的代码进行评判或审查。例如，我让 Claude 编写代码，然后问 Gemini：“你能审查一下这个函数是否有错误或改进空间吗？”这能捕捉到一些细微的问题。
不要因为代码是 AI 写的就跳过审查。 相反，AI 编写的代码需要额外的审视，因为它有时在表面上极具说服力，却隐藏着人类可能不会立即察觉的缺陷。
频繁提交，将版本控制作为安全网
永远不要提交你无法解释的代码。频繁的提交是你的“存档点”——它们让你能撤销 AI 的失误并理解变更。
当与能快速生成大量代码的 AI 合作时，事情很容易偏离轨道。我通过采用超细粒度的版本控制习惯来缓解这一问题。我提交代码的频率比手动编码时还要高。在完成每个小任务或每次成功的自动化编辑后，我都会进行一次 Git 提交，并附上清晰的信息。
这样，如果 AI 的下一个建议引入了 Bug 或混乱的更改，我有一个最近的检查点可以回滚（或从中挑选代码），而不会损失数小时的工作。有人将其比作游戏中的“存档点”——如果 LLM 会话搞砸了，你总能回滚到上一个稳定的提交。我发现这个建议非常有用。当你明确知道可以通过 git reset 撤销操作时，尝试大胆的 AI 重构会变得轻松得多。
规范的版本控制也有助于与 AI 协作。由于不能指望 AI 记住它所做的一切（受上下文窗口限制等），Git 历史记录就成了一份宝贵的日志。我经常扫描最近的提交，向 AI（或我自己）简要说明发生了什么变化。事实上，如果你提供提交历史，LLM 本身也可以利用它——我曾将 git diff 或提交日志粘贴到提示词中，以便 AI 了解哪些代码是新的，或者之前的状态是什么。有趣的是，LLM 非常擅长解析 Diff 并使用 git bisect 等工具查找引入 Bug 的位置。它们有无限的耐心去遍历提交历史，这能增强你的调试能力。但前提是：你得有一份整洁的提交历史。
另一个好处是：带有良好注释的小型提交实际上记录了开发过程，这在进行代码审查时非常有帮助。如果一个 AI 智能体一次性做了五处更改且出了问题，将这些更改分在不同的提交中能更容易定位故障点。如果所有内容都挤在一个名为“AI 更改”的巨型提交中，那就祝你好运了！所以我对自己要求很严：完成任务、运行测试、提交代码。这也与之前提到的“将工作拆解为小块”相契合——每个块最终都成为一个独立的提交或 PR。
