**架构师（职业角色）**是负责系统结构、边界、关键技术取舍和长期演进规则的技术角色，常见于复杂软件系统、平台系统、企业应用和软硬件结合系统中。
核心问题
系统规模变大后，单个功能能跑通并不代表整体系统可维护。模块边界、接口协议、数据一致性、部署拓扑、安全边界、性能容量和演进路线都会互相影响。架构师解决的是：如何让系统在当前约束下可落地，并在未来变化中仍然可演进。
核心对象
| 对象 | 含义 |
|---|---|
| 架构驱动因素 | 影响设计的关键要求，例如性能、可靠性、成本、安全、上市时间 |
| 系统边界 | 哪些职责属于哪个模块、服务、团队或设备 |
| 接口契约 | 模块之间如何通信、交换数据、处理错误和兼容版本 |
| 质量属性 | 可用性、可维护性、可测试性、可扩展性、可观测性等非功能要求 |
| 演进规则 | 系统如何迁移、如何兼容旧版本、如何处理技术债 |
核心机制
架构师的工作不是只画图，而是把模糊目标变成可执行、可验证、可演进的技术结构：
- 收集约束：明确业务目标、团队能力、既有系统、时间窗口、风险和资源限制。
- 抽象边界：决定系统如何拆分，哪些接口稳定，哪些实现可以替换。
- 做关键取舍：在性能、复杂度、成本、稳定性和迭代速度之间选择可辩护方案。
- 固化契约：用设计文档、接口定义、数据模型、部署方案和评审规则让团队对齐。
- 跟踪反馈：通过实现成本、线上指标、事故复盘和维护体验修正架构。
架构师的权威应来自对真实约束和工程反馈的理解，而不是来自图纸本身。
工程用途
架构师常见于以下场景：
- 多团队共同维护一个大型系统；
- 老系统需要重构或拆分；
- 平台能力需要被多个业务复用；
- 系统对可靠性、安全、性能或合规有较高要求；
- 软硬件、云端、客户端和数据链路需要整体设计。
架构师可以是 IC（个人贡献者） 路线上的高阶角色，也可以由 Tech Lead、Staff Engineer 或 Principal Engineer 承担。是否是管理者，取决于是否有正式人员管理责任，而不是“架构师”这个名称本身。
边界与常见坑
- 架构师不是只产出 PPT 和图。没有实现路径、验证指标和反馈闭环的架构设计不可执行。
- 架构师不是所有技术决策的审批者。过度集中决策会让团队失去上下文和责任感。
- 架构师不等于 Engineering Manager。架构师主要负责技术结构和演进规则，EM 主要负责团队与组织机制。
- 架构设计不能脱离团队能力。理论上优雅但团队无法维护的方案，工程上可能是失败方案。