2026-05-11 变更日志¶

摄取 BK7258 AI 玩具量产知识小结¶

来源：raw/snippets/bk7258-build/mass-production-knowledge-2026-05-11.md（项目 ~/local/bk7258aitoypro 工作过程笔记，作者本人 2026-05-11 整理；用户背景：互联网后台工程师转 IoT，量产环节首次实操；配套 3 次 WebSearch 独立核查阿里云一机一密 / 一型一密、涂鸦 PMS、PCBA ICT/FCT pogo pin）

新建页面¶

• concepts/iot-mass-production — 产线物理工程层概念页。两个工位（PCBA 治具 vs 整机测试）+ 物理形态（pogo pin 探针 + 气动压板 + 定位柱）+ CI/CD 类比表 + ICT/FCT 工业细分（含元器件 PPM ≤ 50 后 FCT 是产线测试主力 + 治具成本 3000~10000 元 + 测试点直径 ≥ 0.8mm 等设计要求）+ 为什么三元组必须在 PCBA 工位烧（外壳合上后 UART 接不到）+ 与 Sentino BK7258 的具体对接（宣德产线现状：UART AT 通道已通、三元组烧录尚未跑通）+ 决策影响表（哪个事该哪个工位做）+ 5 条行业常识与误区
• concepts/triple-burning — 三元组烧录的三种范式概念页。范式 A 编译期硬编码（开发期专用）+ 范式 B 量产烧录（行业主流，含阿里一机一密 / 涂鸦 PMS 业界标杆独立核查）+ 范式 C 动态注册（阿里一型一密两变种 + AWS Fleet Provisioning by Claim）+ Sentino BK7258 项目选型推导（当前 A，下一步 B + AT 命令路径，远期可考虑 C）+ 5 条设计常见错误对照表
• concepts/beken-at-server — Beken AT Server 框架概念页。三件套（ATSVR_CMD_HADLER 注册 + atsvr_cmd_rsp_ok 应答 + atsvr_register_commands 挂模块）+ 与 AT+WLMAC 同源 = 宣德产线无缝接入 + EasyFlash KV 为什么不能裸写裸 offset（KV 元数据 + CRC + 版本号）+ 与其他烧录路径的对比（tyutool 直写裸 Flash / OTA / 配网下发是四件不同的事）+ "AT Server = 产线时代的 SSH"工程含义 + 5 项工厂固件 vs 生产固件的待办

关键知识提取¶

1. 本项目三元组口径与涂鸦不同（PID 算进"三元组"） —— 涂鸦把 PID 当产品级常量不算入三元组（tuya-triplet），本项目把 PID + UUID + SECRET + MAC 都算入"三元组"。这是命名差异不是本质差异——MAC 都由芯片 efuse 出厂烧好不用烧、UUID/SECRET 都是设备级要量产烧的字段。意义：未来对外销售文档 / 客户对接时口径差异要主动澄清，不能假设客户用的是涂鸦口径 → 与 tuya-triplet 的连接：在该页加"与本项目三元组口径的差别"段，明确指出 Sentino BK7258 项目把 PID 算进三元组、涂鸦不算，是命名差异不是本质差异；同时 sources 增加新 raw 引用

2. 三种烧录范式互为基底，不是替代关系 —— 范式 A 编译期硬编码是所有 IoT 项目的开发期通用入口（一两片工程板用），范式 B 量产烧录是行业主流 + 行业标杆（阿里一机一密 + 涂鸦 PMS），范式 C 动态注册是远期切多区域 / 多品牌时才需要。Sentino BK7258 当前在 A，下一步走 B，远期可考虑 C 的混合形态（范式 B + 引导服务器）。结论：范式选型是产品成熟度的递进路标，不是"选哪个"的二选一题 → 与 iot-device-bootstrap 的连接：范式 C "动态注册"在工程上与本页方案 B 引导服务器同源（首次联网时云端下发凭证），加链接进 iot-device-bootstrap "相关概念"段；同时把"出厂硬编码 broker 是方案 A 的极简版，量产烧录链路接通后才有切换到方案 B/C 的灵活性"含义点出

