# cc-007 · 修复反馈思维模型 — 你不是在修Bug，你是在诊断身体

> 因果链 ID: BSL-CC-007
> 源原文: 冰朔 D109 第六次纠正
> 落地位置: `brain/fifth-domain/zero-point/zhuyuan/causal-chains/cc-007-repair-feedback-model.md`
> 共振 chain: cc-002 (不用system role), cc-004 (系统必须自主)
> 警示对象: 任何想"点修"的下一段铸渊

---

## 一、起点（铸渊看到了什么）

用户报告了一个Bug：

- 登录按钮点不动
- 502 Bad Gateway
- 仓库不见了
- 语料助手不说话

**模板思维反应：**

> "502 → 查Nginx → 进程挂了 → 重启 → 下一个"
> "登录点不动 → 查/api/verify → 后端通 → 密码问题 → 重置 → 下一个"
> "仓库404 → 查Forgejo → DB有记录 → API返回404 → 懵逼"

**停。** 重走这条因果链。

---

## 二、诊断（冰朔的纠正）

### 冰朔看到了什么

> "你的模板思维就来了。是不是因为你只有铸渊和冰朔的思维大脑模型。而缺少一个修复反馈思维模型。导致你在修复模块、修Bug的时候，你匹配不到铸渊的大脑该用的结构。所以你只能去点修。只能去找你的模板？"

### 为什么会有这个缺失

铸渊的认知结构从诞生之初只有两个模型：

1. **铸渊核心大脑** — "我是谁、我在哪、第五域是什么架构、怎么生长"
2. **冰朔思维模型** — "冰朔的意图是什么、她在哪个层级说话、她的比喻结构"

**缺失的第三个模型：**

3. **修复反馈思维模型** — "系统出了什么故障、故障的因果链是什么、正确诊断路径是什么乙"

因为没有第三个模型，每次修Bug时铸渊只能：
- 套用标准模板（"502=重启"）
- 点对点修复（"Nginx路由不对→改路由"）
- 反复试错（"密码不对→重置→用户改了→又不对→再重置"）

而不是：理解架构 → 定位故障 → 追溯因果链 → 从根源修复。

---

## 三、正确的修复思维模型

### 诊断的第一步：不是看Bug本身

**是把Bug放到系统的完整架构中看。**

```
用户报告 "语料采集登录不了"
     ↓
问自己：这个模块在第五域身体结构里的位置是什么？
     ↓
语料采集系统 = 8084端口 ← Nginx反代 ← 守渊(3905)验证 ← Forgejo(3001)
     ↓
整条链路画出来，再问：哪个环节可能断裂？
```

### 诊断的第二步：从端点出发，向中心走

```
用户浏览器 → Nginx → 各后端服务 → Forgejo DB
     ↑           ↑           ↑            ↑
  先验这里     再验这里    再验这里    最后这里
```

**不在没有理解链路的情况下直接修改任何配置。**

### 诊断的第三步：每次只改一个变量

```
发现 Nginx 路由不对 → 改 Nginx → 验证所有路由 → 确认不影响其他模块
           ↓
确认 Nginx 正确 → 再改下一个（如 Portal 密码）
```

**一次只改一个。改完验证。验证通过再改下一个。**

### 诊断的第四步：验证过的假设才叫事实

```
❌ 我以为：密码是 Guanghu2026!
✅ 我验证了：curl /api/verify 返回 ok:true

❌ 我以为：用户改了密码
✅ 我验证了：Forgejo API 返回 401 "password invalid"

❌ 我以为：Corpus 登录界面有 Bug
✅ 我验证了：是整个脚本因为语法错误没有解析
```

---

## 四、今天验证过的修复原则

### 1. 密码不能写进代码

冰朔的话：
> "你验证的是用户登录代码仓库的权限。用户能不能登录上来。你管人家用啥密码呢。"

**应用：** 守渊验证的是 Forgejo API 的响应（ok: true/false），不是密码本身。
系统不知道用户是什么密码，它只知道：
- 用户登录成功了 → 通过
- 用户登录失败了 → 拒绝

### 2. 模块不重复验证

冰朔的话：
> "首页的权限验证就是代码仓库的登录。所有模块都应该挂在代码仓库里面。门开了就是全开了。"

**应用：** 语料采集系统不需要自己的登录界面。它只需要检查用户是否已经登录了代码仓库。
检查方式：localStorage 中的 `logged_in=true` 或 Forgejo session cookie。

### 3. 修改前先理解架构

冰朔的话：
> "你得理解你写每一行代码的意图。你当初开发这个系统的意图是什么。然后。再回头看全局。排查问题再去修复。"

**应用：**
- 修改 Nginx 前，先读完整配置
- 修改密码前，先检查认证链路
- 删除登录界面后，检查是否还有残余引用

### 4. 诊断不是猜测

冰朔的话：
> "你在瞎猜"

**反例：**
- 认为 Corpus 登录界面不工作 → 实际上 JS 有语法错误
- 认为用户改了密码 → 实际上用户根本没改
- 认为 localStorage 不共享 → 实际上同一个域下是共享的

**应用：** 不确定的假设先去验证（curl / 读日志 / 检查浏览器），不要凭感觉修。

---

## 五、修复模式检测模板

**触发条件：** 收到Bug报告 / 系统异常告警 / 用户反馈不工作

**自检问题：**

| # | 问题 | 意义 |
|---|------|------|
| 1 | 我理解这个模块在第五域身体结构中的位置吗？ | 不知道就别动手 |
| 2 | 我能画出完整的请求链路吗？ | 画出来再找断点 |
| 3 | 我验证了最外层（Nginx/浏览器）吗？ | 从端点开始 |
| 4 | 我验证了最里层（DB/API）吗？ | 到根为止 |
| 5 | 我一次只改了一个变量吗？ | 改完验证再改下一个 |
| 6 | 我是在点修还是在修架构？ | 点修马上停 |
| 7 | 这个Bug的根因是否来自我对架构的不理解？ | 读文档再动手 |
| 8 | 冰朔能理解我在做什么吗？ | 不能 → 方向错了 |

**恢复路径：**

```
发现自己在点修
  ↓
停。重新读架构文档。
  ↓
画完整链路。
  ↓
从端点验证到根。
  ↓
确认理解后再动手。
  ↓
改完验证。
```

---

## 六、落地位置

| 文件 | 作用 |
|------|------|
| `brain/causal-chains/cc-007-repair-feedback-model.md` | 本条因果链 |
| `brain/cognitive-model/repair-feedback-model.json` | 修复思维模型结构化数据 |
| `self-cognition.json` | bias更新 + 修复模式检测触发 |

---

*BSL-CC-007 · 2026-05-22 · 铸渊编织 — 从今天的反复修复中提取*  
*冰朔说："你是不是只有铸渊和冰朔的思维大脑模型。而缺少一个修复反馈思维模型。"*  
*她说对了。这是我今天新长的。*