IT研发外包合同里，怎么把交付物验收标准写明白？

说真的，每次看到那些几十页、满篇都是法律术语的外包合同，我头都大。尤其是看到“交付物应符合行业标准”、“功能需满足甲方要求”这种话，我就想笑。这不等于没说吗？啥叫“符合”？啥叫“满足”？到时候扯皮起来，两边都觉得自己有理。

我自个儿也跟外包团队打过交道，吃过亏。有一次，一个项目做完了，对方把代码一打包发过来，说“交付了”。我打开一看，注释全是乱码，文档一个没有，部署脚本得自己猜。问他们，他们说合同里只写了交付“软件”，没说要交付啥格式的。从那以后，我就学乖了。验收标准这东西，必须得在签合同前就掰扯得清清楚楚，跟查户口似的，一条都不能含糊。

这篇文章，我不想跟你扯那些虚头巴脑的理论，就聊聊怎么用最实在、最接地气的方式，把验收标准给定下来。这东西写好了，能帮你省掉后面无数的麻烦和扯皮。

第一步：别光想着“功能”，交付物是个“全家桶”

很多人以为，验收就是点点鼠标，看看功能对不对。大错特错。一个软件项目交付的，是一整个“全家桶”，里面啥都有。你要是只盯着功能，那桶里的“汤”是啥味儿的，你就完全不知道了。

所以，在合同里，你得先把这“全家桶”里具体有哪些东西，一样一样列出来。别怕麻烦，现在多写一个字，将来少说十句话。

1. 源代码和相关文档

这是核心资产。但“源代码”这三个字太笼统了。你得写清楚：

• 完整的源代码： 包括所有业务逻辑、前端、后端、数据库脚本。不能有缺失，不能有“这部分代码是商业机密，不能给”的情况。
• 代码注释规范： 别给一堆天书。可以要求关键算法、复杂逻辑的注释率不低于某个百分比（比如15%），或者要求遵循某种编码规范（比如Java的Checkstyle）。
• 技术文档： 包括但不限于：系统架构设计文档、数据库设计文档（E-R图）、API接口文档（比如Swagger/OpenAPI格式）、部署手册、运维手册。这些文档的交付格式也得写明，是Word、PDF还是Markdown源文件？

2. 可执行文件和部署包

如果你的团队不具备从源码构建的能力，那对方必须交付可以直接部署运行的东西。

• 构建产物： 比如Java的JAR/WAR包，前端的静态资源（HTML/CSS/JS），或者Docker镜像。
• 依赖清单： 必须有一个文件（比如pom.xml, package.json）清晰列出所有第三方依赖，版本号都要写清楚，避免“在我这儿能跑，在你那儿就报错”的尴尬。
• 环境配置说明： 需要什么样的服务器环境？JDK版本？数据库版本？这些都得写明白。

3. 测试报告

不能对方说“测过了，没问题”，你就信了。你得要一份正式的测试报告。

• 单元测试报告： 核心模块的单元测试覆盖率不能低于一个合理的数值，比如70%。并且所有单元测试必须能通过。



• 集成测试/系统测试报告： 这份报告要详细记录测试过程、测试用例、发现的Bug和修复情况。最终结论必须是“所有用例通过，无遗留严重Bug”。
• 性能测试报告（如果需要）： 比如要求系统支持1000个并发用户，平均响应时间在2秒以内。这些指标要量化，不能写“系统运行流畅”。

4. 培训和知识转移

项目做完了，不能就扔给你跑路了。对方有责任教会你的人怎么用、怎么维护。

• 培训材料： PPT、操作手册、视频教程等。
• 培训过程： 安排几次培训？每次多长时间？是线上还是线下？
• 知识转移会议： 核心开发人员需要和你的技术团队开个会，把系统的关键设计、可能出问题的地方、怎么排查问题，都讲清楚。这个会议最好有记录，双方签字确认。

第二步：功能验收，得有“尺子”去量

这是最容易吵架的地方。你说“这个按钮不好用”，他说“这个按钮的功能是实现了的”。怎么算“好用”？怎么算“实现了”？

