给Claude Code配物理状态灯：用ESP32告别盯终端等待

AI编程的隐性痛点：谁在替你盯终端？

使用 Claude Code 这类 AI 编程工具时，一个反复出现的尴尬场景是：提出问题后，你不得不守在终端前，等它思考、执行、或弹出确认提示。这种「人质式等待」本质上是注意力的浪费——AI 后台运转的几十秒乃至几分钟里，你既不敢去做别的事，又怕错过它的权限申请。

Claude Code 是 Anthropic 推出的终端 AI 编程工具，区别于 Copilot 等代码补全工具，它以「Agent」模式运行：接收任务后可自主调用 bash 命令、读写文件、执行测试，并在需要高风险操作时向用户申请权限确认。这种模式借鉴了 ReAct（Reasoning + Acting）框架的核心思想——该框架由普林斯顿大学和 Google Brain 研究人员于 2022 年提出，核心创新在于将推理链与工具调用行动交织执行：模型不再单纯生成文本，而是先「思考」再「行动」，并将每次执行结果作为下一轮思考的输入，形成「思考—行动—观察」的持续闭环。这一框架显著提升了模型在多步规划任务上的准确性，也成为 LangChain、AutoGPT、Claude Code 等主流 Agent 框架的核心设计基础。正因如此，Agent 模式能够完成多步骤复杂任务，但也引入了不确定的执行时长和中途需要人工干预的节点。这种「委托—执行—确认」的异步模式与传统「输入—输出」的同步交互有本质区别，是当前 AI 编程工具的主流演进方向，也是「等待感知」痛点产生的根本原因。

一位 B 站 UP 主给出了一个颇具工程师浪漫的解法：做一块物理状态灯，把 Claude Code 的实时状态映射到显示器下方的一盏灯上。眼角一扫，就知道 AI 现在在干什么，彻底把视线从终端里解放出来。

实际使用效果

状态灯如何工作：四色对应四种状态

颜色即状态，一眼读懂工作流

这套方案的核心逻辑极为直观，用颜色把 Claude Code 的工作节点拆解清楚：

蓝灯（旋转动效）：执行中，AI 正在思考或调用工具
黄灯：等待用户确认权限（如询问是否执行某条命令）
绿灯：任务完成
红灯：运行报错
熄灭：空闲待命

硬件核心是一块 ESP32 开发板。ESP32 是乐鑫科技（Espressif）于 2016 年推出的低成本、低功耗微控制器，搭载双核 Xtensa LX6 处理器（主频高达 240MHz）、内置 520KB SRAM，并集成了 Wi-Fi 802.11 b/g/n 和蓝牙 4.2/BLE 功能。其双核架构可将网络通信与业务逻辑分配到不同核心并行处理，避免 Wi-Fi 驱动抢占应用层 CPU 时间——这对需要精确时序控制的 LED 驱动场景尤为关键。乐鑫还为 ESP32 提供了完善的 IDF（IoT Development Framework）和 Arduino 兼容层，使来自 Arduino 社区的大量库可以直接移植，是当前创客社区最流行的嵌入式开发平台之一。几十元的价格配合 Arduino 或 MicroPython 生态，使其成为联网硬件项目的首选。上电后，ESP32 先连接 WiFi，连接成功后自动轮播所有灯效——既是开机自检，也确认硬件链路正常。

蓝灯旋转：AI正在思考

一次完整的交互演示

UP 主在视频中跑通了完整流程。向 Claude 提出问题后，灯首先变为蓝色并旋转，代表 AI 开始调用工具推进任务。

第一次测试恰好未触发权限确认，灯从蓝直接跳绿。为展示完整链路，他又刻意让 Claude 走了一遍需要确认的流程：

蓝灯（执行中）→ 黄灯（等待用户确认）→ 确认后重回蓝灯（继续执行）→ 绿灯（完成）

完整状态链路演示

这套状态机精准对应了 Claude Code 的实际工作节奏，尤其把「等待权限确认」单独用黄灯标出，解决了最易被忽视、又最需要人工介入的环节。

为什么这个DIY项目值得关注

从「主动轮询」到「被动感知」

这个项目最大的价值不在技术复杂度，而在于对工作流体验的精准洞察。UP 主的原话很能说明问题：「问完问题就可以用显示器干别的事了，眼角一瞟灯是蓝色就知道它在干活，灯变黄了就知道它在向我申请权限。」

本质上，这是把主动轮询（盯着终端刷新）转化为被动感知（余光扫灯）。人对颜色和光的感知几乎零成本，开发者可以在 AI 执行的空档期真正切入其他任务，不必担心错过关键节点。

绿灯亮起：任务完成

