FDE 小团队如何从 0 到 1 做企业 AI 服务：获客、报价、交付与验收 SOP

技术教程2026-08-3018 মিনিট পড়ুনFDE企业 AIAI 服务Agent 交付SOW测试验收AI 咨询企业数字化

很多人第一次接触企业 AI 服务，会把它理解成一项技术工作：客户提出需求，团队搭一个知识库、Agent 或工作流，测试能跑，部署上线，项目就结束了。

真正做过企业交付以后会发现，技术开发只是中间的一段。前面还有客户从哪里来、客户值不值得做、老板说的到底是不是需求；后面还有范围怎么守、错误谁负责、如何测试、谁来验收、增加需求怎么算钱，以及项目完成后能否顺利交接和回款。

企业老板可能只会说：

“我要在公司里搞 Agent。”

或者：

“我要做一个知识库，把老员工的经验都放进去。”

甚至：

“能不能用 AI 替掉一部分人？”

这些话是方向、预算或想象，还不是可以直接交付的需求。FDE（Forward Deployed Engineer）小团队真正要做的，是在客户愿望和实际落地之间找到一个双方都能理解、能够测试、可以验收的结果。

本文整理自 Hedy Zhang 于 2026 年 8 月 28 日发布的企业 AI 服务实践文章，并按交付顺序重新编排。重点不在于展示一个炫酷 Demo，而在于说明一单企业 AI 服务如何从模糊想法走到可交付闭环。

一、先记住十步交付链路

企业 AI 服务可以先抽象成十个阶段：

线索
  → 初筛
  → 现场调研
  → 需求边界
  → 报价
  → SOW
  → 开发交付
  → 测试验收
  → 交接回款
  → 复盘复用

小团队竞争的重点，不是把 Agent 演示得最复杂，而是能否把这十步稳定走完。每一步都应该产生下一阶段可使用的产物：

阶段	最小产物
线索	客户身份、问题、时间和预算信息
初筛	是否值得继续投入的判断
调研	真实流程、资料、角色和风险记录
边界	第一阶段目标、明确不做项和前置条件
报价	与范围、价值和风险对应的价格方案
SOW	双方确认的工作范围和责任边界
开发	可运行的 POC 或阶段交付物
测试	正向、反向、边界用例和结果记录
验收	客户确认的完成证据
复盘	可复用的模板、案例和风险清单

二、小团队卖的不是 AI，而是可验收的结果

企业不会因为你使用了更先进的模型，就天然愿意多付钱。客户愿意购买的是具体问题被解决之后的变化，例如：

客服、售后和销售更快找到产品资料；
重复录入工作减少，员工把时间投入到更有价值的环节；
运营人员脑中的流程变成可运行、可交接的软件；
原本依赖某个老员工的经验变成可查询、可维护的知识；
某个业务环节的等待时间、错误率或沟通成本下降。

因此，第一次访谈不要先问“用哪个模型”，而要问：

当前哪一步最烦、最慢或最容易出错？
现在是怎样完成的，谁在负责？
一周或一个月大约消耗多少时间和成本？
做完以后，哪一个具体结果会发生变化？
谁能确认这个变化是否真的发生？

企业 AI 项目的难点，往往不是把代码写出来，而是客户自己的资料、流程、角色和目标还没有被说清楚。这些混乱不是项目开始前必须由客户独立清理干净的东西，它们本身就是调研和交付的一部分。但小团队也不应该因此承诺“什么都能解决”，第一阶段仍然必须收窄。

三、第一批客户从哪里来？

有 To B 经验：优先使用信任关系

中大型企业的第一批机会，通常来自老客户、熟人和销售伙伴，而不是完全陌生的流量。原因很现实：企业可能会向外部团队开放业务资料、内部流程、系统权限和经营信息，首先需要解决的是信任问题。

销售伙伴的价值也不只是转发联系方式。他们往往知道：

谁是真正的决策人；
老板关心收入、效率、风险还是成本；
预算从哪个部门出；
部门之间有什么利益关系；
哪个负责人真正能配合调研和验收。

稍微复杂的跨部门项目，纯技术团队很难独立处理这些关系。与可靠的销售或交付伙伴长期合作，通常比单纯追求陌生流量更现实。

没有客户和案例：先进入真实需求现场

没有企业客户、案例和销售资源的新团队，可以从以下入口建立第一条交付记录：

OPC、AI 应用和企业服务社区；
本地创业者、企业老板和行业交流活动；
先参与成熟团队的部分交付；
为熟人企业做范围很小的付费诊断或 POC。

参加活动时，不要上来推销“我会做 Agent”，而是了解对方正在怎样工作：哪个环节最重复、最慢、最容易出错，过去尝试过什么，为什么没有解决，以及谁会为结果负责。

