马金良2026-07-29 来自北京这种职责的岗位一直都存在，很多做saas的公司也一直都尝试这么做。一直有两个问题没有解决：1.深度理解客户，q其实做的事情是在蒸馏客户，客户不愿意把自己最核心的工作内容和盘托出 2.大部分公司的数字化工作，都会有很多的供应商，这就涉及到这些系统的集成问题，就会引出定制化的工作。老师能说一下fde这个岗位怎么解决这两个问题吗作者回复: 你好，马金良，这两个问题提得非常实在，都是干了多年 2B 的人才会问出来的。 第一个问题，客户不愿和盘托出。我的体会是，这本质上一方面可能访谈技巧问题，但也可能是信任问题，而信任不是谈出来的，是干出来的。FDE 的解法有两条：一是不指望客户“讲清楚”，很多业务知识是默会的，客户自己也总结不出来，所以要坐到现场去看他们怎么干活，观察拿到的东西比访谈多得多；二是先用一个小切口快速做出看得见的结果，客户看到你真能解决问题，才会把更深的东西交给你。这个从进场到建立信任的过程，第 5 讲、第 7 讲、第 8 讲会连着展开。 第二个问题，多供应商集成带来的定制化。我的观点是，FDE 并不消灭定制，而是控制定制的边界。集成这类工作确实躲不掉，但要分层处理：对接各家系统的适配逻辑，放在隔离层，用配置和插件来承载；从集成中长出来的通用能力，比如某个行业普遍需要的数据打通模式，才沉淀进产品。而且 AI 让写适配代码的成本大幅下降，定制本身不再可怕，可怕的是定制完什么都没留下。这套施工纪律，第 9 讲会具体讲。
10
刘峥2026-07-29 来自辽宁看了老师的文章，有个问题想向老师请教： 如果FDE真的做到了老师说的有沉淀，形成产品复利效应。从公司的角度来讲自然是好的，得到了一个打磨的完善的商品，在市场中具备竞争力。但是对于FDE工程师而言，他们的价值不是越来越低吗？因为复利效应，剩余的难题会越来越少，会不会到后面有退化成项目实施与部署等工作？而且随着产品的成熟，公司似乎也没有必要再维护这么多数量的FDE，会不会鸟尽弓藏呢？作者回复: 你好，刘峥，这个问题问得很深，我分两层来说。 公司层面，单看一个场景，你的推演是成立的：场景被产品吃透之后，这个场景确实不再需要 FDE 了。但公司请 FDE，从来不是为了守住一个成熟场景，而是为了探索下一个：新行业、新场景、新客户群。产品复利释放出来的人力，会被投到新的客群上去。Palantir 做了二十年 FDE，今天还在扩招，就是因为对它来说，值得探索的问题一直比能吃透的多。而且 AI 技术本身还在快速变化，昨天沉淀好的能力，明天可能就要重新探索一遍，难题枯竭这件事，短期内我觉得不用太担心。 个人层面，FDE 积累的核心资产不是对某一个产品的熟悉，而是可迁移的能力：钻进一个陌生业务、找到真问题、交付出结果、再沉淀成产品。这套能力不会随着某个产品的成熟而贬值。真正要警惕的反而是另一种情况：产品成熟了，你的工作慢慢退化成安装配置，那就不是鸟尽弓藏，而是自己变成了实施。什么时候该离开一个 FDE 岗位、这个职业的天花板在哪，第 23 讲会很坦诚地展开。
4
Ops3602026-07-29 来自广东FDE是坐在客户现场，能通过AI技术主动交付对客户有价值的产品探索者。“客户现场经验能不能沉淀回产品”和“下一个客户是否交付得更轻”是判断FDE的关键指标。FDE真正的机会，是借助 Agent、知识库等工具，把客户现场积累的业务流程、行业知识和踩坑经验提炼成可复用的产品能力。 FDE 并不是消灭定制，而是控制定制的边界， 对签单负责的，有提成，是售前； 对工时和人天负责的，是外包； 对“产品跑起来”负责的，是实施； 永远是10个人三十天完成，是咨询； 使用AI快速开发一套定制化系统，是定开。作者回复: 你好，Ops360，这份总结的完成度很高，特别是“FDE 并不是消灭定制，而是控制定制的边界”这一句，概括得比我课程里讲得还要凝练，后面几组“对什么负责”的排比也梳理得很清楚。唯一想补充的是，这套判断用来看别人的岗位和团队很好使，但它更大的价值是拿来自检：等你自己在现场干起来，AI 让定制变得又快又顺手的时候，“这一单里有什么东西能沉淀回产品”这个问题，要时时问自己。期待你在后面实战章节的留言。
3
熊伟2026-07-30 来自四川我觉得这个岗位比较适合那种技术岗，兼职产品设计，也就是解决方案输出的岗位。有与客户的交流经验，输出方案的经验，再加上一点产品设计的经验。很适合在大厂的外包同学。作者回复: 你描述的这个画像，技术打底、懂产品设计、有客户交流经验，方向是对的，这确实是 FDE 需要的复合能力。 但有两个地方我想补充一下。第一，“解决方案输出”和 FDE 之间还差关键一步：方案是纸面的，FDE 要对方案变成生产系统之后的业务结果负责，这一步恰恰是这节课讲的售前和 FDE 的分界线。第二，大厂外包同学的现场经验确实是资产，但要警惕外包的工作惯性：习惯了按需求文档干活，而 FDE 要自己定义问题。所以转型的重点，与其说是补哪块技能，不如说是换一种负责对象，从“方案有没有输出、需求有没有实现”换成“业务结果有没有改善”。能力模型的完整拆解在第 22 讲，到时候我们可以对照一下。
共 2 条评论1
百川东到海2026-07-29 来自湖南这个模式的乙方政治地位要大于或等于甲方吧？作者回复: 这个模式并不需要乙方“大于或等于”甲方，这在现实中也几乎不可能，中国 2B 的常态就是乙方地位低于甲方。 FDE 模式需要的其实不是政治地位，而是两样更具体的东西：信任和授权，能进业务会议、能拿到真实的数据和权限、有懂业务的人陪你磨合。这些不是靠地位得到的，而是靠筛选加交付换来的。 进场前先筛掉那些只想按需求文档验收的客户，第 5 讲会给一张筛选清单；进场后用小切口快速做出看得见的结果，让对方觉得配合你是划算的。第 2 讲结尾说过，外包客户不用改变自己，FDE 的客户必须改变自己，客户愿不愿意改变，筛的就是这个。 而交付换来，其实在课程中也提到了，FDE 愿不愿意在客户现场，从一些小的 case 做起，慢慢解决客户的问题，给客户带来实际的收益，从而获取客户的信任。
1- Geek_527cab2026-07-31 来自北京曹老师你好,我现在的工作是驻场到客户现场进行信创改造和数据库支持的原厂工程师，但是我们只会对人天和信创改造进度负责，产品有bug会联系研发同事，在工作中并不会写代码最多写一些脚本，要想转型FED工程师是否还需要补齐代码能力和学习AI
作者回复: 你好。先说结论：两样都要补，但你的起点比你自己以为的要好。 先说好的部分。你长期泡在客户现场，懂客户环境、会跟客户打交道，这恰恰是很多坐在总部的工程师最缺的东西，而且是最难速成的。转型 FDE，你缺的是技术那一半，不是现场那一半。 再说要补的。代码能力必须补，第 1 讲说过，FDE 要写生产代码，没有足够的技术深度，在现场就做不出判断，也探索不到真正有价值的东西。学 AI 更是必须，因为它就是今天 FDE 在现场解决问题的主要手段。好消息是这两件事现在可以合成一件：AI Coding 把工程门槛压低了很多，你有脚本基础，起步并不算晚。我的建议是从手头工作里找小切口练手，比如把驻场里那些重复性的检查、巡检、报表工作，用 AI 写个小工具自动化掉，既在真实环境里练了手，客户还能立刻感受到价值。 另外还有一层比技能更重要：你现在对人天和进度负责，这是第 2 讲里典型的外包和实施的位置，转型 FDE 真正要换的是负责对象，对可衡量的业务结果负责。能力怎么补齐、面试考什么，第 22 讲会给一份完整的能力模型，到时候可以重点看看。 当然，这背后的转型很多时候也需要组织提供相应的机会，但不管怎么说，先从积累个人的能力开始，优秀个人和组织之间的博弈关系，在 AI 时代还是有很大不同的。
gaoyan2026-07-30 来自北京FDE是按效果交付，要面对很多高语境，多重语境的情况；很多时候客户的真实需求，是不会在公开场合说出来；客户自己也在探索，组织到底需要什么，达到什么样的效果才够；作者回复: “高语境”这个词用得很准，尤其是最后一句，客户自己也在探索，这个观察很多干了多年交付的人都未必说得出来。 我再往前推一步：FDE 面对的往往不是“客户知道要什么但不肯说”，而是“客户自己也说不清”，很多业务知识是默会的，访谈问不出来。所以与其琢磨提问技巧，不如换个手段：坐到现场去观察他们怎么干活，再用一个很快做出来的 demo 去逼近，拿一个具体的东西让客户说“不对，应该是这样”，比让他凭空描述需求有效得多。至于不在公开场合说出来的那部分，涉及干系人和内部政治，第 7 讲会专门讲怎么处理。摸真问题和 demo 这两讲分别是第 5 讲和第 8 讲，到时候欢迎你再来对照留言。
西蒙2026-07-30 来自湖南我目前的岗位就是外包。作者回复: 外包是现状，不是终点。你在第 1 讲留言里提到公司没有产品，我的建议还是一样的：公司层面暂时没有沉淀的载体，个人层面的沉淀照样可以先做起来，把重复出现的工作抽象成自己的工具和方法论，让第二个项目比第一个更轻。这一步做到了，可能个人职业发展的积累就已经拉开了。
NICE MEMORY2026-08-01 来自四川对于成都的程序员来说，FDE很像当年的货车帮团队，带着自己的产品一次又一次在各个公司实践然后逐步完善。应该会有很多程序员经历了这种模式