西蒙2026-07-30 来自湖南1、我现在做的工作是ETL工程师/数据建模，而且是驻场，我现在明确是交付，没有进行探索，公司还没有合适的产品，我们本来就是外包，人力外包 2、现在还不能把一线看到的东西，真的带回到产品里；因为公司就没有产品，我们就是真实的外包，哈哈。作者回复: 你好，西蒙，感谢你的坦诚，“公司就没有产品，回流无从谈起”，这个判断本身就很清醒。不过我想说，在公司层面暂时没有产品可沉淀的情况下，个人层面的沉淀依然是可以做的：把每个项目里重复出现的工作，抽象成自己的工具、脚本、Agent 和方法论，让你自己做第二个项目比第一个更轻。这一步做到了，你就已经在用 FDE 的方式工作了，将来无论是内部转型还是换平台，这些积累都带得走。另外也建议观察一下，公司接的这些项目之间有没有共性，如果有，说不定恰恰是从外包往产品走的机会。什么样的平台值得去、什么时候不该做 FDE，第 22、23 讲会专门讨论。
共 2 条评论2
Gred2026-07-30 来自福建FDE的职责可以理解为主要两点： 1. 帮客户解决业务问题 2. 帮公司带回产品作者回复: 总结得很准，就是这两件事。再补两个细节：第一点里，“解决业务问题”要落到可衡量的结果上，不是把系统装好就算解决；第二点里，带回的最好不只是需求列表，而是验证过的认知，甚至直接是产品下一版的能力。两头都做到，才算完整跑通了一次 FDE 的循环。
1
普通的一天2026-07-29 来自北京或者说在传统互联网中，又叫懂产品的开发？作者回复: 有点像，但还不等同。“懂产品的开发”说的是能力特质，FDE 则多了三个硬性的约束：第一，他嵌入在客户或者业务的现场，而不是坐在研发工位上；第二，他对可衡量的业务结果负责，而不是对需求实现负责；第三，他要把现场验证的认知沉淀回产品。一个懂产品的开发，如果接的还是定义好的需求、考核的还是交付进度，那他还是在已知的框里落地。可以说懂产品是做 FDE 的好底子，但真正的分界线，在于站的位置和负责的对象。
共 2 条评论1- 沙芦2026-07-29 来自北京1.现在的本质工作是研发，重在交付； 2.我们负责公司内部的二线客服系统搭建，会一年一次去外地的客服现场收集问题，也会现场解决一些问题，但是更多的是收集整理问题，讨论过后给到PM那里去过滤、排序，最后走排期开发。结论是最终会有少量的内容带回到产品中。本质原因 a.组织架构问题，协作流程很长，前/后端研发岗位各司其职 b.研发直观交付，业务和技术两条线，技术不直接为业务目标负责 c.产品能力也是很重要的一环
作者回复: 你好，沙芦，感谢你这么认真地回答思考题，你总结的三个原因，组织架构、责任分工、产品能力，都说在了点子上。我再补一个视角：频率和链路。一年一次去现场，意味着大部分时间里认知是断流的；而“现场收集、整理、给到 PM、过滤排序、排期开发”这条链路，每多一个环节，信息就衰减一层，时效也损失一截，等真正开发出来，现场的情况可能又变了。FDE 这套打法某种意义上就是把这条链路压短：探索和落地发生在同一个人或者同一个小团队身上，现场看到的东西，当周就能变成产品里的尝试。你们的场景其实挺适合借鉴这个思路，不一定要设 FDE 岗位，但可以试试让开发以更高的频率、更短的链路接触一线。
1 - Martin2026-07-28 来自广东我是个研发，我会分两种场景 1. 在做业务需求的时候，是在交付，把业务 or 产品的prd 写对应的代码实现功能 2. 在做自己研发提效or规范工具的时候是探索，整个工作流应该怎么规划，要使用什么工具进行提效，是不是流程都一样，能不能做成规范化，所以就会有 jira，内部的运维工具等平台的出现 不能把一线看到的东西带回到产品里的原因我觉得会有这个团队一开始想做的是通用流程化的东西，当一个一线提出来的时候觉得不够通用，不同团队有不同的做法，但又没有提供定制化的能力。导致痛点一直没有解决
作者回复: 你好，Shopman。我理解你的疑问是：代码生成已经有这么成熟的手段了，还有什么可“探索”的？关键在于，FDE 探索的对象往往不是“怎么写代码”，而是“到底该做什么”。代码或者说实现是廉价的，问题或者说做什么是昂贵的。 在一个真实的企业里，没被开发出来的往往不是某段代码，而是后面这些问题的答案：这个客户最痛的问题到底是哪个？它值不值得做？需要的数据在不在、够不够干净？做出来的东西要嵌进哪个流程、谁来用？这些问题在进场之前没有标准答案，AI 也没法替你回答。举课程里那个例子，产品里一个干干净净的“客户”字段，到了真实企业里能分裂成自然人用户、直客、经销商、关联方好几层，怎么对齐，就得靠人在现场一层层探索。简单来说，代码生成解决的是“做出来”，探索解决的是“做什么、做成什么样”，后者才是目前真正稀缺的。
1 
董聪聪2026-07-31 来自北京这一章的Echo角色，如果站在客户角度，其实可有可无作者回复: 你好，董聪聪。 单看一个项目、一份合同，你说得对，客户关心的是自己的问题被解决，Echo 干的活他确实感知不到。但把时间拉长，结论可能会不一样。Echo 在后方把各个现场的认知沉淀进产品，客户后续拿到的版本才会越来越强、成本才会越来越低；一个没有 Echo 的供应商，本质上就是人力外包，产品不会进化，客户每提一个新需求都要按人天重新买一遍。所以更准确的说法可能是：Echo 对客户的单次交付可有可无，对客户的长期利益和乙方的商业模式，则可能是一个关紧因素。第 2 讲说的“第二个客户是不是更容易”，受益的其实不只是乙方，还有排在后面的每一个客户。
mini希2026-07-30 来自四川我觉得遇到最大的问题还是组织结构层面吧，很多情况下产品、交付是分别独立的2个事业部或者业务线，交付反馈的一线情况，独立的产品线很难采纳，考量不采纳很可能有违产品线已有的路标，造成产品迭代混乱。组织层面有什么能改进的地方、或者真要落地组织必须统一管理？FDE的岗位需要较高的权限才能调动Echo的角色？作者回复: 你好，mini希，这个问题问到了 FDE 模式落地最硬的一环：组织。你描述的困境非常真实，产品和交付分属两个事业部，一线的反馈进不了产品的路标，这在上了规模的 2B 公司里非常普遍。 我的看法是，组织不一定非要统一管理，但认知回流不能靠个人刷脸，必须变成正式的机制。这套机制至少包括两样：一是把现场发现整理成结构化的需求，正式提交给产品团队，有人认领、进评审、被排期，而不是散落在群聊里；二是前线和产研之间要有固定的握手会议，两边共同对这条需求 pipeline 负责。我自己在神策作为 CTO 长期主持过这类会议，体会是，没有固定机制，前线会觉得产研不接需求，产研会觉得一线只会转发客户原话，互相埋怨几乎是必然结果。这套机制怎么建、怎么衡量它转得好不好，第 13 讲会专门展开。 至于 FDE 是否需要较高权限才能调动 Echo，我觉得方向反了：靠的不是 FDE 个人的权限，而是公司层面真的把“沉淀回产品”当成考核和排期的一部分。另外补一句，产品线有自己的路标是合理的，回流也不是要求产品照单全收，收敛和取舍本来就是 Echo 的职责，真正的问题只在于，一线的认知有没有一条正式的通道进入产品决策。AI 时代还有个变化对你有利：第 1 讲说过，AI 让一个人能同时承担 Delta 和 Echo 的活，跨部门协调的链路本身也在变短。
- 不会游泳的小白2026-07-30 来自江苏FDE的工资怎么算 客户又怎么给派FED的企业定价
作者回复: 这两个问题问到了商业模式的根上。先说个人工资：坦率讲，国内目前还没有公开的 FDE 岗位薪资统计，从我了解到的情况看，在硅谷，它一般对标资深研发或者解决方案架构师的薪酬体系。有一个结构性的判断标准，第 2 讲会讲：真 FDE 的薪资里不应该有销售提成，有提成的大概率是售前换皮。 再说企业怎么向客户定价：这恰恰是 FDE 模式最核心的商业问题，如果按人天卖，那就退回外包了。方向是从卖工时走向卖产品加卖效果，比如基础订阅费，加上和业务结果挂钩的部分。这里面怎么定基线、怎么归因、怎么跟客户谈，第 15 讲会用一整讲来展开，值得你到时候重点看看。
懂懂2026-07-30 来自江苏有一个比喻，适合作为收尾。一锅好汤，真正的价值不在食材本身，而在那个能把食材变成一锅好汤的厨师。AI、大模型、数据，这些都是食材；而能把它们在一个真实的企业里，熬成一锅真正有用的汤的人，才是最稀缺的。FDE，就是那个想成为厨师的人。 这个比喻太形象了，最大的壁垒还是人的审美及你对你自己业务的不一样的洞察作者回复: 谢谢认可。你补的这句“壁垒是人的审美和对业务的洞察”，我也很认同。模型和数据会越来越便宜，但判断“什么值得做、做成什么样才算好”，这个能力短期内还是稀缺的。这也是整门课想帮你练的东西。
- 普通的一天2026-07-29 来自北京传统互联网公司，toc，去哪里找客户？
作者回复: 这个问题可以从两个方向理解，我都回答一下。如果是问 toC 公司内部怎么用 FDE 这套打法：toC 公司没有外部的客户现场，但有内部的业务现场；没有外部客户，内部的需求方，如运营、增长、市场这些业务团队，就是技术团队的“客户”。把工程师嵌进业务团队，直接对业务指标负责，再把验证过的能力沉淀成内部的平台和工具，这套逻辑完全适用。如果是问你个人想做 FDE 该去哪里找机会：FDE 岗位天然长在 2B 公司里，模型厂商、AI 应用公司、2B 软件公司这两年都在招，第 22 讲会专门讲怎么准备。