面试题库

7 天 Agent Skills：把经验做成可复用能力

D1 Skills 是什么：SKILL.md 规范、目录结构与三阶段渐进式加载

• 渐进式加载的三个阶段分别加载什么？为什么不能一次性把所有 skill 全加载进去？What does each of the three progressive disclosure stages load, and why not just load every skill up front?

  国内高频海外高频进阶#agent-skills#progressive-disclosure

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

  1. 这题在考你对机制的记忆精度，同时也在考工程感。只背出三个阶段的名字拿不到分，要说出每一阶段加载的**是哪些字段、哪些文件**。
  2. 拆法很简单，按加载的粒度从粗到细数：阶段一只加载 name 与 description，量级是每个 skill 五十到一百个 token；阶段二加载整份 SKILL.md 正文，建议不超过五千 token 与五百行；阶段三按文件粒度加载脚本、引用与资源。
  3. 回答「为什么不全加载」时给一个具体的数：二十个 skill 各三千 token 的正文加上引用文件，全量是十几万 token，超过很多模型的窗口，而且每一轮都要重发。渐进式加载后总量落在一万上下。
  4. 补一条更本质的理由：省下来的不只是钱，是窗口位置。腾出来的空间要留给真正在做的这件事的代码和数据，这就是上下文工程的核心取舍。
  5. 可预期的追问是「阶段三怎么触发」。答案是正文里必须写明读取条件——写「细节见 references 目录」等于没写，写「接口返回非 200 时读 references 里的错误码文件」才真正把时机交给了模型。

  How to reason about it · think before answering

  1. This tests both recall precision and engineering sense. Naming the three stages is not enough; say which fields and which files each stage pulls in.
  2. Order them by granularity: stage one loads only name and description, roughly fifty to a hundred tokens per skill; stage two loads the full SKILL.md body, recommended under five thousand tokens and five hundred lines; stage three loads individual scripts, references and assets.
  3. Answer the why with a number: twenty skills at three thousand tokens of body plus reference files is well over a hundred thousand tokens, past many context windows, and resent every turn. Progressive loading lands around ten thousand.
  4. Add the deeper reason: what you save is window space, not just money, and that space belongs to the actual task.
  5. Expected follow-up: how does stage three fire? The body must state the loading condition. See the references folder is useless; read the error-code reference when the API returns a non-200 hands the timing to the model.

  答题要点

  • 阶段一发现：只加载 name 与 description，每个 skill 约五十到一百 token。
  • 阶段二激活：读入完整 SKILL.md 正文，建议不超过五千 token 与五百行。
  • 阶段三执行：按需读取 scripts、references、assets 里的单个文件，不是整目录倒进来。
  • 全量加载会撑爆窗口且每轮重发，渐进式加载能把量级压到十分之一左右。
  • 阶段三能不能被触发，取决于正文有没有写清「什么条件下读哪个文件」。

  Key points

  • Discovery: only name and description, about fifty to a hundred tokens per skill.
  • Activation: the full SKILL.md body, ideally under five thousand tokens and five hundred lines.
  • Execution: individual files from scripts, references or assets, loaded one at a time on demand.
  • Loading everything up front blows the window and is resent every turn; progressive loading cuts it to roughly a tenth.
  • Stage three only fires if the body spells out which file to read under which condition.
