email-drafter

邮件起草

起草与您既有写作风格和语气相匹配的专业邮件。使用 WorkIQ 分析您已发送的邮件以及与收件人的既往往来，然后生成可让您审阅和润色的上下文感知草稿。

何时使用

• “给 [person] 起草一封关于 [topic] 的邮件”
• “给 [customer] 写一封关于 [project] 的跟进邮件”
• “回复 [person] 关于 [subject] 的邮件”
• “为 [initiative] 撰写一封提案邮件”
• “分析我与 [recipient] 的邮件语气”

工作流

第 1 步 — 收集上下文

起草前，收集：

1. 收件人 — 邮件是写给谁的？
2. 目的 — 邮件是关于什么的？（提案、跟进、技术指导、介绍、状态更新等）
3. 要点 — 需要传达什么？
4. 关系背景 — 如可用，使用 WorkIQ 检查与该收件人的既往邮件历史

如果用户预先提供了所有这些信息，直接继续。否则，提出澄清问题（最多 3 个）。

第 2 步 — 分析语气

为某位收件人起草时，使用 WorkIQ 了解用户既有的沟通模式：

1. 从用户发给同一收件人或类似收件人的邮件中提取 3–5 封近期已发送邮件
2. 识别模式：
   • 称呼风格 — 正式（“Dear”）、标准（“Hello”）、随意（“Hi”）或直接（无称呼）
   • 结构 — 短段落 vs. 项目符号列表 vs. 编号步骤
   • 落款 — 用户通常使用的结尾和姓名格式
   • 正式程度 — 专业、友好专业、随意
   • 语言 — 用户与该收件人交流时使用的语言
3. 将这些模式应用到草稿中

如果 WorkIQ 不可用或没有既往邮件，使用合理的专业默认设置，并注明语气是推断的。

第 3 步 — 起草邮件

应用发现（或默认）的风格规则：

称呼：

• 匹配第 2 步中发现的任何称呼风格
• 默认：对外使用“Hello [FirstName],”，对内使用“Hi [FirstName],”
• 多位收件人：“Hello [Name1], [Name2],”

语气：

• 直接简洁 — 不要赘语
• 友好但专业
• 快速切入重点
• 在适当的地方主动提供帮助（“Happy to discuss further”、“Let me know if you need anything”）

结构：

• 短邮件（1–2 个要点）：简单段落，无需项目符号
• 较长邮件（提案、多点更新）：使用项目符号或编号列表
• 相关时纳入既往对话的上下文（“Following our recent conversation about...”）

落款：

• 匹配第 2 步中用户既有的落款模式
• 默认：“Best regards,”，下一行为用户的名字

语言：

• 除非用户另有指定，默认使用英语
• 如果既往往来使用另一种语言，匹配收件人的语言

第 4 步 — 输出

1. 呈现草稿供审阅，并简要说明所应用的语气/风格
2. 按用户要求应用修改 — 迭代直至满意
3. 将最终草稿保存到 outputs/<year>/<month>/，使用描述性文件名（例如 2026-03-26-email-acme-followup.md）

重要规则

• 绝不发送邮件 — 仅将其起草为文件，供用户审阅并手动发送
• 如可用，始终检查 WorkIQ 以获取与收件人的既往上下文
• 如果用户说“draft email”或“write email”，自动激活此技能
• 使用 outputs/<year>/<month>/ 文件夹约定保存草稿
• 尊重隐私：不要包含来自无关邮件线程的敏感信息

示例提示词

• “给 Sarah 起草一封关于项目时间线的邮件”
• “给客户写一封关于其迁移问题的跟进邮件”
• “为新的培训计划撰写一封提案邮件”
• “回复 John 的邮件 — 同意他的方法，但建议我们增加监控”
• “分析我与 Acme 团队的邮件语气”

要求

• 推荐使用 WorkIQ MCP 工具进行语气分析和收件人上下文分析（Microsoft 365 / Outlook）
• 如果没有 WorkIQ，该技能仍可正常工作，但会使用专业化默认值，而非个性化语气匹配
• 输出内容以 markdown 文件形式保存在工作区中