同一个方案，两个人给出的意见截然相反。一个说"这个方案成熟，很多公司在用"，另一个说"在我们的数据量下它会先崩"。前者说得对但没用，后者说了具体条件。三年后回看，前者换了三家公司在说同样的话，后者成了团队里被追问细节最多的那个人。
技术判断力的差别不在知识量，而在结论是否附带条件。"这个好"与"在我们的场景下、这些前提成立时、这个更好"是两种完全不同的话，前者无法被验证，后者可以被推翻——而只有能被推翻的判断才有价值。
1. 判断力的四个层级
| 层级 | 表现 | 能否被验证 |
|---|---|---|
| 复述结论 | "用 X 就行，大家都在用" | 否 |
| 说出理由 | "因为 X 的性能好" | 部分（理由可能不适用） |
| 给出条件 | "在 A、B 成立时 X 更好" | 是 |
| 给出失效信号 | "如果出现 C，就说明选错了" | 是，且可提前发现 |
这四层的实际分布很极端：大部分讨论停留在第一、二层，因为前两层不需要承担被推翻的风险。说出"什么情况算我错"，等于主动交出了判断的免责，这在组织里需要一点安全感。
第四层才是完整形态。它把判断从"一次性的决定"变成"可监控的假设"——你不仅说了什么对，还说了什么情况下它不再对。
2. 结论为什么容易脱离条件
| 原因 | 机制 |
|---|---|
| 二手信息压缩 | 转述时丢了前提，只留结论 |
| 场景不可见的传播 | 别人的量级与你差三个数量级 |
| 时间衰减 | 结论在写下的那天成立，之后环境变了 |
| 成功案例偏差 | 失败的那批不会写文章 |
第二项最致命："某公司用了这个方案"这句话里，最有信息量的部分是他们没说的——他们的数据量、团队规模、演进阶段。拿这些去套自己的场景，等于用别人的答案答自己的题。
第三项（时间衰减）值得单独说：一个结论的有效期通常短于它在文档里的寿命。三年前写的选型理由，当年的前提（数据量、团队规模、依赖版本）都已变化，但文档还在，后来的人读到它时无法判断哪些前提已经失效。
第四项解释了为什么技术圈的观点看起来总在摇摆：写出来的案例大多成功，失败的沉默，于是每个方案在传播中都显得比实际更可靠。
3. 一个可复用的判断结构
| 要素 | 回答什么 | 例子 |
|---|---|---|
| 前提 | 在什么条件下成立 | 数据量在千万级以内、单机可承载 |
| 代价 | 用了它要付出什么 | 运维复杂度上升、需要额外监控 |
| 失效信号 | 什么现象说明选错了 | 单表超过两千万行、写入延迟上升 |
| 可逆性 | 错了能不能退 | 可以从双写退回，代价一天 |
这四个要素可以写成一个很小的模板，成本远低于写一份设计文档：
// 判断卡：四行，写下来就比只在脑子里强
decision: 用 Redis 作为商品详情缓存
premise:
- 读远多于写（读写比 > 20:1）
- 可接受 5 秒内的不一致
cost:
- 多一套需运维的组件
- 需要处理穿透与雪崩
invalidate_when:
- 商品详情需要与库存强一致
- 单键超过 100KB 或热键占比 > 30%
reversible: 关缓存直连库，代价为延迟上升约 3 倍
invalidate_when 这一栏是最有价值的部分：它同时是监控指标的定义来源。
四个要素里，失效信号最难写，也最能区分判断力。写得出失效信号，说明你真正想过它在什么情况下不成立；写不出，说明这个判断还停在"听起来合理"。
// 三种说法的差别，同一件事
A：用 Redis 做缓存就行。
B：用 Redis 做缓存，因为它比数据库快。
C：用 Redis 做缓存，前提是读多写少且能接受短暂不一致；
代价是多一套需要运维的组件；
如果出现"缓存与库对不上且业务不能容忍"，说明该换成读副本或强一致方案；
可逆：关掉缓存直连数据库即可，代价是延迟上升。
C 与 B 的差别不是字数，而是B 无法被人用事实推翻，C 可以。
4. 判断力的三个训练方式
| 方式 | 做法 | 训练什么 |
|---|---|---|
| 复盘预测 | 事前写下判断与失效信号，事后对照 | 判断准确率 |
| 反方论证 | 为自己的方案写最强反驳 | 找出被忽略的前提 |
| 条件迁移 | 把别人的结论追问出前提 | 识别二手信息缺失 |
可以让这件事变成习惯的最低成本形态：每次技术决定留一行预测，写在决策记录或变更单里，注明复查时间。
// 一行预测，成本极低，收益是半年后的自我校准
预测：启用读写分离后，报表查询 P99 从 4s 降到 1s 以内
复查：2027-01 之前回看
失效：若 P99 仍在 2s 以上，说明瓶颈不在主库竞争
第一项最简单也最有效：在事情发生前写下"我认为会怎样，如果出现什么就说明我错了"。半年后对照，你会发现自己系统性地在某一类判断上偏乐观——这是任何课程都教不了的自我校准。
第二项有个具体做法：把方案交给一个不熟悉它的人，让他只挑毛病。自己写反驳容易手软，因为你知道每个反驳的答案。
5. 什么时候直觉够用
| 场景 | 是否需要显式判断 |
|---|---|
| 已有明确规范的操作 | 否 |
| 可逆且代价极小的改动 | 否 |
| 不可逆或影响面大 | 是 |
| 涉及多方的取舍 | 是 |
| 与既往做法冲突 | 是 |
直觉是压缩过的经验，它在熟悉的场景里效率极高。判断力不是"每次都从头推导"，而是知道哪些场合不能只靠直觉。
// 三问决定要不要展开成完整判断
1. 错了能不能改回来？ 否 → 展开
2. 影响面是否跨团队？ 是 → 展开
3. 是否与团队既有做法冲突？是 → 展开
全否 → 直接用直觉，节省时间
6. 排错：五种"判断看起来对但没用"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 讨论变成立场之争 | 双方都没给失效信号 | 要求各自写出"什么情况算我错" |
| 结论半年后不适用 | 前提变了但没人重估 | 在方案里记录前提与重估时间 |
| 引用别人的案例被反驳 | 场景差异未被识别 | 追问量级、团队、阶段 |
| 评审通过但落地失败 | 组织前提未纳入判断 | 判断里加上"谁维护" |
| 判断正确但没人采纳 | 只有结论没有路径 | 补上代价与可逆性 |
还有一种常见现象值得区分：判断正确但被否决，与判断错误被采纳，两者的复盘价值完全不同。前者需要改的是表达与利益相关方的对齐，后者需要改的是判断依据。把两者混在一起复盘，通常得出"沟通很重要"这种无行动价值的结论。
第五项是沟通问题而不是判断问题，但它常被误认为判断力不足。一个正确的判断如果没说清代价，听的人无法评估风险，只能选择不做。
判断力还有一层与"敢说不知道"有关的能力：能明确区分"我知道"与"我推断"。前者有证据，后者有条件；把它们混着说，会让听的人无法分配信任权重。一个常见的失败是：用"我推断"的语气讲了十分钟，最后被当成"我知道"采纳了。
// 三种确信度的表达，混用会导致误采纳
已知：我读过这个版本的源码，行为是这样的。
推断：基于文档描述，我推断它会这样，但没验证。
未知：这一块我不清楚，需要一次最小验证。
// 说出第三种最难，但它决定了别人会不会做重复劳动
7. 边界：什么情况不必追求完整判断
| 场景 | 为什么 | 做法 |
|---|---|---|
| 试验性探索 | 结论本来就会变 | 只记假设，不写完整论证 |
| 有明确标准答案的问题 | 无需取舍 | 查规范 |
| 时间极紧的应急 | 先处置后复盘 | 决策留痕，事后补判断 |
| 个人范围内的选择 | 影响面小 | 凭经验即可 |
判断口径一句话：这个判断会不会被别人用来做另一个决定。会，它就必须附带条件与失效信号；不会，它只是你自己的思考过程。
8. 自测
- 四个层级中，哪一层才算完整形态？它比"给出条件"多做了什么？
- 为什么"某公司用了这个方案"这句话里最有信息量的部分往往没说？
- 判断结构的四个要素是什么？哪一个最难写、也最能区分判断力？
- 为什么"事前写下判断与失效信号"比其他训练方式更有效？
- 直觉在什么场合够用？三问的判据分别是什么？
- 一个正确的判断因为没写代价而未被采纳，这属于判断问题还是沟通问题？为什么容易混淆？