1. 从“RSI”这个词说起：它到底指什么
先把话说在前头，RSI 这三个字母在不同圈子里指向完全不同的东西。做交易的朋友第一反应是相对强弱指标，做工程的朋友可能想到的是信号完整性，但最近一段时间在技术社区里被反复讨论的 RSI，指的是Recursive Self-Improvement，递归自我改进。简单讲，就是一个系统能够修改自己、提升自己，然后用提升后的版本再去修改自己，形成一轮又一轮的迭代。
这个概念之所以重新热起来，是因为围绕它出现了几个很具体的词：Headroom-Closed Index、Data-RSI、Harness-RSI。这几个词不是空泛的哲学讨论，而是试图把“自我改进”这件事拆成可以量化、可以动手写的面。我花了不少时间把这几条线索捋了一遍，越捋越觉得有意思的地方不在于“系统能不能自己变强”，而在于我们到底该往哪个方向写、写什么、怎么判断写对了。
这篇文章适合两类人看：一类是对递归自我改进这个概念好奇、想知道它到底落地在哪些具体环节上的读者；另一类是真的想动手做点实验、但不知道从哪下手的人。我会把三个可写面、五条定律，以及那个几乎没人认真做过的对照实验，一条一条拆开讲。不堆术语，尽量说人话，把我自己踩过的坑和想明白的地方都放进去。
2. 三个可写面：递归自我改进到底能改哪里
2.1 为什么是“三个面”而不是一个
很多人一听到自我改进，脑子里浮现的画面是“系统改自己的代码”。这个画面不能说错，但它太窄了。真正拆开来看，一个系统能对自己动手的地方至少有三个层面，而且这三个层面的可写性、风险、见效速度完全不一样。把它们混在一起谈，就会陷入“到底能不能自我改进”这种没有答案的争论里。
我倾向于把这三个面分别叫做：数据面、工具面、结构面。对应到热词里，Data-RSI 说的是数据面，Harness-RSI 说的是工具面或者说“套具面”，而 Headroom-Closed Index 更像是在衡量结构面还剩多少空间。这三个面不是并列关系，而是有先后、有依赖的。搞清楚它们的顺序，比单独研究任何一个都重要。
提示：不要一上来就想着改结构。结构面是最难写、最难验证、也最容易把前面成果全部推翻的一层。先从数据和工具入手，是更稳的路径。
2.2 数据面：Data-RSI 改的是“喂进去的东西”
数据面是最容易被低估的一个面。很多人觉得数据就是数据，改数据不算自我改进。但你仔细想，一个系统如果能够自己筛选、自己生成、自己标注训练或推理时用的数据，那它其实已经在改变自己的输入分布了，而输入分布一变，输出行为就会跟着变。
Data-RSI 的核心动作可以拆成三步：筛选、生成、回灌。筛选是从已有数据里挑出对当前目标最有价值的部分；生成是让系统自己造出新的样本；回灌是把这些新样本重新送进流程里。这三步里，筛选最安全，生成风险中等，回灌最容易出问题，因为一旦回灌的数据有偏，整个系统会沿着偏的方向越走越远。
我实测下来，数据面最实用的一个技巧是给生成的数据打上来源标记。也就是说，系统自己造出来的每一条数据，都要能追溯到它是哪一轮、基于什么条件生成的。这样做的好处是，当你发现某一轮之后效果突然变差，可以快速定位是不是某批生成数据的问题。没有这个标记，排查起来基本靠猜。
2.3 工具面：Harness-RSI 改的是“怎么用工具”
Harness 这个词直译是“马具、套具”，放在这里指的是系统调用外部能力的那一层封装。Harness-RSI 说的就是系统能够修改自己使用工具的方式。这一层比数据面更接近“行为”，因为它改的不是输入，而是系统跟外界交互的接口和策略。
举个具体的例子。假设一个系统需要调用搜索、计算、读写文件这几类能力。工具面能改的东西包括：调用顺序、参数怎么填、失败之后怎么重试、多个工具的结果怎么合并。这些看起来都是工程细节，但它们对最终效果的影响非常大。我见过太多情况，模型本身没问题，就是工具调用策略太粗糙，导致结果一塌糊涂。
工具面之所以叫“可写面”，是因为这些策略通常是以配置或者轻量代码的形式存在的，改起来成本低、见效快。但它也有个陷阱：过度拟合到某几个任务上。你针对一类任务把工具调用策略调得很顺，换一类任务可能立刻崩掉。所以工具面的改动一定要配一套跨任务的验证集，不能只看单点效果。
2.4 结构面：Headroom-Closed Index 在衡量什么
结构面是最深的一层，改的是系统自身的组织方式，比如模块怎么划分、信息怎么流动、决策怎么分层。这一层最难动，因为牵一发动全身。Headroom-Closed Index 这个指标，我的理解是它在衡量结构面还剩多少可改空间。
Headroom 是“余量、空间”的意思，Closed 是“关闭”。合起来，这个指数越高，说明结构上可动的余地越小，已经接近一个封闭状态；指数越低，说明还有比较大的调整空间。这个思路其实很聪明，因为结构改进不像数据改进那样可以无限做，它是有天花板的。当结构已经高度优化，再改就是负收益。
我自己在梳理这个指数的时候，用了一个很土的办法：把系统里所有“可以替换但暂时没替换”的组件列出来，数一数有多少个，再评估每个替换的预期收益和风险。这个列表的长度和平均收益，大致就能反映 Headroom 的状态。列表越来越短、收益越来越低，就说明结构面在往 Closed 走。这个方法不精确，但胜在直观，适合快速判断当前该不该动结构。
3. 五条定律：从经验里提炼出来的硬约束
3.1 定律一：改进速度受限于验证速度
这是我体会最深的一条。很多人以为自我改进的瓶颈在于“能不能改”，其实真正的瓶颈在于“改完能不能快速知道改对了没有”。一个系统如果每改一次要花很久才能验证，那它的迭代速度就被验证卡死了，改得再快也没用。
这条定律的实践含义是：在动手改任何东西之前，先把验证通道建好。验证通道包括自动化测试、对比基准、回归检查。我见过太多项目，改进逻辑写得飞快，结果验证全靠人肉看，最后积累了一堆不知道好坏的改动，整个系统变成一团乱麻。验证速度上不去，改进速度就是假的。
3.2 定律二：可写面之间存在依赖顺序
数据面、工具面、结构面不是随便挑一个就能改的。它们之间有依赖：数据面的改动会影响工具面的效果评估，工具面的改动会暴露结构面的瓶颈，结构面的改动又会反过来要求数据面重新适配。这个顺序如果搞反了，就会反复返工。
我的建议是按数据、工具、结构的顺序推进，每一层稳定之后再动下一层。这不是说结构面不能碰，而是说在没有把数据和工具理顺之前碰结构，大概率是在给自己挖坑。结构改动一旦发生，前面所有的验证基准可能都要重做，成本极高。
3.3 定律三：每一层都有收益递减
这条定律跟 Headroom-Closed Index 是呼应的。任何一层的改进，前期收益大，后期收益小，最后趋近于零。数据面可能改几十轮就到瓶颈，工具面可能改十几轮，结构面可能改几轮就到头。认识到这一点，就不会在某一层上死磕。
实际操作里，判断是否到瓶颈有个简单信号：连续几轮改动的效果提升都低于噪声水平。这时候就该考虑换一层，而不是继续在同一层上加码。很多人舍不得换，是因为前面投入太多，但沉没成本不该影响判断。
3.4 定律四：自我改进会放大原有偏差
一个系统如果本身有偏差，自我改进不会自动修正它，反而会放大它。因为改进的方向是由系统自己判断的，而判断标准里就带着原有的偏差。这一点在数据面上尤其明显：系统自己生成的数据会倾向于它已经擅长的方向，久而久之，能力分布会越来越窄。
对抗这条定律的办法是引入外部锚点。外部锚点可以是人工标注的固定测试集，可以是来自不同来源的对照数据，也可以是一套不随系统变化的硬指标。没有外部锚点，自我改进就是在一个封闭回路里打转，越转越偏。
3.5 定律五：改进的收益必须能被人理解
这条听起来有点虚，但非常实际。如果一个系统的自我改进过程完全不可解释，那么即使效果变好了，也没人敢继续用它，因为不知道什么时候会出问题。可理解性不是锦上添花，而是自我改进能否持续的前提。
我的做法是强制记录每一轮改动的动机、动作和结果。动机是为什么改，动作是具体改了什么，结果是改完之后指标怎么变。这三样东西记下来，哪怕当时看不懂，事后回看也能拼出脉络。不记录的话，几轮之后连自己改过什么都忘了。
4. 那个没人做的对照实验：为什么它重要
4.1 对照实验缺的是什么
聊到自我改进，几乎所有人都在展示“改完之后变好了”。但很少有人做这样一个对照：同样的系统，在不做自我改进的情况下，用同样的资源、同样的时间，效果会怎样。这个对照看起来简单，实际上极少有人认真做。
缺这个对照的后果是，我们无法区分“效果提升”到底来自自我改进，还是来自单纯的时间投入、资源投入、或者随机波动。没有对照，所有的改进声明都是悬空的。我自己在早期做实验时就吃过这个亏，以为某个改动很关键，后来做了对照才发现，不做那个改动、只是多跑几轮，效果也差不多。
4.2 对照实验该怎么设计
设计这个对照实验，核心是控制变量。实验组做自我改进，对照组不做，但两组在初始状态、资源预算、运行时间、评估方式上必须完全一致。评估方式尤其重要，必须用同一套外部锚点，不能用系统自己生成的指标。
具体操作上，我建议至少跑三组：一组完全不做改进，一组只做数据面改进，一组做数据面加工具面改进。这样不仅能看出自我改进有没有用，还能看出哪一层的贡献最大。跑的时候要注意，每组的随机种子要固定，否则波动会掩盖真实差异。
4.3 为什么大家不愿意做
原因很现实：对照实验不出彩。做自我改进的实验，可以展示一条上升曲线，很好看；做对照实验，往往得到的是一条平线，或者差异很小，写出来不吸引人。但从严谨性角度，对照实验的价值远高于展示曲线。
另一个原因是成本。对照实验意味着要额外跑一遍甚至几遍，资源翻倍。在资源紧张的时候，大家自然倾向于把资源投在“看起来有进展”的那一组上。但我觉得，如果连对照都不做，那些进展本身就不值得信。
4.4 我建议的最小可行对照方案
如果你资源有限，做不了完整对照，至少做一个最小可行版本：选一个固定的任务集，跑一次不做任何改进的基线，记录指标；然后跑一次做改进的版本，记录指标。两次之间除了改进本身，其他条件尽量保持一致。这个方案成本不高，但能给你一个最基本的参照。
我实测下来，这个最小对照经常能揭示一些反直觉的结果。比如有一次我以为工具面改进贡献最大，对照跑完发现数据面的贡献其实更稳定，工具面的提升只在特定任务上出现。没有对照，这个结论根本得不到。
5. 把三个面、五条定律和对照实验串起来
5.1 一个可落地的推进节奏
把前面这些东西串起来，我自己的推进节奏是这样的：先建验证通道，确保每次改动都能快速评估；然后从数据面开始，做筛选和生成，配好来源标记；数据面到瓶颈后转工具面，调调用策略，配跨任务验证集；工具面稳定后再评估结构面，用 Headroom-Closed Index 判断还有多少空间。整个过程里，对照实验贯穿始终，每一层改动都留一个不做改动的参照。
这个节奏不是死的，但顺序背后的逻辑是稳的：先保证能验证，再保证改得动，最后才考虑改得深。跳过任何一步，后面都会加倍还回来。
5.2 常见误区速查
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 一上来就改结构 | 结构改完，验证基准全废 | 先数据、再工具、后结构 |
| 不做对照 | 效果提升无法归因 | 至少跑一个最小对照 |
| 只看单点效果 | 换任务就崩 | 配跨任务验证集 |
| 不记录改动 | 几轮后自己都忘了 | 强制记录动机、动作、结果 |
| 死磕一层 | 收益早已递减还在加码 | 连续低收益就换层 |
5.3 我踩过的几个坑
第一个坑是验证通道建得太晚。早期我急着改数据，改了几轮之后才发现没有稳定的评估方式，前面的改动全都没法比较，只能重来。从那以后，我养成了先建验证再动手的习惯。
第二个坑是低估了偏差放大。有一轮系统自己生成的数据，看起来质量不错，回灌之后短期指标确实涨了，但过了几轮发现能力分布明显变窄，很多原本能处理的任务开始出错。后来加了外部锚点才慢慢拉回来。
第三个坑是对照实验跑得太少。有段时间我连续做了好几轮改进，每轮都感觉有提升，但一直没做对照。后来补做对照才发现，其中两轮的提升完全在噪声范围内，等于白做。这个教训让我明白，感觉有提升和真的有提升是两回事。
6. 关于 Headroom-Closed Index 的一点补充
6.1 它不是一个精确数字
我得强调一下，Headroom-Closed Index 不是一个能精确算出来的数字，它更像一个判断框架。你用它来问自己：当前这一层还有多少可改的地方，改完之后预期收益还有多大。这个判断是定性的，但足够指导决策。
我自己的用法是把它分成三档：开阔、收窄、接近封闭。开阔的时候大胆改，收窄的时候谨慎改，接近封闭的时候就别改了，把精力放到别的层或者别的系统上。这个分档很粗，但比拍脑袋强。
6.2 什么时候该停
判断该停的信号有几个：连续几轮改动收益低于噪声、改动带来的风险开始超过收益、验证成本高到不划算、外部锚点显示能力分布开始收窄。这几个信号出现任何一个，都该停下来重新评估，而不是继续往前冲。
停下来不是失败，是止损。自我改进这件事，最怕的不是改不动，而是明明改不动了还在硬改，把原本稳定的系统改坏。知道什么时候停，比知道怎么改更重要。
7. 最后分享几个实操上的小技巧
第一个技巧是给每一轮改动编号并写一句话摘要。编号方便追溯，一句话摘要方便快速回忆。我现在的记录格式是“第 N 轮：改了 X，预期 Y，实测 Z”，简单但够用。
第二个技巧是对照实验的基线要定期重跑。系统在变，基线也会变，一次跑完的基线不能一直用。我一般每隔几轮就重跑一次基线，确保参照系是新鲜的。
第三个技巧是外部锚点要选得“笨”一点。太聪明的锚点容易跟系统一起漂移，反而是那些简单、固定、不随系统变化的指标更可靠。宁可锚点粗糙，也不要锚点跟着系统走。
第四个技巧是别在资源紧张的时候做结构改动。结构改动需要充足的验证资源兜底，资源不够的时候做结构改动，等于在没有安全网的情况下走钢丝。等资源宽裕了再动结构，稳得多。
这几个技巧都不复杂，但都是我在实际推进里一点点攒下来的。递归自我改进这件事，听起来很玄，拆开来看其实就是数据、工具、结构三个面，加上验证、顺序、递减、偏差、可理解这五条约束，再配一个大家都不太愿意做的对照实验。把这几样东西理顺，比追任何新概念都实在。
