终于也试了一把 Air Coding：Qwen 122B 跑到 45 TPS，写代码真的顺了
最近抽空试了一把 Air Coding。
这次最直观的感受只有一句话：快，真的会改变写代码时的节奏。
Qwen 122B 实测大约能跑到 45 TPS 左右。这个速度放到实际编码场景里，已经不是“能不能用”的问题，而是你愿不愿意把它加入日常工作流。
45 TPS 到底是什么感觉？
TPS 可以简单理解成模型每秒生成多少个 Token。
数字本身看着有点抽象。换成实际体验就直观多了：
- 让模型生成一段函数，几乎不用盯着进度条发呆
- 修改接口参数时，反馈速度很快
- 让模型解释一段报错，等待时间明显变短
- 连续追问几轮，聊天节奏不会被卡住
- 生成代码时，光标往前跑的速度很舒服
以前用模型写代码，经常是输入完需求后去倒杯水。回来一看，它还在慢慢吐字。
速度上来之后，体验完全不同。你会更愿意把小问题直接交给模型处理，而不是先自己憋半天。
Air Coding 适合拿来做什么？
1. 快速搭一个功能雏形
比如你想做一个文件上传接口，可以直接给出需求：
用 FastAPI 写一个文件上传接口，支持多文件上传。
要求：
1. 限制单个文件大小为 20MB
2. 只允许 jpg、png、pdf
3. 上传成功后返回文件路径
4. 对异常情况返回清晰的错误信息
5. 给出完整可运行代码
这类任务很适合交给模型先打底。
你不用从空文件开始写，也不用先查一堆框架文档。模型生成初版后，再根据项目结构慢慢调整。
2. 处理重复性代码
重复代码最适合交给 AI。
例如：
- 根据数据库表生成 CRUD
- 给多个接口补参数校验
- 批量增加日志
- 为函数补类型标注
- 把同步代码改成异步写法
- 给旧项目补测试用例
- 把一段长函数拆成多个小函数
这些工作不难，却很消耗时间。
让模型先处理一轮，咱们负责检查边界条件，效率会高很多。
3. 排查报错和定位问题
遇到报错时，不要只把错误信息扔给模型。
建议一起提供：
- 完整报错堆栈
- 相关函数
- 输入参数示例
- 预期结果
- 实际结果
- 最近改动过的代码
例如：
下面是一个 Python 异步任务的报错。
请先判断最可能的原因，再给出最小修改方案。
不要直接重写整个项目。
报错：
[粘贴完整 traceback]
相关代码：
[粘贴函数]
预期：任务失败后自动重试 3 次。
实际：第一次失败后程序直接退出。
这种提问方式比一句“帮我修 bug”靠谱得多。
速度快，为什么会让编码体验变好？
很多人以为速度只影响等待时间。
其实它还会影响你的思考方式。
模型响应慢时，你会下意识减少提问次数。一个问题尽量塞得很完整，生怕来回沟通浪费时间。
模型响应快时，你可以采用更自然的方式：
- 先让模型写一个最小版本
- 运行代码
- 把错误贴回去
- 让它只修当前问题
- 再继续补功能
这更像和一个反应很快的同事协作。
需求不用一次说完。代码也不用一次生成到位。
一套比较顺手的 Air Coding 工作流
第一步：先让模型理解项目
不要一上来就让模型改代码。
可以先提供项目目录、技术栈和关键文件，让它回答：
请先阅读下面的项目结构。
暂时不要修改代码。
请告诉我：
1. 项目的入口文件在哪里
2. 核心业务流程是什么
3. 哪些文件可能和用户登录有关
4. 如果要增加手机号登录，最可能需要改哪些地方
这一步能减少模型“看错文件、改错位置”的情况。
第二步：把大需求拆小
不要直接说：
帮我做一个完整的电商后台。
这种需求太大，模型容易开始自由发挥，最后得到一堆看起来完整、实际很难接入的代码。
改成：
这次只实现商品列表接口。
先不要处理新增、编辑和删除。
请沿用现有项目的分页方式，并补充参数校验和错误处理。
范围越小，结果越稳定。
第三步：要求模型少改代码
这是非常实用的一句提示：
只修改和当前问题直接相关的文件，不要重构其他模块。
请先说明准备修改哪些文件，再输出补丁内容。
很多项目被 AI 改乱，不是模型完全不会写，而是它改得太多。
一个小问题，最后变成全项目重构。看着很积极，实际上很危险。
第四步：每次修改后马上运行
别一次让模型改十个地方，然后一起测试。
更稳的节奏是：
- 改一个功能
- 跑一次测试
- 检查一次 diff
- 确认没问题后再继续
尤其是数据库、支付、权限、缓存这些模块，千万别只看模型说“已经完成”。
代码能运行，不代表逻辑正确。
45 TPS 不等于所有任务都很快
这里要提醒一句：推理速度只是体验的一部分。
实际表现还会受到这些因素影响：
- 输入上下文长度
- 输出代码复杂度
- 是否开启思考模式
- 显存和内存带宽
- 模型量化方式
- 并发请求数量
- 推理框架和参数配置
- 文件读取和工具调用速度
短代码补全可能很快。
但如果一次塞入几十个文件，再要求模型分析完整项目，速度依然会下降。上下文太长时，模型的注意力也可能被稀释。
所以别只看测速截图。
真正该测试的是你每天会用到的任务。
建议做一组真实场景测试
可以准备下面几类任务：
代码补全
让模型补一个 20 到 50 行的小函数，观察首字延迟和持续输出速度。
报错排查
提供真实项目中的 traceback 和相关代码，看它能不能定位到有效原因。
多轮修改
连续提出三到五次修改要求，观察模型是否能记住上下文。
项目级理解
提供目录结构和几个关键文件，让模型解释模块之间的关系。
测试生成
给一个已有函数，让模型生成正常、异常、边界三类测试用例。
这比单纯输入一句“写个 Hello World”更有参考价值。
使用时容易踩的坑
只看 TPS，不看首字延迟
持续输出速度很高，但如果每次都要等很久才开始输出，实际体验依旧可能一般。
需要同时关注：
- 首字响应时间
- 持续输出速度
- 长上下文下的稳定性
- 多轮对话后的准确性
一次塞入太多无关文件
项目文件不是越多越好。
把整个仓库全丢进去，模型未必更聪明，反而可能找不到真正相关的代码。
先给目录结构，再提供关键文件，效果通常更稳。
不检查模型生成的依赖
模型可能顺手引入一个项目里没有的库，或者使用过时 API。
看到这些代码时，记得检查：
requirements.txtpackage.json- 框架版本
- API 是否仍然可用
- 是否和现有代码风格一致
让模型直接改生产代码
这件事真的别省步骤。
至少保留：
- Git 提交记录
- 修改前后的 diff
- 可回滚分支
- 基本测试
- 配置文件备份
AI 写得再快，也不该替你承担上线事故。
这次体验的结论
Qwen 122B 跑到约 45 TPS 后，Air Coding 的使用感受明显变顺了。
它最适合的不是“输入一句话，自动生成完整软件”，而是嵌入日常开发：
- 帮你快速写初版
- 解释陌生代码
- 处理重复劳动
- 分析报错
- 补测试
- 做小范围重构
模型负责加速，开发者负责判断。
这套配合用顺之后，很多以前要查半天、改半天的小任务，确实可以更快收尾。每天少被几个低价值问题卡住，早下班一小时也不是完全没可能。🚀
视频记录：这次 Air Coding 的实际运行过程和速度表现，可以结合视频一起看。
