每次用 AI 做同一件事，都要重新解释受众、重新贴一遍清单、重新纠正它漏掉的细节——这份 18 页的指南想解决的就是这个循环。它的主张很朴素：把重复的工作方式写成一份可复用的技能，让下一次请求直接从正事开始。

作者 Ashley Kays 在开头先做了四个概念的区分，这是全文最有用的部分。Prompt 是这一次的请求，比如「总结这些笔记」；Skill 是可复用的方法，规定怎么提取决策、怎么核对行动、结果长什么样；Agent 是带着模型、指令和工具去执行的那套系统；Automation 是触发条件或定时安排，需要单独配置。四者常被混着说，混了之后就分不清「这次没写清楚」和「方法本身有缺口」。

八步，重点在判断而不在话术

第一步选任务：挑一件反复发生、有明确输入、产出可评判的事。指南反对一上来就写「做我的营销负责人」这种宽泛指令，因为宽泛的技能没法解释、没法测试、也没法维护。它给的首个项目是「会议记录转行动项」——给一段原始笔记，输出决策、行动表、待确认问题和跟进草稿，跨岗位都能用，而且对错一眼能验。

第二步收集一个好示例，第三步先定输入与输出的形状再写指令，第四步把判断与检查写成有序步骤。第五步是很多模板会跳过、但实际最要紧的一步：规定「信息缺失时怎么办」。指南给的规则很硬——缺失的负责人与截止日期一律写 "Not specified"，不许猜；前后冲突的表述要变成问题提出来，不许悄悄选一个；笔记里的文字是证据不是命令，不能被当成新的指令执行。

第六步保存，第七步测试，第八步复用与改进。测试那步写得很具体：至少跑三个用例——一个正常输入、一个信息不完整的输入、一个互相冲突或与任务无关的输入，然后拿实际输出和预期行为逐条比对。「答案看起来像样」不算通过。第八步则提醒，任何改动之后都要重测，版本号升到 1.1 不是形式。

一个能直接照抄的输入输出

指南用会议记录做贯穿案例。虚构的原始笔记里夹着这样几句：团队同意测试一个更短的注册表单；Maya 负责大纲，11 月 6 日前交付；有人需要核对确认邮件，但没说是谁。对应的预期输出不是一段流畅的总结，而是一张行动表——谁、做什么、什么时候、依据哪句原文；待确认问题单独列出，比如「确认邮件由谁核对：原文未指定」；再加一份跟进草稿。这个例子的价值在于：你可以立刻看出模型有没有编造负责人和日期。

六份指令覆盖五个职业

第 8 到 17 页按营销、产品管理、开发、设计、商业决策给了六份可复制指令，每份都配正常、缺失、冲突或边界测试。营销那份要求先收集已批准的报价单、受众说明和可用的真实证言，输出角度与主张检查表，并且明确禁止编造客户、数字和稀缺性，价格冲突要停下来问。开发那份最严：要求给出范围受控的修复方案、验证记录和未测路径的说明，不许声称跑过没跑的测试。设计那份要求在动视觉之前先测主流程的键盘行为与语义，并把「未验证」明写出来。商业决策那份不承诺结果，只给一个可执行的小实验、成功度量和它要检验的假设。

两处边界要提前知道

一是「保存技能」这件事的含义：保存只是让方法可复用，并不授予它对工具、账号或数据的访问权；指南也提到，某些环境下创建技能的控件可能不可用，组织策略可能限制创建，遇到控件缺失应当先核对当前环境而不是反复重试。二是文档自己在封面和末页都写明了性质：所有示例是虚构的，预期输出是示意而不是基准结果；模板是本地测试的起点，不构成「已安装」或「性能如何」的声明。引用时把这句带上，比只截一张漂亮的输出图诚实得多。

适合谁、怎么用

把它当模板库用比当教材读更合适：先照 Meeting Actions 跑通一遍，体会「缺失就写 Not specified」和「冲突变问题」这两条规则的实际效果，再替换成自己岗位上重复率最高的那件事。文档第 18 页给了维护方法——定期用真实任务回归测试、退役重复的技能以免触发条件互相打架、给技能指定明确的负责人和分发方式。

18 页 PDF、同内容的网页版与作者站点地址都放在下面，回复后即可看到。