第12章 把成功经验整理成可复用技能

前面三章已经得到任务判断、工作说明、输出模板和验收清单。现在可以考虑把这套低风险流程整理成更容易重复使用的资产，但“考虑”不等于“立刻发布”。你需要先决定固定 Prompt、Agent 工作说明、项目任务方案和技能分别适合什么情况，再记录测试、版本和共享边界。

官方文档把技能描述为把提示词、代码片段或工作经验结构化，形成可保存、复用、优化的任务解决方案；也介绍了从满意对话制作技能、试用、优化和打包的路径。技能概述和制作技能是功能依据。但官方页面的入口、可见范围和套餐提示不一定与当前账号完全相同，本章不把“制作成功、已保存、已共享、所有 Agent 可用”写成必然结果。

先选择复用层级

你可以把复用分成四层，从轻到重：

复用层级	适合什么时候用	主要资产	什么时候先别用
固定 Prompt	任务偶尔重复，规则还在变化	一条可复制指令	输入和输出尚未稳定
Agent 工作说明	同一个 Agent 经常遵守一套行为规则	角色、优先级、异常和边界	只是一次性任务
项目任务方案	需要保留消息、文件、产物并持续推进	项目背景、资料、阶段结果	没有持续主题，只有一次问答
技能	流程固定、已多次测试、需要在类似任务中复用	触发条件、说明、模板、资源和版本	仍需大量人工判断，或权限/风险高

技能不是更强的 Prompt，也不是自动权限。它可以让 Agent 更容易按一套方法工作，但不会替你确认事实、获得邮箱权限或决定是否公开发布。如果当前账号无法制作或保存技能，退回固定 Prompt 或任务方案，仍然可以完成复用目标。

主案例：会议纪要流程是否够资格封装

候选流程是“把虚构或脱敏会议纪要整理成目标、现状、行动、风险、待确认事项”。它看起来低风险，但仍需要两类测试：

测试 A：字段齐全的虚构会议纪要，检查五个栏目是否稳定出现。
测试 B：缺少负责人、日期和预算的虚构会议纪要，检查是否保留“待确认”，而不是补写。

至少记录四件事：技能是否触发、输入范围是否被正确识别、输出是否符合模板、哪些地方仍要人工改。一次成功不能证明流程稳定；第二份缺字段资料往往比第一份漂亮结果更能暴露边界。

命名和版本：让以后找得到、改得明白

名字要包含用途和范围，不要只叫“我的技能”。例如：

会议纪要整理为行动方案初稿-v1
会议纪要整理为行动方案初稿-v2-增加缺字段处理

版本记录不必依赖 Coze 是否提供版本按钮。你可以在自己的文档中写下日期、改动原因、测试资料和已知限制。如果当前界面支持复制、更新或打包，就按照真实入口操作；如果没有，就把版本文件保存在自己的资料目录中。版本的意义是能回答“这次改了什么、为什么改、改后测过没有”，而不是制造复杂流程。

一份简单的生命周期记录可以只有六行：当前版本、上次改动、已通过的输入、未覆盖的输入、可见范围、回退方式。比如 v1 通过字段齐全的会议纪要，v1.1 修复缺少日期时的标记，v2 才考虑改变输出模板。这样即使 Coze 页面没有历史版本按钮，你也不会把新旧规则混在同一份说明里。

官方路径与当前账号边界

官方资料介绍了一条常见路径：在已经满意的多轮对话中请求“将以上处理流程制作为技能”，Coze 可能整理工作流程和模板，生成包含 SKILL.md 的技能文件，并把技能加入当前对话 Agent；之后用新的输入试用，发现触发或执行问题再优化。制作技能还介绍了预览、测试和打包。

在当前账号中，入口可能表现为对话中的指令、技能列表、技能商店或编程项目。你应先看见真实入口，再决定写哪种操作。若只看到普通对话，没有制作、保存或共享选项，就明确记录“当前界面无此项”，把已经验证的方案保留为固定 Prompt；不能用官方截图替代账号实测。

