arXiv 每日速递 2026-06-02

今日总结

今天这批论文（5 月 29 日放出）里，跟我们主线咬合最紧的三篇看似分属不同子领域——一篇做开源代码模型的 API 知识边界（cs.SE），一篇做 on-policy distillation 的训练效率，一篇做 gradient-free 后训练——但它们共享同一个反直觉的研究姿势：先假设那个最贵的动作不必要，再用实验去证明它真的可以砍掉。 PowerCodeBench 砍掉的是 fine-tuning（用 41% 的 token 做定向文档注入就追平全上下文天花板）；TOPD 砍掉的是 full rollout（只用 10% 的 rollout horizon 就追平完整 OPD）；CoRP 砍掉的是 K 次前向 + 梯度回传（gradient-free 把一群 rewarded 扰动折叠进一个模型）。这正是我们"边际价值量化"哲学的镜像版本：与其问"加上这个动作能涨多少"，不如反过来问"减掉这个动作会掉多少"——而今天三篇的答案都是"掉得比想象中少得多"。对预算受限、靠开源 7B–14B 打天下的我们，这是一份难得对胃口的清单。

今日全览

论文	方向	核心贡献	与我们的相关度
Knowledge Boundary Probing for Power System Code Generation	LLM4Code / API 演化 / benchmark	把开源代码模型的首遍失败归因为 API 知识边界错误，用定向文档注入（非 fine-tuning）把 10 个开源模型全部提升 32–56 分	⭐⭐⭐
Are Full Rollouts Necessary for On-Policy Distillation?	蒸馏 / 小模型 / 训练效率	指出 rollout horizon 是 OPD 的真正瓶颈，TOPD 用 10% horizon 追平完整 OPD，POPD 提速 3×	⭐⭐
Consolidating Rewarded Perturbations (CoRP)	后训练 / gradient-free / 小模型	把一群 reward 加权的高斯扰动 gradient-free 折叠成单个可部署模型，0.5B–8B 平均涨 8.1 分，推理只需 1 次前向	⭐⭐

今日主题：把"必要性"反过来问——昂贵动作的边际价值审计

我们实验室的方法论核心是"边际价值量化"：当 LLM 已经 work，去精确测量每个设计动作的真实贡献，常常得出反直觉结论（比如我们之前测出 test execution 在某个 repair pipeline 里只贡献 1.25pp）。今天这三篇论文，本质上是同一种思维的不同投影——只不过它们把审计的对象从"agent 工作流的设计动作"换成了"训练/推理流水线里那个最贵的步骤"。

有意思的是三篇的统一句式："X 真的必要吗？" [48] 问的是"要让开源模型写对专业库的代码，真的需要 fine-tuning 吗"，答案是——不需要，首遍失败大多不是推理能力不够，而是 API 知识边界错误（幻觉函数名、参数误用、结果表误读），用定向文档注入就能补上。[43] 问的是"on-policy distillation 真的需要跑完整条 rollout 吗"，答案是——不需要，rollout horizon 才是瓶颈，截断到 10% 几乎不掉点。[41] 问的是"把一群 rewarded specialist 集成起来真的需要 K 次前向、需要梯度回传吗"，答案是——不需要，那群扰动里藏着低秩结构，gradient-free 折叠就够了。

把这三个"不需要"摆在一起，浮现出一个对资源受限研究者极其友好的趋势判断：2026 年的开源/小模型增益，越来越多来自"砍掉冗余的昂贵步骤"而非"叠加更多算力"。 这跟过去两年"scale up 一切"的叙事正好相反，也正好是我们这种没有商业 API 预算、靠静态分析+小模型打链条的团队能切入的缝隙。下面逐篇拆，重点不在它们的 SOTA 数字，而在它们的"砍法"能不能搬到我们的 repair / migration / OpenHarmony 工具链里。

---

Knowledge Boundary Probing and Demand-Guided Intervention for LLM-Based Power System Code Generation

