Opus 降价 40%，GPT-6 直接砍半：写代码越来越便宜，你的工程为什么没变快？

40%，50%——9 月 22 日这一天里，两个百分比把 AI 编程的成本线又往下拽了一截。

先是 Anthropic 发布 Claude Opus 5.5：每百万 token 输入 4 美元、输出 20 美元，比上一代 Opus 5 低 20%；缓存读取从 0.5 美元降到 0.2 美元，降幅 60%。官方给了个总结口径：按典型负载算，整体运行成本比 Opus 5 低约 40%，输出速度快三成以上，模型默认带 100 万 token 的上下文窗口。

大约 90 分钟之后，OpenAI 端出 GPT-6 Sol 和 GPT-6 Luna：Sol 每百万 token 输入 2 美元、输出 10 美元，Luna 是 0.1 美元和 0.5 美元，比 GPT-5.6 的促销价低 50%，缓存输入读取打到一折。OpenAI 的说法是，Sol 在自家评测里的错误率大约只有上一代的一半。

两家同一天、前后差一个半小时，做的是同一件事：让"写代码"的单位成本再便宜一截。

问题是，如果你手上正带着一个项目，你的交付速度变快了吗？

便宜的是哪一段

先看降价的具体形状，它比"便宜了"三个字信息量大得多。

这轮降得最狠的不是输入输出，是缓存读取。Opus 5.5 的缓存读取降 60%，OpenAI 那边是九折之后再九折，等于打到一折。原因不难猜：agent 干活时最大的一笔开销，是把同一份上下文——同一个仓库、同一批文件、同一段历史——反复送进去。Anthropic 自己说，缓存读取占了 agentic 编程成本的绝大部分。

换句话说，这轮降价的真正指向，是"长时间、反复读同一份代码库"这类工作。而这恰好就是后端工程师每天在干的事。

没变便宜的是哪一段

换个角度看这笔账。

Sonar 2026 年那份 State of Code 调查（1149 名开发者）里，验证工作约占开发者 35% 的工作时间，而且这个比例在 AI 大量参与之后并没有降下来。LinearB 2026 年的数据里，AI 参与之后的 PR 体量约为之前的 2.6 倍，但 merge 率不到一半。GitClear 2026 年的报告里，代码 churn——写完不久又被改掉的部分——同比上升 39%。

三个数字指向同一件事：便宜的是生成，贵的是"确认生成出来的东西是对的"。

生成成本可以从每百万 token 20 美元掉到 10 美元；对齐成本不会跟着打折，因为它花的是人的注意力，不是 token。

对齐为什么会贵

跨层工作里最贵的从来不是写，而是"两个东西已经各自存在了，现在要让它们一致"。

后端接口返回 pageNum，前端页面用 page；接口约定返回数组，前端按对象解构；数据库字段叫 create_time，DTO 里写 createdAt。这些都不是编码能力问题。任何一个熟悉两端的人五分钟就能改对，难的是发现——而发现通常发生在联调那天，成本已经花出去了。

更要紧的是，这类问题会随着产出速度上升而变多。写得越多，两端各自长出来的假设就越多，需要对齐的面就越大。

契约定得越早，对齐成本越低

前面那段分析里，对齐之所以贵，根源是"发现得太晚"——两个产物都做完、各自都跑通，才发现对不上。

在飞算JavaAI 的智能会话里，/前后端设计 这条指令的顺序是固定的：先读上游的需求文档，做数据库设计与 API 接口设计，然后依据 API 设计文档去设计前端页面。也就是说，页面不是先画出来再去找接口，而是接口先定、页面照着接口长出来。接着 /后端开发 按已经定下的 API 接口规范写实现，不再自己另定一套。整个过程产出的工作区上下文、技术栈决策、数据库设计、接口设计、技术需求覆盖、后端设计规范基线，都落在项目的 docs 目录里。如果不想一条条发起，/全栈 是把需求分析、前后端设计、前端开发、后端开发四个环节串起来推进的那一条——一次发起、四个环节依次走，中间遇到需求说不清的地方，仍然会先回来问你。

因果就在这里：pageNum 和 page 这类问题之所以要拖到联调才爆，是因为两端各自开工的时候，手里没有同一份依据。把接口设计放在前端页面设计之前，等于把"对齐"从"事后补"挪到"事前定"——发现成本从联调那天挪到设计那天，后者便宜得多。降价降掉的是生成的钱，这个顺序省下的是返工的钱。

边界也要讲清楚：契约先定不等于需求一定对；前端用什么技术栈，也不是开发者现场随手挑的，而是由上游的技术栈决策文档确定。这套顺序保证的是"两端照同一份约定写"，保证不了业务规则本身正确——那部分仍然得靠人来定。

省下来的时间去了哪

生成便宜之后，省下的时间有两个去处：一个是真省下来，一个是又花在了别的地方。想分清这两件事，可以看三个信号。

第一个信号是联调等待时间。如果前后端各自做完、卡在"对不上"上折腾的天数没变，说明省下的只是写的时间，而写本来就不是瓶颈。

第二个信号是 PR 的构成。翻一翻最近的合并记录，看有多少改动属于"重命名、参数对齐、字段补齐"这一类。这类改动占比高，说明契约在前一个环节没有定死。

第三个信号是返工率。GitClear 统计的那个 churn 指标——写完不久又被改掉的比例——同比涨了 39%，它衡量的正是"生成完之后多久被推翻"。

三个信号指向同一处：省 token 是模型厂商的事，省返工才是工程的事。

便宜掉的是边际成本，转移到的是协调成本

把降价放进项目里看，它更像一次成本转移，而不是成本消除。

生成代码的边际成本确实在掉，每百万 token 的价格摆在那里。但一次需求里的协调点数量没变：接口路径、字段命名、分页方式、状态码、错误结构、鉴权方式，每一个都是两端至少要对一次的约定。约定越多，协调成本越高——而协调花的是人和时间，不是 token。

这解释了一个让人困惑的现象：账单降了 40%，排期表没什么变化。因为降价作用在"写"这一段，而卡住交付的那一段本来就不在"写"上。

便宜之后，比拼的东西换了

生成成本再降，也不会自动变成交付速度。当写代码足够便宜，团队之间被拉开差距的地方，会从"谁能写出来"转向"谁能更早把该对齐的对齐、把该验证的验证掉"。

这对个人也是一样。过去"会写"是稀缺能力，现在更稀缺的是知道该在什么位置停下来确认一下——把契约先定下来、把假设先问清楚、把验证放在提交之前。这些动作不产生代码行数，但它们决定生成出来的东西能不能直接用。

价格战大概率还会继续。但对写代码的人来说，值得盯的不是又降了几个点，而是省下来的那部分时间，最后落在了哪里。

你们项目里，前后端的接口是对着文档写的，还是各自按自己的理解写的？