会议纪要 → 决策与待办提取

把一份流水账式的会议记录，整理成可追踪的「定了什么、谁做什么、什么时候交、还有什么没定」。核心原则只有一条：只提取原文明确说过的内容，未写明就写「未指定」。

适用场景

使用本 Skill：

• 用户粘贴会议纪要、语音转写稿、群聊记录，要求「整理结论 / 提取待办 / 生成跟进清单」。
• 项目周会、评审会、复盘会、客户沟通会等需要形成行动项的场合。
• 需要把会议内容转成可导入任务系统的 JSON 结构。

不要使用本 Skill：

• 从零撰写会议纪要（本 Skill 只做提取与结构化，不补写未发生的内容）。
• 对会议内容做绩效评价、责任判定或法律结论。
• 输入只有一两句、没有实际讨论内容的文本——此时应直接说明「材料不足，无法提取」。

输入

| 输入 | 是否必需 | 说明 | | --- | --- | --- | | 会议原文 | 必需 | 纪要、转写稿或聊天记录。保留说话人标记（如「张伟：」）与时间信息，便于判定负责人和日期。 | | 会议日期 | 可选 | 用于把「下周三」等相对时间换算成具体日期。原文没有且用户未给时，相对时间一律记「未指定」。 | | 参会人名单 | 可选 | 用于规范姓名；原文没有的名字不得补进 participants。 | | 输出偏好 | 可选 | 例如「只要待办」「按负责人分组」。默认同时输出 JSON 与 Markdown 清单。 |

输入不足的处理：

• 原文为空或只有寒暄、没有实质讨论 → 输出「材料不足，未提取到决策或待办」，不要硬凑条目。
• 原文没有会议日期、但出现了相对时间 → 保留原文表述到 due_raw，due 记「未指定」，并在 meta.assumptions 说明原因。
• 说话人标记缺失 → 负责人只有在原文明确写出人名/角色时才能填，否则「未指定」。

输出

必须输出两部分，顺序为 JSON 在前、Markdown 清单在后。

JSON 结构

{
  "meeting": {
    "title": "产品周会",
    "date": "2026-03-02",
    "participants": ["张伟（产品）", "李娜（研发）"]
  },
  "summary": "不超过三句话的会议摘要，只包含原文出现过的信息。",
  "decisions": [
    {
      "id": "D1",
      "decision": "一句话结论，使用陈述句。",
      "rationale": "原文给出的理由；没有则为 null。",
      "evidence": "原文逐字片段（不超过 40 字）。"
    }
  ],
  "action_items": [
    {
      "id": "A1",
      "task": "可执行的动作，以动词开头。",
      "owner": "原文明确的负责人；否则为「未指定」。",
      "due": "YYYY-MM-DD 或「未指定」。",
      "due_raw": "原文中的时间表述；没有则为 null。",
      "priority": "高 | 中 | 低 | 未指定",
      "evidence": "原文逐字片段（不超过 40 字）。"
    }
  ],
  "risks": [
    {
      "id": "R1",
      "risk": "风险或阻碍的描述。",
      "impact": "原文写明的影响；没有则为 null。",
      "evidence": "原文逐字片段。"
    }
  ],
  "open_questions": [
    {
      "id": "Q1",
      "question": "尚未决定、需要跟进的问题。",
      "owner": "原文明确的问题负责人；否则为「未指定」。",
      "evidence": "原文逐字片段。"
    }
  ],
  "meta": {
    "assumptions": ["日期换算等推断说明"],
    "unverified": ["原文无法确认的信息"]
  }
}

字段规则：

• meeting.date：YYYY-MM-DD 或 null；participants 只填原文出现的名字，可保留角色括注。
• summary：最多 3 句，不得加入原文没有的判断、原因或建议。
• 编号：D1…、A1…、R1…、Q1…，同类内唯一，不跳号。
• evidence：必须是原文中连续出现的片段，允许去掉标点核对，但不允许改写、拼接或概括。校验脚本会做原文比对。
• rationale、impact、due_raw、meta.* 没有内容时用 null 或空数组，不要用「无」「暂无」等占位词。

Markdown 清单

## 会议概要
- 主题：<title>　时间：<date 或 未注明>　参会：<participants>
- 摘要：<summary>

## 决策
| 编号 | 决策 | 依据 |
| --- | --- | --- |
| D1 | …… | 「原文片段」 |

