Claude Code 帮助初学者理解递归算法的代码示例

去年秋天，我花了整整两周时间，每天对着屏幕上的递归函数发呆。我盯着那几行代码反复看，感觉自己理解了，函数调用自身嘛，有什么难的。但一合上教程，让我独立写一个遍历文件目录的递归函数，大脑瞬间空白。那种挫败感至今记忆犹新：明明每个字都认识，连起来就是转不过弯。

直到我开始用 Claude Code 对话式地学习递归，情况才发生根本性转变。不是因为它生成了更漂亮的代码，而是它让我看到了代码执行过程中每一步发生了什么。这篇文章记录的就是那两周里，我如何通过不断追问 Claude Code，最终打通递归这条任督二脉的真实过程。如果你也正在经历那种“看得懂但写不出”的困境，这里的每一个示例和提示词，你都可以直接复制到自己的 Claude Code 里跑一遍。

核心结论：Claude Code 真正颠覆的地方，不是帮你生成递归代码，市面上的 AI 编程工具都能干这个。它的独特价值在于，你可以像一个带着满脑子疑问的学生那样，不断追问“这一步参数是什么”“返回值传给了谁”“调用栈现在长什么样”，它会用文本把那个隐形的执行过程画出来给你看。 传统教程只能给你静态的代码和注释，但 Claude Code 可以让你和代码的每一步执行对话。这就是理解递归的秘密通道。

一、我为什么说递归的难点不是语法，而是“看不见”

绝大多数递归教程上来就告诉你：递归就是一个函数调用自身，它由终止条件和递归表达式组成。然后就丢给你一个阶乘函数，让你跑一跑。

但问题是，当计算机执行递归时，它的内部状态，调用栈、参数变化、返回值传递路径，全部对你不可见。你看到的是几行静态代码，计算机在做的是几十上百次动态调用。你试图用阅读静态代码的方式理解一个动态过程，这本身就是认知错配。

我认识一个转行学编程的朋友，他把斐波那契递归函数的代码背得滚瓜烂熟，但问他“当 n=5 时，fib(3) 总共被调用几次”，他答不上来。这不是他不努力，而是他用的所有学习材料都在讲“代码怎么写”，没有一个在讲“代码怎么跑”。

我第一次真正“看见”递归执行，不是某个可视化工具的动画效果，而是在 Claude Code 里输入了这段话：

> “帮我写一个计算阶乘的递归函数，但我不只是要代码，我要你在代码里加 print 语句，让它每次调用时都打印出当前深度、参数 n 的值，以及返回时的返回值。然后运行 n=4，把完整输出给我。”

Claude Code 生成了这个函数并给出了执行输出：

调用 factorial(4)，当前调用栈深度: 1
  调用 factorial(3)，当前调用栈深度: 2
    调用 factorial(2)，当前调用栈深度: 3
      调用 factorial(1)，当前调用栈深度: 4
        到达终止条件: n=1, 返回 1
      factorial(2) 收到返回值 1, 计算 2*1=2, 返回 2
    factorial(3) 收到返回值 2, 计算 3*2=6, 返回 6
  factorial(4) 收到返回值 6, 计算 4*6=24, 返回 24
24

看到这个输出时，我脑子里那个一直卡住的地方突然松动了。缩进代表调用深度，从外向内一层层挖下去，挖到最深处再一层层把结果传回来。这不是一个概念解释，这是执行过程的文字可视化。而且最关键的是，这段代码和输出是我通过一句自然语言对话生成的，不是我复制粘贴的，整个过程有一种“我让它做给我看”的掌控感。

这就是 Claude Code 在递归学习中的核心价值：它不是给你答案，而是让你能向代码执行过程提问。 你不需要安装任何调试器，不需要配置断点，只需要用日常语言描述你想看到什么，它就能让代码自己把内部状态暴露出来。

二、初学者对递归的三大死胡同，以及我是怎么用 Claude Code 走出来的

在我自己踩过的坑和观察身边初学者的过程中，我发现大家卡住的地方高度集中。不是递归定义看不懂，也不是代码语法有问题，而是三个更底层的东西没打通。

死胡同1：把递归当成一个函数在反复执行，而不是一堆函数排队等待

最经典的困惑：“函数调用自己，那它不就一直在执行自己吗？为什么不会死循环？”

这个困惑的根源在于，初学者把递归想象成一个人反复做同一件事。但实际上递归更准确的画面是：将军下令给团长，团长下令给营长，营长下令给连长，每个人都在等下一级完成任务后回来汇报。 不是一个将军反复下命令，而是一个命令链条，每层都有一个等待者。

