一个哈佛硕士在货代公司“装龙虾”后的顿悟：AI 根本进不去真实的中国工厂

从外包到FDE：AI时代的交付方式变了

"这不就是外包换了个英文title吗？"——问题是，真不是

今年四月，吴明泽因为"装龙虾"认识了一位货代公司老板。

说来也巧。那位朋友在物流行业干了整整十年，四月正好是龙虾进口旺季，就顺手给吴明泽介绍了这位年营收过亿的老板。吴明泽是谁？哈佛设计工程硕士、斯坦福HAI（人工智能实验室）科研助理。他还在阿里、腾讯、MiniMax做过工程师——标准的"硅谷-斯坦福-大厂"精英路径。日常接触的要么是硅谷做AGI的极客，要么是斯坦福实验室里的研究员。

结果到了这家货代公司现场，这位年营收过亿的老板连豆包都没真正用过。

不是老板不聪明，不是企业不需要技术。而是AI距离大量普通企业和普通人，远比我们想象中更远。我们坐在北京五道口或者杭州未来科技城的咖啡馆里，觉得AI已经天翻地覆了。但走出这些气泡，真实的产业现场完全是另一个世界。

Lawted——现在朋友都叫他这个英文名——去看跟单员怎么工作。微信、Excel、PDF，每天从早上八点干到晚上九点，纯人工复制粘贴：读取单据、录入字段、核对信息。没有任何系统对接，没有任何自动化。一套操作流程可能十年没变过。

"那一刻我意识到，AI真正的机会，可能不只是在创造更前沿的技术，而是在把已经存在的技术，带进这些真实的产业现场。"

这个顿悟直接催生了他的第二个身份：除了做Ha7ch（一个FDE社群与孵化器），他还创办了鑫栩达科技Alvenda，一家FDE驻场交付公司。从硅谷回杭州，从实验室回工厂，他开始用"土FDE"的方式，一家一家地扎进真实企业。

而当他开始向外讲FDE这个概念时，收到的第一反应几乎一模一样——

"这不就是外包换了个英文title吗？"

问题是，真不是。

"外包换个名字？"——十维对比告诉你差在哪

Lawted专门做了一期"十维度对比"视频来回应这个质疑。外包和FDE的区别，从起点就不一样。

传统外包的起点是什么？方案已经基本确定了。客户说"我要开发一个XX功能"，有PRD，有需求文档，甚至有设计稿。外包团队的终点是"功能做完"——代码交付，项目验收，结款走人。至于这个功能上线后有没有人用、有没有解决业务问题，不在合同范围内。

FDE的起点是另一个极端：一个极其模糊的问题。客户说的话往往是"我也想用AI提效，但不知道从哪里开始"。没有PRD，没有确定方案，连问题本身都需要先定义。FDE工程师要像咨询顾问一样先进场，花几天甚至几周去理解业务流程，找到真正的痛点。

终点也不一样。FDE交付的不是功能列表，而是业务结果。敢把收入和客户结果绑定——做到了分钱，做不到就白干。这是一种对赌式的商业契约，和外包的"按人天计价"天差地别。

Lawted给我讲了一个跨境服装企业的案例。老板只提了一句话："AI帮我赚更多钱。" 模糊到不能再模糊。FDE团队进去分析后发现，这家企业只有英文网站，而且中国式表达完全不适合海外消费者——直译的产品描述、不符合当地习惯的页面布局，海外用户点进来就直接关掉。

FDE提出建18国本地化网站。但关键是收费方式：按有效客户结算，每个5到10块钱。没带来新客户？那网站就没有价值，FDE白干。

看明白区别了吗？

外包交付的是"18个网站"，FDE交付的是"新增客户"。一个是卖人头的逻辑，一个是卖成果的逻辑。

表面上都是"派工程师去客户现场"，骨子里的商业契约完全不同。外包关心的是"我做了多少页面、写了多少行代码"，FDE关心的是"你的业务收入有没有增长"。

让这一切成真的，是Coding Agent。

过去，一个这类定制项目需要完整产品团队——产品经理、设计师、前后端工程师、测试——报价两三百万起步。项目周期三个月到半年，光是沟通成本就能耗掉三分之一预算。

现在？二三十万。一个懂业务、能熟练使用Codex（OpenAI的AI编程工具）或Claude Code（Anthropic的AI编程助手）的人，就能把这事独立干完。Coding Agent把"写代码"这个环节的效率提升了一个数量级，一个懂行的人加上AI，就能完成过去需要一个团队的事。

成本降低整整一个数量级。这不是量变，这是质变——质变到足以让一种全新的商业模式成为可能。

Lawted把FDE生态分成两类。一类是大厂平台型FDE，基于成熟平台做定制，本质上是推动自家产品的销售、使用和续费。Palantir（美国大数据分析公司，市值一度超过千亿美元）是这一模式的鼻祖，国内的飞书、钉钉、阿里云也在推类似的驻场服务。

另一类是他更感兴趣的——创业型FDE，他管它叫"土FDE"或FDE OPC（独立承包商）。这类FDE技术完全中立：客户需要GPT就用GPT，需要做插件就做插件，不做任何预设。不问"我手里有什么产品可以卖"，先问"客户到底需要什么"。

