FDS-13 · B4 会议纪要生成

1. 业务说明

把精修文本(B3 产物:洗干净、分了段、标了说话人的文字稿)用大模型按公司纪要模板凝练成一份正式会议纪要——议题、结论、决策、待办、风险按模板该有的栏目归位,详略和措辞按公司习惯。产出渲染成 Word(.docx),保中文字体和排版,人能下载、能在线修订。

它是"人看到的会议成果"那一份;也是 PDCA 的源头。一条硬约束:纪要被人改后,这场会的下游(B5 抽取)必须失效重算——否则人订正了纪要里"决策改成 X",事实库里还留着旧的"决策 Y",待办/看板/复盘全跟着错。失效不靠人记得去点,靠程序比对内容指纹自动触发(机制见 FDS-17 的 content_hash 与 /facts/invalidate)。

2. 用户操作与界面

• 一般无需操作:精修(B3)完成后自动生成纪要草稿。
• 在会议结果页看到"会议纪要"卡片:在线预览(渲染后的 Word 内容)、"下载 Word"、"在线修订"。
• 点"在线修订"进编辑态:改文本→保存。保存即产生新版本,旧版可对比/回退(纪要版本留痕)。
• 保存后,卡片提示一行:"纪要已更新,本场会议的关键信息将重新抽取"——这就是下游失效联动对人的可见反馈,闭环在站内,不发任何外部消息。
• 重算进度在同一页可见(沿用 B5/流水线的进度展示)。

3. 数据与接口(字段级)

输入:meeting_files(kind=refined) 精修文本 + 其 content_hash(B3 产出时已记,见 FDS-12 §3 / FDS-17 字段)。

输出 meeting_minutes(一条 = 某会议的一个纪要版本):

字段	类型	说明
id	uuid PK	纪要版本 id
project_id	uuid, 索引	项目隔离边界(所有读写强制带)
meeting_id	uuid, 索引	所属会议
version	int	纪要修订序号(每次保存 +1)
body_md	text	纪要正文(Markdown,可编辑/可 diff 的形态)
docx_file_id	uuid	渲染出的 .docx 文件(经现有文件存储,见 §4)
source_content_hash	text	生成本版时所依据的精修文本指纹(失效联动的比对基准)
skill_version	text	生成时所用纪要技能版本(规则升级→可解释差异)
edited_by	uuid null	人改的版本填改动人;AI 生成版为空
status	enum	draft / edited / regenerating
created_at / updated_at	ts	—

辅助:meeting_minute_amendments(每次人改留痕:谁、何时、改前改后,与 FDS-17 project_fact_amendments 同套可逆机制)。

接口(acdm-backend 提供):

• POST /meetings/{id}/minutes/generate:由精修文本生成纪要(调纪要技能→渲染 docx→落库);入参 project_id、refined file_id;返回纪要 id+version。
• GET /meetings/{id}/minutes:取当前版本(正文 + docx 下载链 + 版本列表)。
• PUT /meetings/{id}/minutes:保存人改;入参带 base_version(乐观锁,防并发覆盖)、新 body_md;保存成功后服务端内部触发下游失效检查(见 §4 步 5,不靠前端调)。
• GET /meetings/{id}/minutes/{version} + …/diff:看历史版本 / 与上一版对比。
• 失效联动调用事实库 FDS-17 的 POST /facts/invalidate(按 meeting_id + 旧 source_content_hash 标 superseded),由代码侧发起。

4. 技术实现(分步)

1. 取上游:读 meeting_files(kind=refined) 文本与其 content_hash;无精修产物则不生成(纪要必须建立在精修之上,杜绝拿原始口水稿直生)。
2. 生成纪要(技能):把精修文本喂纪要技能,按公司模板凝练出栏目化正文(Markdown 中间形态),低质量/信息不足处不臆造,保留可被 B5 继续抽取的结构。body_md 落库,记 source_content_hash=步 1 的精修指纹、skill_version=当前技能版本。
3. 渲染 Word(代码):用项目已有的 python-docx(requirements.txt 已含 python-docx>=1.1.2)按公司 docx 模板把 body_md 渲染成 .docx;中文字体绑定走 OOXML w:rFonts 的 East Asian 设置(项目 app/util/file_parser.py 已用 docx.oxml.ns.qn 操作同一命名空间,渲染侧复用同一手法保证宋体/仿宋/标题字体与字号不丢)。生成文件经现有文件存储(StorageClient → Nextcloud,与 ba_report 下载/上传同一条路径)落盘,得 docx_file_id。
4. 展示:结果页预览 body_md、提供 docx_file_id 下载、列版本。
5. 人改 → 下游失效联动(代码,本章核心自建):
   • 人 PUT 保存:乐观锁校验 base_version(不一致拒绝并要求重载,不"最后写赢")→ 写新 version,edited_by 记人,改动入 meeting_minute_amendments。
   • 重算上游指纹:对人改后的纪要正文重算一个 content_hash(规范化后哈希,与 B3/FDS-17 同一算法口径,避免空白/换行噪声误触发)。
   • 比对:取事实库中本场会事实当初记录的 content_hash(FDS-17 project_facts.content_hash)与新值比对。
   • 不一致 → 调 POST /facts/invalidate(meeting_id + 旧 hash)把本场会相关事实标 superseded,并把本场会推入 B5 重算队列;一致(人只改了无关排版)→ 不动下游。失效只标记不立即重跑(重算入队按需/批量,与 FDS-17 §10 取舍一致)。
