随着 GitHub 将其第三方编码智能体扩展至 Claude 和 Codex，它希望借此巩固开发者对其平台的忠诚度。

开发者从未像现在这样倾向于使用 AI，但也从未像现在这样不信任其输出。在 Stack Overflow 的调查中，在开发中使用 AI 工具的受访者比例持续攀升（2023 年为 44%，2024 年为 62%，2026 年为 83%），但信任度并未同步跟上。在 2025 年的准确性问题上，只有约 33% 的人信任 AI 的输出，而 46% 的人不信任。2026 年 Stack Overflow 更改了问题，但仍发现只有 7% 的开发者信任 AI 处理重要的工作决策，如果能够轻松核查输出，这一比例则上升至 48%。

因此，采用率远远领先于信任度。这很可能正是某人介入并弥合信任鸿沟的机会。

GitHub 在这方面有机会，即使开发者更偏爱其他公司的编码智能体。团队已经在使用它来检查、测试和审查代码。帮助他们以同样的方式处理来自 Claude 或 Codex 的工作成果，既给开发者提供了更多选择，又让自身平台更具粘性。这是一招极其聪明的柔道式策略，但它能奏效吗？

早在 2023 年，我就担心 GitHub 对 Copilot 的热情可能会让它忽视 Git，尤其是那些让该平台变得有用的可见性和协作能力。现在有了一个更好的可能性：AI 可以让这些能力变得更有价值。随着提出变更的工具数量不断增加，企业需要在检查、测试和接受这些变更的方式上保持连续性。简而言之，AI 可能让 GitHub 比以往任何时候都更具相关性。

使用并不等于信任投票

我们使用 AI 来更快地构建，并不意味着我们一定信任它。2026 年的调查明确区分了这一点。其修订后的信任问题询问的是人们在什么条件下依赖 AI。结果呢？大约 48% 的人表示他们信任 AI，但前提是能够轻松验证输出。只有 7% 的人无条件信任 AI 处理重要的工作决策。如前所述，这些数字无法与之前的准确性问题直接比较，但它们确实描述了一种务实的交易：人们想要帮助，但越来越多地，他们也想要可以核查的证据，因为他们担心 AI“几乎正确，但并非完全正确”。

这是一种明智的 AI 使用方式。助手可以通过查找不熟悉的 API（应用程序编程接口） 或提出小改动来节省时间，而我们无需同时赋予它全权来判断客户的付款是否被正确处理。我们对 LLM（大语言模型） 的信任应该与特定任务及其后果挂钩。

公司的标准不应仅仅因为代码是智能体编写的就改变。审查者仍然需要知道变更的目的是什么、通过了哪些检查，以及是谁接受的。这样团队才能随着时间推移获得信心，委托更多工作。

不同的智能体，相同的规则

GitHub 已开始围绕这一机会进行构建，力求成为更广泛 AI 工具生态中的治理层。因此，其第三方编码智能体（目前处于公开预览阶段）包括 Claude 和 Codex，而不仅仅是 Copilot。一个 issue 或提示词可以转化为一个提议的变更、一个 pull request，或一个供进一步审查的 issue。GitHub 表示，在其平台上运行的这些智能体享有与 Copilot 云智能体相同的安全保护和限制。需要注意的是，这些策略不会自动扩展到 VS Code 中的本地智能体，这是一个重要的边界。

有用的部分是连续性。公司可以尝试不同的生成器，同时在工作评估环节保持一致。需求、现有测试、审查职责和验收规则不应因为偏好的助手变更而需要重新制定。正如我所指出的，鉴于事物发展之快，为 AI 的变化而设计架构非常重要。

设想一个智能体被要求修复一个授权漏洞。公司需要保留一个简单的要求：一个客户绝不能读取另一个客户的记录。从 Copilot 切换到 Claude 不应改变这一要求，也不应改变执行该要求的回归检查，或谁有权接受补丁。如果架构正确，新智能体只是在既定流程内工作的另一个供应商。

企业可能会花费大量精力将工具适配到其现有的职责和流程中。如果切换智能体迫使它们重建这种安排，那么模型选择的成本将变得高昂，而订阅价格无法体现这一点。一个能保留这种安排的平台可以让实验变得切实可行。有理由相信 GitHub 可以成为这样的平台，正如它多年来在人类驱动的开发中所做的那样。

优秀平台的引力

GitHub 不会仅仅通过收集智能体活动就变得值得信赖，其企业信任的历史也不能保证其未来。但 GitHub 处于有利位置，可以帮助开发团队将证据与他们即将做出的决策联系起来，并提供足够的上下文来质疑那些看起来不错但可能并非如此的代码。

顺便说一句，我并不是建议我们需要确保系统（无论是 GitHub 还是其他什么）永远坚持对每一个琐碎变更进行验证。GitHub 最近在公开预览中推出了一项可选功能，允许 Copilot 代码审查批准拉取请求并满足必需的批准规则。它不是自动的；管理员必须启用它，并且可以按文件路径进行限制。但这是一个很好的迹象，表明事情的发展方向。

它也相当有用。团队可以合理地自动化接受某些常规变更，同时将敏感工作留给知识渊博的审查者。但启用另一个人工智能批准本身并不能提供独立证据。公司仍然必须决定哪些检查可以证明这种权限是合理的，以及何时必须由人介入。GitHub 自己的文档警告说，Copilot 审查可能会遗漏问题，并建议辅以人工审查。

我喜欢 GitHub 的做法。虽然有些人担心 GitHub 的微软化，认为该公司正在让 GitHub Copilot 服从于销售微软人工智能服务这一更大的任务，但 GitHub 开放对第三方智能体的访问实际上是开发和商业上的天才之举。对于开发者来说，他们可以使用任何他们想要的前沿模型，并通过 GitHub 方便地计费。这样，即使 Claude 或 Codex 赢得了编码任务，GitHub 也能留住付费客户。具有讽刺意味的是，这种扩展的选择使得 GitHub 作为一个平台更加难以离开。企业应该权衡一致审查和控制的便利性与对 GitHub 更大依赖的可能性，但便利性通常会在开发者中胜出。

其他平台也可以提供类似的控制，所以 GitHub 并不能梦游般地走向长期的智能体成功。即便如此，它有一个明确的机会，让开发者可以更换编码智能体，而不必让公司重建将代码投入生产的流程。如果 GitHub 能做到这一点，即使别人编写代码，它也能留住客户。这是一种非常聪明的方式，既坚持了 GitHub 对开发者需求的长期关注，又提供了一个非常以微软为中心的平台未来。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：InfoWorld

原创地址：https://www.infoworld.com/article/4233357/ai-distrust-is-githubs-opportunity.html