软件开发公司提案拆解：影响价格、范围与所有权的 12 项条款

要真正审好一份软件开发提案，先把漂亮的排版放到一边十分钟。把它当作一张风险分配图来读：某个假设不成立时谁付钱；工作是否完成由谁判断；开发公司离场后，谁还能继续运行产品。只有这三个问题都有明确答案，首页上的报价才具有可比性。

本文是商业与技术审查工具，不是法律意见。案例完全虚构，只是把软件提案中常见的措辞组合到了一起。责任、质保、知识产权、终止与可执行性，应由熟悉适用法的专业律师复核。

免费下载可打印的 24 分提案审查表。其中包含评分卡、必须暂停的 Hard Stop、第一年可比价格表和十二个修改问题。目前 PDF 为英文版；完整说明已在本页中文化。

用四遍阅读法审查软件提案

1. 商业遍：什么证据触发付款，哪些工作被排除，什么情况会涨价。
2. 交付遍：会产生哪些交付物，如何验收，什么才叫「完成」。
3. 所有权与运营遍：代码、数据、账户、基础设施和许可归谁，你的团队能否接手。
4. 异常遍：延误、安全事件、争议、人员更换或终止时会发生什么。

把「合理」「行业标准」「及时」「基本完成」「按实际工作量」这类主观词圈出来。它们并非一定不合理，但必须配上负责人、证据、时点与未达成时的后果。否则，真正的含义要等到预算与时间已经投入后，才由谈判优势决定。

为什么本文不会与「如何选开发公司」互相抢排名

我们的如何挑选软件开发公司指南回答的是应该雇谁：资深程度、案例、工作方式、沟通与交接。本文从下一步开始，回答如何检查入选公司发来的文件。先选交付伙伴，再审提案或 Statement of Work 中的范围、价格与权利。这是两次不同的采购决策。

虚构提案：「Northstar 客户门户」

它看起来很具体：一个数字、一个周期、四组功能。但下面十二项条款如果保持含糊，真实价格可能多出数月工作、持续平台费用，以及未来的一次完整迁移。

十二项条款速查

1. 验收标准：什么会触发付款？

提案写道：「客户应在五个工作日内验收每个里程碑；未回复则视为验收。」

为什么危险：期限明确，测试却不明确。没有场景、数据、环境、容差和缺陷等级，开发公司可能把演示视为交付，客户却认为还未达到可用状态。默示验收会把这种差异放大。

修改要求：每个里程碑必须对应已命名的测试场景、数据、目标环境、UAT 负责人和窗口。定义阻塞、严重与轻微缺陷，以及修复和复测流程。明确通过验收后哪笔款项到期，合理拒绝时如何处理。

两分测试：一个未参加会议的人，能只凭条款判断该里程碑是否通过。

2. 知识产权：你买的是产品，还是只能访问？

提案写道：「所有定制交付物在全额付款后归客户。既有工具和通用 know-how 仍归开发公司。」

为什么危险：「交付物」「工具」「通用」都没有定义。源代码、基础设施、测试、设计、提示词、数据模型、文档和未完成工作是否转让并不清楚。若中途终止，已付款的里程碑也可能没有可用权利。

修改要求：区分客户材料、既有 IP、项目新产生的 IP 与第三方 IP。列出转让的具体资产、转让时间、地域、期限、修改与再许可权。产品运行所需的既有 IP 应提供永久且足够宽的许可。员工和分包商的权利链也必须有保证。

European IP Helpdesk 明确区分权利转让与许可。合同措辞必须与实际想买到的经济结果一致。

3. 变更请求：额外工作如何获批？

提案写道：「变更与新增要求按当期日费率、依据实际工作量计费。」

为什么危险：没有基线范围、变更表、影响分析或指定审批人。原本的 bug 可能被说成新需求，或者在客户看到价格和周期影响前就已经开始收费。

修改要求：每次变更都要写明原范围、新范围、假设、价格、时间、依赖与验收。只有指定人员能在开工前书面批准。为满足既有标准而修复缺陷，不属于收费变更。

合同模型如何影响这项风险，可参考固定价格与 T&M：用数字看 Scope Creep。

4. 质保：修复的钱由谁付？

提案写道：「上线后 30 天内，开发公司免费修复严重 bug。」

为什么危险：「严重」「bug」「上线」都没有定义。也没有响应时间、补救、复测和早期里程碑缺陷的处理。任何偏差都可能被重新定义为维护或增强。

修改要求：把缺陷定义为不符合规格、验收标准或完成定义。明确质保起点与期限、等级、响应和修复目标、复测与升级。把缺陷修复、维护和增强分开。

5. 依赖：延误风险归谁？

提案写道：「时间表以客户及时配合为前提。客户延误将相应顺延所有日期。」

