电邮靠谱指南
作者：Zoom.Quiet
GitCafe 主页：
https://gitcafe.com/ZoomQuiet
原文地址：
http://blog.zhgdg.org/2014-02/email-kaopulity-guider
俺常常说的:
准入
~ 想理解以下内容，先明确:
习惯科学上网
习惯用 Chrome/Safari/Firefox，万不得以也可以安装 Opera, 死也不能用 IE !
习惯每天处理 42+ 电子邮件
承认并接受 e-mail 暂时无可替代
理解
Gmail 生活指南 (http://blog.zhgdg.org/2014-02/livin-gmail-guider/)
珠海 GDG 社区行动手册之邮件列表 (http://blog.zhgdg.org/2013-06/zh-gdg-mailing/)
WyTiWyG (http://wiki.woodpecker.org.cn/moin/WyTiWyG)
演讲
2.22-SOD-Kaoupulity-email (https://speakerdeck.com/zoomquiet/2-dot-22-sod-kaoupulity-email)
140222_sod-cbi_4_email.MP3 (http://res.zoomquiet.io/ZHGDG/2014/140222-sod-cbi/140222_sod-cbi_4_email.MP3)
140219_wps2_work_mail.MP3 (http://res.zoomquiet.io/ZHGDG/2014/140219-skill4mail/140219_wps2_work_mail.MP3)
主要针对工作邮件的经验，但是，私人邮件其实 80% 的情况是一致的.
只探讨:
在涉及人员都具备基本的职业素养,
同事之间无冤无仇也没有人来大姨妈的情况下,
如何写出让对方看过之后觉得专业并乐于回应的邮件
书面胜于口头
如果不承认这点,就别往下看了:
想不清楚的事儿，一般写不下来
写不清的事儿，一般也说不清楚
必须当面说才能清楚的事儿，一般没谱
而且,邮件在所有事儿的过程中比其它所有网络交流方式有天然的优势在:
电子证据，无法伪造
推进事件链，能客观/完整记述具体过程
永久保存，不会丢失 (特别是使用 Gmail 类似配合云存储的服务时)
最招人反感的邮件形式
RT
正文就两个字母: RT
这种邮件，目测 99.9999% 的正常人，是不会回复的.
正文不剪裁
只回复半行
但是，带了上千行过往数十封邮件的全文
回 1 行字，原文引用 1000 行。（来自 AceFantasy 的微博）
用 回复: 撕裂 coversations 的
明显使用类似 foxmail 之类未流客户端或是免费中文邮件服务的
使用各种可定制的中文前缀文，以及无视 e-mail 协议头信息有关规定
肆意撕裂邮件线索
导致一件事儿，从一组邮件变成离散的一堆邮件
用 top-post 而且有大堆标准PR缀文的
类似 gmail 中不推荐的选项打开了:
Insert this signature before quoted text in replies and remove the "--" line that precedes it.
这样将造成一个讨论线索引文中包含海量难以删除的缀文
HTML
这种格式的邮件，千万别轻易使用,
太多几率对方根本就看不到，或是只能看到错乱的排版！
GB2312
指定这种文字编码的人，基本上没救了。
参考:
有关GB18030编码来由的传说
(http://floss.zoomquiet.io/data/20050826004647/index.html)
神奇的邮箱名
类似 .嘦ぐ龘ǒ 之流后现代网络 KUSO 文
或是，每天变更邮箱名，每次收到邮件都不确定是否是同一位
最容易被无视的邮箱
背景:
邮箱地址反映你的计算机水平 / 煎蛋
(http://skm.zoomquiet.io/data/20101021093909/index.html)
雅虎:用雅虎邮箱的人都很烂吗? | 36氪
(http://www.36kr.com/p/5940.html)
在中国，技术圈儿里，使用以下邮箱来发送邮件，基本上很难得到很好的第一印象:
@qq.com
@163.com
@126.com
@sina.cn
@hotmail.com
@msn.com
...
因为，这些邮箱代表着...呵呵呵...
邮件基础行为要理解
背景：ARCI分析矩阵
工作中任何一个环节的上下文总是有以下责任层级：
Accountability ~ 责任 : 对成败负责和进行协调管理
Responsibility ~ 职责 : 具体实施
Consulted ~ 咨询 : 提供意见，救助决策
Infomed ~ 了解 : 知晓进度
所以，件作为工作中的关键信息载体，要合理使用不同的内置行为:
TO（发送给）
收件人是职责人
是这事儿的直接参与/处置/接手人
CC（抄送）
`抄送给责任/咨询 者
是这事儿的直接/相关领导/组织/机构，可以发表意见
BCC（密送）
密送的应是有权知情人
是这事儿需要知道进展的领导/资源/甲方，但是，不必反馈意见
一般礼节，应该在正文中说明 BCC 给了谁
FW(转发)
收件人是职责人
是这事儿的应该执行/处置/接手人
代表，这事儿不应该归俺作的
所以，回复时，要小心，
不是随便回复就可以的，
或是，永远只是单纯的回复发件人，完全无视 CC 名单
如果邮件发送方，包含了复杂的 CC 名单，
一般情况是要尽力保持,
除非我们回复时包含敏感内容，必须单线联系，才能只回复发信人，清除所有 CC 邮箱.
写新邮件的最佳顺序
附件 -> 正文 -> 标题 -> 收件人
为毛?!
这个自个儿体验就知道了.
邮件标题的最佳结构
30 字以内，尽可能的包含 5W1H
用标签明确类别，是要求/通知/汇报/指令还是其它
有日期要求的一定要写
有明确专有名词指代项目/工程/产品 的一定要用
一般是对部门进行叙述
有明确的期待收件方作什么的行为描述
邮件正文的最佳结构
倒金字塔叙事
在邮件的开头，用三行，言简意赅地概括大意，讲清楚 5W1H
再慢慢展开邮件，旁征博引，罗列数据，推演流程吧
最忌讳将邮件写成小说/散文，一看过去乌泱泱几个大段。没人有耐心逐行去看的。
另外，多说事实，少说道理。
附件
正如附件的名称所指含义：附加文件
既然是附加文件，就不应该是邮件的唯一内容！
一般附件都是相关特殊格式的数据/报告/设计稿，都是给收件人使用的工作元件
而不应该是邮件本身的主要内容！
即使是请求他人来审核附件文件的内容，也应该将全文/或是概要直接写在邮件正文中
因为， 习惯性的使用 D 版 Word 来起草一切文档，然后附件邮件中发送；这其实就是经典的学生式思维：
而从来不从对方角度着想，想看到真正的内容的操作:
点击附件下载
打开资源管理类似工具
定位到默许下载目录
点击下载的附件
等待对应专用软件打开附件
整个儿流程下来，没有半分钟完不了，但是，如果别人一天要处理几百封邮件的话，基本什么事儿也不用想了。
实例故事
事儿:
某活动的邀请函,需要俺转发另外两人
行为:
邮件正文曰:
然后，俺下载到 muCommander( : a cross-platform file manager) 中是这样的:
尝试用伟大的 7 - Zip 解开是这样的:
郁闷ing:
俺 MAC 10.9 Mavericks 系统，想用 WPS 得:
使用另外测试用 Win7 系统机器
或是，启动虚拟在XP 中打开
压缩包险险中文正当, Gmail 立功了
但是，内容，文件名杯具的使用了 cp936(gb2312) 编码
导致在本地的文件名全部乱码
为什么不用 E 文 呢？
俺要真正完成这位同学的吩咐，目测要作:
运行 VirtualBox
进入XP
安装 WPS
在主机设置共享
回到虚拟系统，从共享中打开乱码文件名的 .wps
逐一阅读内容，明确都是给谁的邀请函
输出为对应的 pdf 文件
对应修订 pdf 文件名，为全 E 文的
另外创建一个 .txt 文件，将邀请函内容,复制进入
关闭虚拟机，回到主机
进入gmail 逐一转发邮件并增补邀请函内容到正文，并附件上对应 pdf
整个儿的耍下来，没有半小时搞不掂哪!
正确的作法:
组织好邀请函，并输出为 pdf
向俺发送三封邮件:
给俺的邀请函，并说明马上有另外两封邀请函发送过来，请转发
另外两封邀请函，完全是向另外受邀人的口吻和内容
所有邮件，邀请内容都以纯文本形式在正文，并包含图文排版的 pdf 附件
这样俺收到邮件后，完成吩咐的行为就变成:
打开邮件，阅读，明确接下来的行为
收到另外两封，逐一 FW 给对应小伙伴
是也乎
简单的说，用好/用对电邮的原则极其简单:
从收件人角度设想
邮件的内容/形式/结构/过程，都为解决事儿，而不是掉书袋神马的
以尽可能的节约涉及到的所有人的时间/精力为目标
持续改进，自个儿的邮件习惯
这其中，个人发觉，越早习惯以下思维，越容易变得靠谱:
Markdown
不用中文标点
每行不超过 79 字
感谢 Python 社区的大妈 Zoom.Quiet 为我们涨姿势，他也是 GitCafe 的用户！虽然文中告诉大家不用中文标点，可是小编还是习惯了全部用了中文的标点，特此说明一下……
我们也欢迎大家向我们投稿～～
