这篇厘清 FDE 与 SA 这对最容易「看起来一样」的岗位。
最值得拿走的是一条试金石：方案出了问题，谁在客户现场修到凌晨。SA 的责任通常终止于架构评审通过，FDE 的责任要延续到系统在生产环境稳定运行。最容易误用的判断是拿架构深度论高下——SA 的架构视野通常更宽，FDE 的落地密度更高，两者不在同一根轴上比。
相比站内已有的售前与顾问对比，这篇的增量是指出 AI 交付正在模糊两者边界：模型 API 化让架构选型变轻，让端到端实现变重，趋势是 SA 岗位向 FDE 化演进而非相反。补充一个选岗的现实参考：SA 在传统企业软件里的岗位存量更大，FDE 在 AI 交付里的机会增速更高；跨界迁移的主要成本是现场履历，建议用一两个驻场项目完成转换，而不是纯靠跳槽换 title。
读完建议做一件事：梳理你所在团队的角色矩阵，标出每个角色对「生产稳定运行」是否兜底，缺口就是用人风险。
—— FDEChina编辑部 · 犀利评审
FDE 和解决方案架构师（SA）有什么区别？
最直接的回答：解决方案架构师输出的是架构设计与选型建议，交付责任通常终止于方案评审通过；FDE 输出的是能上生产的系统，责任一直延续到客户的业务流程稳定跑起来。有一个粗暴但好用的试金石——方案在客户现场出了问题，凌晨两点被拉起来修的人是谁：多数情况下是 FDE，不是 SA。
逐维度看。交付深度上，SA 的核心产出是架构图、技术选型报告和非功能性设计，动手写业务代码少；FDE 两头都做，先画图再撸代码，交付密度高得多。责任边界上，SA 通常只对方案的「技术正确性」负责，场景最终有没有价值由客户与交付团队消化；FDE 对「场景能不能成」兜底，这正是两者最本质的分野。能力画像上，SA 强在体系化的架构视野、跨系统集成经验与技术说服力；FDE 强在工程落地速度、现场应变和需求发现的手感。客户关系上，SA 往往出现在售前与关键评审节点，FDE 则长期驻在场内。与售前侧的关系可进一步看 FDE 与售前的区别。
为什么这两个岗位常被混为一谈？因为在传统企业软件时代，两者经常在同一个项目里前后接力，且国内不少公司确实让 SA 兼做实施。但大模型时代正在改变这个结构：模型能力以 API 形式提供，架构选型的自由度变小、复杂度下降，真正难的变成了最后一公里——数据接进来、评测立起来、流程嵌进去、效果稳得住。这恰好是 FDE 的主场，也是 FDE 演化分析里描述的趋势：架构角色在向落地角色倾斜。
怎么选岗？如果你享受宽视野的设计与说服、不想长期驻场，SA 更合适；如果你喜欢从模糊需求一直做到系统上线、愿意为结果兜底，FDE 更合适。两者并非单行道：SA 转 FDE 主要补工程手感，FDE 往架构走主要补体系化设计。更完整的相邻岗位地图，可从 FDE 是什么和 FDE 和产品经理的区别进入。