从代码到架构师的思维跃迁不是写更多代码而是做更少决策一、你升了 Senior依然每天写 200 行代码但发现团队产出反而下降了从写代码的人到设计系统的人最大的思维方式转变不是能力提升——你能写的代码量和两年前差不多——而是从解决一个问题变成避免产生问题。一个好的架构决策可以消除一大批需要写的代码、需要修的 bug、需要协调的跨团队沟通。这个转变有三个层次从单人产出到团队产出的乘法器、从给定约束内写最优代码到挑战约束本身、从技术正确性到系统合理性成本、维护、人因。技术正确只是门槛——一个方案技术上正确但运维成本过高、team 能力不匹配、业务方不买账这不叫好架构。二、底层机制与原理剖析三个核心思维转变转变一从解决一个问题到避免产生问题。架构师最重要的产出不是我设计了这个系统而是因为我的决策团队没有在这个坑里浪费两周。一个清晰的服务边界定义可以避免三个团队之间的需求依赖循环。一个合理的技术选型可以避免频繁的重构。架构师的价值不是正向的做了什么而是负向的避免了什么。转变二做可逆的决策。不是所有架构决策都需要深思熟虑。Jeff Bezos 的双向门理论可逆的决策Two-way door应该快速做出不可逆的决策One-way door才需要深度分析。选择用 React 还是 Vue——如果团队规模不大且项目周期短这是双向门三个月后改的代价不高。选择数据库——关系型 vs 文档型——这是单向门数据迁移成本极高。转变三认知负荷管理。好的架构降低系统的认知负荷。一个新人看你的架构花 10 分钟还是 10 小时能理解整体结构——这就是认知负荷的直接衡量。架构不是越复杂越高级——简洁、一致、可预测的架构是最好的架构。每增加一层抽象都在增加团队的认知成本。如果抽象的收益减少的重复代码大于认知成本值得加否则就是过度设计。三、架构决策记录ADR模板# ADR-042: 选择 vLLM 作为 Agent 推理引擎 ## 状态 已接受2026-07-24 ## 上下文 当前 Agent 系统使用 OpenAI API 调用日均推理成本 ¥3,000。 团队有两台 A100 GPU 闲置。需要决策 1. 是否迁移到自建推理集群 2. 选择哪个推理引擎vLLM / TGI / TensorRT-LLM ## 决策 使用 vLLM 作为推理引擎部署在自建 A100 集群。 ## 考虑的替代方案 ### 方案 A: 继续使用 OpenAI API不迁移 - 优势零运维、零风险 - 劣势成本不可控、对 OpenAI SLA 无控制权 - 不选的原因有闲置 GPU 不使用是浪费 ### 方案 B: vLLM选择 - 优势开源活跃、PagedAttention 显存效率高、兼容 OpenAI API - 劣势社区不如 TGI 成熟、对某些模型如 Mixtral支持不完善 - 选择原因团队已有 PyTorch 经验、API 兼容性降低迁移成本 ### 方案 C: TGI (HuggingFace) - 优势HuggingFace 生态集成、模型支持最全 - 劣势对非 HuggingFace 模型如 GPTQ支持弱、配置复杂度高 - 不选的原因我们主要的推理模型Llama-3在 vLLM 上跑得更好 ### 方案 D: TensorRT-LLM - 优势性能最高受益于 TensorRT 优化 - 劣势模型支持最少、需要模型转换和编译增加运维复杂度 - 不选的原因运维成本与性能收益不成比例 ## 后果 ### 正面 - 推理延迟降低约 40%本地 GPU vs 网络调用 OpenAI - 月推理成本从 ¥90,000 降至 ¥0使用自有 GPU - 完全控制模型版本和推理参数 ### 负面 - 需要专人维护 GPU 集群预计 0.3 FTE - GPU 故障时需要手动切换初期无 HA - 模型更新需要手动操作vs OpenAI 自动更新 ### 风险 - 如果 GPU 资源不够需要扩容备选方案混合使用 vLLM OpenAI - vLLM 社区如果变冷长期维护成本可能上升 ## 可逆性 中等。如果一年后 vLLM 不再是最优选择切换到 TGI 或 TensorRT-LLM 的代价是 2-3 周的迁移工程。 ## 评审人 - 张三 (Tech Lead) - 李四 (ML Infra)四、边界分析与架构权衡什么时候不该做架构决策团队规模 5 人——过度架构带来的认知成本超过收益项目处于 MVP 阶段——快速验证 架构完美。等到 PMF产品市场匹配确认后再考虑架构重构技术不确定性极高——你不知道用户该怎么用这个系统时先做功能而不是先定架构架构师的常见陷阱需求会变所以架构要灵活——过度抽象带来的代价比需求变更还大。一个灵活度 300% 但复杂度 300% 的系统不如一个灵活度 50% 但复杂度 50% 的系统然后用两周重构用最前沿技术——前沿技术的生态支持文档、社区、工具链往往不足引入的风险超过技术先进性带给的好处我的方案在技术上是最优的——技术上最优 ≠ 系统上最优。方案需要考虑运维成本、团队学习成本、与现有系统的集成成本五、总结从工程师到架构师的跃迁不是写更多代码或做更大项目而是转变解决问题的方式从解决一个问题 → 避免产生更多问题从编码能力 → 决策能力。架构师的核心产出不是代码是高质量决策。做可逆的决策快速、低风险、降低认知负荷简洁 灵活、同时考虑技术和系统合理性不是技术上最优的是对团队和业务最合适的。