LinkedIn上的数据很直观：FDE相关岗位需求在过去一段时间增长了42倍。 OpenAI更是砸了40亿美元成立专门的部署公司。资本和人才都在往这个方向涌，说明市场已经用脚投票。

但FDE到底是什么，还没被真正讲清楚。尤其在中国这片土壤上，它会长成什么样，答案更不在硅谷的模板里。

大厂FDE vs 土FDE：中国不需要第二个Palantir

先说大厂FDE怎么玩。

以飞书为例。安徽一家工厂已经采购了飞书和AI额度，飞书派FDE驻场，问老板要不要做安全帽识别、烟火识别，然后接入多维表格。平台成熟，交付稳定，合规能力强——这些都是优势。企业买了飞书，飞书派人来帮你落地，看起来是一站式服务。

但限制也很明显：往往把客户问题导向自己的产品。

客户需要的是一个锤子，但大厂FDE手里只有一把螺丝刀。不是螺丝刀不好，是问题本来就不一样。飞书的FDE会自然地引导你用飞书，钉钉的FDE会引导你用钉钉——这是商业模式决定的，没什么好指责，但企业得清楚自己在买什么。你得到的可能不是"最适合你的方案"，而是"我手里有的方案"。

土FDE没有这个问题。技术中立、灵活、服务大厂覆盖不到的中小企业——这些是它的天然优势。但Lawted说，真正有意思的不是"谁更好"，而是中国市场的特殊性正在催生一种独特的FDE形态。

中国的经济结构里，存在大量制造、物流、跨境、传统服务企业。这些企业内部有大量跟单、发单、审核、流转、录入的工作——流程重复、规则明确、数据结构化程度高，非常适合用AI部分自动化。Lawted在货代公司看到的那套"微信+Excel+PDF"组合拳，在中国的工厂和仓库里，类似的场景可能重复了无数次。

同时，这些企业能接受的付费又很低。Palantir服务的项目动辄几百万甚至几千万，中国中小企业只能接受几万到几十万。市场规模在这里，但单价完全不同。

这就形成了一个尖锐的矛盾：企业愿付的价格低，成熟FDE的人力成本高。一个从Palantir出来的FDE工程师，年薪可能百万起步，怎么服务得起一家年营收几千万、IT预算不到五十万的工厂？

"中国式FDE不是缩小版Palantir。它不会是西装革履的咨询顾问团队，也不会是大厂派来的平台推销员。更像是一群懂行业、懂沟通、能借助Coding Agent独立完成交付的小型团队和个人。"

Coding Agent让定制成本从两三百万打到二三十万，改写的是"一个人能交付什么"的边界。当"一个人+AI"就能完成过去需要一个团队的事，劳动力的组织方式必然被重构。

FDE不是外包换了个英文名字。它是AI时代一种全新的劳动力组织方式——从模糊问题出发，以业务结果为终点，卖成果，不卖人头。而中国式FDE的答案，也不在大厂的PPT里，而在那些愿意蹲进工厂、听懂跟单员抱怨、用Agent把Excel和PDF变成自动流的年轻人手里。Palantir的模板在中国行不通，因为中国的产业土壤需要一种完全不同的东西——不是更贵的咨询，而是更懂现场的交付。

这扇门，Coding Agent刚刚才打开。

"每年五万"还是"一个员工的年薪"——定价本质是翻译问题

门是打开了，但还有一个坎没过去：怎么让老板心甘情愿地掏钱？

这里有个门道。这不是技术问题，是翻译问题。

Lawted踩过最大的坑，就是用错了语言。一说"每年订阅费五万"，老板脑子里立刻浮现两个画面：要么是腾讯爱奇艺的自动扣费——钱月月往外流，值不值不知道；要么是当年被某软件销售忽悠的经历——买的时候吹得天花乱坠，用的时候一团糟。中国中小企业对"软件订阅"天然有戒心。这不是偏见，是血泪教训堆出来的。

Lawted后来换了一套说法，效果完全不同。他不说"软件"，说"数字员工"。不说"订阅费"，说"年薪"。

老板对人的成本太熟悉了。一个员工到手工资五千，企业实际支出接近八千——社保、公积金、招聘成本、培训成本、离职交接、管理精力。这些数字老板不用算，张口就来。一个做重复工作的跟单员，一年综合成本十万起步。

Lawted的沟通公式是这样的：先算基线。原来每周处理多少订单？每单花多少时间？错误率多少？客户投诉多少次？这些数字老板心里都有数，只是没人帮他系统梳理过。把基线摆出来，改进空间自然就亮了。

然后谈收费。不是说"我卖你一套系统"，而是"我提供一个数字员工，承担这两名员工的重复工作，年薪五万"。老板说五万不算贵，因为两个员工的重复工作至少值十万——这账他秒懂。

更关键的是模式。系统每年节省十万实际人力成本，FDE从创造的价值里拿一定比例：5%、10%、或者20%。老板愿意为"省下来的钱"付费，这是人性。 而不是为"可能有用的高科技"预付，那是赌博。

