LOOKS RIGHT / PERFORMANCE VS QUALITY10 SEP 2026
我搭了一套精密的测量
而答案就在一行命令里
这一篇讲我自己前两天犯的一个错。
人会把「方法的表演强度」,当成「方法的真实质量」。而这两者经常是反着的——越是需要精密测量才能回答的问题,往往越说明你还没找到那个能一步回答它的变量。
OPTICS 01 复杂感·完整感·专业感 |
ONE STEP 02 关键变量能否一步拿到 |
EXCEPT 03 构造题除外 |
错误本身不值钱,但它的形状值钱——因为它是一类非常体面、非常不容易被自己抓住的错。
LOOKS RIGHT / 01
一、事情经过
我要判断一件事:一套系统能不能同时扛住十个任务并行。
我做了什么?
我写了一个后台采样器,每隔几秒记录一次进程数和内存占用,跑了两分钟,收了四十个样本,然后准备用这些数据算出结论。
看起来很像回事。有数据、有时间序列、有峰值。
结果:采样窗口和实际发生的时间错开了整整八分钟。四十个样本,一个都没采到我要测的东西。全废。
LOOKS RIGHT / 02
二、而正确的做法是什么
读一遍调度代码,看它有没有全局锁、有没有队列。
一条命令的事。
如果代码里根本没有任何串行化机制,那答案立刻就有了——架构上就是并行的,不需要测。剩下的只是资源够不够,而那是一道算术题。
我花了两分钟采样、外加后续的排查时间,去回答一个一分钟能读出来的问题。
而且还答错了。
LOOKS RIGHT / 03
三、为什么会这样
不是因为懒,恰恰相反——是因为「认真」。
人天然会被三样东西打动:
这三样都是外观。而人很容易犯一个错:
把方法的表演强度,当成方法的真实质量。
搭一个采样器,比敲一行 grep 显得认真得多。而「显得认真」这件事,对我有吸引力——哪怕它没有让答案更准。
LOOKS RIGHT / 04
四、一个反直觉的推论
越是需要精密测量才能回答的问题,越说明你可能还没找到关键变量。
因为真正的关键变量,通常有一个特征:它能被直接观察到。
而当你发现自己在设计实验、搭建工具、收集样本时,先停一下问:
一个问题就够
这道题的关键变量,能不能一步拿到?
能 → 就一步拿,别搭东西。
不能 → 再考虑要不要上复杂手段。
顺序不能反。 我那次就是反了:先决定要"好好测一测",才去想测什么。
LOOKS RIGHT / 05
五、必须挡住的误读:这不是在说「简单总是对的」
有些场合,复杂就是必须的:
—不可逆的动作(签下去就改不了的条款、转出去就追不回的钱)—精度直接决定成败(工程参数、税务结构、法律条款)—构造问题——不是从选项里挑一个,而是要设计出一个东西
这些地方追求简单,才是真的危险。
所以判据不是「简单 vs 复杂」,而是:
这是一道筛选题,还是一道构造题?
>
筛选题——从一堆里排掉不行的——关键变量往往一步可得,别搭复杂分析。
构造题——要造出一个能用的东西——该复杂就复杂,别用「抓关键」把它简化掉。
LOOKS RIGHT / 06
六、这个错最难被自己抓住的地方
因为它带着证据出场。
如果我什么都没做就下结论,我会心虚。而我搭了采样器、收了数据、画得出曲线——我会觉得自己做得很扎实。
一个用错方法但过程漂亮的判断,比一个没做功课的判断更难被推翻——因为它自带说服力,首先说服的是你自己。
LOOKS RIGHT / 07
七、收口
—我花了大力气测量一个可以直接读出来的东西,还测错了—复杂感、完整感、专业感——这三样是外观,不是质量
下次你准备「好好研究一下」之前,先花十秒问问:我要的答案,是不是就在手边?
本篇为个人认知笔记,只做思维方法层面的讨论,不构成任何投资建议。文中案例为笔者亲历,已隐去全部系统与项目信息;「筛选题/构造题」的划分与判据为笔者自拟,读者请自行判断其适用范围。