[collect]如何写好一封电子邮件[bak]

这个一个在知乎上看到的问题，整理了前几名作者的回答成以下内容，算是总结学习。

@奶牛Denny

关于如何写邮件，这是一篇浏览量过十万的短文，最早是发布在笔者自己的博客Denny’s Blog上。放在这里，希望能给更多人带去帮助。

你一定曾经发过很多后来对方就鸟无音讯的邮件吧？你是不是也曾经觉得XXX看上去乐善好施的，怎么发邮件给Ta，Ta就不回复了呢？95%的情况下，答案不是对方耍大牌，人们每天都在处理上百分邮件，多一封不多。真正的原因是，你发的方式错了。所以这篇博客，就讲讲如何发Cold Email。三个核心原则，由浅入深。

原则一、越短的邮件越容易得到回复

这个最简单易懂，因为每个人应该都有体会，但自己发邮件的时候往往就忘了。我自己的真实情况是，两三句话的陌生邮件会立即回复，五句话以上的陌生邮件就会放一放。放一放的意思是，大部分放着放着就再也不会去回了。邮件字数越长，给对方造成的精神压力越大，现代人平时压力已经很大了，实在是心有余而力不足，只能直接把你这份压力抛之脑后了。这一点，你可以思考一下你自己的情况是什么，就马上能开悟了。所以，五句话以内的邮件是王道。

原则二、别说你自己的事儿，说这事儿跟Ta有什么关系

这个世界上对方最在乎的人是谁？对了，Ta自己。太多人写Cold Email的时候，花了80%的篇幅在写自己的事——“我是谁啊、我在干什么啊、我的历程啊、做的事儿的每个细节啊”。。。您等等，您写这封邮件给对方做什么来着，对方正在高效率地处理大量和自己密切相关的邮件，您这是给他插一个故事会么。

所以，你的邮件第一句话应该直入主题地告诉对方，这封邮件的目的是什么。然后，如果你希望增加对方回复的欲望，那么你接下来说的每一句话都应该尽量和对方的利益和兴趣牵扯上关系。你可以花500个字来形容你自己有多牛B，但从吸引力上来讲，这比不上你花50个字来阐述清楚你这事儿和对方有什么关系。

原则三、让Ta可以很容易地回复和帮助到你

这一条只有1%的人在做。

举个例子吧。你在听完一场创业讲座后，和人脉颇广的演讲嘉宾在台下交流了10分钟。他觉得你的项目不错，答应可以将你的团队信息介绍给天使投资人A、投资机构B、和供应商合作方C，让你回去发详细资料到他的邮箱。然后你开开心心地回去发了你的项目简介到他的邮箱，内容大意是说：

“很高兴今天和你Blahblahblah。我们的项目是Blahblahblah，怎么怎么Blahblahblah，已经获得了Blahblahblah。附件中是详细的项目资料。谢谢您的帮助！今后咱们Blahblahblah。”

后来，就没有后来了。然后你就开始想，”XXX看上去乐善好施的，其实也不过如此”。如果你这样想的话，请你站在这位可怜的演讲嘉宾的角度想一想——

他在当天清理邮件的过程中，看到你的这封邮件以后，需要（1）先思考他当时究竟答应你要介绍给哪些个人，关联点究竟是什么（2）找到这三个联系人的邮箱（3）分别写三封独立的邮件给这三个人来介绍你的这个项目和他们的关系。这至少是半个小时的时间投入，你真以为人家是你干爹啊。光在发邮件的时候说“我知道您是个大忙人”，其实只是停留在了一种被动恳求的口吻上，跟伸手要钱其实是同一种精神。

很多人其实都是愿意帮助他人的，但前提是你必须要努力地让对方可以更容易地帮助到你。所以你可以怎么做呢？你回去以后，应该发四封邮件：

第一封：“很高兴今天和你Blahblahblah。我们的项目是X，您提到了可以我们的项目可能会让天使投资人A、投资机构B、和供应商合作方C感兴趣。接下来我会发三封您独立的邮件给您，分别是写给A、B、C的。这三封邮件都是可以被直接转发的格式。谢谢您的帮助！”

第二、第三、第四封在内容和措辞上分别是写给A、B、C，简洁阐述你的项目和他们的关系，并且保证格式完整，让你的联系人可以直接转发。

