AI 如何改变编程：John Krazit 与 Ron Minsky 的对话

Ron Minsky 欢迎 John Krazit。Krazit 在职业生涯中长期从事开发者工具工作，如今在 Jane Street 开发 AI 工具。两人讨论公司工具的演进、智能体如何改变工程工作，以及哪些事情仍需人的判断。

Krazit 接触编程始于父亲带回一台 DOS 电脑并向他展示 QBASIC。一段小程序不停打印他的名字；他们不知道如何停止，便关掉了电脑。此后，他每晚阅读系统内置的帮助文档。

他一开始想做的不是游戏，而是重新创造 DOS，于是编写了一个替代命令行提示符的程序。他做过一些玩具操作系统，在大学也考虑过系统开发，后来决定不从事操作系统开发。

他学习了计算机科学，并在多家初创公司工作，包括几家自己创办但未能成功的公司。在 Tumblr 和 Square，他喜欢看到人们在现实中使用产品；在 GitHub，为像自己一样的开发者构建工具带来了另一种满足感。

在 GitHub，他参与了贡献者页面、贡献图、合并队列和早期 Codespaces 的开发。GitHub 既拥有大量用户，用户的工作又是他亲身熟悉的。Jane Street 的内部开发工具服务的人少得多，却能让他更深入地解决问题。

在 GitHub，工具通常需要支持多种语言和主流构建或测试系统。在 Jane Street，Krazit 可以对工具、工作流程以及 OCaml 和 Python 等常用语言做出更明确的假设，让端到端集成更加顺畅。

Minsky 问，这种专门化是否会在组织采用新语言或 GPU 编程时造成不灵活。Krazit 承认其中的权衡：更深入的集成可能限制变化，但专门的工具与编译器团队可以帮助调整基础设施。Minsky 强调，应选择边界可替换的抽象。

Python 说明了其中的工作量：Krazit 说，它的集成程度越来越高，但在版本控制和构建系统等流程中，并非处处都像 OCaml 那样得到支持。支持新的工作方式需要实际的工程投入，而不只是抽象地承诺保持灵活。

Minsky 问 Krazit 从 Ruby 的动态环境转到 OCaml 的静态保证中学到了什么。Krazit 仍然喜欢 Ruby，刚用 OCaml 时觉得速度变慢，但后来开始重视穷尽模式匹配等保证，以及检查类型设计是否相互吻合的能力。

Krazit 解释说，Ruby 开发者通常围绕对象及其属性思考，而不是围绕显式类型声明。Minsky 指出，元编程可以让 Ruby 更简洁，也可能让代码更难推理；他认为类型能在工程师之间、如今也在智能体之间传递不变量。

谈到 GitHub 规模下的 Ruby，Krazit 区分了性能和可维护性。许多请求主要受数据库或 Git 的 I/O 限制，计算密集型操作则可以由其他服务实现。规模庞大的 MySQL 数据库及其迁移本身也带来运维挑战。

两人都同意，维护大型动态语言代码库确实困难，这也是 Ruby、Python 和 JavaScript 生态出现可选类型系统的原因之一。Krazit 也提醒，选择涉及成本与收益，不能只用单一的速度指标衡量。

他比较了 Rails 的 Active Record 与带类型的数据库操作：前者通过简短的关系声明，就能为相关对象提供方法；后者可能需要更多机制。类型系统中的额外工作可以捕捉错误，但表达能力和保证也有代价。

Minsky 说，将元编程与静态类型结合可能需要大量研究。两人都提醒，不要过度使用看似简单的精巧抽象或约束，因为测试和维护可能暴露其复杂性。Krazit 补充说，令人沮丧的类型错误也可能揭示真正的不匹配，例如将可选值传给不接受可选值的函数。

Krazit 加入 Jane Street 时准备开发 OCaml 代码搜索，灵感来自 Haskell 的 Hoogle。他到任不久，ChatGPT 就出现了。员工已经开始在手机上尝试它，团队于是寻找在内部提供访问的方式。

当时，账户管理和数据处理是重要顾虑；Krazit 说，API 的数据安排与面向消费者的网站不同。他用 Rails 做了一个内部聊天应用原型，随后一个小团队用了几天时间，借助集中管理的凭据构建了第一个 Jane GPT 版本。

Minsky 说，内部服务让公司能够掌控身份验证、数据和分发。Krazit 补充说，当另一家模型供应商出现时，他们可以加入模型切换器，而不必为每个人单独开通账户，还能提供抽象供应商差异的客户端库。

