有关系列笔记，内容是斯坦福公开课，其名称里包含The ，主讲人是Eric。在前讲之中，我们先是从LLM原理开始讲起，之后讲到工程方面，接着又落到从零搭建Agent以及MCP协议上，而在这一讲里，我们要落脚到每个开发者每天都会去使用的事物，那便是IDE。

我用IDE这件事，算是有点年头了。

回忆往昔操弄Java之际，所运用的乃是彼时初崭露头角之物兮，初次目睹“代码自动补全”此项功能时，内心之感竟是觉得着实精妙绝伦——其具备能够预先推测出我即将敲入的下一个单词之能力焉。随后转而运用IDEA，经其重构、跳转至关联之处、实施静态分析等一系列操作，此一整套工具链条助力于将诸多层次较低之错误在程序运行之前便予以拦截摒弃矣。而后等到VS Code突然问世，其呈现出轻量便捷、运行速度极快、插件生态极为繁茂之态势，旋即迅速演变为大多数人员的默认选用对象矣。

每一代IDE进行更替的时候，从本质上来说，都在做着这样一件事情，那就是，将开发者从那种重复的，并且是机械的工作当中解放掉，从而让他们能够更加专注于那些真正是需要去思考的事情。

于2023年现身，所行路径为同一轨迹，直至如今AI IDE呈现出百家争鸣百花齐放的态势，（参看我先前文章三款主流AI编程工具对比：Code、 、Codex）然而此番迈出的步伐，相较以前大幅度增大了许多。

IDE四十年，一条清晰的进化线

于这一讲的开头之处放置了一条时间线，该时间线从1983年的Turbo开始一直延伸至当下。我认为这条时间线是值得用心去细看一番的，缘由在于它揭示出了一个规律：

公元1983年，Turbo出现了，它是首个具备真正意义的IDE，它把编辑器、编译器以及调试器组装入一个工具之内，自此开发者首次无需于多个程序之间来回进行切换了。

在一九九七年，实现到令人惊叹程度：把调试工作可以施展的能力发挥到达了极限化的地步，特别是针对于C++以及Basic而言。大型工程在进行开发之时效率获得了大幅度的提高。

2001年，IDEA，也就是智能代码导航、自动重构、上下文感知的代码补全，此时，IDE开始真正地“理解”代码，而非仅仅是“编辑”代码。

二零一五年，VS Code，采取与常规做法相反的方式，具备轻量化特点，并将扩展能力向社区进行开放。于是，社区展现出令人惊讶的能量，在数年时间里，差不多对整个编辑器市场实现了统治。

2023年，——AI原生的 IDE，并非是针对现有的IDE去添加一个AI插件，而是从起始之际，就将AI能力深入地设计到工具的内在本质之中。

每一步，皆是在回应同一个问题，即怎样促使工具更明晰你所从事之事？不同之处在于，这一回，“懂”的程度，冲破了往昔所有工具的上限。

AI IDE能做什么：从基础到进阶

把AI IDE的使用方式分成两层：

底层基础（Bread-and-具体这个词表述有些不明确，这里取其大概意思），乃是你每日都始终在运用操作的那几个行为动作：

（）之内于行内进行补全——当你正在敲代码的时候，它能够预先推测你接下来将会写下些什么样的内容，只需按下Tab键便可以予以接受。而这是绝大多数人对于AI IDE所形成的首个印象，并且还是频率最为高的功能。

函数等级的生成方式，是你去阐述一个函数所要实施的行为时，它会协助你将整个函数的主体部分书写出来。

单独一个文件进行编辑（-file），此操作是在一个文件的范围之内去开展修改工作，包括增添功能、改变逻辑以及进行重构。

多文件编辑（Multi - file），即跨多个文件同时进行修改，这对于传统 IDE 而言是极难做到的，一个需求或许涉及接口的定义、实现、测试以及文档等方面，而 AI IDE 能够一次性实现跨文件的协调。

一个被称为进阶层（True AI -）的东西，它具备一种能力，这种能力能够使得AI IDE切实地有别于那种所谓的”加了AI插件的普通IDE”。

后台的Agent，你告知它一项任务，它会自行于后台持续运行，并非需要你全程紧盯着。而后你起身去饮用一杯咖啡，返回之后查看最终产出的结果。

MCP集成，是上一讲所讲述的内容，它使得Agent能够直接与外部数据源以及工具进行连接。

记忆，它于过往你们之间所进行的对话以及各自的偏好具备留存能力intellij idea 14教程，往后再度交流时，无需再次去阐释背景情况，有标点符号。

PR审查，它能够自动去扫描你的Pull，进而找出潜藏当中的问题，仿佛是存在着一个时刻做好随时待命准备的code。

揭开盖子：AI IDE的底层机制

这里面的这一部分，是我认为在这一讲来讲，是最具备价值的所在之处。大部分的人运用或者，仅仅是知道这件事情是这样的，却并不清楚它为什么会是这样，然而却将底层的机制讲述得极为清晰明了精确无误。

Tab补全是怎么工作的？

当你于打代码之际，IDE会将你当前光标周遭那一短小片段的代码予以加密并发送至服务器；而服务器借由使用一个专门针对“代码填空”加以训练的LLM（model）来对接下来你将会书写的内容进行预测，随后将此建议发回，且呈现在你的光标后方。

整个过程是在几十到几百毫秒之内完成的，其速度方面的要求是极高的，所以所使用的一般是专门针对低延迟进行优化的小模型，并非像GPT - 4这类的大炮。

Chat功能是怎么工作的？

这里的实现就复杂多了，核心是一套语义索引系统：

把你的全部代码库，截成一小条一小条的代码片段，借着IDE，将每一片段转换成为维度较高的向量，存放于服务器的语义索引当中，文件名会被施行混淆处理，以此来保护隐私。

