评测驱动的刻意练习

最近在复盘 AI Coding 的 Prompt 质量，过程中发现一个问题：我一开始很容易把结论推得太满。

比如看到一些低分 Prompt，就下意识觉得应该统一改成结构化模板：目标、上下文、范围、不做、验收、验证、审批门。这个方向不能说错，尤其是代码修改、发布、同步、删除这类任务，结构化确实能减少跑偏。

但后来继续练的时候才发现，事情没这么简单。现在模型能力已经很强，有些低风险任务，一句话就够了。比如：

把目前组件库支持的主题列出来，包含英文标记和中文说明。

这个 Prompt 如果硬改成八行合同，反而有点过度设计。真正应该练的不是“每个 Prompt 都写复杂”，而是先判断它属于哪一类：一句话就够、轻结构、还是必须写成完整合同。

这个小纠正让我意识到，最近这套训练方式不只是 AI Coding 的方法。它更像一种通用学习方法。

我暂时把它叫做：评测驱动的刻意练习，英文可以叫 Eval-Driven Learning Loop。

这套方法到底在做什么

如果拆开看，它大概是这样一个流程：

真实任务
→ 明确评分标准
→ 自己先做
→ 外部评测
→ 找到最弱点
→ 只练一个小环节
→ 换场景迁移
→ 沉淀成规则或模板

这里最关键的不是“评测”，而是评测之后只打一个点。

很多学习的问题，是反馈太模糊。比如学英语的时候，只知道“我口语不好”“我写作不行”；做 AI Coding 的时候，只知道“这个任务跑偏了”“这次 Agent 做得一般”。这些反馈都太大了，大到没有办法直接训练。

评测的作用，是把一个模糊问题切成几个可以动手改的小问题。

英语写作可以切成：立场、逻辑、展开、语法、词汇、句式。

AI Coding 可以切成：任务建模、上下文、约束与验收、验证、交互效率、复用沉淀、风险治理。

一旦切开之后，训练就变得具体了。今天不是“提升英语”，而是只练一个让理由展开更完整的段落。今天也不是“提升 AI Coding”，而是只练判断 Prompt 应该用哪一档结构。

这个差别很大。

为什么它比泛泛学习有效

我之前学英语时，比较有感觉的阶段，基本都不是“看了很多资料”的阶段，而是有稳定反馈的阶段。

比如写完一段，马上按 TOEFL 标准看问题。问题不是简单地说“写得不好”，而是告诉我：这个观点能看懂，但展开不够；这个句子语法问题不大，但逻辑连接弱；这个表达可以用，但不够自然。

有了这种反馈，下一轮就不是重新学一遍英语，而是改一个很小的动作。

AI Coding 也是一样。最近复盘 Prompt 的时候，一开始我以为弱点是“不够结构化”。后来才发现，真正的弱点更细：

• 有些任务其实不该结构化，写复杂反而降低效率；
• 有些任务需要轻结构，只要补上范围和输出格式；
• 有些任务会改文件、提交代码、发布同步，这种必须写清验收和验证；
• 还有一些任务做完了，但没有沉淀成模板，下次又重新摸一遍。

如果没有评测，这几个问题会混在一起，最后只能得到一句很空的话：Prompt 质量要提升。

这句话没法训练。

评测不是为了打分

这里很容易走偏。评测如果只剩下分数，就会变成刷分。

刷分的问题是，它会让人优化评测器，而不是优化真实能力。比如如果 AI Coding 的评分器只奖励结构化，那我就会把所有 Prompt 都写成合同格式。分数可能上去了，但真实效率下降了。

所以评测标准必须能被修正。

这次 Prompt 练习就是一个例子。原来的规则会惩罚很多简单 Prompt，因为它们缺少验收、验证、风险边界。但这其实不公平。一句低风险的只读请求，本来就不需要审批门。后来我把规则改成了三档：

Direct：低风险、只读、结果简单，一句话就够。
Light：需要查 repo、输出格式要稳定，用 3-5 行轻结构。
Contract：会改文件、跨模块、git/发布/删除/安全相关，用完整合同。