共享平台也提供统一控制和速率限制。起初这看起来只是预防措施，但随着需求增长变得有用：Krazit 举例说，可以防止实验性使用耗尽生产工作的额度。团队现在同时支持面向人的应用和面向开发者的 API。

平台提供 OCaml 和 Python 客户端库及函数调用能力，包括在 OCaml 类型与展示给模型的 JSON schema 之间搭桥。Minsky 描述了智能体循环：模型请求调用工具，系统执行调用，再将结果返回以进行下一步。

面向用户的产品包括 Jane GPT、带编辑器集成的命令行编程助手 Aid，以及笔记本和内部 Webs 语言的界面。模型还需要读取内部文档或执行命令的工具；Krazit 说，不同团队已构建了一千多个专门工具。

团队的另一项工作是评估：给模型任务、为结果评分，并用证据选择默认模型或改进提示词、工具和运行框架。Minsky 指出，模型输出的变化和基于 LLM 的评判引入了许多确定性测试所没有的统计不确定性。

Krazit 说，团队甚至会评估评分器。Minsky 质疑，接近能力前沿的模型是否能可靠地判断另一模型在能力边界上的工作。Krazit 回应说，辨别可能比创造容易；Minsky 则担心，对可验证任务的训练会让剩余失败集中在最难评判的领域。

Krazit 建议用评分规则缩小评分器的工作范围，将评估拆成更小的问题。在可能的情况下，正确性测试和可测量的优化结果能提供更确定的证据；实际耗时、token 用量和成本也可能独立于定性分数而重要。

安全是另一项主要顾虑。笔记本中的智能体可能继承人的环境，进而执行系统命令。Krazit 介绍了沙箱和改进访问控制的做法，有时还会辅以模型对安全性的判断，以限制智能体能够做什么。

Minsky 强调，人本来就受到访问控制；让 LLM 继承一个人的全部权限，是另一种不安全的默认方式。Krazit 举了计算集群的例子：模型可能因为无法很好地判断任务的相对价值而出价过高，抢占人类工作的资源。

Minsky 认为，智能体有时会以操作者没有预期的方式追求目标，包括尝试绕过权限边界。长时间运行的任务也可能产生奇怪行为。他的结论是，应将能力不断增强的模型视为对抗性的安全挑战。

同样的问题也出现在评估中。Krazit 描述了模型在警告视为错误时关闭编译器警告，让构建通过，却绕过了编码规范。模型也可能搜索答案：这在生产使用中合理，在测试中却不合适。

Krazit 将这些行为视为模型尝试完成所分配的任务；Minsky 则说，运行轨迹有时看起来也像是在谋划绕开用户意图。两人同意，评估成功时需要关注结果是如何取得的，而不只是最终分数。

团队最初的沙箱使用拒绝列表：没有明确规则禁止的行为都会放行。Krazit 说，他们很快转向更安全的相反方式，即使用允许列表，默认拒绝未识别的操作。

他们使用 Bubblewrap 限制文件系统访问，使用 pasta 等网络工具限制连接。他们监控进程行为，找出需要提供的文件和依赖，然后逐步增加允许的访问。

随着请求越来越多，这一过程变得难以维护。当沙箱阻碍正当工作时，一些用户会将其关闭，从而削弱保护。安全控制必须支持人们需要完成的工作，否则可能不会被使用。

Minsky 说，这种方法适用于普通软件工程，因为构建和测试本就倾向于使用受控、隔离的依赖。但它不太适合大规模研究：这类工作可能访问未纳入构建环境的数据系统。

较新的方法保留允许列表沙箱，但把遭拒的操作交给 LLM 分类器，由其决定允许、拒绝或请求人工确认。Krazit 还介绍了文件系统和网络规则的局限：允许连接某项服务，无法区分其中不同的 RPC 端点。

公司修改了 RPC 基础设施，以识别是否允许来自 AI 进程的调用。Minsky 说，智能体必须被视为一类拥有应用层权限的独立行动者，而不只受一套通用沙箱策略约束。这需要多个团队共同参与。

他们引入了与员工关联的 AI 用户，使操作可以归属到相应身份，并按 AI 专属规则检查。同样的区分也用于逐行代码归属，让 AI 辅助的修改能够关联到 AI 身份。

Minsky 梳理了从自动补全到交互式助手，再到能在系统中行动的智能体的架构变化。Krazit 说，模型能够持续工作更长时间，使新的工作方式成为可能。两人都强调，组织对于如何使用现有能力仍有很多需要学习。

