冗长录音混乱难整理？掌握AI会议纪要提炼提示词一键提取核心决议与行动项清单

开完两小时跨部门会议，拿到一份动辄两三万字的语音转文字（ASR）文稿，绝大多数人的第一反应是崩溃的。文稿里充斥着大量的“那个、然后、嗯啊”等口癖语气词、同音错别字、频繁被切断的碎片化句式，以及各部门争论不休的发散性闲聊。

如果直接把这一大段未经处理的口语文本扔给大模型，随手输入一句“请帮我总结这份会议纪要”，得到的结果通常只有两类：要么是通篇假大空的套话摘要，遗漏了真正拍板的决策；要么是把讨论过程中的随口建议，误判为团队已经敲定的执行目标。

要想让大语言模型（LLM）精准过滤杂音，一键输出直接可用于项目排期、责任追踪的高质量纪要，关键不在于模型有多聪明，而在于你如何通过结构化提示词（Structured Prompting）对大模型的注意力进行定向约束。

一、 为什么常规提示词总在会议纪要上翻车？

大模型处理会议记录时最容易出现三类致命问题：

1.混淆“讨论过程”与“最终决议”：A同事提议“要不要换方案B”，B同事反驳，最后领导决定“维持方案A”。普通提示词往往把“方案B”也提炼成决议，造成严重的业务误导。

2.行动项（Action Items）缺乏履约要素：只输出“尽快优化产品性能”，缺乏负责人（Who）、明确截止日期（When）与验收标准（Deliverable），这种行动项在实际工作中毫无执行意义。

3.长文本“迷失在中间”（Lost in the Middle）：当录音转写文字超过1.5万字时，模型容易过分关注会议开头的寒暄和会议结尾的总结，把会议中段长达40分钟的核心争论与拍板细节彻底忽略。

为了直观展示差异，我们来看常规粗糙提示词与工程化提示词的实际产出对比：

二、 底层模型选型与核心推理参数配置

不同基础模型在处理长语音转写稿时的表现各有侧重。选择适配的模型，并调整合理的推理参数，是保证输出结果稳定的第一步。

1. 主流大模型长文本处理特性横向对比

2. 模型核心参数调优指南

会议纪要属于高度严肃的事实提取型任务，容错率极低。在通过 API、开源框架或平台高级设置调用模型时，必须将参数固定在低随机性区间：

•Temperature（采样温度）设置为 `0.0` 至 `0.2`：绝不能使用默认的 0.7 或 1.0。将温度压低能够严格抑制模型的发散性创造，迫使模型紧扣输入文稿中的事实，显著降低幻觉。

•Top-P（核采样）设置为 `0.1` 至 `0.2`：与低 Temperature 协同工作，过滤掉长尾概率词汇，确保词语选择高度确定。

•Frequency Penalty（频率惩罚）设置为 `0.0`：不需要刻意避免用词重复，会议中的专有名词、人名必须保持前后一致。

•Max Tokens（最大输出限制）设置为 `4096` 或更高：长会议提炼的决议与行动清单条目较多，如果输出长度限制过小，会导致在输出核心表格时中途截断。

三、 工业级会议纪要提示词核心架构解析

编写高精准度的会议提炼提示词，推荐采用 结构化标签法（基于 XML 标签的分离架构）。这种结构能让大模型一眼区分什么是系统角色、什么是提取规则、什么是格式限制、什么是输入文稿。

整个提示词体系由五个核心模块构成：

1.角色与目标设定（Role & Objective）：赋予模型高级项目总监或专业参谋角色，定义信息梳理的基准水准。

2.术语与背景对齐（Context & Glossary）：前置告知公司内部代号、项目简称、参会人员职位，避免拼音转写错误导致的身份错乱。

3.信息提取负向约束（Negative Constraints）：明确告诉模型“严禁做什么”，这是防止误将头脑风暴记作决议的防火墙。

