人工智能编码工具的真正能力无法通过基准来衡量——2026 年，您应该使用哪些标准来选择人工智能编码工具？

SolanaLink Tech，2026年8月1日

图片：（主图位于https://static.solanalink.jp/blog-and-news/ai-coding-tools-2026-<timestamp>.png）

阅读时间：18分钟

本文从四个角度对2026年的AI编码工具进行了梳理：层级分类、基准测试解读、实证研究以及日本特有的合规性问题。在论证了SWE-bench的饱和度以及厂商报告值的局限性之后，本文基于METR和DORA的实证结果，提出了合同开发公司应采用的分阶段实施策略和数据治理配置。

发布日期：2026年8月

该领域的模型和工具每隔几周就会更新一次。本文中的产品信息和数据截至发布日期均为最新信息，技术判断将定期更新。

引言

过去两年，人工智能在软件开发中的应用进入了一个质的飞跃阶段，从“代码补全辅助”发展到“自主任务执行”。

与此同时，关于工具选择的信息却令人困惑。**厂商发布的基准测试分数往往具有误导性，一些几周后就过时的模型版本号仍然出现在对比文章中。**此外，日本企业面临的实际问题——例如遵守《个人信息保护法》、在合同开发中处理客户代码以及数据驻留问题——却鲜有讨论。

SolanaLink 是一家位于东京的公司，同时负责合同开发和内部产品开发，我们在日常运营中经常使用这些工具。本文将总结截至 2026 年 8 月各工具的现状，并分享我们对如何解读基准测试、实证研究表明以及日本企业应采取哪些切实可行的策略的看法。

首先，让我们按“层级”来分析它们

为什么并排比较表格行不通

许多比较文章中常见的错误是将特性不同的产品放在同一层面上。

将 Cursor 和 Claude Code 放在同一个表格中比较，就相当于问“哪个更好”，集成开发环境还是命令行工具，这没有任何实际意义。实际上，将两者结合使用才是 2026 年的标准使用场景。

SolanaLink 通过将它们分为以下四个层级来评估 AI 编码工具：

第一层：编辑器集成（代码补全/内联编辑）

这类工具集成到现有编辑器中，可在输入时和本地编辑时处理代码补全。GitHub Copilot 和 JetBrains AI Assistant 就属于这一类。它们的入门门槛最低，在企业中的部署数量也最多。

第二层：基于代理的 IDE

编辑器本身被重新设计为 AI 代理的执行环境。 Cursor、Google Antigravity、ByteDance TRAE 等工具维护着整个代码库的语义索引，并能一致地处理多个文件的并发编辑、终端执行和浏览器操作。

第三层：命令行/终端驻留代理

这些代理直接驻留在 shell 环境中，并以非侵入式的方式集成到现有的开发工作流程中。例如 Claude Code、OpenAI Codex CLI 以及 Cline、Aider、OpenHands、Continue 和 Goose 等开源实现。

此层可以自托管，这对于合规性而言至关重要，稍后会详细讨论。

第四层：云端/异步代理

这些代理在隔离环境中执行任务，无需人工干预即可返回结果。例如 Devin（Cognition）、GitHub Copilot 编码代理和 OpenAI Codex 的云沙箱。提交问题后，系统会返回一个拉取请求。

我们的观点：第 1 至 4 层并非相互替代，而是互补。选择解决方案时需要考虑的问题不是“选择哪一个”，而是**“哪些任务应该分配给哪一层，以及分配的程度如何？”**。如果事先没有做好这方面的设计就贸然引入高性能工具，只会增加评审的负担。

主要参与者现状（截至 2026 年 8 月）

GitHub Copilot – 部署规模最大的平台

在对比文章中，GitHub Copilot 常常被忽略，但它在企业采用率方面仍然遥遥领先。**根据微软的财报，截至 2025 年 7 月，其累计用户已达 2000 万，并被 90% 的财富 100 强企业采用。截至 2026 年 1 月，付费用户数约为 470 万，同比增长 75%。

自 2026 年起，Copilot 引入了允许第三方代理运行的机制，进一步巩固了其作为“最大分发渠道”的地位。其编辑独立性、完善的知识产权补偿条款以及易于集成到企业 IT 采购流程中，是其被日本大型企业采用的关键因素。

