同一个网页小游戏,我让两套 AI 各做一遍:一个看起来更像成品,却没做完

昨天，顺我朋友的活儿，我做了一个很小的实验。

题目其实不复杂，就是做一个网页版中国地图互动小游戏：地图上把 34 个省级行政单位都显示出来，名称都标上去，下面给一个输入框，用户输入任意一个数字后，程序找出面积最接近的那个省级行政单位，并把对应区域高亮。

这样的题目，说难不算太难，说简单也不算特别简单。因为它不是一句话问答，也不是生成一段文案，而是一个可以立刻验证结果的东西。你点一下按钮，地图亮不亮，省份对不对，页面会不会直接出错，这些都藏不住。所以我觉得，这种任务反而很适合拿来测试 AI 的真实交付能力。

我把这个任务同时交给了两套 AI 去做。一套是 WorkBuddy，调用某国内模型；另一套是 Codex，调用 GPT-5.4。做这个测试，我倒不是为了给谁贴标签，更不是想搞什么简单粗暴的“谁吊打谁”。我只是想看一件事情：在同样一个小而具体、结果又很容易验证的任务里，两套 AI 的差别，最后到底会落在什么地方。

结果很有意思。

最后看下来，真正拉开差距的，并不是谁更会写代码表面文章，也不是谁更会讲自己做了什么，而是谁真正把事情做完了。

WorkBuddy 做出来的东西，第一眼看上去并不差，甚至在某些阶段，你会觉得它已经很接近一个成品了；但用户一实际点击，问题马上暴露出来，要么地图直接没了，要么对应省份根本没有高亮。

Codex 这一边则不一样，它前面花了不少力气做需求收束和方案确认，真正开始写的时候反倒没那么热闹，但最后交出来的东西是闭环的，能够实际运行，能够验证，也能够复现。

我后来又把两边的交互记录、过程文档和最终截图重新看了一遍，越看越觉得，这个小实验背后其实不是一个“谁更会写代码”的问题，而是一个更本质的问题：AI 时代，真正稀缺的到底是什么。

1、先说 WorkBuddy，它的问题并不是“完全不会”

如果只说 WorkBuddy 没做成，这个结论太粗了，也不够公平。因为回头看它整个过程，它并不是完全不会，也不是完全没有工作思路。相反，它在前面有一个地方其实做得还不错，就是它也知道先问边界。

比如，它会先确认这个网页到底是做成纯静态页还是小型前端项目；会问面积单位按“平方公里”还是“万平方公里”；会确认是不是包含港澳台这 34 个省级行政单位；会问结果区只高亮，还是顺带显示“最接近的是谁”；还会问这版要不要加游戏机制。这些问题说明它并不是一上来就闷头写，而是知道需求需要收口。这一点，我觉得应该承认。

后面它也确实在往前推进。它先出了一版设计，把页面结构、地图呈现、输入区、结果区这些东西拆开说清楚；用户确认之后，它再开始往实现走。从表面上看，这个工作流是有条理的。

问题出在后半程，也就是最关键的那一段：当产品已经不是停留在“怎么设计”层面，而是进入“到底能不能用”层面的时候，WorkBuddy 开始不断给出看起来很像样的修复解释，但始终没把最终结果真正跑通。

用户第一次反馈，说输入数字后一点，地图不仅没高亮，连中国地图都没了。WorkBuddy 很快就给出了解释，说根本原因是 setOption(obj, true) 会强制替换整个 series，而它传进去的内容不完整，导致地图关键配置丢失，所以点击后地图直接消失。单看这个解释，你不能说它没道理，甚至还挺像一个懂 ECharts 的人说出来的话。

但问题是，用户重新一试，还是不行。

于是它第二次修。它又分析说，ECharts 的 regions 是给 geo 坐标系用的，放在 map 系列里不生效，应该改成 dispatchAction({type:'select'}) 来做地图选中态高亮。这个解释，你单独拿出来看，也还是有一定道理。