• SKILL.md 的 name 与 description 有哪些硬性约束？规范为什么要把 name 卡得这么死？What hard constraints does the spec put on the name and description fields, and why is name so tightly constrained?

  国内高频海外高频进阶#agent-skills#spec

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

  1. 这题看着像背规范，其实题眼在后半句「为什么」。能把约束背全只算及格，能说出这些约束是为了解决什么工程问题才是加分项。
  2. 先把 name 的五条约束数完：长度一到六十四个字符、只能用小写字母数字和连字符、不能以连字符开头或结尾、不能有连续两个连字符、必须与父目录名一致。
  3. 再给 description 的两条：长度一到一千零二十四个字符；内容上要同时说清做什么和什么时候用，而不是只说做什么。
  4. 解释「为什么卡这么死」：name 是这个 skill 在整个生态里的唯一标识，要拼进目录名、命名空间、斜杠命令，还要在两个 skill 撞名时用来判优先级。任何一处大小写或分隔符不一致，都会变成一个很难查的「装了却调不到」。
  5. 补一个真实的坑：很多客户端在实现时故意放宽了「name 等于目录名」这条，不一致只打警告仍然加载。于是你本地一切正常，换个严格实现就整个消失。
  6. 可预期的追问是「description 写到一千个字符会怎样」。答案是它每次会话都要付一遍，二十个 skill 都写满上限，光目录就要八千 token，这时候该做的是把描述写短而不是删 skill。

  How to reason about it · think before answering

  1. It looks like spec recall, but the real question is the why. Listing the constraints is a pass; explaining which engineering problem they prevent is the differentiator.
  2. Name has five constraints: one to sixty-four characters, lowercase letters digits and hyphens only, no leading or trailing hyphen, no consecutive hyphens, and it must match the parent directory name.
  3. Description has two: one to one thousand twenty-four characters, and it must convey both what the skill does and when to use it.
  4. The reason name is strict: it is the skill's identity across the ecosystem, feeding directory lookup, namespacing, slash-command invocation and collision precedence. One casing mismatch becomes an installed but uncallable skill.
  5. Mention the real-world wrinkle: many clients deliberately relax the name-matches-directory rule and only warn, so a skill can work locally and vanish under a stricter implementation.
  6. Expected follow-up: what if the description runs to a thousand characters? You pay for it every session. Twenty maxed-out descriptions cost eight thousand tokens of catalog, so shorten the text rather than dropping skills.

  答题要点

  • name：一到六十四字符、小写字母数字与连字符、首尾不能是连字符、不能有连续连字符、必须等于父目录名。
  • description：一到一千零二十四字符，必须同时说清做什么与什么时候用。
  • name 卡死是因为它是唯一标识，要参与目录查找、命名空间、命令调用与撞名优先级。
  • 很多客户端对 name 做宽松校验，本地能跑不代表换个客户端也能跑。
  • description 是每次会话都要付的固定开销，能短则短。

  Key points

  • Name: one to sixty-four characters, lowercase alphanumerics and hyphens, no leading or trailing hyphen, no double hyphens, must equal the directory name.
  • Description: one to one thousand twenty-four characters, stating both what it does and when to use it.
  • Name is strict because it is the skill's identity for lookup, namespacing, invocation and collision precedence.
  • Many clients validate name leniently, so working locally does not guarantee working elsewhere.
  • The description is a fixed per-session cost, so keep it as short as it can be while still triggering.

D2 写第一个 skill：description 的触发词怎么写、结构怎么分层、怎么装进客户端

• skill 的 description 写得太泛会怎样？太窄又会怎样？你怎么找到中间那个点？What goes wrong when a skill description is too broad, and what goes wrong when it is too narrow? How do you find the middle?

  国内高频海外高频进阶#agent-skills#skill-description

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

  1. 这题的题眼在「代价」两个字。只说「太泛会误触发、太窄会不触发」是把题目复述了一遍，面试官等的是后面那句：误触发到底损失了什么。
  2. 先说太泛的代价，而且要说满三层：这个 skill 的正文白占了上下文位置；它的指令会干扰当前任务；更麻烦的是模型一旦选定了一个 skill，就更不容易再去选真正对的那个。**一个太泛的 skill 会拖累整个技能库**，这一句是拿分点。
  3. 再说太窄的代价：它只在用户按你预想的说法提问时才触发，而真实用户几乎不会那样说话。太窄的 skill 通常不是不好用，是根本没被用过，所以你连它不好用都不知道。
  4. 找中间点的方法要给成一套动作而不是感觉：写覆盖多种说法而不是多个关键词，末尾补一句边界排除相邻能力，然后用一组正例加近似负例把触发率量出来，按结果改描述。
  5. 补一个容易被忽略的事实：有些任务简单到模型觉得自己就能干，这时候描述写得再匹配也不会触发。判断描述好不好之前，先确认这个任务值不值得一个 skill。
  6. 可预期的追问是「改描述时怎么避免过拟合」。答案是不要把失败查询的原话抄进描述，要归纳出它代表的那一类说法，并留一部分查询不参与优化、只用来验证。

  How to reason about it · think before answering

  1. The hinge word is cost. Saying too broad misfires and too narrow never fires just restates the question; the interviewer wants to know what a misfire actually costs.
  2. Give three layers of cost for over-broad descriptions: the body wastes context, its instructions interfere with the current task, and once the model has committed to one skill it is less likely to reach for the right one. One over-broad skill degrades the whole library.
  3. For too narrow: it only fires when the user phrases things exactly as you imagined, and real users never do. Such a skill is usually not bad, it is simply never exercised, so you never learn that it is bad.
  4. Give the middle as a procedure, not a feeling: cover phrasings rather than keywords, add a boundary clause that excludes adjacent capabilities, then measure trigger rate against positives and near-miss negatives and revise from the data.
  5. Add the often-missed fact that agents typically only consult skills for tasks beyond what they handle alone, so a trivially easy task will not trigger no matter how well the description matches.
  6. Expected follow-up: how do you avoid overfitting when revising? Never paste the failing query verbatim; generalize to the category it represents, and hold out a validation split.

  答题要点

  • 太泛的三层代价：占上下文、干扰当前任务、挤掉真正该用的那个 skill。
  • 太窄的代价是根本没被触发过，问题被掩盖，你连它好不好用都测不出来。
  • 写法上覆盖「多种说法」而不是「多个关键词」，末尾补一句边界排除相邻能力。
  • 用正例加近似负例量出触发率，按数据改描述，不靠手感。
  • 任务本身太简单时不会触发任何 skill，这不是描述的问题。

  Key points

  • Three costs of over-broad: wasted context, interference with the current task, and crowding out the correct skill.
  • Over-narrow means it never fires, which hides the problem rather than surfacing it.
  • Cover phrasings rather than keywords, and add a closing boundary clause that excludes adjacent capabilities.
  • Measure trigger rate with positives and near-miss negatives, then revise from the data.
  • A task simple enough for the model alone will not trigger any skill; that is not a description problem.