Cursor（Anysphere）——资本市场估值最高的产品

该产品已成为基于代理的集成开发环境 (IDE) 的事实标准。其平均经常性收入 (ARR) 从 2025 年 1 月的 1 亿美元迅速增长，并在 2025 年 11 月由 Accel 和 Coatue 领投的 D 轮融资中实现了 293 亿美元的投后估值。

值得一提的是，其引入了专有模型 Composer。该模型旨在减少对高级模型的依赖并降低推理成本，并被定位为公司解决“包装型产品盈利能力问题”（详见后文）的方案。

另一方面，2025 年 6 月的计费模式变更（从基于请求的计费方式变更为基于代币的计费方式）引发了强烈反弹。出现了意外收费，导致 CEO 在同年 7 月正式道歉，并提供了部分退款。这次事件应该被视为企业采用按需付费工具的风险案例研究。

Google Antigravity——代理优先设计

这是一个于 2025 年 11 月发布的开发平台。它采用双层结构，将运行多个代理异步并行运行的“管理界面”与传统的编辑界面分离。其关键特性在于，代理通过内置浏览器执行 UI 测试，从而留下可追溯的执行过程痕迹。

据报道，核心开发团队由 Google 于 2025 年 7 月从 Windsurf（Codeium）引入。截至撰写本文时，该平台仍处于免费公开预览阶段，但免费层级已多次缩减，正式版的定价结构尚未公布。

Claude Code（Anthropic）——终端驻留开发领域的典范

它驻留在 shell 中，擅长长期自主执行、大规模重构和跟踪复杂的依赖关系。Hooks 机制和 MCP（模型上下文协议）使其能够轻松集成到现有的 CI/CD 和内部工具中。

虽然缺少图形用户界面 (GUI) 对初学者来说可能有些困难，但它能够在不中断现有开发流程的情况下引入，这正是经验丰富的用户选择它的原因。

OpenAI Codex——两种形式：命令行界面 (CLI) 和云沙箱

它不提供独立的 IDE，而是以 CLI、云执行环境和各种 IDE 插件的形式部署。它擅长在隔离环境中自动执行构建、测试和修复，因此非常适合大规模批量变更和测试修复工作负载。

JetBrains（AI Assistant / Junie / Air）——支持类型信息的智能体

对于主要使用 Rust、Java 和 Kotlin 等静态类型语言的组织而言，这是最被低估的选择。

由于该智能体可以直接访问 IDE 中保存的语义索引、类型信息和调用图，因此在分析大型代码库的变更时，它往往比其他依赖文本推理的工具更加准确。**它适用于包括 RustRover 在内的整个产品线，并支持本地模型（Ollama 等）连接以及通过 .aiignore 进行文件排除。

此外，还发布了一个名为“Air”的多智能体环境，该环境基于与 Zed 合作开发的开源 ACP（智能体客户端协议）。

Devin / Cognition——企业级自主智能体应用

Cognition 于 2025 年 7 月收购了 Windsurf 的产品、品牌和团队，并将其智能体产品套件整合到自己的产品线中。 日本是该公司继美国之后的第二大市场，并于2026年6月举行了日本市场战略简报会。

字节跳动TRAE及中国公司

TRAE凭借其慷慨的免费套餐和SOLO模式（一项允许使用自然语言和蓝图进行端到端构建的功能）迅速扩大了用户群。然而，它于2026年2月转型为基于代币的按使用付费模式。

在中国，阿里巴巴的Qoder（原名同一凌马，于2026年5月更名）、腾讯的CodeBuddy和百度的Comate已被广泛部署。

我们的观点：这些产品的技术水平并不低。但是，考虑到后文将讨论的数据治理问题，我们认为它们不适合用于处理合约开发中的客户代码。

开源/自托管系统——最容易被忽视的选择

Cline、Roo Code、Aider、OpenHands、Continue 和 Goose 等开源 CLI 代理可以连接到任何模型后端。将它们与开放权重模型（GLM、DeepSeek、Qwen、Kimi 等）结合使用，可以实现无需向外部发送任何代码的配置。

虽然在对比文章中很少提及，但在高度机密的合同项目中，这可能是唯一可行的解决方案。

主要工具概述

