软件开发合同怎么签？需求变更、验收、源码归属与付款节点清单

软件开发合同不能只写一个总价和一个上线日期。真正容易产生争议的地方，通常是“做什么没有写清楚”“需求变化怎么计价”“什么证据算验收”“源码和账号归谁”“上线后谁负责”。合同的作用，是把这些问题变成双方可以查阅、确认和留档的规则。

本文提供一套适用于软件定制开发、企业管理系统、网站、APP、小程序和阶段性外包项目的核对框架。示例条款是项目管理层面的参考，不替代律师根据主体、交易地点、数据类型和实际业务审查正式合同。涉及知识产权、个人信息、跨境数据、付款税务或争议解决时，应结合适用法律和专业意见确认。

一、先判断需要签哪一种合作文件

很多项目一开始就要求“直接签完整开发合同”，但双方连首期范围都没有确认。这会把需求讨论、原型设计、开发实施和维护服务混在同一个总价里，后续很难判断变化属于原项目还是新增工作。

如果项目比较大，可以把主合同和需求说明书、报价单、排期表、验收标准、数据处理说明、维护协议列为附件，并写明附件之间的优先级。不要让报价单、聊天记录和口头承诺互相冲突却没有解释规则。项目开始前先完成软件定制开发需求分析清单，再决定是否进入完整开发阶段，通常更容易控制风险。

二、合同首先要写清楚“交付什么结果”

“开发一套管理系统”“完成 APP 开发”“做一个官网”都不是可直接验收的交付定义。合同至少要能回答以下问题：

• 使用者有哪些角色，每个角色要完成哪些任务？
• 首期包含哪些页面、功能、字段、状态和异常处理？
• 哪些现有系统、数据、设备或第三方服务需要连接？
• 最终交付的是页面、源码、数据库、接口、部署环境，还是还包括培训和文档？
• 哪些功能、平台、语言、地区、设备、数据迁移或性能目标明确排除在首期之外？
• 谁提供业务规则、素材、接口资料、测试账号、脱敏数据和审核意见？

建议把范围拆成“目标、角色、流程、数据、权限、接口、页面状态、交付物、排除项”九个部分。每个功能都用“角色 + 前置条件 + 操作 + 成功结果 + 异常结果”描述。例如“销售可以新增客户”还不够，需要继续写明重复客户如何提示、哪些字段必填、销售能否查看同组数据、保存失败后是否可以重试、管理员如何导出和撤回。

用范围基线替代模糊的功能名

范围基线是双方共同确认的版本。它可以是需求说明书、原型链接、接口表、页面清单和排除项的组合。每次修订都要有版本号、日期、修改摘要和确认人。

页面数量不能代替范围定义。一个只有展示内容的页面，与一个包含登录、审批、支付、文件上传和多种异常状态的页面，工作量并不相同。报价比较时，可结合软件开发报价拆解方法逐项核对工作量、依赖和风险。

三、需求变更要有一条可执行的流程

开发过程中出现新想法很正常，问题在于双方有没有办法判断它的影响。合同应定义“什么是缺陷，什么是需求变更，什么是原范围内的澄清”，并约定没有确认前是否可以暂停相关开发。

一个简单的变更流程可以是：

1. 提出人填写变更单，描述背景、目标、涉及角色和希望完成的时间。
2. 开发方分析影响，列出新增或减少的工作、费用、周期、接口、数据迁移和测试范围。
3. 双方指定的负责人确认接受、拒绝、拆分或放入后续版本。
4. 变更单获得双方书面确认后，更新范围基线、排期和付款计划。
5. 在版本验收时标出变更单编号，确认变更已实现或转入下一版本。

变更单至少包含：编号、提出日期、提出人、业务理由、原范围、变更内容、影响页面和接口、费用、周期、验收方式、依赖条件、确认人和生效日期。邮件、项目管理工具或后台确认都可以作为记录，关键是双方事先约定什么渠道有效。

