企业官网建设流程全解析

谁在维护你的 CLAUDE.md？官方文档治理插件横向实测

【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-plugins-official

在 Claude Code 的日常使用中，CLAUDE.md是最特殊的一个文件：它既是 Claude 读取项目上下文的"记忆体"，也是团队知识沉淀的载体。可现实往往是——代码每天都在变，CLAUDE.md却半年没动过；新成员靠它上手，但它写的命令早就跑不起来了。官方插件仓库claude-plugins-official里恰好躺着三个与文档治理直接相关的插件，社区文章也把它们单独拎出来对比过：claude-automation-recommender（配置推荐）、claude-md-improver（文档审计）、/revise-claude-md（会话沉淀）。本文不满足于功能罗列，而是直接钻进仓库源码，把三个插件的实现逐行拆开，并在同一项目上实测它们的表现差异，最后按团队角色给出可落地的选型结论。

一、CLAUDE.md：项目记忆，却常常没人维护

Claude Code 会自动发现项目中的CLAUDE.md并把它作为上下文注入会话，因此它的质量直接决定 AI 助手对项目的理解深度。官方仓库对此的定位很明确：plugins/目录存放 Anthropic 内部维护的插件，external_plugins/存放合作伙伴的第三方插件（见仓库根目录 README.md）。而文档治理相关的三个能力，全部集中在两个内部插件中：

• claude-code-setup：内置claude-automation-recommender技能，分析代码库并推荐配套自动化配置；
• claude-md-management：内置claude-md-improver技能 +/revise-claude-md命令，一个负责审计改进，一个负责会话沉淀。

社区的实测文章已经点出这三者的核心差异在于"读写权限、适用场景、与现有工具链的兼容性"——但那是黑盒视角。下面我们从源码出发，看看它们到底是怎么分工的。

二、三个官方文档插件，分工各不相同

2.1 claude-code-setup：只读的"自动化军师"

claude-code-setup/README.md 一句话概括了它的定位：扫描代码库，推荐最适合该项目的 Claude Code 自动化方案——hooks、skills、MCP 服务器、子代理、斜杠命令，五个类别各挑最有价值的 1-2 个。

关键约束写在技能文件的第二行（SKILL.md）：

This skill is read-only.It analyzes the codebase and outputs recommendations. It does NOT create or modify any files.

也就是说，它连CLAUDE.md本身都不碰，产出物是一份"推荐报告"。它的价值在于搭建：告诉你在.claude/settings.json放哪些 hooks（自动格式化、自动 lint、封禁.env编辑）、在.claude/agents/放哪些子代理（安全审查、性能分析）、接哪些 MCP（context7、Playwright、GitHub）。对文档治理而言，它是"上游"——先让整个 Claude Code 环境自动化跑起来。

2.2 claude-md-management：审计 + 沉淀的双引擎

与 recommender 的"只动嘴"不同，claude-md-management 是真正会动手写CLAUDE.md的插件，由一 skill 一 command 组成（见 README.md 中的对照表）：

claude-md-improver的工作流是五阶段流水线（SKILL.md）：发现 → 质量评估 → 输出报告 → 提出定向修改 → 获批后写入。它先用find命令找出仓库里所有CLAUDE.md、.claude.md、.claude.local.md，然后按六个维度打分（Commands/Workflows 20 分、Architecture 20 分、Non-obvious Patterns 15 分、Conciseness 15 分、Currency 15 分、Actionability 15 分，满分 100，见 quality-criteria.md），输出报告后再逐条展示 diff 等待用户批准。

而/revise-claude-md则是一个典型的"会话复盘"命令（revise-claude-md.md）：反思本会话用到了哪些 bash 命令、踩了哪些坑、发现了哪些配置怪癖，然后把最有复用价值的一条条提炼成<命令或模式> - <一句话说明>的格式，每条都要用户批准后才写入，并且明确区分"团队共享的 CLAUDE.md"与"个人私有的 .claude.local.md"。

2.3 三者分工一览

三、实测同一项目下的表现差异

纸上谈兵不算数。我选择直接在这个插件仓库本身上做实测——它既是三个插件的宿主，也是一个结构典型的多目录项目，足够暴露三者的行为差异。

3.1 实测方法

严格复刻每个插件源码中定义的第一阶段命令，在仓库根目录执行：

• claude-md-improver 的发现命令：find . -name "CLAUDE.md" -o -name ".claude.md" -o -name ".claude.local.md"
• claude-automation-recommender 的探测命令：检查package.json、.claude/、CLAUDE.md、src/等特征文件

3.2 claude-md-improver：面对"零文件"仓库，直接判 F

实测结果很直观：这个仓库里一个 CLAUDE.md 都没有。find返回空结果。这意味着 claude-md-improver 的第一阶段就会输出：文件数 0，平均分无从计算，全部标记为"缺失"。按它的评分标准（quality-criteria.md），"Missing or severely outdated"对应 F 级（0-29 分）。

这暴露了文档治理插件的第一个现实：它治理的是"CLAUDE.md 这一个文件"，而不是项目里所有文档。仓库根目录有详尽的 README.md 说明插件结构、安装方式和命名规范，但 improver 一律不读——它只认 CLAUDE.md。对应的改进路径在它的参考模板里（templates.md）：提供项目根精简版/完整版、包模块、monorepo 根四套模板，直接按模板补一个初始版本。也就是说，在"完全没有 CLAUDE.md"的项目里，improver 的产出从"质量报告"退化为"模板推荐"。

