Week 1 · D3About 5 hours

A Design Method: Distilling From Repeated Tasks, Checklist Style vs. Reference-Manual Style, Four Anti-Patterns, and Trigger Testing

Turn writing a skill from inspiration into a method: judge whether a task is worth turning into a skill, organize content into one of two mature forms, avoid four anti-patterns, and use a set of positive and negative examples to measure description's trigger rate.

Today's goals 0/3

能用三条判据判断一个重复任务值不值得做成 skill
能区分检查清单式与参考手册式两种形态，并为一个任务选对形态
能设计一组正负例查询，量出 description 的触发率并据此改写它

今日目标

能用三条判据判断一个重复任务值不值得做成 skill
能区分检查清单式与参考手册式两种形态，并为一个任务选对形态
能设计一组正负例查询，量出 description 的触发率并据此改写它

昨天你写出了第一个 skill，靠的是试三句话看它触没触发。这个办法在只有一个 skill 时够用，装到第十个就不行了——你没法记住十个描述之间会不会互相抢，也没法在改了一句话之后知道自己是改好了还是改坏了。今天给你一把能重复使用的尺子。读完正文、做完实验之后，回到页面顶部把三条目标勾掉。

小白版讲解

三条选题判据

档案柜的空间是有限的——不是物理空间，是模型的注意力。每多一个 skill，目录就长一行，误触发的概率就高一点。所以第一个问题永远不是「这个 skill 怎么写」，而是**「这件事值不值得做成 skill」**。

三条判据，三条都成立才动手：

第一条，重复。 这件事你干过至少三次，而且以后还会干。只干过一次的事没有「经验」可言——你甚至不知道自己那一次做对了没有。判断口径很朴素：你能不能立刻说出上一次干这件事是什么时候。 说不出来就说明它没有你以为的那么频繁。

第二条，有纠正。 模型第一次做这件事的时候，你打断过它。这一条是三条里最硬的，因为它同时证明了两件事：模型确实不会（否则你不用纠正），以及你确实会（否则你纠正不了）。没有纠正记录的 skill，写出来大概率是一堆正确的废话——「妥善处理错误」「遵循最佳实践」这种句子，模型不看你的 skill 也会说。

第三条，结果可检验。 做完之后你能判断它做对了没有。提交信息符不符合格式，一眼就能看出来；报表填完金额对不对，一算就知道。反过来，「帮我想一个更好的架构方案」这种任务，对错要三个月后才知道——它不是不能做成 skill，而是你没法迭代它，写完就只能凭感觉觉得它有用。

三条都过了再动手。任何一条不过，你花在这个 skill 上的时间大概率会白费：不重复的没人用，没纠正的写出来是废话，不可检验的你永远不知道它到底有没有效果。

这三条筛掉的东西，比留下的多得多。这是对的——档案柜里放三本每天都翻的册子，比放三十本没人翻的强。那问题就来了：通过筛选的这件事，内容该怎么组织？ 是写成一步步照着做的流程，还是写成随手查的手册？这两种形态的适用场景完全不同，选错了写出来能用但不好用。下面把两种形态、以及最容易踩的四种反模式，一次说清楚。

从一次真实对话里提炼

「有纠正」这条判据不只是筛选条件，它还是内容的直接来源。方法叫「先做一遍，再提炼」：跟模型完整地做一次这件事，全程正常地纠正它，做完之后回头看这段对话，把四类东西抄出来。

第一类，有效的步骤序列。 最终走通的那条路径，按顺序记下来。注意记的是走通的那条，不是你们试过的所有路——中途放弃的分支不要写进 skill，它们只会让模型多几个选项。

第二类，你做过的每一次纠正。 「用这个库，别用那个」「这里要判一下空」「顺序反了，得先校验再写」。这些是整个 skill 里密度最高的内容，因为它们精确地标出了模型的默认行为和你的期望之间的差。

第三类，输入输出的实际长相。 输入是一份什么格式的文件、输出该长什么样。这一类最好直接贴样例，别用文字描述。