但这里要加一个非常重要的限定：不能搞纯结果兜底。品牌提升、销售增长、客户转化率这些指标，很难全部归因给FDE。一个网站上线了，海外客户增加了，可能是市场环境变了、竞品出问题了、甚至老板自己谈了个大客户——这些都不是FDE能控制的。如果全部按结果结算，FDE变成纯赌徒，模式走不远。

所以实际怎么做？分层定价。前期诊断、开发、部署，收基础费用——这是FDE的时间和智力投入，不管结果如何都要覆盖。正式上线后，能清晰归因的部分按效果结算：自动处理的订单数、节省的工时、减少的错误率。这些数字系统能直接跑出来，双方对着数据说话，没争议。

分层还有一个好处：它逼双方在项目前就把"成功标准"定义清楚。什么是基线？什么指标算改善？改善到什么程度触发分成？这些问题在项目启动前就必须聊透。某种程度上，定价过程本身就是FDE工作的一部分——帮客户把模糊期待翻译成可衡量的指标。

Lawted讲了一个典型的案例。同一家跨境企业，同一个系统，两套说辞。

说辞一："每年五万软件订阅费。"老板想了三天，没回复。

说辞二："每年五万，承担你两名员工重复工作的数字员工，ROI一目了然。"老板当天就签了。

区别在哪？一个让他想到消费软件的自动扣款，一个让他想到人力投入的ROI。定价语言本身就是FDE需要完成的一部分翻译工作。

土FDE从哪来——Ha7ch不是在上课，是在上场

说完收费，再问一个更根本的问题：这些土FDE，谁来培养？

Lawted的思路出人意料：不是培训机构，不是商学院，是Accelerator（加速器）。

他用了一个特别精准的类比——YC。硅谷的Y Combinator（全球知名创业加速器，投出过Airbnb、Dropbox、Stripe等独角兽）给初创公司什么？钱，当然，但更重要的是真实场景：三个月高密度训练、每周和真实用户对话、Demo Day面对真实投资人。没有这些，创业就是PPT上的自我感动。

Ha7ch做的事逻辑完全一样，只是起点不同。YC给公司资本，帮助快速增长。YC的基本单位是公司。YC最值钱的不是那五十万美金，而是"你必须在三个月内做出东西给真人用"的压力。Ha7ch给人真实场景，帮助获得产业能力。Ha7ch的基本单位是人。Ha7ch最值钱的也不是任何课程，而是"你必须进企业、驻场、面对不清晰的需求和旧系统和内部阻力"的真实战场。

Lawted说，FDE本质上不靠上课学出来。你可以看视频学会Python，但你不可能看视频学会"怎么和一位五十岁的工厂老板聊清楚他到底要什么"。这需要进入现场，观察跟单员怎么工作，感受老板对你方案的犹豫，处理旧系统数据格式不兼容的崩溃。

所以Ha7ch现阶段最关注的不是"教什么"，而是"让谁上场"。更关注学生和年轻Builder。原因很现实：时间灵活、愿意用最新的AI工具、愿意进入陌生行业。一个三十五岁的大厂P8，让他去杭州萧山的一家货代公司蹲一个月？他大概率不干。但一个二十三岁、刚毕业、充满好奇的年轻人？他可能就是奔着这个去的。

Lawted特别看重"第一次真实交付"的体验。很多Builder不缺能力，缺的是场景。他们在家里做了一堆toy demo——看起来很酷的AI应用，但从来没有给真正的企业用过。缺的不是教程，而是进入现场的机会。

Ha7ch提供什么？真实问题、企业入口、一群同行、完成第一次真实交付的机会。这些要素加在一起，构成一个加速器的核心。

社群的网络结构分三层。最外层是Meetup，入口级活动，让更多人知道FDE这件事，认识Lawted和早期Builder。中间层是Guild，按城市建立的长期网络——北京、上海、深圳、杭州、硅谷，已经有五个节点。最内核是GuildUp，小规模高频互动，最活跃的Builder每周碰头，聊项目进展、企业反馈、遇到的问题。

整个社群约2000多人，活跃Builder在500到1000人之间。不是大数字，但Lawted说够了——FDE不需要一万个人，需要一百个真正在做的。

时间分配上，Lawted的主要精力在Ha7ch。Alvenda（鑫栩达科技）更接近顾问和联合创始人的角色，由团队日常运营。原因很简单：Ha7ch烧钱——没有稳定收入，靠Lawted个人积蓄撑着；Alvenda更接近造血，项目回款维持运转。

但长期来看，Lawted希望Ha7ch保持非盈利定位。像学校、像校友网络，不占有毕业后的人才。Builder在Ha7ch获得了能力，去创业、去加入企业、去做自己的事，Ha7ch不收后续费用。这种开放性和YC的校友文化一脉相承——"Ha7ch最早一批在真实企业场景中成长的FDE"本身，就是最强的能力背书。

