编码交给AI之后

半年前，我的工作方式开始发生变化。

写代码这件事，大部分时间不再由我完成。我的角色从「写代码的人」变成了「判断代码是否正确的人」。

项目成败的关键在于我在哪些环节介入了判断。这篇文章探讨当编码由 AI 负责时，人到底应该做什么。

验收者的三个环节

我把验收工作拆解为三个环节，定义问题，验证实现，决定交付。

验收者的工作区别于代码审查员和产品经理。验收者要做的事情更具体，知道要什么，判断对不对，决定行不行。

定义问题

AI编码的前提是问题的清晰程度。模糊的需求必然产生模糊的输出。

一个合格的问题定义包含三个要素。第一，输入输出的边界。明确说「输入是一个CSV文件包含用户行为日志，输出是每个用户的留存率，格式是JSON数组」。第二，失败的样例。给AI提供失败样例，相当于提前划定验收的红线。第三，约束条件。性能要求、依赖限制、代码风格偏好。一旦明确说「不使用外部依赖、代码不超过200行」，生成结果的实用性会显著提升。

三个要素缺一个，验收就可能在后续环节出问题。缺少明确的输入输出边界时，AI可能生成一个在功能上正确但接口设计完全不同的模块，导致集成时才发现不匹配。缺少失败样例时，AI只会覆盖正常路径，异常情况全部留给验收者发现。定义问题不是一次性动作，在项目推进中也会迭代。

验证实现

代码能跑只是最低要求。真正的验证是回答这个问题，这个实现在我未知的场景下是否可靠。

对比测试。给AI同一组需求的不同版本，看输出差异是否合理。如果同一需求两次生成的结果在核心逻辑上不一致，说明需求本身有歧义，需要回到定义问题环节重新澄清。

边界测试。异常情况——空输入、超大文件、并发请求——才是考验实现质量的场景。具体做法是枚举每个输入参数的边界值（0、1、最大值），逐一验证AI生成的代码能否正确处理。大多数AI生成的代码在正常路径上表现良好，但在边界处暴露出缺少校验、资源泄漏或死循环。

回归测试。AI生成代码的成本低，但重新生成不保证一致性，任何改动都需要回归验证。回归的关键是确定受影响的模块范围，AI生成的代码往往有隐含的跨模块依赖，仅凭代码diff难以识别全貌。

验证环节最容易被跳过的是记录。这些记录是下一次定义问题的输入。

决定交付

这是验收者最核心的判断。

我看三个标准。第一，核心路径是否可靠。用户最常使用的功能链路必须经过验证，核心路径的每个环节至少手动验证一次。第二，失败是否可控。用三个问题检验，最坏情况下用户会看到什么？数据是否会丢失？系统是否能恢复？如果答不上来，返回验证环节补充对应场景的测试，直到三个问题都有明确答案。第三，是否超出必要范围。AI倾向于生成「功能完整」但超出需求的代码。如果它生成的比你需要的多，删减比新增更需要判断力。

我在几个项目中踩过类似的坑。AI生成的代码功能齐全测试通过，但某个输入阈值下处理时间飙升——缺少分批处理。另一次跳过回归验证，小改动破坏了隐藏的依赖。代码没有bug，但「完成」和「可用」之间存在盲区，这恰好是验收者需要填补的。

两个具体示例

博客改造

需求是三个 Agent 友好端点 llms.txt、Markdown 端点、结构化 JSON API，所有新增内容作为静态文件生成。验证阶段用 curl 确认格式正确，修改源文件后重新构建确认同步更新，模拟 Agent 使用场景确认所有链接存在。交付阶段评估三个指标，核心路径已验证、失败可控（端点不可用时返回 404）、没有超出范围。改造耗时半天，编码不超过两小时。

数据处理微服务

需求是把上游推送的 JSON 事件流转换为结构化数据写入数据库。定义问题时明确了输入格式、失败样例（缺失必需字段的事件按格式错误丢弃而非写入）和约束（单条处理时间不超过 200ms）。验证阶段准备了三组数据，正常数据、边界数据（空事件流、单条极大记录）、异常数据（格式错误、字段缺失）。AI 生成的代码在边界数据上暴露了两个问题，单条极大记录导致 JSON 解析超时，空事件流让写入进程挂起。交付阶段确认核心路径稳定、失败时可优雅降级、功能范围没有膨胀。

总结

人的价值体现在三件事，知道要什么，判断对不对，决定行不行。前两者依赖业务理解和经验积累，最后一个是风险判断。当AI负责了「怎么做」，人就更需要想清楚「要什么」和「好不好」。

如果只能记住一点，在AI时代，判断力比生成速度更稀缺。验收是编码的延续。