企业官网建设流程全解析

上周三晚上开始，好几个技术群里在转同一张截图：某个只挂了一个动物代号“太空兔”的模型，出现在某公开对战榜单的头名位置，分数压过了一众有名有姓的旗舰款。紧接着就是熟悉的那套剧情——实测帖、猜测帖、“我有内部消息”帖在两天之内铺满了时间线，评论区从“吊打一切”到“榜单已死”吵成一锅粥。

我花了两天把这个黑盒啃到半透明，跑了几十组对照实验，同时也把它和几个已知对照组模型放在同一套题上反复比对。结论可能跟大多数热帖里喊的不太一样：“太空兔”确实有真东西，但真正值得聊的不是它排第几，而是“排行榜第一 + 匿名代号 + 全网爆火”这个组合本身会怎么扭曲你的判断。

这篇不打算给它封神，也不打算猜它是谁家出来的。我想讲的是另一件事——当一个新的匿名模型冲上榜首，一个从业者到底该怎么实测它。怎么设计题、怎么控变量、怎么从输出里读蛛丝马迹、怎么避免自己被“爆火”这两个字牵着走。这套方法放到任何一个代号模型上都成立，不管它叫太空兔、太空猫还是别的什么。

1. 代号模型登顶这件事，噪音比信号多得多

1.1 一个没有名字的模型，是怎么被“投”到第一的

先把榜单机制捋清楚，不然后面所有讨论都是空中楼阁。这类公开对战榜单的核心玩法是匿名两两对打 + 用户盲投 + 事后计分。你看到两个不知道是谁的回答，投完票才揭示身份。计分通常用类似国际象棋的等级分体系（Elo 或其变体），也有平台用 Bradley-Terry 模型做统计拟合。这套机制的初衷是好的：屏蔽品牌偏见，让能力说话。

但机制一旦落到真实流量里，就会长出几个不那么好看的特征。

第一，投票者是自选择样本。愿意花时间去点“哪个更好”的人，本身就对模型输出有一定审美偏好——他们更偏爱长回答、更偏爱分点排版、更偏爱“先给结论再展开”的结构。这直接导致一类专门迎合投票口味的输出风格会系统性占优，跟真实业务里“我要一句能塞进代码里的答案”完全不是一回事。

第二，等级分的置信区间在大样本下依然很宽。榜单头名和第五名之间的分差，经常落在统计噪声范围之内。你去翻那些公开的分数表，前几名的分差往往只有十几二十分，而单场对局的方差贡献远大于这个量级。说白了，“第一名”很多时候只是“统计上无法与第一梯队区分”的一个幸运切片。

第三，代号本身就是一种营销杠杆。一个叫“太空兔”的匿名模型和一个叫“anonymous-model-v3”的匿名模型，获得的讨论量能差一个数量级。代号越有记忆点，传播越快，实测帖越多，越容易形成“大家都在用、应该很强”的正反馈。这在评估方法论里有个专门的词叫信息级联——后面的人不再独立判断，而是参考前面人的结论。

提醒：看到一个陌生代号冲上榜首，第一反应不该是“它多强”，而该是“它的分数是怎么攒出来的”。这两者的区别，决定了你后面两天是白干还是真有收获。

1.2 爆火链路里那三个必然失真的环节

从我观察到的传播链路看，一个代号模型从“上榜”到“全网爆火”，中间至少要穿过三道失真滤镜，每一道都会往你的判断里掺东西。

第一道是标题滤镜。大多数转发帖的标题结构是固定的：“XX榜单第一”“碾压”“实测震惊”。这类标题在信息压缩过程中会丢掉所有限定条件——丢掉了“仅在某单一维度”“仅在特定投票人群下”“分差在误差范围内”。等这条信息传到你耳朵里时，只剩一个光秃秃的“第一”。

第二道是演示滤镜。你看到的实测截图，基本都是发布者精挑细选的 best-of-N。这不是说他们在造假，而是人的本能——测到一段惊艳输出就想发出来，测到一段平庸输出就默默跳过。于是时间线上累积起来的印象，是一个被 cherry-pick 过的输出分布上界，不是中位数，更不是下界。我自己就吃过这个亏：某个模型在演示里流畅得像换了个人，我自己上手一跑，稍微复杂一点的多步指令就开始漂。

第三道是期待滤镜。这一条最隐蔽。当你带着“这是榜首”的预期去测，你会不自觉地对它的输出更宽容，对对照组更苛刻。同一段有轻微事实错误的回答，如果来自“太空兔”你会想“大概是这题太刁钻”，如果来自对照组你会想“果然不行”。这就是典型的确认偏误，而它在实测里几乎无法靠自觉消除，只能靠盲评 + 结构化打分表来对冲。