“客户在群里说过”“开发人员口头答应过”不应自动变成无边界的免费工作。反过来，开发方也不能把原范围内的必要修正都包装成新增需求。判断时要回到已确认的目标、流程和验收条件，而不是只看一句功能名称。

四、付款节点应绑定可查看的交付物

付款安排不应只写“签约付一部分、上线付尾款”。每个节点都要对应能够查看和留档的交付物、确认人和异议处理期限。比例没有通用答案，项目规模、前期工作量、数据风险和双方议价都会影响安排；重点是节点与结果相匹配。

合同还要写明发票或收款条件、付款期限、收款账户、逾期处理和争议款项是否影响未争议部分。若客户只对部分交付物有合理异议，应约定双方如何先确认无争议部分，避免整个项目因为一项问题完全失去推进路径。

五、验收标准要能让第三方复现

“客户满意”“功能正常”“符合行业标准”通常太抽象。验收附件应说明环境、账号角色、测试数据、操作步骤、预期结果、允许的缺陷等级和复测方式。验收不是只看页面能不能打开，还要检查流程、权限、异常、数据一致性、性能和交接材料。

验收标准至少包含这六项

1. 环境范围：支持的浏览器、手机系统、屏幕尺寸、服务器配置和网络条件。
2. 测试账号：管理员、普通员工、只读用户、外部协作者等不同角色，账号由谁提供和回收。
3. 测试数据：正常、空数据、重复数据、边界值、超长文本、无权限数据和脱敏真实样本。
4. 场景用例：创建、编辑、提交、审批、撤回、导出、失败重试、并发和断网恢复。
5. 缺陷等级：阻断核心流程、影响主要功能、一般问题和视觉建议分别如何处理。
6. 验收程序：测试周期、问题提交渠道、修复时限、复测方法、部分验收和最终签字。

缺陷分级可以按影响描述，而不是简单按“严重、一般”命名。例如，阻断登录、支付、订单保存或数据隔离的错误，应优先于文字间距问题；但具体响应和修复时限要根据项目约定。验收记录保留 URL、版本号、账号角色、操作步骤、实际结果、截图或日志位置，后续才有复盘依据。

性能目标也要写条件。比如“移动网络下首屏很快”无法复现；可以改成“在约定的设备、网络、页面和测试工具条件下，记录 LCP、INP、CLS 或接口响应时间，并说明测试次数和取值方式”。这不是对所有真实用户体验的绝对承诺，而是双方约定的工程验收口径。

软件开发周期也应以范围、接口、数据准备和确认时间为前提，不能脱离这些条件承诺一个固定天数，可以参考软件开发周期排期方法建立排期附件。

六、源码、数据、账号和知识产权要分开写

“项目成果归客户所有”仍然不够具体。至少要分别确认以下对象：

客户应尽量持有域名注册商、云平台、代码仓库、邮件服务、统计工具和第三方接口的主账号。开发方可以获得完成工作的受限权限，但不应让生产环境长期依赖个人邮箱或个人支付账户。交接时要执行密钥轮换、离职账号回收和权限复核。

如果开发方使用通用框架、脚手架、内部工具或第三方开源代码，合同应区分“本项目定制成果”和“既有材料”，并写清客户是否可以修改、部署、迁移和委托其他团队维护。开源许可不能通过合同任意改写，实际使用前要核对许可证和分发要求。

七、第三方接口和平台审核不能写成单方保证

微信、支付、短信、地图、OCR、云存储、应用商店和海外平台都有自己的账号、审核、限额和服务稳定性。合同应把“开发方能控制的工作”和“依赖第三方决定的结果”分开。

建议逐个接口确认：

