---
source_url: "https://mp.weixin.qq.com/s/YScRbcLfQYJWY7QLHXWp9A"
ingested: 2026-06-23
sha256: 2dc64c8c3317930f
---

# Claude Code 个人学习系统：从答案机到学习工作台

架构师（JiaGouX）
作者：若飞

很多人看到 Claude Code，第一反应还是：这是写代码、改项目、跑命令用的。

这个理解没错。

但用久一点会发现，Claude Code 更像一个能读文件、改文件、跑命令的工作台。它能维护代码项目，也能用同样的方式维护一个学习项目。

学习这件事，光听解释不够。它还需要目标、资料、练习、测验、错误记录和复盘。

这些东西，刚好都可以放进一个本地目录，让 Claude Code 帮忙维护。

我以前学一个新主题，很容易从攒资料开始。看几篇文章，存几个视频，再让 AI 总结一下，短时间内会觉得进展很快。

但过几天再回头，常常会发现：资料还在，理解感也有过，能独立说出来、做出来、排错出来的东西并不多。

所以现在我会换一种用法。

少一点随手问答案，多一点让 Claude Code 帮我维护一套学习目录。

我的体会是：

当 AI 已经很会给答案，学习的关键就变成了：能不能给自己搭一个暴露问题的系统。

这也能和我们最近梳理的 Harness、Loop、Environment 放在同一条线上看。

前面写《Anthropic工程师：我们日常如何使用Claude Code》时，我最有感触的一点是：Claude Code 用到后面，prompt 长短反而没那么关键，需求、规格和验证要提前安排好。

放到学习里也是一样。一个人学不进去，很多时候不是解释不够好。更常见的问题，是学习现场里没有目标、没有测验，也没有能回看的错误记录。

只不过这次不谈 agent，也不谈企业工作流，只谈一个更日常的问题：

AI 能秒给答案以后，我们怎么把学习过程留下来，并且让它真的产生反馈？

## 先把心态调过来

用 Claude Code 学习，我会先区分两种用法。

一种是把它当答案机。不懂就问，问完觉得懂了，过几天再问。

另一种是把它当学习工作台。它不急着给完整答案，而是帮你维护文件、追踪错误、出题检查、整理复盘。

前一种反馈快，后一种更慢。

但能留下能力的，往往是后一种。

原因也不复杂。学习不是把答案读一遍，最后还是要形成可以迁移的判断、操作和表达能力。

Anthropic 的 Claude Learning mode、OpenAI 的 Study Mode，都在往这个方向走：少一点直接给答案，多一点引导、主动参与和知识检查。

学习科学里也有类似结论。Karpicke 和 Roediger 关于检索练习的研究指出，测试不只是评估，它本身也会促进学习。Dunlosky 等人的综述也把 practice testing 和 distributed practice 放在更高优先级。

这些研究落到日常使用里，可以先记住一句话：

如果 AI 只是更快解释，它会放大"我好像懂了"的感觉。等它开始让你先答、先做、先复述，再把错误记下来，它才有点像学习系统。

## 为什么"问一下"不够

第一次用 AI 学东西，体验往往差不多。

你问 Claude："帮我解释一下 Kubernetes 的 Service。"

它很快给出一段结构清楚的回答，有定义，有类比，有 YAML，也有常见问题。

你读完觉得：这不难。

问题是，第二天让你解释 ClusterIP、NodePort、LoadBalancer 的真实差异，或者让你排一个 Service 访问不通的问题，可能还是会卡住。

这通常不是 Claude 解释得不好。

更常见的原因是：那一刻得到的是理解感，还不是能力。

能力通常要经过几步：自己说出来，自己做一题，自己解释理由，自己发现哪里只是背了词，再把知识放进真实问题里跑一遍。

这个过程不太舒服，但很多学习恰恰发生在这里。

Bastani 等人在高中数学场景里的研究也提醒了类似风险：无护栏的 GPT-4 访问可以提高练习时的表现，但当 AI 被拿走后，学生独立表现可能变差。带护栏的 AI tutor 通过提示、追问、不直接给完整答案，缓解了这种负面效果。

