FDE · CONTRACT

FDE 项目招标文件该写清哪些条款和边界

招标文件决定 FDE 项目后期有多少扯皮空间。本文按签约顺序回答:标书和传统软件外包差在哪、服务范围写几层、验收指标哪些能写死、评测集等资产归属怎么写、人力怎么计价、变更和扩场景怎么约定、合作中断时退出条款留哪些后手。

FDE 交付采购与合同企业 AI 治理

FDE 项目的招标文件和传统软件外包标书差在哪?

FDE 买的是把业务场景验证到生产可用的推进能力,不是一份固定功能清单的实现。传统软件外包按功能点枚举和人天单价写标书,投标方照单报价即可;FDE 项目场景尚未定型,功能会随验证结果调整,招标文件若仍按功能清单写,投标方只能按人头填报价,业务效果无人负责。范围章节应按阶段、进入条件和交付物来组织。

从买功能清单改成买阶段推进能力

  • 把招标目标写成一条业务场景的通过标准,而不是系统功能点的枚举清单
  • 列出每个阶段的进入条件与退出判断,允许在任何阶段结束后选择停止投入
  • 写清业务方的配合义务:数据授权、对接人和评审时间,与投标方义务对等
  • 查一遍候选投标方过往项目的阶段划分方式,与标书结构是否对得上
边界与提醒

如果企业内部已完成选型、只缺执行人力,按传统功能外包招标反而更省事;FDE 式标书适合场景尚未定型、需要边验证边建设的项目,把它用在范围已锁定的改造项目上,只会增加阶段评审成本。

服务范围要写到多细,后期才不会扯皮?

服务范围至少写到三层:阶段划分与进入条件、每阶段交付物清单、交付物的验收口径。深云官网的 FDE 页面把交付拆成找准问题、验证闭环、生产上线、采用复制四个阶段,每阶段都写明进入条件与交付物,这套结构可以直接作为招标文件范围章节的参照框架,避免出现无法核对的模糊表述。

范围章节按三层结构写

层级写什么参照写法
阶段划分项目分几个阶段、每阶段进入条件与继续投入的判断点参照官网 FDE 页的四阶段结构逐条对齐
交付物清单每阶段交什么:文档、系统配置、评测集、治理规则逐项列名禁用相关资料、配套文档等无法核对的表述
验收口径交付物由谁验收、按什么标准验、几天内提出异议验收人写到业务负责人,不只由 IT 部门签字
边界与提醒

范围写得过细也有代价:把每项工作都锁死在标书里,场景理解需要修正时每一步都要走变更流程;建议锁定阶段与交付物框架,框架不动、路径可换,允许阶段内的工作方式灵活调整。

哪些验收指标能写进合同,哪些不能写死?

能写进合同的是可复现的过程指标:冻结版评测集通过率阈值、人工复核抽检比例、故障响应时限;不能写死的是业务效果承诺,例如效率提升百分之几——业务效果受数据质量、组织配合等甲方因素影响,写死会让验收必然陷入举证争议。签约前先拿小批量真实数据试跑一轮,再共同确定阈值数字。

验收条款分可写死与不可写死两类

指标类型能否写进合同写法与注意点
评测集通过率能约定以冻结版评测集衡量,如新版本低于基线 3 个百分点即不放行
复核与响应能写明人工复核抽检比例、故障响应时限与问题升级路径
业务效果不直接写改写为双方共同确认的运营指标观察期,观察结果作为下一阶段依据
边界与提醒

阈值数字来自过往项目经验,不是效果承诺;不同场景的合理阈值差异很大,直接照搬别家数字要么让验收必然失败、要么形同虚设,签约前用一轮真实数据校准再落笔。

评测集、提示词这些资产的归属和移交条款怎么写?

评测集、提示词配置、知识接入方案属于企业资产,归属条款只写知识产权归甲方是不够的,必须同时写清交付格式、移交时限和存放位置。合同里逐项列资产清单,约定阶段结束或项目收尾后若干天内,以可导出的格式移交到企业自己控制的库,服务方环境只保留工作副本。

