“GenMail 总结得挺好但抓错重点”通常不是提示词和工具能力二选一的问题，而是三层里有一层先漏了：第一层是读取范围（GenMail 这次到底读没读到那封要紧邮件），第二层是指令写法（“重要”这类词在它那里能不能落成可执行条件），第三层是理解边界（反讽、省略主语的短回复本来就难判）。排查顺序建议从下往上倒着来——先查读取范围，因为没读到的邮件再怎么改提示词也不会出现；范围确认没问题，再改指令；指令改到具体可观察之后仍然错，才轮到怀疑理解边界。下面每一节都给一个可以当天做完的动作，不需要动代码。
适用场景：用 GenMail 类工具批量读收件箱、输出读起来通顺却漏掉要紧邮件时。操作顺序是先溯源再改词：把每条输出拉回原邮件，确认是“读了没提炼”还是“根本没读到”；再把“重要邮件”改写成发件人、标题、时间等可观察条件；最后收缩到单个文件夹或几个发件人复测。验证方式是同一批邮件在改配置前后各跑一次，比对关键邮件是否被覆盖。风险边界：涉及反讽、省略主语的短回复，工具侧判断通常不可靠，需要人工复核。
先确认它这次到底读了哪几封邮件
“抓错重点”里有一半其实是“没读到”，而没读到会被通顺的文字掩盖。溯源方法是把输出里每一条判断拉回原邮件找来源，逐条标注三种状态：
- 有原文支撑：能在某封邮件里找到对应句子或字段，说明确实读到了。
- 读了但漏掉：这封邮件在读取范围内、也被其他条目间接引用过，但真正要紧的信息没被提炼出来。
- 根本没读到：摘要里完全找不到这封邮件任何痕迹，先去核对读取范围，不要急着改提示词。
具体做法：先把范围内的邮件按文件夹、时间、发件人导出成一份清单（多数邮件客户端支持导出或按视图筛选），再把 GenMail 的输出条目逐条贴到清单旁边打勾。落单的那几封，就是问题邮件。如果落单邮件集中在某个文件夹或某段时间，基本可以定位到范围问题；如果落单邮件和已覆盖邮件混在同一范围里，才需要往指令和理解层面查。这一步建议手工做一遍，成本不高，但能省掉后面反复调提示词的盲目试错。
把“重点”翻译成它能执行的判断条件
“重要邮件”“值得关注的”“需要我处理的”这类词，对模型来说没有可落地的判定边界，它只能按训练里常见的邮件形态去猜，结果就是总结读起来很顺、优先级排错。改写的方向是把抽象词换成发件人、标题、字段、时间这些能被观察到的条件，并明确输出格式和原文位置，方便回头核对。
改写前：
帮我总结今天的邮件，重点是重要的邮件。改写后（可替换的通用骨架，域名、关键词按自己的环境改成真实值）：
读取范围：收件箱，最近 1 天。
输出格式：每条一行，字段为——发件人 / 主题 / 需要我做什么 / 原文位置（邮件主题+时间）。
重点判定条件（满足任意一条即列入重点）：
1. 发件人域名属于客户域名列表（example-a.com、example-b.com）
2. 主题包含：报价、合同、付款、逾期、确认
3. 正文出现明确日期或截止时间
非重点邮件只列主题，不展开正文。
如果某封邮件无法归类，单独列在末尾，标注“待人工判断”。只描述可观察到的差异：改写后通常能看到条目里带上具体发件人和主题关键词，重点和非重点被分开列出，而不再是笼统的几段话。如果改写后输出依旧把重点和非重点混在一起，再去看第三节的范围问题。
收缩读取范围：时间、文件夹、发件人
范围越大，模型在有限上下文里分配注意力的空间越紧张，越容易只总结“最大路货”的那几封。验证范围影响的方式是收缩后复测，而不是凭感觉判断。
- 选一个具体范围，例如“客户”文件夹，或某几个发件人域名，或固定为最近 24 小时。
- 用第二节改写后的同一套指令，只改第一行的读取范围，其他不动。
- 跑两次，把范围收缩前后的输出并排放在一起，逐条标注上面那三种状态（有支撑 / 读了漏掉 / 没读到）。
- 记录结果变化：以“关键邮件是否出现在条目里”为准绳，而不是以文字是否通顺为准绳。
很多情况下收缩到某个文件夹或几个发件人之后，要紧邮件就会稳定出现，说明之前是范围过宽导致的注意力稀释。如果收缩后关键邮件仍然被忽略，说明问题在指令或理解边界，需要回到第二节继续收紧判定条件。需要结合环境确认的一点是：缩小范围会让摘要覆盖面变窄，日常使用时可以按文件夹分批跑，而不是把所有邮件塞进一次总结。
它做不到的部分：反讽、省略主语的短回复
有一类判断不属于“提示没给对”，而是模型侧本来就难做准的，需要人来补。可复现的例子：
- 单行回复“行吧，你看着办”——是同意、是无所谓、还是不满，取决于前文语气和两人的关系，字面无法区分。
- “这方案真是太棒了”——在没有上下文时，反讽和真心夸奖的文本形态几乎一致。
- “辛苦了”——在催促交付的语境里可能是委婉施压，在收尾语境里只是客套。
这类邮件通常不会出现在重点列表里，或者被归到“普通闲聊”一类。这不该被夸大成工具的能力缺陷，它是语言本身依赖语境的表现。合理的做法是把这类邮件单独列出来，人工看一眼原文再定优先级；也可以在指令里加一条“凡是单行、无主语、含反讽可能的回复，单独列出并附原文全文”，让模型少做判断、多做搬运。
把摘要当索引而不是结论
把 GenMail 的输出定位成索引，分工就清晰了：它负责列条目和保留原文锚点，人负责定优先级和处理顺序。让输出里每条都带可回溯位置（主题、时间、发件人），人拿到索引后按自己的业务节奏排序，并在每条旁边写一句“为什么先处理这封”，把判断依据留下来。这样做的好处是，下一轮总结如果排错了，可以对照上一轮留下的依据，判断是范围变了、指令变了，还是这封邮件本身就需要人工判断。工具跑得再顺，最终决定先回谁的邮件、先推哪笔付款，仍然由人来做。