老李校长架构这个词，这些年几乎被说烂了。我见过太多团队，一边喊着“要有架构思维”，一边在生产环境里用最快的速度打补丁：订单量上来了就加缓存，缓存穿透了就加锁，锁粒度大了再拆锁，最后整个系统变成一团谁都不敢动的乱麻。更麻烦的是，这种“临时判断”不是个别现象，而是很多企业的常态。今天这篇内容，想认真聊聊我这些年在一线做架构设计、做技术管理的一些真实感受：为什么企业靠临时判断永远不够，架构到底在平衡什么，以及一套能落地、能替代“拍脑袋”的架构决策方法。这篇东西不是写给纯新手的，但如果你是技术负责人、架构师、或者正在往这个方向走的开发，应该能从中找到一些能直接用起来的东西。
1. 为什么“临时判断”成了企业系统最大的隐性成本
1.1 三个典型场景：救火、局部最优、一次性架构
先说几个我实际经历过的场景，你看看是不是很熟悉。
第一个是救火式决策。系统马上要搞大促了，压测发现性能不达标，怎么办？大家的第一反应往往不是回头审视整体设计，而是哪里漏了补哪里。加缓存、加机器、调参数、把同步调用改异步……每一个动作单看都合理，但是这些动作之间没有任何统一的架构约束。等大促结束了，系统里到处都是“应急措施”，没人说得清楚为什么这里要加一层缓存，为什么那个队列要有三级重试。有一次我们排查一个线上问题，从应用层一路查到中间件，最后发现是三年前的某个“临时方案”一直在默默消耗资源，而当时做这个决策的人已经离职两年了。
第二个是局部最优。不同团队各自为政，每个团队都觉得自己的选择是最合理的。支付团队用了消息队列A，订单团队选了消息队列B，用户团队干脆直接走 RPC 同步调用。单看每个团队，他们的技术选型都有充分的理由：A 团队熟悉 RabbitMQ，B 团队看重 Kafka 的吞吐。但从整个公司的视角看，数据链路被割裂成好几段，跨团队排查一个问题要拉四个群，每次联调都要处理各种协议转换。这种局部的“最优”，叠加起来就是全局的“最乱”。
第三个是彻底的一次性架构。每次启动新项目，都不愿意复用已有的东西，总觉得老系统那套“配不上”新项目的宏伟目标。于是重新搭一套框架、重新定义一套规范、重新引入一套中间件。结果公司同时维护着三套风格迥异的微服务骨架，公共组件没人维护，新同学入职光理解这些“历史包袱”就要两周。这其实就是典型的没有架构治理——架构不是没人想，而是从来没有被当作一个需要持续投入的资产。
1.2 临时判断背后的机制性原因
你可能想问，为什么大家明知道临时判断有问题，还是会一次次走回老路？我观察下来，有几个机制性的原因在起作用。
第一个是激励错位。大部分团队的考核周期是季度、半年，而架构治理是典型的长期收益、短期看不到效果。你花了两周时间把技术债还了，这个季度需求评审的时候业务方只看到一个“什么都没交付”的团队。反过来，你带着团队疯狂上线新功能，就算留下了一堆坑，只要眼下没问题，绩效照样好看。这种机制下，理性的人都会选择“先把眼前的火灭了”。
第二个是信息不对称。决策层掌握全局但不了解细节，执行层了解细节但看不到全局。我看到很多架构决策的现场，基层开发提了一个方案，领导凭经验否了，但又说不出具体哪里不行，最后只能拍脑袋。真正有效的架构决策需要把两边的信息拼在一起，但大多数企业缺少这个拼图的机制。
第三个是决策没有记录、没有回溯。很多团队做了决策，但从不记录当初的上下文、考虑过哪些选项、为什么选 A 不选 B。三个月后，当初的方案被证明有问题，但没人说得清当初的假设是什么，于是只能推翻重来或者继续在错误的路上将就。这种“没有记忆的组织”，注定了要反复交学费。
1.3 给临时判断算一笔成本账
很多人对技术债的理解是抽象的，我换个方式给你算一笔账。
假设一个系统有 10 个开发在维护。因为长期临时判断、缺乏架构治理，系统变得非常绕。原本一个需求估时 3 天，因为要处理各种历史包袱，实际要 5 天。这点听起来不多，但你算一下：10 个人每人每天的成本假设是 3000 元，多出来的 2 天就是每个需求多花 6 万。一年 50 个需求，就是 300 万。这还只是人力的直接成本，没算线上故障的损失、新员工磨合期的损耗、以及因为系统改不动而错过的业务窗口。
更可怕的是隐性成本。当一个系统的行为无法被任何一个人完整解释时，组织的决策就开始变得保守：不敢做大的重构，不敢引入新技术，甚至不敢触碰某一块代码。这种“组织性的怯懦”，会让整个公司在技术上的进化速度越来越慢。你会发现，竞争对手半年能做完的事情，你们需要一年，因为你们不是在建设系统，而是在跟自己的历史纠缠。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构不是画图，是管理复杂性的决策系统
2.1 架构的本质是“有约束的决策集合”
我在面试架构师的时候，经常问一个问题：你觉得架构是画出来的，还是长出来的？很多人会犹豫。我的答案是：架构是一组决策的集合，而且是一组有约束的、对系统长期演进有重大影响的决策集合。
选 MySQL 还是 PostgreSQL，这是架构决策。订单服务拆不拆成独立的微服务，这是架构决策。数据一致性是追求强一致还是最终一致，这是架构决策。消息队列用 Kafka 还是 Pulsar，这也是架构决策。但你在某个方法里是用 for 循环还是 stream，这不算架构决策。
为什么强调“决策”而不是“图”？因为图是静态的，决策是动态的、有时间维度的。一张架构图画得再漂亮，如果没人知道为什么要这么画，那它就是一张挂在墙上的装饰品。真正让一个系统立住的，是每一层、每一个模块背后的权衡逻辑。我见过很多团队，架构图齐全，文档规范，但系统照样烂。因为他们的架构是“设计”出来的，不是“决策”出来的——缺少对取舍的深入思考，缺少对后果的预判。
架构决策有一个重要特征：它会形成约束。你用 K8s 做容器编排，那你的应用就要遵循它的部署模型；你选了微服务，就要处理分布式事务、服务发现、链路追踪等一系列新问题。架构本质上是在用一套成体系的约束，换取某种可预期的长期收益。而临时判断的问题就在于，它只看到了眼前的收益，忽略了这套约束的长期后果。
2.2 平衡的艺术：过度设计与设计不足之间
“架构是平衡的艺术”这句话，听起来像正确的废话，但真正能拿捏好度的人很少。
一种极端是过度设计。项目还没开始，先规划好三年后的容量，引入微服务、分布式事务、多级缓存、单元化部署。结果团队只有十个人，业务每天几百单，光是把这套架构维护明白就已经耗尽了所有人的精力。我见过最夸张的一个项目，用微服务做了一个只有三个模块的内部管理系统，每个模块一个独立数据库，服务间用消息队列通信。听起来很“先进”，但每次改一个字段要跨三个服务发布，开发效率低到令人发指。
另一种极端是设计不足。所有逻辑堆在一个巨大的类里，没有分层，没有边界，数据库表随便加字段，服务间互相调用完全没有规范。这种系统在早期开发极快，但到了一定规模后，每加一个功能都像在一团乱麻里找线头。
那平衡点在哪里？我的经验是，架构的复杂度一定不能超过组织和业务的承受能力。判断标准很简单：你的团队是否能在不牺牲交付速度的前提下，理解和维护这套架构？你的架构是否在满足当前业务需求的同时，给未来留下了合理的演进空间？如果答案是肯定的，不管你用的是单体还是微服务，你都在做正确的架构。反过来说，如果你的系统已经复杂到团队无法掌控，再先进的架构理念都是在给企业添乱。
这里有一个特别重要的视角：总拥有成本。一个架构方案不只是开发阶段的成本，还要算上运维成本、学习成本、演进成本。很多团队选型只盯着开发效率，结果把一个运维极其复杂的方案引了进来，最后每天半夜都在处理告警。这就是典型的没有从总拥有成本角度考虑问题。
2.3 组织与架构的纠缠：康威定律在起作用
聊架构，永远绕不开康威定律。1968 年，梅尔·康威提出的观点到今天依然精准：设计系统的组织，其沟通结构会体现在系统的架构上。换句话说，如果你的团队分成 A、B、C 三个组，但系统却是铁板一块的单体应用，那么最终要么组织被迫重组，要么系统被迫拆解——两者之间一定会发生某种强制的对齐。
我在一家公司见过活生生的案例。业务线分成了好几个事业部，但底层的订单系统还是一个大单体。每个事业部都要在这个单体上改需求，代码冲突、发布窗口、权限控制……所有问题都来了。最后迫不得已，花了整整一年时间把单体拆成了多个服务，服务边界恰好就是事业部的组织边界。
康威定律给我的启示是：架构设计不能脱离组织设计单独进行。如果你的目标架构是微服务，那组织同步进行调整，让每个团队对服务有完整的拥有权。反过来说，如果你暂时没有能力调整组织，那技术架构就不要盲目追求“先进”，要选择与当前组织形态匹配的复杂度。很多企业架构转型失败，核心原因不是技术不行，而是组织没有跟着变。
2.4 为什么临时判断永远替代不了架构
回到标题里的问题：为什么企业靠临时判断永远不够？我用一句话总结：临时判断是点状的、无上下文的、无记录的决策，它无法形成体系性的约束，也无法支撑系统的长期演进。
展开说，有三点。
第一，临时判断没有上下文。你今天为了赶工期，跳过统一的分库分表方案，直接在业务代码里做了个临时表分离。这个决定放在当下可能“效率最高”，但三个月后，当系统需要做数据迁移时，没人知道这堆散落的逻辑到底是怎么设计出来的。架构的价值恰恰在于，它强制你思考决策的上下文：这个决定在未来会被什么场景影响？它和其他决策之间的关系是什么？
第二，临时判断没有反馈回路。架构决策之所以需要被记录、被评审、被回顾，是因为我们需要从结果中学习。你做了一个技术选型，半年后发现选错了，如果当初没有记录下决策时的假设和预期收益，你就无法判断究竟是哪里判断失误，也无法在下一次避免同样的错误。临时判断就仿佛是闭着眼睛开车，既没有仪表盘也没有后视镜。
第三，临时判断只优化局部和当下，不优化全局和长期。架构的功能之一，是在决定之间建立起“权衡”的桥梁，让你清楚地知道：这个选择提升了性能，但牺牲了可维护性；那个选择带来了灵活性，但增加运维成本。没有这层桥梁，组织做的所有决策都是孤立的，它们互相冲突、互相抵消，到最后整体复杂度爆炸。
3. 用架构决策机制替代临时判断：一套能落地的做法
讲完了“为什么”，接下来分享一些我实际用过的、能落地的做法。这些方法不涉及什么高深的理论，但每一条都是从项目和组织的真实反馈里磨出来的。
3.1 用ADR把决策显性化
ADR 是 Architecture Decision Record 的缩写，也就是架构决策记录。这个东西在业界已经不是什么新鲜概念了，但我发现真正坚持用的团队少之又少。很多团队连需求文档都懒得写，更别说记录架构决策了。
一个标准的 ADR 一般包含这样几个部分：
- 状态：提议中、已接受、已废弃、被取代
- 背景：我们面对什么问题，有什么约束条件，目标的上下文是什么
- 决策：我们最终选择了什么方案
- 后果：这个决策带来的正面和负面后果，以及后续需要关注的信号
举个我实际写过的例子。当时我们面临一个选择：订单系统要不要引入分布式事务。背景是订单创建后需要同步更新库存、优惠券、积分三个系统，三个系统都分布在不同的服务里。临时判断的做法是“先直接调，出问题再说”。但我们记录了一条 ADR，写清楚了决策：采用本地消息表 + 最终一致性的方案，接受“库存扣减有秒级延迟”的后果，但换取“核心链路不依赖跨服务强一致”的可用性。半年后，这个方案确实遇到了一些边缘场景的问题，但因为 ADR 里写清楚了当初的假设和权衡，团队很快就定位了问题出在“假设库存系统响应永远在 3 秒内”，而不是整个架构方向错了。
ADR 最大的价值不是文档本身，而是强迫决策者把“为什么”说清楚。哪怕只有一页纸，它也会让你在拍板之前多思考一轮，这个思考本身就是价值。
3.2 用效用树做权衡：ATAM的轻量落地
架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）是卡内基梅隆大学软件工程研究所提出的一套方法论。听起来很学术，但它的核心工具——效用树——其实非常好用，而且能在不重流程的情况下落地。
效用树的做法是这样的：从系统的效用（也就是系统为什么存在）出发，把它拆解成几个关键属性，比如性能、可用性、安全性、可修改性。每个属性下面继续拆解成具体的场景，每个场景用“刺激、来源、环境、响应、响应度量”来描述。最后，给这些场景排优先级。
举个例子。一个电商系统，它的效用是“让用户顺利完成交易并持续使用”。拆分下来：
- 可用性：支付链路故障时，系统能否在 30 秒内完成自动切换，保证 99.99% 的可用性？
- 性能：大促高峰期，订单详情页 P95 响应时间能否低于 500 毫秒？
- 可修改性：新增一种支付方式，能否在 2 人/天内完成开发和上线？
- 安全性：用户支付信息能否做到全链路加密且满足合规要求？
这些场景列出来之后，不需要写一份几百页的架构评估报告，只需要开会讨论一个问题：哪些场景是“必须满足”的，哪些是“希望能满足”的，哪些是“暂时可以不满足”的。排完优先级，架构资源怎么投、每一层该做到什么程度，心里就有数了。
我建议从 TOP 5 个核心场景开始做起，贪多嚼不烂。先把最重要的 5 个场景梳理清楚，让团队的每个人都对“这个系统最重要的事是什么”达成共识，这比做一百页的架构文档管用得多。
3.3 架构评审：不是卡流程，而是补盲区
很多公司一提到架构评审，开发就头大，因为评审会往往开成了“批斗会”。但实际上，架构评审如果设计得当，它不是一个卡流程的关卡，而是一个补盲区的机会。
我的经验是，评审范围不要一开始就铺得太广，只评那些“高危决策”：跨团队的系统接口、核心数据模型变更、新技术选型、涉及安全的设计。什么样的决策算高危？最简单的判断标准是：这个决策如果错了，需要返工的工作量是否超过 5 人天？如果超过，就值得花 30 分钟来一次评审。
评审流程也应该是轻量的。提案人提前写一页纸的决策说明：背景是什么、我打算怎么做、我考虑过哪些方案、为什么选这一个、主要风险在哪。评审会 30 分钟，参会的人控制在 5 个人以内，最后必须产出明确的结论：通过、打回、或者附条件通过。最忌讳的就是开完会没结论，大家在会上吵了一通，散会后又各自按自己的想法干。
做了几年之后我发现，评审真正的价值在于“被迫表达”。很多时候，一个方案写下来、讲出来，自己就能发现问题。哪怕评审的结论是不通过，写方案的人也不会白干，因为他被迫梳理了一遍自己的思考过程，这一遍梳理就够了。
3.4 技术债治理：把临时方案变成显式债务
我前面说临时判断一定会产生技术债，但技术债本身并不可怕，可怕的是看不见的技术债。所以，技术债治理的第一步，就是让债务显性化。
我们团队的做法是建一个技术债清单，每个条目记录：债务是什么、什么时间引入的、当时的背景是什么、负责人是谁、建议的偿还时间是什么时候。每季度做一次技术债盘点，按照影响面给债务定级：影响性能的、影响可用性的、影响安全性的、影响可维护性的。然后每个迭代固定拿出 10% 到 20% 的人力来还债，优先还那些影响大、偿还成本低的。
这里有个容易被忽略的点：技术债不一定都是坏事。有些“债务”是刻意的、划算的——比如为了赶一个重要的业务窗口，临时用了某种简化方案，这个代价是值得的。但如果这笔债务没有被记录、没有被计划偿还，它就变成了“坏账”。架构治理要做的事情，就是把每一笔债务都变得“有意识”。
我自己的习惯是，每次允许团队做“临时方案”时，必须在代码里、文档里同时留下一个 TODO，内容不仅是“需要优化”，还要写清楚“为什么当初这么做的”。这比单纯写 TODO 有用得多。
4. 不同领域的架构实践：复杂性如何平衡
架构不是一个虚无缥缈的概念，它最终要落到每个具体的技术领域里。这些年我接触过各种各样的系统，从后端微服务到嵌入式软件，从 AI 系统到基础设施，每个领域的“复杂性平衡点”都不一样。挑几个典型的聊聊。
4.1 后端与微服务：边界的代价
后端领域这几年最热门的话题就是微服务架构、分布式架构。很多人有一个误解，觉得微服务是解决所有问题的银弹。但我的观察是，微服务解决的是“组织协作”的问题，而不是“技术性能”的问题。
服务拆分最重要的不是技术，而是边界。你按什么维度拆服务——按业务域、按团队、还是按技术层次？拆完之后，数据归谁所有？跨服务的数据一致性怎么解决？这些都是架构决策。
举一个很实际的例子：分布式定时任务。在微服务架构里，一个很常见的需求是：多个服务都要跑定时任务，比如订单超时关闭、对账单生成、数据同步。如果每个服务自己写一套定时调度，就会出现任务重复执行、时间不统一、无法集中管理等问题。合理的架构方案是搭建一个独立的调度中心，把任务的定义、触发、执行、监控都收拢到一起。这个决策看起来不大，但它影响了后续所有定时任务的开发和运维方式，值得用 ADR 记录下来。
再比如数据库架构。很多团队业务发展到一定量级，就会面临分库分表的决策。分库分表是典型的“高成本换高容量”方案，它带来的不仅是开发复杂度，还有分布式事务、全局 ID、跨库查询等一系列问题。在这个决策上，临时判断的成本极高：你分错了键，数据迁移就是一场灾难。
4.2 嵌入式与汽车电子：从集中到分布的演进
嵌入式软件和互联网后端是气质很不一样的两个领域。后端可以不停迭代，嵌入式要面对的往往是无法随时更新的硬件环境，这让架构决策变得更加“一锤定音”。
拿 C51 单片机这种比较经典的场景来举例。如果你要在 C51 上做一个支持远程升级（OTA）的固件，就必须在架构层面考虑 boot 和 app 的分区设计。一个关键问题是中断向量表怎么处理：升级完跳转到新 app 后，中断向量表需要重新定位，否则中断来了程序就跑飞。这个看似很小的架构决策，如果没想清楚，设备升级后就直接变砖。
汽车电子领域，AUTOSAR 是典型的架构标准化产物。为什么车企和供应商要花那么大的力气去搞一套标准化的软件架构？因为一辆车里可能有上百个 ECU（电子控制单元），分别来自不同的供应商，如果没有统一的架构约束，整个车辆的软件集成、升级、维护就是一场噩梦。
再往大了看，智能汽车的电子电气架构正在从分布式 ECU 走向域集中、再走向中央计算。这个演进背后的驱动力是什么？是软件定义汽车的需求。当车辆的核心竞争力从硬件转向软件，架构就必须能做到“硬件预埋、软件升级、算力集中”。这背后是一系列极其复杂的架构权衡：算力怎么集中、网络怎么分区、功能安全怎么保证、数据怎么管理。每一个问题，都不允许你靠“临时判断”来糊弄——因为车是要上路的，一个设计失误的代价是安全事件。
4.3 AI与Agent架构：新复杂性需要新架构
AI 系统这两年发展非常快，很多人觉得 AI 系统不需要传统架构了。我完全不认同。恰恰相反，AI 系统更需要架构治理，因为它的复杂度和不确定性都比传统软件高得多。
拿大模型推理服务来说，为什么大家都在关注 Transformer 架构、MoE 架构？因为不同架构直接决定了推理成本、延迟和效果之间的平衡。MoE（混合专家）架构的核心思想是把模型拆成多个“专家”，每次推理只激活其中一部分参数，用“总参数大、激活参数小”的方式平衡效果与算力。这种架构选择，本质上就是一次巨大的架构权衡。
再说到企业级 Agent 架构，这是最近特别火的话题。一个 Agent 系统要处理意图识别、工具调用、上下文管理、人机协同、可观测性等一系列问题。很多人搭 Agent 系统的方式是“先让它跑起来再说”，但这恰恰是最危险的。因为 Agent 的行为天然带有随机性，如果架构层面不设计好意图路由、工具权限控制、对话状态管理、审计日志这些模块，一旦上线，出问题的概率是百分之百。
我也关注到一些新发布的模型架构解读，比如 DeepSeek 的 V4 系列，很多分析都会提到它的 Flash 架构如何在推理效率上做文章。这类分析的背后逻辑其实和传统架构是一样的：在效果、速度、成本之间找一个对应用场景最有利的平衡点。这就是架构思维在 AI 时代的价值。
4.4 基础设施与工具链：架构约束来自底层
最后聊一下基础设施层面。很多做应用开发的工程师对底层架构不敏感，觉得 ARM、x86、指令集这些东西离自己很远。但实际上，底层架构决定了上层软件的运行约束。
举个具体的例子：为什么嵌入式开发要专门用 arm-gcc 工具链做交叉编译？因为 x86 和 ARM 的指令集架构不同，x86 上编译出来的二进制无法直接在 ARM 处理器上运行。这就是架构约束的典型体现。类似的，为什么有人会问“VMware 装 Ubuntu 应该选 ARM 还是 x86”？因为虚拟机的指令集架构必须与宿主机物理机的架构匹配，选错了根本启动不了。
这些底层架构的知识，对系统架构设计师来说尤其重要。因为软件架构不是悬空的，它最终要跑在某一种硬件架构上。你在设计高可用方案时，要考虑底层架构是否支持故障域隔离；你在设计存储方案时，要考虑底层架构对磁盘、网络、内存的访问方式。忽略底层约束的架构设计，就是在沙地上建高楼。
5. 架构能力建设：从个人英雄到组织能力
5.1 架构师的核心职责：做决策并承担后果
关于架构师这个角色，我一直有一个观点：架构师的核心产出是决策，不是图纸。
很多团队对架构师的期待是“画一张完美的架构图”。但架构师的真实工作远不止这个。他要在无数个看似都合理的选项中做出取舍，并且要为这个取舍的后果负责。技术选型选错了，架构师要承担；服务拆分粒度过细导致开发效率下降，架构师要承担；过度设计导致交付变慢，架构师也要承担。这个角色不是一个“顾问”，而是一个“决策者”。
做了这么多年架构，我自己最大的体会是：真正难的不是做出正确的决定，而是当你做出决定后，要持续跟踪它、验证它，并在必要的时候承认“我错了”。大多数组织不是没有架构能力，而是没有允许架构师“认错”的文化。每个人都怕自己的决策被证明是错的，所以宁愿不做决策，或者做模棱两可的决策。这比任何技术问题都要致命。
5.2 让架构决策成为团队共识
架构不能是架构师一个人的英雄主义。如果只有架构师理解系统为什么这么设计，团队里的其他人只是机械地执行，这个架构一定会慢慢腐化。因为架构的维护和演进靠的是每一个工程师的日常开发习惯。
所以，架构能力的建设一定要落在团队共识上。怎么形成共识？靠的不是宣讲，而是参与。让一线的开发参与到架构评审里来，让他们看到“这个决定是怎么被讨论、被权衡的”。当开发自己经历过一个方案被驳回、另一个方案被采纳的过程后，他对架构的理解会比看十份文档都深刻。
这里有一个小技巧：每次架构决策落地后，找机会把它做成一次小型的内部分享。不用讲得多高深，就讲清楚“我们遇到了什么问题、有哪些选择、为什么选了这个、踩了什么坑”。这种分享对分享者是一种复盘，对听众是一种最好的培训。日积月累，团队的架构判断力会肉眼可见地提升。
5.3 架构治理的落地心得
最后，分享几个我在架构治理落地过程中的实操心得。
第一点，从最小的闭环开始。不要一上来就搞一个庞大的架构治理体系，那注定会失败。先挑三个最重要的系统，为它们各写一份 ADR；先做一次 30 分钟的评审，只评审那个你最近最担心的跨团队接口。小闭环跑通了，再慢慢扩大范围。
第二点，把“不做什么”也记录下来。很多时候，架构文档里只写了“我们选择了什么”，很少有人写“我们放弃了什么”。但恰恰是那些被放弃的选项，最能体现架构决策背后的权衡。从今天开始，每次做技术方案时，多写一行字：我考虑了哪些替代方案，为什么不用它们。这一行字，往往比整个方案本身更有价值。
第三点，警惕形式化的评审。架构治理最大的敌人是形式主义。如果评审已经变成了过场、ADR 已经变成了写完没人看的文档、效用树已经变成了为了“完成任务”而画的图，那你不如把这些流程全部砍掉。治理的目的是让决策更高质量，而不是让流程看起来更完善。
架构之道本质上是一个组织持续做高质量决策的能力。它不是一次性工程，而是一种需要长期维护的组织习惯。我在实际项目中最大的感受是，与其花大力气去引入一个“完美的架构框架”，不如先着手建立一个“让错误决策能被及时发现和纠正”的机制。机制有了，好的架构会自己长出来。