Copilot创始工程师谈AI编程效率与实用性

GitHub Copilot的创始工程师Neel Sundaresan，如今正在IBM主导一个名为“Bob”的智能编码项目。目前，这个工具已经在IBM内部被8万名开发者使用。

有趣的是，在最近的一次访谈中，Sundaresan巧妙地回避了三个问题，其中之一就是“IBM Bob为什么叫Bob”。这种刻意的回避，反而让这个项目和他本人的思考路径，显得更加耐人寻味。

作为现任IBM软件部自动化与AI总经理，Sundaresan的职业生涯横跨研究员、产品构建者和高管三重身份。但贯穿始终的，其实是一个核心执念：究竟是什么在阻碍软件开发者提高效率？又该如何系统地消除这些障碍？

他对这个问题的探索，始于2000年——那是一个远早于Transformer架构和大语言模型成为主流的年代，甚至“AI赋能开发”这个概念都还未成形。从那时起，到如今服务8万内部用户的IBM Bob，这条探索之路远比任何新闻稿所描述的都要漫长和深刻。

在无人关注的时候开始

Sundaresan为提升开发者效率搭建的第一个系统，和今天我们熟悉的AI代码生成工具完全不同。那是一个API调用推荐系统。

“开发者有30%的代码都是API调用，”他在接受《The New Stack》深度访谈时解释道。“当你在一个类名后面按下点号，就会弹出一长串函数列表供你选择。这个选择过程本身，就是一个巨大的效率损耗点。”

当时的目标并非生成新代码，而是在最恰当的时机，给出最正确的函数调用建议。本质上，这是一个在代码自动补全场景下的精准搜索排序问题。

当时的模型不是Transformer，甚至按今天的标准看，都算不上深度学习模型。但开发者们非常喜欢这个工具。这个早期的启示——即在开发流程中某个细微环节降低阻力，就能获得超预期的用户满意度——至今仍在深刻影响着Sundaresan的产品哲学。

“编码是一项高度分析性的工作，和网购完全不同，”他强调。“如果系统给出了错误的推荐，或者给出了会干扰我思路的推荐，那这个工具就失去了价值。”

在他看来，用户体验和底层AI能力是两个相对独立的问题。即便模型性能再强大，如果表层的产品体验设计出现偏差，整体的产品体验也会一落千丈。

他亲历了模型技术的整个演进周期：从长短期记忆网络（LSTM）、早期的编码器-解码器架构，到谷歌的Transformer论文，再到初代GPT。在每一个阶段，他的团队其实早已明确了要解决的问题，只是当时的模型能力还不足以支撑理想的解决方案。“如果你回头看看我们发表的论文，这些相关领域我们都有涉猎，”Sundaresan说道，“每篇论文都在探讨哪种模型更适合解决这类问题，哪种模型又适合解决另一类问题。”

当前沿模型终于进化到足以支撑大规模投入并获得回报时，GitHub Copilot应运而生。但到那时，Sundaresan也已经花了多年时间，观察模型会在哪些具体场景中间出错，以及围绕模型的产品设计又会在哪些环节出现疏漏。例如，陈旧的训练数据会导致模型生成看似笃定实则虚假的信息；无论任务是否需要，系统都倾向于调用性能最强、成本也最高的模型；此外，在企业受限的运行环境中部署高性能模型，本身也存在不小的工程难度。

“就连我们的早期客户也不放心把代码数据发送到云端，”他谈及在微软的经历时说，“他们希望数据能留在本地客户端。所以我们投入了大量工程优化工作，让模型直接在个人笔记本上运行，并确保它能在有限的硬件资源下流畅工作。”

为什么是在IBM？

当Sundaresan讲述这段历史时，一个很自然的问题是：他为什么选择将多年积累的经验带到IBM，而不是其他看起来更“光鲜”的科技公司？他给出的直接原因是：在微软十年后，他想换个环境，而IBM提供了一个非常有说服力的机会。

但还有一个更深层、不那么显而易见的答案：对于他所钻研的“企业级开发者效率”问题，IBM的所谓“劣势”，恰恰转化成了独特的“优势”。

