DeepSeek模型不支持真正递归，因无运行时栈，所有“递归”仅为prompt中文本模式展开，易致截断、重复嵌套或质量骤降；应改用迭代描述、结构化输出与显式终止指令协同控制。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 模型里递归调用为什么会爆栈？
不是代码写错了，是 DeepSeek（尤其 deepseek-coder-33b 这类大模型）本身不支持真正的递归执行——它没有运行时栈，所有“递归”都是 prompt 里模拟的文本展开。你看到的 RecursionError 或无限生成，其实是模型在反复续写“函数调用→函数调用→…”这个模式，直到达到上下文长度上限或 token 截断。
常见错误现象：output 突然截断、生成内容重复嵌套（如“调用 func() → 调用 func() → 调用 func()…”）、响应变慢且输出质量骤降。
- 别在 prompt 里写“请用递归实现斐波那契”，模型会硬着头皮展开，30 层就超
max_new_tokens=2048 - 避免让模型“自己决定递归深度”，它没终止条件判断能力，只认 pattern
- 如果必须模拟递归逻辑，显式给出最大层数和 base case 文本模板，比如：“当 n ≤ 2 时直接返回 1；否则展开至第 5 层，每层标注 step=1/2/3…”
怎么把递归逻辑改成 DeepSeek 友好写法？
核心思路：用迭代描述替代递归结构，把“调用栈”变成“步骤列表”。模型对线性流程、带编号的步骤、状态快照的理解远强于嵌套调用。
使用场景：代码生成、算法解释、调试日志模拟、树遍历描述等。
- 把
fib(n)改成 “计算 fib(1) 到 fib(n) 的表格，逐行填写：fib(1)=1, fib(2)=1, fib(3)=fib(1)+fib(2)=2…” - 树遍历不用写“先递归左子树，再访问根”，改写为：“步骤1：从 root 开始；步骤2：若左子节点存在，加入待处理队列；步骤3：取出队首节点并记录值…”
- 注意参数差异：
recursive=True这类 flag 在 DeepSeek 的 prompt 工程中无效，模型不解析参数语义，只看上下文示例
为什么加 stop_words=["return", "end", "base case"] 不管用？
DeepSeek 的 stop words 是 token 级匹配，而 return 在生成中常作为变量名、字符串字面量或注释出现，提前触发截断。更糟的是，模型可能刚写到“if n == 0: return 0”就被拦住，根本没机会展开逻辑。
性能影响：过度依赖 stop words 会导致生成不稳定，同一 prompt 多次调用结果差异大。
- 慎用单个词 stop，优先用短语，比如
stop_words=["\n\nStep 6:", "Reached max depth"] - 兼容性差：不同版本 DeepSeek（如 coder-6.7b vs 33b）对 stop tokens 的敏感度不同，33b 更容易误触发
- 真正可控的方式是结构化输出：要求模型严格按 JSON 格式返回每一步，用
{"step": 1, "state": {...}}包裹，然后靠 parser 截断，而非靠 stop word
真实项目里最容易被忽略的点
不是“怎么写递归”，而是“谁在控制终止”。DeepSeek 没有运行时控制流，所有终止都得由你通过 prompt 结构、输出格式、后处理逻辑三方协同完成。
比如生成一个 DFS 路径，你以为加了 if len(path) > 10: break 就安全——但模型根本不会执行这行，它只是照抄模板。真正起作用的是你在 prompt 里写的：“最多生成 10 个节点，第 10 个后必须写‘STOP’并结束输出”。
复杂点在于：这个 STOP 必须和模型训练数据里的常见终止 pattern 对齐（比如它见过很多 “END OF OUTPUT”），而不是你自己发明一个 ### HALT ### —— 后者大概率被忽略。
