FDE 企业 AI 交付复盘：项目报价、范围控制与收款设计
本文根据企业 AI 从业者唯庸于 2026 年 10 月 18 日发布的X 帖整理。文中营收、成本、报价和项目周期等数字均为作者个人经历与建议，未经独立核验，不应直接视为行业统计或通用报价标准。
企业 AI 项目看起来是在把模型接入业务，实际交付往往从理解流程、整理资料和建立信任开始。唯庸的复盘提醒从业者：模型和代码只是项目的一部分，能不能把服务范围、风险和成本谈清楚，决定了交付是否可持续。
小单很多，利润未必成立
作者回顾，团队曾通过电商平台承接几千到两万元左右的智能体小单，几个月完成约 200 个项目、营收超过百万元。但扣除渠道、交付、税费和场地成本后，作者称实际到手不足一成。大量时间还花在筛选线索、沟通需求和向客户解释 AI 上。
这组数字是作者团队的个案，不代表其他团队也会有相同收入或成本比例。它揭示的经营问题更具参考性：订单数量和营收不等于利润；获客成本、售前沟通、实施返工与后续支持都需要纳入单笔项目核算。如果每个小单都要重复做大量教育和诊断，表面上高频的交付也可能消耗团队的有效产能。
FDE 的核心是对交付结果负责
FDE（Forward Deployed Engineer）常被用于描述贴近客户现场、把工程能力带进实际业务的角色。作者指出，市场上有人把实施外包、垂直场景创业或工具培训都冠以 FDE 之名，但名称本身并不能说明服务质量。客户最终关心的是问题是否解决、流程是否改善，以及交付结果能否被业务使用。
企业的 AI 化通常不是拿到需求后马上开发。客户可能还没有梳理过业务流程，资料分散在不同系统和员工手中，对模型能力也缺少判断。项目早期要先找到适合 AI 介入的环节，并与业务负责人建立信任。作者特别强调直接与老板或有决策权的人沟通，因为他们能推动流程、数据和员工协作。
因此，售前阶段也应有清楚边界。免费初谈可以用于判断是否匹配，但深入诊断、完整方案和可执行设计都是工作成果，可以拆分为独立服务。若客户只说“先帮忙看看”，而交付方持续访谈、整理流程并产出方案，却没有收取诊断或方案费用，就可能把真正的项目劳动免费交付出去。
先限制项目范围和周期
作者团队为企业项目设定了金额和周期上限：项目控制在 20 万元以内、交付周期约一个月。这是作者用来约束自身复杂度的经营规则，不是所有 FDE 团队都适用的标准。其逻辑是先避免项目范围不断扩大，防止团队陷入长期、难验收、难回款的交付泥潭。
面对“覆盖所有业务流程”的大而全设想，可以先挑选一个边界清晰、业务价值明确且模型能力适配的环节作为第一期。小范围试点不只是缩小开发量，也帮助双方验证数据条件、流程配合和效果预期。只有第一期结果被客户认可，后续扩展才有事实基础。
三种报价思路
按人天估算
当技术难度和工作量可以估计时，可以按角色、人数和工作日拆出人力成本，再结合团队的整体成本结构确定报价。作者举例：产品经理与两名研发投入约一个月，人力成本约 1.8 万元；若人力成本约占报价的四成，倒推得到 4.5 万元，再留出余量报价约 5 万元。
这个例子是作者的计算演示，具体人天价格、成本占比和工作日都应以团队实际情况重算。报价不能只加开发人员的工时，还要计入需求沟通、设计、资料整理、原型确认、测试、部署、问题修复和试运行支持。AI 项目还可能在初次开发后持续调优，预估时也要把这部分服务说清楚。
按交付物拆分
项目若有先后依赖，可以拆成若干阶段，并为每阶段定义交付物、验收条件和费用。例如先验证模型在客户业务中的效果与成本，交付评估报告；达到约定标准后，再进入开发阶段。若验证未通过，双方可以在第一阶段结束，而不必继续投入后续开发成本。
阶段拆分让客户先为一个可验收的结果付费，也让交付方避免在不确定性尚未消除时承担全部实施风险。关键是提前写清楚每阶段解决的问题、提供什么成果，以及进入下一阶段的条件。
缩小范围再报价
如果项目复杂到无法估算，问题往往不是缺少一种报价技巧，而是范围或技术风险还没有被理解。此时可以先把目标收窄到一个可验证的小问题，作为付费诊断或第一期试点，再依据结果决定后续工作。
先交付一个小而明确的结果，也比为整套“全业务 AI 方案”直接报出一个缺少依据的总价更容易建立信任。报价应对应可控的工作范围和交付责任，而不是承接客户尚未拆解的所有设想。
收款、算力与合同边界
作者建议把回款拆成两到三笔，并提出 5:4:1 或 4:4:2 作为参考比例，同时强调首付款应能覆盖已投入的开发成本。具体比例需要根据项目阶段、采购流程和客户信用协商；更重要的是，每次付款都对应明确的启动、阶段交付或验收节点，避免团队在没有资金保障时承担大部分成本。
模型调用成本与服务器、数据库等固定支出不同，会随使用量变化。若调用费用被含糊地打包进固定总价，客户使用量增长后，交付方可能持续承担无法预测的成本。可以在合同中明确测试额度、超额计费方式、谁负责充值，以及成本变动时如何处理。
同样，报价范围要覆盖从设计到运维的实际工作。需求沟通、部署、调优、试运行和问题修复若不在约定范围内，后续很容易形成无边界的免费支持。合同应把包含的服务、响应方式、变更流程和不包含的内容写明，让双方知道何时算完成，新增需求如何估价。
从一次成交转向逐期建立信任
作者分享的客户关系多来自重复合作：第一期先做较小范围的项目，交付结果后再讨论后续阶段。单期金额会按客户风险承受能力逐步增加。其核心不是固定的金额阶梯，而是每一次扩展都由上一次的可见成果支撑。
这也解释了为什么企业 AI 项目的第一单不一定适合追求最大合同额。客户购买的不只是代码，也是在承担流程改变、数据准备和团队采用方面的不确定性。范围较小、成果清楚、风险可控的第一期，有助于双方判断能否继续合作。
把作者的经验转成可执行检查项
准备承接企业 AI 项目时，可以先回答以下问题：
- 谁拥有业务决策权，谁会实际使用系统，谁负责提供资料和流程信息？
- 当前流程中哪一个具体环节适合先验证，成功标准是什么？
- 项目按人天、阶段交付物还是缩小范围后的试点定价更可控？
- 报价是否包含沟通、部署、调优、测试和试运行，哪些属于额外工作？
- 首付款、阶段验收、模型调用额度和超额费用是否写进合同？
- 第一阶段如何结束，客户拿到什么成果，满足什么条件才进入下一阶段？
这些问题不能替代财务测算或法律审查，但可以减少“先把方案做完再谈钱”、固定报价覆盖无限调用、需求持续扩张却没有变更费用等常见风险。对交付团队来说，利润率、验收边界和客户信任需要一起设计。