很多人一听到 FDE，就会顺着一套角色图来理解：Echo 负责业务，Delta 负责开发，FDPM 负责项目推进。
但在我看来，这三者首先不是必须一一对应的岗位，而是三类不同的能力：谁来判断该做什么，谁来把它做出来，谁来把客户和项目推进下去。
一个人能不能兼任，取决于他是否同时具备这些能力，以及眼前项目和行业的复杂度，而不是组织图上有没有三个名字。
先说明一下：FDE 目前没有特别统一的定义。Echo、Delta、FDPM 是 Palantir 最早提出的三种角色，或者说三类能力；它们不代表每家公司都有这些固定岗位。
Echo：先确认这是不是一个值得做的场景
Echo 更像业务专家。
他要做的不是把客户说的每个需求都记下来，而是先判断：这是不是一个真实存在、值得投入的业务问题。
一个高价值场景，通常至少有几个特点：
1. 一线同学真的在这样做，而不是经过几层转述后想象出来的需求。 2. 它高频、消耗人力。 3. 上 AI 之后，结果能客观衡量。 4. 错误要么有足够容忍度，要么能由人工快速兜底。
这里的“快速兜底”很关键。
如果 AI 产出以后，人工还要花和原来亲自做一遍差不多的时间去审核，那它没有真正减少工作量。更合理的情况是：人只需要快速判断，处理少数例外。
业务专家的价值，尤其体现在陌生行业里。
比如做制造业项目时，如果听不懂行业术语、不知道默认的业务常识，也抓不住对方真正想解决的问题，就很容易问不到点子上，最后找偏场景。真正懂业务的人能和一线人员高频沟通，顺着一个问题继续追下去，识别哪些才是高价值的机会。
Delta：把可行的场景做成能长期运行的系统
Delta 更像一名全栈工程师。
他接到的不是一句模糊的“帮我做个智能体”，而是已经被翻译过的业务场景：要解决什么问题，什么结果算成功，哪些环节必须保留人工。
Delta 要把它先做成 Demo，再逐步推向生产环境。
Demo 能跑，不等于能上线。
一个 Demo 可以暂时跳过权限、数据安全、稳定性、性能、可维护性和可扩展性；但这些问题到了生产环境，一个都绕不开。甚至在做 Demo 时，就应该先判断这条路有没有走到生产环境的可能。一个未来根本无法工程化的 Demo，再漂亮也没有意义。
所以 Delta 不只是“把功能写出来”。他还要考虑系统集成、测试、灰度发布、异常处理，以及怎样尽量降低对线上环境的影响。
FDPM：把项目持续往前推
FDPM 相当于前线部署项目经理。
他负责整个项目的推进、协调和进展管理，也可能主动与企业方做协同和汇报，并处理项目过程中出现的问题。
在很多 FDE 团队里，有经验的工程师或开发者本身就具备项目管理和推进能力。因此，常见的协作形式是：一位业务专家，加上一位兼任项目经理的全栈工程师。
一个人能处理得过来，就可以兼任；处理不过来时，再把这部分工作分出来。
AI 改变的，不只是开发速度
以前把能力拆给多人，很大一部分原因是工作量太大。
写代码、跟客户沟通、整理文档、收集信息、做方案，这些事都需要大量时间。现在，AI 能帮助全栈工程师更快开发，也能帮助不了解行业的人提前补基础认知：查术语、整理资料、把录音转成文字稿，再从对话里归纳问题。
这不代表 AI 能让一个人立刻成为行业专家。
但它确实让一个原本不懂业务领域的人，更快获得基础理解，成为“半个业务专家”。原来被不同角色分别承担的一些工作，现在可以被一个更强的个人能力组合覆盖。
我自己在电商行业，就可以把这三类事情合在一起做：既理解场景，也能做工程实现，还能推进项目。
但换到偏制造业的项目，因为我对行业领域知识还不够深，就必须有真正懂业务的人配合。这时更适合的组合，是业务专家加上一位兼任项目推进的全栈工程师。
分工的目的，不是把组织图画得更复杂
无论是一人兼任，还是多人协作，最终都不只是为了完成一个客户项目。
Echo 更适合把反复出现的业务问题和行业判断沉淀下来；Delta 在现场也会发现哪些能力值得复用。只有把这些经验回流成 Skill、模板、测试方法或产品能力，下一次交付才可能更快、更稳。
所以，对 FDE 团队来说，更值得先问的不是“我们要配几个人”，而是：
1. 这个场景是否真实、高频、可衡量，并且能由人工快速兜底？ 2. 团队里是否有人既懂这个行业，又能把问题推进成可运行的系统？ 3. 这次现场交付留下的东西，下一位客户能不能复用？
AI 会让更多能力合在一个人身上。
但遇到陌生行业、复杂业务和真正的生产环境，能否找对问题、做成系统、推动协同、沉淀经验，仍然决定了这是不是一次有效的 FDE 落地。
关注赵指导，每天学习一点小知识，3个月让自己刮目相看。