“仅软件部门，我们就有近两万名员工。我们拥有庞大的基础设施与咨询业务，IBM内部本身就是一个巨大的用户池，”他说道。“如果我能打造出让内部员工受益的产品，这本身就是一个体量惊人的市场。”这种内部先行、IBM称之为“零号客户”的模式，给了他任何外部产品发布都无法提供的东西：一个规模庞大、技术栈多元、且愿意为了换取实际效率提升而容忍早期产品缺陷的固定用户群体。

另一个关键优势在于工作负载的极端多样性。IBM内部的开发者不仅编写主流的Python和Rust代码，还需要面对PL/I、COBOL、大型机JCL，以及被Sundaresan形容为“如同行业俚语一般的”各种自定义语言。只要Bob能够成功适配如此广泛的技术栈，它就能应对未来任何企业客户可能遇到的开发场景。

“在敲开客户大门之前，我们就有真实的故事可讲了，”他总结道。

他也明确划定了Bob的研发定位：这不是一个面向所有开发者的通用工具，而是一个专门针对企业复杂场景的系统。而大多数AI编码工具，恰恰把这些企业场景视为边缘情况：遗留代码库、严格的合规与审计要求、混合云环境，以及AI生成那些看似能运行、实则无法投产的代码所带来的真实成本。

没人谈及的成本问题

在对话中，Sundaresan有一段非常坦诚的表述，揭示了大多数开发者在没有约束时如何使用AI编码工具的现状。

“人们会不假思索地选择最新的、像Claude Opus这样的顶级模型。他们可能只是执行一条简单的提示词，但成本却高达每百万词元40美元，”他打了个生动的比方，“这就好比开着法拉利去便利店买牛奶，完全没有必要。”

IBM Bob的设计哲学之一，就是不让用户直接面对底层模型的复杂性。系统会根据任务的实际需求，进行智能的调度与路由。其背后可调度的模型池包括Anthropic Claude、Mistral开源模型、IBM自研的Granite系列，以及多款为Bob运行环境专门定制微调的专有模型。

这种智能路由能力，正是Sundaresan认为能体现架构设计真正价值的核心。“这并非简单地将一堆模型API接入系统，”他解释道，“而是要把模型能力、产品体验，以及能够支撑优质体验的底层架构有机地结合起来。模型，只是整体解决方案中的一个组成部分。”

他介绍了如何在IBM内部用户中进行大规模的A/B测试：不断试验各类前沿模型的变体、监测用户的实际使用模式，从而精准识别出那些高成本模型被滥用于普通模型即可胜任的场景。这种内部部署模式，使得大规模、持续性的实验成为可能，其规模和成本是任何早期初创公司都难以负担的。

智能体市场究竟将去往何方

当被问及对当前AI智能体炒作周期的看法时，Sundaresan给出的更像是一位研究者的冷静分析，而非管理者的市场表态。

“无风不起浪，”他在采访中表示，“如果炒作是烟，那背后一定有火。火势或许没有烟看上去那么大，但火苗确实存在。”

他的基本判断是，基于智能体的开发模式确有实际价值，但这并非什么全新的事物。无论是基于服务的开发、基于API的开发，还是基于智能体的开发，这些模式在历史上都以不同形式存在过。真正的范式转变在于，如今的交互接口是概率性的、对话式的，而非传统的、确定性的程序化接口。这种转变催生了前所未有的新能力，同时也引入了全新的风险维度。

“你也可以分散它的注意力，”他谈及智能体系统时说道，“你可以问不该问的问题，或者透露不该透露的信息。”根据他的观察，高达91%失败的AI项目，根源都可以归结为规范或纪律的缺失。许多企业以为，只要和顶级模型供应商签个协议就万事大吉，但事实远非如此。“在把这些AI能力集成到你的核心软件产品之前，你必须遵循已有的、成熟的软件工程规范和纪律，”Sundaresan强调。

他特别关注一个尚未得到足够重视的发展方向：当智能体之间开始大量相互交互和对话时，最终可能会演化出人类无法直接读懂的、机器原生的通信语言。“倘若这些衍生语言中间出现漏洞或差错，这类错误很可能会以爆炸式的速度在系统间扩散蔓延，”他警告道。“未来还会有诸多我们未曾预料的变化发生。面对未知，我们可以因为害怕而止步不前，也可以选择勇敢但系统性地向前推进。”