速评：这可能是今年最"自曝"的一篇 benchmark 论文。
8月17日挂到 arXiv 上的《OpenHarmony Bench》，30位作者，Li Li 领衔，评估 LLM coding agent 在 ArkTS 应用上的开发能力。数字一出来，我先愣了一下——平均构建成功率 94.77% 到 100%，可任务完成率只有 48.36% 到 58.39%。
构建率接近饱和，任务率勉强过半。这俩数字之间的沟，就是我不太信"AI agent 已经能干活了"这句话的原因。
先说这个基准的设计。要求 agent 去改一个真实可构建的 ArkTS 项目，要端到端跑通——UI 状态、数据持久化、构建配置、平台 API，改完的东西拿真机装上，验证行为可观察。不是跑个静态检查就交差，不是对着 benchmark 集生成一段代码就算过。这个设计本身，说实话，比市面上多数"编程基准"都实在。
而且把所有东西全放出来了：代码、数据、任务、参考解决方案、测试脚本、排行榜。算是把"这瓜保熟"的姿态做足了。连 DataCite DOI 都挂上了，就差把"欢迎复现"四个字写在标题里。
但问题恰恰出在被放出来的这部分。
可构建性接近饱和——94.77% 到 100% 的最终构建成功率。这个数字看着漂亮，其实说的是另一件事：模型把代码补全到"能编过"的程度，已经没什么悬念了。语法、类型、依赖声明、编译配置，这类静态层面的东西，对现在的模型来说确实不是事。
可构建 ≠ 可运行。可运行 ≠ 行为正确。
任务完成率 48% 到 58%，这才是真实的 agent 能力水位线。也就是说，哪怕代码编过了、装上了、跑起来了，有一半的情况它没做对你要的事。这还只是顶层任务的分值，如果按特征点严格计分，数字只会更难看。
论文里有一个数字我盯了很久：规格驱动任务——就是那种给你结构化场景说明，让你实现一堆交互要求的——在所有检查项都需通过的前提下，没有任何配置的完成率超过 35%。
35%。
这个数字，那些"AI 编程已经是未来"的发布会通稿里是绝对不会出现的。因为规格驱动的任务才是真实开发的形状：你拿到的是一个需求文档或 issue，不是一句"写一个计算器"。要处理的是状态流转、边界条件、组件间的偶合。模型在这一栏露出了马脚：阅读理解需求，然后跟现有代码对齐，这步还远没解决。
还有，主榜单按顶层任务计分，不按特征点加权。看到这我想了一下，这算是论文的一个小算计——按特征点加权的话，数字会低得多，因为一个任务里四个特征点对三个，跟全对，在顶层任务口径下是同一分。差一个特征点也算完成了。这个打分粒度，往宽里放了一档。
实验配置：DevEco Code 配八个 LLM，每个配置跑三遍完整套件。三遍取的是最好还是中位数？论文摘要里没写。对 benchmark 论文来说，"三次独立运行"的数据上报口径，本来就是留给读者自己去推敲的地方。
不过有一说一，这批作者有进步。上一次某个号称评测 coding agent 的榜单出来，被吐槽最多的是"代码不可复现、环境不可见、评测集有泄漏嫌疑"。这次他们直接把仓库整个扔出来，任务集快照、参考解、脚本一次性给齐。等于自己先把"复现"这道门槛焊死了。这不是第一次有人这么干了，但这批人的动作确实比之前几波要快、要彻底。
要知道这篇论文是8月17日挂出来的，从它挂出来到今天，OpenHarmony bench 的仓库已经在社区里被翻过了。目前还没人扒出评测集泄漏或者评分脚本 bug——这已经算该赛道少见的卫生水平了。当然，我对"还没人扒出来"这句话也打个问号：它挂着才几天，真要有人扒，得等几个星期后的复现报告才算数。
回到最初那个数字落差。一边是构建成功率 94.77%——告诉你模型对 ArkTS 的语法和编译链已经摸透了；一边是任务完成率 48.36%——告诉你它读需求建功能还差一整个身位。这俩数字拼在一起，恰恰拼出了 coding agent 当前的真实形态：一个极其熟练的打字员，但还不是一个可靠的开发者。
那些拿着 58% 就说"AI 编程已经超越人类"的，属实在拿及格线当满分宣扬。反过来看，那些拿着 48% 就断定"LLM 写代码纯属扯淡"的，也没看出来基准本身已经在真实设备上是真跑过、装过、验过的——这本身就是行业往前挪的一步。
我更好奇的是没人愿意追的那半截：剩下 41.61% 没被完成的任务，模型卡在哪了？是懒得读需求？是改了 A 组件忘了 B 组件的联动？是 UI 状态更新了但持久化没接？还是连需求场景都理解岔了？
这个，论文里没列，排行榜上不显示。但真正的开发工作，恰恰每天就淤堵在这些地方。