GitHub Copilot 创始工程师构建 IBM BobGitHub Copilot 创始工程师 Neel Sundaresan 正在构建 IBM Bob——一款智能编码工具目前已有 8 万名 IBM 开发者在使用。Neel Sundaresan 回避了三个问题其中一个是 “IBM Bob 为什么取名叫 Bob”。这种回避本身就耐人寻味。Sundaresan 现任 IBM 软件部自动化与 AI 总经理也是微软 GitHub Copilot 创始工程师早年还曾担任 IBM 研究员并不是一个擅长做产品营销的人。他是研究员出身后来成为产品构建者再后来成为高管贯穿这三个角色的始终都是同一个执念究竟是什么在阻碍软件开发者提高效率又该如何消除这些障碍漫长的探索之路他从 2000 年就开始研究这个问题远早于 Transformer 架构和大语言模型的问世也远早于 AI 与开发者工具被主流技术圈关联在一起。从那时候起到已在 IBM 内部为 8 万用户提供服务的 IBM Bob 正式发布这条探索之路远比发布会新闻稿所呈现的要漫长得多。在无人关注的时候开始Sundaresan 为提升开发者效率所搭建的第一个系统和如今我们熟知的 AI 编码工具截然不同。那是一个 API 调用推荐系统。 “开发者有 30% 的代码都是 API 调用”他在接受《The New Stack》深度访谈时表示。“当你在一个类名后面按下点号就会弹出一长串可供调用的函数你得从中挑选一个。这本身就是一个效率损耗点。”目标并不是生成代码而是在恰当的时机给出正确的函数调用本质上是开发者代码自动补全场景的搜索排序问题。 当时的模型不是 Transformer甚至从现在的定义来看也不是深度学习模型。但他表示开发者们很喜欢这个工具。这个早期的启示——在开发流程里某个细微的环节降低使用阻力就能收获超乎预期的用户满意度——直到如今仍在影响着 Sundaresan 对这类问题的思考逻辑。用户体验与底层 AI 的关系“编码是一项分析性工作和网购不一样”他说。“如果系统给出了错误的推荐或是给出会干扰我思路的推荐那就有问题了。” 他认为用户体验和底层 AI 的实现逻辑是两个相互独立、互不干扰的问题。即便模型性能再好如果表层产品体验设计出现偏差整体产品体验也会大打折扣。见证模型领域的演进他见证了模型领域的演进长短期记忆网络LSTM、早期的编码器解码器架构、谷歌的 Transformer 论文以及初代 GPT。在每一个发展阶段他的团队早已明确了所要解决的问题只是当时的模型还不够强大。“如果你回看我们发表的论文这些相关领域我们都有涉猎” Sundaresan 说道“每篇论文都会提到哪种模型适合解决这类问题、哪种模型适合解决那类问题。”当前沿模型终于具备了足够的能力足以支撑更大投入并获得回报时Copilot 应运而生他说道。但到那时Sundaresan 也已经花了多年时间观察模型会在哪些场景出现问题——以及围绕模型的产品设计会在哪些环节出现疏漏。陈旧的训练数据会导致模型生成看似笃定却虚假的信息。无论任务是否需要都倾向调用性能最强、成本也最高的模型。在企业受限的运行环境中部署高性能模型也存在不小难度。在微软的经历“就连我们的客户也不放心把数据发送到我们的云端”他谈及在微软的早年经历时说道“他们希望数据留在客户端。所以我们让模型直接在个人笔记本上运行还为此投入了大量工程优化工作确保它能在笔记本有限的资源条件下顺畅运行。”为什么选择 IBM当 Sundaresan 讲述这段历史时一个显而易见的问题是他为什么把多年积累的知识带到了 IBM而不是某个更光鲜的地方。他直言不讳在微软待了十年后他想换个环境而 IBM 给出了一个很有说服力的理由。但还有一个不那么显而易见的答案对于他所研究的问题IBM 的所谓“劣势”实际上是“优势”。“仅软件部门我们就有近两万名员工。我们有完善的基础设施与咨询业务IBM 内部本身就有大量用户”他说道。“如果我能打造出让他们受益的产品这本身就是一个体量巨大的产品。”这种内部部署模式——IBM 称之为“零号客户”——给了他任何外部产品发布都无法提供的东西一个规模庞大、多元且愿意容忍早期产品缺陷、换取实际效率提升的固定用户群体。另一个优势在于工作负载的多样性。IBM 内部的开发者不仅编写 Python 和 Rust 代码还会使用 PL/I、COBOL、大型机 JCL还有被 Sundaresan 形容为“如同行业俚语一般的自定义语言”。只要 Bob 能够适配这么广的技术范围就能应对各类企业客户的任意开发场景。“在敲开客户大门之前我们就有故事可讲了”他说道。 他也直言不讳地说明了自己的研发定位不是面向开发者的通用工具而是一个专门针对企业场景的系统而大多数 AI 编码工具把这些场景条件当作边缘情况遗留代码库、严格的合规要求、混合环境以及 AI 生成的看似可以投产但实际上却不行的代码所带来的真实成本。没人谈及的成本问题与 Sundaresan 的对话中有一段十分坦诚的表述他道出了大多数开发者在不受约束的情况下如何使用 AI 编码工具。“人们会选择最新的 Claude Opus 4.7 这类顶级模型。他们可能只是执行一条简单的提示词但成本却高达每百万词元 40 美元”他说。“这就好比开着法拉利去便利店买牛奶完全没有必要。” Bob 不会向用户暴露底层模型它会根据实际任务需求自动调度路由可选模型包括 Anthropic Claude、Mistral 开源模型、IBM Granite以及多款专为 Bob 运行环境定制微调的专有模型。 这种智能路由能力正是 Sundaresan 认为的真正能体现架构设计价值的核心。“这并非简单地将各类模型接入系统”他表示“而是要把模型能力、产品体验以及能够支撑优质体验的架构有机结合起来。模型只是整体方案的一部分。”他介绍了在 IBM 内部用户群体中开展 A/B 实验的做法测试各类前沿模型变体、监测用户使用模式识别出高成本模型被滥用于普通模型即可胜任的场景。这种内部部署让这类大规模实验得以落地其规模是任何早期初创产品都负担不起的。智能体市场究竟将去往何方被问及 Sundaresan 对智能体 AI 炒作周期的看法他给出的会是研究者视角的答案而不是管理者视角的表态。“无风不起浪”他接受《The New Stack》采访时表示“如果炒作是烟那背后一定有火。火势或许没有烟那么大但火苗确实存在。”他的判断是基于智能体的开发模式确有实际价值但并非新生事物。基于服务的开发、基于 API 的开发、基于智能体的开发这些模式以往早已存在。真正的变化在于如今的接口是概率性、对话式的而非传统的确定性、程序化接口。这种转变催生了全新的能力同时也带来了全新的风险。“你也可以分散它的注意力”他谈及智能体系统时说。“你可以问不该问的问题或者透露不该透露的信息。”他所看到的 91% 失败的 AI 项目归根结底在于规范或者说纪律的缺失。企业以为和前沿模型提供商签个协议就够了但事实并非如此。“在把它们集成到你的软件产品之前你需要遵循已有的规范”Sundaresan 说道。他关注一个尚未得到足够重视的发展方向智能体之间相互交互对话最终会采用人类无法直接读懂的机器原生语言。“倘若这些衍生语言中出现漏洞差错这类错误很可能会呈爆炸式扩散蔓延”他说道。“未来还会有诸多变化发生。我们可以因为害怕而什么都不做也可以勇敢但系统性地向前推进。”