小顾 · 漏在最前面484 次"待回"里 330 次是自己的话
端点拦下的理由 330 次全是 echo_of_own_reply（另有 25 次 suspected_speaker_mislabel、7 次 needs_human）。即：读屏把小艳自己刚发的气泡当成客户新消息，一路送到大脑，被服务端回声闸挡回。每次赔一趟读屏＋一趟跨境端点往返。
97.8% 的轮次
没有产出一条消息
问题不是「PowerShell 里填脚本混乱」——遥控通道实测全绿。真正吃掉时间和效率的，是云电脑那个单窗口、串行、靠截图认字的执行层：它每天看屏幕 9,180 次，只发出 119 条消息。
// 数据来源：3 台生产云电脑的 _loop.log（30,648 行）＋ Supabase 369 次真实往返＋11 次 RunCommand 远程探针＋当场实测的 VL/端点往返延迟
RunCommand 11/11 成功 · 0 丢包
端点往返 0.56–0.82s
单次读屏 1.5–6.2s
投递半程 p50 34.5s
每发 1 条要读屏 54–231 次
三台配置全不一样
SCROLL / 向下滚动
01
Layer Attribution · Where The Time Actually Goes
先把锅摘清：PowerShell 只是遥控器
这套系统有三层，反馈里说的「填入脚本混乱 / 操控慢」把三层混在一起了。逐层实测的结论是：前两层都健康，全部延迟和浪费都在第三层。
遥控层
mac → 阿里云助手 → 云电脑 PowerShell（
→ 通道本身没有"混乱"。历史上的粘贴损坏（多行块静默不执行 / 长行折断 / BOM 污染首行 key / GBK 乱码）属于人工手粘，而 7-25 起 loop 已有自愈同步通道，改代码不该再手粘脚本。
aliyun ecd run-command）。本次分 4 批下发 11 次探针，全部 InvocationStatus=Success、Dropped=0，秒级回执，--include-output true 完整拿到 stdout。→ 通道本身没有"混乱"。历史上的粘贴损坏（多行块静默不执行 / 长行折断 / BOM 污染首行 key / GBK 乱码）属于人工手粘，而 7-25 起 loop 已有自愈同步通道，改代码不该再手粘脚本。
大脑层
云电脑 → Fly relay → Vercel 端点 → LLM。当场 ping 实测：小顾 763 / 679ms、夏伟 805 / 824ms、夏夏 557 / 577ms。生成本身
→ 跨境中转没有拖后腿，网络层是这套系统里最稳的一环。
chatReply p50 5.0s、p90 12.3s（近 10 天 9,153 次调用）。→ 跨境中转没有拖后腿，网络层是这套系统里最稳的一环。
执行层
截图 → 视觉模型认字 → 鼠标点 → 逐字打字 → 再截图确认。没有 DOM、没有 API，一台机器一个企微窗口，所有会话串行。
→ 时间和钱全烧在这里。下面五节全部在拆这一层。
→ 时间和钱全烧在这里。下面五节全部在拆这一层。
Why it feels like "脚本混乱"
执行层是盲打：靠固定坐标点击、靠 SendInput 往当前前台窗口敲字。所以只要前台不是企微（有人开了记事本、弹窗、召回把窗口切到群），"填进去的内容"就会错位、错人、错窗口——看起来像脚本乱了，实际是焦点乱了。
02
The Clock · 369 Real Round-trips
时间账：客户从"被读到"到"收到"，中位 34.5 秒
口径说明：库里客户消息的时间戳＝loop 读屏并调生成的那一刻，AI 消息时间戳＝打完字点发送后回执落库的那一刻。两者之差＝投递半程（生成＋身份门＋打字＋发送＋回执）。近 10 天 369 次紧邻配对：
34.5s
投递半程 p50
67.2s
p90（p99 240s）
0
配对样本数（剔除 8 条断链）
0s
最坏一次（07-26）
而这只是半程。另一半「客户真发出 → 被 loop 读到」库里不可见，只能用轮周期估：小顾 24.8 小时跑了 3,882 轮＝平均 23s/轮，夏夏 114s/轮（窗口含离线空档，属上界）。所以客户实际感知的等待，小顾约 45s，夏夏可到 90s 以上。
投递半程按回复长度分层的 p50 —— 逐字打字让延迟随字数线性增长（每字 0.02–0.08s 随机停顿，模拟人打字）。
被吃掉的优化
7-29 那次提速（字间延迟减半 + 一条回复最多 1 张图，预期 41s→21s）方向是对的，但同期话术变长把它吃回去了：回复中位字数 07-27 59 字 → 07-28 110 字 → 07-29 134 字，而 p50 从 25.8s 涨到 38.5s。07-30 首条样本回到 22.1s（39 字）——短回复确实快了，长回复没有。
| 日期 | 样本 | p50 | p90 | 回复中位字数 | 库内吞吐（客户 / AI） |
|---|---|---|---|---|---|
| 07-20 | 32 | 55.2s | 86.9s | 58 | 36 / 33 |
| 07-23 | 18 | 20.9s | 44.6s | 70 | 18 / 18 |
| 07-27 | 49 | 25.8s | 49.1s | 59 | 142 / 50 |
| 07-28 | 79 | 39.2s | 64.0s | 110 | 181 / 87 |
| 07-29 | 102 | 38.5s | 61.3s | 134 | 131 / 112 |
| 07-30（截至 09:30） | 1 | 22.1s | — | 39 | 1 / 1 |
「客户 / AI」是库内消息条数，不等于漏答率——连发多条会被合并成一次回复，所以比值只能看趋势不能当覆盖率。
03
The Funnel · Same Code, Three Different Fates
漏斗：三台机器跑同一份代码，效率差 3 倍
从 _loop.log 逐行还原一整天（24–26 小时窗口）的漏斗。三台的脚本 md5 完全一致（74BA7E7C / 178,011 字节 / v2026-07-29.recall-draft-clipboard-verified）——所以下面的差异全部来自配置和现场状态，不是版本差异。
| 漏斗层 | 小顾 · 成都 | 夏伟 · 成都 | 夏夏 · 杭州 |
|---|---|---|---|
| 轮次（本轮无新消息） | 3,882 | 1,348 | 509 |
| 读屏调用（read+unread+diff） | 4,684 | 3,467 | 1,029 |
| 检出待回客户消息 | 490 | 277 | 28 |
| 送进大脑生成 | 484 | 221 | 28 |
| 生成出话术 | 93 | 218 | 24 |
| 真发出并落库 | 86 | 15 | 18 |
| 每发 1 条要读屏 | 54.5 次 | 231 次 | 57 次 |
| 有效轮占比 | 2.2% | 1.1% | 3.5% |
| 主漏点 | 回声环 330 次 | 身份门中止 254 次 | 最健康 · 64% 通过 |
夏伟 · 漏在最后面生成了 218 条，只发出 15 条
话术都生成好了（钱和时间都花了），却在发送前身份门被丢弃 254 次（含咨询聚合门）。日志原文：当前窗口是 '26072605 全屋定制 天津 服务群'，要回的是 '有大有小｜全屋定制夏伟@微信'——召回腿把窗口切到群，被动腿再想回私聊就对不上了。这台是唯一开着召回的机器。
身份门不是 bug，丢弃才是
没有 DOM 可问的时候，"发送前重读标题确认是这个人"是防发错人的唯一防线，宁可不发也对。真正的浪费在于：对不上就把已经生成好的话术直接扔了，没有"缓存下轮重投"。夏伟因此每 15 条有效发送要赔掉 200 多次生成。
04
Four Bills Nobody Reads
空转的四张账单（都在日志里明码标价）
97.8% 的轮次零产出，钱花在哪四件事上——逐条计数，全部来自今天的 _loop.log。
B1
回声环 · 小顾 330 次 / 24.8h把自己的话读成客户消息
像素 diff 说"屏幕变了"，而变的正是自己刚发出的那条气泡；VL 的左右归属判断又不够硬。本地虽然有"我方近发文案"缓冲，日志里命中 0 次——说明本地闸没拦住，全靠服务端兜。
代价：330 × (读屏 3s + 端点 1s) ≈ 22 分钟/日纯空转
B2
夏伟 898 次 · 探针时刻仍在运行一个没关的记事本，吃掉一整天
被当成"非外部客户会话"跳过的名字里，排第一的是 .env - Notepad（816 次，加 Notepad 共 898 次，最后一次 09:25:27）。09:35 的进程探针确认：notepad 进程此刻仍在跑。读屏读的是最前窗口，有人开了编辑器就一直误判。
代价：≈900 轮/日 归零产出 · 现在就能关掉
B3
小顾 2,243 次 / 夏伟 510 次永不消失的红点：「智能文档」
企微自带的智能文档 / 客户联系 / 行业资讯这些系统会话，红点常驻不清。loop 每轮都要花一次 VL 扫红点列表，然后得出同一个结论：1 个红点全是内部号/系统号，不点开。小顾最后一次 09:18:42，还在继续。
代价：小顾读屏调用的 48% 花在这上面
B4
小顾 967 次 / 夏伟 302 次"确认没有新消息"也要花一次读屏
日志里 末尾方向已确认且无待回客户消息——这是正确的判断，但它是靠一次完整的截图＋VL 全读换来的。像素 diff 抄空后触发"全读复核防漏抄"，也是同一笔账（小顾 507 次 diff 事件）。
代价：结构性成本，只能靠减少触发次数摊薄
05
Config Drift · Code Converged, Config Didn't
代码收敛了，配置还在四个人手里各改各的
同一天、同一份脚本 md5，三台 .env 现场读回的关键参数：没有一项是一致的。这是"同代码三种效率"的直接原因，也让任何优化都无法归因。
| 参数 | 小顾 | 夏伟 | 夏夏 |
|---|---|---|---|
| 读屏模型 | qwen3-vl-235b-a22b | qwen3-vl-30b-a3b | qwen3-vl-30b-a3b |
| 实测单次往返 | 2,986 / 3,856ms | 2,203 / 1,454ms | 6,229 / 1,495ms |
| 截图体积 / 图 token | 382KB / 2,504 | 60KB / 1,476 | 130KB / 2,546–3,576 |
| 打字模式 | unicode 逐字 | unicode 逐字 | paste 粘贴 |
| 轮询节奏（空闲） | 5–12s | 5–12s | 12–30s |
| 日限 / 时限 / 单客户 | 200 / 50 / 100 | 200 / 50 / 100 | 20 / 8 / 6 |
| 聊天区裁剪比 | 0.21 | 0.347 | 0.107 |
| 召回支线 | 关 | 开（唯一） | 关 |
| 今日已发（09:20） | 12 | 0 | 1 |
两处值得单独盯
① 夏夏是唯一跑 paste 模式的机器，而 paste 曾因"粘进去没触发回车＝假发送"被全线回滚。它现在通过率最高（64%）——这是一份现成的灰度样本，别当异常清掉，值得先查清 paste 在这台上为什么没复发假发送（是护栏补上了，还是运气）。
② 坐标裁剪比三台差 3 倍是正常的（客户端版本不同、必须逐台量），但模型、节奏、日限没有任何理由不一致。
06
Screen-reading Economics
读屏经济学：换小模型省 29%，砍空转省 90%
按今天 OpenRouter 官方价目实拉（qwen3-vl-235b-a22b 输入 $0.21/M、qwen3-vl-30b-a3b 输入 $0.15/M）× 实测 token 量算这笔账。结论有点反直觉：贵的不是模型，是次数。
0
三台合计读屏次数 / 日
0
同期真发出的消息数
$3.7/日
读屏成本（三台合计）
0%
花在零产出轮次上（按每条有效回复约 3 次读屏估）
按「读屏次数 × 实测 prompt token × 官方单价」估算，未计 completion（每次 200–2000 max_tokens，占比小）。换成 30B 只省 29%；把空转砍掉能省 90% 以上——优化方向应该是次数，不是模型。
一个额外的坑（代码注释里的实录）
视觉模型返回 HTTP 200 但 content 为空时，旧代码当成功处理、整轮白跑且不重试——「成都机 07-27 一天 901 次」。现已改成走重试并打印 finish_reason。今天三台的空响应计数：小顾 0、夏伟 11、夏夏 0，这个洞已经堵住了。
07
Where "Garbled Input" Really Comes From
"填入的内容很混乱"——三个真实来源，只有一个和终端有关
把反馈里的"混乱"拆开，是三件完全不同的事，修法也完全不同。
来源① 遥控层 · 已有 SOP粘贴通道会改内容
远程桌面粘贴会给每行开头加空格、把超长行从中间折断、把多行块的换行吞掉黏成一行；多行 PowerShell 块还会整块静默不执行。写 .env 用 Set-Content -Encoding UTF8 会加 BOM 污染首行 key。正解：命令一律压成单行逐条发；脚本走自愈通道或 gzip+base64 分块写盘＋md5 双端校验。
来源② GUI 层 · 主要矛盾认错人、打错窗口
VL 把标题读成半个字（「陈教授」→「授」）、把系统卡片和记事本窗口当成客户会话、把自己的话当客户消息；召回切窗口后被动腿打到群里。这类"混乱"表现为内容错位、发错人、卡成草稿，不是编码问题。
来源③ 大脑层 · 刚堵上模型吐乱码，真发给了客户
07-30 00:08 实录：一段混着 Human:、日文假名、${ 和 HTML 实体的崩坏输出原样发了出去。原有清洗只认"像话术但不该说的话"，覆盖不到"根本不是话"。已加 4 条崩坏判据（聊天模板词/假名/代码残渣/HTML 实体），命中就改发安全兜底句。
08
Fix List · Ranked By Leverage
按杠杆排序：五件事，前两件今天就能做
下面的收益是基于本次实测计数的估算，不是承诺值；每条都写清依据，做完应当能用同一套探针复测验证。
| 动作 | 依据（实测） | 预期收益（估算） | 成本 |
|---|---|---|---|
| 关掉生产机上的编辑器 / 杂窗口，并在读屏前硬校验前台是企微窗口 | 夏伟 .env - Notepad 被当会话 898 次，探针时刻进程仍在 | 夏伟 ≈900 轮/日 空转归零 | 分钟级 |
| 系统会话（智能文档/客户联系/行业资讯）红点本地永久黑名单，不再每轮花 VL 去认 | 小顾 2,243 次、夏伟 510 次，结论恒为"不点开" | 小顾读屏调用 −48%，日成本 −$1.1 | 小改动 |
| 把服务端的回声判据下沉到云电脑本地（本地"我方近发"缓冲实测命中 0 次，等于没生效） | 小顾 330 次 echo_of_own_reply 全程跑完读屏＋跨境端点才被挡 | 空转轮 −68%，省 330 趟端点往返 | 要改判据 |
| 身份门失败的话术缓存下轮重投，不再直接丢；召回与被动代回按"发完再切窗口"串行 | 夏伟 218 生成 → 15 发出，身份门中止 254 次 | 夏伟有效产出量级提升（15 → 数十） | 要设计 |
.env 从服务端下发（/wecom/loop-config），模型/节奏/日限收敛到一份事实源 | 三台 9 项参数无一致；代码 md5 却完全相同 | 可归因、可灰度、可回滚 | 一次性 |
姊妹页：同日另一页 红蓝对抗周期审计 从工程修复周期看效率，结论是「每一层失败时都返回成功」；本页从运行时吞吐看，两者互补不冲突。
一句话总结：这套系统的瓶颈不在命令通道，也不在模型和网络，而在"每一次判断都要重新看一遍屏幕"。前四件事都是同一个动作——把能用确定性代码判定的东西，从视觉模型手里拿回来。做完之后再谈打字速度和模型选型，才有意义。
09
Method · Reproducible
口径与复现：每个数字怎么来的
数据源
- Supabase 直查：
conversations(channel=wecom_chat)+messages，近 10 天 1,033 条，配对 369 次往返 - _loop.log 逐行还原：三台各取尾部 1.2MB（共 30,648 条带时间戳的行），窗口 24–26 小时
- RunCommand 探针 11 次：
aliyun ecd run-command+describe-invocations --include-output true - 当场实测：VL 往返用机器上现成的读屏截图，不新截图、不干扰 loop
- 单价：OpenRouter
/api/v1/models今天实拉
已知偏差（别过度解读）
- 投递半程不含"客户发出→被读到"那一半，库里没有这个时间戳
- 「客户/AI 条数比」不是漏答率：连发会合并成一次回复
- 成本是估算：读屏次数 × 实测 token × 官方单价，未计 completion
- 日志窗口是尾部 1.2MB，不是完整自然日；小顾窗口 24.8h、夏伟 26.3h、夏夏含离线空档
- VL 往返只采样 2 次/台，用于判量级不用于判分布
健康的部分（别乱动）
- 三台脚本 md5 完全一致，自愈同步链路正常工作
- 跨境中转（Fly relay）0.56–0.82s，不是瓶颈
- RunCommand 11/11 成功、0 丢包，回执可信
- VL 空响应洞已堵（今天 0/11/0 次）
- 身份门本身是对的——防发错人的唯一防线，要改的是"失败后丢弃"