让 AI 真正参与 WB2 开发：WorkBuddy + WSL + Windows，实现代码→编译→烧录→验证闭环

[djy876]

让 AI 真正参与 WB2 开发：WorkBuddy + WSL + Windows，实现代码→编译→烧录→验证闭环

副标题：以 Ai-Thinker WB2-12F Kit / BL602 为例，记录从 WorkBuddy 辅助代码开发，到编译、实机烧录、FLASH/VERIFY 校验以及 APP 运行验证的完整流程。

---

摘要

这是一篇个人技术分享，不是官方教程。

本文要回答的核心问题不是"怎么烧录 WB2"，而是：

如何让 AI（WorkBuddy）从一个"帮你写代码"的工具，进一步参与 WB2 的代码修改、编译、烧录和验证，让 AI 开发真正连接到实体 WB2 硬件。

文章基于 Ai-Thinker WB2-12F Kit / BL602 的真实实机验证记录，主要包含：

• WorkBuddy 在整套流程中扮演的"执行 AI"角色
• 开发 / 编译环境（可走 WSL）与当前稳定烧录环境（Windows Git Bash）如何分工配合
• 为什么烧录进入 ISP 只需一次 EN，以及它背后的真实原因
• 为什么 ISP handshake success 不等于烧录成功，真正的成功标准是 FLASH PASS + VERIFY PASS
• 一套整理好的可复刻烧录包 WB2-FLASH-REPRO-v1.0，把"我这台电脑能烧录"变成"别人也能照着复刻"

适合谁：正在用 WB2 / BL602 做小项目、想让 AI 参与嵌入式开发、或者换电脑后烧录环境难以复现的人。

说明：本文使用的 SDK 与烧录工具来自安信可官方；WB2-FLASH-REPRO-v1.0 是个人整理的自动化与复刻方案，不代表安信可官方发布。

---

本文最终验证的不是"AI 会写 WB2 代码"，而是 WorkBuddy 已经可以参与从代码修改、编译，到调用烧录工具、等待真实 BL602 ISP 握手、判断 FLASH/VERIFY，再到 APP 运行验证的完整流程。

---

最终效果

先看这套方案打通后的完整链路：

WorkBuddy 写 / 改代码
   ↓
开发 / 编译环境
（WSL / Ubuntu，或官方 buildenv）
   ↓
生成 .flash.bin
   ↓
Windows Git Bash
   ↓
wb2 flash
   ↓
用户 BURN + EN（只按一次 EN）
   ↓
BL602 BootROM ISP 握手
   ↓
FLASH PASS
   ↓
VERIFY PASS
   ↓
APP PASS（串口看到程序运行输出）

一句话：AI 写完的代码，最终真的烧进了物理芯片并跑起来，全程日志可被 AI 读取和判断。

关于上图的准确边界：编译既可以走 WSL / Ubuntu（原生工具链），也可以走官方 buildenv（Windows）。WSL 只是推荐的开发 / 编译通道之一，不是唯一选择，也不是当前稳定烧录的必要条件。 当前已经实机验证通过的稳定烧录链路是 Windows Git Bash → wb2 → bflb_iot_tool.exe → Windows COM → CH340 → WB2-12F Kit / BL602。

---

1. 为什么做这个项目

做 WB2 开发时，常见的痛点有：

1. 代码好写，烧录难复现——在一台电脑上点几下能烧录，换个电脑、换个 COM、换个路径就各种报错。
2. AI 只停在"写代码"——很多 AI 工具能生成代码，但代码编完、烧进板子、能不能跑，往往还是要人手动搬。
3. 分不清"进入 ISP"和"烧录成功"——新手看到握手成功就以为烧好了，其实固件可能根本没写进去。

所以我希望打通这样一条路：

需求 → WorkBuddy 读工程、改代码、编译 → 出 .flash.bin → wb2 烧录 → FLASH/VERIFY 校验 → 板子跑起来 → 串口/日志回给 WorkBuddy → 继续改。

目标不是做"全自动点一下"，而是让 AI 和实体硬件真正连通，把重复、易错、可判定的步骤交给 AI 和脚本，把必须由人完成的物理按键留给用户。

---

2. 这套方案到底是什么

它由三部分配合而成：

