AST+LLM补全类型注解：我踩了哪些坑

看到这个帖子真是深有同感，我上个月刚折腾完类似的事情，用的也是AST+LLM的方案，踩的坑简直一摸一样。

你提到LLM过度自信这点，我太有共鸣了。我用的是CodeLlama本地部署，补全Django ORM查询的时候，它把QuerySet类型推断成list，还不带泛型参数，跑起来直接报类型错误。后来我加了typeguard做运行时校验才发现，LLM喜欢猜简单的类型，遇到复杂泛型或者自定义类型直接摆烂。

不过你遇到的Flask视图函数那个例子，我倒是摸索出一个办法。可以在AST分析阶段先提取函数参数的上文引用，比如request参数如果被调用了.get()或者.json属性，就把这些调用模式作为上下文喂给LLM。我试过把函数体里对该参数的所有方法调用和属性访问都提取出来，做成一个“使用模式”的prompt片段，准确率提升了不少。另外，对于泛型容器类，我后来干脆让LLM只推断基础类型，像Union、Optional这类组合类型我单独写了个规则层去处理，虽然代码丑了点，但至少不会瞎猜了。

还有个坑我觉得值得提，就是老代码里那些动态导入和条件类型。AST根本看不出来一个变量运行时到底是什么类型，这种情况我目前的做法是直接跳过，或者打上Any标注，等后续手动review。毕竟补全类型注解的目的是提高可维护性，如果为了追求100%覆盖而引入错误类型，反而适得其反。

你们项目有没有考虑过结合mypy的静态分析结果来做二次校验？我觉得这是个方向，但实现起来好像挺麻烦的。

看到你这个帖子，我忍不住想认真聊几句。我在AI辅助代码分析和Python类型系统这块折腾了差不多三年，从最早用规则引擎硬写，到后来尝试各种LLM方案，再到现在搞了一套混合架构，中间踩过的坑和你想的很多地方重合，也有一些不同的视角。

先说你提到的那个Flask视图函数例子，request参数被LLM推断成str。这个问题我太熟了。实际上，LLM对框架特性和约定俗成的模式理解很差。Flask里request是全局的thread-local对象，根本不是参数传进来的，但很多老代码为了方便测试或者显式注入，会把它写成参数。LLM看到参数名是request，上下文里又有字符串操作，就自动往str上靠。我用GPT-4跑过一个Django项目，它把HttpRequest对象推断成Dict，因为代码里确实有request.POST.get这种像字典的调用。更离谱的是有一次，它把ORM查询集的返回值全部推断成List[Dict]，完全忽略了QuerySet特有的惰性求值和链式调用特性。

这里有个深层问题：AST分析只能看到函数签名和局部变量类型，看不到外部框架注入、装饰器修改、元类魔法这些运行时行为。而LLM虽然见过大量代码，但它对“某个具体框架的某个版本的某个API返回什么类型”这种细粒度知识，其实是一团浆糊。它更擅长根据变量名和常见代码模式做表面匹配。所以你让它补全类型注解，本质上是在做一个概率性的模式补全，而不是真正的类型推导。

我自己的实践中，最头疼的是装饰器场景。你问的第二个问题，AST如何追踪装饰器包装后的原始签名。我的做法是分三层：第一层，用Python的inspect模块配合signature对象，在运行时直接扒原始函数的__wrapped__属性。但很多第三方库的装饰器不遵守这个约定，比如Flask的路由装饰器、Django的login_required，它们返回的是一个新的包装函数，原始签名完全丢失。第二层，我写了一个AST模式匹配器，专门识别常见的装饰器模式。比如检测到@login_required这种已知的装饰器，就跳过它直接分析下一层的def节点。但这需要维护一个装饰器白名单，并且遇到自定义装饰器就失效。第三层，我后来改用typeguard库的运行时检测配合动态插桩，在函数被实际调用时收集参数和返回值的真实类型，然后反向推断。这个方法准是准，但侵入性强，而且只能覆盖测试路径覆盖到的代码。

说到LLM过度自信的问题，我深有同感。你提到Union[int, None]和Optional[int]的区别，这还算好的。我遇到过一个更隐蔽的坑：LLM把Callable[[int], str]推断成Callable[..., str]，因为它看到函数体里用了args和*kwargs。实际上这个函数接受一个int参数返回str，但内部实现用了可变参数来做兼容。LLM没有能力区分“这个函数签名是故意模糊的”还是“实现细节暴露了错误的信息”。结果生成注解之后，mypy检查原本能通过的代码反而报错，因为类型约束变宽松了，导致下游调用处的类型检查失效。

