同一个模型、同一个登录需求，为什么一份结果只能演示，另一份却敢交给真实用户？
差距通常不在 Prompt 有多长，而在使用者是否提前定义了“完成”，并为失败路径 准备了可复核的验收证据。
本文不讨论“该不该用 AI 写代码”，也不比较具体工具。我们只解决一个工程问题：
怎样把一句模糊需求，转换成 Agent 可以执行、开发者可以验收、团队可以交付的 任务说明与验收约束？
你会得到一个登录功能示例、一份可复制的任务模板，以及开发过程中可以直接使用的 12 个检查问题。
先区分三种完全不同的“完成”
让 Agent “做一个登录页”，几分钟后通常就能看到页面、输入框和按钮。
但页面能打开，只证明界面被生成了。它没有回答下面这些问题：
- 登录失败时，用户会看到什么；
- 接口超时后，页面停在哪个状态；
- 连续点击是否会产生重复请求；
- 刷新以后，登录状态是否仍然存在；
- 普通用户能否直接进入管理页面；
- 本次修改是否破坏了原来的退出流程。
同一个功能至少存在三个完成层级：
| 层级 | 完成标准 | 判断依据 |
|---|---|---|
| 页面完成 | 界面可以打开，按钮可以点击 | 静态页面或简单操作 |
| Demo 完成 | 主流程在理想条件下跑通 | 一次成功路径演示 |
| 工程交付 | 正常、异常和回归路径均有定义 | 与风险匹配的测试和证据 |
Vibe Coding 很容易把第一个层级误认为第三个层级。真正的分水岭，是团队有没有 一套比“我点了一下，没报错”更可靠的完成定义。
把一句需求改成任务说明与验收约束
“做一个登录页”描述的是界面，不是用户任务。
一个更适合交给 Agent 的版本可以写成：
未登录用户进入
/dashboard时跳转到登录页。输入有效账号并提交后，按钮进入 Loading 且不可重复点击；登录成功后回到原目标页；接口返回 401 时停留在当前 页面并显示可读错误；刷新后登录状态仍然存在。
这段描述没有规定按钮颜色，也没有替 Agent 决定组件怎么拆，却给出了五类关键 信息：
- 前置条件：未登录用户从受保护页面进入；
- 用户动作：填写账号并提交；
- 可观察状态：Loading、成功、401、刷新；
- 不变条件：不能重复提交，不能绕过权限；
- 验收结果：回到原目标页，错误可读，状态可恢复。
以后给 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，而是改变使用方式：
- 先让 AI 复述目标、假设和风险，再让它修改代码；
- 要求它给出两个方案，并解释各自放弃了什么；
- 不只问“怎么修”，还要问“为什么会错”；
- 使用脱敏且有代表性的输入、隔离测试环境和失败场景检验结果；
- 保存失败案例，而不只收藏成功 Prompt；
- 每次完成后复盘：哪个问题本来应该更早发现？
图 3：提出假设、构建、观察、解释和复盘，才能把一次生成转化成下一次判断。 AI 生成技术示意图。
哪些场景可以停在 Demo，哪些不应该
Vibe Coding 并不天然意味着低质量。关键是结果将被用在哪里。
以下场景通常允许更快地试错：
- 验证交互或产品概念的可抛弃原型；
- 不处理敏感数据的个人小工具；
- 失败代价低、能够立即撤销的内部实验。
以下场景则需要更严格的工程验证：
- 账号、权限、支付和隐私相关功能；
- 数据迁移、删除和不可逆操作；
- 面向真实用户的生产系统；
- 会影响安全、合规或关键业务流程的修改。
“能不能交付”不是由文章、模型或工具名称决定，而是由使用场景、失败代价和证据 共同决定。
最后
过去，经验大量体现在亲手实现：如何组织代码，如何调用 API，如何处理状态。
现在，越来越多实现可以交给 Agent，经验开始向更上游和更下游移动：
- 上游，定义真正的问题和约束；
- 中间，判断方案与现有系统是否匹配；
- 下游，验证结果、识别风险并决定是否交付。
GitHub 在一篇讨论 AI 时代代码审查与责任的工程文章中提出：AI 改变了 Merge 之前的很多工作，但最终仍然需要有人愿意为按下 Merge 负责。
Vibe Coding 的分水岭，不是用了哪个模型，也不是 Prompt 写得多漂亮。
而是面对一个“看起来已经完成”的结果时，是否知道还应该检查什么，以及用 什么证据决定它能不能交付。
你最常遇到哪一种“AI 看起来做对了，最后却没有真正解决问题”的情况？
