Principle 01
主题行：你唯一保证被看到的一行
Subject Lines — The Only Line You're Guaranteed to Be Read
Subject · 收件箱分诊
一句话原则 + 名家原话
收件箱是一个扫描场，不是阅读场。主题行不是"标题"，是给收件人的路由标签 + 优先级标签——它替对方回答两个问题：这关我什么事？我现在要不要点开？
"We don't read pages. We scan them."
— Steve Krug《Don't Make Me Think》Ch. 2
中译：我们不读页面，我们扫页面。（Krug 谈的是网页，但收件箱更甚——读者连正文都不点开，只扫主题行。）
原理解读
收件箱 60 封未读，读者的动作不是"阅读"，是"分诊"（triage）：每封给半秒，判断删 / 存 / 现在回 / 待办。主题行就是这半秒里唯一的信息。好主题行做两件事：① 把动作前置——用 [需决定][FYI 无需回复] 这类标签声明性质；② 具体到可检索——三个月后 grep 收件箱，"更新""会议"是噪音，"Q3 发布日期"才是信号。一个反直觉技巧：主题行最后写——正文落定了，你才知道这封到底要对方做什么。
修改示范
主题：会议 / 同步一下 / 更新
主题：[需你拍板·周四前] Q3 发布定 8/12 还是 8/19——倾向 8/12
Subject: Quick question
Subject: [Decision by Fri] Approve $12k vendor switch? (saves 30% / 1-yr lock-in)
改后让对方不点开正文也知道：什么事、做什么、什么时候之前、你的倾向。点开只为确认细节。
适用场景 + 常见错误
- ✓ 任何期望对方"采取行动"的邮件 · 群发通知 · 需日后检索的决策邮件
- ✗ 私人致谢、纯寒暄——不必硬贴标签，显得机械
- 错误一：写"模糊感"——"关于那个事"，对方得点开才知道关不关他
- 错误二：一个主题串塞三个话题——后人无法按主题检索
- 错误三：[紧急] 成习惯——狼来了，真紧急时没人信
关键参考
Steve Krug《Don't Make Me Think》(2000) — 扫描而非阅读 · David Shipley & Will Schwalbe《Send》(2007) — 主题行专章 · Todd Rogers & Jessica Lasky-Fink《Writing for Busy Readers》(2023) — 主题行与回复率的实证
本周习作 + 思考题
习作：翻"已发送"最近 10 封，给每封重写主题行：加性质标签（决定 / 行动 / FYI），删"更新""同步"空词，具体到可检索。对照原标题，哪个能让你三个月后一眼找到。
思考：若对方只读主题行、永不点开正文，这封邮件还能推动事情吗？不能，就还没写到位。
Principle 02
BLUF：把结论放在第一句
Bottom Line Up Front — Lead with the Answer
BLUF · 结论先行
一句话原则 + 名家原话
正文第一句就给出结论、请求或决定，再写背景与细节。读者读完一句就知道"这关我什么事、要我做什么"——剩下的看不看由他。这是军方公文的标准开头。
"Military professionals lead their emails with a short, staccato statement known as the BLUF (Bottom Line Up Front). It declares the purpose of the email and the action required."
— Kabir Sehgal《How to Write Email with Military Precision》Harvard Business Review, 2016
中译：军人写邮件以一句短促的陈述开头，叫 BLUF（结论先行）。它直接声明邮件的目的与所需的行动。
原理解读
这是第 2 日金字塔原理的邮件版。新手按"讲故事顺序"——背景→过程→结论，把请求埋在第四段。但读者是分诊心态，第二段没看到"要我干嘛"就走了。把结论提到第一句，等于把"要不要继续读"的判断权交给对方，而非逼他读完才知能否跳过。
① BLUF — 结论 / 请求 / 决定第一句。要对方做什么、什么时候之前、你的建议
② Context — 为什么最小必要背景，2–3 句
③ Details — 细节 / 选项 / 数据想深究的人往下读；不想的人到这就够了
倒金字塔：信息按"读者需要的紧迫度"排，不按"事情发生的顺序"排
修改示范
上周和数据团队开会，聊到 pipeline 几个老问题，又牵出上游依赖……（三段之后）所以想问能不能批准加两台机器。
请你今天批准：给 ETL 集群加 2 台机器（约 ¥13k/月）。原因：上游数据量本月翻倍，夜跑超时 3 次、阻塞晨报。备选与成本对比见下。
Following up on our discussion last week regarding the roadmap, and after syncing with several stakeholders, there are a few considerations... (buried) ...could you let me know your thoughts on the timeline?
Need your call by Thursday: ship Feature X in v2.4 (Jun) or v2.5 (Aug)? I recommend Aug — June risks the migration overlapping with the audit. Context and tradeoffs below.
适用场景 + 常见错误
- ✓ 请求审批 · 状态汇报 · 决策邮件 · 几乎所有内部邮件
- ✗ 慎用：极敏感 / 坏消息，劈头一句结论显冷硬——先给一句缓冲（见 Card 3）
- 错误一：把"结论"写成"主题概述"——"关于发布时间"不是结论，"建议定 8/12"才是
- 错误二：给了结论却没给"要对方做什么"——读者还得猜行动项
- 错误三：BLUF 后又在结尾重复一遍——信任读者，别啰嗦
关键参考
Kabir Sehgal《How to Write Email with Military Precision》HBR 2016 · U.S. Army AR 25-50《Preparing and Managing Correspondence》— BLUF 的官方出处 · Barbara Minto《The Minto Pyramid Principle》— 结论先行的母本（第 2 日）
本周习作 + 思考题
习作：找一封请求被忽略的长邮件，砍成三段：一句话 BLUF（结论+行动+deadline）、背景、细节。数数原文与改后的字数——通常砍掉一半，回复率却更高。
思考：BLUF 假设读者"想先要答案"。有没有一类沟通，过程比结论更重要、先抛结论反而失礼？这与文化（直接 vs 含蓄）关系多大？
Principle 03
说"不"与负面反馈：对事狠，对人暖
Saying No & Hard Feedback — Hard on the Issue, Soft on the Person
Candor · 坏消息
一句话原则 + 名家原话
坏消息、拒绝、负面反馈——别为了"不伤感情"而把话说糊。对事直接（说清问题），对人在意（顾及关系）。含糊的好意，比直接的坏消息更伤人，因为对方根本不知道该改什么。
"Radical Candor is what happens when you put 'Care Personally' and 'Challenge Directly' together. ... Challenging people generally shows you care."
— Kim Scott《Radical Candor》(2017)
中译：当你把"真心在意对方"与"直接挑战对方"放在一起，就有了彻底坦率。挑战一个人，恰恰是在表明你在意他。
原理解读
面对负面反馈，多数人滑向两个失败模式：毁灭性同情（在意但不敢直说，绕弯、和稀泥，对方收不到信号）或令人讨厌的攻击（直接但不在意，贴标签、论人不论事）。怎么"对事直接"而不"对人攻击"？用 SBI：不说"你态度有问题"（论人、模糊、没法改），而是描述情境—行为—影响三段事实。事实没法反驳，标签必然引发防御。
SSituation 情境具体的时间地点："周二评审会上"
BBehavior 行为可观察的动作，非评判："打断了三次"
IImpact 影响造成的后果："风险点没讲，会后漏了依赖"
SBI 模型（Center for Creative Leadership）— 用事实代替标签
修改示范
你最近表现不太行，开会态度也有点问题，大家都有反映，注意一下。
周二评审会上（S），Lin 没讲完你打断了三次（B）；结果她后半段的风险点没讲，会后漏了那个上游依赖（I）。下次能不能记下来、等她讲完再问？我提这个，是因为你的判断很关键，希望它被完整听到。
（拒绝时含糊答应）这个需求我尽量排排看吧……（结果既没做，又让对方空等）
这个 sprint 排不进了，得直说。如果它比 X 更急，我可以撤下 X 给它腾位置——优先级你来定。（清晰的"不"+ 一条出路，远胜模糊的"尽量"）
适用场景 + 常见错误
- ✓ 绩效反馈 · 拒绝请求 / 需求 · 叫停项目 · 评审指出问题
- ✗ 慎用书面：情绪浓、易误解的负面反馈先当面 / 通话，邮件只做记录
- 错误一："夹心三明治"（夸—批—夸）把核心埋掉——对方只记住两头的夸
- 错误二：说"不"时一堆解释和歉意，却没说出那个"不"——对方以为还有戏
- 错误三：论人不论事——"你就是粗心"是标签，"这次漏了 3 个 case"是事实
关键参考
Kim Scott《Radical Candor》(2017) — 在意 × 直接的二维框架 · Center for Creative Leadership《SBI Feedback Model》— 情境-行为-影响 · Douglas Stone & Sheila Heen《Thanks for the Feedback》(2014) — 接收反馈的一方
本周习作 + 思考题
习作：想一件你"忍着没说"的负面反馈，用 SBI 写成三句：情境、行为（可观察、无评判）、影响。检查有没有混进"你总是""你就是"这类标签——有就改成具体事实。
思考：Radical Candor 生于硅谷的直接文化。在更讲层级、更含蓄的职场里，"直接挑战上级"风险更高——框架怎么改造，才能既保住坦率、又不踩文化雷？
Principle 04
异步优先：一次把上下文写全
Async-First — Write the Whole Context Once
Async · Slack 文化
一句话原则 + 名家原话
异步沟通（邮件、Slack、文档）的黄金律：一条消息说完整件事——上下文、问题、你的倾向、期望的回复时间。别发"在吗？"然后等。每一次"等对方在线"都是一次双向的打断。
"Real-time sometimes. Asynchronous most of the time."
— Jason Fried & David Heinemeier Hansson, Basecamp《How We Communicate》
中译：偶尔实时，多数时候异步。（实时沟通要求所有人同时在场——这是奢侈品，不是默认值。）
原理解读
"在吗？"是把思考成本转嫁给对方：逼对方停下手头的事、追问、再等你打字。异步写作的核心是自足（self-contained）——读者任何时刻打开，无需追问就能行动。它天然可检索、可沉淀：写进文档的决定半年后还在，实时语音里的共识第二天就蒸发。判断同步还是异步，看一点：它需要"立刻的来回"，还是只需要"清楚的一次"？
同步 Sync
- 高带宽、强情绪：辞退、冲突、坏消息
- 需快速多轮碰撞：头脑风暴、危机处理
- 关系建立：1:1、新人融入
- 代价：要求所有人同时在场
异步 Async
- 状态更新、信息广播、FYI
- 需要深思的决定（给对方时间想）
- 跨时区 / 跨深度工作时段
- 红利：可检索、可沉淀、不打断
默认异步，按需同步——把同步留给真正需要"在场"的事
修改示范
（Slack）在吗？ ……（对方："在，怎么了"）……那个支付的事方便聊下不？ ……（来回五轮才进正题）
（Slack）[非紧急] 支付回调超时：我想把 timeout 从 3s 调到 8s，理由是上游 P99 已到 5s（PR 链接）。你若周四前无异议我就 merge；有顾虑随时说。
Hey, you around? Got a sec?
[No rush] Reviewing the Q3 plan — one blocker: the launch date assumes infra is ready by 7/1, but I haven't seen a confirmation. Can you confirm by Wed, or tell me who owns it? Doc here: [link]
适用场景 + 常见错误
- ✓ 远程 / 跨时区团队 · 需深度工作的角色 · 易被"打断税"拖垮的协作
- ✗ 别异步：实时危机、需情绪温度的对话、反复澄清才能对齐的复杂议题
- 错误一："在吗"开场——逼出一轮无信息的来回
- 错误二：把异步当"即时"——发完盯着等回复，比同步更焦虑
- 错误三：一条消息塞五个话题——对方回三个忘两个，可检索性归零
关键参考
Jason Fried & DHH《It Doesn't Have to Be Crazy at Work》(2018) · GitLab《Handbook — Asynchronous Communication》— 远程协作的公开范本 · Cal Newport《A World Without Email》(2021) — "超活跃蜂巢思维"之害
本周习作 + 思考题
习作：这周抓住一次正要发"在吗？"的冲动，改成一条自足消息：背景、问题、你的倾向、期望回复时间各一句。看对方是不是一次就给到位，省了来回。
思考：异步省了打断，却牺牲即时澄清与情绪温度。团队几乎全异步会失去什么"弱连接"？哪些事你会刻意留给同步，哪怕更低效？