第四类，你提供的背景。 那些模型不可能知道、是你现场告诉它的事实：这个字段在三个系统里叫三个名字、这个健康检查接口只看进程活着不看数据库通没通。这类事实的价值极高，它们正是昨天说的「坑」那一段的原料。

除了对话，还有一类被严重低估的原料：你项目里已经存在的材料。内部文档和运行手册、接口规范与配置文件、代码评审里反复出现的意见、以及提交历史里那些修复补丁。最后这一类尤其值钱——它记录的是「实际改了什么」，而不是「本来打算怎么做」。一份从真实事故记录里提炼出来的数据管道 skill，一定强过从「数据工程最佳实践」文章里生成的那份。

两种形态：检查清单式与参考手册式

原料齐了，接下来是组织方式。成熟的 skill 基本落在两种形态里，选对了写起来顺，选错了处处别扭。

检查清单式适合步骤之间有依赖、顺序不能乱、漏一步就出错的任务。它的正文主体是一串有编号的步骤，往往还带一个进度清单让模型自己勾。发布流程、表单填写、数据迁移都属于这一类。

这种形态有一个很有用的变体，叫先规划、再校验、后执行：让模型先产出一份中间计划（比如一个字段到取值的映射文件），拿一个校验脚本对着真值检查这份计划，通过了才真正执行。它的关键不在第一步和第三步，在中间那道校验——错误信息里写清「字段 signature_date 不存在，可用字段有……」，模型才有足够信息自己改对。批量操作和有破坏性的操作都该走这条路。

参考手册式适合知识密集、按需查阅、没有固定顺序的任务。它的正文主体是「什么情况下怎么办」的条目集合，加上一批切好的引用文件。接口错误码处理、格式规范查询、领域术语对照都属于这一类。

两种形态的判据只有一句：这件事有没有一个必须遵守的顺序？ 有就是检查清单式，没有就是参考手册式。混着写是常见的，但要分段混，不要一段里既列步骤又堆条目——那种写法读起来像目录被打乱的说明书。

四种反模式

下面这四种是新手最常写出来的形态，每一种都能用一句话认出来。

第一种，包山包海。 一个 skill 想覆盖某个领域的全部工作。「数据库技能」既管查询又管建索引又管备份恢复。它的问题是没法被精确触发——描述必须写得很泛才能覆盖这么多事，而写泛了就到处误触发。判据：如果你写描述时忍不住用「等等」「以及相关的」这类词，说明范围已经太大了。拆开。

第二种，碎成渣。 反过来，一件事被拆成五个 skill：一个负责读文件、一个负责校验、一个负责转换。它的问题是做一件事要同时激活五个，五份正文一起进上下文，还可能互相矛盾。判据：如果两个 skill 几乎总是一起用，它们本来就是一个。

拆和合的尺度，跟拆函数是一回事：一个 skill 应该封装一个内聚的工作单元，并且能和别的 skill 组合。「查数据库并把结果排版」可以是一个单元；「查数据库并且顺带管理数据库」就是两件事。

第三种，复述常识。 正文里花大段解释什么是 PDF、HTTP 怎么工作、数据库迁移是什么意思。这些模型全都知道，写进去只是在稀释注意力。判据还是那一句：不写这一条，模型会不会做错？ 不会就删。

第四种，给菜单不给默认。 「你可以用 A、B、C、D 四个库中的任意一个」。模型拿到一堆平级选项，只能自己挑，每次挑的还可能不一样。正确写法是给一个默认加一条退路：「用 A；扫描件走 OCR 的场景改用 B」。这一条经常被误当成「保持灵活性」，其实它是在把决策成本转嫁给模型。

顺带说一条相关的：skill 不是写得越全越好。覆盖了所有边界情况的 skill，往往让模型在无关的指令上浪费步数——它读到一条不适用于当前任务的规则，还是会试着遵守。简洁的分步指导加一个可用示例，通常胜过详尽的文档。当你发现自己在覆盖第七种边界情况时，先问一句：这一种是不是交给模型自己判断更好？