资产条款的四条硬要求

  • 列资产清单:评测集、提示词配置、知识接入方案、运维手册逐项写名,不写全部相关资料
  • 写清移交时限与格式:约定收尾后 10 个工作日内,以可导出格式交到企业自己的文档库
  • 约定权限:企业侧资产目录指定单一管理人和变更审批人,其余角色只给只读权限
  • 按阶段对账:阶段结束时对照清单逐项打钩核对,缺项在阶段款支付前补齐
边界与提醒

如果只约定归属而不写交付格式与时限,条款落不了地:拿不到可复跑的评测集和配置文件,更换供应商时这批资产照样带不走,归属条款等于没写。

人力投入按人天、按阶段还是按结果计价?

三种计价方式各有适用:按人天适合范围明确的执行与集成段;按阶段付费与 FDE 的阶段进入条件天然匹配,每阶段付款挂钩进入条件达成而非日历时间;纯按结果付费在 AI 项目里很难谈成,因为业务效果受甲方配合因素影响大。常见做法是阶段款为主、执行段人天封顶为辅的组合。

三种计价方式的适用与组合

计价方式适合场景注意点
按人天范围明确的执行、集成与移交工作写清人数上限与角色构成,避免执行段无限加人
按阶段探索性强、结果待验证的场景验证期付款挂钩进入条件达成,不挂钩日历时间
按结果不建议单独使用效果受双方因素影响,可改为效果挂钩的尾款比例
边界与提醒

按阶段付费要防僵局:场景一直验证不通过、项目停在某一阶段进退两难;合同里写明每阶段最长停留时间,到期给出处理选项——终止、转按人天或调整范围,不留悬而未决的中间态。

变更和扩场景的边界条款怎么约定?

FDE 项目的大变数是第一个场景跑通后要复制到更多场景。招标阶段就写清变更判定规则:影响已冻结评测基线或交付物清单的改动才算变更,走补充协议;新增场景先出简短的补充评估,再决定补协议还是另立项。再设一笔变更工作量豁免额度,小额调整不进正式流程,避免迭代被流程拖慢。

变更判定与扩场景的处理规则

  • 写变更判定规则:改动是否影响冻结的评测基线和交付物清单,影响即算变更
  • 约定新场景流程:先出补充评估,写清复用什么、重建什么,再签补充协议
  • 统计变更次数与原因,按季度复盘一次,区分是需求没定清还是标书漏写
边界与提醒

豁免额度设得过高会变成范围失控的口子,过低则小额调整也走流程、双方都累;经验做法是把豁免量控制在阶段工作量的约一成以内,并写明额度用尽后的处理方式。

如果合作中断,退出条款要留哪些后手?

合同要假设合作可能中断。退出条款至少写四件事:任一方终止的通知期;终止时的资产移交清单与配合义务;移交期的人天计价与上限;移交期内对新接手方的答疑义务。评测数据若只存在服务方环境,中断时企业既无法复跑,也无法举证质量变化,尾款结算会失去依据。

退出条款预留的四项后手

  • 约定终止通知期如 30 天,移交期上限 15 个工作日,按人天计价并设封顶
  • 移交清单对照资产条款逐项打钩,验收人签字确认后尾款才结清
  • 留出答疑义务:移交期内实施方对新团队的问题说明响应不超过 2 个工作日
  • 存下资产:从项目第一天起,评测集与配置就存进企业自己控制的库
边界与提醒

退出条款防不了合作失败本身,它只保证失败时资产带得走;真正的保障是资产存放位置从第一天就在企业侧,移交条款只是补一次导出与签收动作,不能指望合同替代日常管理。

事实来源

内容说明

事实来源含官网公开服务页与腾讯云官方产品页;文中天数、比例与阈值均为经验值,不是效果承诺。

需要评估这类场景的落地路径?

深云做企业 AI 生产化交付,可以先给一版场景判断与实施路径,再决定要不要做。

了解深云的交付方式