合同与价格：为确定交付，也为探索留边界

一个尚未完全认识的问题，很难被一次报价说清。甲方希望控制预算，乙方需要承担探索成本；双方若只把不确定性藏进一句“按需求完成”，签约后的每一次学习都可能变成争执。

FDE 合同需要同时容纳两件事：已经知道必须交付什么，以及还要用什么工作弄清未知。前者不能借探索之名无限拖延，后者也不能被包装成已确定的生产承诺。

先约定这笔钱买到哪一段工作

继续用维修企业的教学试点。甲方希望减少主管寻找资料的时间，未来可能开放自动派单。现阶段，报修资料是否完整、建议能否帮助主管、动作能否安全撤回，都还需要验证。

若立即签一份覆盖“全公司智能维修”的固定总价合同，双方甚至没有共同的交付对象。更可判断的安排，是先批准一种设备、一个区域的材料整理与人工确认试用；探索期需要交出经过许可的数据样本说明、可复现的评估、已知限制、可用范围，以及下一阶段选择。自动派单作为待证明的选项，不进入当前上线承诺。

这样，即使结果是暂不开放自动动作，探索也可能完成了约定工作。相反，只交一个演示，却没有弄清材料和失败条件，不能因为团队“进行了探索”就视为全部履约。这是本书的教学安排，不是任何公司的合同原文。

把阶段分开不等于提前保证下一阶段会采购。甲方应能根据证据选择继续、缩小或结束；乙方也要知道这段工作得到怎样的付款，不能依赖尚未签署的后续合同补回全部投入。需要先发生成本的共同研究，可以各自承担、单独收费或通过双方接受的其他商业安排处理，关键是明说。

定价应当对应谁承担哪种不确定性

本书不提供一个适用于所有企业的报价公式。我们可以比较几种选择如何改变行为。

按时间收费，容易看清投入，但客户可能担心解决问题越慢、账单越大。固定范围收费，给预算带来确定性，却要求双方认真管理范围变化。按软件订阅加实施费用，能将持续产品能力与一次性接入分开，但要解释哪些支持已经包含、哪些另行发生。按结果付费看起来最贴近价值，前提是结果可以测量，而且供应商对关键变量有足够影响力。

如果项目目标是减少某项业务损失，而价格、客户政策、市场环境和内部执行都能改变损失，仅按结果结算就可能引发长期争执。问题不在于这种模式天然好坏，而在于计量范围、影响能力和风险承担是否匹配。

Sierra在2024年12月的定价说明中，把客服问题解决、挽留取消等列为可约定的结果；同一篇文章也承认，迎宾、路由一类交互可能更适合按会话计费的混合方式。¹ 这比一句“以后都按效果收费”更有解释力：有些任务的终点可以清楚计量，有些任务只负责把工作交给下一环。

把它放进一份教学合同，双方至少需要共同判断一次账单：机器人说“已解决”后，客户当天又来追问，算一件还是两件？先由AI收集材料、再由人工处理，分别如何付费？挽留成功是否要等退款窗口结束？这些约定决定谁承担未完成、重复联系和后续反悔的费用。还要分清验收条件与计价方式：固定总价的项目也可以约定达标才付款；按已确认结果的数量结算时，每项结果的单价可以固定，变化的是总费用。

埃森哲在2026财年第一季度的业绩演示中，恰好把两者分开：公司称，2025财年约60%的工作采用固定价格，而以实际实现的结果为基础的商业安排仍只占很小部分。² 所以，看见一家服务商增加固定价格合同，不能直接写成它已经大规模按业务结果收费。双方可能只是重新分配了超时、返工和工具提效的收益与风险，客户的经营结果未必成为结算单位。

较务实的办法，是先把不确定性拆开。探索阶段允许有限的学习预算，达到明确证据后再扩大范围；已经稳定的功能采用更确定的交付与维护约定。这样可以防止一种不舒服的情况：供应商承诺了无法控制的结果，客户则以为所有后续变化早已包含在价格里。

付款节点要能辨认交付，不只辨认活动

英国 DDaT Playbook 的定价指导把确定性与付款安排联系起来：范围较确定时可以采用固定价格，不确定性更高时考虑可变方式；它也提醒，敏捷项目的付款节点不宜仅按完成了几轮开发来设置。³ 这是一种采购设计原则，不能证明某份合同已经合理。

回到维修试点，“团队已经工作若干周”和“主管能在约定范围内找到可核对的依据”不是同一种交付。前者可用于确认投入，后者需要样本、工作步骤和异常处理记录。若约定按时间付费，也可以要求提供这些阶段产物；按固定价格付费，则仍需明确验收责任人与处理异议的办法。

运行期也应说明计费对象。调用量、使用人数、完成事项、人工支持和紧急响应，是不同的成本或价值单位。不能在销售时只展示便宜的调用价格，签约后才把必需的人工支持作为意外增加项。约定包含的服务时段、响应范围和用量变化后的处理方式，才可能让预算与运行相接。

付款时间还会改变双方的周转压力。验收材料迟迟无人确认、余款推迟到账，即使合同总额没变，也会影响乙方是否有资源继续交付。金额、成本与到账时间如何分开，见《项目经济性：把双方的账算清楚》的独立教学账；那组80万元数字不是本章维修试点的真实报价。

一次变更怎样进入合同，而不是进入加班

维修主管提出增加设备类别时，先确认它改变了哪些输入、权限、测试、工作量与运行责任。FDE 提供技术影响，客户业务负责人说明价值，双方有权调整承诺的人再选择接受、缩小或延期。原约定不会因为大家讨论过新需求就自动扩大。

若阻碍来自甲方尚未提供的数据，不能只把时间风险笼统压给乙方；若乙方承诺的能力尚不能使用，也不能把它重新命名成客户追加需求。对前置条件写明提供者、完成证据和未满足后的处理，可以帮助双方辨认究竟发生了什么。

不是所有异常都必须改合同。约定范围内的缺陷修复、已包含的支持、正常工程调整，应按原安排处理。真正改变功能范围、风险承担、使用规模或服务期的事项，才需要相应的商业决定。否则小问题拖成商务谈判，大问题却被藏在即时通信中。

在共同开发之前，说清成果怎样使用

客户原始资料、为客户编写的适配代码、供应商公共平台、第三方组件，不能合并成一句“全部成果归甲方”或“全部归乙方”便结束讨论。所有权、使用许可、维护责任和迁移所需权限，也不必由同一方持有。

例如，客户可能只需要能够使用和维护适配代码，而不购买平台源码；供应商可能愿意维护公共功能，却不能授予自己并不拥有的第三方权利。具体条款应由双方负责商业和权利事项的人按对象确认。现场工程师能说明技术依赖，不能凭一句“以后可以搬走”补出缺少的许可。

这也关系到共建所得能否服务其他客户。可复用的工程方法与客户受保护的资料要分开；是否允许使用、怎样去除客户专属信息，应以实际授权为准，不能因为写成了通用组件就推定已经可以对外传播。

结束时需要交什么，也应在开始时进入估算：可用的数据与状态、必要的说明、接手支持、保留和撤销权限的安排。详细的权利清单与迁出演练留在《边界、风险与退出》。本章要做的前置工作，是使这些责任有人承担、有人付费，而不是等关系结束时才发现双方理解不同。

一份适合共建的约定，应让双方对下一步有相同理解：已承诺的工作不能随意缩水，未被证明的未来也不被提前卖出。价格给出资源边界，阶段证据决定是否继续，变更规则让学习有地方落下。