不写代码，但仍要为代码负责：AI for Code 这两年的变化

本文修订自我 2024 年 8 月 30 日的博文《AI for Code 产品收集》，2026 年 9 月按今天的情况重写。

写那份代码助手清单时，我刚开始用 Cursor，那篇博客就是在它里面写的。两周后，OpenAI o1 在 Codeforces 上冲到了 89 百分位，我当时的感觉是：代码生成这个任务快要被变革了。¹

变革来得比我想的快，也更彻底。清单上的 Codeium 改名 Windsurf 后被拆分收购，现在叫 Devin Desktop；Supermaven 并入了 Cursor；Cursor 自己又被 SpaceX 以 600 亿美元收购。清单里没有的 Claude Code 和 OpenAI Codex，成了今天被讨论最多的两款产品。

变化最大的是我自己。两年前我写代码，代码助手帮我补全和改写；今年我已经完全不写代码了，代码由 Agent 写、由 Agent 跑测试，我定需求、看结果、决定是否合并。这篇文章也一样：资料检索、核对和初稿交给 Agent，取舍和定稿由我来做。

但不写代码，不等于不用对代码负责。代码上线后出了问题，被叫去复盘的不会是 Agent，而是我。所以变重要的，是判断 AI 交回来的东西对不对、好不好、能不能上线。这件事没法靠写一句需求、然后等着“许愿成真”，它需要方法，也很考验人的功底。

还有一件事是两年前没想到的：Code Agent 读写文件、执行命令、调用工具、自我验证的那套能力，并不只对代码有用。2026 年，做 Code Agent 的公司几乎都把同一套 harness（模型之外的那层工具调用、上下文管理和执行环境）搬进了办公场景：Anthropic 有 Claude Cowork，腾讯在 CodeBuddy 之外做了 WorkBuddy，阿里有 QoderWork，字节有 TraeWork。交付物从代码变成报告、表格和 PPT，评估只会更难。

前半篇看产品：分工怎么变了，国内外产品这两年怎么变了，Code Agent 又怎样延伸成通用 Agent。后半篇回到人：不写代码之后我在做什么，为什么仍然要有人为代码负责，以及怎样评估 AI 的产出。

从代码助手到 Code Agent：变的是分工

两年前我也把交互式的 Code Agent 看作一个方向，但以为它和长上下文一样，只是代码助手演进的一条路线。实际上，它把整个品类的形态都换掉了。代码助手和 Code Agent 最大的差别，是谁来写代码、谁来判断代码对不对。

不只是我这样。几家公司披露的数字能说明大致的趋势：

• Google 在 2026 年 4 月表示，公司 75% 的新代码由 AI 生成、经工程师审批，去年秋天这个数字是 50%，2024 年 10 月约为四分之一；²
• Anthropic 发言人在 2026 年 1 月给出的口径是公司 70% 到 90% 的代码由 Claude Code 编写，Claude Code 自身约 90% 的代码由它自己写成；³
• 微软在 2026 财年第四季度财报会上说，GitHub 上三分之一的 PR 已经有 Agent 参与。⁴

这些都是公司自己披露的数字，口径不完全一致，“AI 生成”也可能包含人改过的部分，适合看趋势，不宜直接横向比较。但方向很清楚：写代码的一方换人了，判断代码对不对的一方没有换。

海外产品：两年间的重新洗牌

Cursor：从 AI 编辑器到 Agent 工作台

2024 年我刚用 Cursor 时，它的重点是四种交互：Composer、Chat、Tab 补全和选中代码后的 Edit。那时的 Cursor 是一个“内置了 AI 的编辑器”。

今年推出的 Cursor 3 把重心换了过来。官方的定位是“用 Agent 构建软件的统一工作台”：可以在本地、worktree、云端和远程 SSH 上并行运行多个 Agent，会话能在本地和云端之间迁移；从手机、网页、Slack、GitHub、Linear 发起的 Agent 都汇总在同一个侧边栏里；云端 Agent 完成后会附上演示录屏和截图，供人验证。⁵ 编辑器仍然保留，但已经只是其中一个视图。

