一个百万级的FDE项目，到底在交付什么？

前段时间，我们在深圳办了一场 FDE 沙龙，在现场介绍了这个百万级的 FDE 项目交付路径，现在把当时分享的内容整理成文章，算是抛砖引玉。

这篇文章，我就把这笔订单拆开讲：客户到底买了什么，我们具体做了什么，为什么会是一笔百万级订单。

不过在讲订单之前，有两件事必须先说清楚。这个项目能交下来，靠的就是这两件事。

第一，FDE 项目要分阶段落地。第二，每个阶段开始之前，都要把交付边界定清楚，可以参考下面这张图。

FDE 说白了，就是人带着技术进入业务现场，把一个具体问题做成能用、能验收、也有人接手的工具。这个工具可能是一套集团办公系统，也可能只是一个脚本。该做多大，取决于问题本身和双方约定的边界，不取决于“AI”两个字听起来有多大。

我们做这个项目时，也是先确认这一阶段解决什么问题、做到什么程度、哪些事情暂时不做，再进入开发。否则，试点还没验证，功能已经越加越多；等到验收时，双方说的“做完了”可能根本不是一回事。

下面先讲阶段和边界，再回到这笔订单本身。

一、分阶段落地，每一步都要留下能检查的结果

我通常把这类工作分成四个阶段。

第一阶段，诊断问题，圈定范围。拿一项真实工作，看谁在做、卡在哪里、现在怎么判断对错。文件找不到，是没有资料、版本混乱，还是入口太散？先弄清原因，留下范围说明和可用样例，再判断需要 AI，还是一个脚本就够了。

第二阶段，小范围试点，验证是否有用。先覆盖一类任务、一组资料或一小批使用者，用真实材料做出可检查的结果。正常输入要试，材料缺失、问法不清也要试。试点结束要能说明：解决了哪段麻烦，还会在哪些情况下失败，是否值得继续投入。

第三阶段，工程化，把试点接进日常工作。效果验证之后，再处理企业账号、资料读取、运行环境、用量管理和失败恢复。目标是让工具在约定条件下持续运行。开发电脑上成功一次，还不足以通过这一阶段。

第四阶段，验收交接，让使用者接得住。从实际入口提交材料，检查最终成品，把安装、更新、故障处理和维护责任交清楚。接手的人知道怎么用，出错知道找谁，项目才有条件持续运行。

每一阶段都要有进入下一步的依据。试点没证明有用，就不急着扩部门；企业账号没开通，就不能把真实联调算作完成。阶段要按结果推进，不靠排满日历来证明进度。

推进中也可以回到前面的阶段。进入企业环境才发现文件读不到，就先处理数据和授权；实际使用者指出规则不适合，就重新确认、修改后再测。分阶段是为了尽早发现问题，不是把项目切成四段以后，前面的事就再也不能调整。

二、最重要的，是把交付边界写到能核对

“做一个办公助手”还不能直接拿来开发。它没有说清覆盖哪些任务，输出到什么程度，谁来判断结果可用。

交付边界至少要回答下面这些问题。

比如做会议纪要，约定的是根据材料生成初稿，就不能顺手承诺自动替人决定负责人、自动审批或发送正式通知。使用入口和模板交付了，也不等于所有部门都已经接入。

读取和写回也要分开约定。允许查一张表，不等于允许修改里面的数据；允许生成公文，不等于允许以公司名义发出去。技术上可以把动作连起来，业务上却涉及不同权限和责任。

边界要同时写清做到什么、不包含什么，以及满足哪些前提才能做。企业资料没准备好、账号没开通，工程侧就要说明缺什么、会影响哪一步，不能把尚未具备的条件当成已经就绪。

同一项会议整理，试点可以先交一份人工核对过的样稿；进入日常使用后，还要交代材料缺失怎么办、失败在哪里查、模板由谁更新。把这些写进各阶段的交付说明，双方才知道眼下验什么，下一步还差什么。

需求可以变。增加一个入口、改成企业环境部署、要求源码交付，都应重新评估工作、验收条件、周期和费用，再确认新的范围。先把变化讲清楚，后面的合作才有共同依据。

三、回到这笔百万级订单：企业到底要解决什么

我们做的这个集团办公项目，解决的是几类反复发生的工作：找内部资料、整理会议纪要、写公文和 PPT、设置提醒。

拿会议纪要举例，员工提交材料和整理要求，系统给出初稿，人再核对决定、待办和待确认事项。“可以考虑”不能被改成“已经决定”，没说清的负责人不能凭空填上。公文和 PPT 则结合企业材料与模板，减少从空白页开始组织内容的工作。

我们带着在线系统去现场，让企业当场出题。这能验证功能，但集团采购还要考虑资料怎样处理、费用怎样管理、系统出错后怎么查，以及以后怎样维护。