但用户再一试，还是不行，没有高亮。

第三次，它继续往下追，说 dispatchAction({type:'select'}) 要求 series 的 data 数组里必须先有对应省份的数据项，之前是 data: []，所以根本找不到目标，自然什么都不会发生。于是它又宣称“修复完成”。

表面上看，这个过程很像是在持续定位根因、持续修复问题，甚至每一步的理由都说得头头是道。可用户那边的真实反馈是，问题并没有被真正解决。它像是在不断地产出“解释”，不断地产出一个新的“修复方案”，但没有把“我自己先验证一下，确认真的修好了”当作任务的一部分。

这里面最核心的问题，其实不在于它到底懂不懂某个 JS API，而在于它有没有真正把“验收”这件事情放进自己的工作闭环里。一个工程任务，尤其是这种一点击就能验证结果的网页任务，光有解释是不够的，光有修改意见也不够。真正重要的是，你有没有在结束之前自己先跑一遍，确认它能用，再告诉用户“已经好了”。

WorkBuddy 在这个任务上，差的不是“不会想”，而是“没有把想法落实为经过验证的结果”。这个差别，看上去不大，实际上非常大。

2、再说 Codex，它赢的地方其实不神秘

Codex 这一边，我把过程重新看了一遍，最大的感受是，它做的事情其实一点都不花哨，甚至有点“笨”。但工程上真正可靠的东西，往往就是这种不花哨。

它一开始也没有急着写代码，而是先把边界一项一项问清楚。做纯静态页还是小项目？面积单位用什么？是否包含 34 个省级行政单位？结果区展示到什么程度？要不要加游戏机制？数据口径是用常见近似值还是尽量权威公开口径？这些问题一项一项问下来，表面上看会觉得有点慢，但实际上是在不断压缩歧义。

很多人用 AI 的时候，最容易急的就是这一步。总觉得“这些不用问，直接干吧”。但我自己的体会恰恰相反，越是那种脑子里已经有一个隐约画面的任务，越要先把这个画面问清楚。不问清楚，AI 很容易在自己理解的方向上越跑越远。它不是不努力，而是努力错了方向。

Codex 做完需求收束以后，也没有直接进入“我来给你搞一个很酷的东西”的状态，而是继续往下做方案确认。它把地图实现方案摆了几个选项出来，最后收敛到 ECharts 地图的静态页方案；然后把页面结构、技术结构、错误处理和测试范围分几轮写出来，一段一段让用户确认。这个过程看着有点啰嗦，但实际上它是在把“用户心里那个模糊的成品”一步一步转成“可实现、可验证、可交付的规格”。

真正进入实现阶段以后，它的路径也很清楚。它把页面、样式、面积数据、标签点位、匹配逻辑分开处理；把“根据输入面积找最接近省份”的逻辑单独抽出来做测试；页面层则负责地图初始化、标注、输入绑定和高亮。这样做的好处是，一旦有问题，你知道问题大概会落在哪一层，而不是所有东西全缠在一个文件里。

更重要的是，Codex 在做完以后没有停在“理论上应该可以”这个阶段，而是继续往前走了两步。第一步，它跑了测试；第二步，它用无头浏览器实际打开页面并截图，看地图和标签是不是真的出来了。也就是说，它不只是“写完代码”，而是把“验证结果”作为交付的最后一环。

这一点看上去平平无奇，但恰恰是最难被省略的一步。因为到了这里，很多模型其实已经倾向于结束任务了。前面工作都做了，代码也有了，文案也能讲得通了，再往下走一步去验证，既费 token，又费算力，还不一定有“成就感”。但工程上的成败，往往就差在这一步。你不验，就不知道自己到底做成了什么；你一旦验了，很多“自我感觉良好”的错觉就会立刻消失。

