TL;DR
一句话定义：vibe coding 想到哪写到哪，靠语义直觉驱动模型补全；spec coding 先写规格、定接口和验收，再让模型按规约实现。前者原型阶段真的快，后者在三天后你还认得自己代码这事上无可替代。
长项目的分水岭只有一个问题：模型重新打开仓库时，从哪里恢复”上下文”？vibe 把上下文锁死在对话窗口里，对话一关、context 一满，理解归零；spec 把上下文沉淀进 CLAUDE.md / skill / 单测 / 任务卡，每次新开 session 读完就能接着干。1B token 以下感受不强，跨过 1B 向 3B 推进时，会变成项目能不能走下去的硬约束。
近期 linux.do 一位开发者复盘自己用 Claude Code 跑了 3B token 做家庭记账 APP，引发一轮 vibe vs spec 讨论。本文不复述他具体踩了什么坑，而是把讨论里反复出现的机制问题拆开。
一、为什么 vibe coding 在前 1000 行内是真的香
vibe coding 不是反派。它是 Claude Code 最适合的入口形态，原因有三：
- 沉没成本低：原型阶段方向 30 分钟一变，写 spec 是负收益。直接说”做个能记账并按月统计的最小 demo”，30 秒拿到能跑的版本是最优解。
- 对话即 IDE：Claude Code 是 REPL 式的——看到输出立刻反馈，模型即时改。这种节奏天然适合 vibe，不适合 spec——停下写 spec 那 10 分钟节奏就断了。
- 模型补很多你没明说的东西：默认按工程惯例补目录、错误处理、配置——LLM 编程的隐性红利。一旦写严格规约反而压制这个红利。
所以原型、临时脚本、一次性数据处理 vibe 是正确答案。问题不在 vibe 本身，问题在没人告诉你什么时候该停。参考：AI编程工具现状：从IDE到CLI，开发者如何在Cursor与Claude间抉择、开发者实测：Claude Code 效率超越 Codex，AI编程迈向”零门槛”自然交互。
vibe coding 的真实适用边界
把适用边界写明，比无脑捧或无脑黑都更有用。下面四类场景，vibe 几乎一定赢：
- 生命周期 < 1 周的脚本：写完跑一次就归档，结构再好也没人看第二遍。
- 探索性 spike：你不知道这条路通不通，先要 30 分钟内得到「能跑/不能跑」的信号。
- 样式微调与 UI 拼装：截图给模型、说”这块再宽一点、再蓝一点”——比写 design spec 高效十倍。
- 逆向理解一段陌生代码：让模型一边读一边解释，比自己硬啃快得多。
反过来，下面四类场景 vibe 几乎一定亏：跨团队接口、要长期维护的领域模型、多人协作分支频繁合并的核心模块、单测覆盖率有硬指标的合规系统。这四类一旦走 vibe，三周后必然回头补 spec，且成本 3 倍。
vibe coding 常见的上手坑
新手切到 Claude Code 后最容易踩的三个坑：
- 把”会跑”当”做完”：模型给出一个能
npm start的版本就以为做完了，没回头看异常路径、边界值、并发情况。Claude Code 给的默认实现是工程惯例的均值，不是你这个项目的最优。 - 被自动补全的目录结构带跑：模型默认补
src/services/、src/repositories/、src/dto/，看上去专业，但你这个项目可能根本不需要分层。等到第 3 个 feature 才发现层与层之间的封装是空壳，重构成本反而高。 - 过早接入外部依赖：vibe 阶段模型很容易”建议”装一个新库解决你 30 行就能写完的事。短期省事、长期是债。
避坑的方法不是不用 vibe，是给每一次 vibe 设置一个时间盒：30 分钟跑出可工作版本，下一个 30 分钟回头剪枝。
vibe coding 的收益模型
把 vibe 的收益拆成三个数量级看：
- 输出价值：30 秒拿到能跑的 demo，比手写省下 1-3 小时人力。
- token 成本：原型阶段单次任务通常 50K-200K token，按当前主流定价等于几分钱到几毛钱。
- 反复重写代价：vibe 写出的代码三周后回头改，平均要花原始开发时间的 1.5-2 倍——因为你需要先重新理解模型当初为什么这么写。
净收益公式很简单：寿命短 / 决策频繁切换 / 没有多人协作时，vibe 一定盈利。一旦三者中两条以上反过来，就该考虑 spec 了。
二、vibe coding 在长项目会塌的三种姿势
1. Context window 第一次满。Claude Code 对话上下文有限（即便 1M 版本，文件读多了一样顶满）。context 一满模型开始”忘”：刚改过的签名下一轮又用旧的；同一 bug 改两次没好；你说”按 utils helper 的风格写”，模型重写一个不一样的。常见反应是开新对话——但这意味着模型对项目的所有积累（目录、命名、踩过的坑、接口）全部清零。要么重讲一遍（极贵），要么让模型自己读代码理解（更贵，且容易错）。并非所有”性能下降”都来自 context 满，详见 解决 Claude Code 性能波动难题：用户推测降智与服务器 Session 路由强相关。
2. 重构边界第一次模糊。vibe 写到 5000 行必然遇到：某模块写得不对要重构。模型问”小修还是大改”你答不清——因为没显式定义过这模块边界。结果是：小修不彻底；大改扩散到 7 个文件 diff 失控；你说”自己改”——这时才发现过去一个月的代码已经不熟了。这是 vibe 最致命的失败模式：模型对代码的熟悉度远超过你。不是技术问题，是治理问题。
3. Token 成本第一次让你心疼。vibe 模式下每个动作模型都要重新理解整个相关文件。一个文件被读 20 次、来回 30 轮才改完一个 bug，原型阶段无所谓，1B token 后会让人算账。参考 阿里云 Token Plan 难以支撑 AI 编程，3小时消耗 50% 额度。
三、spec coding 是什么：不是 BDD 也不是文档驱动
spec coding 不是新东西，但在 LLM 语境下含义发生了关键漂移：传统 spec 是给人看的（产品/API 文档、需求规约，落地靠人）；LLM 时代的 spec 是给模型看的——告诉它任务的成功标准、约束、上下文、可调工具、该用哪些文件、不能动哪些文件，目的是让模型在你不在场时也能做出正确决策。
最接近的参考是 Andrej Karpathy 推过的 “spec-driven development”：先写一份足够具体、可验证的 spec，再让 agent 按 spec 跑循环、自检、迭代直到 spec 通过。spec 不是 doc，它是给 agent 用的检查清单 + 执行约束。理解成”写更多文档”你会很快放弃；理解成”把约束沉淀成模型读得懂的检查清单”，就是让模型替你记住事情的杠杆。类似讨论：Anthropic 发布 Claude Tag：AI 正式成为 Slack”团队队员”，支持多人异步协作。
spec coding 和 TDD / BDD / 契约编程的区别
很多老工程师听到 spec 立即条件反射”我做过 TDD / BDD / Design by Contract”。三者都强调”先定义对再实现”，但 LLM 语境的 spec 在三个维度上不同：
- 受众不同：TDD 的测试给 runtime 看、BDD 的 scenario 给 PM/QA 看、契约给调用方看；LLM spec 给模型看。措辞、粒度、抽象层完全不同——给模型看的 spec 需要明确”不能动的文件”和”必读的上下文”，传统三者都没这一条。
- 粒度不同：TDD 是函数级、BDD 是用户故事级、契约是模块边界；LLM spec 通常是任务级（一次 PR 或一次会话能完成的工作量），介于函数和故事之间。
- 生命周期不同：TDD 测试与代码同存，BDD scenario 长期维护；LLM 任务 spec 通常用完即扔，关键约束反向沉淀进
CLAUDE.md。
最容易出错的认知是把 spec coding 当”更详细的 TDD”。两者形态相似但用法不同：TDD 是 runtime 反馈循环，spec 是 prompt 时的约束注入。一个验证产物，一个引导生成。
spec coding 不等于敏捷反义词
spec coding 也不是回到瀑布。瀑布的特征是一次性、前置、整体的 spec，写完一年才进 code 阶段。LLM 时代的 spec 是每个任务前一页、可丢、随时改——粒度和敏捷的 user story 是一个量级，但产物形态不同（spec 是给模型的约束清单，story 是给团队的目标描述）。
理解这点很重要：spec coding 不会让你回到产品文档评审会，它只是让你在每次按 Enter 之前，多花 3 分钟把”想让模型做什么、不能做什么”写清楚。3 分钟换 30 分钟的返工时间，长项目里几乎稳赚。
四、在 Claude Code 里 spec coding 怎么落地
Claude Code 有几个原生抓手，按承诺成本从低到高排：
CLAUDE.md：启动时自动加载
最便宜也最容易被忽视。项目根目录的 CLAUDE.md 会在启动 Claude Code 时默认读入上下文。一个好的 CLAUDE.md 长这样：
# 项目: 家庭记账 APP
## 关键约定
- 包管理: pnpm (不要 npm/yarn); 数据库: SQLite + Drizzle (不要 Prisma)
## 已知坑
- iOS Safari input type="month" 不支持, 走自定义 picker
- Drizzle transaction 在 expo-sqlite 有 bug, 走 db.execute 手写
## 模块边界
- 数据层 src/db/* 只暴露 repositories
- UI 层不直接 import db, 必须经 hooks/use*.ts
成本一次 30 分钟，回报是接下来每次对话不用重新讲。
skill / 自定义命令：沉淀重复工作流
Claude Code 支持自定义 skill / slash command 把多步流程封装成一个调用。长项目里最值得封装的是”做过 10 遍但每次还要解释一遍”的事：「新加一个 page」「迁移一个表」「发布一个版本」。参考 开源神器 SMRmanager：一键统一管理 Claude、Cursor 等 AI 编程工具配置。
任务级 spec：每个 PR 开工前写半页
回报最高，承诺成本也最高。动手前先产出一份任务 spec：
## 任务: 月度账单按分类汇总
输入: 用户 id, 起止月份 (YYYY-MM)
输出: 数组 [{category, total, count}], 按 total 降序
边界: 跨年份支持; 软删除不计 (deleted_at IS NULL); 转账类按出账方分类
验收: 单测覆盖 跨年/无数据/仅一条/含已删除; 1 万条 < 50ms
不能动: src/db/schema.ts, src/api/v1/*
让模型按 spec 实现，结束后对照 spec 跑 self-check。出错比直接 vibe 写明显少。
verify loop：执行级的自检
Claude Code 可在每次改完代码后自动跑测试、lint、类型检查。把这些串成 pre-commit / verify 命令，每次完成任务都过一遍 loop——通不过自己改到通过。这是 Karpathy 反复强调的理念：“瓶颈是验证，不是生成”。把验证自动化，模型就能自己迭代到对。
TaskCreate / 子任务：把大任务拆给模型自己跑
Claude Code 的 TaskCreate 让模型把一个复杂任务拆成可独立完成的子任务，跑完再汇总。这是 spec coding 在执行层的延伸——主任务 spec 把”做什么”定义清，模型自己规划”分几步、每步交付什么”。配合 verify loop，每个子任务跑完都过一次检查，错了重跑，对了沉淀。
五、长项目的 context 管理：四种应对窗口满
context 管理是 vibe 与 spec 分水岭最直接的体现。当对话窗口逼近上限，你只有四种选择：
选择一：精炼当前对话
让模型自己生成一份”当前任务的状态摘要”——已完成步骤、未完成步骤、关键决策、遇到的坑——压缩到 1-2 千字。然后用这份摘要重启会话。优点是几乎不丢上下文；缺点是摘要本身要再消耗一轮上下文，且不能反复用——压缩两次三次后细节就开始失真。
选择二：把通用约定拆进 skill / CLAUDE.md
如果发现某段上下文反复出现在多个会话里（比如某个数据库表结构、某个 API 接口约定），就该把它从对话里搬出去，沉淀到 CLAUDE.md 或独立 skill 文件。一次性投资，永久减负。这才是 spec coding 真正的杠杆点——不是写更多文档，而是把会话里的临时上下文蒸馏成可复用资产。
选择三：用 plan 模式先规划再执行
Claude Code 的 plan 模式（或类似的”先列计划”策略）能显著减少跑偏。模型先把要做的事列成步骤，你审一遍，再让它按步骤执行。优点：你能在执行前发现方向错；缺点：plan 本身要消耗一轮上下文，简单任务用 plan 是浪费。
选择四：重启会话 + 精确喂关键摘要
最后的手段。把当前会话的关键状态写到一个 markdown 文件，关掉对话，新开一个会话，第一条消息就是 请读 docs/sessions/2026-06-24-handover.md，我们继续。看似笨，但实际上是最稳的——新会话从零开始，模型对前面的”上下文污染”完全不知道。延伸阅读：Claude Code订阅限制曝光：Sonnet 4.6的1M上下文并非全员可用、为 Claude Code 打造桌面端：开发者用 Flutter + Rust 封装新交互界面。
CLAUDE.md 的层级与分裂
一个项目的 CLAUDE.md 不能无限膨胀。超过 300 行后模型读完就快用掉一轮注意力。推荐做法：主 CLAUDE.md 只放最关键的项目级约定，剩下的拆成子文档按需引用。比如：
- 根目录
CLAUDE.md只放”项目是什么、用什么栈、最关键的 3-5 条红线”。 docs/ad-slot-system.md、docs/banner-generation.md这类专题手册由主CLAUDE.md指明”涉及 X 时必读”。- 模块级目录可以放
<module>/CLAUDE.md仅在工作于该模块时加载。
这种”主索引 + 按需加载”模式，比一个 800 行的扁平 CLAUDE.md 高效得多。
跨会话状态如何持久化
会话本身不持久。要让”这周改过的关键决策”在下周新会话里还能被模型读到，只有三条路：写进 CLAUDE.md、写进代码注释（让模型读代码时自然带入）、写进 ADR（Architecture Decision Record）。三条路各有适用：
- CLAUDE.md 适合短期约定（这两周用的临时方案）。
- 代码注释 适合永久性的、和代码强耦合的设计决策。
- ADR 适合大架构层面、需要”为什么这么选”的长期决策。
只有这三个地方的信息，下周新会话才一定能被模型恢复。聊天记录、screenshots、口头约定——这些都是临时上下文，会话一关就丢。
六、token 成本控制：定性模型与可操作动作
token 成本不需要数字精确到分，需要的是定性的漂移模型——哪些动作会让 token 几何级增长，哪些动作能压下来。
token 漂移的四个放大器
- 重复读同一组文件：vibe 模式下模型反复 Read 同一文件理解上下文，每读一次都是一次完整文件 token 消耗。
- 错误返工：模型生成错了，你说”再来一遍”，错误的 token 已经付过、新一轮还要再付一次。
- 长会话堆积：会话越长，每一轮新消息都要带前面所有内容当作上下文，单轮成本越走越高。
- 过度详细的输出：让模型”详细解释”是 token 消耗最快的方式。需要简洁就明确要求简洁。
五个可操作的压缩动作
CLAUDE.md替代重复解释：长期约定不靠每次会话重讲。- Read 选择性使用：只让模型读真正相关的文件，而不是”先扫一遍整个项目”。100K 无关代码和 100K 相关代码的 token 成本是一样的。
- 会话短开短关：单个任务一个会话，跑完就关。不要堆积”项目主会话”——那是 token 黑洞。
- 让 subagent 干脏活：复杂的搜索、比对、大文件分析交给 subagent，主会话只接收结果摘要。这是 Claude Code 最被低估的省 token 技巧。
- 明确要求简洁输出：在 prompt 或
CLAUDE.md写”回答简洁，不要重复用户问题，不要总结性段落”。
什么时候付费值，什么时候要刹车
值得付的 token：探索性方案、关键决策前的多方案对比、大型重构前的影响面分析、复杂 bug 的根因追踪。这些 token 换回的是认知，认知的边际收益远高于代码本身。
要刹车的 token：模型反复在两个方案间摇摆、同一 bug 改了 3 轮还没好、明显是上下文不足导致的低质量输出、单次任务超过 500K token 还没收敛。出现这些信号，停下来，要么补 spec 要么开新会话——继续烧 token 不会有结果。参考 AnyRouter 实测：模型路由、API 兼容与价格稳定性。
七、长项目的四个坑与对应方案
上下文管理：新手把对话当主存储舍不得开新对话。正确姿势反过来——对话只跑当前任务跑完就关；关键决策、踩坑、规约进 CLAUDE.md；工作流封 skill；架构决策开 ADR 存仓库。新对话时模型读 CLAUDE.md + ADR + 任务 spec，比重新讲一遍更稳。
Token 成本：把每个常做操作算一个 token 单价。「修 bug」50K、「加 feature」200K、「重构模块」800K。3B token 项目反推约 15 次重构 + 50 次 feature + 1000 次 bug 修复。产出匹配就不亏；远低于就是有浪费——反复读同一批文件 / 模型多绕几圈 / 没 spec 导致返工。
重构边界：失控的根因是改动范围没有显式定义。重构前先产出”边界 spec”：范围（只动哪个目录、不动哪些）、完成定义（测试全绿、tsc 无错、旧实现删干净）、不能动的清单。模型动手前你能评估范围，动完逐项验。
context window 满：让模型 summarize 当前对话到 docs/sessions/YYYY-MM-DD.md，下次新对话先读；把临时状态外移到 todo / 任务卡。
八、切换决策树：何时 vibe / 何时 spec
vibe 和 spec 不是立场之争，是同一项目不同阶段的工具：
临时脚本 / 一次性数据处理? → 永远 vibe
否则:
寿命 < 1 周? → vibe 为主, 关键决策落 README
否则 & 已 > 1000 行?
否 → vibe + 写 CLAUDE.md
是 & 能 5 秒说清模块边界? → 继续 vibe, 每 PR 前写 30 秒 spec
是 & 说不清 → 暂停补 spec 再继续
切换触发信号清单
下面 7 条触发信号，出现任意 2 条就该停 vibe 补 spec：
- 上次 PR 审 30 分钟没看完。
- 模型连续两次问你”是 A 还是 B”，而你需要现场翻代码才能答。
- 打开 3 天前的代码花 5 分钟才理解。
- 同一 bug 改 3 遍没干净。
- 单月 token 翻倍但产出没翻。
- 新人接手要超过半天才能跑起来。
- 改一个看似简单的小功能引发 5+ 个文件的连锁修改。
任何 2 条命中，意味着模型与你的认知已经开始失同步，必须补 spec 拉回来。
反向触发：什么时候从 spec 退回 vibe
spec 也会过度。下面 3 条出现，说明 spec 已经成了负担：
- spec 文档比代码改动还多。
- 模型每次开工前 80% 时间花在读 spec 而不是写代码。
- spec 之间相互引用、相互覆盖，已经没人能完整描述当前状态。
出现这些信号，要么大幅简化 spec（删冗余、合并相似），要么把某些低频模块退回 vibe——不是所有代码都值得维护 spec。
混合策略的常见组合
混合策略也常见：大部分时间 vibe，每周抽 1 小时整理 CLAUDE.md、大 feature 前写一页 spec。适合 1-3 人小项目。再大一点的团队可以走”核心模块 spec + 外围模块 vibe”——核心模块多人协作、需要稳定接口，spec 收益最高；外围模块单人维护、迭代快，vibe 更高效。更多讨论：开发者反馈主流AI编程工具性能”降智”，寻找Claude Code及Codex替代方案、挑战 Claude Code：开发者推出 Rust 原生 DeepSeek 编程 Agent Orca、Claude Code 界面重现”Fable-5″选项，Anthropic 或推进新特性测试。
九、反模式清单：vibe 与 spec 各自的失败姿势
两种模式都有典型失败模式，认出来比躲开更难。
vibe 在长项目的四种典型失败
- “我以为我懂这段代码”：vibe 写了一个月，问你某个函数为什么这么写——你想了 30 秒才答出来，且只答对一半。这是治理失败的早期信号。
- 小修永远不彻底：模型说”我修了”，你跑起来确实没那个 bug 了——但同样的 bug 三天后在另一个调用路径上又出现。根因是没有”边界定义”，模型只修了它看到的，看不到的没动。
- 拒绝重构因为不敢动：项目跑到一定规模后你开始拒绝大重构——不是技术上不行，是心理上怕动。这通常意味着 vibe 已经超期。
- 依赖膨胀：vibe 模式下模型很容易”推荐”装新依赖。半年后
package.json长达 80 个 dependency，其中 30 个一周没用、10 个有重复功能。
spec 的三种过度形态
- spec 写成无人维护的废纸：第一次写得很详尽，三个月后代码改了 5 轮、spec 一行没动。这种 spec 比没有更糟——模型读了会按过期 spec 写新代码。
- spec 取代思考：把”先写 spec”当成不动脑的借口。spec 本身错，模型按错的 spec 实现，bug 比 vibe 更深、更难修。
- spec 形式化：写 spec 写出仪式感——必须有 8 个章节、必须 PM 签字、必须走 review 流程。所有的 spec 价值在这种形式里被消耗光。
避免过度 spec 化的核心原则：spec 是用完即扔的工具，不是要永久维护的资产。把它当成给模型的”任务说明书”，而不是给团队的”产品文档”。
十、实践清单：项目三个阶段的可操作 checklist
项目启动阶段（前两周）
- [ ] 第一天写一个 30 行的
CLAUDE.md草稿，列项目目标、技术栈、3 条最关键的约束。 - [ ] 配置 verify loop：lint + 类型检查 + 一组核心单测，能在 30 秒内跑完。
- [ ] 决定哪些操作要做成 skill，哪些靠 vibe（一般是「新加 page」「迁移表」「发版」这三件最早封）。
- [ ] 建一个
docs/sessions/目录用于存放跨会话握手摘要。
中期复盘阶段（每月一次）
- [ ] 算这一个月的 token 消耗、对照产出数（PR 数 / feature 数 / bug 修复数）。
- [ ] 重新审视
CLAUDE.md，删除已过期约定、加入新挖出的隐性规则。 - [ ] 检查 skill 列表：哪些用得多但慢、哪些写了没用、哪些该新增。
- [ ] 看 PR 历史：哪些类型的任务返工最多？这通常是该补 spec 的重点。
长期归档阶段（项目稳定后）
- [ ] 把临时性的会话摘要清理掉，只保留 ADR 级别的决策记录。
- [ ] 把核心模块边界、接口、不变量明确写成
<module>/CLAUDE.md。 - [ ] 把 skill 沉淀成跨项目可复用资产，迁到团队级 skill 仓库。
- [ ] 写一份”项目接手指南”——新人或新模型如何在半小时内理解整个项目。
相关阅读
- 遭遇GPT降智后转向Claude：开发者实测MCP协议打造”自举”式开发闭环
- 多仓库开发的AI困境：如何实现从设计稿到多库代码的全链路自动化？
- 豆包 AI 优缺点实测: 对比 ChatGPT、Claude 与 Kimi
- 面试强入职弱？大模型时代下的程序员培养困局
- Recall：为 Claude Code 增加零成本本地记忆，解决 AI 编程冷启动痛点
- Claude Code 在做减法
FAQ
Q1: spec coding 是不是回到”瀑布开发”？
不是。瀑布的特征是”先写完所有 spec 再 code”，而且 spec 是一次性的、整体的、需要长期维护的；spec coding 是”每个任务前写一页 spec，写完可以扔”，粒度是任务级而非系统级，生命周期是会话级而非项目级。更接近 TDD 的精神延续——先定义”对”再实现，差别只在受众从 runtime 测试变成 LLM agent。把它当成给模型的”任务说明书”，不是给团队的”产品规约”。
Q2: CLAUDE.md 写多长合适？
50-300 行是舒服区间。< 50 行说明隐性约定还没挖出来，模型每次会话还要靠重复解释获得上下文；> 300 行说明你在写文档而不是写规约，模型读不完也会失焦。建议分块：核心约定 / 已知坑 / 模块边界 / 调试技巧。超过 300 行时不要硬塞，而是拆分——主 CLAUDE.md 留索引，专题文档独立成文，在主文里写明”涉及 X 时必读 docs/X.md”。
Q3: vibe 写出来的代码能转 spec 模式维护吗？
能，但要一次集中投资。通常 2-4 小时把隐性约定挖进 CLAUDE.md、把核心模块边界明确写下来、把过去踩过的坑做成 checklist。这个投资有两个回报：一是接下来每周省下数倍时间，二是项目从你”独家维护”变成”任何会读 markdown 的工程师都能接手”——后者在长项目里价值更大。建议在项目跑到 5000 行或第三个月时强制做一次。
Q4: 长项目 token 成本怎么压？
四件事按优先级排：（1）CLAUDE.md 替代每次会话重复解释，单次投入永久收益；（2）会话短开短关，单个任务一个会话跑完就关，不堆积”主会话”；（3）让模型只读真正需要的文件——读 100K 无关代码和 100K 有用代码的 token 成本是一样的；（4）复杂搜索/比对/分析交给 subagent，主会话只接收结果摘要。这四件做好，长期 token 消耗可以压到原来的 1/3 到 1/2。参考 开发者反馈Codex额度消耗异常快，Claude Pro成替代主力。
Q5: 一个人的小项目真的需要 spec coding 吗？
寿命 < 1 周不需要，写完即弃的项目 spec 是负收益。> 1 个月、代码 > 2000 行、且持续迭代的项目，回报一定为正——哪怕只是 50 行的 CLAUDE.md，三周后回头改都会感谢自己。判断准则不是”几个人”而是”会不会回头改”——只要会回头改，下一个回头改的”你”就相当于另一个工程师，需要一份能让他理解上下文的入口文档。
Q6: 切到 spec 后 vibe 的那种”灵感感”会不会丢？
不会。spec 只约束”做什么、不能动什么、验收是什么”，留给模型的实现空间依然很大。真正会让 vibe 灵感感丢失的是：每个任务前都开冗长的方案评审、把 spec 写成详细到行级的伪代码。这是过度 spec 化，不是 spec coding 本身的问题。一份好的 spec 应该 5 分钟读完、3 分钟写完，剩下时间还是模型自由发挥——但发挥的方向被约束在你想要的轨道上。
Q7: 团队多人协作时 spec coding 怎么落？
三个最小动作。（1）把 CLAUDE.md 进 git，所有人共享同一份项目级约定，改动走 PR review；（2）每个 PR 的 description 里附带”任务 spec”（10-30 行即可），让 reviewer 和 AI 同时能按 spec 验收；（3）每月 1 小时团队同步：哪些 skill 多人用、哪些约定该升级、哪些坑该写进 CLAUDE.md。三件做下来，多人协作的边际成本会显著降低，新人接手时间也能从两周缩到三天。
结语
vibe coding 是入口的礼物，spec coding 是出口的纪律。长项目工程师不是选边，而是在合适时切到合适模式。把 Claude Code 当 REPL 真爽，但 REPL 跑不动 3B token 项目——能跑下去的是把约束沉淀进文件、把验证自动化、让模型替你记住事情的工程实践。
记住一个简单的判断：当你开始怕动自己的代码时，已经过了切 spec 的时机了。早一周补 spec，省的是后面三个月的返工时间。