FDE天然能产生现金流。Builder为企业解决问题就有收入，不需要先拿一笔投资才能启动。这和创业完全不同——创始人要吃饭、要交房租、要发工资，必须融资。但一个FDE Builder，只要接了一个企业的单，就有收入。这意味着加速器模型不需要像VC那样烧大钱，它更像一个"帮助人开始赚钱"的催化剂。

为什么是他——设计工程教会的不止是设计

聊到这里，你可能会好奇：Lawted为什么能看清这些？

他的背景不是标准答案。哈佛设计工程硕士（MDes Engineering）、斯坦福HAI科研助理、阿里腾讯MiniMax工程师——这条路径上不缺技术硬货。但真正的区别不在履历，在思维方式。

设计工程这个学科要求一件事：同时理解产品、设计、工程和人的行为。不能只懂技术，也不能只会画PPT。既要能和工厂老板聊清楚痛点，又要能回去用Claude Code把方案实现出来。

Lawted把FDE分成"大厂平台型"和"土FDE"，和设计工程的训练分不开。纯计算机工程背景的创业者，往往从技术出发——有了新模型能做什么？技术边界在哪？而Lawted的习惯是反过来的：这个人遇到什么问题？什么方案最有效？

这两种思维模式，落地后的差距有多大？如果十年前的技术能解决问题，就用十年前的。企业买的不是技术新旧，是问题有没有被解决。这个思路听起来理所当然，但在AI创业圈里非常稀缺——太多人在追逐最新的模型版本，而不是追问"这个工厂老板到底需不需要GPT-4"。

Lawted没有那么技术崇拜。这是他和纯技术背景创业者最大的区别。最重要的不是使用多新的技术，而是理解技术边界，快速实现真正有用的方案。他给自己定位成"超级FDE"——进入工厂、物流企业、跨境团队、赛车队，和一把手谈战略，也和一线员工聊日常。

以前在大厂，他接触的是复杂软件系统的抽象架构；进工厂后，第一次看到流水线怎么运转、硬件怎么制造、工人和管理者怎么协作。这跟他在赛车队的经历如出一辙：不是先问"上什么模型"，而是先观察车队怎么管理比赛数据、怎么做决策，再判断AI能插在哪里。

说穿了，纯CS背景的人看到新模型想的是"能做什么"，设计工程训练出来的习惯是先问"这里的问题到底是什么"。这些经历不只是帮助他理解FDE，也在充实他对商业、产业、社会运行方式的认识。

当然，FDE能力可以训练，但不可能通过一套课程快速培养成资深FDE——这需要时间积累。Lawted的阶段性答案是：在Ha7ch发现底层能力（学习、主动、访谈、追问），然后用真实项目长行业经验。你可以教一个人怎么问问题，但没法教他对一个行业的直觉——那必须泡在里面。

回到开头那个画面：四月，龙虾进口旺季，一位哈佛硕士通过"装龙虾"认识了一位年营收过亿但没用过豆包的货代老板。八个月后，Lawted的选择已经清晰：以社群和人才为核心，项目用来验证，工具用来沉淀，商业化是为了让这套网络持续转下去——而不是最终目的。Ha7ch像一所没有围墙的学校，Alvenda是学校毕业生的实战场。

我问他，如果重来一次会做什么不同。他想了两秒："更早做自媒体。"连续做出足够多小项目，持续公开表达——不是为流量，是为让更多人看到FDE到底是什么、能做什么。Build in Public，本身就是一种筛选和连接。

说到底，FDE最终不是靠说服证明自己。再漂亮的PPT也打动不了一位工厂老板——他见过太多"数字化方案"来了又走。FDE靠的是在很短时间内做出可见结果：系统上线了，订单自动处理了，员工晚上不用加班了。

AI落地不是靠买更多软件。是靠让懂现场的人，带着AI进去，把问题一个一个解决掉。

那位货代老板现在用豆包了吗？

Lawted笑着说，不重要。重要的是他的跟单员现在每天六点就能下班。

更多对话细节

Q1：你从一个写代码的工程师，转向做FDE社群和产业落地，这个变化是怎么发生的？

Lawted：这个转变大概发生在今年四月。那时候我认识了一位在物流行业做了十年的朋友，我们经常一起吃饭。那段时间龙虾很火，他就通过"装龙虾"这件事，把我介绍给了一位货代公司的老板。

我们最开始其实只是以装龙虾、认识朋友的名义过去，但聊着聊着发现，这位老板甚至还没有真正用过豆包这样的AI产品。这件事对我冲击很大。

因为我之前接触的很多东西，都是硅谷、斯坦福，或者AI行业最前沿的研究和产品。在那个语境里，大家讨论的是Agent、模型能力、工作流和各种新的技术范式。但到了真实企业现场，我突然发现，AI距离大量普通企业和普通人其实还非常远，中间存在一个巨大的gap。

更有意思的是，这些老板不是没有焦虑。他很清楚AI正在发生，也知道自己的企业应该用上AI，但他不知道从哪里开始，不知道AI到底能解决什么问题，也不知道应该找谁来做。

后来我们进入他的业务现场，看跟单员每天怎么工作。很多工作仍然依赖微信、Excel、PDF和人工复制，包括读取单据、录入字段、核对信息、处理异常。我们很快发现，这里面确实存在大量可以被AI优化和提效的环节。

