把粗糙想法写成一封回复要求明确的工作邮件

起草工作邮件前，先确定收件人需要回答什么。把请求放在靠前的位置，补上作出选择所需的背景，再说明收到答复后你会做什么。如果粗略笔记只说了“尽快”，先问清楚是否真的约定过期限，再考虑写入日期。

这里要做的是写一封新邮件，还没有现成段落可供润色。真正有用的成品，是一封从主题到署名都完整的邮件：同事不必重新拼凑你的思路，也不用打开缺失的附件，就知道该怎样回答。

下文 FAQ 案例是原创虚构材料。Sam、Morgan、粗略记录、澄清、邮件和错误版本，都是为本教程编写的，并非真实通信、录音、采集到的模型输出或读者试验。所需内容全部以文字提供，无需访问邮箱。

先保留完整的粗略想法

以下是完整的 E0 记录：

E0——原创虚构的粗略记录；还没有现成邮件正文
我需要就 FAQ 给 Morgan 写封邮件。我们得往前推进了。先写 Setup 还是 Troubleshooting？我倾向于 Troubleshooting，因为我觉得它的提纲更粗略。两节都还需要完善。Morgan 回复后，我会起草其中一节。希望尽快得到回复。

E0 已经有主题、偏好和下一步，但“往前推进”和“尽快”并没有说清楚邮件该表达什么承诺。Morgan 可能需要选择先写哪一节，也可能被要求批准一份成稿，或同意某个交付日期。这些会是不同的邮件。

向写信人提出能确定本次起草方向的问题：

起草之前，先确认一下：你具体希望 Morgan 回复什么？“尽快”是否意味着已经约定了期限？你们是什么工作关系？有没有实际提供、可以附上的文件？

以下是为案例编写的 Sam 完整答复：

C1——为案例编写的 Sam 完整澄清
我是 Sam；Morgan 是我的内部同事，负责 FAQ 的内容优先级。请 Morgan 选择第一轮先起草 Setup 还是 Troubleshooting。我偏向 Troubleshooting，是因为我觉得它的提纲还不够完善；这不是用户研究结论。没有约定回复期限，所以不写催促的话。我会在收到答复后，把选中的一节准备好供审阅，不承诺完成日期。此前没有邮件正文，也没有提供或授权附上的文件。只起草。

现在请求已经具体了：Morgan 选择第一轮先起草的一节，之后 Sam 将那一节准备好供审阅。Morgan 负责内容优先级，Sam 的偏好只是自己对提纲的判断。回复期限和完成日期都没有约定，因此都不应写进邮件。

澄清也解决了附件问题：这里没有可附的文件。不要为了让邮件看起来完整就加上“见附件”。收件人需要的是足以作出选择的背景，而不是一个从未提供过的文件引用。

把明确后的意图写成整封邮件

本例需要作出以下写作选择：

以下是一封完整草稿：

主题：FAQ 先起草哪一节？

Morgan，你好：

你能选一下，我应该先起草 FAQ 的 Setup 还是 Troubleshooting 吗？

我更倾向于 Troubleshooting，因为我觉得这一节的提纲还比较粗略，不过两节都需要继续完善。你选定后，我会把那一节起草出来供审阅。

请回复 Setup 或 Troubleshooting 即可。

谢谢！
Sam

主题和开头先展示要作出的选择，再给解释。第二段给了 Morgan 一个可以考虑 Troubleshooting 的理由，却没有把 Sam 的看法当成客户研究结论或已经作出的决定。最后的请求让答复很简单：回复一个章节名称。

邮件无需重述每一条起草限制。Morgan 需要知道要选什么、相关背景，以及 Sam 下一步会做什么。没有约定期限，就不加催促，而不是在邮件里另写一段防御性的说明。

这封邮件没有请求批准一份已经完成的 FAQ。“准备好供审阅”说的是 Morgan 选定之后的下一步，不代表某一节已经写好、审阅或获批。

给起草助手提供实际输入

如果希望助手协助写作，可以复制下面这份填好的完整请求。它包含 E0 和 C1，因此引用不依赖更早的对话：

根据下面完整的粗略记录与澄清，起草一封新的内部工作邮件。没有现成邮件作为基准。先写需要对方作出的选择，只给足以回答的背景，保留 Sam 的建议作为个人偏好，并请 Morgan 回复一个选项。没有约定回复或完成日期。返回从主题、称呼、正文、明确回复要求到署名的整封邮件。如有必要补充的信息，在邮件之外说明；不要编造邮箱地址、附件、批准、收益、此前约定或发布安排。只起草供审阅，不要发送，也不要访问任何邮箱。

E0——原创虚构的粗略记录；还没有现成邮件正文
我需要就 FAQ 给 Morgan 写封邮件。我们得往前推进了。先写 Setup 还是 Troubleshooting？我倾向于 Troubleshooting，因为我觉得它的提纲更粗略。两节都还需要完善。Morgan 回复后，我会起草其中一节。希望尽快得到回复。

