FDE · 企业 AI · 客户选择
大企业不找FDE，小企业又付不起：这个赛道到底服务谁？
FDE的客户不能只按企业大小来找。更值得做的，是那些问题足够贵、内部能力又不够完整的公司。
FDE 的客户不能只按企业大小来找。更值得做的，是那些问题足够贵、内部能力又不够完整的公司。
昨天刷到一条讨论 FDE 客户选择的帖子。
帖主转述了一个饭局故事：一家亚马逊业务做得很大的公司，没有找外部 FDE，而是长期养着一支开发团队，把选品监控、多账号运营、投流、上架、数据回测等流程封装进自研系统。
他的结论很直接：做 FDE 别盯着大企业，目标客户应该是那些底子差、问题多的中小企业。
评论区很快提出了两个问题。
有人问，一家"千万级营收"的公司，怎么负担两百名程序员？也有人说，中小卖家连这样的开发成本都承担不了。
这两个质疑都合理。原帖里的营收口径、团队规模和成本没有更多证据，不能当成已经核实的商业案例。
但这场争论意外地把 FDE 生意最难回答的问题摆到了桌面上：
大企业有能力自己做，小企业又未必付得起，外部 FDE 到底该服务谁？
答案不是"大企业"或"小企业"。
更实用的划分方式，是看一家公司的问题价值与内部交付能力之间，有没有形成缺口。
大企业为什么会把核心流程收回去
如果一套系统直接决定选品、广告预算、库存周转和利润，它就不只是一个效率工具。
它里面装着公司的运营规则、历史数据和竞争策略。外部团队可以参与建设，企业很难把长期控制权完全交出去。
业务越成熟，这种倾向越明显。
成熟公司通常有自己的技术团队，也有预算把高频流程做成内部系统。外部 FDE 即使进场，也更可能负责早期验证、特殊模块或技术迁移，很难长期掌握整条核心生产线。
所以，帖子里的故事即便删掉有争议的"200 名程序员"，剩下的判断仍然成立：
一项能力越接近企业的利润发动机，企业越倾向于自己拥有它。
这给外部 FDE 划出了一条边界。
你能帮客户搭起第一段路，却不能默认客户会永远把方向盘交给你。项目跑通后，客户可能招人接管、把代码并回内部平台，或者要求交付完整的维护能力。
这并不代表项目失败。恰恰说明它进入了企业的核心流程。
小企业的痛点最直接，预算却最容易算不过来
帖主把中小企业视为 FDE 的主要客户，原因不难理解。
这类公司往往没有完整的技术团队，日常又被大量手工工作拖住。老板能清楚感受到客服慢、运营忙、表格多、数据乱，却不知道怎样把问题拆成系统。
从需求密度看，它们确实适合 FDE。
从交付经济性看，事情没这么轻松。
FDE 要进现场、看流程、接数据、处理例外、培训员工，还要在上线后修改。如果客户只能拿出一个买标准软件的预算，却期待获得一套贴着自己业务生长的系统，双方很快都会觉得亏。
客户觉得："不就是做个自动化吗，为什么一直加钱？"
交付方觉得："需求每天都在变，这个价格根本做不完。"
最小的企业有时也是最难服务的企业。不是因为业务复杂，而是因为它没有多余的人配合整理资料、定义规则和验收结果。老板说一句需求，FDE 得把业务分析、产品设计、开发、培训和运维全包下来。
项目金额不大，服务浓度却很高。
FDE更适合服务"能力有缺口的中间层"
客户画像应该换一种画法。
一端是已经拥有强技术团队的大企业。它们有复杂问题，也付得起钱，但核心系统最终会被内部团队接管。
另一端是人数很少、利润很薄的小公司。它们的痛点真实，却很难承受长期定制，也未必有人能配合完成交付。
外部 FDE 更容易建立健康合作的，往往是中间那一层：
• 已经有稳定收入和明确流程；
• 某项重复工作正在持续损失时间、收入或客户；
• 内部有人懂业务，但缺少把流程做成 AI 系统的能力；
• 愿意提供样本、接口和业务负责人；
• 接受先做一个小范围验证，再决定是否扩大；
• 项目跑通后，能够自己运营，或者为持续服务付费。
这里的"中间层"不等于固定的员工数或营收规模。
一家几百人的工厂可能没有 AI 开发能力，却能组织质量、IT 和一线人员配合项目。一家几十人的跨境团队也可能数据完整、利润不错，并且愿意为一条核心工作流投入。
判断依据应该是交付条件，不是工商资料里的企业标签。
别先问客户多大，先算这四笔账
见客户之前，可以先做一次简单筛选。
第一笔：问题每个月损失多少
不要只听"我们效率很低"。把问题落到人时、返工、响应速度、漏单、广告浪费或库存占用上。
如果问题一年只损失几万元，就不适合用几十万元的定制方案解决。一个现成工具、一次流程调整，可能更划算。
第二笔：第一次验证需要多少配合
谁提供历史样本？谁解释例外？谁判断答案是否可用？IT 是否能开放必要接口？
客户只有预算，没有负责人，项目仍然启动不了。
第三笔：哪些能力必须由客户拥有
涉及定价、投放、风控、供应链策略的核心逻辑，要提前讨论代码、数据、配置和维护权归谁。
如果客户迟早要收回内部，FDE 的交付物就应该包括文档、评测、权限设计和接管培训，而不是留下一个只有自己会修的黑盒。
第四笔：第二个客户能不能少做一点
如果每个项目都要重新访谈、重新写接口、重新搭系统，这门生意只能靠不断增加人手。
健康的 FDE 业务要把现场经验沉淀成模板、连接器、评测集、行业规则包和交付清单。第一个客户付了最贵的学习成本，第二个客户的交付应该更快。
否则你卖的不是可复用能力，只是昂贵工时。
FDE的第一单，不该找"最痛苦"的客户
"越痛苦，越愿意付钱"听起来有道理，现实里经常相反。
有些企业之所以长期痛苦，是因为数据没人管、流程没人负责、部门之间互不配合。这样的客户会把所有旧问题一起交给 FDE，然后用一个很小的预算期待彻底解决。
第一单更应该找"准备好改变"的客户。
他不一定规模大，但至少愿意拿出一项真实任务、一批真实样本、一个能拍板的负责人和一套可验证的结果标准。
这四样东西比"老板很焦虑"重要得多。
外部 FDE 的市场并没有因为大企业自建而消失，也不会因为中小企业数量多就自动成立。它存在于一个很窄的缺口里：客户已经为问题付出足够高的代价，却还没有能力独立完成改造。
找到这个缺口，项目才有机会同时满足两件事：客户算得过 ROI，FDE 也能赚到合理的钱。
最后
原帖提醒了做 FDE 的人一件事：别以为大公司预算高，就一定愿意把核心系统交给外部团队。
评论区又补上了另一半：别以为中小企业痛点多，就一定负担得起高浓度服务。
两边放在一起，结论反而清楚了。
FDE 不该按"大客户"或"小客户"选市场。应该寻找这类公司：问题已经贵到必须解决，内部能力又暂时接不上，同时愿意拿出人、数据和预算一起完成验证。
企业规模只能帮助你估算预算，不能替你判断项目是否可交付。
如果一个客户既没有内部负责人，也不给真实样本，只说"先做出来看看"，不管它有两百人还是两万人，都不是一单好生意。
来源与说明： 本文根据 阿川在 X 发布的帖子及其公开评论 重构。原帖中的企业营收与开发团队规模来自饭局转述，评论区对其经济合理性提出质疑，本文未将该数字作为已核实事实。评论区存在大量无关或疑似垃圾回复，本文只采用与 FDE 客户选择直接相关的观点。
完