# RESEARCH-007: SOTA 标杆逆向解构流与 RSI 副轨自动化治理架构实证研报

- **研报编号**：`RESEARCH-007`
- **课题**：业界 SOTA 标杆应用逆向解构（Reverse-to-Spec / Clean-Room 净室工程）与 RSI 副轨自动化治理巡航（Background Crucible / Blast Radius Hunter）架构实证调研
- **调研时间**：2026年10月
- **核心诉求与直觉审视**：
  1. **构想一（SOTA 标杆逆向解构流）**：做任何新功能前不闭门造车，逆向业界顶尖 SOTA 应用原型（状态机、数据流、交互边界、协议契约），萃取工程规格并由 Agent 净室实现。
  2. **构想二（RSI 副轨巡航卫士）**：针对工程中频繁出现的“改了A漏了B、改了B变了C（散弹式修改与涟漪回归破坏）修bug修得鬼火冒”痛点，构建后台 7×24h 常驻的 RSI 副轨（Background Crucible），主动审查代码一致性、计算变更爆炸半径、红蓝对抗挖掘漏洞。
- **一手信源与方法论基准**：
  - 逆向解构基准：`deliangs123/rea`（80k★ REA MCP 体系）、Clean-Room Software Engineering 原理
  - 副轨巡航基准：AST 爆炸半径分析（Blast Radius Analysis）、Mutation Testing（变异测试）、Invariance Oracles（不变式神谕）、Orca 多 Worktree 隔离调度
- **统一语言遵循**：[`CONTEXT.md`](../../CONTEXT.md)
- **协议依据**：[`AGENTS.md`](../../AGENTS.md)（实证探路优先原则与实体资产留痕优先原则）
- **状态**：已落盘归档 ✅

---

## 1. 调研背景与直觉审视 (Core Philosophy & Problem Statement)

在软件工程研发与 AI-native 自主编码的演进中，开发者经常面临两大经典“心智消耗”痛点：

### 痛点一：从零造轮子的“浅架构陷阱”与盲目摸索
- 开发者构思新功能时，如果仅从文字需求或粗浅原型出发，写出来的代码往往考虑不周全（异常分支缺失、状态机混乱、高并发下竞争崩溃、用户交互体验粗糙）。
- 业界往往已有验证充分的成熟 SOTA（State of the Art）应用（例如成熟的 IDE 插件、高性能协作文档、流式通信协议、终端会话管理器等）。它们在边缘情况、错误恢复、性能瓶颈上经历了千万级用户的千锤百炼。
- **用户直觉**：“做任何功能，先逆向业界 SOTA 原型，搞清它的工作原理，再应用到自己的循环中。”——**这一思考极其深刻且完全正确**。在工业级软件工程中，这正是经典的**“净室逆向工程（Clean-Room Reverse Engineering）”**与**“Reverse-to-Spec”**范式。

### 痛点二：“改了A漏了B，修了B坏了C”——令人崩溃的涟漪回归
- 无论是由人类开发者还是 AI Agent 主导的日常编码，最让人生气和疲惫的场景莫过于：
  > *“明明只是修一个字段，改完这里，结果引用的另一个地方忘了改；好不容易排查出来改了第二个地方，底层状态机又进入非法状态；按下葫芦浮起瓢，修 bug 修得鬼火冒。”*
- 软件工程学将这种现象严格定义为：
  1. **散弹式修改 (Shotgun Surgery)**：单一需求变更导致必须在多个互不相连的模块中做连锁微调；
  2. **隐式依赖破坏 (Broken Implicit Invariants)**：代码各处对数据格式、状态顺序存在未经编译器校验的“暗默假定”；
  3. **局部注意力盲区 (Local Attention Blindspot)**：人类与 Agent 的精力永远聚焦在当前编辑的数十行代码（局部 Diff），看不见全局拓扑调用图。
- **用户直觉**：“建立一个后台副轨，利用 RSI（递归自我改进）循环，针对已有的代码做 review，找 bug，做一致性检查。”——**这完全切中了现代自主研发体系的最强防护网：主轨交付，副轨巡航（Main-Track Delivery & Sidecar Crucible）**。

---

## 2. 构想一：SOTA 标杆逆向解构流 (Reverse-to-Spec)

### 2.1 传统模式 vs 逆向驱动模式

