从会写代码
到能成事Soft Skills Handbook for Engineers

软实力不是“会说话”，也不是“会来事”。它是一组让你在没有正式权力的情况下，仍然能让正确的事情发生的能力。

一个熟悉的场景

小林和阿哲同一年入职，都是后端工程师，技术底子接近。

第一年，两人都在写业务代码。区别出现在一些很小的瞬间：

• 需求评审时，小林觉得方案有问题，憋了半天说“这个实现有点麻烦”，然后被产品经理一句“先这样做吧”带过。阿哲会说：“如果按现在这个设计，订单状态会有四种非法组合，我建议加一个状态机约束，成本大概多半天。”
• 线上出故障，小林在群里连发十几条日志截图。阿哲发的是：“影响范围：3% 的下单请求；已定位到缓存击穿；临时方案已生效；根因今晚给结论。”
• 年底述职，小林写了 8 页“我做了 A、B、C”。阿哲讲了 3 个故事：哪个指标因为他的改动从多少变到多少，谁因此少加了班，他沉淀了什么被别的团队复用。

三年后，阿哲成了那个“别人做方案前会先问一句”的人。不是因为他代码写得更快，而是因为他的判断可以被信任，他的表达可以被依赖，他的推动可以落地。

这就是软实力。它不替代技术，它负责把你的技术兑换成真实世界里的结果。

为什么程序员特别容易在这上面吃亏

不是性格问题，是职业训练的结果。我们的工作长期奖励另一种能力结构：

这本书怎么用

它不是“读完就变强”的书，而是一本可以反复查的工具书。每一章都遵循同一个结构，你可以按需跳读：

一个残酷的事实：在会上，大多数人只会给你 30 秒的注意力。如果这 30 秒里你在铺垫背景，你就已经失去了他们。

为什么我们总是从盘古开天讲起

因为那是我们真实的思考顺序。你接到一个问题，先查资料，再排除方案，最后得出结论——这个链条在你脑子里是完整的，所以你很自然地从头讲。

但听众的脑子和你的不一样：他们不知道你的结论，所以无法判断你哪句话重要。信息一条条进来，他们得自己在脑子里搭结构，搭到一半就累了。

结构化表达做的事情只有一件：把你脑子里的树，倒过来交给对方。先给树根（结论），再给枝干（理由），最后给叶子（细节）。

三个可以立刻套用的结构

结构一：结论—依据—请求（30 秒版）

适合：会上发言、电梯里遇到老板、群里同步重要信息。公式只有三句：

【结论】我建议把 X 推迟到下个迭代。
【依据】因为依赖的支付接口还没联调完，现在上线的故障概率很高。
【请求】需要你确认：是先上不含支付的部分，还是整体延期？

注意最后一句：表达必须带“请求”。没有请求的表达只是广播，对方不知道要不要行动、该做什么。很多人讲完一段话，会议室安静三秒，然后有人说“好的我们再看一下”——问题就出在缺少明确的请求。

结构二：SCQA（讲故事版）

适合：方案汇报、写文档开头、说服别人接受一个不太受欢迎的决定。

SCQA 的妙处在于：它让听众自己走到你的问题面前。你先说结论，他可能抗拒；你先说冲突，他会想“那怎么办”，这时候你的答案就成了他的答案。

结构三：问题—选项—建议（决策版）

适合：让领导做选择、跨团队对齐方案。核心是不要只带问题，要带选项。

问题：导出功能在 10 万行数据时会超时，已有 3 个客户反馈。
选项：
  A. 改异步导出（2 人日，体验最好，但需要新增任务队列）
  B. 限制单次导出上限（0.5 人日，能止血，但客户会不满）
  C. 先加缓存（1 人日，只解决重复导出场景）
建议：先做 B 止血，同时排期 A。
需要你决定：是否接受 A 的 2 人日投入。

同一个意思，两种说法

把结构用在三个高频场景

场景一：汇报进展

不要按时间顺序讲“我这周做了什么”。按目标—结果—风险—下一步讲。

目标：本周要把支付成功率从 92% 提到 95%。
结果：目前 94.1%，主要靠重试策略和超时时间调整。
风险：还有 1.2% 失败集中在某家银行，需要对方配合排查，可能要拖到下周。
下一步：我先做降级方案，保证大促不受影响。

场景二：解释一个技术方案

对非技术听众，永远按这个顺序：它解决什么问题 → 不解决会怎样 → 大概怎么做 → 有什么代价。技术细节放在最后，且只讲一个。

场景三：拒绝一个需求

拒绝的结构是肯定目标 + 说明代价 + 给出替代。不要只说“做不了”，那是在逼对方去找你的领导。

我理解你想解决的是【对方的真实目标】。
如果现在做【他的方案】，需要【具体代价：3 人周 / 延期上线 / 影响稳定性】。
我建议改成【替代方案】，它能达到【目标的 80%】，成本只要【半天】。
如果一定要原方案，我们可以排到【时间】，你看哪个更合适？

工程师最被低估的能力，是把复杂的事情写得让人一次看懂。它同时训练三件事：想清楚、说准确、可复用。

先分清四种文体，别用同一种语气写所有东西

