Vibe Coding 从 Demo 到交付：12 个必须回答的工程问题

同一个模型、同一个登录需求，为什么一份结果只能演示，另一份却敢交给真实用户？

差距通常不在 Prompt 有多长，而在使用者是否提前定义了"完成"，并为失败路径 准备了可复核的验收证据。

本文不讨论"该不该用 AI 写代码"，也不比较具体工具。我们只解决一个工程问题：

怎样把一句模糊需求，转换成 Agent 可以执行、开发者可以验收、团队可以交付的 任务说明与验收约束？

你会得到一个登录功能示例、一份可复制的任务模板，以及开发过程中可以直接使用的 12 个检查问题。

先区分三种完全不同的"完成"

让 Agent "做一个登录页"，几分钟后通常就能看到页面、输入框和按钮。

但页面能打开，只证明界面被生成了。它没有回答下面这些问题：

• 登录失败时，用户会看到什么；
• 接口超时后，页面停在哪个状态；
• 连续点击是否会产生重复请求；
• 刷新以后，登录状态是否仍然存在；
• 普通用户能否直接进入管理页面；
• 本次修改是否破坏了原来的退出流程。

同一个功能至少存在三个完成层级：

层级	完成标准	判断依据
页面完成	界面可以打开，按钮可以点击	静态页面或简单操作
Demo 完成	主流程在理想条件下跑通	一次成功路径演示
工程交付	正常、异常和回归路径均有定义	与风险匹配的测试和证据

Vibe Coding 很容易把第一个层级误认为第三个层级。真正的分水岭，是团队有没有 一套比"我点了一下，没报错"更可靠的完成定义。

把一句需求改成任务说明与验收约束

"做一个登录页"描述的是界面，不是用户任务。

一个更适合交给 Agent 的版本可以写成：

未登录用户进入 /dashboard 时跳转到登录页。输入有效账号并提交后，按钮进入 Loading 且不可重复点击；登录成功后回到原目标页；接口返回 401 时停留在当前 页面并显示可读错误；刷新后登录状态仍然存在。

这段描述没有规定按钮颜色，也没有替 Agent 决定组件怎么拆，却给出了五类关键 信息：

1. 前置条件：未登录用户从受保护页面进入；
2. 用户动作：填写账号并提交；
3. 可观察状态：Loading、成功、401、刷新；
4. 不变条件：不能重复提交，不能绕过权限；
5. 验收结果：回到原目标页，错误可读，状态可恢复。

以后给 Agent 下任务时，可以先复制下面这份最小模板。它不是 Contract Testing 中的"契约测试"，而是本文对任务说明与验收约束的简称。

## 目标
- 用户真正要完成什么？

## 非目标
- 本次明确不做什么？

## 前置条件
- 用户、数据和系统分别处于什么状态？

## 正常路径
- 输入、动作和预期结果是什么？

## 失败与中断
- 空数据、超时、权限不足、重复操作分别如何处理？

## 不变条件
- 哪些已有行为、接口或数据绝不能被破坏？

## 数据与安全边界
- Agent 可以读取哪些获授权文件和非敏感配置？
- 使用哪些脱敏测试数据？哪些密钥、生产数据和隐私信息禁止提供？

## 验收证据
- 用哪些测试、截图、日志或获授权的真实操作证明已经完成？

模板本身不会自动保证质量。它的价值，是迫使任务发起者在生成代码之前，把原本 会被模型自行猜测的空白暴露出来。

把登录示例继续展开，就能得到一张最小验收表：

场景	预期行为	可接受的证据
有效账号登录	只提交一次，并回到原目标页	网络请求记录与完整路径验证
返回 401	停留当前页，显示可读错误	接口桩或测试账号验证
接口超时	结束 Loading，允许用户重试	超时模拟与页面状态截图
连续点击	第二次操作不再提交请求	请求计数或自动化测试
登录后刷新	会话仍有效，权限状态一致	刷新后的真实页面验证
普通用户越权访问	拒绝访问，不只隐藏按钮	服务端响应与权限用例
退出后回访受保护页	再次跳转登录页	原退出路径回归

这里的重点不是要求所有项目照抄同一组测试，而是把"失败时会怎样"写成可观察 行为，再为每个行为指定证据。

从生成到交付，持续检查这 12 个问题

