用蓝盒子驯服天空

今年上半年工会的购书活动我买了一套名字看起来很奇怪的书：《以纸鸢征服加农炮》和《用蓝盒子驯服天空》。因为我有时喜欢在会议间隙看几页书，所以这两本书一直摆在我的桌面上。因为名字确实很奇怪，所以经常有同事路过的时候会问我这两本书是讲什么的，我就会简单地回答：这是一本讲工程的书。 为什么我想买这套书呢？因为我一直在思考一个问题：软件工程的主要载体是代码，当AI可能生成代码之后，软件工程还存在吗? 或者说在AI能产生代码的时代，软件工程师的作用是什么？这个问题自从生成式AI出现并广泛应用于软件工程之后就在困扰我，尤其是最近一两年AI 编程agent的能力越来越强，从以前只能简单地给你推荐一下你应该引用哪个类库变成可以独立地完成一部分代码，比如写一个类或是一个HTML页面。 我无意中在微信读书上读到了微软中国首席技术官给这套书写的序，然后我就觉得这本书能够帮助我回答“AI编程时代，软件工程和软件工程师的价值”这个问题，然后我就推荐公司买了这套书。这套书比较容易读，因为 它用了很多故事来讲述核心的观点，这些故事涵盖了航空工程，机械工程和环保工程等不同的领域。 如果大家对这些故事好奇的话，我建议大家可以自己读一下书，这些故事告诉我们对于一个工程问题来说，最重要的是什么。我们平时经常把科学和技术连在一起使用，好像科学和技术是无法区分的，其实并不然。区分科学和技术有一个最简单的标准，科学是要建立一个模型来描述世界上的现象，技术或是工程则是要用模型来解决各种复杂的问题。 科学中最常用的方法是还原论，也就是把现象中的各种因素拆开，独立研究每一种因素。技术和工程的方法则不然，技术和工程需要一种系统性的视角，也就是说不仅要搞清楚一个组件是如何工作的，还要搞清楚这个组件是如何和整个系统中的其他组件互动并相互影响的。这种系统性视角分析出来的结果就是一个工程问题的结构。 比如说在我们日常的软件工程中，我们不仅要搞清楚一个组件比如数据库或消息中间件的工作原理，我们还需要搞清楚当这个组件和我们系统中的其他组件一起工作时会发生什么，什么情况这些组件被应用到了合适的场景下，什么时候我们应该考虑别的组件。我们需要一个全局性视角来理解各个组件是如何组成一个系统的。 工程问题中除了要了解结构之外还需要了解约束。什么是约束呢？我们在软件工程中出现的业务需求和非功能性需求就是一种强制性的约束，比如用户能否接受异步刷新，API的平均返回时间是多少等等都是对我们工程问题的约束。 作为一个软件工程的参与者，我们每天的任务就是根据各种约束来设计我们的系统和系统中的各种组件，然后通过编码或配置来实现这个系统。在这个过程中我们每天面对的主要问题是什么呢？是编写代码？配置各种环境中的参数和连接字符串？还是监控日志系统中记录的错误? 作者的回答是我们每天需要面对的主要任务是判断问题的类别并做出权衡。 是的，没错，根据系统结构和各种约束条件做出权衡才是各种工程问题和工程实践的核心任务。这个答案在很大程度上回答了我最初的问题，有了AI能产生代码之后，软件工程师还需要做什么？答案很简单：软件工程师需要专注于核心任务：权衡。AI可能帮你写出一个类，但是AI很难告诉你根据你的场景你到底是该用一个接口还是一个抽象类。AI可以快速写出每个软件设计模式的代码实现，但是它没法告诉你当前的情况是应该用简单工厂模式还是抽象工厂模式。 即使AI能够根据你的描述给你建议，这个建议最终是否采纳也只能依赖你自己的权衡，并且只有你自己才能对权衡的结果负责。整个权衡的过程不仅依赖于AI可以快速回答的静态知识，还依赖于我们从长期实践经验中获得的动态知识，也就是知道什么时候应该运用什么知识的能力。所以权衡是一个困难的任务，需要团队的集体智慧和协调一致，权衡的结果永远没有最优解，只有次优解。 为什么权衡是一个困难的任务呢？因为它需要考虑的方面太多了，根据作者在这套书中给出的建议，任何权衡都需要考虑六个方面：效率，模糊性，脆弱性，安全性，可维护性，韧性。也就是说任何工程问题的权衡需要面对的不是非此即彼，非黑即白的简单问题，而是一个棘手的六面体。 我们在软件开发的日常工程中被重视最多的就是效率：在一个sprint里完成了多少task，case是否能够在SLA规定的时间范围内解决等等。效率当然是工程中一个重要的考量目标，所以很多的KPI都是围绕如何提高效率设计的。用AI编程助手来写代码当然能提高效率，所以AI编程助手是任何软件工程都无法抗拒的诱惑。 我们需要注意的一点是效率不是我们工程问题权衡的唯一指标，我们使用AI产生了更多的代码是否会带来可维护性上的困扰，我们能不能理解这些AI产生的代码对系统结构造成的影响，这是我们需要考虑的问题。当然还有更重要的安全问题，AI产生的代码是否有安全隐患，也是我们在代码静态扫描时需要关注的。 我们日常遇到的工程难题一般都是如何在这六个维度上做到平衡，因为如果我们只看一个指标的话，就没有所谓的工程难题。所有的难题都是因为要兼顾多个因素。曾经牛顿力学解决了两个物体之间的作用是什么样的，有人就想了是不是能够计算三个物体在牛顿力学中的相互作用，这就是著名的“三体问题”，后来庞加莱发现这个问题用微积分根本算不出，后来也证明了三体问题没有解析解。现在我们那本耳熟能详的科幻小说的名字就是这么来的。 没有一种工程模式可以解决所有六个维度的问题，明白了这点大家就不用在让人眼花缭乱的技术讨论中迷茫了。有人说他要取消微服务架构改用单体，是不是微服务架构就不能用了？不是，只是在某些场景下微服务架构不是权衡之后的次优解。有人说MCP引发AI应用的上下文爆炸，是不是MCP就不能用了？不是，也是因为在某些场景下这个技术会引发某些维度的混乱，所以只能在权衡之后被舍弃。 解决工程问题最忌讳的就是拿着锤子找钉子。解决工程问题的人最要不得的态度就是一知半解，听说了一种新技术和新概念之后就把这个新技术和新概念当成神药，忘记了工程的本质是权衡，恨不得把这个新技术和新概念应用到一切的工程实践中去。我曾经就见过那种无论多简单的场景都要套用设计模式的人，设计模式就是这么被这些人玩儿坏的。 无论是设计模式还是现在各种AI相关的新概念，它们都是一种技术方案，都有它们适合的场景，同样也有它们不适合的场景。真的要采用哪种技术和模式都需要在团队内部经过讨论之后做出谨慎的权衡。工程问题需要考虑的所有因素是一个六面体，这就意味着在这六个因素之间的权衡没有放诸四海皆准的标准答案和全局最优解，这对于任何从事工程的人来说即是一个魔咒，也是一个福音。 说它是魔咒因为我们没法用一个标准方法和模板来解决所有技术问题，作为一个软件从业者，这些年强行套用微服务架构引起的水土不服我们还见得少吗？说它是福音是因为工程问题没有全局最优解和标准答案，AI就无法替代人类做权衡（主要是因为AI无法替代人来承担权衡失败的结果）。除非Open AI这种大模型厂商宣布对AI做出的决策后果负责，否则根据多个因素做出一个次优解的权衡永远是人类不可逃避的责任和专属领地。 我们明白了工程难题的本质之后我们要明白自己会犯错是正常的，要接受自己的历史局限性并在别人指出之后及时改正。同时我们也要避免拿着锤子找钉子和追求完美的陷阱，我们唯一需要做的是像《周易》中说的一样：“君子终日乾乾，夕惕若，厉无咎。” 只有我们每天都记得自己所做的是没有最优解的权衡，并时刻准备修正自己的错误，我们才能在工程活动中避免更大的灾难。此话与大家共勉。

