这周外部没什么直接讨论微调与提示选择的文章，但 ExtractBench 和 Handbook.md 两篇论文恰好把这条线的两端都占了：一个展示提示工程还有多少空间，一个画出提示工程的边界。我的判断还是那个：大多数团队离微调的距离，比他们以为的远。
ExtractBench 这类任务，离提示天花板还远
ExtractBench 是给「schema-guided extraction」做的评测：给 agent 一份文档和一个用户定义好的 schema，让它按 schema 输出，还要带来源证据。企业文档抽取，格式固定、规则明确，听起来是最该微调的场景——schema 都写死了，把规则烧进权重不好吗？
问题在这：ExtractBench 的出发点，是这类任务当前的表现还不可靠，所以需要先建评测去测。如果任务已经「微调化」，正确动作是直接发训练集和微调基线，而不是先造一个基准跑一堆模型。它造了评测，说明领域里缺的还不是权重，是「怎么把任务描述清楚」。
我不信一个 schema 抽取任务需要微调才能稳。我见过不少团队，文档解析做不好，第一反应是微调。追问下去，多数是 prompt 里没定义「字段缺失时怎么办」，或者示例集全是正常 case、没有反例。这些在提示层能解决，而且比微调快得多。
长文档是提示工程的真实边界
Handbook.md 这篇说得很直接：长政策文档不能可靠地约束 agents。给 agent 塞几百页 policy，期待它每条都遵守，这个期望本身不成立。这周 HuggingFace 那个入侵事件时间线也在侧面印证——出事的 agent 不是不懂规则，是长指令里的优先级和例外条款在特定上下文里互相打架。
但注意边界在哪：这是「指令太长」的边界，不是「任务格式复杂」的边界。把两者混为一谈，就很容易给自己找到微调的理由。事实是，极少数任务需要一次读物超过模型的有效注意力窗口；绝大多数任务是作者把要求写得含糊。
微调真正划算的场景，我数不出几个
按我现在看，值得微调的任务要同时满足三条：输出格式极其固定、调用量大到用长提示不经济、需要把模型尺寸压下来。企业文档抽取是个例证——如果 schema 稳定、标注数据足够、还要部署到客户内网的端侧小模型上，微调是对的。
这三条同时成立的场景，比我遇到过的想微调的团队数量少得多。大部分想微调的人，其实只是想要一个更稳的输出格式。那你应该先做的是写几个 few-shot 示例、把 json schema 塞进 system prompt，再在评测集上跑两周。两周后输出还是碎，再谈别的。
微调锁死版本这笔账，比想象的大
反面观点我得认：微调把模型版本锁死了。厂商发新模型，你的微调管线要重跑一遍——数据清洗、训练、评测、回归，全是成本。提示工程没有这个负债，新模型出来，把 prompt 搬过去，修几处措辞，验证一遍就完事。
所以我给微调加了一个隐含前提：任务定义在接下来半年内不会变。真实世界的任务，定义稳定到这种程度的，不多。schema 变、输出字段变、业务规则变，任何一个变，微调的收益就归零，而提示工程只需要改两行字。
判断标准：同一批评测集调不动再说
说个具体做法。挑几十个有代表性的 case，覆盖正常路径、边界输入、故意写坏的反例。每周改 prompt、补示例、换结构，跑一遍。等到连续两轮一点提升都没有——这时候才有资格谈微调。
这就是那条线。不是「模型不够聪明」，不是「prompt 写累了」，是实测的、可重复的「调不动」。多数团队卡在最前面：评测集没建，或者建了但全是 happy path，提示的问题根本暴露不出来。先解决这个，再谈要不要动权重。