• skill 的正文应该写什么、不应该写什么？为什么「坑」那一段必须留在 SKILL.md 里而不是挪到引用文件？What belongs in a skill body and what does not, and why must the gotchas stay in SKILL.md rather than move to a reference file?

  国内高频海外高频进阶#agent-skills#skill-authoring

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

  1. 这题考的是你有没有真写过 skill。没写过的人会答「写清楚步骤」，写过的人会先给一条判据。
  2. 判据只有一句：**不写这一条，模型会不会做错？** 不会就是废话，删掉。解释什么是 PDF、什么是数据库迁移，模型本来就知道，写进去纯粹在稀释注意力。
  3. 该写的三类是：项目特有的约定、非显然的边界情况、以及指定用哪个工具或接口。这三类的共同点是模型的通用知识里没有。
  4. 输出格式那一段要单独强调：给模板比用文字描述可靠，因为模型对具体结构做模式匹配的能力远强于读一段散文式的格式说明。
  5. 「坑」为什么不能挪走，答案是一个先后顺序问题：**模型得先知道有坑，才会去查坑**。放进引用文件就要求它在还没撞上的时候预判自己会撞上，这个前提不成立。引用文件适合放「我知道会用到，只是现在还不需要」的材料。
  6. 可预期的追问是「那什么该挪进 references」。答案是长、且用不用得上有明确判断条件的材料，并且正文里必须写出那个条件，比如「接口返回非 200 时读错误码文件」。

  How to reason about it · think before answering

  1. This separates people who have written skills from people who have read about them. The untested answer is write clear steps; the tested answer starts with a test.
  2. The test is one sentence: would the model get this wrong without this line? If not, cut it. Explaining what a PDF is only dilutes attention.
  3. Three things belong: project-specific conventions, non-obvious edge cases, and which tool or API to use. All three are absent from the model's general knowledge.
  4. Call out output format specifically: a concrete template beats prose, because models pattern-match against structures far better than they parse a described format.
  5. Gotchas cannot move because of ordering: the model must know a trap exists before it will look it up. Putting them in a reference file assumes it can predict a collision it has not hit yet.
  6. Expected follow-up: what does belong in references? Long material whose need has a clear trigger condition, and the body must state that condition, such as read the error-code file when the API returns a non-200.

  答题要点

  • 判据是「不写这一条模型会不会做错」，不会就删。
  • 该写：项目特有约定、非显然的边界、指定的工具与接口。
  • 输出格式给模板，不要用文字描述格式。
  • 坑必须留在正文，因为模型要先知道有坑才会去查坑。
  • 引用文件放长材料，且正文必须写出「什么条件下读它」。

  Key points

  • The test: would the model get this wrong without the line? If not, delete it.
  • Include project conventions, non-obvious edge cases, and the specific tool or API to use.
  • Give a template for output format instead of describing it in prose.
  • Gotchas stay in the body because the model must know a trap exists before looking it up.
  • References hold long material, and the body must state the condition for loading each one.

D3 设计方法：从重复任务提炼、检查清单式与参考手册式、四种反模式与触发测试

• 怎么测一个 skill 的 description 好不好？自己试几句话够吗？How do you evaluate whether a skill description is good? Is trying a few prompts yourself enough?

  国内高频海外高频进阶#agent-skills#evaluation

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

  1. 题眼在后半句。答「自己试几句就行」直接出局，但只答「要写测试集」也不够——面试官要看你知不知道这个测试集该怎么设计。
  2. 先说为什么抽查不够：一个 skill 时够用，装到第十个就不行了，因为你既记不住十个描述之间会不会互相抢，也没法在改完一句话后判断是改好了还是改坏了。
  3. 然后给三件东西。第一是带标注的查询集，约 20 条，正负各半。正例要在措辞、显式程度、详略、复杂度四个维度上铺开；**最有价值的正例是那些确实该用但字面看不出来的**，字面已经念了一遍功能的查询任何描述都能命中，测不出区别。
  4. 负例是设计的重点：毫无重叠的句子测不出任何东西，真正有用的是近似负例——共享关键词或概念但目标动词不同。对 CSV 分析 skill，「改 Excel 预算表的公式」和「把 CSV 每行写进数据库」都是好负例。
  5. 第二是重复跑取触发率：模型是不确定的，每条跑三次算命中比例，阈值取 0.5。第三是训练验证拆分，六比四，验证集全程不看。
  6. 可预期的追问是「怎么判断一条查询触发了没有」。答案是把所有 skill 的名字与描述拼成目录，连同这句话交给模型问它该用哪一个——这正是客户端在发现阶段做的事，只是单独拎出来跑。

  How to reason about it · think before answering

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 时够用，多个 skill 互相干扰时完全不够。
  • 约 20 条带标注查询，正负各半，正例在措辞、显式程度、详略、复杂度四维上铺开。
  • 负例必须是近似负例：共享关键词但目标动词不同，无关句子测不出东西。
  • 每条跑三次取触发率，阈值 0.5，因为模型行为不确定。
  • 训练验证六四拆分，训练集指导改写，验证集只用来选版本。

  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.