角色	是什么	负责什么
WorkBuddy	AI 编程/执行助手	读工程、改代码、检查、编译、调烧录工具、读日志、判断成败
wb2	个人整理的 WB2 统一命令行脚本	env / build / flash / test / all 统一入口，后台烧录 + 自主检测 ISP
WB2-FLASH-REPRO-v1.0	个人整理的可复刻烧录包	把脚本 + 依赖说明 + 测试结果 + 文件校验打包，让另一台电脑能复刻

重要澄清，这套方案不是：

• 安信可官方软件
• 新 SDK
• 新烧录协议
• bflb_iot_tool 的替代品
• 完整 WorkBuddy 安装包

它只是整个 AI 开发闭环里的**"烧录复刻组件"**。底层真正干活烧录的，仍是官方 bflb_iot_tool；脚本只是把"后台启动、等待 ISP、判读结果"这些易错步骤封装好。

---

3. 整体架构：WorkBuddy + WSL + Windows Git Bash

这里必须把两个环境讲清楚，它们是分工配合的关系。

图 1：整体开发闭环

flowchart TD
    U[用户提出需求] --> W[WorkBuddy]
    W -->|读取 / 修改| SRC[WB2 工程代码]
    SRC -->|WorkBuddy 执行编译| SDK[Ai-Thinker-WB2 SDK / 工具链]
    SDK -->|产出| BIN["<PROJECT>.flash.bin"]
    BIN --> WB2[wb2 : Windows Git Bash]
    WB2 -->|后台启动| BFLB[bflb_iot_tool.exe]
    BFLB -->|Windows COM| CH340[CH340]
    CH340 --> KIT[WB2-12F Kit / BL602]
    KIT -->|BootROM ISP 握手| H[握手成功]
    H --> FLASH[FLASH + VERIFY]
    FLASH --> APP[APP 运行验证]
    APP -->|串口日志| W

Loading

图里的关键点：左侧是"AI 开发"（代码、编译、出固件），右侧是"实际硬件烧录"（CH340 → WB2-12F → BL602 ISP）。中间靠 .flash.bin 和 wb2 脚本把它们连通。

图 2：开发环境 vs 烧录环境的配合

两个环境不必相同，可以分开：

                WorkBuddy
                    │
          ┌─────────┴─────────┐
          │                   │
       开发阶段              烧录阶段
          │                   │
    WSL / Ubuntu          Git Bash
          │                   │
     WB2 SDK               wb2
          │                   │
     修改 / 编译        bflb_iot_tool
          │                   │
      .flash.bin              │
          └──────────┬────────┘
                     ↓
                   WB2
                     ↓
                   BL602

为什么两个环境可以配合？ 因为编译与烧录是解耦的：

• 编译只吃"源代码 + SDK + 工具链"，在 WSL / Ubuntu 里跑很方便（make、gcc、RISC-V 工具链都是 Linux 原生）。
• 烧录需要的是"固件文件 + 可访问的串口 + 烧录工具"。固件是通用的 .flash.bin，谁烧都一样。
• 所以在 A 环境编出的固件，完全可以在 B 环境烧录，二者通过固件文件衔接。

重要（实测事实）：本文当前稳定烧录链路是 Windows Git Bash + Windows COM + CH340。WSL 不是这条稳定烧录链路的必要条件。 在我验证的这台机器上，wsl.exe 甚至被安全策略拦截、无法运行，最终烧录全部走 Windows 侧完成。因此不要把 WSL 当成"当前已验证的烧录前提"。WSL 更多扮演推荐的开发/编译通道，而非唯一或必需。

---

4. WorkBuddy 如何参与 WB2 开发

WorkBuddy 不只是"生成代码的聊天窗口"，它是一个能执行的 AI：可以读文件、改文件、跑命令、读日志、做判断。

在 WB2 开发中，它承担的步骤包括（按真实流程）：

用户
  ↓ 提出 WB2 功能需求
WorkBuddy 分析工程
  ↓
WorkBuddy 修改代码
  ↓
WorkBuddy 检查代码
  ↓
WorkBuddy 编译
  ↓ 生成 firmware / .flash.bin
WorkBuddy 执行 wb2 flash
  ↓
用户完成一次 BURN + EN
  ↓
wb2 等待并检测 BL602 ISP
  ↓
FLASH
  ↓
VERIFY
  ↓
WorkBuddy 继续测试
  ↓
APP PASS

WorkBuddy 具体能做的：