4.认知分步链路（Thinking Step-by-Step）：要求模型在输出最终结果前，先在思考块中完成文本清洗、观点归并与决策溯源。

5.固定输出结构（Output Format）：使用标准化表格与层级清单，锁定核心决议与行动项。

四、 开箱即用：高精度会议决议与行动清单提示词模板

在日常实操中，你可以直接复制以下完整的提示词模板，粘贴到 Claude 3.5 Sonnet、GPT-4o 或 Gemini 中使用。注意将 “ 和 “ 中的占位内容替换为你的实际信息。

<system_instruction>
你是一位拥有10年跨国企业协作经验的资深项目管理专家（PMP）。你的核心任务是审查杂乱无章的会议口语录音转写文稿，从中过滤冗余信息，准确提取会议达成的【核心决议】、【执行行动项】与【待决争议事项】。

在执行提取任务时，请严格遵守以下核心判定规则：
1. 决议判定红线：
   - 只有参会各方明确达成共识、或团队负责人拍板确认的事项，才能列入【核心决议】。
   - 任何“我觉得可以试试”、“后续再讨论”、“方案A可能更好”等建议、讨论或头脑风暴内容，一律严禁记为决议。
2. 行动项判定标准（必须符合SMART原则）：
   - 必须包含具体的唯一责任人。如果会议中未明确指定个人，仅提到“技术部去查一下”，请在责任人一栏填写“待确认（建议技术负责人）”，严禁胡乱指派。
   - 必须包含清晰的交付成果与截止时间。若发言中只说了“下周搞定”，需根据会议日期推算绝对日期，无法推算的标注“需会后对齐时间点”。
3. 事实一致性约束：
   - 严格忠于原始文稿事实，严禁加入输入文本中不存在的外部知识或臆想推断。
   - 遇到转写错别字（如“接偶”应为“接口”），结合上下文合理修正，但保留原意。
</system_instruction>

<context>
- 会议时间：2025年X月X日
- 会议主题：用户增长中台Q3重构方案评审
- 核心参会人及角色：张伟（产品负责人）、李敏（架构师）、王强（测试组长）、刘总（部门总监）
- 业务专有名词词典：
  - CDP：客户数据平台
  - A/B分流引擎：内部代号“北极星系统”
</context>

<workflow>
在正式输出最终报告前，请在内部进行三步事实核查推理：
第一步：清洗口语噪音，过滤客套寒暄、重复讨论与废话。
第二步：梳理各方发言中的分歧点，定位最终达成一致的结论片段。
第三步：检索包含“谁、什么时候、交出什么”的承诺句式，提取行动清单。
</workflow>

<output_format>
请严格按照以下 Markdown 格式结构输出，严禁擅自调整排版层级：

# 【会议纪要】[填入会议主题]

## 一、 会议核心结论（速览）
> 请用简明扼要的3-5句话，总结本次会议解决的核心痛点与达成的全局共识，方便高管在30秒内把握关键信息。

## 二、 核心决议列表（Confirmed Decisions）
| 序号 | 议题模块 | 最终决策内容 | 决策背景与依据 | 涉及影响部门 |
| :--- | :--- | :--- | :--- | :--- |
| D01  | [如：系统架构] | [明确拍板的方案，禁止模糊表述] | [为什么选该方案，简述理由] | [如：研发部、运维部] |

## 三、 行动项追踪清单（Action Items）
| 任务编号 | 待办具体任务描述 | 责任人 | 截止时间（绝对日期/里程碑） | 交付物及验收标准 | 前置依赖项 |
| :--- | :--- | :--- | :--- | :--- | :--- |
| A01  | [做什么，动宾结构] | [具体姓名] | [YYYY-MM-DD 或具体节点] | [如：API接口文档/PRD评审稿] | [如：依赖D01决议通过] |

## 四、 搁置与未决议题（Open Issues & Risks）
- **未决事项1**：[争议的核心内容]
  - 核心分歧：[A方观点 vs B方观点]
  - 下步跟进方式：[谁负责在什么时间点发起再议]