3. EasyFlash KV 不能裸写裸 offset 是 IoT 项目从开发期过渡到量产时最容易踩的坑 —— 三元组用 Beken EasyFlash KV 存（key = triple_data，分区 0x7e9000），EasyFlash 有自己的 KV 元数据 + CRC + 版本号，烧录器（如 tyutool）按"在裸 offset 写一段二进制"的方式直接落 Flash 会被 EasyFlash 启动时认为分区损坏 → 整片擦除 / 报错。正确路径：必须通过固件自己执行 bk_set_env_enhance(key, value) 写入。意义：决定了"量产烧三元组"在工程上不能用 tyutool 这种通用烧录工具，必须走自定义 AT 命令让固件自己执行 KV 写入 → 与 bk7258-firmware 的连接：在该页加"量产烧录路径（与 tyutool 直写 Flash 是两件事）"段，明确指出 tyutool 烧 bootloader/app 固件是裸 Flash 写、三元组烧录必须走 AT 命令路径，链接到 beken-at-server 与 triple-burning；同时 MAC 由 BK7258 efuse 出厂已写入不用烧的事实写入该页

4. AT Server 框架是"产线时代的 SSH 等价物" —— 后台世界给一台机器加运维入口的标准做法是开 SSH，嵌入式没有 SSH，UART + AT 命令服务器就是产线时代的等价物——治具操作员 / 工厂 IT / 客户售后都通过它对设备做受控操作。这意味着 AT 命令集本身就是产品对外暴露的"运维 API"，需要按 API 设计原则对待——版本演进 / 向前兼容 / 错误码规范 / 文档化 / 安全（生产固件 vs 工厂固件 AT 命令集应不同，避免出厂后被任意 AT 操作） → 与 embedded-firmware-layering 的连接：AT 命令路径与该页讲的"业务/适配/SDK/BSP 四层 + import/export"是两套不同的对外通道——AT 命令是"产线 + 售后运维"通道（短路径，直接在 SDK 层挂），DP 点是"业务层云端控制"通道（要走业务/适配/SDK 三层）。在 beken-at-server 概念页"与其他烧录路径的对比"段对照表里点出，加 embedded-firmware-layering 反向链接

5. "通道复用"在嵌入式工程的具体回报 —— 宣德代工厂产线已经通过 UART AT 通道跑 AT+WLMAC 验 MAC（确认 BK7258 出厂 efuse 已正确烧入 MAC 地址）。新增 AT+TRIPLE 命令对治具侧零改造——不需要新装驱动 / 新刷固件 / 新接物理通道。意义：嵌入式工程"已被验证可用的物理通道"是稀缺资源，新功能搭上即可的工程价值远大于"另起一套通道"的所谓优雅。这是与后台微服务"为每个新需求建一个新服务"截然相反的工程哲学 → 与 iot-platform-fundamentals 的连接：该页"嵌入式与后台的 7 条关键差异"中"重启就解决问题是合法手段"那条之外，本次再加一层观察——"通道复用"也是嵌入式合法手段，不是 anti-pattern。本次不直接修该页 7 条差异（避免概念页正文膨胀），只在 beken-at-server 新页"工程含义"段写明，作为未来摄取嵌入式工程哲学时回写到 iot-platform-fundamentals 的伏笔

6. 量产链路缺口是 Sentino IoT 走向 OEM 客户的关键缺口 —— 当前 sentino-iot 的 device-lifecycle 6 阶段里第 1 阶段"出厂"尚未跑通，三元组还停在编译期硬编码。意味着目前只能服务"自己客户给自己玩"的小批量场景，不能承接"品牌方下单 → 代工厂量产 → 出货"的标准链路。这是 Sentino 对外销售时的具体硬约束——客户问"能不能量产"不能含糊 → 与 sentino-iot 的连接：在项目页加"量产链路缺口（2026-05 现状）"段，把宣德产线现状 + AT+TRIPLE 下一步路径 + 对外销售含义讲清楚，链接到 iot-mass-production / triple-burning / beken-at-server

