前段时间，我们在深圳办了一场 FDE 沙龙，在现场介绍了这个百万级 FDE 项目的交付路径。现将当时分享的内容沉淀成文章，把这笔企业订单完整拆开讲：客户到底买了什么，我们具体做了什么，为什么会是一笔百万级的订单。
不过在拆解订单之前，有两件事必须先说清楚。这个项目能顺利交下来，靠的就是这两条基石：
- FDE 项目必须严格分阶段落地；
- 每个阶段开始之前，都要把交付边界写到能逐项核对。
FDE（Forward Deployed Engineer，前沿部署工程师）说白了，就是人带着技术进入业务现场，把一个具体问题做成能用、能验收、也有人接手的生产工具。这个工具可能是一套复杂的集团级办公系统，也可能只是一个二十行代码的脚本。
该做多大，取决于业务问题本身和双方约定的边界，不取决于“AI”两个字听起来有多大。
我们做这个项目时，也是先明确：这一阶段解决什么问题、做到什么程度、哪些事情暂时坚决不做，再进入开发。否则，试点还没验证，功能已经越加越多；等到验收时，双方说的“做完了”可能根本不是一回事。
一、 分阶段落地：每一步都要留下能检查的结果
我通常把企业级 FDE 工作切分成四个递进的阶段：
第一阶段：诊断问题，圈定范围
拿一项真实发生的日常业务，看谁在做、卡在哪里、当前靠什么规则判断对错。
- 文件找不到，是因为根本没有资料、版本混乱，还是访问入口太分散？
- 先弄清深层原因，留下明确的范围说明书与真实可用样例，再判断到底需要上大模型，还是一个简单的 Python 脚本就足够解决。
第二阶段：小范围试点，验证是否有用
先覆盖一类任务、一组资料或一小批核心使用者，用真实业务材料做出可供核对的直接结果。
- 正常输入要测试，材料缺失、提问模糊等极端边界也要测试。
- 试点结束必须给出量化说明：到底解决了哪段麻烦、在哪些情况下会失败、是否值得企业继续追加投入。
第三阶段：工程化，把试点接进日常工作
在算法与交互效果验证成立后，再处理企业账号对接、内部资料打通、生产运行环境部署、Token 用量限额与故障自动恢复。
- 目标是让工具在约定条件下能够长期稳定运行。
- 在开发者的本地电脑上成功跑通一次，绝不代表通过了这一阶段。
第四阶段：验收交接，让业务接得住
从生产环境的真实入口提交材料，由一线员工直接检验最终成品；把安装配置、版本更新、故障排查指引和长期维护责任交接得清清楚楚。
- 接手的人知道日常怎么用，出错知道找谁，项目才具备持续运转的生命力。
[!IMPORTANT] 推进原则：每一阶段都必须有明确的“准入依据”。试点没证明对业务有用，就坚决不急着向全集团推广；企业内部账号没开通，就不能在汇报里把联调当成已完成。阶段要按真实交付物推进，不靠排满日历表来证明工作进度。
推进中也可以随时回退到前序阶段。进入企业内网才发现数据格式读不到，就先退回第一阶段处理数据治理与授权；实际使用者试用后指出业务规则不切实际，就重新确认、修改逻辑后再跑测试。分阶段是为了尽早暴露问题，而不是把项目切成四段以后闭目塞听。
二、 最重要的，是把交付边界写到能核对
“做一个企业办公助手”这种需求，是绝对不能直接拿来排期开发的。它既没有说清覆盖哪些任务，也没讲输出要达到什么成色，更没规定由谁来拍板验收。
交付边界至少要提前回答清楚以下核心问题：
- 功能动作边界：例如约定做“会议纪要助手”，合同中写明的是“根据上传材料生成初稿”，工程侧就绝对不能顺手口头承诺“自动替领导决定责任人、自动提交 OA 审批或自动群发正式通知”。入口交付了，绝不等于所有部门都已经自动完成业务接入。
- 读写权限边界：允许读取一张表，绝不等于允许程序修改里面的数据；允许模型生成公文草稿，绝不等于允许以公司官方名义直接发出去。技术上把几个 API 串联起来很容易，业务上却背负着完全不同的权责划分。
- 前置条件边界：边界必须同时写清做到什么、不包含什么，以及满足哪些前提才能做。企业内部知识库没准备好、对接账号没开通，工程侧就要白纸黑字说明缺什么物料、会影响哪一段排期，严禁把尚未就绪的外部条件默认当成已经就绪。
同样一项会议纪要整理，试点阶段可以先交付一份经过人工修正核对的样例；进入日常生产使用后，还要交代材料缺失怎么办、执行失败在哪里查日志、提取模板由谁维护更新。把这些细则写入交付说明书，双方才知道眼下验收什么，下一步还欠缺什么。
[!NOTE] 需求可以变更，但必须重新评估：中途增加一个协同入口、从云端改成私有化环境部署、临时要求交付全部源码，都应当重新核算工作量、验收条件、交付周期与项目费用，再白纸黑字确认新范围。把变化讲在台面上，合作才有互信的依据。
三、 回到这笔百万级订单：企业到底要解决什么
我们交付的这个集团级办公项目，解决的是企业内部几类高频发生的重复性劳动：
- 检索内部海量政策与业务资料；
- 录音转写与会议纪要提炼；
- 公文、通知与汇报 PPT 初稿起草；
- 关键任务与待办事项的自动提醒。
拿会议纪要举例：员工上传会议录音或原始速记，系统提取结构化初稿，最后由人工逐项核对决定事项、待办清单与待确认事项。
- 业务红线极其严苛：“可以考虑”绝对不能被大模型自行脑补总结成“已经决定”；
- 没说清的责任人绝对不能凭空胡乱填上；
- 公文与 PPT 则结合企业预置模版与历史参考素材，减少一线员工面对空白页冷启动的组织成本。
我们最初带着在线系统去现场，让客户当场出题，现场跑真实材料。这套演示足以验证产品功能，但要推动集团级规模化采购，企业决策层更关心的绝不是几个算法指标，而是：
- 资料流转经过哪里、是否出境、如何加密？
- 各个子公司的调用配额与账单费用如何集中管理？
- 系统调用出错后如何审计定责？
- 未来项目交付后，内部 IT 团队该怎样持续维护？
项目的商务路径由此发生了根本性转变：
- 初始方案：小范围部门试点、公有云端 SaaS 订阅，首年报价在数十万元级别；
- 终局方案：扩大到满足集团千人级并发协同、新增飞书与企微双入口、整套软件部署进客户约定的专有云环境，并交付全部源码与运维底稿。软件工程部分顺理成章迈入百万级，后续维护费与模型推理 Token 费用单独列支。
这里变化的是交付范围与企业购买方式。按千人容量设计，不等于瞬间就会有千人上线并发；企业购买源码，买到的是软件的制作底图，还需要配套的编译环境、部署配置手册和排障知识库，才能真正具备接盘维护的能力。
把一个云端 AI 助手直接改称“集团级管理系统”，替代不了实际新增的繁杂网络对接、内网部署、全链路压测与技术交接工作。
四、 范围扩大以后：技术上要增加什么、保留什么
当项目从原型试点演进为集团核心系统时，架构层面的“加法”与“减法”显得尤为关键。
技术上的“加法”：统一模型网关与安全底座
- 模型路由网关：项目设计并上线了统一模型网关，将所有上层业务的 AI 调用集中管控：
- 过滤敏感词汇与合规拦截；
- 核查各部门配额余量与并发控制；
- 按任务类型（通用推理、长文本总结、代码分析）动态调度被许可的模型；
- 完整记录每一次调用的入参、Token 计费与审计追踪。
- 多层安全防线：网关只管模型调用，文件的持久化加密存储、内网访问 IP 白名单、员工操作日志脱敏，依然需要在存储层和应用层单独做硬隔离。
- 企业通讯软件联调周期：企微和飞书的真实联调，高度依赖客户内网管理员开设正式应用号与配置回调域名。“代码写好了”与“接入联调条件就绪”是两码事，账号审批周期必须提前打入项目缓冲。
技术上的“减法”：克制架构，能用规则就绝不上大模型
在技术选型上，我们刻意保持了极强的克制：
- 放弃重型向量库，回归轻量 BM25：在企业内部资料检索场景中，按照当前知识库的规模，我们优先选用了极度成熟轻量的 BM25 关键词检索，没有盲目引入重型向量数据库。先根据问题关键词拉出最相关的段落，再交给大模型组织提炼答案。
- 能否查到资料，全靠真实业务问题抽样检验；
- 查不到时，先排查是原文未被索引、用词不匹配，还是检索分块不合理，而不是把问题简单甩给“向量表征不准”。
- Excel 物料清单核算：程序计算 + 模型理解：审核完成的 Excel 物料清单，原先需要人工一条条录入 ERP 系统。
- 方案设计为：大模型只负责理解材料、提取复杂文本语义，生成规范初稿；
- 规格编号校验、数量运算、税率换算等确定性逻辑，一律由 Python 脚本按刚性规则硬校验。
- 曾遇到的生产真实问题：一线员工可以在个人桌面打开文件，后台服务读取时却全是乱码密文。排查后发现触发了企业内网的透明文档加密机制，必须申请专用的解密调用服务与授权运行身份。此外，并发运行锁与幂等性校验必不可少，防止断点重试时产生重复单据。
[!TIP] 核心工程理念：AI 可以帮我们更快地制作生产工具，但生产工具在运行时并不一定需要时时刻刻调用 AI。一个小脚本或几行固定正则能兜底的痛点，就按那个范围踏踏实实交付。
五、 验收边界要跟到最终文件
在最终招投标与项目验收阶段，技术团队极易犯的一个错误就是：把“API 调用成功”或“首字吐字快”误当成了“业务可用”。
在投标前，我们做过真实 AI 模型调用的高并发压测：30 路流式请求同时并发，这一轮测试全量成功，首字响应时间（TTFT）P95 约为 7 秒。粗略理解，就是在该轮测试中，约 95% 的请求在 7 秒或更短时间内开始吐字。
这个结果仅仅证明了：在当前受限测试条件下，模型网关连通性良好且开始回复。它根本无法证明系统具备承载千人日常办公的吞吐容量，更不能把“模型开始吐字”等同于“整份业务公文生成完成”——后续可能遭遇流式网络中断，也可能生成到一半触发内容安全拦截。
项目对于故障的容灾策略是：
- 尚未吐字时遭遇模型超时，可无缝平漂切换备用模型；
- 输出中途彻底崩溃时，必须立即自动保存当前生成的草稿，提示人工介入。
- 这绝不意味着任务执行到一半，还能在内存状态丢失的情况下随便换个模型原地续写。
因此，验收测试必须沿着同一份真实业务材料走到底：
- 资料是否真的被检索算法读到了？
- 生成的公文结论是否有权威政策依据？
- 导出的 Word、PDF 或 PPT 文件打开后，排版样式、表格数字、缩进层级是否完全正确？
[!WARNING] 真实翻车案例：在另一个自动生成工程图纸的案例中，程序内部计算出的各项几何测量值全部正确，然而最终渲染导出在图纸上的标注文字却发生了位移错位。原先的自动化单元测试仅校验内部内存数值，测试全部飘绿通过，但交付给用户的成品图纸根本不能用！ 教训：验收必须强制打开用户真正拿到手里的那个最终文件。调用成功、文件生成成功、业务结果可用，必须作为三项独立的标准分开验证。
六、 百万级的价值，最后要算两笔账
企业肯为一项 FDE 服务买单，到最后一定会折算成两笔明明白白的账：
第一笔：交付账（Cost to Deliver）
小范围云端试用与集团级私有化部署、全量源码交付，承诺交付的工程工作量有云泥之别。
在商务报价中，必须将软件开发费、内网网络打通费、企业微信/飞书接入费、现场部署联调费以及最终交付交接费分项列清。随后将后续长期的维保服务费与日常模型推理 Token 成本，放在同一使用周期内对比评估。
SaaS 订阅与软件源码买断属于完全不同的商业购买模型，不能简单地视作同一种商品借故涨价。
第二笔：业务账（Business Value & ROI）
工程工作量庞大，只能解释供应商的报价是如何构成的；但企业客户到底愿不愿意签单买单，关键要看企业在日常运转中到底能实打实少做多少低效重复工作。
我们来推演一笔清晰的工时成本账：
- 假设集团内有 200 名员工稳定使用该系统；
- 扣除人工必须二次核对校验的时间后，每人每天净节省 15 分钟；
- 200 人每天净节省工时即为 50 小时；
- 按全年 220 个标准工作日计算，一年累计可为企业省下 11,000 个工时；
- 假设大企业综合人均工时成本按 100 元/小时（含社保、办公场地及管理公摊）保守折算，名义上对应的是 110 万元/年的人力工时价值。
[!NOTE] 这不是该项目的实测回款收益，也不等于企业账面上能立刻省出 110 万元现金。员工是否真正高频使用、省下来的工时是否被投入到了更高密度的业务交付中、系统是否真正减少了外包采购与无效加班，都需要在后续的季度运营中继续跟踪核验。
交付收尾与项目总结
在交付终局阶段，FDE 工程师必须在客户现场沉淀一整套接盘物料：
- 部署好的应用程序及完全对齐的 Git 源码底稿；
- 详尽的安装部署与环境配置文件；
- 真实业务场景的全套测试用例与验证记录；
- 容灾备份、版本升级与故障快速恢复手册；
- 针对一线运维人员的操作维护与模板更新指引。
只有当公文模版改了内部运维能自主更新、调用失败知道去哪翻查日志、即使原厂工程师撤场后客户的 IT 人员也能平稳接手时，企业才有长效获得商业价值的前提。
从一个轻量脚本到集团级系统：分阶段是为了先低成本验证再重兵投入；定边界是为了让双方清清楚楚地知道这一期交到哪里。需求扩大了，就心平气和地重新评估排期；一个小工具已经能够彻底解决痛点，就踏踏实实把它交稳交透。
FDE 的真正专业价值，不仅体现在写了多少行代码，更体现在这些克制的取舍、清晰的边界与可靠的工程担当之中。
我是 Miles，长期从事 AI 算法研发、企业 AI 培训以及 FDE 落地交付。欢迎关注我的 X：@miles_mazy，持续交流企业 AI 真实落地的技术与实操思考。
