# 把 Claude Code 开成一家公司：headcount 与组织型 Skill 三连拆
## 概述
## 一、数据底座：三条曲线与一个 24.6 万星的背景板
先把本期三个对象的三期快照摆齐：
| 仓库 | 08-31 | 09-01 | 09-03 | 窗口变化 | 隐喻 |
|------|-------|-------|-------|---------|------|
| **cbrock84/headcount** | 783 | 892 | **1113** | **+330（+42.1%）** | 公司 |
| useagenthq/useagent | — | — | 274 | 首次进入快照 | 同事 |
| subsy/skill-cabinet | — | — | 362 | 首次进入快照 | 柜子 |
三个测量结论。**其一，headcount 是加速曲线**：两段增速 +13.9%、+24.8%，第二段比第一段快近一倍——对比第 6 轮拆过的 codex-with-chatgpt（+20.6%、+11.5% 递减），headcount 走的是完全相反的形态：基数越大涨得越快，说明它在突破某个传播圈层而不是消耗存量关注。它是 09-03 新星榜前 20 里第 4 大星数的仓库，也是第 6 轮统计出的“四家明确以 Skill 形态自述”中体量最大的一家。**其二，useagent 与 skill-cabinet 都是 09-03 快照的新面孔**，无历史曲线可查，只能给横截面——这也是本期把主拆位给 headcount 而非两者的硬理由：数据量决定拆解深度。**其三，背景板**：affaan-m/ECC 以 244968→246320（+1352）的量级挂在本周热榜，描述是 "The agent harness performance optimization system. **Skills**, instincts, memory, security…"——第 1 轮已指出这意味着 Skills 正在泛化为 Agent 工程的通用器官名词，本期补一句：headcount 的“公司化”正是同一个泛化进程的**结构化分支**——ECC 说技能是器官，headcount 说技能要按组织图排列。
## 评测对比表
权重沿用本栏口径：功能 25%、设计 25%、实战 20%、上手 15%、社区 15%（上手分越高越容易）：
| Skill | 核心定位 | 功能 25% | 设计 25% | 实战 20% | 上手 15% | 社区 15% | 加权总分 |
|---|---|---|---|---|---|---|---|
| **headcount** | 公司制 Agent 组织（125+ 技能） | ★★★★ | ★★★★☆ | ★★★ | ★★★ | ★★★★☆ | **3.80** |
| useagent | 自带云电脑的开源 AI 同事 | ★★★★ | ★★★☆ | ★★★ | ★★★ | ★★★☆ | **3.45**（沿用第 6 轮对照分） |
| skill-cabinet | 技能收纳柜（无描述） | ★★ | ★ | ★★ | ★★ | ★★ | **1.75**（沿用第 1 轮周报分） |
> 评分说明：全部为黑箱估分，SKILL.md 正文未取得。headcount 的功能分基于描述中“15+ 部门、125+ 技能”的广度承诺，设计分基于描述工程（详见下节），实战分压至三星是因为 125 个技能的质量分布完全无法验证；若实测发现大量“闲岗”应下调功能与实战两项。
## 二、主拆 headcount：一句话描述里的五个设计决定
> An agent organization for Claude Code, structured as a company — 15+ departments, 125+ skills, each
就这一句（外加一个截断的 "each"），能榨出五个设计决定：
**① 开头名词是 "organization"，不是 "skill"。** 对比本期同榜的其他 Skill：story-to-handdrawn-video 用 "Agent skill:" 开头声明形态，headcount 却把品类词换成了 "organization"。这不是疏忽，是定位声明——它卖的不是“一个能干活的技能”，而是“一个干活的**结构**”。类比第 6 轮的结论：codex-with-chatgpt 卖的是架构重组（brain 与 harness 分离），headcount 更进一步，连“组织架构”本身都成了产品。技能市场的品类词正在从功能词（画图/写PPT）向上迁移为结构词（organization/系统），这是描述工程层面的新信号。
**② "structured as a company"——隐喻即架构文档。** 公司隐喻自带上千年的管理学预设：分工、汇报线、岗位说明书。用户不需要读 README 就能预测行为边界——市场部不会去改数据库迁移脚本，法务岗不会自己部署到生产环境。隐喻在这里不是文案修辞，是**压缩到四个单词的交互契约**。对比第 6 轮拆过的 dsh-deep-whale（鲸鱼娘皮肤隐喻，纯情感向）和 useagent（同事隐喻，横向协作向），公司隐喻的独特点是**自带科层**：它承诺的不是“多了一个帮手”，而是“多了一套分工”。
**③ "15+ departments" 是中观层的存在宣言。** 这个数字承认了一件很多技能合集仓库不敢承认的事：125 个技能不能平铺。15+ 部门意味着作者在技能与用户之间插入了**一层路由中间件**——先按部门分流，再按岗位执行。用管理学的话说，平均每个部门管理约 8 个岗位（125÷15），恰好落在“管理幅度”（span of control）的经典舒适区（7±2）。数字是精心挑的，还是自然长成的，无法验证（**存疑**），但“15 与 125 的比值落在管理学的舒适区”这个事实本身值得记录。
**④ "125+ skills" 是信任函数，也是上下文预算问题的引子。** 规模数字在描述里的作用是信任背书——125+ 对 15+ 的倍数关系暗示“部门是真实的分组而非凑数”。但它同时暴露了这类产品最要命的工程问题：125 个技能怎么装进上下文？这是本文第三节的主角。
**⑤ 截断的 "each"——粒度从集合下沉到个体。** "each" 开启的从句极可能是 "each with its own SKILL.md" 或 "each specialized in…"（**两种均未证实**），无论哪种，它都把承诺粒度从“我有一堆技能”下沉到“每个岗位有独立说明书”。在官方 skill-creator 的模型里，一份独立 SKILL.md 就是一份独立触发的描述单元——"each" 这个词等于预告了 125 份独立的触发契约。
## 三、黑箱推演：125 个技能的上下文经济学
SKILL.md 未取得，但按官方 skill-creator 的加载模型（描述层约 100 词、常驻上下文、目录检索与 Agent 触发只认它），可以算一笔硬账：**若 125 个技能平铺注册，描述层就要吃掉约 12,500 词的常驻预算**——在任何长任务开始之前，上下文就先被“员工名册”占掉一大块。因此一份设计合格的 headcount 只有一种活法：**两级触发**。用黑箱推演画出来（内部实现未读取，结构为按描述与官方加载模型推断）：
```mermaid
flowchart TD
U[用户请求] --> R[公司层：根描述常驻
只含 15+ 部门的部门名+一句话职能]
R --> Q{按部门分流}
Q --> D1[研发类部门]
Q --> D2[内容类部门]
Q --> D3[运营类部门
...共 15+]
D1 --> S[命中部门的岗位 SKILL.md
按需加载 = 第二级触发]
S --> W[具体岗位执行
125+ 之一]
```
这个两级结构与生态里已有的三件作品形成有趣的对照。**其一，sepia**（第 2 轮拆过，77+ 集成）：用路由表解决同类问题，但 sepia 的路由是“一个技能对外部的 77 种接入”，headcount 是“125 个技能对用户的 1 张组织图”——方向相反，压力相同。**其二，find-skills**（09-01 存档：安装量 3.2M、总榜第一）：教 Agent 去**外部市场**按需找技能，是“用检索换内存”的路线；headcount 是“把 125 人编制一次装进自家仓库”，是“用组织换检索”的路线。两条路线的赌注完全相反：前者赌市场分发效率，后者赌本地确定性。**其三，ECC** 描述里的 "Skills, instincts, memory" 三分法暗示业界的共识方向：技能要分层、要有触发本能、要有记忆沉淀——headcount 的部门层恰好是“分层”的具体化。
## 四、副拆 useagent：同事隐喻与“平台化反例”
**[useagenthq/useagent](https://github.com/useagenthq/useagent)** | ⭐274（09-03 首次进入快照）| 描述原文（逐字，截断保持原样）：
> The open-source AI coworker for your team: agents with their own cloud computer, your tools and cont
三个设计决定。**① "coworker" 是横向隐喻**：同事加入你现有的团队，公司则要你自建科层——与 headcount 放在同一坐标系里看，两者覆盖的是组织化的两个方向：**headcount 是纵向的（建一套结构），useagent 是横向的（加一个成员）**。对个人开发者，同事够用；对要跑生产线的团队，公司更有吸引力。**② "agents with their own cloud computer" 是隔离承诺**：每个 agent 带独立运行时，这直接决定了它的形态——它不可能是“拷进 skills 目录就能用”的纯文件分发，必然带平台组件。它因此是 Skill 生态的**邻近物种**：用生态的语言（agent、技能）讲平台的故事。第 6 轮把它列为对照位并给了 3.45 分，本期维持该分不改。**③ "your tools and cont[rol]" 的主权承诺**（截断处按词形推断为 control，**未证实**）：工具是你的、控制权在你——这是开源产品对标商业“AI 员工”服务（各类 SaaS 化数字员工）的标准差异化句式，"open-source" 放在 "coworker" 前面同理。一句话概括：**useagent 把组织化的最小单位（一个人）做成了产品，headcount 把完整组织（125 人）做成了仓库**。
## 五、副拆 skill-cabinet 与隐喻光谱
**[subsy/skill-cabinet](https://github.com/subsy/skill-cabinet)** | ⭐362（09-03 快照，新星榜）| 描述栏：**无描述**。第 1 轮周报已给它建过档（1.75 分）并借此讲过“两套适应度函数”的教训：Star 涨在社交通道，触发通道因描述空缺而整体关闭。本期不再重复教案，只把它放进本期的坐标系——**柜子隐喻**。柜子是被动存储：不承诺行为、不承诺分工，你放什么它收什么。与同事（横向协作）、公司（纵向科层）连成一条光谱：
**柜子（存储，零行为承诺）→ 同事（协作，单点加入）→ 公司（科层，全套结构）**
这条光谱本质上是**行为承诺的阶梯**：隐喻越复杂，产品对用户的行为承诺越重，工程兑现的难度越高，翻车面也越大。skill-cabinet 无描述所以承诺为零（也因此触发为零）；useagent 承诺一个隔离的同事（要兑现云电脑）；headcount 承诺一整个公司（要兑现 125 份岗位说明书）。**隐喻的野心与上下文预算成正比，与单人维护能力成反比**——这是本期三连拆提炼出的第一条设计定律。
## 安装与试用
三件均未在本栏验证过市场分发入口，先探后装：
```bash
# headcount：组织型技能集，优先查仓库 README 的安装章节
npx skills add cbrock84/headcount
# 兜底：克隆后按 README 安装（确认它是整体目录、plugin 还是附带 harness 配置）
git clone https://github.com/cbrock84/headcount
# useagent：自带云电脑的平台型产品，大概率非 skills 目录形态
git clone https://github.com/useagenthq/useagent
# skill-cabinet：无描述，装前先读仓库确认功能
git clone https://github.com/subsy/skill-cabinet
```
（`npx skills add` 为本栏目历期沿用的市场安装写法，实际命令以各仓库 README 为准；本文引用描述均为 2026-09-03 快照原文，后续版本可能变动。）
## 推荐排行榜
- **增长最快**：headcount（+42.1%/窗口，且二段加速）
- **描述工程最佳**：headcount（结构词+隐喻+双数字+粒度下沉，一句话五层信息）；useagent 次之
- **形态诚实度**：useagent（承诺与形态自洽：要云电脑就带云电脑）；headcount 的安装形态待验
- **行为承诺最轻 / 翻车面最小**：skill-cabinet（零承诺）
- **最值得盯的未验证问题**：headcount 的两级触发是否真实存在——它决定 125+ 是工程还是文案
## 结论
1. **组织型是 Skill 生态的新品类词**。从 ECC 的“技能是器官”到 headcount 的“技能要按组织图排列”，Skills 正在从功能名词升格为结构名词——本周新星榜上，卖结构的仓库（headcount、codex-with-chatgpt）增速全面快过卖单点功能的。
2. **隐喻是压缩的架构文档，但兑现成本随隐喻复杂度陡增**。柜子、同事、公司的光谱，就是承诺与维护成本的光谱。装 headcount 前先验证两件事：两级触发是否存在、125 个岗位有多少还是“闲岗”。
3. **给想写组织型 Skill 的读者**：部门数取管理幅度的舒适区（7±2 个岗位/部门），根描述只写部门名+一句话职能，把词预算留给第二级触发——这是本期黑箱推演能给出的、成本最低的设计起点。
## 参考来源
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
