团队赋能与运营生产力

屏幕 1：导向：学习目标

模块 · 导向 导向：学习目标

前四个模块让你成为一名能够从利益相关者的第一句话开始，经过设计、集成、治理和交接，完成部署的架构师。本模块则关注围绕该部署的团队：如何让人们在使用Claude时高效工作，并在系统上线后保持高效。

通过本模块的学习，你将能够：

• 为团队配置Claude工具和环境，包括共享配置、推广模式、技能分发策略以及团队设置中的支出控制。
• 通过AI工具改进开发者工作流程，并定义在AI生成的工作进入生产环境之前保持其可信度的审查纪律。
• 通过将症状与架构原因联系起来，支持调试和运营问题解决，并培养团队的自给自足能力。

本模块关注赋能

之前的每个模块都教你如何构建和配置Claude。本模块假设系统已经构建完成，并提出问题：团队如何良好地采用它，以及如何在不将你卷入每个问题的情况下保持其健康？团队设置帮助团队在任何人登录之前获得正确的环境、可重用资产和支出姿态。开发者工作流程提高了团队日常工作的标准，同时不降低质量门槛，而运营支持则是当团队在系统中遇到意外情况时你所做的事情。

这些主题相互关联。你在设置中分发的技能是开发者工作流程所依赖的相同资产；你为这些工作流程建立的审查纪律是在压力下测试运营问题的标准。三者按顺序运行：设置环境，提升日常工作流程，并保持系统健康。

免责声明 / 教育内容声明

我们构建了本架构师课程模块5：团队赋能与运营生产力，以帮助你使用Claude完成实际工作。请将其视为教育内容。它不构成法律、财务或其他专业建议，因此请根据自身情况调整所学内容。我们的产品和服务发展迅速，因此某些内容可能包含错误或已过时；请记得在Anthropic的网站或文档中核实。课程中使用的示例和场景是说明性的，通常是虚构的。如果课程材料提到某家公司或产品，并不意味着Anthropic认可它们，它们认可Anthropic，或我们有关联。另请注意，你对Anthropic产品和服务的使用受我们的条款、政策和文档的约束；如果本课程中的任何内容与之冲突，以它们为准。

屏幕 2：为团队配置Claude工具和环境

团队设置 为团队配置Claude工具和环境 你可以在几分钟内为自己配置Claude；然而，为团队配置则有所不同。为团队配置时，有共享的默认设置，以便每个人都从相同的基线开始，有可更新的可重用资产，并在数十人使用时保持支出在可控范围内。本屏幕涵盖了架构师负责的四个团队设置决策：环境、推广、技能分发和支出，以及跳过其中任何一个步骤可能导致的失败。

将环境部署为共享配置 团队环境是一个共享配置：每个开发者都从相同的基线开始，而不是一组个人设置。对于Claude Code，这意味着团队在项目级别达成一致：共享的CLAUDE. md、商定的工具和MCP服务器，以及权限姿态，以便人们从相同的地方开始，而不是发现临时设置并逐渐偏离。该基线是你可以在所有人中审查、版本控制和改进的东西。

通过冠军推广，然后分批进行 团队采用很少能通过一次全员切换成功。最有效的模式是识别每个部门或团队的冠军，首先授予他们访问权限，在实践中证明工作流程，然后分批推广。冠军吸收早期摩擦，构建本地示例，并成为团队的第一线支持，因此架构师不是唯一能回答问题的人。

工作示例 一个200人的工程组织希望在四个部门中推广Claude Code。架构师没有一次性启用所有四个部门，而是为每个部门启用一名冠军，给他们两周时间转换一个实际工作流程（例如，代码审查辅助、测试生成步骤），并让每位冠军为他们的第一批同事（五名）举办45分钟的会议。到大规模推广时，每个部门都有一个工作示例、一名本地专家和冠军已经调整的共享CLAUDE. md。如果以单一的大规模电子邮件尝试同样的推广，可能会导致大量首次提示的困惑，甚至可能悄悄回归旧习惯。

