考察点
这道题出自蚂蚁集团智能体与大模型应用方向的一面（2026 年牛客面经），是项目深挖题，面试官默认你简历上写了 skill 相关的工作，现在要验货。考察分两层："怎么实现的"看技术细节——skill 的载体格式、加载机制、触发方式，答不出来说明没真做过；"怎么写的"看方法论——怎么选题、怎么写 description、怎么迭代。这一问的关键是讲出写 skill 和写普通 prompt 的区别：skill 的核心不在正文在召回，description 决定它会不会在对的时机被用起来。追问常往"skill 没按预期触发怎么办""skill 之间冲突怎么办"上走。
参考答案
Skills 的实现方式
我们项目的 skill 借鉴了 Claude Code 的 Agent Skills 规范，每个 skill 是一个目录，结构很简单：一个 SKILL.md 加若干可选的资源文件（脚本、模板、参考文档）。SKILL.md 分两部分：YAML front matter 和正文。front matter 里最关键的是 name 和 description，description 我们要求写成触发条件式的，比如"当需要为后端接口编写集成测试时使用，覆盖正向流程与至少三类异常分支"；此外还可以声明该 skill 允许调用的工具子集。正文是流程本身：步骤、判断标准、验收清单，正文里用相对路径引用同目录的脚本和模板。
加载机制是渐进披露的三层结构。agent 启动时，扫描 skills 目录，只把每个 skill 的 name 和 description 拼进系统提示——几十个 skill 也就几百 token，这是常驻成本。模型在对话中判断当前任务匹配某个 skill 时，主动调用文件读取工具加载该 skill 的完整正文，这是第二层。正文里提到的脚本（比如一个生成测试脚手架的 Python 脚本）不预加载，模型执行到那一步才通过 bash 调用，这是第三层。触发方式有两种：模型按 description 自主匹配，这是常态；也支持显式触发，用户在指令里直接点名 skill 名。
实现上有个细节值得说：我们给 skill 加载加了 trace 埋点，每次"哪个 skill 被触发、在第几轮触发、触发后任务是否成功"都记下来，这是后续迭代的依据。
我是怎么写 skills 的
第一步是选题，原则是从重复劳动中抽象，不从想象中发明。我维护一个观察清单：哪些任务 agent 反复在做、每次都要我重复交代同样的要求（比如"写提交信息要带关联 issue 号""改完接口记得更新文档"），出现三次以上就值得固化成 skill。反过来，只用过一次的流程写成 skill 是负资产——多了以后稀释召回准确率。
第二步是写 description，这是整个 skill 里 ROI 最高的几十个字。我踩过的坑是写成功能罗列（"本 skill 提供代码评审功能"），结果该触发不触发。有效的写法是站在模型决策视角回答"什么时候该用我"：明确任务类型、触发信号、甚至排除条件。写完我会在测试集上验证召回率。
第三步写正文，三条经验。一是给标准不给空话，"代码要健壮"没用，"所有外部输入必须校验、错误返回携带 trace ID"才有用；二是能脚本化的不写成文字，让模型每次按文字描述生成一个复杂命令，不如直接给个脚本让它调用，确定性高还省 token；三是带验收清单，让 agent 做完能自查，这也是评测的抓手。
第四步是迭代，靠 trace 驱动。skill 上线后我定期看两类失败：该触发没触发（改 description），触发了但执行走偏（改正文）。skill 不是写完就完的文档，它和代码一样有生命周期，我们仓库里 skill 的修改频率不比业务代码低。
可能的追问
skill 触发不准怎么办？ 先看 trace 归因：没触发是 description 的召回问题，触发错了是区分度问题（和别的 skill 描述太像），触发后做错是正文问题。前两者改 front matter，后者改正文，别混着改。
skill 和直接写在系统提示词里的规则怎么分工？ 系统提示词放全局、无条件遵守的约束（安全红线、输出语言）；skill 放条件触发的流程知识。判断标准：这条知识是"永远生效"还是"特定场景才需要"，后者放 skill 里按需加载。
skill 数量膨胀后怎么治理？ 定期清理低触发率的 skill，合并职责重叠的；数量到上百个时在 description 之前加一层轻量检索（按任务域分组或向量召回），但几十个规模内渐进披露本身就够了，别过早引入复杂机制。