把一个人砍掉一半，他先忘的不会是"怎么开会"，而是"对面那位同事叫什么"。剪枝的退化顺序也是这个理。
先说一条原帖没有的边界：这篇的 arXiv 页面挂着投稿备注——Submitted to EACL Industry Track。原帖写的是"发布时间 2026-09-15"，没提投稿状态。投稿和录用是两件事，引用时得带上这一笔。
实验台账先对一遍：4 个 LLM，三类架构（稠密 Transformer、稠密混合、MoE），四种剪枝方式（深度、宽度、混合、专家），三个智能家居数据集，超过 19,500 个实例，全部在剪枝后做 SFT 再评。规模不算小。
退化顺序是这篇最值钱的一条：先坏的是"接地具体性"（grounded specificity），后坏的是"模式级别的意图"（schema-level intent）。原文用 grounded 这个词是有意的，工具调用本来就是上下文接地的活。说人话：模型先忘的是"这个设备叫什么、这个参数该填什么"，而不是"这一整套流程要干什么"。【推论】这意味着，你在总体准确率上看到的轻微下滑，底下可能已经积了一批"设备名对不上号"的错误。
另一条更阴：激进稠密剪枝会诱发系统性过度拒绝。模型不是变得不会做，而是变成什么都不肯做。这条对线上系统最危险的地方在于，拒绝看起来像安全行为。日志里一片"模型拒绝执行"，很容易被读成防护生效了，实际是能力没了。
退化的第二个维度是任务复杂度，评测也按这个切了一刀。这种切法在端侧选型时比总准确率有用：如果你的场景是长链多步，看平均分会被大量短任务拉高。
下一根钉子：原帖说要"超越总体准确率去评估"。具体怎么超？我建议盯一个数——同一模型在"参数值"这一栏上的错误率。它是最早塌的那格，也是最终用户最先感觉到的那格，该开灯的开错了灯。这条曲线如果在某个剪枝比例上出现拐点，那个比例就是安全线的位置。