ツール	レイヤー	提供元	主な強み	主な制約
GitHub Copilot	1・3・4	Microsoft	企業導入実績・IP 補償・エディタ非依存	エージェント性能は専用製品に一歩譲る
Cursor	2・4	Anysphere	コードベース索引・成熟度・自社モデル	従量課金の予測困難性
Antigravity	2・4	Google	エージェント並行実行・実行過程の検証性	プレビュー段階・価格未公表
Claude Code	3	Anthropic	長時間自律実行・既存フローを壊さない	GUI なし・習熟が必要
OpenAI Codex	3・4	OpenAI	隔離環境での自動検証・大規模一括変更	独立 IDE なし
JetBrains Junie	1・2	JetBrains	型情報活用・ローカルモデル対応	JetBrains 製品群に限定
Devin	4	Cognition	完全非同期・企業導入支援	高価格帯・適用領域の見極めが必要
TRAE / 中国勢	2	ByteDance 他	価格競争力・機能の充実	データガバナンス上の制約
OSS 系 CLI	3	コミュニティ	セルフホスト可・完全な制御	自社での構築・保守が必要

关于模型基础架构——请勿将版本号作为选择标准

工具的性能取决于其背后的模型。截至 2026 年 8 月，Anthropic 的 Claude 系列、OpenAI 的 GPT-5 编码版以及 Google 的 Gemini 3 系列是主要选择。此外，主要源自中国的开源权重模型正在迅速提升性能，显著提高了自托管配置的可行性。

我们的观点：我们不建议使用具体的版本号作为比较的依据。该领域的模型每隔几周就会更新一次，等到文章发表时，它可能已经过时了。关键在于维护一个不依赖于特定模型的架构——将提示层和模型层分离，并保持它们易于替换。

该领域的模型每隔几周就会更新一次，等到文章发表时，它可能已经过时了。**

如何解读基准测试

这是本文最重要的部分。

SWE-bench Verified 已饱和且实际上已过时

SWE-bench Verified 长期以来被视为行业标准，但由于顶级模型的得分都集中在 88% 左右，其区分能力已大不如前。

此外，据报道，OpenAI 已于 2026 年 2 月停止使用该基准测试。该公司审计发现，相当一部分未解决的问题源于测试用例本身的缺陷。

自我报告值与第三方测量结果的差异

目前，Scale AI SEAL 排行榜上的SWE-bench Pro被认为更可靠。由于它是在统一的框架（执行平台）上进行测量的，因此可以对模型进行直接比较。

这里有一个重要的事实：

即使使用相同的模型，从 SWE-bench Verified 切换到 SWE-bench Pro 时，得分平均也会下降 20 分或更多。 此外，使用供应商自行优化的脚手架测得的值与使用第三方标准框架测得的值之间存在系统性差异。

换句话说，“SWE-bench 达到 90%”与“90% 的任务在实践中可以完成”之间没有任何关联。

脚手架作为混淆因素

代理的性能常常被忽视，它并非仅由模型本身决定，而是由“模型 + 脚手架”的组合决定。 即使使用相同的模型，得分也会因执行脚手架的设计而显著不同。供应商公布的数据几乎总是使用为其公司优化的脚手架测得的。

这与上一篇文章中讨论的TTS评估中的“自我参照陷阱”在结构上是相同的问题。当评估者和被评估者拥有相同的利益时，这些数据就不能被视为独立的证据。 **

实际解读

在SolanaLink，我们按照以下优先级顺序解读已发布的数据：

来自第三方标准化框架的测量结果（例如Scale SEAL）——最可靠
独立的测量和审计报告——可作为参考
供应商自报值——将其视为上限，不要用于预测实际性能

我们的观点：**基准测试分数并非选择工具的决定性因素。关键在于它是否能够真正对您自己的代码库、语言和审查系统产生有益的改进。这只能通过短期试点部署来验证。

生产力真的提高了吗？

虽然“人工智能已将开发效率提高了数倍”的说法广为流传，但严谨的实证研究却呈现出更为谨慎的局面。

METR 的随机对照试验

METR 于 2025 年 7 月发表的一项研究是该领域被引用最多的实证研究成果之一。

在一项针对 16 位经验丰富的开源开发者，共 246 项任务的随机对照试验中，使用人工智能工具实际上使工作时间增加了约 19%。