这个结论不用夸大，但方向很值得参考：

AI 可以提高当场完成度，不等于提高了长期学习。

所以我更倾向于把 Claude Code 调成一个带护栏的学习陪练，少让它直接当答案供应器。

## 最小可用版：4 个文件就够

一听"学习系统"，很容易把事情做重。

其实第一版不用复杂。

如果今晚就想试，我会先建一个目录，里面只放 4 个文件：

| 文件 | 用来记录什么 |
|------|-------------|
| learning-contract.md | 为什么学、学到哪、先不学什么 |
| source-ledger.md | 只放 3 到 5 个来源，写清每个来源的用途 |
| quiz-log.md | 问了什么，自己答得怎样 |
| mistake-log.md | 反复出错的地方，以及下一步怎么补 |

这 4 个文件已经够跑第一轮。

这其实就是一个很小的学习 Harness。

它不追求复杂，只负责把学习过程里最容易丢的东西留下来：目标、来源、测验和错误。

第一轮不要追求完美。30 分钟就能启动：

1. 用 5 分钟写学习契约；
2. 用 5 分钟筛 3 到 5 个资料；
3. 用 10 分钟学第一个小主题；
4. 用 5 分钟让 Claude Code 问 3 道题；
5. 用 5 分钟把答错的地方写进错误记录。

这套流程的价值，是让每一轮学习都有一点证据留下来。

这样一来，学习不再只剩"看过了""问过了""大概懂了"。目录里会留下更具体的东西：目标是什么，资料来自哪里，测验错在哪里，下一轮该补什么。

## 第一步：先写学习契约

刚开始学一个主题时，我们很容易这样问：

请教我机器学习。

这个问题太大。

Claude Code 当然能回答，但它不知道你到底要到哪一层。

你是为了看懂业务里的推荐系统？为了自己训练模型？为了准备面试？还是为了判断公司里的 AI 项目靠不靠谱？

目标不同，学习路径完全不一样。

所以我一般会先让它写学习契约。

我想学习【主题】。

请先帮我建立一份学习契约，暂时不要讲解正文内容。

请问我不超过 5 个问题，用来确认：
1. 我的当前水平；
2. 我学习这个主题的真实用途；
3. 我可以投入的时间；
4. 我更需要理解原理、完成项目、通过考试，还是解决工作问题；
5. 本轮先不学哪些内容。

问完后，请给出：
- 3 到 5 个学习阶段；
- 每个阶段的完成标准；
- 每个阶段的一项练习；
- 进入下一阶段前需要通过的自测题。

这里有用的，不是"分几阶段"这个动作本身。重点是把学习目标变成可检查对象。

比如后端工程师学 Kubernetes 排障，完成标准就不该是"看完官方文档"。更实在的标准是：能解释 Pod 为什么起不来，能定位 Service 为什么访问不通，能区分配置、网络、存储和调度问题，能写出排障命令和证据。

学习失败，很多时候不是人不努力。

是目标一开始就太虚。

这点和我们前面写 Loop Engineering 时提到的"反馈契约"很像。目标不清，后面的反馈就没有落点；反馈没有落点，循环跑得再勤也只是热闹。

## 第二步：控制资料，而不是囤资料

AI 时代，学习资料通常不是太少，而是太多。

一个主题搜下去，文章、视频、课程、路线图很快就把人淹没。资源越多，人越容易以为自己在推进。

实际可能只是不断换入口。

我会让 Claude Code 帮我筛资料，但边界要写清楚：

我要学习【主题】，目标是【真实用途】。

请帮我筛选 3 到 5 个最值得投入的学习资源。

要求：
1. 优先选择权威、可验证、适合当前水平的资源；
2. 每个资源说明适合学哪一部分；
3. 按学习顺序排序；
4. 明确哪些热门资源本轮先不看，并说明原因；
5. 基于这些资源，设计一个 7 天学习路径。

不要超过 5 个资源。

最后一句很关键。

这不是偷懒，是在控制学习环境。

