📍 WDQWDWQD987AAAAA:216.73.216.49
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c294b29ea562.html
📄

WordPress搬家，需求清单应该写到什么程度，多人协作才不返工

需求清单要写到“另一个人拿着它就能独立执行、不用再问你”的程度。具体来说，搬家涉及的每个对象都要有明确来源、目标、处理方式和验收标准，而不是只写一句“把网站迁到新服务器”。多人协作时，清单的价值不在于写得长，而在于把容易扯皮的地方提前定死。

先看一个假设例子：清单太粗会怎么返工

假设一个团队要把公司官网从旧主机迁到新主机，成员包括运维、前端和内容编辑。最初的需求清单只有三条：备份网站、上传到新服务器、改域名解析。执行时问题会集中出现：

• 运维只备份了数据库，没备份上传目录，前端发现图片全部丢失。
• 前端在新环境测试时发现固定链接 404，但没人负责伪静态规则。
• 内容编辑不知道旧站的草稿和回收站要不要保留，只能全部搬过去，结果新站多出几百条无用内容。
• 域名解析改了，但旧站没有保留只读入口，市场部投放的链接全部失效。

这些返工不是因为技术难，而是因为清单没有回答“搬什么、搬到哪、谁来做、怎么算完成”。

需求清单必须写清的六类信息

每一条搬家任务，至少包含下面六项，缺一项就可能在协作中变成口头补充：

1. 对象：具体是数据库、主题文件、插件、上传目录、配置文件，还是定时任务。
2. 来源：旧环境的路径、数据库名、表前缀、账号由谁提供。
3. 目标：新环境的对应位置，域名是否变化，路径是否保持一致。
4. 处理方式：直接复制、导出导入、替换域名、还是重新安装。
5. 负责人：谁执行、谁复核，避免“大家都以为对方会做”。
6. 验收标准：打开哪个页面、检查什么现象、达到什么结果才算通过。

以“替换域名”为例，合格写法是：由运维在数据库导出文件中，将旧域名统一替换为新域名，替换后由前端检查首页、文章页、图片和后台登录页是否正常加载。不合格写法是：把域名改一下。

哪些内容可以简写，哪些不能省

清单不是越细越好。以下内容可以简写：

• 通用操作步骤，例如“使用导出工具导出数据库”，执行人具备基本技能时不必展开每个点击动作。
• 临时沟通安排，例如拉群、开会时间，这些不属于搬家需求本身。
• 与本项目无关的通用安全建议，例如“定期改密码”，可以放到团队规范里，不必塞进本次清单。

以下内容不能省：

• 旧站是否还要继续访问，以及保留多久。
• 数据库表前缀是否变化，变化后配置文件同步修改。
• 固定链接结构是否保持，伪静态规则由谁负责。
• 邮件发送、支付回调、第三方接口中写死的旧域名或旧路径。
• 搬家后的回滚方式：出问题时恢复到哪个时间点、由谁决定回滚。

用检查项代替模糊描述

把“确保网站正常”改成可执行的检查项，协作效率会明显提高。例如：

• 首页返回状态码 200，页面样式与旧站一致。
• 随机打开三篇不同分类的文章，正文和图片均正常显示。
• 后台可以登录，能新建一篇草稿并删除。
• 表单提交后，指定收件邮箱能收到通知。
• 旧域名访问时，按约定跳转到新域名对应页面，而不是全部跳首页。

检查项要写清判断结果：通过就进入下一步，不通过就记录现象、交给对应负责人，不带着问题继续改解析。

多人协作时的交接写法

清单里最好给每条任务加一个状态字段，例如“待处理、进行中、待复核、已完成”。交接时只传当前状态和阻塞原因，不靠聊天记录回忆。涉及账号密码时，用团队约定的密码管理方式传递，不写在清单正文里。

如果旧站历史服务或旧插件已经不再维护，不要在清单里写“按原来位置找入口”，而应写成：先确认该功能当前是否仍可用，不可用则记录替代方案，由负责人确认后再决定是否迁移。这样写不会把过去的界面位置当成今天仍然有效的事实。

下一步，把现有清单逐条对照“对象、来源、目标、处理方式、负责人、验收标准”六项，缺哪项就补哪项；补完后交给另一位执行人试读，凡是需要再问你才能动手的条目，都继续改到不需要问为止。