这是一个极其精准的灵魂拷问！你总结出的 “Spec-Decorated”（规约点缀/规约粉饰） 这个词，简直完美概括了现在 90% 宣称在用 AI 搞“规约驱动”，但实际上却深陷泥潭的团队现状。
理解这两个词的区别，就能彻底想通你们之前遇到的“合并冲突死局”。
简而言之：Spec-Driven 中，规约是“宪法和建筑图纸”；而在 Spec-Decorated 中，规约只是“事后写的说明书”或者“代码的遮羞布”。
以下是这两个概念的核心本质区别：
1. Spec-Driven（真正的规约驱动）
在真正的 SDD 模式下，规约拥有绝对的最高指导权。
- 因果关系： 因为有了这份确定的规约，所以才诞生了这堆代码。规约先行。
- Single Source of Truth（唯一事实依据）： 团队讨论架构、评审逻辑，只看 Spec 不看代码。如果代码的运行结果和 Spec 不一致，哪怕代码跑得通，那也是代码的 Bug，必须改代码来迎合 Spec。
- AI 的角色： 绝对服从的“高阶施工队”。它被明确限制在
.openspec或proposal.md画好的圈子里，严禁自由发挥。 - 心智模型： “我想清楚了，大家也同意了，AI 你去把这段逻辑翻译成代码吧。”
2. Spec-Decorated（规约点缀/粉饰）
这是一种典型的反模式（Anti-pattern） ，是披着 SDD 外衣的“随性编程（Vibe Coding）”。
- 因果关系： 开发者（或 AI）先一顿操作猛如虎，把代码写了个七七八八，然后为了应付团队的流程规范（比如必须得有个
proposal.md才能提 PR），事后补写 了一份规约。 - Single Source of Truth（唯一事实依据）： 代码才是实际的真相。规约只是附属于代码的“注释”或“包装”。如果代码变了，规约就得跟着改，甚至很多时候规约过期了也没人管。
- AI 的角色： 脱缰的野马 + 事后诸葛亮。一开始让 AI 随便瞎写，最后再让 AI 扫一遍代码：“来，根据这些代码，给我反向生成一个看起来很高大上的架构文档。”
- 心智模型： “代码终于跑通了！哎呀，还要交个规约文档，随便糊弄一个贴上去吧。”
核心对比一览表
| 维度 | 🎯 Spec-Driven (规约驱动) | 💄 Spec-Decorated (规约点缀) |
|---|---|---|
| 时序先后 | 先定规约，后写代码 | 先写代码，后补/改规约 |
| 评审重点 | 团队在开发前花大量时间 Review 规约 | 团队在提 PR 时才看到大坨代码和敷衍的规约 |
| AI 自由度 | 严格受限，没有规约不准写代码 | 极高，自由发挥，经常产生“幻觉”偏离需求 |
| 遇到冲突时 | 冲突在文档期爆发，几句话就能解决 | 冲突在合并期爆发，面临大规模代码重构 |
| 规约的价值 | 导航仪（决定去哪） | 后视镜（记录去过哪，甚至是为了应付交警） |
回到你上一个问题
现在回头看你刚才提到的痛点： “自己改了 Spec -> 让 AI 生成代码 -> 测试 -> 提 PR 时才发现冲突” 。
这其实就是典型的 Spec-Decorated 做法。
你们表面上是在修改 Spec，但因为没有提前与团队对齐（Sync） ，这份本地 Spec 就成了你自己脑子里的“私有物”。你们本质上还是在用“先干代码，最后合并”的传统思路，只不过在这个包袱里多塞进了一份自欺欺人的 Markdown 文件而已。
要从“点缀”走向真正的“驱动”，就必须忍痛改变习惯，强迫团队做到： “规约未合并对齐前，禁止 AI 敲下第一行核心代码”。
你觉得你们团队目前的情况，更偏向于哪一种？如果你们想从 Decorated 彻底转向 Driven，需要我为你们整理一份**“强制规约先行”的 PR 模板和检查清单**吗？