| 维度 | 传统模式 (Prompt-and-Pray) | SOTA 逆向驱动流 (Reverse-to-Spec) |
| :--- | :--- | :--- |
| **功能输入** | 模糊的人类提示词（如“帮我写个终端管理器”） | 捕获业界标杆应用的运行轨迹、状态图与数据包 |
| **边缘处理** | 凭大模型随机概率联想，漏掉 80% 异常边界 | 逆向提取出标杆应用历经实战检验的完整状态转移与容错分支 |
| **模块深度** | 浅模块（Shallow Module），接口复杂，实现漏洞百出 | 深模块（Deep Module），借鉴成熟架构的小接口、深实现 |
| **合规与版权** | 容易发生大段复现或无脑套用 | **Clean-Room 隔离**：仅萃取契约与 Spec，由 Agent 重新编写纯净代码 |

### 2.2 三阶逆向解构与净室重构流水线

```mermaid
flowchart TD
    subgraph Phase1 ["第一阶段：黑盒/灰盒标杆捕获 (SOTA Probe)"]
        TargetApp["业界 SOTA 标杆原型<br>(优秀应用/插件/协议服务)"]
        REA_Capture["REA MCP / 动态抓包 / AST 提取"]
        TargetApp --> REA_Capture
        REA_Capture --> Traces["运行时轨迹 / HAR 协议流 / 状态机转储"]
    end

    subgraph Phase2 ["第二阶段：架构逆向与规格萃取 (Reverse-to-Spec)"]
        SpecAgent["逆向分析智能体 (Reverse Architect)"]
        Traces --> SpecAgent
        SpecAgent --> ExtractedState["状态机模型 (Statechart)<br>定义所有合法状态与转移条件"]
        SpecAgent --> ExtractedContract["IPC / API 契约与数据流定义"]
        SpecAgent --> ExtractedEdges["极端边界与错误恢复策略 (Corner Cases)"]
        
        ExtractedState & ExtractedContract & ExtractedEdges --> FormalSpec["工程规格说明书<br>(docs/specs/SPEC-NNNN-*.md)"]
    end

    subgraph Phase3 ["第三阶段：双盲净室实现 (Clean-Room Implementation)"]
        FormalSpec --> ContractTests["契约测试与前置门禁 (TDD Red)"]
        ContractTests --> CodingAgent["主轨编码智能体 (Clean Coder)"]
        CodingAgent --> GreenCode["100% 自主编写的纯净代码 (Green & Refactored)"]
    end

    style Phase1 fill:#f8fafc,stroke:#64748b,stroke-width:1px
    style Phase2 fill:#eff6ff,stroke:#3b82f6,stroke-width:1px
    style Phase3 fill:#ecfdf5,stroke:#10b981,stroke-width:1px
```

### 2.3 净室工程 (Clean-Room) 的关键防火墙
为了确保代码既具备业界顶尖的设计水准，又具备 100% 独立知识产权与零版权风险，必须执行**“双盲隔离”**：
1. **分析员 Agent (Analyst)**：使用 REA MCP 深入目标二进制或前端 AST，只负责输出文字版的契约规范（`SPEC`）、状态转移图和测试用例；
2. **编码员 Agent (Coder)**：**严禁**直接阅读目标应用的原始源码或反编译反汇编伪代码。编码员只面对 `SPEC` 和测试用例，从零编写实现。
3. **收益**：既白嫖了业界经过数万次故障换来的系统健壮性设计，又保证了工程代码的优雅、纯净与自主可控。

---

## 3. 构想二：RSI 副轨巡航卫士 (The Background Crucible)

为了从根源上治愈“改了这个漏了那个、修 bug 修得鬼火冒”的顽疾，我们必须将 AI Agent 的职责拆分为**“主轨（Delivery Track）”**与**“副轨（Crucible Track）”**。

### 3.1 主副双轨拓扑架构

