上一节课我们讲了一个核心的认知：你是架构师，Codex是你的工程团队。你负责做决策，他负责执行
但是接下来又产生了一个新的问题，你怎么把你的决策传递给他？
我们可以想一想，如果你以前带过团队，你一定体会过，脑子里想的清楚，但是没有落地成文字，对方做出来的东西大概率和你想的不一样。如果你给了他明确的接口文档、数据模型命名规范错误码定义交付质量会好一个档次。
AI编辑器也一样，它很强，但是他不会读心，你不告诉他规矩，他就自己编写一套，每次编的还不一样。
这一节课我们就要讲贯穿整门课的核心方法论：规范驱动开发SDD 。简单来说就是先定规范，再让AI按规范执行，而不是让它直接写代码。
规范不是一次性的指令，而是一套体系
前面我们看到这样一个现象，你给AI编辑器的指令越清晰，输出质量越高。但是有一个容易被忽略的问题，你给的清晰指令只在那一次对话中有效.
当我们做代码回顾的时候，每一条单独看都不是bug，功能完全正常，但是放在一个项目中，两个模块两种风格，前端对接的时候需要适配两套格式，后面维护的时候，每个模块都要搞清楚这个模块的规矩是什么。这样问题就出现了
问题出在哪里？AI编辑器没有长期记忆，你的上一轮对话给的规范，他这一轮完全不知道，他不是忘了，而是根本没有看到。每次对话对他来说都是从零开始。
所以单次指令的清晰度只能决定输出的质量。要保证整个项目几十次几百次的AI输出完全一致。你需要的不是一条好指令，而是一套规范体系。写下来，每次自动加载，让AI编辑器不管在哪里，哪个模块，哪个阶段都在同一套规矩下工作。
这就是SDD和写号提示词的本质区别。写好提示词是一次性的技巧，而SDD是贯穿整个项目生命周期的方法论。
SDD完整工作流
上一节课我们讲了一个核心的认知：你是架构师，Codex是你的工程团队。你负责做决策，他负责执行
但是接下来又产生了一个新的问题，你怎么把你的决策传递给他？
我们可以想一想，如果你以前带过团队，你一定体会过，脑子里想的清楚，但是没有落地成文字，对方做出来的东西大概率和你想的不一样。如果你给了他明确的接口文档、数据模型命名规范错误码定义交付质量会好一个档次。
AI编辑器也一样，它很强，但是他不会读心，你不告诉他规矩，他就自己编写一套，每次编的还不一样。
这一节课我们就要讲贯穿整门课的核心方法论：规范驱动开发SDD 。简单来说就是先定规范，再让AI按规范执行，而不是让它直接写代码。
规范不是一次性的指令，而是一套体系
前面我们看到这样一个现象，你给AI编辑器的指令越清晰，输出质量越高。但是有一个容易被忽略的问题，你给的清晰指令只在那一次对话中有效.
当我们做代码回顾的时候，每一条单独看都不是bug，功能完全正常，但是放在一个项目中，两个模块两种风格，前端对接的时候需要适配两套格式，后面维护的时候，每个模块都要搞清楚这个模块的规矩是什么。这样问题就出现了
问题出在哪里？AI编辑器没有长期记忆，你的上一轮对话给的规范，他这一轮完全不知道，他不是忘了，而是根本没有看到。每次对话对他来说都是从零开始。
所以单次指令的清晰度只能决定输出的质量。要保证整个项目几十次几百次的AI输出完全一致。你需要的不是一条好指令，而是一套规范体系。写下来，每次自动加载，让AI编辑器不管在哪里，哪个模块，哪个阶段都在同一套规矩下工作。
这就是SDD和写号提示词的本质区别。写好提示词是一次性的技巧，而SDD是贯穿整个项目生命周期的方法论。
SDD完整工作流
1.定规范
在写任何业务代码之前，先要把基础规范定下来
你可能会想这要写多细，会不会花很长时间？
第一版粗一点没有关系，但一定要有，关键是看覆盖AI编辑器最容易跑错的地方
-
命名规范：实体内大驼蜂不加前后缀
-
接口规范：所有接口统一返回Result
-
错误码：按模块分段，四字错误码
-
设计原则：不引入不必要的设计模式，除非明确要求，不做过度抽象，一层能解决，就不拆成两层
这些规范写好了，放在哪里？放在项目的根目录AGENT.md文件中。AI编辑器每次启动新对话，会自动读取这个文件，你不需要每次手动喂给他
2.AI按规范执行
下达任务时，明确引用规范。比如帮我做一个用户登录的CRUD，不要说这个而式按照AGENT.md中的规范，实现用户登录的CRUD。
这句话的重点不是在按规范这四个字，因为AGENT.md已经在上下文中了，AI编辑器是看得到的。重点是提醒他去关注那份规范，而不是按照自己的经验。
3.人验证输出
有了规范之后，review的效率会大幅度提升。因为你不再是漫无目的的看代码，而是对着清单打勾。命名是不是按照规范来的，返回格式是不是统一的，有没有引入不必要的设计模式错误码是否在这个模块划分类内。
规范把review从主观判断变成了客观检查。这个转变对效率提升是巨大的。你不需要每次都重新思考，这里怎么写，因为标准已经定好了。
4.迭代规范
这一步是最关键，但也是最容易被忽略的。
你在验证输出时，一定会发现规范没有覆盖到的地方，这太正常了。你不可能一次性就想到所有情况，关键是每次发现缺口都要补上
每次当AI跑偏时，不只是要改代码，而是停下来问自己他为什么跑偏是不是规范没有覆盖到，然后补充上那个规范。
这规范一旦写进AGENT.md，后面所有的对话都会受到约束，你不需要再遇到同样的问题，他跑偏一次，你补一条以后，这个点就不会再跑偏。
坚持几周，你的规范会从最初的一张纸长成为一犯覆盖命名规则结果规范错误码，异常处理项目结构、分层原则、行为约束前端组件规范的完整体系。
什么样的规范才有用？
具体不模糊
没用的规范："代码要简洁，接口要规范"
有用的规范："不要引入不必要的设计模式，除非明确要求。所有接口统一返回Result，格式为{ code, message, data } ，错误码四位数按模块划分"
有优先级不贪多
规范不是越多越好，太多规范，AI编辑器也处理不过来，因为上下文窗口有限，塞了太多规范，反而会稀释最重要的几条
我的原则是:AI反复跑的地方写戏，不跑偏的地方不写
-
文件使用UTF杠8AI编辑器基本不会搞错，不得占篇幅
-
control层不写业务逻辑，这个经常犯错必须写
但原因,不只是规则
对于涉及工程权衡的规范，不能只告诉AI编辑器，不要这么做，还要告诉他为什么他需要理解约束的原因，才能在类似的场景举一反三。此时他会跟你讨论，可能你想的不对，不过也不是每条规范都需要解释
规范的分层
全局规范:写在AGENT.md中的，整个项目通用。命名规则，接口格式，错误码体系，设计原则，行为约束。项目初期定好，后面很少改动，这是地基。
模块规范：某个模块开发前单独定义。对话模块有自己的数据流定义，工作流模块有自己的节点类型规范，写在模块目录下或者开发前的指令里。
任务规范：每次给AI编辑器下达具体任务时的补充说明，比如这次不需要分页异常时要分区这种情况。这是临时的，不落地文档。
三层怎么配合？全局规范是地基，模块规范是补充，任务规范是临时调度。AI编辑器每次干活时看到的是三层叠加的完整约束，优先级从上到下任务规范，可以覆盖模块规范，但不能违反全局规范。
总结
SDD四步闭环：定规范，AI执行，人验证，迭代规范
规范不是额外的负担，而是节省时间的捷径。没有规范的AI像一匹没有缰绳的马，跑得越快，方向不可控，有的规范等于给他框在了轨道上，又快又稳。
从实操的角度来看，我们需要记住三件事
-
规范不需要一次写完第一版覆盖最容易跑偏的四个地方，命名返回格式错误码设计原则，后面的在开发中迭代补全
-
每次AI跑偏了，不要只改代码，还需要想想规范是不是该补充一条，跑偏一次补充一条，同样的问题不会再出现。第二次
-
规范要具体到AI，不需要猜你的意思。如果他看到后续的规范还需要拆，那就不够具体