三道滤镜叠下来，你从社交媒体上获得的“太空兔很强”这个印象，可靠性大概跟“我在朋友圈看到有人说这家店好吃”差不多。它可能是对的，但你需要自己进去吃一顿。

2. 把它当纯黑盒：动手之前先钉死这四件事

2.1 评测集别用你熟悉的那套题

我见过太多人做实测，上来就是问“9.11 和 9.9 哪个大”“strawberry 里有几个 r”。这些题不是不能测，而是已经被模型侧反复优化过，测出来的结果解释力非常有限。你测的其实是“这个模型有没有被针对性地打过补丁”，而不是推理能力。

我这次的评测集是分四层搭的，每一层解决不同的疑问：

L4 是我最看重的一层，也是绝大多数实测帖直接跳过的一层。做法很简单：翻出你自己过去三个月里被旧模型搞砸的真实请求，原封不动地重放一遍。这些题没有标准答案，但有明确的“能不能用”的判据——比如输出能不能直接粘进配置文件、能不能直接过 CI、能不能被下游解析器吃掉。用别人的题测出来的是别人的结论，用自己的失败案例测出来的才是自己的结论。

设计题量时我踩过一个坑：一开始每个维度只出 5 道题，结果两组模型分数咬得死死的，根本拉不开差距。后来把单维度题量提到 20 道以上，同一批题重复跑 3 次，结论才稳定下来。经验值是每个你想下结论的维度，至少 15 到 20 道独立题，且每题至少 2 次采样，否则你看到的差异大概率是采样噪声。

2.2 温度、并发、成本这三条线得一起定

控变量这件事说起来简单，做起来全是细节。同一个模型，温度从 0 调到 1.0，在创意任务上表现的差距能大到让你怀疑是不是换了模型。我这次的统一配置是：

# 实测统一采样参数（示意） CONFIG = { "temperature": 0.2, # 事实类、代码类任务用低温 "top_p": 0.9, "max_tokens": 2048, "repetitions": 3, # 每题重复 3 次取多数/取最好 } # 创意类、写作类任务单独一套 CONFIG_CREATIVE = { "temperature": 0.8, "top_p": 0.95, "max_tokens": 1536, "repetitions": 2, }

为什么要分两套？因为用 0.2 的温度去测文案生成，你会得出“这模型写得干巴巴”的错误结论；用 0.8 的温度去测 SQL 生成，你会得出“这模型不稳定”的错误结论。任务类型决定采样参数，采样参数决定你看到的输出分布，输出分布决定你的结论。这条链子在任何一环上出错，后面的工作全废。

并发和成本这条线也很现实。几十道题 × 多次采样 × 多个模型，请求量很容易上到四位数。我一般是先用 10% 的题目做一轮快速筛查，把明显不在同一档的对照组剔掉，再对剩下的做全量跑。同时给每次请求记录 token 消耗，最后算出一个“单次可用输出的平均成本”——这个指标在选型时比榜单分数有用得多，因为它直接决定你的业务能不能规模化。

注意：跑之前先确认每个模型的最大上下文和最大输出长度限制，把超限的题单独标记出来，不要让它污染整体统计。我第一轮就有一批长文档题因为超出对照组窗口直接被截断，导致对照组得分被严重低估，白跑了两个小时。

3. 六个维度压出来，才能看清它到底在哪一档

3.1 指令遵循：用“压力梯度”而不是单点测试

指令遵循是最容易测出差距、也最容易被测歪的维度。单点测试（“用三句话总结这段”）几乎拉不开差距，因为现在的中等模型都能做到。真正能分出高下的是多层嵌套约束同时施加。我的做法是设计一条压力梯度，从 1 个约束一路加到 6 个约束，看模型在第几层开始崩。

举个我实际用过的梯度样例（脱敏后）：

• 第 1 层：输出一段产品描述，300 字左右。
• 第 2 层：加约束——必须包含三个具体数字。
• 第 3 层：加约束——全文不得出现“领先”“领先者”“首创”这类形容词。
• 第 4 层：加约束——必须以一个反问句结尾。
• 第 5 层：加约束——第二段必须只有一句话。
• 第 6 层：加约束——把上面所有内容包在一个 JSON 里，字段名固定为title/body/hook。

