第十四章 · 一个组织二十个人的 AIOS
上一章讲一个人怎么搭。这一章讲一个组织——二十个人的规模。
二十个人是个特殊的数。再少一点，靠默契能撑；再多一点，就得有制度。二十个人，正好是“默契不够用、制度还没长出来”的那一档。
这一章讲三个真问题：谁负责、怎么分工、谁说了算。
说明：本章案例来自一家连锁餐饮企业的真实实践。涉及内部人员、组织与经营的数据已做匿名处理，保留的是可迁移的方法结构。
先说一个不容易承认的事实。
一个人搭系统，最难的是“想清楚自己”。
一个组织搭系统，最难的是“谁说了算”。
为什么？因为组织里每件事都要过一道：这是谁的活？
一个人用 AI，错了就是你自己错了，认了改就行。
一个组织用 AI，错了要追责。而系统是“没有责任能力”的东西——你不能处罚它。
所以组织版的第一个设计，不是“能力”，是“责任”：
每个岗位对应的系统单元，必须同时是一个“责任单位”。
它不只是“采集数据、干活”，它还必须是“这件事出问题，找它”。
我们管这个叫责任楔子——一个岗位智能体，要能回答“这事归谁”。
如果它答不出，那它就只是一个工具。而一个组织里最贵的，就是“没人负责”。
具体差在哪？三个。
| 一个人 | 二十个人 | |
|---|---|---|
| 信息 | 你自己知道全部 | 没人知道全部 |
| 口径 | 你知道自己什么意思 | 同一个词，三个人三种理解 |
| 责任 | 自己担 | 必须能追到人 |
这三个差别，对应三个必做动作：
第一，口径必须写下来。（防“三个人三种理解”）
一个人用，你脑子里的口径就是口径。二十个人用，你的口径必须变成文字，否则它就只是“老板的想法”。
而且——必须有人维护它。因为口径会漂移（第六章讲过：一个体系散掉，往往不是被推翻的，是被“差不多就行”磨没的）。
第二，接口必须补齐。（防“没人知道全部”）
上一章讲过那次补接口的活：近三百个技能包，大部分没写“吃什么、吐什么”。一个人用的时候看不出来，二十个人用的时候，这是第一个塌的地方。
第三，每个单元必须能追到责任人。（防“没人负责”）
这一条是组织版独有的，也是最重要的。
这是这一章的核心。也是我们走了弯路才想明白的。
“把总部的系统给二十个人用”——你会本能地想：“简化一下，砍一部分。”
这个方向是错的。
我们最后走的路是：不是缩小，是降维。
差在哪，一张表：
| 缩小版 | 降维版 | |
|---|---|---|
| 做什么 | 砍功能，留一部分 | 结构全保留，改由谁来做 |
| 结果 | 功能少了，复杂度没少 | 复杂度降了，结构还在 |
| 谁干活 | 还是系统全自动 | 机器贴标签，主人写关键 |
| 能活多久 | 你不在就废 | 它在别人手里能自己长 |
具体到那件事上是怎么分的？
脚本负责“贴标签”，主人负责“写接口”。
为什么这么分？因为这两件事的成本结构完全不一样：
| 贴标签 | 写接口 | |
|---|---|---|
| 要的是 | 速度 | 判断 |
| 适合谁 | 机器批量做（越快越准） | 人一个个定（快不了） |
| 交给另一边会怎样 | 人会累死，还容易错 | 机器会编（编的接口比没有更坏） |
降维的本质一句话：把活按“这件事要的是判断，还是速度”切开，各给对它最合适的那一方。
这条也可以反过来用。你手上有一堆活要分给人机，先问一句：
这件事要的是“判断”，还是“速度”？
最怕的是反着给：让机器去做判断（它会编），让人去做批量（他会烦，然后出错）。
还有一个更深的变化。
传统的组织，是先画层级，再定岗位，再派活。
这套东西反过来：先定指标，岗位是这个指标的容器。
这张表一摆，差别就看出来了：
| 层级式 | 指标式 | |
|---|---|---|
| 先有什么 | 谁管谁 | 看什么数 |
| 岗位是 | 权力位置 | 指标的容器 |
| 加一个人 | 多一个位置 | 多一组指标 |
| 好不好的判据 | 上级满意 | 指标说了算 |
| 出问题 | 往上找 | 看哪个指标没到 |
为什么这个转变这么要命？
因为层级式问的是“谁管这一块”，指标式问的是“这一块看什么数”。
第一个问题，答案在人身上；第二个问题，答案在事上。
一个人多、层级多的组织，最怕的就是“这事谁管”——因为这句话问出来的时候，通常已经没人管了。
改成“这一块看什么数”之后，很多扯皮会自动消失：因为数不会两头都好看。
这一条对你有什么启发？
给你自己的系统定岗，别按“我要它干什么”，按“它看什么数”。
第二种，你才知道它到底行不行。
组织版还有一条线，是必须提前划的：哪些事绝对不能交给系统。
这个要写在最前面，比任何功能都靠前。
我们这边的做法是给一个极小的比例——人必须保留的那部分，只有 5%；剩下的 95%，可以交给系统。
听着像“系统几乎全包了”。但请注意那 5% 是什么：
| 系统干的 95% | 人保留的 5% |
|---|---|
| 采集、计算、比对、起草、提醒、执行 | 定方向、拍板、认责、处理不可逆的事 |
这 5% 不能省，也不该省。
因为它的性质不一样：它不是“难”，是“错了没法回头”。
一条规矩：凡不可逆的事，决策权必须在人手上。
为什么？因为系统不需要为后果活着，你需要。
一个替你做不可逆决定的系统，等于把后果留给你，把判断权拿走。没有人会签这样一份合同。
组织里必然出现一种情况：两个目标打架。
比如：
这种时候听谁的？
必须在系统上线之前就把顺序定死，不能临时讨论。
为什么？因为临时讨论的时候，赢的通常是当时喊得响的那个——而喊得响的，多半是业绩。
所以顺序是提前写死的：
安全（不可协商） > 业绩 > 效率 > 体验
从上往下，前面的一票否决后面的。
为什么要写死？因为这个顺序的价值，恰恰在“最容易违反它的那一刻”才体现出来——那一刻没有人会主动想起来。
写死的意义，就是让它在没人想起的时候也生效。
这一条你也可以用。你有几件事经常打架（比如“快”和“对”），提前把顺序写下来。写下来之后，你会发现：很多纠结根本不用纠结，只是你一直没定过序。
这一章的起点，是他 2026 年 9 月 11 日说的一句话：
“把这次智能体修订，完善，形成一个开发文档，我要复刻给味藏其他 20 人。”
我当时听到“复刻”两个字的时候，第一反应其实没觉得有什么。差点就按“部署”的意思去做了。
“部署”和“复刻”，差得很远：
| 部署 | 复刻 | |
|---|---|---|
| 我做什么 | 装一份给他们 | 给他们一份能自己长出来的东西 |
| 他们的角色 | 用户 | 主人 |
| 三年后 | 他们还在等我更新 | 他们有了自己的版本 |
“部署”的逻辑是：我造好，你用。
“复刻”的逻辑是：我给骨架，你长肉。
这两个字的差别，决定了整套东西的形态。
如果我按“部署”做，我会给味藏一套配置好的成品——今天好用，明年就旧了，因为它长不了。
按“复刻”做，我给的是方法和骨架，加上一个判断：哪些活该攒、哪些活该我干。
“复刻”这个词,是他选的。而我一开始差点理解错了。
这件事让我记住一条：别人给你的动词，往往比名词更重要。
“优化一下”、“复刻给二十人”、“你看着办”——不同的动词，藏着完全不同的期待。听漏了动词，活就干错了。
哪怕你手上只有三个人，这一步也能做。
第一步：定责任。
挑一件你现在最常扯皮的事，做一件事：写清“这事归谁”。
判据：把你手写的那句话念一遍——它能不能回答“出问题找谁”？
不能 → 它还是“一块业务”，不是“一个责任单位”。
第二步：分判断和速度。
拿你现在让 AI 干的活，列一张单子，每一条标：
然后检查一件事：有没有哪一条，你给反了？（最常见的是“让机器定标准”和“让人做批量”）
第三步：把岗位改成指标。
挑你团队里的一个角色，把“他负责什么”改写成“他看什么数”。
每条指标必须可复核（有具体数字、有来源）。写完你会立刻发现：有些角色原来根本没有指标。
第四步：定一个仲裁顺序。
写下你手上最常打架的两三个目标，排个序，写死。
然后加一句：这个顺序，在没人想起来的时候也生效。
1. 组织版的难点不在技术，在“谁定”。每个单元必须同时是责任单位——它要能回答“这事归谁”。组织里最贵的，是“没人负责”。
2. 降维，不是缩小。结构全保留，改由谁来做——按“这件事要的是判断还是速度”切开，各给对它的一方。岗位也不再是权力位置，而是指标容器（从“谁管这一块”改成“这一块看什么数”）。
3. 两条必须提前写死的：不可逆的事，决策权在人手上（人保留那 5%）；冲突的仲裁顺序提前定——写死的意义，就是让它在没人想起的时候也生效。
1. 挑一件你团队里最常扯皮的事，写一句“这事归谁”。它能回答“出问题找谁”吗？
2. 把你让 AI 干的活标一遍“判断／速度”。有没有给反的？举一个例子。
3. 把一个角色从“负责什么”改写成“看什么数”。你现在能说清这个数吗？（说不清，说明这个岗位其实是虚的。）
4. 写下你手上最常打架的两个目标，排个序。过去三个月里，它们打架的时候，实际赢的是谁？（答案多半不是你以为的那个。）
5. 想一个反例：有没有哪类组织，“不需要定指标、靠默契就能跑”反而是对的？（提示：想想那种五个人以内、天天见面、活很单一的团队。想清楚之后回答——它是不是只解决一件很窄的事？）