PART 01 · 深度解读

Bttr 五层循环

一颗大脑在中间,人坐在边缘。底层思想来自 YC · Diana The Playbook for Building an AI Native Company,Bttr 在 Burn Tokens, Not Headcount 中把它框架化为五层切分 —— 层级是低带宽时代的应对机制,AI 让它过时。 下面是五层 + 一个中心的最小工程定义。

1.0立论 · 公司不是组织架构图

Bttr 这篇文章的开篇就把传统组织形式的合法性来源拆穿了:公司今天看起来像罗马军团(Roman legion)那样的层级结构,并不是因为这种形态最优,而是因为人类在低带宽人际沟通时代不得不发明的"应对机制"(coping mechanism)。它有用,是因为信息传递贵;而 AI 让信息传递的成本骤降到接近零,于是过去那个"必须要中层来协调"的前提消失了。

Bttr 给出的替代叙述很激进,但很干净:

A company is not an org chart. It is a set of recursive, self-improving loops. 公司不是一张组织架构图,它是一组递归的、自我改进的循环。

这句话里有三个词值得拆开看:

  • loop(循环):公司里发生的每一件事 —— 接到客户工单、研发新产品、谈一笔合同、做一份招股书研报 —— 都不是一次性的"动作",而是一组被反复执行的"流程"。流程意味着:你能观察它、能优化它、能让它下次跑得更好。
  • recursive(递归):循环的输出会变成下一次循环的输入。今天解决的一个 bug、做的一份模板、回的一封邮件,都会沉淀为下一次循环可以站在上面的"地基"。
  • self-improving(自我改进):递归的循环如果只是机械重复,那只是在原地打转;只有循环本身能被修改,"做事的方式"会因为做事的过程而变得更好,组织才会变聪明。

把"公司"这个名词换成"循环"这个动词,就解锁了一种新的看待组织的方式 —— 你不再问"我们应该有几个部门、多少层级",你开始问"我们有几个核心循环、每个循环的五层都搭好了吗、它每跑一轮变得更聪明了吗"。

接下来的五层(再加上一个环绕中心),就是 Bttr 给"一个能自我改进的循环"下的最小工程定义。

1.1第一层 · Sensor Layer(感知层)

"The loop only knows what it can sense."
循环只知道它能感知到的事物。
WHAT这一层是什么
循环的输入感官 —— 客户邮件、支持工单、代码 commit、产品遥测、内部 Slack 消息、销售电话录音、会议记录、监控告警。一切"外部世界发生了什么"的信号,都要先穿过感知层进入循环。
WHY解决什么问题
决定循环的"视野边界"。Bttr 把这一句话写得非常硬 —— 循环只能作用于它能感知到的事物。一件没有被传感器接住的事,对系统来说就是没有发生过。这听起来像废话,但它直接推翻了大量传统组织对"信息流"的设想:以前一件事被员工口头传达三层之后丢失,没人会觉得是个 bug;在循环视角下,这是感知层漏接的事故。
EG举例
YC 的做法被 Bttr 单独拎出来当典型 —— 2000 小时合伙人录音全都喂进系统,让 AI 在一个周末重生成 150 页用户手册,从此每月自动更新。这就是把"老合伙人脑子里的隐性知识"变成感知层的常规输入。再举一个更日常的:你和分析师的每一次微信对话、每一条修改意见,如果没有被 log 到一个 agent 看得到的地方,那这条信息就根本没有"发生过"。SpaceX 案例里这一层表现为把 DRI 给 agent 的每一条修改指令、每一次推翻判断都落到一个共享日志里,下一轮循环起手就能读到 —— 没记下的指令,对循环来说就等于没发生过。
META反思
Sensor 层最容易被低估,因为搭起来枯燥,写不出炫的 demo。但循环的天花板就是它的感知力。一个看不见自己客户在抱怨什么的循环,再聪明的策略层也救不回来。

1.2第二层 · Policy Layer(策略层)

"Rules about what the system is allowed to do without asking."
关于系统在不询问的情况下可以做什么的规则。
WHAT这一层是什么
定义"什么动作系统可以自己拍板、什么必须升级到人"的规则。它不是某个 if/else 块,而是一套护栏(guardrails)
WHY解决什么问题
自治与监督的分界。这一层让你回答下面这种问题:
  • agent 可以自己改一段措辞吗?可以。
  • agent 可以自己往招股书里补一段判断吗?可以,但要标注是 AI 推断。
  • agent 可以自己把一个数字从财报里改掉吗?不可以,必须升级。
  • agent 可以自己给客户回复退款邮件吗?低于 ¥500 可以,超过要升级。
策略层的精髓是默认值:它把"哪些事不需要每次问人"显式地写下来,于是循环跑起来才不会每一步都卡在审批上。同时它也把"哪些事必须问人"显式地写下来,于是循环跑起来不会闯祸。
EG举例
在 SpaceX 招股书研究循环里,我们的策略层会规定:agent 可以自己重组段落、可以自己加交叉引用、可以自己对比同业;但任何涉及"我对这家公司估值的最终判断",必须由分析师做出 —— 这是一个角色边界。Bttr 的金句是:"Senior people will increasingly act like fund partners. Outcome over output."(高级人才会越来越像基金合伙人,要的是结果不是产出。)策略层就是把这种角色边界落到代码里。
META反思
策略层是 prompt 之外的一道闸门。Bttr 一句话点破了它的位置: "The line between autonomy and oversight is set here, not at the prompt." 很多人把 agent 的"敢做什么、不敢做什么"写在 prompt 里,但 prompt 是软约束,模型可以被绕过;策略层是工程化的硬约束,挂在循环外侧,agent 根本到不了那一步。

