写代码只占工作的 30%，CodiumAI 想要另外那 70%

GitHub Copilot 是第一个在商业上取得成功的编程大语言模型。微软在这次访谈四个月前宣布，Copilot 本身已经是一项单独就有 1 亿美元规模的业务。CodiumAI 的首席执行官 Itamar Friedman 做客《The Cognitive Revolution》，论证说：补全和生成，演示再振奋人心，也只覆盖了软件生命周期的一个切片。他的公司成立 18 个月，已经服务了数十万名开发者。

Friedman 把他的看法追溯到 2022 年 8 月，他把那个时间点称为“BC”，也就是 ChatGPT 之前。在他看来，Copilot 早期有效的迹象，就像是把搜索装进了集成开发环境（IDE）：你不用搜五次谷歌、翻五个 Stack Overflow 的帖子，而是直接拿到一个已经变成代码的结果。他认为，这正是 Stack Overflow 流量持续下降的原因。这是一个很有用的起点，也很自然地契合了那些被训练来补全下一行代码的模型。但它并不是工作的大部分。

在一个 50 人或 500 人的团队里，在真实的公司中，真正写代码最多只占开发者时间的 30%。他见过的一些研究给出的比例还要低得多。Nathan Labenz 从没听过这么小的数字。Friedman 说的并不是某个在全新的业余项目上写代码的自由职业者。架构、设计、测试、评审、工单，还有代码写完一周就成了遗留代码这件事，吃掉了剩下的时间。他说，那些能搭起五页“注册加仪表盘”网站的酷炫智能体（Agent）演示，你本来就能从 GitHub 上下载到现成的。

测试、评审，以及检查代码是否符合 Jira 或 Monday 工单的要求，是人们讨厌却又必须做的事。Friedman 和他的团队在 ChatGPT 发布之前就用过 GPT-3.5 的 API，当时他们就料到补全会变成大宗商品。大约 15 个工具已经在做这件事，Copilot 领先；本地模型很快也会足够好。企业仍然成批购买补全功能，因为那 30% 确实重要，而且下一行预测正是大语言模型被训练来做的事。判断代码是否真的能跑，则是另一个训练和产品问题。

他们给公司取名时围绕的是完整性，没有围绕测试。测试是验证意图的老办法。你也可以从代码中自动生成规格说明，再和产品经理已经写好的规格进行比对。从长远看，Friedman 希望同一个闭环还能检查开发的最佳实践，甚至公司文化。红杉资本把生命周期切成构建前、构建和交付三段；CodiumAI 的切法与之相近，但更激进一些。“虚拟团队成员不能只写代码而不测试，不能不理解更深的上下文。”它必须同时坐镇这三个环节。

这也是他们欣赏 Cursor、并在试验自己的集成开发环境（IDE），却没有把新编辑器作为主要押注的原因。AI 原生的 IDE 是把模型织入编写循环的有力方式。在他们看来，完整性必须在你写代码、合并代码和持续集成/持续部署（CI/CD）流水线中始终在场。Codiumate 是他们在 IDE 里的聊天功能，采用类似 ChatGPT 的自由文本，但上下文标记更方便，还有 ChatGPT 没有的命令。一个 Git 插件 PR-Agent 面向拉取请求（PR）评审。两者的目的都不是取代 Copilot，它们要覆盖的是 Copilot 没有做到的工作。

Labenz 听到的说法差异很大。他在类比式编码上得到了好几倍的提升：粘贴一个模式，要求给出变体；而严谨的研究则报告了接近 30% 的提速。GitHub 发表过受控实验，显示质量有大幅提升。另一些报告，以及他认真对待的 Gary Marcus 那种观点，则说质量在下降，技术债务才是隐性成本。Friedman 说两种看法都对，关键看具体的设置。

从零开始做一个项目，尤其是不需要服务数百万用户的项目，你往往能更快拿到好代码。而在一个拥有数百万甚至上亿用户的产品里加功能，那里的缺陷和性能至关重要，而且你需要大量上下文，质量很可能会下降。在他看来，GitHub 那些乐观的实验，隔离出的是从零搭建的一类普通需求，这类需求大语言模型本来就能从网上拼凑出来。复杂的生产代码则是另一场游戏。

他认为，这个行业把生成设计成了系统 1（System 1），用的是 Daniel Kahneman 意义上的那种思维：一点上下文、一条提示词、一个答案。AlphaCodium 则是系统 2：缓慢、多步，愿意在过程中额外获取信息。造一个智能体并不会自动让它变成系统 2；有些智能体仍然只是快速的猜测。代码补全必须保持快速，代码生成则不必。他的预测是：即便是复杂的程序，AI 的质量也会越来越高，到 2024 年底，这种担忧将会大大缓解。Labenz 对怀疑者的回应也是同一个路数：两年前，模型根本不会推理、规划或使用工具。