为什么危险：这是一项单边且没有上限的义务。哪怕迟到的输入不在关键路径上，也可能成为整体延期理由；开发公司却没有尽早预警和降低影响的对等责任。

修改要求：建立责任矩阵，写清 owner、具体交付物、截止日和被阻塞的里程碑。要求立即发出延误通知、记录影响并采取合理缓解。只有能证明影响关键路径的延误才能顺延。

6. 托管：谁拥有生产环境与持续账单？

提案写道：「解决方案托管于开发公司的 managed cloud，基础设施费用按月转收。」

为什么危险：区域、服务、预算、加价、访问、备份、监控与退出都缺失。如果云、DNS、域名、应用商店或日志在开发公司的账户里，更换供应商可能等于重建。

修改要求：尽可能从第一天起使用客户账户。明确区域、服务、预算上限、账单 owner、备份、恢复测试、监控、管理员访问和迁移。基础设施应能通过代码重建。若暂时由开发公司托管，必须规定导出格式、转移期限与已测试的迁移路径。

价格规则：把 12 个月真实的托管、监控与支持费用加回报价。「按使用量」不等于零。

7. 第三方许可：还要支付或遵守什么？

提案写道：「为加快交付，可使用行业标准的开源与商业组件。」

为什么危险：开源通常是正确选择，但许可有条件，商业服务会续费。客户需要知道分发、源码披露、席位、交易费与可转让性是否受影响。

修改要求：要求组件清单或 SBOM，列出版本、来源、许可与已知持续费用。带有限制或高切换成本的组件要事先批准。商业许可应由客户直接持有或可转移。欧盟委员会 ICT 知识产权条款也要求列出开源组件及许可，并对可能限制分发的条款事先批准。

Hard Stop：核心服务只许可给开发公司，客户没有直接权利，也没有实际替代方案，这就是供应商锁定。

8. 交接：胜任的替代团队下周能否部署？

提案写道：「项目完成后，开发公司提供源代码与合理文档。」

为什么危险：仓库快照不等于交接。没有历史、CI/CD、基础设施、凭据、数据模型、运行手册和未解决问题的背景，新团队必须付钱重新发现系统。

修改要求：列出客户自有且含完整历史的仓库、build 与 deploy 流水线、Infrastructure as Code、架构和数据流图、schema 与迁移、自动化测试、运维与支持手册、备份恢复、账户与凭据清单、依赖和许可、已知问题、决策与培训。由客户或替代工程师完成一次干净的部署或恢复，才算交接验收。

完整资产清单见软件交接检查清单。

9. 终止：第九周停止时你能拿到什么？

提案写道：「任一方可提前 30 天书面通知终止。已付费用不退，所有未付发票立即到期。」

为什么危险：它解释了如何通知，却没有解释产品如何退出。未完成工作、部分里程碑、数据导出、访问、过渡支持、删除、许可与未验收工作如何付款都缺失。

修改要求：区分便利终止、未补救违约与破产。定义已验收工作的付款、进行中工作的处理、交付的资产与数据包、转移期限、凭据轮换、删除证明、持续许可与封顶的过渡费率。明确哪些 IP、保密、质保、数据保护与付款条款继续有效。

退出测试：「如果下一个里程碑后停止，十个工作日内会收到哪些文件、账户、权利与帮助，我们还欠多少？」答案应能放进一张表。

10. 安全义务：范围内到底包含哪些控制与证据？

提案写道：「开发公司遵循行业安全与数据保护最佳实践。」

为什么危险：不存在唯一的「最佳实践」，也没有验证级别与证据。无法判断威胁建模、访问控制测试、依赖扫描、密钥管理、事件通知或渗透测试是否包含在报价中。

修改要求：先做数据分类和责任矩阵。指定基线与版本，例如 OWASP ASVS 的某个级别或子集，并用 NIST SSDF 描述安全开发责任。明确测试、证据、修复、密钥、加密、日志、事件通知时限和独立评估。涉及个人数据时，DPA 应按 GDPR 第 28 条覆盖指令、保密、安全措施、协助和次级处理者。

范围提醒：「可以做渗透测试」不是渗透测试；「符合 GDPR」不是处理指令清单。

11. 分包商：实际是谁在做，谁能访问数据？

提案写道：「开发公司可按需聘用合格专家，并继续对交付负责。」

为什么危险：客户不知道分包的工作、地点、数据访问、义务是否向下传递，也不知道开发公司是否拥有足以转让的输出权利。

修改要求：披露重要分包商、角色、地点及系统或数据访问。风险相关的更换要有通知与有意义的反对或批准机制。保密、安全、数据保护、审计与 IP 转让义务必须下传，开发公司仍对结果负责。处理个人数据时，GDPR 第 28 条要求对其他处理者事先给予具体或一般书面授权。

