如何验收软件开发项目，客户能拿到什么

验收软件开发项目，就是确认产品已在生产环境中按您的真实场景运行，并拿到独立掌控产品所需的一切：源代码及其权利、产品结构与发布方式的说明、各项访问权限、故障告警和备份。交付内容和验收流程最好在开工前写进合同。按部分分批验收，比项目结束时一次性交付更稳妥。

什么是验收，为什么要提前考虑

软件项目验收，是客户检查成果并确认已拿到约定内容的环节。实际上它不是签一个字就结束，而是一组检查：产品能正常运行，数据完好，访问权限在您手里，后续接手的团队即使没有原作者也能看懂代码。

最常见的错误是到最后一天才想起验收。这时往往发现：源代码放在开发者的个人账号里，服务器登记在外包方名下，发布新版本的说明根本不存在。上线后再补救，比一开始就约定清楚更费时，也更费钱。

因此，验收标准应当在需求文档阶段就写明：哪些场景必须可用，在哪些设备和平台上，什么算完成。具体写法可参考如何准备软件需求文档。

客户能拿到什么

交付内容因项目而异，但无论是 Telegram 机器人、AI 智能体还是应用，基础内容都相同。在 JEEKSSHIRE 24，客户最终拿到以下内容（与软件定制开发页面上的描述一致）：

• 在生产环境中运行的产品——不是开发者笔记本上的演示，而是真实用户正在使用的版本；
• 源代码及其权利；
• 产品结构与发布方式的说明：系统由哪些部分组成，各部分在哪里，如何构建并发布新版本；
• 已配置好的故障告警和备份。

交付条件——交付什么、何时交付、以何种形式交付——在开工前通过合同确定。此后的维护与迭代按双方约定进行。

交付什么，为什么需要

交付中的每一项都对应一个具体风险。可以用下表核对是否遗漏：

源代码交付与代码归属

只交代码不交权利，等于只完成了一半交付。您可能实际拿到了代码，却无权修改它，也无权在其他产品中使用。因此合同里应当写清楚：工作成果的权利归谁，何时转移，范围多大。

在 JEEKSSHIRE 24，代码归客户所有：与产品一起交付的有源代码、代码权利，以及产品结构与发布方式的说明。相关条件在开工前通过合同确定。

第三方组件值得单独讨论：开源库、字体、付费服务和外部 API。它们按各自的许可协议使用，这很正常，但最好事先清楚哪些是专门开发的，哪些是接入的。法律措辞属于律师的专业范围：不同国家关于权利转让的规定各不相同，合同最好请熟悉适用法律的专业人士审阅。

代码最好以带有完整修改历史的代码仓库形式交付，而不是一个压缩包。修改历史能说明改了什么、为什么改，对下一个团队很有帮助。

访问权限与密钥：放在代码之外

密钥包括数据库密码、支付和邮件服务的密钥、机器人令牌以及各类 API 密钥。正确的做法是把它们放在代码和代码仓库之外：放在服务器的环境配置中，或放在专门的密钥管理工具里。一旦密钥写进代码，任何拥有仓库副本的人都能拿到，而且它会一直留在修改历史中。

在 JEEKSSHIRE 24，把密钥放在代码和仓库之外，不是交付前的一个单独步骤，而是对每一次修改的要求。我们自己的产品也是这样做的。

访问权限要检查什么

• 域名、主机、云服务、应用商店和支付服务的账号登记在客户名下，或已转交给客户；
• 产品运行所依赖的一切，您都有管理员权限；
• 代码仓库中没有密码和密钥；
• 交接后，凡是被外人看到过的密钥都已更换；
• 有一份清单：每个服务负责什么，配置放在哪里。

发布前检查：闸门变红，就不发布

每次部署前，产品都应通过自动检查：构建、代码规范检查（lint，检查代码错误和统一风格）以及测试。只要有一项未通过，闸门就是红色的，无论多紧急都不发布。

这一点在验收时和验收后都很重要。验收时，您拿到的不只是代码，还有一套安全发布新版本的方法：检查项有文档说明，一条命令就能运行。验收后，任何接手开发的团队都按同样的规则工作，不会把有问题的构建部署上线。

验收时，可以请对方现场演示一次发布：运行检查，看到全部通过，再完成部署。这花不了多少时间，却能立刻看出流程在没有原作者的情况下能否复现。

分批验收，而不是最后一次性交付

