Spec Coding 过时了吗？我觉得它刚开始重要

最近经常听到一个疑问：Claude Code、Codex 这样的Agent编程工具已经能自动化写代码了，Spec Coding会不会已经过时了？

以前写代码慢，大家自然会重视需求、设计和评审。现在一句话丢给Agent，它能读文件、改代码、跑测试、看报错，再继续修。代码生成突然变得很便宜，Spec好像就显得有点“重”。

但真正踩过几次坑后，你就会发现AI写不出来，反而没那么可怕。

更麻烦的是：它写出来了，看起来也能跑，但你说不清它到底有没有做对。

一个没有Spec的AI CodingAgent，本质上像一个缺少退出条件的 while loop。

它会不断生成代码、调用工具、读取报错、继续修复。表面看很勤奋，甚至很聪明。可一旦目标、边界和验收标准不清楚，你很难判断它什么时候该停，也很难判断它停下来的结果是否真的可用。

这就是Spec Coding在AI Coding时代重新变关键的原因。Vibe Coding让AI Coding的启动成本降到了很低。你用自然语言描述一个想法，AI很快就能给你一版能跑的东西。这个过程很适合探索，也很容易带来惊喜。

问题出在下一步，能跑的原型，离可交付的功能还有一段距离。

尤其在Vibe Coding和Agent Loop里，AI生成的代码通常要处理状态、权限、接口、测试、错误恢复和人工审批。缺少Spec，这些东西很容易被AI按自己的理解补齐，也很容易补错。

这篇文章先把两件事拆开：Vibe Coding适合做什么，Spec Coding适合做什么。然后再看Spec Coding放进Vibe Coding和Agent Loop之后，具体会改变哪些环节。

一、Vibe Coding 适合探索，Spec Coding 适合交付

Vibe Coding的核心价值，是快。 你可以直接对AI说：

帮我做一个像 Linear 一样顺滑的笔记应用，支持标签、搜索和快捷键。

几分钟后，你可能已经看到一个原型。界面不一定精细，代码不一定干净，但它能帮你判断方向：交互是否顺，功能组合是否成立，产品感觉是否已经出来。

这对AI PM和独立开发者都很有价值。很多产品判断靠文档想不清楚，需要先看到一个东西。看到之后，你才知道哪里要保留，哪里要删掉，哪里根本没必要继续。Vibe Coding的风险，也来自这种自由度。

自然语言给AI留了很大的发挥空间。你想做 MVP，它可能写成复杂系统；你只是想验证交互，它可能开始设计数据库；你想要轻量搜索，它可能直接上全文索引。 这类偏差不一定来自模型能力不足。更常见的原因是：任务边界没有写进系统。

Spec Coding解决的是另一类问题。它把“感觉”转成可以执行的规则：目标是什么，非目标是什么，哪些状态必须覆盖，哪些边界不能漏，最后怎样算通过。Vibe负责把路探出来，Spec负责把能走的路标清楚。

探索先把路线打开，约束再把路线收紧。少了任何一边，结果都容易出问题：要么一开始就写死，要么原型很难交付。

二、Vibe Coding 最能暴露两者差异

WebCoding是观察Vibe和Spec差异的好场景。 因为一个Vibe功能看起来完成，往往只是第一层完成。 比如让AI做一个搜索功能。Vibe Coding很可能很快生成输入框、列表过滤和一个漂亮的空状态。你在浏览器里试一下，确实能搜。

但真正要上线，还要继续看这些细节：

• 空关键词显示什么
• 大小写是否敏感
• 搜索范围包括标题、正文，还是标签
• 输入是否需要 debounce
• 无结果时显示什么
• 搜索结果是否保持原排序
• loading、empty、error 状态是否完整
• 移动端输入框和列表是否会挤在一起
• 测试覆盖哪些边界

这些问题没有写清楚，AI可能会凭经验补。补得顺眼，不代表补得正确。Vibe功能的麻烦就在这里：用户看到的是页面，系统要负责的是状态和规则。Vibe Coding很适合把页面感觉跑出来，Spec Coding则负责把状态、边界和验收条件写清楚。

一个更像 Spec 的搜索需求，可以这样写：

实现笔记搜索。

搜索范围包括标题和正文。

大小写不敏感。

输入 300ms debounce。

空关键词显示全部笔记。

无结果显示空状态。

搜索结果保持当前排序。

测试覆盖空关键词、大小写、无结果、正文匹配。

有了这些规则，AI接到的任务就从泛泛的“做一个搜索框”，变成了一组需要逐条满足的约束。后续的代码、测试和验收，也能对上同一张清单。

三、Spec 在 Vibe Coding 里约束什么

很多人一听Spec，会想到厚厚的需求文档。放到AI Coding里，Spec可以轻得多。 它更像一张写给自己、也写给AI的检查清单。 放到Vibe Coding里，一份Spec最好先把几件事说清楚。

第一件是功能范围。这次做什么，不做什么，要提前写出来。比如做搜索，但不做全文索引、不做搜索高亮、不做云端同步。