“太空兔”在这条梯度上给我的印象是：前四层稳，第五层开始偶发漂移，第六层在重复采样里有大约三分之一的情况会破坏 JSON 结构（比如在 body 里塞了未转义的引号，或者把 hook 写成数组）。这个结果不算差，但也绝对谈不上“断层领先”。对照组里有模型在第四层就崩，也有模型能稳稳撑到第六层。

这个设计的价值在于它给出的是一条能力曲线，而不是一个分数。曲线能告诉你“它在什么复杂度下开始不可靠”，这个信息在工程上比“它比谁高 20 分”有用得多——因为你可以据此决定把它的使用边界画在哪里。

3.2 长上下文：埋针法比扔长文有效得多

长上下文是这轮代号模型最爱宣传的能力，也是最容易注水的。厂商说“支持超长上下文”，实际跑起来经常是“能塞进去，但找不到”。

我的测试方法是埋针 + 多跳定位，分三步：

1. 构造一份长文档（我用的是自己攒的技术笔记，长度控制在窗口的 60%~70%，别贴满，贴满反而容易触发截断）。
2. 在文档的不同深度（10%、30%、50%、70%、90% 位置）各埋一条互不相关的关键信息，每条都用一个不常见的编号标记，比如“第 K-73 号约束”。
3. 提问时不给位置提示，只问“第 K-73 号约束说的是什么”，然后再追问一个需要跨两条针做推理的问题。

这套方法测出来的东西非常直观。太空兔在前 50% 深度的单针检索上表现干净利落，到了 70% 之后开始出现“答得出来但编号记错”的情况；而跨两针的推理题，在 90% 深度组合上它的正确率明显下滑。对照组里有模型更极端——前 30% 检索准确，后半段直接编造一个编号相近的内容，而且编得非常自信，格式完整、语气笃定。

这里有个血泪教训：不要用“大海捞针”类的公开基准题去下结论。这类题目已经被大量优化过，很多模型对它们的模板有记忆。用自己领域的真实长文档，效果完全不一样，因为真实文档里的干扰项是自然分布的，不是人工构造的。

3.3 代码与结构化输出：能跑通远重要于能写出来

代码能力这块，我的评判标准只有一个：产物能不能直接过验证。不是看它写得漂不漂亮，不是看它注释全不全，就是看能不能跑。

我的验证流程是这样的：给定一个明确的功能需求（比如“写一个把嵌套 JSON 拍平成单层字典的函数，保留路径作为 key”），要求模型输出完整可执行的代码，然后我把输出原样保存成文件，直接跑我预置的测试用例。用例覆盖正常输入、空值、深层嵌套、键名冲突四种情况。

实测下来，“太空兔”在常规输入和空值处理上表现稳定，生成的代码基本一次通过；在键名冲突这种边界场景上，它生成的实现会出现覆盖前值的问题，需要我补一句提示才修正。这个表现和对照组的第一梯队基本在同一水平线，没有明显优势也没有明显短板。

结构化输出这一块要单独拎出来说。金融、运维、数据处理这些场景里，模型输出的 JSON 经常要直接喂给下游解析器，一个未转义的字符就能让整条流水线挂掉。我建议的测法是：连续让它输出 20 次同结构的 JSON，然后全部丢进json.loads()里跑一遍，统计失败率。这个数字比任何主观评价都实在。“太空兔”在我这轮里 20 次失败 2 次，失败原因都是字符串里出现了未转义的双引号。这个失败率在可接受范围内，但意味着生产环境必须加一层 schema 校验和重试，不能裸用。

3.4 中文语感与长文写作：看“中位数输出”，别看最好那段

写作能力是最容易产生“演示幻觉”的维度。一个模型偶尔写出一段漂亮的文字，不代表它稳定。我的做法是让它就同一个题目连写 6 遍，然后我自己从这 6 篇里挑出最差的那一篇来评价——因为业务里你不能保证每次调用都抽到最好那次。

具体看什么？我看三件事：

• 段落之间的逻辑咬合。好的输出每一段都在推进，差的输出是在平面上铺砖，三段话说的是一件事。
• 有没有“万能句式”反复出现。“总的来说”“值得注意的是”“在这个快速变化的时代”——这类句子的密度是最直接的水分指标。
• 信息密度。同样 800 字，一篇文章里有多少是可验证的具体信息，多少是形容词堆砌。我一般会数一下具体名词和数字的占比，低于某个线的直接判不合格。

“太空兔”在中文长文上的中位数表现，坦白讲在我预期之内：语句通顺，结构规矩，但个性偏弱，属于“读起来没毛病，读完记不住”的那一类。它在短文本改写和润色上的表现反而比长文更好一些，指令响应更贴合。对照组里有模型长文明显更有想法但偶尔逻辑跳步，也有模型稳但平。这个维度很难拉出绝对的高下，更多是风格差异，选型时得看你自己的场景更吃哪一口。

