先说结论：headcount 这个项目本身不是工具，是一份"技能怎么组织"的答案。它最近有了中文版（cbrock84/headcount），把原项目 cbrock84/headcount 的文档完整翻译了一遍。原项目 2047 stars，主语言是 Markdown，MIT 协议。

我关注它，是因为一个很实际的问题：当团队里每个人都在往项目里塞 prompt、塞 skill、塞 rules 文件的时候，三个月后没人说得清哪个文件在什么时候被加载、谁负责维护、改了会不会影响别人。headcount 给了一种偏"公司治理"的解法，我觉得比单纯堆提示词更值得借鉴。

一句话：一个 CEO 之下设 16 个部门，共 172 项技能。每个部门是一个可独立安装的插件。

安装方式很直接，Claude Code 里：

/plugin marketplace add cbrock84/headcount
/plugin install security@headcount

关键设计在寻址方式上。技能用 

。这个命名空间的意义在于——名称永不冲突。你可以同时装安全部门和财务部门，两边的技能各自在自己的域里，不会出现两个都叫 

这一点我踩过坑。早前团队内部搞过一版共享 prompt 库，所有人往一个目录里丢文件，结果出现了三个 

，一个针对 Java、一个针对前端、一个针对 SQL。最后靠口头约定谁用哪个，纯靠人记。命名空间这件事看着简单，但它把"约定"变成了"机制"。

按部门安装不是洁癖，是硬约束

README 里有一句我觉得是全文最重要的信息：ChatGPT / Codex 侧，技能描述共享约 8000 字符的上下文预算，而全部 16 个部门合计约 50000 字符。

8000 对 50000，差了六倍多。这意味着"全装"在那边根本跑不起来。所以"只装会用到的部门"不是更整洁、更优雅的问题，是唯一可行的做法。

这条约束值得单独拎出来说，因为它暴露了一个很多人没意识到的成本：技能不是免费的。每一个被注册的技能描述都要占上下文，装得越多，留给实际任务的空间越少，而且模型在匹配时被干扰的概率也越高。你在 Claude Code 里可能感觉不明显，但换到有明确预算上限的环境，这个账立刻就算不平了。

我的判断是：不管你在哪个平台，都应该按这个约束来设计。先问"这个项目真正需要哪几个部门"，再动手装。默认全量加载的思路，在技能数量上到两位数之后就会开始出问题。

一种是自然语言触发。你在某个部门的领域里提问，匹配到的技能会自动加载。README 给了几个对照：

| "为什么这个落地页转化率不高？" | 

demand-generation:landing-page-cro-expert

| "在开始构建前审查一下这个设计" | 

| "我们负担得起这次招聘吗？" | 

这两种模式对应两种完全不同的使用心态。自动加载适合"我知道我要解决什么问题，但不确定该找谁"；显式调用适合"我很清楚我要财务建模，别给我扯别的"。工程上我更倾向后者——可控。自动匹配在技能少的时候体验很好，技能一多，匹配错位的概率就上来了，而且错位往往是静默的，你以为加载了安全审查，实际加载的是别的什么，输出看着也像那么回事。

审查类部门：会叫停，不只是加意见

README 里提到一个细节，我觉得是区分"真技能库"和"提示词合集"的分水岭。

它说 docs/USE-CASES.md 里演练了十一个跨部门场景，包括企业客户提出的 SOC 2 要求、两个站点之间的链路中断、因无人负责日期而自动续订的合同，并且说明了"返回什么结果，以及审查类部门在何处叫停工作而非仅仅添加意见"。

"叫停工作"这四个字很关键。大部分提示词库的定位是"给你一些建议"，输出一段分析，然后你自己判断。但审查类技能的定位应该是 gate——不通过就不往下走。这两者的工程含义完全不同：前者是辅助，后者是流程里的一个卡点。

如果你要把这类东西接进 CI 或者发布流程，"会不会叫停"直接决定了它能不能当门禁用。只会输出意见的技能，本质上还是个聊天助手。

另一个我觉得有工程价值的点：每个部门在 

 里附带一份智能体章程，因此部门可以作为子智能体被委派，拥有自己独占的写入范围。

"独占写入范围"这个词在多人协作或者多智能体编排里分量很重。它意味着部门之间的职责边界是文件级的，不是口头级的。CEO 办公室那个部门里有个技能叫 

，README 描述是"为仓库设计编排器与子智能体层级——按独占写入范围拆分智能体，为每个生产者配备独立审计者"。

