AI Agent 已经能在很短时间内生成大量代码，真正变慢的环节却变成了人：阅读、验证、建立心智模型，以及判断这段代码是否真的适合当前系统。Notion 设计工程师 Geoffrey Litt 在 AI Engineer 大会上的演讲把这个变化概括为一句话：理解才是新的瓶颈。
这不是“要不要继续看代码”的问题，而是代码生产速度改变之后，工程师需要重新设计理解代码的方式。
从写代码瓶颈转向理解瓶颈
过去，一个功能从需求到上线，主要受实现速度限制。工程师需要设计接口、编写逻辑、补测试，再根据反馈迭代。现在，Agent 可以迅速生成实现、修改多个文件，甚至根据错误日志继续尝试修复。
但生成速度不会自动带来可靠性。代码进入仓库之后，仍然需要有人回答几个问题：
- 这段实现解决的到底是什么问题？
- 它依赖了哪些现有约定和隐含状态？
- 异常路径、权限边界和数据一致性是否被覆盖？
- 未来的维护者能否快速判断它为什么这样写？
当 Agent 每分钟生成的代码远超过人类能仔细阅读的代码量时，“逐行阅读全部代码”不再是唯一可行的理解方式。工程师需要把注意力从代码产出转移到结构、证据和风险上。
理解代码，不等于读完每一行
可以把 AI 生成代码后的审查分成三层。
第一层是目标理解。先让 Agent 说明它修改了什么、没有修改什么，以及实现依赖哪些假设。这一步的产物不是最终文档，而是一张小型地图，帮助人快速定位变化范围。
第二层是行为理解。围绕输入、输出、状态变化和失败路径检查代码，而不是只看函数名称或代码格式。对于接口服务，重点通常包括鉴权、幂等、超时、重试和错误响应；对于数据处理逻辑，则要关注空值、重复数据、边界条件和回滚行为。
第三层是证据验证。测试、类型检查、静态分析、日志和运行结果都可以帮助人减少纯阅读负担。但这些工具只能提供证据，不能替工程师决定需求是否被正确理解。
因此，Agent 生成的解释也不能直接视为事实。解释必须能够和代码、测试结果以及系统行为互相验证。
一个可落地的 Agent 协作流程
下面是一个可以改造到现有项目中的最小流程。假设项目使用 Git，Agent 已经在当前分支完成了一次修改。先不要直接通读所有文件，而是让它生成结构化变更报告：
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '## Changed files'
git diff --stat
git diff --name-only
printf '%s\n' '## Tests changed or added'
git diff --name-only -- '*test*' '*spec*' || true
printf '%s\n' '## Review questions'
printf '%s\n' '- What user-visible behavior changed?'
printf '%s\n' '- Which assumptions does the implementation make?'
printf '%s\n' '- What happens on timeout, duplicate input, or authorization failure?'
printf '%s\n' '- Which tests provide evidence for the main behavior?'
可以把命令输出连同任务要求交给 Agent，并要求它只回答这些问题：
请基于当前 Git diff 生成一份审查摘要，不要重新实现代码。
请按以下结构回答：
1. 用户可观察到的行为变化
2. 修改涉及的模块和依赖关系
3. 正常路径与失败路径
4. 关键假设和潜在风险
5. 已有测试能证明什么，不能证明什么
6. 我应该优先阅读的三个代码位置
每一项都必须引用具体文件和函数名；无法从 diff 或测试中确认的内容标记为“未知”。
接着，人类工程师只需要沿着风险最高的路径检查实现，并运行与改动相匹配的验证命令。例如：
# 根据项目实际命令替换下面两行
python -m pytest -q
python -m compileall src/
这个流程的重点不是让 Agent 替人做审查，而是让它承担整理上下文、列出影响范围和暴露未知信息的工作。人类仍然负责判断：这个行为是否符合产品意图，风险是否能接受，以及验证是否足够。
速度越快，边界越要清楚
AI 生成代码最容易制造一种错觉：代码已经存在，所以问题已经解决。实际上，生成代码会放大几类工程风险。
上下文遗漏。 Agent 可能只看到当前任务和局部文件，不知道历史兼容性、线上约束或团队约定。修改跨模块行为前，应主动提供接口契约、相关测试和失败案例。
解释替代验证。 一段清晰的说明不代表实现正确。解释应该服务于验证，而不是终止验证。
审查负担堆积。 如果团队持续合并大量“看起来没问题”的 AI 代码，理解债务会像技术债一样累积。可以限制变更规模，要求每个变更说明行为影响，并把关键决策写入可检索的工程文档。
责任边界模糊。 Agent 可以提出实现方案，但生产发布、数据迁移、权限变更和安全决策仍需要明确的责任人。生成速度越快，批准机制越不能含糊。
给团队的采用清单
可以从几个低成本动作开始：
- 要求 Agent 输出变更地图，而不只是代码补丁。
- 让每个任务明确“不在范围内”的行为，避免 Agent 自行扩大修改面。
- 审查输入、输出、状态变化和失败路径，减少逐行阅读的压力。
- 把测试结果、运行日志和类型检查当作证据链的一部分。
- 对鉴权、支付、数据迁移和并发逻辑保留人工深度审查。
- 定期删除无效解释和过期文档，避免上下文本身变成噪声。
AI 让代码生产变快之后，工程师的价值不会只体现在打字速度上。更重要的能力，是快速建立正确的系统模型，识别哪些地方值得深挖，并用足够强的证据判断一项修改能否进入真实环境。理解没有消失，只是从编码过程中的默认动作，变成了需要被主动设计的工程流程。