在上篇里,我已经让 ROG 键盘和 Yeelight 挂灯跟着 Codex 的状态变色:工作时蓝色,需要我回答时橙色,完成后绿色,过一会儿再回到平时的彩色灯效。
这个想法来自 Codex Micro 的指示灯。我希望不用一直盯着聊天窗口,也能知道任务有没有结束、是不是在等我。
但真正用起来以后,我又想加一点东西:如果同时开着两个、三个对话,能不能让键盘分别显示它们的状态?如果 Codex 本身就能给 Micro 发送状态,能不能不再依赖 hooks?
于是,我和 Codex 又折腾了几轮。最直观的变化是桌面版真的出现了 Micro 的欢迎向导;最费时间的部分,却发生在它已经显示“已连接”之后。
封面是 AI 生成的概念插画,用来表达状态与灯光的连接关系,不是实机照片,也不作为灯效测试证据。下文的软件截图来自我的实际测试。
一块键盘,能不能看几个对话?
原来的整块变色很直接,不过只能给出一个汇总结果。我说的多个对话,包括主窗口里的任务,也包括 Codex 右侧打开的另一个对话。
最开始的想法很朴素:两个就左右分,三个就左中右,再多一些也可以继续分,但要有上限。每个区域显示一个任务的状态。
第一次测试时,颜色确实出来了,边界却不太对。后来按这台 G615LR 的实际键盘布局重新校准,去掉不适用的数字小键盘布局假设,三色分区才变得正常。空格这样的大键也需要单独考虑:一个物理按键只能显示一种颜色,不能因为它跨过两个区域,就把它当成两颗灯处理。
紧接着又遇到了一个问题:两个相邻任务都在工作,两个区域都是蓝色,看起来又连成了一片。
我们试过白色分隔键,也试过熄灯隔离带。我反馈过“三色正常,但同色区分隔不清”。后来我举了个例子:一个蓝区向左流动,另一个向上流动,会不会更容易区分?
这把问题从分区带到了动画。区域越多,每块越窄,灯光本身也越难读。能把颜色写进去,离“我扫一眼就能看懂”还有距离。
我想用官方动画,结果发现要分开看
流动效果做出来之后,我的感觉是卡。既然 G-Helper 的灯效看着很顺,能不能直接用它的方式?
这里需要把两种控制方式分开。
整块键盘的常亮、呼吸,可以给键盘发送模式命令,让设备自己运行效果。任意分区里的独立波浪,则需要更细的逐键控制。目前这条实现路径还没有验证出“每个任意分区都能独立调用固件波浪”的能力,所以不能把整板原生动画当成多区动画的现成替代。
软件逐帧发送也做过优化。一次短测里,旧逻辑的实际提交频率约为 6.20 次/秒,调整调度后约为 29.71 次/秒。不过这测到的是程序提交灯光数据的节奏,不是相机测出的 LED 刷新率,更不能代替我的肉眼反馈。
我后来更在意的是颜色是否清楚。任务提示不一定要一直动,尤其不能为了波浪把蓝色压得很暗。动画保留为探索方向,日常显示先回到容易辨认的常亮。
让桌面版真正认出 Micro
接下来,我提出了另一个要求:“我不想用钩子做这个。”
上篇的路线是读取 hooks 事件,再由 Hub 判断状态。这次尝试的是在 Windows 上提供一个兼容 Micro 通信的虚拟 HID 设备,让 Codex 桌面版本身发送灯光状态,再把它转给实际的 ROG 键盘和 Yeelight。
大致路径是:
Codex 桌面版
↓ Micro 灯光状态
虚拟 HID 设备与本地桥接程序
├→ ASUS HID → ROG 键盘
└→ 本地 MIoT → Yeelight 氛围灯
起初 Windows 已经能看到设备,本地程序也能枚举到,Codex 却没有真正开始通信。继续检查后,发现还涉及桌面版筛选设备时使用的设备路径。调整虚拟设备的标识路径之后,欢迎向导终于弹了出来。

桌面版出现了 Micro 的欢迎向导。这里连接的是本项目的虚拟兼容设备,不代表我购买或接入了一台实体 Micro。
这个时刻很有意思:最初只是受到它的指示灯启发,现在终于走到了桌面版原本为它准备的状态通道。
不过,“原生”这个词也容易把几件事混在一起。在这里,我说的是状态由 Codex 的 Micro 通道发出;接收和转译仍然靠本地桥接,键盘仍然是 ASUS 的设备。它不意味着 ROG 键盘变成了 Micro,也不意味着分区动画就由 ASUS 固件自动完成。
这条路线涉及虚拟驱动和本地证书信任,也不是拷贝一个脚本就结束的普通配置。我把它当作自己这台机器上的兼容性实验,而不是已经适合所有人安装的通用方案。
欢迎向导能打开,不代表所有功能都实现了
向导里的智能体按键很贴合我最初想要的体验:六个位置,各自显示状态。截图里的图例包括白色空闲、蓝色思考中、绿色已完成、琥珀色需要输入、红色错误,以及关闭表示未分配。


我目前接的是灯光状态。截图里介绍的命令键、旋钮、麦克风,以及点击按键切换任务,都不能因为欢迎向导出现了,就算成本项目的功能。桥接程序也不会替我点击批准按钮。
设置页同样需要这样看:它显示已连接,能看到亮度和自动调暗设置,是通信接入的证据。但虚拟设备报告的“电池 100%”只是兼容信息,不能当作笔记本电池读数。

