本文永久链接 – https://tonybai.com/2026/05/17/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

大家好，我是Tony Bai。

在 AI 编码工具普及的今天，我们往往容易陷入一种认知误区：认为只需接入最顶尖的模型，生产力便会随之爆发。然而，当我们将 Claude Code 引入拥有数百万行代码、错综复杂的微服务架构或积淀深厚的遗留系统中时，单纯的“模型能力”往往会触碰到现实的边界。

真正的大规模部署，比拼的并非仅仅是单一模型的推理上限，而是如何构建一套高效的“工程化框架”。如何通过 CLAUDE.md 让 AI 读懂组织的隐性约定？如何利用钩子（Hooks）与插件（Plugins）让工具实现自我演进？又该如何将“代码库地图”转化为 AI 的导航指南？

近期Anthropic发布了一篇名为《How Claude Code works in large codebases: Best practices and where to start》的文章，深度揭露了 Anthropic 团队在企业级场景下的实践智慧，为你揭示如何通过精细化的工程布局，让 Claude Code 真正成为大型代码库中不可或缺的高效协作伙伴。

下面是这篇文章的译文。

最成功的 Claude Code 部署案例都共享了一套跨配置、工具和组织结构的可识别模式。本文是“Claude Code 大规模应用”系列文章的一部分，旨在分享工程组织在大规模环境下使用 Claude Code 的最佳实践。

Claude Code 正应用于数百万行的单体仓库（monorepo）、拥有数十年历史的遗留系统、跨越数十个存储库的分布式架构以及拥有数千名开发人员的组织中。这些环境带来了较小的、更简单的代码库所不具备的挑战，即跨越不同子目录或没有共享根目录的遗留代码，其构建命令各不相同。

本文涵盖了我们观察到的促成 Claude Code 大规模成功部署的模式。我们用“大型代码库”来指代广泛的部署场景：包含数百万行代码的单体仓库、运行数十年的遗留系统、数十个微服务的集合，或以上各种形式的组合。这还包括运行在 AI 工具通常不常关联的语言（如 C, C++, C#, Java, PHP 等）上的代码库。（得益于最近的模型版本，Claude Code 在这些情况下的表现优于大多数团队的预期。）虽然每个大型代码库的部署都由其特定的版本控制、团队结构和累积的约定所塑造，但这些模式在各处具有普遍性，是团队考虑采用 Claude Code 的良好起点。

Claude Code 如何导航大型代码库

Claude Code 像软件工程师一样导航代码库：它遍历文件系统、读取文件、使用 grep 查找所需内容，并跨代码库遵循引用。它运行在开发人员的机器上，不需要构建、维护代码库索引或上传到服务器。

基于 RAG（检索增强生成）的 AI 编码工具通过嵌入整个代码库并在查询时检索相关块来工作。在大规模场景下，这些系统可能会失败，因为嵌入管道无法跟上活跃的工程团队。当开发人员查询索引时，它反映的是几周、几天甚至几小时前存在的代码库。检索可能会返回一个两周前重命名的函数，或引用一个在上次推送中已删除的模块，而没有任何过时的提示。

智能体搜索（Agentic search）避免了这些故障模式。没有需要维护的嵌入管道或集中式索引，因为成千上万的工程师在提交新代码。每个开发人员的实例都基于实时代码库中工作。

但这种方法有一个权衡：当 Claude 有足够的上下文知道去哪里时，它效果最好。这意味着 Claude 的导航质量取决于代码库配置的好坏，即通过 CLAUDE.md 文件和技能来分层上下文。如果你要求它在十亿行代码中查找某种模糊模式的所有实例，你在工作开始前就会触及上下文窗口限制。投入精力进行代码库设置的团队会看到更好的结果。

Harness 与模型同样重要

关于 Claude Code 能力最常见的误解之一是它完全由所使用的模型决定。团队专注于模型的基准测试以及它在任务测试中的表现。实际上，围绕模型的生态系统——即“Harness”——比模型本身更能决定 Claude Code 的表现。

