学不会、看不懂、无法评价：为什么人会开始否定复杂系统？
从利润模型出发，讨论职场中一种常见的判断路径：当理解能力暂时跟不上系统复杂度时，人为什么容易把‘我还没看懂’转换成‘它没必要、太复杂’。
本文目录 6 节 · 点击展开
有一种职场现象很有意思。
一个人面对自己暂时理解不了的复杂系统时，未必会直接说“这个我还没看懂”。更常见的情况，是评价逐渐发生变化：
真正值得观察的，不是“有人没学会”。
任何复杂系统都有学习门槛，暂时看不懂很正常。问题出现在下一步：当一个人无法判断系统本身是否正确时，为了继续维持“我能够判断这件事”的感觉，评价标准可能会悄悄从“它对不对”，变成“它为什么要搞这么复杂”。
于是，“我还没理解”被转换成了“它没有价值”。
最容易发生偷换的，是“我看不懂”和“它没必要”
面对一个熟悉的东西，我们通常可以直接讨论内容。
这个公式错在哪里？这个流程有没有重复？这个字段是不是算了两遍？这个规则删除以后会不会影响结果？
这些都属于真正的评价。
但面对一个完全看不懂的系统，人其实很难做这种评价。因为连输入、处理过程和输出之间的关系都没有建立起来，自然也就很难指出具体哪一部分有问题。
这时候，最省力的办法不是继续进入系统，而是站到系统外面评价它：
这些话当然不一定错。系统确实可能被过度设计。
但它们有一个共同特点：不需要理解系统内部，就可以说出口。
所以判断一句“太复杂了”有没有价值，关键不是看语气，而是看后面能不能接着回答：
哪一层复杂度是不必要的？删掉以后，结果为什么仍然成立？
如果回答不了，很多时候它表达的并不是系统的问题，而只是评价者暂时还没有进入系统。
利润模型为什么特别容易出现这种冲突
利润模型是一个很典型的例子。
最简单的利润公式人人都能看懂：
利润 = 销售额 - 采购成本问题是，真实业务通常并不只发生这两笔钱。
如果一个商品卖出去以后还会退款，有广告费、物流费、后勤成本、平台扣点、售后损耗、税费、费用分摊，不同数据又来自不同时间窗口，那么一个真正能够用于经营判断的利润模型，必然会比这条基础算式复杂得多。
- 容易理解
- 容易计算
- 但大量真实成本没有进入
- 需要更多字段和中间结果
- 每一步都应该能解释来源
- 复杂度来自真实业务，而不是公式数量
比如，退款不能只说“有退款”就结束。
要先判断使用金额退款率还是件数退款率；采购成本是否应该随着预计退货件数变化；已经发生的快递费是不是退款以后就能消失；广告费到底属于链接、SPU 还是 SKU；含税金额和未税金额能不能直接混在一起。
这些问题每增加一个，模型都会多一层计算。
但如果这些问题真实存在，那么把它们删掉，并没有让模型“更先进地变简单”，只是让它少算了一部分现实。
这也是复杂系统最容易被误判的地方：
省略问题得到的简单，和解决问题之后得到的清晰，不是同一种简单。
复杂并不自动等于合理
反过来，也不能因为一个系统很复杂，就默认它一定高级。
真正有价值的判断，是先区分三种完全不同的复杂度。
业务本身就存在退款、税费、分摊、时间窗口和不同成本性质。删除这些规则，结果会直接失真。
业务虽然复杂，但可以通过事实层、计算层、展示层，把输入、计算和结果整理得更清楚。
重复计算、口径混乱、互相嵌套、字段含义不明、一个数字没人能追溯来源。这才是真正需要被消灭的复杂。
所以，真正专业的质疑从来不是一句“为什么搞这么复杂”。
而是：
- 这个复杂度对应了什么真实问题？
- 如果删掉这一层，会具体损失什么信息？
- 有没有更简单的实现方式，但仍然保持同样的正确性？
- 最终结果能不能从原始事实一路追溯回来？
能回答这些问题，才是在评价系统。
当无法评价内容时，人很容易开始评价形式
这条路径在职场里并不少见。
看得懂的人，通常会讨论字段、规则、口径、边界和结果。
看不懂但愿意继续理解的人，会问：“这一项为什么这么算？”
真正麻烦的是第三种状态：既没有进入系统，又不愿意承认自己暂时没有评价能力。
这时候评价就很容易从内容转向形式：字段太多、步骤太长、页面太复杂、做这个的人是不是想把事情搞高级。
因为评价形式不需要证明。
而评价内容需要。
指出哪一步错、为什么错、删掉或修改以后结果如何变化。
“太复杂”“没必要”“以前也能用”，不需要先证明具体哪里有问题。
这并不是说所有质疑复杂度的人都在逃避学习。
相反，一个成熟系统本来就应该主动降低理解成本。能用三层讲清楚，就不要写成十层；能把字段命名清楚，就不要靠记忆；能把中间结果展示出来，就不要把所有公式藏在一格里。
设计系统的人有责任减少坏复杂度，使用系统的人也有责任区分“系统真的乱”和“自己还没理解”。
两边都不能把责任推给对方。
真正的“简单”，不是一眼就能看完
很多人对“简单”的理解，是步骤少、公式短、字段少。
但复杂业务里，更有价值的简单往往不是这个意思。
它应该是：
原始事实是什么
↓
经过了什么计算
↓
为什么这样计算
↓
最后得到什么结果即使中间有几十个字段，只要这条链路能够被追踪、验证和重算，它仍然可以是一个清楚的系统。
反过来，一张表可能只有三条公式，但谁也说不清数字从哪里来、换个日期为什么结果变了、一个退款到底扣了几次——它看起来简单，实际才是真正的复杂。
看不懂不是问题，把看不懂变成否定才是
所以我越来越觉得，面对复杂系统时，一个很重要的能力不是“什么都能马上看懂”，而是能够准确判断自己现在处在哪一步。
是系统本身真的设计得差？
还是业务天然就复杂？
还是我暂时还没有建立起理解它所需要的知识结构？
这三个答案，对后续行动完全不同。
真正的问题从来不是“不懂”。承认暂时不懂，仍然可以继续学习、提问和验证。真正让认知停止的，是在还没有评价能力之前，就先给评价对象下结论。
复杂不值得崇拜。
但同样，不能因为自己暂时还没进入一个系统，就把理解门槛误判成系统没有价值。