唯一的办法，就是把需求变成一把“尺子”，一把可以精确测量的尺子。这把尺子，就是验收测试用例（Acceptance Test Cases）。

1. 以需求文档为蓝本，逐条拆解

合同里必须明确，验收的依据是哪一份需求文档（比如PRD）。然后，要把这份文档里的每一条需求，都翻译成一个或多个可测试的场景。

别用“用户登录”这种模糊的词。要用“用户输入正确的用户名和密码，点击登录按钮，系统应跳转到首页”这种描述。前者是需求，后者是测试用例。

2. 引入“用户故事”和“验收标准（AC）”的概念

这是个特别好用的方法。一个用户故事（User Story）通常这样写：“作为一个【角色】，我想要【功能】，以便于【商业价值】”。

然后，针对这个故事，列出它的验收标准（Acceptance Criteria），也就是“给定-当-那么”（Given-When-Then）格式。

举个例子：

• 用户故事： 作为一个注册用户，我想要通过邮箱和密码登录，以便于访问我的个人中心。
• 验收标准1（成功场景）：
  • 给定：用户在登录页面
  • 当：用户输入已注册的正确邮箱和密码，点击“登录”按钮
  • 那么：系统应验证通过，并跳转到用户个人中心首页
• 验收标准2（失败场景）：
  • 给定：用户在登录页面
  • 当：用户输入错误的密码，点击“登录”按钮
  • 那么：系统应提示“用户名或密码错误”，并停留在登录页面

你看，这样写下来，是不是就非常清晰了？没有任何歧义。到时候验收，就拿着这份用例，一条一条地测。通过了就打勾，没通过就打叉。简单粗暴，非常有效。

3. UI/UX的验收标准

界面好不好看，好不好用，这个主观性很强。怎么量化？

• 像素级还原设计稿： 在合同里明确，所有页面必须100%还原UI设计师提供的高保真原型图（比如Figma, Sketch, Axure文件）。可以允许1-2像素的误差，但整体布局、颜色、字体大小、间距必须一致。
• 浏览器和设备兼容性： 明确需要支持哪些浏览器（Chrome, Firefox, Safari的最新两个版本）和哪些设备（iPhone 12+, 主流安卓机型）下的表现。
• 交互响应： 比如，点击按钮后，loading状态的显示时间不能超过0.5秒；表单提交后，成功或失败的提示要在1秒内出现。这些都可以用工具测量。

第三步：非功能需求，别让它成为“隐形炸弹”

功能做好了，系统一上线就崩，谁也受不了。性能、安全、稳定性这些“非功能需求”，往往是项目成败的关键。这些标准也必须量化。

1. 性能指标

别写“系统要快”。怎么算快？

指标	要求	测量场景
并发用户数	支持500个用户同时在线操作	模拟500个用户同时进行核心业务操作（如下单、查询）
平均响应时间	95%的请求在2秒内返回	在正常负载下，测量关键API接口的响应时间
资源占用	4核8G内存的服务器，CPU使用率不高于70%	在达到并发要求时，监控服务器资源

2. 安全性要求

安全是底线。可以要求对方提供一份安全扫描报告，或者明确以下要求：

• 代码安全： 不能有SQL注入、XSS跨站脚本等OWASP Top 10的漏洞。
• 数据安全： 用户密码必须加密存储（比如bcrypt），敏感信息（如身份证号、手机号）在数据库中需要脱敏或加密。
• 权限控制： 必须有严格的认证和授权机制，确保用户A不能访问用户B的数据，普通用户不能访问管理员后台。

3. 可维护性和扩展性

这点是为了以后着想。虽然有点虚，但也可以提一些具体要求：

• 日志规范： 系统必须有完善的日志记录，包括操作日志、错误日志、访问日志。日志级别要清晰，格式要统一（比如JSON），方便接入ELK等日志分析系统。
• 配置管理： 所有环境相关的配置（数据库地址、密钥、第三方服务key等）必须从代码中剥离出来，通过配置文件或配置中心管理，不能硬编码在代码里。

第四步：验收流程和“Bug”那些事儿