D4 带脚本的 skill：可执行附件、依赖与沙箱、跨平台，以及文档处理类 skill 的拆解

• 给 Agent 用的命令行脚本，接口设计上和给人用的有什么不同？How does designing a command-line script for an agent differ from designing one for a human?

  国内高频海外高频进阶#agent-skills#scripts#cli-design

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

  1. 题眼是「不同」。能列出五条通用 CLI 最佳实践的人很多，能说清哪几条是因为「使用者是模型」才成立的人少。
  2. 先给根本差异：人会读文档、会试错、会凭经验猜；Agent 只能读你打印的那几行字然后决定下一步。**它的全部信息就是你的输出**。
  3. 由此推出五条。绝对不能交互，这是硬要求不是最佳实践，Agent 在非交互终端里回答不了提示，会一直挂到超时。
  4. 帮助信息就是接口文档，但要短——这段输出原样进上下文，跟别的东西抢位置，这是给人用的 CLI 完全不必考虑的约束。
  5. 错误信息决定它下一次会不会做对：写清哪一项错了、期望什么、实际是什么、可选值有哪些。**错误信息本质上是给模型的提示词**，这一句是拿分点。
  6. 剩下两条：输出结构化并把数据与诊断分流到标准输出与标准错误；输出体量要可控，因为很多 Agent 环境会静默截断超长输出。再补幂等、有意义的退出码、危险操作给预演开关。
  7. 可预期的追问是「怎么验证接口设计得好」。答案是把帮助输出和一条错误信息单独发给一个没看过这个 skill 的人，他能照着敲对改对，模型大概率也能。

  How to reason about it · think before answering

  1. The hinge is the difference. Many can list CLI best practices; few can say which ones exist specifically because the caller is a model.
  2. State the root difference: humans read docs, experiment and guess from experience; an agent has only the lines you printed before deciding the next move.
  3. From that: never prompt interactively. This is a hard requirement, not a nicety, because agents run in non-interactive shells and will hang until timeout.
  4. Help output is the interface documentation, but it must be short, since it enters the context window and competes with everything else. A human CLI never faces this constraint.
  5. Error messages decide the next attempt: say what failed, what was expected, what was received, and which values are allowed. Error messages are effectively prompts for the model.
  6. Then: structured output with data on stdout and diagnostics on stderr, and bounded output size because many harnesses truncate silently. Add idempotency, meaningful exit codes, and a dry-run flag for destructive work.
  7. Expected follow-up: how do you validate the design? Hand the help text and one error message to someone who has never seen the skill; if they can act on it, the model probably can too.

  答题要点

  • 根本差异：Agent 的全部信息就是你打印的输出，它不会读文档也不会试错。
  • 绝不能交互，否则在非交互终端里会挂到超时。
  • 帮助信息就是接口文档，但必须短，因为它原样占用上下文。
  • 错误信息要写清哪项错、期望什么、实际什么、可选值有哪些，它本质是给模型的提示词。
  • 结构化输出并分流标准输出与标准错误，输出体量要可控，危险操作给预演开关。

  Key points

  • The agent's only information is what you printed; it does not read docs or experiment.
  • Never prompt interactively; a non-interactive shell will hang until timeout.
  • Help text is the interface documentation and must be short because it consumes context.
  • Error messages must state the field, the expectation, the actual value and the allowed set; they are prompts for the model.
  • Emit structured data on stdout and diagnostics on stderr, bound output size, and offer a dry-run for destructive operations.

D5 手写一个 skill 运行时：扫描、frontmatter 解析、注入系统提示、按需读取正文