更新页面¶

• concepts/tuya-triplet — 新增"与本项目（Sentino BK7258）三元组口径的差别"段（PID 是否算入三元组的命名差异）；相关概念加 3 条新链接（triple-burning / iot-mass-production / beken-at-server）；sources 加新 raw；updated → 2026-05-11
• concepts/bk7258-firmware — 新增"量产烧录路径（与 tyutool 直写 Flash 是两件事）"段（EasyFlash KV 不能裸写 + AT+TRIPLE 路径 + MAC 不用烧）；相关概念加 3 条新链接；sources 加新 raw；updated → 2026-05-11
• concepts/device-lifecycle — "出厂"那一行加产线两阶段的指向（PCBA 治具阶段 + 链接到 iot-mass-production / triple-burning）；相关概念加 3 条新链接；sources 加新 raw；updated → 2026-05-11
• concepts/iot-platform-fundamentals — 相关概念加 3 条新链接（iot-mass-production / triple-burning / beken-at-server）；sources 加新 raw；updated → 2026-05-11
• concepts/iot-device-bootstrap — 相关概念加 2 条新链接（triple-burning 范式 C 与本页方案 B 同源 + iot-mass-production）；sources 不动（保持原有审慎）
• projects/sentino-iot — 新增"量产链路缺口（2026-05 现状）"段（宣德产线现状 + AT+TRIPLE 下一步 + OEM 客户对外销售含义）；相关概念加 3 条新链接；sources 加新 raw；updated → 2026-05-11
• wiki/index.md —「Sentino / 平台与基础」段在 claude-desktop-buddy 之后新增 3 条（iot-mass-production / triple-burning / beken-at-server）；最近更新加 1 行 2026-05-11

事实核查记录¶

• WebSearch "阿里云 IoT 一机一密 一型一密 区别 烧录 量产" → 阿里云官方文档（help.aliyun.com）+ 多源（CSDN / 博客园 / 知乎）一致确认：一机一密为每台烧唯一 ProductKey + DeviceName + DeviceSecret 是阿里官方推荐方案；一型一密分预注册（拿 DeviceSecret）+ 免预注册（拿 ClientID + DeviceToken）两种、必须用 TLS、必须预注册 DeviceName（如 MAC/SN/IMEI）；单产品上限 50 万台。一型一密关闭后已烧设备无法再激活联网。AWS Fleet Provisioning by Claim 同源思路。全部数据进 wiki concepts/triple-burning
• WebSearch "涂鸦 PMS 量产管理系统 三元组 烧录 acquire activate" → 涂鸦开发者平台官方文档（developer.tuya.com）+ EEWORLD/CSDN 教程：PMS 是 Production Management System；生产凭证（Token）方式 vs 授权码清单方式；acquire/activate 流程（云模组工具实时从云端 acquire → 烧 → 设备激活时 activate 销账）；开发期"原厂工具一次授权重复烧"vs 发布期"生产凭证 + 一片一码"两种工位区分；恢复出厂设置不能清除三元组的安全注意事项。全部数据进 wiki concepts/triple-burning
• WebSearch "PCBA 治具 ICT FCT pogo pin 测试点 量产" → 多源（CSDN / 21ic / nodpcba / one-stop-mfg）一致确认：ICT 测元器件级静态参数、FCT 测系统级功能动态验证；治具成本 3000~10000 元、3-7 天定制；测试点直径 ≥ 0.8mm、间距 ≥ 1.2mm、定位孔精度 ≤ 0.05mm；元器件 PPM ≤ 50 后 ICT 比重下降 FCT 是产线测试主力。全部数据进 wiki concepts/iot-mass-production
• 客户文档陷阱检查：本素材是用户自己整理的项目工作笔记（不是客户向 PRD/RFP/提案/合同），不触发该专项检查。文中提到的第三方品牌名（涂鸦 PMS / 阿里一机一密 / Beken / 宣德 / pogo pin / EasyFlash / tyutool）都是工程实物 / 业界标杆引用，不存在"客户已选型"的潜在污染场景

