可验证 AI 交付：Spec 驱动工作台与即兴协作的对比分析

一、对比背景：为什么”能不能接着做”成了核心问题

在与 AI 编码助手协作开发时，很多团队会发现一个反直觉的现象：材料其实不缺——聊天记录有、代码仓库有、需求文档也有，但真正卡住人的，是要求、代码和检查结果三者对不上。当一次开发任务需要被接手、被复查、被继续推进时，”当时是按什么要求做的””这次改动覆盖了哪些范围””哪些失败还没解决”往往无从查起。

本文对比的两类对象是：

• 对象 A：Spec 驱动的可验证交付工作台——以”先想清楚怎样算交付完成、别人怎样复查”为起点，用 Spec（可验收的要求说明）、先红后绿（先写失败检查再实现通过）和运行记录（保留检查输出与失败状态）把需求、代码、检查结果建立可追溯的对应关系。
• 对象 B：直接即兴协作模式——不建立固定工作台，依赖聊天讨论、代码版本管理和零散文件加命名约定来推进任务，流程灵活但对应关系依赖人的记忆与临时约定。

需要强调的是，这两者不是”先进”与”落后”的关系，而是可追溯性投入与任务复杂度之间的匹配问题。任务量少、周期短、单人闭环时，即兴协作完全合理；当任务需要多人接手、多次返工、反复验收时，A 模式的价值才会显现。

二、两种模式的共同点

在展开差异之前，先明确它们在目标层面的共性：

1. 都承认”代码通过检查”不等于”交付完成”。两者都需要人来判断真正的使用目的与隐藏条件，测试全绿只说明满足了已检查的约定。
2. 都依赖工程判断归人。无论流程多固定，复用哪些旧代码、改到哪里、结果是否可接受，这些判断无法被流程替代。
3. 都需要保留某种形式的记录。区别只在于记录是结构化的（Spec + 运行记录）还是非结构化的（聊天 + 提交信息）。

正因为目标一致，差异才集中在”如何保证下次能接着做”这一工程实现层面。

三、核心差异分析

3.1 需求可追溯性：正式决定 vs 讨论沉淀

即兴协作模式下，需求散落在聊天里，”哪段讨论成为正式决定”没有显式标记。典型症状是：每次接手都要重新找上下文，问”当时的需求在哪”。

工作台模式要求先产出可验收的 Spec：把”下次能接着做”拆成可检查的要求，逐项写明验收口径。Spec 不是需求文档的复述，而是把模糊诉求转成可判定真假的条目。例如”加一个查询按钮”已经隐含选定了解法，却没有说清谁遇到什么困难；Spec 阶段要回到业务问题本身，再落到写集（本次允许改动的文件与范围）。

3.2 执行范围可控性：显式边界 vs 口头约定

即兴协作中，”这次允许改什么、要跑哪些检查”通常靠对话临时确认，容易漏项。工作台把确认后的范围与检查入口交给执行流程，执行时以写集为边界，越界改动可被发现。

从工程角度看，这相当于给 AI 执行加了一层范围契约：写集之外的修改需要人工重新确认，检查清单则作为”先红后绿”的起点。

3.3 失败可续性：状态可查 vs 从头再来

失败后能否接着处理，是两种模式差异最大的地方。即兴协作中，卡在哪一步、哪些结果仍有效，往往要重新翻记录；工作台则保留运行记录——失败的检查、对应输出、哪次修改触发了它，都作为状态留存。检查失败就按输出修复重跑，要求变化先由人确认，形成闭环。

3.4 验收可信度：对应关系 vs “最近一次通过”

不保存要求与输出的对应关系时，”最近一次测试通过”很容易被误当成”当前版本满足本次要求”。工作台通过 Spec—写集—运行记录三者的绑定，让每次检查结果都能回答”属于哪次工作、对照哪条要求”。这并不能消除未发现的需求风险，但能消除误归因风险。

3.5 成本结构对比

维度	Spec 驱动工作台	直接即兴协作
前期投入	需要写 Spec、定义检查入口	几乎为零，直接开工
接手速度	快，上下文可查	慢，依赖记忆与翻记录
漏项风险	较低，范围与检查显式	较高，依赖临时确认
失败续作	状态留存，可增量推进	常需重新梳理
维护成本	需维护工作台与记录规范	低，但有隐性沟通成本
适用任务量	中大型、多轮返工、多人接手	小型、单人闭环、短周期

3.6 效果回收的层次差异

两种模式都要面对同一个边界：流程走完、测试全绿，仍可能漏掉未发现的要求。效果回收需要预先定好观察对象、时间范围和比较口径，不能把变化全部归因于工具。三个层次——约定检查、使用效果、业务价值——不能互相替代。工作台能做的是把前两层记录清楚，第三层仍要靠人设计观察方案。

四、典型场景与选型建议

优先考虑即兴协作的场景：一次性脚本、探索性原型、单人短周期任务。此时建工作台的维护成本高于收益，文件加命名约定已经够用，沿用也合理。

优先考虑工作台的场景：任务需要多人接手、存在多轮验收、失败后必须增量续作、交付物需要被第三方复查。尤其是 AI 生成占比高、人工复核成本大的团队，Spec 与运行记录能显著降低”对不上”的排查成本。

条件化判断：如果团队目前连”最近一次测试通过是否对应当前版本”都说不清，说明对应关系已经失控，此时引入最小化的记录与查询能力（第一版只做”按什么要求做、结果属于哪次工作”）比全套流程更务实。

五、迁移与使用注意事项

1. 第一版做”记录与查询”，不做大而全的流程。后面无论怎样执行，都要先能回答两个问题：按什么要求做、结果属于哪次工作。
2. 不要用流程替代工程判断。真正的使用目的与隐藏条件、旧代码复用是否适合当前项目、测试未覆盖的业务风险，仍归人判断。
3. 固定流程，保留人的红色节点。AI 说”完成了”不能代替验收；要求变化必须先由人确认，再进入执行。
4. 接受残余风险。工作台提升的是可追溯性与可续性，不是需求完备性；未被发现的条件仍可能漏掉。

六、总结

Spec 驱动工作台与即兴协作的核心差异，不在于是否使用 AI，而在于是否为”下次能接着做”付出结构化的记录成本。即兴协作以低前期投入换取灵活性，代价是对应关系靠人维持；工作台以 Spec、先红后绿和运行记录建立可查找、可复查、可续作的交付链路，代价是维护成本与流程约束。选型的关键是评估任务量、接手频率与验收强度，让可追溯性投入与任务复杂度匹配，而不是一概而论。