Claude Code 大型代码库最佳实践
来源：How Claude Code works in large codebases: Best practices and where to start
发布日期：2026-05-14
学习日期：2026-05-16
学习主题：Claude Code 在大型代码库中的工作方式、配置层次、团队落地模式
说明：这份文档是对博客内容的中文学习整理和课堂式讲解，不是逐字翻译。重点是帮你建立可复用的理解框架。
╔═══════════════════════════════════════════════════════╗
║ Study Session #1: Claude Code in Large Codebases ║
║ Today's Topic: 让 Claude Code 在大代码库里找得到路 ║
╚═══════════════════════════════════════════════════════╝
张老师：今天我们学一篇很实用的文章。它不是在说“模型又变强了”这么简单，而是在说：大型组织想让 Claude Code 真正有用，需要把代码库、工具、流程和团队责任一起整理好。
小明：所以这篇博客不是教程吗？更像一张“企业落地地图”？
林姐：对，像给 Claude Code 修路、立路牌、配地图、安排交通规则。
张老师：很好。我们今天的目标就是看清这套“路网”。
1. 一句话大图景
小明：那这篇博客到底在讲什么？
张老师：一句话：Claude Code 可以在百万行、多仓库、老系统、复杂语言栈里工作，但它的效果不只取决于模型，还取决于代码库有没有给它足够清晰的导航、工具和组织支持。
林姐：也就是说，模型像一位聪明工程师，但聪明工程师也需要项目地图、构建命令、团队约定和权限边界。
张老师：正是如此。一个好比喻是：Claude Code 是来到陌生城市的工程师；大型代码库是城市；CLAUDE.md、hooks、skills、plugins、LSP、MCP、subagents 就是路标、规章、专家手册、工具箱、地图软件、外部办事窗口和临时助手。
小明：这里的“大型代码库”只指 monorepo 吗？
张老师：不只。文章把大型代码库理解得很宽：百万行 monorepo、多仓库微服务、几十年积累的 legacy 系统、多语言工程，甚至包括 C、C++、C#、Java、PHP 这类很多团队不一定第一时间联想到 AI 编程工具的语言。
┌─ New Word ────────────────────────────────────────────┐
│ 大型代码库：不一定只指“行数多”。它还包括多年老系统、 │
│ 多语言项目、多仓库微服务、复杂构建流程和大量团队约定。 │
└───────────────────────────────────────────────────────┘
2. 文章结构地图
这篇博客可以拆成四个大区：
┌────────────────────────────────────┐
│ Claude Code 大型代码库实践 │
│ (城市导航手册) │
└─────────────────┬──────────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌───────▼────────┐ ┌───────▼────────┐ ┌───────▼────────┐
│ 代码库导航方式 │ │ Harness 工具层 │ │ 三类配置模式 │
│ (找路方式) │ │ (装备系统) │ │ (施工方案) │
└───────┬────────┘ └───────┬────────┘ └───────┬────────┘
│ │ │
│ │ │
┌───────▼────────┐ ┌───────▼────────┐ ┌───────▼────────┐
│ 组织落地方式 │ │ 组件对照表 │ │ 适用边界 │
│ (运营团队) │ │ (工具说明书) │ │ (现实提醒) │
└────────────────┘ └────────────────┘ └────────────────┘
小明：为什么这里不按“功能列表”背？
张老师：因为这篇文章真正的逻辑是“怎样让 Claude Code 在复杂环境里少迷路”。先理解导航，再理解工具层，最后理解团队怎么维护它。
林姐：像装修办公室，先要知道人怎么走，再买设备，最后安排谁维护。
3. Claude Code 怎样在大型代码库里导航
张老师：博客强调一个核心区别：Claude Code 更像软件工程师一样在本地代码库里工作。它遍历文件系统、读文件、用 grep 类搜索工具定位内容，再顺着引用去理解代码。
小明：等等，它不是先把整个代码库“吃进去”吗？
张老师：这正是文章要澄清的地方。很多 RAG 类型工具会先把代码库切块、向量化、建立索引，再在提问时检索相关片段。但在大型活跃代码库里，索引可能落后于真实代码：昨天改名的函数、上周删除的模块，都可能还留在旧索引里。
林姐：所以 RAG 像图书馆旧目录，Claude Code 的方式像直接进现在的书架找书。
张老师：很形象。实际情况更细，但这个心智模型很稳。
┌─ New Word ────────────────────────────────────────────┐
│ RAG：Retrieval-Augmented Generation，检索增强生成。 │
│ 可以理解为“先查资料，再回答”。问题是资料索引可能过期。 │
└───────────────────────────────────────────────────────┘
┌─ New Word ────────────────────────────────────────────┐
│ Agentic search：让智能体像工程师一样主动搜索、读文件、 │
│ 跟踪引用，而不是只等一个固定检索系统喂给它片段。 │
└───────────────────────────────────────────────────────┘
导航方式对比
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ RAG 代码搜索 │ │ Claude Code agentic search │
│ (先建目录卡片) │ │ (现场走访) │
└──────────────┬───────────────┘ └──────────────┬───────────────┘
│ │
▼ ▼
建索引 / 向量化 读本地真实文件
│ │
▼ ▼
查询时取相关片段 grep / rg / 文件阅读 / 引用追踪
│ │
▼ ▼
风险：索引滞后 风险：没有起点会乱找
小明：那 Claude Code 这种方式是不是就完美了？
张老师：不是。它的代价是需要“起点上下文”。如果你在十亿行代码里问一个很模糊的问题，它还是会被上下文窗口和搜索范围卡住。
林姐：所以关键不是“把所有东西都塞给它”，而是“让它知道该从哪里开始找”。
4. Harness：模型之外的装备系统
张老师：文章说，一个常见误解是只看模型能力。实际上，Claude Code 的表现很大程度上由模型周围的 harness 决定。
小明：Harness 是什么意思？
张老师：可以理解为“马具”或“装备系统”。马很强，但没有鞍、缰绳、路线和骑手配合，跑不出稳定结果。对 Claude Code 来说，harness 包括配置文件、自动化脚本、技能包、插件、外部工具连接等。
┌─ New Word ────────────────────────────────────────────┐
│ Harness：围绕模型的一整套运行环境和工具系统。它决定了 │
│ 模型在真实工程流程里能不能稳定发挥。 │
└───────────────────────────────────────────────────────┘
Harness 层次图
┌────────────────────────────────────┐
│ Claude Code + 当前模型 │
│ (会思考的工程师) │
└─────────────────┬──────────────────┘
│
┌─────────────────────────┼─────────────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ CLAUDE.md │ │ Hooks │ │ Skills │
│ (路牌) │ │ (自动门禁) │ │ (专家卡片) │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ Plugins │ │ MCP │ │ LSP │
│ (工具包) │ │ (办事窗口) │ │ (IDE 地图) │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└─────────────────────────┼─────────────────────────┘
│
┌──────▼──────┐
│ Subagents │
│ (临时分队) │
└─────────────┘
张老师：文章特别强调，不同组件不是一锅乱炖。它们各自解决不同问题。
4.1 CLAUDE.md：给 Claude 的项目路牌
张老师：CLAUDE.md 是 Claude 每次会话开始时自动读取的上下文文件。根目录文件讲大图景，子目录文件讲局部约定。
小明：那是不是越详细越好？
张老师：这就是第一个坑。因为它每次都会加载，所以只适合放广泛适用、关键、稳定的知识。太多细节会拖慢理解，甚至干扰判断。
林姐：像办公室门口的公告栏，只贴“逃生路线、会议室规则、重要联系人”，不要贴每个同事今天午饭吃什么。
4.2 Hooks：让流程自动发生
张老师：Hooks 是在关键事件发生时运行的脚本。很多人只把它当成“防止 Claude 做错事”的拦截器，但文章说更有价值的是持续改进。
小明：比如？
张老师：会话结束时，让 stop hook 回顾这次工作，提出 CLAUDE.md 是否需要更新；会话开始时，让 start hook 动态加载某个团队或模块的上下文。对 lint、format 这类确定性检查，hook 比一句“请记得格式化”更可靠。
┌─ New Word ────────────────────────────────────────────┐
│ Hook：自动触发的小脚本。像门铃或传送带上的感应器，某个 │
│ 事件一发生，它就按规则做固定动作。 │
└───────────────────────────────────────────────────────┘
4.3 Skills：按需打开的专家手册
张老师：Skills 的价值是“按需加载”。大型代码库有很多任务类型：安全审查、文档更新、支付服务部署、数据分析等。不是每次会话都需要这些知识。
小明：那 Skill 和 CLAUDE.md 有什么区别？
张老师：CLAUDE.md 是每次都读的路牌；Skill 是需要时才打开的专家手册。把所有专家手册塞进路牌，会让路牌变成字典，反而没人看得清。
┌─ New Word ────────────────────────────────────────────┐
│ Progressive disclosure：渐进披露。先只显示必要信息， │
│ 等任务需要时再展开细节，避免一开始就信息过载。 │
└───────────────────────────────────────────────────────┘
4.4 Plugins：把好用的配置打包分发
张老师：Plugins 把 skills、hooks、MCP 配置等打包成可安装组件。它解决的问题是：一个团队摸索出的好配置，不要只留在少数人的电脑上。
林姐：像公司新员工入职包。装上之后，第一天就有常用工具、流程和知识。
小明：所以插件是为了规模化复制经验？
张老师：对。文章用的词是避免知识停留在“部落知识”状态，也就是只有少数老员工知道。
4.5 LSP：让 Claude 像 IDE 一样按符号导航
张老师：LSP 是 Language Server Protocol。它让编辑器具备“跳转到定义”“查找引用”等能力。把这种能力暴露给 Claude，就能让 Claude 按符号找代码，而不是只靠文本匹配。
小明：为什么文本匹配不够？
张老师：在大代码库里，一个常见函数名可能有几千个匹配。LSP 能区分“同名但不同含义”的函数，先过滤掉不相关结果。
林姐：像找人。文本搜索是全城叫“张伟”的都列出来；LSP 是知道你要找哪家公司、哪个部门的那位张伟。
┌─ New Word ────────────────────────────────────────────┐
│ LSP：语言服务器协议。它把编程语言的结构信息提供给编辑器 │
│ 或工具，比如定义、引用、类型错误。 │
└───────────────────────────────────────────────────────┘
4.6 MCP servers：连接 Claude 够不到的内部工具
张老师：MCP servers 用来连接内部工具、数据源、API、文档系统、工单系统、分析平台等。它们让 Claude 不只看代码，还能调用组织内的结构化工具。
小明：那是不是应该先造很多 MCP？
张老师：文章提醒，别太早。基础配置没跑顺之前，先做 MCP 可能是在没修路前先建收费站。要先保证 Claude 能读懂代码库，再扩展外部工具。
4.7 Subagents：把探索和编辑分开
张老师：Subagent 是一个独立的 Claude 实例，有自己的上下文窗口。它可以负责读代码、整理发现，再把最终结果交给主会话。
林姐：像侦察小队先去画地图，主工程师再动手改代码。
小明：那这样可以避免主会话读太多文件，把上下文塞满？
张老师：没错。尤其在大系统里，先探索、后编辑，是很稳的工作流。
5. 组件对照表：该把什么放在哪里
组件 | 可以理解为 | 何时加载 | 最适合做什么 | 常见误区 |
|---|---|---|---|---|
CLAUDE.md | 项目路牌 | 每次会话自动加载 | 项目大图景、广泛约定、关键提醒 | 把可复用专家知识全塞进去 |
Hooks | 自动门禁和传送带 | 事件触发 | lint、format、会话反思、动态上下文 | 用提示词替代确定性自动化 |
Skills | 专家手册 | 任务相关时加载 | 安全审查、文档流程、特定领域操作 | 和 CLAUDE.md 混用 |
Plugins | 入职工具包 | 安装后可用 | 组织内分发成熟配置 | 好经验只留在少数人手里 |
LSP | IDE 地图软件 | 配好后可用 | 按符号找定义和引用 | 以为它天然自动存在 |
MCP servers | 外部办事窗口 | 配好后可用 | 连接内部文档、工单、数据、API | 基础没做好就先连一堆系统 |
Subagents | 临时分队 | 调用时启动 | 探索、并行调查、上下文隔离 | 探索和编辑都挤在一个上下文里 |
6. 三类成功配置模式
文章总结了三类经常出现的成功模式。
模式一：让代码库在规模上可导航
张老师：第一类模式是“让代码库好找路”。不是让 Claude 读更多，而是让它更快找到正确的上下文。
做法 A：CLAUDE.md 精简且分层
根目录 CLAUDE.md 放全局地图和关键坑点；子目录 CLAUDE.md 放局部约定。
小明：那如果子目录里有 CLAUDE.md，根目录内容还会丢吗？
张老师：文章说，Claude 会沿目录树向上加载能找到的 CLAUDE.md，所以根目录的大图景不会丢。
做法 B：从相关子目录启动，而不是总在根目录启动
在 monorepo 里，很多人习惯站在根目录。但对 Claude 来说，任务在哪里，就从相关子目录开始，范围更清楚。
林姐：像去商场修一家店的灯，不是先从整个商场地图研究起，而是先到那家店门口。
做法 C：按子目录配置测试和 lint 命令
如果 Claude 只改了一个服务，不应该每次都跑全仓库测试。子目录 CLAUDE.md 应该告诉它这个模块对应的测试、构建、格式化命令。
小明：这样能减少超时和无关输出？
张老师：对，也减少 Claude 被噪音带偏。
做法 D：用 ignore 和 permissions.deny 排除噪音
生成文件、构建产物、第三方代码通常不该让 Claude 反复读取。文章提到可以把排除规则版本化，让团队共享同一套降噪配置。
张老师：但也有例外。如果团队正在开发代码生成器，生成文件本身可能就是工作对象，这时可以用本地设置覆盖项目级排除。
做法 E：目录结构不清楚时，手写 codebase map
如果顶层目录很多、历史包袱重、命名不清晰，可以在根目录放一个轻量 Markdown 地图：每个顶层目录一行说明。
小明：这像给旧仓库补一个“目录索引”。
张老师：完全正确。
做法 F：配置 LSP，让搜索从字符串升级为符号
文本搜索在大代码库里容易返回太多结果。LSP 能先按语言语义过滤，再让 Claude 打开更少、更准的文件。
模式二：随着模型进步，主动维护配置
张老师：第二类模式是“配置会过期”。以前为了弥补模型弱点写的规则，未来可能会限制新模型发挥。
小明：比如以前让 Claude 每次只改一个文件，是为了稳；但新模型可能已经能处理跨文件重构？
张老师：对。如果旧规则还留着，它就会把新模型绑住。文章建议团队每三到六个月做一次配置审查，也可以在重大模型发布后审查。
林姐：所以 CLAUDE.md、skills、hooks 不是写完就永远不动，而是像软件依赖一样需要维护。
模式三：给 Claude Code 管理和采用分配所有权
张老师：第三类模式是组织层。技术配置自己不会推动采用。成功推广通常需要专门的人或小团队提前把工具、插件、MCP、流程准备好。
小明：这是不是 developer experience 团队的活？
张老师：很多组织确实放在开发者体验或开发者生产力团队里。文章也提到一种新兴角色：agent manager，类似 PM 和工程师的混合角色，负责管理 Claude Code 生态。
林姐：如果没有专门团队，至少要有 DRI？
张老师：是的。DRI 指 Directly Responsible Individual，也就是明确负责的人。这个人要能决定设置、权限、插件市场、CLAUDE.md 约定，并负责让它们保持最新。
┌─ New Word ────────────────────────────────────────────┐
│ DRI：直接负责人。不是“大家都关心”，而是“出了问题知道找谁，│
│ 需要决策知道谁拍板”。 │
└───────────────────────────────────────────────────────┘
张老师：文章还提醒，在大组织和受监管行业里，治理问题会很早出现。比如：哪些 skills 和 plugins 可以用？怎样避免几千个工程师重复造同一个工具？AI 生成的代码怎样进入和人类代码一样的 review 流程？
林姐：所以比较稳的做法是先批准一组工具和流程，小范围开放，随着信心增加再扩大？
张老师：对。文章也建议尽早建立跨职能工作组，让工程、信息安全、治理相关同事一起定义要求和 rollout 路线。
7. 适用边界：这套建议默认什么前提
小明：这篇文章是不是适用于所有项目？
张老师：它主要假设一种常规软件工程环境：工程师是主要代码贡献者，仓库使用 Git，代码目录结构相对标准。大部分大型代码库都接近这个模式，所以建议有普适性。
林姐：那哪些情况更麻烦？
张老师：比如游戏引擎项目里有大量二进制资产，或者组织使用非传统版本控制系统，或者大量非工程师也在贡献代码。这些场景不是不能用 Claude Code，而是需要更多针对性配置。
┌─ New Word ────────────────────────────────────────────┐
│ 适用边界：一套方法默认成立的条件。知道边界不是泼冷水， │
│ 而是避免把好方法误用到完全不同的地形上。 │
└───────────────────────────────────────────────────────┘
8. 整体数据流：一次 Claude Code 任务怎样跑起来
假设一个工程师想让 Claude Code 修改 payments 服务里的一个 bug：
工程师在 payments/ 启动任务
│
▼
┌──────────────────────┐
│ 加载根 CLAUDE.md │
│ (全局地图) │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ 加载 payments/CLAUDE.md│
│ (局部规则和命令) │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ 使用 rg / 文件阅读 / LSP│
│ 找到相关代码 │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ 需要时加载 Skill │
│ (比如支付部署流程) │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ 修改代码并跑局部测试 │
│ hooks 自动检查格式 │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ 可选：subagent 探索 │
│ 可选：MCP 查内部系统 │
└──────────┬───────────┘
│
▼
提交给人类 review
小明：为什么不能一开始就把全仓库、所有文档、所有工具都给 Claude？
张老师：因为上下文不是仓库越满越好，而是越相关越好。就像做菜时不用把超市搬进厨房，只需要拿对食材。
9. 最重要的学习结论
结论一：大型代码库里的 Claude Code 是“现场导航”，不是“全知索引”
它从真实本地代码库工作，避免了旧索引问题；但它需要清楚的起点、目录地图和局部规则。
结论二：Harness 和模型同样重要
模型能力只是发动机。CLAUDE.md、hooks、skills、plugins、LSP、MCP、subagents 这些配置层决定发动机能不能接到真实工程流程里。
结论三：不要把所有知识塞进 CLAUDE.md
CLAUDE.md 放每次都该知道的内容；skills 放任务型专家知识；hooks 放自动化动作；plugins 用来分发成熟配置；MCP 连接外部系统。
结论四：组织所有权决定能否规模化
没有 DRI 或平台团队，配置会分裂，经验会停留在个人电脑上，采用会慢慢停滞。
10. 从博客转成行动清单
如果你要把这篇博客应用到自己的项目，可以按这个顺序做：
写一份根目录 CLAUDE.md，只放项目大图景、关键命令、重要坑点和导航入口。
给重要子目录补局部 CLAUDE.md，写清楚局部约定、测试命令、lint 命令和常见风险。
在大型或混乱仓库里补一份 codebase map，每个顶层目录一句话。
排除生成文件、构建产物、第三方依赖等噪音，并把共享规则版本化。
配置对应语言的 LSP，让 Claude 能按符号而不是纯文本找代码。
把重复任务做成 hooks，比如格式化、lint、会话结束后的文档更新建议。
把特定工作流做成 skills，比如安全审查、发布流程、文档同步、数据查询。
把成熟的 skills、hooks、MCP 配置打成 plugins，给团队统一分发。
基础稳定后再接 MCP，连接内部文档、工单、数据平台或搜索工具。
对大型探索任务使用 subagents，让主会话保留编辑上下文。
指定 DRI 或小团队负责配置、权限、插件市场和审查节奏。
每三到六个月复查配置，尤其在新模型发布后清理过时限制。
11. 常见误区和修正
误区 | 修正 |
|---|---|
“模型强就够了。” | 大型代码库更依赖 harness、导航和组织流程。 |
“CLAUDE.md 越长越好。” | 每次加载的文件越要精简；细节应该分层或放 skill。 |
“RAG 索引一定更适合大仓库。” | 活跃代码库里索引可能过期；现场搜索能看到当前真实状态。 |
“Hooks 只是防止 Claude 犯错。” | Hooks 更重要的价值是自动化一致动作和持续改进配置。 |
“MCP 越早越多越好。” | 先让基础代码导航和配置跑顺，再连接外部系统。 |
“采用是个人自发行为。” | 规模化采用需要 DRI、治理、插件分发和 review 流程。 |
12. 课堂小测
┌───────────────────────────────────────────────────────┐
│ Quick Check #1 │
│ 问：为什么文章认为大型代码库中 RAG 索引可能出问题？ │
│ a) 因为 RAG 永远不能处理代码 │
│ b) 因为索引可能落后于真实代码变化 │
│ c) 因为 grep 比所有系统都聪明 │
│ │
│ 小明：我选 b。旧目录可能跟不上每天提交。 │
│ 张老师：对。文章不是否定所有 RAG，而是指出活跃大型仓库 │
│ 中“索引滞后”会造成错误上下文。 │
└───────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────┐
│ Quick Check #2 │
│ 问：什么内容最适合放进根目录 CLAUDE.md？ │
│ a) 所有安全审查流程细节 │
│ b) 项目大图景、关键命令、全局坑点 │
│ c) 每个团队自己的全部内部文档 │
│ │
│ 林姐：应该是 b。 │
│ 张老师：对。a 更适合 skill，c 容易把全局上下文变成噪音。 │
└───────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────┐
│ Quick Check #3 │
│ 问：LSP 主要帮 Claude 解决什么问题？ │
│ a) 按符号理解代码导航，而不只是文本搜索 │
│ b) 自动替团队写所有测试 │
│ c) 替代代码 review │
│ │
│ 小明：我差点选 b，因为听起来很厉害。 │
│ 张老师：很正常。但正确答案是 a。LSP 是地图软件，不是自动 │
│ 交付保证。 │
└───────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────┐
│ Quick Check #4 │
│ 问：Skills 和 CLAUDE.md 的关键区别是什么？ │
│ a) Skills 按需加载，CLAUDE.md 每次加载 │
│ b) Skills 只能写代码，CLAUDE.md 只能写中文 │
│ c) 两者没有区别 │
│ │
│ 林姐：a。像专家手册和门口公告栏。 │
│ 张老师：正解。这个区别能避免上下文膨胀。 │
└───────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────┐
│ Quick Check #5 │
│ 问：为什么组织需要 DRI 或 agent manager？ │
│ a) 为了集中沉淀配置、权限、插件和最佳实践 │
│ b) 为了让所有人只能用同一种写代码方式 │
│ c) 为了减少代码 review │
│ │
│ 小明：是 a。没人负责就会变成大家各玩各的。 │
│ 张老师：对。治理不是为了束缚，而是为了让好经验能复制。 │
└───────────────────────────────────────────────────────┘
13. 复习用短版
张老师：我们最后把整篇文章压缩成一张小纸条：
Claude Code 在大代码库里靠现场搜索、读文件、跟引用来导航，不依赖预先上传的代码索引。
这种方式需要好起点：精简分层的 CLAUDE.md、清楚的目录地图、局部测试命令、噪音排除和 LSP。
Harness 比单个模型指标更决定真实效果；不同组件要放在正确位置。
成功部署还需要组织层所有权：DRI、平台团队、治理、插件分发、定期配置审查。
小明：我现在理解了。不是“让 Claude 变成全知”，而是“让 Claude 像一个新来的好工程师那样快速上手”。
林姐：而且新来的工程师需要的不只是文档，还需要工具、权限、流程和有人维护。
张老师：很好。下一次我们可以把这篇文章变成你自己项目的落地模板，比如写一份根 CLAUDE.md、一个子目录 CLAUDE.md 模板，以及 hooks/skills/plugins 的分工表。
14. 下次可以继续的方向
根据你的某个仓库，做一份真实的 codebase map。
设计一套根目录 CLAUDE.md + 子目录 CLAUDE.md 模板。
把“哪些内容进 CLAUDE.md，哪些做成 skill/hook/plugin”做成决策树。
为团队落地 Claude Code 写一份 30 天 rollout plan。
做一份配置审查清单，用于每三到六个月清理过时规则。
继续阅读
基于全文检索与主题相似度