前言
干技术的人大多是从代码量堆起来的。架构师不一样——你每天做的事里，写代码反而是少数，更多是：开会、写设计文档、跟 PM 吵架、跟兄弟团队撕责任、给新同学讲"为什么这里要这样写"。
前面 94 篇讲的都是"硬"工程。这一篇反过来讲"软"——但它决定你能走到哪一步。
一、架构师的三件事
我把架构师的工作浓缩成三件事：
下面分别讲。
二、写决策：ARID 框架
最常见的失败是"我能想到的细节都写了，但别人看不到重点"。用 ARID 模板可以救：
Action（动作）：一句话说清要做啥。"把 IM 模块从单架构 App 拆成独立 Module"
Reason（原因）：为什么一定要现在做。"下一季度新增 3 个业务线接入 IM，再不分层就崩"
Impact（影响）：不做会怎样，做的代价是什么。"不做：第 4 个业务接入时联调 3 周；做：2 周迁移 + 2 周新业务并行"
Decision（决定）：明确要选的路径。"决定 A：迁移至 Feature Module；不选 B：插件化"
任何技术评审会上，对齐 ARID 四件事所需的时间至少砍半——因为大家知道接下来要问什么。
三、推共识：你不是来"赢"的
工程师最容易犯的错是在评审会上"赢"。注意：赢了技术观点，输了推进效率，是最差的交易。
推共识的几条经验：
先问"为什么是他们来找你"——多数冲突背后是 KPI 不对齐，把对方的目标翻译成技术语言。
找最小争议点先达成——不要一上来就推整套方案；先解决"我们都同意的部分"，剩下再慢慢聊。
会议前 1:1 沟通——会上反对的 80% 内容，提前 1:1 聊过就消失。
带数据——不要凭经验说服。"我做过，所以应该这样"是最容易输的论点。"压测显示 API P99 在 500QPS 时落到 800ms"才是硬通货。
预留退路——把对方的备选方案写成"备选 1"，不要写成"被否掉的方案 0"。这是给对方台阶。
四、带梯队：让 1 个我变成 5 个我
最痛的认知转变：从"我做了这件事"到"我们一起做这件事"。
管理上有一个标准——"如果我请假一周，团队能照常出活"。达不到，说明你的梯队没起来。
具体动作：
写说明书：把你负责的所有决定写成"如果是我来做的，会这样做"的文档；
永远带 1 个学徒：每个 PR 找一个初级工程师做 owner review，你做 final review；
拆分任务到"能独立交付"：能交给别人做的，绝不自己包圆；
故意留 bug：在某个非核心模块故意放一些"只需要 5 行就能修"的问题，让新人来熟悉代码。
五、一个反面案例：架构师越权
某厂架构师把所有架构决策都收归"架构委员会"。结果：
业务团队遇到突发问题要改架构，必须等周会；
委员会会议 3 周没结论；
业务方绕过去自己写代码，架构"实际不存在"。
架构师的工作是让业务方有能力自己做正确决策，不是替他们做决策。
六、怎么写一份"会有人看"的设计文档
设计文档（Design Doc / RFC）最大的失败是写完没人看。要让它"被看完"，关键是：
起手 30 秒给结论：开头一句话讲清楚要做什么，让读者能在 1 分钟内决定要不要继续看；
章节用可视化的方式分割：每个长章节前放一个 ASCII 架构图，让读者知道下面在讲哪一块；
正反方案并列：不要先讲 A 再说 A 好，要 A vs B vs C 三个都说清楚，最后再选；
可反对的具体细节：避免"整体上更好"这种说法，要给具体可反驳的论据。
文档模板示例：
# RFC-2026-08：IM 模块拆分
**TL;DR**：IM 模块从 `app/main` 拆到独立 module，预计影响 23 个文件，4 周工期。
## 现状
- IM 代码 1.8 万行，半年新增 7000 行
- 任何 IM 改动 → 整体构建耗时 +25%
- 已影响其他业务的依赖解耦
## 方案
（详细 3 个方案对比...）
## 结论
方案 A，预计实施 4 周，业务影响 0.5 周。
七、跨团队协作的"软规则"
软技能的真正功夫是：用最小的代价把事情做成——而不是"证明你是对的"。
八、技术领导力 ≠ 资深工程师
资深工程师是把单件事做深。技术 leader 是把"做事的方向"定义出来。
能力跃迁分四级：
独立写好代码（P5）
独立完成项目（P6）
定方向，影响团队 5+ 人（P7）
定生态，影响公司 50+ 人（P8）
大多数人卡在 6→7，觉得"我代码这么强，怎么还是 P6"。问题就是：定方向、推共识、带梯队，三件事里有两件没做。
小结
架构师是个"做减法"的职业：少写代码、多做决定、把别人培养成自己。下一篇文章我们换个主题——亿级 App 性能治理复盘，看看别人的实战是怎么用上面的思路做事的。
参考阅读
《An Elegant Puzzle: Systems of Engineering Management》— Will Larson
Stripe RFC 文化公开文档
ARID 决策框架（Charity Majors 博客）