[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-928":3,"consumer-news-interaction-928":38,"consumer-news-related-928":41},{"detail":4,"item":34},{"card":5,"schemaVersion":21,"fields":22,"content":28},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":18,"tags":19,"resolved":20},"NEWS_ARTICLE:928","news","NEWS_ARTICLE",928,"资讯","架构师化繁为简，执行者化简为繁","博客园","新手改三天，你改三行——反而是你显得更不重要。因为化繁为简做得越纯熟，产出看起来越小。这篇聊聊两种能力的辩证关系，以及为什么'看不见'的那部分工作，恰恰是最难的部分。","","\u002Fnews\u002F928",[17],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":23,"summary":13,"description":13,"publishTime":24,"updateTime":25,"sourceUrl":26,"language":27},"orange-C","2026-09-11T12:33","2026-09-11T15:21:59","https:\u002F\u002Fwww.cnblogs.com\u002Forange-CC\u002Fp\u002F22934179","中文",{"format":29,"policy":30,"normalized":20,"html":31,"text":32,"wordCount":33,"hasBody":20},"HTML","NEWS_CONTENT_V1","\u003Ch2>\u003Cspan>一、一个让我坐在食堂里想了很久的中午\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>前阵子中午吃饭，我拿起手机看了下公司群的消息，有一条让我很震惊。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>公司表扬了一个技术攻关项目里的人员——有硬件的，有测试的，\u003Cstrong>唯独没有软件\u003C\u002Fstrong>。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我第一反应是不对劲，直接找攻关负责人问：\u003Cstrong>一个产品的技术攻关，怎么会没有软件的人？那它还算个产品吗？\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我又把疑问转给了老板，他回了我一句：\u003Cstrong>\"确实没看到软件有什么动静\"\u003C\u002Fstrong>，然后劝我别激动。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我当时回了：不能这么说。如果没有软件的修改和调参，不可能达到现在的效果。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我坐在食堂里想了很多。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>这个攻关已经不是第一次了，前前后后历经一两年。最初的状态是——距离稍远就卡得没法用。现在做到了流畅稳定。\u003Cstrong>中间软件那一部分，恰恰是我做的。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>而我做的事情是什么？是分析出问题的几个方向，是在其中一端做重连机制，是调参数，是判断某个功能应该放在哪一端改。\u003Cstrong>最后的改动很小。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>小到\"没看到软件有什么动静\"。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>委屈和愤愤不平涌上心头。但冷静下来之后，我觉得有必要好好捋一下自己，捋一下这个事件背后，\u003Cstrong>关于软件的认知\u003C\u002Fstrong>。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Ch2>\u003Cspan>二、我为什么会走上架构这条路\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>我工作很多年，也换过一些公司，但有件事始终没停：\u003Cstrong>思考和学习\u003C\u002Fstrong>。我也没有停止追逐内心的那个目标——成为一名优秀的架构师。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>想成为架构师，是源于中间那家工作了九年的公司。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>在那里，把 NVR 的接入能力\u003Cstrong>提升了一倍多\u003C\u002Fstrong>，并把跨平台版本从无到有重构出来。\u003Cstrong>我第一次感受到自己具备了一定的架构设计能力\u003C\u002Fstrong>——我觉得可以往这个目标冲了。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>当时我已经认识到：\u003Cstrong>重构最重要的是思路和模块化，而思路说到底就是抽象，抽象就是把各种表象找到规律、提炼出来。\u003C\u002Fstrong>​C++ 面向对象的核心之一，也正是抽象。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>于是我在重写回放模块的时候，系统地使用了虚拟继承，把这个思想贯彻下去。带来的结果是——后来要加\"即时回放\"这个功能时，变得非常简单、非常自然。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>而在这之前一年，我维护老版本（只支持单一系统的）NVR 时也加过类似功能，\u003Cstrong>那个痛苦劲儿至今还历历在目——牵一发动全身的那种。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>前后一对比，我真实地感受到了：\u003Cstrong>设计有多重要。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Ch2>\u003Cspan>三、那句话，让我把零散的想法串成了一条线\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>从那家工作了九年的公司出来后，我在网上学习，也找过架构师的培训课程。有一家大数据云计算机构抛出了这么一句话：\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cspan>\u003Cstrong>优秀的架构师把复杂问题简单化，把简单问题解决掉；反之，拙劣的架构师把简单问题复杂化，复杂问题把自己给解决掉。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>\u003Cspan>我一下子就 get 到了其中的精髓——\u003Cstrong>不就是化繁为简吗？\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>这不正是验证了我之前的所思所想吗？\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>思路进一步打开后，我一方面跟着他们学习 Kafka 开源库的设计思想，另一方面开始有意识地研究 MySQL 的实现，写了一系列总结博客，其中《\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002Forange-CC\u002Fp\u002F13395512.html\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">MySQL InnoDB 技术内幕：内存管理、事务和锁\u003C\u002Fa>》就是探秘内部原理的。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>写那篇总结时我非常兴奋，因为\u003Cstrong>我的软件认知又升华了一个档次\u003C\u002Fstrong>。为什么要死磕 MySQL？一方面我的 NVR 重构用了它，另一方面它的优秀早有耳闻——\u003Cstrong>想搞清楚它为什么优秀，就得学它的精髓。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>后来我如愿去了一家科技公司当架构师，师从一位从腾讯出来的架构师，从理论上又升华了一次。当时做得最多的就是画架构图。那位主管兼导师说得最多的一句话是：\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cspan>\u003Cstrong>未来无论你们去哪里、做什么工作，都不要忘了架构的思维。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2>\u003Cspan>四、回到开头那个疑问\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>后来我又回到了安防行业，也回到了文章开头那个疑问：\u003Cstrong>我到底做了什么没有？\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我想通过前面的唠叨，答案应该很简单——\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>我肯定做了事情。只是我做的事情是化繁为简，简单到最后，领导以为我没有动静。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>这恰恰说明了：\u003Cstrong>架构的重要性，设计的重要性，思路的重要性。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Ch2>\u003Cspan>五、那化简为繁又是什么？\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>化繁为简是设计阶段的事，那执行阶段呢？\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>时间拨回到去年，我们需要做一个新形态的客户端，开始找第三方合作，进展很慢。可我们内部一直说这个简单——因为主体产品都出来了，Web 端、APP 端都已完成，接口早就定义好了。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>那为什么还这么慢？\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我反思后突然意识到：\u003Cstrong>我们就是因为它\"太简单\"，而轻视了。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>于是我反馈给领导：战术上一定要重视，一定要分解。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>这就是开发时要做的——\u003Cstrong>化简为繁\u003C\u002Fstrong>：\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cp>\u003Cspan>每个功能模块要分开想，该怎么具体实现\u003C\u002Fspan>\u003C\u002Fp>\u003C\u002Fli>\n \u003Cli>\u003Cp>\u003Cspan>关键点在哪儿\u003C\u002Fspan>\u003C\u002Fp>\u003C\u002Fli>\n \u003Cli>\u003Cp>\u003Cspan>真正需要关注的细节在哪儿\u003C\u002Fspan>\u003C\u002Fp>\u003C\u002Fli>\n \u003Cli>\u003Cp>\u003Cspan>哪些细节容易出问题\u003C\u002Fspan>\u003C\u002Fp>\u003C\u002Fli>\n \u003Cli>\u003Cp>\u003Cspan>\u003Cstrong>要反向思考\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>\u003Cspan>六、两者的关系：一个硬币的两面\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>写到这儿，我想把这件事讲透。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>化繁为简，是设计阶段的能力\u003C\u002Fstrong>——面对一堆混乱的表象，抽象出结构，找到规律，定下层级。产出是：一个判断、一个结构、几行关键改动。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>很多人说架构师其实就是接口定义工程师——这话虽糙，理却不糙。如果你能把模块接口都定义出来，也就是对产品功能理解透彻。我在某家公司做报警业务模块时也是这样的，\u003Cstrong>把接口写好\u003C\u002Fstrong>了，实现就交给了小伙伴。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>化简为繁，是执行阶段的能力\u003C\u002Fstrong>——面对一个看起来简单的任务，反过来把它拆开，把细节想透，把风险前置。产出是：一份分解清单、一堆被提前发现的坑。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>很常见的情况是：架构师、管理者或者经验丰富的开发者，会轻飘飘地丢出一句\u003Cstrong>\"这个很简单\"\u003C\u002Fstrong>。说到底是没有换位思考——没有站在第一次做这件事的人的角度想一想：他该怎么下手，第一脚该往哪儿踩。\u003Cstrong>说实话，我自己也犯过这个错。\u003C\u002Fstrong>觉得理所当然的地方，往往是我已经走过一遍、把坑填平了的地方——而我忘了，别人还没走过。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>它们不是对立的，是同一个人需要的两种能力，甚至是一件事的两个阶段。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>先化繁为简，才知道劲该往哪儿使；再化简为繁，才知道这一脚踩下去会不会塌。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Ch2>\u003Cspan>七、为什么化繁为简的人最容易被低估\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>这是我最想说的一段，也是我坐在食堂里想明白的。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>因为这两种能力的产出，\"可见度\"完全不同。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cp>\u003Cspan>化简为繁的产出是\u003Cstrong>看得见的\u003C\u002Fstrong>：分解清单、讨论记录、改了一堆问题、忙了很久\u003C\u002Fspan>\u003C\u002Fp>\u003C\u002Fli>\n \u003Cli>\u003Cp>\u003Cspan>化繁为简的产出是\u003Cstrong>看不见的\u003C\u002Fstrong>：它最后只留下\"几个参数的调整\"\"一个否决\"\"几行改动\"\u003C\u002Fspan>\u003C\u002Fp>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cspan>于是出现一个残酷的等式：\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cspan>\u003Cstrong>你把难事做简单了，别人就以为这事本来就简单。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>\u003Cspan>而\"想清楚\"那一段，不留痕迹，不产生提交记录，无法被度量。它发生在你坐在食堂的时候，发生在你散步的时候，发生在你盯着现象发呆的时候。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>更残酷的是：化繁为简做得越纯熟，这个效应越明显。\u003C\u002Fstrong>新手要改三天，你改三行——反而是你显得更不重要。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我想了很久怎么破，目前有三条：\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>第一，把\"想\"的过程留下来。\u003C\u002Fstrong>​文档、评审记录、方案对比。不是为了邀功，是为了\u003Cstrong>让认知成本变得可见\u003C\u002Fstrong>。我很庆幸自己早年养成了写博客和写专利的习惯——\u003Cstrong>它们在我说不清的时候，替我说了话。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>第二，把结果量化。\u003C\u002Fstrong>\"优化了无线\"没有力量，\"从卡顿到流畅、稳定性提升数倍\"才有力量。\u003Cstrong>认知价值必须翻译成别人看得懂的单位。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>第三，别等别人来发现。\u003C\u002Fstrong>等待是最差的策略。要么自己讲出来，要么找一个看得懂的地方。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Ch2>\u003Cspan>八、写在最后\u003C\u002Fspan>\u003C\u002Fh2>\n\u003Cp>\u003Cspan>化繁为简是\u003Cstrong>慢功夫\u003C\u002Fstrong>。因为\"想清楚\"这一段，看不见、说不清，也没人给你计时。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>但它是唯一不会返工的路。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>我在《\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002Forange-CC\u002Fp\u002F17110928.html\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">如何做到慢即是快\u003C\u002Fa>》里写过，\u003Cstrong>慢不是目的，不返工才是\u003C\u002Fstrong>。这篇算是它的续篇——所谓慢，很多时候就慢在这里：你花在\"想清楚\"上的时间，跟别人花在\"反复改\"上的时间其实一样多，\u003Cstrong>只不过你的那一段没人看见。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cspan>另外，把我那篇《\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002Forange-CC\u002Fp\u002F17205329.html\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">自以为是与思考\u003C\u002Fa>》也一并推荐。化繁为简最大的敌人不是技术难度，是自以为已经想清楚了。\u003C\u002Fspan>\u003Cspan>而对执行者来说，\u003Cstrong>化简为繁最大的敌人\u003C\u002Fstrong>同样如此——\u003Cstrong>自以为很简单\u003C\u002Fstrong>，于是掉以轻心，于是轻敌，于是进度一拖再拖。\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan>一个提醒自己多想一层，一个提醒自己多拆一层。\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cspan>\u003Cstrong>多想一层再动手，多拆一层再下手。\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>","一、一个让我坐在食堂里想了很久的中午 前阵子中午吃饭，我拿起手机看了下公司群的消息，有一条让我很震惊。 公司表扬了一个技术攻关项目里的人员——有硬件的，有测试的，唯独没有软件。 我第一反应是不对劲，直接找攻关负责人问：一个产品的技术攻关，怎么会没有软件的人？那它还算个产品吗？ 我又把疑问转给了老板，他回了我一句：\"确实没看到软件有什么动静\"，然后劝我别激动。 我当时回了：不能这么说。如果没有软件的修改和调参，不可能达到现在的效果。 我坐在食堂里想了很多。 这个攻关已经不是第一次了，前前后后历经一两年。最初的状态是——距离稍远就卡得没法用。现在做到了流畅稳定。中间软件那一部分，恰恰是我做的。 而我做的事情是什么？是分析出问题的几个方向，是在其中一端做重连机制，是调参数，是判断某个功能应该放在哪一端改。最后的改动很小。 小到\"没看到软件有什么动静\"。 委屈和愤愤不平涌上心头。但冷静下来之后，我觉得有必要好好捋一下自己，捋一下这个事件背后，关于软件的认知。 二、我为什么会走上架构这条路 我工作很多年，也换过一些公司，但有件事始终没停：思考和学习。我也没有停止追逐内心的那个目标——成为一名优秀的架构师。 想成为架构师，是源于中间那家工作了九年的公司。 在那里，把 NVR 的接入能力提升了一倍多，并把跨平台版本从无到有重构出来。我第一次感受到自己具备了一定的架构设计能力——我觉得可以往这个目标冲了。 当时我已经认识到：重构最重要的是思路和模块化，而思路说到底就是抽象，抽象就是把各种表象找到规律、提炼出来。C++ 面向对象的核心之一，也正是抽象。 于是我在重写回放模块的时候，系统地使用了虚拟继承，把这个思想贯彻下去。带来的结果是——后来要加\"即时回放\"这个功能时，变得非常简单、非常自然。 而在这之前一年，我维护老版本（只支持单一系统的）NVR 时也加过类似功能，那个痛苦劲儿至今还历历在目——牵一发动全身的那种。 前后一对比，我真实地感受到了：设计有多重要。 三、那句话，让我把零散的想法串成了一条线 从那家工作了九年的公司出来后，我在网上学习，也找过架构师的培训课程。有一家大数据云计算机构抛出了这么一句话： 优秀的架构师把复杂问题简单化，把简单问题解决掉；反之，拙劣的架构师把简单问题复杂化，复杂问题把自己给解决掉。 我一下子就 get 到了其中的精髓——不就是化繁为简吗？ 这不正是验证了我之前的所思所想吗？ 思路进一步打开后，我一方面跟着他们学习 Kafka 开源库的设计思想，另一方面开始有意识地研究 MySQL 的实现，写了一系列总结博客，其中《MySQL InnoDB 技术内幕：内存管理、事务和锁》就是探秘内部原理的。 写那篇总结时我非常兴奋，因为我的软件认知又升华了一个档次。为什么要死磕 MySQL？一方面我的 NVR 重构用了它，另一方面它的优秀早有耳闻——想搞清楚它为什么优秀，就得学它的精髓。 后来我如愿去了一家科技公司当架构师，师从一位从腾讯出来的架构师，从理论上又升华了一次。当时做得最多的就是画架构图。那位主管兼导师说得最多的一句话是： 未来无论你们去哪里、做什么工作，都不要忘了架构的思维。 四、回到开头那个疑问 后来我又回到了安防行业，也回到了文章开头那个疑问：我到底做了什么没有？ 我想通过前面的唠叨，答案应该很简单—— 我肯定做了事情。只是我做的事情是化繁为简，简单到最后，领导以为我没有动静。 这恰恰说明了：架构的重要性，设计的重要性，思路的重要性。 五、那化简为繁又是什么？ 化繁为简是设计阶段的事，那执行阶段呢？ 时间拨回到去年，我们需要做一个新形态的客户端，开始找第三方合作，进展很慢。可我们内部一直说这个简单——因为主体产品都出来了，Web 端、APP 端都已完成，接口早就定义好了。 那为什么还这么慢？ 我反思后突然意识到：我们就是因为它\"太简单\"，而轻视了。 于是我反馈给领导：战术上一定要重视，一定要分解。 这就是开发时要做的——化简为繁： 每个功能模块要分开想，该怎么具体实现 关键点在哪儿 真正需要关注的细节在哪儿 哪些细节容易出问题 要反向思考 六、两者的关系：一个硬币的两面 写到这儿，我想把这件事讲透。 化繁为简，是设计阶段的能力——面对一堆混乱的表象，抽象出结构，找到规律，定下层级。产出是：一个判断、一个结构、几行关键改动。 很多人说架构师其实就是接口定义工程师——这话虽糙，理却不糙。如果你能把模块接口都定义出来，也就是对产品功能理解透彻。我在某家公司做报警业务模块时也是这样的，把接口写好了，实现就交给了小伙伴。 化简为繁，是执行阶段的能力——面对一个看起来简单的任务，反过来把它拆开，把细节想透，把风险前置。产出是：一份分解清单、一堆被提前发现的坑。 很常见的情况是：架构师、管理者或者经验丰富的开发者，会轻飘飘地丢出一句\"这个很简单\"。说到底是没有换位思考——没有站在第一次做这件事的人的角度想一想：他该怎么下手，第一脚该往哪儿踩。说实话，我自己也犯过这个错。觉得理所当然的地方，往往是我已经走过一遍、把坑填平了的地方——而我忘了，别人还没走过。 它们不是对立的，是同一个人需要的两种能力，甚至是一件事的两个阶段。 先化繁为简，才知道劲该往哪儿使；再化简为繁，才知道这一脚踩下去会不会塌。 七、为什么化繁为简的人最容易被低估 这是我最想说的一段，也是我坐在食堂里想明白的。 因为这两种能力的产出，\"可见度\"完全不同。 化简为繁的产出是看得见的：分解清单、讨论记录、改了一堆问题、忙了很久 化繁为简的产出是看不见的：它最后只留下\"几个参数的调整\"\"一个否决\"\"几行改动\" 于是出现一个残酷的等式： 你把难事做简单了，别人就以为这事本来就简单。 而\"想清楚\"那一段，不留痕迹，不产生提交记录，无法被度量。它发生在你坐在食堂的时候，发生在你散步的时候，发生在你盯着现象发呆的时候。 更残酷的是：化繁为简做得越纯熟，这个效应越明显。新手要改三天，你改三行——反而是你显得更不重要。 我想了很久怎么破，目前有三条： 第一，把\"想\"的过程留下来。文档、评审记录、方案对比。不是为了邀功，是为了让认知成本变得可见。我很庆幸自己早年养成了写博客和写专利的习惯——它们在我说不清的时候，替我说了话。 第二，把结果量化。\"优化了无线\"没有力量，\"从卡顿到流畅、稳定性提升数倍\"才有力量。认知价值必须翻译成别人看得懂的单位。 第三，别等别人来发现。等待是最差的策略。要么自己讲出来，要么找一个看得懂的地方。 八、写在最后 化繁为简是慢功夫。因为\"想清楚\"这一段，看不见、说不清，也没人给你计时。 但它是唯一不会返工的路。 我在《如何做到慢即是快》里写过，慢不是目的，不返工才是。这篇算是它的续篇——所谓慢，很多时候就慢在这里：你花在\"想清楚\"上的时间，跟别人花在\"反复改\"上的时间其实一样多，只不过你的那一段没人看见。 另外，把我那篇《自以为是与思考》也一并推荐。化繁为简最大的敌人不是技术难度，是自以为已经想清楚了。而对执行者来说，化简为繁最大的敌人同样如此——自以为很简单，于是掉以轻心，于是轻敌，于是进度一拖再拖。 一个提醒自己多想一层，一个提醒自己多拆一层。 多想一层再动手，多拆一层再下手。",2896,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":37},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":39,"likeCount":40,"commentCount":40,"contentLikeCount":40,"contentCommentCount":40,"sourceLikeCount":40,"sourceCommentCount":40},false,0,[42,51,57,66,73,79,86,93],{"id":43,"kind":7,"title":44,"summary":45,"image":46,"href":47,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":49},"NEWS_ARTICLE:927","HelloCrab - 短视频开源爬虫，仅供学习参考","HelloCrab 基于 Avalonia、Playwright、AI与 FFmpeg 的跨平台桌面采集器，支持9大平台，以及 Android、iOS、Browser 远程控制端。 Made By ChatGPT & Vincent with ❤ 平台 是否接入 哔哩哔哩 ✅ 抖音 ✅ 快手","https:\u002F\u002Fwww.cnblogs.com\u002Fhupo376787\u002Fp\u002FScreenshot\u002FWindows.jpg","\u002Fnews\u002F927","2026 · 软件开发",[50],"软件开发",{"id":52,"kind":7,"title":53,"summary":54,"image":14,"href":55,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":56},"NEWS_ARTICLE:929",".NET 异常处理的\"暗门\"：代码里写满 catch，你依然能抓住它——从一个 AI Agent 运行时的源码说起","一个健壮的系统，必然到处都是有意的 catch；异常被消化不等于问题不存在。 观测与韧性，是一个硬币的两面——降级逻辑保证系统不崩，FirstChance 保证你能看见它为什么降级。","\u002Fnews\u002F929",[50],{"id":58,"kind":7,"title":59,"summary":60,"image":61,"href":62,"meta":63,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":64},"NEWS_ARTICLE:930","基于 vLLM+Nginx 构建负载均衡推理集群","企业内部私有环境部署大模型推理集群时，很容易遇到流量调度混乱、节点负载失衡、会话上下文丢失、接口缺少鉴权防护等一系列问题，单 vLLM 推理节点难以支撑并发请求。本文基于 Ubuntu 22.04 系统环境，搭建 Nginx + vLLM-Semantic-Router + vLLM-Router","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1379525\u002F202609\u002F1379525-20260910165534385-2022408098.png","\u002Fnews\u002F930","2026 · 人工智能",[65],"人工智能",{"id":67,"kind":7,"title":68,"summary":69,"image":70,"href":71,"meta":63,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":72},"NEWS_ARTICLE:932","2026年AI编程工具大全，33个主流工具一次看懂","事情是这样的，前两天看到一张图，是某个社区官网的「支持的工具」清单，我数了数，整整31个AI编程工具。 两年前这份清单撑死5个，现在直接31个，而且我居然每一个都认识。。。 干脆整理成一篇，顺手把最近字节的TraeWork和豆包工作也补了进来，凑成33个。 今天给大家推荐一遍，每个工具说说它是干什么","https:\u002F\u002Fimage.kjdaohang.com\u002Fimg\u002F20260909210838518.png","\u002Fnews\u002F932",[65],{"id":74,"kind":7,"title":75,"summary":76,"image":14,"href":77,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":78},"NEWS_ARTICLE:931","SH 中文化样例数据使用手册","在数据库演示与 PoC 场景中，Oracle 自带的 SH 示例模式虽然经典，但英文维度数据往往让国内演示效果打折扣。笔者整理了一套方案：保留 SH 标准英文对象名，同时装载中文化维度数据，并按参数生成可复现的销售历史数据，方便个人测试与概念验证。 01 | 环境准备 使用前请确认满足以下条件： O","\u002Fnews\u002F931",[7,8],{"id":80,"kind":7,"title":81,"summary":82,"image":83,"href":84,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":85},"NEWS_ARTICLE:933","写给 C++ 工程师的 OpenClaw.NET 上手指南：用你熟悉的 C++ 思维，跑起一个生产级 AI Agent","它像一个「基于 boost.asio + REST 端点的常驻服务」——对外是 HTTP \u002F WebSocket \u002F 各 IM 的 webhook，对内跑着一个能调工具、读写记忆、跨渠道对话的 AI Agent——只不过协程不用你手写 promise_type，内存不用你管 new\u002Fdelete。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202609\u002F510-20260905070811424-1837144874.jpg","\u002Fnews\u002F933",[50],{"id":87,"kind":7,"title":88,"summary":89,"image":90,"href":91,"meta":63,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":92},"NEWS_ARTICLE:935","[Agent Memory \u002F 强化学习] MemPO源码学习笔记 ---（1）--- 总体","[Agent Memory \u002F 强化学习] MemPO源码学习笔记 （1） 总体 目录[Agent Memory \u002F 强化学习] MemPO源码学习笔记 （1） 总体0x00 概要0x01 基础 & 背景1.1 用RL训练记忆系统的要点1.2 主要难点1.3 主要思路1.4 RL训练方案1.","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1850883\u002F202609\u002F1850883-20260906190854637-986949885.jpg","\u002Fnews\u002F935",[65],{"id":94,"kind":7,"title":95,"summary":96,"image":14,"href":97,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":98},"NEWS_ARTICLE:934","Memory 记忆设计讨论：为什么 Agent Memory 不能只靠向量数据库？","这是 Agent Memory 系列的第二篇文章。上一篇先给出了一个总体判断：Memory 是一套让 Agent 能够持续使用历史上下文的能力。 这篇只讨论一个经常出现的问题： 既然 Agent 需要从历史信息中找内容，接入向量数据库不就可以了吗？ 我的答案是：向量数据库很有用，但它只解决了召回问题","\u002Fnews\u002F934",[7,8]]