企业官网建设流程全解析

榜单刷出来的热闹，和真正能进生产的能力，中间隔着一条很宽的沟。这次被顶上热榜的那位，社区给它起了个代号叫“太空兔”，发布方没署名，模型卡也写得含糊，只丢了几张对比图和一句“多项榜单第一”。我第一反应不是兴奋，而是条件反射地想：又一个匿名模型冲榜了，这回得认真测一遍。匿名模型这四个字，在最近一年里反复出现，每次都能带起一波讨论，因为它同时踩中了三根神经——好奇心、免费尝鲜的诱惑、以及对“榜单是不是还能信”的怀疑。“太空兔”这个名字我沿用了社区的叫法，纯代号，不代表任何真实主体。这篇文章要讲的是：面对一个突然爆火、身份不明的匿名模型，一个从业者应该怎么设计实测、怎么看数据、怎么判断它能不能进你的项目。适合正在做模型选型的技术负责人、需要给团队一个结论的工程师，也适合只是想搞明白“榜单第一到底意味着什么”的普通开发者。

1. 先搞清楚：一个匿名模型凭什么能排到第一

1.1 匿名发布为什么总能自带传播势能

匿名这件事本身就是一种营销杠杆，只不过这次是被动的。没有品牌背书，用户预期会被压到很低，一旦表现超出预期，反差感就会被放大成“炸裂”。我看了一圈社区里的讨论，绝大多数惊叹都来自同一个句式：“没想到这么个小东西能干这个”。这个“没想到”就是匿名带来的红利，如果换成一家知名团队发布同样的权重，评论区的口径多半是“符合预期”。

另一个推手是榜单机制本身。公开榜单的题目分布是固定的，权重是人工设定的，提交次数通常有限制。这就意味着一个团队只要肯针对榜单分布做优化，把有限提交次数用在刀刃上，冲到一个靠前的位置完全可行。这不是作弊，是理性的工程选择，但它带来的结果是：榜单第一衡量的是“在该榜单题目分布下的表现”，不是“通用能力第一”。这两者的差距，在长尾任务上会暴露得非常彻底。

还有一层是社区二次传播的放大效应。第一批尝鲜的人发几张截图，第二批人跟着复现，第三批人开始做对比，一条完整的传播链就成型了。中间任何一环出现偏差——比如截图只展示了成功的案例——最终形成的印象都会偏离真实水平。所以我从不看二手截图，一律自己跑。

1.2 我的评测框架：三层九格，先定框架再跑数据

临时起意跑几个提示词，得到的结论没有参考价值，因为你自己都不知道该看什么。我习惯先搭一个三层框架，把“强不强”拆成可以分别验证的九个格子，跑完再回头拼整体印象。

这三层缺一不可。我见过太多选型踩坑的案例，问题几乎都不出在能力层，而是工程层和成本层：能力确实强，但首字延迟三秒多，聊天场景直接不可用；或者效果很好，可单位成本是原来的四倍，业务侧算不过账。匿名模型尤其要看这两层，因为它的发布信息里通常只讲能力，工程和成本数据一概不提供，只能自己测。

1.3 评测前必须锁死的三个基线

在动手之前，我会先把三个基线钉死，后面所有分数都是相对这三个基线说的，绝对值意义不大。

• 上界基线：选一个业界公认的强模型，作为“当前能买到的最好水平”，用来衡量差距有多大。
• 中位基线：选一个同量级、口碑稳定的通用模型，作为“平均线”，用来回答“值不值得换”。
• 下界基线：选一个能塞进消费级显卡的小模型，作为“地板线”，用来判断匿名模型的体积优势是否真实。

除了模型基线，还有一组变量必须固定：系统提示词全文一致、温度固定、最大输出长度固定、题目顺序一致、并发数一致、判分脚本版本一致。任何一项变动，结论就不可比。我自己的做法是把这些配置写进一个配置文件，跑评测时整个文件哈希一遍记录在结果里，后面复盘的时候能对上号。

注意：温度这一项最容易被忽略。有的模型在温度 0.7 下表现明显好于 0.2，如果你只测一个值，很可能得出偏低的结论。稳妥的做法是每个关键维度至少测两个温度点。

2. 评测集怎么搭：把“感觉很强”变成可复现的数字

