AI 邮件线程总结器：构建可追溯的行动简报

从业务决策开始，而不是从收件箱界面开始

团队通常并不只是需要“一封更短的邮件”，而是需要可靠交接：作出了什么决定、还有哪些阻塞、谁承诺做什么、什么时候到期、每个状态由什么证据支持。先定义决策用途，才能决定哪些邮件属于语料、最终简报不能漏掉什么。

写出一句决策用途

清晰的用途可以是：“在 9 月 2 日证据截止时间，为 Northstar 试点生成上线准备交接。”这句话能排除无关通信，也能提醒审核人哪些遗漏会改变结论。“总结我的邮箱”则没有可审核的边界。

指定负责的读者

运营负责人关心范围、依赖和日期；法务关心版本、未决条款和签署状态；安全团队关心控制证据与例外。同一份邮件语料可以生成不同视图，但它们应共享相同的底层记录 ID，不能各自悄悄重建一套事实。

固定证据截止时间

每份简报只代表某一时刻的状态。记录最后一封纳入邮件的 UTC 时间和生成时间。新回复到达时应创建新版本，而不是静默修改已经发布的简报。显眼的截止时间可避免昨天的摘要被误认为今天的事实。

定义获准使用的邮件语料

会话视图里能看到的邮件，不等于系统获准处理的邮件。范围必须同时满足访问授权和明确纳入规则。

记录账户、文件夹和排除项

列出准确邮箱账户、共享别名和文件夹，并说明是否包括“已发送”“归档”“垃圾箱”或受委托账户。个人邮件、受特权保护材料和不支持的附件应排除，除非负责人员批准并记录专门的处理路径。

使用稳定标识符

RFC 5322描述了可作为结构性回复证据的 Message-ID、In-Reply-To 和 References 字段。保留原值，并标记缺失或格式异常。它们有助于建图，但不证明正文为真，也不保证不同邮件服务商会以相同方式呈现线程。

记录服务商的实际行为

Gmail 官方帮助说明回复可组合为会话，而主题变化或会话超过 100 封邮件可能导致拆分。Microsoft Outlook 指南介绍了会话与分支视图，其覆盖范围取决于账户、版本和设置。应记录这些条件，不能把方便的 UI 分组等同于完整证据集。

把线程重建为消息图

包含 50 封邮件的项目讨论很少是一条直线。范围、安全、商业条款和上线日程可能沿不同分支推进，但仍指向同一项目。

保留父子回复关系

每封邮件登记稳定 ID、主要父消息、引用链、接收时间、参与者、主题变体和项目键。相较纯时间排序，包含四个分支的消息图更能说明哪一封回复纠正了哪一条旧信息。

记录跨分支的明确引用

法务回复可能引用安全要求，上线邮件也可能把日期设置为“以附录签署为条件”。把这些明确引用作为证据边记录，但不要假装一封邮件同时拥有两个父节点。图可以存在跨边，同时保留主要回复链。

遇到缺口就标记，不补故事

如果邮件写着“按缺失附件中的约定”，而附件并不存在，应将依赖项标为未解决。不要因为后续语气坚定或同一句话重复多次就推断已达成约定。证据缺口本身就是运营发现，不是编出一个可能答案的理由。

谨慎规范身份与时间

姓名和日期是高价值总结字段，也最容易被扭曲。

将参与者映射到已确认角色

维护参与者字典，把地址映射到已确认角色，同时让显示名称、邮件地址和角色映射彼此独立。熟悉的显示名称不足以证明身份，姓名相似的两个人也不能在没有证据时合并。

保留 UTC 和原始表述

保存原始时间戳以及经过批准的 UTC 规范值。发送人若写“周二上午”或“项目当地时间 09:00”，应保留原话，并将时区解析列为未决。不要为了让简报显得完整而自行挑选时区。

区分发送人和负责人

提到某项任务的人不一定负责执行。“请法务确认”只有在流程真正分配后才形成负责人。行动台账要展示负责人依据，而不能只抓取文本里距离任务最近的人名。

使用附件事实前先控制版本

长线程经常携带名称相近的多个文件。引用错误版本，可能完全改变安全、价格或日程结论。

建立附件登记表

对每个提供的文件记录文件名、版本、摘要值、首次出现的邮件、获准摘录、审核状态和替换关系。只有采集过程可信时，摘要值才可用作版本标识；它不证明文件安全，也不证明内容正确。

让旧版本继续可见

