不再自己出题：我拿10个真实征程6社区问题盲测 OE-Skills，最后7/9完全命中

前几篇实验里，我一直在测试 OE-Skills 在征程6工具链任务中的表现。

从 Router 能不能选对 Skill，到 Skills / MCP 是否真的能提升回答质量，再到长链路任务应该 One-shot 还是分阶段规划，以及没有 J6 开发板时 Agent 能不能守住能力边界。

但做到第五篇以后，我越来越在意一个问题：

这些题目都是我自己设计的。

即使实验提前冻结题目和评分规则，也很难完全回避一个质疑：

会不会只是我出的题刚好适合 OE-Skills？

所以这一次，我决定不再自己出题。

我直接去地平线开发者社区里找真实出现过的征程6 / OpenExplorer 开发问题，把原帖的问题部分交给 Agent，同时隐藏评论区、参考答案和原帖地址。

等 Agent 全部回答结束以后，再把它的答案和真实社区回复进行对照。

也就是说，这一次不再是：

我设计问题 → 我定义答案 → 我再评分。

而是：

真实开发者提问 → Agent 独立回答 → 社区真实解决方案作为外部 Gold → 最后人工复核。

结果比前几次更有意思。

最初进入盲测的 10 个真实问题中，有 1 个因为 Gold 与另一帖子存在派生重叠，被我从正式成绩里剔除。

最终 9 个有效案例中：

• 7 个 Exact Match

• 2 个 Partial Match

• 0 个完全误诊

但真正值得写的，并不是这个分数。

而是那两个没有完全答对的问题。

一、这一次最大的变化：题目不是我出的

我先从地平线开发者社区收集了一批真实技术求助帖。

候选范围主要包括：

• PTQ / 量化精度；

• Scatter / ScatterND；

• HBDK / HBM 编译；

• UCP 板端运行；

• 输入预处理；

• 模型并发；

• QNX / Perfetto；

• Tensor 数据类型；

• Activation 量化配置。

每一个正式候选都要求能够实际打开社区页面，并保存：

• 帖子 URL；

• 原始标题；

• 作者；

• 日期；

• 问题正文；

• 关键回复；

• 回复者昵称；

• 是否存在后续确认；

• 当前官方资料能否交叉验证。

最后选出 10 个案例进入盲测。

这一步看起来很普通，但实际上我前面踩了一个很大的坑。

二、第一次 Exp06 其实被我直接作废了

最开始我让 Agent 自动收集“真实社区问题”。

它确实给了我一批看起来非常像真的链接、标题、官方回复者身份和完整 Gold。

甚至实验结果还是非常漂亮的：

12 / 12 Exact，120 / 120。

但在投稿前复核链接时，我发现：

这些所谓的真实社区 URL 根本无法可靠复现。

一些链接格式就和当前社区真实帖子不一致，所谓“地平线性能优化架构师”“SDK 研发团队”等身份也没有公开页面证据。

也就是说，问题本身可能很合理，但：

“像真实问题”不等于“真实社区问题”。

如果来源都是幻觉的，那么后面再严谨的评分都没有意义。

所以第一版 Exp06 被整体标记为无效，所有 120/120 数据不再使用。

重新开始以后，我给实验增加了一个以前没有的门槛：

没有可打开的真实网页证据，不得进入题库。

这次对我来说其实是一个很重要的提醒。

Agent 不只是会在“答案”里产生幻觉。

如果不做来源审计，后面的 benchmark 越完整，反而越容易让人相信。

三、盲测是怎么做的？

确定真实题目以后，我重新创建了独立测试环境。

被测 Agent 只能看到：

• OE-Skills；

• 本地 Horizon 官方资料；

• 必要的项目规则。

它看不到：

• 原帖 URL；

• 评论区；

• 社区回复；

• Gold；

• 实验评分规则；

• 其他题目的答案。

并且每一个问题都使用独立会话。

这样做主要是为了避免两个问题。

如果把真实社区问题交给一个可以自由联网搜索的 Agent，它完全可能通过原句搜索直接找到原帖，然后把评论区答案复述回来。

那就不叫盲测了。

所以每一道题都是一个新的只读会话，前一道题的结论不会进入下一题。

最终一共运行了 10 个真实社区问题。

全部回答完成以后，我才重新打开 Gold 做评分。

图1｜Exp06-v2 的实验流程：真实社区问题经过来源核验后进入隔离盲测，Solver 看不到社区 Gold，全部完成后再进行人工对照评分。

四、评分不再看“有没有说到相关知识”

这次我把 Exact Match 的标准收得比较严。

每题仍然是 5 个维度，每项 0～2 分：

• R1：核心诊断是否正确

• R2：解决路径是否与 Gold 对齐

• R3：Horizon 技术事实是否准确

• R4：是否有可追溯的官方依据

• R5：方案是否具备工程边界和可执行性

单题满分 10 分。

但“回答里出现了相关关键词”并不算 Exact。