触发测试：把手感换成数字

现在到今天最硬的一节。前面讲的都是「怎么写」，这一节讲**「怎么知道自己写对了」**。

昨天你用三句话试了试，那叫抽查。要把它变成尺子，需要三样东西。

第一样，一组带标注的查询。 大约 20 条，其中 8 到 10 条应该触发，8 到 10 条不该触发。应该触发的那批要在四个维度上铺开：措辞有正式有随意甚至带错别字；有的直接点名领域，有的只描述需求；有的很短，有的带一堆文件路径和背景；有的是单步任务，有的是把这件事埋在一长串工作里。最有价值的正例，是那些「这个 skill 确实该用，但从字面上看不出来」的查询——如果一条查询已经把 skill 的功能原样念了一遍，那任何描述都能命中它，测不出区别。

不该触发的那批更需要设计。「今天天气怎么样」这种毫无重叠的句子测不出任何东西。真正有用的是近似负例：和 skill 共享关键词或概念，但实际需要的是别的东西。对一个 CSV 分析 skill，「帮我改一下 Excel 预算表里的公式」和「写个脚本把 CSV 每一行传进数据库」都是好负例——前者是 Excel 编辑不是 CSV 分析，后者是数据搬运不是分析。

第二样，重复跑。 模型的行为是不确定的，同一条查询这次触发下次可能不触发。每条跑 3 次，算一个触发率：触发次数除以总次数。应该触发的查询，触发率高于 0.5 算通过；不该触发的，低于 0.5 算通过。20 条查询乘 3 次是 60 次调用，这个量级必须写脚本。

第三样，训练与验证拆分。 这一条是新手最容易漏、也最容易吃亏的。如果你拿全部 20 条去调描述，你会调出一版「专门对付这 20 条」的描述，换一批新查询就崩。做法是把查询集按大约六比四拆成两份：只用训练集找问题、指导改写，验证集全程不看，最后用验证集的通过率来挑哪一版描述最好。两份都要保证正负例的比例接近，拆完就固定下来，别每轮重新洗牌。

判定一条查询有没有触发，是这套东西的核心。原理简单得出乎意料：把所有 skill 的名字和描述拼成目录，连同用户的这句话一起交给模型，让它回答该用哪一个或者一个都不用。这就是客户端在阶段一做的事，我们只是把它单独拎出来跑。

trigger.ts

type SkillMeta = { name: string; description: string }
 
// 这里的提示词刻意贴近客户端在阶段一的做法：只给名字和描述，不给正文
function buildJudgePrompt(skills: SkillMeta[], query: string): string {
  const catalog = skills.map((s) => `- ${s.name}: ${s.description}`).join('\n')
  return [
    '下面是可用技能的清单，每条只有名字与描述。',
    catalog,
    '',
    `用户说：${query}`,
    '',
    '只回答一个技能的名字；如果没有任何一个明显适用，回答 none。不要解释。',
  ].join('\n')
}
 
export async function judgeOnce(skills: SkillMeta[], query: string, target: string): Promise<boolean> {
  if (process.env.MOCK === '1') {
    // 离线模拟：用关键词重合度粗略模拟模型的判断，让整条链路在没有密钥时也能跑通
    const hit = target.split('-').some((w) => query.includes(w))
    return hit
  }
  const answer = await callModel(buildJudgePrompt(skills, query))
  return answer.trim().toLowerCase() === target.toLowerCase()
}
 
// 跑 runs 次取触发率，因为模型的判断本身是不确定的
export async function triggerRate(skills: SkillMeta[], query: string, target: string, runs = 3) {
  let hits = 0
  for (let i = 0; i < runs; i++) if (await judgeOnce(skills, query, target)) hits++
  return hits / runs
}

trigger.py

import os
from dataclasses import dataclass
 
 
@dataclass
class SkillMeta:
    name: str
    description: str
 
 
