这张卡厘清一个容易被头衔掩盖的差异：解决方案架构师画图纸，FDE 盖房子并负责验收。
核心拆解：SA 的产出物是架构文档、选型结论与集成蓝图，价值在约束先行——把非功能性要求（安全、合规、可扩展性）在动工前锁定；FDE 的产出物是能跑的系统。最容易误用的判断是「有 SA 的方案就够了」，实际大型项目里 SA 的架构评审是 FDE 方案获得内部合法性的前提，两者是上下游而非替代关系。评估 SA 方案的实用标准是：每一项架构决策是否附带可验证的假设与验证方式。
增量判断：AI 项目让文档式架构工作部分失效——模型选型、上下文设计、评测策略只能靠做实验回答，SA 也被要求能写 PoC，这正是 SA 向 FDE 迁移的能力缺口所在。
行动建议：评估候选方案时，检查架构文档里有没有可验证的效果假设，没有就要求补一轮实验。这比逐页评审 PPT 的版式有意义得多，一轮实验胜过十页假设。
—— FDEChina编辑部 · 实战派
定义
解决方案架构师（Solutions Architect）负责在售前与交付早期把客户需求翻译成技术架构与集成蓝图，输出架构设计、技术选型与非功能性约束，工作重心在设计而非实现。
展开
与 Forward Deployed Engineer（FDE）的通俗辨析是「画图纸还是盖房子」：SA 的产出常止于文档与评审结论，FDE 的产出是能跑的系统并负责验收。但两者是上下游而非竞争关系——在大型企业项目里，SA 的架构评审、安全与合规约束是 FDE 实现方案的前提，FDE 若绕过这一层直接动手，后期集成与审批会付出成倍代价。与解决方案工程师（SE）相比，SA 更偏蓝图与全局权衡，SE 更偏可运行原型的快速验证。
AI 项目正在改变这个角色的边界：模型选型、上下文与评测设计这类问题很难靠文档推演回答，只能做实验。纯文档式 SA 在 AI 项目里说服力下降，被要求能搭建验证环境、跑对比测试。对个人而言，SA 向 FDE 过渡的主要缺口是工程实现与评测能力，而不是架构知识。