另外两个变化：

• 自研模型：Cursor 今年先后发布了 Composer 1.5、2 和 2.5。Composer 2.5 基于 Moonshot 开源的 Kimi K2.5 继续训练，定价为每百万 token 输入 0.5 美元、输出 2.5 美元。⁶ 产品公司自己训练模型，这在 2024 年还很少见；
• 归属变化：Supermaven 在 2024 年 11 月并入 Cursor，用来改进 Tab 补全。⁷ 2026 年 6 月，已经合并了 xAI 的 SpaceX 与 Cursor 母公司 Anysphere 签署合并协议，交易以全股票形式进行，对 Cursor 的估值为 600 亿美元，8 月 14 日完成。⁸

Claude Code 与 Codex：模型公司直接做 Agent

2024 年这两款产品还不存在。

Claude Code 于 2025 年 5 月正式向公众开放。到 2026 年 2 月，它的年化收入已超过 25 亿美元，Anthropic 引用的一项分析估计，GitHub 全部公开 commit 中约 4% 由 Claude Code 撰写。⁹ 今年的两个更新能看出方向：7 月 Claude Opus 5 成为默认模型，在 API 和 Max、Team、Enterprise 套餐上提供 1M 上下文；8 月 14 日起，Pro、Max、Team 用户的新会话默认进入 auto mode，由分类器判断工具调用是否需要人确认，不再每一步都停下来问。Anthropic 称，Team 和 Enterprise 中采用 auto mode 的用户提交的 PR 多出约 25%。¹⁰

OpenAI Codex 覆盖 CLI、IDE 插件、云端和桌面应用。Codex 桌面应用今年初先在 macOS 推出，3 月上线 Windows，用来同时管理多个 Agent、并行处理长任务；OpenAI 披露，发布前一个月已有超过一百万开发者使用 Codex。¹¹ 之后 OpenAI 又推出 Agents API 公测，把驱动 Codex 的开源 harness 和沙箱直接开放给开发者。¹²

两年前，代码助手的后台是产品公司搭起来的一套系统工程：多模型协作、prompt 工程、RAG。现在，模型公司把模型和 harness 放在一起训练、一起发布，产品公司则开始自研模型，两条路在中间相遇了。关于 harness 的作用，我在 把书放回床头：我和大模型的向内求与向外看 里有更多讨论。

GitHub Copilot：从补全插件到 Agent 调度平台

Copilot 当年是商业化最成功的代码助手，现在依然是，但产品形态已经变了。

Copilot coding agent 可以直接被指派 issue，在后台异步工作，完成后提交 draft PR；提交前它会先用 Copilot code review 自审，并跑代码扫描、密钥扫描和依赖漏洞检查。¹³ 2025 年的 GitHub Universe 上，GitHub 提出了 Agent HQ；2026 年 2 月，Claude 和 Codex 以公测形式进入 GitHub 和 VS Code，同一个 issue 可以同时指派给 Copilot、Claude 和 Codex，再比较结果。¹⁴ 到 2026 财年第四季度，GitHub Copilot 用户达到 5000 万，6 月起改为按用量计费。⁴

GitHub 的优势在于 issue、PR 和 CI 本来就在这里。它没有去和别人比谁的 Agent 更强，而是把自己做成所有 Agent 的工位。

Codeium、Windsurf 与 Devin：一次收购串起两条路线

2024 年 8 月，Codeium 刚拿到 1.5 亿美元 C 轮融资，定位是 Copilot 的平替。之后它以旗下编辑器 Windsurf 为名，在 2025 年 7 月经历了一次罕见的拆分：OpenAI 约 30 亿美元的收购要约到期后，Google 以约 24 亿美元获得技术授权，并聘走了 CEO Varun Mohan 等核心成员；几天后，Cognition 收购了剩下的产品、品牌和团队，当时 Windsurf 的年化收入为 8200 万美元，企业客户超过 350 家。¹⁵

