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 编程工具的工程能力，完成了一次质变。
简单说，它终于学会了 “像人一样读代码”。
核心突破 1：Repo-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 并肩开发，已经是当下最确定的技术趋势。而你，准备好和你的新伙伴一起，开启下一段开发之旅了吗？