3.3 /revise-claude-md：没有记忆可沉淀，输出空报告

/revise-claude-md的表现同样取决于文件是否存在。它的反思清单（revise-claude-md.md）依赖"本会话中实际发生的事"：用过的 bash 命令、踩过的坑、测试经验。在零 CLAUDE.md 的项目里，Step 2 的find同样返回空，于是"决定每处新增归属哪里"这一步直接无解——没有文件可归属，只能建议用户先创建。它的一个隐性优势在这里反而凸显：它知道.claude.local.md的存在，即便团队文件不存在，个人私有文件依然可以是沉淀的落点，这比 improver 的"一刀切"更细。

3.4 claude-automation-recommender：无视文档，但精准识别"这是什么项目"

同一个仓库在 recommender 眼里完全是另一幅画面。它的探测逻辑（SKILL.md）根本不关心 CLAUDE.md 写得好不好，而是回答三个问题：这是什么技术栈？用了哪些依赖？已经配了哪些 Claude Code 能力？

在本仓库上实测，它至少能识别出四条硬线索：

• 仓库按/plugins与/external_plugins划分，且每个插件目录内含SKILL.md/commands//agents/——这是典型的"插件开发型"仓库，对应推荐plugin-dev（插件开发技能包）；
• 大量命令文件（/commit、/review-pr等）存在，对应commit-commands与pr-review-toolkit等 git 工作流插件（见 plugins-reference.md）；
• external_plugins/discord、telegram、imessage等目录里存在package.json，含有真实依赖（如@discordjs之类），对应推荐context7MCP 做实时文档查询（mcp-servers.md 的信号表：npm 包依赖 → context7）；
• 存在大量.env敏感文件处理需求与 hooks 模式，对应 .env 编辑封禁类 PreToolUse hook（hooks-patterns.md）。

它的产出是一份分门别类的推荐报告（MCP / Skills / Hooks / Subagents / Plugins 五类，每类 1-2 条），并且明确结束语："想要更多？可以就任一类别继续追问。"（SKILL.md 的 Output Guidelines）

3.5 三者实测结论：同一仓库，三种"维护姿势"

把三者在同一仓库的实测行为放在一起看，差异一目了然：

值得强调的是权限边界：recommender 明确声明只读；improver 的 SKILL.md 也写明"This skill can write to CLAUDE.md files，但必须先出质量报告、得到用户批准后才更新"；revise 命令更是每一步都要求确认。三者都遵守"先展示、后落盘"的原则，这在 AI 写文档的场景里是必要的安全设计——毕竟 CLAUDE.md 会被注入到每一次会话的上下文里，写错一行可能误导几十次对话。

四、按团队角色选型：谁该用哪个

社区实测文章的结论与源码行为高度一致：选型应基于项目阶段与角色，而不是"全都装"。给出一份可直接对照的结论：

1. 配置负责人 / 基础设施工程师 → claude-code-setup你负责的是"让 Claude Code 在项目里跑起来"。recommender 的只读特性让它天然适合初始化场景：它帮你把 hooks、MCP、子代理的清单一次给全，你再逐个落地。文档治理只是它的副产品——一个运行良好的自动化环境，本身就会减少 CLAUDE.md 的腐化速度。

2. 文档维护者 / 技术写手 → claude-md-improver你面对的是"已有 CLAUDE.md 但质量存疑"的存量项目。improver 的六维评分（命令完备性、架构清晰度、非显性模式、简洁性、时效性、可执行性）就是一份可量化的审计清单，配合 update-guidelines.md 里的"什么该加、什么不该加"（禁止补显而易见的类名注释、禁止堆通用最佳实践、禁止记一次性修复），能把文档治理变成可验收的工程活动，而非玄学。

3. 长期开发者 / 团队 Lead → /revise-claude-md你每天都在产出"只有开过这个会才知道"的经验。revise 的会话复盘机制（记录命令、风格、测试套路、环境怪癖）是把隐性知识显性化的最低成本路径。它对.claude.local.md的支持还给了个人偏好一个不与团队冲突的落点。社区对它的评价——"无侵入式工作流"——正是因为它从不主动打扰，只在会话结束被调用。

4. 组合拳建议最务实的路线是分阶段上三件套：首次配置用 claude-code-setup 搭环境 → 每周用 claude-md-improver 做一次质量审计 → 每次会话后用 /revise-claude-md 沉淀增量。三个插件在官方仓库中本就同源维护（同出自 claude-md-management 与 claude-code-setup 两个内部插件），安装命令统一为/plugin install，不存在兼容性成本（安装方式见根目录 README.md）。

五、结论

回到开头的提问：谁在维护你的 CLAUDE.md？答案是——取决于你想让维护发生在哪个环节。想要"从 0 到 1"的自动化环境，claude-automation-recommender 是入口；想要"从差到好"的存量治理，claude-md-improver 是质检员；想要"从无到有"的经验沉淀，/revise-claude-md 是记账本。三者共享同一套安全原则（先报告、后落盘），却在触发时机、读写权限与治理对象上形成完整的互补链。文档治理这件事，官方已经把工具拆得足够细，剩下的问题只有一个：你的团队，现在处于哪个阶段？

【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-plugins-official