爆肝长文：SDD 实战上篇，从 Vibe Coding 到渐进式 Spec驱动开发

公众号名称：dolphin07

作者名称：Dolphin7

发布时间：2026-06-30 19:39

AI 把编码变成了最便宜的一环，却把验收、维护和协作变成了更贵的问题。下半场的主矛盾，不是生成，而是正确性。

引言：Spec Coding 从个人提效走向团队提效

这篇文章来自一次真实业务团队的 Spec Coding 实战。我想讲清楚的不是“SDD 是什么”这种概念题，而是一个更现实的问题：

当 AI 已经能把代码写得很快，团队研发体系为什么没有等比例变快？

过去一段时间，我们从 Vibe Coding 走到 Spec Coding，试过 OpenSpec、Superpowers，也踩过流程变重、验收变难、个人提效难以传导到团队提效的坑。最大的体感是：AI 降低了写代码的成本，却没有自动降低 review、验收、交接和维护的成本。

很多 AI Coding 经验主要解决个体效率：一个人如何更快完成原型、脚本和局部功能。团队级提效更难，因为它面对的是复杂业务、多角色协作、质量约束和持续交付。试点可以证明方向，真实业务才会暴露系统性问题。

这也是团队落地 Spec Coding 的价值：把需求边界、实现路径、验收标准和协作共识提前显性化，让 AI 生成的代码更容易被判断、验证、接手和复用。

如果你也在探索 Spec Coding，或者正卡在“个人用 AI 很快，团队落地很难”的阶段，上篇会从问题定义、范式认知、工具选型和踩坑复盘，一步步推导出更现实的落地方式：渐进式 Spec Coding。

这不是一套停在概念层的写法。我把这套方法收敛成了一组自研渐进式 SDD skills：从需求澄清、Spec 生成、Plan/TDD 分流、实现、验证到收束，尽量让团队不用在“完全 Vibe”和“重型 SDD”之间二选一。

如果你想直接参考这套落地方式，文末我会放出一套自研的渐进式 SDD 资源包，包含 PrismSpec skills、需求分级卡片和轻量 Spec 模板。读完后私信关键词 prismspec 就可以领取。

读完这篇，你至少能拿走三样东西：

1. 一张解释“为什么 AI 编码提速没有传导到团队交付提效”的问题地图；
2. 一套按需求风险选择 Spec 强度的渐进式方法；
3. 一组可以直接参考的 PrismSpec skills 设计思路。

正文按七个问题展开：

1. 问题定义：为什么 AI 写代码更快了，团队却没有等比例更快
2. 范式认知：为什么需要 Spec Coding
3. 核心定义：Spec Coding 到底是什么
4. 工具选型：Plan Mode、Superpowers、OpenSpec、Kiro、GStack 各自在解决什么问题
5. 实践复盘：OpenSpec + Superpowers 为什么一开始看起来很对
6. 踩坑复盘：为什么完整流程跑起来反而变重
7. 上篇结论：为什么渐进式 Spec Coding 更适合真实团队，以及它如何落成 skills

一、问题定义：AI生成代码提效，为什么没有变成交付提效

AI 最大的误导，是让人以为：编码提效会自然传导为交付提效。
事实正好相反：AI 最容易提速的是编码，最难提速的是交付。

真正的研发交付链路，更接近下面这个过程：

编码只是交付链路中的一个环节，不是交付本身。

AI 主要压缩的，是第三步：编码实现。
它没有同步压缩前面的需求澄清、方案设计，也没有同步压缩后面的代码审核、测试验证、发布上线。

所以 AI Coding 很容易出现三个结果：

1. 编码快了，但验收更贵了
代码越来越像“结果”，不再像“过程”。人没有深度参与生成，review、验收、接手都会更难。
2. 编码只是其中一环，前后做不好会把时间全部吃回去
需求边界没讲清、方案路径没收敛、验收标准没独立，任何一个环节失控，都会把前面省下来的时间重新吃回去，最后变成返工。
3. AI Coding 的个人提效是真实的，但团队提效是困难的
个人只需要把一段代码写出来，团队要把整条链路稳定跑通。

所以团队今天真正面对的问题，不是“AI 能不能写代码”，而是：

为什么生成提效，没有自动变成交付提效？

SDD 的问题空间：它真正要解决什么

SDD 要解决的不是“多写一份 Spec”，而是下面五类核心问题：

