FDE 项目的招标文件和传统软件外包标书差在哪?
FDE 买的是把业务场景验证到生产可用的推进能力,不是一份固定功能清单的实现。传统软件外包按功能点枚举和人天单价写标书,投标方照单报价即可;FDE 项目场景尚未定型,功能会随验证结果调整,招标文件若仍按功能清单写,投标方只能按人头填报价,业务效果无人负责。范围章节应按阶段、进入条件和交付物来组织。
从买功能清单改成买阶段推进能力
- 把招标目标写成一条业务场景的通过标准,而不是系统功能点的枚举清单
- 列出每个阶段的进入条件与退出判断,允许在任何阶段结束后选择停止投入
- 写清业务方的配合义务:数据授权、对接人和评审时间,与投标方义务对等
- 查一遍候选投标方过往项目的阶段划分方式,与标书结构是否对得上
边界与提醒如果企业内部已完成选型、只缺执行人力,按传统功能外包招标反而更省事;FDE 式标书适合场景尚未定型、需要边验证边建设的项目,把它用在范围已锁定的改造项目上,只会增加阶段评审成本。
服务范围要写到多细,后期才不会扯皮?
服务范围至少写到三层:阶段划分与进入条件、每阶段交付物清单、交付物的验收口径。深云官网的 FDE 页面把交付拆成找准问题、验证闭环、生产上线、采用复制四个阶段,每阶段都写明进入条件与交付物,这套结构可以直接作为招标文件范围章节的参照框架,避免出现无法核对的模糊表述。
范围章节按三层结构写
| 层级 | 写什么 | 参照写法 |
|---|
| 阶段划分 | 项目分几个阶段、每阶段进入条件与继续投入的判断点 | 参照官网 FDE 页的四阶段结构逐条对齐 |
| 交付物清单 | 每阶段交什么:文档、系统配置、评测集、治理规则逐项列名 | 禁用相关资料、配套文档等无法核对的表述 |
| 验收口径 | 交付物由谁验收、按什么标准验、几天内提出异议 | 验收人写到业务负责人,不只由 IT 部门签字 |
边界与提醒范围写得过细也有代价:把每项工作都锁死在标书里,场景理解需要修正时每一步都要走变更流程;建议锁定阶段与交付物框架,框架不动、路径可换,允许阶段内的工作方式灵活调整。
哪些验收指标能写进合同,哪些不能写死?
能写进合同的是可复现的过程指标:冻结版评测集通过率阈值、人工复核抽检比例、故障响应时限;不能写死的是业务效果承诺,例如效率提升百分之几——业务效果受数据质量、组织配合等甲方因素影响,写死会让验收必然陷入举证争议。签约前先拿小批量真实数据试跑一轮,再共同确定阈值数字。
验收条款分可写死与不可写死两类
| 指标类型 | 能否写进合同 | 写法与注意点 |
|---|
| 评测集通过率 | 能 | 约定以冻结版评测集衡量,如新版本低于基线 3 个百分点即不放行 |
| 复核与响应 | 能 | 写明人工复核抽检比例、故障响应时限与问题升级路径 |
| 业务效果 | 不直接写 | 改写为双方共同确认的运营指标观察期,观察结果作为下一阶段依据 |
边界与提醒阈值数字来自过往项目经验,不是效果承诺;不同场景的合理阈值差异很大,直接照搬别家数字要么让验收必然失败、要么形同虚设,签约前用一轮真实数据校准再落笔。
评测集、提示词这些资产的归属和移交条款怎么写?
评测集、提示词配置、知识接入方案属于企业资产,归属条款只写知识产权归甲方是不够的,必须同时写清交付格式、移交时限和存放位置。合同里逐项列资产清单,约定阶段结束或项目收尾后若干天内,以可导出的格式移交到企业自己控制的库,服务方环境只保留工作副本。
资产条款的四条硬要求
- 列资产清单:评测集、提示词配置、知识接入方案、运维手册逐项写名,不写全部相关资料
- 写清移交时限与格式:约定收尾后 10 个工作日内,以可导出格式交到企业自己的文档库
- 约定权限:企业侧资产目录指定单一管理人和变更审批人,其余角色只给只读权限
- 按阶段对账:阶段结束时对照清单逐项打钩核对,缺项在阶段款支付前补齐
边界与提醒如果只约定归属而不写交付格式与时限,条款落不了地:拿不到可复跑的评测集和配置文件,更换供应商时这批资产照样带不走,归属条款等于没写。
人力投入按人天、按阶段还是按结果计价?
三种计价方式各有适用:按人天适合范围明确的执行与集成段;按阶段付费与 FDE 的阶段进入条件天然匹配,每阶段付款挂钩进入条件达成而非日历时间;纯按结果付费在 AI 项目里很难谈成,因为业务效果受甲方配合因素影响大。常见做法是阶段款为主、执行段人天封顶为辅的组合。
三种计价方式的适用与组合
| 计价方式 | 适合场景 | 注意点 |
|---|
| 按人天 | 范围明确的执行、集成与移交工作 | 写清人数上限与角色构成,避免执行段无限加人 |
| 按阶段 | 探索性强、结果待验证的场景验证期 | 付款挂钩进入条件达成,不挂钩日历时间 |
| 按结果 | 不建议单独使用 | 效果受双方因素影响,可改为效果挂钩的尾款比例 |
边界与提醒按阶段付费要防僵局:场景一直验证不通过、项目停在某一阶段进退两难;合同里写明每阶段最长停留时间,到期给出处理选项——终止、转按人天或调整范围,不留悬而未决的中间态。
变更和扩场景的边界条款怎么约定?
FDE 项目的大变数是第一个场景跑通后要复制到更多场景。招标阶段就写清变更判定规则:影响已冻结评测基线或交付物清单的改动才算变更,走补充协议;新增场景先出简短的补充评估,再决定补协议还是另立项。再设一笔变更工作量豁免额度,小额调整不进正式流程,避免迭代被流程拖慢。
变更判定与扩场景的处理规则
- 写变更判定规则:改动是否影响冻结的评测基线和交付物清单,影响即算变更
- 约定新场景流程:先出补充评估,写清复用什么、重建什么,再签补充协议
- 统计变更次数与原因,按季度复盘一次,区分是需求没定清还是标书漏写
边界与提醒豁免额度设得过高会变成范围失控的口子,过低则小额调整也走流程、双方都累;经验做法是把豁免量控制在阶段工作量的约一成以内,并写明额度用尽后的处理方式。
如果合作中断,退出条款要留哪些后手?
合同要假设合作可能中断。退出条款至少写四件事:任一方终止的通知期;终止时的资产移交清单与配合义务;移交期的人天计价与上限;移交期内对新接手方的答疑义务。评测数据若只存在服务方环境,中断时企业既无法复跑,也无法举证质量变化,尾款结算会失去依据。
退出条款预留的四项后手
- 约定终止通知期如 30 天,移交期上限 15 个工作日,按人天计价并设封顶
- 移交清单对照资产条款逐项打钩,验收人签字确认后尾款才结清
- 留出答疑义务:移交期内实施方对新团队的问题说明响应不超过 2 个工作日
- 存下资产:从项目第一天起,评测集与配置就存进企业自己控制的库
边界与提醒退出条款防不了合作失败本身,它只保证失败时资产带得走;真正的保障是资产存放位置从第一天就在企业侧,移交条款只是补一次导出与签收动作,不能指望合同替代日常管理。
内容说明
事实来源含官网公开服务页与腾讯云官方产品页;文中天数、比例与阈值均为经验值,不是效果承诺。
需要评估这类场景的落地路径?
深云做企业 AI 生产化交付,可以先给一版场景判断与实施路径,再决定要不要做。
了解深云的交付方式