Claude Code 长项目踩坑: vibe coding 与 spec coding 何时切换

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 仓库。
[ ] 写一份”项目接手指南”——新人或新模型如何在半小时内理解整个项目。

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，省的是后面三个月的返工时间。