最近两周，知乎上有个热帖在AI编程圈里传得很广：“AI写出来的代码越来越多，未来的软件会不会变得’没人真正看得懂’？”
底下赞最高的回答讲了一个让很多人感同身受的故事：作者从头到尾用顶级模型——从Opus一路换到Fable，再到最新的GPT-6 Astra——vibe出一个小工具，结果"我已经彻底看不懂了，或者说从一开始我就看不懂"。加功能得找AI，改bug也得找AI，“每次都要等这里爆炸了我才知道有问题”。他另一个项目更保守，只让AI生成"我认为很简单的模板代码"，结果整个8月都在给这堆代码擦屁股：“出来混的，最后总是要还的。”知乎
这条回答拿了590个赞、74条评论，浏览冲到14.9万。更有意思的是，国庆前后知乎冒出了一排同款新问题：“AI写的代码能跑但没人敢动，接手的人该怎么检查？”“用了AI编程助手后，你写代码到底更快了，还是改Bug更累了？”“开始用AI写代码后，你们会把它生成的代码逐行看完吗？”
不是大家突然开始反思，是第一批vibe coding的人，项目集体跑到第三个月到第六个月——还债期到了。
一、为什么"能跑"总会变成"没人敢动"
先说一个被反复验证的成本结构：写代码变便宜了，但读代码从来都不便宜。
有统计说，开发者本来就有58%到70%的时间花在读源码上。AI把"写"压到接近免费之后，唯一还贵的环节，恰好是本来就最花时间的那一项——读，以及验证。一位三年里把同一个项目重写了五次的作者复盘得很透彻：对AI来说，重写和重构是同一个动作，区别只在于旧代码在不在上下文里；但重构多出来的两项要求，一项是读，一项是保证新代码可用，后者只能靠人兜底。知乎
更要命的是"review幻觉"。那条热回答里有句话特别扎心：AI生成的东西大部分是对的，很容易让你产生"review了一遍它就是我自己的"这种错觉，“但很多很细的细节，你没想清楚就是没想清楚，总有一天它会让你重新想清楚”。知乎
这个瓶颈连工具厂商自己都承认。Cursor研发副总裁Tido Carriero的分享最近又在B站被翻出来传：AI编程助手的效能提升普遍卡在40%左右，要突破就得把Bug排查、安全审计这些环节整个重构。知乎同期一个"为何AI编程速度远超人类，但程序员效率只提升了30%"的问题，浏览冲到8.3万，里面的解释就一句话——AI把活儿推到了你审不过来的环节。哔哩哔哩知乎
二、同期爆火的药方：规范驱动开发
市场很快给出了药方，而且这波来得相当密集。
9月22日，吴恩达的DeepLearning.AI联合JetBrains上线新课《Spec-Driven Development with Coding Agents》（借助代码智能体实现规范驱动开发），讲师是JetBrains布道师Paul Everitt。课程主张很直接：vibe coding上手快，但生成的代码经常和需求对不上；更自律的做法是先写一份清晰的Markdown规范，再让编码智能体照着实现。B站马上出现多个搬运版本，其中一个拿了1291赞、1248收藏，标题就叫"Vibe Coding该升级了"。哔哩哔哩
工具端同步升温。10月6日，"OpenSpec最近火了，规范驱动开发是AI编程的未来吗"这个问题在知乎冲到16.3万浏览。OpenSpec和GitHub官方的Spec Kit，是这波被提到最多的两个名字，路线差别其实很大：知乎
OpenSpec：定位是轻量规范层，只在仓库里加一个openspec/目录，流程是Proposal（变更单）→ Apply（实施）→ Archive（归档进长期规格），理念是"fluid not rigid、built for brownfield"——专为已有老项目设计，想让"系统现在到底怎么工作"始终有一份活文档。Node.js 20.19.0以上环境，`npm install -g @fission-ai/openspec`一条命令装完，MIT协议。一个容易忽略的细节：它默认开启匿名遥测，介意的话要用config手动关掉。知乎
Spec Kit：GitHub官方套件，主张"规范可执行"——规范不只引导实现，还直接生成实现，强调组织级治理，用constitution文件定义安全、测试、架构这些组织级准则。Python 3.11以上，`uv tool install specify-cli`安装，更适合0→1的完整交付。
两者目录不冲突（.specify/对openspec/），可以在同一仓库共存：用Spec Kit做新功能从0到1的交付，项目进入维护期后切OpenSpec沉淀规格。已经有团队实践文章给出了这个组合路线。
三、先听听反对派怎么说
但就在这波热度最高的那个知乎问题里，最有信息量的回答反而在泼冷水：“我不劝你用OpenSpec，但我劝你别把它当文档。”
这位作者摆的证据很硬。有人实测AWS自家的SDD工具Kiro，让它写一个读取运动数据的简单应用，出来20个文件、1500多行代码，而这活儿人写200行就够，代码里还塞满没删干净的console.log；任务失败之后上下文直接丢，得从头再来。还有个被反复提到的词——drift（漂移）：requirements和design文档不会自动更新，代码早跑远了，规范还在原地写着。社区里"用了一个月OpenSpec"的体验帖，不少感受是"和AI来来回回十几轮，沟通时间比自己写代码还长"。知乎
不过这篇回答真正值钱的不是否定规范，而是点破了问题所在：几乎所有人把规范写成了给人读的散文，然后期待AI像读代码一样遵守它。AI确实没有义务遵守一篇散文。他的解法是把规范做成可校验的闸门——同一条规范写两版：
散文版：“禁止在Service层直接操作Mapper，必须通过Repository访问数据。”——写完两周没人记得。
可校验版：“Service层文件不得import *Mapper；触发条件：代码审查；违反后果：CI阻断，PR无法合并。”——一条正则脚本挂上CI，从此没人再犯。
原文的结论值得抄下来：AI时代规范驱动的真正形态，不是说服AI听你的话，而是在AI够不着的地方装一道道闸门。还有一条红线：AI生成的测试脚本，绝对不能自己标记"已审核"——评审状态永远由人写，否则验收标准就变成了AI自己给自己打分。知乎
开源世界甚至已经在给AI装闸门了。今年8月，Rust项目五个团队正式通过AI使用新准则：LLM可以回答问题、分析、审查，但不能用它来创造；LLM参与的贡献必须披露、打ai-assisted标签；还设了一个"熔断机制"——任意六周窗口内，如果已合并PR里超过一半是LLM创建的，所有这类PR暂停合并，直到占比降回50%以下，且至少冷却10天。背景是rust-lang/rust仓库当时积压着1281个未关闭PR：稀缺的从来不是代码，是审阅者的判断力。36氪
成本这头也得算。36氪9月报道过一项实测：即使用一模一样的模型，不同智能体框架的token消耗最多能差70倍。规范流程本身也是要吃token的，流程越重，账单越厚。36氪
四、三笔账，决定你上不上、上多重
第一笔：项目分档账。 一次性小工具（脚本、爬虫、给自己用的查询页）：别上规范，做好备份、接受"炸了就重写"的设定，重写对这类项目本来就是合理退出机制。持续迭代的side project：轻量三件套就够——一份AGENTS.md写清约束、一个验证循环、一两条挂CI的硬规则。多人协作的团队项目：没有CI闸门就别谈规范，文档写得再漂亮也只是自我安慰，先把"违反了会怎样"设计出来。
第二笔：散文还是闸门账。 每写一条规范前问自己：这条能不能变成一行检查脚本？能，就写成可校验版挂进流水线；不能，就诚实地承认它只是给人看的参考，别指望AI自觉遵守。
第三笔：验证成本账。 好消息是验证环节本身正在变便宜。Codex的Auto-review已经包含在套餐里且不消耗用量，官方说法是开着能省2%到10%的套餐额度。这是28天计划第2天交的货，76%投票的人还在喊"重置额度"，说明大家对这类周边改进的耐心有限，但白送的验证不用白不用。Claude Code这边，官方文档已经给出"run and verify your app"的技能指引，思路是让AI自己跑测试、类型检查和Linter，减少来回沟通。10月1日的2.1.287版本更新，则加了一个内置side agent「You should know」，专门盯长会话里容易漏看的细节和边角副作用。知乎哔哩哔哩知乎
五、想试的话，从三件小事开始
别一上来就重构团队流程，也别从写一份完美PRD开始：
一条可校验规范+一行CI脚本。 挑你项目里最容易被AI违反的那条规矩，写成机器可检查的形式挂上流水线。就一条，跑一周就知道这事靠不靠谱。
给agent装验证循环。 把测试、类型检查、lint的命令写进AGENTS.md或CLAUDE.md，要求它每次改完自己跑一遍再交给你。这一步把"你审不过来"的活儿，先分一半给机器。
让指令文件从失败里学习。 开源工具backpass的思路挺超前：读取本地agent会话记录，挖掘反复出现的失败模式，给出有证据支持的指令文件修改建议，最后留人工审核——相当于把AGENTS.md当成一组可以持续训练的权重，而不是写完就吃灰的 README。哔哩哔哩
最后留三个观察信号：OpenSpec官方会不会正面解决drift问题；Rust那个"熔断机制"会不会真的被触发一次；Auto-review这类免费验证功能会不会成为各家套餐标配。
那篇"分水岭变成读得懂"的知乎文章结尾有句话，适合所有正在还债的人收藏：同样拿到"写代码变便宜"这份红利，有人拿去写新的，有人拿去读旧的——前者的系统每换一次技术就重开一次，后者的系统一直在进步。规范驱动开发的本质，不是让AI写得更规矩，而是把省下来的生成成本，拿回一部分投给"读得懂"。知乎
