系统性思维的陷阱：从“完美方案”到“有效落地”

Nov 21 2025

我做程序员已经 10 多年了。

回想刚入行那会儿，我的思维模式很简单：产品经理提什么，我就做什么。那时候追求的是“短平快”，像个执行指令的机器，代码写得快就是牛。

后来加入了腾讯，随着职级的提升，负责的系统越来越复杂，我开始意识到：写代码只是冰山一角，做方案才是真正的考验。

所谓的“系统性思维”，一度让我受益匪浅，但最近我发现，如果一旦陷入对“完美”的执念，系统性思维反而会成为阻碍项目落地的最大陷阱。今天想和大家聊聊，如何在架构设计、风险控制和实际落地之间找到那个微妙的平衡点。

方案的本质：平衡客观条件的艺术

什么是做方案？以前我觉得是画一张最漂亮的架构图，用最牛的组件。现在我理解，做方案其实是把各种“客观条件”作为输入，寻找最优解的过程。

这些客观条件包括：

• 硬件资源：手头有多少服务器？
• 依赖组件：公司基建支持什么？（比如你想用 ClickHouse，但公司运维没经验，出了问题没人兜底，那这就不是一个好选项，不如看看现有组件能不能替代。）
• 人力成本：团队几个人？水平如何？
• 时间窗口：业务等得起多久？

我见过很多“完美”的方案，逻辑自洽，架构优雅，但落地需要半年。而另一个方案虽然略显粗糙，但只需要 1 个月，且预留了后续演进的空间。在商业世界里，后者往往才是胜者。

架构不是设计出来的，是演进出来的。 我们需要做的是调整各种客观条件的优先级，在风险可控的前提下，通过多方评审（集思广益，消除盲区），找到那个平衡点。

实战案例：只解决 80% 的问题

分享一个我在腾讯做权限中心时的真实案例。

当时我们面临一个痛点：有一个中心化的管理员，每天大量时间都在处理审批单，他一直在吐槽，希望把这些审批自动路由到对应的业务负责人，别全堆在他头上。

我第一反应是：做不到。

从技术角度看，审批范围是一个复杂的表达式。要根据用户申请的数据去匹配这个表达式，没法直接做数据库索引。如果要实现，就得全表扫描进行遍历匹配，性能扛不住。而且，很多申请范围很模糊，根本匹配不到具体负责人，最后还是得兜底回落到管理员那里。

于是这个需求被我挡回去了。后来问题太严重，捅到了上面。在复盘会上，我的 Leader 问了一句话，让我瞬间顿悟：

“能不能在只解决 80% 问题的前提下，来做这个方案？”

我突然意识到，我陷入了“完美主义”的陷阱。我一直在纠结那 20% 匹配不到的情况，却忽略了如果能自动化处理掉 80% 的单子，管理员的工作量就能大大减轻。

于是我重新设计了方案：

1. 引入前置索引：提取表达式中的关键特征做索引。
2. 允许降级：能走索引匹配的先走索引，匹配不到的（那复杂的 20%），直接回退给中心管理员。

事实证明，方案落地后，管理员的压力骤减。这就告诉我：有时候真的没有完美的方案，只有平衡现状的方案。

开源代码的“神话”与重构

在阅读优秀开源项目代码时，我常有这种时刻：“哇塞，这代码写得太神了，连这种极端场景都想到了，作者是开了天眼吗？”

随着我自己经验的增长，我发现所谓的“神人”并没有那么玄乎。

他能考虑到那个场景，很可能只是因为他踩过那个坑。

• 版本 1.0 可能是个草台班子。
• 版本 2.0 修复了几个致命 Bug（踩坑）。
• 版本 3.0 因为补丁打多了，代码太烂，被迫重构，把之前的坑变成了新的设计约束。

我在腾讯的 6 年里，权限中心整体重构过 3 次，API 网关也重构过 3 次。每一次重构，都是因为旧的方案无法适应新的客观条件。

踩坑并不是坏事，失败也是财富。 那些让你绞尽脑汁都想不到的 Edge Case，往往是别人血淋淋的经验积累。我们在做方案时，不要怕现在的方案未来会被推翻，只要预留了演进空间，现在的“不完美”就是未来能力的基石。

警惕“过度系统化”的僵局

我现在所在的公司，领导层是运维出身。运维思维和研发思维有一个本质的区别：运维天然厌恶风险（Risk Averse），而研发需要管理风险。

这就导致了一个尴尬的局面： 我提出了方案 A 来解决问题 A，但在评审会上，领导会挑战：“你这个方案没有解决问题 B 怎么办？有没有风险？”

于是，技术评审会变成了“挑刺大会”。

• 为了应对领导的挑刺，我们被迫把方案搞得越来越复杂，试图覆盖所有角落。
• 方案一复杂，落地难度就指数级上升。
• 最终结果是：动作变形，无法落地，不了了之。

组内甚至有同事因为方案迟迟推不动，最后无奈活水走人。

这种过度系统化的思考方式，实际上是一种停滞。领导当然需要系统性思考，但如果一直纠结于“一步到位”的完美方案，就会导致方案根本不具备可行性。

我的应对策略：最小化闭环

面对这种环境，如果硬刚，很容易陷入内耗。我的应对方法是：MVP（Minimum Viable Product）策略 + 工具提效。

1. 把方案切得足够小：不要试图画一张大饼，而是聚焦当前最核心的痛点。
2. 快速跑通 PoC（概念验证）：与其在会议室争论风险，不如直接把代码跑起来，让领导看到可视化的成果。
3. 利用 AI 提效：为了不让自己太累，我现在大量使用 AI 编程工具。它可以帮我快速生成原型代码，大大缩短从“想法”到“演示”的时间。

虽然这样做确实会累一点（因为要先斩后奏，自己承担一部分验证成本），但在“不做不错”和“艰难推进”之间，我选择后者。

写在最后

系统性思维是好东西，它让我们思考得更全面。但我们不能让系统性思维成为阻碍系统发展的借口。

做方案，本质上是在不确定性中寻找确定性。

既要有思维高度，也要有“先解决当下问题”的务实态度。不要害怕方案不完美，只要控制好风险，让系统转起来，剩下的，交给时间去演进。