4.3 纪要模板：一页纸格式与历史归档

料备齐了：待办、决议、发言人归集、会议元信息。但直接把这堆结构化数据扔给同事，还是没人看——信息是全的，就是读不下去。纪要这个东西，读的人是老板和同事，他们只愿意花两分钟。所以我们定了一个死规矩：纪要必须一页纸，多出来的内容全部下沉到附件和链接里。

一页纸纪要版式

一页纸不是少写，是按阅读优先级排布。版式我们定了五个区块，每个区块都标注内容来源和建议字数，方便后来的人照着填：

表里我故意把来源一列写得啰嗦，是因为新接手纪要模板的人最喜欢问的内容就是这块从哪来。来源栏直接堵住了返工的问题，也顺便说明哪些区块机器自动填、哪些必须人来。

概要放最上面，因为老板只看这一块；待办放第二，执行的人直接往下扫一眼就知道谁的活。讨论要点是唯一需要人工摘选的区块——也是我故意保留的人工环节，机器摘不全会议室里那些弦外之音。

一页纸还有个排版细节：待办表的负责人列加粗，截止日用独立一列。以前把截止日写在任务描述里（比如周五前补齐埋点），读的人要逐行扫一遍才找到自己的活，拆成独立列之后谁负责什么、什么时候交，一眼扫到底。这种小改动效果出奇地好。

版式表里还藏着一条不成文约定：所有机器自动生成的区块，渲染时统一加浅灰底色；人工摘选和人工确认的部分留白。这个视觉区分不是为了好看，是让读的人心里有底：灰色的内容出处的可信度由工具兜着，白色的是人看过眼的，将来追责也知道先问谁。

附件区是一页纸之外的延伸：逐字稿、提取 JSON、原始录音链接挂在纪要末尾不显眼的一行小字里。想深入的人点得进去，不想看的人完全不受打扰。这一行小字是三版模板里唯一从第一版活到第三版的设计，大概是因为它真的把详略这两件事同时照顾到了。

一页纸的长度卡得很死：A4 一页内渲染完，超出一页就说明排版或上游出了问题。我们有次待办提了十八条，一页塞不下，最后发现是提取环节把讨论也抓成了待办，问题不在模板而在上游。模板也是一面镜子，哪里超标了，往往是上游哪一环出了毛病。

历史归档目录设计

纪要写完不是就完了，得找得到。归档目录按年、月、会议类型三层组织，前期目录设计做扎实，后面几百份纪要也不会乱：

这个结构看起来层级挺深，但检索的时候非常清爽：想看上季度所有项目评审，直接钻到对应目录；想找某次会议的具体结论，按日期一查就有。检索和双向链接的更深玩法，可以参考我另一本笔记知识库实战，那里把这一套讲得比较透。

说到目录设计，多走一步就能省很多事：文件名里把日期放最前面、用补零的两位数字（01 到 12），这样文件系统默认排序就是天然的按时间线。序号的最后一位是同一天第几场，重名会议再也不会互相覆盖。

归档目录还有个版本演进的小插曲。最早图省事只按年月两级，结果同一天开了周会又开了项目评审，两种纪要混在一个月度目录里翻起来费劲。加了会议类型这层之后清清爽爽。层级不是越多越好，但按检索习惯分层，多走一层就值。

归档还有两条不成文的规矩。第一，归档即冻结：发布过的纪要不再改，发现错误就发勘误链接附在后面，而不是直接改掉旧文件——纪要是有历史效力的，改了就分不清哪版是最新的。第二，附件和纪要同生命周期：原始录音存三年，逐字稿和提取结果长期保留，清理稿跟着走。存储成本本身很低，第五篇会细算账。

归档做起来之后，检索的需求自然就跟上了。光有目录树还不够，同事常问的是上个月那个关于年终方案的决议是怎么定的，这种跨会议的内容检索得靠全文索引和标签体系。我们在纪要的元信息里加了项目名、关键词两类标签，检索时按标签过滤比翻目录快得多。更系统的检索和知识沉淀做法，可以参考我另一本笔记知识库实战，里面有完整的标签体系和全文检索方案。

标签刚加的时候也乱过一阵子：每个人填的关键词随手来，同义词满天飞（登录页、登录模块、login 各填各的）。后来统一收口成受控词表，十几个项目名加三十个常用主题词，填的时候从列表选而不是手敲，检索立刻清爽。标签不在多，在受控。