第二件是交互和状态。Vibe页面不是静态截图，输入、加载、空结果、错误提示、禁用状态、响应式布局都会影响体验。Vibe Coding很容易把默认状态画出来，Spec要把边界状态也拉进来。

第三件是数据。前端从哪里拿数据，字段是什么，排序规则是什么，缓存和刷新怎么处理，这些都会影响功能是否稳定。 第四件是验收。截图、测试、手动清单、浏览器验证都可以放进来。AI可以写代码，也可以照着这些标准做自查。

所以Spec Coding的重点不在文档长度。它要解决的是另一件事：把模糊要求翻译成AI可以执行、可以验证的规则。

四、LLM Loop 解释了为什么一次生成不够

Vibe Coding容易让人误以为，一次生成就能完成任务。 轻量任务可以这样做。到了真实Coding场景，一次生成很快会碰到上限。

写代码要读项目上下文，理解已有约束，修改文件，运行测试，读取报错，再继续修复。模型第一次生成的结果，通常只能算候选答案。后面的检查、反馈和修正，才让它接近可用状态。

这就是 LLM Loop 的基本结构

输入→生成→检查→反馈→再生成

检查、反馈和标准要放在一起看。检查负责判断当前结果，反馈给下一轮提供方向，标准决定循环该不该停。这三件事少一项，Loop就会退回“生成一次，听天由命”的状态。Spec在这里承担的角色，就是把“标准”放进循环。 它让AI知道自己在向什么结果靠近，也让人知道该从哪里验收。

五、Agent Loop 让 Spec 更重要

LLM Loop主要发生在推理层。Agent Loop更进一步，把模型接到文件系统、终端、测试框架、浏览器和外部工具上。 这时AI已经进入行动层。 能改代码、读文件、跑命令、检查结果，并根据结果继续下一步，这是Agent和普通 Chatbot 的差别。

行动能力带来效率，也带来风险。读写文件和调用工具让Agent真正进入开发环境，也把误改、误调用和错误方向上的持续推进带了进来。 所以Agent Loop一定需要边界。

以 RooCode 这类AI Coding工具为例，模型通常不会毫无限制地行动。工具调用需要结构化描述，高权限操作需要用户审批，任务会被拆进一轮轮请求里。审批点、工具 schema、上下文组装，都在给Agent Loop加护栏。

Spec在Agent Loop里的作用，比在普通需求文档里更具体。 它会影响模型每一轮看到什么上下文，可以调用哪些工具，哪些操作需要人工确认，失败以后怎么回退，最终怎样算完成。 换句话说，Spec是Agent Loop的收敛条件。

Spec写得越清楚，Agent越知道目标、边界和停止条件；写得太虚，循环只会更卖力地跑偏。

六、人在 Loop 里没有消失

一个常见误解是：Agent可以自己跑Loop，人就可以离场。 实际情况没这么简单。AI可以接管内层循环，比如写代码、跑测试、看报错、修复、再测试。这个部分越明确，越适合自动化。 外层循环仍然需要人。

功能取舍、体验判断、边界收紧、成本上限和上线风险，这些判断不能完全交给 LLM。 LLM 不掌握你的产品阶段、用户画像、业务风险和团队约束。它可以分析，可以建议，可以执行，最后的取舍仍然要由人来定。 对AI PM来说，角色没有消失，只是前移了。

过去 PM 更多写需求、排优先级、和研发对齐。现在 PM 还需要理解一个Agent系统怎么工作：哪里需要Spec，哪里可以自动跑，哪里必须人工审批，哪里要设置成本上限，哪里要暴露可观测指标。 你不一定要写底层代码，但要看得懂Loop结构。

七、Vibe 和 Spec 应该形成闭环

Vibe Coding和Spec Coding放在一起，最合理的方式是一条闭环：

ßßVibe探索→Spec固化→Code 实现→Verify 验收→Vibe打磨

这里的Vibe指探索阶段，不等于靠感觉一路把功能写完：先让AI帮你试方向、出原型、找产品感觉。

在这条链路里，Vibe先帮你看到可能性，Spec把判断标准固定下来，Code 阶段让Agent按规则实现，Verify 再把结果拉回目标上。体验里冒出来的新问题，会进入下一轮Vibe或Spec。 比如你想做一个笔记应用的搜索功能。

一开始可以先 Vibe

先不要写代码。 帮我探索 3 种搜索方案，说明交互体验、技术复杂度和适合 MVP 的选择。 这一步的目标是看清选择。

等方向清楚后，再整理 Spec

只做标题和正文搜索。 不做全文索引。 不做搜索高亮。 需要覆盖空关键词、大小写、无结果、正文匹配几个边界。 然后让Agent按Spec实现。实现过程中，它可以自己跑测试、读报错、修复问题。最后再对照Spec做验收。

体验上发现新问题，比如输入反馈不够顺，移动端太挤，结果排序不符合直觉，这些反馈会进入下一轮Vibe，再更新下一版Spec。 这个过程更接近：

感觉→规则→实现→验证→新感觉→新规则

八、串行审批和并行 Agent，对 Spec 的要求不同

不同Agent产品，Loop的形态会很不一样。 RooCode 这类交互式AI Coding工具，更强调单任务、串行推进和用户审批。它适合在开发者旁边工作：你给它目标，它一轮轮执行，遇到关键工具调用时让你确认。 这种设计的重点是可控。

