他同时开4个AI写代码，今天关了1个

一位独立开发者同时运行4个Claude Code实例协作开发，却在今天亲手"杀死"了其中一个。这不是技术故障的吐槽，而是一场关于AI协作边界的人为实验——当多个智能体共享同一代码库，谁来决定谁能动什么文件？

四线并行的开发实验

这位开发者正在做一款叫"Jibun Inc."的Flutter Web应用，定位是AI生活管理中枢，把Notion、Evernote、记账软件、Slack等21个竞品的功能塞进一个产品里。光是AI University模块就已经接入了66家服务商。

他的开发流程很激进：同时开4个Claude Code实例并行工作，分别负责不同技术栈。

但就在今天，Web实例被正式下线。

导火索是一次session里连续爆发的三个故障：GitHub MCP连接断了三次，每次重连都要几分钟；Stream空闲超时导致WebFetch并行执行时响应被截断；最致命的是一次"文件未找到"误报——docs/INSTANCE_CONFIG.md明明存在，系统却判断为新文件，试图创建，触发了文件所有权越界。

这个文件属于PowerShell实例，Web实例无权触碰。

三个故障单独看都能忍，同时发生就让整个工作流变得"不可交付"。

清理成本：149行删除背后的架构债务

下线一个实例不是关窗口那么简单。开发者用git show统计了清理工作量：95c385a4这次提交，149行删除，29行新增。

Web实例的残留比预想中深得多。

需要同步修改5个文件：MULTI_INSTANCE_COORDINATION.md的标题从4改到3，删除Web行；INSTANCE_CONFIG.md删掉Web的约束、提示词和角色定义；README.md更新实例数量；CLAUDE.md的规则14/21/22剥离Web相关描述；COMPRESSED_PROMPT_V3.md的头部和范围表全部调整。

这暴露了一个反直觉的事实：AI协作系统的"配置熵"增长极快。你以为只是加了一个实例，实际上它在文档、规则、权限表、提示词模板里埋下了几十处隐性依赖。

更麻烦的是合并冲突。当多个实例同时修改代码库，文件所有权边界就是唯一的防冲突机制。开发者发现，"只是澄清谁可以写什么"，就解决了大部分合并冲突。

跨实例审批：当AI需要AI的许可

这里出现了一个有趣的治理结构。

INSTANCE_CONFIG.md归PowerShell实例所有，但下线Web实例的决策来自Windows Desktop实例。怎么解决？

开发者设计了一个"逃生舱"机制：在docs/cross-instance-prs/目录下创建YYYYMMDD_.md文件，让拥有该文件的实例在下次session时审批。

紧急情况下可以直接修改，但必须在提交信息里标注[cross-instance: PowerShell approval required]。

Windows Desktop的写入范围原本是docs/（DESIGN.md除外）加上supabase/migrations/。这次变更还触及了CLAUDE.md和COMPRESSED_PROMPT_V3.md，而这两个文件被显式标记为"共享领土"。权限表让开发者能瞬间做出判断，而不是卡住。

这种设计本质上是在模拟人类团队的代码审查流程，但把审批权交给了另一个AI实例。

并行开发的Git操作细节

工作目录里还有来自并行实例的未提交修改：lib/pages/admin/quota_dashboard_page.dart。

开发者刻意避开了git add -A，而是逐个文件显式添加：

git add \
docs/MULTI_INSTANCE_COORDINATION.md \
docs/INSTANCE_CONFIG.md \
docs/README.md \
CLAUDE.md \
.github/COMPRESSED_PROMPT_V3.md

这个细节很重要。在AI多实例场景下，-A的风险被放大了：你不知道其他实例在后台改了什么，显式列表是唯一的可控手段。

这也解释了为什么149行删除能精准对应5个文件——每一次add都是一次边界确认。

v2.1.110未部署：版本漂移的隐形代价

开发者提到一个具体版本号：v2.1.110，这个版本修复了"MCP工具调用在服务器连接断开时挂起"的问题。

但显然，claude.ai/code的运行时还没有部署这个修复。