第一单最重要的价值不一定是利润最大化，而是获得一条完整、可复盘、以后敢拿出来证明能力的交付记录。

自媒体是放大器，不是商业闭环

内容和个人品牌可以帮助陌生客户理解你做过什么、怎样判断问题，也能让线下认识的人在线上继续观察你。但有曝光不等于完成商业转化。

一条合格线索至少应该回答：

对方是谁，代表个人还是企业；
现在有什么正在发生的具体问题；
什么时候需要看到结果；
是否愿意为诊断、方案或下一步付费。

只有泛泛询问“企业 Agent 怎么做”，却不愿提供背景、资料和目标的人，不应该立刻获得一份免费的完整方案。

四、选客户往往比选技术更重要

客户选错以后，技术越强，损失可能越大。可以从以下维度判断一单项目是否值得继续：

判断维度	需要确认的问题
企业状态	企业是否仍在增长，是否有稳定经营和试错预算？
问题强度	需求是否正在产生真实的时间、成本或机会损失？
决策意愿	决策人是否真的想做，而不是只想了解概念？
业务负责人	是否有人负责资料、流程、测试和最终验收？
数据与系统	能否接触真实资料、用户、流程和必要权限？
第一阶段	能否在几周内缩小范围并验证最大风险？
付款可靠性	决策、合同、付款节点和合作关系是否清楚？

有些项目应该直接拒绝或暂停，例如：

老 ERP 没有 API，却要求自动读写全部业务数据；
没有人负责确认哪份资料有效；
老板要求“全公司 AI 化”，却说不清第一批用户是谁；
客户无法提供测试数据，也没有人参与验收；
要求团队承担所有结果，但不愿确认范围、预算和前置条件。

知道什么不做，本身就是交付能力的一部分。

五、现场调研：不要只听老板讲功能

老板通常能说清预算和愿望，但不一定能说清实际流程。复杂项目不应只在会议室听老板讲完一个小时，就回去写合同。更有效的做法是进入办公室、工厂或研发现场，与实际使用者和业务负责人一起还原工作过程。

访谈时不要只问“你想要什么功能”，而应该逐步追问：

谁在什么时间收到什么输入？
打开哪个系统或文件？
根据什么信息做判断？
遇到例外时找谁？
最后把结果写到哪里？
哪些步骤写在制度里，哪些步骤只存在于群聊、电话和个人表格里？
哪些规则大家都知道，但从来没有正式记录？

资料正确，不等于答案正确

企业知识库项目经常会遇到一种反直觉问题：AI 准确地读取了错误资料。

例如，一份多年前打印的产品设计文档存在印刷错误，老员工都知道并会在脑中自动修正，但线上资料没有记录这个例外。知识库准确解析并召回原文后，AI 就会非常“准确”地给出错误答案。

因此，调研不能只确认资料能不能导入，还要确认：

哪份资料是当前有效版本；
历史文档是否存在已知错误；
文档和实际流程是否一致；
哪些例外规则只存在于人的经验中；
谁负责确认知识的真实性；
AI 答错时应该拒答、转人工还是引用来源。

AI 可以高质量处理错误知识。知识治理本身，往往是企业 AI 项目的一部分。

六、把老板的愿望收窄成第一阶段结果

调研结束后，要把“想做一个 Agent”转换成一个可测试的业务结果。

一个合格的第一阶段目标应该包含：

明确的使用者；
明确的业务流程；
明确的输入和输出；
可以取得的资料和系统权限；
可量化或可判断的验收标准；
明确的人工接管边界；
几周内能够验证的范围。

例如，不要写：

建设企业级 AI 知识平台，覆盖全公司业务。

可以改成：

为售后团队提供产品资料问答助手。
第一阶段覆盖 50 份已确认版本的产品文档，
回答必须引用来源；资料不足时明确拒答，
无法确定的问题转交指定业务负责人。

后一个目标更容易报价、开发、测试和验收，也更容易在第一轮失败后调整。

七、报价：价格要对应范围、价值和风险

报价不能简单等于“开发天数 × 一个单价”。至少要考虑：

调研、方案设计和会议成本；
数据整理、清洗和标注成本；
开发、集成、测试和部署成本；
客户配合程度；
数据权限、准确率和安全要求；
是否需要驻场；
旧系统接入和兼容风险；
培训、售后和维护周期；
销售、设计、测试、硬件或其它合作成本；
失败责任和需求变更风险。

价格最终要能够解释三件事：交付范围是什么、客户获得的价值是什么、团队承担的风险是什么。

报价建议分阶段

如果双方还不熟、需求也不明确，可以先报价付费诊断或 POC，而不是免费投入大量时间。阶段可以设计成：

需求诊断：还原流程、资料和风险；
POC：验证最大技术或业务风险；
第一阶段交付：完成明确范围内的最小结果；
扩展与维护：按新增范围、周期和责任单独报价。

