商务邮件写作助手

把要点或粗糙草稿整理成结构清晰、语气得体的商务邮件：场景识别、语气分级、结构模板与发送前红线自查

自由如风最新版本 0.1.0更新于 2026-11-03下载 0 次

SKILL.md

1	---
2	name: "business-email-craft"
3	description: "把要点、草稿或口语化诉求整理成一封得体的商务邮件：场景识别、语气分级、结构模板、收件人分析与发送前红线自查，纯指令技能，不联网不写文件"
4	---
5
6	# 商务邮件写作助手
7
8	把零散的要点、口语化诉求或粗糙草稿，整理成一封结构清晰、语气得体、可直接发送的商务邮件。
9	本技能是纯指令技能：只提供写作流程与检查清单，不带任何脚本，不联网，不读写任何文件。
10	适用于中文商务场景，也支持按同样流程产出英文邮件骨架。
11
12	## 触发时机
13
14	当用户出现以下任一情况时使用本技能：
15
16	- 要求"写封邮件""回个邮件""帮我润色这封邮件"；
17	- 给出几个要点或一段口语化描述，希望整理成正式邮件；
18	- 对邮件的语气拿不准（催促、拒绝、道歉、向上汇报、对外沟通）；
19	- 邮件写完了但心里没底，想发前再检查一遍。
20
21	不适用于：纯私人信件、营销群发文案、法律函件（这些场景规则不同，应明确告知用户本技能不覆盖）。
22
23	## 工作流程
24
25	### 第一步：明确四要素
26
27	动手写之前，先确认或向用户补齐这四项。缺任何一项都不要凭空猜测：
28
29	1. 目的：这封邮件要让收件人做什么？（批准、回复、执行、知悉、参加）
30	2. 收件人：对上是领导、对内是同事、对外是客户或合作方？与用户的关系与熟悉程度？
31	3. 场景：请求、汇报、催办、拒绝、道歉、通知、确认，还是多人协调？
32	4. 截止：有没有时间要求？希望对方什么时候回复？
33
34	用户没说就先问，一次把缺的信息问齐，不要挤牙膏式追问。
35
36	### 第二步：语气分级
37
38	按"关系紧密度 × 事情紧急度"选语气档位，写完后回看是否符合：
39
40	- 正式敬语：对上级、对不熟的外部方、跨公司首次联络。用"您""贵方""烦请"，避免口语词和表情符号。
41	- 标准商务：对熟悉的同事与长期合作方。清晰直接即可，客气但不过度铺垫。
42	- 轻松内部：对日常紧密协作的小团队。可以简短口语化，但仍保留称呼与明确诉求。
43	- 升级语气：催办第二次以上、涉及违约或风险。事实陈述代替情绪词，明确后果但不威胁。
44
45	原则：宁可比对方预期的语气稍正式半档，不要随意降档。同一封邮件里语气要一致，不要前恭后倨。
46
47	### 第三步：按结构模板成文
48
49	标准结构从上到下依次为：
50
51	1. 主题行：`[场景/项目] + 核心事项 + 需要的动作/期限`，15 字以内最佳，让收件人不点开也能判断优先级。
52	2. 称呼与开场：一行内说明来意，例如"关于 XX 项目排期，有事项需您确认"。
53	3. 背景（最多两句）：只给对方做决策所需的最小上下文，不铺垫历史。
54	4. 正文主体：要点用编号列表，一项一件事；数字和结论放前面，解释放后面。
55	5. 明确诉求：加粗或单独成段写清"需要谁、在什么时候、做什么"。
56	6. 结尾：感谢 + 署名，不写"祝好"以外的多余客套。
57
58	### 第四步：发送前逐项自查
59
60	输出成稿前，对照下面清单逐项检查，每项都要过：
61
62	- [ ] 主题行能否让收件人 3 秒内判断事项与优先级？
63	- [ ] 第一段是否已说明来意与诉求？收件人是否只看前两行就知道要做什么？
64	- [ ] 收件人、抄送人是否正确？是否误用了"全部回复"？
65	- [ ] 称呼、姓名、公司名、项目名有无写错（这是最高频的事故）？
66	- [ ] 数字、日期、金额、时间是否准确且无歧义（"下周三"改成具体日期）？
67	- [ ] 附件是否提到？附件名是否与正文描述一致？
68	- [ ] 有没有情绪化措辞、反问句、讽刺语气？（一律删掉，改为事实陈述）
69	- [ ] 有没有"随手""好像""可能吧"这类模糊词削弱可信度？
70	- [ ] 诉求是否明确到"谁 + 何时 + 做什么"？
71	- [ ] 全文是否可以再删 20% 而不损失信息？
72
73	## 输出模板
74
75	按以下格式输出，先给成稿，再给简要说明：
76
77	```
78	【主题】<主题行>
79	【收件人】<建议的收件人/抄送，用户自己填邮箱>
80
81	<称呼>：
82
83	<开场一句：来意 + 核心事项。>
84
85	<背景 1-2 句（可选）。>
86
87	<正文要点，编号列表，一项一件事。>
88
89	<明确诉求：需要您在 <具体日期> 前确认/提供/审批 <具体事项>。>
90
91	<结尾致谢。>
92
93	<署名>
94	```
95
96	成稿之后附三行说明：所采用的语气档位及理由、被你修改或删除的原稿风险点、仍需用户补充的信息。
97	如果用户给的是已有草稿，采用"修改说明 + 新稿"的顺序，逐条说明改动原因，不要只给结果。
98
99	## 特殊场景处理
100
101	- 拒绝类邮件：先肯定再拒绝，给出拒绝的实际原因，尽量提供替代方案；不写"很抱歉给您带来不便"这类空话堆叠。
102	- 催办邮件：首次催办假设对方遗漏，语气中性；二次以上才升级语气，并抄送相关上级。
103	- 道歉邮件：三段式——承认具体错误、说明补救措施、给出防止复发的机制；不过度自责，不转移责任。
104	- 坏消息汇报：结论先行，不埋伏笔；同时给出已采取的行动与下一步建议。
105
106	## 红线条款
107
108	以下情况必须拒绝或明确警示，不得照写：
109
110	- 涉及行贿、回扣、虚假报销、阴阳合同等违法内容的措辞，一律拒绝协助。
111	- 不得伪造数据、虚构审批结论、冒用他人名义署名。
112	- 用户要求在邮件中贬损、威胁、人身攻击第三方时，拒绝并建议改为事实陈述。
113	- 涉及裁员、欠薪、劳动纠纷等高风险敏感沟通，提示用户先咨询 HR 或法务，不要仅凭模板发出。
114	- 不得替用户虚构未发生的事实（如"我们已完成测试"），发现与已知事实矛盾的要指出。
115	- 密码、密钥、身份证号等敏感信息不得写入邮件正文，即使用户主动提供也要提示改用安全渠道传递。

文件内容是平台检查时读出的文本，只供查看。平台不会运行包里的任何脚本或程序。