加载 Skills：扫描、渐进披露与触发判定，让经验按需上桌

面试题库

• 技能的渐进披露具体分几个阶段？每个阶段的判据是什么？How many stages does progressive disclosure for skills have, and what triggers each one?

  国内高频海外高频基础#progressive-disclosure#skills

  分析过程 · 先想清楚再作答

  1. 这题在考「你是不是自己实现过一个加载器」。只用过的人会答「先读摘要再读全文」，实现过的人会先说每个阶段的判据不同，因为判据决定了成本的形状。
  2. 怎么拆：三个阶段各说一遍「什么时候发生、注入什么、成本怎么算」，最后点一句三者的判据互不相同。
  3. 阶段一是摘要常驻：判据是「这台机器上装了什么」，与用户说什么无关，所以它拼在系统提示里、每一次请求都付钱。内容只有名字加一行 description，这一行是模型判断要不要用它的全部依据。
  4. 阶段二是全文按需：判据是「这一句话命中了什么」，所以按轮计费，没命中就是零。注入的消息角色应该是 user 不是 system——它是本轮的资料不是长期规则，写成 system 会让它在后面每一轮都被当成同等权重的指令。
  5. 阶段三是附件按需：判据是「模型自己决定要用」，所以它根本不是注入而是一次工具调用。注入全文时只给能直接跑的命令行加一句说明，脚本内容一个字都不读——只给路径的话模型会先读一遍，阶段三就退化回阶段二了。
  6. 一条容易说错的：渐进披露省的是上下文不是磁盘 IO。扫描时整份文件其实都读出来了，因为要拿 frontmatter 就得读文件头；省的是「把这段文字塞进每一次请求」那部分成本。
  7. 可预期的追问：收益大头在哪些轮次上；技能数量增长时这套账怎么变；阶段二的注入要不要进会话历史。

  How to reason about it · think before answering

  1. This tests whether you have implemented a loader yourself. People who only used one answer "summary first, then full text"; people who built one start from the fact that each stage has a different trigger, because the trigger determines the shape of the cost.
  2. How to break it down - describe each stage as when it happens, what it injects, and how it is billed, then point out that the three triggers are unrelated to each other.
  3. Stage one is the resident summary. Its trigger is what is installed on this machine, independent of what the user says, so it lives in the system prompt and is paid for on every request. It carries only the name and a one-line description, and that line is the model's entire basis for deciding whether the skill is relevant.
  4. Stage two is the body on demand. Its trigger is what this particular sentence matched, so it is billed per turn and costs nothing when nothing matches. The injected message should have the user role, not system - it is material for this turn, not a standing rule, and a system role would make it carry equal weight on every later turn.
  5. Stage three is attachments on demand. Its trigger is the model deciding to use one, so it is not an injection at all but a tool call. The body should list a directly runnable command line plus one sentence of explanation and never the script's contents - given only a path, the model will read the script first and stage three collapses back into stage two.
  6. Easy to get wrong - progressive disclosure saves context, not disk IO. Scanning actually reads the whole file, because reaching the frontmatter means reading the head of it; what is saved is the cost of shipping that text with every request.
  7. Likely follow-ups - which turns carry most of the savings; how the arithmetic changes as skill count grows; whether the stage-two injection should persist in conversation history.

  答题要点

  • 三个阶段：摘要常驻、全文按需、附件按需，判据分别是「装了什么」「这句命中了什么」「模型决定要用」
  • 阶段一每技能一行，拼进系统提示，每次请求都付；它是模型判断相关性的全部依据
  • 阶段二按轮计费，没命中就是零；注入用 user 角色而不是 system
  • 阶段三不是注入而是一次工具调用，只给命令行不给脚本内容
  • 省的是上下文不是磁盘 IO；收益大头在「这一轮什么也没命中」的那些轮次上

  Key points

  • Three stages - resident summary, body on demand, attachment on demand - triggered by what is installed, what this sentence matched, and what the model decides to run
  • Stage one is one line per skill in the system prompt, paid on every request; it is the model's entire basis for judging relevance
  • Stage two is billed per turn and costs nothing when nothing matches; inject it as a user message, not a system one
  • Stage three is a tool call rather than an injection - hand over a command line, never the script body
  • What is saved is context, not disk IO; most of the saving comes from turns that match nothing at all