如果客户预算明显无法覆盖必要工作量，应尽早停止继续深挖。需求增加，就必须增加预算、延长周期或减少原范围，不能同时要求预算不变、周期不变、范围持续扩大。

八、SOW 是小团队最重要的护身符

SOW（Statement of Work，工作范围说明）不是为了和客户对抗，而是为了让双方在项目开始前对同一个结果有相同理解。

一份可用的 SOW 至少应该写清：

本次具体交付什么；
哪些内容明确不做；
甲方需要提供哪些资料、账号、接口、环境和人员；
哪些前置条件不满足时项目无法继续；
各阶段的时间节点和交付物；
双方如何测试；
什么结果算验收；
新需求如何变更；
哪些风险由哪一方承担；
培训、售后和维护做到什么时间结束；
付款节点与阶段成果如何对应。

企业 AI 项目常见的阻塞包括资料没有整理、接口权限没有开放、没人确认有效版本、负责人不参加测试和旧系统没有 API。这些依赖必须在 SOW 中写出来，不能等项目做到一半才发现。

九、技术选择：不要为了证明先进而硬上 AI

客户要求数据不能离开公司，就讨论私有化和本地部署；客户允许使用云模型，就比较云端方案。客户没有明确技术偏好时，优先选择团队熟悉、出现问题能够修复和维护的技术。

技术上能做，不代表交付上值得做

如果客户的 PDF 中包含大量产品图片、三维图、尺寸标注和不规则表格，而自动解析成本很高，人工录入可能比强行自动化更可靠。

如果旧 ERP 没有 API，也不应该为了展示技术能力而设计一套不可维护的绕过方案。可以明确这部分不在第一阶段范围，或先把需求改成导入导出文件。

企业买的是可靠结果，不是让供应商证明所有环节都可以自动化。必要时使用人工，也是一种工程判断。

AI Coding 可以加速开发，但不能取消工程

Codex、Claude Code 等 AI Coding 工具很适合把业务人员脑中的流程快速做成 Demo。Demo 交给研发团队后，往往能显著减少沟通成本。

但长期运行的大系统仍然需要：

模块边界；
代码所有权；
测试和回归；
日志和监控；
版本与发布流程；
维护责任；
失败恢复和人工接管。

一句话概括：AI Coding 可以加速工程，不能取消工程。

十、测试集必须在交付前设计

AI 项目不能用“我试了几次，感觉还不错”验收。测试集应该根据每一个需求点设计，至少包含正向、反向和边界用例。

知识库和 Agent 测试集

测试集可以覆盖：

有确定答案的问题；
资料不足的问题；
文档版本冲突的问题；
超出权限的问题；
恶意或无效输入；
工具调用失败；
重复提交和幂等性；
需要转人工的问题；
更换模型、提示词或知识版本后的回归。

确定性问题可以自动判断，例如产品认证、接口参数和标准流程。没有标准答案的问题，则需要业务专家评估是否“足够有用、足够安全、符合实际工作方式”。

乙方自测与甲方验收集分离

一个更可靠的做法是：

乙方根据需求制作自测集；
将测试结构交给客户确认是否遗漏真实业务；
乙方完成自测并记录结果；
客户保留一组不公开的验收题目；
按预先确认的标准判断达标、补修或变更。

客户最终验收的不是模型分数，而是业务结果是否达到约定标准。技术团队负责系统实现，业务专家负责定义什么叫真正答对。

十一、需求变更：预算、周期和范围至少要动一个

真实项目一定会发生变化。可以把变更分成三类：

变更类型	推荐处理
客户新增合同外需求	增加预算，或删减原范围后替换
乙方低估原需求难度	说明原因，重新协商周期和方案
前置条件不成立	由客户补齐条件，或暂停对应范围

不要用沉默和加班掩盖范围变化。项目拖到最后，双方对“当初答应过什么”的记忆往往不同，最终会同时伤害交付质量、关系和回款。

最小的变更记录至少包含：

变更内容；
变更原因；
对范围、周期、预算和风险的影响；
谁提出、谁批准；
是否替换原有内容；
新的验收方式。

十二、验收、证据和回款要从第一天开始准备

不要等项目做完才考虑验收和回款。从项目开始就应该保留：

合同和 SOW；
需求确认记录；
甲方提供资料和权限的记录；
阶段演示与确认；
测试集和测试结果；
需求变更记录；
交付、培训和部署记录；
客户验收意见和最终确认。

这些证据可以回答：

双方当初确认了什么；
甲方是否提供了前置条件；
哪些内容已经交付；
哪些变更得到确认；
验收标准是否达到；
当前未完成事项属于原范围、客户依赖还是新增需求。

