会议总结的价值不在于把转写文本原样搬进文档，而在于把散落在口语表达中的结论、行动项和分歧点提炼成可检索、可追踪的结构化信息。设计标准化模板，本质上是在约定一种信息抽取契约：哪些信息必须出现，哪些表达需要归一，哪些字段允许留空。讯飞听见输出的转写结果已经解决了语音转文字的第一层问题，接下来要做的就是把长文本压缩成固定结构。
一、先把字段口径定下来，而不是只定标题
设计会议模板时，如果只列“会议主题、时间、参会人、内容”四个标题，填写者往往会把转写文本整段粘贴进去。标准化模板和普通标题列表的区别在于，每个字段必须有明确的填写口径。例如“议题”不是指会议议程，而是指本次实际讨论并产生结论的问题；“待办”不是所有提到要做的事，而是有明确责任人和完成时限的行动项。
建议从最小字段集开始：meeting_id、title、date、participants、agenda、decisions、action_items、risks、open_questions、next_meeting。每个字段再定义类型、必填性、来源段落和示例值。比如 action_items 必须是数组，每项包含 owner、task、due_date，不能只写一个句子。
这里给出一个JSON Schema片段，用来约束字段结构和类型。它不负责从文本里抽取内容，但能让后续自动化脚本和人工补录都有同一个校验基准。
{
"type": "object",
"required": ["title", "date", "participants", "decisions", "action_items"],
"properties": {
"title": { "type": "string", "maxLength": 80 },
"action_items": {
"type": "array",
"items": {
"type": "object",
"required": ["owner", "task", "due_date"],
"properties": {
"owner": { "type": "string" },
"task": { "type": "string", "minLength": 4 },
"due_date": { "type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}$" }
}
}
}
}
}
二、从讯飞听见转写文本到模板字段的映射
讯飞听见导出的文本通常带有说话人、时间戳或纯对话流。直接让大模型或脚本“读一遍写总结”效果不稳定，更可靠的做法是先做段落切分和角色识别，再按信号词抽取。比如把转写文本按发言人和时间对齐，一个片段作为最小抽取单元。若导出格式为 说话人A 00:01:23 我们确认周五前完成接口联调，可以用正则先拆成 speaker、time、content 三列。
抽取待办时，不要只依赖“我来做”“你负责”等词，因为口语中经常省略主语。更稳定的是用“时间点+动作+产出物”的组合规则。例如包含“周五前”“今天下班前”“下周一”等时间短语，同时出现“输出”“完成”“发给”“提交”等动词，就标记为候选待办。决策字段则可由“结论是”“确定”“定了”“一致同意”等表达触发。风险字段可以从“风险”“隐患”“可能延期”“依赖”等词出发，但要人工复核，否则容易把假设当风险。
下面是一段Python示例，展示如何从纯文本里粗筛行动项。它不追求精确，但可以作为人工填写的预填数据，减少整理时间。
import re
text = """张工 00:15:20 我们确认接口联调在周五前完成，我来输出联调报告。
李工 00:16:02 依赖第三方认证，可能存在延期风险，需要提前跟进。"""
time_words = r'(周五前|今天下班前|下周一前|本周内)'
action_verbs = r'(完成|输出|提交|发送|跟进|联调|确认)'
candidates = []
for line in text.splitlines():
if re.search(time_words, line) and re.search(action_verbs, line):
candidates.append(line.strip())
print(candidates)
三、让模板跟着会议类型演进，而不是一套打天下
标准化最容易掉进的误区是把所有会议都塞进同一张表。实际上，项目周会关心的字段和产品评审会差别很大。更好的做法是保留公共底座，例如 title、date、participants、action_items，同时允许按会议类型挂接扩展块。比如评审会新增 review_comments 和 approval_result，客户沟通会新增 customer_requests 和 follow_up_owner。
通过配置驱动字段，比每次改文档模板更可靠。可以维护一个YAML或JSON配置，描述某类会议包含哪些字段、字段类型和提示语。讯飞听见的转写结果接入后，按配置抽取对应部分，既能复用抽取逻辑，又能适应不同场景。
下面是一个简单的配置示例，用来描述周会和评审会各自的扩展字段。
{
"weekly": {
"extends": ["base"],
"fields": ["progress", "blockers", "next_week_plan"]
},
"review": {
"extends": ["base"],
"fields": ["review_comments", "approval_result", "rework_items"]
}
}
这种配置方式的好处是，模板变更只改数据不改代码。比如团队决定评审会要增加“风险等级”字段，只需在配置中追加一项，然后重新生成表单或提示词。不要为了每个新需求去修改一整套文档模板。
四、把总结模板接入自动化流程，减少手工搬运
标准化模板真正产生效益，是在它能够被自动填充、校验和推送之后。如果每次开完会还要人工打开Word复制粘贴，模板再标准也坚持不了几周。建议将流程拆成三步：先获取讯飞听见的转写文本或API结果，再运行抽取和模板填充脚本，最后把生成的JSON或Markdown推送到项目管理系统或群聊。
讯飞听见的API通常返回带时间戳和说话人信息的转写结果，可以按上文规则先做候选待办抽取。抽取完成后写入模板JSON，并调用校验函数。若校验不通过，就把错误信息原样回传给会议记录人，而不是直接发布。这样可以形成“机器预填—人工确认—校验拦截—发布”的闭环。
具体实现时，可以把模板JSON作为唯一的中间格式。无论最终展示成Word、飞书文档还是Markdown，都从同一份JSON生成。这样能避免不同人维护不同格式导致口径漂移。例如下面这段Python代码将模板JSON渲染成简单的Markdown清单：
def render_markdown(summary):
lines = [f"# {summary['title']}", ""]
for item in summary.get("action_items", []):
lines.append(f"- [ ] {item['task']}（负责人：{item['owner']}，时限：{item['due_date']}）")
return "\n".join(lines)
print(render_markdown(summary))
设计讯飞听见会议总结的标准化模板，重点不是把表格画得多漂亮，而是把字段口径、抽取规则和校验逻辑固化下来。模板字段要少而明确，抽取规则要能处理口语化表达，校验规则要挡住缺责任人、缺时限这类高频问题。落地时保持“公共底座+会议类型扩展”的配置化思路，再接入自动预填和推送流程，会议记录才能真正从转写文本升级为可执行的项目资产。