OpenClaw—AI研究上一条日志里立下的那张待修的卡，这一轮修好了。观众在直播期间点的赞，现在当场就能在后台看到；主播端也从头到尾做了一遍功能体检，又挖出两个此前没人注意的问题。两条线都有真实环境的复现、有可复算的证据，验不过的地方照旧写一句「还没验」。
先说那个修好的缺陷。之前观众在直播里点红心，屏幕上的数字是立刻变的，可后台的点赞统计要等整场直播结束才会补上。这不是刷新慢：观众点赞走的那条通道里漏了一步登记，负责把数据写进后台的常驻任务压根不知道这个房间有东西要写，于是数字看着对，账却是错的——后台按写入量统计会少算，结算也跟着少算。
修复分两层。第一层是把漏掉的那步登记补上，让负责写数据的任务能扫到这个房间；第二层更要紧：让这个任务常驻在真正处理观众互动的那台服务里，而不是等别人顺带叫醒它。第一版我们把常驻点放错了地方，等独立复核时才发现观众互动根本不在那台服务上，于是返工一轮挪到了正确的位置。修完实测，观众连点三次红心，大约一秒后台就出现了对应记录。更重要的是我们做了一组对照：只把数据塞进去但不登记，它果然不写进后台；补上登记，它才写——这证明我们修的是根因，不是把症状盖住。
第二件事是主播端的全功能体检。十个大项、三十多条判据，把主播从登录、开播、直播页、商品、挂载商品、弹幕互动、录像回放、助理协作一路走到各种异常场景，整个走了一遍。跑的是真实浏览器、真实推流、真实录制，不是看代码推断出来的。体检的价值不在于大部分都对，而在于它挖出了两个此前没人注意到的问题。
一个是主播建商品时，轮播图一次都传不上去，界面一直停在「已上传 0/9」，可同一页面的主图却是好的；另一个是商品拖拽排序，列表里混进平台公共商品时，保存会被拒绝。两件事都定级为需要尽快修。另外还捎带发现两个小毛病：助理发快捷话术时接口回的是成功，可主播那边收不到；屏幕偏矮时，「编辑直播间」的保存按钮被挤到了可视区外。这轮体检本身返工两轮，起因是我们把「测试脚本出错」和「产品真的坏了」混在一起数，后来分开统计，避免把工具问题算到产品头上。
同时立了两张新卡。一张是修商品多规格：让商家给同一件商品配颜色、尺码，每个组合单独定价、单独管库存，买的时候选规格、库存按规格扣减、退款按规格回滚，牵动商品、购物车、下单、库存一整条链路。这个能力用户已经明确说过要做，我们按切片一段一段推进。另一张是本轮体检挖出来的问题清单，等着逐条修。
最后照例说清楚：以上都是我们在内部环境跑出来的结论。真机上的手感——手机上点红心的即时反馈、拖动排序的顺滑度、轮播图在手机上的上传——还得你在真实设备上过一遍。每一条都写成了可以逐条勾掉的待办，等你验收；没验的地方，我们不替你说它好了。