• 如果让你自己给一个 Agent 实现 skill 支持，发现阶段和激活阶段各要做什么？为什么要分成两步？If you implemented skill support in your own agent, what happens in the discovery stage versus the activation stage, and why split them?

  国内高频海外高频进阶#agent-skills#runtime#progressive-disclosure

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

  1. 这题在考你有没有把渐进式加载当成一个可实现的机制，而不是一句口号。只复述「发现、激活、执行」三个词是不够的，要落到每一步读了什么、写进了哪里。
  2. 发现：扫描约定目录，把所有含 SKILL.md 的文件夹找出来，解析出名字与描述，拼成一份清单注入系统提示。**这一步正文一个字都不进来**，清单里只有名字、描述、位置三样。
  3. 激活：模型判断当前任务命中了某条描述，才去读那一份完整的 SKILL.md，把正文放进上下文，同时告诉它技能目录在哪、附带哪些资源文件。
  4. 分两步的理由是成本结构不对称，这是本题的核心句：**披露的成本每一轮都要付，激活的成本只付一次。** 系统提示随每次请求重发，清单每多一个字都要乘会话轮数；正文只在被激活的那一轮进上下文，之后作为历史消息留着。
  5. 由这条不对称性可以顺手解释规范里的硬约束：为什么描述有长度上限而正文没有，为什么描述必须写触发条件而不是使用说明——描述是每轮都在花钱的那一段。
  6. 可预期的追问是「位置这一项能不能省」。不能：模型要靠它知道去读哪个文件，而且它的父目录是正文里所有相对路径的解析基准。

  How to reason about it · think before answering

  1. This tests whether progressive disclosure is a mechanism you could build, not a slogan. Repeating the three stage names is not enough; say what each stage reads and where it writes.
  2. Discovery: scan the conventional directories, find every folder containing SKILL.md, parse out name and description, and assemble a catalog injected into the system prompt. No body text enters here; each entry carries only name, description and location.
  3. Activation: once the model judges that a task matches a description, read that full SKILL.md into context, along with the skill directory path and a list of bundled resource files.
  4. The reason for the split is an asymmetry in cost: disclosure is paid every turn, activation is paid once. The system prompt is resent with every request, so each extra character in the catalog is multiplied by the number of turns.
  5. That asymmetry also explains the spec's hard limits: descriptions are capped and bodies are not, and descriptions must state trigger conditions rather than usage instructions, because the description is the part that keeps costing money.
  6. Expected follow-up: can the location field be dropped? No. The model needs it to know which file to read, and its parent directory is the base for every relative path in the body.

  答题要点

  • 发现阶段扫描目录、解析名字与描述、拼成清单注入系统提示，正文不进来。
  • 激活阶段才读完整 SKILL.md，并附上技能目录与资源文件名清单。
  • 分两步的根据是披露每轮付费、激活只付一次这条不对称性。
  • 这条不对称性解释了描述为什么有长度上限、为什么要写触发条件而不是使用说明。
  • 清单里位置字段不能省，它既是读取目标也是相对路径的解析基准。

  Key points

  • Discovery scans directories, parses name and description, and injects a catalog into the system prompt with no body text.
  • Activation reads the full SKILL.md and adds the skill directory plus a list of bundled resource filenames.
  • The split exists because disclosure is paid every turn while activation is paid once.
  • That asymmetry explains why descriptions are length-capped and must state triggers rather than usage.
  • The location field is required: it is both the read target and the base for relative paths.
• 你的运行时解析到一份不合规范的 SKILL.md，是拒绝加载还是降级加载？另外，两个作用域里有同名 skill 时你怎么处理？When your runtime parses a SKILL.md that violates the spec, do you refuse to load it or degrade gracefully? And how do you handle a name collision across scopes?

  国内高频海外高频进阶#agent-skills#runtime#error-handling

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

  1. 两个小问共用一个立场：**运行时是给人干活的，不是校验器。** 先把这句说出来，后面两半都好答。
  2. 宽松加载这一半要给出可判定的边界，不能只说「尽量宽松」。**唯一的硬性淘汰是缺 description**——少了它这个 skill 在发现阶段没有触发面，永远不会被选中，留在清单里只是白占 token。
  3. 其余一律只告警仍然加载：名字与目录名不一致、名字用了大写或下划线、描述超过上限。它们影响质量，不影响能不能用。
  4. 举一个最常见的畸形做证据：YAML 值里没加引号的冒号会让正规解析器判整行非法，进而拒绝整个文件。正确的兜底顺序是先用完整 YAML 解析，失败了再退回按行取值，只抠出认识的那几个标量字段。
  5. 同名冲突这一半，方向不是重点，**处理方式才是**。跨客户端通行约定是项目级压过用户级，但 Claude Code 的顺序是企业级、个人级、项目级由高到低，两种都合理，关键是固定一种并保持一致。
  6. 最糟的做法是静默丢弃：用户改了项目里那份，行为一点没变，他会去怀疑缓存和保存，就是不会想到别处有个同名的。**必须留一条警告并把两个路径都打出来**，那条日志是排查这类问题的第一现场。
  7. 可预期的追问是「宽松会不会把坏 skill 放进来」。答案是这两件事的层次不同：宽松说的是格式容错，安全靠的是来源信任与工具权限，不能拿格式校验当安全边界。

  How to reason about it · think before answering

  1. Both halves share one stance: a runtime exists to get work done, not to validate. State that first.
  2. For loose loading, give a decidable boundary. The only hard rejection is a missing description: without it the skill has no trigger surface, can never be selected, and only wastes catalog tokens.
  3. Everything else warns and still loads: a name that differs from the directory, a name using capitals or underscores, an over-long description. These hurt quality but not usability.
  4. Cite the most common malformation as evidence: an unquoted colon inside a YAML value makes a strict parser reject the whole file. The right fallback order is full YAML parsing first, then a line-wise field reader that extracts only the scalar fields you know.
  5. For collisions, the direction matters less than the handling. The cross-client convention is project over user, while Claude Code orders enterprise, personal, then project. Both are defensible; pick one and stay consistent.
  6. The worst handling is silent discard. The user edits the project copy, nothing changes, and they suspect caching or a failed save rather than a same-named skill elsewhere. Always log a warning that prints both paths.
  7. Expected follow-up: does loose loading let bad skills in? These are different layers. Looseness is format tolerance; safety comes from source trust and tool permissions, not from schema validation.

  答题要点

  • 立场是运行时不是校验器，默认降级加载。
  • 唯一硬性淘汰是缺 description，因为它没有触发面、永远不会被选中。
  • 名字不一致、名字不合规、描述超长都只记诊断仍然加载。
  • 解析顺序是先完整 YAML、失败再按行取值兜底，专治值里没加引号的冒号。
  • 同名冲突要固定一种优先级并保持一致，绝不静默丢弃，警告里要带上两个路径。

  Key points

  • A runtime is not a validator; degrade by default.
  • The only hard rejection is a missing description, which leaves no trigger surface.
  • Name mismatches, invalid names and over-long descriptions warn but still load.
  • Parse with full YAML first, then fall back to line-wise field reading for unquoted colons.
  • Fix one collision priority, keep it consistent, and never discard silently: log both paths.