值得注意的是，存在认知偏差。参与者在试验前预测速度会提升 24%，但在试验后**自我评估的速度提升仅为 20%，**而实际结果却恰恰相反。

作为后续研究，METR 于 2026 年 2 月发表了一项新的随机对照试验的结果。这并非对初始研究的重新分析，而是使用全新参与者群体（57 位开发人员，超过 800 项任务）进行的重新实验。这是因为在初始研究中发现了选择偏差，其中 30-50% 被分配到“人工智能不可用”组的候选人拒绝参与，导致参与者群体存在偏差，他们不太可能从人工智能中获益。

修正后的新参与者群体的结果为**-4%（95% 置信区间：-15% 至 +9%）。虽然与最初的 -19% 相比，这代表着效率下降幅度的显著降低，但置信区间包含零，这意味着在统计学上并未显示出明显的效率提升**。METR 谨慎地得出结论：“人工智能可能在 2026 年初提升生产力”，但实际测量值仍然接近中性。最初 2025 年 7 月的结果被重新归类为“基于 2025 年初可用的人工智能工具”。 这一进展不仅表明结论的暂时性，也表明测量方法的设计（受试者的选择方式）如何影响结果。

DORA 的“信任悖论”

在 Google Cloud 的 DORA 2025 调查中，约 90% 的受访者使用过 AI 工具，许多人表示生产力有所提高。

然而，只有一小部分受访者表示他们“高度信任”AI 生成的代码，约 30% 的受访者表示他们“几乎不信任或完全不信任”AI 生成的代码。

此外，DORA 将 AI 描述为**“放大器”。** AI 可以加速流程完善的组织取得成果，但对于流程存在问题的组织，它也会放大这些问题。

对代码质量的影响

多项研究表明，近年来，发布两周内代码重写（代码变更）的比例呈上升趋势。这表明，AI 生成代码的增加可能伴随着代码审查工作量和返工的增加。

我们的观点：决定生产力的关键不在于选择何种工具。真正的区别在于维护一套针对人工智能生成代码的审查系统，并持续监控质量指标。在 SolanaLink，我们始终坚持对人工智能生成代码进行人工审查，并将 DORA 指标（变更提前期、变更失败率和返工率）作为运营指标进行监控。

日本市场的独特情况

日本人工智能编码工具的采用展现出与欧美不同的特点。这些特点包括对数据驻留和封闭环境的强烈偏好。

主要系统集成商和金融机构

NTT Data 已宣布一项政策，旨在大幅扩展生成式人工智能的应用范围，并已将其应用于众多项目。他们表示，在敏捷开发概念验证 (PoC) 中，编程工时显著减少，因此，他们提到将重新审视传统的按工月计费的合同模式。
野村综合研究所 (NRI) 已在其自有数据中心内构建了名为“NRI Private LLM”的封闭式平台，并拥有约 10,000 名用户。
NEC 正在部署其自主研发的 LLM（生命周期管理）“cotomi”，并于 2026 年 4 月成为 Anthropic 的全球合作伙伴。
瑞穗证券自 2026 年 4 月起在其生产环境中全面部署了 Cognition 的自主智能体 Devin。作为一家大型日本金融机构的大规模部署案例，此举备受关注。

企业应用案例研究

Money Forward 在其整个开发过程中部署了 Cursor，成为首家被列为 Cursor 官方部署案例的日本公司。其内部调查显示，每位工程师每周的工作时间减少了 15-20 小时。
GMO Internet Group 已与 Anthropic 建立战略合作伙伴关系，并在全公司范围内部署了 Claude。2026 年 6 月进行的一项定点调查（5,621 名受访者）显示，生成式人工智能的利用率达到了 98.7%，其中 Claude 的利用率超过了 ChatGPT。

国内LLM和主权云

作为一项独特的日本发展项目，国内LLM和主权云的开发正在稳步推进。软银旗下子公司SB Intuitions于2026年6月发布的Sarashina3，因其集成了内部知识库的编程支持功能以及在国内主权云上运行，在编码方面尤为引人注目。其他相关项目包括NTT的“tsuzumi”、Preferred Networks的“PLaMo”以及Sakana AI的努力。

日本厂商拓展