```mermaid
sequenceDiagram
    autonumber
    actor Dev as 开发者 / 主轨 Agent
    participant MainRepo as 主分支工作区 (Git main)
    participant Sidecar as RSI 副轨巡航卫士 (Git Worktree 隔离)
    participant AST_Engine as AST 依赖与爆炸半径引擎
    participant Crucible as 变异对抗与不变式沙盒 (Crucible)
    participant IssueTracker as 工单工作区 (docs/issues/)

    Dev->>MainRepo: 提交代码修改 (Git Commit: 修复某业务Bug)
    activate MainRepo
    MainRepo-->>Sidecar: 异步事件通知 (Commit Hook / orca check)
    deactivate MainRepo
    
    activate Sidecar
    Note over Sidecar: 在独立 Worktree (new-child) 启动巡检
    Sidecar->>AST_Engine: 1. 解析 Git Diff，计算【变更爆炸半径 (Blast Radius)】
    activate AST_Engine
    AST_Engine-->>Sidecar: 输出受波及的直接/间接调用集 (Impact Set: 5处关联调用)
    deactivate AST_Engine

    Sidecar->>Sidecar: 2. 检查一致性：Diff 是否覆盖所有受影响调用点？
    alt 发现漏改 (改了A漏了B)
        Sidecar->>IssueTracker: 登记阻断工单：检测到散弹式修改遗漏
    else 静态调用一致
        Note over Sidecar: 进入动态对抗阶段
    end

    Sidecar->>Crucible: 3. 运行【不变式校验】与【红蓝变异攻击 (Mutation Fuzzing)】
    activate Crucible
    Crucible-->>Sidecar: 攻击结果：构造边界数据引发底层状态违规！(复现用例已生成)
    deactivate Crucible

    Sidecar->>IssueTracker: 4. 自动创建高信度 Bug 工单 (含最小复现测试用例)
    Sidecar->>MainRepo: 5. 提交修复建议 PR (隔离验证通过后提请)
    deactivate Sidecar
    
    Dev->>IssueTracker: 开发者审阅：Bug 被提前扼杀在摇篮，零线上暴雷！
```

---

## 4. RSI 副轨的四大核心武器库 (Crucible Arsenal)

要让副轨真正具备“神探”般的自省和查漏能力，不能仅靠大模型泛泛的“文本审阅”，必须配备四套硬核工程工具：

### 武器 1：AST 语法树依赖与变更爆炸半径分析 (Blast Radius Mapping)
- **原理**：改动一段函数或字段时，不依赖人类记忆去搜关键词，而是利用静态分析工具（TypeScript Compiler API、Python `ast` 模块或 Rust `tree-sitter`）构建全项目的**抽象语法树调用依赖图（Call Graph & Type Topology）**。
- **巡航机制**：
  > **爆炸半径数学定义**：`Blast Radius = Direct Callers ∪ Indirect Transitive Callers ∪ Overridden Interfaces`
  副轨自动计算出本次 Diff 涉及的“影响集（Impact Set）”。
  - 如果函数签名或数据结构变了，而影响集中有 3 个调用方在本次 commit 中未作任何变动，副轨立即亮红灯：**“警告：检测到典型的散弹式遗漏，`module_b.ts:42` 仍在使用旧假定调用！”**

### 武器 2：领域不变式神谕 (Invariance Oracles & Semantic Contracts)
- **原理**：很多 Bug 不是语法错误，而是**语义违规**（如：“订单状态变为已退款后，库存必须同步回补”、“化学方程式配平系数必须全为正整数”、“生物动作电位去极化时膜内电位必须高于膜外”）。
- **巡航机制**：
  副轨依据项目规范 [`CONTEXT.md`](../../CONTEXT.md) 与 ADR 设立“不变式断言库”。每次提交，副轨执行属性基测试（Property-Based Testing，例如基于 Hypothesis 或 fast-check）：
  - 随机生成 10,000 种合法与边界输入，验证系统在任何随机状态转移下，**全局不变式是否永远成立**。
  - 一旦发现某个边界输入打破了不变式，立即捕获并记录。

### 武器 3：红蓝变异对抗挖掘 (Mutation Testing & Fuzz Crucible)
- **原理**：传统的单测只能测试“开发者想到的情况”。副轨作为“红队测试员”，其目标是**千方百计搞垮刚提交的代码**。
- **巡航机制**：
  - **代码变异（Mutation）**：副轨自动反转条件分支（`>` 变 `>=`、`+` 变 `-`、删掉 null 判断），查看现有测试套件是否能捕获该变异（Kill the Mutant）。如果变异存活，说明这块代码测试覆盖极其脆弱。
  - **定向模糊测试（Targeted Fuzzing）**：针对刚修好的 bug 注入极限值（超大整数、空字符串、并发同时请求、网络断开等），验证是否“按下葫芦浮起瓢”。