Devin 在 2024 年主打“端到端软件开发、自主编码”，早期评测并不理想。两年后，Cognition 把两条路线接在了一起：2026 年 4 月的 Windsurf 2.0 把 Devin 放进 IDE，并加入管理多个 Agent 的 Agent Command Center；6 月 Windsurf 正式更名为 Devin Desktop。¹⁶ 9 月，Cognition 以 480 亿美元估值融资超过 20 亿美元，年化收入从 5 月的 4.92 亿美元增长到接近 9 亿美元。¹⁷

Cognition 发布 Devin Desktop 时说，软件工程师的工作正在转向 Agent 管理，我觉得这句话概括得很准。

Zed：编辑器变成 Agent 的宿主

Zed 早期的卖点是高性能和多人协作编辑。

这两年 Zed 最重要的动作是推出 Agent Client Protocol（ACP）：一个 Apache 协议开源的标准，让任何 Agent 都能接入任何支持 ACP 的编辑器。第一个接入的是 Google 的 Gemini CLI，之后 Claude Agent、Codex、OpenCode 等陆续接入；JetBrains 也加入进来，和 Zed 一起维护 ACP Registry。¹⁸ 前面提到的 Devin Desktop 同样支持 ACP。

ACP 之于 Agent，有点像 LSP 之于语言服务。编辑器不一定要自带最强的 Agent，能把别人的 Agent 接得好，也是一种定位。

Supermaven 与 Magic：长上下文路线的两种结局

2024 年我很看好长上下文和长文本推理效率这条路线，代表产品是 Supermaven 和 Magic。

Supermaven 并入 Cursor，技术留在了 Tab 补全里。Magic 在 2024 年 8 月发布了支持 1 亿 token 上下文的 LTM-2-mini，累计融资 5.15 亿美元；¹⁹ 2026 年 9 月，它发布了一篇预训练进展，声称训练方法的算力效率比主流开源基座高 10 倍以上，文末写的是“期待把东西发布出来”，也就是说，至今还没有公开产品。²⁰

现在，1M 上下文已经是 Claude Opus 5 等旗舰模型的常规配置。回头看，长上下文是必要条件，但决定体验的是 Agent 能否主动检索、执行和验证：需要的上下文可以让 Agent 用工具去找，不必一次全塞进窗口。这一点在 Code Agent 的中控系统 里有更多展开。

Google：从 Code Assist 到 Antigravity

Gemini Code Assist 的企业版仍在继续。面向个人开发者，Google 这两年的产品线换了几轮：Jules 是异步的云端 Agent，在虚拟机里克隆仓库、制定计划、提交 PR；Gemini CLI 则已经过渡为 Antigravity CLI，与 Antigravity 2.0 桌面应用共用同一套 Agent harness，支持后台子 Agent 并行工作。²¹

新出现的一类：给不写代码的人用的平台

2025 年 2 月，Andrej Karpathy 提出了 vibe coding 这个说法：完全顺着感觉走，忘掉代码的存在。之后以 Lovable、Replit 为代表的平台，让不会编程的人也能用自然语言做出可上线的应用。Lovable 自称年化收入超过 5 亿美元，员工 146 人，平台上 80% 的用户认为自己是非技术人员（均为公司自报数据，未经审计）。²² 这类产品在游戏方向的延伸，可以参考 从 Vibe Coding 到 AI-Native Game。

小结：两年间的去向

国内产品：同样的方向，不同的约束

2024 年，国内大厂几乎人手一个代码助手，定位也相似：补全、问答、单测生成、RAG。两年后，它们演进的方向和海外一致，都加上了 Agent 模式、任务规划和 CLI。但国内多了一个约束：模型。2025 年 9 月，Anthropic 更新服务条款，禁止中国企业控股超过 50% 的公司使用其服务，无论公司注册在哪里。²³ 国内厂商的产品因此基本以国产模型为底座。

