软件项目通常怎么分阶段付款？

结论：软件项目应把付款节点绑定到可检查、可移交的成果，而不是套用 30:30:30:10；每一笔款都要写清触发证据、确认期限、未通过后的整改和退出处理。

签约预付款用于锁定团队和启动不可回收的工作，可以合理存在；但“设计确认”“开发完成”“上线稳定”如果没有具体标准，仍然只是日期或主观感受。付款比例取决于现金流、采购物料、项目长度和双方承担的风险，没有“首付必须不低于 30%”或“尾款必须留 10%—20%”的行业规则。

在形成预算、报价范围与成本假设时，还可以对照 软件平台需要一次性规划未来五年的全部功能吗？ 和 定制软件项目报价偏高时，费用通常主要花在哪些地方？有没有压缩空间？；这些内容补充了需要放在同一项决策中考虑的上下文。

节点名称必须换成可验证证据

付款节点	可接受的触发证据	不充分的写法	未通过时怎么处理
启动	合同生效、项目成员到位、计划与账号清单确认	“项目开始”	未按约启动时的退款或顺延规则
发现/方案	角色流程、原型、接口样例、风险清单和首期范围	“需求已沟通”	指定修改轮次或转入有偿变更
可运行里程碑	指定环境可访问，约定用户故事和测试通过	“开发完成 60%”	缺陷分级、整改期限和复验方式
生产上线	客户账号部署、迁移对账、监控、回滚和培训完成	“已提交商店”	平台驳回与双方原因分别处理
最终验收/交接	验收记录、源代码、文档、凭据移交和遗留清单	“运行一个月无问题”	默示验收条件和未决事项留款

三种项目节奏对应不同付款设计

项目状态	推荐节奏	客户的止损点	供应商的保护
范围清楚、周期短	启动 + 一个中期版本 + 验收交接	中期可运行版本不达标可暂停	启动款覆盖前期投入
高风险接口或数据迁移	先签发现/技术验证，再签建设	验证失败时不进入大额开发	验证工作本身独立付费
长期产品迭代	固定周期预算，按月或迭代复盘	每期调整优先级或终止	团队容量和付款周期稳定
含硬件/许可证采购	采购款与研发里程碑分开	可核验原始采购与所有权	不可退款物料先获资金

付款不是验收的替代品，尾款也不是唯一质量保证。合同应定义缺陷等级、响应与修复、保修范围、责任上限和知识产权交付。若客户迟迟不反馈，需要写明评审窗口和默示确认条件；若供应商未达标，需要规定整改、复验、暂停付款和终止后的代码数据交接。

需求变更必须先说明对范围、金额、工期和验收的影响，再由有权限的人书面批准。紧急口头需求可以先按约定机制处理，但随后应补齐记录。第三方云资源、短信、模型和商店账号由客户直接采购时，应从研发里程碑款中分开，避免供应商停工时生产资产也被锁住。

每次付款前只看一张证据清单

清单至少包含本期承诺、演示地址与版本号、验收用例及结果、已知缺陷、代码和文档位置、下期依赖、范围变更及费用。客户不需要阅读所有代码，但应能复现关键任务；供应商也不会因模糊的“感觉不满意”无限返工。

滚水科技会根据项目风险设计里程碑，不预设固定比例。阶段完成时交付可运行版本、测试记录和范围差异；客户确认后进入下一阶段。若首期证据否定原假设，我们会优先缩减或停止后续投入，而不是用已经规划的付款表强推五年蓝图。