技能分发：团队规模的复用版本 我们了解到，技能包是作为版本化、可重用单元出现的可重复程序。在团队规模下，架构问题是：你应该如何将技能分发给整个团队？考虑如何创建、版本化和发布它，以便团队可以访问它，如何授予和撤销访问权限，以及如果技能行为不当，如何回滚。有四种主要的分发团队技能的方式，你选择的机制取决于工具是什么、谁使用它以及谁有权管理它。 有四种方式将技能部署到团队，它们在谁可以访问以及你保留多少控制权方面有所不同。所有者提供的技能，上传到组织设置 > 技能下，立即对组织中的所有成员可用。当一项能力确实应该覆盖所有成员时，这是最简单的路径。当技能应该仅覆盖特定成员时，你将一个或多个技能捆绑到一个插件中，并将该插件分配给一个组。只有该组的成员才能访问这些技能。插件也是治理分发的地方：安装偏好，如必需、默认安装、可用或不可用，组目标，以及从连接的存储库进行版本控制的更新。第三种机制是Claude Code项目技能：文件系统工件，存在于项目存储库中（. claude/skills/），因此它们与存储库本身一起版本化，并限定在携带它们的项目中。第四种是API技能，由合作伙伴自己的产品以编程方式调用。集中管理的Claude Code配置是完全独立的渠道：服务器管理的设置在用户认证时从Anthropic的服务器交付，并每小时轮询刷新一次——一种设置机制，而不是技能分发路径。

技能分发机制 分发机制 | 最佳时机 | 治理和回滚 --- | --- | --- 组织提供的技能（组织设置 > 技能） | 一项能力应覆盖组织中的每个人。 | 所有者管理的可用性和跨组织移除；用户可以关闭个别技能，但不能移除它们。没有版本固定或原生回滚；更新需要手动重新上传。 分配给组/组织的插件 | 一个程序或工具集应覆盖特定团队，或需要治理推广。 | 组目标，安装偏好控制插件是必需、默认安装还是对用户可用（确切的标签根据当前管理UI，支持文章13837433），以及从连接的存储库进行版本控制的更新。组范围分发的最强治理选项。它不是唯一具有回滚路径的机制：API技能支持显式版本固定，Claude Code项目技能随携带它们的存储库回滚。 Claude Code项目技能 | 一个团队在其项目中共享的工具或约定。 | 项目存储库中的文件系统工件（. claude/skills/），与存储库一起版本化，并限定在携带它们的项目中。 API技能（消息API容器） | 由合作伙伴自己的产品以编程方式调用的能力。 | 在调用系统中治理；支持显式版本固定；复用是机器对机器，而不是面向人类。

将团队工作流程打包为可分发技能，是将良好的本地实践转化为团队标准的方式。该过程作为一个治理工件传播，而不是作为未记录的诀窍，更新通过版本化传播，而不是通过重新解释。

在第一次账单之前设置支出姿态 团队设置还包括成本护栏。管理员应有意设置这些，而不是继承默认值：模型默认值（会话开始时使用的模型）、模型允许列表和限制（团队可以切换到的模型）、努力指导（模型在任务上的工作强度），以及保持消费在可控范围内的支出、速率和每用户上限。模块2表明，不管理模型选择可能会悄悄地将工作路由到比任务所需更强大、更昂贵的层级。在团队规模下，这种选择在每个成员和每个请求中都会倍增。

注意 没有回滚路径的技能。 一个平台团队将其发布说明程序打包为技能，捆绑到插件中，并分配给其四十名工程师的组。一周后，一个善意的编辑更改了提示，技能开始在使用的每个团队中生成错误格式的说明。技能作为扁平捆绑包推送，没有插件提供的版本控制更新和回滚，因此修复需要手动重新编辑，而错误的输出继续发布。技能是一个好主意，但没有所需的治理。没有版本和回滚路径的共享资产，一旦超过一个人依赖它，就会成为负债。当共享资产需要版本控制、组目标或回滚时，将其分发到组织管理的插件中，并确定一个所有者。

