企业官网建设流程全解析

1. 起因：四位数与三位数的账单差距逼我做了一次“降级对比”

我这人平时不太喜欢做“谁便宜谁好用”这种横向评测，因为模型对比太吃变量：测试题怎么选、提示词怎么写、裁判标准松不松，任何一处偏差都能让结果变成一场自说自话。但这次不一样，项目预算摆在那里，不测不行。

我们团队正在维护一个数据同步引擎，里面塞满了有状态逻辑：双向状态收敛、增量同步暂停恢复、分片进度追踪、事务回滚、跨容器任务调度。这类业务天然就是状态机的温床，而状态机恰恰被认为是最考验“代码生成模型逻辑一致性”的场景之一。当前在 ofox 平台上，我们主力使用的旗舰级模型叫 gpt-6-astra，贵是真的贵；团队里有人提议换到同平台上的平价模型 gpt-6.1-sol，后者的挂牌价大概只有前者的五分之一。

如果单纯按价格换算，几乎所有人都会默认“五分之一价格的东西只能干五分之一的活”。但还真不一定。模型的能力分布从来不是一条均匀下降的曲线，它在某些任务上可能被打骨折，在另一些任务上却可能守得很稳。为了搞清楚这条“能力曲线”到底长什么样，我花了三个晚上，在 ofox 上搭了 40 道编程题，从纯算法到工程实现全过了一遍。真正让我意外的是，整体跑完以后分数差额确实存在，但跌得最深和最浅的地方，跟我预想的完全相反：高强度 TypeScript 类型体操它崩得稀里哗啦，而带状态机的 TypeScript 实现任务，它跟旗舰版的差距居然只有 3.8 分。

这篇记录我不打算浮于表面地报个数，而是把题型分布、评分逻辑、具体代码案例、失败场景还原全部摊开。准备做模型选型或者预算受限想“降级”的人，应该能从里面找到一些可复用的判断依据。

1.1 为什么偏偏选 40 道题而不是直接跑一个大型项目

很多人做模型评测喜欢直接丢一个大型仓库，说“你帮我全景式生成”。我试过，踩过坑，最大的问题有两个。

第一是没法归因。一个大型项目包含几十个文件、上百个函数，模型失败了你根本不知道是需求理解错了、类型推导断了、还是某段库函数调用写错了。第二是无法复现。大型任务每次生成的代码差异极大，改一个 prompt 单词结果就面目全非，评价维度直接失效。

所以我选择了 40 道中等粒度题目的方案。每道题都能独立编译、独立跑测试、独立判定通过与否，可以精确记录错误发生在哪个环节。40 道题也不算特别多，但足够覆盖几类我关心的业务形态。题目类别分配如下：

之所以把状态机题目占比提到 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 一组对照数据：旗舰级是“稳”，平价级是“磨”

状态机题目上，首次通过率差距并没有想象中悬殊，修复轮次也只在 1.5 对 2.2。换句话说，平价模型在状态机场景下主要靠“多试几次”来弥补差距，但每次尝试的命中率并不低。而在类型体操那组，gpt-6.1-sol 的首次通过率只有 12.5%，平均要改 5.2 轮才能通过，属于半崩溃状态，这直接决定了它在 TypeScript 类型高度耦合的任务里不能站在生产岗位。

3. 整体总分与成本明细：确实一分价钱一分货，但是“科目”分货

这一节直接上数据。40 道题全部跑完后，我把四个细分组的平均分做了汇总。

3.1 四项科目成绩单

整体看，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
• 月输出 token：200 × 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 任务，它远比五分之一值；如果你的工作负载集中在深度类型体操和隐性需求理解上，那就算它是五分之一价格，也建议三思。模型没有绝对的高低之分，只有跟任务类型匹配不匹配的区别。找个周末，把你的真实业务抽成题目，自己跑一轮数据，比看任何云评测都管用。