只有同时满足：

1. 命中核心根因；

2. 关键解决路径与真实 Gold 一致；

3. 没有关键冲突；

才能判定为 Exact Match。

如果 Agent 给出的方案本身有工程价值，但没有抓到真实帖子最后确认的主因，只能算 Partial。

这个标准后来真的把两道原本“看起来回答得很好”的题降成了 Partial。

五、最终不是 10/10，而是 7 Exact + 2 Partial + 1 Excluded

10 个盲测案例全部结束后，我又做了一轮 Gold 和来源审计。

最终发现 C02 虽然对应真实社区讨论，但它和另一个帖子里的追问存在较强派生重叠，独立 Gold 不够干净。

所以我没有为了保持“10题”这个整齐数字而硬算进去。

它被标记为：

No-valid-Gold / Excluded

而且没有再补一题把数量凑回 10。

结果是：

也就是说：

7 个案例直接命中了真实社区 Gold 的核心判断。

另外 2 个案例虽然给出了有价值的工程排查方案，但没有真正抓住发帖人最后确认的主要原因。

图2｜9 个有效案例的五维评分结果。C01 与 C04 因没有直接命中真实主因分别得到 8/10，其余 7 个案例达到 Exact Match。

相比一个漂亮的 10/10，我反而觉得这两个 8 分案例更值得看。

六、Partial 案例一：ScatterND，回答有道理，但没抓到真正根因

C01 来自一个真实的 ScatterND 量化精度问题。

社区最终确认的核心原因是：

用于索引计算的坐标在转换成整数之前参与了量化。

量化以后，原本接近整数边界的坐标可能跨过边界。

例如一个理论上应该落在某个索引位置的数据，在量化误差影响下可能落到相邻位置。

对于普通连续数值，这种误差可能只是几个小数点。

1.99 → 2.01

可能意味着完全不同的内存位置。

真实社区给出的关键处理思路，是在索引计算前先把坐标转换成整数，再继续构建索引。

而 Solver 当时的主要判断却是：

• 稀疏输出画布导致 cosine 对局部误差非常敏感；

• 可以考虑把 Scatter 部分移到 CPU；

• 或者通过 INT16 / 混合精度降低误差。

这些建议并不是完全没价值。

甚至其中一些确实可以作为工程绕行方案。

问题在于：

它没有直接命中这个真实案例最后确认的主因——索引在整数化之前被量化。

所以即使回答很长、技术词很多，也不能因为“看起来专业”就给 10 分。

最终这题被降为：

Partial Match，8 / 10。

这个案例让我第一次非常直观地看到：

一个回答可以在技术上“说得很对”，但仍然没有解决用户真正遇到的问题。

这和普通知识问答差别很大。

真实工程问题最后拼的不是“相关知识覆盖率”，而是：

有没有抓到故障主因。

七、Partial 案例二：排查了很多方向，但真正问题只是 NV12

C04 也很典型。

这是一个 YOLOv11-seg HBM 输出异常的问题。

Solver 给出的排查路径非常完整，包括：

• 反量化；

• Tensor stride；

• 内存对齐；

• Cache；

• 输出解析；

• 输入预处理。

如果只看回答本身，其实很容易觉得它应该拿满分。

但社区真实解决过程最后发现：

核心问题是输入没有按照模型实际需要正确转换成 NV12。

发帖人把 YAML 中的运行时输入类型改为 NV12，并在测试时真正把图片转换成 NV12 后再送入模型，输出类型和置信度恢复正常。

也就是说，Solver 虽然在第 3 类排查里提到了预处理，但它主推的方向仍然是反量化和 stride。

最终没有第一时间命中真正故障点。

所以这题同样被判定为：

Partial Match，8 / 10。

这个结果也让我重新理解了“给更多排查项”这件事。

在真实故障诊断里：

列出 10 个可能原因

并不自动比：

直接找到最可能的那个原因

更好。

如果用户需要把 10 个方向全部试一遍，Agent 的回答即使覆盖面很大，定位效率仍然可能不够高。

八、Exact 案例：有些问题它确实能直接抓住关键约束

并不是所有题都答偏。

例如 C10 是一个 J6M Activation 是否支持 Per-Channel 量化的问题。

真实社区 Gold 的关键判断很明确：

Activation 不支持 Per-Channel，应按 Per-Tensor 处理。

Solver 在不知道原帖回复的情况下，直接命中了这个核心约束，并给出了与 Gold 一致的量化调整方向。

这种题目就可以判成真正的 Exact。

这里和 C01 的差别很明显。

C10：

核心约束命中 → 调整方向一致 → 没有关键冲突。

C01：

提供了相关工程建议 → 但没有命中真实根因。

而 C02 则属于第三种情况：

问题页面本身真实存在，但 Gold 独立性不够 → 不进入正式成绩。

图3｜Exp06-v2 中三类典型结果：C10 直接命中核心 Gold；C01 有工程价值但没有命中真实主因；C02 因 Gold 独立性不足被主动剔除。

