夜雨聆风一个程序员对AI说：加个登录功能，用邮箱密码就行。
AI两分钟吐出一堆代码，JWT鉴权、bcrypt加密，看起来专业极了。
两天后，麻烦全来了：忘记密码流程没做，token刷新逻辑缺失，数据库schema直接写在业务代码里，连最基本的登录速率限制都没有。安全评审当场打回，从头再来。
这种场景，在2026年的AI辅助编程现场几乎天天上演。而现在，GitHub亲自下场，把这场混乱定了性。
「你的AI写的代码，看起来对，跑起来错」
7月4日，一条来自印度开发者Nainsi Dwivedi的推文，在X上炸开了锅。
"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写的代码，看起来对，跑起来错。模型没错，错的是你自己，你给了它一个感觉（vibe），却指望它交出规格（spec）。」
这句话精准戳中了过去两年所有"随口一提"式AI编程的痛点。她接着补了一句更狠的：
"GitHub just shipped the fix ， and it's already sitting at ~97K stars."
「GitHub刚刚发布了修复方案，目前已经收获约9.7万星标。」
这个"修复方案"，叫Spec Kit。发推时星标还是9.7万，等这篇文章落笔，数字已经冲到了11.9万。
▲ GitHub官方仓库页面：119k stars、10.5k forks，宪法（constitution）、规格（specify）、澄清（clarify）、计划（plan）、任务（tasks）、实现（implement）六大命令一字排开。
Vibe Coding：一场集体信任危机
在深入这个工具之前，得先弄明白它到底在解决什么问题。
过去两年，AI编码代理的能力节节攀升，一种默认工作方式随之成型：你描述目标，AI立刻吐出代码。业内给它起了个名字，叫vibe coding，凭感觉、模糊提示编码。
问题是，"感觉"这东西，AI理解不了。
GitHub官方博客里，产品经理Den Delimarsky（@localden）把这个现象讲得毫不留情：
"As coding agents have grown more powerful, a pattern has emerged: you describe your goal, get a block of code back, and often... it looks right, but doesn't quite work."
「随着编码代理越来越强大，一种模式也随之出现：你描述目标，拿回一段代码，往往……它看起来是对的，但并不完全能用。」
▲ GitHub官方博客首段：vibe coding「对快速原型很好，但在构建严肃、任务关键型应用时，可靠性会打折扣」。
这些数字算不上危言耸听。Stack Overflow 2025年度调查显示，84%的开发者已经在用或计划使用AI编程工具，但真正信任AI输出准确性的，只有33%。对AI的正面情绪，也从70%以上跌到了60%左右。
用得越多，信得越少，这是一种典型的信任透支。原型阶段图快没问题，一旦项目进入生产环境、涉及团队协作、要跟遗留系统打交道，"猜"出来的代码随时可能拖垮整条流水线。
GitHub给出的答案：把「规格」变成活的合同
GitHub的解法，说起来并不复杂：别让AI瞎猜，让人先把话交代明白。
Spec Kit把这套方法论叫Spec-Driven Development（规格驱动开发，简称SDD）。核心翻转可以这样理解：过去规格文档写完就扔，代码才是正主；现在规格本身变成可执行的中心真相源，代码只是它的"最后一英里翻译"。
具体落到六个slash命令上：
/speckit.constitution ， 先定项目的"宪法"：质量标准、测试红线、性能要求、不可协商的原则。
/speckit.specify ， 只讲要做什么、为什么做，不谈技术栈。AI自动生成带验收标准的详细规格文档。
/speckit.clarify ， AI主动提问，把模糊地带标出来，逼着人类先把坑填上，省得写完代码才发现问题。
/speckit.plan ， 这时候才谈架构、技术选型、遗留系统怎么对接。
/speckit.tasks ， 把计划拆成可独立测试、可并行执行的任务清单。
/speckit.implement ， AI按任务顺序落地，人类审查的对象变成一个个可控的小改动，几千行代码一次性砸过来的旧模式就此终结。
回到开头那个登录功能的故事。如果走一遍这套流程会怎样？
specify阶段就得写清楚："必须支持忘记密码、邮箱验证、为社交登录预留接口"；clarify阶段AI会追问："token存在localStorage还是httpOnly cookie？刷新策略是什么？"；plan阶段，宪法会强制"所有认证逻辑走独立模块，先写contract再写实现"；tasks阶段第一条任务就是"先写登录接口的契约测试"。
结果：一次性通过评审，每一行代码都能追溯到某条具体需求。返工的两天，就这样被省了下来。
一条推文，怎么让全网吵起来了
Nainsi的那条推文只是冰山一角。7月3日到4日两天里，X上同类内容集中爆发，核心论点高度一致。
印度AI博主Kshitij Mishra（@DAIEvolutionHub）的帖子拿到了1.1万浏览、88个赞：
"This isn't just any project. It's GitHub telling you how to really code with AI. The real difference is this ， Before: 'make me a task app' and you pray the agent doesn't get lost halfway. Now: specification first, code after."
「这不只是一个普通项目。这是GitHub在告诉你该怎么真正用AI编程。真正的区别在于，以前：『给我做一个任务应用』，然后祈祷代理别中途迷路。现在：先规格，再代码。」
▲ @DAIEvolutionHub帖子：详细拆解6条命令，并指出Cursor、AWS Kiro、Google Antigravity、OpenSpec、BMAD等工具「同期独立收敛」到了同一个方向。
西语区的关注度同样惊人。哥伦比亚开发者Amarillo（@anyelamarillo）的帖子拿到1.9万浏览、216个赞：
"GITHUB ACABA DE SOLUCIONAR EL MAYOR PROBLEMA DEL VIBE CODING... Spec Kit obliga a la IA a entender ANTES de tocar código."
「GitHub刚刚解决了vibe coding的最大问题……Spec Kit强迫AI在碰代码之前，先理解你想要什么。」
▲ 西语区高互动帖：简洁列出六步流程，评论区涌入大量跨语言转发，中文回复区也出现「先把需求捋清楚，少返工太多了」的共鸣。
中文社区的反应更务实、更接地气。有人感慨「给AI写需求比写代码还难一点」，也有人保持警惕：「规范先行听起来很美，但星标热度不等于工程落地。团队如果没有测试、评审和边界约束，规范也可能变成另一层噪音。」
为什么大家管它叫「认证体系」
GitHub自己从没用过"认证"这个词。但翻遍这几天的讨论，你会发现一种共同的潜台词：这套东西正在给"什么是专业用AI编程"划一条线。
理由并不玄乎。Spec Kit的宪法机制会强制LLM遵守：simplicity gate（不能超过3个项目模块）、anti-abstraction gate（禁止过度包装框架）、test-first（测试必须先于实现代码存在）。任何一条没达标，都得在"复杂度追踪"里写清楚原因，才能继续往下走。
这几乎就是一套流程规范：
强制结构，像代码规范或ISO流程一样约束输出。
可审计制品，每一份spec、plan、tasks都是能进版本控制、能被review、能被追溯的Markdown文档。
跨团队一致性，不管用Claude Code、Cursor还是Copilot，走的都是同一套流程。
组织可定制，团队自己的安全合规要求，写进宪法里，成为AI必须遵守的刚性约束。
▲ 文档站首页显示，这套东西的体量早已超出命令集合：105个社区扩展、22个预设，甚至有团队基于它做出了完全不同的SDD流程变体（如AIDE、Canon、MAQA）。
一位X用户的评论说得毫不客气，却也精准：
"You're not a worse engineer than the people shipping clean AI code. You just skipped the spec."
「你不比那些交付出干净AI代码的人差，你只是跳过了规格这一步。」
这句话戳破了一层焦虑，拉开差距的根源，是方法论上的落差，跟天赋关系不大。GitHub现在把这套方法论摆到了台面上，免费、开源、不锁定任何一家AI工具。学不学，成了一道分水岭。
这道题，全行业都在抢答
如果只是GitHub一家在吆喝，这事顶多算一次成功的产品营销。但独立研究者Ry Walker的数据显示，这套逻辑正在被整个行业同时验证。
亚马逊的Kiro用EARS形式化需求语言，配合三份文档体系，让合规审计能照着需求文档逐条核对；开源工具OpenSpec主打改造存量系统场景，用delta标记清楚区分"新增"和"修改"；重量级选手BMAD-METHOD则搞出21个角色代理，从产品经理到架构师到QA一条龙生成完整PRD。
几家公司互不商量，却在同一时间段走到了同一个结论，"规格是人类意图与AI执行之间的契约"。这背后，是行业结构性问题逼出的必然解，运气成分很小。
Spec Kit的独特之处在于三个词：官方、开放、不锁定。它不属于任何一个AI编程工具，MIT协议、支持30余种代理，这让它更像一份摆在台面上的行业参考实现，谈不上是哪家厂商的私货。
争议还在，但方向已经清楚
当然，没有人说这套东西是万能药。
Reddit和Hacker News上，批评声音同样具体：小bug修复用得着走六道工序吗？"我们其实也不知道该给AI什么规格"；长任务里，静态spec会不会跟代码脱节、产生新的漂移？也有人怀疑这不过是"生成一堆文字的假象工作"。
GitHub官方的态度其实很务实：小任务、探索性spike可以继续vibe，真正需要spec纪律的，是greenfield大功能和brownfield遗留系统集成，那些"AI理解错了就要赔上一整天调试"的场景。
这恰恰呼应了X上一条被反复引用的判断：
"A clear spec saves more time than a better prompt ever will."
「一份清晰的规格，比一个更好的提示词能省下更多时间。」
职业化的真正含义
把镜头拉远一点看，这场讨论的核心，其实是AI Agent工程师这个新兴职业，正在经历一次身份重构。
早两年，"会用AI"约等于"会哄模型"，调提示词的技巧活。而现在，能力的重心正在转移：写清晰可测试的需求、设计项目宪法、主动澄清模糊地带、管理不断演进的活规格、在不同AI代理间自由切换而不被锁死。
这套复合能力，其实更接近传统资深工程师、架构师、业务分析师的合体。只不过，GitHub把"正确做法"标准化了，用一个开源工具把门槛摆在了每个人面前，会用的人效率暴涨，不会用的人继续在返工里打转。
往远处看，用"文档驱动代码"这件事，历史上早有人试过。半个世纪前，Donald Knuth提出的literate programming（文学化编程），主张代码与说明文字交织共生。当年这个想法因为工程成本太高没能大规模落地，如今AI把"生成"这一步变得几乎零成本，那个老想法突然有了实现的可能。
有人已经开始预测下一步：培训机构会不会很快推出"Spec-Driven Development认证课程"？招聘JD里，"熟悉spec-driven workflow"会不会像当年"会用Git"一样，从加分项变成基础门槛？
没人能给出确定答案。但11.9万颗星标砸在眼前的时候，答案已经悄悄浮现，这个行当里，谁才算得上"专业"，正在被重新定义。
