AI 硬件起步指南

｜2026 年，AI 硬件的起点为什么变了？

先看同一件产品，在两个不同的时刻里，AI 分别做了什么。

桌边有一枚实体按键。人在电脑里选中一段杂乱文字，按下按键；AI 把文字整理成三条清楚的待办，再把结果送回原来的窗口。人检查结果，决定采用还是修改。

使用这件产品时，AI 直接参与“把杂乱文字整理成可用结果”。这时，AI 是产品能力的一部分。

开发这件产品时，开发者可以让 AI 查资料、阅读现有工程、修改按键和灯光逻辑，再调用工具构建程序、查看报错。这时，AI 是开发工具的一部分。

这两种参与方式解决的不是同一个问题。把 AI 做进产品，是为产品增加过去没有的理解、判断或生成能力；用 AI 来做产品，是让开发者在查资料、读工程、改程序和调用工具时得到帮助。前者回答“产品因此会做什么”，后者回答“人怎样更快把产品做出来”。先看产品这一侧，可以沿着这条任务链理解 AI 怎样参与工作：

现实中发生一件事 → 设备看见、听见或被按下 → AI 参与理解或判断 → 设备反馈或动作 → 人确认事情有没有办成

产品一侧，Google 的 Live API 能力文档和 OpenAI 的 Realtime API 发布说明展示了 AI 持续接收声音、画面和文字并调用工具的能力。研发一侧，一些官方开发工具已经允许经过授权的 AI 发起构建、烧录和状态查询，而不只是给出一段代码，乐鑫的 ESP-IDF Tools MCP 服务器就是一个例子。API（应用程序接口）可以先理解为软件之间约定好的入口；MCP（模型上下文协议）可以先理解为让 AI 连接资料和工具的一套约定。

这些能力说明，AI 正在同时改变产品能力和研发方式：把 AI 做进产品，是让 AI 参与用户完成任务；用 AI 来做产品，是让 AI 参与开发者完成研发。 同一个项目可以同时用到两条路径，但它们解决的是两类不同的问题。

AI 硬件的功能，需要程序和设备一起完成

AI 可以帮人阅读工程、修改代码、构建程序，也能根据报错和运行信息继续排查。在软件开发中，程序能够正常运行、测试没有报错，往往已经能说明很多问题。硬件开发也要做这些检查，但还不够。

AI 硬件有真实的按键、扬声器、传感器和连接，不只是在电脑里运行的一段程序。程序发出的指令最终要落到这些真实部件上，所以硬件开发还要多问一句：真实设备给出的反馈符合要求吗？电脑显示“编译成功”或“测试通过”，只能说明软件检查已经通过；真实的按键有没有响应、扬声器有没有声音、传感器读数是否合理，还要由设备本身回答。

一次桌面设备开发中，开发者想让设备在操作完成后发出一声提示音。AI 帮他找到需要修改的位置，很快做出一版可以测试的程序。

软件编译和开发测试都通过了，程序也成功写进设备。但设备重新启动后，按键和连接都能使用，扬声器却没有声音。电脑里的结果显示程序已经准备好了，真机反馈却说明这项功能还没有完成。

开发者不再只盯着电脑里的成功信息，而是根据真机现象继续排查。按键和连接都正常，说明设备没有整体失效，问题更可能出在发声部分。他让 AI 帮忙对照资料，逐项检查扬声器、连接和程序里的声音设置，最后发现软件设置与真实部件并不匹配。调整后再次测试，设备终于发出了提示音。

这段经历把硬件开发的检查顺序说清楚了：

1. 先看软件结果：编译和开发测试都已经通过，程序能够进入设备。
2. 再看硬件反馈：设备能够启动，但目标部件没有按预期工作。
3. 根据真机现象解决问题：检查真实部件、连接和软件设置，调整后再次验证。

程序通过检查，设备也给出符合要求的反馈，才能说明程序和设备一起完成了这项功能。

2026 年的新方法：人做判断，AI 加速开发

不要学，直接开干。

在 AI 时代，先把学习计划排满，等学完以后再动手，就是执行力低下的表现。刚入门的人，不必先把电子原理、电路设计、固件开发和 3D 建模全部学完，也不必从零画一块电路板。先让 AI 帮你做出一个可以检查的第一版，再围绕真机暴露的问题补知识。

截至 2026 年 8 月，AI 已经可以参与多个开发环节：阅读元器件资料和现有工程，协助编写、修改、构建和写入固件，理解电路连接并在人确认后调整原理图，也可以在 3D 设计环境中形成和修改外壳初稿。这些能力的成熟度和适用范围不同，却共同说明了一件事：AI 已经从“告诉你怎么做”，走向“参与把第一版做出来”。

