公司网站设计：交付物齐全却无法使用，缺口怎样界定
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /de623e86ee72.html
📄
公司网站设计：交付物齐全却无法使用，缺口怎样界定
先给一个可操作的界定：当交付物逐项签字通过，但业务人员按正常流程无法完成一次真实任务时，缺口不在“有没有交”，而在“交付物之间缺少可运行连接”。判断方法不是再数一遍文件，而是拿一个真实页面走完整链路，看在哪一步必须回头找设计方。
先选定一个可执行样本，而不是翻整包交付物
从交付清单里挑一个最常用的页面，例如“产品详情页”或“联系我们页”，要求它能独立完成一次访问、一次内容修改、一次表单提交。样本选得越接近日常使用，越容易暴露缺口。
把样本拆成四层来看：
- 静态层：页面文件、样式、图片资源是否齐全；
- 结构层：页面之间的链接、跳转、返回路径是否闭合；
- 内容层：文案、图片、字段能否由非技术人员替换；
- 运行层：表单、查询、登录等交互是否真的产生预期结果。
四层都过一遍，缺口通常出现在第三层和第四层的衔接处，而不是第一层。
用“谁在什么条件下做什么”验证，而不是看文件是否存在
假设一个场景：运营人员拿到后台账号，想把详情页主图换成新品图，并改一句促销文案。如果这一步需要改代码、找原设计源文件、或重新导出整站，那么交付物虽然存在，使用条件却不成立。
这里要区分两类缺口：
- 权限与入口缺口：后台有菜单，但对应字段不可编辑，或编辑后前台不更新；
- 依赖缺口：页面能显示，但依赖某个未交付的组件、字体或接口，换环境就失效。
判断动作很简单：让实际使用的人在不看说明文档的情况下操作一次。如果他必须回头问设计方“这个在哪里改”，缺口就已经被定位到具体环节，而不是笼统的“不好用”。
把缺口写成可验收的补充项，而不是重开一轮需求
发现缺口后，不要直接要求“重新做一版”。把缺口转成三条可核对的信息：
- 在哪个页面、哪个操作路径上失败；
- 期望结果是什么，实际结果是什么；
- 需要补充的是文件、权限、配置说明，还是接口对接。
例如，假设详情页的规格参数由一段写死的 HTML 生成，而交付清单里写的是“参数可后台维护”。那么补充项应写成“规格参数字段需在后台可增删改，前台同步更新”，并附上一条测试路径。这样处理的结果是：对方能判断这是配置遗漏还是功能未做，下一步是补配置还是补开发，而不是陷入“算不算交付”的争论。
区分“个别样本成立”和“规模化后例外”的边界
一个页面能跑通，不代表整站可用。常见情况是：样板页由设计方手工调过，所以看起来正常；换到其他页面，同样的组件因为缺少统一规则而错位或失效。
判断边界时，选三个不同层级、不同内容类型的页面重复同一套操作。如果只有一个页面通过，缺口属于规则未沉淀；如果三个页面都在同一步失败，缺口属于基础能力未交付。前者补规范文档和模板即可，后者需要回到开发环节，处理优先级和返工成本完全不同。
验收结论怎么写才不掩盖缺口
验收单上不要只写“已交付”。把结论分成三档：可独立使用、可在指导下使用、不可使用。每一档都对应一个具体动作：
- 可独立使用：直接进入维护阶段；
- 可在指导下使用：要求补充操作说明或录屏，并约定复测；
- 不可使用：列出阻塞项，明确由谁在什么条件下补齐，补齐后再走一次同样的样本测试。
这样做的结果是，缺口从“感觉不好用”变成有路径、有责任方、有复测条件的清单，后续沟通和付款节点都能据此推进。