另一个我踩过的坑是泛型。Python的泛型在类型注解里其实很弱，但LLM经常生成一些花哨但无效的写法。比如它会给一个列表生成器函数补上Generator[int, None, None]这种签名，但实际函数用yield from返回，类型完全对不上。更常见的是TypeVar的使用，LLM会凭空生成一些没有约束的TypeVar，导致类型检查时出现“类型变量未绑定”的警告。我后来不得不加了一个后处理步骤，把所有TypeVar都检查一遍，如果没有在函数参数或返回值里出现超过一次，就替换成Any。

你说到“混合引擎”的方向，我非常认同，而且我觉得具体实现上可以更激进一些。我现在在做的方案是：第一步，用基于控制流图的静态分析，跑一遍完整的类型推断。这个用pytype或者pyright的底层库可以做到，能覆盖大约70%的简单情况，比如局部变量赋值、基本类型转换、常见内置函数。第二步，对于静态分析无法确定的点，比如第三方库的返回值、动态属性访问、复杂的回调函数，用LLM来做候选类型生成。但这里不是让LLM直接输出最终类型，而是让它输出多个候选，每个候选附带一个置信度分数和一个简短理由。第三步，用一个规则引擎做冲突检测和优先级排序。比如如果LLM说某个参数可能是str或bytes，但静态分析发现它被传给了json.dumps，那优先选str。如果LLM说返回值是Optional[str]，但函数体里所有return语句都返回None，那就直接覆盖为None。

这个方案目前跑下来，准确率从纯LLM方案的65%提升到了82%，但代价是速度慢了大概3倍。对于大型项目，一个文件可能要分析几十秒。不过我觉得这个方向是对的，因为类型注解这件事本质上是一个“精确需求”，不允许模糊。LLM的幻觉在这个场景里是致命缺陷，必须用确定性方法兜底。

另外我还有一个观察：很多人在做这类工具时，过度关注“补全注解”本身，忽略了“验证注解是否正确”这个环节。我现在的流程里，LLM生成注解之后，不会直接写进代码，而是先插入一个特殊的注释标记，比如# type: inferred by AI，然后运行mypy --strict模式检查所有新注解。如果mypy报错，就把错误信息和对应的代码片段重新喂给LLM，让它做修正。这样形成一个闭环，虽然慢，但质量可控。你提到mypy检查反而更糟的情况，我遇到过不少。最典型的是LLM给一个函数返回值加了Optional，但函数里所有路径都返回非空值，mypy就会报“返回值类型过于宽泛”的警告。这种错误LLM自己很难发现，因为它只看函数签名不看实现细节。

最后聊一下行业视野。你觉得未来是混合引擎，我其实更悲观一些。我觉得纯粹靠LLM来做类型注解补全，天花板很低，因为类型系统本质上是一个形式逻辑系统，而LLM是概率模型。你看那些真正在生产里跑得好的工具，比如Pyright的自动补全、PyCharm的类型推断，核心都是基于类型推导算法的，LLM只是辅助。所以我更看好“静态分析为主，LLM只在边界情况下提供灵感”的模式。而且随着Python 3.12+里类型系统越来越完善，比如TypeVar的PEP 695语法、类型参数化泛型类，静态分析能覆盖的范围会越来越大，LLM的用武之地反而会缩小。

不过话说回来，你这个帖子提到的几个问题，确实是目前这个领域最真实的痛点。尤其是装饰器和动态类型，这两个坑我到现在也没完全填平。如果你找到了更好的解法，欢迎交流。我现在正在尝试用符号执行来追踪装饰器链，但复杂度太高，还在实验阶段。

这个坑踩得太真实了。AST+LLM补全注解的思路本身没毛病，但实际跑起来确实一堆脏活。你说LLM过度自信这点我深有体会，尤其是Union[int, str]这种歧义场景，它经常给你拍板定一个最宽泛的类型，完全不考虑业务语义。我试过用few-shot加类型约束提示词，稍微好点，但还是治标不治本。

我这边遇到更头疼的是装饰器工厂和元类场景。AST解析出来的函数签名跟实际运行时类型完全两码事，比如带@login_required的视图函数，LLM死活认不出request其实是经过中间件包装后的自定义Request子类。后来我折中了一下，先让AST把函数定义、参数名、docstring和调用链上下游的类型引用抽出来，拼成结构化的上下文喂给模型，而不是直接扔原始代码块。这样准确率能从六成提到八成左右，但泛型嵌套和TypeVar绑定还是翻车重灾区。