在Chat之中询问一个问题时，系统会先将该问题转化为向量，接着于索引里开展相似度搜索，从中找出与你的问题关联最为紧密的那些代码片段，随后把这些代码片段当做上下文一并投喂给LLM。

要让索引维持新鲜的状态，IDE会按照固定的期限，再次对代码变更进行索引。更新效率存在一定讲究：借助Tree计算哪些chunk切实产生了改变，仅对存在差异的部分予以更新，并非每一次都进行全量的重建。

Tree属于树形数据结构，其核心思想在于借助哈希值去高效验证数据是否被改动了。

从底部往上理解

想象你有四个文件：A、B、C、D。

首先，针对每一个文件，去计算得出一个哈希值，这是一种能够将任意内容压缩成为固定长度指纹的数据算法。

Hash(A)  Hash(B)  Hash(C)  Hash(D)

第二步： 把相邻的哈希值两两合并，再哈希一次：

Hash(AB) = Hash( Hash(A) + Hash(B) ) 
Hash(CD) = Hash( Hash(C) + Hash(D) )

第三步，持续朝着上方进行合并，一直到仅仅剩下孤零的一个根哈希值( Root Hash）：

Root = Hash( Hash(AB) + Hash(CD) )

整棵树长这样：

           Root
          /    \
       Hash(AB)  Hash(CD)
       /    \    /    \
    H(A)  H(B) H(C)  H(D)

哈希具备一项关键特性，那就是，仅当输入之中发生仅一个字节的改变时，其输出便会全然不同。

所以要是文件B被更改了，Hash(B)会发生变化，Hash(AB)会发生变化，Root同样会发生变化。你仅仅只需比较Root，就能够晓得“有东西改变了”，接着顺着树向下寻觅，很快便能够确定是哪个文件出现了问题。

这便是缘由所在，Tree颇具适宜实施增量更新之机——无需将全部文件逐一检验，单只需开展哈希比对，路径短小精悍，速率快捷迅猛。

究竟是这最后一点，使得我进行了更多的思考。Tree于分布式系统当中是极为常见的，举例来说Git利用它去追踪文件变更，区块链同样也在运用它。在当前所处的这里，它被用于开展增量更新，这无疑是一项极具智慧的工程选择。特别是当代码库规模不断增大之后，全量重建所产生的成本是绝对无法被接受的。

用好AI IDE的关键：你得先成为一个好的PM

这一讲让我印象最深的，是说的这句话：

对于复杂的任务，你需要成为一个产品经理。

他说的不是比喻，是字面意思。

如下这般任务——换一下变量的名称、添加上一行注释、修正之中一个显著露出漏洞、拼写错误之处——随便随即抒写一句话就可以达成，人工智能集成开发环境能够不费吹灰之力就予以搞成正确。

然而，要是对于稍微复杂那么一点儿的那类任务，一旦你仅仅是丢给AI一句模模糊糊的需求intellij idea 14教程，那么它所给出的结果，十有八九并非是你心里所期望得到的那个样子。这并不是由于模型本身不够机灵聪慧，而是归因于它并未拥有充足的相关信息借以去做出准确无误的决策呀。

给了他一个在实际项目当中所运用的Spec文档模板，我认为这是这一讲极其实用的干货。

在撰写这份Spec的进程之中，实际上也是在迫使你对需求进行清晰的思考。倘若你连Edge case都未曾思索考量过，那么这并非是AI所存在的问题，而是你自身所暴露出的问题。

为AI优化你的代码仓库

对于这一讲而言存在着这样一个十分具备价值的视角转换，并非仅仅是你一定要去适应AI IDE，同时你所拥有的代码仓库同样也要朝着为AI进行优化这一方面转变。

讲，LLM会出现紊乱以及差错，不少情形下并非模型的问题，而是它所获取的上下文过于繁杂——繁杂的目录架构、缺失的注解、不一致的命名方式、没有文档说明的API契约 一个于人类工程师而言 “凑合能明白” 的代码库 对AI来讲或许全然是场噩梦。

他提出建议，要在代码库当中提供这些信息，有仓库的整体介绍，有目录结构的相关说明，有的是环境配置以及启动方式，还有代码风格规范，还有常用的API以及契约定义，另外还有访问模式，也就是在什么情况下使用哪个模块。

并且他尤为推荐架构，即把相关代码放置于一个仓库之中，而非分散于多个软件项目资源库。对于人工智能而言，能够在一个上下文环境里瞧见前端、后端以及基础库的完整代码，相较于在多个仓库之间来回跳转，要友好许多。

具体的实现方式，现在各家工具有各自的约定：

所要留意的一点是，存在这样的提醒，即这些配置文件仅仅是指“建议”，并非“命令”，AI并不能保证会全然遵守，哪怕达到百分之百的遵守程度，不过呢，有这些总归是要比没有强一些，起码它能给模型提供一个相对而言更好上一些的起点。

小结

四十年之前，IDE助力开发者将编辑、编译以及调试集聚于同一处。当下，AI IDE实行相同之事，只是此次整合进来的，乃是一个能够领会自然语言，能够生成代码并且能够跨文件进行推理，这样的AI协作者。

但此协作者需具备良好上下文方可发挥功效，代码库需保持整洁，文档需完备，需求需清晰表述。这些看似“理所当然”的工程基本功，然而现实中的代码库，究竟有几个真正达成了呢？

AI IDE有所出现，借助一种意想不到的途径，将我们往回迫使，回到软件工程最基础的问题之上：你的系统，实乃真的有人能够看懂吗？

这个系列的笔记会一直持续进行更新，关于课程里的资料参考方面，有.dev，斯坦福，还有主讲人是Eric。

如有侵权请联系删除！