meeting-notes

会议记录

一项涵盖完整 1-1 和会议记录生命周期的技能：会前准备 → 会议 → 口述或拍摄记录 → 可分享的学习文档 → 下次会前准备。各模式共用一套文件命名规则，因此每次会议的输出都会成为下一次会议的输入。

并非每场会议都通过开会进行。ToR 或实施计划的审阅周期会在文档边栏中敲定决策，而这些决策需要与会议通话一样，记录在同一份笔记、同样的行动项表格和同一条跟踪记录中。这就是边注模式。

模式选择

Ane 提供的信号	模式	阅读
“I want to dictate”（我想口述）、“debrief my meeting/1-1”（帮我复盘会议/1-1）、口语风格的主题总结	口述笔记	references/dictation-mode.md
“prep my 1-1”（帮我准备 1-1）、“prepare my meeting with [manager]”（帮我准备与[经理]的会议）、“what do I owe my manager”（我还欠经理什么）	1-1 会前准备	references/prep-mode.md
图片或扫描件路径 + “draft notes from this photo/scan”（根据这张照片/扫描件起草笔记）、手写笔记	手写笔记（照片/扫描件）	references/photo-mode.md
语音/视频录制文件，或文字稿（Teams .vtt/.docx、txt）	录音和文字稿	references/transcript-mode.md
审阅过的 .docx，决策记录在批注中：“the decisions are in the comments”（决策在批注里）、“marginalia”（边注）、“turn the review comments into notes”（把审阅批注整理成笔记）	文档边注	references/marginalia-mode.md
“learning document”（学习文档）、“shareable summary of this meeting”（可分享的会议摘要）+ 已完成的笔记	学习文档	references/learning-document-mode.md

只阅读所选模式对应的参考文件。若无法确定模式，用一句话询问；不要在会前准备和会议记录之间猜选。其他任何记录方式（聊天记录、作为会议纪要的邮件往来、白板照片）都先转换为文本，然后从第 2 步开始遵循 references/transcript-mode.md，这样无论会议以何种方式记录，都能归入同一种笔记结构。

通用规则（适用于所有模式）

存储。 定期的 1-1 笔记和会前准备文档存放在 C:/Users/AGasser/OneDrive/1. Ane's PROJECTS/Ane Plans/。项目会议笔记存放在 Ane 指定的项目文件夹中。命名规则：Meeting note - Ane-<counterpart> - YYYY-MM-DD.md 和 1-1 prep - Ane-<counterpart> - YYYY-MM-DD.md。.md 是事实来源；.docx 由它生成，绝不分别编辑。

事实可靠性。 口述和手写内容最容易把姓名、数字和日期识别错（这正是需要访谈核实的原因）。绝不要根据惯例猜测或“更正”姓名：向 Ane 确认，或对照上下文文档核实。已确认无误的信息来自 ~/.claude/CLAUDE.md、记忆或项目文件夹；任何无法核实的信息都标记为 ⚠️ 并询问。

里程碑写入。 在对话中起草和修正；只在确认的里程碑写入文件（所有主题均已确认、会前准备文档已获批准）。只写入一次，不要每条消息都写入。 笔记结构（经过验证的模板，2026-07-16 定稿）：

1. 标题区：日期、参与者、类型行，以及带稳定标签的主题列表（T1、T2……）。各笔记中的标签保持稳定，确保对于同一对接人，T1 始终代表同一工作流。将 **Participants:** 写成以逗号分隔的纯姓名列表，括号内不得出现逗号：update_tracker.py 会按逗号拆分此行，并选取第一个非 Ane 的条目作为对接人，因此像 Ane Gasser (IPPF EN, technical lead), <counterpart> ... 这样的角色说明会被解析成 technical，并写入每条行动、决策和待处理事项。将角色说明单独写在 **Roles:** 行。
2. ## Next actions at a glance：两张按截止日期排序的表格（截止日期 | 主题 | 行动），一张列出 Ane 的事项，一张列出对接人的事项（“待跟进”）。按截止日期排序，因为重开笔记时，大家想问的是“我今天要完成什么”。由第三方负责的行动应放入负责跟进该事项的人（Ane 或对接人）的表格中，并在“行动”单元格中注明实际负责人。
3. 每个主题使用 ## T<n> - <name>，并分别包含 ### Key takeaways（最多 5 条归纳要点）、### Decisions（仅列已确认的决策）、### Next steps（注明 Ane 或对接人及截止日期）、### Open / parked（每项注明应重新提起该事项的触发日期或事件）。如果某个主题没有搁置事项，完全省略 ### Open / parked。绝不要写“没有搁置事项”之类的占位文字。update_tracker.py 会将该标题下的每条要点都解析为真实的待处理事项，因此占位文字会在 Pending 标签页中生成一条无法执行的记录。经验证，2026-09-08：两条占位要点生成了两条 Pending 记录；由于更新器只会追加记录，要清除它们只能手动删除行并调整表格范围。
4. 页脚：注明准备过程及 AI 支持情况。