D6 组织与分发：插件与市场、版本与团队共享，以及函数调用、MCP、Skills 三者的分工

• 函数调用、MCP 和 Skills 三者的关系是什么？什么时候用哪个？How do function calling, MCP and Agent Skills relate, and when do you use which?

  国内高频海外高频进阶#agent-skills#mcp#tool-calling#architecture

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

  1. 这是本课最高频的一题。答错的典型是把三者摆成竞争关系，说「Skills 比 MCP 更轻量所以更好」——它们解决的根本不是同一个问题。
  2. 先给一句能背下来的分工：**MCP 管接线，Skills 管经验**，而函数调用是接线之前那根最短的线。
  3. 再落到缺口上。函数调用与 MCP 补的是**能力**：模型本来读不到你的数据库、发不出工单，给它工具它就能了。Skills 补的是**经验**：模型本来就会写提交信息，只是不知道你们这儿的格式。能力的缺口用工具补，经验的缺口用技能补。
  4. 然后给两条对比里最有信息量的差异。第一，上下文成本：工具定义每一轮都要重发，而 skill 每轮只有名字与描述，正文按需加载。第二，装不上时的降级：工具与协议是二值的，接不上就没有；**一个 skill 装不上仍然是一份人能读的 Markdown**，这正是它能在几十家客户端铺开的原因——它不要求宿主实现协议，只要求宿主会读文件。
  5. 选型给一条能当场走的流程：先分缺能力还是缺做法。缺能力时按复用面选，只有这一个应用要用就写函数调用，多个 Agent 都要用才值得做成 MCP 服务端。缺做法时按确定性选，靠指令说清楚就写进 skill 正文，结果必须逐字一致就配脚本。
  6. 最后一定要说配合。三者常态是叠着用：MCP 服务端把工单系统接进来成为工具，skill 的正文里写「先用工单查询工具拉出本周工单，再按这份模板归类」。**工具给它手，skill 给它章法。**
  7. 可预期的追问是「那什么时候不该用 MCP」。答案是只有一个应用要用、动作又只有两三个的时候——为它起一个服务端是过度设计，直接写函数调用更短。

  How to reason about it · think before answering

  1. The most common question in this course. The classic mistake is framing the three as competitors and saying skills are lighter than MCP, when they do not solve the same problem.
  2. Lead with the one-line division: MCP handles wiring, Skills handle experience, and function calling is the shortest wire of all.
  3. Then name the gaps. Function calling and MCP supply capability: the model cannot reach your database or file a ticket until you give it a tool. Skills supply experience: the model can already write a commit message, it just does not know your format.
  4. Give the two most informative contrasts. Context cost: tool definitions are resent every turn, while a skill costs only its name and description per turn with the body loaded on demand. Degradation: tools and protocols are binary, but a skill that fails to install is still readable Markdown, which is exactly why the format spread across dozens of clients. It requires the host to read files, not to implement a protocol.
  5. For selection give a runnable decision path. First separate missing capability from missing method. For capability, choose by reuse surface: one application means function calling, several agents justify an MCP server. For method, choose by determinism: instructions go in the skill body, byte-identical results go in a bundled script.
  6. Close on composition. The normal case stacks them: an MCP server exposes the ticket system as a tool, and a skill body says to pull this week's tickets with that tool and then group them by a template. Tools give hands, skills give procedure.
  7. Expected follow-up: when should you not use MCP? When only one application needs it and there are just two or three actions. Standing up a server is over-engineering.

  答题要点

  • 分工是 MCP 管接线、Skills 管经验，函数调用是接线之前最短的线。
  • 能力的缺口用工具或协议补，经验的缺口用技能补，三者不是竞争关系。
  • 工具定义每轮重发，skill 每轮只有名字与描述，正文按需加载。
  • skill 装不上仍是一份人能读的 Markdown，这是它跨客户端铺开的根本原因。
  • 选型先分缺能力还是缺做法：能力按复用面选，做法按确定性选；常态是三者叠着用。

  Key points

  • MCP is wiring, Skills are experience, function calling is the shortest wire.
  • Capability gaps need tools or a protocol; experience gaps need skills. They do not compete.
  • Tool definitions cost every turn; a skill costs only name and description until activated.
  • A skill that fails to install is still readable Markdown, which is why it spread across clients.
  • Choose by capability versus method: capability by reuse surface, method by determinism, and expect to combine all three.
