别再把 Vibe Coding 当软件工程：AI 时代，真正缺的是一套“工程闭环”

AI 已经能快速生成大量代码，但“能生成代码”和“能做出软件产品”之间，依然隔着一整套软件工程体系。

真正值得关注的，不是 AI 会不会写代码，而是我们有没有能力把 产品决策、需求规格、架构约束、测试验证、质量门禁、发布运维 连成闭环。

最近我一直在思考一个问题：

为什么现在很多人用 Claude Code、Codex、Cursor、OpenCode 等 AI Coding 工具，两三天就能做出一个看起来不错的 Demo，但一旦继续往生产环境走，项目就开始变得越来越难维护？

最开始我们会觉得，是模型能力还不够。

但做得越多越会发现：

问题未必出在模型“不会写代码”，而是我们把软件工程中原本由产品经理、架构师、开发、测试、运维共同承担的约束，全部压缩成了一条 Prompt。

于是一个典型的 Vibe Coding 流程变成了：

想法 ↓ Prompt ↓ AI 生成代码 ↓ 人工大致看看 ↓ 跑起来了 ↓ Demo / MVP

做 Demo，这套方法非常高效。

但如果你想做的是一个真正运行 3 年、5 年，被真实客户持续使用的软件产品，这远远不够。

一、我们真正缺的，不是另一个 Coding Agent，而是“软件工程全貌”

很多人讨论 AI Coding 时，容易陷入一个局部视角：

• Claude Code 和 Codex 谁更强？
• MCP 还是 Skill？
• Prompt 怎么写？
• Agent 怎么自动拆任务？
• 上下文怎么压缩？
• 模型怎么选？

这些当然重要。

但它们几乎都属于：

“实现阶段的效率问题”。

而软件工程真正要解决的事情，至少有六层：

从上往下看：

2. 产品 / 投资管理
   ：这个东西到底值不值得做？
4. 项目 / 交付管理
   ：怎么组织团队持续交付？
6. 需求定义
   ：到底要做什么？
8. 架构设计
   ：系统应该怎么设计？
10. 质量实现
    ：实现到底正确不正确？
12. 交付运维
    ：怎么上线，并长期稳定运行？

这时候你会发现一个很重要的事情：

IPD、敏捷、SDD、TDD 根本不是互相替代的几种研发流程。

它们在解决完全不同的问题。

二、IPD、敏捷、SDD、TDD，到底分别管什么？

很多团队容易问：

我们到底应该用 IPD，还是敏捷？

都用了 SDD，是不是就不用 TDD 了？

这个问题本身就不准确。

因为它们根本不在同一层。

可以把它们压缩成四句话：

IPD：决定“做不做”。

敏捷：决定“怎么持续交付”。

SDD：决定“到底要做什么”。

TDD：决定“怎么证明做对了”。

1. IPD：先解决“值不值得做”

IPD 最重要的价值，不是让研发过程变复杂。

它真正解决的是：

企业到底要不要继续投资这个产品。

一个产品从机会识别开始，通常需要经历：

市场机会 ↓ 产品概念 ↓ 商业计划 ↓ 开发 ↓ 验证 ↓ 发布 ↓ 生命周期管理

每一个阶段都不是为了“写文档”。而是在回答：用户是谁、痛点是否真实、市场空间够不够、产品有没有差异化、成本是多少、ROI 是否成立、是否应该继续投资。

所以 IPD 更接近：产品经营体系。

它的核心判断标准不是“功能做完了吗”，而是：

这个产品还值得继续投入资源吗？

2. 敏捷：解决“不确定环境下怎么交付”

即使已经确定这个产品值得做，也不意味着我们能一次性把需求全部想清楚。

所以软件研发从：

一次性定义全部需求 ↓ 半年开发 ↓ 最后交付

变成：

拆小 ↓ 开发 ↓ 交付 ↓ 反馈 ↓ 调整 ↓ 继续交付

Scrum、Kanban，本质都在解决：

如何缩短“需求 → 软件 → 用户反馈”的周期。

真正重要的不是“每天站会”，而是 Backlog 是否合理、Story 是否足够小、WIP 是否受控、Definition of Done 是否明确、反馈能否快速进入下一轮。

