甘肃网络公司：交付物能通过验收却无法使用，缺口该怎样界定
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /805d17588ba4.html
📄
甘肃网络公司：交付物能通过验收却无法使用，缺口该怎样界定
结论先行：当交付物“能验收”却“不能用”时，缺口通常不在验收动作本身，而在验收标准只覆盖了形式项、没覆盖使用项。界定缺口的正确做法，是把争议拉回到“谁在什么条件下用它完成什么动作”，并区分三种缺口：资料缺口、环境缺口、能力缺口。只有前两种属于交付方责任范围内可补的部分，第三种往往需要重新谈范围。
先分清三种缺口，再决定要不要返工
验收通常检查的是“有没有”：文件在不在、页面能不能打开、后台能不能登录。使用检查的是“能不能完成一件事”：换个人能不能接手、换台设备能不能打开、按流程走一遍能不能走通。二者之间常见三类缺口。
- 资料缺口：交付物存在，但缺少让它被使用的说明、账号、结构解释。例如网站后台能登录，但没有栏目与内容类型的对应说明，接手的人不知道新文章该放哪个栏目。
- 环境缺口：在交付方环境里正常，在客户实际环境里不正常。例如在交付方网络下访问正常，放到客户自己的服务器或域名解析下出现异常。
- 能力缺口：交付物本身完整，但客户方没有人具备使用它的技能或权限。这不是交付缺陷，而是培训或人力问题。
判断顺序建议固定为：先复现使用场景，再定位缺口类型，最后才谈返工或补充。跳过复现直接争论“算不算交付完成”，双方都会停在各自的定义里。
两种合理做法：要求返工，还是接受并自行补齐
面对“能验收不能用”，有两种都成立的处理方式，选择取决于缺口类型和代价。
做法一：按使用场景要求返工或补充交付。适用条件是缺口属于资料缺口或环境缺口，且该使用场景在需求确认阶段已经写明或可合理推定。代价是交付周期延长，且需要把“使用场景”写成可复现的步骤，否则第二轮验收仍会卡在同样的位置。
做法二：验收通过，另行约定补充项。适用条件是缺口属于能力缺口，或使用场景在前期从未提出、属于新增需求。代价是客户需要自己投入人力学习或另行采购，且补充项要单独计价、单独排期，不能混进原验收里反复拉扯。
一个注明假设的短例子：假设合同只写了“交付网站后台并保证可登录”，未写“运营人员可独立发布一篇图文”。验收时后台可登录，但发布流程需要交付方远程协助。按上面的分类，这更接近资料缺口（缺操作说明）而非能力缺口，因为发布图文属于该类交付物的常规使用方式。此时合理动作是要求补一份操作说明并做一次演示，而不是要求重做后台。
一个会让上述结论失效的反例
如果需求确认阶段明确写了“交付后由客户方自行运营，交付方不提供培训”，那么“运营人员不会发布”就不再是资料缺口，而是双方事先约定的能力缺口。此时再要求返工，依据不足。反过来，如果交付物依赖交付方持有的账号、密钥或第三方服务权限才能运行，即使合同没写，也属于环境缺口，因为客户实际上无法独立使用。这类依赖必须在验收时逐项列出，否则“能验收”只是假象。
另一个反例是：把“不能用”简单归因于交付缺陷。访问量、抓取量或某项统计归零，不能单独证明交付物有问题，也可能是解析未生效、访问来源变化或统计口径调整。需要先排除这些解释，再判断是否属于交付缺口。
下一步动作：把使用场景写进验收清单
具体动作是：在验收前，由客户方列出三到五个真实使用场景，每个场景写成“谁、在什么环境下、完成什么动作、看到什么结果”。逐条走一遍，记录通过或卡住的位置。这个动作的结果直接决定下一步：卡在资料或环境上的，进入返工或补充交付；卡在人员技能上的，转入培训或另行约定补充项。验收清单一旦按使用场景写，缺口就不再靠感觉争论，而是靠可复现的步骤定位。
对甘肃网络公司这类服务方而言，把使用场景前置到需求确认阶段，比在验收阶段解释“这不算缺陷”更省成本；对客户而言，验收时多走一遍真实流程，比事后争论谁该负责更有效。