测试时的设置页:亮度为 100%,自动调暗关闭。设置值正常,仍然不保证实际键盘颜色足够明显。
还有一个限制:这条实现接收的是六个原生槽位的灯光状态,不是读取所有聊天内容、任务标题或者百分比进度。它不能无上限地把所有打开的对话铺到键盘上,也不能承诺槽位始终对应屏幕上从左到右的窗口位置。
接通之后,我看到的却是一整块淡蓝白色
接入成功之后,实际效果仍让我不满意。我先反馈“整块蓝”,后来又觉得颜色很淡,基本看不清,甚至像白色。
这次没有继续只看日志里的“发送成功”。我们做了一轮独立的硬件测试:先整块红色,再左蓝右橙,最后左红中绿右蓝。我确认这三种都看到了。
这至少说明键盘能显示明显的颜色,也能接受分区数据。但它只验证了输出路径,不能证明真实聊天状态已经显示正确。接下来还得把状态选择、颜色映射和显示方式一起检查。
此前的显示会把原生槽位里的白色空闲状态也带进键盘,加上浅冰蓝和亮度变化,视觉上很容易变成一片偏白的光。后来的日常策略改得更直接:
- 白色和关闭的槽位不再挤占键盘上的活动区域。
- 只有一个有色状态时,用整块键盘显示。
- 多个有色状态时,再做分区。
- 工作蓝改成更饱和的蓝色,RGB 为
35, 105, 255,先用常亮保证可见。
原始槽位数据仍然保留,改变的是呈现方式。至于相邻同色区域,目前还不能说已经完美解决,尤其不能把两区、三区通过测试,推成所有分区数量都清楚可读。
后来我又提了一个更直接的改法:把分界处的一条按键都点亮,不要只在顶部放一个白色标记。调整后的实拍里,两个相邻绿区之间已经出现了纵向白色分隔键。键盘每一排的位置有错位,大键也不能切开,所以它是一串沿边界排列的亮键,不是一条连续的灯带。

最新原图:左侧蓝色,中部与右侧绿色,白色按键标出两个相邻绿区的边界。这次改动后的代码测试为 110 项通过,照片记录实际显示效果。
写这篇时,我又拍了两张新版分区的效果。第一张能看到左右蓝色、中间绿色;第二张多了一块黄橙色,从左到右是蓝、黄橙、绿、蓝。和之前那种整块偏白的观感相比,这两张照片里已经能直接辨认出不同的颜色区域。



新版分区实拍之二:四块区域同时显示。照片里的黄橙色会受拍摄曝光和白平衡影响;两张静态照片只记录颜色与空间分区,不证明动画帧率,也不单独证明每个区域的任务对应关系。
真正询问时也单独试过。我在一次真实询问里确认键盘和挂灯都变成了橙色。这个反馈比手动发送一个橙色测试命令更有意义,因为它走的是实际交互链路。

另一组分区近照:左侧黄橙色,右侧蓝色。不同状态可以同时留在键盘上。

这张全景把询问窗口、键盘上的黄橙色区域和挂灯两端的橙光拍在了一起。比起只看设置页,我更想保留这种实际使用时的画面。
完成以后,我还是想回到原来的彩色
另一个让我直接要求改回去的地方,是任务结束后的灯。
我问:“运作完的灯为什么关了,还是和以前一样比较好。”
如果把原生槽位的关闭状态直接照搬到整个桌面,任务结束可能就把灯关掉了。但我平时用的就是彩色灯效,希望任务提示只是暂时覆盖它,而不是接管之后再把它熄灭。
后来的修正恢复了本地的完成保持:收到绿色完成状态后,保持三分钟,再恢复平时的灯效。键盘恢复 G-Helper 保存的灯效,Yeelight 恢复配置的空闲灯效。

沿用上篇的彩虹灯效实拍,展示我想保留的日常效果,不单独证明三分钟倒计时与自动恢复的全过程。
这三分钟也不能挡住新任务。同一位置如果又变成蓝色、橙色或红色,就立即显示新状态;重复收到同一轮绿色不会不断延长倒计时。保持期间收到白色或关闭,也不应立刻把完成提示切掉。
这里还有一个边界:如果根本没有收到绿色,只是从蓝色变成关闭,就不能擅自判断“任务完成了”,再编出一段绿色提示。
这一轮修改后的本地测试记录是 109 项通过。它验证了程序行为,但截至这篇记录,我还没有把完整三分钟的双设备实机保持、恢复过程当作已经验收的结果。长时间使用、重启后的恢复,以及多个真实任务同时变化,仍然需要继续观察。
我现在更想要一盏看得懂的灯
这一轮从分区开始,绕到了逐帧动画、虚拟 HID 和 Micro 状态,最后又回到了很简单的要求:蓝色得看得清,需要我回答时要提醒,完成后别马上消失,也别把我原来的灯效弄没了。
Micro 给我的启发一直没有变。我喜欢的是把任务状态放到视线边缘,不用频繁切回聊天窗口。至于是不是每个区域都在滚动、有没有复制出向导里的全部功能,反而没那么着急。
目前的版本已经能继续沿着原生状态接入这条路走,也保留了后续校准和回退的余地。我会先让它在自己的桌面上稳定工作,再决定哪些效果值得留下。
毕竟我想要的是它在需要的时候叫我回来,而不是让我一直盯着灯,猜它现在到底是什么意思。
留两张整理后的桌面照片
最后,我也给两张照片做了 AI 美化,整理曝光和背景,留作这篇的视觉记录。前面的原图仍然保留。美化版可能重绘按键字符、屏幕文字和局部细节,不用于核对按键映射、灯光亮度或软件界面。



评论
聊聊你的想法,使用 GitHub 账号参与讨论。