1. 为什么“AI 写代码”最近突然又换了一个主角

1.1 先认识一下这位“新王炸”是谁

这几年 AI 编码工具的更新频率，说实话已经快到让人麻木的程度。今天这个大模型说自己的代码能力第一，明天那个编辑器说自己能自动改完一个项目，用户嘴上说“好厉害”，手上还是老老实实复制粘贴、手动处理冲突。但最近圈子里聊的火力明显集中到一个名字上——Augment。

它的标签很抓眼球：SWE-bench 冠军、免费开放、专治复杂大项目、直接对标 Cursor。这几个词组合起来，确实容易让人产生“又一个来抢风口的产品”的怀疑。我最初也没有太当回事，直到一个快被重构折磨疯掉的朋友非要我试试，说它在“读旧代码”这方面的表现和一般聊天式工具有本质区别。于是我在手头一个大概 60 万行、经历过多人维护、注释早已和代码脱节的老服务项目上，认认真真用了小半个月。

如果只用一句话概括我的感受：它确实不是来抢 Cursor 位置的，它更像是来抢“架构师助理”这个位置的。Cursor 擅长陪你快速写代码，Augment 则倾向于先把自己泡在你的整个代码库里，然后以近乎审问的方式从你嘴里问出需求边界，再一次性改完一堆文件。这种模式放在小 Demo 里会觉得笨重，但放进大型项目，体验会完全不一样。

1.2 SWE-bench 冠军这个头衔意味着什么

SWE-bench 并不是普通的“写几个算法题”排行榜。它从真实开源项目的 GitHub issue 和 pull request 里，抽出了大量“需要跨文件、跨模块修改才能通过测试”的真实任务。工具最终要把补丁写出来，然后在隔离环境中运行测试，看能不能让原本失败的测试用例转绿。

这意味着它考察的，不是“你能不能生成一段语法正确的代码”，而是“你能不能在一个你不熟悉的庞大代码库里，自己找到问题位置，理解上下游逻辑，改完还能不破坏别的东西”。这和开发者在企业里修一个年久失修的后端模块，面临的情况几乎一模一样。

很多聊天式 AI 工具在 SWE-bench 上分数不高，不是因为模型蠢，而是因为它们默认只拥有你粘贴给它的一小段代码。一旦要自己翻目录、查引用、跨文件追踪调用链，它们就开始一本正经地胡编接口名，或者把已经废弃的旧函数当作当前代码来改。Augment 能在这个榜单上拿到头部名次，说明它的产品形态往“全仓库智能体”方向走了很远，而不只是换了个更大的上下文窗口。

1.3 免费开放，搅动的是整个选型市场

这个产品最让我意外的，反而不是能力，而是“免费开放”这个决定。大型项目级 AI 编码工具的算力和索引成本，明显比普通聊天补丁工具高好几个量级，愿意把这种能力拿出来让人免费体验，多少有点打破现有市场格局的意思。

对开发者来说，免费意味着两件事：一是你可以毫无心理负担地在真实项目上做评估，二是团队采购前能完成一次低成本的可行性验证。我见过不少团队因为“怕买错”而一直停留在复制粘贴补全工具的阶段，免费策略正好把这道心理门槛拆掉了。所以，无论你最终是否选择用，都值得花时间摸一下它的边界。

2. 为什么大项目是 AI 编码的“照妖镜”

2.1 上下文窗口大，不代表真的理解你的代码库

很多人选 AI 工具时会陷入一个参数误区，以为“上下文窗口越大，就越能处理大项目”。实际上上下文窗口只代表模型一次能看到多少字，并不代表它能判断哪些字有用。一个几十万行的工程，你把窗口拉到几百万 token，模型照样不知道该去看哪个文件。

这就好比把一个人丢进一座藏书楼，告诉他“这里的所有书你都能看”，但没告诉他该翻哪一本。没有检索和导航能力，窗口再大也只是堆砌噪音。那些号称大上下文的编辑器，实际用起来经常会犯一个毛病：紧盯着你当前打开的文件，把别的模块里明明已经定义好的工具函数，又从历史对话里“重构”了一遍。

Augment 的做法不太一样。它更像一个先做功课的分析员，在你提问之前就通过代码索引建立了对项目的整体理解。当你问“这个订单状态为什么会从待支付直接跳到已完成”，它拿到的不是当前文件里那几行状态枚举，而是包含了状态机定义、触发事件、定时任务、回调通知等多个模块的完整链路。