文风与语气。 一级工作记录：使用简洁英语、主动语态，每句少于 25 个单词，输出中不得使用长破折号，明确写出数字和日期。决策需编号，以便日后引用（“T3 决策 2，16 Jul”）。

Word 输出。 会议笔记使用信笺抬头模板，而非通用模板（Ane 于 2026-09-08 作出的决定）：徽标和地址区块仅出现在第 1 页，第 2 页起使用简洁页眉。当笔记结构适合模板布局时，使用 ane_package.reporting.word_export.write_word_report(template="letterhead") 从 .md 生成 .docx；对于表格较多的笔记，直接使用 python-docx 和 ane_package.reporting.brand.IPPF_FORMAT_TEMPLATE 常量构建（Barlow Medium 字体，dream #00313C 标题、#EB3300 红色标题、dream 表头行）。切勿硬编码不符合品牌规范的颜色或字体。

直接构建时，严格按照 write_word_report 自身的 letterhead 分支顺序操作：_open_branded_base()、sections[0].different_first_page_header_footer = True、_add_pillar_footer()、_restrict_header_to_first_page()、_ensure_brand_styles()。不要调用 _apply_a4_portrait（基础模板已包含页面设置），也不要调用 _add_logo_header（基础模板的默认页眉已带有徽标，再添加会盖上第二个徽标，并导致地址区块在每一页重复出现）。重新打开文件进行验证：存在 w:titlePg，首页页眉中有图片，默认页眉中没有图片。 三个注意事项，每个都由一次构建失败验证：

• IPPF_FORMAT_TEMPLATE 颜色常量带有前导 #，这在 OOXML 颜色属性（w:shd 填充色、w:color）中无效——Word 会静默丢弃底纹（2026-09-03）。写入任何原始 XML 颜色值前，先去掉 #；word_export._hex_to_rgb 已会为文字运行颜色处理此问题。
• 去除样式的信笺模板不含任何内置 Word 样式，因此 table.style = "Table Grid" 会引发 KeyError: "no style with name 'Table Grid'"（2026-09-08）。这与 word_export._add_bullet 中针对 List Bullet 记录的陷阱相同，而且会影响每一份包含大量表格的会议记录——这正是本规则规定的处理路径。不要指定样式，而应将 w:tblBorders 元素追加到 table._tbl.tblPr，以绘制网格线。
• 由于会议记录文件夹路径中含有撇号（1. Ane's PROJECTS），较长的 heredoc 在 Bash 中会失败（2026-09-08）。应使用存放在 OneDrive 之外的 Python 脚本执行写入；OneDrive 写入和提交规则本来也要求这样做。

编辑保留。 当目标文件已存在时，请遵循 mel_wiki/wiki/concepts/edit-preservation-protocol.md。具体而言：一旦 Ane 手动编辑生成的 .docx，该 .docx 就成为权威版本；后续更改必须通过 python-docx 有针对性地编辑，绝不能从 .md 重新生成。

隐私。 会议记录是个人工作记录，其中可能出现姓名。任何可分享的内容（学习文档，或 Ane 表示要发送的会议记录）都应遵循摘要匿名化原则：使用角色和组织类型，不使用姓名，并删去内部分析部分。绝不要引用 5 JURNAL 知识库中的内容。

集中式行动追踪表。 每份确认后的会议记录还必须更新一份 Excel 工作簿（Ane Plans/Meeting actions tracker.xlsx）：每人一个工作表，用于记录带有截止日期和状态的行动事项；另设 Decisions log 工作表，以及用于搁置事项的 Pending 工作表。任何会生成会议记录的模式都必须在最后一步运行 scripts/update_tracker.py；该脚本只追加内容（ID 稳定，且操作幂等），因此不会触碰 Ane 手动编辑的 Status 和 Progress 字段。详情请参阅：references/action-tracker.md。准备模式会读取此追踪表来检查状态；追踪表中的 Status 列优先于较早的会议记录文本。

记忆收尾。 会议记录确认后，应询问是否将持久有效的项目事实（已确认的决策、预算变更、新截止日期）保存到自动记忆中，并更新现有项目记忆而非重复添加。会议记录留存会议内容；记忆则记录未来会话必须了解的信息。