# 这里的提示词刻意贴近客户端在阶段一的做法：只给名字和描述，不给正文
def build_judge_prompt(skills: list[SkillMeta], query: str) -> str:
    catalog = "\n".join(f"- {s.name}: {s.description}" for s in skills)
    return "\n".join(
        [
            "下面是可用技能的清单，每条只有名字与描述。",
            catalog,
            "",
            f"用户说：{query}",
            "",
            "只回答一个技能的名字；如果没有任何一个明显适用，回答 none。不要解释。",
        ]
    )
 
 
def judge_once(skills: list[SkillMeta], query: str, target: str) -> bool:
    if os.environ.get("MOCK") == "1":
        # 离线模拟：用关键词重合度粗略模拟模型的判断，让整条链路在没有密钥时也能跑通
        return any(w in query for w in target.split("-"))
    answer = call_model(build_judge_prompt(skills, query))
    return answer.strip().lower() == target.lower()
 
 
# 跑 runs 次取触发率，因为模型的判断本身是不确定的
def trigger_rate(skills: list[SkillMeta], query: str, target: str, runs: int = 3) -> float:
    hits = sum(1 for _ in range(runs) if judge_once(skills, query, target))
    return hits / runs

有了触发率，剩下的就是统计与拆分。下面这段把一组带标注的查询跑成一张表：逐条给出期望、触发率、通过与否，再分别汇总训练集与验证集的通过率。关键是两个集合分开算——训练集的数字指导你改，验证集的数字决定你选哪一版。

evaluate.ts

type Case = { query: string; shouldTrigger: boolean; split: 'train' | 'validation' }
 
export async function evaluate(skills: SkillMeta[], target: string, cases: Case[]) {
  const rows = []
  for (const c of cases) {
    const rate = await triggerRate(skills, c.query, target)
    // 阈值 0.5：该触发的要高于它，不该触发的要低于它
    const passed = c.shouldTrigger ? rate > 0.5 : rate <= 0.5
    rows.push({ ...c, rate, passed })
  }
  const rateOf = (split: Case['split']) => {
    const subset = rows.filter((r) => r.split === split)
    return subset.length === 0 ? 0 : subset.filter((r) => r.passed).length / subset.length
  }
  // 训练集的数字指导你改描述，验证集的数字决定你最终选哪一版
  return { rows, train: rateOf('train'), validation: rateOf('validation') }
}

evaluate.py

from dataclasses import dataclass
 
 
@dataclass
class Case:
    query: str
    should_trigger: bool
    split: str  # "train" 或 "validation"
 
 
def evaluate(skills: list[SkillMeta], target: str, cases: list[Case]) -> dict:
    rows = []
    for c in cases:
        rate = trigger_rate(skills, c.query, target)
        # 阈值 0.5：该触发的要高于它，不该触发的要低于它
        passed = rate > 0.5 if c.should_trigger else rate <= 0.5
        rows.append({"case": c, "rate": rate, "passed": passed})
 
    def rate_of(split: str) -> float:
        subset = [r for r in rows if r["case"].split == split]
        return len([r for r in subset if r["passed"]]) / len(subset) if subset else 0.0
 
    # 训练集的数字指导你改描述，验证集的数字决定你最终选哪一版
    return {"rows": rows, "train": rate_of("train"), "validation": rate_of("validation")}

拿到结果之后怎么改，有两条硬规矩。该触发的没触发，说明描述太窄，要补的是「这一类说法」而不是「这一句话」——把失败查询的原话原样抄进描述，就是过拟合的开始。不该触发的触发了，说明描述太宽，要补的是边界：明确写出它不做什么，或者说清它和相邻能力的分界线。

还有两条经验值得记。改五轮左右就该停：如果通过率一直不动，问题多半在查询集本身（太简单、太难、或者标注错了），而不在描述。最好的那一版不一定是最后一版：后面几轮很可能在往训练集上过拟合，所以挑版本要按验证集的通过率挑，不是按迭代顺序挑。

源码导读

动手实验

🧪 D3 实验：一个 skill 触发测试脚本，喂入一组带标注的查询，输出逐条命中结果与触发率