区分：为了已知问题而提前点名的专家是好信号；用看不见的初级资源替换售前资深人员，是交付风险。

12. 完成定义：验收前包含哪些质量工作？

提案写道：「功能在基本实现并向客户演示后视为完成。」

为什么危险：演示只证明一次 happy path。它不能证明代码审查、自动化测试、无障碍、安全、文档、部署、可观测性与清理已经完成。它们之后可能以「加固」名义出现在固定价之外。

修改要求：完成应包括：代码已审查并合并；约定测试通过；验收标准满足；安全检查干净；适用时完成无障碍与浏览器检查；文档更新；部署到指定环境；监控与错误处理启用；没有阻塞缺陷。完成定义要版本化，并写明谁能批准修改。

官方 Scrum Guide 把 Definition of Done 作为 Increment 的质量承诺。即使项目不用 Scrum，这个思想也适用：「完成」描述的是质量状态，不是演示时的信心。

"软件提案里的价格不是一个数字。它等于首页报价，加上以后必须由买方出钱消除的每一处歧义。好的条款不会让合作变得敌对；它们只是避免普通的不确定性在压力下变成谈判。"

验收标准、完成定义和交接不是一回事

把三者统称为「客户签字」会非常昂贵。功能可以通过业务测试，但代码无法维护；代码可以很干净，但客户仍无法部署。三个状态必须分开测试。

如何比较两份提案的真实价格

可比价格 = 开发费 + 被排除的必需工作 + 第一年持续成本 + 估值后的客户工作量 + 预期退出工作。

这些数字是虚构的，不是 Wavect 价格基准。重点是方法：当较低报价把必需工作放到范围外，它反而更贵。让每家公司填写同一张 inclusion matrix，再比较。

评分方法：每项 0、1 或 2 分

• 0 - 缺失。提案未处理，或引用的附件没有提供。
• 1 - 主观。条款存在，但只说「合理」「标准」「及时」，没有 owner、测试或后果。
• 2 - 可执行。明确 owner、资产或测试、时点、依赖与未达成时的处理。

无论总分多少，只要 IP 权利链不清、个人数据没有可执行的安全与处理者条款、核心托管或许可不能转移，或者终止后拿不到代码与数据，就应暂停。分数是分流工具，不能抵消致命条款。

拆解之后应该做什么

1. 发一份汇总的修改清单，不要开十二条互不相干的邮件线。
2. 让未来真正负责交付的人解释每个排除项和假设。
3. 更新 SoW 与附件。会议记录不是合同。
4. 请资深技术人员检查可行性、依赖、安全范围与交接。
5. 请专业律师按适用法与风险调整法律措辞。

一家好的开发公司通常欢迎这些问题。精确边界既保护你的预算，也保护它的利润。拒绝任何细节才是信号；对某项具体风险分配进行有理有据的讨论，只是正常谈判。

来源与延伸阅读

1. UK Cabinet Office（2025），Model Services Contract guidance，v2.2：验收、测试、知识产权、变更控制与退出管理。gov.uk（访问于 2026 年 7 月 13 日）。
2. 欧盟委员会（2021），Additional IP clauses for ICT contracts：源代码、文档、开源批准与组件清单。commission.europa.eu（访问于 2026 年 7 月 13 日）。
3. European IP Helpdesk，Frequently asked questions on IP assignment and licences：权利转让范围、保证、赔偿与再许可。intellectual-property-helpdesk.ec.europa.eu（访问于 2026 年 7 月 13 日）。
4. 欧盟委员会，Can someone else process data on my organisation's behalf?：GDPR 第 28 条下的处理者、次级处理者与合同最低内容。commission.europa.eu（访问于 2026 年 7 月 13 日）。
5. NIST（2022），Secure Software Development Framework, SP 800-218 v1.1：安全要求与供应商采购的共同语言。csrc.nist.gov（访问于 2026 年 7 月 13 日）。
6. OWASP，Application Security Verification Standard v5.0.0：可用于采购与合同的可测试安全基线。owasp.org（访问于 2026 年 7 月 13 日）。
7. OWASP，Secure Software Contract Annex：安全要求、验证、报告与安全部署的谈判问题。owasp.org（访问于 2026 年 7 月 13 日）。
8. WIPO GREEN（2016），Licensing Checklist：SoW、交付物、规格、测试、验收与 IP。wipo.int（访问于 2026 年 7 月 13 日）。
9. Schwaber, K. 与 Sutherland, J.（2020），The Scrum Guide：把 Definition of Done 作为 Increment 的质量承诺。scrumguides.org（访问于 2026 年 7 月 13 日）。