讯飞 iFlyCode、华为云 CodeArts Snap、商汤小浣熊和京东 JoyCoder，这两年我没有持续使用和跟踪，这里不展开。

国内产品有一个共同点：Trae 强调把 AI 编程过程“白盒化”，文心快码的 Spec 模式要求人先确认文档和任务再动手。它们都在解决同一个问题：代码不再由人写，人怎么知道 Agent 在做什么、做得对不对。

走出代码库：从 Code Agent 到通用 Agent

Code Agent 最底层的几个动作，读文件、写文件、执行命令、调用工具、检查结果，并不是代码专属的。整理一份销售报表、做一套 PPT、汇总一周的会议纪要，拆开看也是这几个动作。Anthropic 一篇介绍 Cowork 的博客里，作者说自己在 Cowork 出现之前，已经在用 Claude Code 处理非技术工作了。²⁹

2026 年，这条延伸线在国内外几乎同时出现，而且大多是同一家公司、同一套 harness，换了一层外壳：

• Anthropic Claude Cowork：2026 年 1 月推出，官方说明是“使用与 Claude Code 相同的 Agent 架构”，运行在 Claude 桌面应用里，不需要打开终端。它可以直接读写用户授权的本地文件，把复杂任务拆给子 Agent 并行处理，也支持定时任务，面向调研、分析、写文档这类非编码的知识工作；³⁰
• OpenAI Codex：6 月 OpenAI 公布，Codex 周活跃用户超过 500 万，其中知识工作者约占 20%，增速是开发者的 3 倍多。同时推出了面向不同岗位的插件，以及能让 Codex 直接做出网页应用并在团队内分享的 Sites；³¹
• Microsoft Copilot Cowork：6 月 16 日全球正式发布，是把 Anthropic 的 Cowork 集成进 Microsoft 365 Copilot，上线时跑的是 Claude Opus 4.8 和 Sonnet 4.6，预览期间超过一半的财富 500 强企业用过；³²
• OpenClaw：2025 年 11 月 Peter Steinberger 的一个周末项目，可以自托管，把 Agent 接进 WhatsApp、Slack、Telegram 等聊天工具，让人随时发消息派活。2026 年 3 月它的 GitHub star 数超过 React，到 8 月底约有 38.8 万。2 月 Steinberger 加入 OpenAI，项目转入独立基金会。³³ 微软在财报会上提到，自家的常驻个人 Agent 也基于 OpenClaw；⁴
• Manus：2025 年 3 月发布，是最早让人看到“通用 Agent 在虚拟电脑里独立干活”的产品。2025 年底 Meta 以 20 多亿美元收购，2026 年 4 月中国监管部门要求撤销交易，Manus 于 9 月恢复独立运营。³⁴

国内的几款产品，同样是从 Code Agent 长出来的：

• 腾讯 WorkBuddy：2026 年 3 月 9 日上线，官方说明它基于 CodeBuddy 同一套 Agent 架构构建，兼容 OpenClaw 的 skills，可以通过企业微信、QQ、飞书、钉钉远程给电脑上的 WorkBuddy 派任务，内置混元、DeepSeek、GLM、Kimi、MiniMax 等模型。腾讯同时披露，内部超过 90% 的工程师在用 CodeBuddy，AI 生成代码占比超过 50%；³⁵
• 阿里 QoderWork：2026 年 1 月 30 日发布，把 Qoder 的 Agent 能力从代码扩展到日常工作。它在用户本地执行任务，直接操作本地文件和应用，也提供隔离的沙盒环境；国内版 QoderWork CN 还支持浏览器自动化、桌面控制、定时任务和钉钉、飞书接入。同一系列的 QoderWake 定位为 7×24 小时的“AI 员工”；³⁶
• 字节 TraeWork：在 TraeCode 的 SOLO 模式基础上做成独立客户端，提供 Work、Code、Design 三种模式和网页、桌面、手机三端，办公助理可以接入飞书和微信（通过“微信 ClawBot”插件）；³⁷
• 月之暗面 Kimi Agent：2025 年 9 月推出 OK Computer 模式，让 Kimi 在自己的虚拟电脑里调用浏览器、终端、文件系统等 20 多种工具，官方的说法是“模型即 Agent”，通过端到端训练让模型本身获得工具调用能力。之后的版本支持最多 300 个子 Agent 并行的 Agent Swarm，并延伸出 Kimi Work、Kimi Claw 和 Kimi Code。³⁸