成本 · 复杂性 · 风险 成本 | 建立团队环境需要设置时间：共享配置、推广计划和技能打包前期，但比后来调和四十个偏离的配置要便宜得多。 复杂性 | 困难的部分是分发治理：谁可以访问、更新和撤销每个共享资产。按资产决定。 风险 | 最大的失败模式是没有版本控制或回滚的共享资产（例如，技能、配置），因此一个错误的更改会在任何人阻止之前传播到整个团队。

屏幕 3：检查点：设计团队分发策略

团队设置 · 检查点 检查点：设计团队分发策略

现在试试。对于以下每个场景，选择团队应如何接收可重用资产，并确定使该机制成为正确选择的因素。正确的机制与错误的原因配对不会通过。

A 每个部门必须完全相同运行的合规审查程序，必须可集中更新和回滚。 选择机制... 组织提供的技能（组织设置 > 技能） Claude Code项目技能 插件分发给整个组织（或所有相关组） API技能（消息API容器）

B 一项确实应覆盖每个成员的能力，不需要版本控制或回滚。 选择机制... API技能（消息API容器） 组织提供的技能（组织设置 > 技能） 插件分发给整个组织 Claude Code项目技能

C 工程团队应在每个项目中共享的编码约定和工具集。 选择机制... Claude Code项目技能 API技能（消息API容器） 组织提供的技能 插件分发给工程组

D 合作伙伴的多个产品必须以编程方式调用的可重用能力。 选择机制... 插件分发给整个组织 Claude Code项目技能 API技能（消息API容器） 组织提供的技能

检查选择 暂时跳过

屏幕 4：通过AI工具改进开发者工作流程

开发者工作流程 通过AI工具改进开发者工作流程 一个团队可以完美配置Claude，但仍然从中获益甚少。区别在于他们的工作流程：AI辅助如何融入开发者的工作方式，以及保持其输出可信度的纪律。本屏幕关注在不降低质量门槛的情况下提升工作流程标准，以及跳过第二部分时发生的失败。

将辅助集成到现有工作流程中 AI工具在融入现有工作流程时才能发挥价值：编辑器、审查过程和测试循环，而不是开发者偶尔访问的单独聊天窗口。架构师的工作是找到AI辅助有机会消除实际摩擦并改进整体流程的地方。Claude应集成到团队的当前工作流程中。集成也是团队知识和工作方式被编码的方式。通常存在于人们头脑中的约定、审查标准和重复程序成为Claude一致应用的技能和项目配置，因此良好的实践随工具传播，而不是依赖于谁恰好在场。

Claude在每个工作流程阶段帮助的地方，以及它仍然需要的审查纪律 工作流程阶段 | Claude可以帮助的地方 | 它仍然需要的审查纪律 --- | --- | --- 编写代码 | 从清晰的规范中起草样板代码、测试和初步实现。 | 正确性和安全性审查；作者必须理解生成的内容。 审查代码 | 总结差异，标记可能的问题，解释不熟悉的代码。 | 人类判断；AI标记是输入，而不是裁决。 调试 | 从症状和跟踪中提出假设。 | 在根据假设行动之前，验证假设与证据。

两种失败模式反复出现

• 不均匀的采用：当少数开发者大量使用AI工具，而其他人几乎不使用时，团队永远无法实现工具的真正收益，实践也永远不会标准化。前一主题中的冠军和分批推广是避免这种情况的好方法：它有意传播使用，而不是将其全部留给早期采用者。
• 停滞在基本聊天：团队将Claude用作问答框，从未推进到更高价值的工作流程，如工具使用、存储库感知的辅助、打包的技能，因为没有人让他们超越第一步。为团队提供访问权限并不是采用；你需要在当前工作流程中配置真正的赋能。