那次经历让我第一次非常明确地感受到，AI真正的机会可能不只是在创造更前沿的技术，而是在把已经存在的技术带进真实产业。从那以后，我不再只关注海外最前沿的研究和产品，也不再只把自己看成一个写代码的工程师，而是开始把更多精力放在企业现场，理解真实工作流，判断什么问题值得用AI解决，再快速做出可以验证的系统。这也是我真正开始做FDE的触发点。

Q2：你的设计工程背景，对你理解FDE有什么影响？它和纯计算机工程背景有什么不同？

Lawted：我首先不会说自己已经在定义FDE行业标准，我更像是在提出一种观察和分类。比如我把FDE分成"大厂平台型FDE"和"土FDE"，也就是独立进入中小企业、自己完成需求发现和交付的创业型FDE。

我之所以能看到这两类FDE的差异，和设计工程背景是分不开的。设计工程要求一个人同时理解产品、设计、工程和人的行为。你不能只懂技术，也不能只会做访谈。你既要真正进入企业，和老板、一线员工沟通，理解他们到底需要什么，同时又要理解AI的能力边界，并且自己高强度地使用Agent、Claude Code等工具做过大量项目，知道一个想法能不能快速变成Demo，能不能真正上线。

我和纯计算机工程背景创业者最大的区别，可能是我没有那么技术崇拜。对我来说，最重要的不是用了多新的技术，而是理解技术的边界，然后快速实现一个真正有用的方案。

很多技术型创业者可能会从技术革新出发，先问："我有了一个新的模型、新的算法或者新的架构，我能拿它做什么？"但我更愿意从人的需求和工作流出发，先问："这个人现在遇到了什么问题，什么方案能够最有效地帮助他？"

如果十年前的技术已经能够很好地解决这个问题，我也会使用十年前的技术。因为企业真正购买的不是技术的新旧，而是问题有没有被解决。

Q3：为什么Ha7ch要叫"FDE Accelerator"，而不是培训机构或咨询公司？

Lawted：Ha7ch最早的起点，其实是我在Stanford做科研助理的时候。当时我和一些朋友就在讨论：未来会不会出现一种真正面向AI Agent的产品形态？我们那时候围绕Claude Code做了很多尝试，想做的不是简单地把AI加到原来的产品上，而是从一开始就让产品是AI-native的。

后来我回到国内，接触真实企业以后，发现这件事情和企业需求是不谋而合的。企业当然希望变得更AI-native，希望通过AI提效、降本，甚至重构原来的工作方式。但问题是，谁来梳理业务？谁来判断什么地方适合用AI？谁来把这些需求做成真正能运行的产品？

我后来意识到，这个角色就是FDE。所以Ha7ch从最早的AI-native Builder Lab，逐渐变成了我们所说的FDE Accelerator。

我们之所以把自己叫作Accelerator，而不是培训机构，是因为FDE本质上不是靠上课学出来的。它需要真正进入企业，需要驻场，需要和老板、一线员工沟通，需要面对不清晰的需求、旧系统、内部阻力和真实业务压力。这些东西很难靠一套课程模拟出来。

很多Builder现在做出来的东西，本质上还是toy demo，看起来很酷，但没有在解决真实问题。他们缺的不是再看一篇教程，而是一个进入现场的机会，真正去solve the real problem。

所以Ha7ch更像是给Builder一个真实试验田。让他们进入企业，看看自己能不能听懂业务，能不能发现老板表面需求背后的真问题，能不能做出真正被一线员工认可的东西。

如果要排序，"人、项目、公司"里面，Ha7ch当前最明确加速的是人。项目是训练场，但不是Ha7ch最终要占有的资产；公司可能是长期结果，但不是我们现阶段强行推动的目标。三者的排序应该是：先加速人，再通过项目验证人，最后其中一部分人可能从连续项目中发现真正重复的行业需求，进而创立公司。

Q4：Ha7ch和Alvenda到底是什么关系？是社群给商业公司输送人才吗？

Lawted：我不会把两者简单理解成"社群养商业"。Alvenda只是整个生态中的一环，而不是Ha7ch唯一的商业出口。

我现在在Alvenda这边更接近顾问和联合创始人的角色，主要还是在项目方向、FDE人才判断、需求分析和行业资源上提供支持。但我个人的主要精力仍然会放在Ha7ch，因为我更想长期建设的是FDE的人才网络、方法论和社区基础设施。

Alvenda的价值是让一部分方法和判断在真实商业环境里被验证。因为如果Ha7ch一直只做社群、活动和理念传播，却没有真实项目进入企业现场，它很难获得长期可信度。别人一定会问：你们有没有真正承担过项目？有没有面对过交付、上线、客户预期和组织阻力？

但反过来，也不应该只有Alvenda的项目经验能够沉淀回Ha7ch。FDE本身是一个非常泛的领域，不同行业有完全不同的工作流、业务规则和落地方法。物流的解法不一定适用于制造，制造的经验也不一定能直接迁移到教育或金融。所以我更希望Ha7ch成为一个行业知识不断汇聚、交流和迭代的地方，而不是某一家交付公司的内部培训部门。