很多人写不好，不是文笔问题，是文体错配：用写日记的方式写决策文档，用写论文的方式写周报。

决策文档：把“权衡”写出来

一份能被信任的设计文档，不是证明“我的方案很好”，而是让读者看到你认真考虑过别的路。下面这个结构可以直接用：

# 标题：一句话说明要做什么

## 1. 背景与问题
现在是什么状态？谁受影响？不解决会怎样？（用数据说话）

## 2. 目标与非目标
目标：这次要达成什么，怎么衡量。
非目标：明确这次不做什么。（防止范围蔓延）

## 3. 方案
整体思路 + 关键流程图 + 核心数据结构。
只写“别人需要知道才能评审”的部分，不贴大段代码。

## 4. 备选方案与取舍
方案 B：…… 为什么没选（成本 / 风险 / 长期维护）。
方案 C：……

## 5. 风险与缓解
最可能出问题的地方是什么？怎么发现？怎么回滚？

## 6. 里程碑
分几步上线，每步可验证什么。

## 7. 待定问题
还没想清楚的，明确列出来，指定负责人。

周报：不要汇报“忙碌”，要汇报“变化”

老板看周报只关心三件事：进度是否偏离、有没有需要他出手的、你的产出是什么。所以周报的黄金结构是：

1. 本周期结果

   用可验证的事实，不用“推进中”“持续跟进”。例：支付成功率 92% → 94.1%。

2. 下周期计划

   不超过 3 条，每条有明确完成标准。

3. 风险与求助

   写清楚“需要谁、在什么时间、做什么决定”。这一节最容易被省略，也最重要。

求助：让别人愿意帮你

在群里发“有人知道 XX 怎么解决吗”，本质是把整理问题的成本转嫁给了所有人。高质量提问的公式是：

【背景】我在做 X，环境是 Y（版本/配置）。
【现象】期望 A，实际 B，报错如下：（完整错误信息，不要截图一半）
【已尝试】1) …… 结果……；2) …… 结果……
【最小复现】一段可运行的代码 / 一个仓库链接 / 三步操作。
【我的猜测】我怀疑是 Z，但不确定，因为……
【问题】这个方向对吗？有没有更快的排查思路？

注意最后一句。不要问“怎么解决”，要问“我的判断对不对”——前者把对方当成搜索引擎，后者把对方当成专家。人都更愿意回应后者。

改稿：好文章是删出来的

初稿写完，只做四件事，质量会立刻上一个台阶：

当众表达的本质，不是表演，是帮一群人完成一次认知迁移：把他们从“不知道”带到“知道”，从“不同意”带到“愿意试”。

先把注意力从自己身上挪开

紧张的生理反应是一样的：肾上腺素上升、心率加快。区别在于你怎么解释它。

如果你把注意力放在“我会不会讲砸”，身体会进入防御状态，你会语速加快、回避眼神、越讲越慌。

如果你把注意力放在“他有没有听懂”，同样的肾上腺素会变成专注和能量。这是唯一有效的解法，也是所有演讲教练最终都会说的一句话：去服务听众，而不是保护自己。

准备阶段：四个问题决定一切

结构：钩子—承诺—三点—回扣

钩子：前三句决定他们要不要听

有效的钩子有三种，选一种即可：

• 痛点：“上个月我们因为一次配置错误，损失了 40 分钟的交易量。”
• 反常识：“我们花了两周做的性能优化，最后发现瓶颈不在代码，在 DNS。”
• 具体场景：“想象一下，凌晨两点你被叫起来，监控显示订单全挂了。”

无效的钩子是：“大家好，我是 XX，今天我要分享的是……”——这不是钩子，这是自我介绍。可以放在钩子之后，一句话带过。

承诺：明确告诉听众“值得听”

“接下来 20 分钟，你会看到三个我们踩过的坑，以及一个能立刻用上的排查清单。”

承诺要具体、可实现、和听众有关。不要承诺“全面了解”“深入探讨”，那是空话。

主体：一个要点，一个例子，一句总结

每个要点讲完，停一秒，用一句话收口：“所以，不要在没有监控的地方做灰度。”这句话是给听众的“抓手”，没有它，例子讲完就散了。

技术分享的五段式

技术分享比一般演讲多一个要求：可信。所以结构要包含证据和边界。

1. 问题

   我们遇到了什么，为什么现有的办法不行。用真实数据，不要虚构。

2. 方案

   整体思路，一张架构图，不超过 5 个框。讲清楚数据怎么流。

3. 证据

   效果对比、压测数据、线上指标。没有证据的方案只是想法。

4. Demo

   能跑就跑，跑不了就放录屏。Demo 失败不可怕，假装成功才可怕。

5. 边界

   什么场景不适用、还有什么没解决。主动说局限，反而增加可信度。

PPT：一页一个观点

提问环节：最见功力的五分钟

被问住是常态，处理方式比答案更重要。用一个三步动作：

1. 复述：“你的问题是，这套方案在数据量再涨 10 倍时还成不成立，对吗？”
   —— 确认理解，也给自己 3 秒思考时间。