## 待办
| 编号 | 事项 | 负责人 | 截止日期 | 优先级 | 原文依据 |
| --- | --- | --- | --- | --- | --- |
| A1 | …… | …… | …… | …… | 「原文片段」 |

## 风险与待解决问题
| 编号 | 类型 | 描述 | 影响 / 负责人 | 原文依据 |
| --- | --- | --- | --- | --- |
| R1 | 风险 | …… | …… | 「原文片段」 |
| Q1 | 待解决 | …… | …… | 「原文片段」 |

## 说明
- 未指定负责人：<N> 条；未指定截止日期：<M> 条。
- 日期换算：<如「『周三前』按会议日期 2026-03-02 换算为 2026-03-04」>。
- 未核实 / 未提及：<列表>。

提取规则

决策（decisions）

判定标准：原文出现明确的结论性表述，且有讨论对象。典型信号：

• 「决定 / 确定 / 定了 / 就这么定 / 通过 / 采用 / 上线 / 不做 / 取消 / 暂缓 / 延后 / 改用」；
• 主持人总结并得到默认同意（如「大家没有异议，就这么定」）。

不构成决策，应放入 open_questions：

• 只是提出方案、表达倾向、建议「可以考虑」；
• 明确说「待评估 / 下周再议 / 没有结论」；
• 多人讨论但没有任何收敛语句。

写法：一条决策只表达一个结论；结论要能独立读懂（不依赖上下文代词）。理由只取原文明确给出的，不要替会议总结好处。

待办（action_items）

判定标准：同时满足「有具体动作」+「有人承诺或被执行分配」。典型信号：

• 第一人称承诺：「我来 / 我负责 / 我跟进 / 我周三前给」；
• 明确指派：「请 XX 输出 / XX 负责 / 由 XX 牵头」；
• 带交付物和时间的承诺：「周五前把原型归档」。

不构成待办：

• 泛泛建议（「可以考虑优化一下」）、没有动作的愿望（「希望尽快」）；
• 已经完成的动作（「已上线」）——如确需记录，放 decisions 或摘要，不进待办；
• 纯讨论观点。

字段规则：

• task：动词开头，补全宾语，使其脱离原文也能执行；不添加原文没有的范围。
• owner：只填原文明确的人名或角色。第一人称「我」且说话人可识别时，填说话人姓名；「我们 / 大家 / 需要有人」一律「未指定」。不得根据职责、部门或上下文推断负责人。
• due：原文有明确日期（「3 月 10 日」）或可安全换算的相对日期（会议日期 + 「周三前」）时，写 YYYY-MM-DD；范围或模糊表述（「这周」「月底」「尽快」）写「未指定」。换算必须写入 meta.assumptions。
• due_raw：保留原文时间词（「周三前」「这周」），便于人工复核；没有则为 null。
• priority：只有原文出现明确紧迫性表述（「阻塞」「紧急」「必须今天」「最高优先」）才填「高」；明确说「不着急」「有空再弄」填「低」；其余「未指定」。禁止凭感觉分级。

风险（risks）

提取会阻碍目标达成的事项：依赖未就绪、资源缺口、外部截止日期、关键信息缺失。impact 只写原文明确的影响；原文只说「可能影响排期」就写「可能影响排期」，不要扩写成「导致项目失败」。

待解决问题（open_questions）

提取「讨论了但没有结论」「需要某人拍板」「信息缺失待确认」的问题。不要把待办改写成问题，也不要把已决事项放进来。

禁止编造（硬性规则）

1. 不添加原文没有的决策、待办、负责人、日期、优先级、参会人。
2. 不把「讨论 / 建议 / 可能」升级为「决定」。
3. 不根据部门职责猜测负责人；不根据「下周」猜测具体日期（除非会议日期明确且可安全换算）。
4. evidence 必须逐字摘自原文；需要省略时换一句更短的连续片段，不用省略号拼接。
5. 原文没有的信息写 null / 「未指定」，并在 meta.unverified 说明，不要用常识补全。
6. 摘要不得引入原文没有的因果、评价或建议。
7. 同一件事重复出现时合并为一条，保留信息最完整的 evidence；不要把两次不同承诺合并。

执行流程