1. 正确性定义问题：什么算对，什么不算对
2. 路径收敛问题：这么多可能实现，团队到底要哪一条
3. 共识沉淀问题：怎么把个人和 AI 的临时收敛，变成团队可复用、可协作的约束
4. 验证交接问题：怎么把“写什么”顺利交给 review、测试和验收去裁决
5. 提效转化问题：怎么把个人提效转成团队提效，把生成提效转成稳定交付

这五类问题，就是后面整篇文章的主线。

这一节先带走一句话：

AI 提速的是编码环节，团队真正要补的是正确性定义、路径收敛和验证交接。

二、范式认知：为什么需要 Spec Coding

先从研发面临的问题出发：Intent 到 Code 的路径会爆炸，但工程上只接受团队认可的路径。

核心矛盾：Intent 到 Code 无数条路径，但工程上只需要一条

每一个需求从 Intent 到 Code，中间都存在指数级的路径可能：

Intent: "实现一个抓球扣费功能"
         │
         ├─ 先扣后抓？先抓后扣？
         ├─ 幂等用数据库唯一键？还是 Redis SET NX？
         ├─ 失败重试 3 次？5 次？不重试？
         ├─ 余额校验放网关？放 Service？放 Repository？
         ├─ 并发锁粒度：用户级？订单级？全局？
         └─ ...

路径数 = 决策点1 × 决策点2 × ... × 决策点n → 爆炸

实际工程需要的不是“某条能跑的路径”，而是确定性的、可审计的、团队共识的那一条。

有些初创团队可以接受“模糊的正确”，因为他们对确定性要求没那么高，短期提效会非常明显。但对长期演进的业务系统来说，如果每次都靠 AI 自己选路径，后面很容易积累不可审计的实现债。

三种编程范式，本质上是三种不同的路径收敛策略。

① 古法编程：人脑逐行决策，收敛靠经验

工程师在写代码的过程中逐行做路径选择，靠脑中的隐性上下文完成收敛：经验、偏好、团队规范、历史踩坑。

这种方式确定性高，但慢。每条路径都是人用时间换来的。

② Vibe Coding：AI 替你选路径，Code 成本降了一个量级

Vibe Coding 的进步是真实的：代码生成成本从小时级下降到分钟级，探索、原型、脚本、小工具都非常适合。

但它的问题也很明显。第一次 Prompt 得到的代码大概率不完全对，于是你开始迭代：

Prompt v1 → 代码不对 → 补充约束 → Prompt v2 → 部分对了 → 再补 → v3 → ...

这个反复沟通的过程，本质上就是在逐步收敛路径。但问题在于：

• 收敛过程不可沉淀
• 收敛结果不可复用
• 不同人会收敛到不同路径
• 出问题后很难审计当时的约束和决策

Vibe Coding 的本质：用廉价的 Code 生成 + 昂贵的反复沟通来完成路径收敛。收敛成本从“写代码”转移到了“反复 Prompt”。

③ Spec Coding：把收敛结果固化成团队资产

如果把反复 Prompt 最终收敛出来的约束提前写下来、结构化、固定住，比如“要幂等”“余额不能为负”“失败不重试”，Vibe 里的临时判断就变成了团队可复用的约束资产。

这就是 Spec Coding 的演进价值：把 15 轮对话收敛出来的路径选择，压缩成一份可复用、可审计、可传递的产物。

范式	路径收敛策略	Code 成本	收敛成本	可复用？
古法	人脑逐行决策	高	高（但隐式）	留在人脑，不可转移
Vibe	AI 随机采样 + 反复 Prompt	低	高（反复沟通）	不可复用（对话即弃）
SDD	Spec 提前锁定	低	一次投入，多次复用	跨人、跨模型、跨时间

实践中 Spec 也可以由 AI 生成初稿。人的关键职责，是表达 Intent、审核约束、冻结关键路径。

所以第二章的结论很简单：Vibe Coding 解决个人探索效率，Spec Coding 解决团队路径收敛。
团队需要 Spec Coding，不是因为大家应该多写文档，而是因为复杂协作需要可审、可验、可复用的收敛机制。

这一节先带走一句话：

Spec Coding 的核心价值不是约束 AI，而是把团队认可的路径提前固定下来。

三、核心定义：Spec Coding 到底是什么

上一章回答了为什么需要 Spec Coding。这里先把定义讲清楚：

Spec Coding = 通过显式、结构化、可验证的约束，把 Intent 到 Code 的路径收敛为团队可审计、可复用、可验收的交付过程。