• 读取项目目录、Makefile、源代码，理解当前工程。
• 修改功能代码。
• 运行编译命令，检查是否有 .flash.bin 产出。
• 调用烧录工具（wb2 flash）并后台执行。
• 轮询读取烧录日志，判断 ISP 握手是否成功。
• 判断 FLASH PASS、VERIFY PASS。
• 根据结果继续测试，甚至继续改代码进入下一轮迭代。

但要说清楚边界：WorkBuddy 无法替你物理按下按键，也无法绕过"BL602 是否真的进入了 ISP"这一客观前提。需要人手的环节（按住 BURN、按 EN），仍然由人完成。AI 能做的，是把需要判断的部分自动化并给出明确反馈。

关于"代码→编译"这一步，编译本身需要 WB2 SDK 与工具链。它在 WSL / Ubuntu（原生工具链）或 buildenv 自带的 MSYS make（Windows）里都能完成。WorkBuddy 只要能执行编译命令、拿到固件，就算打通了这一环。

---

5. WB2 烧录为什么只需要一次 EN

先看硬件事实：

• WB2-12F Kit 底部有两个按键，右为 【BURN】（接 GPIO8/PROG），左为 【EN】（仅复位）。
• 芯片要进入 BootROM ISP（下载模式），必须在复位发生的瞬间让 GPIO8(BOOT) 为低。
• EN 只会复位芯片，不会去控制 GPIO8。所以只有在你按住 BURN（把 BOOT 拉低）的同时按 EN，芯片复位后才落到 ISP 下载态。

这解释了为什么：

• 单按一次 EN、不按 BURN → 芯片只会复位进普通运行态，进不了 ISP。
• 最简可靠进入 ISP 的方式 = 按住 BURN，短按一次 EN，继续保持 BURN。

所以流程是：

用户：按住 BURN
   → 短按一次 EN（保持 BURN 不放）
   → 继续保持 BURN
wb2：后台启动烧录工具
   → 等待真实 BL602 ISP 握手
   → 检测到 ack is b'4f4b' / shake hand success
   → 显示 [OK] 已检测到 BL602 ISP —— BURN + EN 操作成功
   → 继续烧录

一个容易踩的误区（务必看）：

❌ 错误写法："软件检测到了 BURN 按钮按下。"

✅ 正确理解："软件无法直接读取你按没按 BURN。软件检测的是 BL602 是否真的进入了 BootROM ISP 并完成握手。"

换句话说，脚本看的是芯片有没有进 ISP 这个结果，而不是去猜你按键的电气状态。这从机制上就避免了"假装检测按键成功、实际芯片根本没进下载态"的假象。

---

6. 从 ISP 到 FLASH、VERIFY、APP：如何判断真正成功

这是新手最需要建立的观念：整个流程有好几个独立的成功点，前一个成功不代表下一个成功。

BURN + EN
   ↓
BL602 ISP ENTRY（进入下载态）
   ↓
ISP HANDSHAKE PASS（握手成功）
   ↓
FLASH（写入固件）
   ↓
VERIFY（回读校验）
   ↓
APP RUN（退出 ISP，启动新固件）
   ↓
最终验证

阶段	它证明了什么	不等于
ISP HANDSHAKE PASS	芯片已进入 ISP，握手通了	不证明固件写进去了
FLASH PASS	固件写入过程完成	不证明写入内容正确
VERIFY PASS	回读校验通过，写入内容正确	烧录已完成、可独立用
APP PASS	退出 ISP 后程序真的跑起来了	属于额外的运行验证

核心结论：

• ISP handshake success 只能证明已经进入 ISP，不能单独证明固件已经成功烧录。
• 最终烧录成功标准 = FLASH PASS + VERIFY PASS 同时成立。
• 若还要验证程序真的在跑，再叠加 APP PASS。

---

7. WB2-FLASH-REPRO-v1.0 复刻包

7.1 它是什么

一句话：

一个用于 Ai-Thinker WB2-12F / BL602 的可复刻烧录环境与自动化脚本打包方案。

7.2 它有什么用

如果只是在自己电脑上跑通，那是"我的电脑能烧录"。但换一台电脑：

• 路径不同
• COM 号不同
• Python 不同
• SDK 不同
• 工具链不同
• USB BUSID 不同

就可能无法复现。

所以把下面这些都整理进一个包：

• 脚本
• 配置示例
• 依赖说明
• 安装顺序
• 测试结果
• 文件校验（SHA256 / Manifest）

目标就一句：

