百万级 FDE 项目交付什么：从范围约定、企业部署到验收交接

企业购买一套 AI 办公系统时，最终需要的不只是模型能回答问题，还包括真实资料能否读取、员工从哪里使用、权限与费用怎样管理、生成的文件是否合格，以及系统交付后由谁继续维护。

Miles Ma（@miles_mazy）在 2026 年 10 月 19 日的帖子中，发布了长文《一个百万级的 FDE 项目，到底在交付什么？》。他以一次集团办公项目为例，说明需求从小范围云端服务扩大到企业部署、源码交接之后，工程内容与验收责任如何随之改变。

本文依据可读取的完整 X Article 正文及配图重新组织。项目金额、配置、测试表现和交付经历均为作者自述，未取得合同、验收文件或独立测试记录；文中的工时价值计算是作者的假设示例。后文补充的检查表与实施建议为编辑整理，不代表该项目已逐项采用。

先把 FDE 落到一项具体工作

在这篇文章的语境里，FDE 的工作是进入实际业务环境，把具体痛点做成可使用、可核验、可接手的工具。项目大小取决于任务和约定范围：有时需要一套系统，有时一段程序就能减少重复劳动。

判断是否需要 AI，可以从三个问题开始：现在是谁完成这项工作？最耗时或最易出错的环节是什么？什么结果才算正确？如果问题来自固定字段搬运或重复计算，确定性的程序可能已经足够；如果涉及非结构化材料理解、内容组织与语言表达，再引入模型能力。

以会议整理为例，工具可以帮助形成纪要草稿，但材料中的建议、讨论和正式决定必须区分。没有明确的负责人不能靠模型补齐，待确认事项也不能被改写为已确认结论。交付目标应当是减少整理工作，并保留人工核对的位置。

四个阶段，每一步都有继续投入的依据

原文把项目推进概括为诊断、试点、工程化和验收交接。可以将每一阶段理解为一组需要交付的证据，而不是仅按日期排列的任务。

阶段	主要工作	应留下什么	进入下一阶段前确认什么
诊断	观察真实流程，核对资料、角色和判断标准	范围说明、输入样例、当前问题与基准	问题是否明确，资料和授权是否具备
试点	用少量用户、有限任务和真实样本验证	可检查的结果、错误案例、适用范围	是否确实减少麻烦，主要失败是否可接受
工程化	接入账号、数据、环境、用量与恢复机制	可部署版本、配置、日志与运行说明	能否在约定环境持续使用
验收交接	从实际入口检查最终结果，移交维护资料	成品、验收记录、源码与运维说明	使用方能否接手，后续责任是否明确

阶段之间允许回退。例如，企业环境中的文档无法被应用读取，就需要重新处理运行身份、数据路径和授权；使用者认为模板遗漏了重要事项，则回到规则确认与试点验证。进度应反映解决了哪些问题，哪些条件仍未满足。

一个实用做法是为每阶段写一页简短记录：本阶段目标、实际输入、已验证结果、未解决问题、下一步依赖及负责人。这样可以避免“代码已经写好”和“业务已经可用”在汇报中被混为一谈。

交付边界要能逐项核对

仅约定做一个办公助手，很难判断何时完成。至少需要明确任务、资料、用户、入口、输出、排除项、前提条件和验收方式。

以会议纪要助手为例，可以这样形成一份可检查的范围说明。以下是编辑示例：

项目	约定示例
输入	指定格式的会议转写稿与已授权附件
输出	包含议题、讨论、决定、待办和待确认项的可编辑草稿
覆盖范围	一个部门、一个入口、一套经确认的模板
人工确认	决定性质、负责人、时间和最终发送内容
本期排除	自动审批、直接发送正式通知、其他部门系统接入
使用方准备	样例、账号、权限、模板与业务确认人
验收材料	固定样本、边界样本、最终文件和使用记录
变更方式	新增入口或写回动作前，重新确认工作量、周期和验收条件

读取资料、生成草稿、写回业务系统和对外发送，是不同权限下的动作。能查询一份资料不意味着可以修改它，能生成通知也不意味着可以代表企业发送。把动作拆开约定，才能清楚说明出错后由谁判断、由谁处理。

