从 Demo 到产品，差的从来不是代码量，而是工程能力。
如今，几乎所有 AI 编程工具，都可以在几分钟内生成一个 ESP32 Demo。点亮 LED、驱动舵机、读取传感器……这些能力已经不再稀奇。甚至很多人已经形成了一种印象：AI 写嵌入式代码，好像已经没有什么难度。
但真正做过产品的人都知道，真正困难的，从来不是写出第一个 Demo。而是之后发生的一切。
产品上线后需要持续升级怎么办？用户家里的 Wi-Fi 改密码怎么办？待机只有几个小时怎么办？界面如何支持多语言？新功能如何持续迭代？如果某个外设损坏，整个系统还能不能继续运行？
这些问题，很少出现在开源项目里，却几乎每天都会出现在真实的研发团队中。
真正决定一个项目能否交付用户的，不是 Demo，而是工程和产品化。
而工程和产品化之所以耗时，往往不是因为「产品应该是什么」想不清楚，而是工程师的大量精力被「代码应该怎么写」占满了——调试、编译、对接、修 Bug。真正该投入创造力的产品思考，反而被挤到了最后。我们想反过来验证一次：如果工程师只负责想清楚产品应该是什么，把「代码怎么写」交给 Loom，结果会怎样？
于是，我们决定做一个实验。我们找到一个开源 ESP32 机器螃蟹项目，并把它完整交给可达智灵织灵（Coda Loom）研发平台。我们的目标非常简单。不是让 Loom 再写一个 Demo。而是回答另一个问题：
如果把一个真实的开源项目交给 Loom，它能不能一路把它变成真正可以交付用户的产品？
最终，这个实验得到的结果，比我们预想的更有意思。
先介绍一下今天的主角。这只机器螃蟹并不是从零开发，而是一个已经公开的 ESP32 开源项目。它已经具备最基础的能力：
- 可以控制多个舵机；
- 可以完成简单动作；
- 可以通过网页进行控制；
- 已经拥有完整的代码结构。
如果只是学习 ESP32，它已经足够优秀。但如果把它放到一家真正准备发布产品的公司，它还远远不够。例如：
- 不支持 OTA 在线升级；
- Wi-Fi 信息需要写死在代码里；
- 待机续航只有几个小时；
- 用户界面只有英文；
- 缺少真正的互动体验；
- 软件与硬件高度耦合，很多场景下无法独立开发和测试。
这些问题并不复杂，却构成了绝大多数 IoT 产品真正的研发成本。也正是这些"最后一公里"，决定了一个项目究竟只是一个 Demo，还是一款真正的产品。接下来，我们就按照一家真实产品团队的研发流程，一步一步看看 Loom 是如何完成这次改造的。
而这次实验真正想验证的，不只是 Loom 能不能写好代码，更是另一件事：工程师则可以把更多精力放在另一件更重要的事情上——思考产品应该是什么，而不是代码应该怎么写。这个思考，将贯穿我们接下来的六道关卡。
第一关（L1）：OTA —— 让机器人拥有持续进化的能力
如果这只机器螃蟹只是放在实验室里演示，那么 USB 烧录已经足够。但如果它是一款已经卖给几千名用户的儿童机器人呢？
上线一个月后，希望增加新的动作。两个月后，希望接入 AI 对话。半年后，需要修复一个严重 Bug。一年后，还希望增加新的交互方式。
没有 OTA，这些事情几乎都无从谈起。每一台已经售出的机器人，都只能停留在出厂当天的软件版本。任何后续功能，都意味着重新烧录，甚至返厂维修。对于今天绝大多数消费电子产品来说，这是不可接受的。因此，在真正的产品研发中，OTA 已经不是什么"高级功能"，而是一项最基础的能力。
首先，我们没有去阅读代码。也没有打开 Arduino IDE。而是直接把整个项目交给 Loom，只提出了一个非常简单的问题：
请分析当前项目是否已经支持 OTA。
几分钟后，Loom 完成了整个代码库的分析，并给出了明确结论：
当前项目仅支持通过 Arduino IDE 使用 USB 手工烧录固件，不具备远程 OTA 更新能力。
更重要的是，它不仅告诉我们"没有 OTA"，还说明了为什么没有。它分析了当前固件升级方式、网络模块、Web Server 结构以及编译流程，并指出整个项目缺失了 OTA 所需的关键组件。
这一步，其实已经不像传统意义上的代码补全。它更像是一位熟悉嵌入式系统的工程师，在快速阅读整个项目之后给出的技术评估。
确认问题之后，我们继续提出第二个需求：
请为当前项目增加 OTA 支持。
剩下的工作，全部交给 Loom。
首先，它像一位真正的软件工程师一样，对整个任务进行了拆解，生成了一份完整的实施计划。
随后开始进入自动执行阶段。整个过程包括：
- 修改固件代码；
- 增加 OTA 服务；
- 扩展 Web 管理页面；
- 更新项目依赖；
- 自动编译验证；
- 检查新增功能是否能够正常运行。
整个过程中，我们几乎没有再介入任何开发细节。从需求提出，到代码修改、编译验证，再到生成最终结果，Loom 完成了一整套研发流程，而不仅仅是生成几段代码。
完成之后，它不仅输出了完整的实施报告，还自动完成了编译验证，并确认所有修改能够正常通过构建。
最终，一个完整的 OTA 管理页面出现在机器螃蟹的控制后台。
至此，这只原本只能依赖 USB 烧录的开源机器人，第一次拥有了持续升级的能力。从产品研发的角度来看，这是一个重要的分界点。它不再是一份"写完即结束"的 Demo，而开始具备持续演进、持续交付和持续维护的能力。
而对于 Loom 来说，这只是第一关。
✦ 关键洞察：Loom 完成的不是"写一段 OTA 代码"，而是先分析现状、再制定方案、最后自动执行并验证——这是一整套研发动作，不是代码补全。
OTA 解决的是"以后如何升级"的问题。但现实中，还有另一个更早就会遇到的问题。如果机器人根本连不上用户家里的 Wi-Fi，OTA 根本无从谈起。于是，我们开始了第二关，运行时配网。
第二关（L2）：联网 —— 让机器人真正走出开发环境
对于很多 ESP32 开源项目来说，联网功能通常只是"够用"。开发者把 Wi-Fi 名称和密码写进代码，烧录到开发板，只要自己的电脑能够连接，整个项目就算完成了。
这只机器螃蟹最初也是如此。它采用 SoftAP 模式启动。机器人开机后，会创建一个 Wi-Fi 热点，用户需要先让手机连接到这个热点，再打开网页进行控制。作为开发 Demo，这种方式简单直接，没有任何问题。但一旦面向普通用户，它很快就会暴露出一连串体验问题。例如：
- 每次控制机器人，都要先切换手机 Wi-Fi；
- 手机连接机器人后，无法正常访问互联网；
- 家里的路由器更换密码，需要重新烧录固件；
- 更换网络环境后，机器人几乎无法重新配置。
对于任何一款智能家居产品来说，这样的体验都很难被用户接受。真正成熟的产品应该像智能音箱、扫地机器人一样，第一次开机完成配网，此后便自动连接家庭网络，不需要用户再关心底层实现。于是，我们把新的需求交给 Loom：
请为当前项目增加运行时 Wi-Fi 配置能力。
与 OTA 一样，Loom 并没有直接开始修改代码。它首先分析了整个网络模块。包括 SoftAP 的启动流程、Web Server 的初始化逻辑、网络状态管理以及配置保存机制，并据此制定了一套完整的改造方案。
随后，进入自动实现阶段。整个修改涉及多个模块，包括：
- 重构网络初始化流程；
- 增加运行时 Wi-Fi 配置页面；
- 保存网络配置；
- 自动完成编译验证。
完成之后，机器人后台新增了一套完整的网络配置界面。我们随后进行了 OTA 升级，并在真实环境中完成了 Wi-Fi 配置测试，整个流程均可正常工作。
至此，这只机器人终于真正接入了家庭网络。而这不仅意味着 OTA 能够正常工作，也意味着它第一次具备了连接云端服务、远程管理、语音交互以及更多 AI 能力的基础。对于一个产品来说，这一步看似只是"联网"，实际上却是它真正走出开发环境、进入真实用户家庭的开始。
✦ 关键洞察：联网改造涉及网络初始化流程重构、配置页面新增、编译验证全链路——Loom 没有被"改代码"的指令牵着走，而是先分析整个网络模块再动手。
第三关（L3）：休眠 —— 从“能运行”，到“能使用”
如果说 OTA 和联网解决的是产品"能不能持续迭代"的问题，那么续航决定的，就是产品"愿不愿意每天被使用"。
很多开源项目并不会特别关注功耗。开发板长期连接 USB，程序一直运行，CPU、Wi-Fi、显示屏保持工作状态，这本身没有任何问题。
但真正的消费电子产品并不是这样工作的。没有人希望一只玩具机器人每天都要充电。更没有人愿意因为忘记关机，就发现第二天电池已经耗尽。原始项目正是如此。
待机状态下，处理器持续运行，网络模块始终在线，屏幕保持点亮，各类后台任务也没有停止。最终，它的待机时间只有几个小时。对于一款准备交付用户的产品来说，这显然远远不够。
对于机器人而言，续航不仅影响体验，更直接影响用户对产品品质的判断。我们没有直接要求 Loom 修改代码，而是提出了另一个更符合真实研发流程的问题：
分析当前项目的功耗问题，并设计一套产品级休眠方案。
Loom 首先对整个系统进行了完整分析。它没有急于生成代码，而是先回答了几个产品设计必须回答的问题：
- 哪些模块始终处于工作状态？
- 哪些外设可以关闭？
- 哪些后台任务可以暂停？
- Deep Sleep 与 Light Sleep 应该如何组合？
- 不同方案分别能够节省多少功耗？
这些分析结果，并不是简单的代码扫描，而更接近一份嵌入式系统设计报告。
它不仅列出了所有可行方案，还分析了每种方案的优缺点，以及对用户体验可能造成的影响。这一过程，其实已经超出了"写代码"的范畴。它开始参与产品设计本身。
综合各项分析之后，我们最终选择了一套两级休眠方案，并把实现工作再次交给 Loom。
请实现两级休眠机制，并完成编译、验证以及提交到新的 Git Branch。
随后，Loom 自动完成了整个研发流程。包括：
- 修改固件逻辑；
- 调整系统状态机；
- 实现休眠与唤醒流程；
- 自动完成编译；
- 自动验证结果；
- 自动提交到新的 Git 分支。
整个过程中，我们没有手工修改任何代码。真正发生变化的，是需求。我们从"机器人一直运行"变成了"机器人应该像消费电子产品一样管理自己的能耗"。
而 Loom 则负责把这种产品需求，落实成具体的软件实现。最终，这只机器螃蟹的待机时间，从最初的几个小时，提升到了数周。直到这一刻，它才真正具备了一款电池供电产品应有的续航能力。
✦ 关键洞察：我们只提了"分析功耗"的需求，Loom 自己回答了哪些模块可关闭、哪种 Sleep 模式合适、省多少电——它参与了产品设计决策，而不只是执行代码修改指令。
一个越来越明显的变化
如果回顾前面三关，会发现一个有趣的现象。OTA、联网、休眠，这三个能力几乎没有一项能够在产品发布会上成为宣传卖点。用户不会因为机器人支持 OTA 而购买它，也不会因为它采用两级休眠而兴奋。
但如果没有这些能力，它几乎不可能成为一款真正成熟的产品。这正是现实中的研发工作。真正耗费工程团队大量时间的，往往不是那些最耀眼的新功能，而是这些看似普通、却决定产品品质的基础能力。
而随着实验继续进行，我们开始把注意力从"产品能不能用"，逐渐转向另一个问题：
它能不能面向不同国家、不同用户，以及不同使用场景交付？
于是，我们开始了第四关。
国际化。
第四关（L4）：国际化 —— 当产品准备走向更多用户
很多开源项目默认只有英文界面。对于开发者来说，这几乎不会造成任何困扰。毕竟，它们的目标是验证技术，而不是服务用户。
但产品不同。今天面向国内市场，可能需要中文；未来进入海外市场，又需要支持英文、日文、德文甚至更多语言。真正的国际化，从来不是简单地翻译几个按钮。它意味着：
- 提取所有用户可见文本；
- 建立统一的语言资源；
- 修改页面布局；
- 保证不同语言都能正常显示；
- 后续新增功能也能够同步维护。
工作本身并不复杂，却十分繁琐。对于一个已经存在的项目来说，更是如此。于是，我们继续向 Loom 提出新的需求：
当前 Firmware 的用户界面全部为英文，请增加中文支持，并将中文设置为默认语言。
Loom 很快完成了整个项目的分析。它识别出所有用户可见字符串，并重新组织语言资源，对界面进行了统一修改。
完成之后，不仅原有页面实现了中文化，我们前面新增的 OTA 页面、Wi-Fi 配置页面等模块，也同步完成了本地化适配。
这意味着，国际化不再是后续需要反复维护的一项工作，而已经成为整个项目的一部分。对于产品来说，这一步虽然不像 OTA 或休眠那样决定系统能力，却决定了它能够服务更多用户。
✦ 关键洞察：Loom 识别了所有用户可见字符串并重构语言资源，连前面新增的 OTA 页面、Wi-Fi 配置页面都同步完成了本地化——它理解"改动一处影响全局"的工程逻辑。
第五关（L5）：让机器人拥有自己的个性
如果说前面几关解决的是产品能力，那么接下来，我们想解决另一件事情。
产品有没有"生命力"。
很多机器人 Demo 都能走路。也能转向。还能挥挥手。但是，看完之后，你很快就会忘记它。
真正让人记住一台机器人，往往不是它会不会走。而是它会不会"回应"你。
于是，我们没有直接要求 Loom 增加某一个动作，而是提出了一个更开放的问题。
结合当前硬件结构和 Servo Motor 的能力，请推荐几个适合这台机器人的新动作。
与普通代码生成工具不同，Loom 没有立刻开始写代码。它先重新理解了整个机器人。包括：
- 当前共有多少个舵机；
- 每个舵机的运动范围；
- 哪些动作符合机构限制；
- 哪些动作会导致机械干涉；
- 哪些动作能够安全完成。
只有完成这些分析之后，它才开始设计动作。随后，给出了多个建议。例如：
- 伸懒腰；
- 打招呼；
- 左右张望；
- 害羞；
- 开心摇摆。
这些建议，并不是随机生成。而是建立在当前硬件能力基础上的产品设计。最终，我们选择了其中一个 —— 伸懒腰。
几分钟之后，一只会"伸懒腰"的小螃蟹诞生了。相比最初那个只能完成基础动作的 Demo，它第一次开始拥有属于自己的性格。
当机器人开始回应你的触摸
不过，仅仅增加几个动作，还不足以让机器人真正有趣。真正的互动，应该来自用户。于是，我们又为机器人增加了一颗触摸传感器。接着，只提出一句话：
当用户轻轻触摸机器人时，请让它表现得开心一点。
最终实现的效果像一只真正的宠物那样，包括：
- 四条腿轻轻摆动；
- 屏幕出现开心表情；
- 保持几秒之后恢复正常状态。
整个交互逻辑，同样由 Loom 自动完成。更重要的是，它并不是一次性的。因为对于 Loom 来说，新的互动方式，本质上只是新的产品需求。例如以后，我们完全可以继续提出：
- 轻拍一下，挥挥钳子；
- 双击一下，开心地跳舞；
- 长按进入睡眠模式；
- 连续点击触发隐藏彩蛋；
- 加入语音互动；
- 加入视觉识别；
- 接入多模态 AI。
机器人能够做什么，不再受限于最初写好的程序。而可以随着产品不断成长。直到这里，这只机器螃蟹终于开始有了一点"生命力"。
✦ 关键洞察：我们没有告诉 Loom 具体做什么动作，它自己分析了舵机数量、运动范围、机械干涉风险后给出了建议——这是产品设计层面的思考，不是代码生成。
第六关（L6）：修 Bug —— 真正的工程能力，往往藏在这里
做到这里，我们已经完成了很多功能。
OTA。
联网。
休眠。
国际化。
新的互动。
看起来，这已经像是一款真正的产品。但如果你问一个有多年经验的软件工程师：
产品研发最花时间的是什么？
他大概率不会回答：
"开发新功能。"
而会回答：修 Bug。
因为增加一个新功能，AI 往往知道应该写什么。但修 Bug 完全不同。它要求 AI：
- 阅读大量历史代码；
- 理解整个系统架构；
- 找到真正的问题根源；
- 判断哪些地方不能改；
- 修改之后不能引入新的问题。
真正困难的，从来不是"写代码"。而是理解别人写的代码。这也是我们最想验证 Loom 的地方。
这只机器螃蟹里，恰好就有一个非常典型的问题。原始项目默认认为：
所有硬件都会一直存在。
于是，只要没有连接舵机，程序启动失败。没有 OLED，启动失败。少接一个外设，启动失败。对于作者来说，这完全合理。因为开发板一直放在自己桌上。但对于一个真正的研发团队来说，这会造成很多麻烦。例如：
- CI 无法自动运行。
- 新同事拉下代码，什么都做不了。
- 调试网络模块，却必须先接好所有硬件。
- 某个外设损坏，整个系统直接无法启动。
软件和硬件，被牢牢绑在了一起。而真正成熟的软件系统，应该做到另一件事：
没有硬件，也能开发软件。 硬件坏了，系统也能继续运行。
于是，我们把这个问题交给 Loom。
请分析当前系统为什么在没有连接外设时无法启动，并修复它。
这一次，Loom 没有直接修改任何代码。它首先开始阅读整个项目。不是某一个文件。而是整个启动流程。它沿着程序启动路径，一层层向下分析：
- 系统初始化顺序；
- 各个模块之间的依赖关系；
- 外设初始化逻辑；
- 错误传播路径；
- 启动失败的真正原因。
它不是停留在"这里报错了"。而是继续追踪：
为什么这里会报错？
这个错误为什么会一路传播到整个系统退出？
最终，它定位到了真正的问题根源。随后，它重新调整了整个初始化流程。让每一个硬件模块，都能够首先检测自身状态。如果硬件存在，就正常启用。如果硬件不存在，就自动关闭相关功能，同时继续启动其它模块。
于是，整个系统第一次拥有了"降级运行"能力。
修改完成之后，即使没有连接任何舵机，也可以正常启动。没有 OLED，也能够继续工作。甚至可以：
- 正常进入 Web 管理页面；
- 调试 OTA；
- 验证联网功能；
- 开发新的软件模块；
- 在 CI 中完成自动构建和测试。
从功能角度来看，这似乎只是修复了一个 Bug。但对于整个研发团队来说，它带来的价值远不止如此。软件终于开始摆脱对硬件的绝对依赖。开发、测试、验证，都变得更加高效。
很多经验丰富的工程师都知道：真正体现工程能力的，往往不是增加一个炫酷的新功能。而是能够在一个复杂系统里，找到真正的问题，并且修好它，而不引入新的问题。对于我们来说，这也是整个实验过程中，最能体现 Loom 工程能力的一次任务。
✦ 关键洞察：修 Bug 是对"理解别人代码"能力的终极考验。Loom 沿着启动路径逐层追踪错误传播链，定位到根因后重构了初始化流程——它理解的不只是单文件逻辑，而是整个系统的依赖关系。
从"写代码"，到"完成产品研发"
做到这里，再回头看看整个实验，会发现一个有趣的现象。我们几乎没有讨论过任何具体代码。没有告诉 Loom 应该修改哪个函数。没有指定应该增加哪些类。也没有一步一步教它如何实现。整个过程中，我们做得最多的一件事情，其实只有一件：
不断描述产品应该变成什么样。
例如：
希望它支持 OTA。 希望它能够动态配网。 希望待机时间更长。 希望增加中文支持。 希望机器人更有趣一点。 希望没有外设时也能正常启动。
这些描述，更像产品需求。而不是开发任务。剩下的事情，则全部由 Loom 完成。
它需要自己：
- 阅读整个代码库；
- 理解已有架构；
- 制定实施方案；
- 修改多个模块；
- 编译验证；
- 修复问题；
- 提交 Git；
- 持续迭代。
换句话说，它接管的已经不只是代码生成，而是一次完整的软件研发流程。而随着实验不断推进，我们也越来越清晰地意识到一件事：
真正耗费研发团队时间的，往往不是写代码本身。
而是：
理解。
分析。
设计。
验证。
维护。
这些工作，远比键盘上敲下的那些代码更加重要。
写在最后
这次实验的主角，是一只小小的机器螃蟹。但我们真正想验证的，从来不是机器人。而是另一个问题：
Loom 是否已经能够参与真正的产品研发？
过去，人们评价 AI 编程工具时，最常问的问题是：
它会不会写代码？
今天，这个问题已经越来越容易回答。而 Loom 尝试解决的新问题，则是：
它能不能接手一个真实项目？ 能不能理解已有代码？ 能不能持续维护一个产品？ 能不能陪伴项目一起成长？
在这次实验中，我们没有重新创建一个 Demo。而是选择了一份已经存在的开源项目。
从 OTA，到联网；从续航，到国际化；从新的互动方式，到修复历史遗留问题。一步一步，把它从一个能够运行的 Demo，改造成一款越来越接近真实产品的软件。
整个过程中，Loom 并没有替代工程师。更准确地说，它开始承担工程师原本需要投入大量时间完成的那部分工作：
阅读代码。
理解系统。
制定方案。
修改实现。
验证结果。
持续迭代。
工程师则可以把更多精力放在另一件更重要的事情上：
思考产品应该是什么，而不是代码应该怎么写。
我们相信，这或许正是下一代 AI 研发平台真正的价值。不是帮助程序员多写几段代码。而是帮助整个研发团队，更快地把一个想法，变成真正能够交付用户的产品。
从 Demo 到产品，差的从来不是代码量，而是工程能力。
这只机器螃蟹的六关改造，没有一关是能拿去发布会上炫技的。OTA、配网、休眠、国际化、互动、降级运行——它们不会出现在任何一张宣传海报上，却是一个研发团队在无数个寻常工作日里，真正与之较劲的东西。正是这些没人鼓掌的"最后一公里"，决定了一个项目究竟只是个 Toy Project，还是一款能安心交到用户手里的产品。
织灵想证明的，从来不是"AI 也能写代码"这种已经不再新鲜的事。它想证明的是：当 Loom 真正读懂了你的代码库、你的系统架构、你藏在需求背后的那些意图，它就能站到工程师身边，默默接走那些最耗神、也最容易被忽视的苦活——把人从一遍遍调试与对接里解放出来，回到真正让人热爱这份工作的地方：去想，产品本该是什么样子。
这正是我们一直在做的事。