按使用场景把这些产品排在一起，大致是这样：

从这张表里，我看到四点。

第一，通用 Agent 的底座仍然是写代码。 生成一份带图表的 Excel、一套 PPT，Agent 在背后往往是写一段脚本再运行它；Codex 的 Sites 更直接，就是让 Agent 写一个应用并部署出来。代码没有消失，只是藏到了交付物后面。非程序员确实可以不看代码，但他拿到的结果，很多仍是代码跑出来的。

第二，harness 在趋同，skills 成了通用格式。 WorkBuddy 基于 CodeBuddy，QoderWork 基于 Qoder，TraeWork 基于 SOLO，Cowork 基于 Claude Code，都是把在编码场景打磨过的 harness 换一层界面。Skills、MCP、记忆和项目规则这些机制也一起被搬了过去，WorkBuddy 直接宣称兼容 OpenClaw 的 skills。关于 Skills 和 Memory 的作用，见 Agent 如何积累能力。

第三，验证比编码场景难得多。 代码有编译器和测试，一份调研报告、一套 PPT 没有，怎么评估这类产出，后文会单独讲。权限问题也更突出：通用 Agent 要碰的是邮件、聊天记录和本地文件。OpenClaw 爆红之后，维护者谈得最多的是贡献者信任、供应链风险，以及能力和安全之间的平衡。³³ Cowork 在操作每个应用前都会先征得同意；国内产品则普遍强调本地执行、沙盒和私有化部署。

第四，国内产品有自己的入口和约束。 企业微信、飞书、钉钉、微信几乎是国内通用 Agent 的标配入口；模型层基本是可切换的国产模型。Manus 的经历也说明，通用 Agent 的归属和数据存放不只是商业问题。

我不写代码之后，工作变成了什么

2026 年 2 月，Karpathy 在 vibe coding 提出一周年时换了一个说法：agentic engineering。他的解释是，“agentic”是因为新的默认状态是你 99% 的时间不直接写代码，而是编排写代码的 Agent 并负责监督；“engineering”是为了强调这里面有艺术、科学和专业能力。³⁹

这和我今年的状态基本一致。不写代码之后，我的时间主要花在这几件事上：

• 写清楚目标和验收条件：这比写代码更花时间。说不清楚“做完是什么样”，Agent 就会按自己的理解补全空白；
• 拆任务、决定并行度：边界清楚、验证便宜的任务可以并行派出去；涉及架构取舍的，先让 Agent 出方案，我来选；
• 审查结果：先看证据，测试有没有跑、跑的是不是原有测试、截图和预览对不对，再看 diff 的范围和结构；
• 维护项目规则：把 Agent 从代码里推断不出来的约束写进 AGENTS.md 这类文件，并定期删掉过期的内容；
• 决定什么时候停：验证不充分、权限不够或目标冲突时，让 Agent 停下来，而不是继续试。

用代码助手那会儿，我遇到的小插曲是续写候选太长、补全内容重复。这些已经不是问题了，新的插曲是这些：

