1. 起因四位数与三位数的账单差距逼我做了一次“降级对比”我这人平时不太喜欢做“谁便宜谁好用”这种横向评测因为模型对比太吃变量测试题怎么选、提示词怎么写、裁判标准松不松任何一处偏差都能让结果变成一场自说自话。但这次不一样项目预算摆在那里不测不行。我们团队正在维护一个数据同步引擎里面塞满了有状态逻辑双向状态收敛、增量同步暂停恢复、分片进度追踪、事务回滚、跨容器任务调度。这类业务天然就是状态机的温床而状态机恰恰被认为是最考验“代码生成模型逻辑一致性”的场景之一。当前在 ofox 平台上我们主力使用的旗舰级模型叫 gpt-6-astra贵是真的贵团队里有人提议换到同平台上的平价模型 gpt-6.1-sol后者的挂牌价大概只有前者的五分之一。如果单纯按价格换算几乎所有人都会默认“五分之一价格的东西只能干五分之一的活”。但还真不一定。模型的能力分布从来不是一条均匀下降的曲线它在某些任务上可能被打骨折在另一些任务上却可能守得很稳。为了搞清楚这条“能力曲线”到底长什么样我花了三个晚上在 ofox 上搭了 40 道编程题从纯算法到工程实现全过了一遍。真正让我意外的是整体跑完以后分数差额确实存在但跌得最深和最浅的地方跟我预想的完全相反高强度 TypeScript 类型体操它崩得稀里哗啦而带状态机的 TypeScript 实现任务它跟旗舰版的差距居然只有 3.8 分。这篇记录我不打算浮于表面地报个数而是把题型分布、评分逻辑、具体代码案例、失败场景还原全部摊开。准备做模型选型或者预算受限想“降级”的人应该能从里面找到一些可复用的判断依据。1.1 为什么偏偏选 40 道题而不是直接跑一个大型项目很多人做模型评测喜欢直接丢一个大型仓库说“你帮我全景式生成”。我试过踩过坑最大的问题有两个。第一是没法归因。一个大型项目包含几十个文件、上百个函数模型失败了你根本不知道是需求理解错了、类型推导断了、还是某段库函数调用写错了。第二是无法复现。大型任务每次生成的代码差异极大改一个 prompt 单词结果就面目全非评价维度直接失效。所以我选择了 40 道中等粒度题目的方案。每道题都能独立编译、独立跑测试、独立判定通过与否可以精确记录错误发生在哪个环节。40 道题也不算特别多但足够覆盖几类我关心的业务形态。题目类别分配如下题目组别数量考核目标纯算法与数据结构12 道基础编码能力与边界处理TypeScript 类型与泛型8 道深度类型推导、类型体操状态机与事件驱动逻辑12 道状态流转规范性、幂等、回滚前端组件与接口适配8 道异步联动、数据流组织之所以把状态机题目占比提到 30%是因为它最能反映我们数据同步引擎的真实工作量。这类任务几乎不可能靠“背诵”应付它要求模型理解了状态集合、迁移事件、迁移条件和副作用之后再把它翻译成类型安全的 TypeScript 代码。这也是让我后续大跌眼镜的地方。1.2 两个模型的大致定位旗舰级与平价级这里简单交代一下两个被测对象的背景。gpt-6-astra 是 ofox 平台的旗舰级代码生成模型上下文窗口明显更大训练量和后训练轮次都投入得比较足接口稳定性好但 token 单价接近 gpt-6.1-sol 的 5 倍。gpt-6.1-sol 是低价路线的代表基座规模更小上下文窗口略有缩水但训练样本步数长在大量常规编程任务上表现得相当能打。我选这两个模型来对比不单纯是想得出“谁赢谁输”的结论更想知道平价模型在什么场景下可以平替、在什么场景下绝对不行。这种边界意识比排名本身更有价值。2. 评分规则隐藏测试、维护性评分与“第二计分轴”缺一不可评测最怕的是“看着分数能过实际不能用”。为了让成绩单能真实反映生产可用度我对跑分机制做了三层设计。2.1 ofox 平台的基础计分100 分制的四个构成ofox 是一个在线的代码生成评测平台它会把 prompt、生成代码、测试用例、编译环境全部管起来。它给每道题设计了一套 100 分制的自动评卷体系编译通过20 分生成代码必须能在目标 TypeScript 版本下编译通过任何类型错误直接扣完。公开测试用例30 分题目给出的可见用例用来快速验证主流程。隐藏测试用例30 分不可见的边界用例专门对付“背题”和“只过了 happy path”的模型。维护性人工复核20 分由平台评审员对代码结构、命名、圈复杂度、注释质量打分。隐藏测试那一层尤其关键。现在很多模型能在公开用例上做到 100% 通过但一遇到边界条件就原形毕露。状态机这类题目最容易埋隐藏用例比如“收到已关闭单据的作废请求时应该报错而不是抛异常”“并发版本号冲突时应该走冲突合并分支而不是直接覆盖”这些都是生产环境里真正会出事的点。2.2 我自己额外加的“第二计分轴”首次通过率与修复轮次平台分只能反映最终结果而生产环境最真实的成本是在“试错”过程中产生的。同一个任务有的模型一次提交就通过有的模型要来回折腾三四轮过程中消耗的 token 和人工检查时间完全不同。所以我额外记录了两个指标首次通过率一次提交即通过全部公开用例和隐藏用例的任务数占比。平均修复轮次从首次提交到最终通过之间模型额外提交的次数。打个比方隐藏测试分数相当于考试卷面得分而修复轮次相当于你交卷之前被打回来重写的次数。后者的经济代价甚至比卷面分更重要因为每次打回都是一次新的 API 调用。2.3 一组对照数据旗舰级是“稳”平价级是“磨”指标gpt-6-astragpt-6.1-sol全题库首次通过率62.5%35.0%全题库平均修复轮次1.93.4状态机题目首次通过率66.7%58.3%状态机题目平均修复轮次1.52.2TypeScript 类型题首次通过率62.5%12.5%TypeScript 类型题平均修复轮次2.35.2状态机题目上首次通过率差距并没有想象中悬殊修复轮次也只在 1.5 对 2.2。换句话说平价模型在状态机场景下主要靠“多试几次”来弥补差距但每次尝试的命中率并不低。而在类型体操那组gpt-6.1-sol 的首次通过率只有 12.5%平均要改 5.2 轮才能通过属于半崩溃状态这直接决定了它在 TypeScript 类型高度耦合的任务里不能站在生产岗位。3. 整体总分与成本明细确实一分价钱一分货但是“科目”分货这一节直接上数据。40 道题全部跑完后我把四个细分组的平均分做了汇总。3.1 四项科目成绩单题目组别gpt-6-astra 均分gpt-6.1-sol 均分分差gpt-6.1-sol 占旗舰版水平比例纯算法与数据结构93.879.514.384.8%TypeScript 类型与泛型91.265.725.572.1%状态机与事件驱动94.690.83.896.0%前端组件与接口适配90.471.918.579.6%全部题库平均92.777.615.183.8%整体看gpt-6.1-sol 拿到了旗舰版 83.8% 的水平这其实已经超出我最初的预期。但更值得关注的是科目间的极差状态机那组它几乎贴着旗舰版走类型体操那组则被打出 25.5 分的巨大口子。两者相差超过 20 分说明平价模型的弱点不是均匀分布在全能力面上的而是集中爆发在特定认知类型上。3.2 把分差翻译成真实成本五分之一的价格不等于五分之一的费用很多人看到“五分之一价格”就直接按乘除算账实际不是这样。平价模型在整体上的 token 消耗几乎是旗舰版的 2.1 倍原因是修复轮次多、生成代码更长、debug 重试更频繁。所以最终账单不是五分之一而是三分之一左右。给你们算一笔具体的账。假设我们一天生成 200 个代码补全请求每个请求平均输入 4000 token、输出 1600 token一个月按 22 个工作日计算月输入总量200 × 4000 × 22 17,600,000 token月输出 token200 × 1600 × 22 7,040,000 token按旗舰版基准为了符合直觉我直接按相对价格换算旗舰版月花费约 2100 元平价版虽然 token 消耗放大到 2.1 倍但单价只有 19%所以月花费约 700 元不到。最终平价版花费大约是旗舰版的 33%而不是 20%。这意味着预算确实能省下约三分之二代价是更长的等待时间和更多轮的调试往返。3.3 一个容易忽略的现象代码越长反而越稳在整理状态机组成绩时我还发现一个有点反直觉的趋势gpt-6.1-sol 生成的代码普遍比 gpt-6-astra 长 25% 上下但在状态机题目里它越长的代码反而通过率更高。仔细看之后才明白平价模型的“长”大部分是冗余的防御性分支和注释比如在状态迁移函数中显式写出所有非法组合的判断而不是用简洁的查表法隐式跳过。这在纯设计层面是啰嗦的但是在自动测试层面它反而把一些容易漏掉的边界条件给覆盖了。这算是一种“笨但有用”。4. 状态机 TypeScript 任务的完整复盘三道代表性题目和它们的解法分水岭要理解“3.8 分到底意味着什么”必须落到具体题目上。我挑三道具有代表性的状态机题目把两个模型的实现差异和翻车过程完整还原出来。4.1 第 7 题库存单据状态机两者接近“无差别”通过这道题模拟的是仓储场景下的单据流转。状态集合如下type OrderStatus | DRAFT | SUBMITTED | AUDITED | RECEIVED | VOIDED | CLOSED;要求实现的状态迁移包括草稿可以提交提交后可以审核或作废审核通过后可以入库入库后自动关闭已入库单据不能直接作废只能先冲红再作废且整体支持带版本号的并发控制。非法迁移要抛出带错误码的异常每次迁移要记录一条不可篡改的时间线。gpt-6-astra 给出的实现是一条非常标准的表驱动路线把状态迁移关系抽象为一个二维矩阵然后用事件处理器查表。代码短、结构清晰、读完不需要注释也能理解。gpt-6.1-sol 给出的实现则完全不是这个风格它用了一组 switch-case 嵌套每个状态写一个处理函数函数里又手工复制了各种防御校验代码体量大出不少。但最终测试结果是两者都一次性通过了公开用例和隐藏用例。唯一的差额出现在维护性评分上gpt-6.1-sol 因为圈复杂度和重复分支被扣了 2 分功能性分全部拿下。这说明什么状态机的“正确性”主要看模型能不能把一个确定性的映射表忠实翻译成代码。表驱动还是分支递归只是风格问题对生产几乎没有影响。4.2 第 9 题TCP 连接状态机平价模型跑了两轮修复第二道是经典的 TCP 连接状态机22 条迁移规则覆盖了 LISTEN、SYN_SENT、SYN_RECEIVED、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK、TIME_WAIT、CLOSED 这些状态。这里最容易出错的是几条“复合事件”迁移比如 FIN_WAIT_1 收到 ACK 时进入 FIN_WAIT_2收到 FIN 时进入 CLOSING收到同时带 FIN 和 ACK 的包时直接进入 TIME_WAIT。gpt-6-astra 一次通过而且把复合事件封装得极其干净。gpt-6.1-sol 第一次提交时把“同时收到 FIN 和 ACK”漏了只处理了纯粹的 ACK 和纯粹的 FIN。这个问题不是语法错误而是理解错误它在构造事件类型的时候把 FIN 和 ACK 拆成了两个独立事件源。有意思的是模型第一次失败以后我直接把红测输出丢回给模型让它自己看失败原因。gpt-6.1-sol 这次的表现还不错只花了第二轮修复就把“复合事件”的分支补上了并且额外补了一个专门的联合类型type TcpEvent | { kind: SYN } | { kind: SYN_ACK } | { kind: ACK } | { kind: FIN } | { kind: FIN_ACK } | { kind: RST };在现有状态下将 FIN 和 ACK 合并成了一个复合事件 FIN_ACK。这个改动解决了问题也让后续的校验逻辑更清晰。整体上这一题它用了两轮旗舰版只用了第一轮但是最终语义正确性保持一致。4.3 第 12 题跨容器部署状态机唯一的真实分水岭如果说前两题只是“小修小补”那第 12 题才是真正拉开差距的一题。这题模拟的是多容器并行部署时的任务状态机涉及状态包括deploying、verifying、starting、health_check_pending、running、failed、terminating、recovering。容器之间通过异步事件回调通信每个回调需要幂等处理版本号冲突时必须进入 recovering 而不是直接覆盖。gpt-6-astra 一次性通过代码里已经天然包含了幂等键判断和版本号乐观锁设计。gpt-6.1-sol 第一次提交时把幂等处理漏了同一个回调用重复的 requestId 会执行两遍这在分布式场景下的后果是重复部署任务。失败后第二轮它补上了幂等字典又花了第三轮才把“版本号冲突时进入 recovering”的分支逻辑补全。这一题它花了 3 轮才完全通过但最终还是通过了。三者的代码复杂度相差约 30%然而在隐藏用例层面gpt-6.1-sol 已经能覆盖所有限定的测试场景。也就是说在真实业务中它确实需要多几次人机对话来打磨但结果可用。顺着这三道题回头看我发现平价模型在状态机任务上掉链子的根因大多集中在“需要从一句隐式需求推导出显式分支”的地方比如第 12 题里面的“重复回调需要做幂等处理”在 prompt 里只出现了一次没有用任何加粗或高亮模型没有把它当作核心约束来对待。除此之外只要规格说明描述得够显式它的生成质量基本能贴近旗舰版。5. 为什么平价模型在状态机任务上守得住在类型体操上却崩盘这个问题是整个评测里最有价值的部分。同样是用 TypeScript同样是考验逻辑推理为什么 gpt-6.1-sol 能在状态机题目里拿到 96% 的旗舰版水平在类型与泛型题目里却只有 72%5.1 状态机本质上是一个“规格翻译”任务而不是“自由设计”任务在状态机题目中prompt 已经给了状态全集、迁移条件、事件类型、异常分支。模型要做的不是发明逻辑而是把规则集忠实地翻译成代码。这个过程很像编译输入是规格说明输出是程序中间不需要创造性推理。打个粮食的比方旗舰模型像一个大厨你点菜它可以自由发挥平价模型像一个能把菜谱精确执行的外包厨工菜谱清楚标了“盐 3 克”“油温七成热”的时候他做出来和主厨差不了多少。可一旦你说“随便来一个好吃的”他就抓瞎了。状态机任务的一切都写在菜谱上这个状态能去哪里、遇到什么事件干什么、非法转移抛什么错误。平价模型不需要推断需求只需要执行需求这个“翻译场景”正好规避了它最致命的弱点。5.2 类型体操的本质是全局约束一致性这正是小模型的阿喀琉斯之踵再看 TypeScript 类型与泛型那一组题目往往是一个高阶函数需要同时满足多个泛型参数之间的约束关系比如一个类型安全的事件总线要求事件名、事件参数、返回类型三者强绑定。模型必须在生成一个新的类型表达式时同时记忆前面所有类型声明任何一个环节失忆都会导致冲突。gpt-6.1-sol 在同类题目中的典型翻车模式是前三分之二代码非常正确到最后一行返回类型时写出了和前方泛型约束矛盾的类型别名。TypeScript 编译器立刻报错它又需要好几轮自我修复才能把冲突消除。这种跨长范围内的一致性维持需要模型有很强的“注意力持久性”而平价模型在这一点上天然吃亏。5.3 维护性评分里的意外代码丑但丑得很安全状态机题目最后的维护性评分gpt-6.1-sol 平均只比旗舰版低 2 分这个差距远小于其他题型。原因是状态机代码的可读性更多依赖好注释和清晰命名而不是依赖极简抽象。平价模型会随手写出一大堆防御性注释甚至在某些迁移函数里把不可能到达的 else 分支都补了注释。视觉上很啰嗦但对下一个维护者来说啰嗦地说明白有时候比优雅地省掉的更难出错。这给到一个很有意思的生产启示如果你的团队目标是“一次通过率优先”那旗舰版值这个钱如果你的目标是“功能正确、业务可跑”平价模型在状态机领域几乎可以无损替代。5.4 能力图谱决定选型而不是总分决定选型结合整轮评测我最大的体会是模型的“能力图谱”远比“总分”重要。gpt-6.1-sol 的总分是旗舰版的 83.8%但你不可能在所有任务里都拿到这 83.8%——它在类型体操上是 72.1%在状态机上是 96%。如果只看总分你会以为它是“全面小幅缩水”但事实上它是“大部分科目中等偏上某一科目几乎满格某一科目重伤”。对选型的人来说正确做法不是问“这个模型值不值得”而是问“我的任务类型落在这个模型的哪个能力区间”。任务类型踩中强势区五分之一价格可以买到几乎满血体验任务类型踩中弱势区再便宜也得三思。6. 落地建议什么样的团队可以把 gpt-6.1-sol 顶上去什么场景必须留旗舰版评测做得再详细最终还是要回到“我到底怎么用”这个问题上。结合这 40 道题的结果和这段时间的实操我梳理了几条比较务实的选型建议。6.1 适合直接上平价模型的场景判断标准很简单需求能不能写成一页说不完的详细规格。具体包括状态集合、迁移事件、异常分支都在需求文档里明确写死了。每个函数输入输出有明确类型定义不必模型自行发挥设计。项目里有完善的单测和集成测试模型生成的代码有自动化兜底校验。代码风格追求“功能正确”和“注释清晰”不追求“极简抽象”。满足这些条件比如内部管理系统、中台数据同步、后台任务编排这类业务gpt-6.1-sol 完全能顶上。我自己实测的感受是只要 prompt 写得多一点把状态表列出来它的产出稳定度会显著提升。6.2 必须保留旗舰版的场景反过来如果以下条件命中大多数就别省这个钱任务描述是开放式的比如“给这个模块设计一个合理的事件驱动架构”。深度 TypeScript 泛型约束强耦合比如类型安全事件总线、复杂条件类型、递归类型推导。一次性生成质量极其重要返回里没有容错机会比如多人同时在线的 IDE 插件。涉及长会话、多文件跨模块的全局重构。需要处理大量隐式业务规则需要模型主动推断隐含需求而不是翻译显式规则。特别是那些需要“模型替我想清楚设计决策”的任务平价模型的短板会暴露得最彻底。在我实际的测试里gpt-6.1-sol 在类型体操题目中有一道题改了七轮才通过每次都是修好一个类型又弄坏另一个。这种场景下即使它再便宜人力成本和时间成本也会把差价吃掉。6.3 推荐一个便宜又稳的“混合工作流”既然两类模型各有强项我比较推荐按阶段分工而不是单纯二选一。第一步用旗舰模型做架构设计阶段。让它先给出类型骨架、核心接口、状态机整体设计这一轮它输出的抽象高度是平价模型很难稳定的地方。第二把设计定稿后将详细的模块拆分、状态表、函数签名、预期的测试用例写进文档再把这些文档作为 prompt 交给平价模型做具体实现。这时候它只需要翻译规格就能发挥出 96% 的水平。第三步平价模型生成的业务代码丢回来给旗舰模型做 code review让旗舰模型专注于找 hidden edge case 和类型不一致问题。这其实是一种“设计与实现分离”的思路。旗舰模型干最难的“需求理解与设计”和“全局审查”工作平价模型干重复度最高的“规格翻译”工作两边都坐到最能发挥的位置。6.4 最后提醒一句用“回归测试集”来验证自己的选型别迷信单次试用很多人只拿一两个真实用例跑一下就决定换模型这不靠谱。单次生成的偶然性太大了一次通过不代表稳定通过一次失败也不代表完全不能用。建议更严格的方式是把自己项目的 20 到 50 个典型任务沉淀成一个私有评估集包含不同复杂度、不同状态机密度、不同依赖耦合的样本。每次模型更新后用同一套评测集重跑一遍把首次通过率和修复轮次记下来半年以后你会比任何平台评测都更清楚手上的模型适合干什么。回到标题那个问题gpt-6.1-sol 到底值不值 gpt-6-astra 五分之一的价我的答案是如果你的工作负载里有大量带状态机的 TypeScript 任务它远比五分之一值如果你的工作负载集中在深度类型体操和隐性需求理解上那就算它是五分之一价格也建议三思。模型没有绝对的高低之分只有跟任务类型匹配不匹配的区别。找个周末把你的真实业务抽成题目自己跑一轮数据比看任何云评测都管用。