AI 编程观察：Composer 2.5 便宜了，但工程瓶颈没有消失

今天的 AI 编程新闻有两条线索值得放在一起看。

第一条是工具层面的：Cursor 的 Composer 2.5 继续把 coding agent 的成本往下压。Artificial Analysis 在 2026 年 5 月 21 日的评测文章中写到，Composer 2.5 在 Coding Agent Index 得分 62，排在 Claude Opus 4.7 max 和 GPT-5.5 xhigh 之后，但标准模式单任务成本约 $0.07，Fast 模式约 $0.44。DeepLearning.AI 的 Data Points 也提到，Composer 2.5 在 SWE-Bench Multilingual、CursorBench 等指标上接近一线模型，同时价格明显更低。

第二条是工作本质层面的：Arvind Narayanan 和 Sayash Kapoor 在 AI as Normal Technology 上发布长文，讨论为什么 AI 没有替代软件工程师，也不太会按“能力达到某个阈值就大规模裁员”的方式替代。他们把软件开发概括成一个 decide-execute-deliver sandwich：决定做什么、执行实现、交付并负责结果。AI 压缩的是中间的执行层，但两端的判断、验证和责任并没有消失。

这两条合在一起，正好说明当前 AI 编程的真实变化：代码生成正在变快、变便宜、变常态，但工程工作并没有因此自动变简单。

Composer 2.5 的意义：低成本 coding agent 进入日常区间

如果只看模型榜单，Composer 2.5 当然可以被写成“又一个强模型”。但更值得关注的是成本结构。

根据 Artificial Analysis 的数据，Composer 2.5 标准模式约 $0.07/任务，Fast 模式约 $0.44/任务；相比更高 effort 的 Claude Opus 4.7 和 GPT-5.5 组合，单任务成本低一个数量级以上。它还被描述为继续基于 Moonshot 的 Kimi K2.5 open weights 做训练，并由 Cursor 追加自己的训练和强化学习。

这意味着什么？

对普通开发者来说，这种模型不一定在每个复杂任务上都超过最强闭源模型，但它把“让 agent 多试几次”变得更可承受。过去你可能只愿意把最关键的任务交给高价模型，现在则可能把更多日常修改、文档整理、测试补齐、UI 小改、脚本维护交给一个便宜但足够强的模型。

对工具厂商来说，这也意味着 IDE 和 CLI 的竞争不只是“接入哪个大模型”，而是开始进入“为自己的工作流训练模型”的阶段。Cursor 不是只把通用聊天模型塞进编辑器，而是在尝试围绕文件编辑、终端执行、长任务迭代和错误修复来优化自己的模型。

这会推动一个明显趋势：AI 编程工具会越来越像完整工作环境，而不是一个侧边栏聊天框。

便宜代码会带来新的工程压力

低成本并不只带来好处。代码越容易生成，越容易出现两个副作用。

第一，团队会产生更多未经充分理解的代码。

当 agent 可以十分钟改完一批文件，人会自然倾向于让它多做一点。短期看，这是效率提升；长期看，如果缺少测试、日志、review 和回滚机制，维护成本会被悄悄推高。

第二，review 压力会从“写代码的人”转移到“负责验收的人”身上。

过去一个人写代码，他通常至少知道自己改了什么。现在 agent 可能一次改出很多文件，审查者需要额外花时间确认：需求是否理解正确、改动是否过大、边界条件是否覆盖、是否引入安全风险、是否影响后续维护。

这也是为什么“便宜模型”不等于“便宜交付”。模型价格下降，只降低了生成候选方案的成本；真正上线还要支付理解、验证、沟通和维护成本。

为什么“AI 会写代码”不等于“AI 替代软件工程师”

NormalTech 文章最有用的地方，是把“写代码”从“软件工程”里拆出来。

软件工程不是单纯把代码打进电脑。真正耗时的部分经常是：

• 识别用户真正需要什么；
• 判断一个需求是否值得做；
• 把模糊目标拆成可交付范围；
• 和历史系统、团队约束、上线风险对齐；
• 验证结果是否真的解决问题；
• 出问题后能追溯、回滚和承担责任。

AI 可以明显压缩执行层。它可以写函数、改组件、补测试、读日志、找错误、生成迁移脚本。这些能力已经足够改变开发方式。

但如果需求本身是错的，AI 会更快地把错误需求实现出来。如果验收标准不清楚，AI 会生成一个看起来合理但无法判断是否成功的结果。如果团队没有测试和回滚，AI 会更快地制造不可控变更。

所以更准确的说法不是“AI 替代工程师”，而是“AI 让工程师的工作重心上移”。人需要少写一些重复代码，多做一些定义问题、检查结果、设计验证路径和维护系统边界的工作。

小团队应该怎么用这类工具

对小团队来说，Composer 2.5 这类低成本 coding agent 很诱人。它能把很多原本不值得自动化的小任务变成可自动化任务。

但使用方式要克制。

第一，把任务切小。

不要一上来让 agent “重构整个系统”。更好的任务是：给某个表单补校验、给某个 API 增加错误处理、给某个脚本增加日志、给某个页面修复移动端布局、为某个函数补测试。

第二，每个任务都要有验收命令。

让 agent 不只写代码，还要说清楚怎么验证。能跑单测就跑单测，能跑构建就跑构建，能用浏览器手测就写下手测路径。

第三，把 AI 当作执行者和第二审查者，而不是最终责任人。

一个实用流程是：人写目标和约束，AI 给方案和补丁，AI 再自查风险，人运行验证，最后人决定是否合并。

第四，记录失败。

AI 编程工具最容易被忽视的价值，不是一次写对，而是失败后能留下线索。每次失败都应该记录：原始任务是什么、模型误解了哪里、测试暴露了什么、最终怎么修。

鲲鹏 AI 观察

今天这两条新闻的共同指向很清楚：AI 编程正在从“模型能力竞争”进入“工作流成本竞争”。

Composer 2.5 代表的是执行层成本下降。NormalTech 的分析提醒我们，执行层下降以后，真正稀缺的是判断、验证和责任。

所以，未来衡量一个 AI 编程工具，不能只问它是不是最强模型。更应该问：

• 它能不能在真实仓库里稳定理解上下文？
• 它能不能把任务拆小，而不是大面积乱改？
• 它能不能主动补测试和解释验证方法？
• 它能不能留下可审查的变更记录？
• 它能不能降低维护成本，而不是只提高代码产量？

如果答案是肯定的，它就是工程工具；如果答案是否定的，它只是一个很会写初稿的模型。

参考来源

• DeepLearning.AI: Cursor Composer undercuts competition
• Artificial Analysis: Cursor’s Composer 2.5: third on the Coding Agent Index and ~10-60x lower cost than rivals
• AI as Normal Technology: Why AI hasn’t replaced software engineers, and won’t
• Simon Willison: June 14, 2026 archive note on the essay