优秀的架构不需要胡萝卜，也不需要大棒

# 好架构不需要胡萝卜，也不需要大棒 原文：https://frederickvanbrabant.com/blog/2026-04-17-good-architecture-shouldnt-need-a-carrot-or-a-stick/ 上一篇我写了如何为架构争取支持（[《这对我有什么好处？》](https://frederickvanbrabant.com/blog/2026-04-04-whats-in-it-for-me-architecture/)）。这个话题我越想越觉得值得深挖。 两周前的文章我依然完全认同，但越想越觉得理想状态是：根本不用去“争取”支持。 ## 胡萝卜与大棒 我见过的架构部门几乎都在“执法”。想让软件、工具或方案落地，必须先过架构委员会（或类似组织）。 会上，架构师们审阅一堆必需文档（工件），然后盖章或打回。我称之为“大棒”模式。没人愿意走这套流程：准备成堆材料、遵循各种规范，忙活两周，却被一个素未谋面的委员会一票否决，返工+deadline 模糊。 现实是，大多数人干脆绕开：要么走影子 IT，要么把新项目硬塞进已有“合法”项目里。 另一种做法是“胡萝卜”模式，效果通常好得多：每个项目配一名专属架构师，全程辅导，确保对齐组织规范。可想而知，架构组工作量暴涨，项目方也要额外盯一堆事。 即便架构师包办所有治理和合规，会议依旧少不了。虽然不用直面委员会，但你收获了一位专职“Yes, but”成员。 ## 内部客户 架构师的客户其实是内部同事，不妨换位思考。 你（非架构师）想提个自动化流程的项目，却被告知要先填 N 份文档，再向一群从未谋面的委员会汇报。直属领导都已点头，凭啥还要花两周准备材料，让陌生人拍板？不干。 或者给你塞一个“项目合伙人”，对架构有绝对话语权。会议更多、事项更杂，最关键的是：我的业务流程最后到底长啥样？ 有没有第三条路？ “听说你想做工作流自动化？我们有现成标准，已全网合规，能给你**这些**好处……顺便把安全、日志、法务全包了，再也不用去那些委员会。” 做梦都会笑醒。客户不仅拿到部分现成方案，还直接甩掉安全+法务两座大山，项目周期立即缩短。下个项目我主动找这帮人。 如果现成工作流不完全匹配？那就改，但地基已搭好，只需谈差异，无需从零撕流程。 这叫“铺好的路（paved road）”架构，Netflix 和 Spotify 都在用。 ``` flowchart TD A[项目想法] A -->|大棒模式| B[写文档/补材料] B --> C[架构委员会] C --> D{通过？} D -->|返工| B D -->|通过| F[继续] A -->|胡萝卜模式| H[指派架构师] H --> I[会议+监督] I --> Q[架构师包办治理] Q --> F A -->|铺好的路| K[直接选标准] K --> F ``` ## 最小阻力路径 项目永远走阻力最小的路，这是项目管理本能：降风险、保范围、保工期。 铺好的路正利用这一点：把“正确”做成“最容易”，大家自然默认选它，全员共赢。 更妙的是，不选这条路反而变成“自找麻烦”——自己开路，花时间、背风险。 有人担心这会扼杀创新，因为事事统一。解决方法是设立“创新项目”，专门迭代升级这些铺好的路。 我甚至认为这是首选方式：战略集中在一处制定，再自动落地。 ## 架构à la carte（按需点餐） 再往前一步，做成完全模块化：把架构拆成可插拔的积木，用户按需勾选，就像点菜。 只要做成“人话”界面，就能问：预计多少用户？应用生命周期多长？喜欢方案 A 还是 B？…… 最后把配置单（或自动生成单）扔给架构组，他们复核一下，项目即可开跑。 治理并未消失，架构仍需全局监控。但如果大部分架构靠事后强制，那你已经解决得太晚了。