这个调整比单纯提高分数重要。因为它让评测更接近真实工作。

学习也是这样。一个好的评测，不应该只是告诉你“你现在几分”，而应该告诉你“下一刀该切哪里”。

和 RLHF 的相似点

这套方法让我想到 RLHF。

当然，这里不是严格意义上的机器学习训练，只是一个类比。但这个类比很有用，因为它能解释为什么“评测 + 小步调整”会比泛泛学习更有效。

如果把人的学习过程拆开，大概可以这样对应：

真实练习场景 = environment
当前做题方式 / Prompt 写法 = policy
一次作文、口语、Prompt 或代码任务 = action
评分、批改、复盘结论 = reward
下一轮只改一个弱点 = policy update
错误本、模板、skill、规则 = memory

也就是说，我不是先把知识学完整，再去做任务；而是在真实任务里输出一次，然后根据反馈去调整下一次输出的策略。

这和 RLHF 的直觉很接近：模型先生成结果，人类或评测器给反馈，然后模型以后更倾向于生成高质量结果。放到个人学习里，就是自己先做一次，再用 rubric、AI 或人工反馈判断哪里不好，下一轮只调整一个动作。

不过这里有一个很大的区别：人可以反过来调整评测标准。

前面 Prompt 结构化的例子就是这样。一开始如果评测器只奖励“结构完整”，我就会把所有 Prompt 都写成完整合同。这其实就是一种 reward hacking：分数看起来更好，但真实效率下降了。

后来把 Prompt 分成 Direct / Light / Contract，等于是把 reward model 也校准了一次。低风险任务不该因为没有审批门被扣分，高风险任务也不能因为写得很长就算合格。

所以这套学习方法里，真正有价值的不是机械地追求高分，而是同时做两件事：

优化自己的输出策略；
校准用来评价输出的标准。

这一步如果做不好，评测驱动就会变成刷题驱动。做得好，它才会变成能力训练。

指标从哪里来

这里还有一个问题：既然评测这么重要，那指标从哪里来？

这个问题比看起来更难。指标如果定错了，后面的训练都会被带偏。

做 AI Coding 复盘的时候，我一开始的做法是找外部材料。比如看官方技术博客、技术白皮书、最佳实践，再让 AI 做 deep research，把这些内容综合起来，提取评估维度和评分标准。

这个做法是有价值的。它至少比自己拍脑袋定指标强很多。官方资料能告诉我行业里真正重视什么，最佳实践能补充具体做法，AI 适合把大量材料归纳成几个维度。

但后来发现，这一步只能生成候选指标，不能直接当最终指标。

原因是官方材料很多时候是倡导材料，不是评测材料。它会告诉你“要有测试”“要有上下文”“要注意安全”，但不一定告诉你：

什么算 0 分？
什么算 1 分？
什么算 2 分？
哪些情况看起来规范，但其实没用？
这个维度和另一个维度怎么区分？

如果把这些材料直接交给 AI 归纳，很容易得到一套看起来很专业、但不一定贴合真实失败的指标。

比如前面提到的 Prompt 结构化问题，就是一个很典型的误伤。外部材料普遍强调结构化、上下文、验证，AI 很自然会把“结构完整”当成高质量信号。但真实任务里，有些只读小任务一句话就够了。这个时候评分器如果还要求完整合同，就是指标本身有问题。

所以后面我会把指标来源分成三类：

目标来源：我到底想提升什么能力？
失败来源：我真实任务里经常在哪里出问题？
外部来源：行业资料和最佳实践认为高质量行为是什么？

三者交叉的地方，才比较适合变成指标。

对于 AI Coding 来说，目标是让 AI 更稳定地完成工程任务；失败样本里暴露的问题是范围膨胀、没有验证、危险动作没拦住、经验没有沉淀；外部资料强调的是 context、eval、verification、security、human oversight。

这三类信息合在一起，才会得到比较扎实的维度。

我觉得后续设计任何评测标准，都应该多做两步。

第一步，每个维度要绑定失败模式。

不要只写：

验证与复审

要写成：

