个人 Prompt 可以帮你分析需求。团队要复用这套做法，还得明确适用条件、步骤、输出和维护人。把提示词贴进共享文档，缺少这些约定仍难以复用。
先整理最近的任务和失败案例，找出反复出现且确实有效的检查步骤，再决定是否写成 Skill。
从一次成功走到可重复
可以先把做过的需求分析保存下来，连同输入版本、已确认规则、AI 输出、人工修订和最后发现的问题一起记录。多做几次后，再辨认哪些步骤重复出现、哪些内容只适用于某个项目。
适合先整理的通常是重复频率高、输入范围较清楚、结果也能核对的任务，例如验收标准审查或测试用例评审。探索性测试、业务方向不明确的讨论仍需要留出弹性，不宜硬塞进固定流程。
| 沉淀阶段 | 要回答的问题 | 可留下的资产 |
|---|---|---|
| 个人试用 | 任务是否真的受益？ | 原始需求、对话、人工修订记录 |
| Prompt 固定 | 哪些要求反复有效？ | 模板、输入字段、输出约定 |
| Skill 封装 | 哪些步骤需要每次照做？ | Skill 说明、参考资料、模板或脚本 |
| 团队试点 | 不同成员能否用好？ | 使用说明、评估样本、反馈与版本记录 |
新手入门：从最近一次成功任务开始
先选一个重复发生、结果能复核的小任务，例如“检查需求是否有缺口”。不用急着写 Skill，按下面顺序做一遍：
- 收集最近 3～5 次脱敏任务，保留需求版本、原始 Prompt、AI 输出、人工修改和最终发现。
- 对照这些记录，圈出每次都要做的检查，再标出只属于某个项目或某版需求的信息。
- 把固定步骤先整理成 Prompt 模板，明确输入、输出和信息不足时的处理方式。
- 用完整、缺字段、来源冲突等样本试跑；把遗漏、误判和人工补充记下来。
- 只有当步骤确实重复且能被稳定评审时，再把它封装为 Skill，并给它指定维护人和版本。
- 让另一位同事用同一批样本独立试用，检查交付结果是否可理解、可追溯、可接手。
如果每次任务差异都很大，暂时保留灵活 Prompt 或人工评审。
一个 Skill 至少要让人看懂这些事
以需求缺口分析为例，Skill 要写清适用场景、必要输入和执行步骤。要求 AI 提取规则、标出缺失与冲突、引用证据并说明风险；无法确认的行为列成问题，留给业务负责人决定。
说明文件还要列出 Skill 名称、输出格式、人工确认点、维护版本和责任人。是否需要脚本取决于任务；如果清晰的说明和参考模板已经够用，就不必另加文件。
责任人还要明确谁更新参考资料、确认业务规则和审查 Skill 变更。若其中包含脚本、文件写入或外部访问，也要写清授权范围和禁止操作，并限制在任务需要的权限内。
以“需求缺口审查”为例，个人 Prompt 可以先沉淀成一份评估样本，再整理成 Skill 的输入输出约定：
| 项目 | 示例约定 |
|---|---|
| 输入 | 带版本的需求、适用范围、已有验收条件和相关接口约定 |
| 步骤 | 抽取规则，逐条关联来源；将缺失、冲突和过期信息分开标记 |
| 输出 | 规则 ID、引用位置、风险影响、待确认问题和最小补证动作 |
| 边界 | 不替产品补写业务规则；没有来源的预期保持待确认 |
| 回归样本 | 需求完整、关键字段缺失、两份来源冲突三类脱敏输入 |
该表只展示一种结构，没有提供实际评测结果。试用时要保存输入版本、输出、人工修订和评审结论；如果模型把缺失信息补成事实，应将该样本留作失败用例，修改说明后再回归。
实例：把需求缺口审查 Prompt 变成 Skill
先把一次性提问改成可复用 Prompt，写清审查步骤和输出约定。可以从下面这版开始调整：
任务：审查给定版本的需求，找出影响测试设计的缺失、冲突和过期信息。
输入：需求版本与范围、验收标准、相关接口或设计约束。只使用本次提供的材料。
步骤：
1. 提取可验证规则，为每条规则记录来源位置。
2. 将规则标记为已确认、缺失、冲突或过时。
3. 检查正向、失败、边界、状态变化和副作用；说明每个风险依据。
4. 对无法从材料确认的行为提出问题和最小补证动作，不替产品决定答案。
输出：规则 ID、来源、证据状态、风险、待确认问题、补证动作。
边界：区分事实、推断和建议；不得把缺失规则写成已确认事实。接着把可复用做法与项目材料分开：
| 从 Prompt 中提取的稳定部分 | Skill 中的落点 | 留在每次任务输入中的部分 |
|---|---|---|
| 先审输入版本和适用范围 | 使用条件与必需输入 | 当前项目、需求版本和业务范围 |
| 逐条抽取规则并附来源 | 固定审查步骤 | 本项目的验收标准和接口约束 |
| 区分缺失、冲突、过期信息 | 证据处理规则 | 本次材料之间的具体冲突 |
| 用统一字段交付风险和问题 | 输出格式 | 项目负责人、优先级和处理决定 |
| 不猜业务规则，信息不足就提问 | 边界与人工确认点 | 本次由谁确认未决问题 |
再把稳定部分整理成一个易读的 Skill 文件。下面展示内容结构；名称和元数据字段需要按目标宿主的 Skill 规范调整：
# 需求缺口审查
## 适用场景
用于审查带版本的需求，找出其中测试相关行为的缺失、冲突或过时之处。
## 必需输入
- 需求版本与范围
- 验收标准
- 相关接口或设计约束
## 执行流程
1. 提取每条可验证规则，并注明其来源位置。
2. 将每条规则标记为已确认、缺失、冲突或过时。
3. 检查成功、失败、边界、状态变更和副作用路径。
4. 将尚未解决的行为转化为问题，并说明需要补充的最少证据。
## 输出
规则编号、来源、证据状态、风险、待确认问题和补证动作。
## 边界
区分事实、推断与建议；不要编造业务规则，也不要代替人作出判断。注意，需求版本、客户数据、负责人和业务决定不应该硬编码到 Skill；它们会变化，应在运行时作为输入提供。也不要把令牌、真实个人信息或超出任务需要的访问权限放进示例。
用失败样本评估 Skill
准备 3～5 份脱敏样本，覆盖规则完整、信息缺失、规则冲突和边界复杂等情况。评估关键问题是否被发现、未知项有没有被误写成事实、输出是否符合约定、人工修订是否减少。把失败样本加入回归集合，每次修改 Prompt 或 Skill 后重新检查。
把完整、缺失、冲突和边界样本放在一起评估，才能看出 Skill 在哪些输入下会漏项或猜测。样本还不够时，将结论标为“尚未验证”，不要宣称团队效率已经提升。
可以用四周做一次小范围试点
| 周次 | 重点 | 交付物 |
|---|---|---|
| 第一周 | 选一个高频任务，收集脱敏需求与失败样本 | 样本集、已知问题清单 |
| 第二周 | 固定 Prompt、必要输入和输出格式 | 可评审的模板 |
| 第三周 | 根据使用平台封装 Skill，并做回归 | Skill 初版、评估记录 |
| 第四周 | 邀请小组成员试用，收集问题并决定是否推广 | 使用说明、改进事项、推广决定 |
四周是便于讨论的试点节奏，团队可以按准备情况调整。样本不足、输出不稳定或没有维护者时，先暂停推广。
重点：把 Skill 维护纳入质量循环
团队要维护可信的输入、适用的步骤和可追溯的输出，也要能在失败后修正流程。Skill 可以减少重复说明，需求确认、风险判断和发布决策仍由人负责。
- 选择真实的重复任务： 从已发生的工作和失败记录开始，不凭想象设定流程。
- 提取稳定判断： 归纳重复有效的检查项、输入要求、证据规则和输出格式；项目特定规则继续留在任务上下文。
- 封装并标版本： 发布 Skill 前记录维护人、适用范围、依赖资料和版本变更原因。
- 评估代表性样本： 用完整、缺失、冲突和边界样本检查遗漏、猜测、来源追溯和人工修订量。
- 小组试用并记录： 保存输入版本、模型/Agent、Skill 版本、输出、缺陷、人工修改和复核结论。
- 修订后重跑： 把确认有效的修订加入回归样本；用同一组样本复核旧问题，再用新样本观察是否适用于新情境。
业务流程、参考资料、模型或宿主工具变化时，重新评估 Skill。没有稳定样本或维护人时，应保留“尚未验证”的状态。新证据出现后，及时更新方法并记录它验证过的输入范围。
最佳实践
- 先积累多次真实使用记录，再决定哪些步骤值得固化；一次成功不等于稳定方法。
- 把可复用的审查流程与项目事实分开，避免 Skill 过拟合某一份需求。
- 在 Skill 中写明证据来源、未知状态、输出字段和人工确认点。“请全面检查”无法固定这些要求。
- 用失败和边界样本做回归，记录修订前后差异；不要只收集成功截图或采用率。
- 为 Skill 指定维护人、版本和复核触发条件；业务、模型、工具或依赖资料变化时重新评估。
- 只申请完成任务需要的文件和工具权限，示例与评估样本全部脱敏。
FAQ：常见问题
什么时候值得把 Prompt 变成 Skill？
当任务反复发生、输入和输出可以说清楚、团队需要一致的步骤，而且结果能够评审时，可以开始试做。若任务变化很大或规则仍在讨论，保留灵活 Prompt 更合适。
Skill 和 Prompt 的核心区别是什么？
Prompt 通常表达一次任务指令或可复用模板；Skill 还需要说明何时使用、所需输入、执行顺序、输出约定、边界和维护方式。具体能力取决于宿主平台，不能只凭名称推断。
一份 Skill 要有脚本或多个文件吗？
不一定。先用最小可读说明满足任务。只有当参考资料、模板或脚本解决了明确问题时再加入，并说明版本、来源和权限。
换了模型之后还能沿用原结论吗？
不能直接照搬。先用固定回归样本重跑，记录模型、工具和 Skill 版本，再检查遗漏、无依据结论和人工修订是否变化；结论只覆盖实际验证的条件。
怎么知道 Skill 真的提高了质量？
比较相同样本上的关键缺口发现、无依据结论、输出可追溯性和人工修订成本，并保留评审记录。没有运行和证据时，应写“尚未验证”，不要声称已经提升。
是否引入更复杂的智能体，要看实际任务和评估证据。自动化程度高本身不是采用理由。