现在鸿蒙拿什么写比较多的，还是用那个 arkts 么，以前好像连 npm 生态都不兼容？，貌似还有个仓颉吧。跨端框架那些支持咋样了

我目前的一个实践：
前期：
设计一个能让 AI 记录试错、任务，并能提供信息给 AI 的环境。
中期：
正常使用 ai ，ai 做错了，要指出，并且让 ai 自己记录。对话中有人为指出的“经验”要自动记录。
ai 写的代码，逐行 cr ，脑跑业务逻辑，测试环境验证，遇到问题无论大小都让 ai 改，哪怕只是一个参数传错了，也要在对话框告诉 AI 为什么错，应该怎么做。
后期：
ai 已经认识了大部分项目，养好了，现在你在做“熟悉”的项目和“熟悉”的任务时，可以不需要 cr ，或者只是一目十行大概看看。最后只需要在测试环境验证。

另外，我发现，现在我只需要几句话，就能让 AI 经过 5 次上下文压缩，一次对话完成了一个要修改 3 个仓库、50+文件的复杂任务，即使我的提示词里并没有让 ai 一次完成长任务，可能是 ai 获得了足够多的信息，自己判断了能够一次对话完成。另外最初的提示词我也是自然语言描述 3 个仓库的名字，“参考旧**组件，将近期新的提交迁移到新的**和**组件”，因为之前已经在这三个仓库里做过了很多任务了，所以 AI 自然知道对应的是哪些仓库，本地位置在哪。模型用的 glm5.2

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

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%难啃的骨头，遇到的奇奇怪怪的问题，人会发现很多代码和文档不能提现的“隐性”逻辑，把这些落到“外置记忆”中，才是提升最大的，但现在记忆系统的设计，还是五花八门，没有一个大家都认可的基准测试，都在摸索

码住

弄个 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 回复，也不是需求有多难，就是干一件事的心流被打断，多个任务反复切换费脑子就累