我在 Claude Code 里做了这样一个实验：

> “用 Python 写一个递归函数 countdown(n)，从 n 开始倒数到 1，每次调用在进入时打印 ‘开始 countdown({n})’，在返回前打印 ‘结束 countdown({n})’。运行 n=3，让我看看输出的时间顺序。”

结果是这样的：

开始 countdown(3)
开始 countdown(2)
开始 countdown(1)
结束 countdown(1)
结束 countdown(2)
结束 countdown(3)

“结束”是从最内层往外层依次出现的。这直观地说明了一个事实：countdown(3) 这个函数并没有消失，它在等 countdown(2) 返回；countdown(2) 也没有消失，它在等 countdown(1) 返回。 每个递归调用都在内存里占着一个位置，直到它完成使命。

这个理解一旦建立，后面学调用栈、栈溢出、尾递归优化时，就有了一个扎实的具象基础。

死胡同2：搞不清楚“参数传进去的是什么”和“返回值传回来的是什么”

很多初学者在递归里看到 return 语句就蒙了：这个 return 是返回给谁的？是返回给最外层调用吗？

不是。递归中的 return，绝大多数时候是返回给上一层调用自己的那个函数。 你是在一层层往外传递结果，直到最外层拿到最终答案。

我用 Claude Code 生成了一个带标注的版本，让这个路径显式化：

> “改写刚才的阶乘函数，让每层 return 时明确打印 ‘第X层将结果Y返回给第X-1层’。”

输出让我彻底看清了返回值在层级间的流动路径。没有任何魔法，就是一层给一层，老老实实传递。

死胡同3：被“先递进再回溯”搞得晕头转向，不知道什么时候执行哪段代码

很多递归函数在递归调用之前有一段代码，在递归调用之后还有一段代码。这两段代码的执行时机完全不同：前者在“挖下去”的阶段执行，后者在“爬回来”的阶段执行。

这个特性在遍历文件目录、生成树状结构时大量出现。如果你不理解这个先后顺序，你写出的代码要么缩进有问题，要么打印顺序全乱。

我在 Claude Code 里做了一个最直观的演示：

> “写一个递归函数 print_tree(path, level=0)，遍历文件夹，要求函数先打印当前文件夹名，再递归进入子文件夹。每进入一层，缩进增加 2 个空格。帮我用一段模拟的文件结构运行，并显示输出。”

输出是这样的：

root/
  src/
    main.py
    utils.py
  docs/
    readme.md

缩进正确地反映了层级深度。奥秘就在于：打印文件夹名的代码在递归调用之前执行，所以先打印再深入；而子树结构能自动对齐，是因为递归调用本身会带着 level+1 下去。

这三个死胡同，没有一个能通过“看参考答案”解决。你必须看到执行过程、参数流动、调用顺序。而 Claude Code 的价值，就是把这些隐性过程变成了可以对话的显性信息。

三、我在 Claude Code 里实操过的三个递归案例，附完整提示词和我的真实解读

以下三个案例按学习顺序排列，不是我随意选的，而是我真实学递归时一步步过渡过来的路径。每个案例我都保留了当时在 Claude Code 里输入的提示词，这样你可以直接复制到自己的环境里重现一模一样的输出。

案例一：阶乘，用最简单的结构看清“递”和“归”

这是所有教程的第一个例子，但多数教程只是给了代码加一行注释。我在 Claude Code 里的做法完全不同：我要的不是代码，是执行过程的逐帧回放。

我输入的第一个提示词：

> “帮我写一个 Python 递归函数计算 5 的阶乘。要求：

> 1. 函数名叫 factorial_trace

> 2. 每次进入函数时打印：→ 进入: n = {n}, 当前id = {id(n)}（id用来区分不同层级的调用实例）

> 3. 每次即将返回时打印：← 返回: n = {n}, 返回值 = {result}

> 4. 在最外层调用后，帮我逐行解释发生了什么

> 5. 最后，用一段话总结‘为什么这个函数不会无限调用下去’”

Claude Code 生成的结果含完整的打印和解释。我第一次知道了 Python 的 id() 函数可以拿来区分不同调用层的实例，虽然变量名都叫 n，但每层的 n 实际上存在不同的内存位置。这个认知彻底打破了我“递归就是同一个变量反复改”的错误直觉。

