Appearance
Vibe Coding、Agentic Engineering 与 Spec-Driven：三种方法的边界
系列第 04 篇
目标：把“凭感觉生成”“可验证委托”和“规格驱动”放回各自适用场景
最后核验：2026-07-20
对应视频：第 04 集《Vibe、Agentic 与 Spec-Driven：AI 编程到底该用哪种方法》
AI 编程讨论中，Vibe Coding、Agentic Coding、Agentic Engineering、Spec-Driven Development 经常被当成同一件事：用自然语言让 AI 写代码。它们确实共享自然语言和模型，但优化目标不同。
Vibe Coding 优化想法到可运行原型的距离；Agentic Engineering 优化一项工程任务从目标到可验证交付的闭环；Spec-Driven 优化复杂需求在实现前的清晰度和一致性。混用这些方法，会出现两个极端：把原型式随手生成直接带入高风险生产，或者给一个小改动编写比代码更长的规格体系。
阅读路线：先看全局，再进入机制
视频版先展示整章地图，再逐层展开。博客沿用同一判断顺序，但保留更多机制、案例、失败模式和生产边界：
- 三种目标：区分价值探索、已知目标执行和多人决策对齐。
- 风险与规格：用歧义、破坏半径和验证难度调节流程强度。
- 原型转生产：补齐状态、权限、数据、恢复、观测和责任。
- 完成定义：为每个阶段设置不同停止条件，避免原型假装可交付。
这四步不是目录装饰，而是一条决策链：三种目标 → 风险与规格 → 原型转生产 → 完成定义。阅读后面的案例时，可以随时回到这条链判断当前问题发生在哪一层。
真实问题：一个能运行的原型为什么仍然不能上线
某位产品经理用 AI 两小时做出内部审批工具：页面能提交，列表能查询，演示非常流畅。进入真实使用后，团队才发现没有并发控制、没有权限隔离、附件地址可被猜测、审批状态可以跳转、失败操作没有审计。AI 没有“遗漏需求”，因为这些需求从未被明确表达；原型的完成定义只是“演示路径能跑通”。
相反，一个工程师为修改按钮文案启动完整 Spec 流程，创建原则、需求、技术计划和任务分解。所有文档都正确，却比直接修改、截图验证和提交耗时数倍。方法没有错，风险匹配错了。
机制：三种方法解决不同不确定性
Vibe Coding 面对的是“我还不知道最终想要什么”，通过快速生成和观察降低价值不确定性。Agentic Engineering 面对的是“我知道目标，但执行工作很多”，通过工具和验证降低执行成本。Spec-Driven 面对的是“多人对目标、边界或方案可能理解不同”，通过可评审规格降低需求和设计不确定性。
同一项目可以先 Vibe 探索，再用 Spec 固化行为，最后用 Agentic 流程实现。关键是每个阶段切换完成定义，而不是把原型轨迹原封不动延伸到生产。
1. Vibe Coding：以感觉和运行结果为反馈
Vibe Coding 的典型循环是描述意图、生成实现、运行观察、继续调整。用户可能不读每行代码，而是通过页面、脚本输出或交互判断“更接近想要的样子”。它让设计师、产品、研究人员和非专业开发者也能把软件当作表达媒介。
它最适合低风险、短寿命、容易人工观察的任务：原型、数据探索、一次性迁移脚本、个人自动化、内部展示。此时过早追求完美架构会阻碍学习。
Vibe 的风险来自反馈维度过窄。页面看起来正确，不能证明权限、并发、错误恢复和数据一致性；一次运行成功，不能证明输入边界和长期维护。Cursor 对 Vibe Coding 的官方说明也明确不建议把不理解的软件直接投入生产。
2. Agentic Engineering：以任务契约和证据闭环
Agentic Engineering 不要求人逐行编写代码，但要求人定义目标、约束和完成标准。Agent 读取代码库，制定或执行计划，调用工具修改，运行检查，根据反馈迭代，最终把 Diff 和证据交给 Reviewer。
这里的自治不是放任。恰恰相反，越希望无人值守，越需要预先设计环境、权限、测试和停止条件。Agent 可以自己决定下一个文件或命令，但不能自己决定业务目标、风险容忍和是否发布。
适合任务包括：已复现缺陷、边界清晰功能、有测试保护的重构、依赖升级、补文档和测试、机械迁移。它们共同特点是结果能够由测试、构建、截图、Trace 或数据校验判断。
3. Spec-Driven：让规格成为实现输入
GitHub Spec Kit 将流程组织为 Constitution、Specify、Plan、Tasks、Implement。Constitution 保存项目长期原则；Specify 描述做什么和为什么；Plan 记录技术栈和架构选择；Tasks 形成可执行拆分；Implement 才进入代码。
规格的价值不在于文档数量，而在于让高成本分歧可见。例如“取消订单”必须澄清哪些状态允许取消、重复请求是否幂等、是否退款、错误码是什么、数据库是否迁移。这些问题如果在代码生成后才讨论，返工会跨越接口、数据和测试。
Spec-Driven 适合跨模块功能、公共 API、数据迁移、安全敏感行为和多人协作。对于范围清楚的局部改动，可以只写轻量任务契约，无需完整仪式。
风险越高，生产门禁越强
低风险原型可以用“能运行、能观察”作为阶段性完成。内部工具需要基本测试和权限。业务服务需要 CI、Review、错误处理和监控。身份、资金和隐私系统需要威胁建模、强审批和审计。受监管系统还需要可追溯责任链与合规证据。
流程强度应随破坏半径增加，而不是随团队规模机械增加。一个只有一百行却能删除生产数据的脚本，比一个十万行离线 Demo 更需要严格控制。
按风险和歧义选择方法
- 低风险、目标清晰：Agent 可以直接实现并运行检查。
- 低风险、目标模糊：用 Vibe 快速探索，保留学习而非架构承诺。
- 高风险、目标清晰：使用 Agentic Engineering，但加强权限和门禁。
- 高风险、目标模糊：先 Spec 和人工决策，Agent 只做研究或方案比较。
还有第三个维度：可验证性。高风险任务如果没有可靠测试，应先建设验证能力，再提高 Agent 自治。否则只是更快地产生无法判断的结果。
原型进入生产的五道转换
第一道是价值：原型是否证明用户确实需要它。第二道是行为：把演示路径变成状态、输入、输出和错误规格。第三道是工程：重构边界、数据和依赖，不承诺保留原型的偶然结构。第四道是质量：测试、安全、可访问性、性能和兼容。第五道是运维：配置、监控、发布、回滚和责任人。
这也解释了为什么“AI 已经写完 80%”常常是误导。原型可能写出了大部分代码行，却只完成很小一部分生产责任。剩余工作不是修饰，而是把软件从可展示对象变成可信系统。
规格不是越厚越好
规格不足会让 Agent 用常识补空白，造成方向返工。适中规格覆盖用户行为、边界、约束、风险和验证，让实现者能做必要局部决策。过度规格在学习发生前冻结所有细节，维护成本高，并可能让团队误以为文档等于事实。
一个实用标准是：规格应回答那些如果理解不同，会导致公共接口、数据模型、安全或大量代码返工的问题。能够在局部实现中低成本调整的细节，不必提前穷尽。
例如订单取消应预先规定允许状态、幂等、404/409 和非目标；至于一个私有辅助方法的命名，可以遵循现有代码风格由实现阶段决定。
三种方法的完成定义
Vibe 阶段在价值假设得到足够反馈时停止，不承诺生产正确。Spec 阶段在关键行为、风险和任务已经可评审、可执行时停止，不承诺代码完成。Agentic 实现阶段在验收和验证全部通过、Diff 被审查时停止。生产交付还需要责任人批准和受控发布。
把这些停止条件分开，可以避免两个错误：因为原型可运行而声称产品完成；因为规格写完而声称实现风险消失。
一个具体案例：订单取消
需求最初只有一句：“给订单加取消功能。”
Vibe 方式可能直接新增按钮和接口，通过手工点击看到状态变成取消。这个结果可以帮助产品确认交互和文案。
进入 Spec，需要回答：只有 CREATED 能取消吗？PAID 是否退款？重复请求怎样处理？不存在订单返回什么？是否修改数据库？原创建接口能否变化？本系列给出的契约是：CREATED -> CANCELLED；重复取消幂等；PAID 返回冲突；不存在返回 404；不修改数据库；原创建接口不变。
进入 Agentic 实现，Agent 先读取 Controller、Service、Order、Repository 和测试，运行 8 个基线测试；新增测试并确认编译失败；实现查询、状态和 HTTP；运行 13 个测试；Review 发现状态规则在 Service 中，移动到 Order.cancel() 并增加领域测试；最终 16 个测试和真实 HTTP 路径通过。
三种方法在同一功能中连续出现，各自解决不同问题。
把方法变成三档团队工作协议
团队如果只讲概念，开发者遇到任务时仍然不知道该走哪条路径。更实用的做法是定义轻量、标准和严格三档协议，并允许按证据升降级。
轻量协议适用于低风险、小范围、验收明确的改动。任务只需写目标、文件范围和验证命令；Agent 可以直接编辑；结束前运行相关测试并审查 Diff。典型例子是修正文案、增加一个现有模式的字段映射、补充缺失单元测试。轻量不等于没有门禁，只是门禁与破坏半径匹配。
标准协议适用于多文件功能和已复现缺陷。任务契约需要范围、非目标、Given-When-Then、兼容要求和验证；Agent 先只读探索并给出计划；实现采用小步测试；完成后运行模块与全量检查，由新上下文 Review。订单取消实战使用的就是标准协议。
严格协议适用于公共 API、数据迁移、身份、资金、隐私和基础设施。除了完整 Spec 与技术 Plan，还要有威胁模型、迁移和回滚、权限设计、可观测性、分阶段发布和责任人审批。Agent 可以承担研究、生成迁移草案、补测试和执行受限 dry-run，但不能持有通用生产权限，也不能自己批准发布。
升级条件应写进协议。例如实现中发现需要修改数据库、公共接口或跨服务消息，就从标准升级为严格；任务被证明只是局部纯函数修改，可以从标准降为轻量。这样流程不会成为固定官僚步骤，而是风险控制系统。
方法选择还要计算验证成本
有些任务描述非常清楚，却缺少低成本验证。例如要求 Agent 优化一个高并发路径，但团队没有基准环境、生产流量模型和性能剖析。直接实现会产生“看起来更快”的代码。正确路径是先建立基准与观测，再进入 Agentic 优化。验证基础设施本身可能成为第一项任务。
相反，机械迁移虽然涉及大量文件，但如果转换规则稳定、编译器与测试覆盖强，反而适合高自治和并行。任务规模不是风险的同义词；隐性要求、不可逆动作和验证困难才是。
规格与代码如何保持同一个事实源
Spec 不应在实现开始后冻结。实现发现新事实时，应明确区分三种情况：代码偏离已确认行为，代码应修正；原规格遗漏真实约束，规格和测试应一起更新；业务方向发生变化，需要责任人重新批准。不能让 Agent 私自选择第三种解释。
长期规则放在仓库文档，具体任务放在 Issue 或 Spec，行为结果放在测试，方案取舍放在设计记录。每类事实有清晰载体后，Agent 不需要从一份巨型文档猜哪些内容仍有效，Reviewer 也能追溯变更为什么发生。
三个反例
第一个反例是“先让 AI 全部做出来，我们再补规格”。一旦前端、接口和数据都围绕模型假设形成，团队会受到沉没成本影响，用规格解释现有实现，而不是重新判断正确行为。
第二个反例是“规格生成通过评审，后面完全自动”。评审只能覆盖当时看见的问题，实现中的依赖、错误路径和环境差异仍会产生新信息。Spec 降低方向不确定性，不消除执行不确定性。
第三个反例是“原型以后没人维护，所以不用工程化”。一次性工具仍可能接触真实数据和权限。短寿命可以降低可维护性投入，却不能取消数据保护、输入边界和破坏性操作确认。
失败模式
失败一：把 Vibe 当作贬义词
快速凭反馈探索本身非常有价值。问题不是 Vibe，而是没有在风险提高时切换完成定义。一个明确标记为原型的工具，不需要伪装成生产系统。
失败二：把 Agentic 理解成无人参与
Agentic 描述的是系统可以自主选择和执行动作，不代表人退出。人仍负责目标、权限、关键方案、Review 和发布。没有人类责任的自治，只是责任不清。
失败三：把 Spec 交给 AI 后直接认可
AI 可以整理需求和发现问题，却不知道未写下来的业务取舍。规格仍需产品、领域专家、安全和工程责任人评审。错误规格会让 Agent 更一致地实现错误方向。
失败四：所有任务都套同一流程
为简单改动写厚规格会降低效率；让跨服务迁移直接进入 Agent 会增加返工。团队应按风险、歧义和验证能力选择流程，而不是用单一模板证明成熟。
失败五：实现变化后规格不更新
实现中发现新约束时，必须回写任务或设计。否则文档、测试和代码形成三个事实源，后续 Agent 会读到冲突上下文。
生产边界
高风险场景中，即使规格完整、测试通过，也不能自动开放生产工具。规格是行为约束，测试是已覆盖行为证据，沙箱和权限控制破坏半径，Review 和审批承担组织责任。它们互补而不能替代。
涉及数据迁移时要有 dry-run、备份、可逆方案和数据校验；涉及权限要有拒绝路径和审计；涉及外部服务要考虑幂等、超时和重试；涉及模型生成依赖要检查许可证、维护状态和供应链风险。
实践清单
- [ ] 明确当前阶段是在探索价值、澄清规格还是交付实现。
- [ ] 用风险、歧义和可验证性选择方法。
- [ ] Vibe 原型明确标记非生产状态和数据限制。
- [ ] 高成本分歧在实现前进入规格评审。
- [ ] 规格描述行为和边界，不穷尽低成本实现细节。
- [ ] Agentic 任务提供可运行完成检查。
- [ ] 发现新事实时更新规格和测试。
- [ ] 生产门禁随破坏半径加强。
- [ ] 不用代码行完成比例表示产品完成度。
- [ ] 每个阶段使用自己的停止条件。
读完之后，你应该能完成什么
- 能判断当前工作是在探索、对齐还是交付。
- 能选择够用的 Spec 强度而不过度文档化。
- 能列出原型进入生产必须补齐的门禁。
- 能在阶段切换时重新声明完成定义。
如果只能复述概念，却不能完成上述动作，说明还没有把内容转化成工程能力；可以回到对应机制图、失败模式和实践清单重新核对。
小结
Vibe Coding 让想法快速变成可观察原型，Spec-Driven 让复杂目标变成可评审任务，Agentic Engineering 让任务在工具和证据中完成。它们不是互斥阵营，而是一条从探索、决策到交付的连续链。真正危险的是阶段已经变化，完成定义却没有变化。