2. 分类：
   · 我知道 → 直接答，先给结论再给依据。
   · 我不确定 → “这个我没验证过，我的猜测是……会后我查一下给你确切答案。”
   · 前提有误 → “这里可能有个误解，实际情况是……”

3. 收口：“这样回答到你的问题了吗？”
   —— 防止答偏，也显得尊重。

紧张管理的三个具体动作

• 提前到场，站上讲台。让身体先熟悉环境，比在座位上默念有效得多。
• 准备第一句和最后一句，背下来。中间可以自由发挥，头尾稳住，整个人就稳了。
• 把“我要讲好”换成“我要让他听懂”。注意力一转移，生理反应会自动降级。

倾听不是“等对方说完”，是主动获取三层信息：他说了什么事实、带着什么情绪、真正想要什么。

为什么我们听不进去

因为对话在我们脑子里是“回合制”的：对方说一句，我们判断对错；找到漏洞，就准备反驳。这在工作里是本能——代码评审训练我们找 bug，找 bug 就有奖励。

但人际沟通不是找 bug。你一开口反驳，对方就会进入防御状态，接下来他说的每句话都是为了证明自己没错，而不是为了解决问题。

三层倾听：事实、情绪、意图

举个具体的例子。同事说：“这个接口怎么又超时了？”

复述：成本最低、效果最好的技术

复述不是重复对方的话，是用你的话总结，然后请他确认。

· 内容复述：“我理解你的意思是，A 和 B 都要在本周完成，对吗？”
· 情绪确认：“听起来这件事让你挺被动的。”
· 意图澄清：“你最在意的是时间，还是稳定性？”
· 归纳分歧：“所以我们一致的是 X，还没谈拢的是 Y。”

最后一句尤其有用。争论到一半，双方往往已经不在同一个问题上了。把“一致”和“分歧”分开列出来，冲突会立刻降温——因为人一旦看到自己的一部分被认可，就不那么需要赢了。

提问：用问题代替判断

“你为什么这么做”听起来像质问，“你当时考虑了哪些因素”就是邀请。同样的信息，不同的门。

连续追问：找到真正的约束

需求说“这个功能必须这周上线”，连问三层，通常会露出真实原因：

• “为什么是这周？”——“因为下周有大促。”
• “大促为什么一定要这个功能？”——“因为上次大促客服被问爆了。”
• “客服被问爆的具体是什么问题？”——“用户找不到自己的优惠券在哪。”

到这一步，真正的需求可能不是“做一个新功能”，而是“在订单页加一行优惠券入口”。追问不是为了刁难，是为了避免用两周做一个半天就能解决的问题。

当对方情绪上来时，讲道理是最没用的

同事在群里发：“你们这个接口又挂了，我们这边全卡住了！”

这时候你解释“是因为你们没按文档传参”，无论多正确，都会让事情更糟。因为对方此刻要的不是原因，是“有人接住了”。

四个动作，顺序不能乱：

1. 承认影响

   “这事确实影响到你们了。”——不判断对错，只承认事实。

2. 给出时间

   “5 分钟后给你结论。”——情绪最怕的是无限期等待。

3. 再谈原因

   等对方平静下来，再说“我查了一下，是参数为空导致的”。

4. 给出下一步

   “我们加一个默认值，另外在文档里补一句。”——让对方看到不会再发生。

沉默也是一种表达

对方说完，停三秒再回应。这三秒里会发生两件事：他可能会补充真正重要的信息；你可能会想到一个更好的回应。

很多重要的信息，都是在“以为对话结束了”的那三秒里说出来的。

职场里绝大多数重要的事，都发生在你的职权范围之外。能不能推动它们，是普通工程师和技术负责人的真正分界线。

先接受一个事实：你没有权力，但你有“货币”

组织里的影响力不只有职位一种。至少还有三种硬通货，每个人都可以积累：

• 信息货币：你比别人更早、更准地知道发生了什么。比如你从监控里发现某个下游团队的错误率在上升。
• 专业货币：你能解决他们解决不了的问题。这是工程师最天然的杠杆。
• 关系货币：你们之前打过交道，你帮过他，或者至少你没有让他难堪过。

大多数人推动事情失败，是因为只带了一张牌：“这件事很重要，请你配合。”重要是你的判断，不是他的优先级。

推动跨团队的四步法

1. 找到共同目标，而不是共同任务

   不要说“请你改一下接口”，要说“我们都在为同一个大促的稳定性负责，现在这个链路是共同的单点”。任务是你的事，目标才是你们的事。

2. 降低对方的成本

   这是最关键、也最少人做的一步。你能不能把改动写好、测试跑通、文档备齐，让对方只需要点一次“合并”？你能不能承担联调和回归？推动的本质，是替对方减少麻烦，而不是增加说服。

3. 小步试点，先拿到一个成功

   不要一上来就要全量改造。先做一个不影响主流程的场景，跑出数据。有了第一个成功案例，第二个团队的说服成本会下降一半。

4. 公开归功，私下感谢

   事情成了，在群里、在汇报里明确说“这次是 X 团队帮我们顶住的”。你损失了一点功劳，换来的是下一次还有人愿意帮你。

先画一张利益相关者地图

