系列: 与 AI 一起学编程

在芯片到货之前先验证硬件

在 AR2 Gen1 芯片到货之前构建好的验证测试框架。

验证你还没有的硬件 AR1+ 转向 AR2 Gen1——芯片发布前测试框架就已全绿 模拟轨迹AR1+ 时代数据 + 规格说明 验证测试框架(CI 中) 热与功耗 Wi-Fi 7 稳定性 传感器启动 CI 冒烟测试 + 指标 隐藏在功能开关之后——AR1+ 路径仍然全绿 AR2 Gen1 芯片还没摆上桌 在零部件发布之前,捕捉接口漂移、缺失的导出项、损坏的传感器流程 为一台我拿不到手的设备做出的 77 次提交
没有设备的测试框架仍然是一个测试框架——而编写它的过程会把规格说明逼成具体的数字。

面对等待芯片这件事,传统的答案是坐下来等。现代的答案是先把硬件下游的一切都构建出来,让它们在零部件到货之前就全部变绿——这样你的硬件就能比竞争对手更快地在 RakuAI 上发布。

一个我在工作周里反复琢磨的决定,在周末开始时就在厨房餐桌上等着我。把产品目标从 AR1+ 转向 AR2 Gen1。在芯片到货之前,先构建新规格说明下游的一切,这样等芯片真的到货时,验证从第一天就开始,而不是第九十天。

每一款硬件产品都会经历这样一个阶段:规格说明存在,验证计划存在,测试框架存在,而真正的芯片却不存在。传统的答案是坐下来等。现代的答案是先把硬件下游的一切都构建出来,让它们在零部件发布之前就全部变绿。

这个周末就是如此。目标平台正式从 AR1+ 转向 AR2 Gen1,工程上的应对是在我们任何人碰到新平台之前,立即构建新平台将会需要的验证基础设施。

落地了什么

五件事,全部在这个周末落地:

  • AR2 Gen1 设备启动与传感器集成基础设施
  • 一套 Wi-Fi 7 连接性与追踪稳定性测试套件
  • 一个热与功耗验证框架
  • 带有指标分析和报告的 CI 冒烟测试
  • AR2 Gen1 硬件验证文档与生产标准规格说明

所有这些都由功能开关把关,这样 AR1+ 的代码路径仍然可以工作,现有运行时中的任何东西都不会退化。落地这些 PR 的智能体正确地遵守了这个无聊的纪律:每一个新文件都隐藏在一个构建标志之后,每一个新增的 API 都不会破坏兼容性,每一个测试都在 CI 中运行,即便没有 AR2 设备可供它运行测试。这些测试是模拟的。这种模拟已经足够好,能够捕捉接口漂移、缺失的导出项和损坏的传感器流程。

这是一个 77 次提交的周末。其中大多数提交,都是为了一台我拿不到手的设备。

为什么这样做是明智的

几个理由。

随硬件一起发布的硬件验证,就是晚了六个月才发布的硬件验证。 这个周末写好的热与功耗框架,会在第一台 AR2 开发套件到达我桌上的当天就被用上,而不是三个月之后。这个平台的第一次热退化会被一个现有的测试捕捉到,而不是靠一个人类注意到设备发烫。

没有设备的测试框架仍然是一个测试框架。 它针对模拟的传感器轨迹运行。这些轨迹来自 AR1+ 时代和规格说明。它们并不完美。它们能捕捉接口错误、集成错误和指标采集错误。它们捕捉不到只有在真实芯片下才会出现的错误。这没关系。它们能捕捉到的错误,正是我们本来要在真实硬件到手的第一周花时间去排查的错误,而现在我们不必这么做了。

编写测试框架的过程本身厘清了规格说明。 到周日晚上落地的生产标准文档,有一半在这个周末开始时只是模糊的意图。编写验证测试把规格说明逼成了具体的数字。帧预算。散热包络。Wi-Fi 7 稳定性阈值。测试框架让这份文档变得清晰锐利。那才是真正的交付物。

智能体是如何处理这次转向的

从 AR1+ 转向 AR2 Gen1 这次转向,第一次并没有处理得很干净。周末中途,智能体落地了一个 PR,其中在本应写”AR2”的新代码路径里引用了”AR1+”。这是因为 issue 的框定没有标出这次改名。修复方式是一个单独的 PR,标题为”Fix AR1+ vs AR2 device discrepancy in documentation and copilot instructions”(修复文档和 copilot 指令中 AR1+ 与 AR2 设备的不一致),它扫过了 121 处单独的引用,并把它们统一了起来。

这种事情不会发生在一个单独的人类写所有代码的情况下,因为那个人类会随手改名。它发生在一个智能体驱动的工作流里,原因是智能体接手了一个早于改名就存在的 issue,并忠实地写下了旧名字。补救办法是让智能体阅读作为输入的文档,与当前的现实完全保持同步,并把改名 PR 当作独立的一块工作来写。

我正在构建一个系统,在这个系统里,智能体的文档也是团队的文档。当文档撒谎时,智能体也会朝同一个方向撒谎。这是我正试图做对的这个工作流的一个特性,而不是一个缺陷。

Wi-Fi 7 测试套件,具体来说

这是我在这个周末最引以为豪的一项工作。

AR2 Gen1 的规格说明假定使用 Wi-Fi 7 连接来进行卸载渲染和有线计算。Wi-Fi 7 在实践中并不像 Wi-Fi 6E 那样稳定,失败模式也不同。这个周末写的测试套件描述了这一系列失败模式(吞吐量下降、间歇性丢失、重新认证风暴),并界定了运行时在每种情况下的行为边界。运行时无法容忍每一种失败。测试套件的工作是明确指出运行时能优雅降级度过哪些失败、哪些失败会大声报错。

这很重要,因为用户正在经历的 AR 体验不能在连接出现波动时卡顿。运行时必须在连接波动持续一帧、两帧或二十帧的情况下,回退到本地渲染,并在连接恢复后重新收敛。这个逻辑此前只是规格说明中的模糊意图。这个周末之后,它变成了具体的测试用例。

我想让合作伙伴从中得到什么

两件事。

如果你是一个考虑 AR 眼镜的硬件合作伙伴,这个引擎随附的验证框架,会是它比竞争对手更快地在你的硬件上发布的原因之一。这个框架是可移植的。新增一个设备目标只需要几百行代码,再加上设备特定的测试向量。昂贵的那部分已经提前付清了。

如果你是一个考虑延迟敏感型设备端推理的 AI 实验室,AR2 Gen1 规格说明所假定的延迟预算是公开的。从传感器到渲染的端到端轨迹现在正在被检测,所以当你的模型必须适配这个预算时,你可以看到实际留给推理的预算还剩多少。这就是我想在十一月与你展开的对话。

周末 77 次提交。以文档收尾,这正是这种周末该有的正确收尾方式。

在一个已经为你的芯片做好准备的运行时上发布

一个可移植的验证框架意味着新增一个设备目标只需要几百行代码加上测试向量——昂贵的那部分已经提前付清了。带上你的硬件来吧。

← 所有文章