第 33 节 · AI System：零件拼成系统的样子¶
把这一本书的零件重新拼回去。这一节收口：从一个 Token，到一个 AI System。
一、把零件重新拼一遍¶
一台发动机拆开是几百个零件，但没有人靠"认得每个零件"就会造发动机——你得把它装回去，让它转起来。
前面三十二节，我一节拆一个零件。拆完之后桌上摆着这么一堆东西，每一个都是被一次具体的翻车逼出来的：
| 零件 | 它回答的那一个问题 | 我这边的一手数字 |
|---|---|---|
| 基座模型 | 一次前向到底在干什么 | 它只做一件事：给定前文，预测下一个 token |
| Small Model（第 23 节） | 为什么不用最大的那一个 | 两代基座八次微调、七次 No-Go；2B 与 4B 同题八项里七项打平 |
| Model Pool（第 24 节） | 为什么一个模型不够 | 配置里注册了 10 个服务；常驻内存按配置相加 10.2 GB |
| Router（第 25 节） | 这活该派给谁 | 三档（5.4 GB / 12 GB / 18 GB）；整条链路停摆过 9 天 |
| Context（第 26 节） | 开口之前得先读多久 | 三个上下文预算：20 万 / 100 万 / 4.8 万，最大最小差 20 倍 |
| Knowledge / Memory（第 27 节） | 一个组织怎么记住自己说过什么 | 387 篇笔记里只有 49 篇用了双链，约 13% |
| Agent（第 28 节） | 一个模型怎么变成一个"人" | 49 个角色定义 |
| 多 agent 协作（第 29 节） | 一群人怎么不互相踩脚 | 12 份早会记录；一次定的三件事 9 天后全部未闭环 |
| Harness / State（第 30 节） | 跑一半崩了怎么办 | 工作流引擎的技能定义文件 388 行、五个模块、68 个单元测试——但它从未真跑过 |
| Evaluation / Gate（第 31 节） | 谁来喊停 | 审稿分 P0–P3；一条 P0 是"把两家公司的事写成了同一个月" |
| 闭环 / 反馈（第 32 节） | 同一个坑怎么不摔第二次 | 一次复盘里的 8 条建议，回灌成 10 条技能条目 |
这张表不是按"重要度"排的，是按"疼"排的——先出血的先补。
但零件清单不等于系统。你把整车厂的零件都买齐，也不会因此拥有一辆车：零件只回答"它是什么"，系统回答"它们怎么互相认得"。
图 A-33-1（待出）：全书零件总图 —— 基座模型 → Small Model → Model Pool → Router → Context → Knowledge/Memory → Agent → Harness/State → Evaluation/Gate → 闭环/反馈 → AI System
二、一个 AI System 长什么样：三层治理 + 九条业务线¶
我这套系统，全部家当数下来是三层。
最上面一层是我，真人。管方向，管不可逆的事（钱、合规、架构的最终签字），另外直管两件不上会的事：生活和学习。
中间一层是一个总经理 agent。主持每天早晨一次的短会、跨线挑出当天最要紧的三件事、把活派下去、再把结果收回来。
最下面一层是九条业务线。它们各自的职责和边界，我在 8 月 1 日定过一次，九条线的骨架此后没动过：
| 业务线 | 一句话职责 | 边界（它不做什么） |
|---|---|---|
| 内容生产 | 内容制作 + 多平台分发 | 不研究前沿、不产模型、不做归档 |
| 软件开发 | 软件产品 + 工程基建（基建服务全公司） | 自产自卖；碰基建但不碰钱、不碰合规 |
| 研究中心 | 前沿研究（agent / 模型）+ 组织效率研究 | 只研究不生产；出建议，执行归别人 |
| 模型基建 | 模型生产的基建，所有模型从这里出 | 产模型但不研究前沿；不直接变现 |
| 技能基建 | 技能的维护与升级（版本、评测闭环、经验回灌的工程实施） | 只做工程实施；优化点由别处策展进来 |
| 量化投资 | 量化投资，未来的赚钱主力（当前是研究态） | 实盘条件达成，才转成赚钱主力 |
| 知识管理 | 信息采集 + 每日沉淀 + 策展路由 + 组织记忆 | 自己不生产 |
| 财务部 | 现金流追踪 + 记账 + 支出审查 + 每日报数 | 不碰业务决策；大额支出由我签字 |
| 法务部 | 法律风险评估 + 开源合规 + 隐私/协议 + 知识产权 | 事件触发，不常态占带宽；重大合规由我签字 |
为什么要拆成九条，而不是三条或者三十条？规矩只有一句：一件事一个 owner，不重叠、也不留真空。 每条线只有一句话的职责，外加一条"它不做什么"。那条边界比职责重要——因为一个系统的失败，通常不是某条线干得不好，是两条线都以为对方会管。
生活和学习不在这九条里。它们不进早晨那次会，各报各的简报：一个周频（菜单、行程），一个日频（复习、倒计时）。节奏不同的两件事，硬塞进同一个会，只会让快的等慢的。
图 A-33-2（待出）：三层治理与九条业务线（我 → 总经理 agent → 九条线；生活域与学习域直管、不进早会）
三、系统跑起来靠什么：每天只准三件事¶
有组织结构不等于系统会转。真正让它每天动起来的那条机制，土得掉渣：
每天最多三件事。
不是"今天要做的有很多，我们拣三件最要紧的"——是硬性三件，超过三件就不许再立。中间那层每天早上按线呈报：每一条线一节，报昨日、今日、阻塞，不合并、不汇总。合起来就是给我跨线挑三件用的。
规则是这样的：
- 每条必须带一个 owner，和一个可验收的完成信号——"文件已经落盘""链接已经登记""数字写到某个值"。写"推进中""已安排"的一律打回；
- 第二天早晨开会的第一件事，是逐项对账昨天那三件；
- 没闭环的必须说明原因并升级，不许静默顺延；
- 任何一项阻塞超过两天，自动升级。
这条机制是补出来的，不是设计出来的。补它的原因是一次难看的对账：某一天定下的三件事，9 天后三项全部没有闭环——而且没人回头问过。那 9 天里，全仓的提交稀稀拉拉——其中 6 天一次提交都没有。
于是就有了那条规矩，生效第一天对账的结果是：三件里 2.5 件闭环（第一件三个信号完成了两个），唯一没闭环的那一件，卡在一个只有我能点的人工节点上。
一个系统最贵的不是算力，是"定了的事没人回头看"。 三件事比三十件事难，因为三件事意味着你必须真的记着它们。
四、零件的真实规模¶
说了这么多机制，看看这套东西到底堆了多大：
| 零件 | 规模 |
|---|---|
| agent 角色定义 | 49 个 |
| 技能包 | 近 20 个（其中 16 个带安装脚本） |
| 装到内容线在用的技能 | 58 条 |
| 工程目录下的项目 | 10 个 |
| 跨线交接件 | 20 份 |
| 浏览器版产品 | v0.5.0，测试套件 277 条断言 |
| 桌面版产品 | 原生窗口，仅 Apple Silicon |
这些数字我一个都不打算往上抹光。49 个定义不等于 49 个人在干活；58 条技能也不等于 58 条都在被调用。定义是库存，不是产能。 前面每一节我都把这条说清楚了：工作流引擎从未真跑过，验证门的分数从未真实出现过，三层记忆的最上面一层是空的。
一个诚实的系统盘点，第一件事就是分清"定义了多少"和"跑起来了多少"——这两者之间的差距，才是真正的地图。
五、真接线在哪¶
这一堆零件里，有一处是真的接到了产品上的。不是"设计上应该接"，是结构上共用同一份源。
那 49 个角色定义，放在同一个地方。浏览器版产品的角色列表，是从这同一批定义里动态读出来的——产品说明与版本记录里写得很直白：角色从定义文件动态加载，不用改前端；文件名就是调用地址。桌面版那个调度台，输入一个 @ 符号弹出的角色清单，同样是从这批定义文件里读出来的。
也就是说：同一份定义，被两处消费。一处把它当"这家公司怎么分工"，另一处把它当"这个产品能召唤谁"。
这就是这一整本书里，唯一一处同一份定义被两处消费的地方。它意味着什么，我尽量说小一点：
我能确认的只是一个结构事实——它们指向同一个源。 我没有验证过"改一个定义、产品立刻跟着变"这种动态联动；那需要端到端的贯通证据，而我没有。结构上共用一份源，和运行时真的联动起来，是两件事。
但即使只说到这里，它也已经是我今年看到的最像"系统"的一件事：
一个零件最值钱的时刻，不是它被写出来，是它同时被两件事需要。
图 A-33-3（待出）：同一份角色定义被两处消费（一处当组织分工图，一处当产品的运行时数据源）
六、收口：从一个 Token，到一个 AI System¶
序章里我写过一句：我没有"接"上一个模型，我被逼着造了一个系统。
现在这本书写完了，可以给那句话补上后半句：
所谓系统，就是那些零件终于互相认得。
从一个 token 开始——那是模型唯一看得懂的东西，也是我和它之间唯一的通货。为了让这个 token 被算得便宜、算得稳、算得不跑偏，我往上补了 Small Model、补了池子、补了路由；为了让它在开口之前知道该读哪些东西，我补了上下文和记忆；为了让一次预测变成一次交付，我补了 agent 和协作；为了让它崩了还能接着跑、跑错还有人喊停，我补了 Harness 和闸门；最后为了让同一个坑不摔第二次，我补了一条回灌的路。
每一个零件，单看都平平无奇——一个配置清单、一张角色卡、一条每天的会。
拼在一起，它第一次有了一张完整的图。序章那句结论，到这一节可以原样放下：
零件我早就在补了，只是今年它才第一次被整张图认领。
这张图现在长这样：从一个 Token，到一个 AI System。
数据与出处¶
- 九条业务线的职责与边界、三层治理、生活域与学习域直管：2026-08-01 一份公司架构与职责分工基线（组织治理决策，当前权威参照）
- 每日节奏与 Top3 纪律（owner + 可验收完成信号、次日对账、不得静默顺延、阻塞超两天升级）：一份早会记录模板 + 12 份早会记录
- 三项全部未闭环的反例与"9 天里 6 天零提交"：2026-09-10 一份早会记录的连续性对账节；生效首日对账结果见另一份对账清单
- 零件清单与各自的数字：本书第 1 至 32 节正文
- 浏览器版产品规模（v0.5.0 / 277 条断言 / 角色动态加载、文件名即调用地址）：该产品说明与版本记录
- 桌面版产品（原生窗口 / 仅 Apple Silicon / 角色清单与状态徽章）：该产品说明
- 角色定义、技能包与跨线交接件的规模：一批角色定义文件、一批技能包与跨线交接文档