把个人电脑上的成功经验，变成别人可以照着复刻的标准流程。

7.3 目录结构

WB2-FLASH-REPRO-v1.0/
├── README.md                  面向新手的完整说明（硬件/烧录/路径适配）
├── QUICKSTART.md              最简烧录操作步骤
├── TEST-RESULT.md             实机验证结果
├── DEPENDENCY-INVENTORY.md    运行依赖与四类分类
├── FILE-MANIFEST.txt          文件清单（相对路径/大小/SHA256，不含自身）
├── VERSION                    版本信息
├── scripts/
│   ├── wb2                    主工具（稳定基线副本）
│   ├── wb2.STABLE-v1.0        冻结基线（与 wb2 完全一致）
│   └── wb2_serial.py          串口探测助手（必需辅助）
├── config/
│   └── env.example            环境变量适配示例（不含本机硬编码）
└── resources/
    └── README.md              官方 SDK 资源获取说明（不打包整个 SDK）

逐项说明：

• scripts/wb2：稳定基线主脚本，唯一"干活"的可执行文件。
• scripts/wb2.STABLE-v1.0：与 wb2 逐字节一致的冻结基线，供比对、防改动。
• scripts/wb2_serial.py：pyserial 串口探测助手，wb2 依赖它在目标机找到 CH340 对应串口。
• config/env.example：环境变量适配示例，教你用 WB2_* 变量指向你实际的 SDK/buildenv/Python，不包含任何本机硬编码。
• resources/README.md：说明官方 SDK、bflb_iot_tool、分区/设备树/boot2 等资源去哪拿、SHA256 是多少。不把整个 SDK 打包进来（体积太大，且属官方发布物）。
• VERSION / README / QUICKSTART / TEST-RESULT / DEPENDENCY-INVENTORY / FILE-MANIFEST：版本、说明、用法、测试结果、依赖、文件校验。

7.4 依赖怎么分类

依赖被分成四类（详见包内 DEPENDENCY-INVENTORY.md）：

分类	含义	例子
A	必须随复刻包提供	wb2、wb2_serial.py、文档
B	必须由用户自己安装	Git Bash、Python+pyserial、usbipd-win、CH340 驱动
C	从官方 SDK 获取	Ai-Thinker-WB2 SDK、buildenv、bflb_iot_tool、chip 资源
D	本机特有，不该进包	当前盘符 /e/、用户名、BUSID、COM 号

D 类如何解决？ 复刻包不把 Administrator、/e/、COM4 等写死。wb2 脚本内部把这些当作"可被环境变量覆盖的探测默认值"。目标机上通过 WB2_SDK_ROOT、WB2_BUILDENV、WB2_PYTHON、WB2_COM 等指向真实路径即可，不需要改脚本本身。

---

8. 从零开始使用（普通用户操作顺序）

前提：Windows 10+，能联网下载 SDK。

1. 准备 Windows：确认有管理员权限（usbipd、驱动可能需要）。
2. 安装 Git Bash：MSYS bash 环境，脚本在 Git Bash 里跑。
3. 准备 Python + pyserial：装一个带 pyserial 的 Python（wb2 串口枚举依赖）。
4. 准备 Ai-Thinker-WB2 官方 SDK：从安信可官方 GitHub / 发布渠道获取（版本标识 release_bl_iot_sdk_1.6.40-11-gf4c8dac01 为本文实测版本，可作参考）。
5. 准备工具链：RISC-V 工具链 + GNU Make（buildenv 自带，或自行安装）。
6. 准备 bflb_iot_tool 和 BL602 资源：在 buildenv 的 flash_tool/chips/bl602/ 下（官方自带）。
7. 解压复刻包：解压 WB2-FLASH-REPRO-v1.0.zip。
8. 配置环境：把 scripts/ 加入 PATH，并按需 export WB2_* 指向真实路径。
9. 自检：wb2 env . 看环境是否就绪。
10. 编译：wb2 build .。
11. 烧录：wb2 flash .。
12. BURN + EN：按住 BURN，短按一次 EN，保持 BURN。
13. 等待 ISP：程序自动检测到 [OK] 已检测到 BL602 ISP。
14. 等 FLASH PASS。
15. 等 VERIFY PASS。
16. APP 测试：松开 BURN、短按一次 EN 重启进新固件，用 115200 串口看输出。

支持的命令（wb2 真实支持，无虚构）