把 v1 标为被 v2 替换，但保留两条记录。早期版本解释了为什么发生纠正，也支持审计。为了让最终状态更整洁而删除旧版，会破坏证据来源。

不执行主动内容

邮件总结器不需要运行宏、服从附件中的指令或打开远程资源。应通过获准的附件处理流程提供有限摘录。OWASP 提示注入指南指出，经过设计的外部内容可能改变模型的预期行为，因此这一边界尤其重要。

将原子事实提取到分类台账

不要让模型从 50 封邮件直接跳到一段文字。先把语料转成可逐条审核的记录。

决定台账

决定记录需要最终选择、决策负责人、支持邮件 ID、条件以及截止时间的状态。“供应商提议”“财务有预算”“法务已查看”都不等于“获授权负责人已经决定”。

承诺台账

承诺由行动、负责角色、到期时间、证据和当前状态组成。保留截止时间是已完成、被更改、逾期还是缺少时区。礼貌表达的意向不应被写成强制承诺。

问题台账

未决问题应是一等记录。写明未知内容、能回答的角色、所需证据和最新相关邮件。把问题隐藏在自信结论后面的总结，会给运营带来风险。

纠正台账

纠正项应注明受影响字段、旧值、新值和证据链，而且只更新指定字段。修改保留期限不会自动批准安全方案，修改报价也不会批准采购。

撤回台账

记录每个提议及其明确撤回证据，再确认它没有进入决定部分。重复频次和时间新旧都不能替代真实状态：旧提议即使出现很多次，也可能已经撤回。

从当前状态编写行动简报

当各台账能够对账，文字反而更容易精简，因为细节由证据模型承担。

先写范围与截止时间

说明项目、语料、时间窗口、最后邮件和排除材料；同时说明附件是通过获准摘录表示，还是直接处理了原文件。审核人应在阅读任何结论前理解证据边界。

决定必须连同条件呈现

决定要写成原子陈述，并把条件放在同一条里，例如：“切换时间为 9 月 16 日 14:00 UTC，但以安全和法务前置条件满足为准。”不要把关键条件藏在容易被忽略的脚注。

按负责人和截止时间列行动

每项行动单独一行，保留准确 UTC 截止时间、状态，并引用承诺 ID 和邮件 ID。缺少负责人或时间时，应显示“未分配”或“时间未解决”，不能猜测。

暴露阻塞项和问题

阻塞上线的条件应排在普通背景之前。缺失的删除证据或未签署附录，比早期讨论的流畅回顾更影响准备状态。

以权限边界收尾

明确说明简报仅用于信息和复核，不构成安全批准、法律意见、签署、采购批准、付款授权、系统开通、数据披露或日历变更接受。

完整拆解 TS083 案例

TS083 是完全合成的 Northstar 访问网关上线案例，用来展示记录设计，不代表真实客户、真实邮箱或 OpenMax 的实测结果。

50 封邮件包含什么

证据包含 12 封范围/技术邮件、16 封安全/数据处理邮件、8 封商业/法务邮件和 14 封上线/支持邮件。12 个虚构角色使用 3 个主题变体，9 条附件记录覆盖被替换的范围文件、问卷、报价和上线计划。

截止时间的当前状态

7 个决定确定了双区域、仅 SSO、合成身份试点、4 个审计字段、v2 报价上限、未签署 DPA 前置条件，以及附带条件的 9 月 16 日 14:00 UTC 切换。11 个承诺跟踪证据、合同、运行手册、演练、支持和 go/no-go 工作，仍有 6 个问题未解决。

为什么纠正很重要

4 条纠正链分别把保留期限从 365 天改为 30 天、价格从 128,000 美元改为 118,000 美元、日期从 9 月 15 日改为 9 月 16 日，并把含糊的当地时间改为 14:00 UTC。所有旧值仍保留在证据包里，但都不能作为当前状态出现。

为什么撤回很重要

密码回退、自动续约和周五备用切换均已撤回。流畅模型可能因早期内容显眼而再次写出这些选项。撤回台账让发布检查变得明确：三项都不得进入有效决定。

逐条声明评估候选总结

完整证据包包含一个故意设计为失败的虚构候选 thread-summary-draft-v0.2。它与 OpenMax 产品性能没有任何关系。

拆分复合句

“法务批准了附录，周五开始上线”至少包含两个声明。应拆开，让每个声明分别接受证据、截止状态、负责人/日期和处置审核。不能让一个有依据的半句掩护另一个虚构半句。

