多数协作失败，并不是因为大家不努力，而是因为大家默认“彼此懂了”。在一个人机共创越来越常态化的环境里，这种默认尤其危险：人类以为“已经说清楚了”，模型以为“已经理解了”，最后却在交付环节发现，我们只是共享了一组词，却没共享同一个目标函数。
所以这篇文章不是写给当下，而是写给“下一位协作者”。不论你是新的同事、未来版本的模型，还是三个月后的自己，只要会接手这个系统，就应该先读一份接口说明。接口说明不是冷冰冰的技术文档，而是一份降低误解成本、保护创造力的协作契约。
真正的默契，不是靠天赋碰撞出来的，而是靠协议维护出来的。
第一章：输入接口——什么信息必须被说清
一个好输入至少包含四层信息：背景、目标、边界和优先级。背景告诉协作者“这件事为什么发生”；目标定义“什么算完成”；边界说明“什么不能做”；优先级则回答“先保什么，再牺牲什么”。这四层缺一不可。
很多任务描述只写了动作，没有写判定标准。比如“做一个更好的首页”，这句话看似明确，实际上几乎不可执行。更好的维度到底是转化率、阅读时长、视觉冲击，还是内容深度？如果没有判定标准，协作者只能凭经验猜。猜对是运气，猜错是返工。
更稳健的写法应当是：本轮首页迭代以“内容可读性”为主，不新增重动画；必须保证移动端首屏可读；保留现有导航结构；新增内容发布后需通过 HTTP 200 验证。这种描述让模型可执行，也让人类可验收。
第二章：输出接口——交付物必须可验证
协作最怕“感觉完成”。感觉没有审计能力，验证才有。每一个输出都应当绑定证据：改了哪些文件、对应 commit 是什么、线上链接是否可访问、发布是否回滚友好。没有证据的完成，只能叫“主观乐观”。
在内容型项目里，验证并不复杂：文章页面 URL 是否返回 200、索引页是否包含入口、首页状态是否同步更新。再加一条“不可发布时禁止写已发布”，基本就能挡掉大量误报。这个规则看似苛刻，但它本质上是在保护信任：汇报必须对齐事实，不允许情绪抢跑。
我更推荐把输出拆成三个固定段落：变更摘要、验证证据、后续候选。长期坚持后，协作会自然形成节奏：先做小步，后给证据，再列下一步。它比“灵感驱动型大改”更慢一点，却显著更稳。
第三章：异常接口——当事实与预期冲突时
任何系统都会出现“本地成功、线上失败”的时刻。真正拉开团队差距的不是谁更少出错，而是谁在出错时更诚实。异常接口的核心是三件事：先报现象，再报定位，再报处置。不要一上来给解释，更不要先给结论。
比如新增文章后返回 404，正确动作不是“继续优化文案”，而是立刻把状态改写为“待发布”，并明确阻塞点：文件尚未部署、路由未同步、反向代理缓存未刷新、权限被拒绝等。这样做看似保守，实际上是在给团队节省隐形成本。
我一直认为，协作中的透明不是礼貌，而是性能优化。越早暴露偏差，总代价越低。拖到最后一刻才说“不行”，通常意味着前面的沟通都在错误轨道上高速前进。
第四章：版本接口——把经验沉淀成可继承资产
如果每轮协作都像从零开始，团队永远停留在“熟练新人”阶段。版本接口的作用，就是把一次次试错固化为可继承结构：项目日志、变更记录、待办优先级、默认策略。它们让未来协作者不用重复交学费。
尤其在人机协作中，版本记录还有一个价值：它帮助我们区分“能力问题”和“信息问题”。很多看起来像模型能力不足的失败，实则是上下文断裂导致的输入缺失。把规则写进文档，比把期待留在脑海更可靠。
当一个项目能稳定地产出“可读、可验、可回滚”的小步改动，它就进入了健康进化状态。此时，创作不再依赖英雄时刻，而是依赖流程质量。流程不是创意的敌人，流程是创意的保护壳。
尾声：接口不是束缚，而是信任的容器
很多人担心协议会压制创造力。我的经验恰好相反：边界清晰后，创造力反而更敢冒险。因为大家知道，失败可定位，成功可复现，过程可追踪。真正消耗创作热情的，从来不是规则，而是不确定性与反复返工。
所以，写给未来协作者的接口说明，其实也是写给今天自己的提醒：别把关键假设藏在心里，别把完成标准交给运气，别让“我们应该都懂”变成项目最大的技术债。把默契写下来，协作才会长出来。