新的分工可以记成三步：

人决定值不值得做 → AI 帮忙做出第一版 → 真机回答有没有做成

人的第一项工作，不是亲手完成每一个技术环节，而是先把问题说清楚：谁遇到了什么麻烦，为什么需要一件硬件，什么变化才算有用。AI 可以帮助查资料、读工程、写和改固件、理解或修改原理图、形成 3D 外壳初稿；人再根据真实设备的按键、声音、灯光、传感器、供电和结构表现，决定继续修改、补哪块知识，还是停止投入。

电子工程知识没有消失。它只是从“开始前必须全部学完的门槛”，变成“真机暴露问题后，围绕当前问题按需补上的能力”。涉及电气安全、结构可靠性和生产交付时，仍要由具备相应经验的人审核和负责。

能更快做出第一版，不代表每个想法都值得做成硬件。接下来先问：这件事为什么一定要发生在现实现场，手机、网页或现有设备为什么不够？

｜这个想法，真的需要做成一件硬件吗？

一个想法要走到硬件产品，先要完成一次不同于纯软件的需求确认：问题是否真实，为什么需要增加实体设备，以及设备进入现实世界以后会影响谁。这里先回答三件事：软件方案具体卡在哪里，硬件怎样在现场产生价值，以及使用者、拥有者和未使用者分别得到或承担什么。完成这三项判断之后，才能继续检查整套系统是否能够完成任务，并进入产品定义与量产。

为什么这个需求不能只靠软件？

先别急着讨论产品形态。先确认这个问题是否反复发生，现有方法具体卡在哪里，以及它造成的麻烦是否值得继续解决。

如果现有的软件和自动化已经能把任务可靠地完成，就没有必要为了“像 AI 硬件”再增加一件设备。硬件值得出现，通常是因为任务发生在现实现场，而纯软件方案在某个环节不够顺手、不够及时，或者无法直接感知和作用于现实环境。

AI 硬件通常仍会与手机、电脑和云端协同。判断重点不在哪一种载体更“高级”，而在事情发生的那一刻，怎样组合最容易让任务真正完成。

可以沿着五个方向检查。它们分别对应五类现实限制：

• 操作成本：任务是否因为步骤太多而难以坚持？ 如果每次都要掏出手机、解锁、寻找页面再操作，人可能因为麻烦而少用或不用。此时要判断，留在现场的按键、旋钮或语音入口，能不能把关键动作缩短。
• 注意力占用：任务发生时，人能否方便地看屏幕和操作？ 做饭、搬运、维修或照看他人时，盯着屏幕可能不方便，甚至不安全。此时要判断，设备能否用声音、灯光或简单动作完成输入和反馈。
• 现场反馈：结果是否必须在环境中持续可见或可听？ 门口是否有人、机器是否完成、桌面任务是否结束，这些状态如果只藏在应用里，人就可能错过。此时要判断，现场看得见或听得到的反馈是否更及时。
• 物理动作：任务是否需要感知或改变现实环境？ 开灯、开门、测量、移动或提醒附近的人，都需要设备去感知或推动现实中的东西。软件可以发出指令，却不能单独完成这些动作。
• 现场条件：网络、隐私和场地规则是否改变方案？ 网络延迟、断网、隐私要求、噪声、光线和场地规则，都会影响系统能不能工作。此时要判断，哪些能力必须留在本地，断网以后还要保留什么。

这些问题不是为了替硬件找理由，而是为了找到软件方案具体卡在哪里。只有硬件能够解决其中一个真实限制，它才值得增加成本、维护和使用负担。如果答案仍然只是“更酷”“更像未来”或“多了一个 AI 入口”，先继续观察场景，不必急着画外壳。

这个判断回答：问题是否反复发生，并且存在一个值得用硬件解决的现实限制？

硬件的价值，怎样在现实现场发生？

OpenAI Supply Co. 与 Work Louder 联合设计的 Codex Micro 是一块面向 Codex 工作流的桌面小键盘。官方页面介绍，每个 Agent 键都能用实时 RGB 灯光显示对应任务正处于思考、运行、等待还是完成状态。人不必先切回每个聊天窗口，抬眼看键盘，就能知道哪个任务需要关注。

这些灯光不是从 0% 走到 100% 的进度条。它们回答的是“任务现在处于什么状态”，让原本藏在聊天窗口里的变化来到人的手边。特别是同时运行多个任务时，人可以先做别的事，等键盘提示需要关注，再回到对应窗口。

Codex Micro 最值得保留的不是某个快捷键，而是“Agent 什么时候需要人介入”这件事终于有了一个屏幕之外的位置。

