万字长文｜FDE 小团队如何从 0 到 1 做企业 AI 服务：获客、报价、交付与验收（附完整SOP框架）
很多人第一次接触企业 AI 服务，最容易把它理解成一个技术类工作：
客户提出需求，我们搭一个知识库、Agent 或工作流，测试能跑，部署上线，项目就结束了。
真正做过以后会发现，技术开发只是中间非常小的一段。
前面还有客户从哪里来、这个客户值不值得做、老板说的到底是不是需求；后面还有范围怎么守、错误谁负责、怎样测试、谁来验收、需求增加了怎么算钱，以及做完以后能不能顺利收回尾款。
我们见过很多企业老板。他们对 AI 的认知，比过去对大数据、移动互联网更强烈。最典型的情况是：老板自己用过豆包，开始接触 Codex、Claude Code，然后很自然地认为，AI 应该可以解决公司里的一切问题。
但他找到你时，往往只会说一句：
“我要在公司里搞 Agent。”
或者：
“我要做一个知识库，把老员工的经验都放进去。”
再激进一点：
“能不能用 AI 替掉一部分人？”
这些都不是可以直接交付的需求，只是一个方向、一笔预算，或者老板暂时的想象。
小团队真正要做的，是在老板的想象和实际落地之间找到平衡点，把一句模糊的话，变成双方都能理解、能够测试、能够验收的结果。
这篇文章不讲一个漂亮但跑不通的“AI 创业故事”。我会根据过去做 To B 和企业 AI 交付的经验，把一单企业 AI 服务从头到尾拆开：
客户从哪里来，怎样筛选，什么时候报价，为什么必须进场，SOW 怎么写，什么技术不要碰，测试集怎么做，需求变更怎么处理，以及怎样避免做完以后收不到钱。
整条链路可以先记成十步：
线索 → 初筛 → 现场调研 → 需求边界 → 报价 → SOW → 开发交付 → 测试验收 → 交接回款 → 复盘复用。
小团队做企业 AI 服务，拼的不是谁能把 Agent 演示得更炫，而是谁能把这十步稳稳走完。
一、小团队卖的不是 AI，而是一个能够验收的结果
企业老板不会因为你用了一个更先进的模型，就天然愿意多付钱。
他真正愿意付钱的，是某个具体问题被解决：
- 原来员工每天要反复查产品资料，现在可以更快找到答案；
- 客服、售后、销售不再一天到晚打断研发；
- 一项重复录入的工作少花了多少时间；
- 运营脑子里的流程变成了一套可以运行的软件；
- 一项原来依赖某个老员工的工作，开始有了可查询、可交接的记录。
所以我们判断一个项目时，第一件事不是问用哪个模型，而是问：
现在具体哪一步最烦、最慢、最容易出错？做完以后，工作会发生什么变化？
这也是 FDE 和普通软件开发最不一样的地方。
普通开发可以等产品经理把需求拆完，再按照任务写代码。企业 AI 项目刚开始时，客户自己通常也没有想清楚。资料可能没整理，流程可能靠口传，部门之间可能有冲突，老板以为的问题和员工每天真正遇到的问题甚至不是一回事。
这些混乱不是项目开始前应该由客户自行清理干净的东西。
它们本身就是交付的一部分。
但这不代表一个人要包办所有事情。
一个人可以完成一些简单、边界清楚的场景。项目稍微复杂以后，获客、产品、开发、测试、部署、运维和客户沟通不可能全部压在一个人身上，这时就需要与做过交付、彼此信任的伙伴合作。
所谓小团队，不是“一个人假装成一家公司”，而是核心人员足够少，决策链足够短，同时知道自己缺什么、应该找谁补上。
二、第一批客户从哪里来？
我观察到，身边很多想做 OPC 或 FDE 的人都有交付能力，真正缺的是客户资源和销售能力。
但“第一批客户从哪里来”不能只给一个答案。
已经做过 To B、手里有客户关系的人，和刚开始做企业 AI、没有案例也没有客户资源的人，走的不是同一条路。
路径一：有 To B 经验，或者想做中大型企业客户
对于中大型企业项目，第一批机会通常来自熟人、老客户和销售伙伴，而不是完全陌生的流量。
原因很现实：企业把业务资料、内部流程、系统权限甚至经营信息交给一个外部小团队，首先解决的不是技术能力问题，而是信任问题。
我们早期的客户主要来自几类：
- 过去服务过、了解交付能力的客户；
- 认识多年、但以前没有正式合作过的企业；
- 销售伙伴或其他 OPC 介绍的客户。
2023 年，我们给一家企业做知识库。这个客户是熟人，之前没有合作过，但彼此认识。他们的公司当时一直在增长，也愿意拿出预算试错，于是这个项目才真正成立。
这几个条件缺一不可：
- 客户信任你；
- 客户确实有问题；
- 企业经营状况允许它试错；
- 决策人愿意为这次试错花钱。
拓展新的中大型企业客户时，我更倾向于先找手里有客户资源的销售伙伴，和他们建立长期合作，再把自己能够交付的服务清单交给他们，由他们介绍合适的客户。
因为传统 To B 项目里，销售不只是帮你转发联系方式。
他知道这家公司谁说了算，老板真正关心什么，部门之间是什么关系，预算大概从哪里出。稍微大一点的项目如果跨部门，纯技术团队很难处理其中的人际和利益问题，必须依赖成熟的销售资源。
路径二：没有企业客户、案例和销售资源的新 OPC
如果你过去没有做过企业交付，也没有熟人客户，就不能把“依靠老客户和销售伙伴”当成自己的起点。
这时候更现实的方式，是先进入那些会发生真实需求的场合。
第一类是 OPC 社区和创业服务社区。今年很多一线城市的OPC社区非常热，有些社区会给有交付能力、但暂时没有业务来源的小团队提供一些项目。价格可能不高，项目也未必完美，但它能让你第一次接触真实客户、真实需求、沟通和验收，而不是一直在家里做 Demo。
**第二类是别人组织的线下活动。**可以参加 OPC、AI 应用、企业服务、传统行业数字化等主题的活动，也可以参加本地创业者、企业老板和行业从业者的小型交流。
参加活动的目的不是上来推销“我会做 Agent”，而是和不同领域的人聊清楚：
- 他们现在怎样工作；
- 哪个环节最重复、最慢、最容易出错；
- 过去尝试过哪些工具；
- 为什么没有解决；
- 谁会为这个问题负责。
很多企业不会公开发布一条“我需要 FDE”的采购需求。真正的线索，往往是在具体交流中慢慢聊出来的。
第三类是先参与别人的项目。如果暂时没有能力独立获得和承担一个完整企业客户，可以先与更有经验的 OPC 或交付团队合作，负责自己擅长的一部分。先把需求沟通、交付、测试和验收真正走一遍，再逐步形成自己的案例和服务清单。
对新团队来说，第一单最重要的价值不一定是利润最大化，而是获得一条完整、可复盘、以后敢拿出来证明能力的交付记录。
自媒体是放大器，不是唯一的起点
无论走哪条路径，内容和个人 IP 都有价值。它可以帮助陌生人理解你做过什么、怎样判断问题，也可以让在线下认识的人回到线上继续观察你。
但“有曝光”不等于“已经完成商业转化”。自媒体只是获客链路的一部分，不能代替后面的初筛、诊断、交付和信任积累。
所以获客不能只看粉丝。真正的线索至少要回答四件事：
- 他是谁，代表个人还是企业；
- 现在有什么正在发生的问题；
- 有没有明确的行动时间；
- 是否愿意为判断和下一步付费。
只有泛泛问“企业 Agent 怎么做”，却不愿提供背景、资料和目标的人，不应该立刻获得一份免费完整方案。
三、选客户，往往比选技术更重要
做企业 AI 服务，客户选错以后，后面的技术越强，损失可能越大。
我们会优先看一家企业是不是仍在增长。
这不是一句绝对规则，但它非常现实。
企业在增长，通常意味着它还有客户、有预算，也更愿意通过工具提高效率。员工知道业务在增长，对外部团队的抵触也会小很多。我们进场时不是站得高高在上，说要用 AI 干掉谁，而是半蹲下来问：
- 你现在工作里哪个环节最烦？
- 哪里重复最多？
- 哪里最容易出错？
我们站在辅助员工的位置上梳理流程，他们通常愿意配合。
相反，一家公司如果业绩持续下滑，它没有 AI 也可能裁员，有了 AI 以后，AI 只是一个更好听的理由。供应商还要面对预算缩减、项目中止和回款风险。
过去做企业项目时，我们也遇到过客户经营状况恶化、项目完成后仍然难以收回尾款的情况。到了这种阶段，合同和追款流程也未必能替一家已经失去支付能力的公司变出钱来。
所以现在再选客户，会优先考虑：
- 企业本身是否增长；
- 决策人是否真的想做；
- 有没有真实业务负责人；
- 是否能接触实际流程和资料；
- 是否有能够确认结果的人；
- 客户与销售伙伴是否可靠；
- 第一阶段能否缩到几周内验证。
还有一些项目，我们会直接拒绝。
例如客户的老 ERP 不提供 API，却要求新系统自动读写；企业内部没有人负责资料和验收；或者老板只说要“全公司 AI 化”，但没有人能说清第一批用户是谁。
小团队的资源有限，不能靠接下所有需求证明自己有能力。
知道什么不做，本身就是交付能力的一部分。
四、老板能说清预算，但说不清交付边界
真正进入商机以后，不要在会议室听老板讲一个小时，就回去写合同。
我们的做法是：复杂一点的项目，要到企业现场聊一周左右。
跟老板谈，通常能谈清楚两件事：他愿意拿多少预算，以及他想选谁来做。
真正要写进合同的交付边界，必须到办公室、工厂或研发场地里，跟老板指定的团队和实际干活的人逐一聊完，才能确定哪些能做、哪些不能做。
访谈时不要只问“你想要什么功能”。
要把真实流程还原出来：
- 谁在什么时间收到什么输入；
- 打开哪个系统；
- 根据什么信息做判断；
- 遇到例外找谁；
- 最后把结果写到哪里；
- 哪些步骤写在制度里，哪些步骤只存在于群聊、电话和个人表格里；
- 哪些规则大家都知道，却从来没有正式记录。
我们在 2023 年的知识库项目中，就碰到过一个很典型的问题。
系统上线测试后，AI 回答错了一个产品问题。
我们先查模型是不是胡说，再查知识库是不是召回错了，再查扫描件是不是解析错了。一路追下去，发现技术链路全部正确。
真正错的是很多年前打印出来的那张产品设计文档。
公司里的老员工都知道那一处印错了，所以平时会在脑子里自动改过来。但这个事实没有进入任何线上系统。AI 只会忠实读取那份错误资料，于是非常准确地给出了错误答案。
这个案例让我意识到：
AI 可以非常准确地处理一份错误知识。
企业里大量真正有价值的信息，不在数据库里，而在人的脑子里。文档版本、历史例外、口传规则、特殊客户处理方式，都可能在项目真正运行以后才暴露出来。
因此，需求调研的目标不是整理一份功能列表，而是确认：
- 原始知识能不能相信；
- 流程是否真的按照文档运行；
- 哪些判断可以交给 AI；
- 哪些必须保留给人；
- 第一阶段究竟只改变哪一步。
客户的愿望可以很大，但第一阶段必须足够小。
五、报价不是开发天数乘以一个单价
报价要分阶段。
如果双方还只是陌生人，线索也不明确，可以先用自己的时间成本做筛选。举个例子：假设你希望自己的年收入达到一百万元，就可以按照每月二十个工作日、每天八小时，反推一个小时的基础价格。
这个数字不是最终项目报价，它的作用是过滤。
如果对方连这个量级都不能接受，就没有必要继续投入大量时间帮他梳理需求。
到了商机阶段，报价就不能只算开发多少天。
还要看：
- 客户的预算和付费能力；
- 这个问题对客户值多少钱；
- 行业里的替代供应商有多少；
- 数据和系统接入有多复杂；
- 是否需要驻场；
- 准确率、权限和安全要求；
- 客户配合程度；
- 交付周期和失败责任；
- 销售、设计、测试、硬件等合作成本。
原则很直接：先有自己的底线，算清楚这件事需要干多少天、最低要收多少钱；再知己知彼，了解客户心理预期和竞争环境。
但这里不能被简单理解成“看客户有钱就随便涨价”。
不同客户看起来要的是同一个知识库，实际范围可能完全不同。一家企业只有几十份整理好的文档，另一家有十几年纸质资料、多个权限层级和旧系统接入，交付风险根本不是一回事。
价格最终要能够对应范围、价值和风险。
还有一个原则必须提前说清：
需求多，钱就得加。不是加量不加价。
如果合同已经签完才发现范围扩大，追加预算通常很难。因此报价之前，最重要的不是把价格谈高，而是尽量把边界谈清楚。
六、SOW 是小团队最重要的护身符
企业 AI 项目很容易做到一半，才发现真正的阻塞不在技术，而在甲方没有提供必要条件。
例如：
- 资料没有整理；
- 接口权限没有开放；
- 没有人确认哪份文件有效；
- 部门负责人不参加测试；
- 旧 ERP 根本没有 API；
- 客户临时增加了几个原来没谈过的流程。
客户很容易认为：既然你承诺交付这个结果，所有卡点就都应该由你免费解决。
所以项目前期必须有一份 SOW，也就是工作范围说明。大项目写进正式合同，小项目至少在邮件、文档或聊天记录中确认。
一份可用的 SOW 至少应该写清：
- 这次到底交付什么；
- 哪些内容明确不做；
- 甲方要提供哪些资料、账号、接口、环境和人员；
- 哪些前置条件不满足，项目就无法继续；
- 各阶段的时间节点；
- 双方怎样测试；
- 什么结果算验收；
- 需求增加后怎样变更；
- 哪些风险由谁承担；
- 培训、售后和维护做到哪里结束。
这件事可以用一句很朴素的话说清楚：
我要交付这些东西，我依赖那些东西，你得给我备好。你备不好，我确实交付不了。如果你想让我把合同范围之外的点也交付掉，那就单独算人天、单独算钱。
SOW 不是为了跟客户对抗。
它是为了让双方在项目开始前，对同一个结果有相同理解。
七、做企业 AI，不要为了证明技术先进而硬上 AI
小团队必须沉淀自己熟悉的技术栈。
客户要求数据不能离开公司，就讨论私有化；允许用云模型，就比较云端方案。客户没有明确技术偏好时，我们会优先选择自己熟悉、出了问题能够修的工具。
我们过去用自己熟悉的知识库工具做过交付，也处理过其中的实际问题，所以碰到故障时知道从哪里下手。Agent、工作流、推理框架也一样，每做一单临时追一个新工具，项目风险会非常高。
但熟悉技术，不代表所有问题都必须用技术解决。
早期做知识库时，客户的 PDF 里有产品图片、三维图、尺寸标注和不规则表格。当时多模态识别能力有限，自动解析成本很高，最后采用的是人工录入。
听起来不够“AI”，但它能把项目按要求交出来。
同样，客户的老 ERP 如果不提供 API，我们的选择不是展示一套更复杂的绕过方案，而是不碰这部分业务。
模型选型也不是看参数表。先准备一套固定题目，用真实数据测试；这个模型达不到准确率，就换另一个。换完仍然达不到，就明确告诉客户现在做不了。
企业买的是可靠结果，不是要FDE来证明所有环节都能自动化。
八、AI Coding 可以加速开发，但不能取消工程
我见过一位企业负责人亲自做过一次很激进的实验。
这位负责人接触了 AI 工具，配置好工作环境以后，开始自己写一套原本需要研发团队长期协作的系统。
刚开始非常兴奋，进度看起来也很快。
随着模块越来越多，问题开始出现：改一个 Bug，可能带出新的 Bug；系统为什么这样设计，谁也说不清；项目里没有人对每个模块有完整认知。
最后，这套工作又慢慢回到了原来的研发流程：梳理需求、拆模块、写测试用例、由研发团队继续维护。
这不是说 AI Coding 没有价值。
恰恰相反，它非常适合帮助业务人员把脑子里的流程做成 Demo。
我接触过一个电商团队，运营人员先把自己的工作流程“喷”给 Codex 或 Claude Code，AI 做出一个可以演示的版本。这个 Demo 交到开发者手里以后，开发者马上就能看懂对方想要什么、运营流程怎么走，沟通成本大幅下降。
AI 可以减少试错和表达成本，也可能让企业少招一个原计划招聘的程序员。
但一个长期运行的大系统，仍然需要工程结构、模块认知、测试和维护责任。
AI Coding 可以加速工程，不能取消工程。
九、测试集必须在交付前就设计
AI 项目不能用“我试了几次，感觉还不错”验收。
客户最后要验收，所以我们会做测试集。
基本方法和传统软件测试类似：根据每一个需求点，设计正向测试、反向测试和边界测试。乙方的自测集会给客户确认，看是否遗漏了真实业务中的情况。
我们自己测试达标以后，再交给客户。客户通常还会保留一套不公开的验收集，只告诉我们最终达标还是不达标、还差多少。
知识库场景里，可以把大约 85% 的问题设计成有确定答案的题目。
例如：某个产品通过了哪些认证，某个接口的电流是多少。这些都有标准答案，可以明确判断对错。
剩下没有标准答案的问题，需要由业务人员评价。
图片生成也一样。信息流广告图生命周期短，容错可以高一些；商品详情页图片会长期公开，手指、串模、产品结构等细节要求更高，必须由人判断。
一份企业 AI 测试集至少要覆盖：
- 正常输入能不能得到正确结果；
- 错误输入会不会被拒绝；
- 资料不足时会不会胡编；
- 文档版本冲突时怎样处理；
- 无权限用户能不能看到不该看的内容；
- 工具调用失败时是否重复写入；
- 模型达不到标准时是否转人工；
- 更换模型、提示词或知识版本后是否重新测试。
技术团队负责把系统做出来，业务专家负责定义什么叫真正答对。
十、需求变更时，预算、周期和范围至少要动
真实项目一定会发生变化。
POC 没有验证到的问题，可能在正式开发时暴露；原来低估的环节可能需要更长时间；某个需求甚至可能发现当前做不了。
大项目应该走正式需求变更流程。小项目可以直接和客户负责人沟通，但不能假装变化不存在。
更现实的处理方式是：
如果客户不愿意加钱，至少要增加时间。不能预算不加、周期不变、范围还继续扩大，因为那确实交付不出来。
需要注意的是，合同签完以后再追加预算，大部分客户不会同意。所以越是小团队，越应该在前期把 POC、依赖和边界做扎实。
可以把变更归为三类：
- 客户新增了原合同没有的需求：增加预算或删减原范围；
- 乙方低估了原需求难度：说明原因，重新协商周期和方案；
- 前置条件不成立：由甲方补条件，或者暂停对应范围。
不要用沉默和加班掩盖范围变化。
项目拖到最后，双方对“当初答应过什么”的记忆往往完全不同。
十一、验收、证据和回款，要从第一天开始准备
很多人等项目做完才考虑验收和回款，已经晚了。
从项目开始，合同、盖章文件、微信沟通、邮件、阶段确认、测试记录和交付痕迹都应该保留。
这些记录不是为了随时起诉客户，而是为了在发生争议时，能够回答：
- 双方当初确认了什么；
- 甲方是否提供了前置条件；
- 哪些内容已经交付；
- 哪些变更得到过确认；
- 验收标准是否已经达到。
我们现在做的小团队项目，因为客户主要来自熟人、老客户或销售伙伴介绍，还没有遇到做完后拒绝验收、验收后不给钱的情况。
但过去的大客户经历已经说明：信任很重要，证据也不能少。
真正降低坏账风险的第一步，不是研究怎样追债，而是在项目前期选择经营健康、仍在增长、关系可靠的客户。
十二、做完一单，下一单不能再从空白开始
小团队如果每一单都从空白文档、空白代码和空白判断开始，很快会被交付拖死。
每个项目结束以后，至少应该沉淀：
- 客户初筛问题；
- 现场访谈清单；
- 流程还原模板；
- 报价成本项；
- SOW 模板；
- 常见前置依赖；
- 正向、反向和边界测试结构；
- 上线与交接清单；
- 需求变更记录；
- 可以匿名公开的真实案例。
知识库项目里发现错误纸档，后面可能形成一项数据治理需求；运营人员用 Codex 做 Demo，可以沉淀成业务人员表达需求的新方法；一次 ERP 接入失败，可以变成下一次商机初筛时必须问的问题。
交付中遇到的问题，边界清楚以后可能成为第二个项目。
项目里形成的方法，也会成为下一次交付的底座。
完整的商业闭环因此不是“发内容—有人私信—成交”这么简单，而是：
真实项目 → 形成判断 → 沉淀方法与模板 → 对外分享 → 获得新线索 → 初筛和诊断 → 新项目交付 → 产生新案例。
截至目前，我们仍在验证内容到付费咨询的这条新增链路，不能把它写成已经稳定跑通的结果。
但线下客户、销售伙伴和真实交付提供了一手素材；内容的作用，是把过去只存在于熟人圈里的经验，变成陌生客户也能看懂的信任证据。
最后：小团队真正需要的，不是一套万能 Agent
现在再回答“小团队怎样从 0 到 1 做企业 AI 服务”，答案已经比较清楚了。
你要找到有真实问题、也有支付能力的客户；进入现场，跟实际干活的人把流程问清楚；把老板的愿望收窄成第一阶段可以验收的结果；在 SOW 里写清范围、甲方责任和变更方式；选择自己真正能维护的技术；用测试集而不是演示效果证明交付；最后留下证据、完成验收，并把这一单的判断沉淀下来。
小团队不需要假装全能。
需要专业销售时，就找销售伙伴；需要其他技术角色时，就找做过交付、彼此信任的 OPC；老系统没有 API 时，不要硬碰；模型达不到准确率时，换模型，或者诚实地说现在做不了；自动解析成本太高时，用人工把项目交出来。
企业最终要的不是一个听起来先进的方案。
企业要的是：这个东西能不能用，错了谁接，做到哪里算完成，以及交付团队走了以后，他们自己能不能继续运行。
技术决定你能不能把东西做出来。
客户判断、范围管理、测试验收和商业关系，决定你能不能收回钱，获得下一次信任。
这才是小团队做企业 AI 服务真正的从 0 到 1。
附：企业 AI 服务完整 SOP框架
1. 线索初筛
客户是谁，所在行业和当前角色是什么？
现在最想解决的具体问题是什么？
当前怎样处理，每周消耗多少时间、成本或机会？
已经尝试过哪些工具、供应商或内部方案？
谁负责推动，谁负责验收？
希望什么时间看到什么结果？
是否有明确预算？
2. 客户判断
企业是否仍在增长？
问题是否正在产生真实代价？
是否能接触真实使用者、流程和资料？
是否有内部负责人？
第一阶段能否在几周内验证？
决策、付款和合作关系是否可靠？
3. 现场调研
还原当前真实流程，而不是只看制度；
访谈老板、负责人和实际使用者；
核对资料版本、数据位置和系统权限；
找出口传规则、个人表格和历史例外；
标记事实、判断、假设和待确认项；
确认哪些事能做、哪些不能做。
4. 方案与报价
把大愿望缩成一个最小业务结果；
估算调研、开发、测试、部署、培训和合作成本；
确认准确率、权限、并发和运维要求；
写清最低成本、客户价值和项目风险；
预算明显不匹配时，不继续免费深挖。
5. SOW
目标与使用者；
交付范围；
明确不做的内容；
甲方前置依赖；
技术假设与验证项；
阶段节点；
测试和验收标准；
需求变更流程；
付款节点；
售后与支持边界。
6. 开发与交付
优先使用团队熟悉、能够维护的技术；
POC 先验证最大风险；
不强行接入没有接口的旧系统；
自动化成本高于人工时，评估人工方案；
每个阶段保留确认记录和交付证据；
范围变化立即沟通，不靠加班隐藏。
7. 测试与验收
每个需求点设计正向、反向和边界用例；
自测集交客户确认是否遗漏；
客户保留独立验收集；
确定性问题自动判断，开放问题由人评估；
测试资料不足、权限、拒答和人工接管；
更换模型、提示词或知识版本后重新测试。
8. 交接与复盘
完成交付、培训、账号和资料交接；
让客户知道什么时候信 AI、什么时候找人；
保存合同、沟通、测试和验收记录；
复盘范围偏差、技术风险和客户配合；
沉淀模板、测试结构和可复用组件；
经客户允许后，将项目匿名整理成案例。
接下来，我还会继续分享更多企业 AI 落地服务中的真实案例：客户最初怎样提出需求，项目进场后发现了什么问题，哪些方案最后被放弃，以及报价、交付、测试和验收中真正容易踩的坑。
这些内容不会只讲 AI 概念，也不会只展示一个能跑的 Demo，而是尽量把企业 AI 从想法走到真实业务的过程讲清楚。
