## 一、先看三行硬指标 发布会开完两小时，通稿就铺出来了。标题里全是"重磅""全面领先""重新定义"，读完还是不知道这东西到底能干什么。 其实真信息就藏在开头几行：模型名和版本号、上下文长度、每百万 token 的价格。 这三项一定，能力边界和成本大致就清楚了。剩下的话术，先放一边。 我自己习惯把发布会当体检报告看。看得多了会发现，通稿里最好看的是效果演示，最难看的是小字备注。 小字里通常有三个东西：测试环境、对比对象、前提条件。三个都写清楚，那个数字才有意义；只写一个，剩下的只能靠猜。 比如「提升三倍」，是相对上一代还是相对开源基线？是单卡还是集群？是某个任务还是全套？三问不定，这个倍数就只能当形容词看。 还有一个细节：讲的顺序。先讲什么，说明团队最想让你记住什么；讲得最少的那个模块，才是真正该去翻文档的地方。 ## 二、参数别只看总量 通稿喜欢写"参数规模达到多少亿"。这个数字有意义，但意义有限。 同样规模的两个模型，训练数据质量差一截，实际表现能差出两个档。而且多数模型并不会把训练数据量写清楚，只说"海量高质量语料"。 看到参数量，接着往下找三样：训练的 token 数、数据配比、有没有提后训练阶段。三样都没有，这个数字基本只能当宣传看。 硬指标我一般只认三行：模型规模、训练数据量、以及推理成本。三行之外的，多数是包装。 为什么是这三行？因为它们决定了这玩意能不能落地。规模决定能力上限，数据决定覆盖面，成本决定你敢不敢用。 如果通稿通篇没提推理成本，基本可以判断：它贵，而且作者自己也知道贵。定价页通常藏在最后一屏。 ## 三、上下文长度要看"有效"两个字 "支持百万上下文"是这几年最常见的宣传点。 但能不能真的用满，要看两件事：长文检索测试的分数，以及超过某个长度后价格怎么算。 有的模型二十万以内很稳，往后就开始漏信息，这叫名义长度。通稿不会说，得去技术报告和技术博客里翻。 有效上下文这个词，落到使用上就是：把关键材料放开头和结尾，中间留给不太重要的内容。 我去年开始改成这个习惯。几百页的文档不再整段灌进去，先让它给个目录，再按目录一段一段问。速度快了，答错也少了。 另一个办法是复述。每聊四五轮，让它用三句话概括前面的结论，再往下走。这一步看着多余，实际上省掉不少跑偏。 ## 四、价格表比参数表更值得存下来 我有个习惯：发布会一结束，先把价格表截图存进同一个文件夹。 原因是模型迭代太快，三个月后再算成本，谁都不记得当时什么价。存着这些截图，做选型和预算能对上账。 顺便说，计费规则和参数说明整理得比较全的文档，可以在[万象云档](https://www.wanxiangyundang.top/)按主题翻，比零散搜新闻省事。 价格表比参数表更值得存下来。理由很实际：参数看过就忘，价格每次报价都要用。 看价格表要看三样：输入输出是否分开计价、缓存是否打折、以及有没有阶梯价。三样都写清的产品，通常做得比较成熟。 还有一个细节：贵的那档往往不是最贵的，超长上下文才是。一份十万字的材料，一次可能抵一百次普通对话。 ## 五、三条判断比通稿有用 第一，这次发布是"新能力"还是"降价"。降价类发布对使用者最实在，能力类要看后续两周的真实口碑。 第二，有没有开源权重或者 API 兼容。有兼容，迁移成本才低，不然又要重写一遍调用层。 第三，发布方敢不敢放基准测试的原始题目。只放分数不放题，可信度直接打对折。 三条判断我一般这么写：这东西解决哪一步、这一步原来谁在做、换过去要付什么代价。 第三步最容易被忽略。换工具往往要改流程、改权限、改验收标准，发布会只讲产品，不讲这一层。 所以看新闻时我会在备忘录里留一行「能不能用我现在的流程接住」。接不住，它就是谈资，不是工具。 ## 六、看行业新闻的顺序 我一般倒着读：先看价格和限制说明，再看技术博客，最后才看通稿。 通稿负责告诉你"有这么个东西"，技术部分负责告诉你"它到底行不行"。顺序反过来，容易被带着走。 留一句：读发布会的正确姿势，是把"重磅"两个字划掉，再读一遍。 补一句关于「发布会」这件事的判断：真正的信息量，往往不在台上讲什么，而在问答环节被追问时怎么答。 答得含糊的地方，通常就是没做好的地方。答得干脆的地方，是他们的主场。 所以我一般会留十分钟看问答。十分钟能省掉两小时的试错。 看行业新闻的顺序，我建议倒着看：先看后面的限制条款，再看中间的演示，最后才看开头的结论。 倒着看的好处是，你先知道它的边界，再看它的能力，就不会被演示带跑。 顺序反过来最容易被牵着走。先看结论，你会不自觉地替它找证据，这是人的本能。