我把会议纪要接入AI后，终于不用在会后“二次上班”了

那次会议结束后，我花了整整两个小时整理纪要。

不是因为会议特别复杂，而是典型的中国职场会议：需求、排期、风险、负责人、客户反馈、下周动作，全都夹杂在一段段口语化发言里。等我把纪要发出去，产品同事提醒我：有两个关键风险点没写进去。

一个是接口依赖外部团队，另一个是客户确认时间可能影响上线窗口。

这两个点在会议里确实提过，但被淹没在“我们再看一下”“这块先推进”“下周同步一下”这些模糊表达里。更尴尬的是，后续项目延误时，大家回头翻纪要，发现风险没有被记录，追踪自然也就断了。

这件事让我意识到：会议纪要真正耗人的地方，不是打字，而是把混乱对话翻译成可执行结构。

于是我做了一个实验：把会议文本接入AI API，强制模型输出 结论、待办、风险 三类结构化内容，再用同一份会议文本分别测试通义千问、文心一言、Kimi、豆包等国内常用模型的表现。

先说结论：如果你只是想快速落地智能会议纪要，Kimi 和豆包在长文本理解、口语归纳、结构化输出上更省心；如果你有明确格式要求，通义千问也很适合做工程化集成。

但更重要的是，模型选型只是最后一步。真正决定会议纪要质量的，是你有没有把流程设计对。

---

一、会议纪要的效率危机：不是你写得慢，是信息太散

大多数会议纪要的痛点，可以归结为三类。

1. 会后整理时间被严重低估

很多人以为会议开完就结束了，但对负责纪要的人来说，真正的工作才刚开始。

一场一小时会议，后续往往还要做这些事：

• 从微信、钉钉、飞书或 Zoom 导出聊天记录 / 转写文本；
• 删除寒暄、重复、跑题内容；
• 提炼共识；
• 标注负责人；
• 拆分待办；
• 识别风险；
• 再发给参会人确认。

如果是项目周会、客户需求会、研发评审会，整理时间经常会接近甚至超过会议本身。

2. 关键信息容易藏在“口语废话”里

会议里最危险的信息，往往不是明确说出来的那种。

比如：

“这个接口如果他们那边这周给不了，我们可能就要先做兜底。”

这句话不是正式结论，也不是明确待办，但它其实是一个风险点：外部接口交付不确定，可能影响当前排期。

人工整理时，这类信息很容易被忽略；而一个好的AI流程，应该能把它自动归入 risk_items。

3. 待办事项缺少闭环

很多纪要看起来很完整，实际没法追踪。

例如：

• “继续推进登录改版”
• “下周再同步”
• “运营侧补充数据”
• “研发确认方案”

这些句子最大的问题是：没有负责人、没有截止时间、没有验收标准。

所以我在设计AI提示词时，最先定下的原则是：不要让AI写“漂亮纪要”，而是让它输出能进入项目管理系统的结构化数据。

---

二、从0到1搭建AI会议纪要流程

我们先不要急着讨论哪个模型更强。会议纪要AI化的第一步，是把输入和输出标准化。

你可以把它理解成一个“厨房流水线”：

• 微信 / 钉钉 / Zoom 文本是原材料；
• Prompt 是菜谱；
• AI 模型是厨师；
• JSON 是标准餐盒；
• 项目管理工具是配送终点。

1. 输入：把会议文本统一成普通文本

常见来源包括：

• 微信群会议记录；
• 钉钉会议转写；
• Zoom 自动字幕；
• 飞书妙记导出；
• 人工速记文档。

不管来源是什么，建议先统一成这样的格式：

会议主题：某产品功能上线评审
会议时间：2026-xx-xx
参会角色：产品、研发、测试、运营、客户成功

原始记录：
产品：本次主要确认登录改版是否进入下个版本。
研发：目前前端页面没问题，但短信服务接口还依赖外部团队。
测试：如果接口周五前不能稳定，我们测试时间会被压缩。
运营：希望上线前能补一版新手引导文案。
产品：那研发今天下班前确认接口风险，运营明天下午给文案，测试等接口稳定后安排回归。
客户成功：客户那边希望月底前看到演示版本。

说明：上面是一个脱敏后的会议样例结构，用于演示流程。真实业务中，请务必删除客户姓名、手机号、合同金额等敏感信息。

2. 输出：强制AI返回JSON

如果让AI自由发挥，它很容易写成一篇“看起来不错”的纪要，但不方便后续处理。

所以我们要强制它输出 JSON：

{
"summary": [],
"decisions": [],
"action_items": [
{
"task": "",
"owner": "",
"deadline": "",
"dependency": "",
"acceptance_criteria": ""
}
],
"risk_items": [
{
"risk": "",
"impact": "",
"owner": "",
"mitigation": ""
}
],
"open_questions": []
}

这个结构有两个好处：

第一，方便程序解析，可以直接写入表格、飞书多维表格、Notion、TAPD、禅道或 Jira。

第二，它会逼迫模型“按字段思考”，减少泛泛而谈。

3. 提示词模板：不要只说“帮我总结”