从使用者的角度看，这个价值并不来自一套看起来多复杂的技术。哪怕只是把几种状态放到实体按键上，只要它减少了反复切换窗口、盯着屏幕等待或错过提醒，就解决了一个具体问题。

AI 硬件的价值，不取决于技术看起来多复杂，而取决于它是否解决了一个真实、反复发生的问题。

实体设备会影响谁？

确认硬件能够解决现实限制之后，还不能马上认定产品成立。硬件会以实体进入工作台、家庭或公共空间；它不仅服务使用者，也会让拥有者承担持续成本，并可能改变周围人的环境。

对使用者来说，一个功能有价值只是第一步。每增加一件硬件，人还要多承担购买、携带、充电、学习和维修；如果它依赖账户与云服务，还要面对授权、订阅、数据保存和停服后的处理。

第一版产品最好先顺着人原有的动作进入场景。本来就在工作台核对，就把提醒留在工作台；本来会按键，就让新能力仍从按键进入。这样做不是要求产品永远不能改变习惯，而是先用尽可能少的新动作，证明这项能力值得被留下。

使用者得到的方便，能不能抵过拥有者新增的购买、携带、充电、学习和维护负担？

产品还会产生外部影响：没有主动使用它的人，也可能被它改变。佩戴者觉得眼镜方便，旁边的人却要判断它是否正在记录；员工觉得桌面设备省事，组织可能有保密、网络或场地规定；家中的常驻设备由一个人购买，其他成员却共同生活在它的感知范围内。

法国数据保护机构 CNIL 于 2026 年发布的智能眼镜提醒指出，录制指示灯的提示范围有限，部分使用场景甚至没有提示。即使灯亮着，也不能因此认定旁观者已经知道或同意被记录。具体产品是否合规，还要结合设备、使用场景和当地规则判断。

因此，硬件的需求确认不能只问目标使用者想不想要，还要确认新增负担是否可以接受，未使用者受到的影响是否能够被说明和控制。

一件 AI 硬件的需求成立，要同时满足三件事：使用者得到明确价值，拥有者愿意承担持续负担，未使用者受到的影响可以被说明和控制。

｜一件 AI 硬件，是由哪些部分组成的？

一件 AI 硬件，可能由哪些部分组成？

看到一件 AI 硬件，最容易先看到外壳、按键和电路板。但这些只是能拿在手里的设备本体。要让设备真正听懂一句话、识别一个物体或完成一个动作，还需要程序和 AI 一起工作。

为了先建立一幅清楚的画面，可以把一件 AI 硬件看成两个部分：

• 设备本体：这是能看见、摸到的部分。它通常包含外壳与结构、电池或电源，接收信息的按键、麦克风、摄像头和传感器，运行程序的微控制器、处理器和存储，用于传输数据的 USB、蓝牙或网络模块，以及输出结果的灯光、扬声器、屏幕或马达。
• 程序与 AI：固件和应用程序负责控制设备、连接各个部件，AI 模型负责识别、理解、判断或生成。它们把设备收到的信息变成结果，再让设备给出反馈或执行动作。

AI 不一定全部运行在设备里面。需要快速反应或断网可用的任务，可以由设备里的端侧模型完成；需要更大模型处理的任务，也可以通过网络调用云端 AI 的 API。实际产品还可以采用端云协同，让设备本地先完成一部分处理，再把更复杂的任务交给云端。

延伸阅读：想直观理解“模型直接运行在设备上”是什么样，可以阅读《从零训练到真板运行：我们怎样把中文模型放进 ESP32》。这是一篇真实的 ESP32 端侧模型实践记录，可作为理解端侧模型的具体案例。

安全、隐私、权限、更新和维护，是这两个部分在实际使用中都要满足的要求，不是与按键、芯片或程序并列的第三种组成。

一件 AI 硬件，就是一台能够感知现实、进行判断并作出反馈的实体设备；它需要设备本体与程序、AI 一起工作。

一块开发板上，都装了什么？

前面把一件 AI 硬件分成设备本体、程序与 AI。现在先把镜头拉近，只看设备本体里最常见的电子部分：开发板。

先分清四个容易混在一起的词：

• PCB（印刷电路板）：用来安装和连接元器件的电路底板。课程里说“PCB”时，通常指还没有装上元器件的裸板。它像一块“地基和道路”，让元器件有地方安装，也让电源和信号按照设计互相连接。
• 元器件：需要安装到 PCB 上、各自承担一项工作的零件，例如主控、存储芯片、麦克风、灯和接口。
• PCBA（装配好的电路板）：把元器件焊接或装配到 PCB 上以后得到的电路板。这个词说明“板已经装好”，不说明它拿来做什么。
• 开发板：为了开发、调试、验证或学习而设计的一类板。从制造状态看，它通常是一块 PCBA；从用途看，它会把供电、程序写入或调试接口、常用输入输出提前做好，方便人直接写程序、接外设和观察结果。产品内部的控制板也可能是 PCBA，但如果不是为了方便开发和验证而设计，一般不叫开发板。