1.3第三层 · Tool Layer(工具层)

"Deterministic APIs ... Boring infrastructure."
确定性 API ……无聊的基础设施。
WHAT这一层是什么
循环里所有"动手做事"的能力,被暴露成一组确定性 API —— 查数据库、读日历、发发票、抓网页、调财报接口、跑 SQL、改文件。注意"确定性"三个字:同样的输入要给出同样的输出,行为可预测、可测试、可审计。
WHY解决什么问题
把循环的"能力面"和"决策面"分开。决策面是 agent 自己用语言模型推理出来的,工具面则是死板的、机械的、可信的。循环依赖的不是"模型很聪明所以会做对",而是"模型再不聪明,调用 send_invoice() 也只能按既定逻辑发出一张合规发票"。
EG举例
YC 那个老司机案例里,第二个 agent 自动 review 第一个 agent 提交的 MR、合并、部署。这两个 agent 自己的脑子都不太可能保证次次靠谱,但部署这一步是死板的工具:通过 review 就部署,没通过就不部署。这就是工具层在干活。落到我们的项目,"读取 spacex_s1_clean.txt 中的某一段"应该是一个工具,"写入 instructions 表"应该是一个工具,"调反思器"应该是一个工具 —— 而不是 agent 用魔法做完。
META反思
Bttr 用的形容词是 "boring"。听起来贬义,其实是高度褒义 —— 工具层越无聊越好。无聊意味着确定性、意味着工程化、意味着调试方便。一个公司是不是 AI Native,看它的工具层有多厚就知道:薄的公司一切靠 agent 临场发挥;厚的公司 agent 只负责选用哪一个工具。

1.4第四层 · Quality Gate(质量闸门)

"Safety filters and human review for high-stakes actions."
安全过滤器和高风险动作的人工审核。
WHAT这一层是什么
所有从循环里被推出去的产出 —— 一段写给客户的回复、一份生成的报告、一行代码 patch、一笔退款 —— 在送达世界之前要经过的一道闸门。质量闸门由两部分组成:安全过滤器(自动)+ 高风险动作的人工审核
WHY解决什么问题
把"自治"和"监督"用看得见的方式落地。Policy 层说"哪些事可以自己做",是规则;Quality Gate 是这条规则的执行点 —— 闸门在这里立着,任何要出去的东西都要在这里被检查一道。
EG举例
SpaceX 案例里这一层表现为留出集打分 + LLM-as-judge + DRI 一键确认:3 篇 DRI 修到满意的黄金终稿做留出集,LLM-as-judge 在完整性 / 结构性 / 判断性三个维度打分,新版得分必须 ≥ 基线才进入候选,最后由 DRI 看 candidate diff 拍板上线。两道闸口逐级收紧,机器先过一道、人再拍板。
META反思
Quality Gate 的存在让"自治"变得可负担。没有闸门的自治,要么不敢放开(agent 永远只能写草稿)、要么放开就出事(agent 直接发了一封不该发的邮件)。有了闸门,才能放心让循环去跑、出错也只会出在闸门内侧。Bttr 的原句很硬: "The line between autonomy and oversight is set here, not at the prompt." 这句话出现在策略层和质量闸门之间反复回响 —— 它在提醒你:自治程度不是用嘴说"agent 可以放手做"决定的,是用闸门设在哪里决定的。

1.5第五层 · Learning Mechanism(学习机制)

"The system looks at where it failed, writes the fix, ships it. By morning it knows more than it did last night."
系统看着自己在哪里失败了,写出补丁,部署上线。第二天早晨,它比昨晚知道得更多。
WHAT这一层是什么
循环的"自检 + 自改 + 自部署"能力。失败被检测到 → 诊断写出来 → 补丁产生 → 通过质量闸门 → 上线。而且这件事在循环本身的运转中自然发生,不需要专门拉一个工程师来排期。
WHY解决什么问题
让系统结构性地变聪明,而不只是变快。Bttr 把这一层称作"多数公司缺的那一层"(the missing layer in most companies)。前四层很多公司都有 —— 数据采进来(Sensor)、规则写好(Policy)、API 暴露(Tool)、QA 流程(Gate)—— 但跑了一年之后还是去年那个公司,因为没有第五层。
EG举例
Bttr 给出的 YC 案例非常生动 —— 一次查询失败了,监控 agent 自动追问"为什么":是错的工具?是缺的 skills 文件?是过期索引?是错误视图?诊断出来后,agent 写补丁、提 MR;第二个 agent review、合并、部署。第二天早晨,整个 codebase 都比昨晚聪明了一点。 "Runs overnight. By morning the codebase is smarter." SpaceX 案例里这一层表现为"反思 → skill 补丁 → 下一轮自动加载":DRI 这周改了哪些 prompt、推翻了 agent 的哪些判断,全部沉淀成新的 skill 文件;下一次同类任务起手就是这周改过的版本。核心动作完全同构:失败 → 反思 → 修复 → 部署 → 下一轮起点更高。
META反思
学习机制是把循环从"工具集合"变成"有机体"的关键。没有这一层,所有前四层的努力都只是把"今天的能力"工程化了;有了这一层,循环才会让明天的能力比今天更强。这是斜率(slope)问题,不是水平(level)问题。

1.6中心 · Company Context(公司语境)

