数字营销顾问：供应商只交文档不实施时怎样设计双方接口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b8ed0eb00aa6.html
📄
数字营销顾问：供应商只交文档不实施时怎样设计双方接口
先给结论：供应商只交文档不实施时，接口设计的核心不是把文档写得更细，而是把“谁在什么条件下必须做什么动作”写进交接边界。可行的做法有两种：一是把接口定义为可执行的验收清单，由你方按清单执行、供应商只负责答疑；二是把接口定义为决策点，供应商在每个关键节点给出判断依据和默认方案，由你方选择后自行落地。两者不能混用，混用会导致责任真空。
两种接口设计的成立条件
选择哪一种，取决于你方是否具备把文档转成动作的人力和判断力，而不是取决于文档本身的质量。
条件一：你方有执行人手，但没有判断经验。此时应选“可执行验收清单”模式。供应商交付的每份文档都要对应一组动作，动作写明输入、输出和完成标志。例如文档给出落地页结构建议，接口就要求供应商同时给出“结构变更前后需要改哪些模板、由谁改、改完用什么标准判断是否生效”。你方照做，遇到歧义再回头问。
条件二：你方有判断经验，但执行人手紧张。此时应选“决策点”模式。供应商不写操作步骤，而是在每个关键节点给出两到三个可选路径、各自的适用前提和放弃代价。你方根据自己的资源选一条，执行由内部完成。这种模式下，文档的篇幅可以更短，但必须包含“如果不选默认方案，会出现什么后果”。
两种条件都不满足时，不要急着签接口，而应先把执行责任收回来，或把实施一并纳入合同范围。否则文档越完整，越容易让人误以为事情已经做完。
把接口写成动作，而不是写成知识
只交文档的供应商最常见的接口缺陷，是把“知识”当成交付物。知识可以阅读，动作必须完成。设计接口时，要求对方把每一条建议转成下面这种结构：
- 触发条件：什么情况下需要执行这条建议。
- 执行动作：具体改什么、在哪里改、由谁改。
- 完成标志：改完之后，用什么可观察的现象确认已经完成。
- 例外处理：如果条件不成立，应该跳过还是替换。
例如，文档建议“优化站内搜索的筛选路径”。接口不能停在这里，而应写成：当筛选结果为空时，触发动作是增加一个兜底提示，完成标志是该提示在空结果页出现，例外处理是如果当前模板不支持动态提示，则改为静态说明文案并记录待改造项。
这样写的好处是，你方执行时不需要重新理解意图，供应商也无法用“文档里已经写了”来回避责任边界。动作清单的长度通常比原文档短，但可执行性更高。
一个假设例子：样本成立、规模化后失效
假设你方有一个内容栏目，供应商在文档中建议“每篇内容发布后 24 小时内提交一次收录检查”。在小样本下，这个动作成立，因为栏目每天只发一两篇，人工可以覆盖。但规模化后，比如每天发布二十篇，同样的接口就会失效：人工检查变成走过场，漏检也无法追溯。
此时不能直接照搬原来的接口。正确的做法是把接口从“人工检查”改成“抽样加异常上报”：供应商定义抽样规则和异常判定标准，你方按规则抽样，只有异常样本才回传供应商判断。这个改动的结果是，供应商的交付物从一份检查记录变成一套判定规则，你方的动作从逐篇检查变成按规则抽样。下一步的接口设计就应围绕规则维护展开，而不是围绕检查次数展开。
这个例子的边界是：抽样规则本身也需要定期复核，否则规则会随样本变化而失效。如果供应商不参与规则复核，你方就要自己承担规则过期的风险。
接口里必须写清的例外和退出条件
只交文档的供应商，最容易在例外情况下产生争议。接口设计时至少写明三类例外：
- 文档与现状冲突。以现状为准还是以文档为准，必须在接口里指定。通常建议以现状为准，但要求供应商在冲突出现后给出书面判断。
- 执行动作失败。动作执行后没有出现预期现象，是继续尝试还是暂停上报。接口应规定尝试次数和上报时限，避免无限循环。
- 供应商不再响应。如果供应商只交文档，后续答疑的时限和方式要写进接口。超过时限未响应时，你方有权按默认方案执行，并记录偏差。
这些条款不需要写得很长，但必须存在。它们决定的是：当文档不能覆盖现实时，双方按什么顺序行动。缺少退出条件的接口，会在第一次例外出现时变成互相等待。
验收动作如何影响下一步
设计完接口后，先做一次小范围验收，而不是直接全量执行。验收的动作是：从文档中挑三条建议，按接口转成动作，由你方执行，记录执行过程中需要供应商判断的次数。如果三条建议中有两条以上需要回头问供应商，说明接口的决策点过多，应改为验收清单模式，或要求供应商补充默认方案。如果三条都能独立执行，说明接口可以扩大范围。
这个验收结果直接决定下一步：是继续扩大执行范围，还是先回头修改接口。不要用“文档已经交付”作为进入下一步的依据，而要用“动作能否独立完成”作为依据。
