很多人看到 Claude Code，第一反应还是：这是写代码、改项目、跑命令用的。这个理解没错。但用久一点会发现，Claude Code 更像一个能读文件、改文件、跑命令的工作台。它能维护代码项目，也能用同样的方式维护一个学习项目。

学习这件事，光听解释不够。它还需要目标、资料、练习、测验、错误记录和复盘。这些东西，刚好都可以放进一个本地目录，让 Claude Code 帮忙维护。

我以前学一个新主题，很容易从攒资料开始。看几篇文章，存几个视频，再让 AI 总结一下，短时间内会觉得进展很快。但过几天再回头，常常会发现：资料还在，理解感也有过，能独立说出来、做出来、排错出来的东西并不多。

所以现在我会换一种用法。少一点随手问答案，多一点让 Claude Code 帮我维护一套学习目录。

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

前面写《Anthropic工程师：我们日常如何使用Claude Code》时，我最有感触的一点是：Claude Code 用到后面，prompt 长短反而没那么关键，需求、规格和验证要提前安排好。放到学习里也是一样。一个人学不进去，很多时候不是解释不够好。更常见的问题，是学习现场里没有目标、没有测验，也没有能回看的错误记录。

本文只想谈一个更日常的问题：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 个文件：

这 4 个文件已经够跑第一轮。这其实就是一个很小的学习 Harness。它不追求复杂，只负责把学习过程里最容易丢的东西留下来：目标、来源、测验和错误。

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

这套流程的价值，是让每一轮学习都有一点证据留下来。学习不再只剩"看过了""问过了""大概懂了"。目录里会留下更具体的东西：目标是什么，资料来自哪里，测验错在哪里，下一轮该补什么。

第一步：先写学习契约

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

请教我机器学习。

这个问题太大。Claude Code 当然能回答，但它不知道你到底要到哪一层。你是为了看懂业务里的推荐系统？为了自己训练模型？为了准备面试？还是为了判断公司里的 AI 项目靠不靠谱？目标不同，学习路径完全不一样。

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

我想学习【主题】。

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

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

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

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

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

学习失败，很多时候不是人不努力。是目标一开始就太虚。

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

AI 时代，学习资料通常不是太少，而是太多。一个主题搜下去，文章、视频、课程、路线图很快就把人淹没。资源越多，人越容易以为自己在推进。实际可能只是不断换入口。

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

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

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

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

不要超过 5 个资源。

最后一句很关键。这不是偷懒，是在控制学习环境。

如果输入全是未经筛选的教程、互相矛盾的建议和包装过度的二手内容，再强的 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 适合做学习系统的地方：它不只是聊天，还能在本地目录里读写这些规则和记录。

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

很多学习系统最后没坚持下来，不一定是方法不对，也可能是维护成本太高。我自己会把每轮学习的产物压到两样：一页学习卡，一条错误记录。学习卡负责恢复上下文，错误记录负责驱动下一轮。

可以让 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 扮演事故复盘主持人，连续追问每一个判断的证据。

跑到这一步，Claude Code 就不只是给你讲 Kubernetes。它在帮你形成排障动作。

怎么判断有没有真的学会

学习系统不能只看过程是否完整。我会给它设几个小验收。

第一，24 小时后能不能闭卷复述。先自己讲。讲不出来的地方，再让 Claude Code 追问和补漏，而不是让它重新解释一遍。

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

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

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

Claude Code 的评分只能当辅助。最后的验收，还是要回到题目、项目、官方文档和真实结果。能讲出来，只说明你理解了一部分；能换题做出来，才说明能力开始长出来。

这套方法的边界

我不想把这套方法说成"有了 Claude Code 就能学会任何东西"。这种说法太轻了。AI 学习系统有用，但边界也很清楚。

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

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

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

Bloom 当年讨论一对一辅导时，让人羡慕的不是"有人讲得更细"，而是形成性测试、反馈、纠正和再测试可以持续发生。今天 Claude Code 给了我们一个低成本入口。但入口不是终点。我们要补上的，仍然是反馈、纠错和训练。

写在最后

AI 学习稀缺的不是答案。答案已经太多了。更稀缺的是一个能持续暴露问题的环境。

Claude Code 可以帮我们搭路径、筛资料、出题、追问、压缩和复盘。但它不能替我们完成最关键的那一步：自己答一遍，自己做一遍，自己解释一遍，自己发现没懂，再回来修一遍。

所以更愿意把结论收得保守一点：用 Claude Code 学习，我最想搭的不是提示词清单；更有价值的是一套有目标、有测验、有纠错、有复盘的个人学习系统。

它不神奇，但很实用。每天多追问一道题，多记录一个错误，多压缩一页卡片。慢慢地，学习就不再只是消费答案。它会变成一轮一轮可复查的反馈。

参考资料