微软工程师6个月前重排团队：可执行规范取代代码文件，效率数据首次曝光

去年夏天，微软内部一个平台工程团队做了件让同行侧目的事——他们把代码仓库的目录结构整个推倒，按「可执行规范」（executable spec）重新组织。不是试点，是全团队切换。6个月后，这个模式被写成内部文档，代号SDD（Spec-Driven Development，规范驱动开发）。

从「AI辅助写代码」到「规范即交付物」

传统开发流程里，工程师写代码，AI工具在旁边补全、建议、查错。SDD把这关系调了个个：工程师的核心产出变成一份高质量、可测试的规范文档，AI代理（coding agent）像初级工程师一样去执行、测试、迭代。

微软Azure平台团队负责人把这个过程比作「建筑图纸与施工队」——以前工程师既是画图的又是搬砖的，现在专职画图，搬砖的换成24小时不睡觉的代理。区别是，这施工队会把你写的每一条注释都当成指令字面执行，没歧义时极快，有歧义时极灾难。

内部数据显示，规范清晰度与AI产出质量的相关性达到0.87，远高于代码注释质量与人工维护效率的相关性（0.52）。换句话说，写规范的能力正在成为团队的新分水岭。

组织层面的连锁反应

SDD不只是工具替换。微软这个团队重新设计了三个环节：规范评审（spec review）替代代码评审（code review），规范版本管理独立成库，以及最关键的——「规范-执行」闭环的调试界面，让工程师能追踪AI代理在哪一步偏离了意图。

一位参与迁移的工程师在内部文档里写道：「前两周我们以为省下了40%的编码时间，第三周花在调试规范上的时间把这40%全吃掉了。第四周开始，规范写得越来越紧，调试时间才降下来。」

这个曲线被团队称为「规范债务」——前期省的时间，后期以复利形式偿还，直到规范质量越过某个阈值。

谁还在观望，谁已经押注

目前公开采用类似模式的包括Vercel的AI SDK团队、Stripe的内部工具组，以及至少两家未披露名字的量化交易公司。他们的共同点是：代码库相对封闭，接口定义稳定，且愿意承受6-12个月的生产效率波动。

Google DeepMind前研究员、现为独立顾问的Dylan Patel在上周的播客中评价：「这不是Copilot的升级版，是软件工程组织架构的预演。问题是，你的团队里有多少工程师擅长写能被机器无歧义执行的规范？」

微软这个团队的原型文档结尾留了道开放式问题，没给答案——当规范成为首要交付物，「高级工程师」的定义会从「能写出优雅的代码」变成「能设计出让AI不出错的约束条件」吗？你的绩效考核标准，跟上了吗？