很多人第一次接触企业 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 CodeAI 做出一个可以演示的版本。这个 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 从想法走到真实业务的过程讲清楚。如果你也在关注企业 AI、FDE 或小团队交付欢迎关注我。主页会持续更新企业 AI 落地的真实案例、实战判断和交付方法。 
长河君 · 2026/8/30 3:57:50 · 阅读 1.2k 万字长文｜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 CodeAI 做出一个可以演示的版本。这个 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 从想法走到真实业务的过程讲清楚。如果你也在关注企业 AI、FDE 或小团队交付欢迎关注我。主页会持续更新企业 AI 落地的真实案例、实战判断和交付方法。