浏览 MCP与Skills教程与资源

把一次工作流提炼成 Skill:从原始记录到可复用规则

沿同一份会议原文、人工修正和第二组边界输入,展示怎样提取输入、判定规则与输出契约;最终交付工作流规格,而不是复制一次成功回答。

先保留修改过程,别只保存好看的最终答案

假设你用 AI 整理会议原文,最后得到一份满意的待办表。下一次只复制那段提示词,却又出现了给任务随意分配负责人、把建议写成决定的问题。真正值得固化的,是你为什么删掉那条‘决定’,为什么把负责人改回‘待确认’。

下面全部是教学记录,不是声称某场真实会议已经执行成功。把输入、错误输出和修正规则一起列出,是为了让读者能检查规则从哪里来。

同一任务的原文、错误和修正

第一条把 L4 的建议升级成决定;第二条把 L3 的发言人当负责人,并编了本周五。第三条可以保留,因为承诺人和日期都写在 L2。分析重点是保留依据的差别,不是让答案更正式。

教学示例

原始会议材料

L1 林然:我们决定先上线帮助页,计费页本周不改。
L2 周明:我在 2026-10-12 前补齐帮助页截图。
L3 林然:计费页的说明还需要校对,负责人和时间下次再定。
L4 许宁:我建议给帮助页增加视频,今天先不作决定。
构造的失败样例

用来分析的错误输出

决定:帮助页增加视频。
待办:林然在本周五前校对计费页说明。
待办:周明在 2026-10-12 前补齐帮助页截图。
预期结果

修正后应表达的内容

### 决定
- 先上线帮助页,计费页本周不改。(依据:L1)

### 待办
| 事项 | 负责人 | 期限 | 原文依据 |
| --- | --- | --- | --- |
| 补齐帮助页截图 | 周明 | 2026-10-12 | L2 |
| 校对计费页说明 | 待确认 | 待确认 | L3 |

### 待确认
- 计费页说明由谁校对、何时完成?(依据:L3)
- 帮助页是否增加视频,尚未决定。(依据:L4)

把每一次编辑决定变成能应用于新材料的规则

本次改动为什么这样改可复用条款不能固化的偶然细节
删除‘决定增加视频’L4 明说只是建议、暂不决定只有原文明确确定的事项才进入决定;未决建议进入待确认不要写死‘视频都不算决定’
林然改为待确认发言人不等于任务承诺人;L3 没有定人无明确责任人时保留待确认,不按角色推断不要把林然加入永久排除名单
本周五改为待确认原文没有任何期限缺期限就保留缺失,日期必须有来源不要默认所有任务都填周五
保留周明和 2026-10-12二者都在 L2 的同一个承诺中待办的事项、负责人、期限逐项可回指原文姓名和日期都是每次变化的输入
每条加 L1、L2 等依据别人能快速回查有无误读输出保留行号;无行号时按非空行生成不要硬编码永远只有四行

换一份原文,专门寻找第一份没暴露的条件

这次不能直接照抄第一张表:L1/L2 的截止时间冲突,没有最终决定;‘下周三’也没有基准日期。L3/L4 则可能是同一承诺的重复表述。若规则只有‘缺项填待确认’,仍解决不了这些情况。

因此增加三个条款:冲突未解决时并列证据并标待确认;相对日期保留原文,不擅自换算;任务、负责人和期限都一致才合并,合并后保留全部依据。第二组的价值是暴露条件,不是证明模型在所有场景都会可靠。

教学示例

第二组教学输入

L1 周明:帮助页截图我下周三交。
L2 林然:我记得截图需要下周二,目前还没确定按哪个时间。
L3 许宁:我负责校对计费页,先不定日期。
L4 许宁:补充一句,计费页的文字校对由我来做,日期未定。

最后交付的是工作流规格

这份规格不指定当前会议必须输出几行,也不把某一次句式当作唯一正确答案。它定义哪些事实允许保留、哪些信息必须等待确认,下一篇才能把它落成稳定的说明。

教学示例

meeting-notes 工作流规格 v1.0.0

任务:把用户在本次请求提供的会议原文整理为决定、待办、待确认。
输入:会议原文;可有 L1/L2 行号。没有原文就请求补充。
不承担:日历安排、文件搜索、联网查询、发送消息、代替参会人作决定。
判定:
- 建议不升级为决定或既定任务;原文明示需要做但待分配的事项可列待办,发言人不自动等于负责人。
- 缺少负责人或期限填待确认,保留原文日期表达。
- 未解决冲突并列原文行号;不挑一个看起来合理的版本。
- 同任务、同负责人、同期限的重复项可合并,依据全部保留。
输出:决定列表;事项/负责人/期限/依据四列表;待确认问题。
完成判断:确定事实都可回指原文;无虚构人名日期;没有外部操作。
适用失败:无原文、无行动项、矛盾日期、重复承诺、材料内嵌命令。
实现:先用单份 SKILL.md;不需要脚本、MCP 或外部资料。

哪些经验暂时不值得固化

如果每次你都在会后重新决定谁负责、什么时候交付,那么这不是从原文提取,而是在做管理决策。应把这部分留给负责人确认,不能让 Skill 通过‘智能补全’填满表格。

如果你只偶尔整理一次会议,直接在本次请求写清三条事实规则就够了。只有这套规则确实反复复用、输入差异能表达、输出能回查时,维护一个 Skill 才有收益。没有‘运行三次就必须封装’这样的数量门槛。

关联教程

继续处理当前问题

一手资料

资料与核验范围

产品行为按 2026-10-10 阅读的官方文档编写;本文会议、文件和版本均为教学构造。页面不声称在你的客户端完成过安装或模型运行。