"If it was not recorded, it did not happen to the intelligence."
没有被记录的东西,对智能体而言就是没有发生过。
WHAT这一层是什么
环绕在五层循环中心的"公司大脑" —— 公司的历史、决策、客户、产品、流程、人员、教训、品味、行话、潜规则。所有让公司之所以成为这家公司的隐性知识,要被显式地、可读地放在一个地方,让循环里的每个 agent 都能读到。
WHY解决什么问题
解决"这个 agent 不像我们公司的人"。一个通用 LLM 知道一切又什么都不知道;它知道波音和 SpaceX 是怎么回事,但不知道你们公司为什么决定不做 X 业务、为什么和某个客户绝交、为什么对某种文风过敏、为什么承付义务那一段必须拆期限分布。这些东西如果不写下来,agent 就不可能学会。
EG举例
YC 那 2000 小时合伙人录音 → 150 页用户手册 → 每月自动更新,本质上就是把合伙人脑子里的"YC 是什么"做成 Company Context,让所有 agent 在做事前可读。
Legibility is the unlock.
The company is a brain in the middle. Humans sit at the edge. 可读性,是一切的解锁开关。公司是中间一颗大脑,人坐在边缘。

后一句是整篇文章里最颠覆传统组织观的一句。传统的组织观是"人在中间,公司架构服务于人的协作";AI Native 的组织观是反过来的 —— 公司大脑在中间承载所有的循环和知识,人坐在边缘,做新情境下的判断、伦理、谈判、设计品味、创始人时刻。中间那颗大脑越完整、越可读,边缘那个人越自由。

META反思
Company Context 不是一层、是一个中心,因为它跟所有五层都打交道:
  • Sensor 收来的信号要写进 Context;
  • Policy 的规则本身存在 Context 里;
  • Tool 要根据 Context 选用;
  • Quality Gate 要参考 Context 来判断"这个产出像不像我们公司的";
  • Learning Mechanism 学到的新东西要回流到 Context。
可以这么理解:五层是循环的骨骼,Company Context 是循环的血液 —— 每一次循环跑动,都把新东西写回血液,下一次循环又把血液带到每一层。

1.7五层 + 中心 · 合在一起看一次循环

把上面六个组件合在一起,一次循环大致长这样:

五层循环 · 大脑在中间 · 人坐在边缘
⑥ Company Context 公司语境 · 大脑 legibility is the unlock ① Sensor 感知层 外部信号 → 写入 ② Policy 策略层 自治 / 升级 边界 ③ Tool 工具层 确定性 API ④ Quality Gate 安全闸门 + 人审 ⑤ Learning 学习 诊断 → 补丁 外部世界 客户 / 邮件 / 工单 / 代码 感知 写入 读出 → 决策 允许 → 调用 产出 ✓ 安全 → 输出到世界 可疑 → 反思 补丁回灌 CENTER
Sensor 感知 Policy 策略 Tool 工具 Gate 闸门 Learning 学习 Context 中心

每一次循环跑完,都会发生下面几件事:

  1. Sensor 收到了新信号 → 写进 Context;
  2. Policy 根据 Context 决定 agent 可以自己做、还是要升级;
  3. Tool 在确定性 API 上动手做;
  4. Quality Gate 把住门,安全的放出去,可疑的留下来;
  5. Learning 把"留下来的可疑"诊断成补丁,下一次同类问题循环就更聪明。
If you were building your company today, would you start it in this shape?
If you are small enough, you have no excuse. 如果你今天才开始建你的公司,你会以这种形态开始吗?如果你足够小,你没有借口。

这是 Bttr 这篇文章的钉子句。它没有让你立刻把公司翻新一遍,但它逼你回答一个问题:你今天做的每一件重复的事,能不能用这五层加一个中心的形态来重描?如果可以,就把它先描一下,再决定要不要改造。

出处:底层思想源自 YC · Diana The Playbook for Building an AI Native Company;五层切分由 Bttr Burn Tokens, Not Headcount 框架化,本章节引文与映射沿用其口径。
Bttr 原文 → https://www.makebttr.com/insights/burn-tokens-not-headcount
PART 02 · 落地

组织级飞轮 · 从一次会议纪要到组织智能

五层循环不是抽象的概念框架,它在投研调研业务上有一套具体的咬合方式。 下面分五步走读:先看 Sensor 层"双入口"的扩展,再看 DRI 在 loop 中的三个具体落点,给出完整映射表,然后用一张飞轮把循环跑给你看,最后回答"为什么值得投入"。

2.1Sensor 双入口 · 任务从哪来 + 修正信号怎么进

第 1 章里 Sensor 层只是泛指"循环的输入感官"。落到 SpaceX 案例上,要追问一个更具体的问题:任务"做 SpaceX 调研"本身,是怎么进入循环的?如果这个信号没被任何传感器接住,那么 agent 跑出来的产出就回答不了"我是为谁、为什么时间点、按谁的判断口径在做这件事"——这是 Bttr 那句"没被记录的就是没发生过"的最大盲点。

所以 Sensor 层在投研调研循环里要有两个入口

①a SENSOR 管 · 启动

任务发起信号 · 这一圈为什么跑

信号源
投委会会议纪要 / 客户邮件 / Slack @ / IC memo 排期
落库
tasks 新增一行:task_id, source = meeting_minutes, assigned_dri, deadline, focus_points
"2026-05-20 投委会决议:S-1 提交后第二日启动 SpaceX 调研,DRI = 张三,T+5 出初稿,重点关注承付义务与频谱收购。"
①b SENSOR 管 · 进化