• Agent 说“已完成”，但测试没跑，或者跑的是它自己新写、恰好能通过的测试；
• 修一个 bug，顺手改了不相关的文件，diff 变大，审查成本跟着上升；
• 代码能跑，但臃肿。Karpathy 在访谈里也说，他看 Agent 写的代码时常“有点心脏病发作”：臃肿、大量复制粘贴、抽象别扭又脆弱；⁴⁰
• 同时开的 Agent 一多，瓶颈就变成了我的注意力。Cognition 做 Agent Command Center，也是因为内部工程师在多个会话之间切换的开销太大。⁴¹

这些插曲有一个共同点：Agent 交回来的东西，看起来都像是做完了。写代码的成本降下来之后，成本转移到了定义和验证上。

不写代码的人，还需要看到代码吗

2024 年用代码助手时，我一直在想一个问题：使用代码助手的同学，如果 ta 不是程序员，ta 为什么需要看到代码？没有代码不是更好吗？用户应该只关注自己原来的问题，或者解决问题的步骤。

乔布斯在介绍 iPad 易用性的时候，曾经说：「即使是从未接触过计算机的两岁小孩也能在几分钟内学会 iPad 操作。他们可以用手指轻松地滑动、点击图标，看视频或玩游戏。」

对非程序员来说，这件事已经部分实现了：Lovable 这类平台上的大多数用户，从头到尾不需要读代码。即使是面向工程师的产品，人关注的对象也在往外移：Cursor 的云端 Agent 会附上录屏和截图，⁵ Claude Code 桌面版可以在对话旁实时显示 iOS 模拟器画面，¹⁰ 文心快码的 Spec 模式把需求文档和任务放在最前面，代码变更排在后面。²⁶ 通用 Agent 更进一步，交付的是报告、表格和网页，代码藏在后面。

但代码并没有消失。它仍然是可以审查、可以版本化、出了问题可以追溯的那份产物。线上出故障时，总得有人读得懂它、判断哪里错了。

所以我现在的回答是：不写代码的人可以不看代码，但必须有人为代码负责。对工程师来说，工作从“写出代码”变成了“对代码负责”：定义它应该做什么，判断它是否真的做到了，并在它出错时知道从哪里查起。

“负责”听起来像一种态度，落到每天的工作里，其实是一件很具体的事：评估。

评估 AI 的产出：新的基本功，不能靠许愿

以前检查和写代码是混在一起的，边写边查；现在写的人换成了 Agent，检查成了单独的一项工作，也是最难的一项。

为什么难

难在几个常用的信号都不太可靠。

• Agent 的自我汇报不可靠。 前面那些插曲就是例子：它说“已完成”，不代表测试跑过；它写的测试能通过，也可能只是和代码犯了同一个错。
• 人的感觉也不可靠。 METR 在 2025 年做过一次随机对照实验：16 位资深开源开发者在自己熟悉的仓库里完成 246 个任务，允许使用 AI 时反而慢了 19%，而他们事后自评快了 20%。⁴² 2026 年 2 月，METR 公布的后续实验无法可靠解读，主要原因是越来越多开发者不愿意在禁用 AI 的条件下工作，要么拒绝参与，要么不提交他们认为 AI 最有帮助的任务。⁴³ 连对照实验都难以做下去，“感觉更快”和“实际更快”就更难分清了。
• 外部的分数也不可靠。 2024 年，Genie、Gru、Honeycomb 这些产品还在用 SWE-bench 的分数证明自己。到 2026 年初，OpenAI 宣布不再报告 SWE-bench Verified：它审计了模型经常失败的那部分题目，发现至少 59.4% 的测试会拒绝功能正确的解答；而且所有被测的前沿模型都能复现部分题目的原始修复补丁，说明它们在训练中见过这些题。⁴⁴ 之后 OpenAI 又估计 SWE-bench Pro 约 30% 的题目有问题，撤回了此前改用 SWE-bench Pro 的建议。⁴⁵ 出题的一方都会出错，榜单上的分数就说明不了模型在我的仓库里表现如何。

