会议纪要撰写助手

会议整理常见的信息断层

直接把会议录音或速记转交给通用大模型，最容易踩的坑是“脑补”。模型会为了读起来通顺，悄悄补全谁负责什么、截止日期是哪天，甚至把某人的一句“我觉得可以试试”润色成“会议正式决定采用某方案”。待办被凭空捏造、分歧被强行抹平，这份纪要发到群里只会带来执行层面的灾难。

从原始记录到结构化报告的流水线

这个技能不拼凑漂亮的废话，而是把写作过程严格绑定在你提供的源文件上。它的核心工作流可以分为四个关键步骤：

• 源文件解析与定位：直接读取纯文本、CSV 和 JSON；遇到 DOCX 则调用 scripts/extract_meeting_text.py 提取；对于扫描版 PDF 或图片，自动走 OCR 流程（优先使用 $mineru-document-parser）；保留文档的页码、幻灯片章节或发言人时间戳。
• 构建证据账本：在正式下笔前，模型会先在内部建立事实台账。只有明确被记录的讨论点、提案、反对意见和决议才会入册，并且都带有对应的来源定位符。
• 严苛的事实定性：这是整个流程的把关核心。只有原文出现“同意”、“批准”、“确认”等字样时，事项才会被划入 Decisions；所有停留在建议、偏好阶段的想法全部留在 Discussion；凭空推断的Owner、Deadline或表决结果在这里被绝对禁止。
• 套用去模板化的自然文风：剥离开场白和客套话，按照标准的章节（摘要、议程与讨论、决议、待办、风险与遗留问题、后续跟进及来源覆盖）进行输出，语言对齐正式但克制的工程报告风格。

适用边界与证据纪律

• 缺失即标记未知：遇到原文未提供的日期、出席人等必要字段，报告会直接写明材料未提供或待明确，绝不用常识去填补空白。
• 冲突保留不调和：如果不同来源对同一个决策的描述互相打架，技能会原样保留矛盾点并附带出处，而不是强行帮你捏出一个各方都满意的完美结论。
• 纯结果导向：最终交付的只会是一份干净、严肃的报告正文，它不会在文中出现“作为AI助理我为您整理了…”这类自我描述，也不附带任何免责声明。