在开口之前，花十分钟把相关的人列出来，按两个维度放：影响力（能不能决定这件事）和态度（支持 / 中立 / 反对）。

群发是最低效的推动方式

三种可以“借”的力量

好的反馈只有一个标准：对方听完知道下一步怎么做，且愿意去做。让人觉得被攻击的反馈，无论多正确，都是失败的反馈。

为什么反馈容易变成吵架

因为我们习惯把“行为”说成“人格”。

人格评价没有改进空间，行为才有。所以反馈的第一原则是：说具体的行为，不说抽象的标签。

SBI：一个足够好用的结构

SBI 把一句话拆成三段：情境（Situation）— 行为（Behavior）— 影响（Impact）。

【情境】昨天下午的需求评审会上，
【行为】当产品经理介绍方案时，你打断了三次，并且说“这个方案根本不可行”，
【影响】产品经理后来没有继续讲完，会议提前结束了，我们也没拿到结论。

我想听听你当时的想法。

注意最后一句。SBI 不是判决书，是一次邀请。你说完事实和影响，要把解释权交回给对方——因为你也可能漏掉了什么。

给反馈前，先问一句“可以吗”

这句话看起来多余，但它决定了对方是“打开”还是“防御”：

• “关于昨天的会，我有个观察，你想听吗？”
• “有个地方我觉得可以更好，现在说方便吗？”

对方说“可以”，等于签了一个心理契约：接下来他听到批评时，不容易立刻反弹。如果他说“等一下”，那就等——强行输出的反馈，效果通常是负的。

接受反馈：比给反馈更难

被指出问题时，人的第一反应是解释。但解释在对方听来就是辩护，辩护会让对方下次不再跟你说真话。

一个可以背下来的四步动作：

1. 不打断，听完

   哪怕你觉得事实有误，也先让对方说完。中途打断，你听到的永远是半句话。

2. 先谢，再问例子

   “谢谢你说这个，能举个具体例子吗？”——例子会把情绪化的评价变成可讨论的事实。

3. 承认你能承认的部分

   “会上我确实打断了他，这点是我的问题。”不需要全盘接受，承认一部分就足够让对话继续。

4. 说明你的判断，而不是辩解

   “不过我当时着急，是因为发现方案里有个数据一致性的漏洞。下次我会先记下来，等他说完再提。”

“谢谢你直接跟我说。
我想确认一下，你说的【具体行为】是指……对吗？
这部分我认，确实造成了【影响】。
我接下来会【具体改变】。你看这样行吗？”

Code Review 里的反馈语言

代码评审是工程师最高频的反馈场景，也是最容易伤人的地方——因为文字没有语气，一句陈述句会被读成质问。

再加两个小技巧：明确标注“阻塞 / 非阻塞”，让对方知道哪些必须改；多用“我们”“这个代码”而不是“你”，把矛头从人转向问题。

表扬也要具体

“干得不错”是一句社交辞令，对方听完不知道该继续保持什么。具体的表扬才有复制性：

“昨天线上故障，你在群里第一时间给出的是影响范围和临时方案，而不是一堆日志。这个动作让所有人都冷静下来了。”

这句话不仅让当事人知道什么行为被认可，也让在场其他人学到了标准。

冲突本身不是问题，回避冲突才是。被压下去的分歧不会消失，它会在上线前夜、在复盘会上、在绩效沟通里，以更贵的方式回来。

先分清：立场与利益

这是谈判学里最重要的一组概念，几乎能解释所有“谈不拢”：

• 立场是你要求的具体结果：“这个功能必须这周上线。”
• 利益是你真正在意的东西：“我怕大促时客服被投诉，影响我的考核。”

立场是对立的，利益往往可以兼容。两个人争一个窗户开不开，立场是“开”和“关”，利益可能是“我要新鲜空气”和“我怕风吹头”——最后方案是开另一扇窗。

五种冲突风格，没有一种永远正确

谈判前，先知道你的 BATNA

BATNA 是“谈不成时你的最佳替代方案”。它决定了你的底气，也决定了你的底线。

比如你在争取一个技术重构的排期：

• 如果谈不成，你能接受“只重构最关键的模块”吗？
• 如果还不行，你能接受“先加监控，等问题发生再处理”吗？
• 如果都不行，你会考虑换团队吗？

想清楚最差选项，你反而能更平静地谈——因为你知道自己不会被逼到墙角。没有 BATNA 的人，容易在谈判里要么过度强硬，要么全盘退让。

冲突升级的四个阶段，越早介入越便宜

1. 分歧

   观点不同，还能就事论事。此时最好的动作是：把双方假设写下来，对照事实。

2. 防卫

   开始解释自己、质疑对方动机。此时不要讲道理，先复述对方的观点，让他感到被听见。

3. 对抗

   出现“你总是”“你根本不懂”。此时应该暂停，改为一对一沟通，避免在群里或会上继续。

4. 破裂

   不再沟通，转为向上投诉或冷处理。此时需要第三方介入，重点不再是方案，而是修复关系。

道歉：不是认输，是修复

工作里的道歉，最容易犯的错是说“如果我让你不舒服，我道歉”——这不是道歉，是把责任推回给对方。

