系列: 与 AI 一起学编程

开启每周节奏

第零天:一份智能眼镜规格说明,强制约束着下游的每一个决策。

第零天:README 与规格说明 规格说明是强制约束。仓库在它之下上线。 AR1+ 智能眼镜规格说明 延迟预算 - AI 界面 - 传感器 运行时仓库 主循环、延迟追踪器、CI SDK 仓库 Unity + Unreal HelloAR 你的模型指挥模拟步骤 在运行时里,每一帧都如此——而不是在编辑器面板里外挂上去的
这不是一份营销文档——而是一个下游每一个架构决策都要回头对照的强制约束。

浏览器里的生成式内容还不错。锚定在你家厨房那面真实墙壁上的生成式内容才是产品。这就是这个被构建来在每一个模拟步骤都接受你的模型指挥的引擎——第零天,公开进行。

这个周六开始了这个博客的常规每周节奏。这篇文章下方的四篇是今年夏天早些时候的设计文档周六:智能体名单、演示套件、文件夹结构、代码开始之前的最后反思。从现在起,节奏是每周一次。这个博客要讲的东西并不新鲜。

十多年来,我一直在思考 AR 眼镜、锚定在真实世界的空间体验,以及驱动它们的运行时应有的正确形态。这些思考中的一部分在 2010 年代早期变成了专利,也就是至今仍支撑着我们现在所构建之物背后知识产权的眼镜形态资产。其中一部分变成了从未见天日的原型。大部分则是在我做其他工作时在后台运行着。

过去一年发生的变化是,世界其他部分终于赶上来了。算力足够小了。光学足够好了。云端 LLM 足够真实了。设备端推理足够快了。这个曾经”早了十年”的产品创意,终于成了一个可以发布的产品。

于是我开始发布。当前这一轮代码已经进行了几个月。这些提交存在于私有仓库中,我现在正一边清理一边把它们带向公开、整合进代码库。从这里开始,这个博客就是公开记录。

接下来几个月会是什么样子

这个周六计划的形态,作为即将到来之事的一个预告:

  • 运行时:今天早上,一份 AR1+ 智能眼镜规格说明草案摆在桌上。PDF、PowerPoint 和 Markdown 版本俱全,这样 LLM 可以对它进行推理,合作伙伴可以阅读它,设计师可以审查它。重点是规格说明本身,而不是格式。格式是为读者服务的。
  • 一个 main.cpp 和一个刚刚提交的运行时主循环骨架。
  • 一个延迟追踪器头文件和一个实现桩。延迟将是定义这个引擎的指标。
  • 一个 CI 中的 CMake 构建工作流,让每次推送都能在一台干净的机器上得到一次干净的构建。
  • 一份 Copilot 上手指南,让团队里的智能体知道这个团队是怎么运作的。

这个周六,SDK 仓库也搭建了自己的脚手架。一个早期的 Unity HelloAR 示例。一个早期的 Unreal HelloAR 示例。两种绑定的头文件骨架。一个包发布工作流。

这些都还不能发布。但这些都是在任何可发布的东西成为可能之前必须要有的东西。让两个仓库同时动起来、并在接缝处刻意耦合的这种模式,将会是一个反复出现的主题。

为什么公开的第一天就要有智能眼镜规格说明

规格说明是一件刻意为之的事情。大多数引擎会先选定一个运行时架构,然后再去物色可能适合在其上发布的产品。我是反过来做的。产品是人们佩戴在真实世界中的 AR 眼镜,引擎必须是适合这个产品的正确形态。所以规格说明要先写,哪怕它还很粗糙。

它不是一份营销文档。它是一个强制约束。它说明了引擎必须运行在什么样的硬件上,延迟预算是多少,AI 界面在实践中必须是什么样子。下游的每一个架构决策都可以指着这份规格说明问:”这个决策是在服务这份规格说明,还是在服务我更想构建的另一个引擎。”第二类正是引擎项目走向死亡的地方,我过去一直避开它,现在也打算继续避开它。

为什么第一天就要有 Copilot 指南

这个周末另一件刻意为之的事情是 Copilot 上手指南。第一版还很粗糙。它会被重写十次。但这份指南之所以存在,是因为智能体是团队的一部分,而团队需要知道团队是怎么运作的。

这份指南说明了:

  • 战略是什么,以及我们不打算构建的是哪种引擎
  • 路线图存放在哪里
  • issue 是如何提交、认领和关闭的
  • 一个好的 PR 应该是什么样子
  • 审查者应该做什么(这里的审查者有时是我,有时是另一个智能体)

“智能体阅读文档”这个框架不是噱头。它是运行一个工作流的现实需要,在这个工作流里,团队是周末的一个人加上持续值班的多个自主编码助手。如果指南写得差,工作就会差。如果指南写得好,工作就会正确,审查成本也会下降。

为什么现在公开这份日志

有几个理由。

这些专利是十年前的现有技术,但没人谈论它们,因为我们自己没有谈论过。 这个引擎所溯源的眼镜形态工作,多年来一直在悄悄地被授予和延续。我想让公开的工程记录指向真正的谱系。空间 AR 不是去年夏天有人才捡起来的新东西。这项工作可以追溯得更远。

合作伙伴的对话正在展开。 硬件合作伙伴、AI 实验室、工作室。当有一份他们可以阅读的公开工程记录,而不是一份演示文稿时,这些对话会变得更加犀利。演示文稿是打磨过的版本。这个博客是真实的版本。

这个开发工作流真的很新,值得展示。 从公开阶段第一天起,团队里就有 AI 智能体。多个供应商。并行分支。公开的 issue 队列。这些都不是为这个项目发明的;不寻常的是把它们全部同时用在一件如此严肃的事情上。我想在这一切发生的当下就把它写下来,趁教训还足够新鲜、还能诚实地谈论它们。

我想让合作伙伴和构建者从中得到什么

如果你在某个大型 AI 实验室,读到了这篇文章,这里是我的推销词。这个引擎被明确地构建为接受你的模型的指挥。不是外挂上去的。不是在一个编辑器面板里。而是在运行时里,在模拟步骤上,每一帧都是如此。架构决策正在此刻发生,公开进行,有明确的文档轨迹。如果你的模型在理解用户所站立的真实物理空间方面变得更好,这个引擎就是它能用这份理解去做点什么的地方。

如果你是一个考虑将来在此基础上构建的开发者,SDK 正在与运行时保持同步移动。截至这个周末,Unity 和 Unreal 示例已经种在 SDK 仓库里了。它们现在还不能用。但它们会的。这个阶段两种绑定都存在的原因,是为了让我永远不会走到六个月后运行时架构已经锁定、而 SDK 不得不扭曲自己去适应它的那一刻。

如果你是一个正在寻找早期信号的消费者,信号是这个:这个引擎正在围绕这样一个假设被构建:最有意思的体验是发生在真实场所中的 AR 体验,而 AI 是让这些体验产生反应的东西。浏览器里的生成式内容还不错。贴在你家厨房墙上的生成式内容才是真正的产品。

今天是周六。博客上线了。明天回去继续构建。

把你的模型放进真实世界,每一帧都如此

RakuAI 是一个为了在模拟步骤上接受你的模型指挥而构建的空间运行时——不是外挂上去的,而是栖居其中的。来看看 AI 层是如何接入的。

← 所有文章