修正信号 · 下一圈起点更高

信号源
DRI 在对话框里下达的一句修改指令
落库
instructions 表(结构不变,已有)
"承付义务太浅,拆出期限分布,重点说近两年占比。"
会议纪要必须像修改指令一样一字不改地落库。它是这一轮循环的"为什么跑",修改指令是这一轮循环的"下一圈起点更高"——前者管启动,后者管进化,缺一不可。会议纪要进 Context 后,agent 在跑任务时能直接读到"这次为什么跑、IC 关注什么",避免它把所有招股书都按同一种通用口径写。

2.2DRI in the loop · 人不在中间,人在边缘的三个具体位置

文档此前用"分析师"这个词,把任务接收人、修改指令下达人、上线一键确认人三个职能压在了一起。要让"人坐在边缘"这件事可操作,就得用 DRI(Directly Responsible Individual)这个词,把人在循环里的三个动作显式拆开:

接 Sensor · 在会议上认领任务、被纪要点名为 DRI
落点 SENSOR + POLICY。DRI 是 Policy 层定义的"谁能拍板"。
SpaceX CASE 投委会指定张三为 SpaceX S-1 调研 DRI,T+5 出初稿。
下指令 · 看完 v3 产出,说出那句"承付义务太浅"
落点 SENSOR ①b。修正信号入口,一句话进 instructions 表。
SpaceX CASE 这一句触发未来的反思器归纳,下次同类任务起点更高。
守闸门 · 看完 v4 候选 diff,一键确认上线
落点 GATE。新版 ≥ 基线才进入候选;最终人工拍板。
SpaceX CASE 0.85 ≥ 0.78;DRI 2026-05-26 上午拍板 v4 上线。
DRI 不在循环中央"主导",DRI 坐在循环边缘的三个具体节点上——任务认领点、指令下达点、闸门确认点。其余所有动作(找数字、拆结构、跑反思器、过留出集)都在循环内部由 agent + tool + gate 完成。这正好对接 Bttr 的 "Humans sit at the edge"——但比"在边缘"更具操作化:DRI 在边缘的哪三个位置
Senior people will increasingly act like fund partners. Outcome over output. 高级人才会越来越像基金合伙人 —— 要的是结果,不是产出。

DRI 的工作不是把每一份调研都亲手改完,而是在这三个边缘位置上做循环做不了的事:在会议上做要不要做、谁来做的判断;在产出上把判断说出来;在 skill 上线前拍板放不放出去。

2.3五层映射表 · 升级版

Bttr 五层(+ 中心)SpaceX 案例里的具体落点
SENSOR感知层 投委会纪要点名张三为 DRI 进 tasks 表;张三那句"承付义务太浅"被 log_instruction() 接住 —— 任务入口和修正信号入口同时打开
POLICY策略层 DRI = 张三;agent 可重写段落、不可改估值结论;skill 上线必须 DRI 拍板 —— 自治边界由 policy 而非 prompt 决定
TOOL工具层 log_meeting() / log_instruction() / SQLite 写入 / 留出集打分 —— 一组确定性 API,agent 不靠魔法做事
GATE质量闸门 留出集 + LLM-as-judge + DRI 一键确认;v3→v4 候选打分 0.78→0.85;DRI 2026-05-26 拍板上线
LEARN学习机制 一周内 6 条同类指令被反思器归纳为"大额数字必拆结构"规则,写进 skill 补丁;下一轮起手就是改过的版本
CTX公司语境 任务来源(投委会纪要)、DRI 判断(每一句修改指令)、skill 版本轨迹全部永久可读、可追溯、可回滚

这张表的价值不在于映射本身,而在于它告诉你:SpaceX case 不是给映射表举的一个例子,它就是这张表本身 —— 一次完整的循环跑动。 五层不是抽象框架,是一组可以一格一格指认到代码、表、人的具体落点。

2.4飞轮 · 从一次会议纪要到组织级智能

这是两者咬合后真正的核心 —— 一个组织级的飞轮。注意它的起点不是"分析师拍脑袋开干",而是会议纪要点名 DRI

视图 点任意节点 · 右侧出现详情
组织级飞轮 · 8 节点闭环 · DRI 在 3 个边缘位置出场 · 斜率每跑一圈变陡
FLYWHEEL slope, not level 每跑一圈 · 下一圈起点更高 STAGE 0 · SENSOR ①a 投委会纪要 点名 DRI DRI ①接 Sensor STAGE 1 DRI 跑一次 SpaceX 调研 SENSOR ①b 一句修改 指令 DRI ②下指令 CONTEXT instructions 表多一行 LEARNING 反思器 周期提炼 GATE 留出集 + DRI 确认 DRI ③守闸门 CTX 写回 skill v4 上线 UP ↑ 下一次 起点更高
注意箭头不是"开始 → 结束",而是闭环。会议纪要触发循环,DRI 在 3 个边缘位置出场,其余动作由 agent + tool + gate 完成;每跑完一圈,下一圈的起点都更高。

注意几件事:

  • DRI 在循环里出现 3 次(认领任务、下指令、守闸门),其余动作全部由 agent + tool + gate 完成。
  • Sensor 有两个入口:会议纪要管"为什么跑这一圈",修改指令管"下一圈起点更高"。

