跑通第一条开发链路

把下面的提示词复制给 AI。这一步只让它查看固件项目，确认按键代码在哪里，以及当前开发板哪些地方不能随意改。

AI 先认清了项目和开发板，后面才不会把其他 ESP32 板子的做法误用到这块板上。

• AI 明确本次开发在固件侧完成，并说清它要怎样接入 App 已有的 Host Action v1。
• AI 用普通中文说清按键代码大致在哪里。
• AI 列出开发板上不能随意改的地方，并说明原因。

如果 AI 已经开始改代码、跑到其他项目，或没有说清哪些硬件不能动，先不往下做，重新执行本步。

让 AI 对原项目运行一次电脑侧逻辑检查，再生成一次固件。此时仍然不改代码，也不写入开发板。

先证明源码和环境原本正常，后续才能判断新失败是否由这次修改引起。

AI 返回本轮实际发现的测试总数，并确认清单中的项目全部通过；固件生成成功；检查过程没有修改代码。测试总数以当前 Git 基线的真实清单为准，不为了匹配页面凑固定数字。

只要有检查未通过、固件无法生成，或验证过程改了代码，就先停下来查原因，不进入新功能修改。

让 AI 选一个现在已经能用的按键动作，从按下开始，一直找到它通过有线或无线发到电脑的路。

新动作必须接入已有流程；跳过理解直接新增并行路径，最容易破坏原功能或造成双发。

AI 用一条清楚的箭头链说明：按下按键 → 找到这个键的动作 → 生成内部消息 → 选择有线或无线 → 发到电脑，并给出对应的代码位置。

如果 AI 只说了一堆名词，却没有说清路径和代码位置，就先让它继续查找，不开始修改。

把页面开头的固定消息格式一起交给 AI，让它与当前固件项目核对，再记进项目。这一步只做核对和记录，不改代码。

EasyInput App 已经按这个格式接收动作，而这里又不能改 App。因此固件必须遵守同一格式，AI 不能现场另造一套。

AI 确认页面开头的固定格式与当前项目没有冲突，已经把它记进项目，并明确说本步没有修改代码。具体编号和字段由 AI 逐项核对，不需要人背诵。

如果 AI 说固定格式与项目有冲突，先保留它给出的位置和原因，不进入修改。如果它已经改了代码，或只给方案却没有留下项目记录，也重新执行本步。

把提示词复制给 AI，让它先核对上一步记下的固定格式，再在电脑上实现并检查打开应用动作。这时不连接真实开发板。

先测纯逻辑，失败只会落在格式、解析、事件或消息这一小块；如果一开始同时接入传输和硬件，错误范围会变得很大。

• 格式正确的 UUID 能被接受，格式错误的 UUID 会被拒绝。
• 按下会生成一次动作，松开不会再生成一次。
• 新检查在修改前会失败，修改后全部通过；有线和无线发送代码还没有被改动。
• 精确字段由 AI 核对并写入项目记录。

如果固定格式没有读到、UUID 检查未通过，或 AI 已经提前改了有线、无线代码，先停在这一步，不用临时加新规则来凑出通过结果。

让 AI 确认八个实体键都能选择打开应用动作，按下只执行一次，松开不重复；同时重新检查复制、粘贴等原有动作。

只测一个键，不能代表八个键都能用。新动作加进去后，原有动作也必须保持正常。

• 八个实体键都有通过记录。
• 每个键都是按下执行一次，松开不重复。
• 复制、粘贴、快捷键和固定文字仍然正常。
• 测试用的示例编号没有被写入默认按键配置。

只验证一个键、配置进入 Keymap 后丢失 host_action: 前缀、松开又产生第二个动作、旧按键回归失败，或把测试 UUID 写进生产配置，都不算完成。如果通用解析本来已经覆盖八个键，用完整测试证据确认即可，不强迫 AI 改生产代码。

让 AI 把已经通过电脑检查的动作，接进项目现有的有线和无线发送路径。两条路发送的内容必须完全一样。

复用既有消息通道可以减少新协议面；同时必须沿用工程原本的 USB／BLE 选择逻辑，避免双连接双发。

• 有线和无线共用同一份动作内容，没有各写一套。
• 有线可用时只用有线，否则才用无线；一次按键不会发送两次。
• 原有状态消息和普通键盘功能仍然通过检查。
• 这一步还只是代码证据，不代表真机已经打开应用。

如果有线和无线各写了一套动作内容，或两种连接同时存在时可能执行两次，就先停下修正。如果 AI 把电脑检查说成真机成功，也不进入下一步。