从云端订阅到集团部署，变化在哪里

按作者描述，项目最初考虑小范围云端订阅，首年报价为数十万级；后来需求扩展到集团规模、更多协作入口、约定企业环境内的部署，以及完整源码交付，软件部分报价进入百万级，维护与 AI 运行费用另行列出。

这里应比较的是不同范围、不同购买方式对应的交付，而不能把两种报价当作同一项服务的直接涨价。原文没有提供可供独立核实的合同与成本细目，不能据此推导同类项目的市场定价。

范围扩大后，至少有几类新增工作需要确认：

• **入口与身份：**哪些员工能使用，企业账号何时开通，入口如何关联应用身份。
• **部署与运行：**安装在哪里，依赖什么环境，如何更新、备份、监测与恢复。
• **数据与权限：**哪些资料可读，是否可写回，日志留多久，数据会经过哪些服务。
• **用量与费用：**额度由谁分配，成本如何归属，超过预算怎样处理。
• **源码与交接：**源码对应哪个部署版本，配置、依赖、构建及维护资料是否齐备。

按千人规模设计，并不能证明已有千人活跃使用；拿到源码，也不意味着接手人员已经能够部署和维护。这些都需要相应的运行记录或交接验证。

模型网关管理调用，其他工程责任仍要落实

作者描述的项目使用模型网关集中处理调用，包括敏感信息过滤、部门额度、允许的模型选择，以及费用和处理记录。这有助于把分散在应用中的调用策略集中起来。

但调用策略与数据安全不是同一件事。文件保存是否加密、用户能访问哪些资料、入口权限怎样限制、操作如何审计，都需要分别设计与验证。应用放进企业环境，也不能自动说明模型在离线运行；推理请求、日志、检索材料和生成文件的实际流向都要核对。

原文还指出，企业微信和飞书接入依赖企业提供账号与通道。接口代码完成，只能说明开发部分到了某个状态，真实联调还需要满足外部条件。项目计划应把这些依赖写清楚，并明确谁负责开通、谁负责验证。

在项目试点中，如果希望统一调用多个模型，可以参考 GPT88 的统一大模型接口指南配置模型访问，再用固定样本比较效果、成本和延迟。这是编辑补充的工具建议，原文未说明使用 GPT88。企业资料是否可以发送到外部接口，应依据本项目的数据流向、授权和部署要求决定；统一接口本身不能替代业务权限、审计或文件保护。

简单方案是否够用，要用真实任务判断

资料检索：先看能否找到正确材料

作者称项目采用了轻量 BM25 检索，没有引入向量数据库。做法是先根据查询词召回相关资料，再让模型基于材料组织回答。这是该项目的选择，不能推导为所有企业检索都适合关键词方案。

评估检索时，可以保留一组真实问题与预期参考资料，逐项检查是否召回、版本是否正确、引用是否充分。资料查不到时，先确认正文是否读入、扫描件是否可解析、用词是否匹配，再判断是否需要调整检索策略。文件名存在于系统，并不意味着正文已经进入可搜索范围。

固定录入：程序可能比 Agent 更合适

原文还介绍了一个 Excel 物料表录入场景。数据已经审核，主要工作是核对编号、数量和换算关系，并通过企业允许的方式写入管理系统。这类任务可以由规则程序承担，无需强行为每条记录调用模型。

该场景遇到过员工能正常打开文件、程序却读到密文的问题。作者强调核对授权应用、运行身份与执行位置，使用被允许的读取方式。这里的问题不是模型理解能力，换一个模型无法修复缺失的读取条件。

此外，并发运行与重复提交要分别处理。锁可以限制同时执行的实例，但中断后重跑仍可能再次写入已处理记录。项目还需要稳定的记录标识、提交状态与重试策略，才能判断哪些数据已经完成。

并发测试要说明测到了哪一层

作者报告，投标前曾进行一轮 30 路真实模型流式请求并发测试，该轮请求全部成功，首字响应 p95 约为 7 秒。该统计反映特定测试条件下开始输出的延迟分布，未提供原始样本和完整测试环境供独立复现。

它不能直接证明千人同时使用的容量，也不能说明最终文件已经完成。首个内容片段出现之后，流式响应可能中断，文件生成或排版也可能失败。