wb2 --help      # 查看用法
wb2 env  [dir]  # 环境自检（BOARD/MCU/SDK/USB/CH340/BUSID/SERIAL…）
wb2 build[dir]  # 编译
wb2 flash[dir]  # 烧录（默认 115200；后台等待 BL602 ISP，提示 BURN+EN 一次）
wb2 test [dir]  # 测试门禁
wb2 all  [dir]  # env + build + flash + test 全流程

[dir] 缺省或为 . 时取当前目录。核心约定：不硬编码 BUSID / COM / 固件名 / 项目名，全都动态识别或从 Makefile 推导。

---

9. 实际验证结果与踩坑经验

9.1 实测验证结果（实机，非仿真）

项目	状态
WB2-12F Kit	PASS
BL602	PASS
稳定烧录脚本	PASS
ISP Detection	PASS
FLASH	PASS
VERIFY	PASS
APP	PASS
EN ISP Entry	1 次
Manifest	10/10
ZIP 解压验证	PASS

关键实机参数

• 板卡：Ai-Thinker WB2-12F Kit；MCU：BL602
• USB-UART：CH340，VID:PID 1a86:7523
• 默认烧录波特率：115200（BootROM ISP 同步波特率；进入 ISP 后工具内部 helper 传输会切到 921600，这是工具内部行为）
• 实测项目：applications/get-started/blink
• ISP 进入所需 EN：1 次；烧录完成后重启进 APP 所需 EN：1 次

关于"两个 EN"的澄清

两个 EN 分别属于：

1. ISP 入口：在按住 BURN 时短按一次 EN，让芯片进入下载态。
2. APP 启动：烧录完成后短按一次 EN，让芯片退出 ISP、重启进新固件。

它们不是 ISP 要按两次 EN。

9.2 成功烧录日志（示意图，取自真实实机日志）

下面这段是真实烧录日志的关键片段（已做示意排版），来自实测日志 wb2_buildenv/logs/wb2_flash_212442.log，能清楚看到握手 → 传输 → 校验 → 全部成功。

[21:24:46] Boot2 is ...boot2_iap_release.bin
[21:24:46] isp mode speed: 921600
[21:24:46] Load eflash_loader.bin via uart
...  （等待用户按住 BURN + 短按 EN）
[21:25:48] ack is b'4f4b'                    ← ISP 握手成功证据
[21:25:48] shake hand success
[21:25:48] ========= ChipID: a405fd195b15 =========
[21:25:52] Load 2048/39212 {"progress":10}
[21:25:53] Load 6144/39212 {"progress":15}
...
[21:25:56] Load 38912/39212 {"progress":99}
[21:25:56] Load 39212/39212 {"progress":100}
[21:25:56] xip mode Verify
[21:25:56] Verify success
...
[21:25:56] Sha caled by host: e26e7bef712e...
[21:25:56] Sha caled by dev:  e26e7bef712e...   ← 主机/设备 SHA 一致
[21:25:56] Verify success
[21:25:56] Program Finished
[21:25:57] [All Success]

配合 wb2 的交互输出，烧录窗口大致长这样：

===== WB2 FLASH =====
请按以下顺序操作（仅按一次 EN，不要重复按 EN）：
  ① 按住 【BURN】
  ② 保持 BURN，短按一次 【EN】
  ③ 继续保持 BURN
正在启动烧录工具并等待 BL602 ISP ...

[OK] 已检测到 BL602 ISP —— BURN + EN 操作成功
[OK] ISP 握手成功，正在开始烧录
[IMPORTANT] 请继续保持 BURN，不要松开
...
FLASH PASS   [log=...]
VERIFY PASS
[OK] 请松开 BURN。烧录完成。

重点提示：从 握手成功 到 [OK] 请松开 BURN 之间，必须一直保持 BURN 按住，直到 FLASH PASS + VERIFY PASS 同时出现。中途松开会导致固件只传一部分就失败。

9.3 APP 运行验证

烧录完成后，松开 BURN → 短按一次 EN，让芯片重启进新固件。然后在 115200 串口上应能持续看到 blink 示例的输出：

Turning the LED ON!
Turning the LED OFF!
Turning the LED ON!
Turning the LED OFF!
...

这代表固件不仅写进去了、校验对了，而且真的在硬件上跑起来了（APP PASS）。

9.4 踩坑经验（真实踩过）

坑 1：同步调用烧录工具，AI 无法处理长 ISP 等待。

