夜雨聆风上一个项目 ASR，我闷头做了很久才拿出来，吃了"不分享、不先证逻辑"的亏。这次反过来：先把想法讲清楚、把逻辑推到我自己都挑不出洞，再动手。这篇就是我最近关于"多人 AI Coding 协作"的完整思考过程，好的坏的都写出来。
一、背景：不是 AI 写得慢，是人复核跟不上
AI Coding 的特点，是 AI 写得飞快，而人的复核工作量被成倍放大。一个人盯一个 AI 还勉强，一旦进入多系统对接、系统适配、多人协作，复核量再翻几番。
更要命的是沟通频率变了。AI Coding 之前，系统之间靠 API 接口文档、设计文档沟通，节奏以"月"为单位；AI Coding 之后，AI 一小时能改动过去一周的量，系统之间的沟通被迫压缩到以"小时"为单位。人，跟不上 coding 的速度了。
我想解决的，就是这件事。
二、从一个看板，膨胀成一座工厂，再收缩成一根绳
起因。我手上有个项目叫 ASR，是个单机的多 Agent 软件工程 Runtime——Builder 写、Tester 测、Analyzer 审、Controller 调度，围着一个目标不断收敛。它跑得挺好。我自然就想：能不能把它从"一台机器里几个 Agent"，扩成"多个人、多台机器一起协作"？
调整。最初的想法很朴素：做一个"消息看板"，让后端做完喊一声，前端接着上。就是个 AI 版的 Slack。
扩大。我找了个模型专家一起推演。它点出了一个更深的东西：多人协作真正交换的最小单位，不是记忆（Memory），而是契约（Contract）。API 其实是一个系统的"超级压缩"——外部只需要知道怎么用你，不需要知道你内部怎么实现。这个判断很对，我很兴奋。
膨胀。然后就开始越推越大。P2P 组网（像"微力同步"那样一个团队共用识别码，无需中间件）、Engineering Mesh、Ontology 做语义路由、Control Plane 做治理、五层 Context 梯度、无限递归的"分形封装"……一整套宏大的"AI 原生软件工厂"架构图，画出来非常性感，听着让人上头。
收缩。我踩了刹车，让它做一轮反事实推演：假设这全错了，哪里先塌？结果很清醒——方向是对的（"Contract 而非 Memory"本就是软件工程 60 年的封装铁律），但落点错了三处：把"类比"当成了"严格同构"；把"AI 自动生成契约"当成了已经解决的事；把 P2P、Ontology 当成了近路。
而最根本的问题是：整个讨论一直在试图"替 AI 建模"——想造一堆机械（自动契约生成器、语义合并器、Ontology 推理机、中心验证管线），去做 AI Coding 自己本来就能做的事。这等于把黄牛的力气按住，自己上去拉车。它悄悄弱化了 AI Coding 本身最强的东西：理解、推理、测试。
控制论。转机在于，ASR 的内核本来就是控制论——一个收敛控制器。那就用控制论重新看这件事：看板 = 参考信号（setpoint），AI Coding = 被控对象（plant），各自的测试 = 传感器，收敛内核 = 控制器，别人的契约变更 = 外部扰动，人 = 只在关键处介入的监督者。控制论的第一课就是：反馈和监督，可以替代对被控对象的精确建模。你不需要给牛的每一块肌肉建模，只要给它参考、给它反馈、在方向错时拉一把。
黄牛绳。于是定位一路收缩到极致：AI Coding 是一头力气巨大的黄牛，我要做的工具，就是套在它鼻子上的那根牵引绳。最小的接触点，只负责给方向，绝不替牛使劲。绳子越简单、越轻、越不抢牛的活，系统越成功。这既是核心定位，也是成败关键。
最后一次收缩，砍到了我自己头上。写完方案我反问一句：这套东西，还非得用 ASR 吗？答案是——不必。局部的"写→测→改"收敛，Claude Code、opencode 这些工具自己就在做，ASR 再插一手是重复造轮子；跨系统的协作，靠的是看板加协议，也不是 ASR。绳的价值本就在于能套上任何一头牛，如果只对我自家那头牛有效，那它就不够格叫牵引绳。于是 ASR 从"核心"降级成了"其中一种节点实现、一个参考样板"。承认这一点有点反直觉——把自己起家的东西请出核心——但方案因此更干净、更通用了。
一个想造工厂的冲动，最后收敛成了一根绳，连绳的发明动机（ASR）都被这根绳排除在核心之外。这个不断收缩、连自己都不放过的过程，比那张性感的架构图值钱得多。
三、解决方案：一块小看板 + 一根绳的三件薄物件
核心命题。一块小小的共享看板（承载目标与契约）+ 一套定义清晰的接口标准，就足以协调多个"人 + AI"一起完成软件生产——不需要共享记忆、不需要中心验证、不需要 Ontology。原则叫"局部复杂，全局简单"：每个人机内部可以有完整的代码、调试、推理、记忆；对外只暴露稳定的契约。看板天然内容很少，因为参考信号本就远小于内部状态，这不是刻意精简，是第一性原理的结果。
通讯不是一个"层"，是边界采样。一想到"通讯"就想造中间件，那又是替牛使劲。真相是：每一轮工作开始时，读一次看板（采样当前该做什么、依赖有没有变）；工作结束时，写一次看板（发布我这轮产出的契约/状态）。就两个采样点。中间的理解、推理、测试，全部交还给 AI Coding 自己——这正是之前被弱化、绝不能再弱化的能力。
三件薄物件，各司其职，别混成一坨。
看板存储：用一个共享的 Git 仓就行，一张卡一个文件，卡的格式就是"接口标准"。版本、历史、签名全白送。 执行器：一个 MCP 服务（或命令行），只有 read_board/write_board两个动作。这是唯一真正跨工具通用的东西，opencode、Claude、Pi 都能调。纪律：一个 skill（或一份协议文档），规定"何时读、何时写、只发布契约不倒记忆"。注意 skill 自己不干 I/O，它必须骑在执行器上，不能单干。在 Claude Code 里，可以直接用 SessionStart / Stop 两个 hook 来硬保证这个节奏。
一条生死线（C1）。消费方必须能对真实的生产方接口做闭环测试——前端按看板上的契约写代码，然后用集成探针去打真实后端。契约有没有"漂移"，由消费方自己的测试测出来，不靠中心裁判。如果这条不成立（够不到真实接口），系统就退化成开环、必然漂移，那我就不做。逻辑上先过这一关，再谈其他。
稳定与完整。加上两条稳定条件（契约要比代码改得慢，避免两边互相追着改而震荡；人只在误差大或有歧义时介入，不然人会被审批淹没）、一个契约生命周期状态机（提议→达成一致→上线→验证→退役）、一个全局收敛判据（所有契约都验证通过、没有悬空、依赖闭合，才算整体完成），以及一条约束：依赖关系必须是无环图（DAG），成环就交给人打断。
它明确不保证什么。这点我要诚实写出来：控制论有条硬边界——你能完美地跟踪一个错误的目标。所以这套系统只保证"一致性"和"向目标收敛"，不保证目标本身是对的。如果大家一致同意的契约本身是个烂设计，系统会让所有人忠实地、一致地收敛到这个烂设计上。方向对不对，是人和产品的判断，在控制环之外。牵引绳只保证牛忠实地往你指的方向走，不替你决定该不该去那儿。
全部加起来，没有 daemon、没有中间件、没有任何组件持有业务状态。全是薄物件。这就是牵引绳的物理形态。
四、后续规划：AI Coding with Two Human
下一步不做大平台，先做一个能证伪的最小场景，我把它叫AI Coding with Two Human：
两个人，各自用自己顺手的 AI Coding 工具（Claude Code、opencode，都行，不强制统一），一个做后端、一个做前端，两个独立仓库，中间只隔着一块看板。后端做完，只往看板发布契约、任务、依赖、测试状态；前端不许读后端源码，只允许读契约，然后完成前端页面。如果它能顺利做完，这套方案最核心的假设就通过了第一轮验证：跨人协作不需要共享记忆，只需要充分的契约。
要落地的就三件薄物件：一个当看板的 Git 仓、一个 read_board / write_board 的 MCP 服务、一份规定读写节奏的 skill。工具无关，谁都能接。通过之后，再一环一环加：破坏性变更的自动识别、两人同时改契约的冲突、离线重连的同步、加入第三个测试角色。每一环都对应基石文档里一个可证伪的判断。
这次我先把逻辑摆出来、把话说全、把"不保证什么"也写清楚，再动手写代码。吃过一次闷头做的亏，就够了。欢迎拍砖——尤其欢迎有人告诉我：C1 那条生死线（消费方能否对真实接口做闭环验证），在你们真实的企业网络里，到底成不成立。