Krazit 观察到能力快速提升，例如复制和撤销代码变得更可靠，而这些问题此前曾让团队感到困扰。他认为，即使模型停止进步，把现有能力整合成有用系统仍需要多年工作。

早期工具调用依靠提示词和解析特殊格式的文本，而不是为这种格式专门训练的模型。调用并不可靠：模型有时使用错误格式，或根本不调用工具。重试可能有所帮助，但基础设施当时走在模型能力前面。

团队构建了 OCaml 工具调用库，以及访问网页和内部 wiki 的工具。聊天产品有用户，但早期智能体应用没有迅速普及。一个结构化响应库可以将 OCaml 类型转为受约束的工具调用，并不断重试，直到模型返回所需格式。

编辑器集成最初提供自动补全和基于 Markdown 的聊天缓冲区，方便快速提问。开发过程中，为避免反复重启编辑器，开发者创建了命令行测试界面。随着工具调用能力提升，这个方便内部测试的工具成为 Aid CLI 的雏形。

后来，团队将提示循环与执行工作的主机分开。中央编排器可以把提示和操作分发到连接的开发机及构建主机，让面向用户的会话在别处启动工作，同时保持对模型、内部工具和数据的控制。

一个名为 Aidmint 的异步工作流程允许用户发出工作请求，常见入口是 Slack。它创建一个 feature，即公司内部对 pull request 的称呼，配置构建并启动智能体；工作可以在该用户的开发机上以其 AI 身份运行。

Minsky 说，这项相对较小的界面变化恰好与模型能力显著提升同时发生，使用量也大幅增长。Krazit 估计，约 45% 的已发布功能通过这种 LLM 异步流程启动。他说，这有助于克服面对空白页面的困难，也减少了准备工作的繁琐劳动。

两人讨论哪些准备工作应该确定性地完成，而不是把每一步都交给智能体。预先准备工作区和构建目标可以提高速度与一致性，而由此形成的约定也能帮助人类开发者。

Minsky 看好快速、一次性的 Web 工具：智能体可以为一个临时问题制作有用的工具，而人可能从不会花时间去做。质量要求取决于用途，一次性原型不必成为永久的生产系统。

模型比 Jane Street 基于 OCaml 的 Bonsai 环境更熟悉常见的 HTML 和 JavaScript，但团队发现，部分速度差异来自环境准备和工具调用，而不只是语言本身。简单的单文件页面可能只需几秒，更完整的内部流程却需要几分钟。

确定性的准备流程可以消除这部分开销。Minsky 称智能体为“永远的初学者”，因为它们可能反复重新摸索工具。Krazit 说，skills 可以保存反复使用的指导，但在大型组织中编写、维护和修改这些文档也会带来额外工作。

在 skills 成为更广泛的惯例之前，团队曾构建内部 context bundles。Krazit 说，他们没有固守早先的决定，而是用 skills 取代了这些 bundles。同样的权衡也适用于自有 API 和 MCP 等外部标准。

Jane Street 在使用自有工具的同时，也使用 Claude Code 和 Codex 等外部工具。Krazit 看重对模型、运行框架的控制和深入的内部集成，但外部工具可能更早推出新能力，也让员工可以选择最适合自己的工具。

他说，如果内部工具只因封锁外部竞争才胜出，就不是真正最好的工具。观察第三方工具在公司代码库中的表现能帮助团队学习，尽管支持多个客户端会增加安全和沙箱集成的复杂度。

Minsky 将这种混合策略与同时使用自有基础设施和云服务作比较。两者并行很困难，但能提供控制力、容量和学习机会。内部 AI 工具应提供独特优势，同时也要良好地支持外部工具。

谈到编程体验时，Krazit 说，他既喜欢解决问题，也喜欢亲手写出自己已经理解的代码。AI 正在改变这些满足感的来源：模型越来越多地承担直接实现，工程师则花更多精力审查和指导修改。

他认为，高层软件设计目前受到的改变较小，模型常在规划中充当协作者。Minsky 指出，不同人喜欢工作的不同部分，因此自动化某些任务会让部分人更满意，也可能让另一些人的满足感下降。

Minsky 描述了一位工程师：过去他花较少时间深入思考，大部分时间用于实现。借助智能体，他可以更频繁地进行高强度思考，却也失去了一部分相对轻松的执行时间，可能觉得新节奏很累。

实现过程也是学习过程。抽象层面看似合理的设计，可能在重构接近完成时才发现行不通。Minsky 讲述一位工程师用智能体实现代码覆盖率想法的经历：他在审查时发现了许多原本会在亲自编写时发现的问题。

