AI编程深度：从工具到伙伴，这一年我们亲历的技术质变

AI 编程现在火到什么程度从最初改代码、写文档、跑测试这类基础辅助到如今人人都在谈的 “零编码” 落地实战发展速度完全超出预期。作为国内较早一批 Cursor、Solo 这类 AI 编程工具的前 100 号用户我用这类工具做开发已经快一年。放在 AI 迭代的尺度里一年不算长但足够让我亲眼见证它从 “辅助插件” 一路进化成真正能扛事的工程伙伴。前两天我写了篇短文聊这个话题很多朋友私信问我背后的技术细节 —— 到底是什么让 AI 在短短几个月里从只能改几行代码的小工具变成了能读懂几十万行工程的 “虚拟架构师”今天这篇我就结合我这一年的实测体验把背后的技术逻辑拆透给你看。一、第一阶段IDE 的 “打杂小弟”解决的只是局部问题最早我接触 AI 编程的时候大概是一年前。那时候的 AI 工具定位非常明确IDE 的补充者帮你干杂活的小弟。那时候的核心能力是什么帮你把一段 Python 代码转成 java帮你给函数写单元测试帮你补全函数的注释文档最多就是帮你改改当前文件里的 bug说白了那时候的 AI能处理的就是单文件、局部代码片段。你要是问它 “整个项目里的用户权限逻辑在哪”它根本答不上来 —— 因为它根本读不懂整个仓库。当时的技术瓶颈算力与上下文的双重枷锁我后来复盘才明白那时候的限制本质上是两个技术瓶颈上下文窗口的硬限制早期的大模型上下文窗口最多也就 8k、32k token换算成代码也就几千行。你一个稍微大点的项目随便一个模块就几万行代码根本塞不进去。那时候有人试过把整个仓库的代码都压缩了喂给模型别逗了几十万行代码就算是 1M 的上下文窗口都塞不下更别说那时候根本没有这么大的窗口。算力成本的死锁就算你能把代码塞进去推理成本也扛不住。处理几十万行代码的推理成本是处理局部片段的上百倍那时候的算力根本支撑不起批量的日常使用。所以早期的 AI 编程只能做 “局部优化”—— 你改哪它帮你看哪至于整个项目的结构它没能力管。那时候的 RAG检索增强生成也只是单文件级的 RAG。它能在你当前的文件里检索相关的代码片段帮你补全上下文但跨文件跨模块想都别想。那时候我们做开发是什么体验你要做一个新功能得先自己把整个项目的依赖理清楚把相关的文件都找出来然后一段一段丢给 AI让它帮你改。你要是不把上下文喂给它它根本不知道你改的这段代码和其他模块有什么关系。说白了那时候的 AI就是个 “代码打字员”你得把思路、把上下文都给它准备好它帮你把代码敲出来。这就是为什么那时候大家都在讨论 “prompt 工程”—— 你得想办法把所有的上下文都塞进 prompt 里才能让 AI 输出靠谱的结果。我那时候写一个功能一半的时间都在写 prompt把各个模块的代码都摘出来拼到输入里现在想想真的挺累的。二、转折点去年 11 月AI 编程的 “工程化觉醒”变化是从去年 11 月开始的。那时候 Cursor 更了一个大版本我当时打开一个我们公司的遗留项目 —— 一个做了三年的 ERP 系统几十万行代码上千个类我本来以为 AI 要索引半天结果我输入了一句 “帮我把采购模块的审批流程改成三级审批”几十秒之后它直接给我输出了修改方案甚至连数据库的字段变更、接口的参数调整都给我理清楚了。我当时直接懵了。这不对啊就几个月前这个项目我丢给它它还说 “项目太大了我处理不了”怎么现在几十秒就搞定了后来我才搞明白这不是大模型的底层能力突然爆发了 —— 那几个月里GPT、Claude 的底层能力并没有什么质的飞跃真正的变化是AI 编程工具的工程能力完成了一次质变。简单说它终于学会了 “像人一样读代码”。核心突破 1Repo-level RAG把整个仓库变成可检索的语义库之前的 RAG是单文件的现在的 RAG是仓库级的 Repo-level RAG。这完全是两个东西。什么意思普通的文本 RAG是把文档切成块转成向量然后检索相似的块。但代码不是普通的文本代码是有结构、有依赖、有层级的。如果把代码当成普通文本来切你就会把函数的结构、依赖关系都切没了检索出来的东西根本不对。新一代的 Repo-level RAG做了三件事结构感知的索引而不是文本切分它不会把代码随便切成 1000 字的块而是先通过 AST抽象语法树解析把代码拆成函数、类、变量这些结构化的单元。比如一个 Python 文件它会把里面的每个函数、每个类都单独拆出来保留它们的依赖关系、调用关系。就像微软研究院和北大提出的 RepoCoder 框架里说的传统的代码补全根本用不上跨文件的上下文而 Repo-level 的框架就是要把整个仓库的跨文件依赖都建模出来。语义向量 依赖图谱双重索引它给每个代码单元生成语义向量同时还会构建一个仓库语义图RSG—— 把所有的函数、类之间的调用、继承、导入关系都存起来。这样一来当你要改支付模块的代码它不仅能通过语义检索找到支付相关的函数还能通过依赖图谱把所有和支付相关的依赖函数、调用它的上层接口都找出来。这就是为什么你问它 “采购模块的审批流程”它能自动把整个流程涉及到的所有文件都找出来根本不用你手动喂给它。Merkle 树增量索引解决速度问题你肯定会问几十万行代码索引一次要多久会不会每次打开项目都要等半天答案是不会。Cursor 这类工具用了 Merkle 树就是 Git 里用的那个来做增量索引。它给每个代码块算哈希构建一棵树当你修改代码的时候只有你改的那个分支会重新索引其他的都不用动。我实测过我们那个几十万行的 ERP 项目第一次索引也就用了不到 5 分钟之后每次打开都是秒开因为只有我改的那几个文件会重新索引。这就是为什么它能做到 “几十秒读懂整个项目”—— 因为大部分索引工作早就后台做完了而且是增量的根本不占你时间。核心突破 2分层解析像资深架构师一样 “先看整体再抠细节”这是最让我震惊的一个点也是用户说的 “AI 像架构师一样读代码” 的背后原理。之前的 AI 读代码是什么样的它是逐行读的就像 IDE 的符号表把所有的函数、变量都列出来然后试图把整个图都塞进脑子里。但这根本不可能几十万行代码的关系图太复杂了模型根本处理不了。现在的 AI 读代码是分层的自顶向下的就像我们资深开发接手一个新项目的时候做的那样第一步先看整体结构反推业务属性它不会上来就逐行读代码而是先看你的目录结构、文件名、类名。比如它看到你有/purchase/、/finance/、/hr/这些目录有PurchaseOrder、Invoice这些类名它立刻就会判断哦这是一个 ERP 系统。然后它会把这个判断和它自己的知识库结合起来 —— 它知道 ERP 系统的采购模块大概是什么样的架构审批流程大概有哪些环节有哪些通用的模块。这就相当于它先有了一个 “全局的认知框架”而不是两眼一抹黑地读代码。第二步从项目级到目录级再到文件级逐步缩小范围这就是学术里说的 \Hierarchical Summarization分层摘要\ 技术。它会先给整个项目做一个摘要然后给每个目录做一个摘要然后给每个文件做一个摘要。就像那篇 ACM 的论文里说的这种 top-down 的策略能把搜索空间从整个仓库一步步缩小到你要的那几个文件根本不用把所有代码都塞进上下文。比如你问它采购模块的审批它先从项目级摘要里定位到采购目录然后从采购目录的摘要里定位到审批相关的文件然后再去读这些文件的细节。整个过程就像我们人找东西一样先找大的分类再找小的模块最后才抠细节。迭代式的认知校准3-4 次就建立完整的项目认知它不是一次就把所有东西都搞对的它会迭代。比如它先判断这是 ERP然后根据这个判断去读代码发现有不对的地方再调整自己的认知然后再读反复 3-4 次整个项目的结构就清晰了。这就是我当时感受到的它不是把所有代码都塞进模型而是像人一样先搭框架再填细节用最少的上下文就能搞懂整个项目。我当时做过一个测试我把一个我自己写的小项目故意把所有的文件名、函数名都改成无意义的名字比如把PurchaseOrder改成ClassA把approve改成func1。结果你猜怎么着AI 读了半天也没搞懂这是啥。这就验证了我的判断它真的是先从命名、结构反推业务然后再理解代码的。如果把这些 “线索” 都抹掉它就和早期的 AI 一样只能逐行读根本搞不懂整体了。三、长上下文 RAG 的组合拳终于打破了算力瓶颈很多人之前都在吵“大上下文窗口出来了RAG 要被淘汰了”。但在 AI 编程这个场景里真相是长上下文和 RAG 不是二选一而是完美互补的组合拳。之前我们说的瓶颈算力和上下文现在用这个组合拳完美解决了RAG 负责 “筛选”长上下文负责 “处理”RAG 帮你从几十万行代码里把和你当前需求相关的那几千行、几万行代码找出来然后把这些相关的代码塞进长上下文窗口里让大模型去处理。这样一来你既不用把整个仓库都塞给模型节省了 90% 以上的算力成本又能让模型拿到足够的上下文去理解这些相关代码的逻辑。长上下文优先在编程场景落地就是因为这个需求太迫切了这就是我当时在会上说的“长上下文这些技术首先用在编程上”。因为对编程来说你需要处理的上下文是最集中的。你改一个功能相关的代码可能就几万行正好能塞进 128k、1M 的上下文窗口里。而如果是普通的文档场景你可能要处理整个知识库那还是得靠 RAG。所以你看这两个技术加起来就把之前的瓶颈都打破了算力不用处理整个仓库只处理检索到的相关代码成本降了一个数量级。上下文不用塞整个仓库只塞相关的部分长上下文足够用了。速度增量索引 分层检索几十秒就能定位到你要的所有代码。这就是为什么短短两三个月AI 编程的能力就上了一个大台阶。不是大模型突然变聪明了是工程技术的组合把这些能力都释放出来了。四、从工具到伙伴到底变了什么很多人说不就是 AI 能读整个项目了吗有什么大不了的我这半年的体验告诉我这完全是两个时代的体验。之前的 AI是你带着它干活。你得把所有的准备工作都做好你得自己找代码自己理依赖自己想清楚要改什么然后把这些都喂给它它帮你把代码写出来。它是你的工具你是主导者它只是执行你指令的手。现在的 AI是它跟着你一起干活。你只要说你要做什么它自己去找相关的代码自己理依赖自己想清楚要改哪些地方甚至能帮你考虑到兼容性、测试、文档。你不用再跟它解释 “这个函数是干嘛的那个模块和它是什么关系”它都懂。举个我最近的例子我们要给我们的系统加一个数据导出的功能要把采购订单导出成 Excel还要加权限校验还要加异步任务防止超时。我就输入了一句话“帮我给采购订单加一个 Excel 导出功能要加权限只有管理员和采购负责人能导出还要做成异步的大订单不要超时。”然后呢它自己找到了采购模块的代码自己找到了权限校验的模块自己找到了我们之前做异步任务的框架然后把整个功能都写出来了从接口到权限校验到异步任务的处理到前端的按钮甚至连导出的列名、格式都给我对齐了我们之前的其他导出功能。整个过程我没给它喂任何代码没跟它解释我们的异步任务是怎么写的没跟它说权限校验的逻辑是什么。它自己都懂。这要是放在一年前我得自己把所有相关的文件都找出来一段一段喂给它跟它解释每个模块的逻辑然后写半天 prompt才能让它给我写出来。你看这就是区别。之前的工具是你得伺候它现在的伙伴是它伺候你。它不再是那个你得手把手教的小弟了它是能看懂你的思路能自己搞定细节能和你并肩打仗的伙伴。五、接下来AI 编程会往哪走这一年的变化已经足够让我震惊了但我觉得这还只是开始。接下来的 AI 编程我觉得会往这几个方向走Agentic RAG更智能的工程协同现在的 RAG还是你问它它帮你检索。接下来的 Agent会自己主动去探索代码库。比如你说 “帮我把这个项目的 Python 3.8 的兼容改成 3.12”它会自己遍历整个项目找到所有不兼容的语法自己一个个改自己测试不用你管。行业化的代码模型更懂业务的伙伴现在的 AI是通用的。接下来会有针对各个行业的专用模型。比如做 ERP 的 AI做电商的 AI做游戏的 AI。它们更懂你这个行业的业务逻辑更懂你这个行业的代码架构能给你更贴合的方案。多模态的代码理解从设计稿到代码的端到端现在已经有工具能把 Figma 的设计稿直接转成代码了接下来会更深入。你给它一个产品原型它能自己帮你把整个前后端的工程都搭起来从数据库设计到接口到前端页面全部搞定。很多人还在担心AI 会不会取代程序员我觉得不会。它只是把我们从那些繁琐的、重复的、没有价值的杂活里解放出来让我们能把精力放在更重要的事情上比如业务逻辑的设计比如架构的演进比如用户价值的挖掘。就像 IDE 出现的时候没人说 IDE 取代了程序员就像 Git 出现的时候没人说 Git 取代了程序员。AI 编程只是我们开发者的下一个工具不是下一个伙伴。对于还在观望的开发者我想说现在入局一点都不晚。毕竟和 AI 并肩开发已经是当下最确定的技术趋势。而你准备好和你的新伙伴一起开启下一段开发之旅了吗