该Harness 由五个扩展点构建——CLAUDE.md 文件、钩子（Hooks）、技能（Skills）、插件（Plugins）和 MCP 服务器——每个扩展点服务于不同的功能。团队构建它们的顺序也很重要，因为每一层都构建在前一层之上。LSP 集成和子智能体（Subagents）完善了整个设置。以下，我们解释了这些组件的功能：

CLAUDE.md 文件优先： 这些是 Claude 在每次会话开始时自动读取的上下文文件：根目录用于全局概览，子目录用于本地约定。它们为 Claude 提供无需任何额外操作即可掌握的代码库知识。因为无论任务是什么，它们都会在每次会话中加载，所以确保它们仅包含广泛适用的内容，可以防止它们成为性能负担。

钩子（Hooks）使设置能够自我改进： 大多数团队认为钩子是防止 Claude 做错事的脚本，但它们更有价值的用途是持续改进。一个停止钩子可以在会话期间反思发生了什么，并提出更新 CLAUDE.md 的建议，同时上下文仍然新鲜。启动钩子可以动态加载特定于团队的上下文，因此每位开发人员无需手动配置即可获得适合其模块的设置。对于像代码检查（linting）和格式化这样的自动化任务，钩子可以确定性地强制执行规则，产生比依赖 Claude 记住指令更一致的结果。

技能（Skills）在不使会话臃肿的情况下实现按需专业知识： 在拥有数十个任务的大型代码库中，并非每个专业知识都需要出现在每个会话中。技能通过渐进式披露（progressive disclosure）解决了这个问题，剥离专用的工作流和领域知识，只有当任务需要时才会加载它们。例如，当 Claude 正在评估安全漏洞时，安全审查技能会加载；当进行代码更改且需要更新文档时，文档处理技能会加载。

技能还可以限定在特定路径上，因此它们仅在代码库的相关部分激活。一个拥有支付服务的团队可以将他们的部署技能绑定到该目录，这样当有人在单体仓库的其他地方工作时，它永远不会自动加载。

图 Claude Code扩展层一览 插件（Plugins）分发工作成果： 大型代码库面临的一个挑战是良好的设置会变得“部落化”。插件将技能、钩子和 MCP 配置捆绑到一个可安装的包中，这样当新工程师在第一天安装该插件时，他们将立即获得与那些一直使用 Claude 的人相同的上下文和能力。插件更新可以通过托管市场（managed marketplaces）在整个组织内分发。

例如，一家大型零售商与我们合作，构建了一个技能，将 Claude 连接到他们的内部分析平台，以便业务分析师无需离开工作流即可获得性能数据。他们在全面推广前将此作为插件分发。

语言服务器协议（LSP）集成赋予 Claude 与开发人员在 IDE 中相同的导航能力： 大多数大型代码库的 IDE 已经在运行 LSP，支持“转到定义”和“查找所有引用”。将此呈现给 Claude 赋予了它符号级精度：它可以跟踪函数调用到其定义、跨文件跟踪引用，并区分不同语言中名称相同的符号。如果没有这一点，Claude 会进行文本匹配，并可能落在错误的符号上。一家企业软件公司在全面推广 Claude Code 之前，在全公司范围内集成了 LSP，专门用于 C 和 C++ 的大规模导航。对于多语言代码库，这是最具价值的投资之一。

MCP 服务器扩展一切： MCP 服务器是 Claude 如何连接到它原本无法触及的内部工具、数据源和 API。最复杂的团队构建了 MCP 服务器，通过将结构化搜索作为 Claude 可以直接调用的工具来暴露出来。其他人则将 Claude 连接到内部文档、票务系统或分析平台。

