本文约 4,623 字，预计阅读 12 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：”做个高大上的官网”，然后三个月都在返工
建站项目里最贵的一句话是”你先做，做完我看看”。这句话的代价是：第一版做出来风格不对，推翻重做；第二版功能缺了，临时加需求导致工期翻倍；第三版发现手机上排版错乱，因为需求里从没提过移动端要求；最后验收时甲方说”感觉差点意思”，乙方说”你说的我都做了”，双方都不满意。
需求文档的作用不是”写得好看”，而是把模糊的期待变成可验证的条目。一份合格的需求文档应该做到：任何一个第三方开发者读完，都能给出准确的报价和工期；项目结束时，甲乙双方能拿着同一份文档逐条打勾验收，不需要靠”感觉”。
无论是给外包用，还是自己做站，这份文档都值得写——自己做站时它同样能防止你中途不断加需求，把项目拖成烂尾。
原理分析：需求文档要解决的三类歧义
第一类：范围歧义（Scope）。 “要有个产品展示”到底是 3 个产品还是 300 个？”要能留言”是只要一个表单，还是要带后台管理、邮件通知、验证码、数据导出？范围不清导致报价差异可达数倍。
解决方法：功能清单必须带量词和边界。 写成”产品展示：支持 50 个以内产品，每个产品含 5 张图片 + 参数表格”，而不是”产品展示功能”。
第二类：质量歧义（Quality）。 “速度快一点”是多快？”适配手机”是哪些机型？质量不可度量就无法验收。
解决方法：所有质量要求数字化。 写成”移动端 PageSpeed Insights 分数 ≥ 70 分””兼容 Chrome/Edge/Safari 最近两个大版本””首页首屏加载 ≤ 2 秒（4G 网络）”。
第三类：责任歧义（Responsibility）。 内容谁填？图片谁拍？服务器谁买？域名谁备案？这些不在”开发”范围内的事最容易被忽略，最后互相推诿。
解决方法：文档里单列”双方分工表”。
需求的优先级划分（MoSCoW 法）：
| 级别 | 含义 | 处理方式 |
|---|---|---|
| Must（必须有） | 没有就不算完成 | 一期必须交付 |
| Should（应该有） | 重要但可延后 | 二期或上线后补 |
| Could（可以有） | 锦上添花 | 排期允许再做 |
| Won’t（本期不做） | 明确排除 | 写清楚不做，避免后期争议 |
“Won’t”这一列极其重要——把”本期不做的功能”白纸黑字写下来，比写”要做什么”更能防止纠纷。
保姆级实操：六个模块的完整模板
模块 1：项目背景与目标。 用三句话说清楚为什么做这个站、给谁看、成功的标准是什么。
## 1. 项目背景与目标
**业务背景**：公司主营工业自动化设备，目前获客依赖展会与销售拜访，
缺少线上传播载体，客户搜索品牌名时无官方信息。
**目标用户**：
- 主要：制造业采购负责人（35-50 岁，PC 端为主，关注资质与案例）
- 次要：行业工程师（25-35 岁，移动端为主，关注技术参数）
**成功标准（可量化）**：
- 上线 3 个月内，品牌词搜索结果首页出现官网
- 每月通过官网表单获得的销售线索 ≥ 20 条
- 移动端首屏加载 ≤ 2 秒
模块 2：站点结构与页面清单。 用树状结构列出所有页面，标注模板类型和数量：
## 2. 站点结构
- 首页（唯一，自定义模板，含 Banner 轮播 3 张 + 核心业务入口 + 案例展示 6 条）
- 关于我们（单页，静态内容）
- 产品中心
- 产品分类页（分类归档模板，8 个分类）
- 产品详情页（自定义文章类型 `product`，首期录入 50 个产品）
- 解决方案（列表 + 详情，8 篇）
- 新闻中心
- 列表页（分页，每页 10 条）
- 详情页（标准文章模板）
- 联系我们（含地图、表单、各分公司信息）
- 搜索页 / 404 页 / 站点地图页
**说明**：全站共 6 个页面模板，页面总数量约 90 个（含动态生成）
模块 3：功能需求清单（带优先级）。 这是文档的核心，逐条可打勾：
## 3. 功能需求清单
| 编号 | 功能 | 详细说明 | 优先级 | 验收方式 |
|---|---|---|---|---|
| F-01 | 响应式布局 | 兼容 375px / 768px / 1440px 三档断点 | Must | 三档宽度下无横向滚动条 |
| F-02 | 产品管理 | 自定义文章类型，字段含：产品名、型号、参数表、5 张图、PDF 手册 | Must | 后台可新增并前台展示 |
| F-03 | 产品筛选 | 按分类 + 2 个自定义参数筛选，AJAX 无刷新 | Should | 筛选结果正确且无需刷新 |
| F-04 | 表单 | 联系表单含姓名/电话/公司/需求，提交后发邮件通知 + 后台可查 | Must | 提交后 1 分钟内收到邮件 |
| F-05 | 表单防刷 | 图形验证码 + 同一 IP 60 秒限一次 | Must | 连续提交被拦截 |
| F-06 | 多语言 | 中英文切换，人工翻译 | Won't | 本期不做，URL 结构预留 |
| F-07 | 在线客服 | 接入第三方客服系统 | Could | 提供嵌入位置 |
| F-08 | 站内搜索 | 支持标题与正文全文检索 | Should | 关键词返回正确结果 |
| F-09 | PDF 下载 | 产品详情页可下载手册，需登录或填表后下载 | Could | — |
| F-10 | 数据看板 | 后台显示表单提交量趋势 | Won't | 本期不做 |
模块 4：技术与非功能需求。 这一块决定了技术方案和可维护性：
## 4. 技术需求
**运行环境**
- 服务器：2 核 4G，CentOS/Rocky 或 Ubuntu 22.04，Nginx + PHP 8.1+ + MySQL 8.0
- 域名与备案：甲方提供已备案域名
- CDN：静态资源接入 CDN
**技术选型**
- CMS：WordPress 最新版，使用子主题开发，禁止修改核心与父主题文件
- 页面构建：使用区块编辑器（Gutenberg），禁止使用页面构建器锁定内容
（避免出现"换主题后内容不可用"的情况）
- 自定义字段：使用 ACF（Advanced Custom Fields）或原生自定义字段
- 表单：使用 Fluent Forms 或 WPForms（提供后台数据查看与导出）
**性能要求**
- 首页首屏加载 ≤ 2 秒（4G 网络、PageSpeed Insights 移动端 ≥ 70 分）
- 启用页面缓存、浏览器缓存、Gzip/Brotli 压缩
- 图片统一输出 WebP，单张 ≤ 200 KB
**SEO 要求**
- URL 结构：`/产品分类/产品别名/`，全站小写、英文或拼音
- 每个页面可自定义 SEO 标题与描述
- 自动生成 XML 站点地图，提交至百度与 Google
- 结构化数据：企业信息（Organization）、面包屑（BreadcrumbList）
**安全要求**
- 全站 HTTPS，HTTP 301 跳转
- 后台登录限制尝试次数，管理员账号启用双因素认证
- 每日自动备份，备份保留 14 天，异地存储
模块 5：内容与设计素材分工表。 明确谁提供什么：
## 5. 双方分工
| 事项 | 负责方 | 交付时间 | 备注 |
|---|---|---|---|
| 域名与服务器 | 甲方 | 项目启动前 | 需完成备案 |
| 文案（全站中英文） | 甲方 | 第 2 周前 | Word 文档，按页面组织 |
| 产品图片与参数 | 甲方 | 第 3 周前 | 每产品 5 张图，≥1200px |
| 企业资质扫描件 | 甲方 | 第 3 周前 | — |
| 视觉设计稿 | 乙方 | 第 2 周末 | 提供 Figma 源文件 |
| 前端与后端开发 | 乙方 | 第 5 周末 | — |
| 内容录入 | 乙方 | 第 6 周 | 录入首期 50 个产品 |
| SSL 证书与 HTTPS | 乙方 | 上线前 | 使用 Let's Encrypt |
| 上线与培训 | 乙方 | 第 7 周 | 提供 1 次线上培训 |
模块 6：验收标准与交付物。 与 网站验收清单 配套：
## 6. 验收标准与交付物
**交付物清单**
- [ ] 网站源码（含子主题、自定义插件），交付至甲方指定的 Git 仓库
- [ ] 数据库导出文件
- [ ] 所有设计源文件（Figma）
- [ ] 第三方插件/主题的授权凭证（必须为甲方名义购买）
- [ ] 《网站后台使用手册》（PDF）
- [ ] 服务器环境配置文档
**验收方式**
- 依据第 3 节功能清单逐条测试，Must 项 100% 通过
- 依据第 6 节交付物清单逐项核对
- 验收期 7 个工作日，问题以书面清单形式提交，修改不超过 2 轮
**质保**
- 上线后 3 个月内免费修复 bug（不含新增需求与内容修改）
常见踩坑
- 用形容词代替需求。 “高大上””有科技感””简洁大气”无法执行。改成”参考以下三个站点的某某页面”并说明喜欢的具体元素。
- 没写”不做什么”。 后期甲方提出”这个应该有的”，乙方说”当时没说”。Won’t 列表能解决大部分争议。
- 忽略内容与素材的交付时间。 开发做完了，甲方文案还没写，项目卡一个月。分工表里必须有交付时间，且写明”延期 X 天则工期顺延 X 天”。
- 性能与兼容性没有量化标准。 “速度快””手机能看”这种描述无法通过验收。
- 不约定插件授权归属。 用乙方个人名义买的商业主题，第二年续费受制于人。要求甲方名义购买。
- 没提”可维护性”。 用页面构建器做的内容，换主题后变成一堆短代码。需求里应明确”内容以区块编辑器形式存储，不依赖特定构建器”。
- 案例：一次因需求模糊导致的三次返工。 客户是家设计公司，需求只有一句话：”做个能展示我们作品集的网站，要好看。”第一版乙方按常规企业站做，被否（”太模板”）；第二版做了全屏滚动特效，被否（”太花哨，找不到作品”）；第三版改成了瀑布流布局，甲方又说”跟竞品太像”。三次返工耗时两个月。复盘时发现，甲方心里有三个明确的参考要求（作品要大图、要有筛选、要能一键分享），但从没说过。后来补了一份需求文档，把这三个点写成 Must 项，两周就验收通过了。教训：甲方说不清需求时，乙方要主动用”参考站点 + 具体元素”的方式引导——给他看 10 个站点，让他指出喜欢哪几个的哪一部分，比让他凭空描述有效得多。
总结
需求文档的价值在于”把不可验证的期待变成可打勾的条目”。判断标准：任何一个第三方开发者读完这份文档，能否在不追问的情况下给出报价和工期？ 如果能，说明文档合格。写作时守住三条：功能带量词和边界、质量带数字、责任带名字和日期；别忘了写”本期不做什么”。文档定稿后甲乙双方签字确认，后续所有变更走”需求变更单”，写明影响与费用。写好需求之后，项目交付阶段可以直接对照 客户项目交付注意事项，验收环节则可以复用 网站验收清单 里的逐项核对表。