• 由谁申请和持有账号，谁承担订阅、调用和超额费用？
• 测试和生产环境是否分开，回调地址和密钥由谁配置？
• 接口超时、重复回调、限流、停服和返回字段变化怎么处理？
• 平台审核失败时，谁负责准备材料、修改功能和再次提交？
• 第三方政策变化导致的改造，属于维护、变更还是新项目？
• 业务数据经过哪家服务，保存在哪里，能否导出和删除？

不要把“保证通过平台审核”“保证获得应用商店推荐”“保证百度或 Google 排名”写成开发方可以单独控制的结果。可以约定资料准备、技术检查、提交协助和问题修复的服务内容，但最终审核和搜索结果受平台规则、竞争环境和实际内容影响。

八、隐私、安全和合规要写到操作层

合同中只写“双方遵守相关法律法规”通常无法指导项目执行。涉及个人信息、客户资料、医疗或财务数据时，至少要确认数据类型、处理目的、访问角色、存储地点、保存期限、导出和删除方式、事件通知以及项目结束后的返还或销毁。

安全条款可以落到这些操作：

• 测试数据使用脱敏样本，不把生产密码和完整个人信息复制到开发环境。
• 生产访问采用最小权限，重要操作有日志，账号离开项目后及时回收。
• 密钥不写进前端代码和公开仓库，发生泄露时约定通知、轮换和排查步骤。
• 备份说明频率、保留周期、存储位置和恢复演练责任，不能只写“定期备份”。
• 约定漏洞或安全事件的联系人、初步响应时间、证据保留和对外沟通责任。
• 数据导出、删除、迁移和项目终止时的交接有可执行格式和期限。

如果项目涉及跨境访问、多语言站点或海外云服务，还要由实际主体确认数据出境、供应商条款、地区可用性和用户告知要求。软件开发者可以提供技术实现和记录，但不能替业务主体替代完成法律判断。

九、质保、维护和新增需求要分成三类

上线后的问题至少分为三类：原范围内未达到验收条件的缺陷、运行环境或第三方变化造成的问题、客户新增或改变业务规则的需求。三类事项的责任、费用和时间不应混在“免费维护”里。

维护协议还要说明是否包含内容更新、数据录入、服务器费用、证书续期、版本升级、漏洞修复、现场支持和节假日响应。把“终身维护”“永久免费升级”这类没有边界的表述改成期限、范围、渠道和退出方式，双方更容易执行。可参考软件上线后的维护与 SLA 约定细化。

十、延期、暂停、终止和交接要提前约定

延期不一定由一方单独造成。客户未按时提供接口、素材、测试账号或确认意见，平台审核、第三方变更、不可抗力和开发方资源安排，都可能影响排期。合同应要求记录依赖事项、预计影响和新的里程碑，而不是等到最后一天才争论谁负责。

暂停或终止时至少确认：

• 已完成和未完成的交付物如何盘点；
• 客户已付款部分对应哪些成果和使用权限；
• 源码、数据、设计稿、文档和环境如何导出；
• 第三方账号、域名、云资源和密钥如何移交或注销；
• 未结算费用、退款、已发生的第三方费用如何处理；
• 保密、数据删除、知识产权和争议解决条款是否继续有效。

交接不能只发一个压缩包。建议做一次接收演练：由客户账号拉取代码，按文档启动测试环境，恢复一份备份，登录生产或预生产查看日志，并确认没有个人账号和失效密钥。交付物清单可以参考软件定制开发交付物清单逐项签收。

十一、签合同前的 20 项核对表

签字前可以逐项回答“是、否、待确认”，不要用“应该包含”代替实际确认：

