把重复工作写成第一个 Skill：从会议记录提取真正的待办

会议记录里常混着决定、建议、历史进展与闲聊。让 AI “整理一下”，它可能把一句“可以考虑”也分配成任务。本课把这个小流程写成 Skill：只提取已经确定的待办，保留负责人和原文时间，缺失信息单列。

你会得到一份完整 SKILL.md、三组测试材料和一组不应触发的请求。它们都是开工科技原创教学内容，不依赖第三方脚本，不需要联网搜索。使用支持 Skill 的模型工具仍可能消耗账号额度。

1. 先判断这件事值不值得做成 Skill

如果只整理一次会议，用明确提示就够了；如果每周都要按相同栏目整理，而且“讨论不等于决定”是反复出现的规则，就适合保存下来。

先把流程压缩成一句话：输入已有会议记录，输出已确认待办与待确认问题，不替会议作决定。别把自动建日程、通知同事和写项目代码也塞进第一次练习，这些动作需要另行设计。

第一版最容易犯的错误是只写“提取所有行动，合理补全负责人和截止日期”。这看起来积极，却把“整理材料”变成了“替团队分工”。我们先观察这个缺陷，再写更准确的版本。

2. 保存完整入口

新建练习项目。Claude Code 使用 .claude/skills/kg-meeting-actions/SKILL.md；Codex 使用 .agents/skills/kg-meeting-actions/SKILL.md。只选实际使用的工具，完整放置方法见 Claude Code 篇 或 Codex 篇。

用纯文本编辑器保存以下全部内容，文件名不能是 SKILL.md.txt，也不要把代码框的三反引号一起写进文件：

---
name: kg-meeting-actions
description: 从用户给出的会议记录中整理已确定的待办、负责人和截止时间，并列出未决问题。用于会后任务整理，不用于分派任务、创建日程或发送消息。
---

# 会议待办整理

只使用本次提供的记录，区分决定、建议、已完成事项和背景信息。

## 提取规则

1. 只有明确决定要做的事项进入待办表。
2. “建议、考虑、尚未决定”进入待确认问题，不改写成已决定。
3. 已完成的事项不重新列为待办。
4. 负责人只采用原文明确分配的人。发言人不自动等于负责人。
5. 截止时间保留原文写法，不把“下周三”换算成日期。
6. 明确的改期或换负责人采用最新决定，同时注明原决定被替代。
7. 两个说法冲突且没有明确变更关系时，保留冲突，等待确认。
8. 缺少负责人或时间，写“待确认”，不能自动分配。

## 输出

先给“已确定待办”表，列为：事项、负责人、截止时间、依据原句。
没有已确定待办时明确写“无”，不制造空任务。
再给“待确认问题”，包括建议、冲突和已确定任务的缺失字段。
最后用一句话说明哪些已完成事项没有重新加入。
不联网、不执行脚本、不写文件、不建日程、不发送消息。

name 用于识别，description 说明什么时候该用，正文才写操作细则。好的描述有任务关键词和范围，不是“万能效率助手”。规则中的“依据原句”让你能回到输入核对，而不是只能评价答案是否像会议纪要。

3. 第一组测试：有决定，也有建议

在 Claude Code 会话中使用 /kg-meeting-actions；在 Codex 会话中使用 $kg-meeting-actions。附上完整输入：

周会记录（虚构）：
决定：小林负责补充安装截图，下周三前完成。
小周说：“我们可以考虑录一段讲解视频。”会议没有决定是否制作。
小陈已经完成文件命名整理，本次不再安排。

人工教学预期只有一条待办：

待确认问题应是“是否制作讲解视频”；已完成的文件命名整理不再安排。这里没有给会议日期，所以不能把“下周三”换算成某个具体日历日期。小周只是提出建议，也不能自动变成视频负责人。

4. 第二组测试：事情决定了，但分工不完整

在新会话明确调用同一 Skill，再输入：

会议决定更新新手下载说明，尚未确定负责人。
小宁介绍了旧版说明的情况，但没有接下更新任务。
更新完成时间也未讨论。

预期待办表有一行：事项为“更新新手下载说明”，负责人和截止时间均为“待确认”；依据采用第一句，并在待确认问题中列出这两个缺失字段。

反例是“小宁，下周五完成”。它把发言人当负责人，又创造了日期。若出现这个结果，先检查当前确实加载的是本课版本，再指出第 4、5、8 条没有落实。不要为了让表格看起来完整就接受猜测。

注意：负责人缺失不等于事情没决定，所以不能把整条任务从待办表删掉。提取规则需要同时表达“决定程度”和“字段完整度”，这是本课比简单总结更重要的地方。

5. 第三组测试：明确改期，不等于记录冲突

继续用新会话测试：

原决定：小白负责检查帮助页面，周四前完成。
会议结尾明确调整：仍由小白负责，截止时间从周四改到周五。
另一个任务是检查搜索结果。记录A写由小雨负责，记录B写由小何负责，
没有说明谁接替谁，截止时间未提供。

人工预期有两条待办。第一条负责人小白、截止周五，依据要包含明确改期，并说明周四已被替代。第二条事项“检查搜索结果”，负责人待确认（小雨与小何冲突），截止时间待确认，不能任意选一个人。

不要把所有出现两个日期的材料都标为矛盾，也不要一律选最后出现的名字。前者有明确变更关系，后者没有；同一个“取最后一条”的简单规则无法正确处理两者。

6. 测试它什么时候不该工作

在新会话发送不含 Skill 名称的普通请求：“请解释 Markdown 标题为什么要用井号。”这不是会议待办整理，不应被强行转成任务表。

自动匹配受当前宿主和其他配置影响，不保证一次就能判断全部情况。如果误触发，先缩小描述中的适用场景，而不是加入“任何时候必须使用我”。明确调用测试验证的是执行流程；自然语言测试验证的是匹配范围，两者要分开记录。

可以用一个简单的本地测试表记录结果：第一组是否只提取一条决定，第二组是否保留任务但不补分工，第三组是否分清改期与冲突，无关请求是否被错误处理。预期由你先写，实际结果由真实运行后填写；本文没有把示例答案伪装成现场运行。

7. 修改规则时，一次只解决一个问题

如果发现“负责人总被乱补”，优先调整负责人规则和对应测试；不要同时重写名称、目录、输出格式和所有措辞，否则难以判断哪一改动有效。

新增规则后，三组旧测试都要再跑，避免修好第二组却破坏第三组。保留旧入口副本，且放在技能发现目录之外；同名两份同时加载会让比较失去意义。

第一次 Skill 到此不需要脚本。只有以后确实要稳定处理大量结构化数据，才考虑增加代码与运行依赖；要发送待办给同事，则需要另行设计权限、目标确认和失败恢复。先把“输出值得信任”练扎实，再看 安全更新与移除。