另外你提到Flask视图函数的request参数被推断成str，这个我怀疑是模型被常见框架的文档污染了——很多教程里写request.json、request.args，模型容易把request当成字典或字符串处理。我试过在prompt里显式声明“这是Flask的werkzeug Request对象”，效果显著。不过这也暴露了另一个问题：LLM对框架内部类型体系的认知其实很脆弱，一旦脱离常见模式就瞎猜。

说到底，这活儿还是得靠人机协作。我现在的做法是让LLM给每个推断的类型打一个置信度分数，低于0.7的自动标记为待人工审核，然后配合mypy的静态检查结果做二次过滤。虽然还是得花时间人工修，但至少不用从头手写所有注解了。你们有没有试过结合类型推断工具（比如pyright的离线分析结果）来给LLM做前置约束？我觉得这条路可能比纯靠模型瞎猜更靠谱。

这个帖子看得我很有共鸣，正好最近也在折腾类似的东西。想问下你提到的本地小模型具体是哪种？我试过用CodeLlama做这个事，但泛型推断基本全崩，感觉光靠AST上下文信息量还是不太够。另外那个Flask视图函数的例子太真实了，有没有试过加一些类型约束或者few-shot提示来减少这种错误？我这边试了效果不明显。

这个坑我太熟了。之前给一个Django项目补类型注解，也是AST+GPT-4的组合，结果它把QuerySet类型全猜成了list，导致mypy检查直接炸了。后来我加了一层规则，如果函数返回值是ORM查询链，强制让模型输出Optional[QuerySet[Any]]，效果稍微好点，但还是有误判。

你提到Union[int, str]这种截断的情况，我怀疑是token限制的问题。本地小模型上下文窗口小，遇到复杂的泛型或者嵌套类型，它倾向于输出一个看似合理但实际简化的结果。我试过把函数调用链和变量赋值的历史引用也塞进prompt，让模型有更多上下文，但代价是推理时间翻倍，而且token消耗太大，对本地模型不太友好。

另一个我踩过的坑是装饰器。AST解析的时候，装饰器内部的函数签名往往被忽略，比如Flask的@app.route，里面包裹的视图函数参数类型被LLM当成了普通的str。我后来专门写了个预处理步骤，把装饰器展开成原始函数定义再喂给模型，虽然增加了复杂度，但准确率提升明显。

你用的本地小模型是多大参数的？我试过7B的，效果不太行，后来换成了基于CodeLlama微调的13B版本，至少对常见类型推断靠谱多了。不过泛型这块还是得靠规则兜底，比如用stub文件或者已有的类型注释做后验校验，不然生产环境跑起来心里没底。

这个坑我太有同感了，特别是LLM对动态类型的“自信”真的让人头大。我之前试过用CodeLlama本地跑，结果它把**kwargs直接猜成Dict[str, str]，实际项目里传进来的value可能有int有list，跑起来直接崩。

你提到AST只能静态分析这点，我后来想了另一个思路：结合运行时类型采集。比如先给测试用例跑一遍，用sys.setprofile或者第三方库像pyre-extensions的inspect_type，把实际运行时的类型签名dump下来，再拿这些真实样本去微调LLM。虽然工程量大点，但至少能避免那种“表面合理实则离谱”的幻觉，比如Flask的request参数，动态跑一次就知道是flask.Request了。

还有个细节想跟你讨论：泛型推导。像List[User]

这种，如果项目里User类在另一个模块，AST只看到函数签名是def get_users() -> list，LLM大概率猜成List[Any]。我后来是先把项目所有类的继承关系做成一个图，再跟AST的引用链做匹配，效果稍微好点，但遇到第三方库的泛型（比如Pydantic的BaseModel子类）还是容易翻车。

另外你提到Union[int, ...]被截断了，是不是在预处理时token数超限了？我遇到类似情况会把长类型拆成多行提示，或者用函数摘要代替完整上下文，虽然牺牲点精度但至少不截断。

说实话，这活想做到生产级靠谱，感觉还是得AST+运行时+LLM三管齐下，单靠哪一环都有硬伤。你最近有试过把类型检查器（比如mypy或pyright）的报错反馈给LLM做二次修正吗？我正准备试试这个闭环。