1. 合同主体、收款主体、发票信息和签署权限是否一致？
2. 项目目标、主要角色和首期业务流程是否写清？
3. 页面、功能、字段、权限和异常状态是否有附件？
4. 明确不做的内容、后续版本和依赖事项是否列出？
5. 需求、原型、报价、合同附件的优先级是否明确？
6. 需求变更是否有编号、影响评估和双方确认渠道？
7. 付款节点是否绑定可查看的交付物？
8. 测试环境、账号、设备、浏览器和数据准备责任是否明确？
9. 缺陷等级、响应时间、修复和复测方式是否可执行？
10. 最终验收的条件、期限、部分验收和异议方式是否写明？
11. 性能、可用性和安全目标是否包含测试条件和口径？
12. 源码、数据库、文档、设计稿和构建文件是否列入交付？
13. 域名、云平台、代码仓库和第三方服务的主账号归属是否明确？
14. 开源依赖、既有组件和第三方授权是否完成核对？
15. 数据访问、脱敏、保存、导出、删除和备份责任是否明确？
16. 平台审核、第三方故障和政策变化的责任边界是否写清？
17. 质保、运维和新增需求是否分开计价和处理？
18. 延期、暂停、终止和已完成成果的处理方式是否明确？
19. 上线交接、培训、恢复演练和权限回收是否有清单？
20. 保密、知识产权、争议解决和适用法律是否经过适当审查？

如果其中多项仍然是“待确认”，更适合先签需求分析或原型阶段文件，把未知内容变成可估算的范围，而不是马上签一个看似完整但无法验收的总包合同。

可直接复制的项目合同附件目录

项目启动时，可以把以下目录作为附件索引，再按项目实际情况删减：

1. 项目目标、角色和首期范围；
2. 页面、功能、字段与权限矩阵；
3. 流程图、原型和版本确认记录；
4. 接口、第三方服务和账号责任表；
5. 数据迁移、脱敏和数据处理说明；
6. 开发排期、依赖事项和里程碑；
7. 交付物、测试用例和验收标准；
8. 变更单模板、问题单模板和会议确认规则；
9. 源码、设计稿、文档、云资源和密钥交接清单；
10. 质保、维护、SLA 和版本发布规则；
11. 备份、恢复、故障响应和安全事件流程；
12. 项目暂停、终止和最终交接记录。

附件不是越厚越好。每一项都应有人负责、能被查阅、能在测试或交接时使用。合同正文解决责任和权利，附件解决具体工作和证据，双方都更容易在项目变化时保持同一套口径。

常见问题

软件开发合同一定要写固定总价吗？

不一定。范围清楚、依赖稳定的项目可以采用固定范围和固定价格；需求仍在探索、接口或数据不确定时，可以先按阶段、工时或上限预算合作。无论采用哪种方式，都要说明计费口径、变更流程和可交付证据。

需求还没确定，可以先签完整开发合同吗？

可以签框架合作文件，但不建议把未知范围直接写成固定结果。更稳妥的做法是先约定需求分析、原型或技术验证阶段的输出和费用，完成范围基线后再确认开发订单。

源码是不是付款后自动归客户？

不能想当然。源码交付、使用权、修改权、再许可、第三方依赖和付款条件应在合同中明确，具体知识产权安排还要结合合同主体和适用法律审查。项目开始时就让客户持有代码仓库和关键账号，通常更便于持续交接。

平台审核失败算开发方延期吗？

要看失败原因和合同约定。开发方可以负责技术检查、材料准备、提交和问题修复；平台规则变化、主体资质、经营内容或资料缺失造成的结果，可能不属于开发方可以单独控制的交付。合同应把协助义务和最终审核结果分开描述。

如何区分缺陷和新增需求？

把问题与已确认的范围、原型、数据规则和验收标准对照。如果已承诺的行为没有实现或结果不符合约定，通常应按缺陷处理；如果新增角色、流程、接口或业务规则，就应进入变更评估。双方应保留版本和变更记录，避免只凭印象判断。

没有案例，怎么判断开发方是否值得合作？

可以要求对方展示脱敏的需求模板、原型、测试用例、部署说明、交接清单和问题处理方式，并用一项小范围工作验证沟通和交付质量。不要要求或公开未经授权的客户源码、数据和合同。服务商选择还可以参考软件定制开发服务商评分表。