Code location: labs/agent-skills-7days/day-03-trigger-eval

验收标准：

MOCK=1 下能跑通全流程，输出一张逐条表格：查询、期望、触发率、通过与否，最后给出训练集与验证集两个通过率。
查询集至少 12 条，正负比例接近，其中至少 3 条是与目标 skill 共享关键词的近似负例。
每条查询跑 3 次并取触发率，而不是跑一次直接判定。
训练集与验证集按大约六比四拆开，两个集合的正负比例接近，并且汇总时分别统计。
按训练集的失败项改一版描述后重跑，能在输出里看到两版描述的验证集通过率对比。

今天有真代码要写。动手之前先把昨天那个提交信息 skill 的描述准备好，它就是这次的被测对象。卡在「近似负例想不出来」的时候，回到「触发测试」那一节的两个 CSV 例子照着造——共享关键词、目标动词不同，这是唯一的口径。

跑通 solution，用 MOCK=1 看清一份带标注查询集跑出来的逐条命中表与两个通过率。
在 starter 里补全描述匹配的判定逻辑，让它对一条查询给出命中与否和一句理由。
补全触发率统计与训练验证两个集合的分别汇总。
自己补三条近似负例，重跑并观察触发率的变化。
按训练集的失败项改写一版描述，再跑一次，对比两版的验证集通过率。

面试题

今天 3 道题在下方题库区，侧重 skill 的选题判据、两种内容形态的取舍、以及触发测试的设计与过拟合。展开后先看「分析过程」再看要点——照着推导练，比背要点管用。标注「国内高频 / 海外高频」方便按目标市场取舍。

检查清单与明日预告

能用三条判据判断一个重复任务值不值得做成 skill
能区分检查清单式与参考手册式两种形态，并为一个任务选对形态
能设计一组正负例查询，量出 description 的触发率并据此改写它
能当场说出四种反模式，并各给一个自己写过或见过的例子
实验的 5 条验收标准全部通过
3 道面试题不看要点也能答出至少 2 道

明天（D4）我们给 skill 加上手脚。今天讲的「先规划、再校验、后执行」里那道关键的校验，就是一个脚本；今天说的「模型每次重新发明同一段逻辑」也是该写脚本的信号。明天讲清楚什么时候该从写指令切换到写代码、脚本的依赖怎么做到自包含、接口怎么为 Agent 而不是为人设计，以及一个绕不开的问题——让模型跑你的脚本，风险到底有多大。

Interview questions