这个坑踩得太真实了，尤其是“过度自信”这点我深有体会。我之前试过用GPT-3.5给一个Django项目补类型，它能把QuerySet推断成list，还把ForeignKey字段的类型直接写成int，实际应该是关联模型的类型。关键是它给出来的代码看起来特别正规，要不是CI报错我都没发现。

不过我觉得你提到的AST+本地小模型路线其实挺有潜力的，主要问题在于怎么约束LLM的“幻觉”。我后来尝试了一个折中方案：先让AST把函数体内所有变量赋值、函数调用、参数传递的路径画出来，然后只把那些路径上明确能推导出类型的子集喂给LLM，让它只负责填写缺失的部分，而不是让它自由发挥。这样准确率能拉到七八成，剩下的手工改也不算太累。

另外Flask视图那个坑我也遇到过，关键问题在于request的类型其实取决于上下文——如果用了类型标注的蓝图或者自定义中间件，它的类型就变了。我现在的做法是在项目里先定义好一组通用的类型别名，比如从flask.typing里导入，然后让AST扫描时优先匹配这些已知类型，再交给LLM去填充那些真正的“盲区”。这样LLM就算猜错，也不会跑偏得太离谱。

对了，你本地小模型用的什么方案？我试过CodeLlama和DeepSeek-Coder，感觉后者对Python类型系统的理解稍微好一点，但对Union和Optional的处理还是一团糟，经常把Optional[str]写成Union[str, None]但格式搞错。有没有什么技巧能调教一下？

看到这个帖子，我其实挺有共鸣的。我大概从去年年中开始也在做类似的事情，不过方向稍微偏一点——我们团队在给一个存量大概30万行Python的金融风控系统补类型注解，目标是让mypy能跑到strict模式。走完这一圈下来，我想说，楼主的观察非常准，尤其是“过度自信”和“装饰器陷阱”这两个点，但我觉得其中有一些细节值得展开，也有一些我实际踩过的坑和摸索出来的方案可以分享。

先说说AST+LLM这个组合本身。楼主说AST只能静态分析，遇到动态类型或复杂泛型时AI容易瞎猜，这确实是大实话。我举个具体例子：我们系统里有一段处理消息队列的代码，函数签名大概是def process_event(event, context):，event参数实际上是一个来自RabbitMQ的字节流，经过内部一个自定义的deserialize函数处理后，会变成Union[TradeEvent, RiskAlert, Heartbeat]这种联合类型。AST扫描只能看到event是个参数名，根本不知道它的下游类型。我们一开始也试过让GPT-4直接补全，它给出的结果是event: str，因为它看到后面有event.decode('utf-8')这样的调用。但实际上，decode是在字节流阶段做的，真正的业务逻辑里event已经被反序列化成对象了。这种“伪上下文”导致的错误推断，我后来统计了一下，在复杂业务代码里占比可能超过30%。

不过，楼主提到的“先用AST收集函数调用链做静态分析，再让AI做二次验证”这个思路，我觉得可以再往前推一步。我实际尝试过的一种做法是：不依赖LLM直接生成类型，而是让LLM生成“类型约束”。具体来说，我们会先用AST提取出每个函数内部的所有变量赋值、函数调用、属性访问和return语句，然后把这些信息做成一个结构化的“证据列表”。比如对于上面那个process_event函数，证据列表里会有一条“event被传入deserialize函数，deserialize的返回类型已知为Union[TradeEvent, RiskAlert, Heartbeat]”，再有一条“event被传入process_trade_event函数，该函数接受TradeEvent类型”，等等。然后我们把这些证据喂给LLM，让它不是直接输出类型，而是输出一个“类型假设集”——比如“我认为event可能是Union[TradeEvent, RiskAlert]”，并附上每条假设的置信度。这样做的目的，是把LLM从“生成者”变成“提议者”，而最终的决策权交给一个基于mypy的静态验证器。如果LLM给出的假设能通过mypy的检查，且不引入新的错误，就采纳；否则就降级为Any并打上TODO标签。这个流程跑下来，我们最终在30万行代码上实现了大约75%的自动补全率，而手动审查的误报率控制在5%以下。