所以我后来想，Codex 这次赢，其实并不神秘。它没有表现出某种神乎其神的“灵感”，也不是靠某一句神奇提示词突然开窍。它只是老老实实地把一个工程任务该走的流程都走完了：先问清楚，再定清楚，再写出来，再验清楚。事情说出来很普通，但真正能做到这一点的 AI，其实并不多。

3、这件事真正提醒我的，不是模型排行榜，而是“闭环能力”

如果只把这次测试看成“GPT-5.4 比某国内模型强”，那这个结论太浅了。因为即便这个判断在这次任务上大概率成立，它也没有解释清楚，究竟强在什么地方。

我自己更倾向于把这件事理解为：两边真正的差别，不只是代码生成能力的差别，而是任务闭环能力的差别。

什么叫闭环？说得简单一点，就是从用户一句模糊的需求开始，最后走到一个可以交付、可以验证、可以复现的结果，中间不能断。你要能收需求，能拆任务，能选方案，能实现，能排错，最后还得能验收。少一步都不行。

很多 AI 现在已经很会“局部表现优秀”了。你让它分析一段代码，它能分析得头头是道；你让它写一个界面，它也能很快给你一个看起来不错的版本；你让它解释 bug，它甚至能说出一整套很像资深工程师的话。问题在于，这些“局部能力”并不天然等于“能把事情做完”。

这也是为什么我越来越觉得，AI时代真正重要的能力，也许不是“会不会写提示词”这么简单，而是你有没有一种把事情做成闭环的习惯。你能不能把问题定义清楚，能不能把边界说清楚，能不能分辨“看起来合理”和“实际上可用”的区别，能不能要求它在结束前自己先验证一遍。这些东西，过去像是管理能力、产品能力、项目能力，现在慢慢也开始变成使用 AI 的基础能力。

我前面看自己那几篇关于 AI 的笔记时，也有一个越来越强的感受：AI 并不是把“思考”这件事从我们这里拿走了，而是把很多过去隐性的能力显性化了。以前一个人做事，需求不清楚、过程不严谨、验证不到位，很多时候还能靠经验和临场反应补一补；但当你把任务交给 AI 以后，这些问题就会被迅速放大。你说不清，它就做偏；你不验，它就容易停在一个“自我感觉已经完成”的位置上。

从这个角度看，这次不是 WorkBuddy 输给了 Codex，而是“会说”和“会做完”之间的差距，被一个很小的网页小游戏放大出来了。

4、最后说一点我自己的判断

这个实验当然很小，不能拿来下什么宏大的结论。我也不认为一次任务就能给所有模型彻底定性。不同模型有不同擅长的方向，不同工具链也会影响结果，这些都要承认。

但即便如此，这次对比我还是觉得很有价值。因为它让我更具体地看到了一点：今天我们讨论 AI，不能老停留在“它看起来会不会”这个层面。很多时候，真正该问的问题是，它有没有把任务闭环走完，它有没有把最后一公里补上。

在日常工作里，这个区别其实非常重要。做 PPT 也好，写文案也好，做分析也好，写代码也好，真正麻烦的通常不是从 0 到 0.7，而是从 0.7 到 1。前面七成，很多模型现在都能帮你做得挺像样；最后这三成，往往靠的是对需求的理解、对质量的判断，以及最朴素但最重要的一件事：验证。

说到底，AI 可以替你生成很多东西，但“什么叫做成了”这件事，很多时候还是得有人盯着。至少在相当长一段时间里，我觉得真正稀缺的不会只是模型能力，而是一个人能不能看得出好坏，能不能把任务讲清楚，能不能逼着流程走到最后。这一点，如果你自己心里没数，再强的模型也可能只会给你一堆看起来很热闹的半成品。

同一个网页小游戏，两套 AI，一次很小的测试。看起来只是地图亮没亮这么一点小事，但我觉得，这件事背后已经把很多东西说得很清楚了。

看起来更像成品的，不一定真的完成了。

而真正能交付的东西，往往不是最会说的那个做出来的，而是最愿意把“确认无误”这四个字落到实处的那个做出来的。