1. 承认事实：“昨天会上我打断了你三次。”
2. 承认影响：“这让你没能讲完方案，也让会议没有结论。”
3. 不找借口：“不管当时多着急，那不是打断你的理由。”
4. 给出改变：“下次我会先把问题记下来，等你说完再提。”

（不要加“但是”。）

案例：和产品经理争排期

你的老板通常同时管着 5–10 个人、几十件事。他不是不关心你，是没有带宽主动关心你。谁让他省心，谁就更容易拿到好机会。

老板真正需要你给的三样东西

三种汇报，别混在一起

最常见的错误，是把“求助”包装成“同步”：说了一堆困难，最后没说要他干什么。老板听完只能回一句“好的，你看着办”——然后事情继续卡着。

坏消息：早说、带方案、给选项

项目要延期，最糟糕的处理方式是拖到最后一刻说“实在做不完”。这时候老板已经没有腾挪空间了，他只能接受结果，并且记住“这个人不可靠”。

【结论】这个项目要延期 3 天，从周五到下周一下午。
【原因】联调时发现对方接口的字段定义和文档不一致，需要他们改一版。
【影响】不影响大促，但会压缩一天测试时间。
【选项】
  A. 砍掉导出功能，周五按时上线（推荐）
  B. 整体延到周一，功能完整
【建议】选 A，导出可以下个迭代补，风险最低。
【需要你】如果同意 A，我今天就去和产品对齐。

注意结构：结论在最前，选项在最后，建议只有一个。不要给老板五个选项让他自己选——那是把决策成本转嫁回去。你要做的是帮他缩小到两个，并明确推荐一个。

承诺管理：不要说“我尽快”

“尽快”“马上”“这周吧”这些词，在你嘴里是“我会努力”，在老板耳朵里是“他没有计划”。

给区间，比给一个乐观的数字更专业。因为区间传达的是：我评估过风险。

1:1 怎么开才不浪费

很多人把 1:1 开成“进度汇报”，那是最亏的用法——进度用文字同步就够了。1:1 应该用来谈那些不方便在群里说的事：

• 判断类：“下季度你觉得团队最该补的短板是什么？”
• 关系类：“上次那个方案我否得比较直接，你当时什么感受？”
• 发展类：“我想往技术负责人走，你觉得我现在最缺哪一块？”
• 对齐类：“我现在同时在做三件事，如果只能保两件，你希望我放掉哪个？”

最后一句尤其重要。它既帮你减负，也让老板明确你的优先级——不做的事，必须由他来确认，否则最后背锅的还是你。

晋升：别等述职才开始准备

晋升不是“我做了很多事”，而是“我已经在按下一级的标准工作，并且有证据”。证据需要平时积累：

1. 记录影响，而不是任务

   不要写“负责支付模块”，写“把支付失败率从 8% 降到 2%，每年减少约 X 万损失”。

2. 收集他人的话

   合作方的正面反馈、你在跨团队会议上的推动，都可以截图存档。到时候你不需要自夸，只需要引用。

3. 提前半年让老板知道

   “我想明年尝试晋升，你觉得我还差什么？”——这句话会让他在接下来的项目里，有意识地给你机会。

工程师的核心价值，不是把需求实现出来，而是在实现之前，判断这个需求值不值得做、有没有更便宜的做法。

症状不是问题

“客服每天被问 50 次订单到哪了”——这是症状。问题是“用户在下单后缺少可预期的物流信息”。

直接解症状，你会做一个“订单查询页面”；解问题，你可能会做一条发货短信，或者一个预计到达时间。后者成本更低，效果更好。

三个追问工具

工具一：连续追问“为什么”

不是问五次“为什么”就一定有答案，而是每次追问都要逼近可验证的事实：

• “为什么要导出？”——“要做月度分析。”
• “分析什么？”——“看哪些商品退款率高。”
• “现在怎么做的？”——“手工复制，一次要两小时。”
• “多久做一次？”——“每月一次。”

结论：一个月用一次、花两小时的事，可能不值得做一个完整的导出系统。一个定时邮件报表，成本低得多。

工具二：反事实提问

“如果这个功能明天上线，会发生什么？如果永远不做，又会怎样？”

这两个问题能迅速区分“想要”和“需要”。很多需求，永远不做的后果只是“有点不方便”；而有些小需求，不做的后果是“客户流失”。

工具三：把“做不了”翻译成约束

“做不了”是一句没有信息量的话。它背后通常是一个具体约束：

把“做不了”说成“在 X 约束下做不了，除非 Y”，你立刻从阻力变成了合作者。

用 JTBD 看需求：用户“雇”你的功能做什么

Jobs To Be Done 的核心是：用户不是买产品，是雇它来完成一个任务。

“加导出”这个需求，用户真正要完成的 job 可能是：

• 功能型：把数据搬到另一个系统里继续处理。
• 情感型：不想再手工复制，怕出错被领导骂。
• 社交型：想在月度会上拿出一张好看的报表。

三种 job，对应三种完全不同的方案。如果你只做“导出 CSV”，可能只满足了第一种。

定义成功：没有指标的需求，无法验收

