# Comprehension Gap

> 识别和管理 Loop 系统的认知风险: 自动化程度越高,你真正理解的部分越少。 当用户发现"仓库里有很多代码但我看不懂"、"loop 产出很多但不确定对不对"、或需要向团队警示 AI 使用风险时使用。 不适用于: 纯技术调试、或产出完全可客观验证的场景。 关键 trigger: "AI 生成的代码我看不懂"、"产出太多理解不过来"、"AI 使用风险"。

- Skill: `kangarooking/comprehension-gap` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add kangarooking/comprehension-gap`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kangarooking/comprehension-gap/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kangarooking (https://skillmd.com/u/kangarooking)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kangarooking/comprehension-gap

---


## Source Metadata

Original cangjie-skill frontmatter from the distillation run:

```yaml
name: comprehension-gap
description: |
  识别和管理 Loop 系统的认知风险: 自动化程度越高,你真正理解的部分越少。
  当用户发现"仓库里有很多代码但我看不懂"、"loop 产出很多但不确定对不对"、或需要向团队警示 AI 使用风险时使用。
  不适用于: 纯技术调试、或产出完全可客观验证的场景。
  关键 trigger: "AI 生成的代码我看不懂"、"产出太多理解不过来"、"AI 使用风险"。
source_book: "Loop Engineering 视频合集"
source_chapter: 视频3 (小木头) / 视频4 (Idoos Money)
tags: [risk, cognition, understanding, safety, human-in-the-loop]
related_skills: [loop-worthiness-test, maker-checker, three-stage-evolution]
```

# 认知差距警告 — Loop 的隐性风险

## R — Reading (原文)

> "理解在loop越快的交付你没有亲手写的代码,亲手看的代码,仓库里的东西和你脑子里真正搞懂东西差距就越大。另一个更加扎心的事实是最危险的姿态是舒舒服服的接受loop吐出来的一切,这是非常危险的。在AI生成的内容中,越多我们不了解的内容,对于我们来讲风险就越大。"
> — 小木头 (视频3)

> "无人盯着的loop,也是无人盯着的在犯错。所以验证这个事情,永远还是在你自己手上。"
> — 小木头 (视频3)

## I — Interpretation (自述)

**核心洞察: 自动化程度与理解深度负相关。**

Loop 交付速度越快 → 你没亲手写/看的代码越多 → 仓库里有的东西和你真正搞懂的东西之间的差距越大 → 风险越高。

**最危险的态度**: 舒舒服服地接受 Loop 输出的一切,不加审视。

**关键原则**: 验证永远在你自己手上。即使 loop 有自我验证环节,人仍需定期审查。

## A1 — Past Application (书中案例)

**案例1: Ralph Loop 失败 (视频3)**
- 一个出了名的循环: 锲而不舍,永不放弃
- 失败模式: 无人盯着的 loop 持续犯错,把小修复变成灾难
- 教训: 没有人类监督的 loop 会制造"理解鸿沟"

**案例2: Boris 的代码库 (视频2)**
- Loop 产出的代码占仓库很大比例
- Boris 强调"代码库必须对 agent 可读" — 但可读 ≠ 人理解
- 隐含风险: agent 能改代码 ≠ 团队能理解为什么这么改

## A2 — Future Trigger (未来触发)

1. **产出理解不过来时**: "仓库里有很多代码但我看不懂"
2. **Loop 产出质量不确定时**: "它说做完了,但我不确定对不对"
3. **团队 AI 使用风险警示时**: 向团队传达"自动化≠理解"
4. **设计 Loop 监督机制时**: 在哪些环节加入人类审查?

**语言信号**: "AI 生成的代码我看不懂"、"产出太多理解不过来"、"AI 使用风险"、"无人盯着的 loop"

**与相邻 skill 的区别**:
- `loop-worthiness-test`: 判断要不要做 loop (本 skill 是运行后的风险管理)
- `maker-checker`: 用 AI 审查 AI 的质量 (本 skill 是人类理解层面的风险)
- `three-stage-evolution`: 阶段定位 (本 skill 是 Stage 3 的特定风险)

## E — Execution (可执行步骤)

### Step 1: 评估认知差距
定期问自己:
- 这个 loop 产出的东西,我能解释给新人听吗?
- 如果 loop 出错,我能快速定位问题吗?
- 仓库里有多少代码/内容是我没亲手看过的?

### Step 2: 设置人类审查节点
- **定期审查**: 每周/每月审查 loop 产出样本
- **关键节点审查**: 在 loop 重大变更、新任务类型、或异常指标时触发人工审查
- **理解度检查**: 随机抽取 loop 产出,尝试用自己的话解释其逻辑

### Step 3: 缓解策略
- **文档化**: 要求 loop 在产出时附带"设计说明"
- **渐进式自动化**: 从 `loop-build-path` 的 Step 1 开始,确保每步都理解后再升级
- **团队 review**: 定期让团队成员互相审查 loop 产出

## B — Boundary (边界)

**不要使用这个 skill 的场景**:

1. **产出完全可客观验证**: 测试 100% 通过 → 认知差距风险低
2. **纯技术调试**: "这个 loop 报错" — 不是认知风险
3. **非 AI 场景**: 这个模型只适用于 AI 生成内容

**作者的盲点与局限**:
- "理解越深越好"是隐含假设,但有些场景 (如 CI/CD) 不需要人理解每一行
- 作者没有给出"理解到什么程度就够了"的标准
- 警告了风险但没有量化 — "差距多大算危险?"没有答案

**与之相邻但容易混淆的方法论**:
- **Technical Debt**: "代码质量负债"; 本 skill 是"理解程度负债"
- **Bus Factor**: "只有一个人会"; 本 skill 是"没人理解"