公司从 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 多刀了

vscode 族群 https://i.imgur.com/agAJ0Rd.png 现在用 cursor

@linhey #8 看了，我们一个微前端 app 入口 50 多个依赖包，依赖包还有依赖包，业务组件都是封装抽离的，构建注入这套不现实，在看 bippy 动态注入的方案了

skill 本身就是个 tool ，也就是个 mcp 协议的东西

@linhey #5 组件在依赖包里怎么办，发到生产包的总不能编译时注入 debug-data 属性吧 https://i.imgur.com/MAyk5GN.png

@Chuckle 只改 app 的构建，能做到给安装的依赖包产物里的组件加上 data-***的额外信息么

最近刚好也需要个从页面元素定位到源码的方案，为的也是 AI 能知道要改哪里、影响范围评估等等。
umi+qiankun 微前端，要改的东西都在独立包里，app 工程就是个页面入口，有时候套快 5 层包人找起来很麻烦，本地只跑 app 的 source map 也没用，安装的包产物都是服务器构建出来的，构建时在节点上注入大量信息也不太行，除非每个包都构建两个版本，构建生产 app 用的 和 开发时带信息的产物。
我现在做法是提取 dom 特征节点（还是有注入一些特殊属性的）、url 路径等元信息，克隆所有的几百个包到本地，让 AI 自己先暴力找，确实能找到，就是慢，也费 token 。优化的话，找到了就把信息落向量数据库里，类似 RAG 一样，特征信息变动还是少的，特征节点嵌套结构也稳定，下次找就快了，至少能快速找到对应包工程，再去定位具体代码。
不过，如果从 React 本身入手，模仿 React Scan 运行时注入应该更好？
另外 AI 写代码确实好用，就是测试起来太麻烦了，很难自闭环，业务链路长又大，e2e 测试的时候没数据，或者接口报错，AI 能自己 call 后端，或者自己造、自己修（

光结构化替换的话信息本身没变，对 AI 来说没区别，要是塞多无用中间代码，200k 上下文里就 1k 有效代码的话，信息多了，对 AI 才有点麻烦

nestjs ，司内内部服务、监控之类的都用它，业务还是用 java