做过一次硬件项目，往往留下了不少东西：代码在仓库里，接线记录在聊天里，设备参数在产品网页上，最近一次成功的配置又保存在某个人的电脑里。换一个伙伴加入，或者换一个 AI 助手接着做，就得重新解释。
Google Cloud 推出的 Open Knowledge Format（OKF），讨论的就是这些知识怎样保存与交换。首发介绍面向需要给 Agent 提供业务知识和技术上下文的团队；对我们做 AI 硬件的人来说，它也值得用来想一想：项目怎样才能被别人接着做？[1]
01｜用普通文件保存知识，让不同工具都能读
OKF 的基本形式很简单：一个 Markdown 文件目录。每份概念文档顶部放 YAML 文件头，下面是正文；文档之间用普通 Markdown 链接关联。概念可以是一张数据表、一个指标、一份操作说明，也可以是项目里的设备或接口。[1][2]
文件头里始终必填的字段是 type，用来说明这份文档属于哪一类。标题、描述和标签等字段帮助查找，正文则解释具体内容。这样的资料可以放在 Git 仓库里，既能让人阅读，也便于工具解析。
它规范的是知识文件，不负责让软件相互调用，也不会直接控制电机。Google 提供的 HTML 图形浏览器是展示这些文件的一种工具，并不是要求所有知识都写成 HTML 或 SVG。[1]
02｜让接线、程序和测试记录能互相找到
如果把这个办法用到小硬件项目，可以给开发板、显示接口和测试记录分别建文件，再从项目说明中链接过去。改了接线，就能找到相关程序与测试；换了屏幕，也知道哪些说明需要一起修改。
一个桌面信息屏的设备记录，可以从下面这样的小文件开始。board 和 display 是为项目增加的字段：
---
type: Hardware Project
title: 桌面信息屏
description: 显示日程，用按键切换页面。
tags: [ESP32-S3, OLED, display]
board: Seeed Studio XIAO ESP32-S3
display: SSD1306 128x64
---
# 交互规则
默认显示当天日程；短按切换到待办页面。
# 开发记录
见 [显示接口](./interfaces/oled.md)
和 [按键测试](./tests/button.md)。
不必先把所有历史文件搬进新系统。挑一个还在继续做的项目，先把最常被问到的几件事写清楚：用哪块板、连接什么、怎样运行、最近哪里改过。下一位伙伴能接着做，再慢慢扩充。
03｜知识能读取之后，还要知道它是否仍然适用
Google 首发介绍的是 v0.1，当前独立仓库中的规范为 v0.2。新版本进一步约定了来源、生成与确认记录，以及资料状态和过期时间等字段。[2]
这对硬件项目很实用。同名开发板可能有不同版本，旧接线说明也可能不适用于新的配置。文档应当让人找到依据，知道它对应哪次修改，而不只是保存一句“这样接就可以”。格式本身不会替我们保证内容正确，记录和更新仍然要做。
对 AI 造物社区来说，可以先把一个完成的小作品整理成可交接的项目包：设备说明、代码入口、操作步骤和测试记录互相链接。青少年留下自己刚解决的问题，工程伙伴补充实现细节，下一次 Study Group 就能从这些记录继续，而不用把同一段调试重新做一遍。