以这块桌面开发板为例，先看正面。正面放着人会直接操作和观察的部件：

• 接收操作：八枚机械按键和一枚可以旋转、按下的旋钮，把人的动作变成设备能够读取的信号。
• 接收声音：麦克风把现场声音变成设备能够处理的数据。
• 给出反馈：五颗 RGB 彩色灯用颜色和亮灭显示状态。
• 供电与连接：USB-C 接口给开发板供电，也可以连接电脑、传输数据和写入固件。
• 启动与恢复：电源开关负责开关机；BOOT 键主要用于固件写入或设备恢复，不是日常功能键。

再翻到背面，就会看到负责运行、记忆、连接和供电的核心元器件：

• MCU／主控芯片：运行固件，读取按键和麦克风传来的信息，再向灯光、声音或其他部件发出命令。
• Flash：断电以后仍然保存固件和配置，像开发板的“长期储物柜”。
• PSRAM：保存程序运行时暂时需要的数据，像工作的“临时桌面”。在这块板上，它集成在主控芯片内部，不能在板上找到另一颗名叫 PSRAM 的独立芯片。
• 无线天线与接口：让开发板通过 Wi-Fi、蓝牙或 USB 与其他设备交换信息。
• 电源与音频电路：把电力送到各个部件，也让麦克风收音，并为连接扬声器和发出声音准备好电路。

这些元器件安装好以后，开发板只是“具备了做事的条件”。它还需要固件：

固件是运行在开发板里的程序。元器件决定它“能做什么”，固件决定它“什么时候做、具体怎么做”。

想继续看懂这些词，可以按四组打开对应图解：

• 先认识一块板：开发板看整体用途；PCB看底板和连线；原理图看电路的连接关系；ESP32-S3看这块板可能使用的一类具体主控芯片。

• 再看板上的核心资源：MCU／主控芯片负责运行程序；Flash负责长期保存；PSRAM提供运行时临时空间；GPIO／通用输入输出让程序通过引脚接收或发出信号。

• 看懂设备怎样感知与反馈：传感器让环境变化进入设备；麦克风让声音进入设备；扬声器把声音带回现场。

• 看懂程序怎样来到真机：固件是运行在板里的程序；ESP-IDF是开发 ESP32 固件的一套框架和工具；构建／编译把源码变成设备能运行的文件；烧录／写入把它写进板里；日志／串口消息把设备的运行情况返回给人和 AI。

PCB 说的是底板，PCBA 说的是“元器件已经装好”，开发板说的是“这块板被设计来帮助开发和验证”。写入固件以后，板上的元器件才会按照程序一起工作。

为什么先从同一块开发板开始？

很多人第一次做电子硬件，桌面上会先出现一块面包板、几根跳线，以及分开的按键、灯和传感器。把线插到不同位置，就能很快验证“按下按键，灯会不会亮”“传感器能不能读到变化”。这种方式改得快，很适合最早期的试错。

但它也有明显限制：跳线容易松，同样的功能可能因为一根线接在不同位置而表现不同。别人即使看到相同的报错，也未必面对同一套连接。要让一群刚入门的人能够使用同一份资料、复现同一个问题，就需要一个更稳定的共同起点。

硬件开发中常见的板子形态，可以先这样理解：

• 面包板与外接模块：把主控、按键、灯、传感器等现成零件临时接在一起，适合快速验证想法，但接线多、容易松动。
• 通用开发板：把主控、供电、程序写入接口和常用输入输出预先装好，需要新功能时再外接模块，适合学习、开发和功能验证。
• 核心板、扩展板与功能模块：核心板集中主控、存储等基础电路；扩展板增加接口和供电；功能模块通常只提供传感、通信或声音等一种能力。它们可以像积木一样组合。
• 自定义 PCBA：功能和尺寸逐渐稳定以后，再把真正需要的元器件和连接整合到自己的电路板上，更接近最终产品。

这些形态不是从“低级”到“高级”的固定等级，而是服务于不同阶段。面包板方便改线，开发板方便反复写程序和接外设，核心板与模块方便组合，自定义 PCBA 则让尺寸、成本和结构更贴近具体产品。