我自己的解读： 终止条件 if n == 1 是递归的刹车。每次调用时 n 的值在变小（5→4→3→2→1），最终踩下刹车，然后结果从内往外层层累乘返回。最关键的心智模型是：不是把一个任务拆成多个独立任务，而是把一个任务延迟到更小的子任务完成之后。

案例二：斐波那契，用计数器暴露递归的性能陷阱

学完阶乘的时候我心里挺得意，觉得递归不过如此。然后我遇到了斐波那契，那种得意碎了一地。

我没有一上来就纠结公式，而是直接在 Claude Code 里这样问：

> “帮我写一个递归函数 fib(n) 计算第 n 个斐波那契数。但请你在函数内部用一个全局计数器，每次函数被调用时计数器 +1。当 n=5、n=10、n=20 时，分别告诉我 fib 函数被调用了多少次。我怀疑有大量重复计算，请帮我验证。”

结果让我倒吸一口凉气：

计算第 20 个数，函数被调用了两万多次。这是因为 fib(5) 可能会在计算 fib(7) 时被调用，在计算 fib(6) 时又被调用一次，完全没有缓存。

我接着追问 Claude Code：

> “既然有这么多重复计算，能不能帮我写一个优化版本，用字典缓存已经算过的结果？然后同样用计数器对比一下调用次数。”

Claude Code 立刻给出了记忆化递归（memoization）版本，并在代码注释中解释：如果某个 n 的结果已经在缓存字典里，直接返回，不再递归。新的调用次数对比：

从两万多次降到 39 次。这个案例教会我的不只是一个优化技巧，而是一个重要判断：递归代码简洁不等于高效。 如果你只用简洁当标准选递归，可能会在数据量稍大时一脚踩进性能坑里。Claude Code 帮我完成了这个“发现问题→诊断根因→提供方案→量化验证”的完整闭环。

案例三：文件夹遍历，递归在真实场景中是什么样子

前两个例子都是数学函数，我学完之后仍然有一个不安：真实开发中，谁会天天算阶乘？递归到底用在哪？

答案藏在操作系统的文件目录里。文件目录天然是树形结构：一个文件夹包含文件和子文件夹，子文件夹又可以包含文件和子子文件夹。用递归处理这种结构，代码极为自然。

我在 Claude Code 里输入：

> “我想用 Python 写一个脚本，递归遍历指定文件夹，打印所有文件和子文件夹的完整层级。要求：

> 1. 文件夹名后面加 /

> 2. 每一层缩进用 4 个空格

> 3. 不要直接用 os.walk，必须自己写递归

> 4. 写完之后，帮我解释为什么递归特别适合处理文件目录这个问题。”

Claude Code 生成的核心逻辑让我印象深刻：对于每个文件夹，先列出所有内容，如果是文件就打印，如果是文件夹就递归调用自己。整个函数不超过 15 行，却能把任意深度的目录结构完整呈现。

我自己的解读： 这个场景让我真正理解了“问题规模不断缩小”的含义。遍历一个大文件夹，等价于先处理当前层的内容，然后把每个子文件夹交给递归去处理。子文件夹处理完之后，当前文件夹的任务自然就完成了。你不需要事先知道目录有多深，也不需要写循环套循环，递归自动帮你搞定任意深度。

四、我让 Claude Code 自己讲自己写的递归，它怎么当“递归家教”

讲到这里，你可能会觉得：这不就是用 AI 生成代码然后加一堆 print 吗，别的 AI 也能做。

我一开始也这么想。直到我尝试了一种完全不同的用法：让 Claude Code 扮演一个递归讲解者，解释它自己刚写的代码。

具体操作是这样的。我会先让它生成一段递归代码，然后切换角色，用第二段提示词让它逐帧解释执行流程。不写新代码，只解释。

第一轮对话：解释“发生了什么”

> “现在请你不要改代码，也不要写新代码。就刚才那个 factorial_trace 函数，假设调用 factorial_trace(4)，请用纯文字的方式，按照时间顺序，描述每一步发生了什么。包括：

> – 什么时候创建了一个新的函数调用

> – 哪一层的代码在执行

> – 什么时候一个调用结束、把控制权交还给上一层

> – 每一层的返回值是怎么计算的”

Claude Code 给出了一段近乎叙事的文字：