小白常犯的错误，是直接把会议文本丢给AI，然后说：

帮我整理会议纪要。

这会导致输出不可控。更好的写法是：

你是一个专业的项目会议纪要助手。请阅读下面的会议记录，提取结构化信息。

要求：
1. 只基于会议原文，不要补充原文没有的信息。
2. 如果负责人、截止时间、验收标准没有明确提到，请填写 null，不要猜测。
3. 输出必须是合法 JSON，不要输出 Markdown。
4. 重点识别三类信息：会议结论、待办事项、风险点。
5. 风险点包括：外部依赖、时间不确定、资源不足、需求未确认、质量风险。

JSON 字段如下：
{
"decisions": [],
"action_items": [
{
"task": "",
"owner": "",
"deadline": "",
"dependency": "",
"acceptance_criteria": ""
}
],
"risk_items": [
{
"risk": "",
"impact": "",
"owner": "",
"mitigation": ""
}
],
"open_questions": []
}

会议记录如下：
{{meeting_text}}

注意这里最关键的一句是：

如果原文没有明确提到，请填写 null，不要猜测。

这是减少幻觉的核心。

---

三、Python集成代码：从文本到JSON纪要

下面是一份简化版代码，用 requests 调用兼容式 API，完成会议文本提交、模型调用和 JSON 解析。

你可以把它改造成命令行工具，也可以接入企业微信机器人、飞书机器人或内部后台。

import json
import requests

API_KEY = "YOUR_API_KEY"
API_URL = "https://api.884819.xyz/v1/chat/completions"

MODEL = "your-model-name"

PROMPT_TEMPLATE = """
你是一个专业的项目会议纪要助手。请阅读下面的会议记录，提取结构化信息。

要求：
1. 只基于会议原文，不要补充原文没有的信息。
2. 如果负责人、截止时间、验收标准没有明确提到，请填写 null，不要猜测。
3. 输出必须是合法 JSON，不要输出 Markdown。
4. 重点识别三类信息：会议结论、待办事项、风险点。
5. 风险点包括：外部依赖、时间不确定、资源不足、需求未确认、质量风险。

请按以下 JSON 结构输出：
{
"decisions": [],
"action_items": [
{
"task": "",
"owner": "",
"deadline": "",
"dependency": "",
"acceptance_criteria": ""
}
],
"risk_items": [
{
"risk": "",
"impact": "",
"owner": "",
"mitigation": ""
}
],
"open_questions": []
}

会议记录如下：
{meeting_text}
"""

def build_prompt(meeting_text: str) -> str:
return PROMPT_TEMPLATE.format(meeting_text=meeting_text)

def call_ai(meeting_text: str) -> dict:
payload = {
"model": MODEL,
"messages": [
{
"role": "user",
"content": build_prompt(meeting_text)
}
],
"temperature": 0.2
}

headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
}

response = requests.post(API_URL, headers=headers, json=payload, timeout=60)
response.raise_for_status()

result = response.json()
content = result["choices"][0]["message"]["content"]

try:
return json.loads(content)
except json.JSONDecodeError:
raise ValueError(f"模型返回的不是合法 JSON：\n{content}")

if __name__ == "__main__":
meeting_text = """
产品：本次主要确认登录改版是否进入下个版本。
研发：目前前端页面没问题，但短信服务接口还依赖外部团队。
测试：如果接口周五前不能稳定，我们测试时间会被压缩。
运营：希望上线前能补一版新手引导文案。
产品：那研发今天下班前确认接口风险，运营明天下午给文案，测试等接口稳定后安排回归。
客户成功：客户那边希望月底前看到演示版本。
"""

minutes = call_ai(meeting_text)
print(json.dumps(minutes, ensure_ascii=False, indent=2))

防幻觉优化：三个小技巧

如果你在实际使用中发现AI“编负责人”“编日期”，可以这样优化：

1. 把 temperature 调低

会议纪要不是写小说，建议使用较低随机性。

2. 增加 null 规则

明确告诉模型：不知道就填 null，不要猜。

3. 加一层校验逻辑

例如要求所有 owner 必须来自参会角色列表，否则标记为异常。

---

四、多模型横向测试：别只看“会不会总结”，要看能不能落地

很多模型都能把会议内容“总结得像那么回事”，但真正拉开差距的，是以下三项：

• 结论提取：能不能抓住会议达成的共识；
• 待办归纳：能不能拆清任务、负责人和时间；
• 风险识别：能不能从隐含表达里看出风险；
• 结构化稳定性：能不能稳定输出合法 JSON。

为了避免伪造数据，我这里不写未经公开验证的“准确率90%+”“耗时节省60%+”这类数字。更推荐你用自己的会议文本跑一次小样本测试，方法如下：

测试方法

1. 选取 5-10 份真实会议记录；

2. 人工标注标准答案，包括：

- 应提取的结论；

- 应提取的待办；

- 应识别的风险；

3. 用同一份 Prompt 调用不同模型；

4. 按字段逐项比对；

5. 记录耗时、JSON合法率和人工修正成本。

建议记录表

