ChatGPT / AI 在飞速颠覆着人们的认知，很多相关文字信息的保鲜度在急速衰减，如前文 2022 生产力工具盘点 中 AI 章提到的几个工具产品，都已演进到全新局面。在 DevTools 方向上，面临 AI 带来的颠覆效应，微软又一次站在了大气层（为什么是「又」、请参考旧文和荐书）；引用 Matt Rickard 的文字来概括：
Any startups that were thinking about building these features might be second-guessing themselves now. GitHub and VSCode power a large surface of the developer workflow, you’re up against the best developer (and enterprise) distribution pipeline in the world — VSCode + GitHub + MSFT.
… Will startups be able to add value here, or will GitHub and Microsoft accrue all the value?
Cody: AI-based 代码生成工具
近期读到 Steve Yegge 在 Sourcegraph 官博的文章 Cheating is All You Need，虽说主要是为新工具产品 Cody 带货，但话题正中 AI + DevTools 交集。代码生成（CodeGen）毫无疑问是现代 IDE 的基础能力，而 OpenAI 的 ChatGPT / Codex 完全在另一个维度实现了工具能力突变，这让 IDE Tools 信仰者们风中凌乱。
撰此文一方面帮助自己梳理下对 AI 黑魔法的漫漫求索，同时也回顾下 IntelliJ IDE 代码补全的能力实现。
关于 Steve Yegge 及他对代码索引（SCIP!）的观点，可参考这篇同 Joe 共同捉刀的 InfoQ 译文，及背后的 翻译故事。
Cody 一文的观点提炼，及个人的总结加工：
- LLM 是下一个跨时代的突破；Steve 类比了 AWS、k8s 等产品技术初露头角的时刻，并告诫工程师们要对此抱有足够敏锐感、不要出于技术尊严等原因拒绝认清这点
- 如果 LLM 能产出 80% 有效代码，那就是接近 5x 生产力提升；不要纠结生成代码的品质，连自己手写的散装代码都不该无脑信任、解决代码质量问题更多要落在软件工程实践上（如代码评审、持续交付等）
- 如果用 LLM 炼丹，除非基于个性化数据集（也即用户代码）进行微调，否则为产生更好的生成结果、要尽可能提供足够的代码上下文信息；而 4~32k Token 满打满算 100k 字符（仅跟 express.js 库代码量相当，见下图），全库代码填满 Context Window 不仅不现实且耗费巨大
- 所以怎样更好炼丹？Steve 非常激动地表示，结合代码搜索引擎的效果会更好，
也就是 Sourcegraph 又要赢了—— - LLM 形成了某种意义上的 “AI 平权”，也即大家在基于 LLM 构建产品能力时、往往只能在 UI / UX 上差异化竞争；而在代码领域 Sourcegraph 有“数据霸权”（相比于本地 IDE 工具所能获取到的上下文，其托管的云端用户代码可作为额外数据源）
- Sourcegraph + LLM 的结合，类似 New Bing + ChatGPT 组合——先通过搜索引擎召回部分代码上下文信息，再构造 Prompt 给到模型。而这部分垂搜的技术能力，恰好是 Sourcegraph 的看家本领（代码文本搜索、符号搜索、相关度排序等）
对 Web 程序员做个比喻，把上图的 Cody 想像成 Web 框架里的 Filter 组件，职责是：
- Query 解读及加工：对用户的查询请求进行拦截及修改，结合 Soucegraph 已有的代码库索引数据。这部分是搜索引擎经典的
[QU - 召回 - 排序]链条 - 数据再加工：对 ChatGPT 返回的生成内容做二次加工；如利用 IDE 原生能力做语法校验（毕竟 ChatGPT 擅长一本正经胡说八道）或对返回代码做格式化、提供一些 IDE UX 体验增强
总结下来，这是一个 ToD 技术产品借力 AI 实现能力跃迁的产品创新，而正因为在代码垂搜方向上的竞争力积累（也包括数据优势），Sourcegraph 得以避开完全落入 AI 的竞争优势区（从而面临同无数 ChatGPT bot 降维竞争的局面）
IntelliJ-based IDE 代码补全
参考 SDK 文档及 IntelliJ Platform 源码，结合 JetBrains Cyprus OpenDay 的一个分享；IntelliJ-based IDE 的代码补全能力概括为：
- 基于注册机制（Contributors），各 PL 结合提供不同场景下的候选词补全逻辑实现；如 JavaCompletionContributor 充斥很多 if-else 规则
- 由于有多个 Contributors，会有排序机制；这个 Ranking 很大程度上决定了用户体验
- 对于一些编程语言（如 Java），IntelliJ IDE 在过去 20 多年的演进中累积了大量的经验规则（hand-written heuristic sorters），能很好处理大量细节场景；因此给用户的感觉是 IntelliJ IDE 的补全排序上更懂这些语言
- 这些 contributors & sortes 跟 PL 强绑，每出一个新 IDE 产品线都要从头积累；因此商业 IDE 近乎智能的产品体验、很大程度是依赖于补丁式规则完善所构筑起来的护城河
- 基于机器学习的排序规则（ML sorters）也在最近几个 EAP 版本里加入进来了，通过一些脱敏埋点上报看、效果还不错
因此 IntelliJ IDE 所期解决的问题，跟 AI-based CodeGen 所针对的是完全不同的命题：
- IntelliJ IDE 代码补全主要是一个排序问题而非生成问题；目标是准确性而非生成无关代码
所以某种程度上两者会是互补而不是替代；而传统 IDE 工具一统开发者编程界面的时代，终究要过去了。
最后转一个 Andrej Karpathy 的推文: “The hottest new programming language is English”，期待中文大模型和各种生产力工具的崛起。