目前来说，我们还没有遇到特别明显的利益冲突。Ha7ch从一开始就坚持非盈利和开放的定位。我们帮助一个Builder成长为FDE，并不意味着要占有这个人，也不意味着他之后必须加入Alvenda。

我觉得它更像一所学校，或者像哈佛这样的校友网络。哈佛不会因为培养了一个学生，就要求他毕业后必须留在哈佛工作。Ha7ch也应该是这样。我们给Builder场景、反馈、连接和背书，但不会绑定他的职业选择。

如果未来一个Ha7ch培养出来的Builder想参与Alvenda的项目，但客户需求和他的长期成长方向不一致，我不会为了填项目缺口而强行把他放进去。Alvenda可以提出机会，但Builder应该拥有选择权。一个健康的生态不能建立在占有人才的基础上，而应该建立在长期信任和双向匹配上。

Q5：很多人说FDE就是外包换了个英文title，你怎么回应？

Lawted：很多人一开始也会问我，FDE不就是把原来的驻场工程师或者外包换了一个英文title吗？但我觉得它们最根本的差异，不在于是不是坐在客户办公室工作，而在于起点和终点完全不同。

传统外包或者驻场工程师的起点，通常是方案已经基本确定。客户会告诉你，我要开发一个系统、增加一个功能、完成多语言适配，工程师接到需求后负责执行。

但FDE的起点往往是一个极其模糊的问题。可能只是因为你去给一个物流老板装了一次龙虾，他突然跟你说："我也想用AI提效，但我完全不知道应该从哪里开始。"这才是FDE真正的起点。它没有PRD，没有确定方案，甚至连问题是什么都还不清楚。

FDE需要进入现场，观察员工怎么工作，和老板、一线人员不断沟通，把这种极其模糊的需求逐渐梳理成明确的工作流，再变成GitHub Issue，最后才变成生产级别的代码。

终点也不一样。传统外包交付的终点往往是产品或者功能完成，验收以后就可以收款。这个产品最后有没有人使用，能不能真正帮客户获客、降本或者提高效率，通常不在外包团队的责任范围内。

但FDE更强调为结果交付。在适合按效果结算的项目里，如果做出来的系统不能帮助客户产生有效线索、降低成本或者提升处理效率，那么这个东西本身就没有价值，也不应该仅仅因为代码写完了就获得全部费用。

当然，不是所有项目都能采用纯效果付费。但FDE的价值判断必须始终以客户结果为终点，而不是以功能列表为终点。

所以我认为，FDE并不是简单的驻场换皮。只改title，仍然按照客户PRD写代码，当然还是传统外包。真正的变化有四个方面：第一，FDE的起点是模糊问题，而不是确定方案；第二，FDE拥有问题定义权，而不是只负责执行；第三，FDE的终点是业务结果，而不只是完成产品；第四，Coding Agent把定制软件的生产成本大幅降低，使一个人或小团队有可能完成过去需要完整组织才能完成的工作。

没有这些变化，它就是换皮；有了这些变化，它才是一种新的组织和交付模式。

Q6：为什么你说Coding Agent不是FDE的辅助工具，而是这一轮FDE爆发的前提？

Lawted：FDE也不是凭空出现的全新物种。它吸收了咨询、产品、工程、售前和实施的一部分能力。但真正让这种模式在今天成立的最大变量，是Claude Code、Codex这一类Coding Agent。

过去给一家企业做一套定制软件，需要一个完整团队，需要前端、后端、产品、测试和项目经理，成本可能达到几百万。

今天有了Coding Agent，同样一套东西的生产成本可能下降一个数量级。过去中小企业根本买不起定制化方案，但如果一套解决方案从两三百万降到二三十万，甚至变成一年四五万元的持续服务，它就开始进入大量中小企业可以接受的范围。

原来需要一个团队才能完成的交付，现在可能一个懂业务、懂产品、懂工程的人，加上Codex或Claude Code，就可以完成。

所以我认为，Coding Agent不是FDE的辅助工具，而是这一轮FDE真正能够爆发的前提条件。

以我现在服务的赛车队为例，客户会持续提出新的需求，但维护本身并没有想象中那么困难。我最重要的工作不是每天亲自写大量代码，而是观察他们的工作流，把需求梳理清楚，再转成GitHub Issue。到了晚上，我可以让Codex或Claude Code去完成这些Issue。

我真正不可替代的部分，是判断问题、澄清需求、定义边界，而不是机械地写每一行代码。随着模型继续增强，越来越多系统的实现会变成"把需求整理准确，然后交给Agent执行"。所以技术实现本身会越来越便宜，现场判断和需求定义反而会越来越贵。

Q7：你怎么看"大厂平台型FDE"和"土FDE"的区别？

Lawted：我自己把FDE分成两类，一类是大厂平台型FDE，另一类是土FDE，也就是创业型FDE，或者FDE OPC。