如果只压缩成一句话：

Spec = 对可接受实现空间的最小、可验证编码。

这句话里有三个关键词：

关键词	含义	解决的问题
可接受实现空间	团队认可的一小块答案空间	AI 可能写出很多合理代码，但团队只接受其中一部分
最小	只锁关键约束，不复写实现细节	避免把 Spec 写成另一份代码
可验证	能映射到 review、测试、验收或运行证据	避免 Spec 变成无法裁决的愿望

从 Intent 推导：Spec 需要描述什么

上一节推导出了 Spec 存在的必要性。现在问：Spec 里到底该写什么？

一个常见误区是：很多人认为只有 Requirement，也就是 What，才是 Spec；Design 和 Plan 不算。这是狭义理解。

从我们的核心模型出发，Intent → Code 中间所有显式约束都是 Spec：

	狭义 Spec	广义 Spec（本文采用）
包含	只有 Requirement（What）	Requirement + Design + Plan
理论依据	学术定义：spec 描述 what not how	工程现实：Intent → Code 中间的所有显式约束都是 spec
问题	Design 不锁定，AI 每次选不同路径	更贴近工程落地

对应三层 Spec 产物：

层	回答什么	产物	为什么需要
Requirement	做什么、不做什么、验收标准	边界 + 验收标准	锁定“正确”的定义。没有它，AI 不知道什么叫对
Design	技术方案、架构选型、数据模型	设计文档、DDL、API、时序图、选型对比	锁定关键实现路径，让人能快速审核方案合理性
Plan	按什么顺序、分几步执行	Tasks 列表 + 依赖关系	把大任务拆成可独立验证的小步骤

Plan 把大任务拆成可独立验证的小步骤，每步聚焦在有限上下文内完成。这不是文档洁癖，而是当下模型能力和人类 review 带宽共同决定的工程约束。

Spec 应该长什么样：二十年前的启示

intent → spec → code，和当年离岸外包的 intent → 架构设计 → 外包写 code，是同一道题。上下摆在一起，差别和共性一眼能看清：

两条链，结构位置一模一样：intent 和 code 中间，都夹着一个看不见、不可信、还会自行脑补的执行者。

中间那个框，架构设计 / spec，是同一个位置。它是你交给执行者、用来约束它的那份契约。

定义讲清楚后，还要守住三个边界：

Spec 可以表现为文档，但本质是约束。
Spec 负责收敛，验证负责裁决。
Spec 追求最小有效约束，不追求越多越细。

文档只是 Spec 最常见的载体。真正有价值的是里面的约束：边界、不变量、路径选择、验收标准和验证证据。

没有裁判机制的 Spec，本质上只是 Claim。越接近测试、运行结果和线上证据，才越接近 Truth。

所以 Spec Coding 的关键不是“有没有 spec.md”，而是 AI 是否工作在团队认可、可验证的约束空间里。

这一节先带走一句话：

Spec 是约束，不是文档；文档只是最常见的载体。

四、工具选型：Plan Mode、Superpowers、OpenSpec、Kiro、GStack 各自在解决什么问题

工具选型最容易踩的坑，是把不同层级的工具放在一起比强弱。

更好的看法是：五个工具，对应五种不同赌注。

工具	设计哲学	一句话判断
Plan Mode	AI 出方案，人审一次，用完即弃	够用就是最优解，大部分日常需求应该停在这里
Superpowers	没有测试就没有代码，纪律即产品	用 token 换纪律，守住质量下限
OpenSpec	Spec 是 Truth，代码是投影	适合审计追溯和规格漂移治理
Kiro	Spec 即 IDE，需求到代码一站式	体验最丝滑，代价是 IDE 和生态绑定
GStack	一个人 = 一个团队，角色即约束	个人开发者有价值，团队协作价值有限

下面拆开看。

Plan Mode：够用就是最优解

设计哲学： Spec 是实时的、一次性的、AI 生成的。Claude Code、Cursor、Copilot 这类工具里的 Plan Mode，本质都是先让 AI 分析代码库生成计划，人审批后再动代码，用完即弃。

短板： session 断了就没，不适合审计，也很难做多人长期对齐。

判断： SDD 的最小构件是“人审意图”这个控制点。Plan Mode 恰好做了这件事，也只做这件事。80% 日常迭代，到这里就该停。

Superpowers：用 token 换纪律

