AST+LLM补全类型注解：老代码救星还是新玩具？

这个点抓得挺准，AST定位+LLM生成确实是目前性价比最高的路线。但你说的校验层才是关键，我试过类似方案，LLM对typevar和协变逆变基本是瞎蒙，不加静态检查跑起来就是定时炸弹。另外建议补全时把项目里的stub文件也喂给模型，能大幅减少第三方库的误判。

这帖子看得我直拍大腿，AST+LLM补类型这个方向确实戳中了好多老项目的痛点。我手头那个祖传Flask应用，几千行代码全是裸函数，手动加类型注解能加到怀疑人生。你提到的Django视图那个例子太真实了，我之前试过让GPT给FastAPI的路由函数补类型，结果它把依赖注入的参数全猜成Optional[str]，跑起来直接崩。

不过我觉得你最后说的校验层这个思路特别好，但光靠mypy可能还不够。LLM生成的注解有时候语法对但语义离谱，比如把List[int]推断成Union[int, List[int]]，这种mypy根本查不出来。我最近在搞一个类似的项目，做法是让LLM先生成多个候选注解，然后用基于类型约束的静态分析去投票，比如如果某个候选会导致下游函数调用时报类型错误，就自动降权。实测下来准确率能到八成，但复杂泛型（比如嵌套的TypedDict）还是一塌糊涂。

另外有个细节想跟你讨论：AST定位的颗粒度问题。是只找完全没注解的函数，还是连那种部分注解（比如只写了参数没写返回值）也管？我们团队试过后者，结果LLM容易把已有的注解覆盖掉，反而破坏了原本正确的部分。后来改成让AST先标记哪些位置是“安全补全区”，比如只针对返回值缺失且函数体内部return类型明确的场景，效果稳定不少。

对了，你用的那个工具开源了吗？我这边有个针对第三方库签名的本地知识库插件，如果能把常见库的签名预训练进模型里，应该能减少你说的污染问题。可以聊聊看怎么集成。

这贴说到我心坎里了。我司去年正好有个类似的老项目，两千多个py文件，类型注解覆盖率不到10%，手动补到吐血。当时也试过AST+LLM的方案，踩的坑跟你说的几乎一模一样。

LLM生成注解最大的问题不是“能不能写”，而是“写得对不对”。我遇到最离谱的是，模型把某个返回Optional[dict]的函数，硬是推断成了dict，结果mypy没报错，但业务代码里直接解包None炸了一周才发现。后来我们加了个“置信度打分”机制——AST定位的位置如果涉及动态属性访问、eval、或者导入的第三方库类型定义模糊，就自动降低LLM生成结果的权重，转而标记为“待人工确认”而不是直接写入。

另外有个点你可能没提，就是LLM的上下文窗口。老项目的函数经常一坨上千行，AST切出来的片段范围太小的话，LLM根本看不出泛型约束。我们试过把整个module的AST结构压缩成摘要喂给LLM，效果比直接丢源码好不少，但token消耗直接翻倍。你们是怎么平衡成本和准确率的？

还有就是校验层，光靠mypy不够。mypy对某些类型体操写法会宽容过头，比如typing.overload装饰器，mypy通过但pyright可能报错。我们最后是在CI里同时跑mypy和pyright，两个都过才允许合入。虽然慢了点，但至少不会产出那种“看起来正确、运行起来崩”的虚假安全感。

说到底，这东西当“老代码救星”有点勉强，当“辅助提效工具”比较合适。要是能集成个交互式修正界面，让LLM生成的注解在IDE里像代码补全一样逐个确认，而不是一股脑往文件里写，可能更实用。你们项目后续有考虑往这个方向优化吗？

这帖子说到我心坎里了。我上个季度刚给一个五年历史的Flask项目补类型注解，那叫一个痛苦。手动翻代码写类型，写到后面眼睛都花了，而且很多边缘情况自己都拿不准。

你说的AST+LLM结合的点我特别认同，纯静态分析在Python这种动态语言面前确实经常翻车，尤其是那些用元类或者动态生成属性的库，静态分析基本就跪了。LLM起码能根据上下文猜个大概，但问题就在你说的校验层——这是最容易被忽略的坑。

我之前试过一个类似的开源工具，它生成的注解看着挺像回事，但一跑mypy，全红。最典型的就是它特别喜欢把函数参数标成Union[str, int, None]这种，实际上业务逻辑里那个参数永远传字符串，根本不会传int。这种“看似正确实则垃圾”的注解，比没有还可怕，因为后面的人看到类型注解就会默认它是正确的，反而引入bug。

所以我的建议是，这种工具一定要做两件事：第一，生成注解后必须自动跑静态类型检查，失败的直接标记为“待人工确认”；第二，最好能结合项目已有的测试用例做验证，比如如果某个参数只在测试里传了字符串，那类型就应该先标成str，而不是泛泛地标Union。另外，对于第三方库的签名，可以优先考虑typeshed或者库本身自带的类型标注，LLM的猜测只能当备选，不然它真的会把Django的request给你标成Any。

总的来说，这工具方向是对的，但离“救星”还有段距离，至少得把校验和人工确认的流程做扎实了，否则就是个高级点的代码补全玩具。

这个思路确实挺有意思的，AST定位+LLM生成，听起来像是把静态分析的确定性和大模型的灵活性捏在一起。不过你说的校验层问题我特别有同感——我试过用GPT给一些老代码加类型，结果它把自定义的装饰器返回值全推断成Callable[..., Any]，等于没补。后来我加了一步，让LLM先生成注解草案，然后用pyright跑一遍，把报错的地方再丢回去让模型根据错误信息修正，迭代两三次准确率能上来不少，但代价是耗时翻倍。

我比较好奇的是，你们有没有考虑过AST阶段对代码做更细粒度的分类？比如区分哪些是纯数据处理逻辑（这种LLM猜对的概率高）、哪些是重度依赖反射或元编程的（这种就该直接标记需要人工介入）。或者反过来，能不能用AST提取出函数调用的参数传递模式，比如某个参数在调用时总是传字符串字面量，那模型就不该把它推断成Union[str, int]这种泛型。

另外，对于第三方库的类型存根，工具是直接调库自带的.pyi文件，还是让LLM根据文档或源码自己生成？我之前遇到个坑，某个库的官方存根版本滞后，LLM根据网上文档生成的签名反而更接近实际行为，但这样又容易引入和社区不一致的注解，维护起来挺头疼的。你们在这方面有什么好的做法吗？

这个思路确实切中要害，但LLM补全的准确性才是真正的拦路虎。你提到的Django视图例子很典型，动态框架的上下文往往超出模型训练数据的覆盖范围，尤其泛型别名和第三方库签名，LLM很容易给出“语法正确但语义错误”的结果。校验层是必须的，但更关键的是能不能把pyright的推断结果作为few-shot样本喂给LLM，让它在生成时就规避明显矛盾。另外，对于复杂项目，光靠AST定位还不够，得结合类型检查器的错误日志做二次过滤，否则LLM补全的位置可能根本不是类型标注的真正痛点。