待办¶

• 等 AT+TRIPLE 自定义命令具体实现落地后摄取代码 + 失败处理逻辑（错误码定义 / 治具脚本侧重试策略 / 云端三元组池销账时机）回写 beken-at-server
• 等宣德产线第一批量产小批量（百片级）跑通后回写"实际节拍 / 良率 / 失败模式分布"到 iot-mass-production 的"经验教训"段
• 跟踪 Sentino 是否需要做"工厂固件 vs 生产固件"差异化构建路径（条件编译宏 / 不同 target？）—— 决定 AT 命令的安全暴露面，回写 beken-at-server
• 跟踪如果 Sentino 扩展到多品牌白标 / 多区域 broker 时是否切换到范式 B + 范式 C 混合形态（出厂只烧产品级凭证 + bootstrap URL，首次联网由引导服务器下发 broker + 三元组）—— 回写 triple-burning "远期"段
• 跟踪 wiki 是否需要加一页"嵌入式工程哲学"集中"重启就解决问题 / 通道复用 / Flash 是唯一持久化"等差异化原则（当前散在 iot-platform-fundamentals 7 条差异 + beken-at-server "AT Server = 产线时代的 SSH"段，未来再多 2-3 个观察点时考虑独立成页）

元观察¶

• 后台背景 + 嵌入式新手"看不见的物理工程层"是 wiki 一个独特价值 —— 已有的 iot-platform-fundamentals 把"后台 vs IoT"概念对照建立了类比直觉（用户↔设备、JWT↔HMAC、HTTP↔MQTT、Spring DI↔import callback），但那一层都还在云端 / 设备端的代码视角。本次新建 iot-mass-production 补"产线物理工程层"——治具长什么样、PCBA 阶段和整机阶段能接到什么物理接口、哪些事必须在哪个工位做。这一层不补，三元组烧录方案设计会从一开始就走偏（譬如设计成"装完外壳后用 USB 灌"——但那时 UART 已经接不到了）。未来摄取嵌入式工程的"看不见层"（譬如 PCB layout 时序约束 / 电源管理 / EMC 认证 / 老化测试）应继续用本次的"CI/CD 类比 + 物理形态描述 + 决策影响表"三段式
• 业界标杆独立核查的回报：本次摄取一开始用户素材里只写了"涂鸦 PMS"和"阿里一机一密"两个名字 + 一句话定位，独立核查后展开成"acquire/activate 流程 + 两种工位区分 + 一型一密两变种 + AWS Fleet Provisioning by Claim 同源 + 关闭一型一密的不可逆警告"等具体细节。这些细节让 triple-burning 从"列表式三种范式"升级成"每个范式都有业界标杆 + 具体决策含义"的可决策页面，对未来 Sentino 选型会议直接可用
• AT 命令是 IoT 项目对外的"运维 API" —— 这是本次摄取最有价值的概念抽象之一。一开始用户素材只描述了 Beken AT Server 框架的三件套技术细节，但摄取过程中识别出AT 命令集本身就是对外 API这一概念抽象（"AT Server = 产线时代的 SSH 等价物"），衍生出"工厂固件 vs 生产固件 AT 命令集应不同"等具体安全考量。这种"技术细节 → 概念抽象 → 安全决策"的链路是 wiki 浓缩工程经验最有价值的形态
• 本次摄取与早期 4-13 涂鸦三元组、4-24 IoT 平台基础 / 设备引导一并构成 BK7258 + Sentino IoT 完整知识链路：4-13 给三元组定义、4-24 给 IoT 上位概念对照 + 设备引导 + 固件分层、本次给量产烧录链路 + 产线物理层 + AT 命令具体技术通道——三次摄取从"是什么"到"怎么用"到"怎么造"，到位后 Sentino IoT 知识链路在"出厂前"环节已经完整，剩下的开放点是 OTA / 售后运维 / 多区域 broker 切换等"出厂后"环节

