要不是底层开发的话 mac 直接用也没啥差，非要 linux 的话 docker 起一个，更原汁原味的就 qemu VMware ，唯独虚拟机里跑桌面版 linux ，我从来没鼓捣完美过。

够不上清北那就复交之后就是浙大北航，关键是选城市然后选个电子信息类专业，进可机器人芯片开发，退可转计算机 ai 。高分去什么军校，部队没关系毕业扔新西兰悔死你。

写到 AGENT.md 或者 CLAUDE.md 里

没有 不能 对 AI

@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 就行了。