本地代码模型能启动、能读懂代码、能指出 Bug，看上去已经离“可以接手开发”很近。最近一次实际评估却让我把这三个判断重新拆开：服务恢复只证明能调用，解释正确只证明看懂了部分问题，修复可用还要靠独立执行。
我没有拿整套业务系统让它自由发挥，而是交给它两份边界清楚的小任务：一份修复文件写入问题，一份检查结构化结果的校验逻辑。原始输入、模型回复和实际执行结果分别保存。下面只讨论匿名化后的机制，不公开具体系统、设备、模型配置或私有代码。
第一份任务：它找到了写入窗口，补丁却没封住窗口
这份任务的核心问题很具体：创建一个新文件时，不能让其他读取者看到尚未写完的内容，也不能覆盖已经存在的目标。
模型给出的方向并不离谱。它建议先把内容写入临时文件，再把完整内容暴露给目标路径；同时注意清理临时文件、处理并发冲突。这些解释读起来很像一份合格的修复说明。
但候选实现里仍有一步：提前把目标文件创建出来，用它占住名字，然后才完成后续写入。
正是这一步，重新引入了“目标已经可见，内容还没完整”的窗口。它在文字里强调不要暴露半成品，代码却先暴露了一个半成品。
我把候选实现放入隔离副本，运行已有的针对性测试。并发和冲突场景中的部分检查通过，但“创建过程不能提前暴露目标”这项失败了。
这个结果比一句“代码写得不错”有用得多：模型对问题方向有理解，却没有交出满足关键约束的修复。部分测试通过，也不能替失败的核心约束投票。
测试草稿也是候选，不是测试证据
同一份回复还附带了测试草稿。它看起来覆盖了临时文件、冲突和写入行为，但原样运行时，测试准备阶段就出现错误：草稿调用的接口形状与实际对象不匹配。
这不意味着那些测试想法完全没有价值。它们仍然可以帮助我列出需要检查的情形。但它们当时不能证明补丁正确，因为它们还没有进入有效的行为断言。
我现在会明确区分三种结果：
- 测试思路：知道应该测什么，但还只是描述。
- 可运行测试：能在目标环境中找到对象、准备输入并执行断言。
- 有效检测：故意保留或重新引入原 Bug 时失败，修复后通过。
Python 的 unittest 文档把测试发现、模块导入、测试准备和测试执行分开说明；测试模块必须可导入，准备阶段的异常也会成为测试错误。[2] 所以“输出了一份测试代码”和“用测试验证过修复”不是同一种交付。
第二份任务：只检查坏结果，会看漏校验器的问题
第二份任务不是修复写入，而是生成一个结果校验器。它需要判断：数值是否与原始数据一致、字段间是否自洽、证据绑定是否正确，以及结论有没有超出输入允许的范围。
初看回复，它已经写了不少检查：重算数值、比较选项、检查绑定。真正把候选代码放进一组对照样例，问题才显出来。
漏检：结论越界，却没有报错
我只改变样例中的结论范围：把“仅能说明一份冻结样本”改成“可以说明当前运行状态”。数值部分保持不变。
校验器没有给出错误。它能检查一些数值关系，却没有守住结论范围。另一个证据绑定不匹配的样例也没有被识别。
这说明“写了许多检查”不是完整性证明。最关键的字段如果没进入断言，其他检查再多，也不能代替它。
误报：诚实记录失败，也被当成格式错误
我又放入一个合法对照：一次选择确实没有命中预期答案，但记录如实标明“本次答错了”。
这份记录并不自相矛盾。它描述的是一次合法发生的失败，应当通过记录一致性检查，再作为效果不佳的样本参与评估。
候选校验器却因为“选择与预期不同”直接报错，把任务结果不好和结果记录不合法混为一谈。
这是很容易被忽略的区别：如果校验器只接受成功结果，就会把诚实的失败样本排除在外，让后续质量判断失去一部分重要材料。
我以后怎样做一场小型代码模型验收
这次评估没有变成大型榜单。真正值得保留的是一份读者也能复用的小方法。
1. 先写行为要求，不先看模型解释
把任务缩成几条能判断真假的要求，例如：创建失败不能留下可见半成品；不能覆盖已有对象；结论不能超出证据；失败结果可以被诚实记录。
要求在看到模型答案前确定，避免看完漂亮解释后，把验收条件改成“它刚好做到了什么”。
2. 让答案落到完整产物
找出问题、写出候选补丁、附上测试、运行测试、关键行为通过，是不同层次。
如果本轮只让模型输出文本，就承认它交付的是候选；不要因为语气坚定，自动补上“已经运行过”的经历。
3. 保留三类对照
- 原错误：它是否真正检测或修复了这次要解决的问题？
- 邻近错误：换一个相似的越界、缺失或冲突，它还能识别吗？
- 合法但不漂亮的结果：空结果、未命中、如实记录的失败，会不会被误杀？
对于输入—预期结果关系清楚的场景，可以用参数化测试把这些对照写成一组案例。pytest 官方文档提供了让同一测试函数分别运行多组输入和预期值的方式。[1] 工具只负责运行案例，哪些案例能代表真正的约束，仍需要评估者决定。
4. 测试失败后分类，不立即换模型
先区分：环境没有准备好、测试草稿接口不匹配、候选实现违反约束、校验器漏检，还是校验器误报。它们需要的修正完全不同。
如果接口没对上，却不断更换提示词；或者服务不可用，却直接判模型能力差，都会把评估带到错误方向。
5. 按任务给岗位，不按一句总评给身份
这轮结果支持的判断很窄：模型可以提供部分排查思路，但这两份候选还不足以作为免复核的实现交付。
它是否适合生成测试想法、解释代码、整理局部风险，可以继续分别测。不能因为补丁失败，就说它毫无价值；也不能因为抓到了一个 Bug，就宣布它已能独立承担开发。
适用边界：这不是所有本地模型的排名
这是一次具体任务、具体输入和实际候选的评估，不是统计意义上的模型能力排名。换模型、推理后端、上下文、提示方式或工具权限，结果都可能改变。
本轮独立执行的是候选实现和校验逻辑，并不是证明模型自己完成了调用工具、修改仓库、运行测试与交付的整条链路。评估者帮助它跑过候选，不能算成它已经拥有自主闭环能力。
我也没有在这篇文章中给出一份新的完整修复教程。关键结论是验收方式：找到问题，是排查价值；交出候选，是实现尝试；经独立执行满足行为要求，才是可接受的修复。
评测本地代码模型，最值得盯住的不是回答有多长，而是它的解释、代码和运行结果有没有说同一件事。
本文为 AI 辅助整理的原创实践内容。依据作者近期实际评估的原始回复、隔离执行日志与对照结果撰写；案例已抽象化，不披露设备、账号、内部路径、项目身份、调用量或私有实现。官方来源于 2026 年 10 月 11 日回源核验；官方文档只支持测试机制，不为本次模型结果背书。
一手来源
- pytest 官方：参数化测试（2026-10-11 回源核验）
- Python 3.14 官方：unittest 测试框架（2026-10-11 回源核验）