好了，就点到这里。大而全的长邮件大家都会写，也很容易写，所以也不追求什么回复率——很多人只是图个不吐不快（我个人觉得真写这样就别发了，自己宣泄一下就好）。写短邮件则需要更多努力。而写能够设身处地为对方思考的短邮件，则更是需要时刻努力保持这种意识。

不过这三个原则如果能发扬光大，一定能为整个人类社会节省大量浪费的时间和电力。

链接：如何发邮件请求帮助，并获得超高回复率 | Denny’s Blog

@吴思扬

以下内容不是规范，只是写邮件时的总结，请务必根据自己公司、团队的实际情况带入思考
内容过长，手工码字不易，为避免没耐心的人误以为我在写申论，先提炼一下观点：

保证把事情说明白
在1的前提下，尽可能短
必要时可以罗嗦，不要为了短而短
HTML格式与txt格式的选择，跟团队保持一致即可
写完后考虑一下受众的阅读体验
让自己的邮件易于检索
由简入繁，后而化简

纯工作性质电邮的书写可以粗略分两个部分，思路和修辞。
（这里先做一个区分，有一部分电邮是用来搞关系、扯皮、划分责任的，这些电邮的编写可以按照传统信的手法写）

A-思路部分，有一些通用的原则可以作为书写的指导。

1、“战地记者”原则

设想自己是一名战地记者，在弹雨纷飞的时候要报道当前的战况，在每说一句话都有可能有枪子儿找上脑门的时候，废话、套话、官话、空话一概省略，直切主题是最合适的。比如说作为一个系统部署人员，要向一个主管技术的大领导汇报客户现场的一个重大问题，可以用这样的思路写：

A系统B模块目前无法运行，部署日志见附件1，报错信息见附件2，客户端环境见附件3.客户要求24h内解决，否则将延迟上线。

一句话将所有的重点信息浓缩起来，相关但冗长的技术信息用附件传递，可以保证对方在看到邮件后马上理解事情的起因经过以及可能的结果，这种情况下如果顾虑太多，仍然用“尊敬的领导”一类的套话起头和修辞的话，可能会导致对方遗漏重要信息。保证对方第一眼就能看到电邮的目的。

2、“金字塔”原理

想象一下金字塔的典型构造。我认为所有电邮（甚至可以包括其他实用文章）都应该遵循这种结构：中心明确，分层叙事，逐层铺开。
关于金字塔原理的书籍，有一本同名的《金字塔原理》可以深入学习，这里只讲述一下我理解的具体概括法。
（《金字塔原理》http://book.douban.com/subject/1020644/）

a.先用战地记者原理过滤一下自己所想表达的内容。找到少数的几个重点，然后再逐一筛减直到找到有且只有一个的中心，先将这个“点”暂时列为自己所有表述的最终目的。

还是拿刚才的例子来解释，客户现场的重大问题，我需要告诉很多事情帮助对方判断，比如日志、报错信息、环境等等，但实际上仔细分析，这些东西都只是为了解决“系统部署失败”这个问题，而再仔细分析，解决“系统部署失败”后可以避免“系统延迟上线”，并且可以避免项目的失败、客户的不信任，最终将所有蛛丝马迹的问题都汇聚到一点“维持客户的信任”。

b.分析邮件接受者对于这个中心点的理解程度。如果不言而喻，则降级到下一中心点，如果可能不甚理解，则保持这个中心点，围绕着它展开描述。

对方是主管技术的大领导，对于“维持客户的信任”这一点自然能有足够的认识，因此降级，选择“项目失败”，同样有足够的共识，再降级“项目延迟上线”，在这一点上，大领导可能不会比现场人员有更清醒的认识，因为山高皇帝远，他能看到的实况有限，而自己的任务就是将这一实况以足够明显而肯定的方式汇报给对方，让他有足够的资源进行判断、协调资源，所以选定“项目延迟上线”这一点作为中心。

c.描述中心点最直接相关的一层信息。

项目延迟上线最直接相关的是“部署失败”，但部署失败只是个结果而不是过程，所以还需要继续描述为什么部署失败。通常做一件事有这么几方面信息，“我有什么资源做、怎么做的、出现了什么结果”，这三个方面就是部署失败的直接相关的信息。