这张表是选型观察维度，不是公开基准排名。不同会议类型、输入长度、Prompt 设计都会影响结果。

输出对比示例

原始会议文本里有一句：

研发：目前前端页面没问题，但短信服务接口还依赖外部团队。
测试：如果接口周五前不能稳定，我们测试时间会被压缩。

比较理想的风险识别结果应该类似：

{
"risk": "短信服务接口依赖外部团队，稳定时间不确定",
"impact": "可能压缩测试周期，影响登录改版上线节奏",
"owner": "研发",
"mitigation": "今天下班前确认接口风险，并同步后续方案"
}

不理想的输出通常有两类：

第一类是遗漏风险，只写：

{
"decisions": ["登录改版进入下个版本评审"]
}

第二类是过度脑补，比如写出原文没有的信息：

{
"risk": "短信服务供应商已经延期两周",
"impact": "项目确定延期"
}

后者看起来“聪明”，但对业务是危险的。

---

五、小白和进阶用户怎么落地？

不同用户，不需要一上来就做完整系统。

小白版：直接复制提示词，用AI对话生成纪要

适合人群：

• 产品经理；
• 运营；
• 项目助理；
• 创业团队负责人；
• 不会写代码但经常开会的人。

操作步骤：

1. 从微信、钉钉、Zoom 导出会议文本；

2. 删除敏感信息；

3. 复制上面的提示词；

4. 粘贴会议记录；

5. 要求输出 JSON 或表格；

6. 人工快速复核后发到群里。

你可以让AI最后再生成一版“适合发群里的纪要”：

请基于上面的 JSON，生成一版适合发到工作群的会议纪要。
要求：
1. 语言简洁；
2. 按【结论】【待办】【风险】【待确认问题】分组；
3. 每个待办必须包含负责人和截止时间，如果没有则标注“待补充”。

进阶版：接入API，自动生成可追踪任务

适合人群：

• 技术负责人；
• 自动化爱好者；
• 企业内部工具开发者；
• 需要批量处理会议记录的团队。

进阶玩法包括：

• 自动读取会议转写文件；
• 调用不同模型生成结构化结果；
• 写入飞书多维表格；
• 自动生成负责人待办；
• 对高风险项打标签；
• 每天定时推送未完成任务。

这一步真正有价值的地方在于：会议纪要不再是文档，而是项目管理数据源。

---

六、实际使用中的坑：AI不是秘书，它更像一个实习项目助理

把AI接进会议流程后，我最大的感受是：它不是万能秘书，而是一个很聪明但需要规则的实习生。

你规则写得越清楚，它越可靠。

坑1：会议文本太乱，模型输出就会飘

如果原始文本没有说话人、没有时间顺序、没有上下文，模型很难判断谁负责什么。

建议保留说话人：

产品：
研发：
测试：
运营：

这比一整段无角色文本更容易提取待办。

坑2：不要把“总结”和“决策”混为一谈

“大家讨论了上线方案”不是决策。

真正的决策应该是：

• 是否上线；
• 什么时候上线；
• 谁负责；
• 前置条件是什么。

Prompt 里最好明确：

只有会议中明确达成共识的内容，才能写入 decisions。

坑3：风险识别要单独强调

如果你只是让AI总结会议，它往往会优先写结论和待办，风险容易被弱化。

建议单独加一句：

请重点识别没有被明确列为待办、但可能影响项目结果的隐含风险。

这句话非常有用。

---

七、我的选型建议：先用起来，再精调模型

如果你是个人用户，我建议从最简单的对话方式开始：复制提示词，粘贴会议文本，先让AI帮你出第一版纪要。

如果你是团队用户，可以直接走API路线，把会议纪要变成固定工作流。

一个务实的选择路径是：

• 长文本会议多：优先测试 Kimi；
• 日常会议、轻量自动化：优先测试豆包；
• 需要稳定结构化输出：重点测试通义千问；
• 已有百度生态或办公场景：可以测试文心一言；
• 多模型对比或统一接入：建议用统一API平台管理密钥和调用。

最后再强调一次：不要迷信单一模型。会议纪要这类任务，模型能力固然重要，但 Prompt、输入清洗、JSON 校验、人工复核流程，同样决定最终质量。

AI 已经不是“未来会改变办公”的东西。它现在就能把你从会后两小时的手动折腾里解放出来。

如果你也想把这些AI模型快速接入自己的会议流程，不妨直接访问 api.884819.xyz 获取API密钥和结构化输出模板，几分钟就能完成集成，让你的会议纪要从“手动折腾”变成“智能提取”。

8848AI 平台注册流程很简单，用户名+密码即可注册，不需要邮箱验证；平台内置AI对话功能，注册后直接能用；国产模型如 Deepseek、千问等可免费使用；没有月租、没有订阅，按量付费。新用户注册即送体验token。

除了会议纪要，AI在项目风险追踪与跨团队决策中的应用同样值得深入研究。下一篇，我会继续拆解：如何把AI接进项目协作流程，让风险自动浮出水面，让待办真正闭环。

#AI教程 #会议纪要 #智能办公 #国产大模型 #Prompt技巧 #API集成 #8848AI