Vibe Coding｜如何不作冤大头——“大模型善后工程师”逆袭之路

Vibe Coding 发展到今天，再说“AI 不只是补全代码”，已经太过时了。

现在真正的问题不是 AI 会不会写代码，也不是 AI 能不能生成一个页面、一个 App、一个后台、一个 Landing Page。它当然能。甚至在很多场景下，它已经可以把一个模糊想法快速变成可运行的产品雏形。

问题在后面。

AI 交付出来的东西，往往是一个“看起来能跑”的半成品：页面能打开，按钮能点，数据能显示，动画也有，甚至代码结构看起来也不差。但当你真正准备上线、交付客户、交给团队维护，问题就开始暴露。

需求理解偏了一点。组件规则乱了一点。状态边界漏了一点。异常流程没处理。样式系统不统一。代码能跑但不好维护。交互能用但不符合用户心智。修一个地方，坏三个地方。

于是人类开始进入那个痛苦的阶段：
AI 生成了 80%，人类花大量时间修最后 20%。

这就是所谓的“大模型善后工程师”。

它不是一个调侃，而是当下 AI 产品生产里最真实的成本结构。

一、AI 交付后的“烂摊子”，到底烂在哪里？

很多人以为 AI 生成代码的问题，是代码质量问题。其实不完全是。

AI 交付后的问题，通常不是单点 Bug，而是系统性偏差。

第一类，是需求偏差。
AI 可以按照你的话生成，但它不一定理解你真正想要的业务目标。你说“做一个用户管理页面”，它会做出列表、搜索、编辑、删除，但它未必理解权限层级、组织架构、数据合规、操作审计、异常状态。

第二类，是设计偏差。
页面看起来完成了，但信息层级不稳定，间距不统一，组件语义混乱，品牌气质不一致。AI 很擅长做“像样的界面”，但不擅长自动维护一套长期一致的设计系统。

第三类，是工程偏差。
代码能跑，但目录结构不清晰；状态管理临时拼接；组件抽象过度或者完全没有抽象；API 调用散落在各处；错误处理缺失；测试覆盖不足。

第四类，是上下文偏差。
AI 不知道你之前怎么约定的，不知道这个项目为什么这么设计，不知道哪些东西不能改，不知道哪些技术债是历史原因，不知道哪些组件必须复用。

第五类，是验证偏差。
AI 认为“完成了”，但它的完成标准通常是“没有明显报错”。而真正产品交付的完成标准是：需求正确、体验稳定、代码可维护、异常可控、性能达标、安全合规、团队能接手。

这就是为什么 Stack Overflow 2025 开发者调查里，AI 工具使用率很高，但开发者对 AI 输出准确性的信任并不高：46% 的开发者表示不信任 AI 输出准确性，只有 33% 表示信任，真正“高度信任”的比例只有 3%。这说明行业不是不用 AI，而是已经进入了“广泛使用，但必须强审查”的阶段。

所以，AI 善后的根本问题不是 AI 不够聪明，而是我们还没有建立一套足够成熟的 AI 交付系统。

二、为什么总会剩下那 20%？

很多 AI 生成项目的问题，出在一开始。

人类给 AI 的输入通常是这样的：

“帮我做一个高级感官网。”“帮我做一个 AI Agent 市场页面。”“帮我做一个用户登录和设备绑定流程。”“参考这个风格，做一套高保真 UI。”

这些指令对于原型阶段够用，但对于交付阶段远远不够。

因为 AI 缺的不是执行力，而是边界条件。

它不知道什么是必须遵守的设计原则。它不知道哪些组件可以复用，哪些不能新建。它不知道业务流程里的优先级。它不知道异常状态是否重要。它不知道用户是谁、使用场景是什么、错误代价有多高。它不知道什么叫“这个项目的正确做法”。

所以它会用最大概率生成一个“差不多”的结果。

而“差不多”，就是那 20% 善后工作的来源。