大型产品最好分部分验收，而不是在最后签一次字了事。把任务拆成可以单独演示和检查的部分，您在项目进行中就能看到可用的成果，也可以在各部分之间调整优先级。

JEEKSSHIRE 24 就是这样工作的：包含核心场景的第一个版本先上线，其余功能在后续版本中陆续发布。参考我们页面上的时间范围：Telegram 机器人或小型自动化通常需要一到几周，AI 智能体的第一个可用版本需要几周，独立应用则需要几个月起。更多关于周期的内容见应用开发需要多长时间，关于第一个版本见最小可行产品：从哪里开始。

每个部分都应事先约定什么算完成：哪些场景可用，用什么数据检验，客户方由谁负责验收。这样最终验收就只是走个流程，因为主要内容早已检查过。

软件项目验收清单

可以以下面的清单为基础，再根据自己的产品补充：

1. 对照合同和需求文档检查成果：验收标准中的所有场景是否都能正常运行。
2. 在生产环境中亲自走一遍核心场景，使用产品所面向的真实设备和平台。
3. 如果产品支持多语言，逐一检查每种语言，包括阿拉伯语的从右到左布局。
4. 以带修改历史的代码仓库形式接收源代码，并确认访问权限在您手里，而不只在开发方手里。
5. 确认代码权利按合同约定转移给您。
6. 接收产品结构与发布方式的说明。
7. 请对方演示一次新版本发布：构建、代码规范检查和测试全部通过，部署顺利完成。
8. 检查访问权限：域名、服务器、云服务、应用商店和支付服务都在您名下。
9. 确认代码和仓库中没有密钥，已泄露的密钥都已更换。
10. 检查故障告警：发给谁，多快能收到。
11. 检查备份：存放在哪里，多久备份一次，如何从备份恢复。
12. 约定上线后的维护方式。

上线后的维护

上线并不意味着项目结束。产品需要更新、修复和持续迭代：操作系统在变，应用商店规则在变，外部服务在变，您自己的业务流程也在变。如果没有事先约定维护方式，第一次故障就会变成临时四处寻找愿意接手陌生代码的人。

在 JEEKSSHIRE 24，我们会配置监控、故障告警和备份，让您从我们这里得知问题，而不是从客户那里；同时与您约定维护方式。同一支团队也在生产环境中运营自己的产品——Wallet 和 Legal——所以监控和更新对我们来说是日常工作，而不是额外负担。

如果想讨论项目以及验收方式，请在申请表中用自己的话描述任务，不需要现成的需求文档。其他常见问题的解答汇总在问答页面。

用户验收测试（UAT）：由谁来检查，怎么检查

用户验收测试（UAT，user acceptance testing）是从实际使用者的角度检查产品。开发团队在上线前检查代码和流程，而 UAT 回答的是另一个问题：产品在实际工作中能否解决客户的问题。

要让这项检查有成效，需要提前准备：

1. 指定客户方的测试人员：每天都会使用产品的人，而不只是项目负责人。
2. 根据验收标准整理场景清单：用户做什么，期望得到什么结果。
3. 准备环境和数据：测试版本，或带有接近真实示例的独立系统副本。
4. 在产品面向的设备和平台上测试，包括每一种界面语言。
5. 逐个场景记录结果：通过、未通过，具体哪里出了问题。

对于移动端和桌面应用，UAT 通常在上架应用商店之前，用测试版本进行。这是 移动应用开发 流程的一部分：客户在自己的设备上检查测试版本，提交到商店的是已经验收的版本。

问题反馈、验收单与阶段收尾

测试结束后，会留下一份问题清单。为了不让验收变成没完没了的修改，需要先给问题分类：

• 缺陷：产品没有满足约定的验收标准。在本阶段内修复。
• 新需求：想修改的内容不在原先的约定中。需要单独评估和安排。
• 阻断性问题：不修复就无法使用产品。非阻断性问题经双方同意，可以在下一个版本修复。

当不再有阻断性缺陷时，用验收单来结束这个阶段：双方在这份文件中确认，工作已按约定完成。如果项目分部分进行，每个部分各签一份验收单。验收单中也会写明哪些非阻断性问题顺延到下一个版本。

验收之后发现的错误如何处理，最好提前写进合同：由谁修复、在什么时限内、后续工作以什么方式继续。这通常属于上线后的 软件运维与升级。