定制软件分几步付款,才方便核对阶段成果?

做定制软件，谈到付款时，双方常会先讨论比例：启动付多少，开发完付多少，上线后还留多少。

但对企业来说，更早要说清的是：每一次付款前，究竟能看到什么成果？成果由谁核对？有问题时，哪部分继续、哪部分待补？

如果这些没有对应起来，即使分成很多期，也可能只是把一笔看不清的费用拆成几笔。下面给出一套阶段核对方法，帮助企业把付款讨论落到具体交付物上。示例是项目管理建议，不是通用合同条款，也不设统一付款比例。

一、先画交付过程，再讨论付款节点

可以先写四段：需求与范围确认、关键流程验证、约定范围交付、移交与运行检查。四段并不意味着一定分四次付款；小项目可以合并，大项目可以围绕业务模块拆开。

关键在于：每段都要有能够检查的成果，不能只有“完成30%”这样的进度说法。

例如需求阶段的成果，可以是范围清单、流程图、待确认事项和不在本期的功能。关键流程阶段，可以是一条能实际操作的完整路径。交付阶段，要对照约定清单检查。移交阶段，则核对代码、运行说明、账号权限和接手安排。

英国政府服务手册将探索阶段与后续构建区分开，先理解问题、用户和限制。这种做法可以帮助我们思考阶段目的，但它不是中国企业的付款规则。本文建议借鉴的只是“每个阶段回答不同的问题”。

二、把“做了什么”改成“拿什么核对”

“页面已完成”“后台已开发”可以作为进度描述，却不够成为一次检查的全部依据。企业还需要知道从哪里进入、用什么数据、走哪条路径，以及预期结果是什么。

下面用一个虚构的内部报修工具说明。第一期只处理报修登记、指定人员受理、状态查询和结果留存，不包含自动派单、资产盘点和费用结算。

在关键流程检查时，双方可以约定：使用已获准用于测试的样本，提交一条报修记录；管理员查看并受理；提交人能看到状态变化；处理结果与时间能够回查。

这种描述让业务人员有机会验证“工作能否接着做”。它不等于代码质量、安全性、性能等检查都已经通过。需要哪些技术检查，应另外列清。

一张核对单可以只保留六项：阶段目标、交付物、检查入口、样本和预期结果、确认人、未解决问题。每项写到可操作即可，不必为了显得正式堆很多术语。

“预计周五提供测试地址”和“周五已提供可用测试地址”应分别记录。把预计事项写成已交付，会让付款讨论从一开始就失去共同依据。

三、对结果分三种状态，别只留一个“通过”框

一次检查之后，至少可能出现三种结果：已通过、待修复、待企业补充条件。它们需要不同的下一步。

已通过：写清对应版本、检查时间和确认范围。只确认了报修登记，就不要把整个平台标为通过。

待修复：记录实际表现、预期表现、复现步骤和处理人。修复后还要复测。“已经改代码”与“业务检查通过”不是同一状态。

待企业补条件：例如正式接口尚未开放、业务规则存在冲突、负责人还没有确认字段。这类问题可能影响交付判断，应写明影响哪个环节和补齐时间。

这张表只用于把事实说清。哪些结果会触发付款、顺延或其他处理，需要双方在具体约定中明确，不能从“问题属于哪一类”直接推导付款结论。

有争议时，先固定当前版本和问题清单，再讨论处理安排。这样下一次复核不会把两次不同版本混在一起。

四、新增需求单独记，避免阶段成果越查越大

还是报修工具的例子。检查时有人提出：“能不能同时统计维修费用，再自动生成月报？”这个想法可能有价值，但并不自动属于已约定的第一期。

可以另外写一条变更记录：提出了什么、解决什么问题、是否必须现在做、对已有功能和时间有什么影响、由谁决定。

若决定加入，就更新范围与后续安排，并保存原版本。若暂缓，也写明重新评估的条件。不要口头答应后，让开发方与业务方各自记住不同的范围。

同样，发现原来就约定的功能没有实现，应记为交付缺项，不能为了清空问题单，把它改称新增需求。判断依据是双方已确认的范围和版本记录。

五、最后一个阶段，别只看系统能不能打开

页面能够访问，是交付检查的一部分。企业还应核对后面由谁维护、怎样定位问题，以及是否具备约定的接手材料。

对于包含源码交付的项目，可按约定检查：代码及版本标识、依赖与构建说明、部署配置说明、数据库结构或迁移说明、必要的测试记录、问题清单和维护责任。账号凭据应走双方认可的安全交接方式，不要直接放在公开文档或普通群聊里。

第三方服务也要单列。域名、云资源、短信、模型调用等由谁开通、谁续费、费用如何核对，需要明确。交付一份代码，不等于这些服务会永久免费运行。

如果合同范围本来不包含某项材料，应先确认差异，不能把本文检查表直接当成对供应商新增的义务。

智链魔方怎么做

智链魔方讨论AI辅助软件定制时，会先把业务任务、现有条件与交付范围分开梳理。对企业来说，先确认一条需要完成的工作，再确定第一期功能，通常比一次列出所有想法更便于沟通。本文的阶段核对单可作为需求讨论的起点：业务人员补充检查样本，技术人员说明实现条件，双方共同确认待解决问题。是否包含源码、哪些运行资料需要移交、第三方费用由谁承担，都应写进具体项目约定。这里介绍的是工作方法，不代表统一报价、付款比例或效果承诺。

回到最初的问题：定制软件分几步付款，没有适用于所有项目的固定答案。可以先让每一步都有清楚的交付物、检查方法和确认记录，再讨论与付款安排的对应关系。

参考资料：GOV.UK Service Manual，How the discovery phase works。本文阶段核对单与报修例子为原创方法示意，并非该手册的合同模板。

内容发布：智链魔方（深圳市智链魔方科技有限公司）。专注企业 AI 应用与落地，分享方法、工具实践与交付经验。主理人：聂亚奇。