Vibe Coding 早期靠的是感觉，靠的是快速试错，靠的是人和 AI 一轮一轮对话。但现在的问题已经不是“怎么更快生成”，而是“怎么第一次就更接近正确”。

这就需要把 Vibe Coding 推向下一阶段：

从 Vibe Coding，进入 Spec Coding。

从 Prompt 驱动，进入 Context 驱动。

从人肉善后，进入系统化交付。

三、所谓“缩小最后 20%”，本质是把修补工作前置

最后 20% 为什么痛苦？

因为它发生在交付之后。

一旦 AI 已经生成了一堆页面、一堆组件、一堆状态逻辑、一堆临时代码，人类再去修，就不是“优化”，而是“拆弹”。

你会发现很多问题不是局部问题，而是源头错了：

信息架构没定义清楚；设计规范没写清楚；组件边界没定义清楚；数据模型没想清楚；交互状态没列完整；测试标准没提前建立；

AI 的执行规则没有约束。

所以，减少 AI 善后工作的第一原则是：

不要等 AI 做完再审查，而要在 AI 开始之前就定义它不能做错什么。

这就是 design.md、PRD.md、AGENTS.md、CLAUDE.md、rules、test.md、flow.md 这些文件越来越重要的原因。

它们不是普通文档。
它们是 AI 生产系统的“轨道”。

OpenAI 在 Codex 文档中提到，Codex 可以运行测试、linter、类型检查，也可以通过仓库中的 AGENTS.md 文件获得项目导航方式、测试命令和项目标准实践。换句话说，AI Agent 的能力不只取决于模型本身，也取决于你有没有给它清晰的项目环境、测试方式和行为规则。

Claude Code 的文档也强调，CLAUDE.md 可以为 Claude 提供项目级、用户级或组织级的持久指令，包括构建命令、代码规范、项目架构、命名规则和常用工作流；并且当 Claude 反复犯同一个错误，或者代码审查发现它本该知道的项目规则时，就应该把这些内容沉淀进 CLAUDE.md。

这说明一个趋势已经很明显：

未来优秀的 AI 编程能力，不是更会聊天，而是更会建立规则。

四、要把 20% 缩小到 0，先要重新定义“0”

这里必须说清楚：
真正的软件开发里，缺陷不可能绝对为零。

所谓把 AI 善后从 20% 缩小到 0，不是说 AI 永远不会犯错，而是说：

人类不再承担大量低级、重复、可预防的修补工作。

也就是说，目标不是“没有问题”，而是：

问题在生成前被约束；
问题在生成中被检测；
问题在提交前被阻断；
问题在审查前被自动修复；

最终留给人类的，只剩产品判断、体验判断、商业判断和架构决策。

这才是“零善后”的真实含义。

不是没有修正。
而是没有人肉擦屁股。

五、从 “AI 善后”工程师，到 AI 交付架构师

没人想当“大模型善后工程师”，我们更愿意作为“AI 交付架构师”，交付高质量的开发结果。

“善后”工程师一直在 AI 做完之后补救。
交付架构师是在 AI 开始之前设计系统。

我觉得只要是个资深从业者，没人愿意去给AI“擦屁股”。

作为善后工程师经常会问：

“这个 Bug 怎么修？”“这个页面怎么调？”“这个代码为什么又坏了？”

交付架构师问的是：

“为什么 AI 会生成这种错误？”“哪条规则没有前置？”“哪个测试没有覆盖？”“哪个组件边界没有定义？”“哪个上下文没有进入工作流？”“这个错误能不能下次自动避免？”

这就是新一代 Vibe Coding 的核心能力。

不是更快地让 AI 干活。
而是让 AI 在一个更清晰、更稳定、更可验证的系统里干活。

Martin Fowler 近期关于 coding agent 的文章里提到，一个好的外部 harness 有两个目标：提高 Agent 第一次做对的概率，并在问题到达人类眼前之前，通过反馈循环自动纠正尽可能多的问题。它最终要减少 review toil，也就是审查疲劳，同时提升系统质量。

这句话非常关键。

