浏览 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 阅读的官方文档编写;本文会议、文件和版本均为教学构造。页面不声称在你的客户端完成过安装或模型运行。
