为什么很多问题越优化越糟糕
很多问题越优化越糟糕，这种事你在生活里肯定见过。甚至不用特意去找案例，随便翻翻工作群、看看热搜，就能抓出一把。
上一部分我们聊了什么是系统——它不是一堆东西随便摆在一起，有要素、有关系、有目的、有边界、有反馈，还会出现单个部件加起来根本无法解释的整体行为。
简单说，一个真正的系统，一定有活的连接、清晰的意图、明确的内外分野，以及一套持续运转的反馈机制。
既然系统是这样的，那问题就来了：为什么我们明明在努力优化，最后反而把事情搞得更糟？
这种事在现实里，简直多到让人叹气。
学校想提高学习效率，作业就越加越多，学生越来越累，眼睛里的光也越来越暗。
公司想提高协作效率，流程越改越密，大家却越来越不敢自己做决定，什么都要走审批。
平台想提高用户停留时长，推荐算法越做越精准，用户越刷越空虚，刷完甚至想打自己两下。
城市想缓解交通拥堵，道路越修越宽，车却越来越多。
产品想减少用户投诉，客服话术越写越完整，用户听完火气反而越来越大。
到最后，就会出现一种非常荒诞的局面：每一个动作看起来都在解决问题，但系统整体却在稳定地恶化。
这就好比你手机卡了，于是装了个清理软件。清理软件说你后台应用太多，你就再装个管理后台的软件。
管理后台的软件说你内存不够，你又装了个加速器。一通操作之后，手机确实不寂寞了——后台常驻三位大将，电量掉得比打工人的精气神还快。
很多问题越优化越糟糕，根子就在这里。
你动手改的是一个点，但真正运行的是一个系统。
你动的是局部，反馈的是整体。
你盯着的是指标，响应的是关系。
你关心的是当下效果，系统却会把这个动作带到未来，然后不紧不慢地给你演一出大型连续剧。
第一种翻车姿势，是把指标当成了目标。
这种事在职场上太常见了，常见到几乎每个人都能在自己的周报里找到影子。
指标本来只是帮我们理解系统的一扇窗。透过这扇窗，你能看到大致情况，但不代表窗户就等于整栋房子。
可问题在于，窗户看久了，大家就开始对着窗户搞装修，不再关心房子里到底在发生什么。
教育就是个典型。分数当然重要，完全不看分数也不现实。
但一旦分数变成唯一的目标，整个教育系统就会自动朝着刷题、押题、排名、压缩一切探索空间的方向滑下去。
学生更会考试了，老师更会抓重点了，学校更会包装成绩了。
至于好奇心、表达力、面对复杂问题的耐心，这些不好量化的东西，就安安静静地缩在角落里，像极了会议上从来没被点到名字的人。
公司里也一样。管理者想提高投入度，就开始盯在线时长、打卡时间、任务数量。
结果你猜怎么着？员工很快学会了另一套生存技能：电脑保持在线，文档保持打开，会议保持参加，群消息保持秒回。
看起来人人都在忙，系统热闹得像菜市场，真正推进的事情却没几件。赛博牛马的精髓，就是人在工位，魂在旷野。
这种现象有个很著名的说法，叫古德哈特定律，大概意思是：当一个指标变成了目标，它就不再是个好指标了。这句话放在系统工程里，简直是救命级别的提醒。
指标本身没有错，错的是你把它从系统里单独拎出来，然后逼着所有人围着它跳舞。
产品只看日活，结局就是疯狂推送。
内容平台只看停留时长，结局就是把用户往情绪刺激里推。
客服中心只看平均处理时长，结局就是把复杂问题迅速关单，管它解没解决。
所有人都在优化，所有人都在交差，图表确实变好看了。
然后用户体验裂开，长期信任下降，系统维护成本暴涨。
指标赢了，目标死了。
第二种，是只盯着局部效率，根本不管整体代价。
局部效率谁都看得见，让某一段流程更快，某一个部门产出更多，某一个模块性能更强。听起来很合理，现实里也经常需要这样干。但系统的问题是，局部的压力不会凭空消失，它只会转移。
医院为了提高门诊效率，挂号更快了，医生接诊也更快了，前台数字漂漂亮亮。
可如果检查、缴费、取药这些环节没同步跟上，拥堵就从候诊区搬到了检查区，又从检查区搬到了药房。
病人的总等待时间未必减少，只是排队的地点换了个皮肤。
软件开发里就更常见了。
前端团队为了赶进度，先把页面做出来，演示的时候特别顺，客户频频点头。
可后端接口还没完全稳定，测试用例还没补齐，权限系统还没接好，日志也没有统一。
短期看进度快了，长期看，所有的风险全挤到了联调、测试和上线阶段，最后大家在深夜的办公室里，深度体验“今晚谁也别睡”的团建氛围。
这种优化最迷惑人的地方，就是它确实让一个局部变好了，但没有让系统变好。
像一条生产线，某个工位速度翻倍，如果下游接不住，库存就堆起来了，管理成本也跟着涨。
单点快了，整体慢了。前端漂亮了，后端爆炸了。每个局部都在报喜，系统整体在报丧。
还有一种情况，是没看见反馈回路。
系统不是死的，你改变它，它也会反过来改变人的行为。
交通就是最直观的例子。
一堵车，人的第一反应就是修路。
路不够宽？拓宽。车太多？加车道。
这个想法特别符合直觉，也特别容易得到支持——毕竟堵在路上的人，很少会说“少修路，多研究系统反馈”，只会暴躁地想，前面那辆车到底在干嘛。
但交通系统有个很麻烦的地方：路变宽了，开车的时间成本就降下来了。原本不开车的人可能开始开车了，原本错峰出行的人回到了高峰期，原本住得远的人也能接受更长的通勤距离了。
短期看，拥堵缓解了；长期看，车流增加了，路又堵回去了。
交通研究里管这叫“诱导需求”，说的是新增道路容量会降低驾驶的时间成本，从而诱发更多驾驶需求，把扩容缓堵的效果抵消得干干净净。
这就很像减肥的逻辑：今天运动了，多吃一点没事。然后运动消耗了三百卡，奶茶补回八百卡。身体沉默，体重微笑。
反馈回路的可怕之处，就是它会让直觉上特别好的办法，在更长时间里慢慢失效。你提高了效率，需求可能跟着增长。你降低了成本，使用量可能跟着上涨。你加强了考核，大家就开始研究考核本身。你强化了推荐，用户就被困在越来越窄的信息回音壁里，越刷越累。
经济学和技术史里有个相关的概念叫杰文斯悖论，说的是技术提高了资源使用效率之后，总消耗量反而可能增加，因为使用成本下降刺激了更多需求。
放到今天的AI领域也很有意思：模型推理越来越便宜，大家未必会少用算力，反而会把AI塞进更多场景。原来只让它写总结，现在让它写代码、做客服、跑流程、分析日志，甚至评价自己写的周报。
效率提升的结果，是总调用量飙升，总算力消耗继续往上走。
所以，优化不能只看第一层效果。
第一层，成本下降了。
第二层，使用增加了。
第三层，系统规模变大了。
第四层，新的瓶颈出现了。
第五层，原来的优化开始制造新问题。
很多人只看到第一层就开香槟了，系统通常等到第五层才来敲门，敲门的方式也很朴素：要么成本炸了，要么体验崩了，要么维护人员集体沉默了。
第四种，是激励设计把人带进了沟里。
系统里最活跃的要素永远是人。人会响应规则，会适应指标，会寻找路径，会在压力下发明各种神奇操作。
所以，只要你设计了激励，就要准备好面对人类的创造力。
别小看任何人在完成考核这件事上的聪明程度——只要规则有洞，一定有人发现。
只要指标有空子，一定有人研究。
只要奖励足够明确，行为就会朝着奖励飞奔过去，原来的目标还在不在，另说。
现实里这种事一抓一大把：平台奖励发帖数量，水帖就变多。公司奖励销售签单，后端交付就被压爆。学校奖励论文数量，灌水和拼接就层出不穷。客服考核解决率，复杂问题就被快速关闭。开发考核需求数量，小修小补就比系统重构更受欢迎。
最后，系统会出现一种非常荒诞的自洽：规则说什么，人就优化什么。你奖励表演，系统就生产表演。
你奖励数量，系统就生产数量。你奖励速度，系统就牺牲耐心。
你奖励短期结果，系统就透支长期结构。
很多组织最痛苦的地方就在这里——嘴上想要A，激励却奖励B，最后所有人都去做B。
然后管理层开始困惑：为什么大家没有自驱力？这不能全怪人，方向盘都打到那边去了，车当然往那边开。
你不能一边把导航设到火锅店，一边抱怨怎么没去图书馆。
第五种，是边界画得太窄了。
很多优化之所以翻车，是因为你把系统边界画得太小。边界一窄，很多代价就看不见了。看不见，就当它不存在。然后放心大胆地动手。等到问题从别的地方冒出来，又觉得世界好复杂，怎么到处是意外。
比如一个部门为了提高自己的效率，把大量的前置整理工作扔给了下游。自己的指标变好看了，响应快，汇报漂亮。可下游开始加班，错误率上升，沟通成本暴涨。站在这个部门的边界里看，优化大获成功。站在整个系统里看，只是把成本转嫁了而已。
AI产品也一样。只把边界画在“模型回答是否流畅”，优化就会集中在“说得更快、更顺、更像人”。但如果你把边界画到“真实任务是否完成”，那就要看信息来源是否可靠、工具调用是否安全、权限是否明确、错误是否能复核，用户是不是真的解决了问题。只看回答，模型很体面。一看交付，系统开始冒汗。
这才是边界真正的力量，它决定了哪些问题会被看见，哪些代价会被藏起来。
边界画错了，优化自然就跑偏了。
第六种，是把复杂问题硬压成单一解法。
很多时候，大家不是不知道系统复杂，只是太想找一个简单的按钮了。堵车就修路，学习差就加课，效率低就加班，风险高就加审批，模型差就换更大的模型。
这些办法不一定完全没用，有些在局部甚至挺管用。
问题是，它们把复杂的系统问题压成了一次性动作，就像看到人发烧，只盯着降温，不管感染、炎症和免疫系统。温度可能降了，人还在继续坏下去。
系统问题需要的往往是组合解法。交通拥堵需要道路规划、公共交通、停车政策、信号调度和出行需求管理一起调。
教育焦虑需要课程设计、评价机制、家庭预期、社会用人标准一起动。
单一解法最吸引人，因为它便宜、清楚、方便汇报。
可复杂系统从来不吃这一套，它会把你投进去的单点动作吸收掉，再从另一个地方吐出新的问题。
最后一种特别隐蔽，是优化速度超过了理解速度。
这在今天尤其明显。技术变化快，市场变化快，大家都怕慢，怕窗口期过去，怕别人先跑出来。于是很多系统还没看清，就开始加速。还没弄懂用户就开始增长，还没打通流程就开始规模化，还没搞明白风险就开始自动化。
速度当然重要，但在没看清系统之前的加速，往往只是更快地抵达错误地点。就像导航还没加载出来，司机一脚油门就冲出去了。副驾说好像该右转，后排说不对该左转，导航终于出声了，第一句话是：请在安全位置掉头。
很多项目就是这么跑起来的。开局很燃，中期很乱，后期很玄，复盘很熟。大家说快速试错，结果试了很多错，却从来没有真正学到过教训，因为反馈没沉淀，经验没结构化，问题没回到系统设计里去。每次都像第一次犯错，每次都带着新鲜的狼狈感。
所以，为什么很多问题越优化越糟糕？
因为优化太急了，理解太少了。
指标替代了目标，局部效率遮住了整体代价，反馈回路被无视了，激励把行为带偏了，边界画窄了，复杂问题被压成了单一解法，你太想看到立竿见影的效果，可系统偏偏是个慢慢结算的东西。
现实世界很少给人一键修复的爽感。
它更像一个结构复杂、历史包袱沉重、接口文档缺失、还长期有人在线修改的老项目。
你当然可以优化，但别指望随便改一行配置就天下太平。
有些优化是修补，有些是转移，有些是透支，还有些看起来像进步，实际只是把代价藏进了系统的更深处，等着未来某个倒霉时刻集中兑现。
写在最后
很多问题越优化越糟糕，并不是说优化没有价值。问题在于，我们常常还没看清系统，就急着动手了。
看到分数不够，就加作业。看到效率不高，就加流程。看到风险冒头，就加审批。看到用户流失，就加刺激。
这些动作可能都有道理，也可能在短期有效。但系统不会只按你的第一层意图运转，它有它的关系、边界、反馈和慢慢长出来的整体后果。
你今天按下去的按钮，明天可能从另一个角落弹回来，附赠一句：惊不惊喜，意不意外。
系统思维教给我们的第二课，就是学会警惕那些“看起来很合理”的优化。越是复杂的问题，越不能只盯着最容易量化的指标。越是紧急的现场，越要留一点时间看清代价会流向哪里。越是想把一个数字做漂亮，越要小心系统开始为了这个数字，悄悄改变自己的行为。
真正成熟的优化，是从理解系统开始的。先看目标有没有被指标偷换，再看边界有没有画窄，再看局部改动会不会转嫁成本，再看反馈能不能回到决策，再看人的行为会不会被激励带偏。然后，再动手。
否则，很多优化到最后都会长成同一种模样：
表面更精细了，实际更脆弱了。
表面更高效了，实际更拥堵了。
表面数据更好看了，实际系统更疲惫了。
然后大家坐下来，表情凝重，语气诚恳：下次一定注意。
1 个帖子 - 1 位参与者