所以敏捷管理的是：交付流。

三、为什么 AI 时代，SDD 突然重新变得重要？

过去，人类程序员读一份并不完整的需求，大概率还能根据经验自己补全很多东西。

例如产品经理写：

增加订单取消功能。

一个熟练开发往往会主动去想：什么状态允许取消？已支付怎么办？已发货怎么办？是否需要审计？并发取消和支付怎么办？

但 AI 不一样。

如果你只告诉它：

“帮我实现订单取消功能。”

它非常可能：合理地猜。

而“合理地猜”，恰好就是软件开发里最危险的事情之一。

所以 SDD——Spec Driven Development，在 AI 时代的价值被重新放大。

SDD 本质上是在减少“自由发挥空间”

例如：

REQ-ORDER-003  功能： 用户可以取消未支付订单。  前置条件： Order.Status = PendingPayment  成功结果： Order.Status = Cancelled  禁止： Paid / Shipped / Completed 订单不得取消。  并发规则： 支付和取消同时发生时，只允许一个成功。  审计要求： 记录操作者、取消时间和取消原因。

这时候 AI 面对的就不再是一句模糊需求，而是一个：

约束明确的执行空间。

因此 SDD 的核心不是 Markdown，而是：

把人的意图，转化成机器可持续执行和验证的规范。

四、但只有 SDD 仍然不够

流程升级成：

Spec ↓ Plan ↓ Task ↓ AI Coding

已经比单 Prompt 强很多。

但仍然存在一个问题：

谁来证明 AI 写的代码是正确的？

如果还是：

AI 写实现 ↓ AI 写测试 ↓ AI 告诉你测试通过

那本质上：AI 还是既当运动员，又当裁判。

这就是 TDD 在 AI Coding 中非常重要的原因。

五、TDD：让 AI 先证明“自己现在还不会”

TDD 最经典的是：

RED ↓ 先写失败测试  GREEN ↓ 写最少实现让测试通过  REFACTOR ↓ 在测试保护下重构

这里最关键的其实不是“测试覆盖率”，而是：

先看到一个正确的失败。

例如：

Given 订单状态 = Paid  When CancelOrder()  Then 返回 OrderCannotCancel

AI 首先写测试，运行，必须 FAIL。因为此时功能还不存在。然后 AI 再去实现，再运行 PASS。

这时测试才具备真正的证明价值。

六、Vibe Coding 为什么特别容易停留在 Demo？

把两种开发模式放在一起，就非常清楚了。

普通 Vibe Coding：

Prompt ↓ AI生成代码 ↓ 人工看看 ↓ 能运行 ↓ 结束

而真正的 AI Native Engineering 应该是：

产品意图 ↓ Specification ↓ Architecture ↓ Task ↓ Test ↓ Implementation ↓ Verification ↓ Review ↓ CI/CD ↓ Production

它们最大的差别，不是 AI 写代码能力强不强，而是：

有没有工程闭环。

七、真正降低 AI 幻觉，不能只靠 Prompt Engineering

很多人想到“减少幻觉”，第一反应是：Prompt 写详细一点、加 System Prompt、增加上下文、给 AI 更多文档、换一个更聪明的模型。

这些当然有帮助。

但工程领域真正靠谱的做法，是：

不要要求 AI 永远不犯错，而是让错误无法轻易逃过系统。

数据库会失败，所以我们有事务。网络会失败，所以我们有重试和幂等。服务会宕机，所以我们有容灾。程序员会犯错，所以我们有测试和 Code Review。

那么 AI 会幻觉怎么办？

答案不是：

“让 AI 不要幻觉。”

而是：

给 AI 建立约束系统和验证系统。

八、我认为 AI 工程化至少要有 8 个阶段

阶段 1：产品定义

回答为什么做、谁会用、解决什么问题、成功标准是什么。

阶段 2：需求规格

把模糊需求转成 Requirement、User Story、Acceptance Criteria、Edge Case、Non-Functional Requirement，并明确 MUST / SHOULD / MAY。

阶段 3：架构设计

