夜雨聆风深夜十一点，你对着AI编程助手打了一行提示词：帮我做一个任务管理App。
几秒钟后，几百行代码吐了出来。缩进整齐，命名规范，注释齐全，看起来无懈可击。
你信心满满地跑起来。
第一个按钮点下去，报错。修。第二个功能测试，逻辑对不上。改。third轮，AI又把你已经改好的地方悄悄改了回去。
到了凌晨两点，你盯着屏幕，脑子里翻来覆去只有一个念头：这AI到底有没有认真听你说话？
7月4日，X平台一条推文把这种崩溃感戳穿了。发帖人Nainsi Dwivedi写道：
"Your AI writes code that looks right and works wrong. That's not the model's fault. It's yours. You gave it a vibe and expected a spec."
「你的AI写出的代码，看着对，跑起来错。这锅模型不背，得你自己扛。你给它的是一种感觉，指望换回来的却是一份规范。」
这条推文底下，她甩出了一个数字：GitHub刚发布的工具，星标已经冲到9.7万。
先别急着怪AI
问题出在哪？
Dwivedi给出的答案是：你一直在用「氛围编程」（Vibe Coding）的方式驱动AI，随口说一句想法，剩下的全靠它猜。猜对了是运气，猜错了就是你熬夜改bug的开始。
GitHub官方给这套猜谜游戏起了个名字，叫Spec Kit。核心思路说白了就一条：别再把编程代理当搜索引擎使唤，把它当成一个只认字面意思的实习生。你嘴里说的越模糊，它吐出来的垃圾就越多；你写得越精确，它做出来的东西才越接近你脑子里真正想要的样子。
▲ Nainsi Dwivedi的种子推文：「你不比那些交付干净AI代码的人差，只是跳过了规范」，1.7K次查看
这套工具把开发流程拆成六个命令，环环相扣：
/constitution，先定这个项目不可商量的原则，质量标准、测试要求、架构底线；
/specify，描述要做什么、为什么做，先不谈技术选型；
/clarify，AI在动手写代码之前，主动把没搞懂的地方问出来；
/plan，这一步才轮到确定架构和技术栈；
/tasks，把计划拆成一个个能单独测试的小任务；
/implement，代理按任务清单往下执行，人负责在每个节点把关。
每一步都会生成一份Markdown文档，喂给下一步。GitHub官方博客的说法是：
"Crucially, your role isn't just to steer. It's to verify."
「这里的关键在于：方向盘握着不算完，验货的责任你也一样跑不掉。」
▲ GitHub官方博客：《Spec-driven development with AI: Get started with a new open source toolkit》，作者Den Delimarsky，2025年9月2日发布
一周之内，星标从9万7冲到11万9
这套方法论去年9月就已经上线，一直不温不火地积累口碑。真正被顶到聚光灯下，是最近这一周。
几乎同一时间，另一位技术博主Kshitij Mishra也发了条推文，角度不太一样，但结论一模一样：
"GitHub just 🪦 the vibe coding. Just published spec-kit and in a few days it has 95k stars and 8.3k forks."
「GitHub刚刚把氛围编程送进了坟墓。刚发布的spec-kit，短短几天就冲到9.5万星标、8300次fork。」
他补了一句更让人破防的对比：以前是「给我做个任务App」，然后祈祷AI别中途走偏；现在是先定规范，后写代码，代理清楚知道要建什么、按什么顺序、为什么这么建。
▲ Kshitij Mishra：「GitHub官方发布，MIT许可，支持25+代理」，1.1万次查看
等到这篇文章落笔的时候，GitHub官方仓库的实时数据已经变成：星标11.9万，fork 1.05万，248名贡献者，累计1318次提交，社区第181个版本刚在13小时前发布。issue开了227个，pull request挂着176个，这些数字堆在一起，活脱脱是一台还在高速运转的机器，压根谈不上安静。
▲ github/spec-kit仓库页面：119k星标、10.5k fork、248名贡献者、21个分支
配套文档站也早已成型：30多种AI编程工具接入，社区贡献的扩展超过105个，预设模板22套，覆盖从架构守护到角色化套件的各种场景。
▲ Spec Kit文档站：「先定义要造什么，再动手造」，支持Copilot、Gemini、Codex、Claude等30+代理
中文开发者：这一幕，太熟悉了
这波热度没有停在英文圈。国内开发者的反应几乎是同步的。
一位署名「孤桜ETH」的用户发帖感慨，这个项目「确实被震了一下」，GitHub官方出品，短时间内星标冲破11万，数据属实厉害。他把工作流拆成三点讲给中文读者听：用大白话描述想做什么，工具自动补全验收标准、边界条件、异常场景；规范定好后一键生成技术方案，任务拆分、技术选型、测试清单全套排好；支持三十多种主流AI编程工具，覆盖面几乎无死角。
最后他补了一句大实话：如果你也经历过「改了几十轮才发现AI从一开始就理解错了」的绝望，这东西值得立刻上手试试。
▲ 孤桜ETH：「用Spec-Driven Development的思路干活，确保AI从第一步开始就没理解偏」
这种共鸣不难理解。国内团队在出海和快速迭代的场景里，对「需求说不清楚」这件事的痛感格外强烈。一个能把模糊想法结构化的工具，戳中的是每天都在发生的真实摩擦。
泼冷水的人来了
但故事没有到这里就结束。
星标涨得越快，质疑声就跟得越紧。Thoughtworks的杰出工程师Birgitta Böckeler，业内更熟悉她的另一个身份，Martin Fowler团队的核心分析者，亲自把Spec Kit和另外两款同类工具拿来做了横向拆解。
她的判断很冷静：「规范驱动开发」这个词现在还是个筐，不同工具塞进去的东西完全不一样。有的只是「先写规范再干活」，有的要求规范全程保留、随功能一起演进，最激进的一派干脆规定人类以后只准改规范，代码全部交给AI生成，连碰都不该碰。
▲ martinFowler.com：《Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl》，作者Birgitta Böckeler，2025年10月15日
她引用了另一家工具Tessl的定义：
"A development approach where specs ， not code ， are the primary artifact. Specs describe intent in structured, testable language, and agents generate code to match them."
翻译过来：规范才是真正的核心产出，用结构化、可测试的语言把意图写清楚，代码只是代理跟着规范生成出来的附属品。
问题是，这套逻辑她并不完全买账。她亲自上手试用后发现，遇到简单任务时，走完这一整套流程花掉的时间，可能比单纯用普通AI辅助编程还长。规范驱动更适合从零搭建的大项目，遇到小修小补，更像是拿一把大锤去敲核桃。
「这是在制造一种干活的假象」
真正的重锤，来自GitHub Discussions里一场持续了大半年的辩论。
一位用户NaikSoftware去年9月开了个帖子，标题毫不留情：
"SpecKit creates the illusion of work, generating a bunch of text"
「SpecKit制造了一种正在干活的假象，实际只是生成了一堆文字。」
他列出了亲身经历：就算给了完整详细的信息，AI生成的文件依旧无视项目原有结构；本该只是给现有代码加个测试，它非要另起炉灶，造出几百个毫无意义的新测试；LLM忙着分析成千上万行指令，反而把任务本身的重点丢了。
他的结论毫不客气：Spec Kit的适用范围其实很窄，测试新想法、生成简单原型还行；真要做正儿八经的渐进式开发，项目分析该谁来做谁来做，实现步骤该开发者自己想清楚，AI能帮着澄清问题，但规划这件事绝对不能全权交出去，因为LLM终究只是在模仿理解，并没有真正搞懂任务本身为何而存在，它只是一张很大很复杂的网络。
这条帖子下面聚集了14位参与者、27条回复。有人反驳：只要项目宪章写得扎实，plan阶段肯下功夫打磨，这套流程对大规模改动确实值。也有人退让半步：对小改动来说，这套流程摆明是大炮打蚊子。
▲ github/spec-kit Discussions #1784：「SpecKit制造了干活的假象」，14人参与，27条回复
这出戏，历史已经演过一遍
Böckeler在分析里埋了一条更深的伏笔：上世纪末到本世纪初，软件行业流行过一种叫「模型驱动开发」（Model-Driven Development, MDD）的方法论。用UML图或者DSL搭结构化模型，人类只改模型，代码全靠生成器吐出来。
听起来耳熟吗？
MDD最后在主流业务系统里全面败退。抽象层次不上不下，工具本身开销巨大，生成出来的代码想调试比登天还难，灵活性更是无从谈起。
规范驱动开发用自然语言取代了UML，用大语言模型取代了确定性生成器，绕开了「必须能被机器精确解析」这道约束。但换来的代价是LLM本身的不确定性，同样一份规范，喂给模型两次，出来的实现可能都不完全一样。前期投入巨大、后期陷入僵局，这条老路会不会被重新走一遍，现在没人敢打包票。
有一派更激进的实验，索性把代码标记成「此文件由AI生成，请勿手动修改」，人类彻底退出代码层，只在规范层活动。这是目前整场实验里走得最远的一步棋。
谁才是真正的AI Agent工程师
抛开工具本身的成败，这场争论最终指向一个更让人破防的问题：如果AI真能写完大部分代码，工程师这份工作到底还剩下什么？
X上流传的一种说法给出了答案：「Claude Code不做架构，Claude Code不写规范，Claude Code只管写代码。AI工程师负责设计系统。」
讨论区里还有一种更具体的换算：过去一名工程师的精力分配大概是80%写代码、20%做别的；换到规范驱动的框架下，这个比例可能要反过来，50%花在规划上，20%留给编码，剩下30%全部投入验证和把关。
这背后是一次悄悄发生的技能迁移。过去两年，行业里卷的是提示词技巧；现在，真正稀缺的能力变成了需求梳理、架构判断、验证策略，以及在多个AI代理之间做编排调度。会不会写出一份经得起推敲的规范，正在变成区分「真懂行」和「只会喊AI帮忙」的分水岭，没人给它发考卷，可它已经在事实上扮演着这个行业新的准入标尺。
当然，也有更往前看的声音。有观点认为，顶尖工程师早已不满足于静态的规范文档，转向一种叫「损失函数驱动开发」（Loss Function Development）的更激进路径，不再写一份写死的规范，而是设计可优化的目标、评估集和约束条件，让AI在框定的边界内自己迭代。如果这个方向成立，规范驱动开发很可能只是一个过渡阶段，行业最终会走向「人类定义目标，AI在约束里自主试错」的下一站。
那条最先把这场讨论捅开的推文，最后留下一句让无数程序员长舒一口气的话：
「你不比那些交付干净AI代码的人差，你只是跳过了规范。」
这句话把责任从「模型不行」或者「我太笨」，转移到了「流程没搭对」。焦虑被卸下了一半，但另一半才刚刚开始，写好一份规范，正在变成这个时代工程师必须补上的新功课。
