Bttr 五层循环
一颗大脑在中间，人坐在边缘。Bttr 在 Burn Tokens, Not Headcount 中提出的"循环视角" 把传统组织合法性来源拆穿 —— 层级是低带宽时代的应对机制，AI 让它过时。 下面是五层 + 一个中心的最小工程定义。
1.0立论 · 公司不是组织架构图
Bttr 这篇文章的开篇就把传统组织形式的合法性来源拆穿了：公司今天看起来像罗马军团（Roman legion）那样的层级结构，并不是因为这种形态最优，而是因为人类在低带宽人际沟通时代不得不发明的"应对机制"（coping mechanism）。它有用，是因为信息传递贵；而 AI 让信息传递的成本骤降到接近零，于是过去那个"必须要中层来协调"的前提消失了。
Bttr 给出的替代叙述很激进，但很干净：
这句话里有三个词值得拆开看：
- loop（循环）：公司里发生的每一件事 —— 接到客户工单、研发新产品、谈一笔合同、做一份招股书研报 —— 都不是一次性的"动作"，而是一组被反复执行的"流程"。流程意味着：你能观察它、能优化它、能让它下次跑得更好。
- recursive（递归）：循环的输出会变成下一次循环的输入。今天解决的一个 bug、做的一份模板、回的一封邮件，都会沉淀为下一次循环可以站在上面的"地基"。
- self-improving（自我改进）：递归的循环如果只是机械重复，那只是在原地打转；只有循环本身能被修改，"做事的方式"会因为做事的过程而变得更好，组织才会变聪明。
把"公司"这个名词换成"循环"这个动词，就解锁了一种新的看待组织的方式 —— 你不再问"我们应该有几个部门、多少层级"，你开始问"我们有几个核心循环、每个循环的五层都搭好了吗、它每跑一轮变得更聪明了吗"。
接下来的五层（再加上一个环绕中心），就是 Bttr 给"一个能自我改进的循环"下的最小工程定义。
Sensor 感知层
Policy 策略层
Tool 工具层
Quality Gate 质量闸门
Learning 学习机制
公司语境 · 大脑在中间
1.1第一层 · Sensor Layer（感知层）
1.2第二层 · Policy Layer（策略层）
- agent 可以自己改一段措辞吗？可以。
- agent 可以自己往招股书里补一段判断吗？可以，但要标注是 AI 推断。
- agent 可以自己把一个数字从财报里改掉吗？不可以，必须升级。
- agent 可以自己给客户回复退款邮件吗？低于 ¥500 可以，超过要升级。
1.3第三层 · Tool Layer（工具层）
1.4第四层 · Quality Gate（质量闸门）
1.5第五层 · Learning Mechanism（学习机制）
1.6中心 · Company Context（公司语境）
The company is a brain in the middle. Humans sit at the edge. 可读性，是一切的解锁开关。公司是中间一颗大脑，人坐在边缘。
后一句是整篇文章里最颠覆传统组织观的一句。传统的组织观是"人在中间，公司架构服务于人的协作"；AI Native 的组织观是反过来的 —— 公司大脑在中间承载所有的循环和知识，人坐在边缘，做新情境下的判断、伦理、谈判、设计品味、创始人时刻。中间那颗大脑越完整、越可读，边缘那个人越自由。
- Sensor 收来的信号要写进 Context；
- Policy 的规则本身存在 Context 里；
- Tool 要根据 Context 选用；
- Quality Gate 要参考 Context 来判断"这个产出像不像我们公司的"；
- Learning Mechanism 学到的新东西要回流到 Context。
1.7五层 + 中心 · 合在一起看一次循环
把上面六个组件合在一起，一次循环大致长这样：
每一次循环跑完，都会发生下面几件事：
- Sensor 收到了新信号 → 写进 Context；
- Policy 根据 Context 决定 agent 可以自己做、还是要升级；
- Tool 在确定性 API 上动手做；
- Quality Gate 把住门，安全的放出去，可疑的留下来；
- Learning 把"留下来的可疑"诊断成补丁，下一次同类问题循环就更聪明。
If you are small enough, you have no excuse. 如果你今天才开始建你的公司，你会以这种形态开始吗？如果你足够小，你没有借口。
这是 Bttr 这篇文章的钉子句。它没有让你立刻把公司翻新一遍，但它逼你回答一个问题：你今天做的每一件重复的事，能不能用这五层加一个中心的形态来重描？如果可以，就把它先描一下，再决定要不要改造。
指令驱动 Skill 进化引擎 · 四步动作
MVP 设计塌缩到只剩一种修正通道：人用一句自然语言指令让 agent 改。 指令本身就是最高质量、无损的训练信号 —— 哪里不对、该怎么改、为什么，全在一句话里。 下面是这套引擎的四个动作，全部引用《MVP 设计方案》原文。
2.0一句话方案
MVP 文档开篇直接给出立场：
为什么只保留"指令驱动"这一种修正通道，而不要"直接改产出"那种？文档解释得很硬：
底层有一个很简单的纪律要求：改东西必须"说出来"，不能埋头自己改。这恰好和 Bttr 关于 Company Context 的那句 "If it was not recorded, it did not happen to the intelligence" 完全咬合 —— 没说出来的判断，对 skill 而言就是没有发生过。
2.1动作 ① · 记录指令
log_instruction() 写库。文档给的伪代码：2.2动作 ② · 入库
instructions 表。MVP 阶段就这一张主表，9 个字段：| 字段 | 类型 | 说明 |
|---|---|---|
| id | INTEGER PK | 事件唯一 ID |
| ts | TIMESTAMP | 发生时间 |
| task_type | TEXT | 任务类型，如 prospectus_research |
| skill_id / skill_version | TEXT | 本次用的 skill 及版本 |
| target_section | TEXT | 指令针对的章节，如"承付义务分析" |
| instruction | TEXT | 【核心】人说的原话，一字不改。这就是一手的 why |
| issue_category | TEXT | 问题归类（可选，反思器可自动打） |
| agent_output_before | TEXT | 被指令针对的那段 agent 原产出（给反思器上下文） |
| promoted_to_skill | BOOLEAN | 是否已被进化进 skill（防重复消费） |
文档强调的"砍掉了哪些字段"很关键：
✗ revised_output —— MVP 不必存改后稿，指令已含意图
✗ reason_source / severity / embedding —— 归因相关，全部不需要
一张表从 13 个字段瘦到 9 个，且没有一个需要「推断」。
为什么强调"没有一个字段需要推断"？因为推断会引入噪声 —— 一旦你让系统去猜"分析师为什么改"，就会有猜错的时候，错误一旦进库就污染后面的反思器。指令本身就是 why，无需推断，是这套设计最干净的地方。
配套表 skill_versions 让 skill 可回滚：每次进化留痕，新版必须 ≥ 基线分才能上线，否则丢弃。这是"不退步"的硬约束，MVP 也不能省。
2.3动作 ③ · 反思器提炼
- 按量：某 task_type 下未消费的指令攒够 N 条（建议 N=5–8）
- 按期：每周固定跑一次
反思器 prompt（文档原文，可直接用）：
注意"反复出现 ≥2 次"和"忽略一次性的特例"两条 —— 这是反思器的"信号去噪规则"。一次性的指令可能是分析师当下情境下的特殊需求，硬塞进 skill 反而会让所有未来任务都被它绑架；只有反复出现的模式，才说明这是一个普遍判断，值得变成 skill 的一部分。
2.4动作 ④ · 验证后进化
只升不降。新版得分 ≥ 基线才进入候选；否则丢弃（但保留记录，失败也是数据）。
人工上线。通过验证的候选，由你一键确认上线。skill 变更是高风险动作，人在闭环。
这两道闸特别关键，因为自我改写本身有退步风险。文档直接点了一句业界铁律：
也就是说，让一个系统改自己是危险的 —— 除非你有一把"客观尺子"在那里量它改完之后是不是真的变好了。留出集就是那把尺子。
2.5四个动作 · 全景图
组织级飞轮 · 从一句话到组织智能
把前两章合并起来看，会发现一件让人愉悦的事 —— 指令驱动 Skill 进化引擎不是"五层循环"之外的另一个东西，它就是五层循环在投研调研业务上的实例化。 每一个动作，都对应着 Bttr 五层中的一层。
3.1五层映射 · 工程上是同一件事的不同切片
| Bttr 五层（+ 中心） | Skill 进化引擎里的对应物 | 在 SpaceX 案例里具体表现 |
|---|---|---|
| SENSOR感知层 | 动作 ① 记录指令 | 分析师那句"承付义务太浅"被 log_instruction() 接住 |
| POLICY策略层 | "什么算修改指令"的判断规则 + skill 谁能改的权限 | 只记针对已有产出的修改指令；skill 改动必须经反思器 + 人工 |
| TOOL工具层 | log_instruction()、SQLite 写入、反思器 prompt、留出集打分 |
一组确定性 API，agent 不靠魔法做事 |
| GATE质量闸门 | 留出集 + LLM-as-judge + 人工一键确认 | v3→v4 候选打分 0.78→0.85；分析师拍板上线 |
| LEARN学习机制 | 动作 ③ 反思器 + 动作 ④ 进化 | 一周内 6 条同类指令被归纳为"大额数字必拆结构"规则 |
| CTX公司语境 | instructions 表 + skill_versions 表 + skill 内容本身 |
分析师说过的所有判断，永久可读、可追溯、可回滚 |
这张表的价值不在于映射本身，而在于它告诉你："做一个能让 skill 进化的系统"和"做一个 AI Native 组织"，在工程上是同一件事的不同切片。
3.2飞轮 · 一句话到组织级智能
这是两者咬合后真正的核心 —— 一个组织级的飞轮：
注意箭头不是"开始 → 结束"，而是闭环。每跑完一圈，下一圈的起点都更高 —— 因为：
- skill 比上一版多了一条规则。 v4 比 v3 知道得更多。
- 分析师的注意力被释放。 上一轮被改的那一段，下一轮不用再改了，分析师可以把同样的注意力投在更深的判断上。
这就是 Bttr 文章里那句"slope vs level"的具体形态 —— 水平上每一次循环都在做事，斜率上每一次循环都在变聪明。公司的真正复利不来自任何一次循环本身，而来自循环的斜率。
3.3为什么这件事值得投入
回到一开始的灵魂拷问 —— 为什么我应该把自己的工作流改造成这个形态？三句话：
instructions 表的修正，都是 skill 在未来无数次同类任务中替你重复执行的"判断模板"。一句话被存一次，循环跑一万次，这一句话就替你做了一万次决定。这是非线性的杠杆。
而你，坐在循环的边缘，做循环做不了的事 —— 新情境下的判断、和客户的谈判、对一份报告的品味判断、深夜里关于公司方向的犹豫。
你的工作流，下一步该把哪一段说出来？
SpaceX 招股书调研 · 一次完整循环走读
用 SpaceX S-1 调研当作贯穿案例，把"指令驱动 Skill 进化引擎"完整跑一遍：
第一轮用 skill v3，分析师下达一句修改指令；
一周后反思器从 6 条同类指令归纳出新规则；
第二轮用 skill v4，agent 第一次产出就达到了上一轮的最终质量。
ai_brain/PROJECTS/spacex_s1/（提交日 2026-05-20，财务截至 2026-03-31）。
文中"agent 行为""指令""diff"用于呈现完整工作流走查，帮助读者理解协作链路。
任务：基于 SpaceX 提交的 Form S-1 招股书，完成投资判断研究报告。
承担循环：投研调研循环（task_type = prospectus_research）
当前 skill 版本：prospectus_skill v3（包含 6 条"拷问清单"规则）
skill v3 的"拷问清单"长这样（节选）：
agent 在分析师的命令下，针对招股书 MD&A 章节中的 Material Cash Commitments（重大现金承付义务）小节，给出了如下产出。
以下产出严格基于 S-1 原文（spacex_s1_clean.txt，"Material Cash Commitments"段落），但只保留了 v3 拷问清单能驱动 agent 做的处理。
▼ v3 产出片段 · 关于 SpaceX 重大现金承付义务的分析
- EchoStar 频谱许可收购：根据 2025-09-07 签订、2025-11-05 修订的 Spectrum License Purchase Agreement，SpaceX 将以约 196 亿美元的总对价收购 EchoStar 持有的 65 MHz 美国频谱及若干全球 MSS 频谱许可，已于 2026-05-12 获得 FCC 批准，预计 2027-11-30 前后完成交割。
- 未偿债务：截至 2026-03-31，公司及其子公司合计未偿本金 291.32 亿美元，最早一笔本金到期日为 2027-08-28（如不延期）。
- 最低租赁付款：截至 2026-03-31，最低租赁付款合计 58.23 亿美元，其中本财年内到期 10.26 亿美元。
- 多年期云算力容量承诺：S-1 风险因子披露公司对第三方云算力提供商有"不可撤销的多年期容量承付义务"，需按合同付款，与实际使用量无关。
- 零部件与原材料采购：公司业务中常态采购协议大多无长期约束性订单，未来采购可能形成额外重大现金承付义务。
▼ 分析师看完 v3 产出之后的反应
分析师扫了一眼，皱起眉头 —— 这份产出所有信息都是真的、所有数字都对，但它没用。它读起来像一份"我把 S-1 的 commitments 段落翻译过来了"的总结，而不是一份"我帮你想清楚 SpaceX 在未来现金流上有多大压力"的判断。
具体哪里不够？分析师能立刻指出来：
- 没有期限分布。196 亿、291.32 亿、58.23 亿这些数字砸在脸上，但它们具体什么时候要现金出去？近 12 个月要付多少？2027 年要付多少？2028 年以后呢？没有节奏感的总额是骗人的 —— 你不知道公司明年要不要再融一笔。
- 没有结构拆分。EchoStar 的 196 亿里，111 亿是用 261.8 百万股 A 类普通股付的（每股固定 $42.40），最高 85 亿才是现金（用来代付 EchoStar 的债）。"196 亿的 commitment"和"85 亿的现金 commitment + 111 亿的股本稀释"完全是两件事。
- 没有近两年占比。2026 财年内最低租赁付款 10.26 亿、2027-08-28 才有第一笔债务本金到期、EchoStar 现金支付预计 2027-11-30 才发生 —— 这意味着未来 18 个月内 SpaceX 在大额承付义务上的现金压力其实不算大。这条结论对融资节奏判断很关键，v3 的产出根本没碰到。
- 没有对现金流的含义判断。一份投研报告的最后一公里是"那这又怎样（so what）"。v3 给了"是什么（what is it）"，没给"那这又怎样"。
分析师没有亲自动手改产出 —— 这是 MVP 方案的纪律：改东西必须"说出来"。她在和 agent 的对话框里直接说了下面这句话（这就是 MVP 第 5 节里的那条原话）：
agent 接到指令，做两件事：
- 自动调用
log_instruction()把这条指令写进instructions表（动作 ①②）； - 在本次对话里执行修改，按指令重写承付义务那一段。
注意：分析师没有亲自改任何文字，她只是把判断说出来。
下面是真实写入数据库的字段（按 MVP 方案 §2.1 表结构）：
几个要点：
instruction字段一字不改保留分析师的原话 —— 这是一手 why，不需要 agent 二次推断。issue_category留空 —— MVP 阶段允许反思器在归纳时再补这一栏。agent_output_before存了 v3 的原产出，方便反思器看到"被指令针对的那段长什么样"。promoted_to_skill = false—— 防止下一轮反思器重复消费同一条。
这一周里，分析师在做 SpaceX 调研以及另外两份招股书时，又陆陆续续下达了 5 条性质相似的指令。instructions 表中的相关记录如下（精简版）：
▼ 6 条同类指令
到 05-25 周日晚上，自动 cron 触发反思器（按文档 §4.1：每周固定跑一次，且 task_type = prospectus_research 下未消费指令已超过 N=5 条）。
▼ 反思器读完 6 条指令后的归纳（输出 JSON 节选）
候选补丁不直接上线，要先过留出集（MVP §4.3）。
留出集：分析师此前已经修改到满意的 3 篇黄金终稿（包含承付义务、研发费、CapEx 三个章节，分别来自 SpaceX、OpenAI 内部参考稿、Stripe 内部参考稿）。
LLM-as-judge 打分维度：完整性（是否覆盖期限分布）、结构性（是否拆出构成）、判断性（是否给出 so-what）。
结果：
| 留出集稿件 | skill v3 得分 | skill v4 候选得分 |
|---|---|---|
| SpaceX · 承付义务终稿 | 0.72 | 0.88 |
| OpenAI · 研发费终稿 | 0.81 | 0.86 |
| Stripe · CapEx 终稿 | 0.79 | 0.82 |
| 平均 | 0.78 | 0.85 |
判定：v4 候选得分 0.85 ≥ 基线 0.78，进入待上线候选。
人工确认：分析师 2026-05-26 上午看了 candidate diff，一键确认上线 v4。
下面是 skill 文件的真实 diff（"拷问清单"章节）：
▼ skill_versions 表新增一条
promoted_to_skill = true，避免下次重复消费。
2026-05-27，分析师在做另一份发射服务公司招股书调研时，让 agent 重跑了一遍 SpaceX 的承付义务段。 注意：这次分析师什么都没说，agent 只是按 v4 的规则去写。
下面是 v4 第一次产出（"第一次"是指：分析师还没下任何修改指令）：
| 类别 | 总额 | 现金部分 | 非现金部分 | 性质 |
|---|---|---|---|---|
| EchoStar 频谱收购 | 196 亿 | 最高 85 亿（代付 EchoStar 债务，不足现金补） | 111 亿（261.8M 股 A 类，固定 $42.40/股） | 战略性资产收购 |
| 总未偿债务（本金） | 291.32 亿 | 全部现金还本付息（含可变利率） | — | 经营性 + 收购融资 |
| 最低租赁付款 | 58.23 亿 | 全部现金 | — | 不动产、设备 |
| 第三方云算力多年期容量 | 未披露 | 全部现金，不可撤销，按合同付款 | — | 经营性，不可撤销 |
| 部件原材料采购 | 大多无长期约束 | 取决于实际下单 | — | 弹性较强 |
| 期限 | 关键现金流出 | 估算金额 |
|---|---|---|
| 未来 12 个月（至 2027-03-31） | 租赁付款（本财年剩余）+ 利息支出 + 云算力月度对价 | 约 10–15 亿 现金（其中租赁本财年内 10.26 亿） |
| 未来 12-24 个月（至 2028-03-31） | 2027-08-28 起首批债务本金到期（具体金额需查 Note 10）+ EchoStar 频谱现金支付（预计 2027-11-30）+ 持续租赁与云算力 | 现金集中点：85 亿 + 数十亿债务本金 |
| 24 个月以上 | 剩余债务本金、剩余租赁尾段 | 大头 |
2. 真正的现金压力点集中在 2027 Q3-Q4：85 亿 EchoStar 现金 + 首批债务本金 + 持续运营性现金流出，将在同一个 6 个月内集中。届时若 IPO 资金未到位、或经营现金流不足，需要外部融资。这是判断 IPO 时点合理性的关键 —— SpaceX 的 IPO 时点窗口大概率被 2027 Q3 现金需求倒逼。
3. 111 亿股本稀释的隐性成本：以 $42.40 锁价对 EchoStar 发行 261.8 百万股 A 类普通股 —— 如果 IPO 后股价显著高于 $42.40，相当于以折价对 EchoStar 让利；如果显著低于，则说明高估了自己。这是估值锚之一。
4. 云算力承诺值得单列警惕：S-1 在风险因子中专门提示"non-cancellable, multi-year capacity commitments to cloud compute providers, requiring payment regardless of usage"。具体数额未公开，但考虑到 SpaceX 同时在收购 xAI、跑 Starlink 网络运营、加上自建数据中心，这部分若规模较大可能在未来 24 个月成为隐性现金黑洞。建议追问管理层。
分析师判断：这次没有再下任何修改指令。v4 第一次产出已经包含上一轮她说过的所有判断 —— 那一句"承付义务太浅，拆出期限分布"，永久变成了 skill 的拷问清单第 7 条。
- EchoStar 频谱许可收购：约 196 亿美元总对价，预计 2027-11-30 前后交割。
- 未偿债务：合计未偿本金 291.32 亿美元，最早一笔本金到期日 2027-08-28。
- 最低租赁付款：合计 58.23 亿美元，本财年内到期 10.26 亿美元。
- 第三方云算力多年期容量承诺：S-1 风险因子披露公司有"不可撤销的多年期容量承付义务"。
- 零部件与原材料采购：常态采购协议大多无长期约束订单。
分析师判断：所有信息都对、所有数字都真，但没用。读起来像把 S-1 翻译了一遍，没有期限分布、没有结构拆分、没有近两年占比、没有"那这又怎样"。
v3 vs v4 · 第一次产出的差距
| 维度 | v3 第一次 | v4 第一次 |
|---|---|---|
| 现金 vs 股本拆分 | 没有 | 85 亿现金 + 111 亿股本被显式分开 |
| 期限分布 | 没有（只列了几个总额） | 按 0-12 / 12-24 / 24+ 三档 |
| 近两年占比 | 没有 | 明确指出未来 18 个月并不构成压力高峰 |
| 对现金流含义 | 一句"规模可观" | 4 条具体判断（IPO 时点 / 稀释 / 黑洞 / 追问点） |
| 第三方云算力承诺 | 一笔带过 | 单列警惕，标注未披露数额、给出建议追问 |
| 分析师本轮指令数 | 6 条 instructions | 0 条（不需要再说） |
注意一个细节：分析师在第二轮里没有下任何修改指令。她也不需要。v4 第一次写出来的，已经覆盖了她上一轮才"说出来"的所有判断。她原本要花 30 分钟写下来的那句"承付义务太浅，拆出期限分布……"，永远地变成了 skill v4 拷问清单的第 7 条规则，对所有未来同类任务永久生效。
这正是 Burn Tokens, Not Headcount 那句 "By morning the codebase is smarter" 在投研场景的具体形态：
- 被改的不是代码，是判断；
- 被记住的不是 diff，是分析师亲口说的"为什么"；
- 复利不来自这一次循环本身，而来自下一次同类循环开始时，agent 已经知道得更多。
附录 A · 本案例引用的 S-1 原文锚点
为了让这份案例可被同事核查，下面列出本案例所有数字的 S-1 原文出处（均来自 ai_brain/PROJECTS/spacex_s1/spacex_s1_clean.txt）：
| 数字 | S-1 原文锚点 |
|---|---|
| EchoStar 196 亿、111 亿股本、85 亿现金、261.8 百万股、$42.40 | "The total consideration ... is approximately $19.6 billion, consisting of (i) approximately $11.1 billion in equity ... approximately 261.8 million shares ... at a fixed value of $42.40 per share, and (ii) up to $8.5 billion related to the payoff of designated EchoStar debt ..." |
| 291.32 亿未偿债务、2027-08-28 首批本金到期 | "As of March 31, 2026, we and our subsidiaries had outstanding $29,132 million in aggregate principal amount of indebtedness and no debt principal payments are due until August 28, 2027 if we choose not to extend." |
| 58.23 亿最低租赁付款、本财年 10.26 亿 | "As of March 31, 2026, our total minimum lease payments was $5,823 million, of which $1,026 million is due within this fiscal year." |
| 不可撤销多年期云算力容量承诺 | Risk Factors 段，"We have non-cancellable, multi-year capacity commitments to cloud compute providers, requiring payment regardless of usage." |
| FCC 批准 EchoStar 交易 2026-05-12、预计交割 2027-11-30 | "The Spectrum Transaction was approved by the FCC on May 12, 2026 and is expected to close on or about November 30, 2027 ..." |
附录 B · 本案例对应 MVP 方案的章节
| 阶段 | 对应 MVP 方案章节 |
|---|---|
| 阶段 1 v3 产出 | §5 贯穿实例 · 第一行 |
| 阶段 2 修改指令原话 | §5 贯穿实例 · 第二行（保留原话） |
| 阶段 3 表结构 | §2.1 instructions 表 |
| 阶段 4 反思器归纳 | §4.2 反思器 prompt |
| 阶段 5 留出集 | §4.3 验证闸 |
| 阶段 6 skill diff | §5.1 skill v3 → v4 |
| 阶段 7 v4 第一次产出 | §5 蒸馏发生了 |