一开始是"前台同步"调用烧录命令。结果板子在 App 态时，烧录工具会在启动后约 1 秒内就 shake hand fail 退出，根本没留给人按 BURN + EN 的窗口，必然失败。

• 解决：改成后台子进程启动烧录 + 前台轮询日志。烧录工具会进入几十秒的握手/重试窗口，期间用户从容完成 BURN + EN，握手命中即成功。

坑 2：ISP 握手成功后误杀烧录子进程，固件只传一部分。

曾有个 bug：握手成功后就 kill 烧录进程，结果把正在下载的 bflb_iot_tool 误杀（rc=143），固件传到 8160/37184 就中断了。

• 解决：握手成功后绝不 kill，让它自然跑完下载 / Verify / [All Success]；只有超时（未进 ISP）才允许清理自己的子进程，并且要用 wait 回收、不产生僵尸进程。

坑 3：ISP handshake success 不代表烧录成功。

• 解决：最终成功以 FLASH PASS + VERIFY PASS 为准；判定要看日志里的 [All Success]、Verify success 等真实标记，而不是只看握手成功。

坑 4：Manifest 自引用导致自身 SHA256 无法稳定记录。

文件清单如果记录了自己，那么清单一写入、自身字节就变，记录的自身哈希永远对不上。

• 解决：Manifest 不记录自身。当前 FILE-MANIFEST.txt 只记录其余 10 个交付文件，结果 10/10 MATCH、NO SELF-REFERENCE。

---

10. 后续：让 AI 开发 WB2 多传感器

本文 v1.0 的实机闭环以 blink 示例为基准（验证了"代码→编译→烧录→FLASH/VERIFY→APP"这条链路是通的）。

在此基础上，后续计划引入更多传感器与模块作为 AI 驱动开发的对象，例如：

• PIR（人体感应）
• Rd-03D（毫米波雷达）
• AHT20（温湿度）
• 雨滴传感器
• 光照传感器
• WS2812（RGB LED）
• Wi-Fi / BLE
• 接入 Home Assistant

重要：以上是后续开发方向，并非当前 v1.0 已全部实现。它们用于验证"AI 驱动的多传感器开发流程"，而不是宣称已有成品。

设想的未来形态是形成这样一条数据闭环：

需求
  ↓
WorkBuddy 修改代码
  ↓
编译
  ↓
烧录
  ↓
硬件运行（传感器采集）
  ↓
串口 / 网络验证
  ↓
WorkBuddy 分析结果
  ↓
继续修改…

最终沉淀为：

AI → 代码 → 固件 → 实机 → 数据 → AI

也就是让 AI 不只写一次代码，而是能根据实机跑出来的数据反复迭代，真正"看着硬件调程序"。

---

下载与版本信息

版本

• 复刻包：WB2-FLASH-REPRO-v1.0
• 稳定基线：WB2 FLASH STABLE BASELINE v1.0
• MCU：BL602；Board：Ai-Thinker WB2-12F Kit
• 默认波特率：115200

SHA256（文件数字指纹）

什么是 SHA256？ 可以把它理解为文件的数字指纹：

• 只要文件内容有一点点不同，SHA256 就会完全不同。
• 用途：判断下载包是否完整、文件是否被修改、确认双方拿到的是同一个版本。

当前交付物指纹：

项目	SHA256
稳定脚本 wb2 / wb2.STABLE-v1.0	f9e370ca106e9f1882c638d72505d88b325f75b491d7a2c3dc1e1c812e2d6506
wb2_serial.py	4159fa7e5725df8f8a38613cd77b2f65d7a6d65c7475c1f25859e486b009d9b7
复刻包 WB2-FLASH-REPRO-v1.0.zip	648f764ca4561500130c8c01b5ce13d3e10a03b5ce0f49b0949931f853693f42

文件清单（Manifest）：10/10 MATCH、NO SELF-REFERENCE（清单本身不入列，避免"记录自己"造成的哈希不稳定）。

由于包内 bflb_iot_tool.exe、SDK、分区/设备树/boot2 均属安信可官方发布物、需从官方渠道获取，本文不提供第三方下载链接。请在安信可官方 GitHub / 发布渠道获取与上述版本匹配的 SDK 与工具。

---

已知限制

如实列出当前方案的边界：

