大项目中大家真的会用 Spec-Driven Development 吗？
https://openai.com/zh-Hans-CN/index/harness-engineering/ 中提到要把 Spec & Planning & Tasks 进度放进 git 仓库中，大家实践中真的会这么做吗？但是我看 codex 仓库内根本没这些东西，而且很多 Spec 他们都是放在的 Issue 中讨论的。
我自己也用 Openspec ，但实际使用中各种地方不顺手
- openspec 会自己生成一堆 design & propsoal 很多都是正确的废话，给人 Review 就很困难，找不到重点
- 执行完还是有些 Bug ，这种再写回到 Spec 让他修复感觉很 tricky ，明明是 AI 特定问题，结果却要写到给人看的文档中。
- 生成的 Spec 你要严格按照他的流程来，执行 Task 等等。但是加上 Bug 修复。总时间感觉不如用 Planning 功能，再加少量提示词修正顺手，还不用考虑后续文档和代码对不上的问题。
- 据说有人碰到过 Spec 合并 delta 对不上的问题。
请教一下大家日常怎么实践的？
巧了，我的选择是把交易策略 SPEC 化，在 strategy studio 编辑定义 SPEC ，然后发布到策略服务中运行。
AI 主力编程的场景下，人类可能更适合去做 SPEC 定义的工作。
我的建议是，自行定义 SPEC 规范，反正都是丢给 AI 实现，这样 AI 会有更全面的理解和支持。
最近在研究和尝试 sdd ，我觉得 plan mode 和 superpowers 算是轻量单次的 sdd ，这种思想是对的。在生成代码前先通过跟 ai 多次交换意见并最终对规格达成一致，让 ai 对任务内容有全面理解后再开工。可以很大程度避免 vibe 的漂移和幻觉问题。
想更深入地在整个项目贯彻 sdd 的话就会面临维护全局 spec 的挑战。仅仅将每次任务的 spec 存放在那里不仅很难作为一个体系化的知识来参考，还有可能前后矛盾。所以 openspec 用 delta 机制来更新 spec ，并用 Delta 来驱动代码变更。理论上没错，但这不是一个很强的约束能保证代码忠实反映 spec 。
复杂度只会转移不会消失，只是从维护代码转移到维护 spec 了。随着 ai 的上下文窗口增长，未来可能仓库里只有 spec ，想要 code 的时候就一股脑扔给 ai 瞬间 code 就完成了，或者直接让 ai 将 spec 当 system prompt 来模拟业务系统。
试试 superpowers 加个记忆定时提取知识库，基于 skill 比基于固定 command 组织工作流更灵活。基于记忆提取比基于 spec 维护知识库更简洁。个人感觉大模型工具用起来要符合直觉。强行用工程化手段约束模型是工程师的一厢情愿。不懂工程的人往往 vibe coding 反而有更灵光的情况