更高级的形态里，一个人可能同时调度几十个甚至上百个Agent，让它们分别处理不同任务。每个Agent都在自己的循环里运行，有自己的目标、频次和完成标准。 这种设计的重点是规模。

两种形态对应不同场景。交互式编程更需要安全边界和随时接管。规模化自动化更需要任务拆分、状态管理和调度能力。

从产品设计角度看，这是一条谱系

单个Agent辅助一个任务→多个Agent并行处理任务→Agent系统自动调度和优化任务

越往后走，Spec越重要。规模一旦变大，靠人盯每一步就不现实了。目标、权限、退出条件、观察指标，都要被写进系统。

九、AI PM 要把需求写得更可执行

很多AI产品讨论，最后都会落到模型选择：用 GPT、Claude，还是别的模型。 模型当然重要，但它无法覆盖全部产品问题。 当模型能力越来越强，产品差异会更多体现在Loop设计上。

一个AI Coding产品好不好用，取决于它是否能稳定完成这些事：准确召回上下文，合理拆解任务，控制工具权限，处理失败路径，记录每轮变化，在关键节点让人接管。 这已经不只是“会不会写需求”的问题了，它会直接影响产品怎么跑起来。

所以AI PM要开始关心一些以前看起来偏技术的东西：

• Spec放在哪里
• State 记录什么
• 工具权限怎么分层
• 最大迭代轮次是多少
• Token 成本怎么控制
• 失败后是重试、降级，还是交给人
• 用户是否看得懂Agent当前在做什么

这些问题会直接影响用户体验。 最大轮次太低，Agent可能还没修好就停了；轮次太高，用户等待时间和账单都会上升。审批点太多，体验会被打断；审批点太少，又容易出风险。AI PM不需要把技术细节都背下来。真正要理解的是，这些技术选择会带来什么产品代价。

十、可观测性是 Spec 的反馈来源

一个看不见的Loop，很难优化。你需要知道AI每次迭代做了什么，为什么这么做，花了多少 Token，调用了哪些工具，失败在哪里，最后为什么停下来。 这些信息可以服务工程 debug，也可以成为产品指标。

迭代轮次能提示任务复杂度，Token 消耗会暴露成本压力，工具失败率反映系统稳定性。人工介入次数和验收通过率也很有用，前者说明自动化边界在哪里，后者能反推Spec是否足够清楚。 如果这些数据长期记录下来，PM 就能看到真正的问题在哪里。

这些数据看久了，问题会更具体：功能卡住，可能是Spec太模糊；任务失败，可能是上下文没给全；体验变慢，可能是审批点设计得太碎。 有了这些记录，Spec就不用只靠感觉改。哪些规则没写清楚，哪些边界反复出错，哪些审批点拖慢了用户，数据里会慢慢露出来。

十一、怎么开始写一份轻量 Spec

不用一开始就做复杂的多Agent系统。 可以先从一个 Web 功能开始。

一份轻量 Spec 至少包含这些内容

• 背景：为什么要做
• 目标：这次具体解决什么问题
• 非目标：这次明确不做什么
• 行为规则：页面、状态、数据、交互怎么运转
• 边界情况：空数据、错误、权限、移动端、异常输入
• 验收标准：测试、截图、手动检查清单

比如笔记搜索：

背景：用户笔记变多后，需要快速通过关键词找到笔记。 目标：实现标题和正文搜索。 非目标：不做全文索引，不做云端同步，不做搜索高亮。 行为规则：输入 300ms debounce，大小写不敏感，空关键词显示全部笔记。 边界情况：无结果显示空状态，搜索结果保持当前排序。 验收标准：覆盖空关键词、大小写、无结果、正文匹配。

这份Spec不复杂，但足够让AI少走很多弯路。 它也方便 Verify。实现完成后，你可以让AI对照每一条检查：哪些满足了，哪些没满足，哪里需要补测试。

十二、结尾：Vibe 给速度，Spec 给边界

AI Coding的下一阶段，当然会继续受益于更强的模型和更快的生成速度。 但产品层真正拉开差距的地方，会是把自由生成带到可靠交付上的能力。

一套完整的AI Coding工作流，需要把几件事接起来：Vibe Coding让用户快速表达想法，Spec Coding把想法翻译成边界和验收标准，LLM Loop负责在反馈中修正，Agent Loop把模型接到工具和真实环境，Verify 再把结果拉回可判断的标准上。

未来Spec也可能不完全由人手写。Agent可以根据失败模式自动补充规则，根据历史任务生成验收标准，根据用户反馈调整下一轮约束。 即使到了那一步，人也不会从系统里消失。

人的价值会更集中在几个地方：方向怎么定，取舍怎么做，哪里要看得见，哪些风险不能放给Agent自己处理。 所以下次使用AI Coding工具时，不要只看它写代码有多快。 更值得观察的是：它的Vibe在哪里，Spec在哪里，Agent Loop又是怎么被约束和验证的。

这些问题看起来细，但会越来越影响一个AI Coding产品到底好不好用。