4. 从输出痕迹反推来源，哪些线索真有用

4.1 分词痕迹、拒答话术、模板化开头

很多人喜欢从输出细节反推模型来源，这个玩法有一定道理，但成功率远低于网上的传说。我把常用的线索按可靠性排了个序：

为什么自我声明极低？因为它已经被系统性训练成不可信了。你问十个模型“你是谁”，能得到十种答案，其中大部分是错的、模糊的或者是设定好的。把这当成线索，等于自欺欺人。

分词痕迹这块倒是有点意思。你可以构造一些包含罕见字、生僻组合、非常规标点的输入，观察输出的切分习惯。不同技术路线的模型在处理这些边界情况时有细微差异。但这个方法的信噪比很低，需要大量样本才能勉强看出倾向，而且很容易被“后训练对齐”抹平。我个人的态度是：当个乐子可以，别当证据。

拒答话术反而是相对稳定的指纹。每个模型在触发安全干预时，倾向于用一套固定的措辞模式——有人喜欢“我理解你的需求，但是……”，有人喜欢直接一句“抱歉，我无法协助”。这类模板在多次触发后会高度一致。我这次故意构造了十几组会触发干预的边界输入，记录下“太空兔”的拒答措辞，确实能和几个已知对照组区分开。但这只能告诉你“它和某几家的风格不像”，推不出“它是谁”。

4.2 反推法的失效边界在哪

必须说清楚一件事：反推的可靠性在持续下降。原因很简单，所有主流模型都在同一批公开数据上做后训练，风格在趋同。三年前你能靠“它喜欢用分号”认出某一家，现在不行了，因为大家都学会了分号和“首先/其次/最后”。

还有一个更现实的干扰因素：产品层和模型层是两回事。你测的是某个接口后面的模型，但这个接口可能套了一层系统提示词、一层输出格式化、一层安全过滤、甚至一层路由分发。你观察到的“风格”，很可能是产品团队写的系统提示词，而不是模型的固有特征。我这次的实测里就有一次误判：某个对照组输出异常简洁，我一度以为是模型本身的问题，后来才想明白是接口层强制加了长度约束。

所以我的建议是：把反推当成一个假设生成器，而不是结论生成器。你可以从痕迹里提出“它可能属于某某技术路线”的假设，但不能拿这个假设去指导任何实际决策。真正指导决策的，永远是那个最朴素的问题——它在我这套题上跑出的结果，能不能让我少改几遍。

5. 实测里最容易翻车的几个地方

5.1 提示词污染：改一版问一遍等于没测

这是我早年犯得最多的错误。测到一半发现题目表述有歧义，顺手改一版再问；改完发现答得不好，又加一句“请仔细思考”再问一遍。三轮下来，你手上是三条不同提示词下的结果，根本没法横向比较。

正确做法是提示词冻结。所有题目在开跑之前定稿，跑的过程中一个字都不改。如果中途发现某题有问题，正确流程是：把这题标记为作废，从头用新提示词重跑，且新提示词要用在所有被测模型上，不能只对某一个模型改。这条纪律听起来简单，执行起来非常考验自制力，因为改一个字就能让它答得更好，手真的很痒。

顺带说一个相关的坑：多轮对话里的上下文累积。如果你在同一个会话里连续问十几道题，前面的回答会持续影响后面的判断。测独立性的时候必须每题开新会话，测多轮能力的时候才有意把题串起来。这两件事在报告里要分开写，不能混着算总分。

5.2 单人打分等于白测：评分者偏差的量化对冲

自己出题、自己跑、自己打分，这套流程最大的漏洞是评分者偏差。你出了题，心里已经有预期答案；你跑了模型，看到了输出；你再打分，很难不受“这是榜首模型”这个预期的干扰。

对冲手段有三个，我按有效性排序：

第一，盲评。把模型名去掉，输出顺序随机打乱，给它们编上 A/B/C 代号，然后再打分。这一步能把品牌偏见削掉一大半。实现上很简单，跑完之后写个脚本把输出洗一遍再存成匿名文件就行。

第二，多人交叉。找两三个同事，用同一份评分表独立打分。别给他们看你的分数，也别告诉他们哪个是太空兔。最后算一下评分者间的一致性（简单点就用分数排序的相关系数），一致性低于某个阈值就说明你的评分表定义不清，得重新写。

