第 5 部分：审查与发布

当智能体写出你 80% 的代码时，你更多地扮演审查者而非作者的角色。工作从敲键盘转变为做判断——而这个判断必须比以前更敏锐，因为生成的代码以更隐蔽的方式失败，不同于人类写的代码。

让智能体做第一轮审查

在人工审查之前，先让智能体做第一轮。它擅长机械层面：发现可能的 Bug、风格违规、安全气味和性能问题。这可以过滤掉噪声，让人工审查者把注意力放在真正需要人来判断的事情上——设计、可维护性、以及这次改动是否符合系统的演进方向。

这种分工就是要点所在。第一轮审查是机械性的，可以委派。关于设计的最终判断则不能。

审查每一行将要上线的代码——带着正确的怀疑

因为代码能运行就信任它的本能，对生成的代码来说恰恰是错误的本能。审查每一行将要进入生产的代码，并把你的怀疑对准 AI 输出失败的特定方式：

• 对精巧的代码保持怀疑。 生成的解决方案有时会选择一个花哨的抽象，而平庸的才是正确的。精巧是一个警示信号，不是赞美。
• 确认导入的包真实存在。 模型会幻觉出听起来合理的包名。一个看起来正确的导入可能指向一个不存在的包——或者更糟，是一个恶意占用模型常用名的仿冒包。
• 针对真实失败场景检查错误处理。 生成的代码往往在正常路径上表现良好，在失败路径上却很薄弱。问问看：当网络调用超时、输入为空、数据行不存在时，会发生什么。

跳过这个步骤的代价是具体的：你的团队不理解的代码会变成你的团队承担不起的调试成本。快速生成带来的节省，在第一次有人花三天逆向工程一段没人审查过的精巧代码块时就烟消云散了。

钩子：让机器强制执行它容易忘记的规则

有些规则太重要了，不能依赖人工审查。把它们编码为钩子——在生命周期的固定节点（工具调用前、文件编辑后、提交前）运行的确定性代码，自动阻止不当行为。

一个拒绝提交硬编码密钥的 pre-commit 钩子：

#!/usr/bin/env bash
# .git/hooks/pre-commit
if git diff --cached | grep -E -i '(api[_-]?key|secret|password|token)\s*=\s*["'\''"][^"'\'']+'; then
  echo "Blocked: looks like a hard-coded secret. Remove it before committing."
  exit 1
fi

钩子是你放置"智能体（或人类）'永远不该忘记但经常忘记'的事情"的地方。与文件中的规则不同，钩子是说不过去的。

可观测性：看清智能体实际做了什么

你无法管理你看不见的东西。随着智能体承担越来越多的工作，建立可观测性，让你能够回答"它做了什么，为什么这样做？"。追踪：

• 每次运行的追踪（Trace）——步骤和工具调用的完整序列。
• 随时间变化的评估结果，以便质量回退能早早浮现。
• Token 成本和延迟，让悄悄变贵的工作流能被发现。
• 行为漂移——没有明显原因的随时间行为变化。

没有这些，一个行为异常的智能体就是一个黑箱，你唯一的调试工具就是猜测。

被低估的收益：维护工作

把你现在能力更强的工作流指向你一直在回避的工作。那些"风险太大，不敢碰"的遗留代码——因为只有最初的作者才理解它们——恰恰是智能体大展身手的地方：它可以读懂代码、推断模式、找到相关文件，并在尊重现有结构的前提下做出改动。

这解锁了以前永远不会发生的工作，因为它太繁琐、风险太高：框架迁移、废弃 API 更新、现代化旧测试套件。一个没人愿意花一个季度来做的迁移，变成了一个规格明确的后台任务，最后产出一个可供审查的 PR。

搭建你自己的工作流

• 在人工审查之前增加第一轮审查步骤（智能体审查 diff）。
• 为生成代码编写一份审查清单：精巧的抽象、幻觉的导入、薄弱的错误处理。
• 至少添加一个钩子——从上面的密钥拦截器开始。
• 开启智能体运行的追踪，随时间观察 Token 成本和评估分数。
• 选一段"风险太大不敢碰"的遗留代码，将其作为一个范围明确、可供审查的任务交给智能体。