客户半夜发来一句「在吗」，谁来替你回？

一句话：客户随时说话，程序先接住；拿不准的那几条，才交给人。

做培训、做服务的人都躲不开一件事：客户不问时间。晚上十点四十来一句「老师，那个课怎么报」，第二天早上才看见，人已经凉了。可要真做到秒回，等于把自己钉在屏幕上，一天什么都干不成。

这个值守程序站的就是这个位置。它每 60 秒巡检一次两个微信窗口，读到新消息就判一次：这条能不能自己回。能回的当场回，回不了的截图转给李雪。客户那边永远有人应，人这边不用盯着。

关键的一条设计是回复不靠模板。早先的版本用关键词规则，客户说一句「接口请写在我服务器上，配置在 D 盘那个文档里」，规则引擎只答得出「收到，您说的我记下了」——客户一眼就看出来这是机器人。现在把整段对话交给 WorkBuddy 读一遍，让它判断意图、写一句贴合原话的回复，再发回去。实测一次 33 到 41 秒。

第二条设计是企业微信按只读处理。个人微信能回就回，企业微信一个字节都不写：不点击、不输入、不激活窗口。理由写在下面这一节里，代价是真金白银掉过两次登录。

触发词：微信自动回复 / 监控微信新消息 / 客服值守 / 装一下那个监控 / 企业微信有红点通知李雪 / 转交给梦由 / 这个监控怎么又停了 / 开机自启没生效。

不适合拿它做的事也说清楚：它不碰群聊和公众号，只看单聊；不给企业微信发一个字；不报价、不承诺时间、不签任何确认——这三条是口径，写在人设里，任何一层都不许越过；不替人做决定，遇到必须由人拍板的事只转交，不猜。

企业微信能走无障碍接口，个人微信是 Qt 自绘的，只能截屏认字。同一个判断，读法完全两套。

怎么向 WorkBuddy 提问

WorkBuddy 是 Electron 应用，聊天文字通过 UI Automation 暴露出来，get_app_state(window_id, mode="text") 能拿到屏幕上全部可见文字，还带坐标。这一段不需要 OCR，准确率 100%——整套方案能成立，靠的就是这一条。

提问的协议也刻意做得简单：只要它回两行中文标签，不要 JSON。中文标签在文字流里不会和正文混淆，正则一抓就准。

# 发给 WorkBuddy 的要求：只回两行
动作：回复        （或者：转交）
内容：给客户看的话，40 字以内

这几十秒里窗口会被切到前台。如果检测到输入框里已经有内容，说明人正在里面打字，这一条就主动让开，退回规则引擎——不抢人的键盘。

读个人微信，四个绕不过去的坑

还有一条比时间更可靠的判据：红点是微信自己画的，不受 OCR 错字影响。红点亮着就强制按新消息处理，宁可多回一次，不许漏一条。

29 个文件，235 KB。主流程一份、人设一份、踩坑记录一份、脚本二十三个。

daohu-cs-monitor/
├── SKILL.md                  主流程：五条铁律 + 判断链路 + 故障对照表（8 KB）
├── config.json                人设、转交对象、安静时段、限频
├── persona.md                 回复口径：硬性规则 + 八种场景话术
├── install.py                 一键部署：复制程序、建 state/、写开机自启
├── run-monitor.bat            守护循环：进程挂了 20 秒自动重启
├── references/
│   └── lessons.md             十五条踩坑记录，每条都付过代价（8 KB）
└── scripts/                   23 个脚本，5717 行
    ├── monitor.py             主循环：巡检 → 判定 → 回复 / 转交（625 行）
    ├── brain.py               决策：四层判断的具体实现（709 行）
    ├── wbbrain.py             把 WorkBuddy 当大脑：提问、读回、解析（447 行）
    ├── send.py                发消息：写操作唯一入口，先查 WRITABLE
    ├── capture.py             PrintWindow 抓图，零触碰
    ├── layout.py              自适应布局：窗口尺寸变了不用重标定
    ├── ocr.py                 OCR 封装，返回带坐标的文本行
    ├── ledger.py              台账：每个会话处理到哪条、时间置信度
    ├── inbox.py / watch.py      巡检：零触碰扫描与被动监控
    ├── wx.py / ww.py          两个客户端的各自适配
    ├── kimicu.py              kimi-cu 的 stdio MCP 客户端封装
    ├── llm.py                 HTTP 模型接口（CLI 那条路已经放弃）
    ├── doctor.py              开工自检：两个窗口读不读得到
    ├── notify.py              给李雪补发一句话，手工救场用
    └── winlist / winlib / winfix / act / probe / wwgeo / setkey

主脚本各管一段

跑之前得备齐

五条铁律，改代码之前先读一遍。每一条下面都压着一次事故。

三道闸，防止对着同一句话回三遍

第一道是时间置信度：四位数字对不上，就只登记发现时间，不推水位。第二道是 90 秒冷却，刚回过的那一行直接跳过。第三道是每小时三条上限。三道闸合起来，同一个客户不会连着收到三条一模一样的「在的，您说」。

安静时段那条也值得单独说：半夜给客户回消息，比不回更像机器人。这段时间返回「压住」，但是不推水位，早上第一轮巡检会重新把它判成新消息，照常处理，不算漏。

踩过的坑，都留了处理办法

解压后先跑 python install.py，程序会自己装到 %USERPROFILE%\WorkBuddy\daohu-msg 并写好开机自启，然后打印剩下要手工做的三件事。

装法

:: 1. 解压，进目录
:: 2. 一键部署（默认装到 %USERPROFILE%\WorkBuddy\daohu-msg）
python install.py

::    想换目录就带个参数
python install.py D:\tools\daohu

:: 3. 先跑一轮看看日志，不动微信
python scripts\monitor.py --once

:: 4. 没问题就前台常驻（或双击 run-monitor.bat）
python scripts\monitor.py --interval 60 --auto-reply

部署完还有三件手工活，install.py 会把它们再打印一遍：把微信和企业微信都打开、保持窗口可见；打开 WorkBuddy 并登录；改 config.json 里的 targets.alert_contact，改成那台机器微信里李雪的备注名——必须跟备注一字不差，否则找不到人。

注意：技能目录里的 scripts/ 是可移植母版，不要从技能目录直接启动。它没有 state/，起来以后台账从零开始，会把所有老会话当成新消息再回一遍。请走 install.py 装到独立目录。