Claude Code 别再当工具用了：headcount 把它拆成了 15 个部门

先说结论

headcount 是一份给 Claude Code 准备的“公司组织架构”。它不写新模型，也不发明协议，只是把项目里常见的活，分门别类塞进 15 个部门、125 项技能里，每个技能都可以独立安装。这一周它在 GitHub 拿到 688 颗星，节奏比同类插件库快得多。值得装，但别贪多。

真正的问题

Claude Code 的插件市场越来越像早期的 npm：什么都有，挑花眼。装一套全家桶，配置目录会迅速膨胀到几十兆，模型启动时还得先把所有技能的描述塞进上下文。结果就是：真正用得上的那条指令，被淹没在一堆不相关的 system prompt 里。

更糟的是权限混乱。一个 review 技能和一个部署技能写在一起，模型很容易在 review 代码时顺手执行了 shell 命令——这不是 bug，是结构问题。

怎么做更省力

headcount 的解法很朴素：把“公司”当成组织单位。部门之间职责清晰，比如代码审查只读不写、CI 流水线只跑不删，安全部门默认拒绝一切高危操作。每个技能是一份 Markdown 文件，描述尽量短，模型读得快、判断得也快。

安装走 GitHub Releases，下哪个部门就只装哪个部门，不用 clone 整个仓库。配置目录干净得像只装了一个工具。

下面这张表是几个常用部门和它们的适用场景，按需挑就行：

| 部门 | 典型技能 | 适合谁 | 代价 |

| --- | --- | --- | --- |

| code-review | diff 解读、风格检查 | 个人开发者 | 几乎无 |

| devops | CI 配置、日志查询 | 小团队维护 | 需要写权限 |

| security | 密钥扫描、依赖审计 | 处理敏感代码 | 可能误报 |

| docs | README、API 文档生成 | 开源项目作者 | 中文术语需校对 |

装完一个部门，跑一个小任务验证一下，再决定要不要加下一个。别相信“一次到位”。

哪些坑要避开

第一，技能名撞车。不同项目里 review、reviewer、code-review 可能指向不同行为，headcount 用统一前缀是为了避免歧义，自己扩展时也要守这条规矩。

第二，权限没分开。devops 部门和 security 部门如果同时启用，模型偶尔会绕过去。要么拆开跑，要么在配置里写明优先级。

第三，别把部门当成“人”。它们只是技能包，没有记忆，没有上下文。一项工作做完就结束，下一次又是从头读描述。把这事当成工具箱，不是当成团队。

第四，Markdown 文件里写太多背景故事。模型会把背景当指令读，长度建议压在 300 字以内，动词在前、对象在后。

现在就能动手

打开 GitHub Releases，下载 headcount 的最新压缩包，只挑一个最常用的部门，比如 code-review。把它丢进项目的 .claude/skills/ 目录，重启 Claude Code。跑一次真实的 PR 检查，确认行为符合预期。

如果觉得好用，再加 devops；如果觉得审查太啰嗦，就只留 code-review。配置应当越用越少，不应当越装越多。

需要把这次改造整理成汇报，可以丢进职场汇报生成器，让它把“减少了哪些上下文噪音”翻译成领导看得懂的进度、价值和风险。