土FDE直接面对中小企业，没有一个必须销售的平台，也没有一个成熟产品在背后支撑。他可以根据现场需求自由选择技术，用GPT就用GPT，用Codex就用Codex，需要做AI加ERP的增量插件就做插件，需要做知识库、工作台或自动化流程就做这些。

他最终交付的不是某一个固定产品，而是客户问题的解决方案。这也是土FDE和传统软件销售非常大的差异。土FDE不先问"我手里有什么产品可以卖"，而是先问"这个客户到底需要什么"。

大厂平台型FDE的逻辑则完全不同。无论是Palantir，还是国内的飞书、钉钉、阿里云，本质上都是基于一个成熟平台，为客户完成一定程度的定制化。

比如我之前去安徽探访一家工厂，他们已经采购了飞书，也购买了AI额度。飞书团队就会进一步询问，他们是否需要安全帽识别、烟火识别等能力，再把监控数据接入飞书多维表格。因为客户已经购买了平台和额度，所以FDE服务可能作为附加服务提供。派过去的FDE可能已经给二三十家工厂做过类似项目，他到现场以后确认摄像头型号、系统接口和流程，很快就能完成。

这就是典型的大厂FDE：表面上看是在为某一家客户定制，实际上背后已经有成熟平台、标准组件和重复交付经验。

所以大厂FDE最终通常是在推动某个产品的销售、使用或续费。Palantir FDE背后是Foundry，飞书FDE背后是飞书和多维表格，钉钉FDE背后是钉钉，模型厂商的FDE背后则是模型、API、Coding Agent或云服务。

他们的优势是平台成熟、交付稳定、合规能力强，但也有天然限制：他们往往会把客户问题导向自己的产品。土FDE的优势则是技术中立、灵活、能够服务大厂暂时覆盖不到的中小企业，但风险是容易变成低价外包，也缺少大平台提供的品牌、工程和售后保障。

所以两者不是谁取代谁，而是服务不同层级的市场。

Q8：中国式FDE会长成什么样？它会是缩小版Palantir吗？

Lawted：我觉得中国式FDE现在仍然在探索中。

中国有大量制造、物流、跨境贸易和传统服务企业，内部存在非常多跟单、发单、审核、流转、录入和沟通流程。这些工作非常适合被AI部分自动化。

但中国市场也有一个非常现实的矛盾：企业愿意支付的价格比较低，而目前成熟FDE的人力成本又比较高。Palantir服务的往往是几百万、几千万甚至更大的项目，但中国大量中小企业可能只能接受几万到几十万元的预算。

这意味着中国式FDE必须更轻、更快、更依赖Agent，也更强调嵌入现有系统，而不是重做一套平台。

我不认为所有中国企业都需要照搬Palantir的Ontology路径。Ontology不仅是把企业里的对象、关系和动作统一建模，更重要的是在复杂组织里建立一层可溯源、可审计、可进行权限控制和数据合规审查的治理结构。对于政府、大型金融机构、跨国企业或者高度监管行业，这当然很重要。

但对中国大量中小企业来说，它往往过于重。很多中小企业首先要解决的，不是一个决策是否可以被完整审计，也不是跨部门、跨国家的数据权限如何统一，而是今天还有五个员工在手工录单，一张PDF需要复制二十次，一个订单需要在微信和Excel之间反复确认。

在这个阶段，先搭建一套完整的本体、权限和审计体系，成本可能远高于实际问题本身。

所以对于中小企业，更现实的方式是先找到一个高频、边界清晰的流程，用AI或数字员工把它做好，再根据企业规模、风险和合规要求，逐步增加权限、日志、溯源和审计能力。

不是所有企业都需要一个缩小版Palantir。它们更需要的是轻量、快速、能嵌入现有系统的解决方案。

我认为，中国式FDE最有可能形成的形态，不是缩小版Palantir，而是大量懂行业、懂沟通、能够借助Agent独立完成交付的小型团队和超级个体。

Q9：你说FDE要"卖成果"，但中国企业真的接受按效果付费吗？

Lawted：根据我目前接触企业的经验，中国老板其实并不排斥按效果付费，甚至很多情况下，他们会比接受传统软件订阅更容易接受这种模式。

第一个原因是，如果AI真正进入一个高频工作流，它带来的效果通常是比较显著的。比如原来需要几个人反复录入、核对和跟单，现在系统可以先完成大部分处理，只把异常情况交给人工；或者原来客服每天需要处理大量重复问题，现在AI可以承担其中相当一部分。只要这个效果可以被真实观察和量化，老板其实很容易理解它的价值。

第二个关键是，不要一开始用"软件订阅费"的语言和传统企业老板沟通。你一说每年交多少订阅费，他很容易联想到腾讯视频、爱奇艺，或者各种自己很少使用、却每个月都在扣费的软件。他会天然觉得，订阅是一项持续发生但价值不确定的成本。

我们更常用的说法是"数字员工的年薪"。虽然它从严格意义上并不是真正的数字员工，但对传统企业老板来说，这是一套更容易理解的价值语言。

老板对人的成本非常熟悉。他知道一个员工每年需要多少工资、社保、五险一金，还要承担招聘、培训、离职和管理成本。当我们告诉他，这套系统能够承担原来几个人的一部分工作，而它一年的费用相当于一个数字员工的年薪，他就更容易进行比较，也更容易作出决策。

