devgo.cn2026 年的 Python 类型标注调查给出三组互相打架的数据：85.5% 的人经常写类型，三年几乎没动；同时用两个以上检查器的人从 46.0% 涨到 49.9%；而「AI 帮我处理类型」的比例从 18.5% 跳到 38.4%。结论很清楚——类型标注这场仗早就打完了，现在吵的是工具链，以及 AI 该站在哪一边。
一、使用率停在原地，工具链在洗牌
三年数据摆在一起看，类型标注的普及率是 88.0%（2024）、85.9%（2025）、85.5%（2026）。每年答题的人不同，比例却稳定得像同一批人在反复点头。
变化全部发生在「用哪个检查器」上。2026 年有 49.9% 的受访者同时选了两个及以上检查器，比 2025 年的 46.0% 高了近四个百分点。选检查器的首要理由不是准确率，是速度——56.5% 的人把性能排在第一位。
有位受访者 2024 年说的话现在看像预言：「想要一个更快的 Mypy。它慢，导致生态分裂，别的检查器又不支持 Mypy 插件，行为还不一样。」两年后，Pyrefly、Pyright 这些后来者正是踩着这道缝长起来的。
这解释了一种很现实的团队配置：本地用 Pyright，因为只有它认得自家代码里的冷门写法；CI 跑 Pyrefly，只把 Pyrefly 报错的文件再交给 Pyright 复核。不是为了更正确，是为了让流水线别卡在等待上。
- 700 个选 Mypy 的人里，297 个同时装了它的编辑器插件，314 个另外配了别的检查器集成
- 264 个选 Pyrefly 的人里，220 个（83.3%）同时还在用别的检查器
二、真正的痛点不在语法，在别人的库里
被问「最大的困难是什么」，65.1% 的人选了「第三方库缺少类型信息」，远高于「类型系统表达不了我的代码」（44.6%）。
受访者点名的库很集中：Django、SQLAlchemy、Pydantic、NumPy、pandas、Polars。有人直接吐槽 Django 的黑魔法多到「能跑起类型检查本身就是奇迹」。
这里有个容易忽略的分层：低频用户抱怨的是「类型系统太复杂、太啰嗦」，比例 41.6%，高频用户只有 14.5%；而高频用户抱怨「库没类型」的比例是 70.0%，低频用户只有 36.2%。同一份问卷，两种人看到的是两个世界。
- 新手要的是少配置就能跑出第一次结果，错误信息能点开看例子
- 老手要的是 stub 覆盖率和框架语义，最好精确到 ORM 查询的返回类型
- 库作者要的是写一次注解，别让下游每个使用者自己补
Meta 的 Pyrefly 团队已经在和 Quansight 一起补 pandas-stubs 和 NumPy 的类型。这条路很慢，但它是唯一能同时降低两类人痛苦的路。
另外，被选为「最想要的缺失特性」第一名的是更好的 Callable 语法，45.7%。不是新范式，就是把现有写法变顺——这个信号值得标准库和 PEP 作者注意。
三、AI 已经挤进类型工作流，姿势有点野
2025 年只有 18.5% 的人认为「类型能让 AI 生成的代码更准确」，2026 年这个数字是 38.4%，翻了一倍多。
行为上的变化更直接：1517 位受访者里，42.5% 让 AI 工具替自己写类型标注；32.6% 为了让 AI 生成的代码更靠谱而补类型；61.0% 至少用过一种「AI 加上类型」的组合。
但最值得警惕的是反向流动。24.4% 的人说，检查器是 AI 编码工具替他们跑的；而这 370 人里有 61.6% 还会让 AI 去修检查器报的错，其余人群只有 19.3%。换句话说，一个闭环正在形成：AI 写类型，AI 跑检查，AI 修错误，人只负责点接受。
受访者的原话比数据更刺耳：
- 「我得手动改 AI 写的类型，它经常偷懒，什么都标成 object。」
- 「懒惰的编码 agent 到处刷 #type: ignore。」
这就把「类型安全」变成了一个信任问题。如果最后一道检查也是 AI 在跑、错误也是 AI 在压，那类型系统还剩多少独立的校验价值？
调查自己也承认没答案：被问「类型对 AI 辅助编码到底有多大用」，29.8% 的人选「不确定」，是六项收益里第二高不确定率（7.7%）的近四倍。Pyrefly 团队已经在研究 agent 工作流里的类型检查，并在 2026 年的 Python Typing Summit 上做过分享，但目前还没有可用的实证结论。
四、给团队的四条落地建议
1. 把「检查器由谁跑」写进规范。本地 pre-commit 必须跑一次真人配置的检查器，CI 再跑一次，agent 跑的那次只能算第三道，不能替代前两道。
2. 给 #type: ignore 上锁。要求带错误码和一句理由，CI 统计新增数量，涨了就拦。AI 最容易在这里留垃圾。
3. 优先补自家边界类型，别急着补全库。请求体、配置、ORM 模型、对外 SDK 这四处收益最高，内部函数的宽类型可以先放。
4. 多检查器团队要写清「谁说了算」。Mypy 管 lint、Pyright 管编辑器、Pyrefly 管 CI 这种分工没问题，但要明确冲突以哪个为准，否则新人第一天就会撞上两个工具打架。
五、这份调查没回答的问题
问卷能测出态度，测不出效果。29.8% 的「不确定」其实就是一句诚实的话：我们还不知道 AI 和类型检查器怎么配合才算真的帮上忙。
至少有三个问题悬着。第一，AI 写的类型质量到底如何，是靠人抽查还是靠后续 bug 率衡量，目前没有公开数据。第二，当 agent 能自己跑检查器、自己改错误时，人的审查该放在哪一步，业界没有共识。第三，检查器越来越快之后，团队会不会为了省 CI 时间把检查从「必须绿」降级成「仅供参考」——速度提上来了，约束反而松了，这种退化在别的工具链上已经发生过。
调查里那句「类型系统最大的价值是运行时保证」，不确定率只有 7.7%，说明大家对「类型能防住什么」是有共识的；分歧全部集中在「AI 参与之后，这个保证还算不算数」。
调查样本 1794 人，76.4% 有五年以上 Python 经验，所以它代表的是「已经写了很久的人怎么想」，不代表新手。读结论时这一点别忘。它也没有覆盖完全不用类型的那部分人——那才是真正的沉默大多数。
原文：https://engineering.fb.com/2026/10/27/developer-tools/python-typing-survey-2026-ai-tools-checker-landscape/
内容与图片版权归原作者所有 · 原文: https://engineering.fb.com/2026/10/27/developer-tools/python-typing-survey-2026-ai-tools-checker-landscape/