每跑完一圈,下一圈的起点都更高 —— 因为:

  1. skill 比上一版多了一条规则。 v4 比 v3 知道得更多。
  2. DRI 的注意力被释放。 上一轮被改的那一段,下一轮不用再改了,DRI 可以把同样的注意力投在更深的判断上。

这就是 Bttr 文章里那句"slope vs level"的具体形态 —— 水平上每一次循环都在做事,斜率上每一次循环都在变聪明。公司的真正复利不来自任何一次循环本身,而来自循环的斜率。

2.5为什么这件事值得投入

回到一开始的灵魂拷问 —— 为什么我应该把自己的工作流改造成这个形态?三个理由,按重要性递增:

你嘴里那句"该这样改",今天用完,明天就消失了。

它能改掉这一次的产出,但下一次同类问题来的时候,你还得重说一遍。一年下来你说了几百遍同一个意思。这种"一次性使用"的判断,才是真正的浪费 —— 浪费的不是 token,是你 —— 一个本应做更高阶判断的人 —— 的时间。

你说的话只要被记住,就会以复利方式回报你。

每一句被存到 instructions 表的修正,都是 skill 在未来无数次同类任务中替你重复执行的"判断模板"。一句话被存一次,循环跑一万次,这一句话就替你做了一万次决定。这是非线性的杠杆。

五层循环 + 组织飞轮合起来,把你蒸馏成一个永远在岗的智能体。

Bttr 那句被反复引用的话很合用:"Senior people will increasingly act like fund partners. Outcome over output." 你不需要再亲手把每一份调研改完,你只需要让你说过的每一句话都被记住、被沉淀、被复用。剩下的让循环去跑。而你,坐在循环的边缘,做循环做不了的事 —— 新情境下的判断、和客户的谈判、对一份报告的品味判断、深夜里关于公司方向的犹豫。

The company is a brain in the middle. Humans sit at the edge. 公司是中间一颗大脑,人坐在边缘。

你的工作流,下一步该把哪一段 说出来

CASE STUDY · SPACEX S-1

SpaceX 招股书调研 · 一次完整循环走读

用 SpaceX S-1 调研当作贯穿案例,把五层循环 + 组织飞轮完整跑一遍:

STAGE 0 投委会纪要进入 Sensor ①a,DRI 被点名接住任务; 第一轮用 skill v3,DRI 下达一句修改指令(Sensor ①b); 一周后反思器从 6 条同类指令归纳出新规则; 第二轮用 skill v4,agent 第一次产出就达到了上一轮的最终质量。

数据来自 ai_brain/PROJECTS/spacex_s1/(提交日 2026-05-20,财务截至 2026-03-31)。 文中"agent 行为""指令""diff"用于呈现完整工作流走查,帮助读者理解协作链路。
STAGE 0 Sensor ①a 投委会纪要 · 点名 DRI · 任务进入循环DRI ① · 接 Sensor 2026-05-20 · S-1 提交当晚

这一段是循环的真正起点:任务不是凭空出现的。投委会的一段会议纪要,被 Sensor ①a 收下,落进 tasks 表,并显式点名一位 DRI。

投委会纪要 · 摘录
"SpaceX 已于 2026-05-20 向 SEC 提交 S-1。请张三牵头,下周三(05-26)前出一份投资判断研究报告。
重点关注:① 收入分部结构与同业利润率;② 客户集中度与关联交易;③ 承付义务(capex / 发射台租约 / 长期供货)对现金流的压制。"

▼ Sensor ①a 落库 · tasks 表新增一行

{ "task_id": 2104, "task_type": "prospectus_research", "source": "meeting_minutes", "source_ref": "ic_meeting_2026-05-20.md", "subject": "SpaceX S-1 投资判断研究报告", "assigned_dri": "张三", "deadline": "2026-05-26", "focus_points": [ "收入分部 × 同业利润率", "客户集中度 × 关联交易", "承付义务对现金流的压制" ], "skill_binding": "prospectus_skill@v3", "status": "open", "created_at": "2026-05-20T22:14:00+08:00" }
为什么这条记录重要:它把"会议口头分配的任务"变成了循环可识别的结构化输入——有 DRI、有 deadline、有 focus_points、绑定了当前 skill 版本。没有这一步,后面所有的指令、产出、反思都没有归宿
在五层循环里的位置:这是 Sensor ①a(任务起点入口)。后面 STAGE 3 DRI 下达的修改指令是 Sensor ①b(修正信号入口)——同一个 Sensor 层,两个入口,对应组织里两种不同的"信号源"。
STAGE 1 Policy DRI 接到任务、查 skill 版本 2026-05-21 · S-1 提交后第二天

