# 代码写完不等于做对 AI 让代码实现越来越便宜，但验收不会。以后更难的工作，是确认一件事到底做没做对。 URL: https://foo-z.com/blog/ai-code-acceptance/ Author: Charliefoo Language: zh Published: 2026-08-30T00:00:00.000Z --- 最近几天看 AI 日报，我注意到一组变化。模型已经不只是回答问题，而是开始直接完成工作。 OpenAI 的企业研究把它概括成从 assistance 到 execution。企业不再只是问 AI 怎么做，而是让 Agent 读取资料、调用工具、创建文件，最后交付一份可以审核的结果。[4] 很多人的第一反应可能是：以后是不是只要会描述需求，代码就有人写了？ 我的判断是，代码实现会越来越便宜，验收不会。以后更难的工作，可能是确认一件事到底做没做对。 ## 写出代码已经不再是最难的部分 我过去做游戏策划时，很多想法不是死在设计上，而是卡在实现环节。一个功能要经过需求文档、设计稿、程序、美术和测试，最后才能变成玩家真正看到的东西。只要其中一个环节排期不够，想法就只能停在文档里。 现在，AI 已经可以替人完成其中相当一部分工作。写一个小工具、改一个页面、补几组测试、处理一批文件，只要目标明确，Agent 很快就能给出一个能运行的结果。 模型之间的差距，也正在从「能不能做」变成「做得多快、成本多高」。一篇基于 OpenRouter 数据的分析显示，平台上 84% 的 token 并不来自最前沿模型。主要流量模型的性能约为前沿模型的 77%，价格却只有很小一部分。[1] 这说明，很多任务根本不需要最强模型。边界足够清楚，普通模型也能承担大量执行工作。 ## 能运行，不代表值得交付 软件开发里有一个容易被忽略的区别：功能能运行，和功能做对，是两件事。 一个登录页面可以成功提交表单，但权限边界可能是错的。一个战斗系统可以正常计算伤害，但节奏可能让玩家觉得无聊。一张角色图可以符合提示词，放进整套资产后，比例、风格和辨识度却可能对不上。 AI 很擅长把明确要求翻译成结果。它很难替你决定这个结果是否值得存在。 我做 AI 美术时经常遇到类似问题。一次生成几十张图并不难，难的是从里面选出一个能继续发展的方向。选择不只是看哪张图好看，还要判断它能不能延展成三视图、表情、动作和后续资产。 这也是我在游戏开发里越来越明显的感受：实现成本下降以后，验收成本会上升。以前很多方案因为做不出来而被淘汰，现在它们都能被做出来，真正需要淘汰的是方向不对的方案。 ## AI 需要的是标准 Agent 参与执行以后，最有用的输入不是「做得高级一点」或者「界面更有质感」，而是可检查的标准： - 这个功能解决哪个具体问题？ - 什么情况算完成？ - 哪些边界不能碰？ - 结果要通过什么测试？ - 即使结果正确，什么情况下仍然不值得上线？ 这类标准以前常常藏在资深员工的经验里。设计师知道什么样的交互会让用户困惑，策划知道一个数值改动会怎样影响整个循环，工程师知道一段看似正确的代码将来可能在哪里留下隐患。 AI 可以生成候选方案，但这些经验不会自动出现在候选方案里。标准没有说清楚，Agent 就只能按照统计上最常见的方式完成任务，最后得到一份看起来合理的平均答案。 ## 真正有用的门，是阻拦 AutoGPT 分享过一套管理 AI 贡献者的做法。他们没有只给 Agent 写一份很长的说明文档，而是把指令放在 Agent 实际会经过的代码目录旁边，再用 `AGENTS.md`、Skill、PR 模板、测试计划和 CI 检查组成门槛。[2] 这样做不会让 Agent 突然变聪明，但会让错误更难直接进入主分支。 他们后来发现，测试、覆盖率和提交格式都通过之后，剩下的问题往往变成：这个 PR 虽然能运行，但不符合项目路线图。[2] 代码质量只是验收的一层。产品方向还要再往上看一层。 Google 最近发布的零信任 Agent 示例也采用了相同的思路。它没有把系统提示词当成安全边界，而是在模型之外增加签名、沙箱和确定性校验。只要 Agent 能修改数据库、执行代码或调用真实 API，错误就不再只是回答错了一句话，而可能直接改变生产状态。[3] 个人工作流不一定需要硬件签名和云端沙箱，但原则一样：不能指望 Agent 自己记得小心一点。 我现在让 Hermes 操作文件时，关键结果不会只看它的回复。文件是否真的写入，要用 `read_file` 验证；命令是否成功，要看终端结果；涉及删除、覆盖和外部写入，则需要额外确认。Cron 任务也只允许执行适合无人值守的读取、分析和推送工作。 这些动作没有让模型变聪明，却让系统更容易发现它什么时候没有做好。 ## 人的工作从实现转向定义 过去的产品流程大致是：提出需求，设计方案，编码实现，测试上线。 AI 加入以后，实现环节会被压缩。流程更像是先定义问题和标准，再让 AI 生成多个方案，然后由人选择、修改、验证，最后承担交付结果。 这不意味着人可以不懂技术。越依赖 Agent，越需要知道它可能在哪些地方出错。只是亲手写出每一行代码，不再是唯一的专业证明。 我在 AI编程能力与审美权重转移推演 里把这个变化写成了「从实现稀缺到判断稀缺」。以前，一个人能不能做出功能，本身就是能力证明。以后更难的问题会变成：他能不能判断这个功能该不该做，能不能给出明确的验收标准，出了问题敢不敢负责。 游戏设计本来就是一项验收工作。玩家是否理解规则，反馈是否及时，数值是否破坏循环，某个功能是否值得占用开发资源，这些问题都没有单一答案。它们依赖长期经验，也依赖对目标的判断。 AI 会把更多方案摆到桌面上，但不会替人完成取舍。 ## 先定义什么叫做对 我现在看 AI 编程，已经不太关心它能不能一次生成一段代码。这个问题的答案大多是能。 我更关心几件事：它理解的目标和我想要的一样吗？有没有遗漏隐含约束？实现能不能放进现有系统？通过测试以后，是否真的改善了用户体验？ 这些问题无法靠一条更长的提示词全部解决。它们需要领域经验、明确标准，以及一套不会让错误直接通过的验收流程。 AI 把实现变便宜以后，人的工作会往更上游移动。以后更稀缺的，可能不是「能不能做出来」，而是知道什么值得做，以及什么才算做对。 ## Sources [1] https://www.tomtunguz.com/model-release-exhaustion — Honestly, Who Buys SOTA? | Tomasz Tunguz [2] https://github.blog/open-source/maintainers/your-contributors-are-ai-first-now-is-your-project — Your contributors are AI-first now. Is your project? | GitHub Blog [3] https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit — Build zero-trust AI agents with Google ADK [4] https://openai.com/index/how-enterprises-put-ai-to-work — From assistance to execution: How enterprises put AI to work