设计与网站项目最危险的验收方式，是把所有问题留到最后一天。此时客户可能突然推翻方向，供应商可能把“能打开”视为完成，双方对内容、移动端、后台、源码和维护边界也可能完全不同。
更成熟的做法是阶段验收：需求范围、结构与原型、视觉方向、全量设计、开发功能、上线环境和最终资产分别确认。每次确认都要对应可检查的成果和书面记录。
01 验收前先统一四个概念
概念 | 含义 |
|---|---|
阶段确认 | 确认某一阶段方向和范围，可进入下一阶段 |
测试 | 发现功能、兼容、性能、安全和内容问题 |
上线验收 | 确认正式环境满足约定，可对外发布或投入使用 |
最终交付 | 确认源文件、源码、账号、文档、培训和维护边界已移交 |
“客户看过”不等于“已经验收”，“上线”也不等于“所有资产已交付”。合同、需求确认书、报价单和阶段确认记录应形成一致证据链。
02 第一阶段：需求与范围验收
在设计开始前，验收的不是界面，而是双方对项目边界的理解。范围没有确认，后面的每一次修改都可能变成“原需求还是新增需求”的争议。
- □ 项目目标、目标用户和成功标准明确；
- □ 页面、模板、功能、语言和设备范围明确；
- □ 设计、开发、内容、拍摄、SEO和部署责任明确；
- □ 不包含项、第三方费用和外部依赖明确；
- □ 交付物、文件格式、源码和账号范围明确；
- □ 项目周期、客户反馈时间和延期规则明确；
- □ 修改轮次、方向重做和新增需求机制明确；
- □ 付款节点与各阶段验收成果对应。
03 第二阶段：信息架构与原型验收
原型验收重点不是颜色和字体，而是页面结构、用户流程、信息优先级和异常状态。这个阶段确认后再进入视觉，能显著降低后期推翻布局的成本。
检查项 | 验收问题 |
|---|---|
页面结构 | 导航、层级和页面关系是否覆盖需求？ |
关键任务 | 用户能否完成咨询、注册、购买、申请等核心任务？ |
内容优先级 | 首屏、标题、证据和CTA是否顺序合理？ |
角色与权限 | 不同用户看到和操作的内容是否正确？ |
状态完整度 | 空、加载、成功、失败、无权限和异常是否考虑？ |
移动端逻辑 | 小屏下导航、表格、表单和操作是否可用？ |
范围对应 | 原型页面和功能是否与需求清单一致？ |
04 第三阶段：视觉方向验收
视觉方向通常先通过首页或核心页面验证，不建议一开始做完全部页面。验收时要区分品牌方向问题与局部细节问题。方向确认后，后续页面基于该系统扩展；若重新选择完全不同方向，应按变更处理。
- □ 视觉是否符合已确认的品牌定位和受众；
- □ Logo、色彩、字体、图片和图形使用一致；
- □ 信息层级清楚，重点不依赖装饰表达；
- □ 关键CTA、表单和操作状态清晰；
- □ 对比度、字号、点击区域和键盘操作满足项目要求；
- □ 设计可在常见屏幕和内容长度下扩展；
- □ 使用的字体、图片、图标和素材授权可说明。
05 第四阶段：全量UI与设计系统验收
验收范围 | 具体标准 |
|---|---|
页面完整 | 页面清单、弹窗、空态、错误态和响应式版本齐全 |
组件一致 | 按钮、表单、导航、卡片、表格和反馈状态统一 |
内容适配 | 长短文案、数字、英文、多语言和真实数据可容纳 |
交互标注 | 悬停、点击、禁用、加载、动画和跳转说明清晰 |
开发可用 | 尺寸、间距、变量、组件和资源可被研发读取 |
文件管理 | 页面、组件、版本和命名清楚，无无效稿混入 |
资产导出 | 图标、图片、字体和动效文件按约定整理 |
06 第五阶段：开发功能验收
开发验收应基于测试环境、需求清单和验收用例，不应只在供应商演示时观看。客户应使用真实账号、真实内容和不同设备完成核心流程。
测试类型 | 重点 |
|---|---|
功能测试 | 每项功能、按钮、表单、流程和状态是否符合需求 |
角色权限 | 不同角色的数据与操作权限是否正确 |
兼容测试 | 约定浏览器、系统、分辨率和设备是否可用 |
响应式 | 桌面、平板、手机布局和交互是否正常 |
内容测试 | 真实文案、图片、附件和数据是否正确 |
接口测试 | 支付、邮件、CRM、地图、客服等是否成功与可恢复 |
异常测试 | 断网、重复提交、超时、失败和边界数据如何处理 |
回归测试 | 修复问题后是否影响其他功能 |
07 缺陷要分级，不要把所有问题混在一起
级别 | 示例 | 处理建议 |
|---|---|---|
P0 阻断 | 系统无法访问、核心数据丢失、严重安全问题 | 不得上线，立即处理 |
P1 严重 | 核心流程无法完成、支付/表单失败、主要设备不可用 | 上线前必须修复 |
P2 一般 | 非核心功能异常、局部兼容或明显视觉错误 | 约定时限修复 |
P3 轻微 | 细微间距、非关键文案或优化建议 | 可进入后续优化列表 |
新增需求 | 原确认范围外的新页面、功能或方向 | 变更评估，不作为缺陷 |
缺陷分级需要在项目中统一，表中只是通用参考。涉及安全、隐私、支付和数据的风险应由相应专业人员评估，不应仅由视觉验收决定。
08 网站上线前的内容与SEO验收
- □ 页面标题、描述、H1和正文与页面主题一致；
- □ 正式域名、HTTPS、canonical和重定向正确；
- □ robots.txt和站点地图符合索引计划；
- □ 旧站重要URL完成映射，避免大量404；
- □ 导航、面包屑、正文和相关推荐链接有效；
- □ 图片压缩、尺寸、alt和懒加载合理；
- □ 表单提交、感谢页和转化追踪正常；
- □ 社交分享标题、描述和图片正确；
- □ 测试页、演示内容和无效账号未公开；
- □ 搜索控制台、分析和错误监测已配置。
09 性能、可访问性与安全验收
领域 | 至少检查 |
|---|---|
性能 | 首屏、图片、字体、脚本、缓存和移动网络表现 |
可访问性 | 标题层级、键盘、焦点、表单标签、对比度和替代文本 |
安全 | HTTPS、权限、依赖、备份、日志、漏洞与密钥管理 |
隐私 | 数据收集目的、同意、第三方脚本和删除/退出方式 |
可靠性 | 404/500、异常提示、监控、恢复和备份演练 |
自动化工具可以发现一部分问题，但不能替代真实设备测试、人工任务测试、安全审查和业务验收。项目应根据行业风险决定测试深度。
10 上线当天的检查顺序
时间 | 动作 |
|---|---|
上线前 | 备份旧站与数据库，确认回滚方案和负责人 |
切换时 | 部署正式环境、域名、证书、配置和数据 |
切换后1小时 | 检查首页、核心页面、表单、支付、登录和接口 |
上线后24小时 | 检查错误日志、抓取、索引、流量和转化 |
上线后7天 | 处理真实用户问题、重定向遗漏和性能异常 |
上线后30天 | 复盘SEO、线索、内容、维护和下一阶段需求 |
11 最终交付必须包含什么
- □ 最终设计源文件、组件库、图标、图片和动效资产；
- □ 前端、后端、配置、数据库脚本和构建说明；
- □ 代码仓库、域名、服务器、CMS和第三方账号权限；
- □ 部署、环境变量、接口、数据结构和维护文档；
- □ 字体、图片、插件和第三方素材授权清单；
- □ 网站内容、数据、附件和备份；
- □ 管理员培训、操作手册和常见问题；
- □ 未解决问题、已知限制和后续优化清单；
- □ 免费维护范围、期限、响应方式和不包含项；
- □ 最终验收单、付款和版权转移条件。
12 一份简化的验收记录模板
字段 | 填写内容 |
|---|---|
验收阶段 | 需求/原型/视觉/UI/开发/上线/交付 |
对应版本 | 文件名、链接、提交日期和版本号 |
验收依据 | 合同、需求确认书、页面/功能清单和用例 |
通过项 | 已确认成果 |
待整改项 | 问题、级别、负责人和截止时间 |
新增需求 | 另行评估的内容 |
验收结论 | 通过/有条件通过/不通过 |
确认人和日期 | 双方负责人书面确认 |
13 验收争议最常见的5个原因
- 合同只写“设计开发完成”，没有成果清单和标准；
- 客户多人分别反馈，没有统一决策和阶段确认；
- 把方向重做、内容补充和新增功能都当作Bug；
- 只验收前台页面，没有检查后台、账号、源码和数据；
- 尾款、版权、源文件和上线条件没有形成明确顺序。
14 最终原则：验收标准必须可观察、可记录
“高级、好看、速度快、体验好”都不是足够清晰的验收标准。应转化为页面、功能、状态、设备、文件、数据和具体检查动作。无法量化的品牌和视觉判断，也应通过已确认方向、参考、提案逻辑和决策人书面确认控制。
常见问题
网站上线就算验收完成吗？
不一定。上线验收和最终资产交付可以是不同节点，应以合同和验收单为准。
客户可以在验收时要求全部重做吗？
若成果不符合已确认需求，应整改；若是已确认方向后的全新偏好或新增范围，应按变更机制评估。
免费维护一般包含什么？
通常包含已交付范围内的Bug修复和兼容问题，不默认包含新增功能、改版、第三方变化和客户自行修改造成的问题。
没有专业技术人员怎么验收网站？
可根据需求清单和真实任务进行业务验收，并委托独立技术、安全或SEO人员检查高风险部分。
验收问题多久修完才合理？
应按严重程度、复杂度和项目约定确定。阻断和严重问题通常需优先处理，轻微问题可列入计划。