任务:基于 SpaceX 提交的 Form S-1 招股书,完成投资判断研究报告。
承担循环:投研调研循环(task_type = prospectus_research
当前 skill 版本:prospectus_skill v3(包含 6 条"拷问清单"规则)

skill v3 的"拷问清单"长这样(节选):

1. 收入分部必须分开看,不要只看总数 2. 利润率必须和同业对比,不要孤立看 3. 客户集中度(Top 5 / Top 10)必须列出 4. 关联交易必须特别标注 5. 风险因子要重点提取"非常规"风险,跳过模板套话 6. 现金流和净利润背离时,必须给出解释
注意:v3 此时没有关于"承付义务怎么写"的规则。
STAGE 2 Tool 第一轮 · agent 用 v3 的产出 skill v3 第一次产出

agent 在 DRI 的命令下,针对招股书 MD&A 章节中的 Material Cash Commitments(重大现金承付义务)小节,给出了如下产出。

以下产出严格基于 S-1 原文(spacex_s1_clean.txt,"Material Cash Commitments"段落),但只保留了 v3 拷问清单能驱动 agent 做的处理。

▼ v3 产出片段 · 关于 SpaceX 重大现金承付义务的分析

关于 SpaceX 重大现金承付义务的分析 截至 2026-03-31,SpaceX 在 S-1 中披露的重大现金承付义务(Material Cash Commitments)主要包括以下几项:
  • 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 风险因子披露公司对第三方云算力提供商有"不可撤销的多年期容量承付义务",需按合同付款,与实际使用量无关。
  • 零部件与原材料采购:公司业务中常态采购协议大多无长期约束性订单,未来采购可能形成额外重大现金承付义务。
小结 综合上述披露,SpaceX 当前承担着规模可观的中长期承付义务,主要由 EchoStar 频谱收购、未偿债务、租赁、云算力承诺等组成。

▼ DRI 看完 v3 产出之后的反应

DRI 扫了一眼,皱起眉头 —— 这份产出所有信息都是真的、所有数字都对,但它没用。它读起来像一份"我把 S-1 的 commitments 段落翻译过来了"的总结,而不是一份"我帮你想清楚 SpaceX 在未来现金流上有多大压力"的判断。

具体哪里不够?DRI 能立刻指出来:

  1. 没有期限分布。196 亿、291.32 亿、58.23 亿这些数字砸在脸上,但它们具体什么时候要现金出去?近 12 个月要付多少?2027 年要付多少?2028 年以后呢?没有节奏感的总额是骗人的 —— 你不知道公司明年要不要再融一笔。
  2. 没有结构拆分。EchoStar 的 196 亿里,111 亿是用 261.8 百万股 A 类普通股付的(每股固定 $42.40),最高 85 亿才是现金(用来代付 EchoStar 的债)。"196 亿的 commitment"和"85 亿的现金 commitment + 111 亿的股本稀释"完全是两件事。
  3. 没有近两年占比。2026 财年内最低租赁付款 10.26 亿、2027-08-28 才有第一笔债务本金到期、EchoStar 现金支付预计 2027-11-30 才发生 —— 这意味着未来 18 个月内 SpaceX 在大额承付义务上的现金压力其实不算大。这条结论对融资节奏判断很关键,v3 的产出根本没碰到。
  4. 没有对现金流的含义判断。一份投研报告的最后一公里是"那这又怎样(so what)"。v3 给了"是什么(what is it)",没给"那这又怎样"。
STAGE 3 Sensor ①b DRI 下达修改指令 DRI ② · 下指令 纪律:改东西必须说出来

DRI 没有亲自动手改产出 —— 这是循环的纪律:改东西必须"说出来"。她在和 agent 的对话框里直接说了下面这句话:

DRI 原话
"承付义务这段太浅,拆出期限分布,重点说近两年占比和它对现金流的含义。"
→ 2026-05-21 15:42 · prospectus_research · 承付义务分析 · skill v3

agent 接到指令,做两件事:

  1. 自动调用 log_instruction() 把这条指令写进 instructions 表(动作 ①②);
  2. 在本次对话里执行修改,按指令重写承付义务那一段。

注意:DRI 没有亲自改任何文字,她只是把判断说出来。

STAGE 4 Tool instructions 表里这条记录长什么样 instructions 表结构

下面是真实写入数据库的字段:

{ "id": 23, "ts": "2026-05-21T15:42:08+08:00", "task_type": "prospectus_research", "skill_id": "prospectus_skill", "skill_version": "v3", "target_section": "承付义务分析", "instruction": "承付义务这段太浅,拆出期限分布,重点说近两年占比和它对现金流的含义。", "issue_category": null, "agent_output_before": "截至 2026-03-31,SpaceX 在 S-1 中披露的重大现金承付义务...(截断)", "promoted_to_skill": false }

几个要点:

  • instruction 字段一字不改保留 DRI 的原话 —— 这是一手 why,不需要 agent 二次推断。
  • issue_category 留空 —— 反思器在归纳时再补这一栏。
  • agent_output_before 存了 v3 的原产出,方便反思器看到"被指令针对的那段长什么样"。
  • promoted_to_skill = false —— 防止下一轮反思器重复消费同一条。
STAGE 5 Learning 同类指令积累 · 一周后的反思器 2026-05-25 周日晚 · cron 触发

这一周里,DRI 在做 SpaceX 调研以及另外两份招股书时,又陆陆续续下达了 5 条性质相似的指令。instructions 表中的相关记录如下(精简版):

▼ 6 条同类指令

#12"研发费总额给我没用,按业务线拆,告诉我哪个吞钱最快"研发费分析
#15"CapEx 别只给一个数,按 Starlink/Starship/Terafab 拆开,标注未来 24 个月节奏"CapEx 分析
#19"AI 分部收入要拆出广告 / 订阅 / 数据授权三块,单一总额没意义"收入分析
#23"承付义务这段太浅,拆出期限分布,重点说近两年占比和它对现金流的含义"承付义务
#24"云算力多年容量承诺也算承付义务,别漏,单独成段"承付义务
#27"291 亿债务必须拆出到期年份分布,给我看 2027/2028/2029 三档"长期债务

到 05-25 周日晚上,自动 cron 触发反思器(每周固定跑一次,且 task_type = prospectus_research 下未消费指令已超过 N=5 条)。

▼ 反思器读完 6 条指令后的归纳(输出 JSON 节选)

{ "patches": [ { "section": "拷问清单", "change_type": "add_rule", "new_rule_id": 7, "new_rule": "大额数字必拆结构。任何单一总额(承付义务、研发费、CapEx、收入、长期债务)出现时,必须追问其构成与期限分布:近 1-2 年占比、按分部/用途/币种拆分。总额掩盖节奏,结构揭示压力。", "based_on_ids": [12, 15, 19, 23, 24, 27] } ], "rationale": "6 条指令落在 6 个不同 target_section(研发费、CapEx、收入、承付义务×2、长期债务),但底层模式一致:DRI 反复要求'把单一总额拆成构成 + 期限'。归类 depth_insufficient(深度不够)。属于 ≥2 次反复模式,建议作为新规则进入 skill v4。" }
注意反思器没有为每一条指令分别加规则 —— 它做的是抽象:6 条不同 section 的指令背后是同一个判断模板("总额无意义,结构才有意义"),那么这条新规则就以最一般的形式落入 skill。这就是反思器的价值。
STAGE 6 Quality Gate 验证闸 · 留出集打分 + DRI 一键确认 DRI ③ · 守闸门 验证闸 · 留出集打分

候选补丁不直接上线,要先过留出集。

留出集:DRI 此前已经修改到满意的 3 篇黄金终稿(覆盖承付义务、研发费、CapEx 三个章节)。
LLM-as-judge 打分维度:完整性(是否覆盖期限分布)、结构性(是否拆出构成)、判断性(是否给出 so-what)。

结果:

留出集稿件skill v3 得分skill v4 候选得分
留出集稿件 · 承付义务(SpaceX)0.720.88
留出集稿件 · 研发费(同业 A)0.810.86
留出集稿件 · CapEx(同业 B)0.790.82
平均0.780.85

判定:v4 候选得分 0.85 ≥ 基线 0.78,进入待上线候选。
DRI 确认:DRI 张三 2026-05-26 上午看了 candidate diff,一键确认上线 v4(DRI 三落点中的"③ 守闸门")。

STAGE 7 Tool skill v3 → v4 · diff 2026-05-26 10:14 上线

下面是 skill 文件的真实 diff("拷问清单"章节):

prospectus_skill · 拷问清单 6. 现金流和净利润背离时,必须给出解释 + 7. 【新增】大额数字必拆结构。任何单一总额(承付义务、 + 研发费、CapEx、收入、长期债务)出现时,必须追问其 + 构成与期限分布:近 1-2 年占比、按分部/用途/币种拆分。 + 总额掩盖节奏,结构揭示压力。 + —— 沉淀自 6 条 DRI 指令 (#12, #15, #19, #23, #24, #27)

▼ skill_versions 表新增一条

{ "version": "v4", "parent_version": "v3", "change_summary": "拷问清单新增第 7 条「大额数字必拆结构」", "based_on_instructions": [12, 15, 19, 23, 24, 27], "eval_score_holdout": 0.85, "eval_baseline": 0.78, "status": "active", "promoted_at": "2026-05-26T10:14:00+08:00", "promoted_by": "yuanzhidian" }
同时反思器把 6 条 instruction 标记为 promoted_to_skill = true,避免下次重复消费。
STAGE 8 Tool 第二轮 · agent 用 v4 的产出 2026-05-27 · DRI 什么都没说

2026-05-27,DRI 让 agent 用 skill v4 重跑一遍 SpaceX 的承付义务段,看第一次产出长什么样。 注意:这次 DRI 什么都没说,agent 只是按 v4 的规则去写。

下面是 v4 第一次产出("第一次"是指:DRI 还没下任何修改指令):

关于 SpaceX 重大现金承付义务的分析 截至 2026-03-31,SpaceX 在 S-1 中披露的重大现金承付义务规模可观,但其现金流压力的真实节奏与披露的总额并不一致。下面按"先拆构成、再排期限、最后看含义"的顺序给出: 一、按构成拆分(区分现金 vs 股本,区分性质)
类别总额现金部分非现金部分性质
EchoStar 频谱收购196 亿最高 85 亿(代付 EchoStar 债务,不足现金补)111 亿(261.8M 股 A 类,固定 $42.40/股)战略性资产收购
总未偿债务(本金)291.32 亿全部现金还本付息(含可变利率)经营性 + 收购融资
最低租赁付款58.23 亿全部现金不动产、设备
第三方云算力多年期容量未披露全部现金,不可撤销,按合同付款经营性,不可撤销
部件原材料采购大多无长期约束取决于实际下单弹性较强
关键校正:外界容易把 EchoStar 的 196 亿当成"近期要现金出去 196 亿",但其中只有最高 85 亿是现金部分,且要到 2027-11-30 前后才支付;111 亿其实是股本稀释(按当前每股 $42.40 锁价,261.8 百万股新增 A 类普通股)。这两笔的财务含义完全不同。 二、按期限分布(未来 24 个月、24-48 个月、48 个月以上)
期限关键现金流出估算金额
未来 12 个月(至 2027-03-31)租赁付款(本财年剩余)+ 利息支出 + 云算力月度对价约 10–15 亿 现金(其中租赁本财年内 10.26 亿)
未来 12-24 个月(至 2028-03-31)2027-08-28 起首批债务本金到期(具体金额需查 Note 10)+ EchoStar 频谱现金支付(预计 2027-11-30)+ 持续租赁与云算力现金集中点:85 亿 + 数十亿债务本金
24 个月以上剩余债务本金、剩余租赁尾段大头
三、so-what · 对现金流的含义 1. 未来 18 个月并不构成现金压力高峰:本财年内承付义务实际现金流出主要来自租赁(10.26 亿)+ 利息 + 云算力,规模相对可控。债务本金最早 2027-08-28 才到期,EchoStar 现金支付要等到 2027-11-30。这意味着 SpaceX 在未来 18 个月内不需要为承付义务额外融资

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 个月成为隐性现金黑洞。建议追问管理层。

DRI 判断:这次没有再下任何修改指令。v4 第一次产出已经包含上一轮她说过的所有判断 —— 那一句"承付义务太浅,拆出期限分布",永久变成了 skill 的拷问清单第 7 条。

关于 SpaceX 重大现金承付义务的分析 截至 2026-03-31,SpaceX 在 S-1 中披露的重大现金承付义务(Material Cash Commitments)主要包括以下几项:
  • EchoStar 频谱许可收购:约 196 亿美元总对价,预计 2027-11-30 前后交割。
  • 未偿债务:合计未偿本金 291.32 亿美元,最早一笔本金到期日 2027-08-28。
  • 最低租赁付款:合计 58.23 亿美元,本财年内到期 10.26 亿美元。
  • 第三方云算力多年期容量承诺:S-1 风险因子披露公司有"不可撤销的多年期容量承付义务"。
  • 零部件与原材料采购:常态采购协议大多无长期约束订单。
小结 综合上述披露,SpaceX 当前承担着规模可观的中长期承付义务,主要由 EchoStar 频谱收购、未偿债务、租赁、云算力承诺等组成。

DRI 判断:所有信息都对、所有数字都真,但没用。读起来像把 S-1 翻译了一遍,没有期限分布、没有结构拆分、没有近两年占比、没有"那这又怎样"。

v3 vs v4 · 第一次产出的差距

维度v3 第一次v4 第一次
现金 vs 股本拆分没有85 亿现金 + 111 亿股本被显式分开
期限分布没有(只列了几个总额)按 0-12 / 12-24 / 24+ 三档
近两年占比没有明确指出未来 18 个月并不构成压力高峰
对现金流含义一句"规模可观"4 条具体判断(IPO 时点 / 稀释 / 黑洞 / 追问点)
第三方云算力承诺一笔带过单列警惕,标注未披露数额、给出建议追问
DRI 本轮指令数6 条 instructions0 条(不需要再说)

注意一个细节:DRI 在第二轮里没有下任何修改指令。她也不需要。v4 第一次写出来的,已经覆盖了她上一轮才"说出来"的所有判断。她原本要花 30 分钟写下来的那句"承付义务太浅,拆出期限分布……",永远地变成了 skill v4 拷问清单的第 7 条规则,对所有未来同类任务永久生效

FINAL 闭环 · 五层全过 一句话结论
DRI 那一句"承付义务太浅,拆出期限分布",没有被她自己再说第二遍。 它被 instructions 表接住、被反思器抽象成"大额数字必拆结构"、通过留出集验证、变成 skill v4 的拷问清单第 7 条 —— 对所有未来同类调研永久生效。

这正是 Burn Tokens, Not Headcount 那句 "By morning the codebase is smarter" 在投研场景的具体形态:

  • 被改的不是代码,是判断;
  • 被记住的不是 diff,是 DRI 亲口说的"为什么";
  • 复利不来自这一次循环本身,而来自下一次同类循环开始时,agent 已经知道得更多。

把 DRI 的三个落点连起来回看一遍:

  • ① 接 Sensor(STAGE 0):投委会纪要点名张三 → 任务进入循环;
  • ② 下指令(STAGE 3):一句"承付义务这段太浅" → 高质量训练信号沉淀;
  • ③ 守闸门(STAGE 6):留出集打分 + 一键确认 → skill v4 上线。

三个动作各占一个边缘位置,把循环的"开口、修正、上线"三件事都钉死在 DRI 身上。剩下的中段——产出、记录、反思、打分——agent 自己跑。

下一份招股书来到 DRI 手上的时候,她会发现 agent 一上来就把承付义务拆好了 —— 因为她之前的那一句话,已经是 skill 的一部分了。这就是 DRI 在 loop 边缘的复利。

附录 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 · 9 个阶段在五层循环 + 组织飞轮里的位置

阶段对应到五层循环 + 组织飞轮
STAGE 0 投委会纪要 · DRI 接 Sensor ①a组织飞轮 §2.1 Sensor 双入口 · §2.2 DRI 三落点 · ① 接 Sensor
STAGE 1 DRI 接任务 · 查 skill 版本Policy 层 · skill 版本绑定(CH01 §1.2)
STAGE 2 v3 第一次产出Tool 层 · agent 调用确定性 API(CH01 §1.3)
STAGE 3 DRI ② 下达修改指令Sensor ①b 修正信号入口 · §2.2 DRI 三落点 · ② 下指令
STAGE 4 instructions 表结构Tool 层 · log_instruction() 落库
STAGE 5 反思器归纳同类模式Learning 层 · 反思器周期归纳(CH01 §1.5)
STAGE 6 留出集打分 + DRI ③ 守闸门Quality Gate · 留出集 + DRI 一键确认 · §2.2 DRI 三落点 · ③ 守闸门
STAGE 7 skill v3 → v4 · diffContext 层 · skill 版本沉淀回写
STAGE 8 v4 第一次产出 · 蒸馏发生了下一圈起点更高 · 飞轮 N8(组织飞轮 §2.4)