生产者配独立审计者，这个模式在传统工程里很常见，放到智能体编排里同样成立。让写代码的和审代码的是两个不同的智能体、不同的写入范围，比让同一个智能体自查要靠谱。这不是什么新发明，但把它写进技能库的组织结构里，说明作者是认真想过职责分离的。

中文版解决了什么，没解决什么

回到中文版本身。它做的事情很清楚：文档中文化，外加一份"中文快速上手"导读。

导读部分明确标注了是"面向中文用户的补充导读（非原文内容）"，目的是让你不用读完整篇 README 就能先把项目跑起来。这个分层做得挺诚实——原文翻译和补充导读分开标注，不混在一起。

对国内团队来说，实际降低门槛的地方在于：安装命令、环境要求、常见坑这几块不用再对着英文猜。尤其是"ChatGPT / Codex 侧有 8000 字符预算"这种关键约束，中文读者能第一时间看到，不至于装了一堆部门之后才发现跑不动。

没解决的部分也要说清楚。README 里明确写了：操作系统原文未说明，硬件原文未说明，版本要求原文未说明，国内网络环境相关的镜像源或加速下载原文未提及。也就是说，中文版是文档层面的翻译，不是环境层面的适配。你该有的网络问题还是有，该自己判断的平台兼容性还是得自己判断。

翻译质量有没有问题、后续原项目更新了中文版跟不跟，这些都还没有样本可看。我的态度是：文档翻译这件事本身价值明确，但维护节奏需要观察一段时间。如果你的团队打算长期依赖，建议直接盯原仓库的更新，把中文版当参考而不是唯一来源。

基于上面这些约束，如果让我给一个团队排落地顺序，大概是这样：

先评估平台。headcount 的技能运行在 Claude Code 和 ChatGPT / Codex 中，两边技能文件相同、只有 manifest 不同。你得先确认自己的主力环境是哪个，再决定走哪条安装路径。README 提到两套清单都从同一个目录树生成，所以一次修复会同时到达两边——这是维护上的好处，但你得先选定一边跑通。

再评估上下文预算。如果目标环境有类似 8000 字符这种硬上限，那就必须做减法。先列出项目真正涉及的领域，映射到部门，只装这几个。宁可少装，不要先全装再删——删的时候你很难判断哪个技能正在被隐式依赖。

然后是审查类技能的接入位置。想清楚哪些环节需要"叫停"能力，哪些只需要"给意见"。需要叫停的，才值得接进流程卡点；只需要意见的，放在日常对话里就够了，别硬塞进门禁。

最后才是子智能体编排。独占写入范围、生产者配审计者这套东西，收益大但复杂度也高，建议在单部门跑顺之后再往上叠。

headcount 用公司组织架构来类比技能组织，这个隐喻好不好用，我觉得因人而异。16 个部门、172 项技能，对个人开发者来说可能偏重；对有一定规模、职责边界本来就清晰的团队，反而容易对上号——因为你团队里本来就有安全、财务、运维这些角色，映射过去很自然。

真正值得抄的不是"CEO 下设 16 个部门"这个形式，而是背后那几条约束：命名空间避免冲突、按需加载控制预算、审查类技能要能叫停、智能体之间要有独占写入范围。这几条跟公司不公司的没关系，是纯粹的工程治理问题。

中文版把这几条讲清楚了，剩下的就是你自己判断该装哪几个部门。

headcount 工程视角：把 172 个技能塞进 16 个部门，这个组织方式值得抄

人工智能

开发工具

架构设计

headcount提供了一套以“公司部门”为框架的技能组织方案，含16个部门172项技能，通过department:skill命名空间避免冲突。项目强调按需加载以控制上下文预算，支持自然语言自动触发与显式调用。审查类技能具备“叫停”能力，子智能体拥有独占写入范围，适合多智能体协作。中文版已上线，完整翻译并附快速上手导读。

智能体

Markdown

ChatGPT

Agent

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

headcount提供了一套以“公司部门”为框架的技能组织方案，含16个部门172项技能，通过department:skill命名空间避免冲突。项目强调按需加载以控制上下文预算，支持自然语言自动触发与显式调用。审查类技能具备“叫停”能力，子智能体拥有独占写入范围，适合多智能体协作。中文版已上线，完整翻译并附快速上手导读...

headcount 工程视角：把 172 个技能塞进 16 个部门，这个组织方式值得抄

headcount 工程视角：把 172 个技能塞进 16 个部门，这个组织方式值得抄

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