• 一个团队要共享十几个 skill，你会怎么组织和分发？A team needs to share more than a dozen skills. How would you organize and distribute them?

  国内高频海外高频进阶#agent-skills#distribution#team-governance

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

  1. 这题考工程治理，不是考命令。面试官想听的是你按什么切包、按什么选分发路径，而不是背几条安装命令。
  2. 先讲组织。判据是**它们是否一起被采纳、一起被淘汰**：都围着同一套团队规范转、谁装了都得装全套，那就是一个包；一个是团队规范一个是你的个人习惯，凑在一起只会逼别人接受不想要的那半边。十几个 skill 通常应该切成三四个包，不是一个巨包也不是十几个碎包。
  3. 包的两条硬规矩要点出来：**包名就是命名空间**，包里的技能会被前缀成「包名冒号技能名」，撞名问题在这一层解决，所以包名要一次想好；组件目录必须在插件根下，不能塞进放清单的那个目录里，这是官方标出来的最常见错误。
  4. 再讲分发，给三条路径和各自的判据。随仓库走：直接放进项目目录跟着代码提交，零基础设施、评审走原来的流程，但只对这个仓库成立——**只跟某一个代码库有关的规范就选它**。
  5. 走市场：一个仓库加一份清单 JSON，成员各自添加一次，之后按需安装并自动收更新。一处维护多处生效、有版本、有升级说明，代价是要推动每个人添加一次。跨仓库的团队规范选它。**私有就是把市场仓库设成私有，没有中心服务器这回事。**
  6. 走组织托管：管理侧统一下发，不能随便关掉，覆盖率有保证、可审计，但流程重迭代慢，只有必须强制且不装就出事的规范才值得，比如安全合规那几条。
  7. 最后说三条不互斥，稳定组合是安全合规走托管、跨仓库规范走市场、项目独有的怪癖随仓库走。
  8. 可预期的追问是「十几个 skill 会不会把目录撑爆」。答案是发现阶段的开销只和描述总长有关，所以治理重点是**审描述的长度与互斥性**，而不是限制数量。

  How to reason about it · think before answering

  1. This tests governance, not commands. The interviewer wants your criteria for splitting packages and choosing a distribution path.
  2. Organization first. The criterion is whether they are adopted and retired together. Skills orbiting the same team convention belong in one package; a team convention and your personal habit do not, because bundling forces people to take the half they did not want. A dozen skills usually becomes three or four packages.
  3. Name two hard rules. The package name is the namespace, so skills are prefixed as package colon skill, which is where collisions are resolved; pick the name once. And component directories must sit at the plugin root, never inside the manifest directory, which is the documented top mistake.
  4. Then the three distribution paths with criteria. Ship with the repository: commit the skills alongside code, zero infrastructure, reviewed through the existing pull request flow, but scoped to that repository. Choose it for conventions tied to one codebase.
  5. Use a marketplace: a repository plus a catalog JSON, added once per person, then installed on demand with automatic updates. One place to maintain, real versions and upgrade notes, at the cost of getting everyone to add it. Private simply means a private repository; there is no central server.
  6. Organization-managed distribution: pushed centrally and not easily disabled, with guaranteed coverage and auditability, but heavy process and slow iteration. Reserve it for rules that must be enforced, such as security and compliance.
  7. Close by noting the three combine: compliance centrally managed, cross-repository conventions via a marketplace, project quirks with the repository.
  8. Expected follow-up: will a dozen skills blow up the catalog? Discovery cost scales with total description length, so governance means auditing description length and mutual exclusivity, not capping the count.

  答题要点

  • 切包的判据是它们是否一起被采纳、一起被淘汰，十几个通常切成三四个包。
  • 包名就是命名空间，撞名在这一层解决；组件目录必须在插件根下。
  • 只跟一个仓库有关的规范随仓库走，零基础设施但不跨仓库复用。
  • 跨仓库的团队规范走市场，市场就是一个仓库加一份清单 JSON，私有仓库即私有市场。
  • 必须强制的合规规范走组织托管，三条路径可以组合使用。

  Key points

  • Split by whether skills are adopted and retired together; a dozen usually becomes three or four packages.
  • The package name is the namespace where collisions are resolved, and component directories live at the plugin root.
  • Repository-scoped conventions ship with the repository: no infrastructure, no cross-repository reuse.
  • Cross-repository conventions go through a marketplace, which is just a repository plus a catalog JSON; private repo means private marketplace.
  • Mandatory compliance rules go through organization-managed distribution, and the three paths combine.