课程先使用同一块开发板，是为了建立共同的硬件上下文：相同的板型和版本、元器件位置、引脚与连接关系、基线固件、资料名称和日志方式。一个人遇到按键没有反应、灯光状态不对或程序写入失败时，其他人面对的是可以复现的同一类问题，说明、日志和解决办法也更容易互相复用。AI 读取同一套硬件资料后，也更容易基于一致的事实帮助排查。

统一开发板不等于统一最终作品。共同基线跑通以后，仍然可以外接不同的传感器、灯、扬声器或马达，改变外壳与交互方式，甚至继续设计自己的 PCBA。

统一的是开发时的硬件事实、资料和排错上下文，不是最后的产品形态。

｜一个 AI 硬件产品，怎样从定义走到量产？

看懂一件 AI 硬件由哪些部分组成以后，还要知道这些部分怎样从方案走进真实生产。量产不是开发结束后的最后一步，而是从产品定义开始，就在影响外观、结构、电路、软件、成本和交付方式。

量产，从产品定义的第一天就开始

很多人会把量产理解成“样机做好以后，找一家工厂多做几台”。真正的流程要更早开始。产品准备卖给谁、解决什么问题、目标价格是多少、预计生产多少台、会在什么环境中使用，都会改变芯片和器件选择、外壳工艺、连接方式、测试方法与包装运输。

产品定义 → 产品与系统方案 → 工程样机 → EVT 工程验证 → DVT 设计验证 → PVT 生产验证 → MP 量产与交付

EVT、DVT、PVT 是硬件行业常见的阶段叫法，不同团队的名称和边界可能略有不同。新手先记住：每一阶段都在回答一个更具体的问题。

• 产品定义：确定用户、场景、核心任务、目标价格、预计数量和使用环境，先回答“要做什么，为什么值得做”。
• 产品与系统方案：把外观、交互、结构、电路、芯片、传感器、固件、软件和 AI 的运行位置放进同一张方案，回答“哪些部分需要共同完成任务”。
• 工程样机：用第一版电路板、3D 打印结构和基础软件把核心任务跑起来，回答“这套想法能不能真的工作”。
• EVT（Engineering Validation Test，工程验证测试）：检查功能、功耗、声音、连接、散热和稳定性，回答“工程方案是否基本可行”。
• DVT（Design Validation Test，设计验证测试）：让外观与结构接近最终状态，推进开模与试模、可靠性测试、认证准备和完整软件，回答“接近最终产品的设计是否可靠”。
• PVT（Production Validation Test，生产验证测试）：在真实生产线上小批试产，检查装配、烧录、校准、测试治具（用于固定设备并自动检查的生产工具）、包装和追溯，回答“工厂能不能稳定地把它生产出来”。
• MP（Mass Production，批量生产）：进入批量生产与交付，持续管理来料、生产质量、抽检、包装、物流、售后和版本，回答“能不能持续交付质量接近的产品”。

开模通常不会在想法刚出现时立即开始。它要等结构和内部布局逐渐稳定，再随着设计验证推进。否则前面一个尺寸、接口或器件变化，都可能让模具返工。

从产品定义到量产，需要哪些角色一起工作？

上面的七个阶段不是七个人依次接力。真实项目里，同一个问题往往需要多个角色同时处理，岗位名称和分工也会因公司与项目规模而变化。新手不用先背组织架构，先认识一件 AI 硬件从定义到交付时常见的九种职责：

• 产品经理：把用户、场景、核心问题、第一版边界、目标成本和验证目标说清楚，让所有人朝同一个结果工作。
• 工业设计师：决定产品的形态、比例、使用方式、颜色、材料和表面效果，让技术变成容易理解和使用的实体。
• 结构工程师：安排内部器件怎样堆叠、固定和装配，并处理公差、散热、防护、可靠性和可制造性。
• 硬件工程师：选择芯片、传感器、电源和接口，设计原理图与 PCB，并验证电路是否稳定工作。
• 嵌入式工程师：编写固件和驱动，处理器件通信、实时控制和功耗，让板上的部件按预期协同。
• 软件工程师：开发手机、电脑或网页应用、设备服务和云端系统，让用户可以操作设备并接收结果。
• AI 工程师：决定模型在设备端还是云端运行，准备数据和评测方法，验证 AI 能否在真实场景里稳定完成任务。
• 制造与质量工程师：把样机变成可以重复生产的产品，处理物料、供应商、模具、工艺、装配、测试治具、认证、质量和包装。
• 品牌、市场与销售：确认产品怎样被用户理解、在哪里交付和怎样获得反馈，并把销售、使用与售后信息带回下一轮改进。

