CodeGeeX 通过运行时上下文与参数演化趋势识别 Python 递归死循环，要求文件为已保存的 .py 文件、光标位于函数声明前空行、自然语言描述含明确约束（如“非负整数”），并需手动触发分析。
VSCode 插件能帮你写递归函数，但不能替你思考终止条件——它只放大你已有的逻辑漏洞，不掩盖它们。
CodeGeeX 在 Python 里识别递归死循环的触发方式
它不是靠静态扫描函数名就下结论，而是结合运行时上下文和参数演化趋势做判断。比如你写了 factorial(n - 1)，但它发现调用前没校验 n > 0，且函数签名允许传入负数，就会标红该行并提示“参数可能进入负向无限递归”。
- 必须把光标停在递归函数体内部（哪怕只是某一行空格），再按
Ctrl+Enter，否则插件不激活分析逻辑 - 语言模式必须是
Python，不是Plain Text或JSON；左下角状态栏错一个字符都不行 - 指令要具体：“检查基线条件是否覆盖所有分支”比“分析这个函数”有效得多——模糊提示会让模型跳过关键路径比对
用右键模板生成安全递归函数的三个硬性前提
VSCode 右键菜单里的 “Generate recursive function” 类功能（如 CodeGeeX 的模板补全）默认带防护，但只在满足条件时才生效：
- 当前文件后缀是
.py，且已保存（未保存的临时文件不触发语言服务器） - 光标位于类定义外、函数声明前的空行，否则模板会错误嵌套进已有结构
- 输入的自然语言描述含明确约束，例如“写一个非负整数阶乘函数”，若只说“写阶乘”，它可能忽略
if n 校验
递归深度报错 RecursionError: maximum recursion depth exceeded 的真实诱因
这个错误常被误认为是“递归层数太多”，其实 80% 情况下是逻辑错误导致的隐式无限递归——插件不会直接报这个错，但能提前暴露根因：
-
n == 0写成n ，而递归调用传入 <code>-1→ 参数未收缩，分支漏判 - 递归调用写成
func(n)而非func(n - 1)→ 参数恒定，永远达不到基线 - 多分支中某个 else 分支遗漏 return，实际执行到函数末尾隐式返回
None，上层用这个值继续递归 → 类型错配引发不可预测跳转
真正危险的不是报错，而是不报错：参数缓慢漂移、分支条件互相抵消、或依赖外部状态变化——这些插件目前无法建模，得靠你手动加 print(n) 或断点验证每层参数走向。