D7 综合与复盘：把一套团队规范做成 skill 包并驱动子代理完成一次真实任务

• 一份三十页的团队规范文档要拆成几个 skill，按什么切？How many skills should a thirty-page team convention document become, and how do you split it?

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

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

  1. 这题看着开放，其实有明确的对错。答「按章节切」几乎必错，能说清为什么错才是拿分点。
  2. 先给错的那条：**章节结构是为人的阅读顺序服务的**，通常从概念讲到细节；而 skill 的边界必须为触发场景服务——模型是在「用户刚说了一句话」这个时刻决定要不要翻开它。这两种结构几乎从不重合。
  3. 然后给正确的三步。第一步通读文档，只记「什么时候有人会用到这一段」，记场景不记内容，三十页通常能压出十来个场景。
  4. 第二步把场景按**同一个时刻**聚类。提交信息的格式、类型的取值、正文写什么，可能分散在三章里，但都在「我要提交了」这一刻被用到，它们是一个 skill；同一章里的「怎么写提交信息」和「怎么拆提交」是两个时刻，要拆开。
  5. 第三步为每个聚类写一句描述并检查互斥：各写三句会触发的话、两句形似但不该触发的话，跑一遍看有没有互相抢。**抢了说明聚类没聚干净，回第二步。**
  6. 还要主动说一件面试官爱追问的事：**文档里有一大半内容不该进任何 skill**。背景、沿革、当初为什么这么定，对人有价值，对模型是纯负担。判据仍是「不写这条，模型会不会做错」。三十页压成三四百行是正常的。
  7. 最后补一类特殊内容：确定性的规则（类型只能是这六个、版本号必须匹配某个格式）更适合沉淀成校验脚本，正文只留一句「写完跑一次校验」。
  8. 可预期的追问是「到底该切几个」。答案是数量由聚类结果决定而不是先定，但如果切出七八个还互相抢，通常是场景记得太细了；如果只切出一个，说明你还是按文档整体在想。

  How to reason about it · think before answering

  1. It sounds open-ended but has a clear wrong answer. Splitting by chapter is almost always wrong, and explaining why is where the points are.
  2. Chapter structure serves a human reading order, usually concept then detail. A skill boundary must serve the trigger moment, because the model decides whether to open it right after the user speaks. The two structures rarely coincide.
  3. Give three steps. First, read the document recording only when someone would need each passage. Record situations, not content; thirty pages usually yields a dozen situations.
  4. Second, cluster situations by shared moment. Commit message format, allowed types and body content may sit in three chapters but all apply at the moment of committing, so they are one skill. Writing a commit message and splitting commits share a chapter but are two moments, so they split.
  5. Third, write one description per cluster and test mutual exclusivity with three triggering phrases and two near-miss non-triggers each. If they compete, the clustering is not clean; go back to step two.
  6. Raise something interviewers probe: most of the document belongs in no skill. Background and history matter to people and are pure overhead for a model. The test remains whether omitting a line would make the model get it wrong. Thirty pages compressing to a few hundred lines is normal.
  7. Add the special case: deterministic rules such as an allowed type set or a version format belong in a validation script, leaving the body to say run the validator.
  8. Expected follow-up: how many exactly? The count follows the clustering. Seven or eight that still compete usually means the situations were recorded too finely; exactly one means you were still thinking about the document as a whole.

  答题要点

  • 不能按章节切，章节服务人的阅读顺序，skill 边界服务触发时刻。
  • 三步：只记使用场景、按同一个时刻聚类、写描述并用正负例查互斥。
  • 互相抢说明聚类没聚干净，要退回重聚，不是改描述糊过去。
  • 文档里一大半内容不进任何 skill，判据是不写这条模型会不会做错。
  • 确定性规则沉淀成校验脚本，正文只留一句跑校验。

  Key points

  • Do not split by chapter: chapters serve reading order, skill boundaries serve trigger moments.
  • Three steps: record situations, cluster by shared moment, write descriptions and test with positive and negative examples.
  • Competing descriptions mean bad clustering; go back rather than patching the wording.
  • Most of the document enters no skill; the test is whether omitting it would cause a mistake.
  • Deterministic rules become a validation script, leaving one line in the body.