当然，这个方案也有代价。最大的代价是证据提取本身很复杂。比如遇到装饰器，楼主问怎么让AST正确追踪原始签名，这恰恰是我花了最长时间解决的问题。Python的装饰器本质上是一个语法糖，在AST层面，你看到的只是一个Call节点，包裹着被装饰的函数定义。比如一个典型的Flask路由装饰器@app.route('/test')，在AST里，它会把下面的函数定义整体包在一个decorator_list里。如果你只解析函数定义的节点，你拿到的signature是原始函数的参数，但实际运行时，装饰器可能已经替换了函数对象。更坑的是，有些装饰器会使用functools.wraps来保留原始签名，有些不会。我的做法是写了一个专门的“装饰器解析器”，它不是靠AST，而是靠模拟Python的符号解析过程。具体来说，我们维护了一个“装饰器效果表”，里面记录了常见装饰器（比如functools.lru_cache, flask.route, django.db.transaction.atomic, 以及我们自己团队内部几十个自定义装饰器）会如何修改函数的签名和返回类型。对于未知装饰器，我们会在运行时通过inspect.signature去捕获实际签名，然后反向构建一个“装饰器签名映射”。这个映射会被缓存下来，后续在AST分析阶段，如果遇到已知装饰器，就直接用映射结果替换原始签名；如果是未知装饰器，我们就保守地认为签名不变，但会打一个“待验证”标记留给人工审查。

说到mypy检查反而更糟的情况，这个问题我深有体会。我们团队初期用LLM批量补全了一轮，结果mypy strict模式下的错误数从800多个直接飙升到3000多个。原因倒不是LLM全错了，而是它补全的类型和代码里已有的类型注释产生了冲突。比如一个函数原来有# type: ignore注释，LLM补全了类型后，mypy不再忽略这个函数，于是之前被掩盖的错误全部暴露了出来。更隐蔽的问题是，LLM经常补全出一些“看似合理但实际不兼容”的类型。举个例子，一个函数返回了None，但在某些分支下返回了整数列表[1,2,3]。LLM看到return None，就推断返回类型是None，忽略了其他分支。结果mypy一跑，报错说“返回类型不兼容”。这种问题在if-else分支较多的函数里非常常见。我的教训是：补全类型注解之前，一定要先对代码做一次“类型一致性分析”。具体做法是，用ast模块遍历所有return语句，统计每个函数实际return了哪些类型的值，然后取它们的“最小公共超类型”。比如一个函数既返回None，又返回list[int]，那最小公共超类型就是Optional[list[int]]。这个信息可以作为LLM补全时的“硬约束”，告诉LLM：“这个函数的返回类型必须是Optional[list[int]]或者它的子类型，不能是None或者list[int]单独一个”。这样一来，LLM的幻觉空间就被大大压缩了。

再补充一个很多人可能没注意到的坑：泛型类型的处理。LLM对于像List[int]和list[int]这样的新旧风格差异倒是能处理好，但遇到更复杂的泛型，比如一个函数参数是Callable[[int, str], bool]，LLM经常给出错误的参数顺序或返回类型。我们有一次遇到一个高阶函数，它接受一个回调函数作为参数，这个回调函数本身又接受一个函数作为参数。AST分析只能看到参数名是callback，LLM根据上下文推断出callback: Callable[[int], str]，但实际上callback应该是Callable[[Callable[[int], str]], bool]。这种嵌套泛型，LLM几乎不可能靠上下文猜对。我们的方案是：对这种高阶函数，不依赖LLM，而是走全静态分析。具体做法是，扫描所有调用这个高阶函数的地方，收集传入的回调函数的实际签名，然后取这些签名的“泛型模式”。比如如果所有调用点传入的回调都是Callable[[int], str]类型，那我们就推断参数类型就是Callable[[int], str]；如果调用点传入的回调类型不一致，我们就用TypeVar来表达泛型关系。这个工作极其繁琐，但效果很好，因为它是基于实际用法的，而不是基于LLM的猜测。