用蓝盒子驯服天空：承认“不可知”不是无能，而是基于数学逻辑的理性诚实 评分7分 1. 核心主张 * 应对棘手问题，不是仅凭直觉或简单分割问题的方式，进行有效干预并带来深刻改进，而取决于更好地对棘手问题进行工程设计（better engineering of wickedness）。这需要一种系统工程学的方法，以及培养一种将工程学概念融入文化和公民参与的公民意识 2. 主要价值 * 提供一种系统工程学的思维模式和方法论——即“运行概念”（Concept of Operations, ConOps），帮助人们负责任地评估和处理生活中最难缠的、具有多面性和矛盾性的“棘手问题”（Wicked Problems） 3. 要点 * 哲学家卡尔·波普尔（Karl Popper）的“时钟与云朵”（Clocks and Clouds）隐喻来分类问题，论证棘手问题的不可预测性 * 棘手问题不是两面性问题，是六面性问题，效率（Efficiency）、模糊性（Vagueness）、脆弱性（Vulnerability）、安全（Safety）、维护（Maintenance）、韧性（Resilience），处理棘手问题必须应用多准则方法 * 问题层次：“硬性问题”（Hard）、“软性问题”（Soft）和“混乱问题”（Messy），相互作用 * 硬性（Hard）：有明确边界，可优化（Optimize）/解决（Solution）。软性（Soft）：涉及人类行为，结果不明确，可满意够用（Satisfice）/化解（Resolution）。混乱（Messy）：由价值观冲突产生，需理想化（Idealize）/消融（Dissolution） * 拉塞尔·阿考夫（Russell Ackoff）的观点，区分了“解决”（Solution，针对硬性问题，目标是优化）、“化解”（Resolution，针对软性问题，目标是满意够用，即 satisficing）和“消融”（Dissolution，针对混乱问题，目标是理想化）三种不同的问题应对策略 * “怪物方程”（the monster equation） I=2^n*(n−1) 来量化系统的潜在状态，以直观展示复杂系统的爆炸性复杂程度 * 书中列举了飞行模拟机、波士顿糖蜜灾难、卡特莉娜飓风、冰岛火山危机、福岛核事故、美国海军命中率提升的案例，道路修建时候从单纯的物理效率（技术参数）转向经济和社会效率（公共福利）也是不错的案例，从投入大于产出、到机会成本、到支付意愿，效率不仅仅是数学计算，还涉及人类的欲望、选择和行为（软问题） 4. 洞见 * 识别问题（时钟 or 云朵）→问题结构分类（软、硬、混？）→硬性要素（Hard）：可优化（Optimize），通过技术解决（Solution）；软性要素（Soft）：涉及人类行为和偏好，可满意够用（Satisfice），通过化解（Resolution）；混乱要素（Messy）：涉及价值观冲突，可理想化（Idealize），通过消融（Dissolution）→尝试从多角度（as many angles as possible）进行问题分解→运行概念用六大属性过滤器，确保解决方案考虑了所有方面→多准则行动与整合，拥抱矛盾，寻找“协同作用”（synergies） 5. 启示 * 应该从优化的思维（如，平衡效率和安全），到多准则评估的方向进行转向，确保结论在其他维度不会造成灾难性后果，更加不要不要把云当成时钟来修。 * 人类的认知带宽是有限的，而系统的复杂性是无限的。承认“不可知”不是无能，而是基于数学逻辑的理性诚实 * 对安全的错误感知或对系统能力的夸大承诺更加可怕，The promise or perception of a system when it does not exist is perhaps more dangerous than no system at all. * 一些解决方案要从技术解决到文化消融、从“创新”（Innovation）转向“维护”（Maintenance）转向，因为维护是现代性的基础，对现有系统的长期投入比盲目追求新技术更为重要，能够避免“缓慢灾难” Source：用蓝盒子驯服天空 《Wicked Problems: How to Engineer a Better World》 Guru Madhavan