验证层次	能说明什么	还需要检查什么
请求成功	调用链路在该次条件下可达	后续是否中断、是否返回有效内容
首字延迟	开始输出的等待时间	完整生成耗时与长尾表现
文件生成	导出流程完成并产生文件	文件能否打开，内容与格式是否正确
业务验收	约定任务的输出达到检查标准	日常使用、维护和持续效果

原文的故障处理是输出前调用失败时尝试备用模型，最终失败则保留草稿。它没有承诺一个模型执行到一半时，另一个模型能够无缝继续。设计降级时，应明确当前状态、哪些动作已经发生、是否可重新执行，以及如何避免重复写入。

验收一直检查到用户拿到的成品

原文举了一个自动出图的教训：内部测量数值正确，最终图片上的尺寸文字却有误，而检查只覆盖了内部数值，因此未发现成品问题。

这说明最终验收要沿着同一份材料走完整条链路。以报告生成任务为例，除了检查工具返回值，还应打开导出的文件，核对数字、文字、来源、排版和可编辑性；以检索问答为例，需要确认答案引用的确实是有权限、版本正确的正文。

编辑建议把验收样本分成三组：正常材料、边界材料和故障场景。边界材料可以包含资料缺失、含糊的负责人、扫描件、过期模板和同名版本；故障场景则覆盖读取失败、模型中断、额度耗尽及重复提交。每类都写明期望行为与人工接手位置。

这样验收得到的是任务行为的证据，而不只是一个成功演示。截图、响应日志和文件都可以保留，但各自证明的范围要说清楚。

报价与业务价值，需要两套不同的核算

原文区分了交付投入与业务收益。软件、接入、部署、源码和交接可以解释项目包含哪些工作；企业是否值得购买，还要看实际使用后减少了多少重复劳动与返工。

作者给出的假设计算是：200 名员工稳定使用，每人每天在扣除人工核对后净节省 15 分钟，合计每天 50 小时；按一年 220 个工作日计算，是 11000 小时；若每小时综合成本为 100 元，对应名义工时价值 110 万元。

这不是该项目已经测得的收益，也不等于企业实际少支出了 110 万元。要把它变成业务证据，还需核对活跃人数、同类任务前后耗时、核对与返工成本，以及节省的时间有没有转化为更多产出或更少加班、外包。

比较不同交付方式时，也应使用同一时间范围，把软件、维护、模型调用、部署运行和企业内部投入放在一起。不能只拿一次性软件费用与另一个方案的一年订阅费用直接比较。

交接包应该让另一位维护者接得住

项目收尾时，可以用下面这份编辑清单核对交接材料：

• **版本对应：**交付源码、依赖、构建结果与实际部署版本能够对应。
• **安装配置：**环境要求、配置项、权限需求和部署步骤齐全；密钥通过约定的安全渠道管理。
• **运行记录：**验收样本、测试条件、已知问题与适用范围可查。
• **日常维护：**模板、资料、模型配置与额度如何更新，哪些变更需要重新验证。
• **故障恢复：**失败任务怎样查询，草稿怎样恢复，版本怎样回退。
• **责任归属：**企业账号、数据准备、通道开通、软件维护和调用费用分别由谁负责。

最有说服力的交接检查，是由另一位维护者按文档在约定环境中完成一次部署或恢复，并通过同一组验收样本。能否离开原开发者继续使用，是检验交付完整程度的实际办法。

这篇案例可以转化为三个项目动作：先用小范围任务证明价值；需求扩大时重新确认范围和前提；把验收一直跟到真实入口、最终成品与维护交接。对具体项目而言，做多大、选什么技术，都应由这些证据决定。

来源与延伸阅读

• Miles Ma：原始 X 帖子，2026-10-19。
• Miles Ma：一个百万级的 FDE 项目，到底在交付什么？，完整正文及配图通过公开 X 镜像读取。金额、项目经历和性能数据为作者自述，未独立审计。
• 配图来自原文，按相关主题保留，用于解释阶段、范围、调用、验收与交接。
• 站内延伸：从 Palantir 本体论理解 FDE 的现场交付、AI Agent 工程师 12 步学习路线。