“最外层调用 factorial_trace(4)。它执行到 return 4 * factorial_trace(3) 时，必须暂停自己，先问 factorial_trace(3) 要结果。于是创建 factorial_trace(3)，它同样在等 factorial_trace(2)……直到 factorial_trace(1) 直接返回 1。这时 factorial_trace(2) 醒来，用 2*1=2 返回给 factorial_trace(3)，factorial_trace(3) 用 3*2=6 返回给 factorial_trace(4)，factorial_trace(4) 用 4*6=24 返回给外部调用者。”

这段描述给了我一个全新的理解角度：递归不是一堆函数“同时存在”，而是一个“创建-暂停-等待-唤醒-销毁”的循环。 每一层的函数都有一段时间处于“冻结”状态，它们并没有消失，只是睡着了等结果。

第二轮对话：画一张“调用栈图”

理解了时间顺序后，我又想看到空间布局，调 用栈是什么样子的。因为调用栈这个概念对学递归至关重要，但几乎所有教程都在跳过它。

我的提示词：

> “能不能用纯文字的方式，给我画一张 factorial_trace(4) 的调用栈图解？不用 ASCII 画图，就用缩进和箭头表示。每一层标注：参数 n 的值、当前等待谁的结果、该层在内存中的大致位置（用地址来区分即可）。从调用开始到逐层返回，分阶段展示。”

Claude Code 用纯文本给了我三个阶段：

阶段一：全部展开时

[栈顶] factorial_trace(1): n=1, 终止条件触发, 准备返回
       factorial_trace(2): n=2, 等待 factorial_trace(1) 返回
       factorial_trace(3): n=3, 等待 factorial_trace(2) 返回
[栈底] factorial_trace(4): n=4, 等待 factorial_trace(3) 返回

阶段二：返回进行中

factorial_trace(1) 已返回 1, 被销毁
[栈顶] factorial_trace(2): 收到 1, 计算 2*1=2, 准备返回
       factorial_trace(3): n=3, 等待 factorial_trace(2) 返回
[栈底] factorial_trace(4): n=4, 等待 factorial_trace(3) 返回

这个“栈顶先返回、栈底最后返回”的特性，我之前从来没有在教程里看到过如此清晰的文字描述。多数教程只会说“后进先出”，但不会给你动态的栈帧销毁过程。

第三轮对话：故意问一个“错误理解”，让它纠正我

这是最有价值的一轮。我故意用一个错误理解去问 Claude Code：

> “我理解递归就是 factorial_trace(4) 里面嵌套了 factorial_trace(3)，factorial_trace(3) 里面嵌套了 factorial_trace(2)，就像一个套娃一样。这样理解对吗？”

Claude Code 的回复指出了这个比喻的关键缺陷：

“套娃的比喻在‘一层包一层’这个层面上是对的，但有一个重要区别：套娃是静态存在的，你打开最外层娃娃时，里面的娃娃早就做好了。但递归是动态生成的，factorial_trace(3) 并不是预先存在的，它是 factorial_trace(4) 在执行过程中临时创建出来的。更准确的比喻是：你不是在拆套娃，你在现场造套娃，造一个，塞进去，再造一个，直到最小那个造出来了，然后一个个拆开往外传。”

这个纠正太重要了。因为我发现自己之前对递归的误解，根源就是这个“静态嵌套”的心智模型。套娃的类比让我忽略了函数是动态创建和销毁的，也让我忽略了每一层都有独立的参数和返回地址。

这三轮对话加起来不超过 20 分钟，但带给我的理解深度超过我之前两周自学。 秘密在于：Claude Code 不只是输出正确内容，它还能对错误理解进行针对性纠正。传统教程不知道你哪理解错了；Claude Code 可以在对话中定位你的盲区。

五、用一个“故意出错”的实验看 Claude Code 怎么定位递归 bug

学到这，我产生了一个想法：如果我故意写一个错误的递归函数，Claude Code 能帮我找到问题在哪吗？

这很重要，因为现实中初学者最崩溃的时刻，不是看不懂正确代码，而是自己写的代码错了，怎么都找不到错在哪。逐行比对参考答案是一种办法，但效率极低。

实验1：忘记终止条件

我让 Claude Code 写了这样一个函数，并直接问它问题在哪：

> “以下是一个计算阶乘的递归函数，但运行时会报 RecursionError。你能帮我定位问题吗？

>

>

> def bad_factorial(n):

> return n * bad_factorial(n – 1)

>

>

> 不要直接改代码，先帮我分析一下为什么报错，执行路径是怎样的，在哪一步出了问题。”

Claude Code 的回复结构清晰：