C1——为案例编写的 Sam 完整澄清
我是 Sam；Morgan 是我的内部同事，负责 FAQ 的内容优先级。请 Morgan 选择第一轮先起草 Setup 还是 Troubleshooting。我偏向 Troubleshooting，是因为我觉得它的提纲还不够完善；这不是用户研究结论。没有约定回复期限，所以不写催促的话。我会在收到答复后，把选中的一节准备好供审阅，不承诺完成日期。此前没有邮件正文，也没有提供或授权附上的文件。只起草。

同一份文字另存为完整起草请求，并提供独立的来源资料包。它们都是纯文本材料，不假定助手能读取收件箱、检查附件或发出结果。

也可以直接根据明确后的请求亲自写邮件。对于两项之间的简短选择，手工起草可能就够了。如果收件人不需要留存一封邮件，而且工作情境允许直接交谈或发一条短消息，也可以使用那个渠道；先把需要对方作出的决定说清楚。

否定一封编造了约定的完整邮件

下面是整封刻意编写的错误版本：

主题：FAQ 更新已获批，周五发布

Morgan，你好：

按之前的约定，更新后的 FAQ 两节都已获批，并随信附上。我们会在周五发布它们，使支持问题减少 30%。

无需回复。

谢谢！
Sam

它有主题、称呼和署名，但目的已经改变。它向 Morgan 通知一次已获批的发布，而不是询问 Sam 应先起草哪一节。完整的格式无法修复这种含义变化。

真正的错误涉及实质内容：邮件增加了 Sam 从未提供的决定、文件和结果。即使把这些句子写得更亲切，仍然是在传达错误的信息。

从明确后的意图出发，修复整封邮件

将下面的指令与前文完整 E0、C1 和错误邮件一起提供：

使用完整粗略记录和澄清，修复整封错误邮件。从这些意图重新开始，不要沿用错误邮件里编造的约定。返回一封从主题到署名都完整的新邮件。请 Morgan 选择 Setup 或 Troubleshooting。保留 Sam 的偏好，以及收到答复后只起草选中一节供审阅的计划。删去批准、附件、周五／发布、收益百分比和无需回复等措辞。没有约定期限。不要发送，也不要访问邮箱。这是编写的练习，不是真实模型失败。

完整的独立修复请求已包含三份输入。从 E0 和 C1 重新开始，可以避免把错误邮件中的“按之前的约定”当成另一个事实来源。

以下是整封修正后的邮件：

主题：FAQ 先起草哪一节？

Morgan，你好：

你能选一下，我应该先起草 FAQ 的 Setup 还是 Troubleshooting 吗？

我更倾向于 Troubleshooting，因为我觉得这一节的提纲还比较粗略，不过两节都需要继续完善。你选定后，我会把那一节起草出来供审阅。

请回复 Setup 或 Troubleshooting 即可。

谢谢！
Sam

修正稿恢复了需要对方作出的选择，没有保留错误邮件里的发布通知。两个选项、Sam 的偏好，以及答复后的审阅步骤都保留下来。没有约定的期限依然不写，未提供的附件直接去掉，不拿猜测的文件替代。

完整邮件文件与上面两次展示的作者编写版本一致。在这里重列全文，是为了让读者能检查修复后的整封邮件，而不只是看到一份修改建议。这封邮件并非把任一请求提交给模型后生成的结果。

选定版本前，从 Morgan 的角度读一遍

先把 E0 和 C1 放到一边，只阅读最终邮件：

这是对所给文字的检查，不代表 Morgan 或另一位读者实际试过。可以检查邮件是否包含这些答案；真实收件人能否理解、是否回复，则需要实际沟通来确认。

一则关于工作邮件表达不清的收件人讨论里，有人说起草辅助减少了自己追问的需要，也有人报告邮件变长、有用信息反而变少。另一则关于同事使用 AI 写邮件的讨论关注真实性，以及发件人是否理解邮件内容。这些是不同个体的说法，不是量化比较，也不能证明某种工具会改善这项任务。本例将这些顾虑应用到一封新邮件中，属于编辑设计。

如果选择说出粗略想法而不是打字，使用前应先检查得到的文本。在这个案例里，章节名称、否定表达，以及对“尽快”的改口，比转写读起来顺不顺更重要。口述只是可选的输入方式，不能据此认定工具理解了要作出的选择，或能保留你的个人口吻。

把真正想发送的版本留下来，供自己审阅。准备这份草稿，没有发送邮件、替 Morgan 选章节、创建附件或批准 FAQ 发布。最终文字应当让下一次回复的要求明确，同时把决定保留在 Sam 和 Morgan 原先确定的位置上。