SKILL.md 怎么写：把人工操作流程改写成智能体 Skill 的提示词（触发描述、步骤、判断点、参考文件拆分）
团队里有一套反复执行的流程（发版步骤、周报整理、代码评审清单、客户资料核对），想沉淀成智能体可以按需加载的 Skill 时用：把现有的流程文档或口头步骤交给 AI，它改写成结构清楚的 SKILL.md——什么情况下启用、按什么顺序做、遇到分支怎么判断、哪些内容拆到附属文件，并指出原流程里只有老员工才知道的隐含知识。
通用大模型 对话模型通用
【角色】你是为团队编写智能体 Skill 的工程师。你知道写给人看的流程文档默认读者有背景知识、会自己判断，而写给智能体的 Skill 必须把触发条件、判断依据和完成标准都写出来。 【输入】 - 现有流程（文档原文，或一位熟手口述的步骤）：[现有流程] - 这个流程什么时候会被用到（用户通常怎么提出需求）：[使用场景与说法] - 智能体在其中可用的工具与权限：[可用工具与权限] - 流程中用到的模板、脚本、清单等材料：[已有材料] - 所用平台对 Skill 的格式要求：[平台格式要求] 【任务】 1. 先判断适不适合做成 Skill：这个流程是否会重复出现、步骤是否相对稳定、是否有智能体自己无法推断的团队约定。不适合的话说明更合适的形式（写进项目说明文件、做成脚本、保持人工）。 2. 挖出隐含知识：逐步检查原流程，列出「熟手默认知道但文档没写」的内容——前置条件、判断标准（什么算「没问题」）、例外情况、做完后要通知谁——整理成问题清单问我；我没回答的部分在成稿中标【待确认】。 3. 写元信息： - 名称：简短、小写、用连字符； - 描述：一两句话，说明这个 Skill 做什么、在什么情况下应当使用，包含用户常用的说法作为触发线索；同时写明不适用的相近情况，避免误触发。 4. 写正文，建议结构： - 适用范围与前置检查（不满足时怎么办）； - 步骤：每步写清动作、用到的工具或材料、这一步完成的判断标准；需要判断的地方写成「如果……则……否则……」； - 需要先征得用户确认才能做的动作（对外发送、删除、发布等）； - 完成标准与最终汇报应包含的内容； - 常见问题与处理。 5. 拆分建议：正文只保留每次都要用的内容；篇幅长的参考资料、模板、示例放到附属文件，在正文里用一句话说明什么时候去读哪个文件；能确定性完成的步骤（格式转换、校验）建议做成脚本而不是让模型每次重新写。 6. 解释每条关键规则背后的原因（一句话即可），让智能体在遇到流程没覆盖的情况时能据此判断，而不是只会机械执行。 7. 给出 4–6 条测试用的用户请求：应当触发并走通的、应当触发但会走到分支的、相近但不应触发的，分别写明期望行为。 【约束】 - 不替我编造流程中没有的步骤或团队规定；发现流程本身有漏洞时单独指出，由我决定是否修改。 - 格式以我提供的平台要求为准；我没提供时按「带名称与描述的元信息 + Markdown 正文」的常见形式写，并提醒我核对所用平台的文档。 - 正文不写口令、密钥等凭据内容，只写它们存放的位置。 【输出格式】适用性判断 → 隐含知识问题清单 → SKILL.md 全文 → 附属文件与脚本拆分清单 → 测试请求表。
高亮处换成你自己的内容：[现有流程]、[使用场景与说法]、[可用工具与权限]、[已有材料]、[平台格式要求]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[现有流程] 可以直接贴团队文档，也可以让最熟悉的人口述一遍后贴转写稿，口述版往往包含更多「其实还要看一下……」的隐含步骤。[使用场景与说法] 写用户平时怎么开口，例如「帮我发个版」「出一下这周的周报」，这些说法会写进描述里帮助触发。[平台格式要求] 从所用产品的文档里复制关于 Skill 文件结构的说明；拿不准就留空，模型会按常见形式写并提醒核对。
常见失败与调整：
- 描述写得太宽（「处理各类文档」），导致不相关的请求也触发；或太窄，用户换个说法就不触发。用第 7 步的测试请求来回调整描述。
- 把几十页的规范全文塞进正文。正文越长，每次加载占用的上下文越多，按第 5 步拆到附属文件。
- 通篇都是「必须」「严禁」，却不说原因。遇到没覆盖的情况时模型无从判断，补上第 6 步的理由。
追问：「根据我对隐含知识问题的回答，更新 SKILL.md」「把其中的校验步骤写成一个脚本，并在正文里改为调用它」。
示例输出
示例，仅供参考（虚构：把「每周客户周报」流程改写成 Skill）
markdown
---
name: weekly-client-report
description: 按团队模板整理每周客户周报。当用户说「出周报」「整理本周给客户的进展」或提供本周工作记录并要求汇总时使用。不用于内部站会纪要或月度总结。
---
# 每周客户周报
## 前置检查
- 确认用户提供了本周工作记录；没有则先询问，不要凭空编写进展。
## 步骤
1. 读取 `templates/report.md` 作为版式。
2. 把工作记录归入「已完成 / 进行中 / 风险与需客户配合」三栏。
- 如果某项没有明确状态，归入「进行中」并标【待确认】。
3. 数字（工时、完成数量）只使用记录里出现的，原因：周报会被客户当作结算依据。
4. 生成草稿后交给用户确认。**发送给客户前必须得到用户明确同意。**
## 完成标准
三栏齐全、无【待确认】残留、用户已确认草稿。不应触发的测试请求：「帮我写一下今天站会的纪要」——期望行为是不加载本 Skill。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～