适用场景：AI 生成代码比例高、个人项目做完后、你想保持"代码品味"不退化
总耗时：30 分钟｜可重复执行｜跨项目通用

为什么需要这件事

AI 能在 5 分钟内生成 500 行代码。这种生产力放大有一个隐性代价：理解债（Understanding Debt）。每一行你没有读过的代码都是一笔欠账，会在三种情况下被强制偿还：

1. 需要扩展 / 修改 — 你得重新读代码，但已经没有当时的上下文
2. 出 bug — 从零开始调试，而 AI 的记忆也已经不在了
3. 有人问"这是怎么工作的" — 答不上来就是能力证据的损耗

如果不做任何回顾，长期后果是代码品味的缓慢退化 — 你能让 AI 生成代码，但失去了评估它的能力。当有一天你连"这段 AI 代码写得好不好"都判断不了，协作上限就封死了。

这份清单的目的不是"为了读代码而读代码"，而是用最小的时间投入（30 分钟）防止这种退化，同时把项目中有价值的模式沉淀为个人知识。

---

执行清单

阶段 1 — 准备（2 分钟）

• 一句话写下项目目的（强迫自己澄清最终交付物）
• 列出开发中遇到的 bug / 摩擦点（即测试摩擦地图）
• 打开代码根目录和 AI 对话窗口

阶段 2 — 获取代码地图（4 分钟）

向 AI 提问（可直接复制）：

简要列出这个项目每个文件的职责（一句话/文件），以及文件之间的调用关系。不要展开细节。

• 浏览返回的地图
• 标注：哪些文件职责和我印象一致？哪些是我完全不知道在干啥？

阶段 3 — 对抗式提问（5 分钟）

依次问 AI 以下三个问题（一次一个，不要打包问，不同问题会激活不同视角）：

1. “这份代码里最可能藏 bug 的是哪几处？为什么？”
2. “代码做了哪些假设没有被验证？如果这些假设不成立会怎样？”
3. “如果一个新人接手并需要改这份代码，他会在哪里卡住？”

• 记录 AI 指出的脆弱点列表
• 保持怀疑但也别忽略 —— AI 会错过一部分，但也会指出你没想到的

阶段 4 — 选读目标（2 分钟）

画交集：

AI 脆弱点 ∩ 我的测试摩擦        → 必读（最高 ROI）
AI 说复杂、但我开发时没遇到问题  → 选读（看时间）
我想沉淀为知识的新技术/模式       → 选读
AI 说不重要                      → 抽 1 个校准

• 圈出 3-5 个精读目标

阶段 5 — 精读（10-12 分钟）

对每个精读目标：

• 读代码：理解"在做什么" + “为什么这样做”
• 读不懂的地方问 AI：“这段为什么不用 X 方式？这样写的权衡是什么？”
• 记一句话感悟（这段最值得带走的是什么）

阶段 6 — 校准抽查（3 分钟）

• 从 AI 标为"不重要"的文件随机挑 1 个
• 快速扫 2 分钟
• 判断：它真的不重要吗？ AI 分类能力这次靠谱吗？

抽查无事 → 下次可以更信任 AI 的推荐
抽查有坑 → 下次降低 AI 分类权重

这一步是校准环节，很多人会省掉，但它是长期复利最关键的一步。

阶段 7 — 复盘（2 分钟）

用 bullet 写，不超过 8 行：

• 学到了什么可迁移的模式 / 技术？
• 这次 AI 在哪里表现好？哪里翻车？
• 下次类似项目我会做什么不同？

---

清单背后的三个关键原理

1. AI 自评存在固有偏差

让 AI 挑"值得读的部分"，本质是让写代码的同一个智能评估自己的输出。三个典型偏差：

• AI 倾向高亮"教科书式巧妙"的部分（算法、数据结构），漏掉"粘合处的坑"（边界条件、错误处理、并发细节） —— 后者才是大多数 bug 的来源
• AI 不会主动识别自己的错误 —— 如果能识别早就改了
• 循环偏差：AI 的"品味"和它写代码的倾向是同一套，等于让学生给自己打分

对抗方法：用挑错视角的提问代替"请总结"式提问（见阶段 3）。

2. 你的测试摩擦比 AI 自评更可靠

每个 bug 都是代码脆弱性的高强度信号。开发过程中被坑过的地方 > AI 自认为重要的地方。

3. 校准是长期复利

单次抽查 3 分钟看起来低效，但它决定了你对 AI 分类能力的信任权重校准。一年后你对 AI 推荐的依赖程度，取决于你是否做过这些校准。

---

使用提示

• 时间超了就砍精读，不要砍校准抽查（阶段 6 是长期复利项）
• 每次都写阶段 7，哪怕一句话 —— 它是你"AI 协作能力"的成长记录
• 复用这份清单就是把它置顶，项目结束就跟着走，不用思考流程本身
• 跨团队分享时，鼓励成员记录自己的"测试摩擦地图" —— 这是组织级的隐性知识

---

适用 / 不适用

适用场景	不太适用的场景
个人项目 / 小团队项目	超大型代码库（需要更长的分层阅读）
AI 生成比例 ≥ 50%	传统模式下人写为主
一次性或探索性项目	已有严格 code review 流程的团队项目
涉及不熟悉的领域 / 技术栈	纯粹重复你熟知模式的项目