在动手前，和需求方一起写下这句话：

“这个功能上线后，如果 ______ 从 ______ 变成 ______，就算成功。”

填不出来，说明这个需求还没想清楚。填得出来，后面所有的取舍都有了依据——包括砍功能。

案例：一个“简单”的需求

一个残酷的换算：把一件不重要的事从 80 分做到 95 分，不如把一件重要的事从 0 做到 60 分。

先判断：这个决定可逆吗

贝索斯把决策分成两类，这个分类能帮你省掉大量纠结：

大多数人的问题，是把 Type 2 当 Type 1 来纠结（一个变量名讨论半小时），又把 Type 1 当 Type 2 来草率（拍脑袋选了个数据库）。

优先级：用二维图代替感觉

如果非要打分，可以用一个粗糙但有效的公式：

RICE = (覆盖人数 × 影响程度 × 信心) ÷ 投入成本

覆盖人数：受影响用户/团队数（1–10）
影响程度：0.25 微小 / 0.5 一般 / 1 明显 / 2 极大 / 3 颠覆
信心：100% / 80% / 50%
投入：人日

例：(8 × 1 × 0.8) ÷ 5 = 1.28

RICE 的价值不在于算出精确数字，而在于逼你把“感觉重要”拆成四个可讨论的量。团队吵起来时，通常是因为有人在说影响，有人在说成本。

沉没成本：已经付出的，不构成继续的理由

“这个方案我们已经做了两个月了，现在换太可惜。”——两个月是沉没成本，它不会因为你继续投入而回来。

正确的问法只有一个：“如果今天从零开始，我还会选这个方案吗？”

如果答案是否定的，那么继续投入的每一天，都是在为过去的错误追加投资。

复盘：不是写检讨，是提取可复用的判断

大多数复盘会开成追责会，原因是问题问错了。不要问“谁的错”，要问“哪个环节的假设错了”。

1. 预期是什么

   上线前我们预计会发生什么？写下来，不要事后修改记忆。

2. 实际发生了什么

   只写事实和时间线，不写评价。

3. 差异在哪

   哪一部分和预期不一样？是量级不同，还是方向相反？

4. 为什么没预料到

   是信息不足、判断偏差，还是流程缺失？这一层要挖到系统性原因。

5. 什么可以复用

   下次遇到类似情况，哪个动作应该提前做？把它变成清单或自动化。

用区间表达不确定性

“这个大概要三天”是一个点估计，几乎一定不准。更专业的说法是：

“最乐观两天，最可能四天，如果第三方接口有问题可能要一周。我按四天排，第五天作为缓冲。”

区间不是不自信，是把风险显性化。老板要的从来不是“准确”，是“可预期”。

情绪不是需要被消灭的敌人，它是一套报警系统。问题不在于你有情绪，而在于你把警报当成了事实。

情绪 ABC：事件不决定反应，解释才决定

常见的认知偏差有三种，几乎构成了大部分内耗：

• 读心术：“他没回我消息，一定是对我有意见。”——事实可能只是他在开会。
• 灾难化：“这次汇报讲砸了，我的职业生涯完了。”——把一次事件放大成终身判决。
• 以偏概全：“这个 bug 我没查出来，我根本不适合做技术。”

打断它们的方法很朴素：问一句“证据是什么”。如果找不到证据，那它只是一个想法，不是事实。

反刍：越想越难受的循环

反刍和思考的区别是：思考会产出下一步动作，反刍只会产出更多反刍。

如果你已经在同一个场景里想了超过 20 分钟，还没有任何行动，那基本可以判定为反刍。三个打断方法：

冒名顶替综合征

“他们迟早会发现我其实什么都不懂。”——这句话，几乎每个认真做事的人都对自己说过。越往上走，越明显，因为你会越来越频繁地进入“不懂的领域”。

三个校准方法：

1. 区分“不懂”和“不行”

   不懂某个技术，是信息缺口；不行，是能力缺陷。前者可以补，后者需要证据。你有证据吗？

2. 记录“做成的事”

   开一个文档，只记别人感谢你、你解决了什么。低谷时翻一翻，比自我鼓励有用。

3. 把评价标准从“我懂多少”换成“我解决了什么”

   没有人要求你懂所有细节，大家要的是问题被解决。

精力管理，比时间管理更重要

你一天有 8 小时工作时间，但真正能写出好代码的可能只有 3 小时。把重要的事放在精力最好的时段，比延长工作时间有效得多。

还有一件事常被忽略：切换成本。被打断一次，平均需要 15 分钟才能回到原来的状态。所以保护一整块不被打扰的时间，比多工作两小时更有产出。

边界：不会说“不”，就会被默认“可以”

每次你默默接下不属于你的活，你都在训练别人：这件事可以交给他。等到你撑不住时，别人不会觉得你辛苦，只会觉得你“怎么突然不行了”。

“我现在手上在做 A（本周必须交付）和 B（大促相关）。
如果接 C，A 就要延到下周，你能接受吗？
或者我们看看 C 能不能拆小，我只做最紧急的那部分。”

关键不是拒绝，是把选择权交回去。你不是在说“我不干”，你是在说“资源有限，你来排优先级”。