与此同时，Agent 一次能做的事情越来越多。METR 的任务时长指标显示，前沿模型以 50% 成功率能完成的软件任务，对应的人类耗时在过去 6 年里大约每 7 个月翻一倍；在 2026 年 1 月更新的任务集上，2024 年以来的翻倍时间缩短到约 89 天，METR 也提醒，目前超过 16 小时的测量已不可靠。⁴⁶ 任务越长，交回来的 diff 越大，人审一次的成本也越高。

许愿和评估差在哪里

我说的“许愿”，是写一句需求，等 Agent 做完，看着像对就合并。它在小任务上经常能成功，所以很容易养成习惯。两种做法的差别，出现在每一个环节：

我的几条原则

• 说不出怎么验收，就先别让它写代码。 验收条件要在派任务之前写好。写不出来，说明需求本身还没想清楚，这时应该先让 Agent 调研、出方案，而不是直接动手；
• 能执行的检查，优先于文字描述。 “页面要好看”没法检查，“在 375 像素宽的屏幕上不出现横向滚动条”可以。能写成测试、命令或截图对比的，就不要只写成一句话；
• 不让同一个 Agent 自己判卷。 Agent 新写的测试，往往和它写的代码共享同一个误解。我更信原有测试、人写的关键用例，以及换一个模型或 Agent 做的审查。产品也在往这个方向走：Copilot coding agent 提交 PR 前会先做代码审查和安全扫描，¹³ Agent HQ 可以把同一个 issue 同时派给几个 Agent，再比较结果；¹⁴
• 按风险分配注意力。 不是每个 PR 都值得逐行读。文档、样式和一次性脚本，看证据就够了；涉及权限、数据迁移、支付、公共接口和架构的改动，一定要读 diff。Claude Code 的 auto mode 也是类似的思路，由分类器判断哪些工具调用需要人确认；¹⁰
• 同一类错误出现第二次，就写进规则。 把返工的原因写进 AGENTS.md 或 skill，评估标准就成了 Agent 下一次的上下文。

报告、表格、PPT 这类通用 Agent 的产出更难评估，因为没有测试可跑。能做的是核对来源、抽查关键数字，并要求 Agent 标出它访问不到的内容、不确定的地方，以及仍然需要人判断的事项，这也是 OpenAI 在 Codex 办公教程里强调的做法。⁴⁷

为什么说这是技能

判断一段代码好不好、一个方案有没有隐患、一个测试是不是真的在测行为，这些能力来自写代码和踩坑的积累。我不写代码了，但这些积累没有过时，反而是我现在用得最多的东西。前面提到 Karpathy 看 Agent 写的代码会“心脏病发作”，前提是他知道好代码长什么样。

Lovable 这类平台让不会编程的人也能做出应用，这是真实的进步。但做出来的东西是否可靠、出了问题从哪里查，仍然需要有人能判断。Agent 让写代码的门槛低了很多，判断的门槛还在。

落到团队：采纳率之后看什么

代码助手时代，大家看的是用户渗透率、代码生成比率和代码采纳率，其中采纳率被当作用户体验的关键。这套指标衡量的是“一次建议有没有被接受”。当交付单位变成一个任务、一个 PR，它就不够用了。团队层面，我会看这几项：

以前常说不能片面追求采纳率，换成合并率也一样。评测方面更系统的讨论，见 Evaluation of Code Language Models 和 长程 Agent 为什么会失效；验证、权限和长期运行，见 Code Agent 的中控系统。

展望

接下来，我会关注这几件事：