Labenz 在 VS Code 上装了这款插件用了一周。CodiumAI 在那里大约有 25 万名活跃用户。Friedman 说，JetBrains 的插件增长更快，几个月内就可能超过 VS Code，而且评分是 4.8 星。他们投入 JetBrains，是因为企业在用它，而那里的高分很难拿到。Labenz 点了“Generate tests”，得到一个大约 20 种行为的面板，外加前六个左右的测试。你可以展开子行为；有些函数能列出 50 到 100 个角度。Friedman 说，这正是开发者最常提到的价值：他们学会了应该怎样测试，包括那些平时不愿去想的边界情况。

“运行并修复”让 Labenz 有些紧张：如果模型给代码打了补丁，谁来检查这个补丁？Friedman 的回答是把验证织入整个流程，而不设单一的关口，这一思路后来也出现在 AlphaCodium 中。对于觉得高级面板太重的人，聊天里还有一个更轻量的 Quick Test。Explain 是一等命令，因为他们希望在测试和代码旁边，放一份类似 README 的规格说明。口号是“DRY by AI”：今天你先写 Jira 故事，然后写实现，再写测试，三份互相重叠的产物会逐渐走样。他们的押注是：其中任何一份都能生成另外两份；等准确率足够高时，产品会主动把它们拉齐，并在出现偏差时发出警报，而不是等人去点击。

对 Labenz 来说，Enhance 像是一位软件导师，会提醒类型、风格，还有自学出身的原型开发者常会忽略的那些东西。Friedman 很高兴他喜欢，也说大约一半的开发者讨厌它。这关乎品味，比如用空格还是用制表符。解决办法是每个仓库一份配置，说明 Enhance 在这里意味着什么，这样技术负责人就能为初级开发者设定原则。有一个客户配置了弃用规则：调用旧 API 时，插件会提示你改用新的 API，团队几乎把它视为改变游戏规则的功能。他们更长远的期望是，模型能自己学会团队的实践。第一步，是让人们自己写下规则。

Labenz 的实验大多以函数和类为范围。PR-Agent 以及任何需要运行在真实产品中的功能，需要的范围要大得多。上下文窗口已经从 4000 个 Token 增长到 128000 个 Token，这有帮助，但并没有解决问题。CodiumAI 的一些客户有 1000 万行规模的单体仓库（monorepo）。Friedman 提到了关于长窗口和注意力分散的研究：即便模型能装下全部文本，顺序依然重要，而人在被告知“这是全部代码”之后，行动前仍然要先整理。Friedman 回忆的 Andrej Karpathy 的说法是：多一次迭代，就多出一段思考。模型同样需要步骤。

创业之初，他们把零数据留存（zero data retention）作为一种近乎战略性的策略，包括在私有云部署（cloud-prem）上也是如此。上下文是根据依赖图（dependency graph）即时计算的，并用一套启发式规则决定向上和向下遍历多远。他们不会预先为整个 1000 万行的仓库建立索引。客户担心新的向量数据库（vector database）在自己的防火墙内存放代码，而 GitHub 和 Bitbucket 则很成熟，管控也很严密。他们等待的主要原因不是成本。如今领域已经成熟，他们正在考虑对仓库和多仓库做后台消化，并在运行时用来获取更深的上下文。

在 Extend test 功能中，他们已经把计算出的子上下文呈现为一份依赖列表，开发者可以添加或删除。如果你想让测试覆盖系统的更多部分，就把额外的节点拉进来。把图谱直接以图的形式展示出来，很有诱惑力；但很多开发者并不想在 IDE 里看到更多界面。构建这些图谱，对语言的依赖非常痛苦。Tree-sitter 和常见的开源解析器，对 30 种主流语言来说还不够。Friedman 相当确定，JetBrains 和 GitHub 都有自己的内部版本，用于 IDE 和搜索，而且它们并不是完整的开放框架。CodiumAI 对工作做了拆分：客户端做一些预处理，更深入的算法放在后端，以便少传数据、多做计算。

AlphaCodium 是他们在 CodeContests 上的一次尝试。CodeContests 是 DeepMind 的基准测试（benchmark），题目主要取自 Codeforces。他们选它，是因为 LeetCode Hard 比较简单，HumanEval 已经饱和，而且有人发现，GPT-4 在某个截止日期之前在 HumanEval 题目上得了 100%，之后则一题也做不出来，这几乎就是训练集泄露的证据。Codeforces 像 Kaggle 那样，把私有测试藏在公网之外。只有 DeepMind 和 OpenAI 认真提交过，CodiumAI 是第三个。这些题目难度高，而且自成体系：它们不是百万行的企业技术栈，这也是他们现在要把同样的思路融入 PR-Agent 和 Codiumate 的原因。