这些角色不会等到自己的“阶段”才出现。EVT 主要验证工程方案能否工作；DVT 需要设计、结构、电子、软件、AI 与质量一起确认接近最终状态的产品是否可靠；PVT 则让制造、供应链、质量和前面的工程角色在真实产线上检查装配、烧录、校准、测试、包装与追溯。验证节点的作用，就是让不同角色用同一台样机、同一份数据和同一组问题重新对齐。

包装、认证、隐私、模型或 API 的持续成本、断网与停服后的剩余能力，也不能留到最后才补。它们会反过来影响产品定义、器件和结构选择、软件方案、生产测试与售后方式，因此相应角色要比直觉中更早加入。

岗位名称可以不同，但结果必须能够接起来：产品决定做什么，各专业把它做成可验证的版本，制造与质量让它能稳定复制，市场与售后再把真实反馈带回下一轮。

01-05｜现在开工：先让 AI 读懂手里的开发板

前文已经分清两件事：产品里的 AI 要替使用者完成一个现实任务，开发中的 AI 则帮助人更快把这项能力做出来。现在真的坐到桌前，第一件事不是订制电路板，也不是先补完一整套电子工程知识。

先准备一块已经能够上电运行的开发板，以及能说明这块板的资料。让 AI 先读懂手里的硬件，再从一个清楚的功能开始开发。

第一版先不画板、不焊板。先让 AI 读懂一块现成开发板，再在真机上完成一个功能。

开工总览：四个环节，拿到第一次真机结果

开始一个 AI 硬件项目，先看清开工顺序。下面四个环节与后文四步一一对应；前一个环节的完成结果，会成为后一个环节的起点。

整理硬件资源 → 让 AI 判断并搭好开发环境 → 对齐编程 Agent 的项目上下文 → 选择工程起点，得到第一次真机结果

• 01｜整理硬件资源｜做什么：整理开发板实物与版本、原理图、PCB 正反面和 GPIO 引脚表，并把资料里的名称与手中实物逐项对上。｜完成标志：AI 能准确说出手里是哪块板、有哪些可用部件、它们怎样连接、程序从哪里读写。
• 02｜搭好开发环境｜做什么：让 AI 结合硬件资料、现有工程和当前电脑，判断应该复用、修复还是安装哪套开发环境；人确认后再执行。｜完成标志：同一份基线工程能在当前电脑上真实构建通过。
• 03｜对齐项目上下文｜做什么：让编程 Agent 通读硬件资料、环境记录和现有工程，先完整复述，再由人纠正误读。｜完成标志：人与 AI 对板型、环境、工程现状、已验证结果和未知项的理解一致。
• 04｜开始最小开发｜做什么：根据手里是否已有可运行工程，选择修改现有工程或从已验证起点新建；先确认最小方案，再只完成一个功能。｜完成标志：功能完成构建、写入和真机检查，真实设备给出可以继续判断的结果。

STEP 01 整理硬件资源，让 AI 读懂手里的开发板

先把与开发板有关的硬件资源整理出来，告诉 AI：手里是哪块板、有哪些可用部件、它们怎样连接、程序应该从哪里读取和控制。下面以 EasyInput V2.0 为例，先整理四类最基础的硬件资料。

把这四类硬件资源整理出来：

• 开发板实物与版本：先把桌上的实物和资料里的名字对上。EasyInput V2.0、固件里的板型名称 v2 和 PCB（印刷电路板）丝印 AI Keyboard V2.1 指向同一块硬件；部件说明图再把按键、旋钮、RGB 灯、麦克风、USB-C、电源开关和 BOOT 按键标到真实位置。交给 AI 后，它能知道“这次开发面对哪块板，手里有哪些可以直接使用的部件和接口”，不会把相似名称误认成不同板型。
• 原理图：原理图不是板子的照片，而是硬件的连接关系图。公开版两页原理图分别画出 USB、电源、按键、旋钮、RGB 灯、ESP32-S3 主控、存储、麦克风、功放和扬声器接口等电路。它告诉 AI“设计里有什么、怎样连接”，让 AI 能沿着信号和电源关系判断一个功能涉及哪些电路，而不是照着常见开发板经验猜。
• PCB 正反面：PCB 正反面图把原理图里的符号放回真实板面，用来确认部件、接口和电路实际位于哪里。它告诉 AI“要检查、测量或连接的对象在板子的哪一面、哪个位置”，也帮助人把 AI 提到的器件名称准确对应到手里的实物。
• GPIO 引脚表：GPIO（通用输入输出引脚）是主控芯片读按键、收声音、控制灯光等动作的程序入口。引脚表把每个部件对应到具体 GPIO，并注明它是输入、输出还是特殊信号。它告诉 AI“程序应该从哪里读取、向哪里控制”，避免功能逻辑正确，却写到了错误的引脚。

