@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+刀

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

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

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

你们的项目过不过是老师说了算还是用户说了算。
难肯定是难，前端就是个 Android app ，想显示 3d 效果最好用 unity 或者虚幻搞，界面弄好一点。后端你们自己训练也不现实，找找有没有现成的 yolo 模型，获取输出写 if else 就行了。

本月刚过半，用了 500 刀

@kinkin666 单卖啤酒的话毛利能到 80%，就是全倒了也赔不了多少。关键是有没有生意，一年中也就卖半年，天冷了不好卖。

这不就是 axios 投毒的套路吗？ op 在维护啥重要软件？

看着挺好的，想起青岛的袋装啤酒了。鲜啤确实比瓶装的好喝，可以考虑配煮花生什么的。

@lynn1su 这那就是防 prompt injection ，Claude code hooks 可以做一些检测

skill 就是个文本文件，我手动把广告删了不可以吗？除了讨人厌能有啥用。