它把 AI 编程的重点从“模型能力”转向了“交付系统”。

未来不是谁的 Prompt 更神，而是谁的 harness 更完整。

六、缩小那 20%，需要做哪些具体工作？

要把 AI 交付后的修补成本降下来，至少要建立六层前置机制。

1. 需求前置：把模糊想法变成可执行规格

不要直接让 AI 开始写代码。

先写清楚：

这个功能解决什么问题；

目标用户是谁；主路径是什么；边界场景有哪些；哪些状态必须覆盖；哪些不在本次范围内；完成标准是什么。

如果这一步不清楚，AI 后面做得越快，返工越大。

未来 PRD 不再只是给产品经理和工程师看的文档，而是给 AI Agent 读取和执行的任务规格。

2. 设计前置：用 design.md 约束视觉和交互

AI 很容易生成“看起来还行”的 UI，但很难自动保持长期一致。

所以需要 design.md。

它至少应该定义：

品牌气质；颜色系统；字体层级；间距规则；圆角规则；阴影规则；动效原则；组件使用边界；页面结构原则；

移动端和桌面端响应规则；
哪些视觉风格绝对不能出现。

对于设计师来说，design.md 的价值不只是“让 AI 知道怎么画界面”，而是把设计判断变成可复用、可传递、可执行的规则。

这一步越清楚，后面的 UI 善后越少。

3. 架构前置：让 AI 先读项目，而不是先写功能

很多 AI 生成代码的问题，是因为它没有真正理解项目结构。

所以每次让 AI 开始开发之前，应该先让它完成一件事：

读取项目结构，说明它理解了什么，再提出实现计划。

不要让它直接改文件。
先让它输出计划。

包括：

会改哪些文件；为什么改这些文件；是否复用现有组件；是否新增状态管理；是否影响 API；是否需要迁移数据；是否需要补测试；是否存在风险。

Codex app 现在已经把多线程任务、worktree、review、diff、commit、push 等能力整合进工作流，说明 AI 编程工具正在从“生成代码”走向“管理变更”。

真正专业的 AI 工作流，一定不是一句话开干，而是先计划、再执行、再验证、再提交。

4. 测试前置：没有测试，就没有交付

AI 生成的代码，如果没有测试，就只能靠人肉点击和肉眼检查。

这就是善后工作失控的原因。

所以要把测试变成 AI 工作流的一部分。

至少包括：

类型检查；lint 检查；单元测试；核心流程测试；视觉回归测试；接口 mock 测试；异常状态测试；构建测试；部署前检查。

OpenAI 对 Codex 的介绍中明确提到，Codex 可以运行 test harnesses、linters 和 type checkers，并提供终端日志和测试输出作为可验证证据，让用户追踪任务完成过程。

这其实给了我们一个标准：

AI 的交付物不能只说“我完成了”，它必须带着证据交付。

没有测试输出的 AI 交付，不是真交付，只是生成。

5. 记忆前置：把每一次善后沉淀成下一次的规则

AI 善后最糟糕的地方，不是这次要修，而是下次还会犯同样的错。

所以每一次人工修补，都不应该只停留在当前代码里，而应该沉淀成规则。

比如：

“以后不要新建 Button 组件，必须复用 components/ui/button。”“所有 API 错误必须进入统一 toast 和 error boundary。”“移动端底部导航高度固定为 72px。”“所有表单必须包含 loading、error、disabled 三种状态。”“涉及支付、权限、删除操作时，必须先给实现计划，不允许直接修改。”

Claude Code 文档里也明确建议，当 Claude 第二次犯同样错误、代码审查发现它本该知道的规则、或者你反复输入同样的纠正时，就应该把这些内容写进 CLAUDE.md。

这一步非常重要。

因为真正成熟的 AI 工作流，不是“人不断教 AI”，而是“每次纠错都变成系统规则”。

6. 审查前置：让 AI 自己先审 AI

未来的人类审查，不应该是第一道审查，而应该是最后一道审查。

在提交给人之前，可以让 AI 先做几轮自检：