这是崔牛会基于《硅谷今年最火的岗位 FDE，我们闷头干了三年》做的一小时深访。崔强约访时说得很直接：他想看 FDE 照进中国的落地现实到底长什么样，能不能抽出一套给中国 AI 公司、SaaS 转型公司用得上的打法。所以这次不复述文章，只追问那些一笔带过、当时觉得"不好展开"的地方。下面按对话整理，问题做了合并，金句做了高亮。
一、FDE 这个词，和一个没打算做 FDE 的起点
崔牛会：你最早注意到 FDE 这个词是什么时候？是前年 10 月 Palantir 把它讲火的时候吗？
更早，具体哪天记不清了，但一定在 2023 年之前。Palantir 这个角色搞了二十多年，我很早就盯着这家公司。
但有意思的是，2023 年我自己下场的时候，出发点根本不是 FDE。我们几乎是跟 dify、coze 同一时间做那套低代码平台的。我在 SaaS 行业创业了十多年，太清楚上一代低代码平台的毛病了：技术看不上，觉得这东西 low，不屑于用；非技术又没那个逻辑能力，用不起来。每家低代码公司本质上都在发明一种自己的语言，可你这门语言凭什么能标准化到所有人都认？这就跟"PHP 是世界上最好的语言"一样，是个吵了二十年也没结果的梗。
所以我当时就一个判断：这套东西必须我们自己用，自己拿它给客户交付结果。我卖了太多年软件，太清楚 SaaS 交付的从来不是软件，是最佳实践——今天 AI 让最佳实践交付得更简洁，那我们干脆只卖最后那个结果。2023 年第一天我就没卖软件，第一天就开始搭团队。那时候团队不叫 FDE，叫 PE，prompt engineer。
崔牛会：那会儿招 PE 是什么光景？
巨贵，还傲慢。一个应届生两万多。我印象特别深，面一个人鼻孔朝天，我多问几个细节，他觉得我在窃取他的方案——我就问了他一个 RAG 的原理，他转头找 HR 投诉，说你们公司想偷我的知识产权。
现在回头看挺可笑，但那就是当时的风气：大家对 AI 没什么真认知，懂一点点就觉得自己是大佬。这事现在完全不存在了。说它只是想说明，我们是从一个很糙的起点摸出来的。后来我才发现，当时纯属自救折腾出来的这些东西，OpenAI 后来也在做——真没想到。
二、为什么是一个新角色，不是"让更好的人上"
崔牛会：你最早是怎么意识到，需要的是一个新角色，而不是把现有的人换成更厉害的？
是被客户的不满意逼出来的。
最早交付全靠 PE。他能照着客户说的把提示词、把流程搭出来，活儿不差。但那一年半，我有一半时间在救火。火分两类。
一类是 PE 摸不透客户那门生意：客户怎么获客、钱卡在哪个环节、一句话背后是什么业务逻辑，他不懂。客户说一套，他照着搭一套，交出去总不是客户真正要的。这类火，我后来靠搭一支懂行业的咨询团队压下去——先把客户的生意吃透，再动手搭。
另一类是交付出去的 Agent 质量不合格：测试时好好的，一上线碰到真实数据和真实用户就出问题。这类火，我后来靠「句子守护」压下去——专门盯 Agent 上线之后的表现。
我一开始的反应跟大多数人一样：是不是这个 PE 不够强？换个更强的上。换了发现没用。再强的 PE，一个人也补不上"读懂客户的生意"，更盯不住上线后的质量——那都不是 prompt 写得好不好的问题。
两类火救下来，我才想明白：缺的不是能力高低，是能力的组合，还有责任的边界。一个人既要钻进客户的生意，又要把东西搭出来，又要接进系统，还要上线后一直盯着。这套组合，现有任何一个岗位都不完整。所以不是"让更好的人上"，是这个活本身需要一个新角色。
崔牛会：实施、售前、产品经理、客户成功，公司里这些岗位都现成的，为什么补不上这个位置？
因为它们各自只对一段负责，干完那一段就撤了。
售前对签单负责，单签下来就走。实施对验收负责，验收完就走。产品经理对 roadmap 负责，做的是卖给所有客户的功能，不对某一个客户身上的结果负责。客户成功维护关系、催客户用起来，但他不动手改系统。
AI 系统最麻烦的地方，是风险在上线后。它是个概率系统，测试时好好的，一碰到真实数据和真实用户就开始悄悄退化，还不报错，一点点把客户的信任磨掉。偏偏这时候，上面这些角色全撤了——系统最该有人盯的时候，没人了。
FDE 补的就是这个。售前的终点、产品经理的终点、实施的终点，正好是 FDE 的起点。从进场到上线到客户自己的人能接手，一根线拉到底，中间不换人。
还得补一句为什么是现在。
传统交付为什么要一串角色接力？因为一个人干不完。懂生意、搭系统、接老系统、上线盯着，每一段都是专门的活，只能拆开交给不同的人。可一拆开，每交接一次，上下文就掉一层：售前听懂的需求，传到实施那儿变了形；实施搭的东西，产品又按自己的 roadmap 改一道。交付里最值钱的就是上下文，可协作的人越多，上下文丢得越快——每一道交接都在丢。所以最好的办法，是让一个人尽量把能做的都做完。
以前只能忍这份损耗，没有 AI，一个人确实干不完这么多事。今天不一样：写代码、搭流程、跑测试这些工序，AI 都能当手脚使，一个 FDE 借着这套工具，能把原来一条流水线上几个人接力的活，自己并行做完。人少了，交接少了，上下文就留住了。一根线拉到底不是因为我们要求 FDE 是全才，是 AI 把那些原本必须拆开的工序，重新收拢回了一个人手里。
崔牛会：这听起来像是 OPC（一人公司）的逻辑。
我有个暴论：OPC 是个伪命题，可每家公司里，每个人又都该是 OPC。只有这样组织效率才提得上去。Anthropic 后来的访谈里讲的也是这件事——职位的边界会模糊掉，因为当每个人都为结果负责，沟通产生的信息熵就少了。说白了有点像 OKR 和 KPI：当大家的 O 真的统一了，你就没必要再去拆那一堆 KPI 了。
三、FDE 到底是什么，它怎么反过来塑造了你们
崔牛会：用你自己的话定义 FDE。
一个客户，很多能力，对客户身上的真实成果负责。
拆开就三件：读懂客户的生意，把要交付的成果设计出来，用工程手段把质量兜住。具体到我们，就是 FDE 拿着七大产品基建，直接给客户交付结果。写代码只是其中一道工序，不是目的。衡量他的不是写了多少代码、交了几份文档，是这套系统到底有没有人在用、客户的生意有没有变好。
这套基建是三年踩坑踩出来的。FDE 拿它做完一个客户，能做到 1/10 的时间、1/10 的成本，交付两倍好的效果——中间是 200 倍的差异化。
崔牛会：它和售前、产品经理、实施顾问，一句话各自的区别？
售前对"签没签下来"负责，FDE 对"签下来之后客户有没有变好"负责。产品经理对"功能上没上线"负责，FDE 对"这个客户的转化、人效有没有真涨"负责。实施顾问对"交付物验收没验收"负责，FDE 对"上线之后还在不在跑"负责。
差别都在最后那半句。前面那些岗位的终点，是 FDE 的起点。
崔牛会：上一篇文章把 FDE 对客户的价值讲透了。我想问反过来的——它对句子互动自己的价值是什么？
这个问题问到点子上了。对外我们讲的都是客户人效翻倍、转化涨了多少。对内，FDE 对我们最大的价值，是它塑造了我们的产品形态。
我们今天的七个产品基建，只有句子秒回、句子秒懂这两个是当初坐在会议室里规划出来的；剩下五个，全是 FDE 在客户现场撞墙撞出来的。这也是我第一天就不卖软件的原因——我卖了太多年软件，太知道这里头的拧巴了：客户提的需求都是合理的，客户提的解决方案永远是不合理的。如果客户那么厉害，他自己就能当产品经理了。需求经过销售、经过售后、再传到产品手里，早就变形成一个奇怪的东西，解决不了他真正的问题。那好，我直接下场给你解决，我自己就知道最佳实践长什么样。
句子守护就是这么长出来的，这个故事很典型。
我逼着 FDE 必须交付好结果。FDE 说不行，有这问题那问题。我说好，那给你做 AI 测试。第一版做出来，FDE 又说一堆断点。我拉着 CTO 一起对，CTO 说你可以这么这么做，FDE 说不行有问题，俩人就是对不到一起去。我说那行，CTO 你下场，你把这个客户的 AI 测试整个跑出来，给我交付个结果。CTO 下场才发现，原来中间这么多断点，FDE 根本没能力把它讲清楚。整个句子守护，就是 CTO 一个人从产品设计、开发、测试到交付结果干出来的——因为他自己干过 FDE，所以他知道断点在哪，所以他解得开。雏形出来后再丢给产品包装交互、丢给测试做工程化测试，才成了今天的产品。
AI 时代，我们公司很多产品的开发顺序都倒过来了：原来是产品提需求、技术写代码、测试测结果；现在是技术直接下场把活干完，再丢回给产品写 PRD、丢给测试出报告，紧接着上线。生产的顺序变了，生产的组织也跟着变了。
崔牛会：那 FDE 是一个岗位，还是一种能力？
现在是岗位，本质是能力，长期会变成 AI native 公司的基本功。
同一件事，两个名字：对外，给客户搭 AI 员工的岗位叫 FDE；对内，帮我用 AI 重塑组织的岗位叫 AI 管培生。只是对内做得更彻底——因为决策权在我手里。他们直接向我汇报，任务只有一个：把我们自己的业务流，用 AI 重做一遍。有些对内跑通的场景，直接就长成了对外能卖的产品。比如内部招聘难受，我们就把 boss 直聘打招呼、自动面试全自动化，做成产品卖出去；比如我们有个产品叫跟单小二，最早是内部的 AI CRM——我认为以后 B2B 销售就负责到场、提供情绪价值，会议纪要、录 CRM、竞品分析、出解决方案、跟踪客户进展这些后台活全是 AI 给他干完。
这事不止这两个岗位在干，是整个公司在干。合同审核我们有个 AI 员工叫秒审，一份合同从过去审一天压到两分钟。我办过一次内部的 AI 员工 Hackathon，让各部门自己造 AI 员工，马上还要再办一次——标准就一个：这个 AI 员工能不能在内部真上岗、真接活，不是做个 demo 给大家看。每两周一次 AI workshop，以前是我讲，现在台上换成了销售、运营、财务、HR 这些从没写过代码的人，分享自己怎么用 vibe coding 把手上的活解决掉。为了让大家敢用，我给全员开了无限量 token，一人一台 MacBook，爱怎么烧怎么烧。从我到不写代码的财务，每天第一件事都是打开 Claude Code 干活。
我之所以把内部这件事看得重，是因为我判断组织形态本身在变。
第一代是华为，把公司当一套流程跑，靠标准化做规模——run a company as a process。
第二代是字节，把公司当产品做，整个组织像软件一样迭代——develop a company as a product。
第三代我看的是 Anthropic：design a company as a parallel network——把公司设计成一张并行的网络，不停把串行的瓶颈压掉。
前两代再强，人和人之间还是串行的：你等我交接，我等你审批。AI 第一次让协作可以并行，组织的最小单元不再是一支团队，是"一个人加一支 Agent 团队"，我叫它 1+N。一家 AI native 公司，如果人均做不到 FDE，那就说明这个员工不合格——这事在 Anthropic 内部已经发生了，在我们公司我还在努力。
四、谁在干，从哪来，怎么练
崔牛会：现在 FDE 团队谁在带，结构什么样？多大规模？
负责人是个学法学的 00 后女生。一开始没想让她当 leader，选她是因为两点：一是责任心极强，客户结果不好她会焦虑，甚至有点内耗；二是热心，我们开玩笑叫她鸡妈妈，新人进来她特别愿意教——这其实很少见，教人很费精力。她现在也面临新课题，带的人多了，太年轻，还需要更有资历、更懂客户和管理的人补上来，团队一直在迭代。但这个选择背后我想说的是：FDE 真正稀缺的不是写代码的人，是有极强责任心、又足够 AI native 的人。
规模上，公司现在七八十人，三分之一是 FDE，二十多个。这是核心部门，未来人数可能超过产研。画像很杂：基本是 00 后，也有从腾讯、百度、比亚迪挖来的资深测试开发，还有我们自己的产品转岗的——中间出去创过业，做 Geo 拿了 TS，团队也组得不错，后来又回来了。我挺喜欢硅谷 PayPal 黑帮那种气质——Palantir 自己就是从那帮人里长出来的，反叛的人能做好 founder，也能做好 FDE。所以我们不强求统一画像，核心就是责任心、AI native、好奇心、执行力。
我们刻意把规模按住。这不是省钱，是设计。如果客户翻一倍 FDE 就得翻一倍，那说明产品没起到杠杆，又退回外包了。Palantir 到 2016 年 FDE 比软件工程师还多，我们想走反过来的路：客户在涨，FDE 人数按住，靠产品基建放大每个 FDE 能盖住的客户数。
崔牛会：从哪招？要行业老兵，还是 AI 原住民？淘汰率多高？
两类人，不是一类。一类是懂某门生意的老手，招这种我专挑"反叛者"——不只懂这行怎么干，还能一眼看出现在这套为什么不够好。另一类是长在 AI 里的年轻人，天生把大模型当手脚使。唯独不该上来就招的是算法工程师。大部分公司做 AI 落地第一反应是招算法，错了。第一个该招的，是能听懂客户怎么赚钱的人。
招聘是社招，一整套标准面试体系，最后一轮我亲自面。早期我这关淘汰率 80% 到 90%，现在画像对齐了，淘汰率降到 10% 到 20%。我面得很快，半小时，就看一件事：你是不是真做过事。很多人爱用 fancy 的词把自己包装得很厉害，我往细节里追几句，纸老虎一捅就破。只要真做过，就能来。
崔牛会：怎么培养？怎么考核？
培养不靠上课，靠筛选加老带新。底层先筛两样东西：好奇心和执行力。
好奇心，让你愿意扎进一门跟你八竿子打不着的生意，把它当回事去搞懂。
执行力，让你在"看出哪儿不对"和"动手把它改了"之间一直来回，而不是写份报告就交差。
这股劲，Palantir 早期那帮人身上最明显。他们招人不挑科班对口的领域专家，专挑好奇心旺、不服现状的——把一个你完全不懂的领域甩过来，情报也好、反欺诈也好，你能自己钻进去趟出条路。这批人后来出去开了一大堆公司，底色是同一种：不接受"这行就这么干"，先问凭什么，再上手把它干掉。会写代码、懂行业，都能补；好奇心和不服气这两样，补不出来。我招 FDE 看的就是这股劲，比简历上写了什么重要得多。
筛对了人，培养就简单了。先上一周新兵训练营——这套课打磨到现在，HR 自己就能带了，今年还拿到了工信部认证的 FDE 培训证书，甚至开始跟职业大学合作培训 FDE。上完直接老带新，老 FDE 带着新人上真实客户现场，跑着跑着就长出业务 sense，听得懂客户话里的生意了。这个过程没法加速，就得在真客户、真数据、真出过故障的现场崩溃过很多次，才能跑出来。所以我不觉得能招到完美的 FDE，但我有信心能培养出来。
考核只看一件事：你负责的客户，业务指标有没有真涨。拿销售场景举例，我们落地时和客户做 AB Test——AI 组是销售加 AI，对照组是同样的销售纯人工，两组线索质量、团队水平拉平，只差用不用 AI。不看代码量，不看文档，不看工时。内部考核口径和对客户的收费口径是同一个，所以不会跑偏。
崔牛会：你自己还会下场做 FDE 的活吗？
会，而且挑的是最难的那摊——带着 AI 管培生，把我们自己的内部业务流重做一遍。我在革自己的命，第一刀先冲着我自己的工作流来。这种改造最难啃、杠杆也最高：它动的是流程本身、是谁干什么、是出了事谁担，这种决定只有我拍得了，所以我得自己先下场。
我先把自己一天的活搬上 Agent——调研、写文档、看数据、盯几条线并行。我一个人每天就烧掉几百万 token，把模型推到极限，所以我很清楚现在模型最强能到哪、边界在哪。所以 FDE 不大敢跟我说"这是模型幻觉"，他知道我会把他骂回去，而且会给一个更好的解法。
我自己趟通一条，就带着 AI 管培生照着把它铺到对应部门，一条业务流一条业务流地重做。
五、一个完整的案例，和按结果收费踩过的坑
崔牛会：挑一个最典型的，从头到尾讲一遍。
就讲那个头部在线教育客户。
第一阶段，诊断。一位懂这行的前辈带着行业经验驻场三五天，把客户的 SOP、知识库、整条获客转化链路摸清楚：他从哪获客，怎么转化，钱卡在哪个环节。不上来装软件，先搞明白这门生意。
第二阶段，搭。业务专家带着 FDE 把销售 Agent 搭起来、跑内测，质量这块交给句子守护兜底。
第三阶段，落地，做 AB Test。整条链路一个环节一个环节比：触达率、响应率、转化率、人效，每一步都有数据，全程留痕。结果：AI 组的产出是对照组的三倍。一个销售一个月能盯的人，从一千做到三千。转人工率从 27% 降到 2.73%，故障率从 16.26% 降到 0.13%，线索量六个月爬了十一倍。收费跟着结果走：他盯的人翻了三倍，付给我们的也翻三倍。
崔牛会：按结果收费喊了这么多年，这套收费方式是一开始就这样吗？
不是，踩了很多坑，迭代了快一年。
最早我特别想按 GMV 分成，跑失败了。因为 GMV 好不好，取决的因素太多——流量质量、销售转化、SKU 定价，你很难说这单涨了是因为我的 AI。GMV 没法做干净的 AB Test。
迭代到最后，变成按 leads 收费，核心是控制变量法：只留"用不用 AI"这一个变量，别的全拉平，我才能说产出都是 AI 带来的。光是把这个量化指标跑通，就花了小一年——你不知道怎么量化，就不知道怎么收钱。
中间还有个坑特别有意思：销售特别爱抠 AI 的字眼。在线教育的销售都觉得自己的话术身经百战，就揪着 AI 说"你这语气跟我不一样""你这句该用'亲'还是'宝'还是'~'"，说你这就是不准。后来我们干脆不纠准确率了，只盯两类指标：
- 过程指标：填表率、行课率、完课率、作业完成率
- 结果指标：就一个——一个人能接的 leads 翻倍，ROI 不掉。人工组一个人接 800 leads，AI 组接 3000 leads，单个 leads 的 ROI 不下降
注意力全压到这两类指标上，那些"要不要加个'哦'"的纠结，就不重要了。
崔牛会：做了 FDE 之后，项目成功率提高了吗？怎么定义成功？
提高了，但不是每个都成。成功的定义就是上面那个 AB Test：AI 组打赢对照组，客户业务指标真涨，然后他愿意续约、愿意把单子做大。从世俗的 SaaS 口径看，我们的 NDR 是 112%，recurring 收入占 92%——老客户每年不光续，还在扩，单个合同越做越大。这是用脚投票的结果。
做不动的也有，两类。一类是数据和系统基建太烂，底层是散的，AI 在上面跑不起来；另一类是组织本身不愿意用，老板想要、下面的人不配合。这两类我们后面都有了对应的解法，下面讲。
六、七大产品基建：现场每撞一堵墙，产品就长一块
崔牛会：这种"现场的苦变成产品"，挑几个最典型的讲讲？
七个产品基建，每一个背后都是一堵现场撞过的墙。
句子守护，我最看重的一个。它管的是 Agent 的质量。Agent 改一行就可能带坏另一处，靠人一遍遍手测根本测不全、测不准，上线前心里没底。我们的办法是把传统软件工程那一套搬过来，管 Agent 的健康度。我们内部叫六道关：AI 生成测试用例、批量验收跑回归、灰度上线、AI 工单、上线后 AI 质检——每改一行全量重考，回归不到标准不放行；上线后还有一个 AI 盯着所有 AI，定期抽检真实对话出健康度报告。这套东西在 PE 时代根本做不起来：全靠人的手感，没有自动化回归兜底，测漏是常态。现在它是产品，下一个客户进场质量这道关开箱就有。我们给它一句定位：像管软件一样管 Agent。我特别想做的事，本质是 AI 守护人，因为人本来就不靠谱。它也理顺了销售和 FDE 的协作。销售不懂技术，过去 Agent 到底好不好全靠嘴上掰扯，掰不清就来找我断官司。现在句子守护直接出一份测试报告，质量结果全在上面，是量化的——销售一看就知道 FDE 交付的 Agent 行不行，报告不达标就是 FDE 没搞好。这份报告甚至能直接摊给客户看。
句子制造，从"客户基建太烂"那类失败里长出来的。客户底层数据是散的，AI 没法在上面跑，以前我们不做定开，就让客户自己去补，周期一拉长就不了了之。所以我们做了个独立环境，本质是个 coding agent，FDE 直接在里头给客户把需要的数字化系统做出来，时间成本很低，还跟我们系统打通。
句子懂行，解决知识工程。客户甩给你两个 T 的文件，说"这就是我的知识库，拿去做 AI"。可文件里到处是矛盾：同一个产品，这份文档写卖 2000，那份写 5000，到底信哪个？而且文件散落各处，没标签、没元数据，根本没法检索。句子懂行用 AI 做预处理，把散落的内容整理成 AI 能检索的形态，再把所有矛盾点列出来，让客户先裁决哪条对、再进库，顺手把测试也做了。这是每个客户专属的知识工程——做好了，其实是帮客户把自己的知识先理清楚，AI 检索才跑得准。
句子 CLI，解决"老系统不敢动"。客户有几百个系统，往往跟收银、跟钱相关，是核心业务，谁也不敢让你重做——出了事谁负责？所以我们不动它，给每个系统配 CLI，原系统不用改，照样能把数据处理打通。
崔牛会：刚才提到两类做不动的客户，后来怎么解的？
第一类，基建太烂，就是上面说的句子制造，直接下场帮他把数字化系统补上。
第二类更微妙——老板和执行层有 gap，老板聊得很好，下面的人就是不配合。我们最早觉得自己有底气按结果收费，就不收咨询费，直接下场吭哧吭哧干。后来发现不行，不收咨询费他就不重视。所以现在反过来：先收一笔咨询费，老板交了钱，下面的人才会觉得"这东西我们交了钱，得用起来"，后面再收按结果付费的 AI 员工费用。先收咨询费再按结果收费，成功率反而更高。
七、什么客户最需要，规模化卡在哪
崔牛会：在你的认知里，哪类客户最需要 FDE？
所有非 AI native 的公司，都需要 FDE。
判断一家公司 AI native 不 native，有个暴论式的标准：看 00 后比例，看 founder 背景。如果 founder 是 00 后、又在做 AI，大概率挺 native；如果 founder 不是 00 后、又没技术背景，很难。我自己是把命革掉半条，加上原本就写程序出身——我的开源框架上个时代有两万多 star，影响过上百万开发者——我才长成一个还算 AI native 的人。今天的 vibe coding，其实你得懂程序，才知道怎么设计架构、怎么部署。没技术背景的销售型创始人，补这个认知要花不少时间。
顺带说个观察。美国的 SaaS 土壤确实比中国好太多，这点我承认。但也别因此就神化它的数字化程度。我中美两地常跑，2019 年进过 YC，现在也给一些美国 founder 做 mentor。一个耶鲁的同学做财务 Agent，底下接的还是 Windows 时代那种离谱的老软件，在美国跑了几十年。真到系统层面，各家公司都不行。怎么用 AI 把这些老掉牙的东西接进来、变成 AI 能处理的，才是今天所有 AI 公司共同的命题。
项目这边：越复杂、离钱越近、结果越能量化的，FDE 机会越大。制造业、金融这类复杂项目尤其需要——我们最近还做了个 AI 后勤主管，管充电站的保洁：几千个充电桩，过去靠人排班、靠人盯、验收靠抽查，现在 AI 按需派单、AI 看照片验收、不合格自动出工单和报告，连这种蓝领后勤的活都能管。反过来，离钱越远的就越低一档，比如客服——同一个客户，一个 AI 销售岗一年带来的合同额，是 AI 客服岗的十倍以上。
崔牛会：FDE 规模化，最大的挑战是什么？
人。
能扎进陌生生意、又对结果较真的人，本来就稀缺；更麻烦的是，这种人离自己出去开公司只差一步——他既懂一门生意怎么赚钱，又会用 AI 把活干完，凭什么留下来跟你干？
我们公司最近就有两个离职的人又回来了。靠的是文化和产品基建，让人觉得"咱们一起干，你拿到的更多"。所以挑战是两层：一是持续找到、留住这种人；二是用产品把对这种人的依赖一点点降下来，让一个没那么稀缺的人，靠我们的工具也能干出接近的结果。第二层做得好不好，决定了按结果收费这个模式能铺多大。
崔牛会：FDE 会成为 AI 公司的标配吗？
会。Bob McGrew 那句话我很认同：
Agent 没有现成的样子。SaaS 你一上来就知道要做成什么样，照着做个更好的去抢市场；Agent 不是，没人知道一个销售 Agent、客服 Agent、甚至我们做的那个能接案子的律师 Agent，最后该长成什么样，只能钻进客户真实业务里一点点试。谁想在 Agent 时代找到 PMF，FDE 大概绕不开。
硅谷今年集体做 FDE，巨头一边自建一边拉麦肯锡、德勤，说到底是认了同一件事：客户认的是结果，不是过程。
八、重来一次，和"CEO 是天花板"
崔牛会：如果重来一次，你会怎么设计 FDE？
三件事，两件照做，一件会改。
照做的：第一天就按结果收费，2023 年就定下来，扛住了同行都按人头按工时收的压力。还有一句——第一天就别招算法，招懂生意的人。这条我们只做对了一半：确实第一天就没招算法，但也没招到懂生意的人，招的是一批 00 后 PE。不过那个时候我没那么多资源，再来一遍大概率还是这么走，还是得从零培养。这其实是个资源匹配的问题——换成今天的我，有资源了，第一天就会去招懂生意的人。
为什么以前没资源、现在有了？很多人是因为相信所以看见，也有很多人是因为看见所以相信。两年前我盲目相信这事能成，先做了出来，今天麦肯锡、科尔尼、安迈这些非常资深的合伙人愿意跟我们合作、给我们带大 case——是因为我们做到了，他们看见了，所以信了。
会改的：更早把"质量兜底"做成产品。句子守护我们做晚了。其实 2023 年第一个项目我就在干这事——自己写代码、用 Excel 把测试用例放进去批量跑结果，想把它标准化。但真做成花了这么久。为什么慢？说到底还是组织的问题：23 年我没有现在的现金流、现在的认知。一家 AI 公司的天花板，就是 CEO 本人——他的认知、他的执行力、他当下的资源，决定了这家公司能做成什么样。
所以那些坑，我大概只能自己踩。CEO 多半是不撞南墙不回头的人，没撞到南墙，就总觉得自己是对的。换个阶段、换个认知，踩的坑不一样，但该犯的错一个不会少——区别只在于，撞下去之后知不知道收脚。
这次没聊完的还有很多。如果你也在把 FDE 往中国落地，或者在做 SaaS 转型的路上，欢迎来找我接着聊。
评论