Agent 时代的「环境感知」新思路

随着 Claude Code、Cursor 等 AI Agent 工具普及，人机协作正从「一问一答」演变为「委托—等待—确认」的异步模式。在这种模式下，如何让人以最低认知成本掌握 AI 实时状态，成了一个真实的产品命题。

物理状态灯是**环境计算（Ambient Computing）**的朴素实践。这一概念源自施乐 PARC 研究员 Mark Weiser 于 1991 年发表的奠基性论文《The Computer for the 21st Century》。Weiser 与其同事 John Seely Brown 进一步发展了「平静技术（Calm Technology）」理念：优秀的技术设计应当能在「注意力中心」和「注意力边缘」之间自如切换，仅在需要时进入用户焦点，其余时间退居外围，以不打扰的方式服务人类。物理状态灯正是平静技术的典型实现——灯光变化只需余光感知，不触发屏幕通知，不打断当前任务流，只在颜色切换时自然吸引注意。这一理念在 2000 年代被 Alistair Cockburn 引入敏捷开发社区，演变为「信息辐射体（Information Radiator）」实践：要求团队将关键指标以物理可见的形式展示在工作区，让信息「主动找人」而非「让人找信息」。CI/CD 领域经典的「构建状态灯」（Build Light）正是软件工程中最早落地的环境计算案例之一——Facebook、Google 等公司均有团队将物理灯挂在工位旁，红灯代表构建失败，绿灯代表主干健康。这位 UP 主把同类逻辑迁移到 AI 编程场景，可谓恰逢其时。

动手复现：门槛与开源资源

从硬件角度看，复现成本相当低：

ESP32 开发板：几十元
可编程 RGB 灯：如 WS2812 灯珠或灯环。WS2812（及其改进版 WS2812B）由 WorldSemi 公司设计，最大创新在于将 PWM 控制芯片直接封装在 RGB LED 内部，实现单线串行级联控制——任意数量的灯珠只需一根 GPIO 信号线即可驱动，每颗灯珠接收属于自己的 24 位 RGB 数据后将剩余数据转发给下一颗，形成数据链。其通信协议通过精确的高低电平时序传输数据（0码：高电平约 0.35μs + 低电平约 0.8μs；1码：高电平约 0.7μs + 低电平约 0.6μs）。ESP32 的 RMT（Remote Control Transceiver）硬件外设原本为红外遥控信号设计，但其可编程的高精度时序控制特性恰好满足 WS2812 协议的严苛要求，可在不占用 CPU 资源的情况下精确生成驱动信号，无需额外的 LED 驱动芯片，极大简化了电路设计。这一创造性用法已被 ESP-IDF 官方文档收录为标准示例。
状态推送脚本：Claude Code 提供了完善的 Hook 系统，开发者可在配置文件中注册特定事件的回调脚本——例如工具调用前（PreToolUse）、工具调用后（PostToolUse）、模型完成响应（Stop）等关键节点。这些钩子以子进程形式执行，可接收包含当前状态、工具名称、执行结果等信息的 JSON 上下文。开发者编写 shell 脚本监听这些事件，通过 HTTP 请求将状态变更实时推送给 ESP32 上运行的轻量级 Web 服务器，整个链路的端到端延迟通常在 100 毫秒以内，足以提供近实时的状态反馈体验。这种 Hook 设计不仅支持状态灯场景，还可用于自动化审计日志、成本监控等扩展用途，体现了 Claude Code 在 Agent 安全性上的前瞻考量。

UP 主已将完整代码开源发布在评论区，感兴趣的开发者可直接取用参考。

对于重度依赖 Claude Code 或 Cursor 的开发者来说，这个 DIY 小项目或许能切实改善日常工作节奏。它也提醒我们：提升 AI 协作效率，有时候不需要更强的模型，一个更贴心的交互设计就够了。

小结

这盏放在显示器下方的状态灯，是一个典型的「小而美」工程作品。没有炫技的算法，却精准命中了 AI 编程时代的真实痛点——如何在异步协作中保持从容。当越来越多的任务被委托给 AI Agent，我们需要的不只是更聪明的模型，还有更人性化的状态反馈机制。从 Mark Weiser 提出环境计算与平静技术理念，到软件团队挂起构建状态灯，再到今天开发者为 AI Agent 打造物理感知界面，这条探索「计算隐入环境」的路径从未中断。ReAct 框架赋予了 AI 持续行动的能力，ESP32 与 WS2812 的硬件组合降低了物理反馈的实现门槛，而 Claude Code 的 Hook 系统则提供了软硬件之间的标准化桥梁。这盏灯，正是这个方向上值得借鉴的起点。