把接口设计成“可执行的验收条件”而不是“可阅读的说明书”,是这类合作能否继续的关键。文档只说明对方打算怎么做,接口则要说明双方各自交付什么、以什么形式交接、出现不一致时谁负责修正。若供应商坚持只交文档,你至少要把接口写成可被第三方复现的步骤和可核对的输出物,否则后续任何实施方都要重新猜一遍。
同样是只交文档,背后可能是两件完全不同的事,处理方式也相反。
两种解释在表面现象上很像:都只有文档、都不含部署动作、都缺少运行数据。区分它们不能靠感觉,要看证据。
第一组证据是文档能否被独立复现。假设一份接口文档只写“调用用户服务获取数据”,没有字段、没有错误码、没有超时约定,那么第三方实施方必须回头找原供应商确认,这更像责任没有划清。反之,如果字段、示例请求、异常分支都齐全,即使没有实施,也属于可移交的能力边界。
第二组证据是对追问的响应方式。可以就同一处细节连续追问两次:第一次问“这个字段为空时怎么处理”,第二次把对方的回答复述回去,问“是否确认按这个执行”。如果两次答案一致且愿意写入文档,属于边界清晰;如果第二次改口或回避落字,更接近责任规避。
第三组证据是历史交付物的形态。若对方过去交付的项目里,文档总是伴随可运行的测试环境或部署脚本,本次却只剩文档,变化本身值得追问;若对方一贯只做方案层,那本次并不反常,只是你需要提前安排实施方。
这里要提醒一点:文档数量、页数、抓取或访问统计都不能单独证明哪种解释成立。文档很厚可能只是模板堆砌,访问量归零也可能只是链接失效或权限调整,和供应商是否愿意实施没有必然关系。
无论属于哪种解释,接口都应包含四个可核对的要素,缺一个都会在实施阶段变成扯皮点。
一个实际动作是:在合同或补充确认里,把“验证接口”写成一次联合走查,并规定走查记录作为验收附件。这个动作的结果会直接影响下一步——如果对方拒绝参加走查,你就知道后续实施不能依赖其口头支持,应尽早引入独立实施方;如果对方参加并当场补齐缺口,文档的可移交性就得到了一次实证。
小项目里,双方靠熟人沟通就能补上文档缺口,接口写得粗也过得去。一旦同时推进多个站点、多个环境,例外就会集中出现:同一个字段在不同项目里含义不同,同一份部署说明在不同服务器上步骤不同,原先靠人记的约定没人记得。
这时不能照搬单个成功样本的做法。单个样本成立的条件通常是:双方对接人稳定、环境单一、变更少。规模化后这三个条件至少有一个不成立,接口就必须从“靠人补”转为“靠文档和验证记录补”。具体做法是把每个项目的输入、输出、验证、变更四项分别留档,并指定唯一对接人;对接人更换时,交接以留档为准,不以口头说明为准。
边界也要说清:如果供应商只做方案设计,且你方已有稳定实施团队,那么只交文档是可以接受的,接口重点放在文档质量与澄清时效;如果供应商既做方案又拒绝实施,而你方没有替代团队,那么继续推进的风险不在文档,而在上线环节无人负责,此时应优先解决实施主体,而不是继续打磨文档。
最后把接口落到可观察的信号上,避免“已完成”“已交付”这类无法核对的表述。可以要求对方在文档中标注每个模块的就绪状态,例如已定义、待确认、不包含,并说明每种状态对应的后续动作。你收到文档后,逐项核对状态是否与合同范围一致:标注不包含的部分,就是你需要另行安排实施的地方。
这样做的结果是把“供应商只交文档”从一个模糊抱怨,变成一张可分配任务的清单;下一步无论是继续合作还是更换实施方,都有明确依据,而不是重新从零沟通。