前面梳理 Environment Engineering 时，有一个想法在这里也适用：环境不是越大越好，关键是能不能给出高质量反馈。

如果输入全是未经筛选的教程、互相矛盾的建议和包装过度的二手内容，再强的 AI 也只能帮你整理噪声。

学习环境要先瘦身。

资料少一点，反馈反而更清楚。

## 第三步：先让它做考官

这一步最不舒服，也最有用。

很多时候，我们希望 AI 多讲一点。但学习真正往前走，往往发生在自己被迫回答的时候。

我会把测验放得很靠前。

我刚学完【主题】里的【具体范围】。

请你扮演严格但友善的考官。

规则：
1. 一次只问 1 道题，等我回答后再继续；
2. 题目从基础到高阶逐步增加难度；
3. 每次回答后给 10 分制评分；
4. 只讲我答错、漏掉或含糊的部分；
5. 如果我回答薄弱，先追问，不急着进入下一题；
6. 结束后给出薄弱点和下一组练习。

不要一次性给出答案。

这里最重要的是：答案不能提前出现。

一旦答案提前出现，大脑很容易进入"识别答案"的状态，而不是"生成答案"的状态。

看懂答案和自己答出来，中间隔着一道很深的沟。

工程里我们不会因为系统"看起来能跑"就说它可靠。至少要有测试、日志、review 和验收。

学习也一样。

没有测验，很多"我懂了"只是界面渲染成功。

## 第四步：把 Claude Code 设成带护栏的陪练

如果每天都从零写提示词，也很累。

更稳的做法，是在学习目录里放一段长期说明。用 Claude Code 时，可以把它写进 CLAUDE.md，让每次会话都有同一套学习规则。

你是我的 AI 学习陪练。

默认规则：
1. 先给提示和追问，不直接给完整答案；
2. 每次只推进一个概念或一道题；
3. 如果我回答错误，指出具体错在哪里，再给一个更小的练习；
4. 每次学习结束，帮我更新学习契约、测验记录和错误记录；
5. 涉及事实时，标注来源层级：官方文档、论文、教材、经验判断或模型推断。

你的目标是让我更稳定地形成能力，而不是更快拿到答案。

这段指令不复杂，但会改变 Claude Code 的默认行为。

普通对话里，模型天然像客服：用户一问，它就完整回答。

学习场景里，完整回答不一定是好事。我更喜欢把默认值调成：先提示，再追问，再检查，最后才揭示答案。

这也是 Claude Code 适合做学习系统的地方：它不只是聊天，还能在本地目录里读写这些规则和记录。

## 第五步：每轮学习只留下两样东西

很多学习系统最后没坚持下来，不一定是方法不对，也可能是维护成本太高。

我自己会把每轮学习的产物压到两样：

一页学习卡。

一条错误记录。

学习卡负责恢复上下文，错误记录负责驱动下一轮。

前面写 Self-Harness 时，我们反复提到"先要学会留证据"。个人学习也是一样。没有证据，就很难知道下一轮到底该改什么。

可以让 Claude Code 这样整理：

请把【主题】整理成一页学习卡。

要求：
1. 用一句话说明它解决什么问题；
2. 列出 5 个核心概念；
3. 每个概念配一个最小例子；
4. 标出 3 个常见误区；
5. 最后给 3 道一分钟速答题。

目标是让我 5 分钟内恢复上下文，不是重新读一篇长文。

一页学习卡不追求完整。

它只解决一个问题：下次回来时，能不能用 5 分钟把脑子接回去。

错误记录也不用写成长篇复盘。够用就行：

错误：我把 Service selector 问题误判成 DNS 问题。
原因：没有先检查 endpoints。
下次动作：遇到 Service 不通，先看 selector、endpoints、pod labels，再看 DNS。

这种记录很朴素，但比"今天学了 Kubernetes 网络"有用得多。

## 用一个例子串起来

假设你是后端工程师，想用 3 周补一轮 Kubernetes 排障能力。

我不会让 Claude Code 从百科开始讲。