推荐理由：这篇几乎是为我们"小/本地 LLM for Code + compatibility migration + benchmark 方法论"三条线量身定做的——它把"开源模型为什么写不对版本化库的代码"拆成可测量的 API 知识边界，并证明不靠 fine-tuning、只靠定向文档注入就能补齐。这正是我们做 Python 版本演化修复、ArkTS 项目级修复时反复撞到的同一堵墙。

📌 论文信息：Hui Wu, Xiaoyang Wang, Zhong Fan | arXiv:2605.31478 | cs.SE, cs.CL, eess.SY

⚠️ 配图说明：本文 ar5iv HTML 页面尚未渲染（重定向至 abs 页），故本期暂无配图。

TL;DR

开源代码模型在专业库（pandapower 电力仿真）上的首遍失败，主因不是"不会推理"，而是"不知道这个版本的 API 长什么样"——幻觉函数名、参数用错、结果表读错。作者把这个失败归因为可量化的 API 知识边界，再用一套"按需文档注入"的轻量干预，在不 fine-tune、不上云的前提下，把 10 个开源模型（≥7B）和 4 个商业中端 API 全部提升 32–56 个准确率点，而 prompt token 只花了全上下文方案的 41%。

问题是什么？

很多电力公司、能源实验室出于保密、合规、可复现、成本的考量，必须本地部署开源模型——这跟我们"7B–14B 开源模型能否替代商业 API"的核心问题是同一个约束。但本地部署立刻暴露一个老问题：模型在 versioned simulation library 上首遍就写错。

关键在于，过去大家习惯把代码生成失败笼统归因为"推理能力不足"，于是要么换更大模型、要么砸数据 fine-tune。这篇论文做了一件我们很欣赏的事——先把失败解剖开：它发现首遍失败由"结构化的 API 知识边界错误"主导，具体三类：(1) 幻觉出根本不存在的函数名；(2) 函数存在但参数用错；(3) 仿真结果表（result tables）的字段读错。这三类都不是"逻辑不会"，而是"这个版本的 API 我没记准"。用一个类比：模型像一个算法很强但手边没有最新 API 文档的工程师——它知道要做什么，但把 runpp() 的返回字段名写成了上个大版本的样子。这恰恰是 dependency/API 演化场景的典型病灶，跟我们做 whole-repository compatibility repair 撞的是同一堵墙。

他们怎么做的？

核心 Insight：把"代码生成可靠性"从一个模糊的能力问题，重构成一个可测量、可定点补给的知识边界问题——既然失败是"缺这个版本的 API 知识"，那就精确地、只在缺的地方把文档喂进去。

具体三件套：

1. PowerCodeBench——execution-validated benchmark generator：把自然语言运维查询配上 pandapower 代码和数值 ground truth，且是执行校验过的（不是 LLM 打分），冻结成 2000 题。这点对我们尤其重要——它不是又一个静态 pass@1 测试集，而是带数值真值、可执行验证的生成器，天然适合做版本/库演化的对照实验。
2. L0–L3 文档驱动的探针程序：分层测量每个模型的"per-model API knowledge profile"——即这个模型对某个库的哪些 API 知道、哪些不知道、知道到什么程度（L0 到 L3 四级）。这是把"知识边界"真正量化出来的关键步骤，而不是停留在定性描述。
3. Boundary-aware intervention（按需干预）：在 query 侧先做 API demand estimation（这道题需要用到哪些 API），再做 targeted proactive documentation injection（只把这些 API 的文档主动注入），配合 routed reactive correction（执行报错后定向纠正）。注意"targeted/按需"是精髓——不是把整本文档塞进上下文。

跟之前方法的本质区别：主流做法要么 fine-tune（贵、要数据、要算力），要么把全文档塞进上下文（token 爆炸）。这篇是"先探针测出知识缺口，再按需定点补给"——它把职责切得很干净：用结构化探针负责"诊断缺什么"，用文档注入负责"补什么"，模型本身一动不动。这种"诊断与修复职责分离"的哲学，跟我们"static analysis 做定位、LLM 只负责修复"的切分思路是同构的。