6. 重算回灌:B5 按新纪要重抽 → 经 B6 校验/B7 确认 → 写回事实库新版本(supersedes_id 指旧),下游下次读即拿到订正后结果。整条是单向数据流,人改纪要是唯一触发点。

边界:技能只决定"纪要怎么写"(模板、详略、风格);"渲染成什么格式""人改后谁失效"是确定性逻辑,代码做,不交模型自律。

5. 技能 or 代码

• 技能:meeting-minutes 纪要生成规则——公司模板栏目、各栏详略、措辞风格、什么该进/不该进纪要、禁止臆造。业务人可读可改、版本化、带 eval 样例,改动走自动测试 + 人审才生效(FDS-04 三红线)。模板细则可放技能 references/(如公司纪要栏目骨架),正文引用。
• 代码:docx 模板渲染(含中文字体 OOXML 绑定)、文件存储、版本与留痕、乐观锁、人改→指纹比对→调失效接口→入重算队列的整条联动。这些是正确性/一致性逻辑,漂移即数据错,必须代码。

判据复述(FDS-04):"换套写法/详略" = 技能;"错了会让事实库与纪要打架" = 代码。

6. 二开归类

🟢 复用 deer-flow(直接用) · 🟡 基于 deer-flow(扩展位上做) · 🔴 自建(acdm-backend)

• 🟡 基于:纪要生成做成 meeting-minutes 技能,挂技能目录、跑在 deer-flow 引擎上(用其原生技能机制 + FDS-04 业务约定,不动引擎内核)。
• 🟢 复用:python-docx 既有依赖与 qn() OOXML 字体手法;文件存储/下载链(StorageClient→Nextcloud,与 ba_report 同路径);可逆留痕机制(沿用 *_amendments 套路)。不重造渲染与存储。
• 🔴 自建(acdm-backend):docx 模板渲染管线(把 body_md 套公司模板、保中文字体)、纪要版本与 diff、人审回流(在线修订→保存→留痕→可回退)、人改→比对 content_hash→调 FDS-17 /facts/invalidate→本场会进 B5 重算队列 的失效联动。后两项 deer-flow 完全没有,是本章重点自建。

7. 与人机协同模型关系

• 纪要卡片 = 任务卡:AI 出草稿(AI 管"怎么写"),人在卡片上审阅/在线修订/回退(人管"对不对"),符合"AI 与人共写、可审阅可回滚"。
• 人改纪要触发下游失效重算 = 单向数据流落地:纪要是这场会的上游凭据,改它则下游(事实库内本场会事实、待办、看板、复盘)统一作废重来,杜绝"多处数据打架"。
• 闭环全在站内:提示、版本、重算进度都在项目工作台/会议结果页,不依赖任何外部 IM。

8. 验收(可证伪)

• 可用:精修完成后能自动生成纪要;下载的 .docx 用 Word 打开,中文字体/标题层级/字号与公司模板一致,无乱码、无字体丢失(随机抽 10 份目测 + 解析 w:rFonts 断言含 East Asian 设置)。
• 可用:在线修订保存后产生新版本,旧版可下载、可 diff、可回退;并发两人改同一纪要,后保存者因 base_version 不符被拒,无内容丢失。
• 好用(核心):人改纪要正文里某条结论并保存后,本场会在事实库中的相关事实变为 superseded 且该会进入 B5 重算队列(查 project_facts.status + 重算队列可证);只改无关排版(指纹不变)时下游不被触发(防过度重算)。
• 好用:重算回灌后再读事实库,本场会结论与订正后的纪要一致(配合 B5/B6 验收)。

9. 现状

部分有,关键缺。 项目已有 docx 生成能力(python-docx 已在依赖,ba_report 已在产 Word 类产物并经 Nextcloud 存取,qn() OOXML 操作已在用)——渲染这块是复用扩展,不从零。但没有:专门的会议纪要技能(当前是大提示词一把抓,见 FDS-12 §9)、纪要在线修订与版本回退、以及人改纪要后下游(B5/事实库)失效重算的联动(当前各下游各自重跑、互不感知纪要被改)。本章补齐人审回流与失效联动这两块自建。

10. 风险与取舍

• 风险:docx 公司模板复杂(页眉/表格/编号样式)→ 套版易跑偏。取舍:模板骨架固化为模板文件(放技能 references/ + 渲染侧按占位填),技能只管文字内容不管排版;复用项目已验证的 qn() 字体手法,不自造 OOXML。
• 风险:指纹太敏感(空白/标点变动即触发)→ 频繁无谓重算,贵且烦人。取舍:content_hash 对规范化后文本(去多余空白/统一换行)计算,与 B3/FDS-17 同口径;失效只标记不立即跑,重算入队按需/批量。
• 风险:指纹太粗(实质改了没触发)→ 事实库与纪要不一致,比频繁重算更危险。取舍:宁可偏敏感不偏迟钝;并辅以"按 meeting_id 兜底失效"——人确实改了纪要(产生新 version)却比对意外判等时,仍按 meeting_id 标本场会失效,确保订正必传导。
• 风险:业务人改纪要技能改坏(漏栏目/风格跑偏)。取舍:技能必带 eval 样例 + 改动走评审(FDS-04 三红线),坏了立刻看得见、可回退。
• 风险:人改纪要与 B5 重算并发(人又改了一次,前一次还在重算)。取舍:重算认"最新纪要版本 + 其指纹"为准,旧重算结果以版本号判废,不写回过期结论。