维度：验证与复审
要防的问题：AI 说完成了，但没有证据；改动实际没解决问题；引入回归。
可观察证据：测试、lint、typecheck、截图、diff review、复现说明。

如果一个维度说不清它要防什么失败，它大概率只是一个漂亮概念。

第二步，评分标准要有行为锚点。

不要写：

2 分：验证充分
1 分：验证一般
0 分：没有验证

这太虚。更好的写法是：

2 分：运行了与任务相关的测试/检查，并报告结果；如果无法运行，说明原因和替代验证。
1 分：提到了测试或检查，但没有结果，或验证范围偏泛。
0 分：没有任何验证证据。

这样两个人看同一个样本时，才有可能打出接近的分数。

最后还要拿真实样本反向校准。随机抽一些历史任务，看低分样本是不是真的差，高分样本是不是真的好，有没有明显误伤。如果发现误伤，就不要急着解释样本，而是先改 rubric。

所以更完整的流程应该是：

外部资料找上限；
真实失败找痛点；
AI 负责归纳；
人工负责校准；
历史样本负责验收。

这一步做好了，评测才不会停在“看起来专业”。它会真正变成下一轮训练的方向。

可以迁移到哪些学习场景

这套方式目前我至少能看到几个适用场景。

英语学习：

输出一段写作或口语
→ 按考试或真实沟通标准评测
→ 找到最弱维度
→ 只改一段/一句
→ 换题复练
→ 写入错误本

AI Coding：

做一个真实任务
→ 复盘 session
→ 找到 Prompt 或协作流程的问题
→ 改写一个 Prompt
→ 下次任务复用
→ 沉淀成 skill / rule / template

技术学习：

做一个小功能或小项目
→ 用测试、代码审查、讲解清晰度来评测
→ 找到一个知识缺口
→ 只补这个概念
→ 做一个变体题

AI 相关课程也可以这样学。不要只是看课、记笔记，而是每学一个方法，就设计一个小 eval。跑一次，比较输出，改一次 workflow，最后留下一个可复用模板。

这里的重点不是把所有学习都工程化。重点是避免自己陷入“我学了很多，但不知道哪里变强了”的状态。

这套方法的几个坑

这个方法也不是万能的，甚至很容易被用歪。

第一个坑是评测标准太单一。英语如果只看语法，最后可能写得很干净，但观点没有力量。AI Coding 如果只看 Prompt 是否结构化，最后可能每个小任务都写成规格说明书。

第二个坑是没有真实任务。只做人工构造的小题，短期进步会很明显，但迁移到真实工作时容易断。真实任务里有噪声、有上下文、有历史包袱，这些才是能力的一部分。

第三个坑是只复盘不训练。复盘报告写得再漂亮，如果没有下一轮的小练习，也只是多了一份总结。

第四个坑是训练后不沉淀。这个我自己也容易犯。某次任务里摸清楚了一个做法，如果没有写成模板、规则、错误本或 skill，下次大概率还会重新走一遍。

所以这套方法真正要形成习惯，至少要保留三个动作：

评测：这次最弱点是什么？
练习：下一轮只练哪一个动作？
沉淀：这个经验以后怎么复用？

后续我准备怎么用

后面我会把这个方法继续用在几个方向上。

英语学习里，继续保留写作和口语的即时评测，但不要每次都泛泛改全文。每次优先抓一个最影响得分的问题，比如逻辑展开、例子具体度、句子自然度。

AI Coding 里，继续做 session 复盘，但评测规则要允许简单任务保持简单。重点不只是 Prompt 写得好不好，还要看任务有没有验证、经验有没有沉淀、风险有没有提前拦住。

技术学习里，尽量少做“看完就算学过”的学习。每学一个概念，最好能有一个小输出：一段代码、一个 Demo、一次讲解、一个测试，至少要有东西可以被评测。

我现在越来越觉得，学习效率低很多时候不是因为不努力，而是因为没有把反馈变成下一步训练。

以后可以记住一句话：

不要只问“我学得怎么样”，要问“下一轮我只改哪一个动作”。

如果这个问题能回答清楚，学习就不容易散。