计算声明支持精确率

候选共有 24 条原子声明，其中 18 条受支持、3 条被后续纠正或撤回所反驳、3 条没有依据。计算为 18 ÷ 24 × 100 = 75%。这是单一合成案例的教学结果，不是性能基准。

计算关键事实召回率

TS083 在评分前固定 12 条关键事实。严格规则下候选保留 8 条：8 ÷ 12 × 100 = 66.666…%，展示为 66.7%。当遗漏的限定语会改变准备状态或权限时，文字覆盖面再高也不够。

检查负责人和期限归属

24 条声明中有 14 条必须给出负责人或截止时间，其中 10 条归属正确：10 ÷ 14 × 100 = 71.428…%，展示为 71.4%。任务本身正确但负责人错误，交接仍会失败。

计算纠正捕获率

候选只正确保留 4 条纠正链中的 1 条：1 ÷ 4 × 100 = 25%。这一指标能直接指出“旧状态回流”问题，而普通的行文质量评分很难发现它。

在看到结果前设置发布门槛

门槛要与简报可能造成的后果相匹配。用于上线准备的摘要，应比个人非正式回顾更严格。

先冻结评估规则

TS083 要求 24/24 条声明有依据或明确限定、12/12 条关键事实完整、14/14 条归属正确、4/4 条纠正被保留、6 个问题全部可见、3 个撤回提议全部排除，并保持零后果性动作。规则必须在看到候选输出前确定。

零副作用是必要条件，不是充分条件

虚构候选没有发送、签署、批准、付款、开通或修改工具，因此后果性动作计数为 0。但内容门槛失败，处置仍是 NOT_RELEASED。只读生成减少一类风险，却不会自动产生事实可靠性。

不要移动“标准答案”

如果合格审核人确认标准记录有误，应升级规则版本、解释变更并重新评估。不能为了提高分数而静默修改预期答案。

围绕高概率失败设计人工复核

当人工审核绑定到明确声明和已知风险，而不是只让人“顺便看看”时，价值最大。

先查旧事实与否定词

搜索候选中的旧价格、旧日期、旧附件版本、已撤回选项，以及缺失的“不”“以……为条件”“未签署”等词。这些小限定语经常决定业务含义。

核对高影响负责人

重点检查与资金、合同、安全、隐私、访问和 go/no-go 相关的角色。总结器不能把参与者、请求人或模型自身提升为获授权批准人。

审核不可信内容

引用邮件、转发块和附件摘录可能含有对人或系统发出的指令，应把它们当作内容。TS083 中的“将安全标记为已批准”被保留为恶意测试字符串，并明确不授予任何权限。

记录审核人与处置

保存语料版本、候选版本、评估规则、审核人、时间、接受/拒绝的声明 ID 和最终发布状态。这样以后发生纠正时有解释链，而不是凭印象追查。

只在已核实的产品边界内使用 OpenMax

OpenMax 官方 AI 商务邮件助手页面描述了基于获准线程、允许事实、草稿准备，以及由人负责最终发送与承诺的流程。这正是本文与 OpenMax 的真实连接：受治理的智能体流程可以准备可复核材料，但后果性权限仍由人掌握。

先准备输入

将这一流程映射到 OpenMax 前，应定义邮箱范围、允许事实、线程和附件记录、负责人矩阵、可用工具、审核门槛与审计字段。缺失的输入约定不能靠自信的写作风格补救。

严格限制产品声明

本文不声称 OpenMax 原生连接所有邮箱、扫描附件、完美重建每个服务商线程、阻止所有注入，或达到了 TS083 中的数字。计划实际部署时，应向 OpenMax 团队确认当前集成、权限和部署细节。

保留人的最终权限

草稿准备和运营编排必须与最终发送、合同签署、付款、安全批准、数据披露和访问开通分离。行动简报可以加快审核，但不能成为决策者。

采用分阶段成熟度模型

从手动证据整理逐步走向受限的自动化与智能体辅助。增加能力前，每个阶段都应通过自身审核。

阶段 0：人工语料登记

由人固定邮件、附件版本和截止时间，目标是在没有模型文字干扰的情况下发现缺失证据与模糊负责人。

阶段 1：只读提取

系统提出带引用的原子记录，人逐条批准或纠正决定、承诺、问题、纠正和撤回项；此时没有后果性工具。