关键结果

设置	评估对象	干预效果	备注
Boundary-aware intervention	10 个开源模型（≥7B）+ 4 个商业中端 API	每个模型 +32 ~ +56 准确率点	全员受益，无一例外
模型规模对照	70B–120B 开源 vs 商业中端 API	追平商业中端区间	开源在合适干预下可替代
领跑	Llama-3.1-405B / Qwen3-Coder-480B	面板最强	但中端开源已够用
Token 成本	targeted prompt vs 全上下文	仅用 41% token，保住全上下文准确率天花板	关键的成本-效果证据

结果解读：

• 提升幅度（32–56 分）大得有点惊人，但这恰恰反证了"首遍失败主因是知识边界而非推理"这个论点——如果失败真的来自推理能力，光注入文档不可能涨这么多。这是一个很漂亮的"归因正确性"的间接证明。
• 最值得我们抄的是 41% token 这条线：它说明"全文档塞进去"里有近 60% 是浪费的，按需注入既省钱又不掉天花板。对 local inference、上下文受限的小模型部署，这是直接可用的省钱杠杆。
• 一个隐含的强信号：70B–120B 开源 + 定向干预 = 商业中端 API。这对"开源能否替代商业 API"是一个偏乐观的实证答案，但要注意它的边界条件（见下）。

局限性与开放问题

• 局限 1：单库、单领域。 整个结论建立在 pandapower 一个电力仿真库上。API 知识边界的"可探针性"很可能依赖该库文档质量高、API 命名规整。换到文档稀疏、API 命名混乱的库（比如很多新生生态的库），L0–L3 探针还能不能稳定测出 profile，是个大问号。这正好是我们 OpenHarmony / Cangjie 低资源生态会撞到的——新生语言根本没有成熟文档可注入。
• 局限 2：首遍失败 ≠ 全部失败。 论文聚焦"first-pass failures"，但真实修复往往是多轮的。截断到首遍可能高估了"知识边界"的占比——多轮交互里推理类失败的比重可能上升。
• 开放问题：知识边界探针测的是"模型知不知道某 API"，但没区分"不知道"和"知道但被相近 API 干扰"。后者（API 混淆）在版本演化场景里其实更普遍、更难治——文档注入对"纯不知道"有效，对"记成了旧版本"未必有效。

💡 对我们的启发

1. 直接可用的技术点：我们做 Python 版本演化修复时，可以把"按需文档注入"这套搬过来替代部分 retrieval。具体地，把他们的 API demand estimation → targeted documentation injection 用在我们 repair pipeline 的"补给"步骤上：在让小模型生成 patch 前，先用静态分析估出这段代码要触碰哪些演化过的 API，只注入这些 API 的新版签名/文档，而不是把整个 changelog 喂进去。这跟我们"static 定位 + LLM 修复"的切分天然契合。
2. 具体实验想法（1–2 周可验证）：取我们现有的 compatibility repair benchmark，固定一个 7B 开源模型，对比三种上下文策略——(a) 无文档、(b) 全 changelog 注入、(c) 按需 API 文档注入。输入是带版本冲突的 repo + 失败的测试，做的是测量三种策略下的 pass@1 和平均 prompt token；预期观察到的是 (c) 在 token 上远低于 (b)、pass@1 接近甚至追平 (b)——如果复现出"41% token 保住天花板"这条线，我们就拿到了一个对小模型修复非常实用的省钱配方。同时可以顺手做我们最擅长的边际价值量化：把"文档注入"这个单一动作的贡献从 pipeline 里单独切出来测。
3. 研究趋势判断：这篇代表了一个对我们极其有利的方向——用"知识探针 + 定向供给"替代 fine-tuning。它把代码模型的可靠性问题从"训练侧"拉回到了"推理侧的上下文工程"，而推理侧正是我们这种没有大规模训练算力的团队能精耕的战场。更进一步，"per-model API knowledge profile"这个概念本身就是一个可发表的工具——如果我们能为 ArkTS / Cangjie 这类新生生态建一套 API 知识边界探针，那既是 benchmark 又是 dataset，正好符合"产出真能被用上的东西"的实验室哲学。