子智能体（Subagents）分离探索与编辑： 子智能体是一个拥有自己上下文窗口的隔离 Claude 实例，它承担任务、完成工作，并仅将最终结果返回给父智能体。一旦Harness框架就位，一些团队会启动一个只读子智能体来映射子系统并将发现结果写入文件，然后由主智能体进行全面编辑。

下表总结了每个组件的作用、加载时间以及我们常见于每个组件的错误：

成功部署的三种配置模式

你如何为大型代码库配置 Claude Code 取决于代码库的结构。尽管如此，我们观察到的部署中始终出现三种模式。

使代码库在大规模下可导航

Claude 帮助大型代码库的能力取决于其查找正确上下文的能力。每次会话加载太多上下文会导致性能下降，而加载太少则会使 Claude 盲目导航。最有效的部署会在前期投入，使代码库对 Claude 可读。以下模式始终出现：

• 保持 CLAUDE.md 文件精简且分层。 Claude 在代码库中移动时会累积加载它们：根目录提供大局观，子目录提供本地约定。根目录应仅包含指针和关键注意事项；其余所有内容都会造成噪音。
• 在子目录中初始化，而不是在代码库根目录。 当它被限制在实际开发的代码库部分时，Claude 的工作效果最好。
• 按子目录限制范围和 lint 命令。 当 Claude 更改一项服务时，运行全套测试会导致超时并浪费无关的输出。子目录级别的 CLAUDE.md 文件应指定适用于代码库该部分的命令。这对于具有深度跨目录依赖关系的编译型单体仓库来说，按目录进行范围限制更难实现，且可能需要特定于项目的构建配置。
• 使用 .ignore 文件排除生成的文件、构建产物和第三方代码。 在 .claud/settings.json 中提交 permissions.deny 规则意味着排除项是版本控制的，因此每位开发人员无需自己配置即可获得相同的降噪效果。在某些代码库中，生成的文件本身就是开发工作的对象。开发人员可以在其本地设置中覆盖项目级排除项，而不会影响团队的其他成员。
• 当目录结构无法完成工作时，构建代码库地图。 对于那些没有整理成常规目录结构的组织，一个在 repo 根目录下包含顶层文件夹描述及一行内容摘要的轻量级 markdown 文件，可以在打开文件前提供一个目录索引供 Claude 扫描。对于拥有数百个顶层文件夹的代码库，这种方法作为分层方法效果最好：根文件仅描述最高级别的结构，而子目录 CLAUDE.md 文件在 Claude 遍历目录树时按需提供下一级别的详细信息。对于更简单的情况，通过 @ 引用特定的文件或目录也可以完成同样的工作。
• 运行 LSP 服务器，以便 Claude 按符号而不是字符串进行搜索。 在大型代码库中，针对通用函数名进行 Grep 会返回数千个匹配项，Claude 会消耗上下文文件来找出哪些内容相关。LSP 仅返回指向同一符号的引用，因此在 Claude 读取之前会进行过滤。设置此项需要为你的语言安装代码智能插件和相应的语言服务器二进制文件；Claude Code 文档涵盖了可用的插件和故障排除。

一个警告：存在分层 CLAUDE.md 方法失效的边缘情况，例如拥有数十万个文件夹和数百万个文件的代码库，或非 git 版本控制系统上的遗留系统。我们将在本系列的后续文章中讨论它们的挑战。

随着模型智能的发展积极维护 CLAUDE.md 文件

为当前模型编写的指令可能会在面对未来模型时产生反作用。引导 Claude 遵循其难以处理的模式的 CLAUDE.md 文件，在下一代模型出现时，可能会变得不必要或起到积极的限制作用。例如，一条告诉 Claude 分解每次重构的 CLAUDE.md 规则可能曾帮助旧模型保持在轨道上，但会阻止新模型完成它所处理的更高级的跨文件编辑。

在模型的推理能力或 Claude Code 自身工具的开销变得不再重要时，这些限制就成了负担。一个截获文件写入以在 Perforce 代码库中强制执行 p4 edit 的钩子，在 Claude Code 增加原生 Perforce 模式后变得多余。