一年多以前，AlphaCode 微调了一个专门的模型，解决了大约 28% 的题目，大致相当于竞赛参赛者的中位水平，每道题用了大约 100 万次模型调用。AlphaCode 2 微调了 Gemini Pro，把调用次数降低了几个数量级，但仍然需要一个专为竞赛打造的模型。AlphaCodium 使用的是现成的 GPT-4，没有微调。五次提交，每次约三个候选解，每个解约 15 次调用：Friedman 估计总计约 100 次调用，几分钟，几美元。在一个解决了 30% 题目的测试集上，它排在第 51 到 52 百分位，超过了多数参赛者。要进入前 10%，则需要超过一千次调用，但他们没有这样做，因为那不会是一个实用、可复现的结果。通常的做法是提交十次，那样分数会更高；他们选择五次，因为一个产品提供三个或五个选项是合理的，提供十个就不合理了。

他们刻意把这种方法称为流工程。思维链（chain of thought）是流程的一种，但他们不想用“智能体”这个流行词。论文题为《从提示词工程到流工程》。一旦每一步都要求清晰，对提示词的敏感度就会大幅下降，花在提示词上的时间也降到约 5%。Labenz 读过代码仓库：提示词简短而利落，工作都在拆解上。预处理阶段不写代码：先反思问题，推理公开测试，生成策略（不生成代码），再给策略排序，然后为边界情况生成额外的 AI 测试。只有到这一步，才开始生成代码、自我改进、运行公开测试、修复，再运行 AI 测试，然后再修复一遍。

关键设计是锚定。通过的测试会被锁定，之后的修改必须保持它为绿色。失败的测试会触发反思：是代码错了，还是测试错了？开发者本来就会争论这个问题，而且他们倾向于接受绿色结果。AlphaCodium 把这种倾向也引了进来：从易到难，逐步积累一批被锚定的通过测试，这借鉴了课程学习（curriculum learning）的思路。为了防止错误层层累积，他们使用了知识积累，把已经消化过的通过结果继续传递下去，并使用跳跃连接（skip connections）：把第四步的输出注入到第七步，使原始信号不至于被完全消化掉。YAML 在 Token 消耗和可读性上都优于 JSON 和 XML；Labenz 说他已经从 XML 阵营倒戈。GPT-4 在验证集上的领先，比在测试集上更大。Friedman 的解读是：验证题目可能有重叠；同时，流程的价值在更干净的划分上体现得更明显。DeepSeek 表现出乎意料地好，尤其是在测试集上。有些擅长聊天的模型，代码能力却很弱。

Labenz 的收尾清单是打算拿去别处用的。结构化输出用 YAML。从简单开始，逐步攻克难题。在积累知识的同时，尽量不积累错误。把重大决定往后放：先策略，再代码。要求小而模块化的单元，以便单独验证。并且在生成之后，立刻运行另一条批判性的提示词，去评判结果。“我觉得，让 AI 做完一件事，然后马上拿它的方案让它批评自己的方案，这似乎不太直观。可它就是有效。”Karpathy 在推特上评论这篇论文时，特别点出了那套流程。

Friedman 补充说，一旦步骤变得简单，提示词就不那么敏感了，但论文里仍然写明了反思的一些注意事项。另一个常被忽略的细节是跳跃连接：有时你会把第四步的输出拿出来，注入到第七步，这样之后的消化过程就不会把它埋掉。这个项目是开源的，细到温度参数和配置。对于那些工作不是竞赛题的人，Labenz 额外建议是：把你所在领域已经在用的工作流程写下来。很多团队从未把自己混在一起的那些步骤记录下来。此前做客的 Elicit 在研究场景中也探索过同类的严谨拆解。

开发者明天就能装上这款插件，点一下 Generate tests，就能看到他们之前没有考虑过的行为；团队可以试试开源的 PR-Agent。做 AI 产品的人可以克隆 AlphaCodium 的仓库，复制其中的流程。在被问到下一期该收听什么节目时，Labenz 把 Friedman 引向了 TinyStories 这项研究：微软研究院的 Ronen Eldan 和 Yuanzhi Li 用三岁儿童阅读水平的故事训练小模型，仍然观察到了微推理能力的涌现。Friedman 收尾时更正了开场介绍：他是联合创始人之一，并非唯一的创始人，接下来的一切都要归功于团队。