用 DDD、C4、ADR、API Contract、Event Schema、数据模型、安全边界等限制 AI 的自由发挥空间。

未来一个非常重要的能力，会是：Architecture as Constraints。

阶段 4：任务拆解

建立完整追踪链：

Business Goal ↓ REQ ↓ DESIGN ↓ TASK ↓ TEST ↓ CODE

未来我们不只问“这段代码是谁写的”，而应该能回答：

这段代码为什么存在，它对应哪个需求、哪个设计决策和哪个测试？

阶段 5：TDD 实现

每个 Task 最理想的 AI 工作流应该是：读取 Spec → 定位现有代码 → 写失败测试 → 运行确认失败 → 最小实现 → 运行测试 → 重构 → 运行完整测试。

注意：不是 AI 说“Tests Passed”，而是真实执行环境返回 Tests Passed。

LLM 输出 = 推测 CLI / Compiler / Test Runner 输出 = 事实

阶段 6：Quality Gate

真正生产级系统，AI 完成代码后不能直接结束。至少还要经过 Build、Unit Test、Integration Test、Contract Test、Static Analysis、Dependency Scan、Security Scan。

全部通过以后，才允许进入下一阶段。

阶段 7：独立 Review 与 Convergence

不要让 Coding Agent 自己判断自己。

可以采用：

Agent A：负责实现 Agent B：负责 Review

Agent B 只获得 Spec、Architecture、Git Diff、Tests，然后判断是否漏需求、是否违反架构、是否增加未要求行为、是否存在安全问题、测试是否真的覆盖需求。

最终再做：Spec-Code Convergence。

阶段 8：Production 才是真正的“Done”

一个真正的软件产品，Done 应该延伸到 Production。

因为上线以后还需要 Logs、Metrics、Traces、Alerts、SLO、Rollback、Incident、Root Cause Analysis。

形成：

生产异常 ↓ 分析 ↓ Bug ↓ Regression Test ↓ 修复 ↓ 重新发布 ↓ 知识沉淀

这才是完整的软件生命循环。

九、所以 AI Coding 的下一阶段，可能不是 Vibe Coding

Vibe Coding 更像 AI 软件开发的第一个阶段。

它证明了一件事情：

代码生产成本正在快速下降。

但是当代码越来越便宜以后，真正昂贵的东西会发生变化。

过去最昂贵的是 Coding。以后更昂贵的可能是：

Intent Specification Architecture Constraints Verification

也就是说：

真正有价值的资产，可能逐渐从 Code 转向“可执行的软件知识”。

十、未来的软件工程，也许会从 Code-Centric 转向 Spec-Centric

过去：

需求文档 ↓ 程序员理解 ↓ Code ↓ Code 是最终事实

未来可能变成：

Intent ↓ Specification ↓ Architecture Contract ↓ Acceptance Test ↓ Agent Implementation ↓ Verification

甚至未来 Code 都可能变成：

一种可以不断重新生成的派生物。

真正需要长期维护的反而是：

2. 为什么做
4. 做什么
6. 哪些约束不能突破
8. 怎么证明它正确

这也是我认为 SDD、TDD、ADR、Architecture Governance 在 AI 时代反而会越来越重要的原因。

十一、最后，用一句话总结

很多人今天讨论 AI Coding，还主要停留在：

怎么让 AI 写更多代码。

但真正的软件工程问题应该变成：

怎么让 AI 在明确的意图、规范、架构和质量约束中工作，并通过真实工具验证结果。

所以真正值得构建的不是一个更强 Coding Agent，而是：

Product + Spec + Architecture + Agent + Test + Quality Gate + Review + CI/CD + Observability

组成的：

AI Native Software Engineering System

当 AI 从“帮我生成代码”进化到“在工程体系内持续交付可验证的软件”，Vibe Coding 才真正跨过 Demo 和 MVP 的边界，进入软件工程。

写在最后

AI 正在极大降低实现成本。

但它不会消灭软件工程。

恰恰相反：

当 Coding 越来越便宜以后，“定义正确的问题、建立正确的约束、证明结果正确”会越来越重要。

所以我认为：

AI 不会让软件工程消失，而会迫使我们重新认识软件工程真正有价值的部分。