### 武器 4：独立 Worktree 隔离与显式工单提请 (Worktree Isolation & Ticket Synthesis)
- **原理**：副轨无论做多么耗时的变异测试、跑多么庞大的调用图分析，**绝对不能卡住主轨开发，更不能直接在主代码上乱动破坏未保存进度**。
- **巡航机制**：
  - 严格遵循 `AGENTS.md` 规范：副轨始终通过 Orca 启动独立的 Git Worktree（`--worktree new-child`）；
  - 副轨在独立沙盒中完成复现验证；
  - 只有当副轨写出**100% 稳定失败的最小可复现单测（Minimal Repro Test）**，且给出通过验证的修复 patch 时，才在 `docs/issues/` 下生成正式工单并提交 PR，等待主轨审阅合并。

---

## 5. 对比与辨析：为什么副轨能彻底解决“改了A漏了B”？

| 常见治理手段 | 人类开发者排查 | 传统 CI / 静态检查 (ESLint/Jest) | RSI 副轨巡航卫士 (Sidecar Crucible) |
| :--- | :--- | :--- | :--- |
| **工作方式** | 依赖肉眼看 Diff，疲惫时极易漏看 | 机械规则匹配，只查当前文件语法/已知测试 | 全局拓扑依赖分析 + 动态主动变异攻击 |
| **覆盖广度** | 仅关注眼前几十行改动 | 只覆盖预先写好的静态用例 | 动态展开全项目 AST 爆炸半径，拉网式排查 |
| **发现隐患** | 经常漏改，线上出 bug 鬼火冒 | 语法通过但业务语义被破坏 | 发现“改了A漏了B”，当场揪出未改动的影响方 |
| **对新 Bug 的态度** | “只要没报错就先上线” | “只要单测全绿就放行” | “我要合成 1,000 个极端用例主动攻击它” |
| **介入体验** | 人肉救火，频繁打断思路 | 每次 push 阻塞等待 CI 几分钟 | **后台静默巡航，零打扰；确认有确凿证据才递交工单** |

---

## 6. 在本工程与新项目中的工程化落地路线 (Actionable Roadmap)

基于上述实证与架构推导，推荐将这一思想分三个递进阶段落地：

### 第一阶段：轻量落地 —— 静态爆炸半径扫描器 (Blast Radius Pre-Flight)
- **落地动作**：编写一个无依赖的 AST 检查脚本（如 `scripts/blast_radius.py`），挂载在 commit 或自审阶段。
- **行为**：每次修改公共函数、类型定义或全局常量时，脚本自动列出整个项目所有引用了该符号的文件；若发现引用方未包含在本次 git diff 中，在控制台高亮提示，杜绝“改了A漏了B”。

### 第二阶段：规范落地 —— SOTA 逆向驱动规格模板 (Reverse-to-Spec Workflow)
- **落地动作**：在开发复杂新模块（如高频交互、本地缓存、复杂状态机）前，不直接写代码，而是增加前置步骤：
  1. 使用 REA MCP 分析业界同类标杆应用的数据流与 IPC 消息契约；
  2. 沉淀出 `docs/specs/SPEC-NNNN-*.md` 规格与契约测试；
  3. 主轨 Agent 根据 Spec 进行净室编码交付。

### 第三阶段：全自主落地 —— Orca 驱动的 7×24h 副轨 Crucible Loop
- **落地动作**：使用 Orca 调度引擎拉起常驻后台 Worker：
  - 监听 Git 仓库的每一次 commit；
  - 自动在独立 Worktree（`--worktree new-child`）拉起变异测试与不变式对抗；
  - 发现隐患自动生成带最小复现代码的工单（`docs/issues/crucible-findings/`）并提出 PR；
  - 彻底将开发者从“修 bug 修得鬼火冒”的泥潭中解放出来。

---

## 7. 结论与总结 (Conclusion)

1. **用户的直觉高度契合国际软件工程顶尖实践**：无论是“从 SOTA 标杆逆向架构规范”还是“用 RSI 副轨自动化巡航消灭回归 Bug”，都是跳出粗放式 AI 编码、走向高可靠工业级系统的不二法门。
2. **逆向不是抄袭，而是净室吸收架构精髓**：通过 REA 与动态协议追踪，我们学到的是业界最健壮的状态机与边界处理方式；通过双盲隔离，我们产出的是 100% 自主纯净的高质量代码。
3. **副轨的核心价值是“认知盲区外包”**：人类和主轨 Agent 只需专注实现眼前的业务逻辑；把所有“有没有改漏”、“有没有连锁破坏”、“在极端并发下会不会崩”的繁重体力活与对抗测试，彻底交给后台不知疲倦的 RSI 副轨巡航卫士。