• 技能和工具的边界在哪？同一件事你怎么决定做成技能还是做成工具？Where is the line between a skill and a tool, and how do you decide which one a given capability should be?

  国内高频海外高频进阶#skills-vs-tools#agent-design

  分析过程 · 先想清楚再作答

  1. 这题在考架构判断。答「技能是文档、工具是函数」只说到了形式，说不到代价；能说出「技能不能保证被执行」的人明显是做过取舍的。
  2. 怎么拆：先给一句判据，再各说一条好处与一条代价，最后给一个必须做成工具的反例。
  3. 判据一句话：工具是能力，技能是流程。工具让 Agent 做到它本来做不到的事（没有跑命令的工具它就是跑不了测试），技能让它把已经能做的事做对（它会跑测试，但不知道这个仓库跑哪条命令、输出先看哪一行）。
  4. 技能的好处是不占工具清单的位置：工具表要随每次请求发出去，几十个工具之后选错工具的概率会明显上升；技能的常驻成本只有一行描述，全文根本不常驻，所以技能数量几乎没有上限。
  5. 技能的代价是不能保证被执行：工具调用有确定语义，模型发出调用就真的会执行、参数不对还会被挡回来；技能只是一段文字，模型可以读了不照做，而你没有任何机制拦得住。
  6. 所以反例很清楚：一条必须被执行的纪律不该只写成技能。写文件前拍快照、危险命令要审批、结果超长要截断，这些都得写进代码。手艺卡管的是判断，代码管的是纪律。
  7. 还有一类中间态值得提：技能带的可执行脚本。它形式上是技能的附件，实际执行时走的是工具调用那条路，等于用技能承载「什么时候该跑」，用工具承载「跑起来」。
  8. 可预期的追问：技能里写的规矩和系统提示里写的规矩冲突了听谁的；要不要给技能加一个「强制执行」标记；技能的描述文本算不算不可信输入。

  How to reason about it · think before answering

  1. This is an architecture judgment question. Saying "a skill is a document and a tool is a function" covers the form but not the cost; candidates who can articulate that a skill cannot be guaranteed to execute have clearly made the trade-off in practice.
  2. How to break it down - give one criterion, then one benefit and one cost for each, then a counter-example that must be a tool.
  3. The criterion in one line - a tool is a capability, a skill is a procedure. A tool lets the agent do something it otherwise cannot (without a shell tool it simply cannot run tests); a skill lets it do correctly what it already can (it knows how to run tests, but not which command this repo uses or which line of output to read first).
  4. The benefit of a skill is that it does not occupy a slot in the tool list. The tool table ships with every request, and past a few dozen tools the odds of picking the wrong one rise noticeably. A skill's resident cost is one line of description and its body is not resident at all, so skill count is practically unbounded.
  5. The cost of a skill is that execution is not guaranteed. A tool call has defined semantics - the model emits it, we really run it, and bad arguments are pushed back. A skill is just text; the model may read it and not comply, and nothing you own can stop that.
  6. So the counter-example is clear - a rule that must be enforced should not live only in a skill. Snapshot before writing, approval before dangerous commands, truncation of oversized results: all of those belong in code. The card governs judgment, the code governs discipline.
  7. Worth mentioning a middle case - executable scripts bundled with a skill. Formally they are attachments of the skill, but running one goes through the tool-call path, so the skill carries "when to run it" while the tool carries "running it".
  8. Likely follow-ups - what wins when a skill contradicts the system prompt; whether skills deserve a mandatory flag; whether skill description text counts as untrusted input.

  答题要点

  • 工具是能力、技能是流程：前者让它做到本来做不到的事，后者让它把已经能做的事做对
  • 技能不占工具清单的位置，数量几乎没有上限；工具表随每次请求发出，多了会让模型选错
  • 技能的代价是不能保证被执行，模型可以读了不照做，没有任何机制拦得住
  • 必须被执行的纪律要写进代码：拍快照、审批、截断都不该只写成技能
  • 技能附带的可执行脚本是中间态：技能管「什么时候跑」，工具调用管「跑起来」

  Key points

  • A tool is a capability and a skill is a procedure - one enables what was impossible, the other makes the already-possible correct
  • Skills take no slot in the tool list and scale almost without limit; the tool table ships on every request and a bloated one causes mis-selection
  • The cost of a skill is that execution is not guaranteed - the model may read it and ignore it, and nothing stops that
  • Rules that must be enforced belong in code - snapshots, approval gates and truncation should never be skills alone
  • Bundled executable scripts are the middle case - the skill says when to run, the tool call does the running