生成前

• 1. 用户真正要完成的任务是什么？
• 2. 本次明确不做什么？
• 3. 哪些已有行为绝不能被破坏？
• 4. 哪些需求只是未经验证的假设？

生成中

• 5. AI 是否在获授权范围内理解了相关代码、数据结构和运行环境？
• 6. 它对哪些地方并不确定？
• 7. 它有没有悄悄扩大修改范围？
• 8. 正常、异常和边界状态是否都有明确结果？

交付前

• 9. 主流程是否从真实入口完整走通？
• 10. 是否使用脱敏且有代表性的测试数据验证？
• 11. 修复以后，是否重新执行原路径和相关回归？
• 12. 是否留下测试、截图、日志或其他可复核证据？

如果这些问题没有答案，换一个更强的模型，往往只是更快地产生一个未经验证的 答案。

AI 最危险的结果，往往只是"差一点"

模型能力当然重要。不同模型在上下文、复杂修改和错误率上确实存在差异。

但模型达到可用门槛以后，输出并不会自动变成可交付结果。

Stack Overflow 2025 开发者调查显示，84% 的受访者正在使用或计划使用 AI 开发工具；主动不信任 AI 输出准确性的受访者占 46%，高于表示信任的 33%。 66% 的受访者把"方案几乎正确，但还差一点"列为主要困扰。

这是一项开发者自报调查，不能证明经验与交付质量之间的因果关系。但它准确描述 了日常开发里最难发现的一类风险：结果不是完全错误，而是足够像正确答案。

Anthropic 在 2026 年发布的 Claude Code 使用研究分析了约 40 万次会话。报告 观察到，典型会话中，人主要决定"做什么"，Agent 主要决定"怎么做"；使用者 表现出的领域经验越强，会话越容易成功，也更容易从错误和误解中恢复。

这同样是针对 Anthropic 自家产品的观察性分析，不是所有工具和任务的普遍定律。 更值得注意的是，报告中不同职业在编码任务上的平均成功率非常接近。

关键未必是"会不会亲手写每一行代码"，而是能否理解问题、补齐约束，并判断 输出是否真的解决了它。

可以把整个过程拆成四层：

模型决定可生成方案的范围。

问题框架决定应该解决什么。

相关经验帮助发现哪里可能出错。

验证提供是否可以交付的证据。

图 1：低判断密度的流程止步于生成；完整流程会先定义约束，再验证结果。 AI 生成技术示意图。

经验的工程价值，是更早看见后果

这里所说的经验，不等于工龄，也不等于熟练使用某个 Agent。

工具熟练度让人生成得更快；相关经验让人看到正常结果时，主动追问它可能怎样 失败。

看到的结果	经验会继续追问
登录成功	会话过期、权限绕过、错误提示、重复提交
接口接通	空数据、超时、重试、幂等、部分成功
页面还原	Loading、Empty、Error、移动端、长文本
字段已修改	旧数据、版本兼容、迁移中断、回滚
Bug 已消失	根因、原路径复测、相邻回归、可观测性

可以把经验理解成：对后果的记忆。

经历过重复扣款的人，会更早想到幂等；处理过缓存事故的人，会在"加个缓存"后 继续追问失效策略；做过权限修复的人，也不会只检查按钮是否隐藏。

Microsoft Research 对超过 8 小时 Vibe Coding 过程视频进行的质性研究也观察 到，编程专业知识并没有消失，而是转移到上下文管理、快速评估结果，以及判断 何时应该从 AI 操作切回人工操作。

这项研究不能用来估算普遍效率，也不能证明经验是唯一变量。它说明的是工作重心 发生了变化：实现动作可以被委托，判断时机仍然需要学习。

图 2：同一个 AI 生成结果，需要从产品、架构、状态、安全、数据和运维等多个 视角检查。AI 生成技术示意图。

把隐性经验变成 Agent 能读取的约束

只有存在人脑里的经验，无法稳定复用。

更有效的做法，是把反复出现的判断写进任务模板、项目规则、测试和发布门禁中。

生成前：让 Agent 先建立问题模型

先让它只读取与任务直接相关且已经授权的仓库文件、文档和非敏感配置，再回答：

• 它理解的目标和非目标是什么；
• 当前实现依赖哪些假设；
• 修改会触及哪些文件、接口和状态；
• 哪些行为必须保持不变；
• 它还缺少什么信息。

