这是让人做负担，让人先弄好顶层设计，但好累，我也发现另一个朴实无华的办法，模仿 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%难啃的骨头，遇到的奇奇怪怪的问题，人会发现很多代码和文档不能提现的“隐性”逻辑，把这些落到“外置记忆”中，才是提升最大的，但现在记忆系统的设计，还是五花八门，没有一个大家都认可的基准测试，都在摸索

码住

弄个 ai 脚手架吧，这种项目挺多的，做过的事情让 ai 记住，沉淀规范，别每次打开新对话 ai 都不知道之前做过什么，做错过什么，a 代表 XXX ，b 代表 XXXX ，c 代表 XXX ，用多了 ai 就懂你了（当然 token 花得也更多了），就不会拉扯你了

@nowant 不清楚，反正极致站起来狠狠蹬，之前 cursor 不限量，一个月蹬 1k 多刀，忒贵了，我自己弄了个 ai 脚手架，一个月，qoder 也调教得勉强能用
https://github.com/qxchuckle/lattice/

公司从 cursor 换成 qoder 用，费用总体便宜 2/3 ，但是用起来确实费劲，而且 Credits 怎么算的太不透明了，不过没限量，我狠狠蹬，换算一下 400 刀了，要是 cursor ，早就 1200 刀了，https://i.imgur.com/xxcpIX9.png

这就是现在 agent 的一个痛点了，多项目多支持非常不好，别说把项目放一个大文件夹里管，不现实，打开 ide ，ts 服务不挂，我看着密密麻麻的文件夹都要先挂了，更何况根本克隆不完司内的项目，上下游大大小小的包太多了，都是用到哪个包克隆哪个。所以我自己搞了个 skill+cli 的工具，在项目里加一个 json ，里面就存一个 id ，用来标识项目，ai 创建的任务、对话、规范沉淀，都关联 id 。下次开新对话 ai 自然知道要怎么找项目、怎么看现在做的需求涉及哪些项目。https://github.com/qxchuckle/lattice/
为了方便人管理项目，我之前也搞了个 vsc 插件项目管理 https://marketplace.visualstudio.com/items?itemName=qcqx.qcqx-project-manage

我也遇到了这个问题，重构一个大概 13w 行的包，必须古法的：整体架构、数据流，交给 AI 的：填充内容的部分，人为划分出小任务交给 ai 完成，并且用上 ai 脚手架，复利式迭代，让 AI 越用越懂项目

我感觉 rag 作为海量数据时，找出和关键词有相关性的内容，给 ai 去读还是有用的，不需要什么准确度，找到了全塞给 ai 自己判断。不然上下文不够

对，原本要再招一个人干活，现在变成给人配个 ai ，原本一天干一需求，变成两个需求多线程干，桌面切来切去，等 ai 回复，也不是需求有多难，就是干一件事的心流被打断，多个任务反复切换费脑子就累

@qiuyuerror #66 有空可以看看人月神话这书

毕业了才知道软件工程是门好课。
------
学习什么语言不重要，语言是工具，ai 也是工具，没有 ai 的时候速通一个语言最多也就 7 天，像 js 这种 3 天就能搞定，现在有 ai 了，学不学语言都无所谓了，有更好的工具就用，发展到自然语言编程更好，工具是有最佳实践的，就像有了高级语言，也还是需要很多人写汇编，搞芯片前端的赚得可多了，摆脱技术思维去看问题。
------
没有 ai 的时候，写代码的时间其实也没占多少，都是做做需求，维护下现有系统，真碰上重构、新功能开发，现在 AI 也搞不定，一堆没法写成文档的东西，怎么给 ai 讲，让 ai 发挥，等上线爆炸，1m 上下文还是太小了，等 100m 还有可能。我最近在搞一个重构，13w 行有效代码，45 个业务独立包，古法占了 70%，老代码里那堆死逻辑，shi 山，要复刻，各种取舍、业务风险都要人把握，这些不是技术的事情，看到渐进式加载、上下文压缩就想到小马拉大车。把技术看得太重了，业务和技术，拿出来总是吵架的话题。
------
学技术本质也就是在学用工具，现在学怎么用 ai 这么工具反而顺应时代。提供工具肯定是最赚钱的，淘金热边上卖铲子。

@maix27 #120 有啊，搞出来挺多 AI 产品了，业务上的，还有自用的，什么需求 AI 分析，全自动创建仓库写代码提 cr ，但都还是实验，碰上实际业务需求还是难绷，知识文档都在语雀上，迭代这么多年体量已经 boom 了，而且，有些东西 AI 就是搞不了，我现在又个重构任务，20w 行 tsx 代码，好几个包，和拆炸弹一样，AI 只能辅助我梳理原来业务逻辑，harness 那文章都强调单仓库了，而且还要测试自闭环，自动化测试根本就是天方夜谭 https://i.imgur.com/NIvxivj.png

写点 cli 工具、浏览器插件、司内自用软件这种，一个仓库搞定，没有复杂多包依赖关系，代码总量最多几 w 的，那现在 AI 随便写，3 天平地起高楼，也不用 cr ，自己点一点看看功能对了就行。
但是吧，司内重业务的代码，一个页面背后几十个独立包，依赖关系错综复杂，代码加起来快百万，AI 就省省吧，上下文不够的，现在的渐进式加载就会漏东西，只能辅助人处理，比如找函数的链路，某个参数到底有没有用到之类的，明确一个小功能点去改，改完几百行代码 cr 下也行，至于全自动整个需求让 AI 改就算了，包是进雷区的。
每次改这种维护了好几年的项目，就和拆弹专家一样

和 spec 驱动差不多？

公司开的 cursor ，这个月已经 100 多刀了