尽职调查：保持AI生成工作可信度的纪律 尽职调查是四项AI流畅能力之一。Anthropic将其定义为对我们使用AI做什么以及如何做负责。部署尽职调查具体意味着对我们使用或共享的输出进行验证和担保的责任。应用于开发者工作流程时，这种责任表现为一个具体的习惯：将AI生成的代码与任何其他代码保持相同的标准，即正确性、安全性和可维护性，并警惕工程师接受他们不再完全理解的输出，因为它看起来正确并通过了检查。 尽职调查产生的具体可交付成果是验证清单：AI生成的输出在进入生产环境之前必须通过的明确检查集。该验证清单是团队根据其特定需求内部生成的。清单应包括解决验证所有四个维度的问题：正确性、安全性、可维护性和人类理解。 只要检查可以自动化，就应该自动化。回归测试套件和评估集将正确性和行为验证从审查者的判断转变为在每个更改上运行的关卡。清单定义了必须为真的内容。评估和测试是团队如何重复证明它，而不是每次手动重新推导。拥有该清单的团队将良好的意图转化为可重复的关卡；没有它的团队默认信任AI输出，并希望审查者抓住重要内容。

注意 没人能解释的合并。 一个团队采用了AI辅助编码，并显著加快了交付速度。三周后，一个生成的更改通过了代码审查和测试，并进入生产环境，在那里它通过一个从未验证的输入泄露了数据。在事后审查中，作者无法解释代码为什么以这种方式处理该输入；它看起来合理，测试通过，没有人问清单会强制的问题：合并的人能解释它做了什么以及为什么吗？速度悄悄地取代了理解，这正是尽职调查存在的判断侵蚀。

成本 · 复杂性 · 风险 成本 | AI辅助降低了生成代码的成本，这提高了到达审查的数量；验证清单是保持该数量不压倒质量门槛的东西。 复杂性 | 困难的部分是文化上的，而不是技术上的：将AI生成的代码与手写代码保持相同的审查标准，尤其是当它更快地交付并且看起来正确时。 风险 | 最大的失败模式是判断侵蚀：团队交付他们不再理解的输出，因为它通过了浅层检查，直到一个没有人推理的输入进入生产环境。

屏幕 5：练习：定义验证清单

开发者工作流程 · 练习 练习：定义验证清单

现在试试。编写AI生成的代码在进入生产环境之前必须通过的验证清单。对于以下四个维度中的每一个，用你自己的话写一个具体的检查。编写你的清单，然后揭示下面的模型答案。

正确性

安全性

可维护性

人类理解

揭示模型答案 正确性：测试存在并通过，行为符合所述要求，包括边缘情况。 安全性：代码中没有秘密；输入已验证；任何工具或外部调用使用最小权限访问。 可维护性：代码清晰易读，遵循团队约定，不包含未解释的复杂性。 人类理解：提交更改的开发人员可以解释代码的作用和原因，包括它如何处理未明确测试的输入。

标记清单完成 暂时跳过

屏幕 6：支持调试和运营问题解决

运营支持 支持调试和运营问题解决 总有一个时候，一个实时部署会让团队感到意外。当这种情况发生时，架构师是将团队所看到的内容与原因联系起来的人。架构师还负责提升团队的技能，以便下次他们感到有能力自己解决问题。本屏幕关注支持角色、定义它的症状到原因的推理，以及培养团队的自给自足能力。

支持角色是翻译，而不是救火 当运营问题出现时，团队通常识别的是症状，而不是原因。例如，他们会注意到延迟激增、输出质量下降或工具开始失败。然后团队会拉入架构师，其价值在于将运营症状与其架构原因联系起来：模块2为生产系统建立的相同诊断纪律，现在应用于支持拥有部署的团队。自己解决一个事件是救火；教会团队他们可以在未来再次遵循的症状到原因路径是持久的支持。

将症状与架构原因联系起来 许多运营症状可以追溯到一小部分架构原因。识别这些原因可以让团队从他们所看到的内容清晰地推理出应该查看的地方。 症状 → 可能的架构原因 → 第一个动作 症状 | 可能的架构原因 | 第一个动作 --- | --- | --- 输出质量逐渐下降，但没有代码更改 | 模型或提示更改，或随着语料库增长而检索漂移。 | 与评估集进行比较；检查模型、提示或语料库中发生了什么变化。 延迟激增 | 上下文大小增长，工具变慢，或缓存停止命中。 | 使用遥测和请求跟踪找到最慢的跨度：检查每个请求的token计数和最慢的工具调用，并确认缓存行为。 间歇性工具失败 | 授权、速率限制或未处理的错误路径。 | 检查失败工具的授权和限制；端到端跟踪一个失败的调用。 成本上升而没有使用量变化 | 模型层级上升，或缓存回归。 | 根据预算模型检查每个请求的模型层级和缓存命中率。

