流传最广的代码能力测试题是「写个快排」，也是最没用的一道。这道题的答案在公开语料里出现了几万次，任何能写代码的模型都能默出来，默完之后你还是不知道它能不能改你那段三千行的老代码。AI 对话的代码能力要测得准，题目得从公开题库换成你自己的仓库。
通用题测的是记忆，不是能力
算法题有标准答案、有大量题解、有固定输入输出。模型在这类题上的表现，和它在真实项目里的表现，相关性比想象中低。真实任务的特征是：需求含糊、上下文散在几个文件里、正确做法取决于你们团队的约定。这三点在算法题里一个都没有。
更麻烦的是评估污染。公开题库的题目和解答大概率进过训练数据，模型答对不代表会做，可能只是见过。用它比较两个模型，比的是谁记得更全。
三个维度与各自的判分线
| 测试维度 | 怎么测 | 什么算过 |
|---|---|---|
| 补全 | 在真实文件中间删掉 5–10 行，光标停在断口让它续写，重复三次 | 三次里至少两次能直接用：沿用项目的日志封装、命名风格与错误处理，只需改细节 |
| 调试 | 给一段能稳定复现的报错、相关文件与调用栈，不给结论 | 首轮就指向真正出错的位置；改动在十行以内；不靠 try-catch 把异常吞掉 |
| 重构 | 拿一个有测试覆盖的百行函数，要求行为不变地拆分 | 原有测试全绿，对外接口签名不变，重复分支消失，没有新增依赖 |
三项里调试最接近日常，也最能暴露问题：它要先读懂别人的代码，再定位因果，最后给一个最小改动。只会重写不会定位的模型，在维护型项目里帮不上忙。
用你自己的代码出题
从最近三个月的提交里挑三样东西：一个你修了半天的 bug、一个你重构过的函数、一个新写的模块。这三类题自带标准答案——你自己的真实改法，比任何榜单都准。
给模型的信息要和给人一样：需求描述、相关文件、完整报错。不要额外提示，也不要暗示答案在哪一行，否则测的是你的提示技巧，不是它的能力。文件给多少也有讲究，上下文窗口装得下是一回事，塞进去一堆无关文件把关键信息稀释掉是另一回事。
跑通之后还要看四件事
风格是否一致：命名、日志、异常处理有没有沿用项目里已有的写法。边界是否处理：空值、零、超大值、并发同时进来。依赖是否新增：为了一个字符串处理引入一个库，长期是负担。注释是否解释为什么：复述代码的注释不如不写。
还有一类失败很隐蔽：它调用了一个不存在的内部方法，或者签名对不上。这类读得懂但跑不通的产出，报错往往指向别处，排查要多花一倍时间。
按项目寿命定及格线
写脚本、做一次性数据处理，跑通就够，风格无所谓。要维护三年的项目，可读性和一致性权重很高，一段能跑但风格混乱的代码，评审时会被打回，等于白写。
同一个模型在两种场景下的评分可以完全不同。所以别问「它代码能力怎么样」，要问「它在我的技术栈、我的项目寿命下够不够用」。语言也要限定：不同模型在不同语言上的训练数据差别很大，Python 上很强不代表在你的语言上能用。
一次通过不代表稳定
同一道题换个变量名、换个业务字段再问一遍，看它给的思路是否一致。稳定的模型两次结构相同，只是细节不同；不稳定的会给两个完全不同的解法，说明它在猜，而你没看到的那次可能就猜错了。
隔一天重问也有用。有些模型对措辞敏感，换个说法就从「能修」变成「不会」，这种脆弱性在真实使用里会反复出现。
速查：代码能力实测清单
- 弃用算法题，改用自己的 bug、重构和新模块
- 三个维度分开测：补全看风格，调试看定位，重构看测试
- 判分看边界、依赖、注释，不只看能不能跑
- 同一题换字段重问一遍，确认不是碰巧
- 先限定语言和框架，再谈强弱
