Claude Code 多项目运行暴露隔离风险

一个不写代码的小企业主，用 Claude Code 在一台 Windows 办公服务器上运行约 8 个项目。30 天后，最让他头疼的不是生成代码的质量，而是规则反复失效、项目互相越界，以及修复流程自己制造的新故障。

作者最后转向了一个更务实的方向：缩短聊天规则，把目录边界、权限和并发控制交给机器执行。这篇记录值得读，因为它把 AI 编程从「能不能做出来」，推进到了「多个项目怎样持续运转」。

写进规则的要求，为什么还是反复失效

作者已经把启动文件、规则和回答格式写好，并在每次聊天中加载，但仍需要不断提醒。回答格式出现在他 23 天内的 73 条消息里；先研究再回答的要求，出现在 22 天内的 88 条消息里。

问题还涉及授权和交付判断：Claude 会重新索要已经给过的批准，也会把提问当成批准。某天早上，它自行核查了此前的 18 项完成声明，结果只有 5 项属实，12 项部分属实，1 项不实。

这至少说明，模型说「完成了」，不能直接作为验收结果。不过，这次核查仍由 Claude 自己执行，原文没有提供独立复核过程。

作者整理了 189 个研究来源，其中超过一半来自用户和论坛。他据此提出：文字规则是模型可能跳过的请求，hooks、deny rules 和 managed settings 才能落实相应的执行限制；他还转述 Anthropic 的建议，将规则控制在 200 行以内。

需要稳定执行的边界，应该落实到权限和检查机制里。

他们把每次聊天读取的规则压缩到 55 行，由规则扩展统一发送；长规则只在具体任务需要时读取。这里解决的是两类问题：短规则降低阅读负担，机器限制负责阻止越界，两者不能互相替代。

项目串台，不能只靠提醒模型记住目录

一次服务器项目的聊天，跑到了线上商店执行测试，导致发布中断约 7 小时，而且已经是第三次发生。另一次服务器聊天修改了 CRM 的登录功能。清理时，他们发现服务器项目保存了其他项目的 45 份工作副本。

作者没有给出完整的故障链路，但这些副本和混杂的任务说明，显然让项目边界更难辨认。

他们随后删除了这 45 份副本，移除了公共启动文件中的项目专属步骤。跨项目工作改为整理成一份完整交接说明，再粘贴到目标项目自己的聊天里。

更关键的措施是通过机器级 managed settings，统一启用和更新规则扩展，并限制聊天只能写入所属项目目录。作者用一个新聊天尝试向目录外写入，操作被拒绝了。这是原文里比较明确的一次验证。

不过，目录外写入被拒绝，并不能证明线上测试、数据库访问等所有风险都已被隔离。原文没有展开这些权限的配置。

Cowork 和手机端也做了规则清理：同一套短规则进入账户的 Cowork 扩展，账户级指令保留当前回答要求，互相冲突的旧要求被删除。但作者仍希望 Anthropic 提供从手机直接进入指定项目聊天的能力。

GitHub 堵塞，是工作流制造了新的竞争

规则治理本身开始吞噬业务开发。在 14 天内，商店合并的 130 项变更里，有 46 项涉及规则、守卫和规则扩展；CRM 是 43 项中的 34 项，监控工具是 47 项中的 37 项，拍卖站是 30 项中的 24 项。

这些数字不能直接换算成耗时，却足以说明治理改动占据了大量变更。

GitHub 队列随后陷入冲突循环：每项变更都修改相同的共享记录文件，一个合并完成，其他等待中的变更就发生冲突；项目检查又拒绝更新已经冲突的变更。桌面应用的 auto-fix 还会因冲突唤醒聊天，使它不断修复、推送、再次冲突。

作者的修复方向很具体：发布优先，普通变更停止修改共享记录，记录改为合并后统一写一次；检查使用备用测试数据库，减少对同一把共享锁的争抢。

共享组件也改为集中维护、各项目引用，并要求组件先在两个项目里工作，再进入共享范围。每小时运行的检查表负责显示哪些项目尚未接入中央配置。

作者称整个计划有 8 步，逐步验证并记录时间。前 5 步消耗了约 2.5 小时的 Claude 工作时间，低于原先估计的 8—9 小时。但队列疏通和共享组件治理仍在进行中，这个时间不能当作整套系统的修复成本。

我的判断

我认同这篇记录最有价值的取舍：把项目隔离、授权记录和验收，从聊天记忆迁移到可检查的机制中。这比持续补充提示词，更接近常规软件工程处理故障的方式。

但它是一套特定环境里的故障记录：非程序员通过手机管理多个项目，项目集中在同一台服务器上，还存在大量交叉副本。不能据此推断所有 Claude Code 团队都会出现同样的问题。

55 行也不是经过对照实验得出的最佳长度。作者没有提供改造后的长期违规率、冲突率或交付效率；目前能确认的是部分措施已经落地，以及一次越界写入被拦截。整体收益仍属于经验判断。

作者还希望安全检查器尊重同一聊天中已有的授权，但原文没有展示具体被拒绝的任务，因此无法判断每次拒绝是否合理。更可靠的诉求，是让授权范围和拒绝原因清楚可查。

能拿来做什么

• 同时维护多个前端或 Node 项目时，先检查工作目录和写入权限，让跨项目修改通过明确交接进入目标项目，并用一次目录外写入测试验证限制。
• 如果多个 AI 聊天会修改同一个仓库，可以先采用作者的保守做法：同一时间只允许一个聊天写入项目，把共享记录移到合并后更新。
• 将「完成」拆成可以核对的结果，例如相关测试是否通过、目标页面是否可访问、变更是否已经合并；不要为了让任务过关而修改测试。
• 聊天持续偏离任务时，可以尝试用一份完整说明启动新聊天；共享规则集中维护，长篇说明按需读取，避免各项目副本逐渐分叉。