2.2 检索式“找片段”和全库静态理解，完全是两回事

上一代 AI 编码工具为了解决“找不到代码在哪”的问题，普遍走的是 RAG 路线：把代码切块、向量化，用户提问时检索最相关的几个片段，再丢给大模型生成答案。听起来合理，实际用起来问题很多。代码不像文档那样可以随便切块，一个类的核心逻辑可能分散在五个文件里，检索到的片段往往有上下文缺失，模型只能顺着残缺的信息去猜。

我在一个交易系统里测试过，找一个“优惠券触达用户”的功能入口，某些工具返回的全是参数定义和空函数壳，完全跳过真正实现逻辑的那一层。因为那一段逻辑的关键词和提问词并不直接匹配。这种“答非所问”的体验，在小项目里不常见，在大型项目里天天见。

Augment 走的是另一条路，它更像把整个仓库做了一次多维度静态分析，函数之间谁调用了谁、接口在哪里被实现、枚举在哪里被消费，这些关系在索引阶段就被组织好了。它回答问题时，不再依赖“短文本向量相似”，而是真的沿着调用关系做推理。

2.3 大型改造真正要求的是“会读代码的助手”

我拿一个具体的重构场景来说。有一次我要把一个老支付网关里的“同步回调”改成“异步通知+对账补偿”，这不是改一个函数就能收工的活，涉及到网关适配、内部事件发布、回调状态存储、超时重试策略，还有至少四个微服务之间的接口约定。

传统对话式工具在我描述完需求后，通常只会给我一个“整体思路”，然后建议我手动改哪些文件，再帮我把第一个文件里的代码改掉。等我改到第二、第三个文件时，它已经忘了我之前定下的字段命名和异常处理方式。

Augment 的风格是把整个改动当成一个工作任务来管理，先建立修改计划，再按依赖顺序逐文件定位、修改，最后补上重试和补偿逻辑。虽然它给出答案的速度比普通补全工具慢不少，但那种“不用我在三个服务之间来回粘贴代码片段”的体验，是真实存在的。

3. 亲自上手：把 Augment 用进一个 60 万行的老项目

3.1 安装与索引：别跳过“过一遍代码”的步骤

现在的安装流程已经很简化了，基本上就是装插件、登录、把项目根目录指给它。真正需要注意的是首次索引阶段。大型项目首次建立索引需要的时间并不短，我那个 60 万行的项目，完整走完大约花了十几分钟，期间 CPU 占用明显升高。

很多人习惯装完工具就立刻开问，结果发现它给的答案和普通工具没什么两样，就开始吐槽“不过如此”。实际上索引没建完时，它根本不了解项目全貌，只能退回通用检索模式，效果当然打折。

建议在任何包含大量历史代码、第三方依赖、代码生成器的仓库里，都把索引过程跑完再开始正式提问。中途不要反复改分支或者大改文件，否则索引一致性的校验会让后续响应变慢。这个等待虽然磨人，但它是后续一切体验的地基。

3.2 大项目提问的四段式模板

在大项目里问问题，提问方式直接决定答案质量。我自己实际用下来，最有效的方式可以拆成四段：

第一段是目标，说清楚你要什么结果，不要只描述痛苦。例如“让定时清点任务失败后自动进入可重试队列”，而不是“这个定时任务总是失败”。第二段是边界，明确指出哪些模块允许被修改，哪些是只读的。比如“只能改 worker 模块，结算服务接口不允许动”。第三段是参考，给一个你认为可以模仿的相似实现。第四段是验证，告诉它改动完成后应该执行哪条命令，或者看哪个测试用例。

这种模板并不新鲜，但 Augment 对结构化描述的理解和执行度，确实比普通工具高得多。它给出的修改方案往往能直接贴合项目已有的代码风格，而不是另起炉灶引入一套新的命名体系。

3.3 一次跨模块事件链路改造的真实操作记录

我挑一次有代表性的任务说说实操过程。任务本身不复杂，给现有的事件上报接口增加一条“失败转离线文件”的兜底路径。改动点包括事件模型字段、上报接口校验、落盘格式、定时重推逻辑，还有一套测试桩。