团队应预计每三到六个月进行一次有意义的配置审查，但只要在重大模型发布后感觉性能停滞，也值得进行一次审查。

为 Claude Code 的管理和采用分配所有权

仅靠技术配置无法推动采用。那些在组织层面也进行了正确投入的组织获得了成功。

传播速度最快的推广都有专门的基础设施投资，而非广泛的全面开放。一个小团队，有时甚至只有一个人，将工具预先配置好，以便开发人员在第一次接触时就适合他们的工作流程。在一家公司，几名工程师在第一天就构建了一套可用的插件和 MCP；在另一家公司，另一个团队在推广前就准备好了基础设施。在这两种情况下，开发人员的首次体验是富有成效的，而不是令人沮丧的，采用也由此蔓延开来。

Claude Code 推广的三个阶段 今天从事这项工作的团队倾向于位于开发人员体验或开发人员生产力部门，这通常是负责新工程师入职和构建开发工具的职能。几个组织中出现的一个新兴角色是智能体经理（agent manager）：一个混合 PM/工程师职能，专门致力于管理 Claude Code 生态系统。对于没有专门团队的组织，最小可行版本是一个 DRI：一个人拥有对 Claude Code 配置的所有权、对设置、权限策略、插件市场和 CLAUDE.md 约定的批准权，并负责保持它们的更新。

自下而上的采用会产生热情，但如果没有人集中管理，就会变得支离破碎。你需要有一个个人或团队组装并倡导正确的 Claude Code 约定（例如标准化的 CLAUDE.md 层级和精选的技能与插件）。如果没有这项工作，知识将保持部落化，采用也会停滞。

在大型组织中，特别是在受监管的行业，治理问题很早就出现了，例如：谁控制可用的技能和插件，你如何防止数千名工程师独立重复做同样的事情，你如何确保 AI 生成的代码经过与人类生成的代码相同的审查流程？为了尽早解决这些问题，我们建议从一套定义的经批准的技能、必需的代码信心构建开始。

我们观察到，组织中平稳的部署是在早期通过让工程、信息安全和治理代表聚在一起共同定义需求并建立推广路线图来建立跨职能工作组。

将这些模式应用到你的组织

Claude Code 是围绕传统的软件工程环境设计的，工程师是主要的代码库贡献者，且 repo 遵循标准目录结构。大多数大型代码库都符合这一模式，但非传统设置，例如具有大型二进制资产的游戏引擎、具有非常规版本控制的环境，或非工程师参与的代码库，则需要额外的配置工作。我们的指导假设采用常规设置，并且我们观察到的模式在我们的许多客户中都有效。任何剩余的复杂性都需要针对你的代码库、工具和组织进行具体的判断。这就是 Anthropic 的应用 AI 团队直接与工程团队合作，将这些模式转化为适合你组织特定需求的专业知识的地方。

企业Claude Code 入门清单 致谢： 特别感谢来自 Anthropic 应用 AI 团队的 Alon Krifcher、Charmaine Lee、Chris Concannon、Harsh Patel、Henrique Savelli、Jason Schwartz、Jonah Dueck 和 Kirby Kohlmorgen 分享他们在规模化部署 Claude Code 方面的经验，并感谢 Zoox 的 Amit Navindgi 对本文提供反馈。

原文链接：https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/04/19/thin-harness-fat-skills

大家好，我是Tony Bai。

在过去一年，你有没有想过，为什么同样用着 GPT 或 Claude 等大模型以及Claude Code这样的Coding Agent，有的人生产力只提升了 2 倍，而有的人却能爆发出 100倍、甚至 1000倍 的惊人能量？

就在前几天，硅谷创投界的大佬、Y Combinator 的 CEO Garry Tan，发表了一篇阅读量高达 70万+ 的长文，极其犀利地揭开了这个“效率鸿沟”背后的残酷真相。

