rocmax

@MX11XM 理解，我经历过每天上班前要做心理建设的时期。提早抽身不是坏事，别给自己搞抑郁了。

@MX11XM 如果眼下这摊是你一个人在管，领导认为进度有问题的话不妨先跟他谈谈？说了现状和困难他不给你解决的话再说？

经历过，这种情况明显就是 pm 无能。2 年前呆过一个项目，pm 不懂技术，你给他说这个功能需要 2 天实现他一定怀疑你虚报了，你给他说原因他又听不懂。总之就是技术我不懂但你别想蒙我那股劲，上面给他压 deadline 他又不敢提意见，回来就开会说为了提高效率原来 2 周一个敏捷开发周期改为一周。后果就是一周 5 天 2 天在开计划会总结会，提高了个蛋效率。

有个更轻量的工具 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+刀

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