最早的方案是小范围云端订阅，首年报价数十万级。后来扩大到按集团规模设计，增加协作入口，软件要部署进约定的企业环境，还要交付全部源码，软件部分进入百万级，维护和 AI 运行费用另列。

这里变化的是交付范围和购买方式。按千人规模设计，也不等于已经有千人实际使用。企业拿到源码，是拿到软件的制作底稿，还需要对应版本、安装配置和维护说明，才能具备继续接手的条件。

用前面的边界来看，这些变化都需要重新确认。把原来的云端助手直接叫作“集团系统”，并不能替代新增的接入、部署、测试和交接工作。

四、范围扩大以后，技术上要增加什么、保留什么

这个项目做了模型网关，把 AI 调用集中管理：过滤敏感内容、检查部门额度、调用允许使用的模型，再记录费用和处理过程。企业调整模型范围和用量时，有统一的位置可以处理。

但网关主要管理调用。文件和消息加密保存、访问入口限制、操作记录留存，仍要分别处理。应用部署进企业环境，也不等于所有模型都在本地离线运行，资料经过哪里要逐项确认。

企业微信和飞书的真实联调，还依赖企业开通账号。代码写好与接入条件就绪，是两件事，账号和外部通道的开通周期必须提前考虑。

有些部分则刻意保持简单。资料检索按规模选了轻量的 BM25，没有上向量数据库：先根据问题中的词找相关材料，再交给模型组织回答。能否找回需要的资料，要用真实问题检查；查不到，先分清正文没读到、用词不匹配，还是检索方式不合适。

另一个物料表录入场景：审核好的 Excel 清单，仍要人工重复录进管理系统。字段和规则确认后，程序检查编号、数量和换算关系，再通过企业允许且系统支持的方式写入，就可能解决问题。

这个场景曾遇到的问题是：员工能打开文件，程序读到的却是密文。需要核对授权应用、运行身份和位置，走允许的读取路径。两台机器同时跑与中断后重试，也要分别处理，限制同时运行的锁不能代替重复提交检查。

这类经验用到办公系统里，就是把职责分清：模型理解材料、组织初稿，程序按固定规则检查计算结果、字段和任务状态。AI 可以帮我们更快地制作工具，工具运行时却不一定需要调用 AI。一个小程序或脚本能解决的痛点，就按那个范围交付。

五、验收边界要跟到最终文件

投标前，我们做过真实 AI 调用的并发测试：30 路流式请求同时运行，这一轮全部成功，首字响应 p95 约 7 秒。粗略理解，是这轮测试里约 95% 的请求在约 7 秒或更短时间内开始回复。

这个结果证明的是所测条件下的调用和开始回复情况。它不能证明千人容量，也不能把“开始出字”当成“整份文件完成”。后面可能中断，文件也可能尚未生成好。

项目对失败的处理是：还没开始输出就失败，可以切换备用模型；彻底失败时保存草稿。这不意味着任务做到一半，还能随便换个模型原地接着跑。

所以验收要沿着同一份材料走到底：资料是否真的读到，回答有没有依据，文件打开后数字、文字和格式是否正确。文件名登记进系统，不代表正文已经可检索；扫描件或加密文件的问题，也不是换模型就能补回来。

另一个自动出图案例里，内部测量值正确，最终显示的尺寸文字却错了。原来的检查只看内部数值，结果仍然通过。这个教训提醒我们：验收必须打开用户真正拿到的成品。

调用成功、文件生成成功、业务结果可用，要分开验证。每一阶段都明确验收到哪里，才知道后面还剩什么工作。

六、百万级的价值，最后要算两笔账

第一笔是交付账。小范围云端服务与集团部署、源码交付，承诺的工作不同。报价要列清软件、接入、部署和交接范围，再把维护与 AI 运行费用放进同一个使用周期里比较。首年订阅和软件买断不能直接当成同一件商品涨价。

第二笔是业务账。工程工作多，可以解释报价怎样形成；值不值得买，还要看企业实际少做了多少重复工作。

举个粒子：200 人稳定使用，扣掉人工核对后，每人每天净省 15 分钟，一天就是 50 小时；按 220 个工作日，是一年 11000 小时。假设每小时综合成本 100 元，名义上对应 110 万元工时价值。

这不是本项目的实测收益，也不是省下同等现金。员工是否真的使用，省下的时间有没有用于更多交付，是否减少了返工、加班或外包，都要继续核对。

交付收尾还要留下应用、对应源码、安装配置、测试记录、升级恢复及维护说明。模板改了能更新，任务失败能查，换了维护人员也能接着用，企业才有条件持续获得价值。

从一个脚本到集团系统，分阶段是为了先验证再投入，定边界是为了让双方知道这一期交到哪里。需求扩大，就重新评估；小工具已经够用，就把它交稳。

FDE 的专业判断，也体现在这些选择和责任里。

---

我是 Miles，做 AI 算法研发、企业 AI 培训和 FDE 落地交付。关注我 @miles_mazy，继续交流企业 AI 的实际做法。