Chuckle

现在还是 cli + skill 最方便
以后模型自己对着各种系统，并发无数个子代理，给一本说明书自己读去，自己试错，点了什么会有什么后果，产生什么反应，所有可能性，全跑一遍，就像人类幼崽刚摸到电脑一样，也是乱按键盘吧

cursor 吧，用不了国外的就 qoder 也还行，至少极致是套皮 opus 好像，codex 配 vsc 也行。国产模型的话，用 glm5.2 / 5.1 ，千问的 3.7max 小的需求、改动明确的任务可以做。

理论来说，异地要手机号接码啥的操作，已经基操了，没有确实有问题

这是让人做负担，让人先弄好顶层设计，但好累，我也发现另一个朴实无华的办法，模仿 AI 训练，设计一个环境，让 AI 自己无限试错碰壁，闲着没事，把做过的需求再让 AI 做一遍，然后给正确答案，AI 自己对比自己做错了什么，做得更好了什么，记录下来，沉淀 spec 之类的，这个工作流我养了一个月了，前两天感觉 AI 灵智开了，仿佛看到原子弹爆炸.jpg 。
我开了一个新对话，只输入了一句话，“现在把另一个扩展适配新组件”，这句话背后，需要涉及 4 个项目仓库，还要对比新老组件 api ，还要看之前的组件怎么迁移的，扩展怎么写，等等潜在逻辑，传统让 AI 辅助我弄的话，起码半天，而且很累。但现在它 10 分钟，在单个对话窗口，一句话，甚至触发了 5 次上下文压缩，还能保持工作流。工作流里从来没有要求过要一次完成长任务，但它就是做到了。最后只有两个细节差异逻辑不对，我让它自己再检查一遍就发现了。

@Chuckle 多 agent 对抗是个方向，毕竟我现在最常干的事情就是让 AI 自己再审查一遍代码，比如“逐行代码对比新老组件的上层扩展适配是否一致，有无逻辑、功能、细节差异，以及潜在的风险”，往往我自己 cr 前先问个几轮，就完成了 99%了能挑出来不少风险和毛病，但这句话要是扔 rules 或者 skill 里貌似不起作用，ai 不会完成代码后自己检查，因为这种提示词和具体业务有关联，找不到黄金提示词，但有另一个 agent 自动介入的话，就能根据业务情景，自动生成这段话

界面好看，有空试试，不过学习一个新工具成本还高，现阶段专业的还是脱离不了 ide 或者 codex cc 成熟的 agent 生态，以及 vb 上绕不过去的 codex app 大山。如果给成熟的 agent 做“外围插件”，什么记忆系统之类的，难免会受限，像支持 hook 、plugin 的 agent 也没多少，更别说更深层的定制改动了，不够自由，但自己做 agent ，同质化和换工具成本高。如果只是免费注册用 api ，推广的吸引力还是不够，毕竟凹凸曼大善人，时不时来个 bug gpt5.5 就 free 了，还有一堆中转站。
我实践时也发现 op 所言，它完全缺乏全局观，agent 本身只是个“操作系统”，在复杂老项目中，完成需求任务，更多的瓶颈不是上下文大小、agent 能力，而是上层应用，只有 agent ，AI 不知道业务架构，AI 无法从一个页面上，定位到你成百上千的仓库改哪个文件，AI 无法完成测试闭环，这背后还有需求分析、业务数字化、代码地图、质量审计的事情，以及模仿阿尔法狗进化的老路子，让 AI 自己学习经验，试错才是最宝贵的，这也是我边做需求边做 ai 工作流头疼的点。
多 agent 弄个对抗网络的设计，之前好像也见过，但实际开发并不会像 demo 那样一段话生成***，自由度没这么高，也不是单仓库项目，往往是涉及多个仓库，多个包。
多 agent 对抗、规范沉淀，加上需求复杂性导致不可避免的上下文压缩，感觉有让 AI 偏离原有的产品 prd 设计方向的风险。
另外对比图也过于夸张了，opus4.7 不至于，一句话生成***不仅听腻了，感觉也并不是好的案例，先弄一个网盘系统，再用标准的产品 prd ，对比看或许更明显。

我近一个月实践下来，大模型其实能力是够了，上下文也不是问题，对于大型软件项目，瓶颈在上层应用设计，需要有一个决策，让公司所有人都用上 ai ，需要有一个工具，在人和 ai 不断对话过程中，自动记录经验、试错过程，ai 能完成的 90%工作，那不是重要的，对于剩下 10%难啃的骨头，遇到的奇奇怪怪的问题，人会发现很多代码和文档不能提现的“隐性”逻辑，把这些落到“外置记忆”中，才是提升最大的，但现在记忆系统的设计，还是五花八门，没有一个大家都认可的基准测试，都在摸索