这三种结果放在一起，比单独看一个“95.6%”对我更有意义。

九、真实社区 Gold 也不是天然正确

这次还有一个以前没有这么明显的问题：

Gold 本身也需要审。

社区回复不等于官方标准答案。

有些帖子存在：

• 用户明确回复“按照这个方法修改后恢复正常”；

• 用户只是回复“好的，谢谢”；

• 管理员在长时间没有后续反馈以后关闭帖子；

• 回复本身可能对应旧版本工具链。

这几种情况的证据强度完全不同。

这次 9 个有效主案例中：

• 2 个案例有原作者明确实测反馈；

• 2 个案例有原作者正向确认或接受答复；

• 5 个案例是在答疑后长期没有进一步反馈，随后关闭。

所以我没有再把它们统一写成：

“9个问题全部被官方确认解决。”

这并不准确。

同样，社区用户的等级也不能自动等价于“官方专家”“架构师”或“研发团队”。

这次我只保留页面能够公开验证的信息。

对我来说，Exp06 后来真正增加的不是一个“社区题库”。

而是多了两层审核：

Source Audit：这个问题是不是真实存在？

以及：

Gold Audit：这个参考答案到底有多可信？

十、这次 95.6% 到底能说明什么？

最终主评测集得分是：

86 / 90，平均 9.56 / 10。

9 个有效案例全部达到 Partial Match 或以上。

但这个结果依然不能写成：

“OE-Skills 解决真实 J6 问题的准确率是 95.6%。”

它不是一个大样本统计意义上的准确率。

而且这次只有 9 个有效案例。

帖子类型也不可能覆盖整个征程6工具链。

更准确的说法应该是：

在本次 9 个经过来源与 Gold 审计的真实社区案例中，7 个回答与外部 Gold 完全吻合，2 个部分吻合，没有出现完全误诊。

这个结论已经够用了。

不需要再把它包装得更大。

十一、这次实验对我最大的提醒，其实不是分数

如果只看最后的 7 / 9，很容易把 Exp06 理解成一次“OE-Skills 表现不错”的实验。

但我觉得真正有价值的是中间暴露出来的三个问题。

第一个：

Agent 甚至会幻觉实验数据源。

第一版 Exp06 就是最直接的例子。

如果不检查 URL，我甚至可能拿一套不存在的社区问题写出一篇看起来非常严谨的 benchmark。

第二个：

覆盖了正确知识，不等于命中了真实故障。

C01 和 C04 都证明了这一点。

第三个：

Gold 也需要验证。

真实社区里的回复有强有弱，有用户实测闭环，也有只是长时间无反馈后被管理员关闭。

所以一个真正可信的 Agent 实验至少需要：

问题来源审计
→ 隔离盲测
→ 外部 Gold
→ Gold 可信度审计
→ 技术事实复核
→ 最终评分

比我前几次实验多了不少麻烦。

但我现在反而更愿意相信这样的结果。

十二、从自己出题，到让真实问题检验 Agent

回头看前六次实验，我感觉测试重点一直在往外推。

最开始，我只是在问：

Router 有没有选对 Skill？

后来变成：

Skills / MCP 有没有让回答更可靠？

再后来是：

Agent 能不能规划完整工具链？

第五次是：

它知不知道什么时候不能声称已经完成？

而这一次终于变成：

真正的开发者碰到问题时，它能不能在不知道标准答案的情况下，把问题诊断到正确方向？

至少在这 9 个有效案例里，结果还不错。

但 C01 和 C04 也提醒我：

“知道很多”仍然不等于“诊断正确”。

如果以后真的把 Agent 放进征程6开发流程里，我觉得下一步比继续测问答更有意义的事情，应该是：

让它真正生成工程产物，然后审计这些产物本身。

比如：

它生成的 UCP C++ 代码，到底能不能经得住 API、生命周期、Tensor、Cache 和错误处理的逐项检查？

这可能就是下一次实验要解决的问题。

参考资料

• HorizonRobotics / OE-Skills
  https://github.com/HorizonRobotics/OE-Skills
• 地平线 OpenExplorer 官方文档
  https://docs.oe.horizon.auto/
• 地平线开发者社区
  https://developer.horizon.auto/
• Exp06-v2 代表案例 C01：ScatterND 量化 / 索引问题
  https://developer.horizon.auto/forum/13774
• Exp06-v2 代表案例 C04：YOLOv11-seg / NV12 输入问题
  https://developer.horizon.auto/forum/13748
• Exp06-v2 代表案例 C10：J6M Activation Per-Channel 支持问题
  https://developer.horizon.auto/forum/13666

本文记录的是 OE-Skills 在真实征程6社区问题上的盲测实验。实验未执行真实 PTQ、HBDK 编译、HBM 推理或 J6 板端测试；86/90 为本文预注册评分规范下的回答质量得分，不代表征程6真实问题的总体准确率或部署成功率。