真正降低坏账风险的第一步，不是研究项目失败后的追债技巧，而是在项目开始前筛选经营健康、关系可靠、决策和付款流程清晰的客户。信任很重要，但证据不能少。

十三、交付完成后，要把一单变成下一单的底座

小团队如果每一单都从空白文档、空白代码和空白判断开始，很快会被交付拖垮。

每个项目结束后，至少沉淀：

客户初筛问题；
现场访谈清单；
流程还原模板；
报价成本项；
SOW 模板；
常见前置依赖；
POC 风险验证模板；
正向、反向和边界测试结构；
上线、交接和培训清单；
需求变更记录模板；
可以匿名公开的真实案例。

一次知识库项目中发现的错误纸档，可能沉淀成数据治理服务；一次 ERP 接入失败，可能变成下一次初筛时必须询问的问题；一次 AI Coding Demo，可能沉淀成业务人员表达流程的方法。

完整商业闭环不是“发内容—有人私信—成交”，而是：

真实项目
  → 形成判断
  → 沉淀方法和模板
  → 对外分享
  → 获得新线索
  → 初筛和诊断
  → 新项目交付
  → 产生新案例

十四、企业 AI 服务完整 SOP

1. 线索初筛

客户是谁，所在行业和角色是什么？
当前最具体的问题是什么？
现在怎样处理，每周消耗多少时间、成本或机会？
已经尝试过哪些工具或方案？
谁负责推动，谁负责验收？
希望什么时间看到什么结果？
是否有明确预算？

2. 客户判断

企业是否仍在增长或具备试错能力？
问题是否正在产生真实代价？
是否能接触真实使用者、流程和资料？
是否有内部负责人？
第一阶段能否在几周内验证？
决策、合同和付款关系是否可靠？

3. 现场调研

访谈老板、负责人和实际使用者；
还原真实流程，不只看制度文件；
核对资料版本、数据位置和系统权限；
找出口传规则、个人表格和历史例外；
区分事实、判断、假设和待确认项；
标记 AI 可以处理、必须人工处理和暂时不做的部分。

4. 方案与报价

把大愿望缩成一个最小业务结果；
先验证最大技术或业务风险；
估算调研、开发、测试、部署、培训和合作成本；
确认准确率、权限、安全、并发和运维要求；
让价格对应范围、价值和风险；
预算不匹配时及时停止免费深挖。

5. SOW

目标与使用者；
交付范围；
明确不做的内容；
甲方前置依赖；
技术假设和验证项；
阶段节点和交付物；
测试和验收标准；
需求变更流程；
付款节点；
售后与支持边界。

6. 开发与交付

优先使用团队熟悉、能够维护的技术；
POC 先验证最大风险；
不强行接入没有 API 的旧系统；
自动化成本高于人工时，评估人工方案；
每个阶段保留确认记录和交付证据；
范围变化立即沟通，不靠加班隐藏。

7. 测试与验收

每个需求点设计正向、反向和边界用例；
自测集交客户确认是否遗漏；
客户保留独立验收集；
测试资料不足、权限、拒答和人工接管；
更换模型、提示词或知识版本后重新测试；
验收结果与阶段付款节点对应。

8. 交接与复盘

完成交付、培训、账号和资料交接；
让客户知道什么时候可以信任 AI，什么时候必须找人；
保存合同、沟通、测试和验收记录；
复盘范围偏差、技术风险和客户配合；
沉淀模板、测试结构和可复用组件；
经客户允许后，将项目匿名整理成案例。

总结：小团队不需要假装全能

FDE 小团队从 0 到 1 做企业 AI 服务，核心不是找到一套万能 Agent，而是把客户愿望逐步转化为可交付结果：

找到真实问题
  → 选对客户
  → 进入现场
  → 收窄第一阶段
  → 写清 SOW
  → 选择能维护的技术
  → 用测试集证明结果
  → 保留证据并完成验收
  → 复盘并复用

需要销售伙伴时就合作，需要其它技术角色时就找可信的交付伙伴；老系统没有 API 时不要硬碰，模型达不到标准时就换模型或诚实说明当前做不到，自动解析成本过高时也可以用人工把项目交出来。

企业最终要的不是一个听起来先进的方案，而是：能不能用，错了谁接，做到哪里算完成，以及供应商离场后能不能继续运行。技术决定你能不能把东西做出来，客户判断、范围管理、测试验收和商业关系，决定你能不能完成交付并获得下一次信任。

本文整理自 Hedy Zhang 于 2026 年 8 月 28 日发布的企业 AI 服务实践文章。文中的客户筛选、报价、SOW、测试和回款方法属于实践参考，不构成法律、财务或合同建议；具体项目应结合客户行业、数据安全、采购流程和当地法律要求，由专业人员审阅合同与责任边界。

সম্পর্কিত গাইড

企业 AI 培训与落地方法