先给结论:供应商只交文档时,接口的边界应当从“谁写内容”改为“谁把文档变成线上状态”。如果对方不接触站点、不提交变更、不验证线上结果,那么你付的钱买到的是一份决策依据,而不是一次上线动作。接口设计要围绕三件事:交付物形态、责任移交点、变更确认方式。把这三件事写清,再决定保留、改写还是退出。
同样是不实施,背后的原因完全不同,处理方式也不同。
区分方法很简单:看文档里有没有明确的“执行主体”和“完成判据”。如果每条建议都写清了由谁改、改哪个页面、改成什么状态、如何确认改完,那它更接近策略型交付;如果只有方向和理由,没有落到具体页面和状态,那它更接近半成品。
只交文档的场景里,最容易出问题的地方是把文件当成交付完成。文件到了,但线上状态没变,双方对“做完了没有”的理解就会分叉。设计接口时要强制引入状态字段。
可以要求每一条建议都带四个字段:
这四步做完,文档就从“建议”变成了“工单”。即使对方不实施,你的执行方也能按工单推进,减少来回确认。
假设一个场景:供应商交付了一份页面结构调整建议,包含标题写法、内链方向和内容取舍。你不确定该由谁改。这时接口要回答的是“从哪一刻起,风险和责任转到执行方”。
一种做法是设置可执行性确认:供应商交付后,由执行方在约定时间内反馈“能否按此执行”。如果执行方指出某条建议依赖不存在的模板或权限,供应商需要补充替代方案。这个动作的结果直接影响下一步——如果执行方确认可执行,后续线上问题主要由执行方承担;如果执行方无法确认,说明文档还没到可移交状态,供应商需要继续补充。
另一种做法是设置变更窗口:文档交付后一段时间内,供应商对文档内容的准确性负责;窗口结束后,执行方对落地结果负责。这个时间边界必须写进接口说明,否则容易出现“改完没效果又回头找文档”的循环。
当你发现对方只交文档不实施,先不要急着换供应商。用下面这组可核对的证据判断属于哪种情况。
对应的取舍前提是:如果文档质量高、你的执行方稳定,保留这种分工是成立的,接口重点是补状态字段和确认方式;如果文档需要你大量二次加工,且执行方也不稳定,改写接口(要求对方至少提交变更说明或验证记录)比直接退出更省成本;如果对方既不实施也不提供可执行颗粒度,且沟通后没有改善,退出是合理选择。
假设你要求供应商对一批页面给出调整建议,但对方不登录后台、不发布内容。接口可以这样写:
供应商交付一份清单,每条包含目标页面、当前可观察状态、目标状态描述、建议改动方式。执行方在收到后两个工作日内反馈“可执行”或“需补充”。供应商只对清单内描述与当前状态的对应关系负责,不对执行后的线上表现负责。执行方完成改动后,在清单上标记“已变更”,并记录变更时间。后续如果发现某条建议无法落地,由执行方说明具体障碍,供应商在约定轮次内给出替代描述。
这个例子里,<目标页面>、<当前状态>、<目标状态> 是必须字段,缺一项就视为未完成交付。动作很具体:执行方反馈可执行性,结果决定供应商是否需要继续补充,也决定后续责任落在哪一侧。
最后做一次反向测试:把文档交给一个不了解项目的人,看他能否在不问你的情况下说出“谁在什么时候改什么、改成什么样、怎么算改完”。如果说不出来,说明接口还停在文件层面,没有进入状态层面。这个测试的结果直接决定你是继续保留当前分工,还是要求改写交付格式,或者终止合作。