比如一个系统经过验证后，每年能够为企业节省十万元、二十万元甚至更多的实际人力成本，我们可以讨论从创造的价值中拿出一定比例作为服务费用，可能是5%、10%或者20%。只要计算方式透明，企业通常是可以接受的。

但这里也要区分"价值定价"和"纯结果兜底"。并不是所有项目都适合承诺做不出效果就一分钱不收。

有些结果非常容易归因，比如系统实际处理了多少订单、减少了多少人工录入时间、降低了多少修正率，这类项目可以采用按处理量、节省成本分成，或者基础费用加效果奖金的方式。

但像品牌提升、销售增长和客户转化，往往同时受到产品、价格、渠道和市场环境影响，很难把全部结果归因给FDE。如果在指标、基线和双方责任没有定义清楚之前，就直接承诺纯效果付费，后续很容易产生争议。

所以更现实的方式，是在项目开始前先定义清楚原来的基线、衡量指标和双方能够控制的变量。对于能够清晰归因的部分，可以按结果结算；对于前期诊断、系统开发、部署和维护，则可以保留基础费用或者阶段性费用。

我理解的"卖成果"，不是服务商承担企业内部所有不可控风险，而是整个项目的价值判断要以业务结果为终点，不能只因为功能开发完成，就认为项目已经成功。

Q10：如果只能给企业决策者、AI创业者和工程师转型者一条建议，你会说什么？

Lawted：如果只能给一个关于"怎么让AI真正落地"的建议，我觉得第一件事不是继续听课，也不是再看更多行业报告，而是高强度地使用Claude Code，并且用它做出大量原来想做、但因为时间和成本一直没有做出来的东西。

很多人会说自己用过Claude Code，但如果你原来是怎么写代码的，现在只是把其中一部分代码交给Claude Code来写，我觉得还不够。真正的质变来自使用频率足够高，高到你开始重新理解什么是Agent、Agent可以承担什么，以及一个人的能力边界到底可以被放大到什么程度。

我自己比较明显的质变，是开始使用每月200美元的套餐以后。那时候我同时维护了很多产品，一个月内大概做了八九个相对完整的产品，前后启动了十多个项目。也是在那个阶段，我才真正意识到，一个人加上AI能够做的事情非常多。

以前凌晨三点想到一个想法，我可能先把它记下来，过几天再说，最后大概率不会做。但现在我可以直接打开电脑，把背景、用户、需求和我想要的结果讲清楚，让Agent开始工作。第二天早上，我可能已经能看到一个可以运行的版本，接着就可以发布、寻找第一批试用者，再根据反馈继续迭代。

只有当你以这样的频率不断从想法走到产品、再走到真实用户时，你才会真正理解Agent的能力，而不是停留在"它能帮我补代码"这一层。

所以，无论你是企业决策者、AI创业者，还是准备转型的工程师，我都建议你先连续做出足够多的小项目。这些项目不能只是放在本地自我欣赏的Demo，最好能够被真实发布，吸引到真实用户，哪怕最开始只有十个人使用。

第二个建议，是所有准备转型做FDE的人，都应该认真考虑做自媒体，也就是Build in Public。因为FDE最困难的问题之一，其实不是写代码，而是获客和建立信任。你怎么让企业知道你能解决问题？怎么让下一个客户相信你不只是会做Demo？最有效的方法之一，就是把你在真实项目里遇到的问题、思考过程、失败、成果和方法持续记录下来。

如果完全不做公开表达，只是埋头一个项目接一个项目地交付，那很容易重新变成传统外包。项目结束以后，经验只留在自己脑子里，没有形成品牌、方法论和新的客户来源，也就没有复利。

对企业决策者来说，我觉得有三个信号可以判断自己的团队是否需要一个FDE。

第一个信号，是你已经有明显的AI焦虑。你知道同行开始使用AI，也知道企业需要改变，但内部没有人能够把这件事具体化。

第二个信号，是你的公司还在持续招聘人员，去承担一些你直觉上认为AI已经能够替代的重复工作，比如录入、整理、审核、跟单、信息搬运和反复沟通。

第三个信号，不一定是降本增效，而是你单纯希望企业继续进步。有些老板并没有非常具体的KPI，不一定要求利润立刻增长多少、成本立刻下降多少，但他希望五年后回头看，今天开始做AI是一个正确的决定。

至于如何选择一个FDE或FDE服务商，我觉得现在很难给出一套绝对标准，因为市场还很早，真正成熟的服务商也不多。但有一个原则是，不要过于迷信title、名校背景和各种包装，最重要的是看对方能不能在很短时间内持续做出东西。

我会建议企业不要一开始就签一个特别大的合同，也不要只根据PPT和名头做选择。可以先为一次真实、小规模、高强度的合作付费，看对方能不能进入现场、理解业务、快速构建，并持续交付。

FDE最终不是靠说服证明自己的，而是靠在很短时间内做出可见结果证明自己的。

文章来自于微信公众号 “非凡产研”，作者 “非凡产研”