---

Are Full Rollouts Necessary for On-Policy Distillation?

推荐理由：标题就是边际价值量化的口吻。它精确地把 OPD 里"rollout horizon"这一个变量单拎出来审计，证明完整 rollout 是冗余的——这对我们想用蒸馏把小代码模型练起来、又被算力卡脖子的场景，是直接的成本配方。

📌 论文信息：Yaocheng Zhang, Jiajun Chai, Songjun Tu, Yuqian Fu, Xiaohan Wang | arXiv:2605.31490 | cs.CL

⚠️ 配图说明：本文 ar5iv HTML 页面尚未渲染（重定向至 abs 页），故本期暂无配图。

TL;DR

On-policy distillation（OPD）默认要让学生跑完整条 rollout 再让老师沿途打分，既贵、又会在训练早期把学生暴露给"rollout 后段不可靠的老师反馈"。作者指出 rollout horizon 才是真正的瓶颈，并给出两个极简策略：POPD（渐进扩展 horizon）把训练效率提升最多 3×；TOPD（永久截断到可靠前段）只用 10% 的 rollout horizon 就追平完整 OPD，同时大幅省 wall-clock 和显存。

问题是什么？

OPD 是当下长程推理后训练的热门范式：让学生模型自己生成 rollout（on-policy），老师沿着这条学生轨迹逐 token 给 dense 反馈。它比 RLVR（只有最终答案 reward）信号密、比 off-policy 蒸馏更贴合学生分布。

但它有两个被忽视的代价。其一，生成完整 rollout 本身就贵——长程推理动辄几千 token，每步都要学生生成+老师前向。其二，更微妙的一点：在训练早期，学生还很菜，它跑出来的 rollout 后段往往已经偏到离谱的状态，老师在这种"已经崩坏"的轨迹后段给的反馈是不可靠的——你在教学生如何从一个根本不该到达的状态里继续走，这等于在喂噪声。用类比说：让一个刚学下棋的人走到第 40 手已经是必败残局，再请大师逐手点评后面 20 手，这 20 手的点评对初学者几乎没有学习价值，还浪费大师的时间。

他们怎么做的？

核心 Insight：OPD 和 RLVR 有一个本质区别——RLVR 需要完整轨迹和最终 reward 才能给信号，而 OPD 的 dense 反馈不需要走到终点就能产生学习信号。既然每一步都有监督，那"走多远"就成了一个可以自由调节的旋钮，而不是必须拉满的常量。

两个策略：

1. POPD（Progressive OPD）：训练早期用短 horizon，随训练推进逐步放长。背后的道理是——早期学生菜，短 rollout 既省算力又避开"后段崩坏轨迹"的不可靠反馈；后期学生强了，再放长去学长程依赖。这是一种"课程式"的 horizon 调度。
2. TOPD（Truncated OPD）：更激进——永久只在"可靠的截断前段"上做蒸馏，根本不跑完整 rollout。赌的是前段的 dense 反馈已经足够。

跟之前方法的本质区别：标准 OPD 把"跑完整条 rollout"当成不可动摇的前提。这篇的贡献不是发明新损失，而是识别出 horizon 是一个被默认拉满、其实可以大砍的设计变量——这是典型的"审计既有 pipeline 里冗余动作"的工作，跟我们 test execution 边际价值那篇的精神完全一致。

关键结果

策略	关键指标	效果	对照
POPD（渐进 horizon）	训练效率	最高 3× 提速	vs 标准 OPD
TOPD（截断 horizon）	性能	追平完整 OPD	仅用 10% rollout horizon
TOPD	wall-clock / 显存	大幅下降	由 horizon 缩短直接带来

（实验在数学推理任务上。）

结果解读：