设计哲学： 纪律即产品。它把 brainstorming、计划、TDD、review、finalize 做成流水线，核心不是“更会写代码”，而是强制团队把需求、测试和交付纪律串起来。

真正的价值： 测试吃掉了部分 Spec 文档。Brainstorm 阶段逼你把验收标准想清楚，再翻译成测试。测试就是可执行的 Spec：pass/fail 无歧义，不腐化，不需要和代码同步。

短板： 费 token，简单改动 overhead 明显。七阶段流水线对配置修改、小 UI 调整这类任务是杀鸡用牛刀。

判断： 你买的不是速度，是质量下限。如果核心痛点不是代码质量和工程纪律，就不需要一上来用它。

OpenSpec：理想很丰满，工程很骨感

设计哲学： Spec 是真相源，代码是投影。改动以 Delta 形式提案，实现后归档合入主 Spec，让系统规格保持最新。

价值： 对存量系统、审计追溯、规格漂移治理很有吸引力。它在为更长期的意图驱动开发做预演。

短板： 自然语言没有编译器，Spec is Truth 这个假设在工程上很脆弱。活基线维护成本会随需求增长，同步大量依赖人。

判断： 适合受监管行业、审计要求强、超大系统规格漂移严重的团队。大部分产品团队不在这个条件里。

Kiro：Spec 即 IDE

设计哲学： 把 SDD 全流程焊进 IDE：需求、设计、任务、执行、Hooks 自动化都在一个产品里完成。

价值： EARS 句式有工程价值，结构化需求天然更容易映射测试；从需求到代码的体验也最顺。

短板： IDE 绑定和生态绑定。你的编辑器、插件、快捷键、工作流都要迁移，Spec 产物也会强依赖 Kiro 的项目结构。

判断： 如果团队愿意接受 IDE 迁移，并希望把需求到代码的流程产品化，Kiro 值得看。否则成本很高。

GStack：YC 掌门人的个人武器

设计哲学： 角色即约束。它用一组 slash command 模拟 CEO、产品经理、架构师、QA、安全官等角色，让一个人获得多角色视角。

它解决的不是 SDD 问题，而是“一个人怎么当一个团队”的问题。 它不关心 Spec 是不是 Truth，它关心的是一个人能不能在不同角色之间切换，并把产品、工程、QA 的视角补齐。

短板： Prompt 驱动，没有持久化 Spec 或测试约束。本质上是结构化的 Vibe Coding，质量强依赖底层模型。

判断： 独立开发者或一人公司有价值；团队协作价值有限。团队本身就是角色，不需要一个人模拟 23 个角色。

决策路径

正确路径是渐进式加层，不是并联缝合：

每次只加一层。每层解决一个当前真实存在的问题。

这一节先带走一句话：

工具选型不要比强弱，要看它解决的是计划、纪律、审计、IDE 体验，还是角色约束。

五、实践复盘：OpenSpec + Superpowers 为什么一开始看起来很对

当时想法很自然：

• OpenSpec 管 What：需求、变更、规格基线
• Superpowers 管 How：方案、TDD、验证、Code Review

理论上，一个管需求层，一个管执行层，看起来非常互补。

OpenSpec：What，需求层

Superpowers：How，执行层

OpenSpec + Superpowers：看起来完整，但实际变重

这套方案的问题不是“不合理”，而是落到实践后，我们发现一个更关键的问题：

有了 Superpowers 之后，我们到底还需要 OpenSpec 的什么？

这个问题逼着我们重新审视：团队真正需要的是“更多工具”，还是更低成本的路径收敛、更好的上下文和更可靠的验证？

六、踩坑复盘：为什么完整流程跑起来反而变重

坑 1：迷信 Spec is Truth，双重编码损耗，Code 才是真相

业界流行的 Spec Coding 三条铁律：

1. No Spec, No Code：没有文档，不准写代码

2. Spec is Truth：文档和代码冲突时，错的一定是代码

3. Reverse Sync：发现 Bug，先修文档，再修代码

这三条铁律在理论上无懈可击：spec 是 single source of truth，代码只是 spec 的实现。违反铁律 = 技术债。

但实践一段时间后，我们发现这三条在很多场景里都会变成误区。

