在AI编程工具如Claude Code和Codex日益普及的当下，Spec Coding的价值正被重新审视。本文深入探讨Vibe Coding与Spec Coding的边界，揭示AI自动生成代码背后隐藏的陷阱，以及如何通过规范化的需求文档为Agent Loop设置清晰的收敛条件。从探索到交付，看Spec如何成为AI时代编程不可替代的护栏。
最近经常听到一个疑问：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的核心价值，是快。 你可以直接对AI说：
帮我做一个像 Linear 一样顺滑的笔记应用，支持标签、搜索和快捷键。
几分钟后，你可能已经看到一个原型。界面不一定精细，代码不一定干净，但它能帮你判断方向：交互是否顺，功能组合是否成立，产品感觉是否已经出来。
这对AI PM和独立开发者都很有价值。很多产品判断靠文档想不清楚，需要先看到一个东西。看到之后，你才知道哪里要保留，哪里要删掉，哪里根本没必要继续。Vibe Coding的风险，也来自这种自由度。
自然语言给AI留了很大的发挥空间。你想做 MVP，它可能写成复杂系统；你只是想验证交互，它可能开始设计数据库；你想要轻量搜索，它可能直接上全文索引。 这类偏差不一定来自模型能力不足。更常见的原因是：任务边界没有写进系统。
Spec Coding解决的是另一类问题。它把“感觉”转成可以执行的规则：目标是什么，非目标是什么，哪些状态必须覆盖，哪些边界不能漏，最后怎样算通过。Vibe负责把路探出来，Spec负责把能走的路标清楚。
探索先把路线打开，约束再把路线收紧。少了任何一边，结果都容易出问题：要么一开始就写死，要么原型很难交付。
WebCoding是观察Vibe和Spec差异的好场景。 因为一个Vibe功能看起来完成，往往只是第一层完成。 比如让AI做一个搜索功能。Vibe Coding很可能很快生成输入框、列表过滤和一个漂亮的空状态。你在浏览器里试一下，确实能搜。
但真正要上线，还要继续看这些细节：
这些问题没有写清楚，AI可能会凭经验补。补得顺眼，不代表补得正确。Vibe功能的麻烦就在这里：用户看到的是页面，系统要负责的是状态和规则。Vibe Coding很适合把页面感觉跑出来，Spec Coding则负责把状态、边界和验收条件写清楚。
一个更像 Spec 的搜索需求，可以这样写：
实现笔记搜索。
搜索范围包括标题和正文。
大小写不敏感。
输入 300ms debounce。
空关键词显示全部笔记。
无结果显示空状态。
搜索结果保持当前排序。
测试覆盖空关键词、大小写、无结果、正文匹配。
有了这些规则，AI接到的任务就从泛泛的“做一个搜索框”，变成了一组需要逐条满足的约束。后续的代码、测试和验收，也能对上同一张清单。
很多人一听Spec，会想到厚厚的需求文档。放到AI Coding里，Spec可以轻得多。 它更像一张写给自己、也写给AI的检查清单。 放到Vibe Coding里，一份Spec最好先把几件事说清楚。
第一件是功能范围。这次做什么，不做什么，要提前写出来。比如做搜索，但不做全文索引、不做搜索高亮、不做云端同步。
第二件是交互和状态。Vibe页面不是静态截图，输入、加载、空结果、错误提示、禁用状态、响应式布局都会影响体验。Vibe Coding很容易把默认状态画出来，Spec要把边界状态也拉进来。
第三件是数据。前端从哪里拿数据，字段是什么，排序规则是什么，缓存和刷新怎么处理，这些都会影响功能是否稳定。 第四件是验收。截图、测试、手动清单、浏览器验证都可以放进来。AI可以写代码，也可以照着这些标准做自查。
所以Spec Coding的重点不在文档长度。它要解决的是另一件事：把模糊要求翻译成AI可以执行、可以验证的规则。
Vibe Coding容易让人误以为，一次生成就能完成任务。 轻量任务可以这样做。到了真实Coding场景，一次生成很快会碰到上限。
写代码要读项目上下文，理解已有约束，修改文件，运行测试，读取报错，再继续修复。模型第一次生成的结果，通常只能算候选答案。后面的检查、反馈和修正，才让它接近可用状态。
输入→生成→检查→反馈→再生成
检查、反馈和标准要放在一起看。检查负责判断当前结果，反馈给下一轮提供方向，标准决定循环该不该停。这三件事少一项，Loop就会退回“生成一次，听天由命”的状态。Spec在这里承担的角色，就是把“标准”放进循环。 它让AI知道自己在向什么结果靠近，也让人知道该从哪里验收。
LLM Loop主要发生在推理层。Agent Loop更进一步，把模型接到文件系统、终端、测试框架、浏览器和外部工具上。 这时AI已经进入行动层。 能改代码、读文件、跑命令、检查结果，并根据结果继续下一步，这是Agent和普通 Chatbot 的差别。
行动能力带来效率，也带来风险。读写文件和调用工具让Agent真正进入开发环境，也把误改、误调用和错误方向上的持续推进带了进来。 所以Agent Loop一定需要边界。
以 RooCode 这类AI Coding工具为例，模型通常不会毫无限制地行动。工具调用需要结构化描述，高权限操作需要用户审批，任务会被拆进一轮轮请求里。审批点、工具 schema、上下文组装，都在给Agent Loop加护栏。
Spec在Agent Loop里的作用，比在普通需求文档里更具体。 它会影响模型每一轮看到什么上下文，可以调用哪些工具，哪些操作需要人工确认，失败以后怎么回退，最终怎样算完成。 换句话说，Spec是Agent Loop的收敛条件。
Spec写得越清楚，Agent越知道目标、边界和停止条件；写得太虚，循环只会更卖力地跑偏。
一个常见误解是：Agent可以自己跑Loop，人就可以离场。 实际情况没这么简单。AI可以接管内层循环，比如写代码、跑测试、看报错、修复、再测试。这个部分越明确，越适合自动化。 外层循环仍然需要人。
功能取舍、体验判断、边界收紧、成本上限和上线风险，这些判断不能完全交给 LLM。 LLM 不掌握你的产品阶段、用户画像、业务风险和团队约束。它可以分析，可以建议，可以执行，最后的取舍仍然要由人来定。 对AI PM来说，角色没有消失，只是前移了。
过去 PM 更多写需求、排优先级、和研发对齐。现在 PM 还需要理解一个Agent系统怎么工作：哪里需要Spec，哪里可以自动跑，哪里必须人工审批，哪里要设置成本上限，哪里要暴露可观测指标。 你不一定要写底层代码，但要看得懂Loop结构。
Vibe Coding和Spec Coding放在一起，最合理的方式是一条闭环：
ßßVibe探索→Spec固化→Code 实现→Verify 验收→Vibe打磨
这里的Vibe指探索阶段，不等于靠感觉一路把功能写完：先让AI帮你试方向、出原型、找产品感觉。
在这条链路里，Vibe先帮你看到可能性，Spec把判断标准固定下来，Code 阶段让Agent按规则实现，Verify 再把结果拉回目标上。体验里冒出来的新问题，会进入下一轮Vibe或Spec。 比如你想做一个笔记应用的搜索功能。
先不要写代码。 帮我探索 3 种搜索方案，说明交互体验、技术复杂度和适合 MVP 的选择。 这一步的目标是看清选择。
只做标题和正文搜索。 不做全文索引。 不做搜索高亮。 需要覆盖空关键词、大小写、无结果、正文匹配几个边界。 然后让Agent按Spec实现。实现过程中，它可以自己跑测试、读报错、修复问题。最后再对照Spec做验收。
体验上发现新问题，比如输入反馈不够顺，移动端太挤，结果排序不符合直觉，这些反馈会进入下一轮Vibe，再更新下一版Spec。 这个过程更接近：
感觉→规则→实现→验证→新感觉→新规则
不同Agent产品，Loop的形态会很不一样。 RooCode 这类交互式AI Coding工具，更强调单任务、串行推进和用户审批。它适合在开发者旁边工作：你给它目标，它一轮轮执行，遇到关键工具调用时让你确认。 这种设计的重点是可控。
更高级的形态里，一个人可能同时调度几十个甚至上百个Agent，让它们分别处理不同任务。每个Agent都在自己的循环里运行，有自己的目标、频次和完成标准。 这种设计的重点是规模。
两种形态对应不同场景。交互式编程更需要安全边界和随时接管。规模化自动化更需要任务拆分、状态管理和调度能力。
单个Agent辅助一个任务→多个Agent并行处理任务→Agent系统自动调度和优化任务
越往后走，Spec越重要。规模一旦变大，靠人盯每一步就不现实了。目标、权限、退出条件、观察指标，都要被写进系统。
很多AI产品讨论，最后都会落到模型选择：用 GPT、Claude，还是别的模型。 模型当然重要，但它无法覆盖全部产品问题。 当模型能力越来越强，产品差异会更多体现在Loop设计上。
一个AI Coding产品好不好用，取决于它是否能稳定完成这些事：准确召回上下文，合理拆解任务，控制工具权限，处理失败路径，记录每轮变化，在关键节点让人接管。 这已经不只是“会不会写需求”的问题了，它会直接影响产品怎么跑起来。
所以AI PM要开始关心一些以前看起来偏技术的东西：
这些问题会直接影响用户体验。 最大轮次太低，Agent可能还没修好就停了；轮次太高，用户等待时间和账单都会上升。审批点太多，体验会被打断；审批点太少，又容易出风险。AI PM不需要把技术细节都背下来。真正要理解的是，这些技术选择会带来什么产品代价。
一个看不见的Loop，很难优化。你需要知道AI每次迭代做了什么，为什么这么做，花了多少 Token，调用了哪些工具，失败在哪里，最后为什么停下来。 这些信息可以服务工程 debug，也可以成为产品指标。
迭代轮次能提示任务复杂度，Token 消耗会暴露成本压力，工具失败率反映系统稳定性。人工介入次数和验收通过率也很有用，前者说明自动化边界在哪里，后者能反推Spec是否足够清楚。 如果这些数据长期记录下来，PM 就能看到真正的问题在哪里。
这些数据看久了，问题会更具体：功能卡住，可能是Spec太模糊；任务失败，可能是上下文没给全；体验变慢，可能是审批点设计得太碎。 有了这些记录，Spec就不用只靠感觉改。哪些规则没写清楚，哪些边界反复出错，哪些审批点拖慢了用户，数据里会慢慢露出来。
不用一开始就做复杂的多Agent系统。 可以先从一个 Web 功能开始。
比如笔记搜索：
背景：用户笔记变多后，需要快速通过关键词找到笔记。 目标：实现标题和正文搜索。 非目标：不做全文索引，不做云端同步，不做搜索高亮。 行为规则：输入 300ms debounce，大小写不敏感，空关键词显示全部笔记。 边界情况：无结果显示空状态，搜索结果保持当前排序。 验收标准：覆盖空关键词、大小写、无结果、正文匹配。
这份Spec不复杂，但足够让AI少走很多弯路。 它也方便 Verify。实现完成后，你可以让AI对照每一条检查：哪些满足了，哪些没满足，哪里需要补测试。
AI Coding的下一阶段，当然会继续受益于更强的模型和更快的生成速度。 但产品层真正拉开差距的地方，会是把自由生成带到可靠交付上的能力。
一套完整的AI Coding工作流，需要把几件事接起来：Vibe Coding让用户快速表达想法，Spec Coding把想法翻译成边界和验收标准，LLM Loop负责在反馈中修正，Agent Loop把模型接到工具和真实环境，Verify 再把结果拉回可判断的标准上。
未来Spec也可能不完全由人手写。Agent可以根据失败模式自动补充规则，根据历史任务生成验收标准，根据用户反馈调整下一轮约束。 即使到了那一步，人也不会从系统里消失。
人的价值会更集中在几个地方：方向怎么定，取舍怎么做，哪里要看得见，哪些风险不能放给Agent自己处理。 所以下次使用AI Coding工具时，不要只看它写代码有多快。 更值得观察的是：它的Vibe在哪里，Spec在哪里，Agent Loop又是怎么被约束和验证的。
这些问题看起来细，但会越来越影响一个AI Coding产品到底好不好用。
本文由 @Mayrian 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。