- **识别到的潜在风险**：[包括工期风险、技术风险或资源冲突]

</output_format>

<transcript>
[在此处完整粘贴你的会议转写文本或ASR导出的文字稿]
</transcript>

五、 实操工作流SOP：从录音文件到结构化文档的落地闭环

在实际办公场景中，不要直接把整段录音丢进去不管，建立标准化操作流程（SOP）能将提炼准确率稳定在可用状态。

[原始录音] 
   │
   ▼
步骤一：音频转文字（ASR引擎处理 / Whisper / 飞书妙记 / 腾讯会议）
   │
   ▼
步骤二：前置对齐（提取参会名单、填充专有名词缩写、明确会议背景）
   │
   ▼
步骤三：模型推理（应用低 Temperature 参数 + 结构化提示词）
   │
   ▼
步骤四：人工交叉复核（基于“决议红线”与“行动项五要素”核对）
   │
   ▼
[可直接抄送群聊与项目协同软件的正式纪要]

步骤一：录音转写文稿质量自检

若采用纯文本模型，首先通过转写工具输出带说话人标记（Speaker Diarization）的文稿。若使用 Gemini 1.5 Pro，可直接上传音频原文件，免去前置转写步骤，其自带的多模态机制能通过语调直接判断发言人态度（如犹豫、肯定、强烈反对）。

步骤二：前置上下文注入（关键动作）

大模型之所以会把行业术语听错，是因为缺乏组织内部的先验知识。在输入文稿前，花30秒补充一行说明（如：“本次会议中提到的‘神策’是指数据分析系统，‘老李’是指架构师李敏”），能直接消灭80%以上的实体识别错误。

步骤三：分步处理超长会议（超3小时会议必用技巧）

如果会议文稿长达4-5万字，直接一次性输入即便不超出上下文窗口，也会触发模型的注意力衰减。建议采用按议程切块处理（Chunking by Topic）：

1.先让模型快速阅读全文，仅输出一份“会议议程时间线拆解”；

2.按照议程切片，分别执行上述提取提示词；

3.最后让模型执行一次“汇总去重”，合并行动项。

步骤四：输出结果的事实审计清单（Checklist）

在将输出内容发送至工作群前，执行以下四项快速审查：

•[ ] 行动项中的责任人是否存在“全员”、“大家”等无责指派？（若有，打回修正）

•[ ] 截止时间是否明确到了具体时间节点，而非宽泛的“尽快”？

•[ ] 是否漏掉了会议开局提出的核心目标？

•[ ] 是否存在模型擅自臆测的外部解决方案？

六、 常见应用场景模型选型建议

在实际业务部署与日常办公中，不同场景对延迟、成本和精度的敏感度截然不同。参考以下方案进行选型：

七、 避坑提醒

在构建自动化纪要提炼流程时，有三个隐蔽陷阱需要时刻警惕：

1.警惕“礼貌性附和”被误判为决策：在中文会议环境中，参会人常说“行吧、先这样、那就看情况”，这往往只是敷衍或暂缓决策，并不是最终确认。提示词必须强制模型寻找具备终局性质的确认语句。

2.严禁依赖默认 Temperature：很多工程师在调用 API 时忘记修改配置，导致默认温度（通常为 0.7 甚至 1.0）生效，输出的行动项每次运行都不一致，直接破坏了生产环境的严肃性。

3.敏感信息合规处理：在将包含商业机密、财务数据、人事变动的录音提交给公开云端模型前，务必在本地流程中做好脱敏清洗，或确保使用的是承诺不进行数据训练的企业级 API。

只要把提示词的角色定位清晰、逻辑判断规则封死、输出结构固定，哪怕面对几万字逻辑混乱的口语转写稿，大模型也能在数十秒内抽丝剥茧，输出一份条理清晰、权责分明的专业会议决议与行动项清单。