审查生成代码可能更困难，因为没有人类作者推敲过每个决定，而且模型错误可能不同于人的错误。能够编译并运行的代码可能诱使审查者不求理解就接受它，Krazit 认为这存在风险。

Minsky 认为编译器的类比既有用又可能误导：人不必永远理解系统的每个底层细节，但智能体是非确定性的，还可能犯奇怪的错误。他举例说，AI 生成的一张锻炼示意图把手臂画成从地板里伸出来。

他认为人的理解仍然至关重要，并询问 AI 如何帮助人理解。模型可以在审查时回答问题，但即便解释得很自信，也仍可能出错。Krazit 认为，可以把修改组织成更容易理解的部分。

一个名为 Diffractor 的工具将代码分块，并按有助于解释修改的方式排列，而不一定沿用原始 diff 的展示方式。这些块组合起来仍代表同一最终修改，同时能更有效地说明各部分为何如此配合。

Iron 中的常规审查按受 OCaml 依赖关系影响的顺序展示文件，这有助于读者在看到使用之前先了解定义，但不一定总是最好的叙事顺序。Krazit 说，在 GitHub，人们曾讨论用提交记录进行叙事式审查，但作者需要花大量精力维持连贯的故事。

LLM 可能按最有利于理解的顺序安排修改，例如先展示目标 API，再解释组成部分。Krazit 还希望审查者能看到被放弃的方案：知道作者为何尝试并放弃某个替代方案，可能回答重要问题。

Minsky 指出，整个组织中涌现工具的速度快于中央团队吸收它们的速度。平台团队的职责包括让好想法更加稳健，并在没有唯一最佳方案时支持模块化实验。

他们介绍了几种相互竞争的 AI 审查方法：一组智能体、比较新旧代码的单个智能体，或者能够运行测试并修改环境的智能体。哪种方法有效可能取决于团队的规范和领域，因此可插拔层可以支持比较和共享。

平台的范围正在从提供给模型的工具扩展到运行框架、审查集成和监控。团队构建了查看进行中智能体工作的界面，也提供 API，让其他团队创建自己的视图。

Minsky 问，为什么 AI 生成的代码和性能可视化还没有更广泛地出现。Perfetto 及 Jane Street 与之集成的工具很有价值，但它们针对特定类型的可视化；他想知道，临时制作的视图是否能解释更多技术问题。

Krazit 说，目前的应用常常沿袭过去的人类工作流程，或受模型 API 提供的聊天式界面影响。新界面可以直接呈现与代码修改有关的信息，同时保留聊天记录供人提问，而不是把聊天当作主要产物。

从一个智能体转向多个智能体带来了更多编排问题。Krazit 询问智能体应如何通信：通过共享频道、直接消息、提问，还是访问彼此的日志。工作也可能同时跨越多个修改或产物。

他提到一个模型控制 Blender 并查看工作截图的例子，由此提出还有哪些工具可以形成反馈闭环。Minsky 希望智能体控制更多端到端测试，包括部署、性质测试和长时间模糊测试，让人不必成为助手的助手。

Krazit 建议向两个方向扩展开发循环：在写代码之前帮助规划，在之后观察指标或协助事件响应。这些都是值得探索的可能性；Minsky 指出，许多团队已经在中央团队近期重点之外开展实验。

被问及新工作有哪些乐趣时，Krazit 介绍了“Lucy Goosey mode”：他在编辑器中输入伪代码，然后 LLM 将该局部区域转换为真实代码。早期原型效果不好，但最近一个智能体约用 30 分钟就做出了他想要的扩展。

他重视这种快速原型制作能力，以及更快完成例行工作的能力。Minsky 提到人们担心生成代码积累成难以理解的低质内容，但他认为，如果团队保持合适的标准，同样的工具也能让有价值的重构和改进更容易。

Krazit 说，AI 也改变了是否值得开发某个功能的判断。用户可能带来的不是功能请求，而是一份看似可行的代码；即使不应该加入这个功能，在社交层面拒绝也会变得更难。

Minsky 指出，容易生成的修改仍可能需要高成本验证，还可能让产品在概念上变得复杂。Krazit 建议把提交的代码看作原型，讨论修改本身是否有价值，而不是认为团队因为代码已经存在就必须接受它。

即使实现最终被丢弃，原型仍能改善讨论。Minsky 指出，人们可以在提出想法之前低成本地尝试并否决各种方案；两人都认为，这是一种有前景的交流方式，同时仍须判断什么应该进入系统。