rocmax

有个更轻量的工具 cc-sdd ，不将 spec 看作唯一真相来源，而是看作模块间的契约，它的 spec 粒度比较大，但里面搞了很多审核节点。

@moudy spec 就是为了让 ai 全面理解任务内容，spec 后面还有 plan 和 task 两个环节，切 task 就是为了不爆 context 。superpowers 会启动多个 subagent 处理 task 。spec 中有 Acceptance Criteria （验收条件），testcase 对应 ac 条目生成。

@KingFong 准确的说倒不是讨厌用 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 来模拟业务系统。

这个月 Claude1k+刀

补充一点，不要给别人人生建议，混好了是自己努力，混差了是你的黑锅，切记切记。

既然问这个问题了，说明既没下什么功夫收集信息，本人也没什么强烈意愿，那么最保险的就是花钱解决。

spec driven development ，ai 生成的代码成本已经可以忽略不计，那么人应该从维护代码转为维护 spec 。代码由 ai 根据可验证的 spec 检查。