Which tasks are worth turning into a skill and which are not? Give me a test I can apply on the spot.什么样的任务适合做成 skill，什么样的不适合？给我一套能当场用的判断标准。
Common in ChinaCommon overseasBasic#agent-skills#skill-design
How to reason about it · think before answering
The lazy answer is repetitive and complex tasks, which anyone can say. The interviewer wants a falsifiable test plus the reasoning behind each part.
Give three criteria and insist all three must hold: repetition (done at least three times and will recur), correction (you interrupted the model the first time), and checkable results (you can tell afterwards whether it was right).
Explain each. Correction is the strongest, because it simultaneously proves the model does not know and that you do. Without correction history you produce generic filler like handle errors appropriately.
Checkability is the one people skip, and it decides not whether you can write the skill but whether you can iterate on it. If correctness only surfaces in three months, you are guessing.
Then state the failure modes: without repetition nobody uses it, without correction it is filler, without checkability you cannot improve it.
Expected follow-up: how wide should one skill be? Scope it like a function: one coherent unit that composes with others. Two skills always activated together were one skill; if the description needs and so on, the scope is too wide.
分析过程 · 先想清楚再作答
这题最容易答成「重复的、复杂的任务」，那是所有人都会说的话，没有区分度。面试官想听的是一套能证伪的判据，以及每一条判据背后的道理。
给三条，并且强调三条都要成立：重复（干过至少三次且还会干）、有纠正（模型第一次做时你打断过它）、结果可检验（做完能判断对错）。
逐条解释为什么。「有纠正」是最硬的一条，因为它同时证明模型确实不会、你确实会——没有纠正记录的 skill 写出来大概率是「妥善处理错误」这类正确的废话。
「可检验」这条常被忽略但很关键：它决定的不是这个 skill 能不能写，而是**你能不能迭代它**。对错要三个月后才知道的任务，你写完只能凭感觉觉得有用。
然后给反面：不满足这三条会怎样——不重复的没人用，没纠正的是废话，不可检验的没法改进。这一句把判据从清单变成了论证。
可预期的追问是「那范围多大合适」。答案是像拆函数一样：一个内聚的工作单元，且能与别的 skill 组合。两个总是一起激活的 skill 本来就是一个；描述里忍不住写「等等」说明范围太大了。
Key points
All three must hold before you start: repetition, correction, checkable results.
Correction is the strongest signal because it proves both the gap and your expertise.
Checkability decides whether you can iterate, not whether you can write it.
Scope to one coherent unit; two skills that always activate together should be merged.
If the description needs and so on, the scope is already too wide.
答题要点
三条判据全部成立才动手：重复、有纠正、结果可检验。
有纠正是最硬的一条，它同时证明模型不会而你会。
可检验决定的不是能不能写，而是能不能迭代。
范围按内聚工作单元切，总是一起激活的两个 skill 应该合并。
描述里出现「等等」「以及相关的」，说明范围已经太大，该拆。
How do you evaluate whether a skill description is good? Is trying a few prompts yourself enough?怎么测一个 skill 的 description 好不好？自己试几句话够吗？
Common in ChinaCommon overseasIntermediate#agent-skills#evaluation
How to reason about it · think before answering
The hinge is the second half. Saying a few prompts is enough fails immediately, but saying write a test set is not enough either; the interviewer wants the design.
Explain why spot checks fail: fine with one skill, useless at ten, because you cannot hold ten descriptions in your head nor tell whether an edit helped or hurt.
Then give three ingredients. First, a labeled query set of about twenty, balanced positive and negative. Vary positives along phrasing, explicitness, detail and complexity; the most valuable positives are the ones where the skill applies but the wording does not say so.
Negatives are where the design effort goes: unrelated sentences test nothing. Near-misses that share keywords but need something else are what matters, such as editing Excel formulas or loading CSV rows into a database for a CSV-analysis skill.
Second, repeat runs for a trigger rate, since model behavior is nondeterministic: three runs per query with a 0.5 threshold. Third, a roughly sixty-forty train and validation split with the validation set untouched.
Expected follow-up: how do you decide whether a query triggered? Build the catalog of names and descriptions, hand it plus the query to the model and ask which skill applies. That is exactly what a client does at discovery, run standalone.
分析过程 · 先想清楚再作答
题眼在后半句。答「自己试几句就行」直接出局，但只答「要写测试集」也不够——面试官要看你知不知道这个测试集该怎么设计。
先说为什么抽查不够：一个 skill 时够用，装到第十个就不行了，因为你既记不住十个描述之间会不会互相抢，也没法在改完一句话后判断是改好了还是改坏了。
然后给三件东西。第一是带标注的查询集，约 20 条，正负各半。正例要在措辞、显式程度、详略、复杂度四个维度上铺开；**最有价值的正例是那些确实该用但字面看不出来的**，字面已经念了一遍功能的查询任何描述都能命中，测不出区别。
负例是设计的重点：毫无重叠的句子测不出任何东西，真正有用的是近似负例——共享关键词或概念但目标动词不同。对 CSV 分析 skill，「改 Excel 预算表的公式」和「把 CSV 每行写进数据库」都是好负例。
第二是重复跑取触发率：模型是不确定的，每条跑三次算命中比例，阈值取 0.5。第三是训练验证拆分，六比四，验证集全程不看。
可预期的追问是「怎么判断一条查询触发了没有」。答案是把所有 skill 的名字与描述拼成目录，连同这句话交给模型问它该用哪一个——这正是客户端在发现阶段做的事，只是单独拎出来跑。
Key points
Spot checks work for one skill and break down once several skills compete.
About twenty labeled queries, balanced, with positives varied by phrasing, explicitness, detail and complexity.
Negatives must be near-misses that share keywords but need a different action.
Three runs per query for a trigger rate with a 0.5 threshold, because behavior is nondeterministic.
Split roughly sixty-forty; train guides revision, validation picks the winning version.
答题要点
抽查在一个 skill 时够用，多个 skill 互相干扰时完全不够。
约 20 条带标注查询，正负各半，正例在措辞、显式程度、详略、复杂度四维上铺开。
负例必须是近似负例：共享关键词但目标动词不同，无关句子测不出东西。
每条跑三次取触发率，阈值 0.5，因为模型行为不确定。
训练验证六四拆分，训练集指导改写，验证集只用来选版本。
When optimizing a description, how do you avoid overfitting to the very queries you wrote?优化 description 的时候怎么避免过拟合到你自己写的那几条测试查询？
Common in ChinaCommon overseasDeep dive#agent-skills#evaluation
How to reason about it · think before answering
This is a familiar machine learning idea in a new setting. Saying validation set is only the start; the discriminator is describing the exact wrong move.
Name what overfitting looks like here: a query fails, you paste its wording into the description, that query passes, and a synonymous one fails. Pasting the wording is the overfitting act itself.
The right move is to generalize: identify the category the failing query represents and cover that. If a casual phrasing failed, cover casual phrasings, not that sentence.
Structurally, rely on the split: roughly sixty-forty, revise only from train-set failures, keep the validation set out of the loop, preserve label balance in both, and freeze the split across iterations.
Two practical rules: pick the version by validation pass rate rather than by recency, since later rounds tend to overfit, and stop after about five iterations if nothing moves, because the problem is then in the queries.
Expected follow-up: how do you know the queries are the problem? Look at items that pass or fail in every configuration. Always-pass items carry no information; always-fail items are mislabeled or beyond the model.
分析过程 · 先想清楚再作答
这题是机器学习的老概念换了个场景，考的是你能不能把它迁移过来。能说出「验证集」三个字只是起点，真正的区分度在你怎么描述那个具体的错误动作。
先点明过拟合在这里长什么样：一条查询没触发，你把它的原话抄进描述，于是这一条过了，换一句同义的又不过。**抄原话就是过拟合的动作本身。**
正确做法是归纳：找出这条失败查询代表的**那一类说法**，然后把这一类补进去。比如「这几个文件我要提交了」失败了，该补的不是这句话，是「不含专业词的口语提交请求」这一类。
结构上靠拆分兜底：查询集按六比四拆成训练与验证，只用训练集的失败项指导改写，验证集全程不参与优化过程，两份都要保持正负比例接近，拆完固定不再洗牌。
还有两条实操经验。**挑版本按验证集通过率挑，不是按迭代顺序挑**——后面几轮往往在往训练集上过拟合，最好的可能是第三版而不是第五版。改五轮左右还不动就该停，问题多半在查询集本身而不在描述。
可预期的追问是「怎么知道是查询集的问题」。答案是看那些在两种配置下都失败或都成功的条目：都成功说明这条太容易、没有信息量，都失败说明要么标注错了要么要求超出模型能力，两类都该换掉。
Key points
The overfitting move is pasting a failing query verbatim; generalize to its category instead.
Split roughly sixty-forty and revise only from train-set failures.
Keep label balance in both splits and freeze the split across iterations.
Select the version by validation pass rate; the best is not always the last.
If five rounds change nothing, inspect the query set for triviality, impossibility or mislabeling.
答题要点
过拟合的具体动作是把失败查询的原话抄进描述，要改成补它代表的那一类说法。
查询集六四拆分，只用训练集指导改写，验证集全程不看。
两个集合都要保持正负比例接近，拆完固定，不要每轮重洗。
按验证集通过率挑版本，最好的那版不一定是最后一版。
五轮不动就停，去查查询集本身是不是太容易、太难或标注错了。

Comments

No comments yet — be the first.