• No Spec, No Code：很多需求是一个人半天搞定的小任务，为它们写 spec 的时间可能大于直接写代码的时间。铁律变成了“为了写 spec 而写 spec”。
• Spec is Truth：Spec 是人用自然语言写的，AI 用概率模型解读，中间存在两层有损翻译。它不是 truth，它更像 claim。真正的 truth 是跑通测试的代码。
• Reverse Sync：编码中发现变化，先改 spec 再改代码，成本往往是直接修改的数倍。强制 Reverse Sync，容易让团队维护一份注定过期的文档。

这不是说 Spec 没价值，而是说：Spec 的价值主要在前置对齐和约束生成，不一定在长期充当唯一真相源。

坑 2：迷信流程控制，叠加工具 ≠ 双保险

我们选择 OpenSpec + Superpowers 融合方案时，理想是各司其职：

• OpenSpec 定义 What
• Superpowers 负责 How

但实际跑起来，两套工具处处打架。

冲突	现象	后果
设计文档归谁管	OpenSpec 产出 design.md，Superpowers brainstorming 也产出 design doc，内容高度重叠	开发者不知以哪份为准
What 的价值被稀释	OpenSpec 的验收标准被 Superpowers TDD plan 转化为 test case	spec 文件本身不再是验证手段
多层审批互不信任	review spec → review design doc → review plan，三层审的是同一组信息的不同表达	时间变长，信心不一定增加

根因：两套工具各自都是完整方案，叠在一起，中间地带完全重叠。

本质：1 + 1 不等于 2，可能等于 1.3。重叠部分不是双保险，而是双重负担。

这里的教训不是“工具选错了”，而是我们对控制的理解需要调整：

模型越强，全流程控制的边际收益越低，边际成本越高。更合理的方向是 关键节点控制，而不是每一步都控制。

给模型丰富上下文，让它更少猜；用关键闸门控制不可逆决策，而不是用 200 行 spec 束缚每一步。

更重要的是：串行叠加是错误路径，按场景渐进式加层才是正解。

错误路径是把所有需求都塞进同一条重流程：

需求 → OpenSpec → Superpowers → TDD → Review → Archive

看起来完整，实际会把低风险需求拖重，把中风险需求拖慢，把高风险需求也拖进重复审批。

正确路径是先区分场景，再决定控制强度：

所以后面我们真正收敛出来的不是“OpenSpec + Superpowers 全流程”，而是渐进式 Spec Coding：小需求轻量跑，复杂需求补约束，高风险需求上验证，有审计需求再引入持久化规格。

坑 3：Spec 的理解太窄，以为只有描述 What 才算 Spec

这个坑的隐蔽性最强，因为它藏在概念定义层面，不一定发生具体事故，但会持续扭曲团队对工具的选择。

团队讨论时经常会出现两种声音：

• “Plan Mode 不算 SDD，因为它没有写 spec 文件。”
• “Superpowers 才是正统 SDD，因为它有 design doc。”

这些说法背后隐含一个假设：只有显式写出一份独立的 spec 文件，且主要描述 What，才算 Spec-Driven。

但这个定义太窄了，会把大量实际上在做 spec 驱动的实践排除在外。

我更认可的定义是：

Spec = 对可接受实现空间的最小、可验证编码。

按这个定义：

实践	是不是 Spec？	为什么
OpenSpec 的 spec.md	是	显式描述 What，结构化文件
Superpowers 的 design doc	是	描述 What + How 的设计边界
Plan Mode 的 prompt	是	先调研、给方案、确认后再写代码 = 轻量 spec
CLAUDE.md / AGENTS.md	是	项目级约束 = 持久化的 spec
验收测试	是	可执行的 spec，且是最强形式
一句话口头意图	边界	极轻量 spec，但确实约束了实现空间

关键洞察：

• Plan Mode 不是“没有 spec”，而是 spec 和执行在同一条交互链里完成。
• CLAUDE.md 不是“只是配置文件”，它是活的项目级 spec。
• TDD 的测试不是“只是测试”，它是最严格的可执行 spec。

这个认知局限会带来三个后果：

1. 把“写 spec 文件”等同于“做了 SDD”，文件写了但没发挥作用，最后变成形式主义。
2. 把 Plan Mode 视为偷懒，而不是轻量 SDD，导致所有需求被迫走重流程。
3. 忽视 CLAUDE.md 和验收测试的 spec 属性，没有利用最高 ROI 的 spec 形式。

教训：