倦怠的三个早期信号

• 情绪耗竭：还没开始工作就觉得累，周日晚上开始焦虑。
• 去人格化：开始用“就这样吧”“反正也没人在意”来描述工作。
• 效能感下降：以前能轻松搞定的事，现在觉得做不动，并且开始怀疑自己。

出现两个以上，不要靠“再撑一撑”解决。先减载，再谈恢复。倦怠不是意志力问题，是资源耗尽。

个人品牌不是包装，是让你的专业能力可被检索、可被转述、可被信任。它的最低标准是：有人遇到某类问题时，会第一个想到你。

职业叙事的三层结构

一个好的自我介绍，不是履历复述，而是三层递进：

【第一层：我做什么】
“我是做交易系统后端的，主要解决高并发下的数据一致性问题。”

【第二层：我擅长什么】
“过去两年我主导了三次大促的稳定性改造，比较擅长在不动主链路的前提下做渐进式重构。”

【第三层：证据】
“最近一次是把支付成功率从 92% 提到 97%，写成了内部文档，现在有三个团队在用。”

三层缺一不可：只有第一层，你是岗位说明书；只有第二层，你是自我评价；只有第三层，你是流水账。三层合起来，才是一个可以被转述的“人设”——注意，这里的“人设”是褒义，指别人能准确复述你的价值。

三种可以积累的资产

把经历写成“影响”，而不是“职责”

这是简历和晋升材料里最常见的问题。看两组对比：

S（情境）：大促前订单库成为瓶颈，单表 8000 万行，查询超时。
T（任务）：在不停止业务的前提下完成拆分，保证大促稳定。
A（行动）：按业务域拆库，做双写迁移，灰度 3 个业务方，回滚预案演练 2 次。
R（结果）：P99 1.2s → 240ms，大促零故障，方案被另外 2 个团队复用。

如果实在没有数字，就用范围和对比：“原来需要 3 个人做一周，现在 1 个人半天”“从 0 到 1 搭建”“被 3 个团队采用”。

最小可持续的输出节奏

很多人一想到个人品牌，就想到“要写公众号”“要做视频”，然后坚持两周就放弃。更现实的做法是把输出嵌入工作：

弱连接：机会通常来自不熟的人

社会学里有个反复被验证的结论：人们的工作机会，更多来自弱连接（不常联系的人），而不是强连接（天天见面的同事）。因为强连接和你的信息高度重叠，弱连接才连接着不同的圈子。

维护弱连接的成本很低：

• 看到对方领域的好文章，转过去附一句“想到你之前在做的项目”。
• 对方发了新项目，点个赞，说一句具体的认可。
• 一年一次，简单同步一下你在做什么。

不需要刻意经营，只需要不要断联。

关系不是资源清单，是长期的小额存款。平时不存，急用时取不出来。

关系的三种“存款”

怎么找导师：不要问“能当我导师吗”

这句话门槛太高，对方很难答应——因为它意味着长期承诺。更有效的做法是一次一个具体问题：

聊完之后，做三件事：当天发感谢（提到具体哪句话有用）、一周后同步进展（让他知道建议生效了）、三个月后再联系（带着新的问题或结果）。

绝大多数人只做第一件。做到第三件的人，会慢慢拥有真正的导师关系。

怎么成为别人的资源

关系是双向的。如果你只索取，再好的技巧也会耗尽。三个可以主动提供的价值：

• 做连接者：“你说的这个问题，我认识一个做过的人，要不要我拉个群？”
• 做翻译者：帮非技术的人理解技术，帮技术的人理解业务。这个位置天然稀缺。
• 做记录者：把一次讨论整理成清晰的纪要，发给所有参与者。成本低，记忆点强。

案例：一条没有回音的求助

一位读者给我看过他的消息记录。他给一位资深架构师发了这样一段话：

“您好，我是 XX 部门的小李。我最近在做服务拆分，遇到了一些问题，想请教您。不知道您什么时候方便？”

消息已读，没有回复。他得出的结论是“大牛都很冷漠”。

但问题不在对方。这条消息里有三个致命的信息缺失：不知道要花多久、不知道要解决什么、不知道拒绝了会怎样。对方要回复，就得先反问三个问题——而他一天可能收到十条这样的消息。

改成下面这样，回复率会完全不同：

“张老师，我们在做订单库拆分，卡在灰度这一步：
老库和新库双写时，有一批历史订单的状态对不上。
我看了您之前分享的迁移方案，里面提到用对账任务兜底，
想确认一下：这个对账是按天跑还是按小时跑？会不会有漏单？

如果方便，20 分钟就够。我把现状和两次失败的尝试整理成了一页文档：
【链接】。如果不方便也完全理解，我再自己查查。”

差别不在于礼貌，而在于你把对方的决策成本降到了最低：他只需要判断“这个问题我能不能答”，而不是“我要不要开始一段未知长度的对话”。

关系不是越多越好

有一个反直觉的结论：真正能在关键时刻帮你的，通常不是通讯录里那 500 个人，而是10 个左右“知道你在做什么、也愿意为你说句话”的人。

所以与其到处加微信，不如定期问自己三个问题：