d.继续描述“直接信息”的“直接信息”。这里将进入一个循环，将自己认为需要说明的情况用逐层铺开的方式附加到中心信息上，丰富中心信息的支撑体系。在电邮里需要根据实际情况采用不同的方式进行附加，例如图片、图表、附件文档等。

日志、操作记录等信息虽然有价值，但因为信息过长、对中心点没有直接帮助，而必须以一种不干扰阅读的方式出现，挂附件是比较好的选择，这可以保证对方在需要获取的时候不难获取、在不需要获取的时候直接避开。

通常参考这两项原则、经过不断的书写联系和概括，就能保证自己的电邮产出是思路得体的。

B-修辞部分，每个人都有自己的文字风格，但在工作性质的电邮中，需要适当约束自己的码字习惯。

1.标点

这部分是最容易忽视的，不少工作N年的老同事在书写电邮时要么不加符号，要么乱加符号。比如每句话都用问号结尾、到处乱跑的感叹号、翻译腔的破折号等等。我自己有一个电邮标点的心里底线，就是“可以不规范，但一定要规律”。
比如有时因为输入法等问题没办法使用标准的中文句号，我索性就直接用英文句号、甚至减号，但一定会有规律地用，比如所有减号都是句号的意思，避免对方看不明白符号的意义，另外日常聊天时我习惯以三个句号结尾，但在电邮中尽量避免这些个人习惯，就算不能规范地使用标点，但也至少不要成为潜在的阅读障碍。

2.字体

默认字体

如果公司有规范，严格执行，如果没有规范，就保持默认字体，因为在不知道对方视力、阅读场合、阅读仪器的时候，默认字体是最安全的选择。

粗体

仅限于刻意强调的文字，一般情况下在一段话内只出现一个粗体词组时，强调效果是最好的，而出现了三四个甚至更多的粗体时，效果反而降低，“都强调等于没强调”，所以，找到自己最需要的那个点，然后再考虑是否值得加粗。

斜体

另外，无论如何都要谨慎对待“斜体”，尽量避免使用，目前win平台的斜体是粗暴的。
参考这个问题（http://www.zhihu.com/question/20120243）

3.颜色

安全色：红色、绿色

除了红色（代表强调或者危险）和绿色（代表通过和安全）可以适度使用外，其他颜色尽量避免使用。

多种颜色时，给出标注

如果一定要用多种颜色，必须在显眼的地方给出颜色的标注，否则邮件几经转手后，阅读者会不理解颜色的意义而错失、误解信息。

4.对齐

段首对齐

我见过不少同事在写一个新段落的时候前面加了两个空格，甚至一些程序员会加四个空格（因为一个英文空格是1/4个汉字长度），但是在电邮中，段落开始时应该避免加空格，这属于“web时代新文字排版问题”，不在这里铺开讨论。
（参考@梁海的这个回答：http://www.zhihu.com/question/19572531/answer/12254947）

段末对齐

不要用回车控制换行，因为在自己的客户端设置下看起来美观的回车换行，到了别人的设备上将可能是一种视觉灾难，参考这个图片（左为原始屏幕，右为较小屏幕下的显示效果）。

5.换行与行间距

手工空行

在表述完一个完整段落后，尽量手工空一行，因为在不同的阅读设备中，没有这个空行的话会导致密密麻麻的文字墙，这种视觉压力会直接影响阅读者的理解能力，留白能让人在阅读的时候有喘息的机会和理解的间隙。

适当的间距

行间距可以用默认间距或1.5倍以内的间距，取决于篇幅多长，更高的间距会让阅读者的视线跳跃过多引发视觉疲劳。

6.文字描述手法

概括一下我所推荐的电邮写作手法，“选择朴实准确的形容词和副词，多用具备一定意义的短句，避免复杂术语的堆砌”。

选择朴实准确的形容词和副词

这里主要针对偏爱小说式电邮的写作方式，比如需要用“美观”代替“美轮美奂”等等，工作电邮不是散文，需要确保务实。

多用具备一定意义的短句

将长句拆解为短句，可以让阅读者更容易理解，比如

本次项目延期上线是因为在客户现场出现了一个由于安装A程序失败导致了冗余的tmp文件丢失所引发的故障。