• 技能的触发条件怎么设计？过度触发和漏触发哪个更难查？How would you design skill trigger conditions, and which is harder to diagnose - over-triggering or under-triggering?

  国内高频海外高频深入#trigger-design#false-positives

  分析过程 · 先想清楚再作答

  1. 这题的题眼是「哪个更难查」。多数人会答「触发词要写准」，那是在回避取舍；真正的答案是两类误判的代价不对称，所以默认姿态本身就该是偏向某一边的。
  2. 怎么拆：先答那个更难查的，再由它推出设计姿态，最后才说具体的条件类型与实现坑。
  3. 漏触发更难查，而且难得不是一个量级。过度触发的代价是花掉一点上下文，而且看得见——注入报账里会多出一行，你当场就知道它上桌了。漏触发是模型按通用知识回答，答得像模像样，而没有任何东西提示你有一份约定没被读到；你只有在代码评审时才会发现它又把除零写成了返回无穷大。
  4. 由此推出设计姿态：判定层宁可多上一张，真正的刹车放在预算层。这和多数人的直觉相反——第一反应是把触发词写严，结果技能常年不触发，最后得出「这套东西没用」的结论。
  5. 条件类型按可信度分三类：用户显式点名最可信、路径命中次之（很难误报）、关键词最容易误报。分数只用来排序与打破平局，作者声明的优先级绝不该参与「有没有命中」，否则一个高优先级技能会在完全不相干的话里上桌。
  6. 实现上有一个人人都踩的坑：英文触发词必须按词边界匹配，否则 test 会被 latest、contest 命中；中文只能按子串，因为没有空格分词。而且这条分界不能交给技能作者自己选——他写触发词时想的是「我这个技能是干嘛的」，不是「这个词会不会出现在别的句子里」。
  7. 最后是可观测性：命中原因必须打出来。漏触发时用户唯一的依据就是那几行——到底是词写窄了、路径写错了，还是这条技能压根没装上。没有这几行，这套机制就没法调。
  8. 可预期的追问：同时命中两条互相矛盾的技能怎么办；要不要让模型自己决定加载哪一条；触发判定能不能交给一次小模型调用。

  How to reason about it · think before answering

  1. The crux is "which is harder to diagnose". Most people answer "write precise trigger words", which dodges the trade-off. The real answer is that the two failure modes have asymmetric costs, so the default stance should itself lean one way.
  2. How to break it down - answer the harder one first, derive the design stance from it, and only then discuss condition types and implementation traps.
  3. Under-triggering is harder, and not by a small margin. Over-triggering costs a little context and is visible - the injection report gains a line and you know immediately. Under-triggering means the model answers from generic knowledge, plausibly, with nothing anywhere hinting that a convention went unread; you find out at code review when it once again returns infinity on divide-by-zero.
  4. That yields the stance - be generous at the matching layer and put the real brake in the budget layer. This is the opposite of most people's instinct, which is to tighten trigger words until the skill never fires, ending in the conclusion that the whole mechanism is useless.
  5. Condition types rank by trustworthiness - an explicit mention by the user is the most reliable, a path match is next and rarely false-positives, and keywords are the most error-prone. Scores should only order and break ties; an author-declared priority must never decide whether something matched, or a high-priority skill will surface in a completely unrelated sentence.
  6. One implementation trap catches everyone - ASCII trigger words must match on word boundaries, or "test" fires on "latest" and "contest"; Chinese can only match as a substring because there is no whitespace tokenization. And that distinction must not be left to the skill author, who is thinking about what the skill does rather than where the word might otherwise appear.
  7. Finally observability - match reasons must be printed. When something fails to trigger, those lines are the user's only evidence for whether the word was too narrow, the path was wrong, or the skill never loaded at all. Without them the mechanism cannot be tuned.
  8. Likely follow-ups - what to do when two contradictory skills both match; whether the model should choose which to load; whether matching could be delegated to a small model call.

  答题要点

  • 漏触发更难查：过度触发在注入报账里看得见，漏触发没有任何提示，只能在评审时发现
  • 由此定姿态：判定层宁可多上一张，刹车放在预算层而不是判定层
  • 三类条件按可信度排：显式点名、路径命中、关键词；作者声明的优先级只打破平局，不决定是否命中
  • 英文触发词按词边界匹配（否则 test 命中 latest），中文按子串；这条不能交给技能作者自己选
  • 命中原因必须打出来，否则漏触发时无从判断是词写窄了、路径写错了还是技能没装上

  Key points

  • Under-triggering is harder - over-triggering shows up in the injection report, while a missed trigger leaves no trace and only surfaces at review
  • Hence the stance - be generous when matching and put the brake in the budget layer instead
  • Rank conditions by trustworthiness - explicit mention, path match, keyword; an author's priority only breaks ties and never decides a match
  • Match ASCII trigger words on word boundaries (otherwise "test" fires on "latest") and Chinese as substrings; this must not be left to the skill author
  • Always print match reasons, or a missed trigger gives no way to tell a narrow word from a wrong path from a skill that never loaded

评论