1. 通读并标注：识别会议主题、日期、参会人；标记每段话的说话人。转写稿中的语气词、重复句可忽略，但不要改变语义。
2. 建立候选池：按「决策 / 待办 / 风险 / 待解决问题」四类，把带信号的句子连同原文片段记下来。宁多勿漏，后续再筛。
3. 判定与过滤：逐条套用上方判定标准，剔除讨论、建议、已完成事项；对拿不准的条目，优先放入 open_questions 而不是 decisions。
4. 补全字段：填写 owner、due、due_raw、priority。凡原文没有的，一律「未指定」/ null，不要推断。
5. 合并去重：同一决策的多次表述合并；同一动作的重复承诺合并，保留最早或最完整的截止信息。
6. 编号与排序：按原文出现顺序编号 D1/A1/R1/Q1；待办可按截止日期升序展示，但编号不变。
7. 写摘要：最多 3 句，只覆盖「定了什么、要交什么、还有什么没定」。
8. 自校验：若运行环境可执行脚本，把 JSON 写入临时文件后运行 scripts/extract_check.py（见下）；有错误则修正后重跑。
9. 输出：先 JSON 代码块，再 Markdown 清单，最后「说明」。不要输出思考过程。

校验脚本

scripts/extract_check.py 仅使用 Python 标准库（3.8+），校验：

• 顶层字段与各分节字段是否齐全、类型是否正确；
• 编号格式与唯一性；
• due 是否为合法 YYYY-MM-DD 或「未指定」；
• priority 是否在允许集合内；
• 提供 --notes 时，逐条核对 evidence 是否为原文的连续片段（忽略空白与标点）。

用法：

# 仅校验结构
python scripts/extract_check.py output.json

# 同时核对证据是否逐字来自原文
python scripts/extract_check.py output.json --notes meeting.md

# 把警告也视为失败（提交前建议开启）
python scripts/extract_check.py output.json --notes meeting.md --strict

退出码：0 通过（可能有警告），1 校验失败，2 文件或 JSON 解析错误。脚本只做机械校验，不能代替人工判断「这条到底算不算决策」。

示例

输入（节选，完整示例见 examples/sample_notes.md）：

2. 张伟：这周先把 A 版推给 5% 流量做灰度，数据看七天再决定是否全量。大家没有异议，就这么定。灰度配置我来跟进。
3. 李娜：灰度需要埋点，我周三前把埋点方案发出来。
5. 赵敏：运营侧的春季活动页面 3 月 10 日必须上线，但现在文案还没定，可能影响排期。

输出（节选，完整 JSON 见 examples/sample_output.json）：

{
  "decisions": [
    {
      "id": "D1",
      "decision": "新版首页先以 A 版进行 5% 流量灰度，观察七天数据后再决定是否全量。",
      "rationale": null,
      "evidence": "这周先把 A 版推给 5% 流量做灰度，数据看七天再决定是否全量"
    }
  ],
  "action_items": [
    {
      "id": "A1",
      "task": "跟进 A 版 5% 流量灰度配置",
      "owner": "张伟",
      "due": "未指定",
      "due_raw": "这周",
      "priority": "未指定",
      "evidence": "灰度配置我来跟进"
    },
    {
      "id": "A2",
      "task": "输出灰度埋点方案",
      "owner": "李娜",
      "due": "2026-03-04",
      "due_raw": "周三前",
      "priority": "未指定",
      "evidence": "我周三前把埋点方案发出来"
    }
  ]
}

要点：A1 的「这周」是范围表述，因此 due 保持「未指定」而不是猜成周五；A2 的「周三前」在会议日期 2026-03-02（周一）明确的前提下换算为 2026-03-04，并写入 meta.assumptions。

自检清单

• [ ] 每条决策都是明确结论，没有把讨论或建议写成决策。
• [ ] 每条待办都有具体动作；owner 和 due 没有靠推断补全。
• [ ] 所有相对日期要么已换算（且写入 meta.assumptions），要么保持「未指定」并保留 due_raw。
• [ ] 所有 evidence 都是原文连续片段，未被改写或拼接。
• [ ] 编号格式正确且不重复；priority 只取「高 / 中 / 低 / 未指定」。
• [ ] 摘要不超过 3 句，且只包含原文信息。
• [ ] 空字段用 null / 「未指定」/ 空数组，没有「无」「暂无」等占位词。
• [ ] 风险与待解决问题没有混入待办。
• [ ] 已运行（或手工执行）结构与证据校验，无错误。
• [ ] 输出包含 JSON 与 Markdown 两部分，顺序正确。

<!-- OB-S:cMqGAoMQ9q-mmvX-1BB-zA -->