网站开发外包：交付物能验收却不能上线时怎样界定缺口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dfd90badfb72.html
📄
网站开发外包：交付物能验收却不能上线时怎样界定缺口
当验收清单上的每一项都打了勾，站点却无法承接真实流量或完成业务动作，缺口通常不在“有没有交付”，而在“交付物是否满足运行前提”。界定缺口的方法是：把验收标准从文件存在性改为业务可运行性，并区分是外包方未履行合同义务，还是需求方未提供运行条件。前者要求返工或扣款，后者需要变更范围并追加投入。
两种解释：交付缺陷与前提缺失
第一种解释是交付缺陷。代码、模板或配置虽然存在，但缺少运行所必需的组成部分：依赖未锁定、环境变量未说明、数据库结构未同步、构建脚本在目标环境失败、接口鉴权方式与文档不符。这类缺口属于外包方责任，因为合同隐含了“可运行”这一基本要求，而不只是“可查看”。
第二种解释是前提缺失。外包方按约定交付了代码和文档，但运行所需的域名解析、服务器权限、第三方账号、支付或短信资质、内容素材、法务合规确认始终没有到位。此时验收通过并不矛盾，因为验收范围从未包含这些外部条件。缺口在需求方一侧，继续要求外包方免费补齐并不合理。
两者常被混为一谈，因为表面症状相同：页面打不开、功能不可用、数据不显示。区分它们不能靠感觉，要靠证据。
用三组证据区分责任归属
证据一：合同与需求文档中的运行前提条款
翻出签约时的需求说明和验收标准。如果其中写明了“部署到指定服务器并完成一次真实下单”，而实际未做到，属于交付缺陷。如果只写了“提供源码与部署说明”，且说明确实存在，则属于前提缺失。这一条决定了后续是索赔还是追加预算。
证据二：在干净环境中的复现结果
找一个未安装任何项目依赖的空白环境，按交付文档逐步执行。记录在哪一步失败、报错信息是什么、文档是否提前说明了该步骤的前置条件。能够复现并定位到具体缺失项的，通常是交付缺陷；无法复现或卡在外部账号权限上的，通常是前提缺失。这个动作的结果直接决定下一步：能复现就发返工通知，不能复现就补条件或改范围。
证据三：交付物与运行环境的版本对应关系
检查代码版本、依赖版本、数据库版本、运行时版本是否与文档描述一致。假设文档写的是某长期支持版本，实际交付的代码却依赖一个已停止维护的旧版本，且没有迁移说明，这就属于交付缺陷。反过来，如果文档明确要求某版本，而需求方坚持使用另一版本导致不兼容，则属于前提变更。
一个假设例子：验收通过后无法下单
假设某外包项目验收时，后台能登录、商品能显示、订单列表能打开，验收单全部勾选。上线后用户无法完成支付。排查发现：支付接口的商户号是测试号，正式号需要需求方自行申请并配置。合同只写了“集成支付功能”，未写明由谁提供正式商户号。
此例中，代码集成本身可能没有缺陷，缺口在于运行前提未定义。合理的处理不是要求外包方免费更换正式商户号，而是确认变更范围：由需求方提供正式凭证，外包方协助配置，配置工作按变更单计价。如果合同写明了“上线可用支付”，则外包方应承担未提醒和未预留配置入口的责任。
把缺口写进变更单而不是验收单
一旦确认缺口属于前提缺失或范围外事项，不要试图在原有验收单上补勾。正确动作是开一份变更单，写明：缺失的具体条件、由谁提供、提供后需要外包方执行哪些动作、这些动作是否产生额外费用、完成后的验证方式。变更单签署后再执行，可以避免“先做了再说”导致的扯皮。
如果缺口属于交付缺陷，则走返工流程：列出可复现的失败步骤、期望结果、实际结果，要求外包方在约定时间内修复并重新提交验证。返工验证仍以业务可运行性为准，而不是以“文件已更新”为准。
界定缺口的最终依据不是验收单上的勾，而是“谁控制着缺失的那个条件”。控制方在需求方，就是前提缺失；控制方在外包方，就是交付缺陷。把这个判断写进变更单或返工单，后续的预算、工期和责任才有可执行的落点。
