别的帖子喜欢先解释/讲道理, 但我这里直接说结论/结果/怎么用, 如果你觉得有用/说得对, 后面才是我的解释
augment code的上下文引擎 augment context engine提供了一个工具codebase-retrieval
这个工具能根据冷启动指令(就是第一条用户消息)去搜索代码库, 打个比方说人话
你说了这么一个命令
把页面中的请求方法改为统一封装的Axios工具
augment code的系统内置提示词会注明调用codebase-retrieval工具, 当这个工具被LLM调用时, 工具的内置描述就会让LLM主动发散传入搜索词 ,
(这一切都是我猜的, 工具是闭源没法看到实际情况, 但我的描述已经尽量贴近实际情况来)
去找所有和网络请求有关的内容, 包括但不限于fetch/ajax等
比如你页面原本是ai写的fetch方法
fetch("http://example.com/movies.json")
.then((response) => response.json())
.then((data) => console.log(data));
他就会给你换成getMovies(), 而这个方法又会在api列表那边单独配置好, 走你的Axios, 从而自动处理cookie/token/res err msg
看到这里有的人可能就皱眉+质疑 或者说不想看了, 觉得完全没什么含金量, 会反驳我说
你这个cursor/Trae/cc/droid/roo不是也能做到?区别在哪?意义又在哪
你先别急
当你面对巨型代码库, 比如压缩完都有700-800kb的无依赖.7z最好级压缩包, 这种量级的项目
如果我告诉你, augment code通过augment context engine(简称ACE)提供的codebase-retrieval工具, 也能在3次调用之内完全理解问题呢?
我这只是举了第一个浅显的例子 实际上ACE在体量越大的项目上, 横向对比时, 发挥越好
比如一个qiankun子应用, 你告诉他,
在哪个哪个系统, 哪个哪个导航, 哪个哪个分类, 新增一个页面, 接口文档是
http://example.com/movies.json. 必须保持组件复用/高内聚低耦合的开发指导原则
通过ACE的发散机制自动去找项目里出现过的, 相关的组件/方法/工具, 调用3~5次codebase-retrieval工具基本上都能收集完成, 再把收集到的信息喂给Claude4.5
此时你再去对比CC/cursor/droid/Trae/codex 他们一个个去readFile, read directory, 一个文件几百上千行, 一个grep搜索返回 一大堆和用户指令沾边但不相关的内容 就这么丢给LLM干扰 两边的效果谁更好, 一目了然 你再看看呢?
后面是讲道理环节了
我们都知道大上下文窗口时LLM会表现不佳
现阶段的LLM作为文字生成器而不是真正的会思考的器灵
受干扰越多, 越影响发挥,
特别是用户基本上没有几个用正经规范的LLM prompt来和LLM交流
要么对骂, 要么偷懒, 要么就是用那种唐氏词(唐氏提示词)
什么各种先执行XX模式, 再执行XX任务, 最后执行XX流程
我的评价是纯唐
就比如gemini虽然提供了1m, 谁用得完? 都是到一定程度就会开新对话
在AI编程环境下, prompts要做从来就不是用LLM生成的玄之又玄的人类完全没法读懂的规范
唯一要做的就是给LLM提供最关键的信息 比如让他调用工具/提供给他最精准的问题段落/明确的指示去陈述任务/避免LLM处理情绪输出
而ACE就做到了这一点: 给LLM提供最精准/最相关的上下文
所以在augment里, 你唯一要做的就是告诉LLM,用ACE提供的codebase-retrieval工具去查找你要做的修改内容最相关的信息, 然后告诉LLM, 该修改成什么样
为什么augment比cursor/cc/droid/codex要强?
你能看到这里, 相信不用我解释, 你也知道为什么augment要强于cursor了 augmentcode其实是个很烂的插件, 几乎没有记忆和规则prompts能成功阻止他在大上下文之后写markdown/测试/跑开发服务器
有的人可能要说我你这时候怎么又左右脑互搏了
强的从来就不是augmentcode vsix, 而是ACE
ACE相比于传统codebase_search tool 原理强在哪, 我也不知道, 但我能明确告诉你的是:
- 去重.
-
- 是的, cursor/roo/Trae的codebase_search工具会寻回重复的内容喂给LLM, 具体表现在一个文件出现两次
- 精准.
-
- 只要你能用人话说得清, 不管中文英文, ACE必定会给你返回和你描述的最相关最精准的内容. 如果没找对, 那只能说是你的描述问题. 他已经很尽力了. 再不行, 新对话+分步骤思考期间反复调用
codebase-retrieval工具是备用解法, 适用于完全不懂代码/不理解项目的人
- 只要你能用人话说得清, 不管中文英文, ACE必定会给你返回和你描述的最相关最精准的内容. 如果没找对, 那只能说是你的描述问题. 他已经很尽力了. 再不行, 新对话+分步骤思考期间反复调用
- 简洁
-
- 我何出此言? rooCode的codebase_search会返回不计其数/无上限的语义搜索结果, 这个问题似乎没有解法, 所以rooCode从软件层面给了一个寻回文件上限的设定, 比如他默认设置50, 那就最多会返回50个语义搜索结果最相关的文件
-
- Trae的search_codebase和rooCodecodebase_search坐一桌, 光抄不带脑子, 我让他找development, 他连queryDev方法都给我寻回了, 这种内容喂给LLM, 你说能解决问题, 那就真有鬼了, LLM从文字生成器进化成器灵了
-
- 数量少, 如果你用过auggie, 你就知道了. auggie里多次调用ACE, 通常只会寻回个位数X~18个文件, 不像rooCode那样不设上限的返回, 没有多余的废料喂给LLM
我现在问你, LLM通过ACE拿到如此精准的上下文 他为什么还不能提供修改成功率/准确率/命中率? 他为什么还不是地球上最强的AI编程工具?
关于我对ACE的猜测
通过augment code官网的博客可以看到去年年底的时候他们就在科研ACE了 BYD公司都一年了, 还不搞支付宝收款, 到底在想什么集贸
比rooCode在今年早期推出的codebase_search要早得多
我猜测 ACE应该是用LLM去接了一层嵌入模型从向量数据库中搜出来的语义搜索结果 LLM起到的作用是额外做了语义搜索结果筛选, 在他那边处理完内容以后, 然后最后才把内容返回给编程用的LLM 但这只是我猜的, 如果自己复刻一个, 效果如何, 我也不知道, 前面的内容你们也看到了, 我就会写写网页, 什么AI后端人工智能, 我全都不知道, 我只是会用augment code
内容不设等级, 允许转载, 注明出处即可, 最好帮我发点自媒体
写这篇文章的目的
如果你能看到这里我很高兴, 希望这篇文章能让其他AI编程开发工具意识到 精准的上下文提供工具才是AI编程的灵魂
特指Trae和GLM/KIMI, 这三家公司, 别再走歪路了 纯靠readFile/read directory 这两个tool去读文件, 那得读到什么时候, 既浪费显卡性能又浪费用户token, 又浪费水电 能不能科研点TRAE/GLM/KIMI ContextEngine这种真正有用的东西
其实这是我压箱底的焚决, 也就是通过prompt让其主动调用codebase-retrievaltool, 我把他发出来是因为augment试用今天起我也嫖不到了, 必须要信用卡支付, 然而我没有能付外币的信用卡, 所以干脆发出来算了
其他没有信用卡的朋友希望你能加入和我一起给support.augmentcode.com发工单, 让他们推出支付宝收款/KIMI/GLM/QWEN3 MAX+ACE, 甚至纯ACE, 无消息次数的套餐我也愿意付费
因为ACE实在是太超模了
有人说我命令ai公司搞笑的
- kimi现在就是想做Claudecode呗, 都发JD了
- Trae现在纯对着cursor照搬, 结果嵌入模型用的效果烂成啥样我上面说了
- 不扩大影响力, 怎么让他们懂现在力大砖飞的方向是错的? GLM就靠卖token随便用硬蹬, 不喂上下文, 浪费水电算力时间
- 能复刻出来一个ACE这样的工具, 不管你前面用了多少上下文窗口, 调用完ACE绝对稳定解决当前问题
还是那句话不是希望国产好起来, 谁会说他? 我直接无脑给国外付费不就完事儿了么?