这揭示了一个被低估的运维风险：当你依赖云端AI编码工具，你的稳定性不仅取决于自己的代码，还取决于服务商的版本推送节奏。2.1.110已经发布了，但运行时没跟上，你的多实例架构就要为别人的部署延迟买单。

每次重连"几分钟"听起来不长，但在4实例并行的节奏里，这是指数级放大的摩擦成本。

Stream空闲超时：并行化的物理极限

WebFetch和文件编辑并行执行时触发了Stream空闲超时，响应被截断且session无法恢复。

这是一个架构层面的信号：AI编码工具的流式输出有隐性的时间窗口，当你的操作模式（网络请求+本地IO）突破了这个窗口，系统不会优雅降级，而是直接崩溃。

开发者原本的设计是让Web实例处理网络相关任务，但网络任务的异步特性与AI session的状态机产生了冲突。这不是配置问题，是执行模型不匹配。

文件所有权：AI协作的治理原型

整个实验最有价值的部分，是开发者摸索出的"文件所有权"机制。

每个实例有明确的写入范围：PowerShell管INSTANCE_CONFIG.md，Windows Desktop管docs/和supabase/migrations/，共享领土需要显式标注。

这本质上是在没有操作系统级隔离的情况下，用文档约定实现软隔离。当Web实例误触INSTANCE_CONFIG.md时，系统没有技术层面的阻止，但开发者可以通过审计发现越界。

这种"事后发现"而非"事前阻止"的设计，说明当前AI编码工具还没有原生支持多实例协作的权限模型。开发者在用人类团队的治理模式，填补工具链的空白。

66家服务商的接入逻辑

回到产品本身：AI University模块接入66家服务商，这个数字本身说明了"Jibun Inc."的产品策略——不做选择，全都要。

吸收21个竞品功能进一个产品，这种超级应用（super app）思路在移动端已经被验证过（微信、支付宝），但在AI原生工具里还是早期实验。

66家服务商的维护复杂度，可能是4实例并行架构的原始驱动力。当集成规模超过人类开发者的上下文容量，必须用AI实例分片处理。

但今天的下线事件也说明：分片带来了新的协调成本，当协调成本超过分片收益，就得收缩。

从4到3：规模与可控的权衡

开发者没有透露剩下3个实例的具体分工，但从清理的文件可以反推：PowerShell（后端/配置）、Windows Desktop（前端/文档）、还有一个未提及的实例（可能是移动端或AI核心）。

Web实例的下线，意味着前端开发被合并进Windows Desktop的职责范围，或者完全改由人工处理。

这是一个典型的"去并行化"决策。当系统的故障模式从"单点失效"变成"级联失效"，并行度的收益曲线就会拐头向下。

开发者的判断标准是"是否可交付"（unshippable）——不是能不能跑，而是能不能稳定地、可预测地跑。一次session三个故障，已经突破了这个阈值。

对行业的影响：多智能体开发的早期范式

这个案例的价值在于它的具体性。不是抽象地讨论"AI会不会取代程序员"，而是一个真实开发者在用AI取代部分自己时，遇到了哪些 friction（摩擦点）。

文件所有权、跨实例审批、版本漂移、Stream超时——这些问题没有现成答案，开发者正在用工程实践试错出答案。

对于25-40岁的科技从业者，这个案例有几个可迁移的观察：

第一，AI协作的治理成本被严重低估。当你从"一个AI助手"扩展到"多个AI角色"，配置管理的复杂度不是线性增长，而是网络效应式增长。

第二，云端AI工具的版本不一致是真实风险。你的prompt engineering可能在一个版本工作，在另一个版本崩溃，而你没有控制部署节奏的能力。

第三，显式边界比隐式约定更可靠。无论是git add的文件列表，还是INSTANCE_CONFIG.md的所有权标记，把假设写出来是防止AI"幻觉"越界的唯一手段。

这位开发者的实验还在继续。3个实例的协作模式是否稳定，是否会在未来某个节点再次收缩到2个甚至1个，取决于今天这套治理机制的有效性。

而更大的问题是：当AI编码工具的原生厂商（Anthropic、GitHub、Cursor等）注意到这些实践，会不会把"多实例协调"做成内置功能？开发者的临时方案，会不会成为下一代工具的标准范式？