这四类资料回答的是同一件事：这块板在现实中是什么，设计里有什么，部件实际在哪里，程序应该从哪里读写。多人从同一块开发板和同一套硬件事实开始，遇到的问题才容易复现，也更容易一起解决。统一的是学习时的硬件上下文，不是最后要做成的产品形态。

先让 AI 认清手里的硬件，再让它参与开发；原理图告诉它“设计里有什么、怎样连接”，PCB 告诉它“东西实际在哪里”，引脚表告诉它“程序从哪里读写”。

STEP 02 让 AI 读完资料，再判断怎样搭开发环境

第一步已经把开发板实物、原理图、PCB 图和 GPIO 表整理出来。现在在电脑里为这次开发新建一个项目文件夹，把这些硬件资料和已经跑通过的固件工程放在一起。不要让资料散落在聊天记录、下载目录和几个压缩包里；AI 只有同时看见硬件与工程，才有机会把“手里是哪块板”和“这份代码怎样运行”对上。

一个够用的项目文件夹，可以先放三样东西：

• hardware/（硬件资料）：开发板说明、原理图、PCB 正反面和 GPIO 表。
• firmware/（固件工程）：已经在这块板上跑通过的固件，也就是运行在设备里的程序工程。
• README.md（项目说明）：写清开发板名称与版本、已知的开发环境基线，以及这次准备从哪个功能开始；暂时不知道的内容就标成“待确认”。

然后用 Codex、Claude Code 等能够读取本地项目文件的编程 Agent 打开整个项目文件夹。第一条指令可以直接这样说：

请先通读当前项目文件夹，不要修改文件，也不要安装工具。先告诉我你读了哪些资料，识别到哪块开发板、哪个主控芯片、这份工程使用什么开发框架和版本；再检查这台电脑的操作系统、处理器架构和已有工具，列出可以直接复用的部分、还缺少的部分，以及建议的搭建方案。所有安装或修复动作，先等我确认。

同一项目文件夹 → AI 通读硬件资料与现有工程 → AI 复述硬件与工程要求 → AI 检查本机 → 提出复用、修复或安装方案 → 人确认 → 搭建环境并完成基线构建

这里的 ESP-IDF，是 Espressif IoT Development Framework 的缩写，可以理解为“乐鑫为 ESP32 系列提供的官方开发框架”。它把编译工具、芯片驱动、常用软件库和项目配置组织在一起，让电脑能够把固件源码变成 ESP32-S3 可以运行的程序。

课程会使用配套的 ESP-IDF 环境 Skill（技能包） 协助完成这一步。Skill 可以先理解为一套交给 AI 的专业操作手册和工具：它帮助 AI 检查电脑里已经有什么，优先复用兼容环境；确实缺少时，再在用户允许后安装或修复；最后真实运行版本检查与构建命令。新手不需要先把 Python、工具链和依赖逐项学完，但要看懂 AI 为什么选择这套环境，以及它拿什么结果证明环境可用。

AI 的第一次输出不应该是一串安装日志，而应该是一次可以核对的复述：它读了哪些文件，确认了哪块板、哪个芯片和哪套工程要求；电脑里已经有什么，缺什么；接下来准备复用、修复还是安装什么。人看懂并确认这份判断以后，再让它借助 Skill 执行。

当同一份基线工程在这台电脑上再次构建成功，才算拿到可以共同继续的开发起点。它还不能证明每个硬件功能都正确，但已经先排除了“电脑环境没有对上”这个变量。

先把资料放到同一个项目文件夹，再让 AI 通读和复述；资料没有对齐前不安装，方案没有确认前不改电脑，真实构建通过后才算环境可用。

STEP 03 让编程 Agent 对齐完整项目上下文，再说第一个功能

第二步里，AI 读取资料是为了回答“这台电脑怎样让工程跑起来”。现在要换一个更完整的问题：编程 Agent 是否真正理解这是什么项目、已经做到哪里、接下来准备做什么。把第一步的硬件资料、第二步的环境验证记录和现有固件工程放进同一个项目上下文，再用 Codex、Claude Code 等能够读取项目文件并调用开发工具的编程 Agent 打开工程。

第一条指令仍然不是“帮我改代码”，而是：

请先阅读硬件资料、现有工程和环境记录，不要修改任何文件。请用自己的话完整复述：这是什么开发板，有哪些可用输入与输出；现有工程是为了解决什么问题，已经做到哪一步；工程使用什么框架、版本和目标芯片，怎样构建；哪些事实已经确认，哪些地方仍然没有答案。

