Salesforce 如何用 Claude Code 将有效编码产出翻倍

Salesforce 首席技术官 Muralidhar Krishnaprasad 表示，在 Dreamforce 上展示的几乎每个新应用或用户体验，都可能受到 Claude 的一定影响。被问及公司如今能交付哪些过去难以实现的产品时，他提到了 Claudeforce，以及让 Salesforce 应用不依赖常规界面也能访问所需的工作。

Salesforce 已经存在几十年，其产品并非每个部分都有 API，也就是供软件与之交互的接口。Krishnaprasad 估计，逐一检查应用的设置页面并补齐缺口，可能需要六个月到一年。他说，团队实际上用不到几个月，就让旗下各云产品的 API 覆盖率达到 80%–90%，期间也没有召开跨团队会议。他补充说，令人印象深刻的是，团队修改的是有几十年历史的代码，而非从头开始。

Boris Cherny 问 Salesforce 如何衡量工作加快带来的回报。Krishnaprasad 说，计算代码行数并不充分：有人可以增加注释，却没有让软件更有用。Salesforce 与 Stanford 的研究人员共同开发了“有效产出”评分，修改逻辑或创建新功能的权重高于添加注释和简单修改。

公司还会看每单位有效产出花费多少美元。Krishnaprasad 表示，这项产出指标已经翻倍，Salesforce 现在正为其他职能寻找合适的指标，例如处理的案例数量。公司会比较工作流或组织调整前后的结果，同时看 AI 的 token 消耗，再判断没有取得改善是因为工具使用方式不对，还是工具本身不适合这项工作。

Krishnaprasad 说，Salesforce 在软件开发流程的大部分环节都使用 Claude Code。为了让使用方式更加系统，公司制定了智能体成熟度曲线：许多工程师仍只让它完成小而简单的任务，而不是让智能体代自己开展工作。他说，在一两个月内，很大一部分工程师进阶到更高的阶段，产出和质量都有提高，缺陷没有翻倍。

Richard Pack 解释说，人们一开始常常只给出简短指令，却没有描述好的结果是什么样。这在简单任务上可能可行，到了耗时更长的任务就可能失败。后续步骤包括制订全面计划、使用智能体团队和承担子任务的智能体、在隔离的代码副本中拆分工作，最终实现更多工作流自动化。

Pack 举了一个进阶后的例子：一个智能体可以接手失败的自动化测试，调查并修复问题；另一个智能体可以审查并合并改动。Krishnaprasad 说，现在已有数千人以这种自主模式工作。一个主要挑战是让大家理解，更高阶段代表的是一种不同的工作方式，而不是单纯比拼分数。

推广工作依靠鼓舞人心的示范和真实数据。Pack 说，人们现场解决问题、分享结果，展示自己的工作方式。Krishnaprasad 补充说，团队在几周内做出了可能原本需要几个月才能完成的真实产品，让同事看到这种方法确实能有所帮助。

一位架构师告诉 Krishnaprasad，理解不熟悉的代码通常需要几天，还要与三四个团队交流。借助智能体理解代码后，她不再需要开这些会。他还说，越来越多人有兴趣在故障处理中使用智能体，因为工程师往往要花大量时间寻找应对故障所需的信息。

Krishnaprasad 说，现在每个团队都有故障处理智能体。他曾在 Slack 上看到一起故障：最初收到呼叫的是外层服务，实际问题却出在内部服务。智能体找到了原因和负责团队，通知了该团队，还提供了联系人。他说，否则可能要接连叫醒九个团队。

Salesforce 还建立了一个地方，让团队共享自己制作的可复用指令，也就是技能。Pack 说，这个想法发展成了带有评估功能的市场：团队可以重放使用和不使用某项技能的会话，也可以让 Claude 建议如何减少 token 消耗或更快得出结论。目的是判断共享技能是否确实改善了结果。

这个共享系统不只覆盖编码：它还帮助团队看清软件开发的哪些部分正在自动化，并在公司、团队和更小的小组层面设计工作流。Salesforce 有数千个代码仓库。Pack 说，要帮助工程师修复任何地方的缺陷，就需要找到相关的仓库和接口，然后在陌生代码中工作，提交高质量的代码变更。

Cherny 将这种模式描述为让创新自下而上发生，验证有效后再扩大应用，并询问有哪些保障措施。Pack 说，质量是核心：团队需要科学地评估能力在不同情境中的表现，了解技能创建者期望它达到什么效果，并检查其他开发者是否真的获得了这些价值。

Krishnaprasad 说，在最近加快工作的过程中，Salesforce 的代码量接近翻倍，但缺陷和客户案例没有随之翻倍。他说，平均每单位生成代码的缺陷反而减少了。他认为，传统和新的制衡检查机制帮助团队在产出增加的同时维持了质量。

被问及其他公司如何衡量时，Salesforce 团队表示，他们的起点是标注一致的工单，这些工单与提出的代码变更相互关联。Pack 的团队还从过去的工作中建立了一套基准。Salesforce 可以用新模型或新技能重放这些任务，比较结果和成本，再判断变化是否值得。

基准涵盖产品开发中的短期和长期任务，也包括模型反复失败的任务。Krishnaprasad 说，当新模型开始通过那些长期无法完成的任务时，就可能构成采用它的理由：公司可以由此发现此前无法利用的能力。

Cherny 问 Pack，在信任智能体之前需要什么证据。Pack 首先为好结果和坏结果设定客观标准。例如，如果任务是创建一个新的数据结构，反向测试可以检查智能体是否修改了现有结构或破坏了其他东西。他不会只要求智能体自我审查，而是让它找出相关特征，并在矩阵中展示证据和来源；如果做不到，就继续工作。

在任务规模上，Pack 通常更愿意将一组较大的功能打包，而不是分成许多小任务：极小任务的准备工作可能不值得。他会与模型或周边工具一起，将较大的任务拆成相互隔离的部分。只需几分钟的工作可以通过交互式会话完成，其他工作则积累起来一起处理。Krishnaprasad 补充说，前期规划越好，产出通常越多、质量也越高。

被问到推广过程中犯过什么错误时，Krishnaprasad 说，团队需要根据每项工作的长度和复杂度，以合适的价格选择合适的模型。有人曾使用强大的模型生成普通文件，而这些文件并不需要如此强的模型。选好模型会影响工作的回报。

Pack 回忆起一个产品缺陷：团队经过几次调查仍找不到原因。他们让 Claude Opus 调试代码、做出修改、编译，然后继续调查。他说，24 小时后，模型找到了问题并提出修复方案。由于这款业务软件对客户至关重要，错误答案可能影响财务，他强调要验证修复，确保解决小缺陷不会造成一个更大且同样难找的缺陷。

给首席技术官的建议是，Krishnaprasad 鼓励大家大胆行动，同时让管理层和实际工作的团队都能推动创新，并建立保障措施和供人分享的学习环境。Pack 则建议工程师深入尝试：他已经能够快速处理积压的工作，并以前所未有的方式了解团队的代码变更。他认为仍有很多东西值得探索和学习。