什么时候用
描述适用场景，让 Agent 能判断当前任务是否应该加载这个 Skill。
面向程序员 · Agent 工程实践课
Agent Skill：沉淀可复用工作流
一次 prompt 能解决一次问题，Skill 解决的是“这类问题以后都怎么稳定解决”。它把触发场景、执行步骤、参考资料、脚本工具、输出标准和验收清单写成 Agent 能读懂的工作说明书。
把经验显性化
不要把流程只留在人的脑子里，而是写成 Agent 可执行的说明。
把重复任务标准化
PRD、评审、排障、周报、资料整理，都可以沉淀成稳定流程。
把资料和工具打包
Skill 可以引用脚本、模板、参考文档和素材，避免每次重新找。
把质量检查写进去
好的 Skill 不只说怎么做，还会说明怎样判断结果是否达标。
repeatable workflow
SKILL.md
一次成功任务
人工反复解释背景、流程、模板和验收口径。
→
Skill 化
触发条件、步骤、材料、工具、检查项写进说明书。
Agent 执行
遇到同类任务时自动加载相关流程和资料。
→
稳定输出
产物结构一致、质量可检查、流程可迭代。
scripts
自动化动作
自动化动作
references
参考资料
参考资料
templates
输出模板
输出模板
01 · 先给定义
Skill 是给 Agent 的可复用工作说明书
它不是让模型“更聪明”的魔法，而是把某类任务的做法写清楚：什么时候用、先做什么、再做什么、用什么资料、调用什么工具、最后怎么检查。
怎么做
把流程拆成可执行步骤，不只写原则，也写顺序、判断和例外情况。
用什么
放脚本、参考资料、模板、样例、检查表，减少重复查找和重复解释。
怎样算好
说明验收标准、常见错误、输出格式和自检方式，让结果更稳定。
一句话面试版
可直接背
Agent Skill 是把一类重复任务的经验、流程、资料和验收标准沉淀成可复用说明书。它让 Agent 在遇到同类任务时，不用重新猜做法，而是按已经验证过的流程稳定执行。
02 · 价值判断
Skill 的核心价值，是让好做法不只发生一次
如果每次都靠临时 prompt，质量容易受提问方式、上下文完整度和个人经验影响。Skill 把稳定做法固化下来，降低重复沟通成本。
每次都要重新讲一遍
用户要反复说明背景、规则、模板、检查项。换一个人提问，输出结构可能就变了；换一个场景，Agent 还可能漏掉关键步骤。
流程变成团队资产
触发场景、执行顺序、资料入口、输出模板和验收标准都在 Skill 里。以后同类任务可以按同一套口径执行和迭代。
企业里最适合沉淀的场景
高频
- 1需求类：从需求描述、知识库资料、接口文档生成 PRD 或评审材料。
- 2研发类：排查错误、做代码评审、生成测试用例、整理发布说明。
- 3运营类：生成周报、分析用户反馈、整理竞品调研、输出 FAQ。
- 4治理类：安全检查、文档规范检查、数据质量检查、上线前核对。
03 · 概念区分
Prompt、Tool、MCP、Skill 各管一层
面试时不要把这些概念混在一起。它们经常组合使用，但解决的问题不同。
这次要做什么
一次性任务指令，例如“帮我把这段需求整理成用户故事”。它更像临时任务单。
实际能做什么
外部能力，例如查数据库、调接口、读文件、跑测试。Tool 是动作能力。
怎么标准连接工具
把外部数据、工具、模板用标准协议暴露给 AI 应用，解决连接和能力发现问题。
这类事以后怎么做
沉淀流程、判断、模板、材料和验收标准，让 Agent 按稳定方法执行。
一句话总结
边界
Prompt 是一次任务单，Tool 是可执行能力，MCP 是标准连接协议，Skill 是可复用工作流。一个完整 Agent 往往会用 prompt 接收任务，用 skill 选择做法，用 MCP 或工具访问外部系统，最后按质量标准交付结果。
04 · 适用判断
不是所有事情都值得写成 Skill
Skill 的价值来自复用。如果任务很少出现、流程还没稳定、只是一次性闲聊，就没必要沉淀。先判断复用价值，再决定是否写 Skill。
适合写 Skill
- 1重复出现：每周、每天或每个项目都会做。
- 2流程稳定：步骤、模板、检查项已经比较清楚。
- 3质量要求高：输出格式、口径、证据和校验不能随便变。
- 4依赖资料工具：需要固定参考文档、脚本、模板或内部系统。
暂时不适合
- 1只是一次性问题，没有明显复用机会。
- 2流程还在探索，经常大幅变化。
- 3只需要普通常识回答，不需要特殊材料和规则。
- 4说明书比任务本身还复杂，维护成本高于收益。
判断公式
实用
如果一个任务同时满足“高频、稳定、有规则、有材料、质量要统一”，就很适合 Skill 化。如果只是偶尔问一次，先用 prompt 解决就够了。
05 · 文件结构
一个 Skill 通常从 SKILL.md 开始，再按需加资料和脚本
不要一上来就堆很多文件。先把触发场景和流程写清楚，再把真正能减少重复工作的资料、脚本、模板放进去。
skill folder
结构示例
prd-from-requirement/
SKILL.md
references/
prd-quality-checklist.md
enterprise-system-context.md
templates/
prd-template.md
interview-answer-template.md
scripts/
extract-doc-outline.js
validate-prd-fields.js
assets/
flow-example.png
每个部分放什么
拆开看
| 部分 | 用途 |
|---|---|
SKILL.md |
核心说明书：触发场景、步骤、规则、质量标准。 |
references/ |
参考资料：规范、背景、检查清单、领域知识。 |
templates/ |
输出模板：PRD、周报、评审意见、测试报告。 |
scripts/ |
自动化脚本：解析、校验、转换、批量处理。 |
assets/ |
素材：图例、样例文件、截图、设计资源。 |
06 · 触发描述
description 写不好，Skill 就可能该用不用、不该用乱用
触发描述是 Agent 判断是否加载 Skill 的入口。它要写清楚适用任务、典型触发词、边界和不适用场景。
“用于写好文档”
太宽。什么文档、什么场景、什么输出、什么时候不该用都没说。Agent 很难判断是否加载，也容易把无关任务拉进来。
“从需求描述和企业资料生成 PRD”
明确用于产品需求分析场景：读取需求描述、检索知识库、对齐企业系统现状，输出结构化 PRD，并包含验收标准和风险点。
description example
触发描述
---
name: prd-from-requirement
description: Use when the user wants to turn a product requirement description,
business idea, interview scenario, or rough feature request into a structured PRD
grounded in existing enterprise systems, knowledge base materials, constraints,
user flows, data fields, edge cases, acceptance criteria, and risks.
---
Use this skill only for product requirement analysis and PRD generation.
Do not use it for general article writing, casual brainstorming, or code review.07 · 工作流设计
Skill 不是写愿望，而是写可执行步骤
“认真分析、输出专业结果”不是工作流。真正有用的 Skill 会告诉 Agent 先问什么、查什么、怎么判断、怎么产出、怎么自检。
1
识别输入
用户给的是完整需求、模糊想法、现有文档，还是面试题。
2
补齐信息
缺目标、用户、范围、约束时，先追问或标记假设。
3
查资料
读取知识库、接口文档、历史案例、业务规范和系统限制。
4
生成产物
按模板输出，不让结构随模型发挥。
5
质量自检
检查完整性、一致性、证据、风险、可执行性。
写步骤时的原则
具体
- 1用动词开头：读取、对比、提取、校验、生成、复核。
- 2写判断条件：如果缺关键字段，先追问；如果资料冲突，列出冲突。
- 3写产物形态：表格、JSON、PRD、评分表、清单、报告。
- 4写停止条件：什么时候可以交付，什么时候必须说明不确定。
08 · 材料组织
脚本、资料、模板只放真正能提高稳定性的东西
Skill 不是资料仓库。不要把所有东西都塞进去。只放 Agent 反复需要、难以临时推断、会影响结果质量的材料。
适合机械稳定的动作
例如解析 Excel 字段、检查 PRD 必填章节、生成目录、批量转换格式。脚本减少手工错误。
适合领域固定知识
例如企业系统现状、接口规范、字段字典、权限规则、风控要求、历史案例。
适合统一输出结构
例如 PRD 模板、评审模板、日报模板、测试报告模板。模板让产物更可比。
材料选择检查
克制
- 1这份材料是否在多数任务里都会用到？
- 2没有它，Agent 是否容易漏步骤或输出不一致？
- 3它是否比写在正文里更适合单独维护？
- 4它是否过期风险高，需要标记版本和维护人？
09 · 质量标准
好 Skill 的标准是“能触发、能执行、能检查、能迭代”
不要只看文字写得漂亮。Skill 的价值要看它能否稳定帮 Agent 做成事。
该用时能用，不该用时不会乱用。description 要具体、有边界。
每一步都能落地，不停留在“专业、全面、深入”这种空话。
参考资料、脚本、模板有清晰路径、用途和更新方式。
有输出格式、质量检查、失败处理和人工复核点。
好 Skill 的样子
- 1触发描述能让 Agent 判断适用场景。
- 2步骤清楚，能处理缺信息和资料冲突。
- 3输出有模板，检查有清单。
- 4依赖资料按需加载，不把全部内容一次塞给模型。
坏 Skill 的样子
- 1描述宽泛，什么任务都想管。
- 2正文全是口号，没有可执行步骤。
- 3材料堆太多，Agent 不知道该读哪份。
- 4没有验收标准，输出好坏只能凭感觉。
10 · 迭代维护
Skill 要从真实任务里长出来，再用真实反馈迭代
不要凭空设计一个完美 Skill。最好的做法是先完成几次真实任务，找出稳定步骤，再沉淀，再验证。
1
记录成功案例
保存一次高质量输出和完整操作过程。
2
抽取稳定步骤
把每次都要做的动作、判断和材料提出来。
3
写成初版 Skill
先小而准，不要一开始覆盖所有边界。
4
用新任务试跑
观察触发是否准确、步骤是否可执行、输出是否稳定。
5
补规则和材料
把失败案例变成新的判断、检查项或参考资料。
版本管理建议
团队协作
- 1每次改动说明原因：触发误判、步骤遗漏、模板升级、资料更新。
- 2保留几个标准测试任务，用来回归验证 Skill 有没有退化。
- 3资料类文件标记维护人和更新时间，避免 Agent 使用过期资料。
- 4复杂 Skill 拆成小 Skill，不要让一个说明书同时管十种任务。
11 · 团队治理
Skill 一旦进入团队，就要按知识资产来管理
个人用 Skill 可以灵活，团队用 Skill 要考虑命名、归属、权限、版本、评审和淘汰机制。
名称要反映任务
用 prd-from-requirement 这种任务型命名，少用 awesome-writer 这种泛化命名。
资料边界要清楚
Skill 引用内部资料时，要说明哪些角色可用、哪些数据不能外发。
上线前要试跑
至少用 2 到 3 个真实任务验证触发、流程、输出和异常处理。
过期 Skill 要下线
业务规则变了、资料过期了、长期没人用，就要更新或归档。
团队 Skill 评审清单
Checklist
- 1是否有明确触发场景和不适用场景？
- 2是否引用了敏感资料？是否说明权限和脱敏规则？
- 3是否能用标准任务稳定复现预期结果？
- 4是否有维护人、版本记录和过期检查机制？
12 · 企业案例
把“需求描述生成 PRD”沉淀成 Skill
这个例子能把前面课程串起来：需求描述、查资料、企业知识库、RAG、MCP、结构化输出，最后形成高质量 PRD。
1
原始任务
用户输入“产品批量导入失败后，如何展示失败明细，并生成一版 PRD”。
2
沉淀触发
凡是用户要把粗略需求、业务想法或面试题整理成 PRD，就加载这个 Skill。
3
固定流程
先澄清目标和范围，再查知识库、接口文档、权限规则，最后按模板生成 PRD。
4
质量检查
检查背景、用户故事、流程、字段、异常、埋点、验收标准、风险是否完整。
SKILL.md sketch
核心片段
---
name: prd-from-requirement
description: Use when turning rough product requirements, interview scenarios,
or business feature ideas into structured PRDs grounded in enterprise context.
---
Workflow:
1. Identify product goal, user group, business scope, and missing assumptions.
2. Search enterprise knowledge base for existing modules, APIs, constraints, and policies.
3. Compare the new request with current system behavior.
4. Generate PRD using templates/prd-template.md.
5. Validate with references/prd-quality-checklist.md.
Quality bar:
- Every key requirement must map to user value or system constraint.
- Unknown facts must be marked as assumptions.
- Output must include edge cases, permissions, data fields, and acceptance criteria.
这个案例的讲解重点
面试友好
Skill 不负责凭空知道企业系统现状。它负责把“查资料、对齐现状、组织 PRD、做质量检查”的流程固定下来。真正的资料来自知识库、接口文档、MCP Server 或人工提供的上下文。
13 · 面试问答
回答要体现“流程资产化”的思路
面试官问 Agent Skill，通常不是只想听“它是一个文件”。更重要的是看你是否理解可复用流程、质量标准和团队维护。
Q1：Agent Skill 是什么？
A：Agent Skill 是给 Agent 的可复用工作说明书。它定义某类任务什么时候触发、按什么步骤执行、需要哪些参考资料或脚本、最终输出什么，以及怎样检查结果是否达标。
Q2：Skill 和 Prompt 有什么区别？
A：Prompt 更像一次性任务单，解决“这次让 AI 做什么”；Skill 更像长期沉淀的流程，解决“这类任务以后怎么稳定地做”。Prompt 可以临时写，Skill 适合高频、稳定、有规则、有质量要求的任务。
Q3：什么时候应该把流程沉淀成 Skill？
A：当任务重复出现、流程相对稳定、需要固定资料或工具、输出质量需要统一时，就适合写 Skill。比如 PRD 生成、代码评审、故障排查、发布说明、知识库问答评测。
Q4：一个好 Skill 应该包含什么？
A：至少要有清晰的触发描述、可执行步骤、必要资料或脚本、输出格式和质量检查清单。如果是团队使用，还要有维护人、版本记录和权限说明。
Q5：怎么判断 Skill 写得好不好？
A：看四点：触发是否准确、步骤是否可执行、材料是否可维护、结果是否可验证。好 Skill 应该让不同人、不同时间执行同类任务时，产物结构和质量都比较稳定。
14 · 练习和速查
练习目标：把一次任务变成一份可复用说明书
学完这一课，至少要能从一个真实任务里抽取触发条件、流程、材料和验收标准。
会议纪要 Skill
写出触发描述、输入要求、输出模板和质量检查项，注意区分事实、决议和待办。
故障排查 Skill
设计一个排查流程：收集现象、看日志、找变更、提出假设、验证根因、输出复盘。
PRD 生成 Skill
列出需要放进 references、templates、scripts 的材料，并说明每份材料的作用。
一页速查卡
复习
- 1Skill 是可复用工作说明书，不是一次性 prompt。
- 2适合沉淀高频、稳定、有规则、有材料、有质量要求的任务。
- 3核心结构：触发描述、执行步骤、参考资料、脚本模板、质量检查。
- 4好 Skill 要能触发准确、步骤可执行、材料可维护、结果可验证。
- 5团队使用时，要管理命名、权限、版本、评审、维护人和过期机制。