"但这不是 SDD/OpenSpec 的缺点，而是它把冲突提前暴露了。" 这句话我不是很认可。为什么说是提前暴露了呢？我修改完规约，然后会让AI给我生成代码，最后测试完没问题，我才会合并到主分支。这时候也才能发现问题呀。
你这个质疑是对的。 我前一句话说得过于绝对了。
更准确的说法不是：
SDD 一定会把冲突提前暴露。
而是：
只有当规约被当成“共享的、先于实现的协作对象”时， SDD 才有机会把一部分冲突前移；否则，它并不会天然提前暴露问题。
你描述的流程其实很关键：
- 你改规约
- AI 按规约生成代码
- 你本地测试通过
- 最后合并主分支
- 这时才发现问题
在这个流程里，冲突是否提前暴露，取决于“谁在什么时候看到你的规约变更” ，而不是取决于“有没有 spec”本身。
你为什么会觉得“并没有提前暴露”
因为在你这个链路里，规约变更和代码实现仍然是在个人分支内闭环完成的：
- 规约先改了，但只是你自己在用
- AI 生成代码，也只是围绕你自己的规约理解
- 测试也主要验证你这条分支内部自洽
- 真正和别人发生碰撞，是在合并主分支时
所以你看到的问题本质是：
spec 只是单人开发的输入，不是团队协作的公共约束。
在这种情况下，SDD 当然不会自动“提前暴露”冲突。 它只是把“你写代码前先写点说明”换了个形式而已。
哪些问题你的本地测试是发现不了的
你说“测试完没问题”，这通常只能说明：
- 你的规约与你的实现一致
- 你的代码在你的测试边界内成立
但多人并行时，真正麻烦的经常不是这个，而是下面几类问题。
1. 你的分支内自洽，不代表和别人的分支自洽
例如：
- 你把订单状态改成
CREATED -> PAID -> FULFILLED - 另一个人把退款流程改成只能对
DELIVERED状态发起 - 各自本地测试都过
- 合并后状态机拼不起来
这里问题不是“你的代码错了”，而是两个局部正确，组合后错误。
2. 你的测试验证了功能，没验证“共享契约”
比如你改了接口字段：
- 你把
status拆成两个字段 - 你的服务内测试全过
- 但下游还按旧字段消费
你这边绿灯，不代表系统绿灯。
3. AI 会强化“局部闭环正确”，但不天然保证“全局一致”
AI 最擅长的是：
- 根据当前输入补全实现
- 让某个局部模块看起来完整
- 按你当前 spec 生成合理代码
但 AI 不会天然知道：
- 别的组员有没有并行改同一个领域规则
- 主干上最近有没有语义变化
- 你这个 spec 是否破坏了跨模块不变量
所以 AI 提高的是单分支产出效率，不是自动解决多分支语义一致性。
所以，“提前暴露”到底指什么
这句话只有在下面这些前提成立时才对：
情况 A：规约先评审，再实现
流程是：
- 提 spec 变更
- 团队先对业务语义/接口契约/边界影响做评审
- 评审通过后再让 AI / 人类去实现
- 然后合并代码
这时很多问题确实会在代码之前暴露，比如：
- 术语冲突
- 状态机冲突
- 契约破坏
- 兼容性风险
情况 B：规约和测试资产是共享的
例如：
- 主规约是统一版本
- contract test 从 spec 自动生成
- CI 会校验接口/事件/schema 是否兼容
- 有跨模块验收用例
这时你一改 spec，就可能立刻触发：
- 兼容性告警
- 依赖方测试失败
- 共享样例不通过
这也算“提前暴露”。
情况 C：团队真的把 spec 当作 merge gate
也就是：
- 不是“改完代码顺手更新文档”
- 而是“规约不通过，代码不允许进入主干”
只有这样，spec 才是协作面的第一道闸门。
你现在描述的，更像哪一种情况
更像是：
Spec-assisted branch development，而不是严格意义上的 Spec-governed collaboration。
也就是说，spec 主要帮助你和 AI 在单分支内快速产出，但它还没有成为团队的公共协调机制。
于是冲突发现时点依然主要在：
- 合并主干
- 联调
- 集成测试
- 线上验证前后
这完全合理，也解释了你为什么不认可“提前暴露”这句话。
我帮你把这个判断再说得更硬一点
如果满足以下条件，SDD 不会明显提前暴露冲突
| 条件 | 结果 |
|---|---|
| 每个人都在自己分支单独改 spec | 规约冲突在合并时才出现 |
| spec 不做先行评审 | 冲突不会前移到设计阶段 |
| 测试只覆盖本模块 | 跨模块冲突难以提前发现 |
| AI 只读当前分支上下文 | 容易生成局部最优实现 |
| 主干没有契约兼容性校验 | 共享接口问题到集成时才爆 |
所以你的直觉是对的： SDD 不是天然的“冲突前移器”。
那为什么很多人会说它“前移问题”？
因为他们默认了一个前提：
spec 是多人共享、先于实现、并受流程约束的。
但这个前提一旦不成立，SDD 的效果就会退化成：
- 更快写代码
- 更快生成测试
- 更规范地描述需求
而不是：
- 更早发现团队协作冲突
你这个问题背后，其实是在区分两类“问题”
第一类：单分支内部问题
比如：
- 需求没描述清楚
- 边界值漏了
- AI 生成逻辑不完整
- 单模块测试不过
这类问题，SDD 确实容易提前发现，因为你在生成代码前就得把规则写出来。
第二类：多分支 / 多人协作问题
比如：
- 两个人改了同一个核心概念
- 上游字段变了，下游没同步
- 两个模块各自正确，但组合错误
- 一个规则在 A 域成立，在 B 域被破坏
这类问题，只有共享规约 + 共享校验 + 合并前治理 才能前移。 光有“先写 spec 再让 AI 生成代码”并不够。
一个更准确的结论
我建议把原来的话改成下面这样：
SDD /OpenSpec 不是天然减少冲突，而是提供了一个“可前移冲突发现”的载体。是否真的前移，取决于团队是否把规约纳入共享评审、契约校验和主干治理。
换成更直白的话就是：
- 你自己一个人用 spec + AI 写分支：问题不一定提前暴露
- 团队把 spec 当共享协议来管：部分问题才会提前暴露
你这个场景下，真正该关心的不是“spec 能不能提前暴露”，而是：
1. 合并前能不能发现“规约级冲突”
比如：
- 是否有人也改了同一份 spec
- 是否破坏已有字段/事件/状态机
- 是否影响其他模块假设
2. AI 生成前能不能拿到“主干最新规约”
如果 AI 只看你当前分支，它会把局部实现做得很好； 如果它还能感知主干契约、依赖模块约束、最近变更记录，冲突才更可能提前显现。
3. CI 校验的是代码，还是“规约与系统的一致性”
更成熟的做法是把下面几项都纳入 CI：
- schema diff
- API backward compatibility check
- event contract check
- state transition invariants
- cross-module acceptance cases
否则“测试通过”很可能只是局部通过。
最后一句话总结
你的反驳成立。 在“个人先改 spec -> AI 生成代码 -> 本地测试 -> 合并主干”这个流程里，冲突并不会因为用了 SDD /OpenSpec 就天然提前暴露；它依旧大概率在合并、 联调 、集成阶段才暴露。
真正能前移的不是 “spec 这个物件”，而是围绕 spec 建立起来的那套团队机制。
如果你愿意，我下一条可以继续帮你拆成两个版本：
- “为什么 SDD + AI 在单人开发里很顺，但多人协作时不一定更优”
- “如果要让 OpenSpec 真正提前发现冲突，团队流程该怎么设计”
我建议你看第 2 个，会更落地。
