不要把参数规模误写成能力终局

模型卡片上的参数量很好写进标题。把更大写成更强，则是偷懒。能力并没有随着稠密层数一起自动到站，它取决于任务、工具和上下文有没有被用上。一种规模的扩张，常常只是把旧瓶颈挪到显存和延迟上。

这不是反对更大的模型。更大的模型在知识覆盖和指令遵循上仍然有统计优势。需要反对的，是一种写作习惯：只报参数，不报它在哪一类工作里开始稳定地省时间，在哪一类工作里仍然需要人托底。读者被训练成只问“多大”，不问“少返工了几次”。

参数是一种镜头

镜头对准千亿参数，画面就有了结论。可是同一套权重，接上检索和代码解释器之后，表现会换一张表。客服工单、合同比对、内部 wiki 问答，比公开榜更能暴露掉质量的位置。如果只读参数，会把套壳当成突破。

实验室内部其实早就这么做了。对外稿件却仍在比谁的数字更整。一个常见的错位是：研究团队用内部脏任务决定是否发版，市场稿却把发版写成参数胜利。两种真实同时存在，被写成了一种。

镜头还会造成采购误判。预算委员会更容易批准“上更大的模型”，而不是批准“把工具轨迹和权限模型补齐”。于是钱花在了更贵的推理上，失败却出在检索和流程。

真实任务比榜单更诚实

把失败案例按任务类型画出来，能力的边界才出现。一个模型也许能写流畅的总结，却在“根据表格计算并引用单元格”时持续编造。另一个模型在闲聊里显得笨拙，却能稳定地调用内部工单接口。这两种能力无法被同一个参数数字概括。

更麻烦的是分布外任务。榜单题目被做满之后，分数会走平；工位上的新表格、新规则、新的拒答策略，仍能分出高下。走平不是竞争结束，是旧镜头该换了。

一家做对账助手的团队曾经把旗舰模型换到开源中等规模，总结文采下降，但“金额与发票不一致”的检出率上升。他们没有对外宣布变强，只是把评测从流畅度改成了差错数。这才是终局不该被参数宣布的理由。

工具把能力重新分配

检索、代码执行、浏览器和内部 API，会改写“模型本身”的排位。一个中等规模的开源模型，配上干净的工具轨迹，常常能在垂直场景里打过只会聊天的更大模型。这时再把参数当终局，等于无视整条流水线。

代价是治理变难。工具一多，权限、审计和失败回滚都要重新设计。能力上涨和应用变脆，往往是同一件事的两面。谁把工具接得越深，谁就越需要把“模型说了什么”和“系统做了什么”分开记账。

评测栏不该提前宣布终局

下一代模型仍会涨参数，也会涨上下文。评论不该替用户提前宣布已经够用，或已经无用。该写进版面的，是它在哪一类工作里开始稳定地省时间，以及省下的时间有没有被复查成本吃回去。

参数还会被写进标题，这很正常。只要正文里同时出现任务、工具和失败案例，读者才不会把镜头误认成地形。终局如果存在，也不会写在模型卡片第一行。