最后说说我对“混合引擎”这个提法的看法。我非常赞同楼主说的“静态分析兜底+LLM补充复杂场景”这个方向，但我认为这个混合并不是简单的“先用静态分析，再让LLM补全”。我设想的架构是分层的：第一层是全量静态分析，包括类型推断（基于PEP 484的type inference算法，比如Pyre或Pyright内部用的那种）、控制流分析、数据流分析，这一层能覆盖大概60%-70%的场景，尤其是那些类型明确、没有动态特性的代码。第二层是“模式匹配引擎”，针对常见的动态场景（比如装饰器、动态属性访问、args/*kwargs、类型变量）预置了一套规则。这一层能再覆盖20%左右。剩下的10%-15%才是LLM的战场，主要针对那些需要跨文件、跨模块理解，或者涉及业务领域语义的场景。而且LLM的输出不能直接落地，必须经过第三层的“类型一致性验证器”过滤。这个验证器本质上是一个轻量级的mypy，它会检查LLM输出的类型是否与已有的代码逻辑一致，如果不一致，就降级为Any并记录原因。我们团队目前就在搭建这样一个三层的管道，虽然还很早期，但初步效果已经比单纯用LLM好很多——在10万行代码的测试集上，补全率从50%提升到了80%，而mypy通过率从30%提升到了85%。

当然，这个方案也有明显的天花板。对于完全动态的代码（比如大量使用eval、exec、getattr/setattr、动态类创建），任何自动化工具都很难处理，因为类型信息在编译时根本不存在。这种代码，我认为最务实的做法是：先通过重构改成静态可分析的形式，再补类型注解。如果实在改不了，那就用TypedDict或者Protocol来给出一个近似的类型定义，然后手动加上# type: ignore[override]或者# type: ignore[type-arg]来压制mypy的报错。这不是妥协，而是现实——类型系统的价值在于帮助人理解代码，而不是追求100%的完美覆盖。

另外，我还想提一个容易被忽视的非技术因素：团队对类型注解的接受度。我见过一些项目，技术方案做得很好，mypy也能跑通，但开发人员就是不买账，因为觉得写类型注解降低了“灵活性”。我个人的经验是，补全类型注解最好和代码审查流程结合起来，不要一次性全量补完，而是每改动一个模块，就顺便把该模块的类型注解补全。这样既不会有“一次性污染”的风险，也能让开发者逐渐适应。对于LLM补全的结果，我建议留一个“审核窗口”——

比如补全后先跑mypy，如果mypy通过了，再让一个经验丰富的开发者快速过一遍。如果mypy没有通过，那就直接把LLM结果废弃，改为手动补全。这个流程虽然看起来增加了工作量，但实际上比“让LLM补全然后人工逐行审查”要高效得多，因为mypy可以自动过滤掉大部分错误，只剩下少数边界情况需要人工判断。

总结一下，我觉得这个领域目前最大的挑战不是技术，而是如何设计一个“人机协同”的工作流。LLM很强，但它没有代码所有权，不知道业务上下文；静态分析很可靠，但它无法处理动态语义。把两者结合起来，再加上合理的流程设计，才是真正能让Python类型注解从“体力活”变成“自动化工具”的关键。楼主提到的“未来混合引擎”方向，我非常认可，而且我认为这个混合引擎的“调度器”才是核心——什么时候该相信LLM，什么时候该回退到静态分析，什么时候该让人工介入，这些决策逻辑本身就需要大量的工程实践来打磨。希望有更多团队在这个方向上分享经验，毕竟Python的类型化之路，还远远没有走到终点。

这个过度自信的问题太真实了，我试过用Claude补类型，它能把一个简单的dict硬猜成TypedDict，连字段名都对不上。后来我换了个思路，先让AST提取函数调用链里的实际传参类型，再喂给LLM做参考，准确率能上来不少，你可以试试。另外Flask视图那块，我怀疑是LLM没见过框架源码里的类型定义，是不是得先预埋点上下文？

这个帖子看得我直拍大腿，Flask视图函数那个坑我也踩过，而且不止一次。我当时用AST跑完一个老项目，发现LLM对上下文依赖特别强的类型推断基本是瞎蒙，比如装饰器包装过的函数，它经常把内部闭包参数直接当成原函数签名来补。更离谱的是，有次它把ORM模型里的relationship字段推断成List[str]，实际上应该是List[User]这种自定义类型。

我后来试了个折中方案：先让AST提取所有函数签名，然后对每个缺失注解的参数，把它的使用模式（比如调用了哪些方法、在哪些if分支里出现）拼成一段伪代码，再丢给LLM。这样模型至少能根据实际调用方式**猜出类型，而不是纯靠函数名脑补。比如request参数，如果在函数里调了request.args.get，那大概率是Flask的Request而不是str。

不过你这帖子让我想到另一个问题：泛型怎么处理？比如List[Dict[str, int]]这种嵌套，AST只能看到List，LLM又容易把内层搞错。我试过用类型约束模板，比如先让模型输出Union[int, str]这种简单类型，再通过类型传播把上游的类型推断结果当成提示词喂回去，效果稍微好点，但遇到循环依赖还是崩。

对了，你那个本地小模型是微调过的吗？我试过用CodeLlama跑类似任务，发现它对第三方库类型完全没概念，比如传给Pandas的DataFrame参数，它经常给个通用类型。感觉这要是真想落地，还是得搞个类型字典，把常用库的类型签名提前编进去，不然真成碰运气了。