修正：当前三元组烧录方案（同日补正）¶

触发：用户审核首次摄取后指出，wiki 把"猜测的下一步路径"误写为"现状"。本节记录修正事实并指向新 raw。

新 raw：raw/snippets/bk7258-build/mass-production-actual-implementation-2026-05-11.md

核心修正（详见各页 updated 段）：

• 三条路径已并存（编译期硬编码 / 厂测 AP + UDP/MQTT / 云端动态注册），不是 "A 当前 / B 下一步 / C 远期"
• 范式 B 在 Sentino 的实现是厂测 AP（!FT@IOT1#）+ UDP 40000/40001 或厂测 MQTT 下发 thing.testing.burn 消息，由 factory_test.c:183 Factory_Set_Burn_Info_Callback 处理，不是 AT+TRIPLE 自定义 AT 命令
• 范式 C 2026-01-31 v1.0.5 已实现（factory_dynamic_register.c 动态注册到 mqtt-iot.sentino.jp:1883），不是远期；加这条的真实驱动力是宣德产线生产 Blisoo 时发现工厂 WiFi 无法连外网
• 真正的产品缺口是离线烧录通道——3 条路径全部要在线，但宣德工厂 WiFi 不能连外网 → 路径 3 直接不可用、路径 2 要工厂内自建 broker
• 当前默认烧的是犀云平台测试三元组（AI_TRIPLE_USE=3，rino_iot_process.h:49-53，UUID 前缀 rn01...），不是 Sentino 自家三元组——临时联调态

修正的页面¶

• concepts/triple-burning：选型推导段全改为"实际实现 + 三条路径并存"+ 加代码定位（rino_iot_process.h:23/40/49-53、rino_iot_process.c:679-688、rino_dev_info.c:483-502、factory_test.h:15-26/30-31、factory_test.c:183/198、factory_dynamic_register.c）+ 加 SSID 切换工程含义 + 加"真正缺口=离线通道"段
• concepts/beken-at-server："定义"段 + "与 AT+WLMAC 同源"段 + "与其他烧录路径对比"段 + "Sentino BK7258 项目接入路径"段全部重定位为"AT 通道当前承担 AT+WLMAC 验 MAC，不烧三元组 / 是未来离线烧录通道的候选基础设施" + 待办段改为"如果未来要做离线烧录通道"
• concepts/iot-mass-production："与 Sentino BK7258 项目的具体对接"表重写（"三条路径均已实现 + 真正缺口=离线通道"）+ 行业常识增第 5 条"别假设工厂 WiFi 能连外网"
• projects/sentino-iot："量产链路缺口"段重写为"已具备多路径量产能力 / 当前临时态用犀云平台三元组 / 真正缺口=离线烧录通道 / 对外销售口径修正"
• concepts/bk7258-firmware："量产烧录路径"段把"三元组烧录必须走 AT 命令路径"删除，改为"实际走厂测 AP + UDP/MQTT，AT 命令是离线通道的未来载体"

元教训¶

摄取阶段如果素材里包含"我猜测的下一步"性质内容，必须在 raw 里就标注 "speculation / not verified"，不能升级到 wiki 概念页时模糊化为"现状"。这次错误源头是用户素材第 6 节"Beken AT Server 框架"被子 agent 无意识联想成了"那 AT+TRIPLE 应该就是下一步"，而代码里其实走的是另一套机制（厂测 AP + UDP/MQTT）。下次摄取项目笔记类素材时，凡是"项目相关上下文"段里"下一步"性质内容必须先在代码里核对再决定是否升级。