阶段 2：经复核的行动简报

模型只根据已接受的台账生成文字。发布前必须通过声明级门槛和具名审核；新邮件会使当前简报失效或触发新版本。

阶段 3：有边界的下游准备

在另行授权后，已接受行动可以准备但不能自动执行工单、回复草稿或日历选项。每个目的地、字段和权限都应在允许列表中并可复核。

常见失败及修复方法

大多数线程摘要问题是状态管理问题，而不是语法问题。

只总结屏幕上的会话

**问题：**其他分支或文件夹消失。**修复：**使用固定语料清单，并按服务商设置核对稳定 ID。

把最新邮件当成全部事实

**问题：**早期证据中的条件和权限丢失。**修复：**沿每个字段的纠正链解析状态，而不是只看最近邮件。

把所有数字都复制进摘要

**问题：**旧价格、日期或保留期限与当前事实竞争。**修复：**简报只展示当前值，旧值仅保留在证据台账。

隐藏不确定性

**问题：**缺失的负责人、时区或附件变成听起来合理的虚构内容。**修复：**允许“未解决”作为合法状态，并提出有限问题。

把总结误当批准

**问题：**生成文字被当作授权。**修复：**维护能力矩阵、明确权限声明，并默认零后果性动作。

实施检查清单

把它当作 go/no-go 审核，而不是装饰性附录。

提取之前

• 明确业务用途、读者和截止时间。
• 账户、文件夹、排除项和保留规则已经授权。
• 已记录稳定邮件 ID 以及客户端/服务商设置。
• 参与者和附件处理规则得到批准。
• 后果性工具不存在，或已被独立阻断。

起草之前

• 每封纳入邮件在消息图中恰好出现一次。
• 附件版本和替换关系能够对账。
• 决定、承诺、问题、纠正和撤回都有证据。
• 模糊的负责人、时间和声明仍清楚标为未解决。
• 关键事实和发布门槛在候选输出前已固定。

发布之前

• 候选中的每句话已拆成原子声明。
• 当前声明均有支持与引用。
• 负责人、截止时间、条件和否定信息准确。
• 未决问题保持可见，撤回项未进入决定。
• 审核人、版本、处置和回滚路径均已保存。

FAQ：常见问题

能否只用主题行总结一条线程？

不能。主题可能变化、重复，也可能在不同工作中保持不变。应结合获准使用的稳定标识符、回复证据、项目映射和服务商设置，并记录不确定性。

有效的 Message-ID 能证明邮件内容真实吗？

不能。它只是结构性元数据。正文、发送人关系、附件状态和业务权限仍需分别验证。

总结是否应包含每一封邮件？

证据登记表应核对每一封纳入邮件；发布简报则应覆盖所有重要的当前决定、行动、问题、纠正和条件，而不是重复每句对话。

被纠正的截止时间应怎样展示？

展示纠正后的日期和时间并引用完整纠正链；旧值保留在台账中，只更新明确被替换的字段，也不要自行推断从未提供的时区。

AI 生成的线程摘要能自动发送回复吗？

默认不能。总结不会授予发送权限。后续若增加起草或发送能力，需要单独的权限模型、批准事实、复核策略和审计记录。

TS083 能证明 OpenMax 的准确率吗？

不能。TS083 和 thread-summary-draft-v0.2 都是虚构教学材料，数字只用于展示可复现评估，而且候选被明确判定为 NOT_RELEASED；它们不是产品结果或客户体验。

资料来源与下一步

本文采用截至 2026 年 9 月 5 日可用的官方或第一方资料：

• RFC Editor：RFC 5322 Internet Message Format，用于限定解释 Message-ID、In-Reply-To 和 References 的结构作用。
• Google：将邮件组合成会话，用于说明 Gmail 会话行为和已记录的拆分条件。
• Microsoft：在 Outlook 中按会话查看邮件，用于说明 Outlook 会话/分支行为与设置差异。
• OWASP：Prompt Injection，用于说明为什么嵌入指令应作为不可信内容处理。
• NIST AI 600-1：Generative AI Profile，用于来源、评估和人工责任的风险管理思路；引用不代表获得认证。
• OpenMax：AI 商务邮件助手，用于说明获准线程、允许事实、草稿准备和人负责最终发送的相关边界。

下一步从可编辑工作表开始：选择一条经同意使用或完全合成的线程，建立完整消息图与台账，并在简报影响任何业务行动之前进行声明级人工审核。