• 过去半年，我帮过谁一个具体的忙？
• 有谁在我遇到问题时，会愿意花 20 分钟？
• 如果我要换一个方向，有几个人能给我真实的信息，而不是客套的鼓励？

这三个问题的答案，才是你的网络，而不是好友数量。

结构洞：连接两个不相通的圈子

社会网络研究里有个概念叫“结构洞”：两个群体之间如果没有连接，站在中间的人就拥有信息优势。

在公司里，这个位置通常是：既懂业务又懂技术的人、既在研发又和客服熟的人、既做后端又参与前端方案的人。

你不需要成为每个领域的专家，只需要成为两个领域之间那个“说得上话”的人。

一对一咖啡：最低成本的深度连接

比群聊、大会更有效的关系建立方式，是两个人聊 30 分钟。不用刻意，一句邀请就够：

“我最近在做 X，看到你们团队在做 Y，感觉有些地方可以互相借鉴。
要不要找个 30 分钟聊聊？我请你喝咖啡。
我这边想请教的是：你们当时怎么解决 Z 的？”

三个要素：说明为什么找你、给出明确时长、带一个具体问题。有具体问题，对方就不会觉得这是一次尴尬的社交。

技术学习容易产生“我懂了”的错觉，因为看懂代码不等于能写出来。软技能更麻烦：听懂道理不等于做得到，必须在真实情境里练。

三个区：你该站在哪

大多数人的问题不是不努力，是一直待在舒适区里重复：用熟悉的框架做熟悉的业务，写熟悉的代码。十年经验，可能只是一年经验重复了十次。

刻意练习的四个条件

“多练”不等于“刻意练习”。真正的刻意练习，必须同时满足：

1. 有明确的小目标

   不是“提升架构能力”，而是“这次能把一个单体拆成两个服务，并保证零停机”。

2. 难度在边缘

   比当前能力高 10%–20%。太简单没成长，太难会放弃。

3. 有即时反馈

   代码有测试和 review，演讲有录像，写作有读者。没有反馈的练习，是在固化错误。

4. 针对子技能

   把“沟通能力”拆成：结构化表达、提问、处理异议。一次只练一个。

费曼技巧：用“讲给外行听”检验理解

四步，任何概念都能用：

• 选一个概念，写在纸顶。
• 用不含术语的语言解释它，像讲给一个非技术朋友。
• 卡住的地方，就是你没真懂的地方，回去补。
• 再简化一遍，直到能用一句类比说清。

比如“为什么需要消息队列”，术语版是“解耦、削峰、异步”；费曼版是“下单的人不用等仓库打包完才走，先把单子放进传送带，仓库慢慢处理”。后者才是真懂。

知识管理：输入—加工—输出

只输入不加工，等于把别人的书架搬进自己家，一本没读。一个最小可运行的循环：

判断有没有学会，只有一个标准：你能不能在没人提示的情况下，把它用出来。

从“会做”到“会教”：迁移的分水岭

会做一件事，是掌握了步骤；会教一件事，是理解了为什么这些步骤有效、在什么条件下失效。

教别人有三个额外好处：

• 逼你把隐性经验显性化，发现自己其实没想清楚的地方。
• 建立“专家”身份，这是最自然的影响力来源。
• 你会收到问题，而问题会带你去补知识的洞。

所以最好的学习方式，是学完立刻讲一次：团队分享、写一篇短文、带一个新人。

案例：20 小时，把“不敢提反对意见”练成“能提”

“在会上提反对意见”听起来是一个能力，其实至少是四个子技能：

如果只练“勇气”，你会一直在原地打转。正确的练法是把它拆开，一次只练一个：

1. 第 1 周：只练“组织”

   每次开会前，写一句“我担心 X 场景下会 Y，建议 Z”。不发言，只写。目标是能在 30 秒内写完。

2. 第 2 周：只练“时机”

   在低风险的小会上，等对方说完后接一句：“我补充一个风险。”只做这一个动作。

3. 第 3 周：只练“承受”

   被反驳时，不回击，只说：“这个角度我没考虑到，我回去验证一下。”观察对方的反应，通常没有你想象的那么糟。

4. 第 4 周：组合

   在一次正式评审上完整做一次：判断、组织、选时机、接住反应。会后问一个信任的同事：“我刚才那句话，听起来怎么样？”

20 小时不会让你变成谈判专家，但足以让你从“心跳加速、说不出口”变成“能平静地说完一句话”。软实力就是这样长出来的：不是想通了，是做过了。

T 型与第二曲线

早期要深，先有一根足够长的竖线——那是你的立身之本。没有深度，广度只是浮于表面。

但到了某个阶段，单一技能的边际收益会下降。这时候需要第二曲线：用你的深度去连接另一个领域，比如技术 + 业务、技术 + 管理、技术 + 产品。

注意，第二曲线不是“转行”，是叠加。你的第一技能不会浪费，它会让你在新领域里有一个别人没有的视角。

所有模型都只是脚手架。真正重要的是：在正确的场景，想起正确的那个。

建议按顺序做。每周只聚焦一个主题，周末复盘一次。如果某天没做，跳过即可，不要从头再来。