• "10% horizon 追平 100% horizon"这条线信息量极大——它意味着完整 rollout 里约 90% 的后段长度对 OPD 学习是近乎冗余甚至有害的（早期不可靠反馈）。这跟 [48] 的"41% token 保住天花板"是同一类发现：贵的那部分里大半是浪费。
• 提升主要来自两处叠加：省掉后段生成的算力 + 避开后段噪声反馈带来的质量收益。论文把"效率"和"质量"统一到 horizon 这一个旋钮上，是它优雅的地方。
• 需要警惕的是，结论目前限于数学推理——这类任务的错误往往"早段就定型"，截断前段恰好抓住了关键监督。

局限性与开放问题

• 局限 1：任务类型偏窄。 只在数学推理上验证。代码生成（尤其是 repo-level、长程多文件编辑）的错误未必集中在前段——一个 patch 的致命错误可能出现在很靠后的某次文件写入。截断前段在代码场景能不能成立，完全未验证，而这正是我们关心的场景。
• 局限 2：截断点怎么定没说透。 "可靠的截断前段"到底截在哪、用什么信号判断"后段开始不可靠"，是个关键超参。如果截断点本身需要精调，那省下的算力可能被调参吃掉。
• 开放问题：POPD 的渐进调度曲线（什么时候放长、放多长）显然影响很大，但论文给的更像存在性证明而非最优调度。"horizon 调度"本身可以是一个独立的小研究。

💡 对我们的启发

1. 直接可用的技术点：如果我们要蒸馏一个小代码模型（比如把某个强教师在 program repair 上的能力蒸到 7B），TOPD 的"截断 rollout"思路可以直接降我们的蒸馏成本。但要先回答一个我们独有的问题：代码 repair 的错误分布是不是前段集中？ 如果不是，就需要改成"按结构截断"而非"按长度截断"——比如截到第一个完整 patch 边界，而不是固定 token 数。
2. 具体实验想法（1–2 周可验证）：拿一个长程 repair / 多步编辑任务，做一个 horizon 消融——把 OPD 的 rollout 分别截断到 10% / 30% / 50% / 100%，输入是同一批 repair 轨迹，测每个截断比例下蒸馏出的学生 pass@1 与训练 wall-clock。预期观察到的是：数学推理里漂亮的"10% 追平 100%"在代码上很可能不成立或临界点更靠后——而这个"代码 vs 推理的截断曲线差异"本身就是一篇有价值的、符合我们方法论的小实证（边际价值随任务类型变化）。
3. 研究趋势判断：这篇和 [48] 一起，指向"后训练/推理的成本，越来越多由一个被默认拉满的旋钮决定"——horizon、context 长度、ensemble 次数。识别并审计这些旋钮，是低算力团队最高杠杆的研究动作。我们完全可以把"边际价值量化"从 agent 工作流扩展到"训练 pipeline 的旋钮审计"，开辟第二战场。

---

Consolidating Rewarded Perturbations for LLM Post-Training (CoRP)

推荐理由：又一篇"砍掉昂贵动作"的工作，且直接覆盖 0.5B–8B 小模型 + code 任务。它把 RandOpt 那种"推理时集成 K 个 specialist"压成"单模型单次前向"，gradient-free，对没有大显存做 RL 的我们是很现实的后训练路径。

📌 论文信息：Zheyu Zhang, Shuo Yang, Gjergji Kasneci | arXiv:2605.31494 | cs.CL, cs.LG

⚠️ 配图说明：本文 ar5iv HTML 页面尚未渲染（重定向至 abs 页），故本期暂无配图。

TL;DR

RandOpt 这类方法在权重空间采样高斯扰动、把 reward 最高的 top-K specialist 在推理时集成，效果能跟 PPO/GRPO 打平，但代价是每个测试样本要 K 次前向，且难扩展到自由生成。CoRP 提出一个 gradient-free 算子，把这群 rewarded 扰动折叠进单个可部署模型——reward 加权聚合 + 兼容性重加权 + held-out 验证门控。5 个模型（0.5B–8B）、5 个任务（数学/代码/创意写作）上平均比 base 涨 8.1 分；只用 RandOpt 1/10 的扰动预算，就比单次推理的 RandOpt 高 6.5 分，且推理只要 1 次前向。