Anthropic于2025年10月在东京开设了其在亚太地区的首个办事处，并与一家日本人工智能安全研究机构签署了谅解备忘录。2026年6月，该公司在东京举办了开发者大会。 Cognition 于 2026 年 6 月公布了其在日本市场的架构。

我们的观点：日本市场的一个关键特征是数据主权优先于性能。在海外被视为标准的工具未必会被直接采用。相反，设计封闭网络、自托管配置的能力在日本市场是一项切实的竞争优势。

合规性 – 合同制定中的实际问题

法律框架

在日本，《人工智能促进法》已于2025年全面实施。然而，这是一部促进法，而非具有直接处罚条款的监管法。

实际义务源于现有的法律法规，特别是《个人信息保护法》（APPI）。经济产业省和总务省联合制定的《人工智能业务经营者指南》也是在遵守现有法律法规的前提下制定的。

合同制定中需要确认的三点

将源代码发送给外部人工智能服务商需要从以下几个方面进行考虑：

《个人信息保护法》（APPI）第20-22条：关于安全管理措施、员工监管和承包商监管的义务。如果代码包含个人信息作为测试数据或设置，则直接适用。
客户合同条款：将客户代码发送给第三方服务是否构成分包或信息泄露？许多标准外包合同并未包含预期使用人工智能工具的条款。
训练用途的有无：能否在合同或配置层面保证提交的数据不会被用于模型训练（零保留）？

处理中国工具

关于TRAE、Qoder、CodeBuddy等工具，SolanaLink采取以下政策：

我们认为这并非技术优劣之分，而是管辖权问题。这是因为企业遵守本国法律可能与其他国家的数据治理要求在结构上不兼容。因此，我们不会在处理客户机密代码的流程中使用这些工具，即使需要评估，也仅限于非机密的内部验证环境，并经过法律和安全审查。

截至本文撰写之时，日本政府尚未出台任何禁止使用这些工具的措施。是否使用这些工具由各公司自行决定。

配置选项

構成	データ送信先	適した用途
コンシューマ版 SaaS	ベンダークラウド	個人学習・非機密の検証
企業版 SaaS（ゼロリテンション契約）	ベンダークラウド	自社プロダクト開発
クラウド事業者経由（Bedrock / Vertex AI 等）	自社クラウドテナント	一定の機密性を要する案件
主権クラウド／国産 LLM	国内データセンター	データレジデンシー要件のある案件
セルフホスト（OSS + オープンウェイトモデル）	送信なし	最高機密・厳格な契約条件下の案件

成本结构的现实

从固定价格模式到按需付费模式的过渡已接近完成

在 2025 年至 2026 年间，主流工具陆续过渡到按需付费模式。Cursor 于 2025 年 6 月切换到基于代币的按需付费模式（如上所述，这引发了强烈反对），GitHub Copilot 也于 2026 年 6 月推出了积分系统。

**这具有重要的实际意义。名义月费不再反映实际成本。**这是因为，在代理长时间处理任务的使用场景中，实际消耗可能远超名义价格。事实上，已有多个案例表明，小型团队在短时间内产生的成本远远超出预期。

积分对初创企业的作用

大型公司会向早期企业提供大量积分。云服务提供商的积分有时可用于支付自有租户上的模型推理费用。

然而，我们的观点很明确。这些补贴用于产品获取，并不会改变企业的单位经济效益。 积分延长的是“产品适用性探索期”，而非收入结构本身。对于主要从事合同开发的公司而言，其收益有限。

实际控制

SolanaLink 采用以下操作流程：

为每个用户和每个组织设置每月限额
每周监控代币消耗
将低成本模型分配给日常任务，并将高级模型仅用于复杂的设计决策（分层管理）
如果封装产品的月度成本超过直接 API 使用成本 + 自托管配置预期成本的特定倍数，则审查配置

实用选择指南

第一阶段（0-1 个月）：奠定基础并进行试点

向所有开发人员部署第一层工具。 使用具有企业级应用成功记录的、与编辑器无关的工具作为基准。这降低了准入门槛，并为衡量有效性奠定了基础。
如果主要关注静态类型语言，则并行评估基于 JetBrains 的解决方案。 利用类型信息和语义索引的优势在大型代码库中尤为明显。
在非机密代码库中试点第三层 CLI 代理。 这主要针对重构、测试准备和长时间运行的任务。
首先建立代码审查机制。 对 AI 生成的代码进行人工审查，无一例外。这应该在第一阶段完成； 推迟实施将阻碍其建立。 **

