FDE和解决方案架构师的区别在哪？

把 FDE 和解决方案架构师（Solution Architect）放在同一条时间轴上，区别就一目了然了：SA 的主场在合同签署之前，FDE 的主场在合同签署之后。一个负责让客户相信这事能成，一个负责让这事真的成。两者都重要，但混用会出事。

一、时间轴：签约线两边的人

SA 的典型一天：跟客户开需求会、画架构图、评估技术可行性、准备 POC 演示、配合销售应对招标提问。他的成果物是文档、原型和一份让人愿意签字的信心。

FDE 的典型一天：泡在客户机房调数据管道、跟车间主任对口径、发现三个字段命名混乱当场重构、深夜提交一版补丁。他的成果物是能出数的系统。

这条时间轴解释了很多摩擦。SA 承诺的效果如果脱离现场实际，买单的是后面进场的 FDE。所以在成熟组织里，FDE 会被要求提前介入售前，给方案打上现实主义的补丁。

二、失败代价：一个丢单，一个丢客户

SA 做砸了，后果是单子没拿下，损失是机会成本。这个损失痛，但可控，下一个项目还能再来。

FDE 做砸了，后果是钱已经收了、人已经进场了、系统跑不起来。这时候损失的不只是这一单，是客户对整个 AI 品类的信任。行业里 95% 试点无回报这个数字，很大一部分就堆在这个环节。

所以两者的性格取向也不同。SA 需要乐观和想象力，把可能性讲得动人；FDE 需要悲观和防御性，提前把所有会崩的地方想一遍。让一个人同时干这两件事，通常两头都不讨好。

售前卖的是未来，交付还的是现在。中间那道差额，就是行业信任被消耗的地方。

三、能力结构：广度与纵深

SA 的能力是广度型：要懂云、懂数据库、懂集成、懂安全合规，还要懂客户所在行业的大致运作，能在两个小时的会里把全景讲清楚。深度可以适度让位于覆盖面。

FDE 的能力是纵深型：可以不懂全部，但对本项目涉及的那几层必须能钻到底——数据脏在哪一行、接口为什么超时、模型为什么在这个场景幻觉率高，都得亲手解决。

还有一层软能力差异容易被忽略：FDE 需要在客户现场处理人的问题。有调研显示约 29% 的员工会暗中抵制公司推行的 AI 工具，怕被替代、怕被监控。这类阻力不写在需求文档里，但足以让项目停摆。

四、阿优至简的视角

中小企业往往两个角色都请不起，也不需要请。我们的做法是一人两段：同一个人先做诊断（SA 的活），再做落地（FDE 的活），但把两段的口径强制对齐——诊断阶段承诺的指标，落地阶段必须拿数据回证。

对甲方来说，这样做还有个附带好处：讲方案的人就是干活的人，方案里不敢注水。很多项目的失败不是能力不够，而是从一开始就承诺了做不到的事。

落地前的三条至简建议

1. 对齐口径：要求方案里写的每个指标，都有明确的验证方式和责任人。
2. 让干活的人参与售前：至少让实际交付负责人参加一次现场勘查，再报价。
3. 预留人的预算：把员工培训与沟通成本算进项目，通常占总投入一到两成。

架构图画得再漂亮，不落地就是纸。真正值钱的不是那张图，是把图变成系统的过程中，那些没写在图上的判断。