一、会议纪要的常见失败
开完会，纪要发出去，一周后回头查一项决定，发现纪要里写的是"大家讨论了一下定价"。
这种纪要等于没写。
可用的纪要必须回答四个问题：定了什么、谁负责、什么时候完成、没定的卡在哪里。
二、流程四步
第一步：先拿录音转写。
不要直接让模型"总结会议"，先转成逐字稿。转写稿是原料，总结是加工。
第二步：分两层提炼。
第一层：事实。谁说了什么，围绕什么议题。
第二层：决议。哪条达成了一致，哪条被搁置。
很多人把两层混在一起，读的人分不清讨论与结论。
第三步：抽取行动项。
要求模型按"负责人 / 事项 / 截止日 / 依赖"四列输出表格。如果发言人没明确负责人，宁可填"待确认"，不要猜。
第四步：人工复核。
重点核三处：人名、数字、否定句。
否定句最容易翻车，"暂不上线"常被总结成"计划上线"。
三、可用的提示词
```
下面是一段会议逐字稿。请输出三部分：
- 议题与讨论要点（每条不超过50字）
- 已达成的决定（只写明确表态过的）
- 行动项表格：负责人/事项/截止日/依赖
不确定的信息标注"待确认"，不要推测。
```
最后一句必须写。不写，模型就会帮你补上去，风险很大。
四、纪要怎么发出去
纪要不是给自己看的。发到群里时，开头一句结论、中间行动项、最后待定事项。
不要把逐字稿直接贴进去，没人看。
五、一个提升体验的小动作
把行动项单独拆出来，变成任务分给对应的人。
这一步用手动也行，用工具也行。关键在于同一份纪要只能有一处负责更新，否则行动项很快会变成两套口径。
六、关于隐私
会议录音涉及公司内部信息，上传到哪个服务、存多久、能不能删，得提前确认。
涉及人事、合同、未公开数据的会议，我建议只做本地转写。
七、想补工程侧的话
如果要做团队内部的纪要工具，除了模型，还得处理存储、检索、权限。这部分属于后端活。
BackendWiki 里关于 MySQL 索引与事务、Redis 缓存、RESTful 接口设计的内容都比较基础但完整，适合做内部工具的开发者补一补。
八、一句总结
纪要的价值不在"写得多",在"写完之后大家知道接下来干什么"。