1. 先指出缺少终止条件，函数没有判断“什么时候该停”。
2. 然后模拟执行路径：bad_factorial(5) 调用 bad_factorial(4)，一直往下到 bad_factorial(0)、bad_factorial(-1)……永无止境。
3. 解释 Python 的递归深度限制（默认约 1000 层），超过就抛出 RecursionError。
4. 最后解释为什么需要终止条件：它告诉递归“别继续挖了，到底了”。

我补充追问了一句：

> “如果我一定要写终止条件，应该加在哪里？加在 return 前面，还是函数开头？为什么？”

Claude Code 的回答让我彻底理解了终止条件的结构位置：必须放在递归调用之前，而且要写成独立判断分支，而不是嵌在某个计算表达式里。 因为终止条件的第一要务是阻止递归调用发生，所以必须最先被检查。

实验2：正确加了终止条件，但参数没变

我又试了一个更隐蔽的错误，这个错误我自己第一次写递归时犯过，当时 debug 了快一个小时。

> “这个函数运行没有报错，但结果一直是 None。帮我找原因：

>

>

> def sum_to_n(n):

> if n == 1:

> return 1

> n + sum_to_n(n – 1)

>

Claude Code 一眼指出：递归调用前缺少 return 关键字。 函数执行了递归调用，但递归的返回值没有被传递出去。加了一行 return 就修好了。

这个错误极其隐蔽，因为它不报错，代码看起来也很合理。如果你不理解“递归的返回值必须一层层 return 回去”，你可能根本想不到问题在这里。

六、递归和循环到底什么时候用哪个，Claude Code 帮我做的决算

学到这，递归我已经基本通了。但一个新问题冒出来了：既然递归有栈溢出风险和重复计算问题，为什么还要用它？什么时候用循环就够了，什么时候必须上递归？

这个问题如果只抽象讨论，永远不会有答案。我选择让 Claude Code 帮我做具体对比。

对比实验：同一个任务，两个版本

我的提示词：

> “请写两个 Python 函数，分别用递归和循环实现‘反转一个字符串’。然后基于以下维度帮我对比：

> 1. 代码行数和可读性

> 2. 时间复杂度

> 3. 空间复杂度

> 4. 当字符串长度为 2000 时，递归版本会有什么风险？

> 5. 最后给我一个明确的建议：字符串反转选哪个？”

结果：

结论很明确：对于线性问题（每次只处理一个元素），循环更安全、更高效。 递归的用武之地不在这里。

对比实验2：树形结构，递归的真正主场

> “再帮我写两个函数，分别用递归和非递归方式实现‘计算二叉树的深度’。非递归版本可以用栈模拟。然后同样维度对比，再给我建议。”

这次结果反过来了：

结论：递归擅长的不是简单重复，而是“分支结构”。 当问题天然包含分叉（树有左右子树、目录有多个子文件夹、排列组合有多种选择路径），递归几乎是唯一简洁的表达方式。用循环硬写也能做，但代码会成为一大坨难以维护的状态管理。

七、给你一套可以直接上手操作的学习流程

以下不是我瞎编的步骤清单，而是我回顾自己整个学习过程，提炼出的最有效路径。每一步都附带可以直接在 Claude Code 中使用的提示词模板。

第一步：建立可视化认知（预计 15 分钟）

目标： 不是学公式，而是亲眼看到递归的执行过程。

提示词模板：

> “帮我写一个递归函数 ____（如：阶乘），要求：

> 1. 每次进入函数时打印当前参数值和使用缩进表示深度的进入标记

> 2. 每次返回前打印返回值和使用缩进表示深度的返回标记

> 3. 运行时选择一个小规模输入（如 n=4）

> 4. 完成后，用纯文字描述整个执行过程的时间线”

你重点关注： 缩进最深的那一层就是递归的底部；底部返回后，上面一层才依次“醒来”。

第二步：用计数器暴露重复计算（预计 10 分钟）

目标： 理解递归的性能特性，建立“递归不一定高效”的警觉。

提示词模板：

> “在刚才的递归函数里加一个全局计数器，每次函数被调用时 +1。分别测试 n=5、10、15 时的调用次数，用一个表格展示 n vs 调用次数。如果有重复计算，解释为什么，并给出优化方案。”

你重点关注： 调用次数的增长速度。如果是 O(2^n) 级别的增长，它就是递归的性能陷阱，必须学会识别。

第三步：覆盖不同递归模式（预计 30 分钟）

不要只学一种递归。我建议至少覆盖以下三种模式：

提示词模板（以结构递归为例）：

