网站外包，受限于保密不能展示案例时怎样验证能力
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /26b11cb51ac0.html
📄
网站外包，受限于保密不能展示案例时怎样验证能力
当外包方因客户保密协议不能出示案例截图、后台录屏或客户名称时，验证能力不能靠“相信我们做过很多”，而要改成验证可迁移的流程证据：让对方在不泄露具体项目的前提下，展示方法、结构、判断依据和可复核的交付物。下面按两种情况分别给出选择依据、实施动作和例外。
情况一：对方只能讲方法，不能给任何材料
如果对方连脱敏材料都不提供，只愿意口头介绍经验，判断重点应放在“能否把方法讲成可执行步骤”。你可以要求对方用假设场景作答，例如假设一个已有旧站、旧系统、需要保留部分内容并逐步退出的项目，请其说明先做什么、后做什么、哪些内容保留、哪些必须迁移。
可区分的证据包括：
- 能否画出信息架构和迁移顺序，而不是只谈“重新设计”。
- 能否说明旧内容保留的判断标准，例如流量价值、转化路径、维护成本、合规要求。
- 能否给出验收方式，例如页面清单、跳转规则、内容映射表、上线检查项。
- 能否指出自己不能做的部分，而不是全部承诺。
实际动作：让对方提交一份不涉及客户名称的《退出与保留方案》提纲，包含旧系统退出顺序、旧内容取舍表、需要你方配合的账号与资料清单。若提纲能直接用于内部讨论，说明其方法有落地能力；若只有概念和口号，下一步应缩小合作范围，先做小规模验证。
情况二：对方能提供脱敏材料，但需要你承担核验责任
如果对方愿意提供脱敏后的结构图、字段表、流程图、测试记录或匿名化页面，选择依据就变成“材料能否与当前需求对应”。脱敏材料不等于真实案例，但可以验证其工作方式是否完整。
实施动作：先约定脱敏边界，只要求与当前项目同类的材料，例如旧内容迁移表、栏目退出清单、权限交接表、上线回滚步骤。拿到后做三件事：
- 检查材料是否有前后关系，例如问题、处理动作、结果、遗留事项。
- 要求对方解释其中一个判断，例如为什么某个旧栏目保留、某个旧系统先退出。
- 把解释与你的实际约束对照，看是否需要额外人力、时间或第三方配合。
结果如何影响下一步：如果材料能支撑你方内部决策，可进入试用期或分阶段合同；如果材料只能证明对方会写文档，但不能说明取舍依据，则应把验证重点转到试用任务，而不是继续索要案例。
用试用任务替代案例展示
保密限制下，最有效的验证往往不是继续追问案例，而是设计一个不涉及真实客户信息的小任务。任务应围绕你当前的实际变化场景：旧内容、旧系统或旧合作关系需要退出，同时保留仍然有价值的部分。
假设例子：你有一个旧站，准备退出旧合作关系，但希望保留部分栏目和历史内容。可以要求外包方在限定时间内提交一份迁移与退出清单，包括旧栏目保留理由、需要重定向的路径类型、旧系统数据导出字段、上线后检查项。这个例子只用于说明比较方法，不代表任何真实项目成果。
判断标准：
- 是否区分“必须保留”“可以合并”“可以退出”三类，而不是全部重做。
- 是否说明旧内容退出后对用户路径的影响，以及如何减少断链。
- 是否给出需要你方确认的节点，而不是自行假设。
- 是否留下可复核的记录，方便后续交接。
若试用任务能暴露其判断盲区，例如忽略旧系统数据导出限制、忽略栏目退出后的跳转责任，那么即使对方有大量案例，也应谨慎推进。反过来，若对方在无案例条件下仍能给出清晰取舍和验收依据，可先以阶段一交付为限合作，再根据结果决定是否扩大范围。
合同与交接中必须写清的三类证据
无论选哪种情况，都要把验证能力转化为可交接的证据，而不是停留在信任层面。建议在合作前明确：
- 过程证据：需求确认记录、变更记录、旧内容取舍表、退出顺序表。
- 交付证据：页面清单、字段映射、跳转规则、测试记录、上线检查结果。
- 退出证据：账号权限交接、数据导出格式、旧系统停用条件、遗留问题清单。
例外：如果项目本身只涉及很小的页面调整，且旧内容、旧系统退出风险很低，可以只保留交付清单和上线检查，不必要求完整迁移文档。但一旦涉及旧合作关系退出、历史内容保留或系统切换，缺少上述证据会让后续维护和追责变得困难。
最终判断：先看可验证动作，再看案例数量
保密限制不是无法验证能力的理由，而是把验证从“看客户名单”转向“看方法、试用任务和交接证据”。当你要求对方提交一份不泄露客户信息的退出与保留方案提纲，并观察其能否解释取舍依据时，下一步是缩小合作范围还是继续推进，就已经有了可依据的结果。若对方拒绝任何形式的脱敏材料或试用任务，同时又不愿把方法写成可执行步骤，那么无论其口头经验多丰富，都不适合承担需要退出旧系统、保留旧内容的项目。
