一项任务终于跑通后，团队最自然的动作是什么？
保存聊天记录，整理出最后一版 Prompt，发到群里，再告诉同事：“下次照这个做。”
可轮到第二个人执行，结果还是可能不稳定。输入看起来差不多，步骤也照着走了，输出却换了样子。换个模型，之前踩过的坑还会再踩一遍。
问题往往不在那段 Prompt，而在团队分享的只是一次答案，没有把成功的条件一起交出去。
任务当时用了哪些资料？人在哪一步纠正了方向？什么操作不能做？出现哪种情况必须停？最后凭什么判断可以交付？这些信息通常散落在对话、文件和人的判断里。
所以，一次成功只能证明这次做对了。只有成功条件能够复现，失败能够识别，结果能够验收，它才开始从个人经验变成团队能力。
这正是 Agent Skill 值得讨论的地方。但重点不是“多写几个 Skill”，而是学会判断：什么经验值得沉淀，以及怎样证明它真的比原来的做法更可靠。
Skill 不是一段更长的 Prompt
聊天记录适合回看一次过程，Prompt 适合描述眼前这次请求。Skill 要解决的是另一件事：当 Agent 遇到某一类任务时，它能知道何时调用一套方法、开始前需要什么、按什么步骤执行，以及怎样检查结果。
在 Agent Skills 的开放格式中，一个 Skill 至少是一个包含 SKILL.md 的目录，还可以按需附带脚本、参考资料和模板等资源。
这里有个很容易被忽略的细节：description 不只是功能介绍，还要说清楚“什么时候使用”。如果它与同事在真实工作中的表达对不上，Skill 可能该出现时没有出现，也可能在看似相近、其实不适用的任务上被误触发。
这就是“存下一段好 Prompt”和“沉淀一项能力”的差别：
-
Prompt 保存的是当前任务怎么说；
-
Skill 保存的是一类任务何时开始、如何执行、怎么判断完成。
但不要因此把所有约定都塞进 Skill。
跨任务持续生效的安全要求，更适合放进规则；某类任务的方法适合 Skill；外部系统连接应由工具或 MCP 承担；字段、数量和文件存在性等机械检查适合交给脚本；高风险取舍和主观质量判断仍要留给人。
这些机制可以组合，不是互斥分类。Skill 的价值也不是包办一切，而是把它们接成一套可以重复运行的方法。
还要注意，开放格式只是提高了迁移的可能性，不代表一个 Skill 能在所有客户端原样使用。不同产品支持的扩展字段、脚本环境、权限和执行能力可能不同。跨工具复用前，仍要查看目标产品当日文档，并用真实任务测试。
先别写模板，回放一次真实成功
团队准备做 Skill 时，一个常见动作是打开空白文档，让模型直接生成一套“最佳实践”。
这样的内容往往完整、正确，也往往过于通用。每一步都像有道理，换到真实项目里，却没有包含真正决定结果的约束。
更可靠的起点，是找一项已经完成的真实任务，把它从开始到交付重新走一遍。不要复制所有对话，重点找出六类信息：
-
开始前必须具备哪些输入；
-
哪些步骤真正推动了任务；
-
人在哪些节点纠正过 Agent；
-
哪些项目规则不能靠常识推断；
-
出现过什么失败，后来怎样恢复；
-
最后用什么证据判断可以交付。
以内容稿检查为例，一次任务成功，可能不只是因为 Prompt 里写了“检查错别字”。真正有效的条件还可能包括：先锁定事实来源，把事实问题和表达问题分开，修改后重新核对关键主张，无法自动判断的争议项交给人确认。
把这些条件抽出来，得到的才是一类任务的方法，而不是某次漂亮回答的复印件。
Tranfu 既有内容一直强调目标、上下文、权限、反馈、验证证据、人工确认和失败恢复。这是 Tranfu 的编辑立场，不是行业统一定律，但它提供了一个实用的复盘视角：不要只问 Agent 做了什么，还要问任务为什么能完成，以及团队凭什么相信结果。
当然，来自真实任务不等于第一版就会成熟。真实成功只能提供更扎实的起点，之后仍要靠运行、观察和修订逐步稳定。
用六格提炼法，写出一张最小任务说明书
下面这套“六格提炼法”，是本文综合公开规范与实践给出的 Tranfu 实用框架，不是 Agent Skills 规范中的官方固定六项。
它的作用，是把一次成功里最容易遗漏的信息摊开来写。
第一格：触发条件
回答两个问题：什么任务应该调用？哪些相似任务不该调用？
例如：“用户提供完整草稿，并要求检查事实边界、结构和语言时调用；只有选题、零散素材或单独起标题时不调用。”
触发条件要用同事真实会说的话测试，不能只写抽象分类。
第二格：输入与前提
列出开始前必须具备的文件、数据、工具、权限、版本和上下文。
例如：“必须有完整草稿和可用的事实来源；涉及私有材料时需要读取权限；缺少关键来源时停止事实判断，并返回缺口。”
前提越清楚，Agent 越不容易用常识补齐不该补齐的信息。
第三格：可复用步骤
只保留那些对结果确实有贡献，而且下次还会重复的动作。
内容稿检查可以拆成：提取关键主张，逐项绑定来源，标出证据不足处，再检查结构与语言，修改后重新核对关键主张。
步骤需要具体到能指导执行，但要删掉只适用于当次任务的临时文件名、口令和偶然绕路。
第四格：边界与分流
写清楚哪些内容属于 Skill，哪些应该交给规则、脚本、工具或人工。
比如，禁止泄露私有数据应成为持续生效的规则；读取内容库要通过获准工具；检查字段数量可以用脚本；判断一个观点是否会误导读者，则保留人工复核。
第五格：失败处理
说明哪些失败可以重试，哪些情况必须停止，以及如何恢复。
例如，来源文件无法读取时停止事实检查并报告缺失项；结构检查不通过时修正后重跑；权威材料互相冲突时，不替用户武断裁决，而是保留冲突与各自范围。
只写顺利路径的流程，无法应对真实工作。
第六格：验收证据
最后写清楚：什么证据能说明任务完成，而不是只听 Agent 说一句“完成了”。
必填字段、文件数量、路径和格式等可计算条件，可以写成确定性断言交给验证脚本。风格是否自然、结论是否切题、风险是否可接受，仍由人判断。
脚本负责可计算的“对不对”，人负责需要判断的“好不好”和“该不该”。
六格填完，团队得到的不是一份加长 Prompt，而是一张最小任务说明书：何时开始、凭什么执行、何时停止、怎样证明结果成立，都有了落点。
写完别急着推广，先做有无 Skill 的对照测试
共享会放大好方法，也会同步放大错误。因此，Skill 写完后的下一步，不是让全员安装，而是让它通过一条受控的晋级路径。
先做个人低风险试用。选择几项已经发生过的真实任务，既有常规输入，也有边界情况。对同一批任务分别运行“有 Skill”和“无 Skill”，或者比较新旧版本。
观察的内容不只是一句“看起来更好”，而应包括：
-
客观断言通过了多少；
-
人工纠正发生在哪些位置；
-
整体耗时是否变化；
-
上下文成本是否增加；
-
边界输入有没有暴露新的风险。
只有对照结果显示它在目标任务上带来稳定改善，而且没有新增不可接受的成本，才进入项目内共享。
早期测试样本通常很小，适合帮助团队比较版本，不适合包装成具有统计意义的行业结论。原始通过情况和失败记录，比一个模糊的“效果不错”更有价值。
再往后，组织级维护需要明确负责人、适用客户端和版本、所需权限、复审时间，以及哪些变化会触发重新测试。
2026 年 9 月 2 日，Microsoft 发布的 Copilot Studio 更新已经支持把 Skill 添加到多个 Agent，并与团队成员共享，以复用经过验证的方法。这是团队分发能力的一个明确产品信号，但它只代表 Copilot Studio 当时的支持范围，不能外推为所有 Agent 平台都具备相同能力。
如果 Skill 能执行脚本或访问外部系统，治理要求还要提高。团队需要确认来源可信，坚持最小权限，校验输入，限制和隔离执行，保留必要审计，并让高风险操作经过明确批准。此时它不只是说明文档，还应按代码和权限资产管理。
不是所有成功经验，都值得固化
沉淀不是越多越好。至少有四类任务，不适合急着做成 Skill。
第一，没有 Skill 也能稳定完成。继续增加流程，可能只会增加触发和上下文成本。
第二，每次任务都高度不同，找不到连贯、可复用的方法。一次性战略判断或信息残缺的例外处理，可能更适合保留复盘和人工决策说明。
第三，使用频率很低，维护成本高于收益。这里没有适用于所有团队的频率或投入回报阈值，要按自己的使用量、风险和维护能力决定。
第四，无法定义可靠验收，或者风险必须依赖人工判断。尤其涉及敏感数据、外部写入和不可逆操作时，如果权限、停止条件和批准机制说不清，就不应通过 Skill 扩大执行范围。
即便任务本身适合，Skill 的范围也可能设计错。过宽会让方法变得空泛，误触发增加；过细会产生大量难以发现和维护的小文件。
Skill 还会像普通文档一样过期。团队流程变化、依赖版本升级，都可能让原来的描述和步骤失效。它必须能被更新，也必须能被停用。
“不做 Skill”并不等于“不记录”。规则、复盘、检查清单、脚本、工具连接和人工决策说明，都可能是更合适的归宿。
本周，先做一次最小实验
不必先搭建一整套组织级 Skill 库。
从一个高频、可重复、结果能验收的真实任务开始，完成一张六格卡。然后准备三组真实测试，其中至少一组是边界情况；分别运行有 Skill 和无 Skill 的版本，保存输出、失败证据、客观断言结果和人工判断。
最后，指定一名维护人，记录适用客户端和版本，并约定什么变化发生时必须复审。
只有结果确实改善，才扩大共享范围。如果没有改善，就继续修改，或者承认这个任务并不需要 Skill。
组织能力从来不是文件数量。真正重要的是，团队能不能让正确的方法被可靠调用、被验证、被更新，也能在不适用时停下来。