他引用了 Google 前员工 Steve Yegge 的一个惊人论断：

“使用 AI 智能体（Agent）的人，比现在用 Cursor 和聊天窗口的人效率高 10-100 倍，比 2005 年的 Google 工程师效率高 1000 倍。”

Garry Tan 写道：“这不是吹牛，我亲眼见过，我亲身经历过。”

他甚至爆出一个猛料：2026 年 3 月 31 日，Anthropic 意外地将 Claude Code 的全部 51.2 万行源码泄露到了 npm 仓库。他读完了。

“这次泄露证实了我在 YC 一直教导的东西：秘密根本不在大模型本身，而在那个包裹着模型的‘驾驭层（Harness）’！”

今天，我们就来读读 Garry Tan 这篇文章，看看硅谷最顶尖的玩家，是如何通过 “薄驾驭，厚技能（Thin Harness, Fat Skills）” 的架构哲学，来榨干大模型的每一滴潜能的。

你的“胖驾驭”，正在杀死你的 AI

在文章的开头，Garry Tan 就毫不客气地指出了当下大多数 Agent 框架的“原罪”：臃肿的驾驭层，和孱弱的技能。

我们大多数人是怎么做的？我们给 AI 挂载了 40 多个 Tool Calls，每一个工具都对应一个外部 API。结果就是，光是这些工具的定义，就吃掉了上下文窗口（Context Window）的一半！

大模型每次行动前，都要在几十个工具中艰难地做选择题，不仅推理速度慢得像乌龟，出错率更是高得离谱。

Garry Tan 给出的架构哲学恰恰相反：

推崇“薄驾驭（Thin Harness）”：驾驭层（Harness）只做四件事——循环运行模型、读写文件、管理上下文、执行安全策略。代码量可能只有 200 行。

推崇“厚技能（Fat Skills）”：将所有复杂的业务逻辑、判断力、领域知识，全部封装成一个个可复用、可参数化的 Markdown 文件，即“技能（Skill）”。

“反面教材就是一个臃肿的驾驭层，配上一堆孱弱的技能。……你想要的是专为特定目的打造的、快速且狭窄的工具。”

五大心法：从“写 Prompt”到“编程 AI”

Garry Tan 认为，大模型的瓶颈从来不是智商。它天生就会推理、综合、写代码。它之所以频繁失败，是因为它不理解你的数据、你的规范、你问题的具体形态。

而下面这五个定义，正是修复这个问题的“架构级补丁”，也是“薄驾驭，厚技能”哲学的具体体现。

心法一：技能文件（Skill Files）—— 用 Markdown 写“方法调用”

这是最颠覆认知的一点。Garry Tan 认为，优秀的 Skill 文件，工作起来就像一个函数调用（Method Call）。它接受参数，并且根据不同的参数，产生完全不同的能力。

他举了一个名为 /investigate 的技能为例。这个 Skill 只有 7 个步骤：圈定数据集、构建时间线、标注文档、综合信息、正反方辩论、引用来源。

• 当你把这个 Skill 指向一个安全科学家的 210 万封邮件，它就变成了一个医学研究分析师。
• 当你把它指向一家空壳公司和 FEC 的文件，它就变成了一个法务调查员。

“这根本不是提示词工程。这是软件设计。你用 Markdown 作为编程语言，用人类的判断力作为运行时。”

心法二：解析器（Resolvers）—— AI 的“智能路由表”

技能文件告诉模型“怎么做”，而解析器告诉模型“在什么时候，加载什么上下文”。

Garry Tan 坦白，他自己曾经写过一个长达 20000 行的 CLAUDE.md 文件，里面塞满了各种他遇到过的奇技淫巧。结果导致模型注意力严重下降，甚至 Claude 自己都“告诉”他让他删掉点。

最终的解决方案，是把这个巨大的文件，拆成了一个只有 200 行的“指针”文件，和一个解析器（Resolver）。