问题是什么？

后训练通常是"采样-打分-梯度更新"的循环。RandOpt 这条新线把循环搬到了权重空间：在预训练模型周围撒高斯扰动，挑 reward 最高的几个"专家"在推理时集成。它的吸引力在于 gradient-free——不用反向传播，对显存友好，这对我们这种本地小卡环境很有意义。

但它有两个硬伤：其一，推理时要跑 K 个模型再集成，K 次前向的开销在部署时不可接受；其二，这种 prediction-level 集成不能干净地扩展到自由生成（free-form generation）——你没法简单地对一段生成文本做 token 级投票。换句话说，RandOpt 用"推理时变贵"换来了"训练时变省"，而这笔交换在真实部署里往往不划算。

他们怎么做的？

核心 Insight：那群 reward 高的扰动并不是各自为政的孤立专家——作者通过 split-half analysis 在全部 25 个 model-task 组合上发现了可复现的低秩结构。既然这群扰动主要活在一个低维子空间里，就不必在推理时维持 K 个模型，而可以把它们折叠（consolidate）成一次权重更新。

具体三步：

1. Reward-weighted aggregation：按 reward 给每个扰动加权，聚合成一个候选更新方向——reward 高的扰动贡献大。
2. Compatibility-aware reweighting：不是简单平均，而是考虑扰动之间的"兼容性"再加权，避免互相打架的扰动相互抵消。这是它比朴素 model averaging 更细的地方。
3. Held-out validation gate：用留出集做门控，只接受真正能涨分的折叠更新——一道防止过拟合 reward 的闸。

全程没有梯度流过语言模型，所以保留了 RandOpt gradient-free 的好处，却把推理成本从 K 次前向压回 1 次。

跟之前方法的本质区别：RandOpt 是"训练 gradient-free，但推理 K 次前向"；CoRP 是"训练仍 gradient-free，推理 1 次前向"。它没有否定 RandOpt 的权重空间探索，而是把'集成'这个昂贵动作从推理时挪到了训练时的一次性折叠——又一个"砍掉推理时冗余"的范本。

关键结果

对照	指标	CoRP	对手	差距
vs base 模型（5 模型 × 5 任务平均）	任务分数	base + 8.1	base	+8.1
vs 单次推理 RandOpt	任务分数	—	—	+6.5（且只用 1/10 扰动预算）
vs 50-pass majority-vote 集成	增益回收	回收 >50%	50× 前向集成	CoRP 仅 1× 前向
推理成本	每样本前向次数	1	RandOpt K 次	K→1

（模型规模 0.5B–8B；任务覆盖 math / code / creative writing。）

结果解读：

• 最关键的一行是"1/10 扰动预算 + 1 次前向，反超单次 RandOpt 6.5 分"——这说明 RandOpt 的扰动群里存在大量冗余采样，低秩结构一旦被利用，预算可以砍一个数量级。又是"贵的部分大半是浪费"的同一母题。
• "回收 50-pass majority-vote 一半以上增益，却只用 1 次前向"是一个很务实的性价比点：majority-vote 那 50× 的推理开销在部署里几乎不可行，CoRP 用单次前向拿回一半，对小模型本地部署是实打实的可落地方案。
• 跨 0.5B–8B 都成立，说明低秩结构不是大模型专属——这对我们用 0.5B–1.5B 做边缘/本地代码补全的设想是个利好信号。

局限性与开放问题