我先按四段式把目标、边界和验证命令写清楚，尤其是“不要在已有文件里新增第三套时间格式”这种约束。随后 Augment 给出的计划里，除了把目标文件指认出来，还标了一段它从索引里找到的“历史相似实现”，也就是三年前就有的一个文件补偿模块。这个补充非常关键，没有全仓库索引能力，普通工具不可能从这么远的地方找到可参考样本。

确认计划后，它陆续修改了五个文件。我自己做代码评审时发现，大部分改动和我手改的路径一致，个别地方它还会比我更保守，比如在落盘逻辑里多做了一个目录不存在则创建的判断。整个过程体验下来，它的角色更像一个“不厌其烦的老员工”，而不是一个“随时接话的新实习生”。

3.4 三个极大增加成功率的设定习惯

第一个习惯是每轮对话只聚焦一个工作流，不要在一个会话里既改 A 模块又改 B 模块。混在一起会让它自动扩大修改范围，容易出现本来只想加个字段，结果把相邻的构造函数全重写的情况。

第二个习惯是让它先输出方案，等确认后再执行。Augment 默认也会先展示计划，但如果你跳过直接要求“赶紧改”，它会默认你同意它的一切判断，这在大项目里挺危险。

第三个习惯是注意项目里被忽略的配置文件。它特别看重.gitignore的语义，有时候会把生成代码误当成手写代码来处理，导致改错目标。把生成目录明确标注成“只读”，能避免大量无效修改。

4. 和 Cursor 摆在一起，到底谁更适合谁

4.1 我从体验上把它分成五个维度

市面上讨论声音最大的对比，就是 Augment 和 Cursor。在我看来，它们已经不属于同一类工具了，更准确地说，Cursor 是一个“写代码加速器”，Augment 是一个“代码库分析师兼改造执行者”。为了让大家更容易理解，我从实际体验里拆了几个维度：

这五个维度罗列出来后，其实很明显能看出来，它们不是替代关系，而是分工关系。Cursor 解决的是“你这行代码帮我怎么写”，Augment 解决的是“这个模块的问题帮我定位和修好”。

4.2 这些场景我会选 Augment，那些场景我仍会用 Cursor

实际开发里，我遇到三种场景会坚定地选择 Augment。第一种是接手历史项目，项目里充斥着只在某个角落出现一次的魔法数字、隐式全局变量、跨模块副作用，你看代码半天都不知道从何查起。第二种是重构前的全局调研，想知道“这个老接口到底还有多少处在用”，以前只能全局搜索再人肉排查，现在可以直接问它。第三种是有明确验收条件的跨模块改造，就像上面提到的事件链路，它的计划能力和执行一致性让人省心。

反过来，也有几类场景我依然觉得普通对话式工具更快。比如你正在写一个新文件，需要自动生成一个 DTO 结构、补一个单元测试模板，或者快速把一段 JSON 转成结构体，这些轻量操作没必要动用全仓库级别的分析。又比如你在跟前端框架做试错，需要不断调整一小段 JSX 看渲染效果，这一步一反馈的节奏，也更适合 Cursor 那种轻快模式。

4.3 与其“硬刚”，不如“双打”

这个问题的答案，说出来可能让一些“站队党”失望，但它在我的工作流里就是事实：两个一起用，比二选一强得多。

我的习惯是，把一个中型功能拆成“探索”和“执行”两个阶段。探索阶段用 Augment 摸清代码结构、找出所有相关依赖、确认调用链，它会画出清晰的模块地图。执行阶段里，遇到特别琐碎的增删改查，我用熟悉的轻量工具快速完成，毕竟这一段我完全清楚自己在干嘛，没必要让重型工具慢慢分析。

这种组合还有一个额外的好处：互相验证。当其中一个工具给出一个看起来不太合理的接口名时，另一个工具往往能从不同角度看出问题。把它俩当成两个人来用，互相查漏补缺，比迷信任何单一工具都可靠。

5. 实测中我觉得它“难用”的四个地方

5.1 首次索引的等待感，比想象中更磨人

前面说过索引是大项目体验好的前提，但等待的过程确实难熬。在小型项目里根本感知不到这一步，到了大型项目里，它会让一个急着改 bug 的开发者产生“我装了个编译器”的错觉。

