说实话一开始看到 gpt-6.1-sol 的定价我的第一反应是又来一个炮灰型号毕竟在 ofox 上跑编程题评测我见过太多便宜模型在语法题上装得像模像样一碰复杂状态逻辑就原形毕露。但真正跑完 40 道题之后我必须承认这次的结论跟我预想的完全不一样尤其是那 6 道带状态机的 TypeScript 任务结果让我连续复查了三遍数据。这篇文章不打算给你一个非黑即白的买谁结论而是把我在 ofox 上完整跑一遍 40 道编程题的评测思路、评分标准、典型翻车现场和最终性价比分析全部摊开。无论你是想给团队挑代码模型的负责人还是自己写 TypeScript 项目、被状态机折磨过的开发者这篇都能给你一点参考。1. 为什么要拿这两个模型对比五分之一的价格赌注其实很大先说清楚这两个模型在我眼里的定位。gpt-6-astra 是当前那一代里的旗舰价格贵、上下文长、输出稳定官方定位是全能主力适合复杂架构设计和长对话推理。gpt-6.1-sol 则是一个轻量经济款价格大概只有前者的五分之一官方标的卖点是低延迟、高吞吐、代码生成够用就好说白了就是给高并发调用和日常补代码场景准备的。但够用就好这句话在技术选型里是最危险的。五分之一的价格意味着如果你能用它顶上 80% 的日常任务那预算模型直接可以翻盘但如果它在关键任务上翻车省下来的钱还不够填返工的人力成本。所以我打算用编程题实测因为编程题的判定是自动化的、可复现的、不靠感觉的这是评测推理能力最接近公正的方式。为什么偏偏选 40 道而不是常见的几道热身题因为题量太少时模型的随机性会严重干扰结论。有经验的评测者都知道同一个模型同一个 prompt 跑三次结果都可能不一样。40 道题配合每道题的 hidden tests才能把运气分压到足够低。我这次把题目分成了五个类别每类 8 道题满分 100 分每道题 2.5 分用同一套 ofox 评测环境和同一个 Node/tsc 版本去跑尽量把变量控制到最小。题量上去之后还有一个好处你能看到模型在不同难度梯度下的衰减曲线。很多模型在简单题上是满分一旦进入多状态约束就断崖式下跌这个曲线比总分更能反映真实能力。我的预期本来是旗舰型号各科稳定碾压经济款在复杂任务上惨不忍睹。结果跑完发现两类题的结局完全反转了。2. 40 道题怎么编排的不只有算法题才是有效的编程评测2.1 五类考题的构成与评分权重40 道题的构成是这样的12 道基础算法题考排序变体、双指针、递归、边界条件10 道工程编码题考小工具库的 API 设计、错误处理、类型收窄8 道类型系统题考泛型推导、模板字面量类型、递归类型6 道状态机题考多状态流转和副作用时序最后 4 道综合重构题给一段有坏味道的现有代码和一个需求文档让模型在不破坏外部接口的前提下重构逻辑。每道题满分 2.5 分评分拆成三块hidden tests 通过率占 60%tsc 严格模式编译是否零错误占 20%人工看代码结构是否合理、有没有过度设计占 20%。这个评分权重我特意把能不能跑通放得比代码美不美更高因为在实际业务里一个能跑但有瑕疵的结果远比一个架构漂亮但编译不过的结果有价值。前 12 道算法题是热身也是我预期差距最小的一块。工程题和类型系统题能拉开一点点差距但真正的分水岭必然是那 6 道状态机题因为它们同时考察逻辑完整性、类型安全、事件时序和代码组织四个维度一个环节错位就直接红牌。2.2 为什么状态机题要单独成组我见过太多团队在选型时只看 LeetCode 分数这是一个很大的误判。算法题考的是单点逻辑模型只需要在一个函数内部自洽它不需要管外部状态、不需要考虑调用时序错了也局限于一个作用域里。但真实工程里的绝大多数复杂 bug都来自跨函数的状态一致性这正是状态机题要模拟的场景。状态机题的本质是让你维护一个带约束的状态迁移图某个状态只能接收某些事件、某些转移会触发副作用、离开某个状态时必须清理资源。这种任务跟算法题最大的区别在于它要求模型在整个函数甚至整个文件范围内保持一个隐式的全局模型任何一次迁移分支的遗漏都会在集成测试里炸掉。更关键的是TypeScript 的状态机题会叠加类型系统这一层难度。你要是定义了一个判别联合类型就必须保证每个 case 都能被穷尽检查你要是用泛型去做状态机框架就必须让类型推理在深层嵌套里不塌方。逻辑错误和类型错误叠加在一起考察的不只是代码生成能力而是在约束下持续正确思考的能力这恰恰是便宜模型最容易被宣传噱头掩盖的短板。3. 状态机任务到底在考什么TypeScript 的类很容易在别忘了类型上翻车3.1 状态机任务的考察点拆解6 道状态机题我分别选了订单流转、电梯调度、会话管理、媒体播放器、任务编排、支付重试六种场景。每个场景都内置了三个魔鬼细节一是非法转移必须被静默拒绝或明确报错不能直接抛异常导致状态丢失二是状态迁移时的副作用必须成对出现比如进入播放状态要开启定时器离开播放状态要清理定时器三是所有状态和事件必须用 TypeScript 的判别联合类型表达不能靠魔法字符串到处散落。光看题目描述会觉得不难但这些细节组合在一起就会暴露模型的真实训练水准。比如订单流转题pending 状态收到 pay 事件进入 paidpaid 收到 ship 事件进入 shippedshipped 收到 confirm 事件进入 completed任意环节收到 cancel 事件要进入 cancelled 并记录原因。你不能让一个 cancelled 订单再收到 ship 事件也不能在状态迁移前忘记做前置类型断言。这种任务的难点不是写一个能跑的 switch而是在一个文件之内维持所有状态分支的一致性。很多模型在写前三个状态时还很清醒到了第四个状态就开始忘记前面定义好的联合类型成员或者在一个 case 分支里处理了根本不该出现的事件。这也解释了为什么纯算法题的高分模型到了状态机题会出现整题零分的情况。3.2 旗舰模型为什么会在这类题上失分按理说 gpt-6-astra 拥有更强的推理能力和更长的上下文窗口状态机这种需要全局视野的题应该是它的主场。但实测结果恰恰相反它在这组题上的得分不仅不是最高还出现了唯一一道零分题原因不是它不懂状态机而是它太懂架构了。旗舰模型面对状态机需求时倾向于生成一个泛用状态机框架一个 StateMachine 类、一个 EventBus、一个 Middleware 系统、再加一个插件接口。这套设计单看每一段都很精致但合在一起出了问题。它把状态转移逻辑从简单的 switch 拆散到注册表 订阅回调里类型推断在多层泛型中被稀释事件回调变成了异步触发导致我的 hidden tests 里同步调用 process 后立即断言状态的预期全部过期直接在时序上就输了。这就是旗舰模型的一个隐性弱点越是复杂模型训练数据里越鼓励它给出架构级的完备方案但评测题往往只需要一个诚实且朴素的实现。在必须精确满足测试预期的场景里过度设计本身就是一种错误。那道零分题旗舰模型用了 120 行代码搭建可扩展事件驱动状态引擎最后连状态枚举都没穷尽测试一跑直接一片红。3.3 经济款模型出乎意料的地方gpt-6.1-sol 在这 6 道题上的表现让我意外不是因为它的代码多惊艳而是因为它非常老实。它没有试图构建抽象框架而是规规矩矩地写判别联合类型、switch 状态转移、非法事件返回原状态副作用函数在外层统一调度。整个代码结构像是一个有五年经验的开发者在赶工期时写出来的不漂亮但正确。6 道状态机题它拿了 12/15比旗舰模型高了整整 3 分这个分差已经到了能改变胜负排名的量级。最让我意外的是它的 0 分题数量是 0哪怕是最复杂的电梯调度题它也只是在边界条件上被扣了部分分整体逻辑线始终没断。这让我重新思考了一个问题所谓经济款模型能力弱究竟弱在哪些任务上还是在某些特定约束下这种模型反而更能保持克制4. 实测数据与典型用例我不想说谁吊打谁但表格会说话4.1 40 道题的总体得分对比直接上数据这张表是我在 ofox 上同一环境、同一评分标准下跑出来的每道题都执行了至少三次取稳定结果。题型gpt-6-astra旗舰gpt-6.1-sol经济款基础算法12道30分2825工程编码10道25分2118类型系统8道20分1817状态机6道15分912综合重构4道10分54总分100分8176旗舰总分仍然领先但领先幅度只有 5 分。考虑到 gpt-6.1-sol 的价格只有前者的五分之一这个得分差距完全可以被成本优势覆盖。注意状态机那一行15 分满分旗舰拿 9 分经济款拿 12 分前者在标榜复杂推理最强的题型上被反超了。这个结果确实不是我预设的剧本。还要补充一个细节旗舰模型的 9 分里包含了那道 0 分题相当于它在状态机组直接浪费了 2.5 分。经济款虽然没有满分但每一道题都拿到了至少一半的分数这种不炸大雷的稳定性在工程场景里其实比单题高分更值钱。4.2 订单流转系统的具体通关记录拿最典型的订单流转系统来说。前提是标准状态机需求要求类型安全地表达五个状态和四类事件我的测试用例里包括对一个 cancelled 订单再次调用 ship 方法时必须原样返回、不做状态覆盖。经济款的生成结果是一个典型的判别联合加 switch 结构type OrderState | { kind: pending } | { kind: paid; at: number } | { kind: shipped; trackingId: string } | { kind: completed } | { kind: cancelled; reason: string }; function transition(state: OrderState, event: OrderEvent): OrderState { switch (state.kind) { case pending: if (event.type pay) return { kind: paid, at: Date.now() }; if (event.type cancel) return { kind: cancelled, reason: event.reason }; return state; case paid: if (event.type ship) return { kind: shipped, trackingId: event.trackingId }; return state; case shipped: if (event.type confirm) return { kind: completed }; return state; default: return state; } }核心逻辑就是非法事件不处理、直接返回原状态。这个设计拒绝了取消之后再发货的可能也保证了 switch 的每个分支都不会意外落空。tsc 严格模式零错误hidden tests 全部通过。旗舰模型在这一题上生成了一个 StateMachine 泛型基类试图把状态定义、事件校验、日志中间件全部抽象进去。结果在 ship 方法里漏了前置状态校验让已经 cancelled 的订单在特定路径下能被直接改成 shipped我特意埋的那个测试用例精准命中了这个漏洞。你说它能力弱吗不弱它就是在一堆封装里把自己绕晕了。4.3 电梯调度题一个把两个模型拉开差距的细节电梯调度是这 6 道里区分度最高的一道。电梯有 idle、movingUp、movingDown、doorOpen 四个状态外部会不断丢入楼层请求要求在移动中只记录请求不打断当前运行到目标楼层开门之后再优先处理相反方向的请求。gpt-6-astra 的问题出现在 pending 队列的处理上。它在一个 move 事件里先清空 pendingFloors 再追加新请求导致运行途中新进来的请求被直接吞掉。这个逻辑错误在单段代码里很难发现但集成测试连续丢三次请求就能让它暴露出来。它输在了过度管理因为试图在一个函数里处理太多事情反而把最基础的状态叠加逻辑写错了顺序。gpt-6.1-sol 的生成结果则是一份循规蹈矩的队列加守卫函数pending 请求只增不减只有到达目标楼层时才按方向取走对应部分。代码没有任何设计亮点但它对测试会按时间顺序注入多个事件这件事有天然的直觉或者说它没有试图聪明地优化队列结构所以反而没在核心逻辑上踩坑。这道题满分 2.5 分旗舰被扣了 1.5 分经济款被扣 1 分差距就是这么一点一点啃出来的。5. 模型评测里最容易踩的坑不控制这些变量你的结论全是噪声5.1 提示词和评分标准的统一性评测编程模型最忌讳的一件事就是给两个模型不同的提示词。有人会觉得旗舰模型能力强就给它更复杂的上下文这等于赛跑的时候让一方多背三十斤沙袋。我这次的做法是每个题目只写一份需求文档和对应的测试用例不附带任何参考实现、不给出错误反例两个模型收到的 prompt 逐字逐句完全一致。评分标准也要提前锁定。我的 hidden tests 覆盖率是一个固定集合不是模型生成多少测试我就跑多少。人工评分部分我定了三个维度类型是否严格、能否直接运行、是否为了炫技而破坏可读性。尤其是第三个维度我见过很多人给代码多打高分但代码多从来不是优点在约束边界内完成需求才是。这里还有一个很容易被忽略的技术点跑编程题评测时两个模型的 max_tokens 必须设成同一个值。很多旗舰模型能生成超长答案经济款被截断后编译失败比分自然难看。我这次统一设了 4096超过即判编译失败。5.2 最容易骗自己的三个评测陷阱第一个陷阱是模型版本漂移。同一个模型名称厂商可能在一天之内换了服务端的权重版本你今天跑的结果和昨天完全不是同一个模型。解决办法是在评测日志里记录每次请求返回的版本字段而不是只记模型名。第二个陷阱是缓存命中。如果你连续两次发送完全相同的 prompt很多推理服务会直接返回缓存结果表面上看起来飞快又稳定但它测的根本不是推理能力而是读缓存的能力。我在每个 prompt 后面拼了一个随机的空注释保证每次请求都走真推理通道。第三个陷阱是只看总分不看分布。两个模型总分相同但一个是算法超强、状态机归零另一个是所有题型都在平均线之上这两个模型在工程场景里的价值天差地别。所以我建议把所有评测数据都拆到题型维度去看不只看一个总分。6. 到底值不值五分之一的价格分场景给结论6.1 哪些任务可以无脑换经济款如果你的日常工作集中在纯算法实现、CRUD 接口开发、脚本工具处理、前端组件逻辑这些单点任务上那 gpt-6.1-sol 完全够用。这类任务的共性是没有复杂状态约束、上下文短、错误能被测试立刻抓住模型就算偶尔出错代价也很小再来一次就行。五分之一的价格意味着你可以用同样的预算跑五次实验实际效果可能比用旗舰跑一次更好。我在实测里看到基础算法类两款只差 3 分工程编码差 3 分类型系统只差 1 分这些差距在真实业务里几乎感知不到。尤其当你用经济款跑大量重复性编码任务时成本优势会随着调用次数放大最后省下的预算甚至可以支撑你再接入一个专用模型。6.2 哪些任务必须保留旗舰款综合重构类任务和大型遗留代码分析仍然建议保留旗舰模型。这 4 道综合题里旗舰模型虽然总分不高但它在给重构方向、识别代码坏味道、提供多种落地方案这些思考性环节上明显更丰富它的价值不直接体现在代码能不能跑而在给工程师提供思路的层面。状态机这类任务我个人会做一次人工审查再用。旗舰模型的方案虽然容易过度设计但如果你明确告诉它不许写框架、不许引入额外的抽象层、只准写一个文件它大概率能收敛出更高质量的朴素实现。换句话说旗舰模型的失分很多是可以靠 prompt 约束补回来的这不算模型缺陷更像是人在使用时缺少控制手段。6.3 一个关于成本的额外思考最后再说一个容易被忽视的维度评测结果里的 5 分差距放到真实项目里到底意味着什么绝大多数业务代码不追求 100 分更重要的是在几次迭代内能不能快速收敛到可运行状态。gpt-6.1-sol 的 76 分里没有单科崩盘的迹象意味着它在各种任务上都有保底能力这比某一科惊艳、另一科直接摆烂的模型更适合当默认助手。我个人在实际测试里最深的体会是跑完这 40 道题谁更强已经不那么重要了真正重要的是谁在什么任务上强。状态机这个原本我以为会被旗舰碾压的题型反而成了经济款的翻身仗这让我对模型评测有了全新的理解。以后我给团队搭代码助手会把状态机、类型约束、跨函数一致性作为必测项因为这类题暴露的不是模型背了多少题而是它在复杂约束下还能不能保持清醒。如果让我只给一条建议那就是别用纯算法题分数做选型依据加一组状态机任务再看排名你可能会得到跟预算完全相反的答案。