> “帮我写一个递归函数遍历文件夹。先给我代码，再有层级缩进地展示模拟输出，最后解释为什么这个场景用递归比用循环更自然。”

你重点关注： 不同模式下，递归调用的数量和控制流的复杂程度。

第四步：故意犯错，让 Claude Code 诊断（预计 15 分钟）

目标： 建立调试能力，不再怕递归报错。

操作方式： 自己先在 Claude Code 生成的正确代码上做一个小改动（比如删掉 return、改反终止条件判断），然后把它当做一个“不知道错在哪的代码”丢给 Claude Code 诊断。

提示词模板：

> “我写了这个递归函数，但运行结果不对/报错了。请帮我定位问题，先不要改代码，先解释执行路径，看看在哪一步出了什么问题。”

你重点关注： Claude Code 是怎么定位问题的，它通常会从终止条件开始检查，然后追踪参数变化，最后看 return 语句。这个检查流程本身就是你应该学会的 debug 套路。

第五步：自己写，让 Claude Code 评审（预计 20 分钟）

目标： 彻底摆脱“看得懂写不出”的局面。

操作方式： 给 Claude Code 出一个你用递归解决的问题描述，不看它生成的代码，自己先写。写完再让它帮你检查：有没有边界问题？终止条件会不会被跳过？栈深度够不够？

提示词模板：

> “给我一个适合用递归解决的问题描述，但不要给代码。我自己写完之后，你帮我评审。”

你重点关注： 在评审环节，Claude Code 给你的反馈里一定有你没想到的细节，那就是你还薄弱的地方。

八、我对 Claude Code 辅助学递归这件事的诚实评价

用到今天，我对 Claude Code 在递归学习上的角色有了一个相对成熟的认识。它既不是我最初以为的万能老师，也不是某些人说的华而不实的玩具。

它真正做得好的地方

第一，对话式执行追踪。递归学习最痛苦的就是看不见过程，而 Claude Code 可以通过你描述的“想看什么”，把过程展现在你面前。你可以问“参数怎么变的”“调用栈长啥样”“这个值是从哪返回给谁的”，这些问题传统教程回答不了，但是 Claude Code 可以。

第二，错误诊断的精准度。初学者写递归最常见的五个错误（缺终止条件、终止条件永假、参数不收敛、漏 return、递归深度过大），Claude Code 几乎可以秒定位。搜索引擎做不到这一点，因为你可能连怎么描述自己的错误都不知道。

第三，多语言一致性。我在 Python 里学的递归原理，让 Claude Code 帮我翻译成 JavaScript 版本后，核心结构完全一致。这说明它帮你建立的是跨语言的通用认知，不是某个特定语法的记忆。

它不能替代的东西

第一，你不能不思考。Claude Code 讲得再清楚，如果你自己不闭着眼睛在脑子里把调用栈跑一遍，你还是写不出来。它是一种辅助理解的工具，不是替代思考的捷径。

第二，算法直觉的培养。什么问题是递归形问题、终止条件怎么设、参数怎么递推，这些属于“题感”，必须靠大量练习积累。Claude Code 可以带你透视一个案例，但不能替你积累一百个案例的直觉。

第三，真实项目中的上下文判断。学习示例的递归都很干净，但真实项目里可能有十几种边界情况要处理。哪些该用递归，哪些必须改循环，哪些要加缓存，这些判断需要你对自己项目的性能要求和数据规模有把握。

我的最终建议

如果你正在学递归，不要再用“看代码 + 读注释 + 背执行结果”的老办法了。打开 Claude Code，用对话的方式学。 你不只是在看一个输出结果，你是在和一个能解释执行过程的系统对话。这种交互密度，是任何图文教程或视频课程都无法提供的。

也正因为这个体验，我后来把很多难理解的技术概念都用同样的方法学了一遍。递归只是一个开始。当你发现所有的“抽象概念”都可以通过不断追问 Claude Code 变成看得见的过程时，你会发现学习编程这件事，门槛比想象中低很多。

学递归那两周，我最大的收获不是一个算法技巧，而是一个认知转变：理解一个概念的最好方法，不是反复阅读它的定义，而是对它执行的每一步进行追问。 Claude Code 恰好给了你一个可以无限追问的执行过程解释器。这篇文章里用到的每一个提示词，你现在就可以打开 Claude Code 试一遍。如果你在练习时遇到什么奇怪的递归问题，把它丢给 Claude Code，让它帮你一步步拆，你会发现，曾经让你头疼的递归，其实就那么回事。