更麻烦的是，当你在命令行里切分支、拉扯远程更新，索引会因为代码变化而部分失效，后续提问可能引用到旧版本的实现。我的应对办法是，在工作开始前把代码状态稳定下来，索引建好之后尽量不要频繁切分支。团队协作时尤其注意，别人推上来的大批改动，不会实时进入它的分析视野，需要手动触发重扫。

5.2 它处理“模糊的优化”时常常用力过猛

如果你用“帮我把这个模块优化一下”这种没有边界的描述去问它，它会默认开启“大扫除模式”，把一些本来运行正常的代码也顺手重构了。我遇到过它主动把一段循环改成 Stream 流、把工具类里的静态方法重新归类，虽然改动本身没出错，但会给代码评审带来巨大压力。

大型项目最怕的就是“顺手优化”。所以只要修改范围超出提问目标，我都会在计划确认阶段直接驳回。它的计划界面能清楚看到哪些文件会被触碰，这也是我觉得它比普通工具安全的地方，只是需要你有意识去用。

5.3 长对话跑久了，它会陷入“自我验证”假象

一个很有意思的现象是，当你在同一个会话里连着问十几个问题，它给出的答案会逐渐向自己之前的回答靠拢，对早期错误的修复不够主动。比如你第一次提问时给了它一个错误的前提，它基于那个错误前提给出了回答；后续即使正确的代码已经出现，它仍倾向于维护之前的错误结论，而不是推翻重来。

这一点和人的惯性很像，但放在工具上就有点坑。我的解决办法是，当线索发生重大变化时，新建一个会话并把关键发现作为新前提重新提问，而不是在旧会话里试图把它“纠正”过来。独立会话的上下文干净，反而能获得更客观的答案。

5.4 快捷键与现有插件之间的冲突

这种问题不算大事，但真的很影响心情。装好 Augment 后，我原来的代码跳转、快速搜索快捷键和它默认的唤起方式有重叠，经常会出现按一个键同时触发两个功能，界面弹出半天都不知道是谁激活的。

解决办法倒也不复杂，进设置里把它的唤起快捷键改成自己顺手的组合，再把不需要的 AI 助手类插件先禁用。大型项目里插件之间的钩子冲突，比小项目严重得多，因为代码分析扩展往往要监听编辑器大量事件，收费工具和免费工具互相打架的情况并不少见。

6. 常用问题速查与一套行之有效的避坑清单

6.1 高频问题对照表

6.2 我的五个实用习惯，或者叫血泪教训

第一，永远先看修改计划再批准执行。不要嫌多一步麻烦，这一眼能省下后面几百行 review 的时间。

第二，给每个独立性强的任务开新会话。工作量看似重复，但换来的是稳定、单一线索的思维链，错误率明显更低。

第三，不要把它给出的调用链分析当真理，要在代码里复核一遍。它再厉害，也会遇到某些项目里使用反射、动态代理、字符串拼接调用这类让静态分析失灵的情况。

第四，遇到“历史代码为什么这么写”的问题，直接用它的代码库问答模式，别只让它改代码。它的定位在这一步发挥得最出色。

第五，对待免费额度要冷静。免费的算力资源肯定是有限度的，不要在临近限额时硬塞超长任务，分次处理反而更稳。

6.3 接下来如果你也想试，我给一个最稳的起步姿势

选一个你平时不愿意碰、历史包袱最重的项目，先别让它改任何代码，只用提问模式去追问项目结构、关键模块入口、数据流走向。这个过程能让你快速感知它的分析能力和普通工具的区别，也不会因为改坏代码而产生抵触情绪。

当它能准确回答“这个模块的入口到底在哪，为什么会有两条数据通路”这类问题时，再开始尝试小范围跨文件修改，慢慢建立信任。我不太建议第一次就挑全世界最复杂的重构任务来考验它，工具再强，也需要使用者和它建立一套共同的协作语言。

这半个月用下来，我不太关心它和 Cursor 到底谁更厉害，因为答案已经很清晰：谁定位不同，谁适用场景不同。我更在意的，是它终于把“AI 编码助手”的概念往前推了一步，从一个只会接话的聊天框，变成了一个肯在动手前先翻完整个仓库、再列计划的老员工。对一个常年泡在大型项目里的开发者来说，这种变化，比分数榜上那一两个百分点要实在得多。