夜雨聆风系列说明：这是「AI Coding 系列」的第 5 篇。第 3 篇我们剖析了 Vibe Coding 的爽与痛。第 4 篇我们讲了 Spec Coding 的哲学与方法论。这一篇，我们走进工厂——看一套完整的 Spec Coding 工程化框架，到底长什么样。
上一篇，我们说了一句话：
"先画图纸，再让 AI 按图纸施工。"
很多人读完之后，给我留了一句相同的评论：
"道理我都懂。但图纸怎么画？AI 怎么按图纸施工？能不能给我看看真的？"
好。
这一篇，我们不讲道理。
我们进工厂。
想象一间工厂。一百个 AI 工人站在流水线旁。每个工人都很能干——它们会写 Java、会写 Vue、会写 SQL、会写测试用例。但如果你只是对着它们喊一声"做一个招聘系统"——一百个工人会朝一百个方向跑。有人写的字段叫 user_name，有人写的叫 userName，有人写的叫 name。有人用 MySQL，有人用 PostgreSQL。有人返回 JSON，有人返回 XML。
混乱不是因为工人不行。而是因为没有工头、没有图纸、没有流程。
所以，一间真正的工厂，需要三样东西：
工头（谁指挥谁？） 图纸（按什么标准做？） 流程（先做什么，后做什么？）
这三样东西，就是 Spec Coding 工程化框架的全部。
一、工头：多 Agent 协作
在传统软件开发里，一个项目需要产品经理、架构师、程序员、测试工程师、代码审查员。
在 Spec Coding 的框架里，这些角色被映射为不同的 AI Agent。
🎯 总指挥：Master Orchestrator
它是"工头中的工头"。不写代码，不做设计。它只做一件事：管任务清单。- 接收用户的需求- 把需求拆解成可执行的子任务- 把子任务分配给不同的 Worker Agent- 追踪每个任务的进度- 当一个任务完成后，启动下一个
📐 设计工人：Design Worker
负责"画图纸"。它接收 Master 分配的设计任务，然后调用不同的设计技能：- 需求澄清：把模糊的需求变成清晰的功能描述- 数据库设计：设计表结构、字段、索引- API 设计：设计接口路径、参数、返回值- 架构设计：设计模块划分、依赖关系每个技能都有严格的输出模板。不是"随便写一个设计文档"，而是——按照固定格式，输出标准化的 Spec。
⚙️ 编码工人：Coding Worker
负责"按图施工"。它接收 Master 分配的编码任务，以及 Design Worker 输出的设计文档。然后按照设计文档生成代码。生成完之后，它还会：- 自动运行代码审查（对照设计文档检查一致性）- 自动生成测试用例- 自动运行测试如果测试不通过，它会自己修复，直到通过为止。
技术深扒：为什么要用多个 Agent 而不是一个？答案是两个字：上下文。一个 AI 的上下文窗口是有限的。即使 2026 年已经到了百万 Token 级别，但一个完整项目的"所有信息"加在一起可能有几十万 Token。如果让一个 AI 同时装下所有信息，它会"注意力分散"——对每一部分的理解都不够深。多 Agent 的好处是：每个 Agent 只关注自己的职责范围。- Design Worker 的上下文里只有需求文档和设计模板- Coding Worker 的上下文里只有设计文档和编码标准- Master 的上下文里只有任务清单和进度每个 Agent 的上下文都是"精炼"的，而不是"塞满"的。这就像一个团队：CEO 不需要看代码，程序员不需要看财报。每个人只看自己需要看的东西，效率最高。
二、图纸：三层规范体系
上一篇我们讲了"三层架构"的概念。这一篇，我们看看它在真实框架里长什么样。
第一层：全局规范（Global Standards）所有项目通用的规范。不管你做的是电商、社交还是内部工具，这些规范都适用。
| 数据库规范 | t_ 前缀，字段蛇形命名，必须有 created_at 和 updated_at |
| API 规范 | { code, data, message } |
| 后端规范 | |
| 前端规范 | |
| 编码风格 |
这些规范一旦定好，AI 在生成代码时会严格遵守。
第二层：领域知识（Domain Knowledge）特定业务领域的规范。比如做招聘系统：- 招聘流程：简历投递 → 筛选 → 面试 → Offer → 入职- 业务实体：职位（Job）、候选人（Candidate）、面试官（Interviewer）、面试记录（Interview）- 状态机：候选人状态流转（待筛选 → 已筛选 → 面试中 → 已录用 / 已拒绝）这些知识告诉 AI：这个系统的"业务世界"长什么样。
第三层：最佳实践（Best Practices）经验沉淀。比如：- "多 Agent 协作时，用 Orchestrator-Workers 模式"- "长任务要做进度持久化，防止中断后丢失上下文"- "设计文档要用结构化格式（Markdown + YAML Frontmatter）"这些实践不是"硬规范"，而是"软建议"。但它们能显著提高 AI 生成代码的质量和一致性。
技术深扒：规范是怎么"喂"给 AI 的答案是：上下文注入。当 AI 开始一个编码任务时，框架会自动做以下事情：1.加载全局规范：把数据库规范、API 规范、编码风格等，注入到系统提示词中2.加载领域知识：根据当前任务涉及的业务实体，加载相关的领域知识3.加载设计文档：把当前任务对应的 Spec 注入上下文4.加载最佳实践：如果当前任务涉及特定模式，加载对应的最佳实践这个过程是自动的。开发者不需要手动复制粘贴。框架根据"当前任务是什么"，自动选择"需要加载哪些规范"。
三、流程：从需求到上线的七步
有了工头（多 Agent），有了图纸（三层规范），最后需要的是流程。
Step 1：需求澄清输入：用户的原始需求 → 输出：结构化的功能需求文档AI 不会直接写代码，它会反问——把模糊的需求变成清晰的功能列表和验收标准。
Step 2：架构设计输入：功能需求文档 → 输出：模块划分、技术选型、系统架构图产出是一个"鸟瞰图"——告诉所有人，系统的大框架长什么样。
Step 3：数据库设计输入：功能需求 + 架构设计 → 输出：完整的 DDL（建表语句）每张表的字段名、类型、约束、索引，全部明确。
Step 4：API 设计输入：功能需求 + 数据库设计 → 输出：完整的 API 接口文档每个 API 的请求参数、返回格式、错误码，全部定义清楚。
Step 5：代码生成输入：数据库设计 + API 设计 + 全局规范 → 输出：可运行的后端 + 前端代码AI 严格按照设计文档中的字段名、接口路径、返回格式生成代码。
Step 6：测试输入：代码 + API 设计 → 输出：测试用例 + 测试报告根据 API 设计文档，自动生成正常/异常/边界场景的测试用例。
Step 7：代码审查输入：生成的代码 + 设计文档 → 输出：一致性审查报告逐项检查字段名、接口路径、返回格式是否与设计文档一致。不通过则自动修复。
技术深扒：七步流程的编排逻辑
Step 1（需求澄清）↓Step 2（架构设计）↓Step 3（数据库设计）──→ Step 4（API 设计） ↓ Step 5（代码生成） ↓ Step 6（测试）──→ Step 7（审查） ↑ │ └──── 不通过 ────┘
注意最后的循环：如果审查不通过，会回到代码生成重新修改。这个循环最多执行 3 次。Master Orchestrator 负责管理这个依赖图。人类只需要在 Step 1 参与（澄清需求），以及在 Step 7 之后做最终确认。中间的 Step 2-6，全部由 AI 自动完成。
四、一个真实案例
说了这么多，来看一个完整的实例。
需求：给一个招聘系统添加"面试官管理"模块。
用户输入
"我需要一个面试官管理功能。面试官有姓名、部门、职级、擅长领域。能增删改查，能按部门筛选。"
Step 1 输出：需求文档（AI 生成，人确认）
功能模块：面试官管理（Interviewer） 功能列表： - F001：创建面试官 - F002：编辑面试官信息 - F003：删除面试官（软删除） - F004：查看面试官详情 - F005：面试官列表（分页 + 按部门筛选） 实体字段： - id: 主键 - name: 姓名（必填，2-20字符） - department: 部门（必填） - level: 职级（选填，枚举：初级/中级/高级/专家） - expertise: 擅长领域（选填，多选标签） - status: 状态（启用/停用） 验收标准： - 创建成功返回 201 + interviewer_id - 名字重复允许（不同部门可以有同名面试官） - 删除为软删除，status 改为"停用" - 列表默认按创建时间倒序
Step 3 输出：数据库设计
CREATE TABLE t_interviewer ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(20) NOT NULL COMMENT '姓名', department VARCHAR(50) NOT NULL COMMENT '部门', level TINYINT DEFAULT 0 COMMENT '职级: 0-初级 1-中级 2-高级 3-专家', expertise VARCHAR(200) DEFAULT '' COMMENT '擅长领域,逗号分隔', status TINYINT DEFAULT 1 COMMENT '状态: 0-停用 1-启用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_department (department), INDEX idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='面试官表';
Step 4 输出：API 设计
POST /api/interviewer → 创建面试官 GET /api/interviewer/:id → 获取详情 PUT /api/interviewer/:id → 编辑信息 DELETE /api/interviewer/:id → 软删除（status → 0） GET /api/interviewer/list → 分页查询（?department=xx&page=1&size=10）
Step 5 输出：代码
后端自动生成：
InterviewerController.java— 5 个接口 InterviewerService.java— 业务逻辑 InterviewerMapper.java— 数据库操作 Interviewer.java— 实体类
前端自动生成：
InterviewerList.vue— 列表页（含分页、部门筛选） InterviewerForm.vue— 新增/编辑表单 interviewer.ts— API 调用层
Step 6-7：测试 + 审查
自动生成 12 条测试用例，全部通过。
审查报告：字段名一致 ✅、接口路径一致 ✅、返回格式一致 ✅。
从用户说出需求，到前后端代码全部生成，整个过程大约 15-20 分钟。
人类的参与只有两个节点：确认需求文档 + 确认最终代码。
其余全部自动化。
五、这和"直接让 AI 写"有什么区别？
Vibe Coding❌ 字段名每次可能不同❌ 只能看最终代码判断对不对❌ 5 个人各自 Vibe，字段名不统一❌ 三个月后出 Bug，没人知道当初为什么这样写
Spec Coding✅ 设计文档写了什么，代码就是什么✅ 代码生成前就能审查设计文档✅ 5 个人看同一份设计文档✅ 打开设计文档就知道设计意图
四个区别，一句话总结：
"在图纸阶段发现错误"的成本，是"在施工阶段发现错误"的 1/10。
六、谁适合用这套框架？
核心判断标准只有一个：
你的代码，以后需要被"不是你"的人理解吗？
如果是——你需要图纸。
七、从手工作坊到工业革命
最后，拉远一点看。
人类历史上，从"手工作坊"到"工业流水线"，经历了什么？
标准化。
螺丝钉有了统一的尺寸。
钢材有了统一的强度等级。
图纸有了统一的画法。
标准化让"个人技艺"变成了"工业能力"。
一个工人不需要是天才，只需要按 SOP 操作，就能产出合格的产品。
AI Coding 正在经历同样的转变。
Vibe Coding 是手工作坊——每个匠人凭手艺吃饭，产品质量因人而异。
Spec Coding 是工业流水线——标准化的规范、标准化的流程、标准化的产出。
这不是对"手艺"的否定。而是——当你需要造一万辆汽车，而不是一把手工椅子的时候，你需要流水线。
就像亨利·福特说过的那句话：
"如果我问顾客想要什么，他们会说想要一匹更快的马。"
Vibe Coding 是"更快的马"——让写代码更快。
Spec Coding 是"汽车"——改变了整个生产方式。
一百个 AI 走进同一间工厂。
它们不需要天赋。
它们需要的是——图纸、规范、和一条设计精良的流水线。
这条流水线搭好之后，会发生什么？
产品经理开始提交 Pull Request。
测试工程师开始写业务代码。
职业的边界，开始模糊。
下一篇，我们聊聊这件正在发生的事。
如果这篇文章对你有帮助，欢迎点赞 👍、在看 👀、转发 🔗