培养自给自足：运行手册和升级路径 自给自足是功能团队的设计。运行手册捕获已知的症状到原因到动作路径，以便团队可以在没有架构师的情况下解决重复出现的问题。上表是良好运行手册的基础。升级路径确定谁处理什么以及何时问题离开团队，以便人们知道他们可以解决的边界以及必须升级的内容。始终鼓励团队为其部署保留运行手册，并定义清晰的升级路径。目标是团队只在出现新问题时需要你，而不是你已经教会他们如何面对的问题。

注意 等待季度审查的漂移。 一个支持团队观察了一个部署的仪表板在整个季度保持绿色，而答案质量悄悄下滑。没有人将缓慢下降与其原因联系起来：一个不断增长的检索语料库，索引没有跟上。症状一直可见，但运行手册条目中缺少“没有代码更改的逐渐质量下降指向模型、提示或检索漂移”。如果有这条路径，一线工程师可以在一个下午解决问题；但没有它，它等待审查。

成本 · 复杂性 · 风险 成本 | 教授症状到原因路径在前期比直接解决事件花费更多架构师的时间，但它是唯一减少未来负载而不是重复它的支持版本。 复杂性 | 困难的部分是抵制救火的冲动：快速修复是自己解决它，但持久的修复是帮助团队创建运行手册条目并确定升级路径，让团队在没有你帮助的情况下解决下一个问题。 风险 | 最大的失败模式是缓慢的退化，没有人将其与原因联系起来，因此它一直运行，直到计划审查抓住它，而不是团队在它开始的那天抓住它。

屏幕 7：模块测验

模块 · 测验 模块测验

涵盖三个主题的五个情景问题。选择最佳答案；反馈会指出原则。

问题 1 · 团队设置 一个团队正在同时向四个部门推广Claude，采用情况不均匀。最好的下一步是什么？ A. 为每个人设定每日使用目标。 B. 首先在每个部门启用一名冠军，证明工作流程，然后分批推广。 C. 等到每个部门请求帮助。 D. 给每个人最强的模型以鼓励使用。

问题 2 · 技能分发 一个程序必须由每个部门完全相同地运行，并且可以从一个地方撤销。应该如何分发？ A. 作为提示粘贴到每个团队的聊天中。 B. 捆绑到一个组织管理的插件中，分发给所有部门，具有组/组织目标、版本控制更新和回滚。 C. 一个团队存储库中的Claude Code项目配置。 D. 作为文档通过电子邮件发送供人们遵循。

问题 3 · 开发者工作流程 一个团队更快地交付AI生成的代码，但一个安全问题溜过。最可能缺少什么？ A. 一个代码审查SLA，豁免小型AI生成的更改的安全审查。 B. 一个配置为在合并前标记已知漏洞模式的linter。 C. 一个AI生成的代码在进入生产环境之前必须通过的验证清单，包括安全维度。 D. 更频繁的模型更新以纳入最新的安全模式。

问题 4 · 判断 在审查中，开发人员无法解释为什么AI生成的更改以某种方式处理输入，但测试通过。应该发生什么？ A. 合并它；测试通过。 B. 保留它，直到作者能够解释行为和其理由，人类理解检查。 C. 删除测试并手动重写。 D. 每次合并都升级到架构师。

问题 5 · 运营支持 一个实时部署的输出质量在过去两个月逐渐下降，没有代码更改。架构师首先应该查看哪里？ A. 提高模型层级；更强大的模型将弥补检索差距。 B. 模型或提示更改，或随着语料库增长而检索漂移，将症状与架构原因联系起来。 C. 禁用缓存以确保每次调用都拉取新鲜内容。 D. 回滚最后一次代码部署并重新运行集成测试。

