12.1 A 角色认知（4 问）

本章导读

本 节 目 标

• 能用「产出物归属」说清 FDE 与驻场实施、售前角色的差别，判断不写代码做 FDE 的可行路径与底线。
• 能应对项目推进的四类高频困境（需求说不清、客户自带方案、一线抵触、Demo 上线即崩），给出对应的操作动作。
• 能用「第二个场景被用过一次」的资产标准检验沉淀质量，运用信任四问与三态溯源处理客户信任问题。
• 能独立排查 Skill 不触发、企业下发不见效、知识库未被引用、MCP 连不上四类产品操作问题，并按上手清单启动岗位实践。

入门阶段最容易产生的 21 个疑问，按角色认知、项目推进、能力沉淀、产品操作、管理端与 WMA 五组归类，最后附一份回到岗位的上手清单。建议先通读一遍建立索引，遇到具体场景再回来查。

Q1：FDE 和驻场实施、售前解决方案架构师，到底差在哪？

差在产出物的归属，不在工作内容的表面相似度。

驻场实施的产出是「一个跑起来的系统」，交付完成即结束；售前解决方案的产出是「一份客户认可的方案」，签单即结束。FDE 的产出是两份：客户侧拿到可运行的结果，同时组织侧拿到可复用的资产。

用第 1 章的试金石自查：项目结束后，如果只有客户手里多了个东西，你的组织什么都没多——那就还是实施。

Q2：我不会写代码，能做 FDE 吗？

可以，而且这条路径正在变宽。

FDE 的能力被拆成 Echo（判断该做什么）和 Delta（把它做出来）两侧。AI 正在系统性降低 Delta 侧的门槛——在 WorkBuddy 这类平台上，配置专家、编排工作流、接入连接器、搭建资料库，大量工作已经可以用自然语言完成，不必写代码。

相反，Echo 侧才是稀缺的：能不能听懂客户业务、能不能判断客户说的是不是真问题、能不能推动组织真的用起来。业务背景强、不会编程的人，走 Echo 路线（有的团队称为 FDPM，前沿部署产品经理，偏客户沟通、需求对齐、测试用例设计）往往比工程背景的人更有优势。

但有一条不能省：你必须自己动手把原型跑出来。不要求写代码，但要求会用平台把想法变成能点的东西。只说不做的角色，就是第 1 章讲的「传话式陷阱」。

Q3：Echo 和 Delta 必须是两个人吗？

不必须。早期小团队里常常一个人同时承担两种能力，这也是成长最快的阶段。

但随着项目变多会自然分化：擅长发现问题、带回经验的人逐渐偏向 Echo；擅长快速做出来、守住质量的人逐渐偏向 Delta。关键是两者的考核标准要不一样——用「交付准时率」考核 Echo，他就不会再花时间去挖真需求；用「知识贡献量」考核 Delta，他会应付式地写文档。

Q4：FDE 团队应该放在哪个部门？

单一归属都有明显缺陷：放销售体系容易被当成签单赠品，沉淀动力弱；放交付体系容易固化成项目制团队；放产品体系有利于沉淀但容易远离一线真实场景。

更合理的是矩阵制：行政上与产品保持强连接，确保经验能回流成产品能力；业务上与销售、客户成功协作，确保贴近客户；考核上既看客户价值也看知识产出。

如果你的团队正在讨论组织归属，把「谁为沉淀负责、沉淀算谁的绩效」这两个问题先定下来，比讨论挂在哪个部门更实际。