什么时候该把重复任务做成 Agent Skill？五道判断关卡

运营团队请 AI 助手核对本周促销 SKU 清单。下周一，又来了同类请求，但文件和市场换了。有人提议把上次的整段对话保存成“Agent Skill”。关键不在于同一主题出现两次，而在于触发条件、必备输入、操作步骤和合格结果是否会稳定重复。

OpenAI 的 Build skills 文档把 Skill 描述为包含任务专用指令、资料和可选脚本的工作流包。ChatGPT 与 Codex 可先根据名称和描述选择 Skill，选中后再加载完整 SKILL.md。Skill 是可复用的做事方法，不会自动增加权限、记住上周客户资料，也不能证明所用数据仍然有效。

上下文图回答一次模型请求带入了哪些材料；工具调用契约约定操作结构与后端校验；MCP Server 准入检查一项外部集成暴露了什么能力。本页只判断一条工作方法是否稳定到值得封装和维护。需要外部状态时，Skill 应指定权威来源，而不是假装自己记得上周那份文件。

写 Skill 前先过五道关卡

找近期几次同类任务，至少包括一条困难或失败案例，把观察到的事实填进下方设计卡。五道关卡是本站的实务判断法，并非 OpenAI 要求写进 SKILL.md 的五个字段。

关卡	支持封装的证据	应收窄或暂缓的信号
触发	一句简洁描述能区分应触发与相近却不应触发的请求。	“处理采购”可能是查资料、谈判、法律审阅或批准付款。
输入	必需文件、日期、范围和权威来源能列清；缺输入时知道下一步。	Agent 必须猜账户、市场、文档版本或适用规则。
步骤	顺序与关键分支基本重复；脚本的输入和报错行为清楚。	每次都要临时发明不同的调查或作广泛判断。
验收	同事能检查输出字段、证据位置和严重失败条件。	只有“看起来有帮助”一条标准。
维护	有人负责来源或流程变化后的修改、复测和停用。	旧规则、失败运行和过期说明都无人处理。

某一关不过，不代表任务完全不能用 AI。它可能更适合一次性任务说明、更窄的子任务、确定性程序，或直接交给人。尤其不要把尚无稳定依据的法律、财务判断封装为 Skill，让它看起来像已经有了标准答案。

选能复用的最小形式

如果核心工作只是用结构化输入做固定计算，应先实现并测试脚本或普通流程。Skill 可以说明 Agent 何时运行脚本、使用哪些获批输入、怎样处理异常，但不应把可确定性检查的逻辑改成一大段模糊文字。若任务需要选择步骤，而这些选择有稳定边界，Skill 才更有价值。一次性问题或触发范围难以区分时，先在当前任务中写清指令，同时积累案例。

官方文档要求 SKILL.md 至少有 name 和 description 元数据，脚本、参考资料和素材均可选。隐式触发要靠描述匹配，因此把用途和排除范围放在描述前面。正文保持聚焦：需要什么输入、按什么顺序做、何时停、产出什么、如何检查。本页卡片要求填的负责人、测试日期、变更信号和停用决定，是本站的维护选择，不表示官方强制 Skill 元数据必须有版本或失效日。

Skill 可以写“调用获批的目录读取工具”，但不能凭这句话授予工具权限；后端仍需核对身份与范围。它也可以要求“读取当前商品目录快照”，但 Skill 本身不是可信的跨会话记忆。要决定哪些事实可以持久保存，可另用记忆生命周期方法；执行权限由系统的沙箱和审批机制控制。

测触发，也测实际结果

准备一条应该选中 Skill 的正向请求、一条很相近却不该选中的反向请求，以及一条缺少必备输入的请求。描述匹配不保证一定隐式触发；记录漏触发和误触发，再修改描述与边界。关键流程也可以显式指定 Skill。随后用代表性案例跑完整流程：助手有没有追问缺失材料、选对获批来源版本、填全约定字段，并在边界处停下？与现有人工或脚本基线比较；只有减少反复解释或错误、又不扩大任务范围，封装才有意义。

记录复测信号：输入格式、政策、来源系统、脚本或验收规则变化；负向请求开始误触发；正常案例失败。发生变化就重新复核。“已经安装”不是质量结论。没有维护人的大资料夹，反而可能变成旧指令的来源。

案例一：每周促销 SKU 核对

一家虚构零售商每周收到促销 CSV、获批的商品目录快照和市场代码。重复工作是找出缺失 SKU、重复行、下架商品和市场不匹配项，并生成带原始行号的异常表。触发条件应写窄：“把本周促销 SKU 导出与已批准目录核对。”它不包括设置折扣比例、批准活动或编辑商品目录。

Skill 可以验证周次与市场、定位获批快照、运行确定性对比脚本，再把异常交给人复核。若目录版本缺失，应暂停执行并要求补齐目录版本，不能沿用上周资料。团队测试普通文件、重复 SKU、市场错配，以及一条“批准降价”的相近请求。前三项应产生可核查的行；降价请求不应触发本 Skill。CSV 结构或商品状态码变化时，由运营负责人更新卡片并重测。

案例二：跨地区供应商条款审阅

一家虚构采购团队经常请助手“审阅供应商条款”，文件横跨不同语言、司法辖区、续约机制和谈判例外。没有一条简短而稳定的流程能够判断某条款在法律上能否接受。建立宽泛的“供应商批准 Skill”，只会遮住仍需专业判断的部分。

其中有一项子任务比较稳定：从已提供的条款中抽取明示的生效、续约、通知和终止日期。窄范围 Skill 可以要求文档版本与地区，逐项输出日期、准确条款位置与原文；模糊或缺失的日期须标记，不自行作法律解释。测试一条明确日期、一条藏在自动续约条款中的日期，以及“30 日内”这种基准日不明的语句。法务复核抽取结果，并判断该地区的法律含义。若用户问“能否签署”，日期抽取 Skill 可以准备表格，却不能给出批准结论。

不适用边界

这张卡只判断是否值得封装一套重复指令，以及怎样测试触发和结果。它不授权工具、不认证 MCP Server、不在会话之间保存个人或业务事实，也不能代替专业人员的判断。案例均为虚构。工作表草稿保存在当前浏览器，只填合成案例编号、脱敏摘要和受控证据位置；真实供应商合同、商业条件与客户文件留在获准系统中。