提交测验 暂时跳过

屏幕 8：术语表

总结 · 参考 术语表 本模块中使用的关键术语，按字母顺序排列。点击术语展开其定义。

按部门冠军推广 | 一种采用模式，首先在每个团队中启用一名冠军以证明工作流程，然后分批推广。 升级路径 | 一个命名的定义，确定谁处理什么以及何时运营问题离开团队。 运行手册 | 一组已知的症状到原因到动作路径，让团队在没有架构师的情况下解决重复出现的运营问题。 共享配置 | 一个单一的团队基线（例如项目CLAUDE. md、商定的工具和权限姿态），每个成员都从它开始，而不是逐渐偏离的个别设置。 技能分发 | 通过四种机制之一将技能传递给正确的人，每种机制具有不同的访问、版本控制和回滚行为：组织提供的技能（组织设置 > 技能）用于组织范围内的可用性；分配给组或组织的插件用于具有安装偏好、版本控制更新和回滚的范围分发；Claude Code项目技能与存储库一起版本化并限定在一个团队；API技能以编程方式调用，具有显式版本固定。 支出姿态 | 作为团队配置的一部分设置的模型默认值、模型允许列表和限制、努力指导以及支出、速率和每用户上限，保持消费在可控范围内。 验证清单 | AI生成的输出在进入生产环境之前必须通过的明确正确性、安全性、可维护性和人类理解检查集。

屏幕 9：回顾：贯穿所有内容的四件事

模块 · 回顾 回顾：贯穿所有内容的四件事

01 团队设置是共享配置、分发和支出姿态的前期决策 团队环境是一个共享基线加上技能分发方法：组织提供的技能覆盖所有人，插件用于组和组织目标，具有版本控制更新和回滚，项目技能用于一个团队，API技能用于编程复用，所有这些都由模型和预算护栏限定。

02 通过冠军和分批推广实现采用 每个团队的冠军证明工作流程并推广采用；没有赋能的访问停滞在基本聊天，不均匀的采用永远不会标准化收益。

03 尽职调查保持AI辅助工作的可信度 将AI生成的代码保持正确性、安全性和可维护性标准，并要求作者能够解释交付的内容，作为在生产前把关的验证清单。

04 运营支持是翻译加上自给自足 将症状与架构原因联系起来，并留下运行手册和升级路径，以便团队在新问题时需要你，而不是熟悉的问题。

这完成了架构师轨道。 你可以从利益相关者的第一句话开始，经过设计、集成、治理、交接，并将其交付给采用和运行它的团队。

来源 Anthropic Skilljar，使用Claude API构建：工具使用、API集成机制和基线技能概念引入团队分发。 Claude Code配置文档（code. claude. com）：CLAUDE. md说明与可执行设置、权限、钩子、MCP和托管设置。 Claude Code技能和组织技能配置文档：技能包结构、项目技能、基于插件的分发和所有者提供的组织范围可用性。 组织插件管理（support. code. com）：插件市场、组分配、安装偏好、必需/默认安装、隐藏/弃用行为、手动上传、Github同步、更新和移除机制。

屏幕 10：恭喜！你已成功完成本模块。

模块完成 · 架构师 · 2分钟 恭喜！你已成功完成本模块。 模块5涵盖了团队工具配置、开发者工作流程设计和运营支持实践，这些实践在部署上线后维持AI生产力。 一个团队无法操作、调试和改进的部署不会保持生产力；你现在有了保持其运行的模式。

0 通过0个检查点

M1 Claude平台与解决方案设计 模型选择、提示架构、工具设计和平台层权衡。

M2 企业集成与生产 部署模式、集成架构和生产可靠性。

M3 负责任AI、安全与风险 安全框架、风险识别和治理实践。

M4 利益相关者参与、生命周期与市场推广 利益相关者沟通、生命周期管理和市场推广策略。

M5 团队赋能与运营生产力 团队工具配置和运营支持实践。 你在这里

回顾模块 重新开始