内容来源：Medium / Danar Tech Society。https://danartechsociety.medium.com/using-claude-code-on-enterprise-level-62a6dec13bfc
原题：Using Claude Code on Enterprise level
原发布时间：2026-05-21
当 Claude Code 覆盖整个工程组织后，真正发生了哪些变化。
归档校注（截至 2026-07-22）
• 这是一篇以作者和一位匿名 CTO 的谈话为主线的独立观点文章。文章没有公开公司名称、访谈记录、部署设计、样本规模、原始数据或前后测量周期，因此不能视为可独立核验的案例研究。
• 文中的入职改善数据——第一个有实际意义的 PR 从入职第三或第四周提前到约第二周，第十个 PR 的到来速度提高一倍——没有说明队列定义、人数、任务构成、置信区间，也没有控制招聘、代码库、流程或模型变化等因素。
• 缺陷修复时间减少 50%、发布频率提高到每周一次、PR 合并量增加 40%，以及 PR 描述开销接近于零等数字，来自没有名称和链接的案例。它们应被视为未经验证的示例，而不是企业基准。
• 文中对分析仪表盘的描述与当前官方文档大致相符。不过，贡献指标仍处于公开测试阶段，需要集成 GitHub，只覆盖 claude.ai 组织中的用户，而且会有意少计一部分数据。接受代码行数不会追踪之后删除的内容，也不是衡量质量或因果生产力的指标。
• 单纯对比 Claude Code 辅助和未辅助 PR 的周期时间，并不能自动排除噪声。开发者会自行选择在哪类任务中使用 Claude Code；任务复杂度、审查者是否有空、团队、代码仓库和推广阶段都可能混淆结果。
• “事故调查从半天缩短到一小时”“支持问题当天解决”，以及“SaaS 工程团队 60%～70% 的周期用于维护”等说法，在原文中只是轶事或没有引用依据。
• 通过 MCP 使用自然语言查询 SQL 可能很有价值，但这并不能免除受治理的语义层、只读凭据、行级和列级授权、查询限制、审计日志、提示词注入防护，以及对重要答案进行人工验证。
• 客服、财务和人力资源应用都是说明性的匿名示例。文章没有提供代码仓库、架构、权限、安全审查、维护负担、采用数据或业务结果。
• 托管权限和 Claude 审计日志不能自动证明每一项 AI 生成代码变更的来源。后端 IAM、MCP 授权、Git 历史、CI 控制、部署日志和服务审计轨迹仍然不可缺少。
• Hooks 可以确定性地运行配置好的处理程序，但它本身不会让系统自动改进，也不会自动捕获会话经验。这些结果需要明确的 Hook 逻辑、经过审查的记忆工作流，以及防范陈旧或污染上下文的控制措施。
• 插件可以封装 Skills、Hooks、MCP 服务器和 LSP 服务器，托管市场允许列表也能限制来源。不过，在整个组织中分发插件仍会扩大提示词、可执行代码、依赖项和自动更新的供应链攻击面，因此必须审查、锁定版本、测试并持续监控。
• 分层 CLAUDE.md 的行为确实存在：父级文件会在启动时加载，子目录文件则按需加载。这些文件可以把知识外化，但陈旧、冲突或范围过宽的指令，不仅会扩散良好规范，也可能大规模复制错误。
• 原文称 Anthropic 在 5 月发布过一篇关于大型代码库规模化应用的文章，却没有提供标题或链接。归档正文完全没有编辑性引用，只有正文以外的 Medium 界面链接。
• 四张插图的图注明确标注为 AI 生成，第五张正文插图只标注为“Claude.md”。归档保留来源自己的标记，没有自行推断图片来源。
• 文章包含五张正文插图和一张作者头像，不含视频、音频或 iframe。由于直接从 CDN 下载一直没有完成，归档将 Medium 页面显示的 WebP/PNG 图像以无损 PNG 像素保存。
已核对的官方资料：
• https://code.claude.com/docs/en/analytics
• https://code.claude.com/docs/en/memory
• https://code.claude.com/docs/en/plugins
• https://code.claude.com/docs/en/plugin-marketplaces
• https://code.claude.com/docs/en/server-managed-settings
• https://code.claude.com/docs/en/security
• https://code.claude.com/docs/en/mcp
当 Claude Code 覆盖整个工程组织后，真正改变了什么
本周，我写了一篇文章，讨论 AI 工具进入组织时会经历的三个层次。第一层是个人：某个开发者利用周末开始使用 Cursor 或 Claude Code。第二层是团队：工具成为团队共同工作方式的一部分。第三层是组织：AI 不再只是一个聪明的助手，而是成为公司构建软件方式的一部分。
AI 价值的三个层次（AI 生成图片）
那篇文章收到的回复，比我过去几个月写过的任何内容都多。大部分回复发在私信里，而不是评论区；这通常意味着人们确实在认真思考这个问题。其中有一段谈话尤其令我难忘。一家中型 SaaS 公司的 CTO 花了一个小时，向我详细说明他们认真推广 Claude Code 之后，工程组织发生了哪些变化。不是试点，也不是“给平台团队五个席位玩一玩”，而是把它当成真正的基础设施，配有共享上下文文件、治理机制和清晰的责任归属。
他分享的数字很惊人。但更有意思的是，他在通话中途几乎随口说出的一句话：最大的变化并不是生产力，而是公司里哪些人能够构建软件。
我想具体解释一下他的意思。
入职流程的变化
他首先想谈的是新开发者入职。他的团队多年来一直认真测量从入职到提交第一个 PR 的时间。在采用 Claude Code 并妥善维护 CLAUDE.md 层级结构之前，新员工通常要到第三或第四周，才能合并第一个真正有意义的 PR。推广之后，这个时间缩短到大约两周。与推广前的员工队列相比，新开发者合并第十个 PR 的速度大约提高了一倍。
他特别强调，这并不是因为新开发者变得更加优秀。人才来源没有变化，招聘标准也完全相同，真正改变的是阻力。过去，新工程师加入公司后，头两个星期通常都在问各种小问题：身份验证代码在哪里？为什么这个服务采用这样的结构？这里的测试惯例是什么？关于部署管道应该去问谁？每个问题都必须等资深同事有空才能得到回答。资深工程师每周都要抽出相当多时间，解释那些已经存在于他们脑海中的上下文。
有了维护良好的 CLAUDE.md 文件，大部分问题都能立刻获得答案。新开发者可以让 Claude Code 根据团队自己记录的规范解释架构，而不是采用从互联网上搜集的通用最佳实践。他们可以询问某项具体重构需要修改哪些测试，也可以让工具梳理一个陌生服务中会受到影响的区域。资深工程师仍然可以处理那些真正困难、需要判断力的问题，而小问题不再堵塞等待队列。
生产力基准测试几乎从来不会捕捉到这一点。入职最大的成本并不是新开发者逐渐进入状态所需的时间，而是资深开发者不断被打断的专注时间。把这种打断减少一半，会在团队中产生复合效应，而这种效应几乎无法由任何单一的开发者指标完整反映。
如何测量 Claude Code KPI（AI 生成图片）
仪表盘开始显示什么
除了入职流程，组织层面发生变化的指标，主要都与吞吐量和周期时间有关。
Anthropic 自己的 Claude Code 分析仪表盘会追踪一些基础指标：有无 Claude Code 辅助的已合并 PR、接受的代码行数、每日活跃用户，以及每位用户的 PR 数随时间如何变化。真正认真推广这项工具的工程组织，通常还会在这些基础上增加更多测量。比较 Claude Code 辅助与未辅助 PR 的周期时间，是最干净的对照，因为它可以控制噪声。新员工提交第一个 PR 所需的时间，是最清晰的入职指标。每位开发者的 PR 吞吐量，再配合缺陷率或回滚频率这类质量制衡指标，则是最清晰的生产力信号。
已经发布的案例开始呈现出一致模式。一家金融科技公司称，在全团队推广后，平均缺陷修复时间缩短了 50%。一家 SaaS 平台在全面部署后两个月内，将发布频率从每两周一次提升为每周一次。某电商工程团队在保持代码质量的同时，把 PR 合并率提高了 40%。过去，为了重新梳理和说明变更，每位工程师每周大约要花两个小时编写 PR 描述；团队让 Claude 直接根据代码差异起草描述后，这项开销几乎降为零。
这些数字都不是个人使用工具带来的，而是来自工具真正接入团队工作方式的那一层。一个 PR 吞吐量提高 40% 的团队，并不是其中每位开发者把 Claude Code 用好了 40%，而是这个团队的 CLAUDE.md 文件、Hooks、Skills 和审查流程形成了相互强化的系统。
更快解决问题，而不是更快发布产品
谈到这里，那位 CTO 说了一句话。我想谨慎地复述出来，因为它与“AI 让开发者速度更快”的常见说法有着不同的意义。
他说，真正释放出来的最大价值并不是发布新产品，而是解决问题。
他的工程团队负责维护一个 SaaS 平台、一组 API 和一个客户门户。从历史上看，这类工作最困难的部分并不是开发新功能，而是持续不断的客户特定问题、集成疑问、缺陷调查和生产事故；它们占据了工程团队实际工作时间的大部分。这些工作从来不会出现在产品路线图中，却决定着用户是否觉得产品可靠。
当 Claude Code 能够遍历整个代码库后，这类调查的速度显著提高。过去，一次生产事故的根因分析需要半天：有人必须阅读最近的提交、检查日志、追踪三个服务，再找出发生了什么变化。现在只需一个小时。工具可以读取日志、理解近期变更并提出可能原因。最终判断仍由资深工程师做出，但他们的起点已经好得多。以前，客服工单被转给工程团队并询问“能否检查这个特定边缘情况中的 API 行为”后，往往要等到下周才能解决；现在当天就能处理完。
这种变化的战略意义比表面看起来更大。大多数 SaaS 工程组织会把 60%～70% 的工作周期用于维护、支持、集成和事故响应，只有剩余部分用于新产品开发。加快这 60%～70% 的工作，并不会表现为“我们发布了一个新功能”，而是会表现为客户满意度提高、流失率下降，以及团队终于有空间思考下一步应该构建什么。
他用更直接的话概括：“我们并没有发布更多功能，只是不再被现有产品压得喘不过气。”
静态仪表盘的消亡
他描述的另一个意外影响，出现在公司的内部报告体系中。
推广之前，分析团队维护着几十个 Power BI 仪表盘和 Looker 报告。每一份报告都代表某位业务人员曾提出过的一个问题：这个问题重要到值得正式制作成报告，而且没有人愿意再问第二次。其中一半只被看过两次便遭到遗忘；另一半虽然每周都有人看，却始终不能完全回答用户真正关心的问题，所以大家最终还是回到电子邮件中，请分析团队临时提取数据。
通过 MCP 把 Claude Code 连接到内部数据仓库后，大部分仪表盘都变得没有必要。非技术团队成员可以使用自然语言提问，Claude 会编写 SQL、执行查询，然后在给出适当注意事项的同时返回答案。分析团队不再维护无人使用的仪表盘，终于可以开始进行真正的分析。营销团队不必为了查看营销活动表现的定制报告等待三天；客户成功团队也可以在需要时自行提取队列数据，并且得到真正符合需求的格式。
告别仪表盘和 Power BI（AI 生成图片）
这个模式值得仔细思考。静态仪表盘本来就是为了绕过“会写 SQL 的人”和“不会写 SQL 的人”之间的鸿沟而产生的替代方案。一旦这条鸿沟消失，大部分仪表盘也就不再需要。你真正需要的是一个查询引擎，可以用提问者已经掌握的语言回答问题。这是公司使用自身数据方式上的结构性变化，而大部分管理者甚至还没有意识到，变化已经发生在自己身上。
非工程人员开始构建真正的软件
整段谈话中最出人意料的，是最后十五分钟。
每个团队都在创建自己的应用（AI 生成图片）
他告诉我，公司里有几个非技术团队已经开始发布自己的内部应用。他们没有招聘开发者，也没有把需求交给平台团队，而是在工程团队制定的一套谨慎设计的共享模板、治理规则和已批准模式之下使用 Claude Code。
客服团队构建了一个工具：新对话出现时，自动展示相关历史工单和客户记录。财务团队构建了一个与会计系统集成的内部费用分类助手。人力资源团队构建了一款入职检查清单应用，直接从真实业务系统获取数据，而不再依赖静态文档。这些都不是关键任务基础设施，但每一项都是满足真实需求的真正应用。如果必须让工程师放下产品路线图中的工作来开发，它们永远不会出现。
这之所以能够实现，是因为工程团队认真完成了那些并不起眼的基础工作。他们定义了新内部应用应当遵循的架构模式，创建了包含预先批准 Skills 和 MCP 连接的插件市场；设置托管权限，使客服团队的 Claude Code 实例能够从某些系统读取、向另一些系统写入，却不能接触生产数据库；还建立审计日志，保证每项 AI 生成的变更都可以追溯。
从结构上看，内部工具的开发成本正在快速坍塌。过去不值得占用工程师时间的软件，现在值得客服经理花一个下午完成。那些一直躺在“以后应该做”的清单上、最终不了了之的工具，现在一周内就能构建出来。公司内部软件覆盖的范围不断扩大，却不需要同步扩大工程团队。
这是 AI 真正带来的新事物之一，但我认为它还没有得到足够讨论。过去，内部软件始终受工程能力配给限制。现在，这种配给正在放宽，于是公司中每一位运营和客服负责人的实际问题也随之改变。问题不再是“能不能请工程团队帮我们做这个”，而是“我们的治理机制是否足够完善，能不能让公司的其他人安全地自己构建”。
成功推广有哪些共同点
Anthropic 在 5 月发布过一篇文章，介绍 Claude Code 如何在大型代码库中进行规模化应用。文章描述的情况与那位 CTO 告诉我的内容高度一致。成功的企业部署中反复出现的模式，其实与模型本身关系不大，真正重要的是模型周围的支撑系统。
首先是 CLAUDE.md 文件。它们应当精简且分层：根目录文件提供整体说明，子目录文件描述局部约定。Skills 使专业知识能够随时调用，又不会让每次会话都塞满上下文。Hooks 通过确定性地运行检查并捕获会话经验，让系统能够自我改进。插件把有效的做法分发到整个组织，使优秀配置不再只是少数人的部落知识。MCP 服务器把 Claude 与内部工具、文档、工单系统和分析平台连接起来。LSP 集成则让 Claude 在大型多语言代码库中获得符号级导航能力，而不必只依赖文本模式匹配。
从 Claude Code 规模化应用中真正获得价值的组织都有一个共同点：有人明确负责这件事。负责人可以是一个小型开发者体验团队，也可以是新出现的“智能体经理”岗位；最低限度也需要指定一名直接责任人，使其有权管理设置、权限、插件市场和 CLAUDE.md 规范。推广工作之所以会碎片化、停留在少数人的部落知识中，或者止步于“个人生产力工具”，都是因为没有人为组织层负责。
那位 CTO 用一句话作了总结：“购买席位不是战略，设计一套让工具发挥作用的条件才是战略。”
Claude.md
可以带走的三点结论
如果你正在领导工程组织或技术职能部门，并思考 Claude Code 或其他同类编程智能体的下一步方向，那么我看到和听到的一切，可以归纳为三个重点。
1、**不要再测量个人生产力，转而测量周期时间和入职速度。**个人层是整个故事中最不重要的部分。每位开发者的代码行数一直都是一个可疑指标，AI 只会让它变得更加可疑，而不是更加可靠。真正重要的是：团队的周期时间是否缩短，新员工是否更快做出有效贡献，事故解决时间是否下降，维护负担是否变得可控。只有这些指标，才能反映工具进入组织层之后真正发生的变化。
2、**把支撑系统当成工程工作，而不是简单配置。**CLAUDE.md 层级、Skills、Hooks、插件、MCP 连接和权限，这些都不会自动形成，也不会因为购买了 Enterprise 席位就自然出现。成功的部署会在大规模推广之前投入数周甚至数月的专门工程时间，构建这套支撑系统；随着代码库和模型不断演进，还要持续投入时间维护。如果团队中没有人负责，推广最终只会产生少数个人成功案例，以及整个组织的失望。
3、**提前为非工程人员开始构建软件做好准备。**这是大多数管理者还没有开始思考的部分。一旦工程团队完成了模式、权限和治理机制的定义，公司其他部门构建内部工具的成本也会随之快速下降。运营、客服、财务、人力资源和营销团队中，有些人会开始发布自己的应用。真正的问题是：他们会在工程团队批准的架构中，按照治理要求提供安全和可观测性；还是会在所有控制之外，以影子 IT 的形式开发。这项决定无法无限推迟。你要么明确做出选择，主动建立相应条件；要么什么都不做，让事情照样发生，从而被动做出选择。
更深层的变化
四十年来，软件工程一直是一门依靠师徒传承的手艺。你坐在经验更丰富的人身边学习，吸收各种约定，品味真正有效的代码，逐渐理解某些决策背后的原因。这种传承的成果存在于资深员工的脑海里，存在于陈年的 Slack 讨论串、依稀记得的 Pull Request，以及那些从来没有人真正写下来的组织知识中。
而我如今看到的，是这些知识逐渐外化，变成 AI 可以读取和应用的内容。CLAUDE.md 文件其实不只是配置，而是试图写下优秀开发者已经掌握、过去却从来不必说出口的知识。一旦这些知识变成 AI 可以读取的形式，它就不再被困在某个人的脑海里。新开发者可以在几天内吸收它；非工程人员可以依靠它安全地构建自己的内部工具；员工离职之后，这些知识依然能够保留下来。
这才是那位 CTO 真正想要描述的变化。不是开发者速度更快，也不是发布更多功能，而是公司里的人与公司赖以运行的软件之间，形成了一种不同的关系。
我认为，我们对这意味着什么还处于非常早期的理解阶段。但是，最先把它想明白的组织，会在未来两年里不断领先于那些仍然只把 AI 当作个人生产力工具的组织。
个人层只是预告片。
组织层才是真正的正片。
