简介：为什么 AI 编程需要方法论

本章是全书的起点。先搞清楚"为什么"，再学具体的"怎么做"，才不会把每种工具当成孤立的时髦词。

一、从一个真实痛点说起

你可能有过这样的经历：

对着 AI 说一句"帮我做个待办清单应用，带搜索、筛选和本地存储"，几分钟后它真的吐出了一整套能跑的代码。页面能点、交互像回事，甚至还有点动画。

那一刻的体验像魔法。但当你把这套代码放进一个要长期维护的真实项目，魔法就开始失效：

• AI 写的"第一版"看着对，细节却总差一点；
• 小 Demo 很顺，一进大仓库就开始"飘"，改 A 处坏 B 处；
• 多轮对话、跨模块改造时，AI 明显变笨；
• 它很擅长"生成代码"，却不擅长"稳定地把一件事做完"。

根本原因：代码生成本身，是整个工程闭环里最便宜的一步。真正昂贵、也真正决定交付质量的，是下面这些事：

• 意图是否被正确定义
• 需求是否被结构化沉淀
• 测试是否能形成约束
• 上下文是否足够且相关
• 代理是否有验证与回退机制

当"写代码"变得几乎免费，瓶颈就从"能不能写出来"转移到了"能不能持续写对、写清楚、可维护"。方法论，就是为了应对这个瓶颈而诞生的。

二、AI 编程的三个阶段

如果把这几年 AI 编程的演进压缩成一句话，就是一条工程成熟度升级线：

2024            2025               2026
Vibe Coding  →  Spec Coding    →   Harness Engineering
"先做出来"      "让产出真正可用"      "人设计系统，代理稳定执行"

阶段	核心问题	关注点
Vibe Coding	能不能快速做出东西？	速度、灵感、即时反馈
Spec Coding（SDD）	做出来的东西对不对、可不可维护？	意图、规格、验证
Harness Engineering	代理能否在真实环境里长期稳定地干活？	执行环境、反馈闭环、约束

本教程就是要带你把这条线上的关键理念——Vibe Coding、TDD、SDD、人机协作与工作流、上下文工程（Context Engineering）、执行工装工程（Harness Engineering）——逐个讲清楚，并告诉你它们如何组合使用。

三、一个必须先澄清的误区

很多人一听到"方法论""规格""流程"，脑子里立刻浮现：厚厚的文档、瀑布式审批、低效率。

这恰恰是 AI 时代最该避免的误解。今天好的方法论形态不是"文档越多越好"，而是：

• 轻量：只把最容易返工的决定提前说清楚；
• 结构化：能被机器解析，而不只是给人看；
• 和代码库一起版本化：规格进仓库，而不是散落在聊天记录里；
• 人与代理都能读：对代理来说，"看不见 = 不存在"。

💡 心智模型：方法论不是给 AI 套枷锁，而是给 AI 修一条不容易跑偏的路。路修好了，AI 反而能跑得更快更稳。

四、这套理念到底解决 / 不解决什么

它解决：

• 让需求不再只存在于一次性对话里；
• 让 AI 产出从"概率性猜谜"变成"按图纸施工"；
• 让多人、多轮、多代理共享同一份意图；
• 让代码、测试、文档围绕同一份规格演化。

它不解决：

• 它不会替你思考"到底要做什么产品"——意图仍由人定义；
• 它不是银弹，越轻的任务越不需要重流程（一个脚本就没必要开 Spec Kit）；
• 它不保证模型一定对——仍需人来审查与验收。

五、适合谁来读

• 一线开发者：想把 AI 从"补全插件"升级为"可靠的工程能力"；
• 团队负责人：想给团队立一套可复用、可审计的 AI 协作规范；
• AI 编程爱好者：被 SDD、Context Engineering、Harness 这些词搞晕，想要一张清晰地图。

六、本章小结

• AI 让"写代码"变便宜，"讲清楚需求 + 组织上下文 + 搭验证闭环"变昂贵——方法论就是为这条新瓶颈而生。
• 演进主线：Vibe Coding → Spec Coding（SDD）→ Harness Engineering。
• 方法论不是加重流程，而是用轻量、结构化、入库的规格让 AI 少跑偏。

七、下一步

• 继续阅读：范式全景图：一张地图看懂，把 9 个理念放到同一张工程地图上。
• 想直接看核心主线：跳到 SDD 规格驱动开发。