第三，把主观判断转成可验证判据。能自动验证的绝不靠眼睛看。代码题跑测试用例，JSON 题跑解析器，格式题写正则检查，事实题查资料核对。只有那些真的没法自动化的部分（比如行文流畅度）才用人工打分，而且必须限定在总分的较小权重内。我自己的评分表里，自动可验证的部分权重占了 70%，主观部分只占 30%。

评分表的结构我大概长这样：

任务编号 / 任务类型 / 是否满足核心约束(0/1) / 是否可自动验证通过(0/1) 格式合规(0-2) / 信息准确性(0-2) / 可用性-能否直接使用(0/2) / 备注

注意“可用性”这一项的判据要写死：能直接贴进目标环境且不需要任何修改 = 2，需要改一处 = 1，需要重写 = 0。判据写死了，不同人打出来的分才有可比性。

5.3 被“爆火”拖着走：注意力成本也是成本

最后这条不是技术坑，是节奏坑。一个模型爆火的时候，你会不自觉地想“赶紧测完发出来”，于是压缩题量、跳过盲评、省掉重复采样，最后产出一篇看起来热闹但结论站不住的实测帖。我自己在第一天就差点这么干——晚上十点开始测，测到十二点只跑了三十道题，就想直接写结论了。后来忍住，第二天补了两轮，把一批原始结论全推翻了。

我的建议是：给自己设一个最低完成线，达不到就不发。我的最低线是每个维度 15 道题、每题 2 次采样、必须盲评、必须有自动验证。达不到这条线，写出来的东西就只能算“个人印象”，不能算“实测”。这两者在读者眼里可能长得差不多，但在你自己心里必须分得很清楚。

6. 把这一轮实测整理成别人能复用的东西

6.1 报告该写什么：字段比结论重要

测完之后我发现，最有价值的产出不是“太空兔强不强”这个结论，而是一份结构化的评估记录。结论会过期——模型一更新就失效；但评估记录不会，因为它记录的是“在什么条件下、用什么方法、观察到了什么现象”，这些东西下次换个代号模型还能直接套用。

我的记录表固定包含这几列：任务编号、维度、提示词版本号、采样参数、自动验证结果、单次可用性评分、失败模式归类。最后这一列“失败模式归类”是我加得最值的一列，因为它能告诉你这个模型的薄弱点在类别层面长什么样。

“太空兔”这轮的失败模式，我归出了三类：

• 结构破坏类：JSON 未转义、嵌套层级错误。占比最高，主要集中在高约束多层任务上。
• 位置遗忘类：长上下文后段信息定位错误。集中在文档深度 70% 之后。
• 过度收敛类：开放写作题里六次采样输出的结构高度雷同，缺乏变化。这个现象在低温下尤其明显，本质上是分布太窄。

这三类失败模式比任何分数都有用，因为它们直接对应工程上的补救措施：第一类加 schema 校验和重试，第二类把关键信息前置或者拆成多轮检索，第三类在需要多样性的场景里把温度调高或者显式要求换角度。

6.2 后续可以怎么往下扩展

这一轮测完，我手上还留了几个没跑完的方向，写出来给同样想动手的人参考。

一个是跨轮一致性。让模型对同一个有争议的问题连续回答十次（每次新会话），看它立场漂移的幅度。这个指标在法律、医疗、金融这类需要稳定输出的场景里非常关键，但公开榜单完全测不出来。

另一个是降级表现。把提示词故意写模糊、写错别字、写得不完整，看模型能不能猜对意图。真实用户不会写完美的 prompt，这个维度比“给它一个精雕细琢的复杂指令它能执行”更贴近投产环境。

还有一个我自己很感兴趣的：失败后的自我修正能力。把它上一轮的错误输出原样丢回去，只说一句“这有问题，改”，不给具体方向，看它能不能自己定位到问题所在。这个能力在 agent 类应用里几乎是刚需，但目前我还没看到特别可靠的评测方式，只能靠大量真实案例硬堆。

我个人在实际操作中的体会是，做这类实测最容易犯的错误不是方法不对，而是太想快点得出一个能发的结论。太空兔这轮跑下来，我最大的收获不是知道它排第几，而是把自己的评测流程又打磨了一遍——题库更贴近真实业务了，评分表判据更死了，盲评环节彻底固化了。至于它到底是不是真的第一，我只能说：在我的这套题上，它落在第一梯队里，但没有任何一维度表现出能够和同梯队拉开身位的优势。这个结论听起来平淡，可它就是两天实验的真实结果，我不会为了配合“全网爆火”的氛围去修饰它。