可以拆解为

项目延期上线，因为在现场出现了安装故障，该故障由A程序安装失败所引发，具体原因为冗余tmp文件丢失。

避免复杂术语的堆砌

这一条在技术同事来看，可能有不同意见，因为在大部分RD相互沟通的时候，术语是相当于世界语的。
不过大部分RD线以外的同事并不理解RD之间说的“我打算继承你写的A方法”或者“给我个接口”，所以在同事间互相电邮的时候，需要确保自己写的东西是对方能看懂的，例如下面这种替换（阅读者是财务同事）。

你打开浏览器，输入1234，然后看系统控制台，把里面的systemp参数copy给我。

可以替换成

你打开IE，或者360浏览器，在地址栏（上面那个有http:\\字样的）里输入1234，然后看打开的页面，左边有一个菜单，靠中间的位置有一个功能叫“系统控制台”，点开它，再看弹出来的窗口，最上面有一排英文，把名字是systemp的后面的框内的东西复制下来发给我。

粗看起来废话不少，但这种方式的电邮却是最能保证效果的，因为同事间对于信息的理解不同，而信息不对等是造成沟通不畅的最主要障碍，说白了就是“你说的我不理解，我说的你不理解，双方都要往复几次才能理解对方”。

7.标题

电邮标题也是经常被忽视的一点，但这一点至关重要，可以说保证了自己和对方在今后查找相关信息时的准确性。
恰当的标题一般是最全面的概括、最开始的引子、最点睛的描述。

最全面的概括

《有关XX项目在XX客户现场的部署故障及现场情况说明》

最开始的引子

《XX市XX客户现场部署故障》

最点睛的描述

《XX客户现场部署故障将可能导致延期上线》

这些都是可行的例子，根据实际情况作权衡。

8.其他

其他电邮的写作内容还包括签名档、邮件重要度、邮件格式、阅读者的环境预估等。

签名档

签名档主要用于让对方获取自己的其他联系方式，公司有统一要求的，需要严格执行，如果没有统一要求的，需要设置一个固定的格式，包括个人姓名\英文名、公司正式注册名称、部门\项目组、手机、座机、MSN等必要信息。

重要度

除非是火烧屁股的事，千万不要使用重要度这个设置，以免重写狼来了的故事，《狼来了之现代电邮版》。

邮件格式

通常设置为html格式，如果有特殊要求也可以考虑txt纯文本，但后者将没有视觉格式可言，一般不推荐。

阅读者的环境预估

这部分其实有一点投机，也可以看做是“电邮沟通中的用户体验”，例如对方经常使用12寸小本，就尽量把表格设置得紧凑一些，对方如果是出差在酒店里，发邮件时就尽量避免发送大附件，而使用其他方式传递等等。

以上为个人观点，供参考，欢迎讨论指正。

@ Sven

第一次写作商务邮件的人往往都不知道自己应该表达什么。在这个时候，有三个自问的问题很容易帮你理清思路：

第一，我需要的答复是怎样的？
第二，为了得到答复我应该提供哪些信息？
第三，我提供的信息当中哪些是主要信息？

@陈甫鸼

很久之前赞同过排名第一的君的回答，前些天被邀请，又重新看了看，想法有些改变，而且很多东西现在看来我已经无法同意。所以还是回答一次。回答前声明：不同单位的具体实践肯定有差异，所以我的回答不是规范，只是参考。另外，我不打算就遣词造句给建议。这是语文课就该完成的事。

大体上，我把邮件看作三种不同种类：私人邮件、内部交流、公务信函。不同类型要求不同。对我来说，我大概会使用如下原则：

原则一：礼貌原则。

语句保持通顺，标点无错。这是起码的要求，不只是邮件，所有类型的写作都有这一条。当然，具体到微软这样的公司，大家来自全球各地，英文水平参差不齐，偶尔犯个小错大家也会宽容，但绝对不意味着可以一直打马虎眼。

公务环境请使用环境中通行的语言。这同样是一种形式的礼貌。比如公司环境中通行英文，即便是整个邮件的阅读者都是中国人，也请用英文。反过来也一样，不要在中文邮件中突然冒出个说英文的，非常不礼貌。