第二阶段（1-3个月）：治理与成本控制

根据数据敏感性对项目进行分类并映射配置。 对于已签约的项目，务必确认合同中关于使用人工智能工具的资格，并根据需要添加条款。
将中国工具排除在处理客户代码的流程之外。
将成本控制融入运营。
开始监控质量指标。 持续衡量返工率、变更失败率和审查时间。

第三阶段（3-6个月）：避免数据被锁定

保持模型层的可替换性。 至关重要的是，不要因为与特定供应商的信用额度挂钩而固定设计。
推广高敏感项目的自托管配置演示。 开源模型和开源软件代理的结合已达到实用水平。

策略审查触发条件

如果返工率或变更失败率恶化 → 缩小应用范围并加强审查
如果特定工具的月度成本持续超出预期 → 考虑审查配置
如果客户合同要求数据驻留于国内 → 切换到自主云或自托管配置
如果收购或业务策略变更引发对依赖产品连续性的担忧 → 启动迁移计划，迁移到替代配置

总结

AI 编码工具分为四层，并排比较表格容易产生误导。真正的问题是：“哪一层应该负责哪项任务？”
基准测试分数并非选择标准。 SWE-bench Verified 已趋于饱和，厂商报告值与第三方测量结果之间存在系统性差异。
实证研究（METR、DORA）表明，AI 会增强组织现有的流程，单靠实施本身无法取得成效。
在日本市场，数据主权优先于性能。**设计封闭网络和自托管配置的能力成为一项实际的竞争优势。
在合同制定过程中，验证应用程序隐私信息 (APPI) 和合同条款是前提条件，并且需要根据项目的保密性采用不同的配置。
随着按需付费定价模式的转变，月度名义价格已不再反映实际成本。 将控制措施融入运营至关重要。

来自 SolanaLink 的信息

SolanaLink 致力于以符合日本法律体系和商业惯例的方式，为人工智能 (AI) 开发工具的引入提供支持。我们尤其在以下领域提供咨询服务：

AI 编码工具的选择和分阶段实施设计
在合同制定过程中，针对 AI 使用的治理和合同条款制定
在自托管/封闭环境中构建编码代理
基于 AI 生成代码设计审查系统和质量指标

我们提供以上领域的咨询服务。

如有任何关于内部概念验证 (PoC) 的考虑、现有工具切换评估、客户项目合规性设计等方面的疑问，请随时通过以下渠道联系我们：

咨询：info@solanalink.jp
公司简介：https://solanalink.jp

注意：信息有效期

本文中的产品信息、数据和技术判断截至2026年8月有效。该领域的模型和工具每隔几周就会更新，假设条件可能在六个月内发生变化。

此外，关于各公司的性能数据，我们已尽可能区分供应商自行发布的数据和第三方机构测量的数据。请在做出任何重要决定前查阅最新信息或联系我们。

本文仅供一般参考，不构成法律建议。请就《个人信息保护法》及其他相关法律的合规性咨询法律专业人士。本文不推荐或贬低任何特定产品或公司，文中观点基于我们自身业务环境下的判断。

参考资料

METR，“衡量 2025 年初人工智能对经验丰富的开源开发者生产力的影响”（2025 年 7 月发布，2026 年 2 月更新）：https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Google Cloud，DORA“DevOps 现状”2025：https://dora.dev/
SWE-bench 官方网站：https://www.swebench.com/
Scale AI SEAL 排行榜（SWE-bench Pro）
个人信息保护委员会（个人信息保护法及关于生成式人工智能的警告）：https://www.ppc.go.jp/
经济产业省和总务省“人工智能业务经营者指南”
各公司（微软/GitHub、Anthropic 等）的官方公告和财务报表OpenAI、Google、Anysphere、Cognition、JetBrains、NTT Data、NRI、NEC、瑞穗证券、Money Forward、GMO Internet Group、SB Intuitions 等公司）

本文由 SolanaLink 的工程师 Tony 撰写。欢迎评论和提问。

标签：#人工智能 #开发工具 #软件开发 #合规性 #日本市场