Andrej发明"氛围编程"3个月后，19%开发者反而更慢了

2025年初，Andrej Karpathy把一句话丢进技术圈："vibe coding（氛围编程）"——对着AI打几个字，它出啥你用啥，完事。当时像给所有人发了把枪，觉得 coding 的门槛终于要被踏平了。三个月后数据回来：用AI工具的资深开发者，在真实代码库里的效率反而掉了19%，AI联名的PR（Pull Request，代码合并请求）重大问题多了1.7倍。按键更快了，软件更烂了。

模型一直在进化，但生成质量提升解决不了意图错位，也拦不住后续设计决策的连锁崩塌。这就是autospec要切的问题。

「氛围编程」的甜蜜陷阱

Karpathy的提法戳中了痛点。以前写代码要查文档、搭环境、debug到半夜，现在Claude、GPT、Gemini能直接吐出一整段能跑的逻辑。对新手尤其诱人——不用懂底层，不用理架构，prompt（提示词）写对就能出活。

但"能跑"和"该这么跑"是两件事。你敲下"add user auth（添加用户认证）"，模型开始猜：OAuth还是邮箱密码？Session还是JWT（JSON Web Token，一种令牌格式）？中间件放哪？错误返回什么格式？它猜完就写，你写完才发现猜错了。这就是misalignment（意图错位）——模型从没真正拥有你的意图，再聪明也白搭。

更麻烦的是连锁反应。一个错位的地基上，每一层后续决策都在放大偏差。等到测试崩了、安全审计挂了、用户数据泄露了，你回头找根因，发现源头只是当初那个prompt太模糊。

数据不会骗人。19%的效率下滑发生在"资深开发者"身上，恰恰说明问题不是AI不够强，是人机协作的接口设计错了。氛围编程把工程师变成审核员，而审核比亲手写更耗认知——你得先理解AI为什么这样写，才能判断它对不对。

spec驱动：从"猜你想写"到"先对齐再动手"

autospec的解法是把流程倒过来：spec（规格说明书）→ plan（计划）→ tasks（任务）→ implement（实现）。不是直接跳代码，第一步先生成spec.yaml——一个结构化产物，包含需求、验收标准、边界情况、约束条件，全部由你项目的constitution.yaml（项目宪法）塑形。

constitution.yaml是什么？项目的"非 negotiable（可谈判）"规则——质量标准、架构约束、安全要求，带明确的优先级和强制执行机制。autospec会从你的代码库推断初始原则（Makefile目标、CI配置、README），你再手工精修。此后每个命令都在这些约束下运行。

spec.yaml生成后，你可以手工编辑，也可以用autospec clarify开启交互会话，和AI一起精修范围、消除歧义、收紧需求，直到spec真正捕获你的意图。这时候才进入规划和实现，把对齐状态一路传递下去。

一个典型的constitution.yaml长这样：

preamble（序言）里写明项目定位；principles（原则）列表里，每条有ID、优先级（NON-NEGOTIABLE/MUST/SHOULD）、描述、执行机制、例外情况。比如"测试先行"是NON-NEGOTIABLE（不可谈判），CI流水线强制执行，除非显式标记为原型代码。

这不是文档洁癖。优先级标签直接决定AI的决策权重——当两个原则冲突时，NON-NEGOTIABLE压倒一切。你不需要在每次prompt里重复"记得写测试"，constitution已经内嵌进工作流。

autospec的运作细节

autospec本身是一个Go写的CLI（命令行工具），编排Claude Code和/或OpenCode agent（智能体）。核心命令就几条：

autospec init——扫描现有代码库，生成初始constitution和目录结构。它会读你的Makefile、CI配置、依赖文件，推断技术栈和既有约定。

autospec spec——从自然语言需求生成spec.yaml。这里的关键是"结构化"：不是直接出代码，而是出一份人可读、机器可解析的规格，包含背景、目标、非目标、验收标准、边界情况、依赖项。

autospec clarify——交互式精修spec。AI会针对模糊点提问，你回答后它更新文档，循环直到双方满意。这一步解决的是"你以为你说明白了"的问题。

autospec plan——spec定稿后，拆解成可执行的任务列表，带依赖关系和验收条件。

autospec implement——实际编码阶段，AI agent在constitution约束下逐任务实现，每步可验证。

整个流程的咬合点是：spec作为单一事实源，plan和implement只负责执行，不参与意图解释。意图的解释权完全留在人类这边，通过spec.yaml和constitution.yaml显式固化。

对比：两种工作流的认知负荷

氛围编程的认知模型是"说→看→改"。你说"加用户认证"，AI出代码，你发现不对再改prompt，循环。每次迭代都在重新建立上下文，模型对"为什么上次错了"只有隐式记忆，没有显式追踪。

spec驱动的认知模型是"说→澄清→固化→执行"。前期投入更高，但spec一旦定稿，后续阶段是纯粹的执行问题。plan阶段拆任务时，AI不需要再猜"用户要的是哪种认证"，它只读spec.yaml里的"采用JWT、无状态、支持刷新令牌"。

这种区分对团队尤其重要。个人开发者可以靠短期记忆维持上下文，但多人协作时，"为什么这样设计"必须外化为文档。spec.yaml就是那份可版本控制、可diff、可review的设计意图。

autospec的开源仓库里有个细节：spec.yaml的schema（模式）被设计为可扩展。你可以为特定领域添加字段——比如机器学习项目加"数据隐私合规检查"，金融项目加"审计日志要求"。constitution同理，支持自定义enforcement mechanism（执行机制）。这不是一个封闭的最佳实践清单，而是一个元框架，让团队把自己的约束编码进去。

谁该用，谁还不该用

项目维护者在README里写得很直白：autospec是给"professional（专业开发者）"的。如果你还在学Go的goroutine怎么用，或者第一次搭Web服务，这个工具会增加而非减少摩擦。spec驱动的前提是你知道"好"长什么样，能把质量标准写成可执行的规则。

但对已经踩过坑的团队，autospec解决的是规模化问题。当代码库超过10万行、贡献者超过10人、CI流水线超过5条时，"氛围"就是债务。每个新功能都需要和既有架构对齐，每个PR都需要符合安全基线，这些检查自动化不了，但可以用constitution和spec结构化。

一个值得观察的指标：autospec的issue列表里，关于"AI生成spec质量不够高"的反馈很少，大部分讨论集中在"如何让constitution更好地继承现有代码库的隐式约定"。这说明工具的定位被理解了——它不替你做设计决策，只确保你的决策被忠实执行。

最后留个开放问题：当你的团队开始用AI写代码，你们是把"审核AI产出"当成新工种，还是愿意前期多花30%时间把意图写清楚？两种选择没有绝对对错，但19%的效率数据和1.7倍的问题率已经摆在那了——你选哪边？