• 局限 1：8.1 分是 5 任务平均，code 单项不明。 数学、创意写作和代码的 reward 信号性质差别很大（代码可执行验证、创意写作主观）。平均涨 8.1 分，code 子任务到底涨多少、低秩结构在 code 上是否同样干净，需要单看——这恰是我们最该追问的一项。
• 局限 2：依赖一个好 reward。 整个 pipeline 建立在"扰动能被 reward 正确排序"之上。对 code 而言 reward 相对客观（测试通过率），但对需要 process quality 的修复任务，outcome reward 可能误导折叠方向——这跟我们一贯关心的"process quality vs outcome correctness"是同一个坑。
• 开放问题：低秩结构"为什么"存在、它的秩跟任务/模型规模的关系，论文是经验观察而非机制解释。如果能把"rewarded 扰动的有效秩"和"任务可压缩性"联系起来，这会是一个更深的、可发表的方向。

💡 对我们的启发

1. 直接可用的技术点：CoRP 给了我们一条不需要 RL 框架、不需要大显存反传的小代码模型后训练路径。我们可以在一个 7B 代码模型上，用"撒扰动 + 测试通过率当 reward + CoRP 折叠"来做轻量后训练，全程 gradient-free，单卡可跑。这比搭一套 GRPO/PPO 的工程成本低得多，符合我们"ship 速度优先"的取向。
2. 具体实验想法（1–2 周可验证）：在一个小 repair 数据集上，对 7B 代码模型撒 N 个高斯扰动，用"补丁是否通过测试"作为 reward，对比三种聚合——(a) 朴素 top-K averaging、(b) CoRP 的兼容性加权折叠、(c) 单纯 base。输入是失败的 repair 任务，测 pass@1 与推理前向次数。预期观察到的是 CoRP 折叠在保持 1 次前向的同时显著超过朴素 averaging——如果在 code 上也复现出低秩结构，我们就能写一篇"gradient-free 后训练用于程序修复"的实用小论文，且天然带 dataset/tool 产出。
3. 研究趋势判断：CoRP、TOPD、PowerCodeBench 三篇合起来，指向一个对我们极其友好的元趋势——2026 年小模型的竞争力，越来越取决于"如何在不加算力的前提下榨干现有结构"（低秩扰动、可截断 horizon、按需文档），而非'谁的卡多'。 这正是资源受限团队能弯道超车的窗口。我们应该有意识地把"砍掉某个默认昂贵动作并量化掉点"做成一个系列性的研究母题——它既是方法论（边际价值量化），又持续产出能被工业界直接用上的省钱配方。

---

方法对比

维度	PowerCodeBench [48]	TOPD/POPD [43]	CoRP [41]
被审计的"昂贵动作"	fine-tuning / 全文档注入	full rollout（完整 horizon）	推理时 K 次前向集成 + 梯度回传
砍掉它的方法	按需 API 文档定向注入	截断 / 渐进 horizon	gradient-free 低秩折叠成单模型
砍掉后掉了多少	几乎不掉（保住全上下文天花板）	几乎不掉（10% horizon 追平）	不掉反涨（vs 单次 RandOpt +6.5）
省下来的是什么	59% prompt token + 整个训练流程	90% rollout 长度 + wall-clock/显存	K→1 次前向 + 反传
模型规模覆盖	1.5B–480B（开源）+ 商业中端	中等规模推理模型	0.5B–8B
对我们的最大价值	版本演化修复的省 token 配方 + 新生态 API 探针	蒸馏小代码模型的截断成本配方	无需 RL 框架的小模型后训练路径
主要局限	单库验证、依赖好文档（新生态没有）	仅数学推理、截断点未给定	code 单项不明、依赖好 reward

把这张表竖着读，会发现三篇是同一个研究范式的三个实例：找到 pipeline 里一个被默认拉满的昂贵旋钮 → 假设它冗余 → 用实验量化"砍掉它会掉多少" → 答案都是"掉得比想象中少"。 这就是我们"边际价值量化"哲学的对偶形式。对一个没有商业 API 预算、靠开源小模型 + 静态分析打链条的团队，这三篇与其说是三个孤立的技术点，不如说是一份共同的方法论邀请函：别只问"加什么能涨分"，多问"减什么不掉分"——后者往往是低算力团队唯一能领先的赛道。