• 多 Agent 编排成为默认界面：Cursor 3、Codex 桌面应用、Devin Desktop 和 GitHub Agent HQ 都在做同一件事，把多个本地和云端 Agent 放进一个可以统一监控、审查的界面；
• harness 开放、可替换：ACP、OpenAI Agents API、Cursor SDK，以及国产模型接入 Claude Code 的编程套餐，都在把模型、Agent 和编辑器拆成可以自由组合的几层；
• 模型与产品的边界变模糊：Cursor 有 Composer，Qoder 有针对自家 Agent 强化训练的 Qwen-Coder-Qoder，²⁴ GitHub Copilot 里也有微软的 MAI-Code-1-Flash；⁴
• Code Agent 的 harness 走向所有知识工作：Claude Cowork、Codex、WorkBuddy、QoderWork、TraeWork 都是例子。编码场景先成熟，是因为它最容易验证；下一步要解决的，是没有测试可跑的工作怎么验收；
• 评估成为瓶颈：连公开基准的测试都有大量问题，团队自己的测试环境、验收标准和审查习惯只会更重要；一个人能同时管好多少个 Agent，取决于他评估得有多快、多准；
• 计费从席位走向用量：GitHub Copilot 6 月改为按用量计费，⁴ Qoder CN 的订阅席位引入了 Credits，²⁴ Agent 跑得越久，按人头收费就越难覆盖成本。

从卖 token 到卖结果

上面最后一条讲的是计费从席位走向用量，我觉得它还会再往前走一步。

现在几乎所有产品卖的都是 token，或者是折算成 Credits、请求次数的 token。用户一边干活，一边要盯着用量，还要自己判断什么事情用什么模型：简单改动用便宜模型，复杂重构换旗舰模型，选错了不是浪费钱，就是浪费时间。这种判断对工程师都是负担，对普通用户就更不友好了。用户真正想买的是一个具体的功能，比如一个能导出报表的页面；背后用了多少 token、调了哪几个模型，他并不关心。

按结果收费，就是把这个功能整个“外包”出去：约定好交付什么、怎么验收，按完成度付钱，token 和模型的选择由服务方自己承担。客服领域已经这样做了：Intercom 的 Fin 公开按结果收费，每个被解决的会话 0.99 美元，用户明确要求转人工的会话不收费。⁴⁸ 编程领域也有小团队在尝试，比如 MergeLoom 只在 Agent 提交出 PR 时才收费。⁴⁹

按结果收费要成立，有两个前提。

第一，双方对“完成”有一致的定义。这又回到了前面讲的评估：验收条件写不清楚，服务方和用户就会在“算不算做完”上扯皮。客服场景里“问题解决了没有”相对好判断，一个软件功能的完成度要复杂得多。反过来说，谁能把验收做成标准化、可以自动执行的东西，谁就更有条件卖结果。

第二，服务方的成本可控。按结果收费，失败重试和选错模型的成本都由服务方承担，所以它必须把每一步都交给“刚好够用”的模型。过去常见的做法是用一个大模型判断该用哪个模型，路由本身就不便宜。9 月 TypeSafe 发布的 Jev 提供了另一种思路：它不生成文本，只对给定的输入做结构化判断，返回选项和概率，价格是输入每百万 token 0.042 美元，输出免费。⁵⁰ LiteLLM 把它接进自动路由做了对比：在 80 个合成用例、每个跑 3 次的测试里，Jev 分类的中位延迟比 Claude Haiku 快 5.43 倍，分类成本低 96%。LiteLLM 也说明，这个结果依赖他们自己编写的用例和标签，没有测量最终回答的质量。⁵¹ 路由的成本接近于零，“让系统自己决定用什么模型”才有了经济上的基础。

所以我觉得这里是一个机会点：一边是足够便宜的路由，一边是足够可靠的评估。两边都做好了，服务方才敢按结果收费，用户也才能不再操心 token。

2024 年引用乔布斯那段话时，我希望工具能简单到让人忘掉代码。现在，工具确实让我不再写代码，但没有让我不再思考代码。需要思考的，从“这行怎么写”变成了“这件事该不该做、做到什么程度算完成、怎么证明它是对的”。最后这个问题答不上来，剩下的就只有许愿了。

参考资料

关于 Code Agent 的整体组件，可以阅读 A few things about Code Agent；中控、验证与权限见 Code Agent 的中控系统，RAG、Memory 与 Skills 见 Agent 如何积累能力。