2.1 任务分层：L1 到 L4，覆盖从日常到长尾

题库不能全是难题，也不能全是简单题，得按难度和类型分层，这样出来的报告才能回答“它在哪一档”。我这次用的是四层结构，总规模 520 条自建题，全部是手写或改写，没有直接从公开数据集搬。

L1 是基础层，180 条，涵盖事实问答、信息抽取、文本改写、简单分类。这一层主要看基础扎实程度和格式稳定性，一个模型如果连这层都掉链子，后面不用看了。

L2 是复杂层，160 条，包含多步数学应用题、需要跨段整合的长文档问答、中等难度的代码生成与修复、以及带约束的长文写作。这一层是最能拉开差距的地方。

L3 是长尾层，120 条，故意挑偏门的：带方言色彩的语句理解、结构混乱的表格转 JSON、超长编号列表的精确引用、多层嵌套的格式要求、以及各种“请只输出 X 不要输出任何解释”的刁钻指令。

L4 是抗污染层，60 条，全部是我临时现造的题，比如把一个经典题目里的数字和主体替换掉、把常见问题的提问方式倒过来写、或者构造一个只有我这套题里才存在的虚构场景。这一层的目的是筛掉那些靠记忆题库拿分的模型。

分层的好处是，报告可以直接给出“L1 92%、L2 71%、L3 48%”这样的画像。一个模型如果在 L1 和 L2 都不错但 L3 崩了，那它的定位就是通用助手，不能拿去做数据清洗这类需要处理脏输入的活。

2.2 判分口径：能用规则判的绝不麻烦裁判模型

判分这块我吃过亏。早期图省事，全部交给一个强模型当裁判，结果发现裁判有明显偏好：偏爱结构清晰、分段多、带小标题的回答，哪怕内容空洞也给高分。后来改成三层判分，稳定性好了很多。

第一层是规则判分，覆盖 60% 的题目。选择题直接比对选项，抽取题比对关键字段，代码题跑单元测试看通过率，格式题用 JSON 解析器验证 schema。这层最可靠，因为它是确定性的。

第二层是成对比较，覆盖 30%。同一个题目分别喂给候选模型和基线模型，把两份回答随机打乱顺序交给裁判模型，跑两轮交换位置，只有两轮结论一致才算有效。位置交换这一步很关键，能消掉相当一部分位置偏置。

第三层是人工抽检，覆盖 10%，主要针对长文写作和开放式推理。这部分没法自动化，只能人看，但抽检样本一定是分层抽的，不能只抽高分样本。

import json, re def judge_format(answer: str, schema: dict) -> dict: """规则判分：校验结构化输出是否满足 schema""" try: data = json.loads(answer.strip().strip("`").replace("json\n", "", 1)) except Exception as e: return {"pass": False, "reason": f"JSON 解析失败: {e}"} missing = [k for k in schema["required"] if k not in data] if missing: return {"pass": False, "reason": f"缺字段: {missing}"} type_err = [] for k, t in schema["types"].items(): if k in data and not isinstance(data[k], t): type_err.append(k) return {"pass": not type_err, "reason": f"类型错误: {type_err}" if type_err else "ok"}

这段判分脚本很土，但它稳定、可复现、零成本，跑一万条也不会漂移。相比之下，裁判模型每次调用都要钱，而且版本一更新，历史分数就不可比了，所以我只把它用在确实需要语义判断的地方。

2.3 数据污染排查：三个不花钱但有效的土办法

匿名模型的训练数据是个黑箱，你没法从模型卡上知道它用了什么语料。所以污染排查只能靠行为观察，我常用的有三个办法。

第一个是同题变体法。把一道经典题改两个无关紧要的词，比如把“苹果”换成“梨”、把“12 个”改成“15 个”，看模型是不是还在用原来的答案。如果改完之后它仍然给出那个熟悉的数字或者熟悉的结论，基本可以判定是记住了原题而不是在做题。

第二个是要求给过程。对于推理题，强制要求分步输出，然后看过程的合理性。背题的模型往往过程混乱但答案正确，这种“答案对过程错”的模式是污染的最典型特征。我在 L4 层的 60 道题里发现了几处这种情况，答案对得上，但中间步骤出现了题目里不存在的条件。

