大家好，我是孟健。
针对两个真实业务模块的冻结源码做修复，8次调用按闲时价和usage核算总计约0.71元，最终拿到了4份通过既定检查的补丁。这个花费确实很低，但低价不代表拿来即用。最初4次调用里有3次被我人为设定的18000 token预算强行截断，导致没有留出最终代码的空间，这也直观标出了配置的底线。
01 审视官方基准与社区早期测试
9月10日，DeepSeek正式发布552B总参数的MoE新架构，采用Causal-Encoder-Decoder设计，输入激活8B、输出激活16B，并原生支持视觉处理。官方给出的软件工程能力基准评测DeepSWE v1.1中，V4.1 Flash拿到74.2分。
图1：DeepSeek官方发布的基准测试对比（厂商自测数据）
官方DeepSWE v1.1榜单图上，74.2分高过自家的Pro（63.1分），但落后于图里的GPT-5.6 Sol（76.9分）。厂商自测终究不是第三方定论，相较于分数，我更看重它在当前调用成本下能不能换来稳定可用的代码产出。
图2：官方公布的人民币峰谷计费标准（注意单位为每百万tokens）
按官方价格，北京时间工作日9点至12点、14点至18点为高峰期，其余时间为闲时。闲时每百万tokens缓存命中输入为0.02元，未命中输入为1元，输出为4元；高峰期价格翻倍。注意0.02元仅为缓存命中的输入单价，非全部输入统一定价。
此前社区的内测跑过不少热闹方向：机器之心9月8日实测7分多钟、花费不到2元搓出HTML小游戏；WorldofAI在9月9日展示了园林建模等视觉能力，但也指出长任务推演容易拖延交付。这些基于早期内测的尝鲜大多围绕从零搭新项目，而我更关心已有老模块在带着历史包袱修复缺陷时，它是否真能扛得住。
图3：机器之心内测小游戏开发用时与费用记录（引自机器之心评测）
02 抽取故障模块遭遇预算截断
这次实测选取了两个业务系统的冻结代码片段，给出明确上下文与约束，要求直接输出补丁。
第一个模块来自ShipSite负责截图恢复的322行代码，痛点在于异步无头浏览器的资源回收。超时只是调用端决定不等了，不等于后台晚到的浏览器实例会自动蒸发；3页并发配额、迟到实例强制回收，以及close过程挂起不能拖死主进程，这些都是绕不开的硬约束。原始代码在15项检查里仅通过8项，参考实现全过。
第二个模块来自ShipSolo统计Worker，面对6006行大文件，我切出了约685行精准上下文。它的难点不在于堆接口，而在于规矩极多：不同凭据绝不能串缓存，12个相同请求在Mock里必须被聚合成1次fetch，调用方擅自篡改返回对象绝不能污染下一位读取者。原始代码36项仅过16项，参考实现全过。这轮未做真实线上压测。
我为两任务分别配置Thinking模式的low和high两档，发起初始4次请求。然而首轮返回后，仅low档ShipSolo返回了代码，其余3次虽然HTTP状态码为200，但代码块均为空。
检查API返回发现，这3次响应的finish_reason均为length。由于最初设置的max_tokens为18000，模型思考过程消耗完18000个tokens后触发正常API长度截断，未能留出正文输出配额。根据官方说明，思考过程直接计入输出配额，必须留出表达空间。
03 放宽上限并在隔离沙箱复验
找到原因后，我保留原始源码和提示词，将截断任务的输出上限调整至64000重跑，请求顺利完成。连同首轮成功的一次，共获得4份完整补丁。
需要说清楚，整个验证都在本地冻结副本、Mock和无网络Docker里闭环，没有跑整包build与E2E，更未部署到生产环境。同一份补丁复验两遍，确认的是本地运行的一致性，绝不等于重新向模型采样了两次统计概率。
图4：本地验证脚本汇总与多维度检查记录（截自本地浏览器报告）
检查表现如下：
- ShipSite在low和high两档生成的补丁，均通过了全部15/15项检查。
- ShipSolo在两档生成的补丁，均通过了全部36/36项检查。
- 同一输出复验两遍，断言结果保持一致。
- 4份补丁均通过TypeScript类型检查，编译器退出码为0。
不过在审查Diff时发现了一处范围越界：在ShipSolo的两份补丁中，模型除了修改指定的缓存与日期校验外，还改动了同文件下游另一个实时统计函数里的错误脱敏逻辑。尽管脱敏改动本身方向合理，但超出了最初划定的修改边界。这一现象提醒我们，即使自动化用例检查全过，人工代码审查仍不可替代。
整个链路里，首轮成功的low档ShipSolo耗时约47.6秒，核算下来只要0.0652元。需要厘清，这单纯是API吐出补丁的时间，并不包含后验验证与人工审查的总体交付成本。
04 验证官网长表的结构化提取
视觉部分我用了一张字迹极清楚的官网双模型价格长表。测试的核心目的很简单：把图片精准转成结构化JSON方便直接核账，验证它在具体运营和对账场景下的实用价值，而不是指望它在模糊照或手写体上也能处处泛化。
图5：作为视觉输入测试的官网双模型定价长表（测试输入原图）
测试未提供OCR文字或外部工具，仅提供图片并要求输出JSON。模型需要提取两款模型的名称、多模态支持、上下文长度、输出上限、并发限制以及高峰与闲时的12个价格数值；同时结合一组假想工作量（设定Flash处理输入包含1200万命中、120万未命中及60万输出tokens），计算闲时与高峰总费用。这组假想用量与本次评测本身的实际调用支出需严格区分。
图6：模型根据长表截屏生成的结构化JSON结果（截自浏览器中的模型JSON文件）
比对程序针对事先冻结的28个字段进行核对，结果为28/28全部正确。针对假想工作量计算出的闲时3.84元和高峰7.68元，也与脚本预设一致。
该视觉调用耗时4.576秒，按当时闲时价格核算约为0.005元（约半分钱）。结合前面7次代码生成与截断调用，8次任务调用按实际usage与官方闲时价核算总计约0.71元。该核算包含失败截断的消耗，但不包含前期网络探针、写作、本地机器及人工审查成本，非财务对账单。
05 建立参数配置与落地边界
基于这轮实测，我依然以Codex和Claude为主力，它并非全能，但我愿意把更多边界清楚的活交给它。需要特别澄清的是计费规则：账单涵盖实际输入tokens与包含思考过程在内的输出tokens，并非只按实际生成的最终代码收费。提高max_tokens上限本身不收费，但可能诱发更多实际生成，因此必须设定总预算并紧盯finish_reason。如果想尝试，不妨挑一个验收条件清晰的模块，建个隔离副本跑一次；拿到结果后务必逐行核对diff，测试没跑通前绝不上线部署。
参考来源：
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