让 AI 在固件的功能清单中加入“已支持打开应用动作”的标记，再检查加完后的无线状态消息是否还放得下。

App 需要先知道固件已经支持这个动作，才能正确开放功能。新标记还不能挤掉原有的电源和扬声器状态。

• AI 确认固件所有对外功能清单都带上了支持标记。
• 每种真正会发出的无线状态都不超过 512 字节。
• 电源和扬声器的必要信息仍然保留，原有功能继续通过检查。

过程中可能先看到“消息太大”的失败，原提示词已经告诉 AI 怎样收紧可选内容，让它继续修复并重跑即可。如果最终仍超过 512 字节，或原有的电源、扬声器信息被删掉，就停在这里，不自己另编新格式，也不只改检查来制造通过。

让 AI 用当前代码重新运行全部电脑检查，再重新生成固件。不使用前面步骤留下的旧结果或旧文件。

局部测试只证明局部逻辑；完整测试与构建要确认新增功能没有破坏工程其余部分，并能生成固件。

AI 列出的测试发现数、执行数和通过数完全一致，失败数为 0；固件生成成功，并给出新固件的位置和大小。此时只能说“代码通过并产生了固件”，还不能说真机功能已经成功。

测试清单对不上、发现数／执行数／通过数不一致、存在失败，或固件生成失败，就先查明原因。不跳过检查凑数字，也不改工具版本来掩盖问题。

让 AI 列出从开始到现在所有新增、删除和修改的文件，并检查会影响构建、烧录或提交的 Git 忽略内容，逐项说明来源和用途。这一步只检查改动，不再修改代码。

代码检查通过，不代表 AI 只改了该改的地方。写入开发板前，要让真实改动、会影响结果的生成内容和实际构建配置互相对上；与构建、烧录和提交无关的缓存不需要逐个清点。

所有 Git 变化都被列出并归类；会影响构建、烧录或提交的 ignored 内容也有来源证据。托管依赖、实际构建配置和锁定文件互相吻合，硬件、存储布局、设备身份和无关功能都确认未改。AI 最后明确说“可以进入写入确认”，但此时还没有写入开发板。

真实改动或会影响构建、烧录、提交的生成内容说不清，或硬件和设备身份有变化，都不写入开发板。先保留清单和问题位置，再决定怎样修正。

让开发板保持开机，用可传数据的 USB 线连接电脑，再把提示词复制给 AI。AI 会先显示它识别到的开发板和准备写入的固件，然后停下等你确认。

写入会覆盖开发板现在的固件，所以必须先确认“是这块板、是这个文件”，再由人明确授权。写完后看不到下载用的连接口，也不一定代表失败。

• AI 先显示目标开发板、将要写入的固件和唯一确认句，此时还没有写入。
• 你原样输入 确认烧录到 XXXX 后，AI 才开始写入，并明确显示写入和校验成功。
• 写完后用板上开关完全关机，再不按 BOOT 正常开机。这里只确认固件已写入，最终功能留到下一步。

目标板不确定、固件不是最新检查过的文件，或你还没有输入完整确认句时，都不能写入。自动连接失败时，只在开机状态短按并松开一次 BOOT；还是失败就停止，不连续重试。

1. 先确认上一步已经写入成功，开发板也已正常重新开机；如果还看不到设备，先检查 App、有线或无线连接，不重新写入。
2. 打开从 EasyInput 官网获得的正式 App，只保留这一个实例运行。课程完整复验使用过 0.1.26；如果实际小版本不同，先确认它仍能识别开发板，并且“按下动作”里能选择“打开应用”，不用只为匹配数字降级。
3. 为一个按键选择“打开应用”，再选一个容易观察的应用，例如计算器或备忘录。点击同步，等 App 明确显示开发板已经保存；UUID 由 App 自动生成，不需要手动输入。
4. 保持 App 运行，再按下页七项逐一检查。

“开发板已连接”只证明连接可用，不代表 App 已经知道这个键要打开哪个应用。只有 App 保存好对应关系，并明确确认开发板已收到，才能开始按键检查。

开始七项检查前：开发板已正常连接，当前只运行一个官网正式 App 实例；无论小版本号是多少，动作列表都能选择“打开应用”，App 也明确显示开发板已经保存配置。下面七项要分别记录结果，不用一项成功代表全部通过。

开发板看不到时，先停在连接检查，不重新写入。App 来源不明、没有“打开应用”，或同时开着两个实例时，先把 App 环境理清。App 一直没有确认开发板已保存时，只重连并重试一次；仍然失败就保留现场。不手写 UUID，也不从头盲目重写固件。