“当一个开发者改了代码，没有解析器，他直接提交了。有了解析器，模型会先去读取 docs/EVALS.md，这个文件说：先跑评测套件，对比分数，如果准确率下降超过 2%，就回滚并调查。”

解析器就像一个智能的“路由表”，在不污染上下文的情况下，按需加载最精准的知识。

心法三：潜在空间 vs. 确定性—— 别让 AI 做数学题

这是 Agent 设计中最常见的错误：让 AI 去做它不擅长的事。

• 潜在空间（Latent Space）：这是 AI 的主场。它负责阅读、理解、判断、综合、模式识别。
• 确定性（Deterministic）：这是传统代码的主场。SQL 查询、代码编译、数学计算。

“一个 LLM 可以帮你安排 8 个人的晚宴座位，它会考虑每个人的性格和社交关系。但你让它去排 800 个人的座位，它会幻觉出一个看似合理、但完全错误的座位表。因为这是一个确定性的组合优化问题，应该交给传统算法。”

最牛逼的系统，对这条边界的划分是冷酷无情的。

心法四：倾向分析 —— 让 AI 拥有“判断力”

这是让 AI 从“数据库”进化为“分析师”的关键一步。

倾向分析，就是让模型读取关于一个主题的所有信息，然后写出一份结构化的、浓缩了判断力的简介。

Garry Tan 以 YC 内部正在构建的、管理 6000 名创始人的 AI 系统为例：

传统的关键词搜索，根本无法发现一个伪装成“可观测性”工具的 FinOps 项目。

但通过倾向分析，AI 读取了创始人的所有 GitHub 提交、访谈记录、公开帖子后，会给出一个惊人的洞察：

“创始人：Maria Santos。公司：Contrail。声称在做：‘给 AI Agent 用的 Datadog’。实际在做： 80% 的代码都在写账单模块。她其实在做一个伪装成可观测性的 FinOps 工具。”

这种“判断力”，是任何 RAG 管道都无法产生的。模型必须真正地去“阅读”和“思考”。

心法五：技能即永久升级

这是 Garry Tan 架构哲学的最终闭环。

他给自己团队的 AI Agent 下了一条铁命令：

“你绝不被允许做一次性的工作。如果我让你做一件事，而这件事未来可能需要再做一遍，你必须：第一次手动在 3-10 个样本上完成它，把结果给我看。如果我批准了，你就必须把这个过程固化成一个 Skill 文件。如果它应该自动运行，就把它加到定时任务里。测试标准：如果我需要为同一件事第二次开口，你就失败了。”

每一次你写下的 Skill，都是对你的 AI 系统的一次永久性升级。它永不衰退，永不遗忘。当下一代更强的模型发布时，你所有的 Skill 都会在一夜之间变得更聪明。

小结

Garry Tan 的这篇文章，为所有在 AI 时代感到迷茫的开发者，提供了一套极具实操性的架构蓝图。

它告诉我们，当大模型的能力趋于同质化时，真正的护城河，不在于你拥有哪个模型的 API 访问权限，而在于你为这个模型构建了怎样一个高效、智能、且能源源不断自我进化的“外部大脑”。

这个“大脑”，就是你沉淀下来的“厚技能（Fat Skills）”资产。

不要再沉迷于寻找那些能一键生成整个项目的“魔法按钮”了。慢下来，像一个真正的软件设计师一样，去思考你的流程、你的判断、你的领域知识。然后，把它们一一固化成 Markdown。

构建一次，它将永远为你运行。

资料链接：https://x.com/garrytan/status/2042925773300908103

今日互动探讨：

看完 YC 掌门人的这套“薄驾驭，厚技能”心法，你对自己目前开发 Agent 的方式有什么新的反思？你认为用 Markdown 来“编程”AI 的想法，是天才还是异端？

欢迎在评论区分享你的看法！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。