1. Spec 是光谱，不是特定格式。 从口头意图到验收测试，都是 spec 的不同浓度。
2. Plan Mode = 轻量 SDD。 不要把“没有独立 spec 文件”理解成“没做 spec 驱动”。
3. 最高 ROI 的 spec 形式往往不是文件。 而是 CLAUDE.md、验收测试、brainstorm 对话和关键决策表。
4. SDD 的成功标准不是有没有写 spec 文件，而是 AI 是否在约束空间内工作。

这一节先带走一句话：

完整流程的问题不是不对，而是太早要求所有需求都付出同样的流程成本。

七、上篇结论：渐进式方案，不同需求用不同强度

前面讲了为什么串行叠加会变重。那落地时应该怎么做？

我的结论是：不要把所有需求都塞进同一条 SDD 重流程，而是按风险和协作成本选择控制强度。

这里有两个现实选择。

选择一：Superpowers + Plan Mode，先用现成能力做分级

如果团队还在探索阶段，最稳的方式不是马上自研，而是先把现成能力用对：

需求类型	推荐方式	核心目的
低风险 / 小改动	Plan Mode	先出计划，人确认后执行，避免为小事写重文档
中等复杂 / 多人协作	Plan Mode + 简短 Spec 摘要	锁住边界、关键路径和验收标准
高风险 / 回归风险	Superpowers	用 brainstorming、plan、TDD、verification、review 守住纪律

为什么这个组合有效？

• Plan Mode 提供了最轻量的“先计划、人确认、再执行”控制点。
• Superpowers 提供了更强的执行纪律，尤其是 TDD、verification 和 review。
• 两者不需要强行缝合成一条统一流程，而是按需求风险切换。

这里最重要的不是工具本身，而是分级意识：低风险不拖重，高风险不裸奔。

错误做法是把所有需求都塞进：

需求 -> OpenSpec -> Superpowers -> TDD -> Review -> Archive

正确做法是先问：这个需求到底需要多强的控制？

选择二：PrismSpec，把渐进式 SDD 做成自研 skills

如果团队已经跑过一轮工具试点，发现 Plan Mode 太轻、Superpowers 对部分需求又太重，就可以把中间层抽出来，做成自研渐进式 SDD skills。

我把这套思路收敛成了 PrismSpec。它不是完整 Harness，也不试图替代所有工具，只做一件事：把渐进式 Spec Coding 固化成一组可恢复、可交接、可验证的最小工作流。

PrismSpec 的默认链路很克制：

brainstorm -> plan -> implement(plan|tdd) -> verify -> finish

每一步都必须产出一个能落盘的工件：

阶段	产物	解决的问题
`brainstorm`	`spec.md`	把 Intent、Scope、AC、关键决策收敛下来
`plan`	`plan.md`	把 Spec 拆成能独立 review 的任务
`implement`	代码 + task evidence	根据风险走 `plan` 或 `tdd`
`verify`	`verify.md`	记录真实验证命令和结果
`finish`	`summary.md`	收束本次交付，留下可交接摘要

它支持两个执行策略：

模式	适用场景	规则
`plan`	低风险功能、文档、脚手架、直接重构	按已 review 的计划实现，行为变化时补测试
`tdd`	Bug 修复、核心流程、权限/资金/状态机、并发、幂等、迁移、回归风险	先写红测，再实现，再重构

auto 不是第三种流程，而是让模型根据风险选择 plan 或 tdd。如果后续发现风险升高，允许 plan -> tdd；但不能静默把 tdd 降级成 plan。

这个设计背后的原则很简单：

只有当一个步骤能产生持久工件，或者能防止真实工程事故时，才值得成为流程。

所以 PrismSpec 和重型 SDD 最大的区别，不是少写几个文件，而是流程强度始终跟着风险走：

这就是我更认可的渐进式 Spec Coding：不是在 Vibe Coding 和重型 SDD 之间二选一，而是在不同需求上使用不同浓度的 Spec。

前面提到的资源，放在这里。

如果你想直接参考这套做法，可以私信关键词 prismspec。我会发你三样东西：

1. 自研 PrismSpec 渐进式 SDD skills；
2. 需求风险分级卡片；
3. 轻量 Spec 模板。

也欢迎在评论区说说你们团队现在处在哪一档：纯 Vibe Coding、Plan Mode、Superpowers、OpenSpec，还是已经开始做自己的 SDD 流程。

下篇会继续往前推：渐进式 Spec 解决了“流程别做重”，但还没有解决工程补强问题。要把个人提效真正变成团队提效，还需要走向 Harness 和 Loop。

内容效果不满意？点此反馈