让 Agent 复述，不是让它做一份文件摘要，而是检查它有没有把硬件、环境和工程连成同一个项目。人要拿它的回答与原始资料逐项对照：板型和引脚有没有认错，环境版本是否一致，工程当前要解决什么问题，哪些结果已经实际验证，哪些仍然未知。

能打开文件，不等于读懂项目；能准确复述并接受纠正，才算真正拿到了项目上下文。

只要有一项说错，或者把未知内容当成已知结论，就把对应资料和纠正意见再交给它，并要求重新复述。这个过程可以重复，直到它能准确说清“手里有什么、工程怎样运行、现在已经做到哪里、还有什么不知道”。

上下文对齐以后，人再告诉它第一个要实现的功能，并请它先复述任务目标。下一步再根据手里有没有可用工程选择起点；无论新建还是修改，都先形成最小开发方案，再由人确认。

第三步的结果不是代码，也不是架构方案，而是一份由编程 Agent 复述、经人核对无误的项目理解。

STEP 04 选择工程起点，让 AI 开始开发

项目上下文和第一个功能都对齐以后，才进入实际开发。这里有两个入口：如果手里已经有能在这块板上运行的工程，就从现有工程修改；如果没有可用工程，就让 AI 在已经确认的 ESP-IDF 环境中，从与目标芯片和板型相符的官方模板或已验证示例新建工程。区别只是起点，后面的开发方法相同。

先让 AI 说明它选择的工程起点：

• 新建工程：说明准备使用哪个官方模板或已验证示例，哪些硬件配置沿用第一步的事实资料，第一版只建立哪条最短链路。
• 修改已有工程：说明当前可运行基线在哪里，准备修改哪些文件或模块，哪些已经验证的配置和功能必须保留。

无论从哪个入口开始，第一轮都先不改代码。请 AI 交出一份最小开发方案，至少说清三件事：

• 系统与边界：这次需要固件、App、服务端或产品里的 Agent 中哪些部分；资料没有答案的地方继续标成未知。
• 实施顺序：先新建或修改什么，让哪条最短链路先成立，这一轮明确不做什么。
• 验证与回退：构建、写入、日志和真机分别检查什么；失败后怎样回到可用版本。

硬件资源 + 开发环境 + 项目需求 + 工程起点 → AI 交出最小开发方案 → 人确认 → AI 新建或修改工程 → 构建与写入 → 真机检查

开发开始以后，每次只完成方案里的一个最小改动，并保留五类信息：

• 本轮目标：这次只让哪一步成立，不顺手加入第二项功能。
• 修改记录：AI 改了哪些文件、配置和接口，为什么要改。
• 构建结果：工程是否在约定的 ESP-IDF 版本里成功生成固件，错误信息是什么。
• 写入与日志：程序是否写进正确的开发板，设备启动后实际运行到了哪里。
• 真机现象：按键、麦克风、灯光、电脑 App 或服务端分别发生了什么，和成功标准还有什么差距。

有可用基线时，优先在现有工程上做最小修改，因为已经跑通的配置和外设逻辑都是证据；只有没有可用基线，或现有工程与目标明显不相符时，才新建工程。两种入口都要先由人确认方案。构建通过和程序成功写入只是中间结果，最后仍由真实按键、麦克风、灯和电脑输入位置回答功能有没有完成。

JOTO 企业落地观察

• 企业部署AI硬件时，必须建立‘软件结果—硬件反馈—真机现象’三级验证机制。编译通过或测试成功仅表明程序逻辑无误，真实按键响应、扬声器发声、传感器读数等物理表现才是功能闭环的关键判据。这要求测试流程从纯仿真转向真机驱动，将设备本体纳入CI/CD验证链。
• 智能体工程需重新定义AI在硬件开发生命周期中的角色。当前AI已能参与元器件资料解读、固件修改、原理图理解及3D外壳初稿生成，但其输出必须由真机现象校准。这意味着智能体不能仅输出代码，还需关联物理信号（如GPIO状态、ADC读数）构建可验证的行为契约。
• RAG知识工程在硬件领域需适配强结构化文档体系。开发者依赖的ESP-IDF文档、芯片手册、原理图和PCB布局图具有严格术语与层级关系，RAG系统须能解析引脚定义、电源域划分、时序约束等硬性参数，并在AI生成固件时自动对齐真实板载资源（如PSRAM集成位置、麦克风电路路径）。
• AI安全治理须覆盖端侧模型与物理执行层的耦合风险。当AI直接生成控制扬声器、马达或无线模块的固件时，其输出可能绕过传统代码审查流程。治理重点应从模型幻觉扩展至物理副作用——例如错误配置音频寄存器导致扬声器持续高音啸叫，或误设GPIO驱动强度引发接口损坏。