不要把密钥、Cookie、生产数据、私人链接或无关配置交给 Agent。需要代表性数据 时，优先使用脱敏样本或隔离的测试数据；生产环境操作必须单独授权。

这一步的目的不是让 Agent 写一篇分析报告，而是在修改代码之前发现理解偏差。

生成中：让每一步都可观察、可回退

• 把大任务拆成可以单独验证的小改动；
• 要求它列出不确定项，不要静默猜测；
• 修改后先检查 Diff，再运行最相关的测试；
• 失败时先解释根因和证据，再修改；
• 不让一次修复顺手扩成无关重构。

交付前：证据必须匹配风险

不同任务需要的证据不同，但"Agent 说已完成"从来不是交付证据。

风险	更合适的证据
代码结构被破坏	Diff 审查、Lint、类型检查、编译
业务逻辑错误	单元测试、集成测试、边界输入
用户路径断裂	从真实入口执行 E2E 或人工全流程
权限与数据泄露	权限矩阵、安全检查、敏感数据审查
修复引入回归	原路径复测、相邻功能回归
环境差异	在获授权的目标等价测试环境构建并验证

不是每个小改动都需要完整 E2E。验证强度应与失败代价相匹配，但必须能够回答： 为什么现在可以相信它？

生产环境验证、数据修改、部署和发布仍是单独授权边界，不能因为测试环境通过就 自动执行。

新手也可以主动建立判断力

如果经验只是资历，新手只能等待时间过去。

但如果经验是"经过反馈校正的判断"，就可以被主动积累。

Anthropic 在 2026 年公布的一项 AI 辅助与编程技能形成研究让参与者学习一个 新的 Python 库。AI 组在随后的即时测试中平均得到 50%，手动完成任务的参与者 平均得到 67%，最大的差距出现在 Debugging 问题上。

这项研究样本有限，测量的是短期理解，不能直接推导长期职业结果。它提示的风险 是：如果 AI 只负责给答案，人可能在得到代码的同时，跳过了形成判断所需的阅读、 卡顿和排错。

解决办法不是少用 AI，而是改变使用方式：

1. 先让 AI 复述目标、假设和风险，再让它修改代码；
2. 要求它给出两个方案，并解释各自放弃了什么；
3. 不只问"怎么修"，还要问"为什么会错"；
4. 使用脱敏且有代表性的输入、隔离测试环境和失败场景检验结果；
5. 保存失败案例，而不只收藏成功 Prompt；
6. 每次完成后复盘：哪个问题本来应该更早发现？

图 3：提出假设、构建、观察、解释和复盘，才能把一次生成转化成下一次判断。 AI 生成技术示意图。

哪些场景可以停在 Demo，哪些不应该

Vibe Coding 并不天然意味着低质量。关键是结果将被用在哪里。

以下场景通常允许更快地试错：

• 验证交互或产品概念的可抛弃原型；
• 不处理敏感数据的个人小工具；
• 失败代价低、能够立即撤销的内部实验。

以下场景则需要更严格的工程验证：

• 账号、权限、支付和隐私相关功能；
• 数据迁移、删除和不可逆操作；
• 面向真实用户的生产系统；
• 会影响安全、合规或关键业务流程的修改。

"能不能交付"不是由文章、模型或工具名称决定，而是由使用场景、失败代价和证据 共同决定。

最后

过去，经验大量体现在亲手实现：如何组织代码，如何调用 API，如何处理状态。

现在，越来越多实现可以交给 Agent，经验开始向更上游和更下游移动：

• 上游，定义真正的问题和约束；
• 中间，判断方案与现有系统是否匹配；
• 下游，验证结果、识别风险并决定是否交付。

GitHub 在一篇讨论 AI 时代代码审查与责任的工程文章中提出：AI 改变了 Merge 之前的很多工作，但最终仍然需要有人愿意为按下 Merge 负责。

Vibe Coding 的分水岭，不是用了哪个模型，也不是 Prompt 写得多漂亮。

而是面对一个"看起来已经完成"的结果时，是否知道还应该检查什么，以及用 什么证据决定它能不能交付。

你最常遇到哪一种"AI 看起来做对了，最后却没有真正解决问题"的情况？