comprehension-gap

Source Metadata

Original cangjie-skill frontmatter from the distillation run:

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 产出