夜雨聆风大家好，这里是数字木鱼 TK 科技观察 ✨
记录 AI、数字工具和智能制造领域的一些个人观察。
这两年，AI 编程工具越来越多。每当新模型或新版本发布，排行榜、跑分和成功率往往会成为最先传播的信息。
但真正开始使用以后，我逐渐意识到：排行榜可以告诉我们一个工具大概有多强，却很难直接回答它是否适合自己的项目。
尤其是当我们把 AI 用于真实开发，而不是完成一道标准化测试题时，任务是否说得清楚、项目环境是否完整、结果能不能复核，往往比分数本身更重要。
SWE-bench 官方排行榜页面截图。榜单结果会随着新模型、Agent 框架和提交记录更新，截图时间：2026 年 7 月 31 日。图片仅用于说明公共编程评估的呈现方式，不代表本文认可某一模型为最终最佳选择。
一个高分，可能没有看上去那么简单
2026 年 7 月，OpenAI 发布了一篇关于编程评估质量的研究文章。
OpenAI 表示，在检查 SWE-bench Pro 的任务后，其团队估计约有 30% 的任务存在不同程度的问题，包括题目描述不完整、隐藏测试要求与题目不一致、测试过于严格，以及测试覆盖不足等。这个比例是 OpenAI 针对该基准进行审计后得出的估计，不能直接外推到所有编程排行榜。(OpenAI)al Studio Code 团队公布了另一项看起来非常简单的评估。
它让编程 Agent 在一个空目录中创建 HELLO.txt 文件，并写入“HELLO”。任务只检查两件事：文件是否存在，文件中是否包含预期内容。VS Code 团队在六个月内重复运行了五万多次，观察不同模型和系统版本完成同一任务时所使用的工具路径。(Visual Studio Code)是否可靠，另一个研究在重复一个几乎简单到不能再简单的任务。
两者放在一起，反而说明了同一件事：
评估 AI 编程工具时，测试题是否清晰、稳定，并且符合真实目标，与最终分数同样重要。
排行榜回答不了“适不适合我”
公共排行榜当然有价值。
它提供了一组相对统一的任务，让不同模型能够在相近条件下进行比较。如果完全没有基准，我们就只能依赖产品宣传、发布会演示和零散的个人体验。
但排行榜也有天然限制：
测试任务不一定与自己的项目相似； 评分标准可能偏向某一种实现方法； 一次通过不代表长期使用也稳定； 正确率不一定体现等待时间和调用成本； 模型成绩不能完全代表编辑器、工具链和执行环境； 同一个模型在不同权限、提示词和项目上下文中，表现可能完全不同。
因此，排行榜更像一张地图。
它可以告诉我们大致方向，却不能替我们完成最终选择。
测试本身有问题，分数就可能误导
根据 OpenAI 公布的分析，编程基准可能出现几类典型问题。(OpenAI)没有说明的具体实现方式；有些题目遗漏了隐藏测试会检查的条件；还有一些测试覆盖不足，使得只完成部分功能的修复也能够通过。
这可能产生两种相反的误判：
模型给出了合理方案，却因为题目没有公开的隐藏规则被判错； 模型只解决了部分问题，却因为测试不完整被判对。
这并不意味着所有编程基准都不可信。
真正需要警惕的是：当我们看到一个模型领先了几个百分点时，很容易忽略这个分数是怎样产生的。
一个相对可靠的评估，至少应该说明：
测试任务来自哪里； 正确答案如何定义； 测试是否覆盖了主要需求； 是否存在训练数据污染风险； 争议结果是否经过人工复核； 任务是否接近实际使用场景。
如果这些问题没有明确答案，那么小数点后的排名差异，可能并没有想象中那么重要。
为什么“写一个 HELLO”仍然值得测试？
VS Code 的测试只要求创建一个文件并写入五个字符。
几乎所有被测试的模型大多数时候都能完成。真正被观察的不是模型“会不会写”，而是它“怎样完成”。
最直接的路径，是调用一次创建文件工具，把“HELLO”写进去。
但有些 Agent 会先制定计划、读取目录、检查环境、搜索文件，最后才创建目标文件。这些额外步骤并不一定会造成正确性错误，却可能增加等待时间、工具调用次数和 token 消耗。(Visual Studio Code)察出一些重要差异：
模型能否判断任务的实际复杂度； 是否能够选择足够短的工具路径； 会不会产生不必要的规划和搜索； 系统更新后是否出现行为回退； 同一个简单任务能否稳定重复完成。
当然，一个创建文件的任务，不能证明某个模型擅长大型项目。
复杂开发工作本来就需要阅读代码、分析依赖和制定计划。小型评估的意义，并不是建立一个万能排名，而是把某一项具体能力单独观察清楚。
我没有做过多工具横向评测
需要说明的是，我没有系统对比过 Codex、GitHub Copilot、Claude Code 等多种 AI 编程工具，也没有在相同项目中记录它们的完成率、速度和费用。
因此，我无法根据个人体验给这些工具排名。
我真正使用得比较多的是 Codex。我曾经把一些实际需求交给它处理：一类是制作具体的小工具，另一类是尝试搭建一套包含前端、后端、数据库和业务规则的系统。
这些经历没有形成严格的评测数据，但让我对“怎样判断 AI 编程工具是否好用”有了一些更现实的认识。
我的 Codex 使用体验：能力之外，更重要的是任务是否清楚
刚开始接触 AI 编程时，很容易产生一种期待：
只要把“帮我做一个系统”或者“帮我开发一个工具”发给它，AI 就应该自动理解全部需求，并一次性生成能够直接使用的结果。
但真正做项目以后，我发现情况并不是这样。
当需求比较模糊时，Codex 也许能够快速搭出页面、目录和基础代码，但这些内容是否符合真实业务，仍然取决于我有没有提前说明：
这个工具到底解决什么问题； 输入和输出分别是什么； 哪些字段必须保留； 哪些情况属于异常； 数据能不能被修改； 怎样才算任务完成； 出现错误时应该怎样处理。
例如，“帮我做一个数据清洗工具”看起来是一句完整的需求，但真正开发时还需要继续明确：要清洗哪些数据、超长数字怎样保存、单元格中的换行怎样处理、是否保留原文件、输出格式是什么，以及错误数据应该提醒还是自动修复。
这些规则没有说清楚，AI 就只能按照自己的理解补全。
它生成的代码可能可以运行，却不一定能解决我真正遇到的问题。
搭建系统以后，我开始重视“可复核”
在使用 Codex 搭建系统的过程中，我越来越关注的，不只是它有没有生成代码，而是我能不能确认这些代码真的有效。
一个页面被创建出来，并不代表业务流程已经跑通；一个接口能够启动，也不代表数据结构符合实际需要；项目目录看起来完整，也不代表依赖、测试和部署环境都没有问题。
因此，我后来更倾向于要求它同步保留：
项目结构说明； 当前已经完成的内容； 尚未解决的问题； 关键业务规则； 配置和环境要求； 测试结果； 后续开发步骤。
这类文档看起来不像直接功能，却能减少一个很现实的问题：项目做了一段时间以后，连自己都不知道哪些部分已经验证，哪些只是生成出来但还没有测试。
对我来说，AI 编程工具真正有价值的地方，不只是“写得快”，还包括能否把修改过程、失败原因和当前状态说清楚。
环境问题也是评估的一部分
在实际开发中，AI 并不是只面对代码。
它还会遇到依赖无法下载、开发环境不完整、权限不足、配置文件缺失、接口信息没有提供，以及业务规则仍未确认等问题。
这些情况未必是模型能力不足，但会直接影响任务能不能完成。
这也让我意识到，评价一个 AI 编程工具时，不能只看最终有没有生成代码，还应该区分：
是模型没有理解任务； 是生成的代码存在问题； 是项目环境无法运行； 是外部依赖不可用； 还是用户没有提供必要信息。
如果把所有失败都简单归结为“模型不行”，得到的结论同样可能不准确。
我目前形成的一套使用方法
虽然我还没有进行正式的模型对比，但从使用 Codex 制作工具和搭建系统的过程来看，我认为比较有效的方法，是把一个大目标逐步拆开。
第一步：先说清楚问题
不要一开始就要求 AI 直接生成完整系统，而是先说明现有流程、实际痛点、使用对象和最终目标。
第二步：把业务规则写出来
哪些内容必须保留，哪些内容不能自动修改，缺少信息时怎样处理，都应该提前确定。
第三步：确定最小可用版本
先完成一条能够验证的核心流程，再逐步增加统计、权限、自动化和界面优化等功能。
第四步：要求保存过程记录
让 AI 更新项目说明、待办事项、修改记录和当前阻塞，避免项目状态只存在于某一轮对话中。
第五步：用结果而不是代码量验收
真正的验收标准应该是问题有没有解决，而不是 AI 一次生成了多少文件、多少行代码。
这套方法未必适合所有人，但它比单纯更换模型更能改善我的实际使用效果。
对个人开发者来说，最有用的是“自己的小基准”
普通开发者不一定需要搭建一套专业评测平台。
更现实的办法，是从自己反复遇到的任务中挑选几项，形成一组能够重复执行的小测试。
例如：
在固定项目中修复一个明确的小错误； 按现有代码风格增加一个简单接口； 为指定函数补充测试； 把一段重复代码重构为公共函数； 根据错误日志定位一个已知问题； 更新文档，同时保持原有格式； 读取需求说明并生成一份实施方案。
每项任务都要提前写清楚完成标准。
测试时也不应只记录“成功”或者“失败”，还可以观察：
这样的结果可能不适合做公开排名，却更接近自己的真实需求。
不要让 AI 同时出题、考试和判卷
现在不少评估会让另一个模型给生成结果打分，也就是常说的“模型评判模型”。
这种方式适合大规模处理开放式结果，但评判模型本身也可能存在偏好。
Apple 在 WWDC 2026 的 Evaluations 资料中讨论了模型评判结果与人工判断之间的偏差，并介绍了如何测量两者的一致程度、分析对齐失败，以及通过更明确的评分维度和示例改进评判模型。这提醒我们，自动评分不能完全替代人工抽查。
更稳妥的流程是：
先由人写清楚评分维度； 用少量典型案例对齐判断标准； 再进行自动化批量评估； 人工复核低分、冲突和边界案例； 定期检查评分标准是否发生变化。
AI 可以帮助扩大评估规模，但最终仍需要人确认：这个分数是否代表了真正想要的结果。
选择 AI 编程工具时，我更关注什么？
结合这些公开资料和自己的 Codex 使用经历，我目前会从五个方面观察一款 AI 编程工具。
1. 正确
任务最终是否真正完成，测试能否通过，有没有遗漏明确需求。
2. 稳定
同一个任务多次执行时，结果是否接近，而不是偶尔表现得非常好。
3. 克制
是否只修改必要内容，能否避免无关搜索、过度规划和大范围改动。
4. 透明
是否保留修改记录、测试结果、失败原因和关键依据，方便人工复核。
5. 经济
完成同样的任务，需要多少时间、调用次数和费用。
最强的模型不一定是每个任务中最合适的模型。
简单工作可能更需要快速、稳定和克制；复杂工作才需要投入更多时间进行阅读、推理和规划。真正成熟的 AI 编程工具，应该能够根据任务调整投入，而不是对所有问题使用同一种处理力度。
排行榜适合筛选，真实项目负责做决定
排行榜仍然值得看。
它可以帮助我们了解不同模型的大致能力范围，也可以帮助排除明显不适合某类任务的工具。
但完成初步筛选后，真正决定是否长期使用的，应该是它在自己项目中的表现。
我目前没有足够的实际依据去判断哪一个 AI 编程工具最好，也没有必要为了文章完整而虚构一组对比测试。
现阶段我能确认的是：在使用 Codex 制作工具和搭建系统的过程中，影响结果的并不只有模型能力。
需求是否清楚、上下文是否完整、环境是否可用、验收标准是否明确，以及使用者能不能复核结果，都会改变最终体验。
所以，与其一直寻找排行榜上的第一名，不如先建立一套适合自己的判断标准。
延伸思考
如果一款 AI 编程工具在公开排行榜上更强，但在你的日常任务中更慢、修改范围更大，也更难复核，你还会选择排行榜冠军吗？
或许未来真正有价值的，不是一个所有人通用的模型排名，而是每个人都能根据自己的项目，建立一套小而真实的评估方法。
参考资料
OpenAI，《Separating signal from noise in coding evaluations》，2026 年 7 月 8 日。(OpenAI)io Code，《What 50,000 Runs of a 5-Line Eval Taught Us》，2026 年 6 月 19 日。(Visual Studio Code)oper，《Improve your prompts by hill-climbing with Evaluations》，WWDC 2026。(Apple Developer) 本文由作者基于公开资料整理，并结合个人观察完成。AI 工具仅用于资料整理和文字辅助，内容已经人工审核。
