11｜怎样把项目交出去，并保证别人能运行？

本章任务：让甲方换个地方也能用上项目，出了问题知道怎么恢复。
准备材料：现在能用的代码、你试过的结果、甲方准备放项目的电脑或服务器。
本章产出：一份照着能启动的说明、一份检查记录，以及备份和后续处理办法。

交付不是发一个压缩包

图解：交付需要可复现的运行说明。 查看大图

你把压缩包发给甲方，说「双击启动就行」。甲方试了，页面打不开。你才想起来：还要装一个程序、填数据库密码，而且数据只存在你的电脑上。

在你电脑上能跑，只说明你电脑上的东西凑齐了。 甲方并没有你的那些设置，也不知道少了什么。你的电脑一关，项目可能就不能用了。

交付，就是把约好的项目真正交到甲方手里。除了代码，还得让他知道怎么启动、怎么看出正常、坏了找谁，以及数据怎么找回来。

第一步：把运行条件写成可核对清单

先说清部署。部署就是把项目装到实际使用的地方，让别人能打开。比如你在自己电脑上写完报名系统，把它放到甲方的服务器上，这就是一次部署。

不要写「安装相关环境」这种只有你自己看得懂的话。把需要装什么、用哪个版本、先执行哪一步、最后打开哪个地址写清楚。

需要说明	活动报名与审核系统的核对点
要装什么	程序名称、版本、安装和启动方法
要填什么设置	哪些必须填，从哪里拿；示例不放真密码
数据放哪	数据库和上传文件在哪里，第一次怎么准备
要连什么服务	比如甲方已有的登录服务是否可访问
出错看哪里	日志，也就是程序运行时留下的记录；比如登录失败的原因
平时怎么操作	怎样启动、停止、检查、备份和恢复

拿一台没有你私人设置的测试电脑，或者重新准备一套测试用的安装位置，照说明走一遍。哪里还得靠你临时补一句，就把那一句写进去。

第二步：把密钥与普通配置分开

密钥就是让程序访问某项服务的秘密凭证，作用有点像密码。比如调用付费接口时用的那串字符，拿到它的人可能花掉你的额度。

配置，就是程序运行前要填的设置。网站名称可以公开，数据库密码不行。公开示例可以写「这里填密码」，不能填真实值。

检查代码、截图、日志和打包后的文件里有没有秘密。你以为密码只写在本机，结果它被一起打包发出去了，也算泄露。

测试和正式使用尽量不要共用密码。真泄露了，要撤销或换掉；只把文件里的文字删掉，已经拿到的人照样能用。也别让甲方的项目长期依赖你的私人账号。

第三步：先在隔离环境演练数据迁移

数据迁移，这里指为了新功能调整原来的数据存法。比如报名表要加一个「取消时间」，旧记录没有这个内容，该填什么就得先想好。

隔离环境就是单独准备、不会碰到真实报名的测试地方。先在那里试：旧记录还能不能打开，原来没填的内容会不会报错，两条相同记录会怎样。

别为了让修改成功，直接把旧数据清空。那只能说明空表能用，证明不了甲方已经积累的几千条记录还能用。

把代码换回旧版，不会让数据库自动变回原样。 旧版也可能看不懂新版写下的状态。反过来，把数据库恢复到昨天，又会丢掉今天新报名的人。

先写清楚要先改数据还是先换程序、失败后怎么办。会暂停使用多久，也要提前告诉甲方，不能操作到一半才说网站暂时打不开。

第四步：备份之后，真的恢复一次

图解：恢复旧备份可能丢失之后新增的数据。 查看大图

这就像备份手机照片。软件显示「备份完成」，不代表换台手机后每张照片都能打开。文件可能没传全，也可能忘了密码。

所以别只看「备份成功」四个字。把一份备份放到独立测试位置恢复出来，真的打开记录、查看名单和文件，才能知道它有没有用。

恢复练习不要覆盖甲方正在用的数据。 原数据和唯一备份也别放在同一块容易一起丢失的地方。

恢复演练记录	应记录的结果
这份备份是哪天的	比如昨天晚上，不能只叫「最新备份」
恢复到哪里	写清测试位置，别弄错成正式数据库
恢复后查了什么	报名数量、审核结果、所属活动和文件
一共花了多久	从开始准备到主要功能能用
哪些数据找不回来	比如备份完成之后的新报名，要怎么补救

跟甲方说明实际结果：最多可能停多久、可能丢哪段时间的数据。没有真试过，别随口保证「五分钟肯定恢复」。

第五步：按清单发布，并设置停止条件

图解：代码回退与数据恢复分别评估。 查看大图

发布，就是把准备好的新版本换到实际使用的网站上。比如原来没有取消功能，现在把带取消功能的版本换上去。

换之前，核对到底是哪一版、设置是否齐全、备份能不能恢复、哪些操作需要甲方同意。把发布前能用的版本留住，别现场顺手升级别的东西。

仅作为示例，不建议作为实际项目中的提示词使用。

请根据我提供的项目资料，列出换上新版本之前、换的过程中、换完之后分别要做什么。每一步写清怎么确认成功，出现什么情况要停，怎样恢复原来的可用状态。先只整理，不操作。没做过的备份和测试不能写成完成；缺资料就指出来。代码怎么换回去、数据怎么恢复，请分开讲，并提醒是否会丢掉新增报名。

比如新版本启动不了，或者报名保存失败，就按事先说好的办法停下来处理。别一边影响真实使用，一边让 AI 随机改十几个地方。

第六步：在目标环境做发布验收

验收就是核对「做到什么样算合格」。比如甲方在实际网址提交一次报名，刷新后还能看见，再从后台审核，报名端能看到新结果。

你在测试电脑上试过，到甲方实际用的地方仍要试。设置、网络和账号不同，结果可能就不一样。

除了正常报名，还要试没有权限的账号能不能偷看名单、报错后有没有乱保存。检查用的数据要标明是测试记录，并按约定清理，别混进真实名单。

把通过、没通过和甲方接受暂缓的问题分别记下。换完之后再观察一段约好的时间：有没有报错、变慢、重复报名。程序没退出，不代表业务一定正常。

第七步：交代后续维护

维护就是项目交出去后，继续处理故障和必要更新。比如网站突然登不进去，或者证书到期导致打不开，都得有人知道该找谁。

写清楚问题发到哪里、要带什么截图和操作步骤、哪些修改包含在约定里。新增功能要另外讨论，不能把「修一下」无限扩大成重做项目。

再列清单：代码或约好的文件、启动说明、设置说明、数据修改步骤、备份恢复方法、使用说明、已知问题。秘密凭证另按约好的方式交接。

域名、证书、外部服务额度什么时候到期，也要记下来。别等甲方网站停了，才发现付款账号一直是你的。

练习：发布后新增字段读取失败

假设新版本写下了旧版不认识的报名状态。新版本出错后，你换回旧版，旧版也报错了。发布前应该怎样试，才能提前知道这件事？

如果昨晚备份以后又来了 20 条报名，直接恢复昨晚的数据会怎样？写清楚哪些能恢复，哪些可能丢失，再看看你的项目是否也有同样问题。

完成检查

• [ ] 换个没有私人设置的地方，照说明也能启动。
• [ ] 数据改法已经用测试记录试过，知道失败怎么处理。
• [ ] 备份真的恢复过，知道需要多久、可能少哪些数据。
• [ ] 实际使用的网址上，主要功能和账号限制已经试过。
• [ ] 甲方知道哪些完成了、有哪些问题，以及以后找谁处理。

本章带走： 能让甲方用起来的项目和说明。下一章看看，除了把东西交出去，你自己到底学会了什么。