AI编程正在进入一个反直觉阶段：代码生成越容易，越不能急着写代码。
过去，开发效率的瓶颈在于人写得慢。现在，瓶颈变成了AI写得太快、太顺、太容易绕过约束。一个提示词下去，项目能跑起来，测试看似通过，界面也能展示，但需求有没有被完整覆盖，架构有没有被破坏，安全约束有没有落实，没人能只靠肉眼放心。
这就是规格驱动开发开始变重要的原因。
它不是把开发流程变复杂，而是在AI动手之前，先把边界画清楚。需求是什么，测试怎么验证，哪些原则不能违反，哪些代码必须可追溯，哪些场景要阻断实现。AI越强，规格越像方向盘和刹车。
一个成熟的AI编码流程，不能只问模型能不能写代码，而要问它是不是被约束在正确轨道里。
规格驱动开发不是一类工具，而是一套分层生态。现在可以把它看成三种工程合同。
第一种是轻量合同，先写规格，再写代码。
这类方式可以称为Spec-First。它适合个人开发者、小团队、MVP、新项目和实验性功能。它的重点不是永久审计，而是让AI在当前开发周期里先理解目标，再拆解任务，再实现代码。
Spec-Kit就是典型代表。它不只是几个命令，而是会在项目里放入一套持续影响AI行为的文件，例如constitution.md、spec模板、plan模板和tasks模板。constitution.md相当于项目宪法，规定功能要优先抽象成库，要先写测试，要控制复杂度，要重视可观测性和模块化。
这种方式的价值在于，AI不再拿到一句模糊需求就开始编码，而是要先形成用户故事、功能需求、成功标准、实现计划和任务列表。对很多团队来说，只要能做到这一步，AI编码质量就会明显稳定。
但它也有边界。功能合并之后，规格往往变成历史文档，不一定继续随项目长期演进。它适合追求效率和结构，不适合强审计场景。
第二种是硬纪律合同，用门禁阻止AI乱跑。
Superpowers的流行就说明了这一点。它的价值不在于复杂，而在于简单粗暴地阻断坏习惯。安装后，它通过技能文件给Claude Code加上明确流程：先头脑风暴，再写方案，再准备测试驱动开发，再执行任务。
其中最关键的是HARD-GATE。没有经过批准的设计，没有先失败的测试，就不能写生产代码。这一点非常适合AI编程，因为AI最常见的问题不是不会写代码，而是太愿意直接写代码。它会先实现，再补测试；会跳过设计，直接堆功能；会在长上下文中逐渐忘记早期约束。
Superpowers用波次执行和子代理审查来缓解这些问题。一个代理负责方案，一个代理负责实现，一个代理检查规格符合度，一个代理检查代码质量。每个阶段尽量减少上下文污染。
它不提供完整追踪矩阵，也不特别适合遗留系统改造，更偏向Claude Code生态。但对个人开发者和小团队来说，这种门禁可能比复杂体系更有用。因为它抓住了AI编码最核心的风险：没有设计就写，没有失败测试就写，没有审查也敢合并。
第三种是审计合同，规格必须贯穿需求、设计、代码和测试。
这类方式可以称为Spec-Anchored。它适合企业团队、合规场景、多人协作和长期维护项目。这里的规格不是开发前的临时说明，而是项目生命周期里的锚点。
MUSUBI是这一层中非常有代表性的框架。它的热度不高，但形式化程度很高。它强调EARS需求写法、C4架构图、ADR架构决策记录、测试驱动开发和完整追踪矩阵。
EARS的意义在于减少需求歧义。需求不能写得含糊，比如应该、可以、也许这类表达都要避免。系统必须在什么条件下做什么事，要写成明确模式。每条需求都有编号，后面能一路追到设计文件、代码位置和测试文件。
追踪矩阵是企业真正关心的部分。它回答的是一条需求有没有被设计覆盖，有没有代码实现，有没有测试验证。对普通项目来说，这可能显得繁琐。对金融、医疗、政企、基础设施和安全要求高的项目来说，这就是审计语言。
如果一年里从来没人问过需求到测试的追踪关系，那大概率不需要这种复杂度。如果已经有人问过，或者未来大概率会被审计，就不能只靠轻量规格文档。
第四种是源头合同，只允许改规格，不鼓励直接改代码。
这就是Spec-as-Source。它比前两类更激进。规格成为唯一可编辑源头，代码由规格生成。代码文件里会明确标出来自规格生成，不应手工编辑。
Tessl代表这种方向。开发者在.spec.md里写需求、测试和生成目标，然后由工具生成对应代码。要改变行为，就改规格，再重新生成。它还试图建立规格注册表，让AI使用经过验证的库规格，而不是凭记忆猜API。
CSDD则把安全约束也放进规格体系。比如SQL注入防护、身份验证、输入校验等安全规则，不是事后扫描，而是作为宪法条款提前约束AI生成。规则违反就拒绝实现。这种方式对安全关键系统很有吸引力。
不过现实一点看，Spec-as-Source在2026年仍然偏早期。它适合关注、试点和用于高风险模块，不一定适合所有普通业务项目全面铺开。它代表未来方向，但还不是多数团队今天的默认答案。
所以，工具选择不能从排行榜开始。
星标高不等于严谨，严谨也不等于适合。Superpowers星标高，是因为安装简单、上手快、纪律强。MUSUBI星标低，不代表价值低，而是它面向的是需要合规、审计和严格追踪的少数团队。Tessl和CSDD更像未来基础设施的早期形态，值得关注，但部署要看场景。
真正的选择逻辑应该先问四个问题。
第一，团队规模多大。一个人或三五人团队，过重流程会拖慢节奏。轻量Spec-Kit或Superpowers更合适。
第二，项目是不是新项目。绿地项目可以从规格开始建秩序。遗留系统更适合OpenSpec这类支持增量变更和delta specs的工具，再配合Shotgun CLI先理解代码库。
第三，是否有合规和审计压力。没有就不要过度设计，有就必须上可追溯体系。MUSUBI加CSDD会比单纯提示词可靠得多。
第四，安全是否是核心风险。普通后台管理系统和金融支付核心模块，不应该使用同一套门槛。安全关键场景要把OWASP、CWE、MITRE Top 25等约束写进规格和审查流程。
未来的方向已经很清楚。
MCP会让工具和AI代理之间的连接更标准，像给AI代理准备统一接口。AGENTS.md会让项目根目录里的代理行为规则成为跨工具共识，类似过去package.json对前端生态的意义。Living Spec会让规格从文档变成持续同步的意图数据库，既能被人读，也能被代理更新和执行。
到那时，AI编程的竞争不再是谁更会写提示词，而是谁更会写规格。
提示词是一次性对话，规格是可维护资产。提示词解决眼前任务，规格沉淀团队规则。提示词让AI开始工作，规格让AI按正确方式工作。
对多数团队来说，最务实的做法不是一上来追求最高严谨度，而是先在低风险项目里引入轻量规格流程。让AI先写规格、计划和任务，再写代码。再根据项目复杂度逐步加入TDD门禁、追踪矩阵和安全宪法。
AI写代码的时代，真正稀缺的不是能生成代码的人，而是能把业务意图变成工程约束的人。
代码会越来越便宜，规格会越来越值钱。谁能把需求、架构、测试、安全和协作规则组织成AI必须遵守的系统，谁就能在AI编程时代拥有真正的工程控制权。