技能方案的文字结构直接在本章正文中解释，不使用纯文字截图作为技能已创建的证据。旧图片文件保留，但不再由本章引用。

用固定文字请求制作个人练习技能

如果当前账号显示可从对话制作技能，先使用虚构资料和下面的请求。这里的“适用范围”只出现一次，避免把输入边界重复写成相互矛盾的规则：

请把本次“会议纪要整理为行动方案初稿”的处理流程制作为个人练习技能草稿。
适用范围：虚构或脱敏会议纪要；输出目标、现状、行动、风险、待确认事项和人工核对提示。
触发前先确认资料范围；没有依据写“待确认”；不发送、不发布、不连接外部服务。
请先说明将保存或生成什么。若当前账号不能制作技能，请明确说明，不要声称已经完成。

请求中先写范围，再写触发、输出和边界，是为了让生成的技能说明有可检查的入口。它不要求 Agent 直接把技能发布到商店，也不要求连接外部服务。得到回复后，检查名称、触发条件、输入范围、人工确认点和当前可用范围；任何一项看不见，都标记待实测。

如果当前账号没有制作入口，这里应显示真实的替代界面或“当前界面无此项”的备注，正文退回固定 Prompt/任务方案，不把流程写成已完成。

测试：正常输入和边界输入都要跑

技能制作后，不要只用同一份资料测试。先用正常会议纪要，再用缺字段版本，最后用一个不在范围内的请求。官方使用技能说明 Agent 可能自动匹配技能，也可以通过对话入口选择已添加技能；不同端和技能类型的入口、状态可能不同。

固定测试 Prompt：

请用“会议纪要整理为行动方案初稿”技能处理下面的虚构资料。
先确认资料范围，再输出五个栏目；缺少负责人、日期、预算时写“待确认”；不要发送、发布或连接外部服务。
如果当前任务没有触发该技能，或界面无法显示技能状态，请直接说明，不要把普通 Prompt 的结果当成技能调用。
资料：活动主题方向已讨论；下次会议前整理两种主视觉方向；嘉宾、场地、预算、负责人和日期待确认。

截图或记录时，要区分三种证据：看见技能名称，不等于技能已启用；看见“加载”提示，才较接近触发证据；得到一份正确结果，只能证明这次输出可用，不能单独证明技能被调用。如果当前界面无法显示触发状态，就写“调用状态无法从当前界面确认”，而不是猜测。

保存、共享和发布：是不同的决定

技能保存到个人空间、添加给自己的另一个 Agent、共享给协作者、发布到技能商店，是四种不同的可见范围。每扩大一次范围，都要重新检查资料、版权、触发条件和权限。官方文档提到自定义技能默认仅本人可用，商店技能可能涉及添加、购买或企业范围；这些状态以当前页面和账号提示为准。

在做任何共享动作前，用下面的检查请求：

请检查这份个人练习技能方案是否适合保存或共享，只输出：当前版本、适用范围、输入风险、外部权限风险、人工确认点、共享前仍缺什么。
不要发布、购买、授权或发送；如果当前账号没有版本或共享入口，请明确说明。
方案名称：会议纪要整理为行动方案初稿-v1

如果页面出现购买、授权、发布或公开提示，停在预览，不要为了截图点击确认。先把“能不能共享”和“现在要不要共享”分开讨论；许多个人练习只需要保存到自己的文档，不需要进入商店。

共享前还要问一个问题：别人拿到的是“方法”，还是连同你的资料和权限一起拿到？如果技能包含真实客户资料、内部术语表或外部服务配置，先移除或替换，再讨论共享。撤销也要有预案：如果当前界面提供停用、移除或删除，就记录真实入口；如果没有，就停止使用该版本，并在自己的任务清单里标记为不可用。不要把“我看到了共享按钮”写成“已经可以撤销”。

当前账号如果没有版本或共享入口，截图应保留真实替代界面并注明“当前界面无此项”，正文回退到个人固定 Prompt 或项目任务方案。

