4.2 练习与巩固
通过练习来检验你对三种方法论的理解。
概念题
题目 1：方法论匹配
以下项目应该用哪种方法论（或组合）？请说明理由。
场景 A：一个大学生想用周末时间做一个个人博客网站。
场景 B：一家银行要开发新的在线支付系统。
场景 C：一个 5 人团队在做一个 SaaS 产品的持续迭代。
场景 D：一个 2 人的创业团队，要在 2 周内给投资人演示一个产品原型。
参考答案
- A：Vibe Coding。个人项目，风险低，速度快优先。
- B：SDD + TDD。金融系统，安全关键，必须有规格和测试双重保障。Vibe Coding 绝对不能用。
- C：三者融合。新功能用 Vibe Coding 探索，确认后用 SDD 写规格，核心逻辑用 TDD。
- D：Vibe Coding。2 周出原型，速度是唯一优先级。
题目 2：核心问题匹配
每种方法论回答的核心问题是什么？
| 方法论 | 核心问题 |
|---|---|
| TDD | ? |
| SDD | ? |
| Vibe Coding | ? |
参考答案
- TDD：代码是否正确？（Is this code correct?）
- SDD：我们在构建正确的东西吗？（Are we building the right thing?）
- Vibe Coding：能不能先跑起来？（Can it work?）
题目 3：判断题
判断以下说法的对错，并简要说明理由。
- TDD 的测试覆盖率 95% 就意味着产品方向正确。
- SDD 的规格文档写完就不能修改了。
- Vibe Coding 项目在 3 个月后可能会遇到维护困难。
- Karpathy 在 2026 年提出了"Agentic Engineering"来替代 Vibe Coding。
- AI 让方法论变得不再重要。
参考答案
- 错。TDD 验证的是代码正确性，不是产品方向。95% 覆盖率的代码可能构建的是错误的产品。
- 错。SDD 的规格是活的（Living Spec），随需求演进而更新：规格 v1.0 → 实现 v1.0 → 反馈 → 规格 v1.1。
- 对。这就是"三月之墙"现象——第 1-3 月兴奋期后，集成挑战和代码理解问题开始浮现。
- 部分对。Agentic Engineering 是 vibe coding 的进化而非完全替代，强调更系统化的 AI 代理编排。
- 错。AI 让方法论比以往更重要——歧义在 AI 生成的代码中成本被放大了。
场景题
题目 4：转换信号识别
以下是一个 Vibe Coding 项目的现状，请判断是否到了切换的时机：
项目已经开发 4 个月。最近两周：
- 修复了登录 Bug，但支付功能出了新问题
- 新来的同事看了三天代码说看不懂
- 产品经理说要下个月上线
出现了哪些转换信号？应该切换到什么方法论？
参考答案
出现了 3 个转换信号：
- 上下文漂移：修了一个 Bug 但引入了新问题——代码关联超出了 AI 的理解范围
- 团队扩张：新同事加入，需要更好的文档和协调方式
- 生产意图：下个月上线，需要更高的代码质量和稳定性
建议：立即从 Vibe Coding 切换到 SDD + TDD 混合模式：
- 先花 1-2 天用 SDD 整理现有功能的 API 规格
- 核心功能（支付、登录）补写 TDD 测试
- 后续新功能按 SDD 流程开发
题目 5：工作流设计
为一个"在线教育平台"设计开发方法论组合。
需求清单：
- 用户注册/登录
- 课程列表和搜索
- 视频播放
- 支付购买
- 学习进度追踪
- 后台管理面板
请对每个功能模块选择最合适的方法论，并说明理由。
参考答案
| 功能 | 方法论 | 理由 |
|---|---|---|
| 用户注册/登录 | TDD | 安全敏感，认证逻辑必须有测试保障 |
| 课程列表和搜索 | SDD + Vibe Coding | 先用 Vibe Coding 验证搜索体验，确认后用 SDD 写 API 规格 |
| 视频播放 | Vibe Coding | 前端播放器有成熟方案，AI 可以快速集成 |
| 支付购买 | SDD + TDD（必须） | 支付是安全关键功能，必须有规格和双重测试 |
| 学习进度追踪 | SDD | 涉及数据模型和 API，需要精确的数据规格 |
| 后台管理面板 | Vibe Coding | 内部工具，风险低，速度优先 |
整体策略：以 SDD 为主线（定义 API 规格），支付和认证用 TDD（核心安全逻辑），UI 和内部工具用 Vibe Coding（快速出活）。
思考题（开放性）
题目 6：哲学思考
"在人类编写的代码库中，歧义的成本是几小时。在 AI 生成的代码库中，歧义的成本是数千行听起来合理但微妙错误的输出。"
结合你学到的三种方法论，回答：
- 为什么 AI 会让歧义的成本放大？
- TDD 和 SDD 各自是怎么降低歧义成本的？
- 在你的日常开发中，"歧义"通常出现在哪里？
参考思路
AI 放大歧义成本：人类开发者遇到歧义会停下来确认，但 AI 会根据自己的统计推断直接"猜"一个答案——而且猜的答案通常"听起来合理"。这意味着歧义不会在编码阶段暴露，而是在测试或生产阶段才被发现，修复成本远高于编码阶段。
TDD 降低歧义：通过测试用例把"期望行为"精确地固定下来（assert result == 5 就是 5，没有第二种理解）。SDD 降低歧义：通过规格文档把"系统契约"精确地固定下来（OpenAPI 里写的是整数就是整数）。
歧义的常见来源：需求文档中的模糊表述（"要快""要好用"）、前后端之间的接口约定不清晰、产品经理和开发者对同一功能的不同理解。
题目 7：团队实践
如果你是团队技术负责人，你会怎么向团队推广"三者融合"的工作方式？考虑：
- 怎么说服"只用 Vibe Coding"的同事开始写测试？
- 怎么说服"只用 TDD"的同事尝试 Vibe Coding 做原型？
- 怎么在不增加太多流程的情况下引入 SDD？
参考思路
说服 Vibe Coding 同事写测试：不要说"你应该写测试"。而是——用 Vibe Coding 快速做原型，但告诉他们"当你发现修了一个 Bug 又引入新 Bug 时，就是该加测试的信号"。从痛点出发，不是从教条出发。可以先让 AI 帮他们生成测试，降低写测试的门槛。
说服 TDD 同事尝试 Vibe Coding：不是让他们放弃 TDD，而是——在写测试之前，先用 Vibe Coding 快速验证一下"这个方向对不对"。TDD 保证代码质量，Vibe Coding 保证方向正确。先花 2 小时验证，总比花 2 周写了完美的测试后发现方向错了强。
轻量引入 SDD：不要一上来就要求写完整的 OpenAPI 规格文档。可以先从一个 API 开始，只写最关键的几个端点的规格，让团队体会到"前后端不用扯皮"的好处。有了甜头，自然会扩展。
📌 课程总结
| 方法论 | 核心要点 |
|---|---|
| TDD | 测试驱动，Red-Green-Refactor，缺陷密度降低 40-90%（Nagappan et al. 2008） |
| SDD | 规格驱动，精确契约消除歧义，AI 时代的关键方法论 |
| Vibe Coding | 氛围编程，快速探索，注意 80/20 法则（社区观察） |
| 三者融合 | 探索 → 规格 → 验证，根据项目阶段灵活选择 |
| 核心洞察 | 三者不是对立的，而是互补的。AI 是引擎，方法论是方向盘 |
将方法论作为工具箱中的工具，根据场景选择最合适的那个。