第一天，先写学习契约。

目标可以更具体一点：能处理常见线上排障，比如 Pod 异常、Service 不通、Ingress 配置、存储挂载、调度失败、资源限制。

第二天，筛 3 到 5 个资源。

比如官方文档、kubectl 速查、一个 kind 本地环境教程、一组常见故障案例、一份网络模型解释。

接下来每天只做一个故障复现。

Claude Code 不直接告诉你答案，只给现象、日志、命令提示，让你自己提出假设。每天结束，把答错的地方写进 mistake-log.md。

第二周，让它按错误模式重新组织练习。

比如：看现象太快下结论；忘记确认 namespace；没有先看 endpoints；把资源限制和应用错误混在一起。

第三周，做一个小项目。

搭一个故意坏掉的服务链路，从请求入口到 Pod 日志完整排一次。最后让 Claude Code 扮演事故复盘主持人，连续追问每一个判断的证据。

## 怎么判断有没有真的学会

学习系统不能只看过程是否完整。

我会给它设几个小验收。

第一，24 小时后能不能闭卷复述。

先自己讲。讲不出来的地方，再让 Claude Code 追问和补漏，而不是让它重新解释一遍。

第二，换一道题还能不能做。

如果昨天学的是 Service 访问不通，今天换成 DNS 解析异常，还能不能沿着同样的证据链排查：现象、假设、命令、证据、结论。

第三，错误会不会减少。

错误记录不是为了显得认真。它主要用来看同一类错误有没有反复出现。反复出现，就说明学习计划要降一层，不能继续往前赶。

最后，能不能落到一个小项目。

哪怕只是一个本地 kind 集群、一个坏掉的 YAML、一次完整排障记录，也比又看三篇讲解更有用。

## 这套方法的边界

我不想把这套方法说成"有了 Claude Code 就能学会任何东西"。

这种说法太轻了。

AI 学习系统有用，但边界也很清楚。

第一，AI 会把错误说得很顺。涉及法律、医学、考试标准、生产配置、论文细节时，还是要回到第一来源。

第二，AI 很容易顺着目标走。目标设错了，它会帮你更高效地走错路。

第三，AI 的反馈不等于真实反馈。Claude Code 可以发现概念漏洞，但能不能在项目里用出来，还要靠真实任务、真实约束和真实结果验证。

Bloom 当年讨论一对一辅导时，让人羡慕的不是"有人讲得更细"，而是形成性测试、反馈、纠正和再测试可以持续发生。

今天 Claude Code 给了我们一个低成本入口。

但入口不是终点。

我们要补上的，仍然是反馈、纠错和训练。

## 写在最后

我越来越觉得，AI 学习稀缺的不是答案。

答案已经太多了。

更稀缺的是一个能持续暴露问题的环境。

Claude Code 可以帮我们搭路径、筛资料、出题、追问、压缩和复盘。

但它不能替我们完成最关键的那一步：

自己答一遍。

自己做一遍。

自己解释一遍。

自己发现没懂，再回来修一遍。

所以我更愿意把结论收得保守一点：

用 Claude Code 学习，我最想搭的不是提示词清单；更有价值的是一套有目标、有测验、有纠错、有复盘的个人学习系统。

它不神奇，但很实用。

每天多追问一道题，多记录一个错误，多压缩一页卡片。

慢慢地，学习就不再只是消费答案。它会变成一轮一轮可复查的反馈。

## 参考资料

• Karpicke & Roediger: The Critical Importance of Retrieval for Learning (Science, 2008)
• Dunlosky et al.: Improving Students' Learning With Effective Learning Techniques (Psychological Science in the Public Interest, 2013)
• Bloom: The 2 Sigma Problem (Educational Researcher, 1984)
• Bastani et al.: Generative AI without guardrails can harm learning (PNAS, 2024)
• Mollick & Mollick: Assigning AI: Seven Approaches for Students, with Prompts (arXiv:2306.10052)
• Anthropic: Claude Code overview, How Claude remembers your project, Introducing Claude for Education
• OpenAI: Introducing study mode