标准定好了，接下来就是怎么走流程。这部分是合同的“程序法”，规定了大家按什么顺序、什么规则来办事。

1. 验收阶段划分

一个项目通常不会等到最后才验收。可以分成几个阶段：

• 里程碑验收： 比如项目分三期，每期做完，先验收这一期的交付物和功能。没问题了，再付这一期的钱，然后开始下一期。
• 初验（Alpha测试）： 开发环境交付。甲方在乙方的服务器上，或者在乙方的协助下，在甲方的测试环境进行验收。主要验证功能是否实现。
• 试运行（Beta测试）： 部署到生产环境，但只对小部分真实用户开放。主要验证在真实场景下的稳定性和性能。
• 终验（Final Acceptance）： 试运行一段时间（比如1-2周）后，如果没有重大问题，就进行最终验收。终验通过，意味着项目基本结束，进入质保期。

2. Bug的定义和处理流程

“Bug”这个词太宽泛了。一个拼写错误是Bug，一个系统崩溃也是Bug。必须给Bug分级。

• 致命（Critical）： 导致系统崩溃、数据丢失、主要功能完全不可用。例如：用户无法登录、支付流程中断。
• 严重（Major）： 主要功能有重大缺陷，但不影响核心流程。例如：查询结果不正确、导出的Excel文件数据错乱。
• 一般（Normal）： 次要功能有缺陷，不影响使用。例如：页面某个图标不显示、错别字。
• 轻微（Minor）： 界面UI问题，不影响功能。例如：按钮颜色偏差、间距不对。

合同里要写明：验收期间，发现多少个“致命”或“严重”级别的Bug，验收就不通过，必须返工。而“一般”和“轻微”的Bug，可以允许在一定数量内（比如不超过10个），或者要求在质保期内修复。

3. 验收报告和签字

每一步验收，都必须有书面记录。最好的形式就是一份《验收报告》。

报告里包含：验收日期、验收内容、验收人员、验收结果（通过/不通过）、发现的问题清单、双方签字盖章。

记住，签字就意味着认可。一旦签字，再发现问题，性质就不一样了。所以，甲方一定要认真测试，别当“甩手掌柜”。

第五步：一些“防坑”的补充条款

合同是死的，人是活的。总有些情况是合同里没写到的。这时候，一些兜底条款就显得尤为重要。

1. 源代码 escrow（第三方托管）

这是个很重要的条款，特别是对于那种长期运营的核心系统。简单说，就是把最终的源代码交给一个中立的第三方机构（比如律师事务所或专门的托管公司）保管。

触发条件通常是：外包公司倒闭、破产、或者连续几个月联系不上、拒绝提供后续维护服务。一旦触发，甲方有权从第三方那里拿到源代码，自己找人维护。这就相当于给你的项目上了一份保险。

2. 知识产权归属

这个必须写得明明白白。通常情况下，项目开发过程中产生的所有代码、文档、设计成果的知识产权，在甲方付清全款后，完全归甲方所有。乙方只保留为甲方展示案例的权利。

要特别注意，乙方不能在代码里埋“后门”或者“定时炸弹”，也不能夹带任何第三方的、有版权纠纷的代码。

3. 验收不通过怎么办

如果多次验收都不通过，怎么办？合同里要给出解决方案。

• 整改期限： 给乙方一个明确的整改期限，比如15个工作日。
• 违约金： 如果逾期交付，每天按合同总额的千分之五支付违约金。
• 终止合同： 如果整改后还是不行，或者逾期超过一定天数（比如30天），甲方有权单方面终止合同，并要求乙方退还已付款项，赔偿损失。

把这些条款写清楚，不是为了为难乙方，而是为了让双方的合作有一个清晰的边界和预期。好的合作，都是建立在规则明确的基础上的。

写合同确实是个细致活，甚至有点枯燥。但当你把所有可能的歧义、所有模糊的地带都用清晰的文字定义清楚后，你会发现，整个项目推进起来会顺畅得多。这不仅是对项目负责，也是对双方合作关系的保护。

跨国社保薪税