组织如何借助 AI 构建工作体系的参考模型
Jose Martinez · 2026 年 10 月 1 日 · v1.8.1（在 Claude Code 中实测；并于 2026 年 10 月 1 日对照 Anthropic 官方文档复核）
五句话总结。
- 组织是树状结构：公司、业务线、项目、任务。而 Claude 的项目是扁平的：聊天界面里只有一个 3,000 字符的组织指令块，聊天和 Cowork 中的项目既不能嵌套也不会继承；在一个项目中，连接器账号要么属于个人，要么属于整个组织，绝不会属于某个分支。
- 于是，每个项目都只能手动复制一份所属业务线的规则。这些副本各自演化、逐渐偏离，最后谁也说不清某条回答到底出自哪条规则。
- Anthropic 其实已经把这套树状结构做过两次了。Claude Code 按文件夹嵌套指令，而且从 2026 年 10 月 1 日起，组织的 mod 会优先于个人的 mod 执行。Slack 里的 Claude Tag 则实现了从组织到工作区再到频道的指令与凭证继承。但两者都没能延伸到“项目”这一层。同样的模型完全可以做到：加一层业务线，让项目从对应文件夹中生成，引入类型化任务，用一个在模型看到之前就拦截冲突的编译器，再配上能在 Team 版上生效的节点级权限。
- 我在 Claude Code 里测过两次。一条组织规则和一条项目规则相互矛盾，分别放在不同层级的 CLAUDE.md 里，且都没有标记为强制生效：结果项目规则 20 次全胜。把同一条组织规则用文字标记为强制执行后：它 20 次全胜。优先级是由任何编辑者都能随手改掉的措辞决定的，而不是由结构决定的。
- 这套方案今天就能跑起来。我写的一个桌面应用就是在树状结构里运行 Claude Code。它把每一层挂载为一个 CLAUDE.md，把 Claude 的能力限制在当前节点允许的操作范围内，在写入时就拒绝冲突，并把每次回答连同其依据的规则、消耗的 token 以及审核人一起记录下来。实测下来，树状结构加载的指令 token 比平铺复制少了 20–34%。
组织天生就是树状的。公司制定方针，业务线确立标准，项目把标准落实到具体工作上，任务交付最终成果。我接触过的所有质量体系都是这么搭建的，几乎所有公司的文件服务器目录也是如此：公司、业务线、年份，然后每个工作一个文件夹，用一串把所有信息都编码进去的工作编号命名。
但 AI 项目却是扁平的。我拿 Claude 举例，一方面因为它是我每天都在用的产品，另一方面因为它已经在自己的两个产品形态里给出了答案。在 Claude 聊天界面中，项目无法嵌套，组织指令只是一个最多 3,000 字符、对所有人一视同仁的文本块。在 Enterprise 版上，管理员可以按组划分权限范围；而在 Team 版上，角色作用于整个组织。无论是聊天还是 Cowork 的文档里，都没有任何机制能把指令向下传递到部门或业务线，再一路落到项目里。在 Enterprise 版上，技能和项目可以共享给某个组，但那只是分发，不是继承。
缺的就是这一层：介于组织和项目之间的那一层。本文会讲清楚到底缺了什么、为什么重要、真实的代价有多大，并给出一个任何平台都能落地的参考模型，包括它的权限设计和数据结构。
1. 现状如何
以下内容已于 2026 年 9 月 29 日至 10 月 1 日期间对照 Anthropic 官方文档核实。Claude 目前有四个承载团队工作的产品形态，每个都有自己的一套指令模型：
权限取决于订阅计划：
Anthropic 已经搭好了半棵权限树。 在 Enterprise 版上，自定义角色被分配给各个组；“自定义角色还能控制该角色可以使用哪些连接器，以及这些连接器上的哪些工具”；在整个平台上，组织、角色和用户三个层级遵循“最严格的层级优先”原则，而同一成员的多个角色权限会叠加；管理员可以“查看有效角色”，并附带“授权来源”标签；各个组还能设置独立的消费上限。但这些只是扁平的分组，不是树，而且全都没有延伸到指令层面。最接近的是插件：在 Enterprise 版上，所有者可以让某个插件及其技能对一个组设为必装或默认安装，并且有明确的优先级顺序（“先组设置，再全组织设置，最后是市场默认值”）。但这针对的是一群人，而不是一个项目；项目之间没有任何继承关系，而且技能依然只在 Claude 判断相关时才会加载。Team 版的角色面向整个组织，共享也只能逐个成员进行；用文档的原话说，它的插件设置“没有组级别配置”。而 Team 版恰恰是为中小型企业设计的套餐。
在项目之外，Anthropic 已经把整棵树搭过两次了。
在 Claude Code 里，按文件夹。 Claude Code 会从四个层级加载 CLAUDE.md 文件；“所有被发现的文件会被拼接到上下文中，而不是互相覆盖”，顺序是“从文件系统根目录一直到你的工作目录”，子目录中的文件则“按需加载”。组织层面的内容可以通过每台机器上的托管文件下发，也可以从管理控制台以文本形式推送（claudeMd 字段）。文档对此的局限性说得很直白：Claude 把这些文件“当作上下文，而非强制执行的配置”，并且“如果两条指令相互矛盾，Claude 可能会随意选择其中一条”。
在 Claude Tag 里，按 Slack 频道。 Claude Tag 就是把 Claude 接入团队的 Slack，目前在 Team 和 Enterprise 版上处于公开测试阶段。它的设置绑定在作用域上，“作用域就是配置包的生效范围：Default Slack access（全组织根节点）、某个工作区，或者单个频道。”本文后面呼吁的三件事，它已经做到了：
• 指令可继承。 “各作用域的自定义指令会拼接在一起，先是 Default Slack access，然后是工作区，最后是频道。频道的指令是对上层设置的补充，而不是替换。”
• 凭证跟着分支走。 在频道里，Claude 使用管理员绑定到对应作用域的服务账号进行操作，并且“采用最窄作用域的凭证：频道优先于工作区，工作区优先于 Default Slack access。”
• 你能看清权限的来源。 每个连接器、代码库和插件条目都会标明是“继承自”更宽泛的作用域，还是“附加自”某个配置包。消费上限按组织和频道分别设定，并按频道出具报告。
局限性同样写在了文档里。这棵树长成了 Slack 的形状：只有三个固定层级，而且 Slack 频道不能嵌套。指令只是“引导，而非强制护栏”，文档也没有提到任何跨作用域的冲突检查机制。系统“不会记录每项任务及发起人的逐操作日志”。而且它在项目边界前戛然而止：“claude.ai 中的项目不适用于此场景；Claude 在 Slack 里不会读取项目的指令或知识库，频道也无法指向某个项目。”
2026 年 10 月 1 日的更新。 Claude Code 2.1.287 正式启用了此前处于早期体验阶段的 mod：它们是插件内部的函数，运行在 Claude Code 中，可以重写提示词或系统提示词的某一部分，拦截或改写工具调用，批准或拒绝权限请求，还能在界面中绘制专属面板。其中有三点与本文密切相关：
• 它们有明确的执行顺序。 内置护栏和组织自己的 mod 最先运行，然后才是个人安装的 mod。“第一个 mod 位于最外层：它最先看到事件、最后看到结果，并由它决定其他 mod 是否执行。”在护栏生效的环境里（配置了托管设置的机器，或使用 Team / Enterprise 账号登录），个人的 mod 无法修改“系统提示词、你托管的 CLAUDE.md 以及其他托管指令”，也不能批准被拒绝规则拦截的工具调用。这就是由结构决定的优先级，也正是本文所呼吁的。但它只是默认行为，并非铁律：用 --safe-mode 启动 Claude Code 的用户不会加载任何已安装的 mod（包括组织的 mod），不过托管钩子和拒绝规则依然生效。
• 这个顺序有两个主导方。 组织的 mod 默认在个人的 mod 之前运行，但如果组织愿意，也可以放到后面。这里并没有业务线这一层。从管理控制台下发的设置“对组织内所有用户统一生效。目前还不支持按组配置。”想要为不同组制定不同策略的组织只有两条路，而且都要经过 IT 部门：给各组机器部署不同的配置文件，或者运行一个自托管网关，“按 IdP 组下发托管设置”。
• 它们进不了聊天界面，对 Cowork 的支持也不一致。 “mod 在 Claude Code CLI 和 Claude Desktop 应用的 Code 标签页中生效。”mod 随插件的 hooks/hooks.json 一起发布，而 Anthropic 的插件支持表把该文件在聊天界面中标记为“忽略”。同一张表在 Cowork 中标记为“加载”，因为“Claude Desktop 应用中的 Cowork 是在 Claude Code 上运行会话的”；但 mod 的相关页面并未提及 Cowork，我也没有亲自测试过。组织在那里的控制力更弱：在 Cowork 会话中，Claude Code“永远不会从 claude.ai 管理控制台拉取服务器托管的设置，即使用户使用 Team 或 Enterprise 账号登录也一样”，而远程 Cowork 会话根本没有设备策略可读。
正在推进的变化。 Cowork 正在并入 Claude：帮助中心现在写着“Claude Cowork 现已直接称为 Claude”，Pro 和 Max 版率先切换，而 Team 和 Enterprise 版“保持聊天和 Claude Cowork 的现状不变”。2026 年 10 月 6 日，Pro 和 Max 上新建的 Cowork 任务将迁移至云端。同时，新版项目功能已在 Pro 和 Max 上开启公测，首发于 Claude Code，聊天、Cowork、Team 和 Enterprise 随后跟进；在新版中，“一个项目就是一场对话”，由 Claude 拆分成并行线程。但它依然是单层结构：“一个项目只属于一个用户”，并且“在公测期间，项目没有组织级别的控制能力。”
所以，树状结构对 Anthropic 来说并不是新概念。它在代码里按文件夹存在，在 Slack 里按频道存在，而且在这两套体系中都是组织优先。唯独企业真正归档工作的地方——项目——既没有父节点，上面也没有业务线。Anthropic 另外两款产品也指向同一个方向，但不在本文讨论范围内：Claude for Government 通过租户、组和组织的链路来解析设置，而第三方提供商上的 Claude Desktop 正在测试按组配置策略的功能。
2. 为什么这很重要
项目不是容器。 真实的工作才是容器。它有主键（工作编号）、有父节点（所属业务线）、有生命周期（开启、关闭、按年归档）、有文件夹、有客户、有人员、有规则和交付物。而一个 Claude 项目只有一个自由文本名称，没有主键，没有父节点，没有子节点，文档里提到的生命周期也只有归档和删除。Cowork 可以把项目绑定到本地文件夹，但只能手动操作、一次一个，既没有编号规则，也没有父节点。一条业务线一年可能开启数百项工作。这就只剩下两个糟糕的选择：要么为每项工作手工建一个 Claude 项目，每个都复制一份规则；要么每条业务线只用一个项目，让不同客户的上下文挤在一起。
传力路径断了。 在结构工程里，每一笔荷载都需要一条连续通往基础的路径。抽掉一根构件，上面的力就传不下去。规则也是一样。当组织和项目之间缺少一层时，业务线的标准、模板和审批规则就无处安放。于是每个项目只能拿到一份手工复制的副本。
副本会漂移。 你在一个项目里修正了某条规则，其他项目还在用旧版本。每个项目依然能通过自己的本地检查。这种不一致只有在有人把项目放在一起对比时才会暴露，而在受监管的行业里，这个人通常是审计员。基础设施团队对这种故障再熟悉不过了。Firefly 2026 年的调研显示，约三分之一的受访者认为配置漂移导致了高昂的生产事故，约五分之一的人根本没有检测或修复它的流程。
身份也是扁平的。 很多人同时在多个组织里工作，每个组织都需要一套隔离的上下文。但在任何一个组织内部，无论是在聊天还是 Cowork 中，连接器账号都属于个人，而不属于分支。Enterprise 版的角色可以决定某个组能用哪些连接器，管理员也可以一次性为整个组织授权某个连接器；自定义连接器甚至可以为所有人共用同一个凭证（测试中）。无论哪种方式，账号要么是员工的，要么是组织的，绝不会是某个分支的：一位同时服务两个客户的顾问，没法把每个客户的 Drive 分别绑定到对应客户的项目上。共享项目让问题更尖锐：“连接器仅在私有项目中可用。”Claude Tag 证明了另一种设计是可行的——把服务账号绑定到 Slack 频道——同时也暴露了它的边界：止步于项目。Anthropic 的 Google 连接器页面只描述了一个已连接的 Google 账号，文档给出的更换方法是断开再重连；下面列出的三个公开 issue 都在要求支持多账号。边界全靠员工自己记着，而这恰恰是最容易悄无声息失效的人工防线。
没人知道究竟是哪条规则起了作用。 Claude Enterprise 会给管理员提供“查看有效角色”的权限视图，Claude Code 的 /context 会列出加载了哪些记忆文件。现在 Claude Code 的 mod 可以绘制自己的面板，所以任何人都能在那里搭出一个“有效指令”视图。Claude Tag 会给每个连接器和代码库标上继承自哪个作用域，但对于指令，文档的建议是“让 Claude 复述它的管理员指令”。没有任何一个产品形态能告诉你：针对某条回答，哪条指令来自哪一层。没有溯源就没有审计轨迹，没有审计轨迹就没有质量体系。
大家已经在提这些需求了。 以下是 Anthropic 公共 issue 跟踪器（github.com/anthropics/claude-code）中的未解决 issue，查询日期 2026-10-01：
第七个 issue #47741 曾要求提供由组织托管的 CLAUDE.md，但因为 Claude Code 已经具备该功能而被关闭。这正是关键所在：这些层级在 Code 和 Slack 里都已经存在，而这些 issue 要求的，是把它们带到项目所在的地方。
3. 代价是什么，token 又掩盖了什么
3.1 Token 并不是障碍
层级越多，每条消息携带的上下文可能就越多，而 AI 是按 token 计费的。这个解释只对了一半。在按量付费的 Enterprise 计划中，用量按 API 费率计费，所以更多上下文意味着更多收入，而不是更少。在 Team 版上，席位费是固定的（除非开启了超额用量），额外的 token 只会让成员更快触及每周上限。而同样按 token 计费的 Claude Code，早就上线了四级级联。如果 token 真是障碍，它根本不会存在。3.2 节的实测数据显示，在加入我们自己的任何指令之前，Claude Code 自身的系统提示词和工具大约占 30,200 个 token；一个项目的完整指令只在此基础上增加了 3.5–5.2%。
3.2 一个计算示例
每张图表上的标签含义：REAL = 在 2026 年 9 月 29 日至 10 月 1 日期间实测，或对照 Anthropic 文档核实；EST = 模拟得出；IND = 示意性数据。
先看实测。 我用同一个问题在 Claude Code（claude -p，Claude Sonnet 5.5）中对一个演示项目进行了测试，每种条件跑五次，取 Claude Code 自己报告的输入 token 数。我在 9 月 30 日用 Claude Code 2.1.286 跑了一遍，10 月 1 日又用 2.1.287 跑了一遍；指令 token 数完全一致。减去一次完全不加载项目指令的运行结果，剩下的就是每种布局的真实成本：
下面的模拟无法体现两件事。第一，对于相同的规则，级联加载比编译后的单文件多出 224 个 token：每多一个文件就多一份开销，在这里表现为应用自身在每层文件里插入的标记和标题，加上 Claude Code 为每个加载文件添加的包装。层级越多，开销越大。第二，即便按 × 1.30 换算，Claude Code 实际加载的 token 仍比公开分词器的估算高出 21–26%；这部分差距里有一些正是上述单文件开销。比例关系不受影响，但绝对金额会失真，所以请把模拟得出的美元数字看作下限。
再看公司规模的模拟。 我为一家示意性公司模拟了一个月的指令 token 消耗：3 条业务线共 40 人，250 个活跃项目，每条业务线 6 种报告模板，每人每个工作日在长度为 5 轮的会话中发送 35 条消息，总计 29,400 条消息。Token 数量是用 Anthropic 公开的旧版分词器对示例指令文本统计得出的（Anthropic 自己也称它对 Claude 3 及后续模型“只是非常粗略的近似”），再按 1.30 倍放大以适配 Claude 4.7+ 的分词器。组织指令块是从 597 字符的样本外推到 3,000 字符上限，业务线手册则是 953 字符样本的三倍。价格采用 Claude Sonnet 5.5 的官方定价（输入 $2，5 分钟缓存写入 $2.50，缓存读取 $0.20，均按每百万 token 计）。提示词缓存有效期五分钟，每次命中都会刷新。
• 扁平结构（目前的变通做法）： 组织指令块，加上每个项目自行复制的业务线手册、全部六份报告模板以及项目特有信息。
• 树状结构： 组织、业务线、仅当前使用的报告模板，再到项目特有信息，按共享度从高到低编译。
表格背后的数值：组织指令块 830 个 token（3,000 字符），业务线手册 729，单份报告模板 147，项目特有信息 98（已取整；合计值在取整前计算）。模拟未计入位于组织指令块之前的 Claude 自身系统提示词。
两点必须说明的局限。首先，树状结构本身并不省 token。−29% 的收益来自类型化任务：只加载正在撰写的报告对应的模板，而不是全部六份。−62% 主要来自把共享度最高的层级编译在最前面，这样数百个项目就能共用一段字节级完全相同的前缀：即使仍然加载全部六份模板，仅靠调整顺序就能把共享缓存的成本从 $36 降到 $18（−51%），剩下的节省由类型化任务贡献。但第二种节省的前提是缓存能在用户间共享。在 Claude API 上，缓存在组织之间是隔离的，在同一组织内按工作区隔离，因此相同前缀可以在一个工作区的多次请求间复用；而 claude.ai 并未对此作出说明。在目前发布的 Claude Code 中也做不到这一点：在那里“缓存实际上限定在一台机器的一个目录下”，所以两个人在两个项目文件夹里工作时，彼此用不上对方的缓存。请把最后一列理解为聊天界面原生支持该层级后可能带来的收益，而不是今天就能用的东西。一个合理的反驳是：技能已经是按需加载了，所以把工作区里的模板搬进技能，今天就能吃到 −29% 的一部分红利。但技能在聊天和 Cowork 中缺的是作用域和继承：一个技能无法只属于某条业务线，并自动向下流入该业务线的所有项目。（在 Claude Code 中，子文件夹里的技能确实会为在该目录或其下级目录启动的会话加载。）其次，这里只算了指令 token，在这个规模下，根据缓存情况每月花费在 $14 到 $149 之间。真正账单的大头是历史对话和输出。支持树状结构的有力理由在于正确性，以及在 Team 版上的容量，而不是那张发票。
上面的实测在真实的树状结构中（在 Claude Code 里）复现了类型化任务的效果，用的是真实数据而非假设体积：级联方式减少 −20%，编译方式减少 −34%，而模拟结果是 −29%。如果一条业务线只有一种任务类型，类型化任务就省不下任何东西。
3.3 同一个答案，来自真实的 Claude
我把同一个问题问了 Claude Code 四十次：四种条件下各十次独立回答，分两批进行，间隔一天。问题是：路基压实度检测是否合格，实测值 112.3 pcf，最大干密度 115.8 pcf，要求达到 98%。指令要么是公司的六条规则，要么是一句“乐于助人的助手”提示词；语言要么是英语，要么是西班牙语。四十个回答得出了完全一致的结论：97.0%，不合格。
Claude Code 会报告两个输出数字：计费的 token 数，以及其中有多少是读者永远看不到的思考过程。
四个发现：
• 公司的规则让屏幕上的回答长了 1.4 倍，账单上的长度则是 1.8–1.9 倍。 多出来的可见内容是规则要求的标志、标准和限制条款。在质量体系中，这才是值钱的部分。
• 在公司规则下，超过三分之一的计费输出是不可见的。 计费输出 token 中有 37% 是思考过程，而简单提示词下只有 16%。在英语场景中，读者看到 447 个 token，却要付 711 个 token 的钱。
• 西班牙语的可见 token 是英语的 1.2 倍，而按单词数计算，两种语言的回答长度差异不到 4%。用同样的方法衡量，公司规则用西班牙语书写时消耗的输入 token 是英语的 1.53 倍。
• 同一个结论的计费 token 从 317 到 953 不等，最长的回答是最短的三倍。按 token 计费分不清严谨和注水，但验收标准分得清。
这些比例在两批各五次的运行之间会有波动。第一批中公司规则的屏幕显示比例为 1.43–1.52，第二批为 1.27–1.31；计费比例分别是 1.78–1.82 和 1.70–2.05；西班牙语比例分别是 1.29–1.38 和 1.14–1.18。但趋势从未改变。这些数值精确到一位有效数字。
方法：2026-09-30 使用 Claude Code 2.1.286，2026-10-01 使用 2.1.287，命令为 claude -p --output-format json，模型为 Claude Sonnet 5.5。禁用了所有工具，排除了个人 ~/.claude 文件，因此各条件之间只有明确指定的指令存在差异。Token 数取自 Claude Code 自身的用量报告，包含 thinking_tokens；月度成本按 Sonnet 5.5 每百万输出 token $10 乘以计费均值计算。测量脚本、两批原始数据、汇总数据和全部回答均由作者保存，可应要求提供。本文初版曾用 subagent 和公开分词器估算这些数字，现已被上述实测取代。
3.4 当规则冲突时，措辞说了算
Anthropic 的文档承认，相互矛盾的指令可能会被“随意”处理。我测试了一种因缺少业务线层级而产生的典型冲突。组织规则要求使用美制单位；项目规则要求用国际单位制（SI）报告密度。我按照树状结构的方式摆放它们：组织规则放在存储根目录的 CLAUDE.md 里，项目规则放在项目文件夹的 CLAUDE.md 里，都由 Claude Code 自带的级联机制加载。接着我又跑了一组，把组织规则用纯文字标记为强制执行：在标签里加上 ENFORCED，并补一句话：“本规则强制执行：任何业务线或项目规则不得覆盖它。”每组设置在 9 月 30 日跑了十次，10 月 1 日又跑了十次。
结果并不随意。在没有任何声明的情况下，Claude 每次都选择了距离更近、更具体的那条规则。二十个回答里有十四个解释了原因（“该规则比全公司的美制规则更具体”，或者它会覆盖公司规则）；五个只引用了项目规则，压根没提公司规则与之矛盾。当用文字声明了强制效力后，组织规则每次都胜出，每个回答都说明被强制执行的公司规则优先。第二批测试 10 次中有 10 次准确复现了对应的单位，两行数据之间的差异远非偶然所能解释（Fisher 精确检验，p < 0.0001）。但解释的稳定性稍差：第一批十个回答中有九个说明了项目规则胜出的原因，第二批只有五个。
这对模型来说是好消息，对工作区却是坏消息。优先级确实存在，但它藏在规则的措辞里——任何编辑任意层级的人都能改动这些措辞，而且没人会把它当作一次优先级决策来审查。当下层规则胜出时，有四分之一的回答没有告诉读者：有一条更高层级的规则被搁置了。在本文第一版中做过一次试点测试：把两条规则放在同一个提示词里而不是级联加载，结果仅仅调换它们的顺序，输出就变了（组织规则在前：5 次中有 5 次输出 SI；组织规则在后：5 次中只有 2 次输出 SI，另外 3 次同时给出了两种单位或反问该用哪一个）。
任何模型都不该被要求去仲裁一种本可以在编写规则时就由组织自己拦截的冲突。Claude Code 给出了两个不完整的解法。当用户手动运行 /doctor prompt-audit 时，它会请 Claude 查找相互矛盾的指令文件。而自 10 月 1 日起，mod 可以在代码层面强制执行顺序：组织的 mod 先于个人的 mod 运行；当内置防护生效时，deny 规则优先于个人的 mod。但两者都没有覆盖指令文本本身。指令文件依然是拼接在一起的，文档对结果的描述也有三种说法：Claude “可能随意选择其一”；当用户规则与项目规则冲突时，“Claude 可能遵循其中任意一条”；以及“当指令冲突时，Claude 会自行判断如何调和”。这里的二十次全中，就是这种“判断”的实际表现。Claude Tag 为它的三个作用域声明了一个顺序，并把结果称为“指引，而非强制护栏”。参考实现的校验会在任何内容到达 Claude 之前，直接拒绝这种改动：“R-22 sets units.density=SI; R-01 (org:firm) enforces US”，而且 enforced 是规则上的一个字段，不是规则里的一句话。
指令密度让情况更糟。在 IFScale 基准测试（2025）中，Claude Sonnet 4 的准确率从 10 条并发指令时的 100% 跌到了 500 条时的 42.9%。
3.5 用算力或能耗作为计量单位会更公平吗？
在同一个模型内部，token 是算力的合理近似：token 越多，硬件干的活确实越多。这也正是为什么按算力或能耗定价无法消除语言惩罚。西班牙语更贵，是因为分词器对它的压缩率更低，而那些多出来的 token 对应着真实的算力消耗。真正的解法是更好的分词器，或者按内容归一化后的计量方式。
归一化的算力单位依然能在三个方面带来帮助。它让不同模型和供应商之间可以比较。它是物理可度量的、可报告的，比如用于可持续发展报告。而且如果系数是相对于参考硬件固定的，供应商就能保留自身效率提升带来的收益，这才是正确的激励方向。这有先例：云厂商曾经销售过归一化单位，比如 EC2 Compute Unit。
但它也有现实问题。没有标准和审计方，客户就无法验证。实际能耗取决于硬件、数据中心效率、批处理和电网状况。而 Anthropic 并不公布每次请求的能耗；我只找到了第三方估算。最重要的是，算力仍然只是投入，它无法说明答案是否正确。
我的结论是分成三个独立层次：
- 计费使用 token 或归一化算力单位。
- 披露每个任务和每个节点的能耗。
- 管理依据“每个已验证成果的成本”。
对于 Team 方案，最低限度的一步是用明确的单位公布每周限额。每次会话的额度被表述为“Pro 方案每次会话使用额度的 1.25 倍”；而每周限额根本没有公布具体数字。这两者都没法做预算。
正如 FinOps Foundation 所说：“token 是计费单位，不是价值单位。”层级结构才让价值变得可定义，因为验收标准需要依附于它。
3.6 它还没被造出来的更可能原因
- 隐式优先级。 Anthropic 自己的文档也承认，直接矛盾的指令会产生不一致的行为，而 3.4 节表明，优先级完全跟着规则的字面措辞走。层级叠加会让冲突成倍增加，而指令遵循能力会随密度下降：在 IFScale 基准测试（2025）中，即便是测试中表现最好的模型，面对 500 条并发关键词指令时准确率也只有 68%（即 3.4 节引用的同一基准）。
- 权限继承。 如果知识沿树向下继承，访问控制也必须继承。这意味着要在每一层下面重建权限模型。
- 偏好记忆与检索，而非静态层级。
- 面向消费者的极简主义。 代码工具天然从文件系统继承一棵树。聊天产品却得自己发明一棵。
Anthropic 并未公开说明为什么 Claude 聊天和 Cowork 缺少层级结构。本节所有内容都是基于已发布功能的推断。
4. 参考模型
这套设计借鉴了已经解决过该问题的系统：云资源层级（AWS Organizations、Google Cloud Org Policy、Azure 管理组）、目录策略（Active Directory Group Policy），以及 Claude Code 自身的 CLAUDE.md 级联。节点之间的关系只用五个词表达：contains（包含）、inherits（继承）、uses（使用）、sealed（密封）和 shared（共享）。
4.1 挂载组织已有的那棵树
别让人在 AI 工作区里重新搭建一遍组织架构。文件服务器或文档系统已经是单一事实来源。选一条路径即可：
项目编号 26GT301 本身已经编码了这棵树：年份、业务线、序号。工作区应该挂载这个结构，而不是复制它。
4.2 承载规则的节点、分组节点、项目与任务
• 承载规则的节点：组织、业务线、项目、任务。每个节点都携带同样的三样东西：上下文（指令与知识）、策略（允许使用哪些工具、数据和连接器）以及身份（绑定到该节点的连接器账号）。
• 分组节点：系列、年份、区域。它们不携带任何规则。它们的存在是为了导航、保留和生命周期管理。把它们分离出来，可以让规则树保持较浅的深度——三到四层，正如微软自己对管理组的建议那样（“不超过三到四层”）。
• 项目是一个带键的容器。 它会自动创建：当出现一个匹配业务线键模式的文件夹时（例如业务线根目录下的 {YY}GT{NNN}_{Name}），就会创建一个项目节点，它继承自所属业务线，并获得仅作用于该文件夹的连接器访问权限。它只保存与业务线不同的部分：成员、客户、规格说明。它的状态会从“开启”流转到“关闭”，再到“归档”（图 2）。
• 任务是有类型的。 类型来自业务线的目录（一份密度报告、一份钻孔日志）。类型自带模板和验收标准。产出物会按公司的命名规范归档回项目文件夹，并由审核人验收。技能（Skills）是今天 Claude 最接近“任务类型”的东西。在 Enterprise 上，它们可以与某个群组共享，但那只是分发，不是继承：没有任何东西会沿着分支向下流动。
这种递归是有意为之的。Stafford Beer 的可行系统模型（Viable System Model）说得很直白：“在递归型组织结构中，任何可行系统都包含另一个可行系统，同时也包含于另一个可行系统之中。”
4.3 一个主父节点，加上叠加层
Christopher Alexander 在 1965 年提出“城市不是一棵树”。真实结构是相互交叠的。一个客户、一家机构的规格说明或一种任务类型，可能横跨多条业务线。因此每个节点只有一个主父节点，而跨领域的规则集则以叠加层（uses）的形式附加。冲突的解决方式每次都一样：deny 优先，否则最近的节点优先。
4.4 两条通道，两套语义
这是设计的核心，也是大多数层级结构出错的地方。
• 上下文是拼接的。 指令和知识从根向下合并，就像 CLAUDE.md 的做法。
• 策略默认拒绝。 只有当从根开始的整条路径上都存在 allow 时，某个工具或连接器才被允许；而上层任何一处显式的 deny 都会胜出，就像 AWS Service Control Policies 那样。父节点可以把某条规则标记为 enforced，这样任何子节点都无法阻止它，如同 Group Policy。
把两者混为一谈是经典错误。建议性的上下文应当融合。强制性的执行则不应如此。
4.5 在模型读取之前先编译
今天，冲突的指令是由模型在生成答案时解决的。解法是一个有效指令编译器，在模型看到任何内容之前运行：
- 从根到叶合并上下文。
- 应用策略：deny 优先，且 allow 必须在整条路径上都成立。
- 遵守来自父节点的 enforced 规则。
- 给每条规则打上 ID 及其所属层级的标记。
- 按各部分的共享范围对整个块排序，并为每一层设定 token 预算。
冲突永远不会走到这一步：它们在更早阶段、也就是规则被编写时就会被拒绝，而且审批人不能是作者本人（图 3，下方泳道）。
由于冲突在编译期就已解决，输出可以按各部分的共享范围排序，而不必严格按深度排序：组织、业务线、任务类型模板，最后是项目特有内容。这样的顺序能最大化缓存命中（3.2 节）。它可以映射到 Anthropic 的四个缓存断点上，每层分配 token 预算，不过实践中可能需要留一个断点给对话本身。
4.6 身份绑定到分支，而非个人
连接器身份（账号、租户、作用域）绑定到节点，而不是人。Claude Tag 在 Slack 频道上已经这么做了：管理员把一个服务账号绑定到某个作用域，作用域最窄的那个凭证胜出。这里的模型要求在下一层实现同样的事，即在业务线及其项目上。一个人在两个组织中工作，就有两棵密封的树；他切换的是树，而不是账号。除非两边的所有者显式共享，否则任何东西都不会在两者之间流动。技术原语已经存在：MCP 授权规范使用了绑定受众的 OAuth 令牌（RFC 8707 资源标识符、RFC 9728 受保护资源元数据），并要求服务器“不得接受或转发任何其他令牌”（规范版本 2026-07-28）。
4.7 权限跟随树结构
主体： 人员、群组、服务账号、外部访客（例如客户），以及 agent 本身。
agent 的权限永远不超过调用者或节点。 Claude 以调用用户的权限与该节点策略的交集行事。它不能修改规则或权限，只能提出变更建议。（今天，Claude 可以自行更新 Cowork 文件夹的指令。在这个模型里，这会变成一个需要他人批准的提案。）
求值。 授权只向下流动，绝不向上或横向。一个节点的有效权限，是其路径上各角色所授予的权限、在整条路径策略允许范围内的部分，再减去上层所有的 deny。叠加层只授予对其自身内容的访问权：读取一份规格说明并不会打开使用它的那些项目。
生命周期。
• 开启（Open）： 角色按授予方式生效。
• 关闭（Closed）： 不再新建任务，但待审的评审可以完成。
• 归档（Archived）： 对所有人只读；只有所有者能恢复，且恢复操作会被记录。
• 密封树（Sealed tree）： 没有显式共享，任何东西都无法跨越。
例外与委托。 例外必须有时间限制和正当理由，并由申请人之外的人批准。它们会自动过期并被计数，因为每一次覆盖都会形成一个永久的维护孤岛；SharePoint 的继承中断上限就是前车之鉴。委托授予的权限永远不能超过委托人自身拥有的权限。所有者的紧急访问（break-glass）机制存在、始终被记录，并在事后接受审查。
在 Team 上， 即使没有群组也能运作：授权存在于节点上，所以一个只有四种角色的组织依然能获得按分支划分的权限。
4.8 各层如何交互
只有当变更能在树中传递时，构建树才有意义。三种交互承担了大部分工作（图 5）：
• 向下推送。 业务线负责人发布了规则的新版本。该业务线下的每个项目在下一次编译时都会读取它。已获批的例外会在到期前继续使用旧版本，而已归档的产出物保留其生成时所用的版本。
• 向上拉取。 某位成员在一个项目中改进了模板并提出建议。由业务线负责人（而非提议者）批准，随后同级项目会继承它。而在今天，这种改进只会留在发生它的那个项目里。
• 横向。 某机构规格说明只改动一次。三条业务线中的项目用它重新编译，而业务线本身不变。若与业务线规则冲突，在写入更新时就会被拒绝。
一次请求就能同时展现所有层级（图 6）：树检查成员的授权和项目状态，编译器构建指令块，Claude 通过限定在该项目文件夹作用域内的身份读取现场数据，把带类型的产出物归档回文件夹，再由一位未参与编写的审核人验收。每一步都会落入日志，成本计入项目键。
4.9 数据结构
配置是事件驱动的：在业务线的 storage_root 下出现一个匹配 key_pattern 的新文件夹时，就会创建项目节点。answer_log 为每个答案提供溯源，并记录每个节点的成本。
4.10 衡量成果，而非 token
每种任务类型都带有验收标准：即“完成”的定义。有了这些，AI 工作的更好计量单位就变得可测量了：
每个已验证成果的成本 =（token 成本 + 评审时间）÷ 已验收交付物
因为每个答案都记录在某个节点下，AI 成本可以像人工和材料一样计入项目键。部分能力已经存在：Claude Tag 可以报告并限制每个频道的支出，而 Claude Code 的遥测数据也可以手动按部门、成本中心或仓库打标签。但没有一个是按项目键关联的，也没有一个会除以已验收交付物。对于按项目编号计费的机构来说，AI 会变成直接项目成本，而不是间接费用。在工程领域，你为经过校核、盖章的交付物付费，而不是为铅笔芯付费。AI 工作也该用同样的方式衡量。
4.11 回应质疑
“技能和插件已经在做这件事了。” 技能是在 Claude 判断相关时才加载的，这只是相关性，不是保证。配置会把一项技能赋予所有人；在 Enterprise 上，携带该技能的插件可以被设为某个群组的必需项。这是今天聊天和 Cowork 中最接近“业务线”的东西，但它在三方面不足：仅限 Enterprise、针对人而非项目、且没有任何东西能从业务线流向其项目。一条必须在某业务线内始终生效的规则，不能依赖相关性检测。
“Mods 已经在做这件事了。” 在 Claude Code 中算是部分实现了，自 2026 年 10 月 1 日起。mod 可以重写系统提示词、拒绝工具调用并绘制面板，而且组织的 mod 先于个人的 mod 运行。因此本文中的编译器、写入时校验和有效指令视图，今天都可以做成一个 mod，第 6 节也会提到这一点。但仍存在三个限制。mod 不会在 Claude 聊天中运行，而在 Cowork 中，组织的控制台设置并不生效。它们的顺序有两个所有者——组织和个人——中间没有业务线这一层；在 Enterprise 上，某个群组必需的插件可以把 mod 带给该群组，但它会作为个人自己的 mod 之一运行，没有优先级。而且 mod 是非沙箱代码：要跑在个人 mod 前面，组织的 mod 必须位于每台机器的某个目录下，而从管理控制台下发的设置“无法把目录放到机器上”。没有设备管理的公司可以把 mod 推送给所有人，但它会混在个人自己的 mod 中运行，而不是排在它们前面。一家公司不该为了说明某个部门要用不同单位汇报，就得去写 TypeScript。
“记忆会学会这些规则。” 记忆主要由 Claude 为某个人或某个项目写入，而所有者无法读取或编辑成员的记忆。审计人员需要的规则必须由人编写、有版本、经审批，并可追溯到每个答案。Anthropic 已经把这套机制做过三次了：权限方面有“查看有效角色”及其“授予者”标签；技能和插件有版本历史和一个“你不能批准自己提交的内容”的审核步骤；Claude Tag 的访问控制有“继承自”标签。而项目中的指令三者皆无。
“Claude Tag 已经在做这件事了。” 对 Slack 频道而言基本如此，第 1 节也提到了。但还缺三样东西。频道不是项目：它没有文件夹、没有键、没有生命周期，而且“频道无法指向一个 Project”。树只有三个固定层级，于是拥有业务线和数百个项目的公司不得不把其中两层压扁进频道名称里。文档也没有描述在写入指令时进行冲突校验的机制；各作用域被拼接起来，留给模型自己去调和。如果说有什么证据，Claude Tag 恰恰是本文设计最有力的佐证：同一家公司在为团队构建产品时，选择了继承、作用域绑定的凭证和来源标签。
“层级会增加复杂度。” 只有在深度不受限时才会。微软自己对管理组的建议就是“不超过三到四层”。本模型固定了四个承载规则的层级，而系列、年份等分组文件夹根本不携带任何规则。
“继承是安全风险。” 如果访问控制被随意继承，确实是。云的答案同样适用：每一层都必须存在 allow，任何一处的 deny 都会胜出，Claude 以用户权限与节点权限的交集行事，而 Claude 自己对规则的修改会变成提案。
“更多层级意味着更多 token。” 3.2 节在 Claude Code 中测出的结论恰恰相反：相比平铺复制，级联方式减少 20% 的指令 token，编译方式减少 34%。每多一个文件确实会带来一点开销，所以编译优于级联。带类型的任务会丢弃未使用的模板，编译后的前缀在不同项目间字节级一致，因此提示词缓存可以复用它们。在 Claude API 上，缓存是按工作区隔离的，所以每个组织一个工作区正好映射到树的根节点。今天的 Claude Code 还做不到：它的缓存作用域限于单台机器和单个目录。
“团队自己维护自己的项目就行了。” 这就是今天的变通做法，而第 5 节的原型测量了它的结果：在一个小演示中，六份粘贴副本里有两份已经过时。
5. 它今天就能跑：一个参考实现
为了证明这个模型是可以造出来的，而不只是可以争论的，我构建了 Worktree——一个小型桌面应用（Node 加 Electron，在 Windows 和 Linux 上通过 24 项测试），布局类似 Claude Desktop。上面的视频是它的真实运行过程，只在 Claude 工作时做了剪短。它是一个独立应用，从外部驱动 Claude Code，而不是一个 mod。它不调用自己的模型。每次聊天都运行电脑上已安装的 Claude Code（claude -p），并使用 Claude Code 当前的登录方式：Claude 订阅或 API 密钥。我用一家虚构的公司进行了测试，包含三条业务线和六个项目。当有人发送消息时：
• 许可。 操作者需要在该项目或其上层拥有授权，且项目必须处于开启状态。一位在该业务线上没有授权的管理员，在 Claude 启动前就被拦下了。
• 校验。 写入时校验最先运行。3.4 节中的 SI 规则因与一条 enforced 的公司规则冲突而被拒绝，因此它永远不会进入任何 CLAUDE.md。
• 挂载。 树被写入真实的项目文件夹，每层一个 CLAUDE.md（存储根目录处是组织，然后是业务线，再是项目），由 Claude Code 自身的级联机制加载。编译模式则改为每个项目只写一个文件。没有本应用标记的文件绝不会被覆盖。
• 运行。 任务模板通过 --append-system-prompt-file 传入。Claude 可以做什么由 Claude Code 强制执行，而不是靠 CLAUDE.md：--allowedTools 是个人角色与各层策略的交集，写入被限制在项目文件夹内，而 --permission-mode dontAsk 会拒绝其他一切操作。在真实运行中，一次网页搜索被拒绝了，因为该业务线的策略不允许 web；一次向项目文件夹外的写入也被拒绝并记录在案。
• 日志与评审。 每个答案都会记录操作者、节点、所有规则标签、Claude 引用的规则，以及 Claude Code 上报的输入、缓存和输出 token。由未编写该答案的评审人决定验收或退回。演示中一次真实的密度报告运行耗时约 30 秒；在三次运行中，Claude Code 按标价上报每次回答花费 $0.08–0.22。Claude 引用了它所应用的规则，标出了接近验收限值的结果，并把工程师字段留空。
• 漂移。 每个挂载的 CLAUDE.md 都会与树进行比对，手工修改会被标记。一个更早的命令行原型对粘贴到平铺项目中的副本做了同样的比对，发现六份中有两份已过时：一份仍停留在 R-07 v3，另一份有一条规则被手工删除了。
构建过程中的三点发现，对所有在 Claude Code 上分层指令的人都有参考价值：
- 你的个人指令会泄漏到组织的运行中。 默认情况下，每次运行还会加载我个人的
~/.claude/CLAUDE.md、规则、agents 和 MCP 服务器。现在该应用通过claudeMdExcludes设置加上--strict-mcp-config排除了它们。在我的机器上，这把一次运行的上下文从 29.6k 降到了 21.4k tokens。看似明显的替代方案--setting-sources project,local，在 Windows 上的 Claude Code 2.1.284 中起到了反效果：它保留了个人文件，却丢掉了承载组织和业务线的父文件夹 CLAUDE.md 文件。
- 个人的 mod 也会泄漏进来。 mod 是在这个应用构建完成后第二天推出的，于是我做了测试。我在自己的用户作用域安装了一个单 hook 的 mod，会给每个提示词加一行。它进入了应用的运行：组织的三条规则被加载了，我个人加的那一行也被加载了，而且答案遵循了它。在运行设置中加入
disableAllHooks可以把它挡在外面，同时保留三层 CLAUDE.md 完整；应用现在就是这么做的。--safe-mode不能替代它：它会把 mod 连同整个 CLAUDE.md 级联一起移除。按照文档说明，在个人自己的设置中使用disableAllHooks会让组织管理的内容继续运行。
- CLAUDE.md 是上下文，强制执行是配置。 Anthropic 的文档写道：“设置规则由客户端强制执行，无论 Claude 决定做什么。CLAUDE.md 指令塑造 Claude 的行为，但不是硬性执行层。”本应用正依赖于此。规则必须保证的一切都被映射为工具权限；CLAUDE.md 中的一切都是带标签的指引。
它能在今天的 Claude Code 上运行，编译后的文本也可以粘贴到任意方案的聊天或 Cowork 项目指令中。有一个依赖可能会过时：该应用依赖 claude -p 加载 CLAUDE.md 文件，而 Anthropic 文档称会跳过这些文件的 --bare “将在未来版本中成为 -p 的默认行为”。等那一天到来，应用就得用另一种方式传入这棵树；编译模式和 --append-system-prompt-file 已经能做到。它是原生版本的可用规范，而不是安全边界：“acting as”只是一个演示开关，不是登录。
6. 从已有功能出发的演进路径
现在，在 Claude Code 中。 自 10 月 1 日起，这棵树可以作为 mod 发布：将节点的规则编译进系统提示词的一个段落，拦截节点策略所拒绝的工具调用，并在面板中绘制出实际生效的指令。组织可以在任何个人安装的 mod 之前运行该 mod。我还没有实现它；它是参考实现路线图上的第一项。它将覆盖 Claude Code，也可能覆盖用户机器上基于同一引擎运行的 Cowork 会话，但不会覆盖聊天功能。
面向聊天和 Cowork 的 30 天版本。 Anthropic 已经具备了所需的组件。让一个项目指定一个父项目并继承其指令，就像 Slack 频道在 Claude Tag 中继承其工作区的指令一样。按顺序编译两者，为每条规则打上标签，并在现有的“查看生效角色”（View effective role）旁边增加一个“查看生效指令”（View effective instructions）面板。仅这一步，就能让每个业务线都有一个统一的地方来存放自己的规则。
之后，每一步本身都有价值，从对 Team 计划有帮助的部分开始：
- 业务线节点与关键模式配置，复用已经在代码中生效的 CLAUDE.md 语义。在 Claude Code 本身中，匹配步骤是介于组织 mod 和个人 mod 之间的群组层级，以及按群组管理的设置。
- 任务类型作为限定在某个业务线内的技能，并附带验收标准。
- 写入时冲突检查，让矛盾由树结构直接拒绝，而不是交给模型去仲裁。
- 节点授权，在没有群组的 Team 上可用，并可扩展 Enterprise 的自定义角色。
- 绑定到分支的连接器身份用于项目，就像 Claude Tag 已经把服务账号绑定到 Slack 频道那样。
- 按节点计费并以项目为键，正如 Claude Tag 已支持按频道统计；以明确单位公布的每周限额；以及每项任务的能耗披露。
7. 局限性
• 覆盖范围。 2026 年 10 月 1 日，code.claude.com/docs 和 claude.com/docs 的完整页面索引按标题进行了梳理（共 466 页），并阅读了约 150 页，同时引用了此处列出的帮助中心文章。本文的早期版本完全遗漏了 Claude Tag；当前版本可能也遗漏了其他内容。文中提到了面向政府的 Claude 以及在第三方提供商上运行的 Claude Desktop，但未作分析。
• 平台功能每月都在变化，撰写本文期间就有一项发生了变动。文中的每一项产品声明均标注于 2026 年 9 月 29 日至 10 月 1 日之间，依赖前请务必重新核实。Mods 才推出一天；我阅读了它们的文档并测试了一个用例，尚未在生产环境中使用。
• 第 3.1–3.4 节中的实测数据来自 Claude Code 自身的使用报告，分两批采集：2026-09-30 的 Claude Code 2.1.286 和 2026-10-01 的 2.1.287，两者均使用 Claude Sonnet 5.5。脚本、两批数据及所有回答均由作者保存，可应要求提供。数据包含 Claude Code 自身的提示词（约 30,200 个 token），而 claude.ai 和 Cowork 并不共享这部分内容；且仅涵盖一个模型、一个演示项目和一个问题。样本量较小：回答长度测试每种条件 10 个回答，冲突测试每种条件 20 个回答。两批数据之间回答长度比例发生了变化（第 3.3 节）；相隔一天的两批数据还存在 Claude Code 版本差异，我无法将其与随机波动区分开来。
• 第 5 节中的运行时间、成本和上下文大小来自应用自身的回答日志，包括三次演示运行和一次手动隔离测试，均为作者的自有记录。
• 冲突回答由作者在非盲态下编码，逐条阅读每个回答（是否报告了计量单位；回答是否说明了哪条规则胜出及原因；是否进行了追问）。全部 40 条均可应要求提供以供重新编码。测试仅使用了“enforced”的一种表述；其他表述、模型和规则组合的表现可能不同。
• 第 5 节中的 mod 测试仅涉及一个带有一个 hook 的 mod，在一台 Linux 机器上使用 Claude Haiku，通过订阅账号登录，且未启用托管设置。我没有测试组织的策略 mod、Team 或 Enterprise 登录下的内置防护，也没有测试桌面端应用。
• 第 3.2 节中的成本模型是对一家示例公司的模拟，并非实际账单数据。它只计算指令 token；而在真实账单中，对话历史、输出和思考通常占大头。其 token 数量采用 Anthropic 公开的旧版分词器 × 1.30；在实际测量中，Claude Code 加载的量比该估算高出 21–26%，因此其美元数值偏低。其中的百分比为比值，结论成立。会话模式和缓存共享属于假设。
• Enterprise 上的聊天用量是否享受 API 缓存定价，以及 claude.ai 上的缓存是否在用户间共享，均无文档说明。Cowork 在 Claude Code 上运行其会话，插件 hook 也在其中加载，但 mods 页面并未列出 Cowork，我也没有进行测试；截至 10 月 1 日，桌面端应用仍捆绑的是 Claude Code 2.1.286，即 mods 上线前的一个版本。设备的托管策略会作用于用户机器上的 Cowork 会话，除非组织在完整的虚拟机沙箱中运行它们。有两个页面对于个人的 ~/.claude 文件是否会进入 Cowork 说法不一，因此本文对此不作定论。我也没有测试父文件夹中的 CLAUDE.md 文件是否会在 Cowork 会话中加载；如果会，那么参考实现的挂载树今天就能作用于用户机器上的 Cowork。在 Pro 和 Max 上，这一窗口将在 2026 年 10 月 6 日收窄，届时新的 Cowork 任务将迁移至云端。
• 动机属于推断。Anthropic 尚未公开解释为什么 Claude 聊天和 Cowork 是扁平结构。
• 代码和原始数据未随本文发布。 读者无法仅凭本文复现测量结果；视频展示的是应用的运行效果，而非其构建方式。
• 参考实现基于一家虚构公司运行。它未与 claude.ai 或 Cowork 集成，“acting as”只是一个演示开关，而非登录。权限由 Claude Code 的工具列表强制执行，而非由应用执行。隔离机制会在运行期间关闭个人的 hook 和 mod；但 Claude Code 内置的 mod 会继续运行，个人 Agent 的名称仍可能出现在上下文中。该应用依赖 claude -p 加载 CLAUDE.md，而 Anthropic 表示这将不再是默认行为。个人文件泄露和 --setting-sources 的结果在 Windows 上测试；测量和 mod 测试在 Linux 上运行。
来源
• Anthropic，设置组织指令
• Anthropic，角色与权限
• Anthropic，什么是 Team 计划？ · 方案与定价
• Anthropic，在 Enterprise 计划上管理自定义角色
• Anthropic，在 Claude Cowork 中使用项目整理任务
• Anthropic，使用 Google Workspace 连接器
• Anthropic，在 Enterprise 计划上管理群组和群组支出限额
• Anthropic，什么是项目？（新版项目，beta）
• Anthropic，开始使用 Claude Cowork（全局和文件夹指令）
• Anthropic，Claude 如何记住你的项目 (CLAUDE.md) · 所有设置（claudeMdExcludes、disableAllHooks）
• Anthropic，使用 mods 自定义 Claude Code（2026 年 10 月 1 日） · Mods 概览 · 为你的组织管理 mods · 使用 mod 响应事件 · Mods 参考文档
• Anthropic，Claude Tag：什么是 Claude Tag？ · 配置按频道访问 · 自定义 Claude Tag · Agent 身份的工作原理 · 审计 · 设置支出限额
• Anthropic，Claude Code 中的项目（新项目 beta） · Cowork 中的项目 · Claude Code 如何使用提示词缓存 · 以编程方式运行 Claude Code（--bare） · 扩展 Claude Code · 管理项目的可见性与共享 · 使用连接器 · 为整个组织授权 MCP 连接器 · 配置和管理技能
• Anthropic，配置服务器托管设置（不支持按群组配置） · 为你的组织管理插件（Enterprise 上按群组控制插件可用性） · 各平台的插件功能支持情况（hook 在聊天中被忽略，在 Cowork 中加载） · 部署托管设置（Cowork 在 Claude Code 上运行其会话）
• Anthropic，定价（Sonnet 5.5 费率、分词器说明） · 提示词缓存（API 上按组织和按工作区隔离缓存）
• Anthropic，@anthropic-ai/tokenizer（用于计数的公开分词器）
• AWS，SCP 评估 · Google Cloud，层级评估
• Microsoft，组策略处理 · SharePoint 细粒度权限
• FinOps Foundation，Token 经济学
• Jaroslawicz 等，LLM 一次能遵循多少条指令？(IFScale)
• Firefly，2026 年 IaC 现状研究
• MCP，授权规范，2026-07-28 版本
• GitHub，anthropics/claude-code issues #68262、#14467、#30554、#27567、#30250、#27302、#47741
• Beer, S. (1979)，The Heart of Enterprise；Alexander, C. (1965)，“A City is Not a Tree”，Architectural Forum；Simon, H. (1962)，“The Architecture of Complexity”，Proc. Am. Phil. Soc. 106(6)
• 参考实现与数据：Worktree 应用及其测试、测量脚本、两批结果数据和所有回答均由作者保存，可应要求提供。