• 当前稳定验证环境为 Windows Git Bash；此链路已实测通过。
• WSL 不是最终烧录的必要条件（在本机 WSL 甚至不可用，烧录全部走 Windows COM）。
• CH340 的 COM 号可能变化：由目标机系统枚举决定，脚本动态探测，也可用 WB2_COM 显式指定。
• USB BUSID 可能变化：由当前电脑 usbipd 环境决定。
• SDK / buildenv / toolchain / bflb_iot_tool 资源需要目标机自行准备（属官方发布物，体积大，未打包进 ZIP）。
• 脚本无法直接读取 BURN 的电气状态：它检测的是"BL602 是否真的进入 ISP 并握手成功"。
• EN 按一次，指的是"ISP 入口操作一次"；烧录完成后重启进 APP 的那次 EN 是另一次复位，不算重复进 ISP。
• ISP handshake success 不等于 FLASH PASS。
• FLASH PASS + VERIFY PASS 才是烧录成功。
• APP PASS 属于额外的运行验证。

---

常见问题（FAQ）

Q1：为什么不能全自动按 EN？
EN（复位）在普通运行态按一次，只会让芯片重启进普通程序，因为 GPIO8(BOOT) 在复位瞬间不为低。要进 ISP，必须在 BOOT 拉低（按住 BURN）的同时复位。所以这一步目前由人完成。

Q2：为什么还需要按住 BURN？
因为 BL602 靠 GPIO8(BOOT) 在复位瞬间的电平决定进 ISP 还是进 App。按住 BURN = 把 BOOT 拉低 = 芯片复位后才进入下载态。这是芯片/BootROM 的设计，绕不开。

Q3：为什么 ISP 握手成功后还要继续等？
握手成功只是确认"进 ISP 了"。后面还有固件传输、写 flash、回读校验。所以要继续等 FLASH PASS 和 VERIFY PASS。

Q4：为什么 handshake success 不能直接算烧录成功？
握手 ≠ 写入。握手只说明芯片在线、可以通信。固件有没有写对，必须靠 VERIFY（回读对比）来证明。

Q5：为什么我的 COM 号和别人不一样？
COM 号由每台电脑的操作系统按 USB 枚举顺序分配，天然不同。所以脚本不写死 COM，而是按 CH340 的 VID:PID 动态探测。

Q6：为什么 WSL 没有直接参与最终烧录？
在当前验证的机器上，稳定烧录走的是 Windows COM 通道，WSL 未参与且不可用。WSL 更适合当开发/编译环境，而不是当前已验证的烧录前提。

Q7：为什么别人不能直接拿 ZIP 就烧录？
ZIP 里只有脚本和说明，不含官方 SDK、工具链、烧录工具这些大体积发布物。目标机需先按依赖说明装好 Git Bash、Python+pyserial，并从官方获取 SDK/buildenv，才能跑起来。

Q8：FLASH PASS 了但程序没输出，怎么办？
先确认烧录后是否松开 BURN 并按了一次 EN 让芯片退出 ISP、重启进 App。再看串口工具波特率是否 115200、COM 选对没有。若还是没输出，检查程序本身是否有串口打印逻辑。

Q9：如何判断自己拿到的 ZIP 没被修改？
对 WB2-FLASH-REPRO-v1.0.zip 算 SHA256，与上文 648f764c… 比对；解压后再核对 FILE-MANIFEST.txt（10 项应全部 MATCH）。不一致说明包被改动或下载不完整。

---

免责声明

• 本文为个人基于 Ai-Thinker WB2-12F Kit / BL602 实机验证后的技术分享。
• 使用了官方 Ai-Thinker-WB2 SDK 及官方相关烧录工具。
• WB2-FLASH-REPRO-v1.0 是个人整理的自动化与复刻方案，不代表安信可官方发布。
• 文中"多传感器 / PIR / Wi-Fi / BLE / Home Assistant"等为后续开发方向，非当前已实现功能。
• 文中终端日志取自真实实机烧录日志（做示意排版）；未提供实物照片与软件界面截图，相关位置已留出配图建议。

---

复刻文件

FILE-MANIFEST.txt
WB2-FLASH-REPRO-v1.0.zip
WB2-FLASH-REPRO-v1.0-DELIVERY.md
完 — 欢迎讨论。有问题请在评论区提出，我会基于实机进一步补充验证。

[Yaqing-Zheng]

nice~

[SeaHi-Mo]

看来你在烧录的时候踩了超级多的坑