学会区别To和Cc。如果确实希望对方读到，请务必将其放入To栏，其他人可以放入Cc栏。尽管我自己会检查所有To和Cc栏有我的邮件，但那只是个人习惯，很多人遇到自己只在Cc栏的情况时是不读邮件的。Bcc有些特殊，据我所知，不同公司对这一栏的用法区别非常大，所以无法建议。

抬头和落款。内部讨论可以随便，没有开头没有落款都无妨。但正式一点的邮件就需要。我个人的做法是：如果是一对一的邮件且同事之间相熟，那么我经常不写开头和落款；如果接收方是两个人或以上，或者是上级或师长或合作部门同事，无论如何我都会写好抬头和落款。对师长，不仅落款抬头不能缺少，而且我会始终使用敬语。

文件格式：的说法是不对的。正确的做法是：跟随你的社区。比如在微软我们都使用 Outlook，所以HTML格式的邮件是标准。但我也曾经为 Linux 内核社区工作过一年多，在那里，标准的做法是纯文本。为什么文件格式要单独提出来说？因为很多开源社区对此并不宽容，Linux 内核社区就是其中之一。我不想评论这个决定好坏，但如果你需要融入工作/社区环境，请遵守这些习惯。

用词。正式信函请使用规范用语，避免口语化。同事间私下讨论可以稍微随便一点，私人信函更随便一些。不过我也确实看到前台的姐妹们发的帮助邮件里“亲爱的~~”用得不少。对此我当是不同部门文化有差别，再说也挺可爱，不是么？

原则二：专注原则。

标题明确。的回答我完全赞同。标题的原则是一句话能表达主旨，能做到这一条，其他的就没关系了。

长度。公务邮件和内部邮件请务必保持邮件简短，多的内容请放进附件或打电话。我曾见过一些邮件特别喜爱长篇大论，而且表格、图表、链接，什么都往里面塞，一封邮件看得人昏昏欲睡。但有一点例外：对外公务信函。这类信函往往有宣传的目的，需要长篇大论的时候不少见。相应地，私人信函就没必要如此讲究。我和身处美国的老师之间通信聊聊近况讨论最近身边的趣闻，经常长篇大论的。

内容单一。似乎很少有朋友提到这个问题。一封邮件不要说两件事，除非两件事的确紧密相关。如果有两个问题，请发两封邮件，在两个列表中讨论。这是为了防止一件事被讨论太久忘记了另一件。

合法性/政治正确。这个也是上面的答案很少提到的。商务/公务邮件不仅是通信工具，法律上也承认它们可以作为证据。所以邮件里不是什么内容都可以说的，特别是和其他公司或外部媒体打交道的公务邮件。如果有任何不清楚的地方，发邮件前请务必和上司或法务讨论。即使是内部邮件，出于安全考虑也不应破坏这个规则。

关于一些我不同意的点：

重要度。请容我说一句：真正火烧屁股的事情，是***绝对***不会写邮件的，打电话，直接敲门才是正确的做法。在我们这里，如果某人确实太久没回邮件，有耽误事的危险时，加个重要度是一个善意的提醒。与此相对地，还有Outlook的低重要度选项，一般我会在发一些工作无关的问候邮件时使用（比如祝在美国的老同事们节日快乐）。

签名档。很多时候，统一格式的签名档仅仅用于工作中有对外交流内容的同事当中，比如销售部门、前台、IT等。技术部门的同事们很少有这种习惯。

术语堆砌。这不是邮件问题，而是写作技巧问题。内部讨论只要确实是为了说清问题，有时候堆砌术语难以避免也没必要避免。但如果邮件读者是管理层、销售部门，那么避免使用技术术语就是很自然的事情。

颜色、粗体、斜体……。我的说法是：如果是对有限听众，则一概不要用，即使是HTML邮件也不例外。我们是在写邮件，不是在写广告，一份邮件花花绿绿的让人看得头脑发麻。除了一个例外：如果我的邮件是一封面向大量公司同事的、广告性质的邮件（比如宣布某个活动开始），那么就需要用大字体或粗体突出重点。

Cut and Paste。在一些特定的状况下是必须的。所谓特定状况，主要是转发给手下的时候，避开一些不适合公开的内容。当然，给上司的邮件不该这样做。

大体上就这样了。

http://www.berkshirehathaway.com/letters/letters.html