Spec-Driven AI 编程半年实战 — 有损管道、三工具比较与三大认知陷阱¶
Ch09.181 Spec-Driven AI 编程半年实战 — 有损管道、三工具比较与三大认知陷阱¶
📊 Level ⭐⭐ | 4.1KB |
entities/spec-driven-development-cognitive-framework.md
Spec-Driven AI 编程半年实战 — 有损管道、三工具比较与三大认知陷阱¶
百人级互联网前后端团队半年 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 → 更多场景过盈亏线
参考¶
→ [raw/articles/d4MCEB91ppMVrNO4JQaI7Q|原文存档]