顺带一提，归档目录由于和纪要页面同源，发布时一起部署就行，不用额外维护第二套系统。部署上的门道，可以参考轻量建站实战里内部工具站的做法，我们这本工具的页面也是照着那套思路搭的。

纪要与原始稿的关联

一页纸纪要是压缩过的信息，难免有人想看原话。所以每份纪要都必须能一键追到原始材料，我们的做法是双向关联：纪要的每条待办和决议后面都挂一个时间戳锚点，比如待办来源时间戳 00:12:35，点击就跳到逐字稿对应位置；反过来，逐字稿的相应段落也标注了它被哪条纪要引用。纪要、逐字稿、原始录音通过对象存储的 URL 串在一起，三者同目录存放，移动也不会断链。

这个设计在第一次争议时救了场。两个同事对某个决定有分歧，打开纪要点时间戳，原话三秒钟调出来，争议立刻消停。也正是因为这个链路，我在 4.1 里坚持清理后的文本绝不覆盖原文——原文被覆盖了，锚点就成了死链。

锚点的实现上有一处需要注意：时间戳用的是转写给的时间，不是播放器时间。两者差个零点几秒问题不大，但我们遇到过转写开头静音被截掉的情况，直接跳会偏出两三秒，后来统一在录音和转写结果之间做了时间基准对齐，跳转才真的准。

关联链路还分单向和双向两种用法，适用场景不同。单向是默认形态：纪要挂向原始稿，够轻、好维护。双向用在反复参引的场合，比如某条决议被后续三次会议引用，双向链接让每份纪要都能互相串起来，追决议的前世今生特别方便。双向的做法就是笔记知识库实战里双向链接的思路，搬到会议纪要场景依然好用。

关联做完还不算完，偶尔回查一下死链很必要。转写文件被归档移动、原始录音清理过期，都可能让锚点失效。我们每月跑一次关联检查脚本，扫所有纪要的链接是否还能打开，失效的自动标红通知我。这事主动做，别等同事点链接发现 404 才补救。

三版模板的演化故事

模板不是一次设计到位的，我们前后换了三版。第一版叫全面版，什么都往里塞，待办、讨论、发言稿原文都在，一份纪要三四页，发出去根本没人看完。第二版反弹到极简版，只留待办和决议，结果出了事追溯不了上下文，老板问这个决定当时怎么定的，纪要里一个字没有。第三版才收敛成现在的一页纸加附件：一页纸管两分钟能读完的，附件管需要回看的。三版背后的逻辑其实是同一条：阅读成本和可追溯性不能只顾一头。

三版演化也给了个副产品：模板里留了一个叫变更备注的小字段，记录这版模板相对上版改了什么、为什么改。没指望谁看，但下次有人想把模板再加宽，翻一眼变更备注就知道当年为什么收窄——少走一轮弯路。

这三版折腾也说明，模板看着是格式问题，本质是阅读者和使用场景的问题。三版改下来有个体会：每版砍掉的内容，后来基本没人再要回来；每版加上的克制，反而都留住了。模板越改越短的进程中唯一的例外，就是附件链接那行小字——详略平衡，最后就剩它一个代表。

模板定稿后还做了点克制的工作：把区块数量从七个砍到五个，又把每个区块的字数上限压了一轮。每砍掉一块，我都问自己一句话——这块内容如果删掉，读纪要的人会来找我要吗？连续两周没人要的区块，就真的删掉。模板和代码一样，够用且能维护才是好模板。

模板之外还有些配套的小约定。纪要正文统一用固定字号渲染，不用同事在群里猜比例；待办和决议前面都带方括号编号（如 待办 1、决议 2），群里讨论时直接报编号，不用复述一长段。这些细节单看不起眼，合在一起就是读纪要的体验差异。

还有一个反直觉的决定：一页纸模板里不放假会标。最初考虑加一栏本周待办完成率，后来砍了——这东西对开新会没用，反而让这一页变沉重。纪要只记录当次会议，历史完成情况归档检索里查更好，各司其职。

这一节定下的目录结构、一页纸版式和关联设计，合起来就是纪要能不能长期用下去的地基。地基稳了，第五篇的通知分发和运行监控才有意义。

延伸阅读

• 笔记知识库实战：归档目录、标签体系与检索的完整做法
• NAS 家庭服务器：原始录音本地留存的备份方案
• 轻量建站实战：纪要页面怎么轻量部署给同事看