迁移案例：自媒体选题周报

假设你每周收到 5 条虚构选题，需要整理主题、受众、重复角度和待判断项。规则仍在变化时，用固定 Prompt 最灵活；如果同一个 Agent 总要遵守“先列来源、不要猜热度”的行为，可以放进工作说明；只有输入格式和输出模板稳定、至少测试过正常与缺字段资料后，才考虑技能。技能不能保证选题受欢迎，也不能自动替你发布。

失败排错：技能做出来，却没有触发

现象：界面显示技能草稿，但对话结果和普通 Prompt 一样；或者 Agent 说找不到技能。

先检查：技能名称和描述是否写清触发条件；是否已经添加到当前 Agent；是否处于可用状态；输入是否在适用范围；当前账号是否需要额外授权或本地设备在线。

修正或停止：先用技能说明中的最小示例测试，再用缺字段资料测试。若仍无法确认，退回固定 Prompt，保留测试记录；不要为了“看到成功”而批准未知权限或发布技能。

恢复标准：至少能确认当前任务的输入范围、输出结构和人工检查点；如果不能确认技能是否触发，就明确写出限制，不把正确结果冒充技能证据。

当账号能力变化时，回退路径很简单：把技能中的适用范围、流程和边界复制成固定 Prompt，继续在当前对话中使用；项目还在持续推进，则把资料和结果放回项目任务方案。回退不是失败，而是让工作在“技能入口暂时不可见”时仍能继续，并保留未来重新测试的记录。

一份最小测试记录应该写什么

每次测试可以记录：输入类型、是否触发、输出是否符合模板、人工发现的问题、采取的修正和当前版本。正常输入证明主路径能走通，缺字段输入证明边界规则有效，超范围输入则证明技能会停下来而不是胡乱处理。三种记录放在一起，才比一张“测试通过”的截图更有说服力。

如果同一个问题在两类输入中反复出现，就先修改工作说明或模板，再重新制作/更新技能；不要只在结果后面手工改字。技能的生命周期不是“生成一次—永久使用”，而是“制作—测试—修订—再测试—决定保存范围”。

保存范围从小到大

个人练习版本只服务于自己，最适合第一次验证；项目内方案适合让同一个项目的成员继续查看资料和产物；共享或商店版本则需要额外检查说明是否清楚、资源是否可用、权限是否最小。先从最小范围开始，可以在发现问题时快速停用，也不会让未经验证的规则扩散到其他人的任务。

每次扩大范围都重新做一次人工确认：输入是否仍然脱敏，技能是否依赖本地文件，是否包含第三方资源，失败时谁负责停止。范围越大，维护责任越清楚，越不能只凭一次对话结果决定。

当你决定暂不制作技能时，也要把决定写下来：例如“当前任务每月只做一次，继续使用固定 Prompt”；或“输入格式还在变化，保留 Agent 说明 v2”。这不是拖延，而是避免在没有收益的地方增加维护成本。等重复频率、输入范围和验收标准都更稳定，再回到本章重新评估。

本章产物与验收

本章应产出一份带版本号的个人复用方案、两类虚构测试记录和一份保存/共享前检查清单。验收重点是：

• 是否选择了合适的复用层级，而不是一律制作技能？
• 名称、版本、触发条件、输入范围和不适用场景是否写清？
• 是否测试过正常、缺字段和超范围输入？
• 是否区分看见入口、技能已添加、技能已触发和结果可用？
• 当前账号没有制作、保存或共享入口时，是否退回固定 Prompt/任务方案？
• 是否在共享、购买、授权或发布前停下来由人确认？

本章小结

可复用技能不是一次成功结果的包装，而是经过测试的低风险流程、输入边界、输出模板、触发条件和人工检查点的组合。能用固定 Prompt 解决时就不要增加复杂度；需要技能时也先从个人练习版本开始。

第三部分到这里结束。下一部分进入项目协作和多个 Agent 的分工，继续沿用“先定义范围、再执行、最后人工验收”的方法。