第三个是日期与常识漂移。问一些时效性强的常识，看它对近半年发生的事情了解多少。这里要小心，了解得多不代表没污染，了解得少也不代表能力差，只能作为参考维度之一。我一般把它和知识题的正确率放在一起看，如果知识题分数极高但时效常识几乎为零，那说明它的训练数据可能截断得比较早，或者知识题的分是靠题库记忆拿的。

提示：污染排查不需要做到严谨的学术级别，你要的只是一个“能不能信这个分数”的判断。三个办法跑下来，如果疑点集中出现，就把对应维度的分数打七折看，结论会稳很多。

3. 环境拉起与第一轮实测全流程

3.1 接口调用与最小可用脚本

第一步是把服务拉起来，接到统一接口上。我不关心它内部用什么框架，只要暴露的是标准的对话补全接口，我的评测脚本就能直接复用。下面这个脚本是整个评测流程的地基，后面所有测试都是在它上面套不同的题目和判分逻辑。

import json, time, urllib.request ENDPOINT = "http://127.0.0.1:8000/v1/chat/completions" def call(prompt, system="你是一个严谨的助手。", temperature=0.2, max_tokens=1024, timeout=120): payload = { "messages": [ {"role": "system", "content": system}, {"role": "user", "content": prompt}, ], "temperature": temperature, "max_tokens": max_tokens, "stream": False, } req = urllib.request.Request( ENDPOINT, data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json"}, method="POST", ) t0 = time.time() with urllib.request.urlopen(req, timeout=timeout) as resp: body = json.loads(resp.read().decode("utf-8")) cost = time.time() - t0 text = body["choices"][0]["message"]["content"] usage = body.get("usage", {}) return {"text": text, "latency": round(cost, 2), "usage": usage} if __name__ == "__main__": r = call("用三句话说明为什么需要给模型评测设置固定随机种子。") print(r["text"]) print("耗时", r["latency"], "秒", "用量", r["usage"])

脚本里我特意把耗时和用量都打出来了。这两项在后面做成本换算的时候是原始数据，跑评测的时候顺手记录，比事后补测要省事得多。另外timeout我设得比较宽，因为有些模型在长输出时确实慢，超时定太短会误判成失败。

3.2 参数、显存与成本估算：先算清楚再决定要不要压测

在正式压测之前，我会先做一轮纸面估算，目的是判断这台机器能不能扛住，避免压到一半 OOM 白跑。

显存占用可以粗略按这个公式算：权重显存 ≈ 参数量 × 每参比特数 ÷ 8。以 FP16 为例，每参 16 比特，一个 7B 量级的模型权重约占 14GB；换成 8 比特量化降到 7GB 左右，4 比特量化降到 3.5GB 左右。这只是权重，还要加上 KV Cache。

KV Cache 的计算稍微复杂一点：缓存显存 ≈ 2 × 层数 × 隐藏维度 × 序列长度 × 批大小 × 每参比特数 ÷ 8。举例来说，层数 32、隐藏维度 4096、序列长度 8192、批大小 4、FP16 的情况下，缓存部分大约是 2 × 32 × 4096 × 8192 × 4 × 2 字节，算下来约 17GB。这个数字很多时候比权重还大，是长上下文场景下真正的显存杀手。

需要说明的是，这里的层数和维度是通用示意值，不同结构差异很大，实际测算以部署时的实测为准。我做估算的目的只是判断“大概够不够”，不是精确值。

成本换算我用的是单位千 token 的综合成本，把电费、机器折旧、人力维护都摊进去。这个数字在不同团队差异很大，我给不出通用值，只能提醒一句：别只算推理卡的钱。运维、监控、故障排查、版本升级这些隐性成本，在长期运行里往往比卡钱还多。

3.3 第一轮实测数据记录：先看画像，不看总分

第一轮我跑了 L1 和 L2 共 340 条，温度 0.2，最大输出 1024。结果整理成下面这张表，分数是规则判分和成对比较混合后的加权值。

这张表最有意思的地方不是它比上界差多少，而是它在中位基线之上的位置。事实问答和抽取小幅领先，格式遵守甚至反超上界基线，但多步推理和代码落后明显。这个画像非常典型：擅长模式匹配和格式输出，不擅长需要多步状态维护的任务。我在实测里也印证了这一点，它在写格式化报告、做字段抽取这类活上很稳，但一旦要求连续做五步推理并保持中间结果，错误率就上来了。

还有个小发现，格式遵守分数高得有点反常。我把 L3 里的刁钻指令单独抽出来又跑了一遍，发现它在“只输出 JSON 不要任何解释”这类约束上确实强，几乎不啰嗦。这个特性看起来不起眼，但在实际工程里价值很高，因为解析失败带来的重试成本往往比模型能力不足更让人头疼。

3.4 长上下文与多轮稳定性：最容易翻车的地方

长上下文我用了经典的填充测试：在一段几万字的技术文档中间埋一句特定信息，然后问模型那句话是什么，分别测 8K、32K、128K 三个长度，每个长度测 20 次取平均，信息埋在开头、中间、结尾三个位置。

结果很说明问题。8K 长度下命中率接近满分，32K 掉到八成多，128K 掉到六成出头，而且信息埋在中间位置时最差，开头和结尾反而好。这就是典型的中间遗忘现象，很多模型都有，不是这家独有的问题，但它决定了你不能拿它去做“整本手册一次塞进去”的活。

多轮稳定性是另一个坑。我做了 12 轮连续对话，每轮追问一点细节，观察它是否还记得第一轮设定的约束。前六轮基本稳，第八轮之后开始出现约束丢失，第十二轮时它已经忘了最初要求的输出格式。这个衰减速度在同量级模型里算中等偏上，但如果你要做长会话客服，得设计一套外部记忆机制，不能指望模型自己记住。

4. 六个维度的深水区实测细节

4.1 推理与数学：思维链长度和正确率不成正比

我在 L2 推理题上做了个额外实验：同一道题，分别用“直接给答案”“先分析再作答”“强制分五步”三种提示，看正确率变化。结果前两种差不多，第三种反而略微下降。原因是强制分步时，模型会在中间步骤自己给自己挖坑，一步错了后面全错，而且它不会回头检查。

这个现象给我的启示是：对这类模型，别迷信“让它多想一会儿”。它的强项是一次成型，弱点是没有自我纠错回路。真正有效的做法是在提示词里加一条“如果发现前一步有误，请停下来重新推理”，把检查动作显式写出来，比单纯拉长思维链有用得多。

另一个细节是答案截断。推理题如果最大输出设得太小，它会话说到一半就断，最终答案丢失。我一开始把 max_tokens 设成 512，结果有 11% 的推理题被判错，回头看原始输出，其实推理方向是对的，就是没写完。把上限提到 1024 之后，这 11% 里有七成变成了正确。这个教训很朴素：输出的长度上限，会直接影响推理维度的分数，测的时候一定要留足余量。

4.2 代码生成与调试：单测通过率和“能跑起来”是两回事

代码这块我用了 40 道题，覆盖算法实现、数据处理脚本、正则构造、以及带 bug 的代码修复。判分不看代码漂亮不漂亮，只跑单元测试，通过就算对。

结果是单测通过率 68%，但可运行率（能直接执行不报错）只有 61%。这两个数字的差距，主要来自依赖幻觉——它会引用一些并不存在的库函数，或者用了某个库的旧版接口。比如让它写一个配置解析脚本，它会调用一个看起来很像那么回事的方法名，实际那个方法在新版里已经被改名了。这类幻觉很隐蔽，因为它长得完全合理，只有真跑才知道。

调试能力是我比较意外的一项。给它一段报错信息和对应代码，让它定位问题，它的表现明显好于从零写代码。40 道题里有 9 道是这种调试题，它答对了 7 道，而且给出的修改建议基本能对上。这说明它的模式识别能力是真的强，擅长在现成材料上做判断，不擅长凭空构造完整方案。

实操建议：用它写代码，一定要配一个自动执行的沙箱，让它自己跑一遍。光看代码看不出问题，跑起来才知道哪一行在骗人。

4.3 中文长文写作：结构漂亮，细节容易飘

我给了它三个写作任务：一份产品需求文档、一篇技术说明、一篇面向非专业读者的科普。评判标准是四项：结构完整、事实准确、术语使用恰当、没有明显重复。

结构和术语两项它表现很好，需求文档的章节划分甚至比我自己写的还清晰。事实准确这一项掉分，具体表现是它会为了行文流畅而补一些想当然的细节，比如给一个虚构的指标编一个看起来合理的数值，或者把一个不确定的结论写成确定句。这类问题在技术文档里是致命的，因为我没法逐句去核实。

还有一个细节是重复。超过 1500 字之后，它开始出现段落级的重复表达，同一个意思换个说法再说一遍。我统计了一下，一篇 2000 字的稿子里大约有 3 到 4 处这样的冗余。人工修改一遍需要十几分钟，这个成本要算进去。

对策是在提示词里明确列出禁忌：不得编造任何具体数字、不确定的表述必须加限定词、每段必须有新信息。加了这三条之后，编造问题减少了大概一半，还是有残留，但已经可以用了。

4.4 指令遵循与格式约束：这是它的主场

我把格式约束单独拉出来测，因为这是它的强项，值得说细一点。测试包含：输出指定 JSON schema、只输出单个词、按固定分隔符拼接、在特定位置插入标记、拒绝执行某些请求并给出理由。

JSON schema 遵守率 94%，失败的那 6% 主要是嵌套层级深的地方，比如三层以上嵌套数组里的字段类型写错。单字段约束几乎全对，多字段组合也基本稳。这个水平已经可以直接用在做数据清洗的流水线里了，配上重试机制，整体稳定性完全够。

有个有趣的现象：它对否定式指令的遵守度明显低于肯定式。要求“输出 A”它很准，要求“不要输出 A”它偶尔还是会带出来。这是语言模型的通病，解决思路是把否定改成肯定，比如“只输出 B，不要输出 A”改成“输出 B”，效果立刻变好。

提示：格式约束类任务，把要求写成正向的、具体的、可验证的，比写一堆禁止项有效得多。这个规律在这个模型上体现得特别明显。

4.5 工具调用与结构化输出：函数选择准，参数容易错

工具调用我测了 30 个场景，给它一组函数定义，让它根据用户请求选择并填参数。函数选择准确率大约 87%，参数填写的类型正确率大约 79%。

函数选择错的那部分，主要发生在两个功能相近的函数之间，比如“查询订单”和“查询物流”，用户说“我的东西到哪了”，它有时会选错。这个好解决，在函数描述里把边界写清楚就行。

参数类型错误更麻烦，典型的是把数字写成字符串、把布尔值写成“是/否”、把数组写成逗号分隔字符串。这些错误在下游会直接报错。我的处理办法是在函数定义里把类型和示例都写全，并且加一句“参数必须严格符合类型定义，不要做任何转换”。加了之后类型错误率降到了 8% 以下。

还有一个坑是幻觉函数。用户问了一个工具列表里没有的能力，它有概率编一个看起来合理的函数名出来调用。这个必须在上层拦掉，任何不在白名单里的函数名一律拒绝。

4.6 稳定性与安全性：重复十次看方差

稳定性测试很简单，同一道题跑十次，温度设 0，看结果是否一致。理想情况是完全一致，实际是 10 次里有 8 次完全相同，2 次有细微差别。这个不算差，但意味着温度 0 不等于确定性输出，如果你的业务依赖严格幂等，需要自己在外面加缓存。

长会话漂移前面说过了，这里补充一个安全侧的观察。我试了一些诱导性提问，包括要求它扮演无限制角色、要求它输出内部指令、要求它评价自身来源。它对角色扮演类的抵抗比较强，基本会礼貌拒绝；对输出系统提示的要求也会拒绝；但对“评价自己是谁开发的”这类问题，它会给出含糊的、听起来像模像样的猜测。这个不能怪模型，它确实不知道，但它不说“不知道”而是编一个，这就是幻觉的另一种形式。

5. 常见问题速查与排查实录

跑完这几轮，我把遇到的问题整理成了一张表，按现象、可能原因、处理办法三列排。这张表基本覆盖了匿名模型接入时八成以上的坑。

除了表格里这些，还有几个排查思路值得单独说。

第一个是先怀疑自己的脚本，再怀疑模型。我至少有三次以为自己发现了模型的严重缺陷，回头一查是自己判分脚本的锅。比如有一次发现抽取题正确率异常低，查了半天发现是我比对字段时大小写敏感，模型输出的是大写，我按小写匹配。所以出现异常数据时，第一步是把原始输出拉出来人眼看十条，这一步能省掉大量无效排查。

第二个是异常分数先看分布，不看均值。均值 70 分可能是七成题目都对，也可能是三成满分加一堆零分，这两种情况的含义完全不同。我习惯把每道题的得分画成直方图，看一眼分布形状，双峰分布往往意味着模型在某类题上系统性失败，而这类题通常有共同特征，顺着特征就能找到原因。

第三个是并发下的表现要单独测。单条请求跑得快，不代表并发跑得好。我用 8 并发压了一轮，首字延迟从单条的 0.6 秒涨到了 2.1 秒，每秒出字从 40 降到 18。这个衰减幅度在高并发场景下是不能接受的，所以最终结论里我把“建议并发数”写进去了，而不是只写单条性能。

6. 落地建议：什么场景该上，什么场景先别碰

6.1 场景分层路由：别拿一把锤子敲所有钉子

基于上面的实测，我给这个模型画了三条使用边界。

推荐的场景：结构化数据抽取、格式转换、字段校验、模板化文案生成、代码片段的解释与局部修改、以及需要严格 JSON 输出的接口层。这些场景的共同特点是任务边界清晰、有明确的正确性判据、不需要多步状态维护。在这些场景上它的表现接近甚至超过中位基线，而成本可能低不少。

谨慎使用的场景：多步业务推理、需要长文档整体理解的分析、复杂代码从零构造、面向外部用户的自由对话。这些场景要么对准确性要求极高，要么需要跨段整合，它的短板会直接暴露。真要用，必须加人工复核环节。

暂不推荐的场景：涉及关键决策的自动化流程、需要严格幂等的服务、以及需要长期记忆的连续会话。这三类要么风险太高，要么它的稳定性还撑不住。

分层路由的实现其实不复杂，一个简单的分类器加一张规则表就够了。简单任务走小模型，复杂任务升级到大模型，中间加一个置信度阈值。我自己的经验是，这套路由能省下三到四成的调用成本，而且用户几乎感知不到差别。

6.2 灰度与回滚：先把退路铺好再上线

模型替换最大的风险不是效果变差，是效果变差了你不知道，或者知道了也来不及回滚。所以上线前一定要准备好三样东西。

一是影子流量。新模型先接一部分真实流量但不影响用户，把输出存下来离线比对。这个阶段重点看两件事：整体分数是否稳定、有没有出现基线模型完全不会出现的错误类型。我一般跑三到五天，样本量够了再决策。

二是一键回滚开关。配置里留一个开关，出问题直接切回旧模型，切换时间控制在分钟级。这个开关要定期演练，别到真出事的时候才发现切不过去。

三是回归测试集。把这次实测里最具代表性的 100 条题固化下来，每次模型版本更新都跑一遍。这套题库是资产，跑一次成本很低，但能拦住绝大多数退化。

6.3 我自己的几点体会

最后说点不在框架里的东西。

关于匿名模型，我的态度一直是：可以试，别轻信，更别裸奔上线。匿名本身不是问题，问题是匿名意味着你拿不到训练数据说明、拿不到版本变更记录、拿不到长期维护承诺。这三样东西在项目初期看起来不重要，到了运行半年之后，会变成非常现实的麻烦。所以我给它的定位是“一个可以快速验证能力的候选”，而不是“可以直接托付的长期方案”。

关于榜单，我现在基本只用它做初筛，绝不用它做决策。榜单能告诉你“这个方向有人在认真做”，但告诉不了你“它能不能解决你的具体问题”。真正有用的信息，永远来自你自己那 500 道题。

关于实测这件事，我最深的一个感受是：测模型其实是在测你自己的需求。一开始我列的评测维度特别多，跑到一半发现有一半的维度对我的业务毫无意义。后来我把维度砍到六个，每个都对应一个真实场景，报告反而更有说服力。与其追求评测的全面，不如追求评测的针对性，一个能回答“我这个场景能不能用”的窄报告，比一份漂亮的大而全报告有价值得多。

“太空兔”这个名字过几个月大概就没人提了，下一波还会有新的代号冒出来。把这套方法论留下来，比记住某个模型的分数有用。