Spec-Driven AI 编程半年实战 — 有损管道、三工具比较与三大认知陷阱¶
📊 Level ⭐⭐⭐⭐ | 9.5KB
百人级互联网前后端团队半年 SDD 实践。核心洞察："有损管道" 框架 + 三大工具的 结构性代价 对比 + 认知陷阱。1
核心命题¶
AI 时代软件开发的核心矛盾变了：不是写不出代码，是没人能证明代码是对的。意图持有者和代码编写者的分离，是所有 SDD 问题的第一因。1
有损管道框架¶
所有开发范式都是同一条管道：人有意图，机器产生行为。中间是一条有损管道。
| 范式 | 控制点 | 损耗处理 |
|---|---|---|
| 古法编程 | 人脑 | 工程师隐式兜底 |
| Vibe Coding | 无 | 损耗裸奔 |
| SDD | spec | 显式定位 + 人审 |
与 Harness Engineering 互补——该实体是 Harness 工程框架，本实体是 Spec 层的认知与选型理论。
Spec 的定义¶
spec = 对"可接受实现空间"的**最小、可验证、可演进**的显式编码
Prompt 是一次性指令，Spec 是可审计的责任链。1
三大工具结构性代价对比（实测 30+ 需求）¶
| 工具 | 力气花在 | 放弃什么 | 实测数据 |
|---|---|---|---|
| Spec Kit (GitHub) | 管道控制（多阶段审） | 信息保真度 | 四层串联损耗：85%→72%→61%→52% 对齐度 |
| OpenSpec (社区) | 规格演进（活基线） | 强过程控制 | delta 回写抗漂移 |
| Kiro (AWS) | 需求精确（EARS 形式化） | 工具自由+review 带宽 | 形式化门槛 2-4 周适应 |
选型不是选"更好的工具"——是看你的 Intent→Spec→Code→Verify 控制链断在哪。1
与已有实体的关系¶
- OpenSpec 四步法复盘 — 互补：该实体聚焦 OpenSpec 具体流程短板，本实体提供 SDD 的认知基础框架
- OpenSpec + Trae/Solo 实践 — 互补：工具实操 vs 认知理论
- Spec 作为反熵架构 — 互补：该实体聚焦 Spec 作为架构工具，本实体聚焦 SDD 的开发流程认知
三大认知陷阱¶
陷阱一：不能自动验证的 spec 注定会烂¶
判断标准：能不能在 CI 里自动判定 pass/fail？不能的，就是换名字的技术文档。1
陷阱二：Spec 是契约，不是蓝图¶
信息论硬约束：spec 若比代码短，必然省略实现决策。唯一完整的程序规格就是程序本身。试图让 spec 完整到能推出所有代码→维护成本爆炸。1
陷阱三：不是所有需求都上 SDD¶
| 风险等级 | 策略 | 占比 |
|---|---|---|
| 低（脚本/原型） | vibe coding | ~15% |
| 中（功能迭代） | Plan Mode + 轻量 spec | ~70% |
| 高（支付/权限/合规） | SDD 全流程 | ~15-20% |
Spec 的未来演化¶
- 变稀疏：模型越强，L2(设计细节)消失，人只需写 L1(意图+边界)
- 变可执行：从自然语言 → property check / invariant assertion / 验收 oracle
- 成本下降：AI 辅助写/维护 spec → 更多场景过盈亏线
深度分析¶
一、有损管道是信息论约束，不是工程缺陷¶
人脑意图是连续的、含隐性成分（偏好/经验/语境/审美/风险直觉），代码是离散的符号序列。连续意图映射到离散实现必然是压缩，压缩必然丢信息——这是信道容量意义上的硬约束，而不是"工具还不够好"。任何范式都无法消除损耗，SDD 能做的只是把误码从运行时爆炸提前到评审时暴露，让损耗可见、可审计、可归因。
由此才理解为什么"意图持有者与实现者分离"被列为第一因：古法编程里损耗由同一个大脑的隐式兜底吸收，分离一旦发生，这层兜底被物理切断，损耗瞬间从"被吸收"变成"裸露"。Vibe Coding 的病灶不是损耗更大，而是损耗不可见；损耗始终存在，变的只是谁来承担。
二、Spec 是契约，不是蓝图¶
契约定义边界与接口（该做什么、什么叫对、越界即失败），蓝图描述构造（怎么做、每一步如何落地）。二者的完备性标准根本不同：契约的完备性是相对于争议可裁决而言的，它不需要预见所有履约细节，只需要在违约时可判定。按这个标准，spec 的目标不是"完整到能推出所有代码"，而是"任何实现都能被判对错"。
这也解释了 spec 为什么天然远短于代码：它省略的正是 L2 实现决策空间，而决定"怎么做"恰是 AI 的强项。反过来，硬把 spec 补全到蓝图级别，等于用自然语言把程序重写一遍——两处真相必然漂移，维护成本翻倍而不增加任何裁决能力。反向论证见 别再幻想用 Spec 替代写代码。
三、CI 可自动判定是工程产物与技术文档的分界线¶
判断标准只有一条：能不能在 CI 里自动判定 pass/fail。能，spec 就具备回归价值——改代码时它会主动报警；不能，它只能靠人的自觉维护，而自觉在迭代压力下必然衰减。深层含义是：可验证性不是 spec 的加分项，而是它的定义属性（与"最小、可验证、可演进"中的可验证同源）。
可验证性还决定 spec 的寿命。一条不能自动验证的 spec 在第一次大规模重构后就变成谎言，而谎言比缺失更贵，因为后来者会相信它。这也让"从自然语言 → property check / invariant assertion / 验收 oracle"的演化方向不再是文风问题：它是把 spec 从叙述物迁移为可执行物。
四、85%→72%→61%→52%：阶段数是"控制力—保真度"旋钮¶
Spec Kit 四层管道每层约 15% 损耗，累积对齐度约 52%（0.85⁴ ≈ 0.52）。这个数字说明的不是 Spec Kit 差，而是一条结构性权衡：每多一层，控制力（可审、可归因、可回滚）上升，信息保真度乘性下降。乘性意味着损耗不会因为"每层只丢一点"而温和——四层之后只剩一半。
推论是阶段数应随需求风险反向选择：高风险需求值得用四层换审计能力，因为 52% 的对齐可以靠人的评审补回，合规缺失补不回来；中风险需求两层（Plan Mode + 轻量 spec）足够，多出的层级纯属净损耗。OpenSpec 的 delta 回写与 Kiro 的 EARS 形式化，本质上是对同一条损耗律的两种应对——前者用"基线保鲜"压低跨迭代损耗，后者用"语法消歧"压低单次传递损耗。所以选型动作永远是先定位 控制链 的断点，再决定在哪一段加层、哪一段减层；延伸阅读 从 Spec 驱动到环境验证驱动。
实践启示¶
- 先定位断链，再选工具。 把 Intent→Spec→Code→Verify 四段写下来，逐段问"这一段现在怎么失败"。断在 Spec（说不清什么叫对）→ 补 L1 意图对齐；断在 Code（spec 对但实现漂移）→ 补自动验证与约束；断在 Verify（改完不知道有没有坏）→ 补回归 oracle。跳过诊断直接挑工具，通常是在不缺的地方加层、在真正漏的地方继续漏。
- 每条 spec 条目必须配一条 CI 检查。 拿不出 pass/fail 判定的条目当场删除或降级为备注；一条 spec 的实际价值约等于它触发过的失败告警数。评审 spec 时先问"它怎么被判错"，再问"它写得好不好"。
- 按风险分层投入（约 15 / 70 / 15-20%）。 低风险脚本与原型走 vibe coding；中风险功能迭代走 Plan Mode + 轻量 spec；高风险（支付、权限、合规）走 SDD 全流程。把全流程套在中风险需求上，等于用 52% 保真度换一批没人看的审计材料。
- 保持 spec 最小，并让它活着。 只写"可接受实现空间"的边界，不写实现步骤；用 delta 回写类机制让基线随代码演进，而不是写一份写完即归档的快照。spec 一旦成为快照，下一次迭代它就从资产变成负债。
- 把 review 带宽当预算来管。 多阶段管道每层的 ~15% 损耗，买的就是"人能审"这件事。如果团队没有相应的评审带宽，加层只会生产无人审阅的中间产物——那是最昂贵的损耗形式：既丢了保真度，也没换到控制力。
- 优先把 spec 迁移成可执行物。 能用 property check、invariant assertion、验收 oracle 表达的，就不要写成自然语言段落。可执行条目占总条目的比例，是团队 SDD 成熟度最直接、最不易自欺的指标。
参考¶
→ [raw/articles/d4MCEB91ppMVrNO4JQaI7Q|原文存档]