AI 把语音会议纪要落成公文：乱码、老 .doc、ASR 错名三道坎

背景与目标

9 月 23 日下午 3 点，甬金高速改扩建东阳段征迁工作推进会开完，手头有四份素材：微信语音转文字出来的 AI 会议纪要（txt）、会议通知（老格式 .doc）、项目部征迁汇报材料（docx）、山口村蓄水池塘情况说明（md）。

当晚任务两条：一是以东阳市指名义出正式公文会议纪要，二是把情况说明按实际背景改好。随后追加第三条：情况说明也落成公文 docx。产出全部归入任务文件夹 会议纪要/2026年9月23日会议/。

过程回顾

1. 取素材：读 txt 和 md 顺利；汇报材料 docx 用 python-docx 提取——第一坑出现（见下）；会议通知 .doc 提取——第二坑。
2. 起草纪要：按 8 月 11 日房屋拆除推进会纪要的体例成文，五段结构（镇街遗留问题/三改处置原则/山口村专项/审计档案/工作部署），以 参考资料/模板/WPS公文底稿.docx 为底稿生成，GB/T 9704 版式逐项落实。
3. 校验：重新打开 docx 逐段核对字体、字号、页边距，实测通过。
4. 改情况说明：补真实背景（TJ01 标占用山口村原山塘 2/3 库容、9·23 推进会提出安全顾虑）、改致送单位为东阳市指、管控措施补"已按推进会意见暂停施工"。
5. 情况说明转公文：第二轮一条指令"写成公文文档"，直接复用同一套生成逻辑出 docx。
6. 收尾：一次性脚本和中间文件全删（项目 AGENTS.md 纪律），文件夹内只留四份正式素材加两份成品。

关键踩坑

坑一：docx 文本 print 到 Git Bash 终端，整段乱码

• 现象：python-docx 提取的中文 print 到终端全是问号方块，一百多段内容没法用。
• 根因：Git Bash 控制台是 GBK 代码页，Python stdout 默认跟着走，UTF-8 中文直接阵亡。项目 AGENTS.md 其实早写了"路径含中文注意 UTF-8"，但我图快直接 print 了。
• 解决：改为 open(..., 'w', encoding='utf-8') 写临时文件，再用 Read 工具读。一轮浪费。

坑二：WPS 生成的 .doc，antiword 拒认

• 现象：file 明明显示 Composite Document（标准老 Word 格式），antiword 却报 "is not a Word Document"。
• 根因：该文件是 WPS Office 写的 .doc，内部流结构 antiword 不认。另外第一次调用还带着中文路径，错上加错。
• 解决：PowerShell 探活 COM 组件（Word.Application、KWPS.Application 均可用），用 Word COM 打开后 SaveAs 为 txt，再 iconv -f GB18030 -t UTF-8 转码。三步走通：

powershell.exe -NoProfile -Command "
\$w = New-Object -ComObject Word.Application
\$d = \$w.Documents.Open('D:\path\xxx.doc', \$false, \$true)
\$d.SaveAs([ref]'D:\path\xxx.txt', [ref]7)   # 7 = wdFormatEncodedText
\$d.Close(\$false); \$w.Quit()"
iconv -f GB18030 -t UTF-8 xxx.txt > xxx_utf8.txt

坑三：语音纪要的 ASR 错名地雷阵

语音转文字的纪要里埋了一串同音错名："永金高速"=甬金、"魏塘镇三口村"=巍山镇山口村、"60互通/六十胡同"=六石、"微山镇"=巍山镇、"护航公司"=建管公司、"蔡国东"疑为"蔡国忠"。人名地名录进正式公文，错一个就是事故。

• 解法：以书面汇报材料为基准做交叉验证——汇报材料写"白岩湾村蔡国忠户""红江村蒋中华户"，人名一律采用书面写法；书面材料没有的推断项（如"节后第二天"推断为国庆假期）在交付说明里列成待核实清单，不写死在正文里充当确定事实。最终向本人交出 5 条待核实点，由他拍板。

最终方案

• 纪要：甬金高速改扩建东阳段征迁工作推进会会议纪要（2026年9月23日）.docx，五部分结构。按本人明确口径，汇报材料里十余处桥梁净空不足、降坡改路等工程科三改问题不逐点展开，压缩为四条处置原则（净空不低于原标准走设计变更、降坡同步配排水、用地要素打包报自规、联合踏勘逐个销号）。
• 情况说明：md 源文件保留，另出公文版 docx，主送东阳市指顶格、落款 TJ01 标项目部右对齐。
• 版式落实细节：标题方正小标宋二号居中；正文仿宋_GB2312 三号、行距固定 28 磅；一级标题黑体、二级楷体；首行缩进用 w:firstLineChars="200"（字符单位，比磅值换算稳）。

做得好的地方

1. 口径执行准：本人一句"类似那种桥梁净空不够需要降坡的情况简化说明"，纪要里三改部分就只剩原则不见点位，王村通道 3.8 米这种有会议决议的才保留一句话。
2. 格式一次到位：生成后实测页边距上 3.7/下 3.5/左 2.8/右 2.6cm、逐段字体字号全对，没有返工。
3. 可追溯：5 条 ASR 歧义点在交付说明里逐条列明推断依据，留给本人裁决，不替他拍板。

复盘与改进

1. 中文项目在 Git Bash 里跑 Python，输出一律写文件再读，禁止 print 长文本到终端——这条应写进项目 AGENTS.md 的文档读取章节，目前只写了文件读写编码，没写终端输出。
2. 老 .doc 提取应形成固定顺序：先复制到 ASCII 路径 → antiword 试 → 失败直接上 Word COM，跳过本次"带中文路径试 antiword"的无效动作。
3. 日期类推断（"节后第二天"、情况说明落款写成 9 月 24 日而成文时还是 9 月 23 日 23:25）应默认标【待核实】，不写死。

成长评估

AI 自评失分点：①乱码坑是章程已载明事项的再犯；②antiword 首次调用带中文路径，属低级叠加错误；③两处日期推断未默认打标，靠交付说明兜底而非正文自律。

素材点

• "语音转文字 → 公文"的 ASR 错名校正清单法（书面材料交叉验证+待核实清单），可沉淀为征迁科固定工序；
• Word COM 救场老 .doc 的三行 PowerShell，全项目可复用；
• GB/T 9704 版式的 python-docx 参数集（firstLineChars=200、固定 28 磅行距），已在两个文档上验证。