砺锋日志 · 公众号教程整理

以下内容基于Tony Bai极客时间课程《AI原生开发工作流实战》教程整理，

📝 第一篇：认知篇

《当AI从"工具"变成"同事"：软件开发者的范式革命》

开篇：一个你一定熟悉的场景

一个普通的下午，你正在开发一个新功能。IDE的屏幕上，是你专注构建的业务逻辑；而在另一块屏幕上，是AI大模型的聊天窗口。你的工作流变成了一支"双屏探戈"：

1. 从IDE中，小心翼翼地选中一段代码、一个报错信息，Command+C
2. 切换到AI聊天窗口，Command+V，然后用自然语言小心翼翼地"裱糊"上足够的上下文
3. 等待AI回复，Command+C，切换回IDE，Command+V
4. 发现AI的建议只考虑了局部，叹气，重复上述过程……

这个场景，你熟悉吗？

---

三大摩擦力：阻碍我们迈向真正生产力

我们真正渴望的，或许不是一个更聪明的"AI助理"，而是一个能与我们并肩作战的"AI同事"。

这个"同事"应该：内在于我们的工作流，而不是游离其外；拥有记忆，能理解项目的"前世今生"；具备行动力，能将想法转化为可执行、可验证的操作。

问题的根源已经清晰：割裂的工作流与被动的AI，是阻碍我们迈向更高阶生产力范式的核心障碍。

而这层隔阂，来自于三大摩擦力：

1. 上下文摩擦力
我们花费大量精力去"告诉"AI它本应"知道"的事情。项目的技术栈、代码规范、模块依赖……这些对身处项目中的我们是常识，但对于那个"身外之物"的AI助理，却是一片空白。我们像是在与一个永远是"第一天入职"的新同事对话。

2. 工作流摩擦力
我们的工作流是连贯的：编码→测试→审查→提交→构建。而与AI的交互却是断裂的、片段化的。AI只给出一段文本，无法直接运行一次测试来验证建议，也无法自动将生成的提交信息填入git。我们成了AI建议的"手动执行者"。

3. 认知摩擦力
我们的大脑在两种截然不同的模式间高频切换：在IDE中是沉浸式的"创造者"，在AI聊天窗口是逻辑严谨的"提问者"。这种切换不仅消耗精力，更破坏了宝贵的"心流状态"。

---

AI-开发者集成成熟度模型：你现在处于哪一级？

我将AI与开发者的集成关系，划分为四个成熟度等级：

Level 1：AI作为外部知识库
典型代表：网页版ChatGPT、Gemini或Claude。
AI是一个与你的开发环境完全隔离的"远程顾问"。你需要手动将所有问题和代码上下文"搬运"到它的世界里，再将答案"搬运"回来。核心痛点是极高的上下文摩擦力。

Level 2：AI作为嵌入式副驾驶
典型代表：VS Code中的GitHub Copilot Chat、Cursor AI原生IDE。
AI被深度"嵌入"到IDE里，能"看到"你当前打开的文件，提供上下文感知的代码补全和对话。相比Level 1极大降低了切换摩擦力，但仍有三大局限：

• 它仍然是被动的伙伴，不会主动发起任务
• 它的视野是"文件级"的，对整个项目的宏观架构认知不足
• 它的行动空间被"囚禁"在IDE的直接上下文里，无法触达服务器、CI Runner等远程环境

Level 3：AI作为原生工作流智能体 ⭐
典型代表：Claude Code等命令行AI Agent。
这正是我们要精通的核心领域。AI的角色发生根本性转变：它不再仅仅是一个"副驾驶"，而是获得了"主动性"的工作流智能体。

它能够：

• 感知全局：通过@指令、CLAUDE.md等机制，理解整个项目的结构和规范
• 规划行动：面对高层级意图（如"重构这个模块"），自主将任务分解为一系列具体步骤
• 与环境交互：主动提议并执行读写文件、运行Shell命令等操作

在Level 3，AI与我们的对话，从"请告诉我怎么做"，变成了"我打算这么做，请批准"。开发者成为了"指挥家"与"审批者"，AI则成为了能将意图转化为一系列实际行动的"执行官"。

Level 4：AI作为自主软件工程师
这是我们正在迈向的未来。AI将能够独立地、端到端地完成从需求理解到部署上线的整个软件开发生命周期。

---

真正的革命：规范驱动开发（Spec-Driven Development）

在Level 3的AI原生开发范式中，一份高质量的、可被机器精确理解的规范，是驱动整个开发工作流的起点和核心引擎。没有它，AI的强大能力就如同无的之矢，无法精准作用于我们的工程目标。

这就是**规范驱动开发（SDD）**的核心思想。

"失落的翻译"问题
在传统开发流程中，产品经理将业务构想翻译成PRD，架构师进行"人脑编译"翻译成技术设计文档，开发者再次"人脑编译"翻译成代码——每一次"翻译"都不可避免引入信息损耗、歧义和主观臆断。

更糟糕的是，文档与最终的"真理之源"——代码是完全脱节的。项目迭代时，代码飞速演进，文档被遗忘在角落，迅速腐烂。

权力的反转

在SDD范式中，不再是文档服务于代码，而是代码服务于规范。那份结构化的、无歧义的、可被机器理解的规范，取代代码成为了项目唯一的、至高无上的"真理之源"（Single Source of Truth）。

代码，降级为这份"真理之源"在某个特定技术栈下的一个自动渲染产物。

在这个反转中：

• 维护软件的核心：从"修改代码"，变成了"演进规范"
• 调试Bug的核心：从"修复错误代码"，变成了"修正产生错误代码的规范"
• 技术重构的核心：从"大规模迁移代码"，变成了"基于同一份规范，生成全新技术栈的实现"

AI Agent的"编译"角色

在SDD中，AI Agent扮演了多个"编译器"的角色：

• 需求编译器：将模糊的自然语言想法，"编译"成结构化的需求规范（spec.md）
• 方案编译器：将需求规范与技术约束结合，"编译"成技术实现蓝图（plan.md）
• 任务编译器：将技术蓝图，"编译"成带依赖关系的、原子化的任务指令集（tasks.md）
• 代码编译器（生成器）：根据任务指令集，生成最终的可执行代码

理解了这个隐喻，你就能明白：我们在SDD中所做的一切，都是在为AI的"多阶段编译"过程提供高质量的"源代码"（即规范），并监督每一步"编译"的结果。

---

SDD工作流的四个阶段

第一阶段：意图定义
目标：澄清并固化"做什么"（WHAT）和"为什么做"（WHY）。
输出：spec.md 需求规范——完全与技术实现解耦，只关心用户故事、功能需求和成功标准。

第二阶段：技术规划
目标：决定"如何做"（HOW）。
输入：spec.md和技术栈约束。
输出：plan.md（技术方案）——将业务需求精确映射到技术实现。

第三阶段：任务拆解
目标：分解为可执行的原子任务。
输出：tasks.md——带依赖关系的、原子化的任务列表。

第四阶段：编码与验证
目标：生成可工作的代码。
输出：经过测试验证的、符合规范的业务代码。

---

本篇小结

这是一场深刻的范式转变：

从Level 1-2的"AI助理"时代——AI是被动的工具，我们扮演"上下文搬运工"和"提示词调优师"的角色，充满了三大摩擦力。

到Level 3的"AI同事"时代——AI是原生的、可编程的工作流组成要素，我们成为"指挥家"和"审批者"。

核心引擎是规范驱动开发（SDD）：规范成为了"真理之源"，代码成为规范的"编译产物"。AI Agent扮演了从意图到代码的"多阶段编译器"角色。