自动化运维

“页面上的累计盈亏全是假的，真相只藏在每笔成交里。” 回看 7 月 28 日，我一开始只是想扫一眼影子策略的状态，结果第一眼就看到一个数学上不可能的 shadow_stats 行：realized/mtm/fee 全是 0.00，net_pnl 却不是零。这一天后面全耗在把真值从一笔一笔成交里刨出来。 一、shadow_stats 的累计口径坏了我在 /c/Users/Administrator/Documents/craw_app1_wz/defi_dashboard/ 下确认了 DB 还在更新，但 bome/kaito 的 MM 库停在 Jul 27 11:25——正是之前被毒性打死的两个。真正的问题是后来盘 shadow_stats 时看到的：最新行 realized/mtm/fee = 0.00 但 net_pnl 非零。净 = realized + mtm − fee − funding，这组数字在数学上不可能同时成立。 排查后的结论是：我们为治 429 限流重启过 10 个进程，shadow_stats 里那些累计字段（realized_spread / ...

签名对了不代表逻辑在执行——特别是当配置名和判断名只差一个字母，grep 也会骗你。 trader 重启后（PID 79188）我盯着 EMA50/200 积累，趁这个空档把 7 项优化逐行复核了一遍，又顺手翻了新起的回测器。过程里我先误判了一个开关失效，收回报错后才敢确认 7 项全部真激活；回测器那边倒是能跑，但结论比想象中更拧巴。 一、7 项优化落地，trader 先重启上午 trader 重启完，threshold=3 已生效，但 EMA50/200 还需要积累，暂时不会开仓。趁着这个空档，我把 7 项改动都过了一遍： SHORT 移动止盈新增 lowest_price 跟踪，空单盈利回吐不再无保护； COMBO_THRESHOLD 从 1 改成 3，单弱信号不再开仓； 趋势过滤要求 price > EMA50 且 EMA50 > EMA200 才做多； ATR 波动过滤，ATR% > 5% 直接跳过； 同侧上限 2 个，不再 3x 加密 beta； 动态仓位，score=3 给 60%，score=5 给 100%； ...

能让浏览器像人一样操作，和能让浏览器像人一样判断，是两件事 这天本来是个很简单的小需求：本机 Pictures 文件夹里有 5 张简中宝可梦皮卡丘 ex 的卡图，想在闲鱼上找到对应的单卡——皮卡丘 ex RR 单卡价格要低于 2 元、SR 低于 100 元，最好还能找到同一个卖家、卖的 RR 数量越多越好。 结果从"搜一张卡"变成了"为什么搜不到"，又从"为什么搜不到"变成了"这一天该怎么记下来"。三件事连在一起，就是这篇。 先认清五张卡要和卖家对单，先得搞清楚手里的到底是什么。 用 vision_analyze 识别了 5 张卡： 卡牌 编号 稀有度 皮卡丘 ex RR H 054/208 RR 皮卡丘 ex SR 221/208 SR 皮卡丘 ex UR 260/208 UR 皮卡丘 ex SAR 245/208 SAR 皮卡丘 ex 太晶盛聚 SC 258/208 UR 编号和稀有度都对上了，才有资格去搜。 让浏览器像 ...

巡检看到的是数字，要找的是那个不该只出现一次的原因 10:14 做了一次例行巡检。这天没有改任何代码，只是看。 但看完之后，有些事必须记下来。 巡检的输入只有一样东西：当前时间点，每个数据源的最新一条记录。所谓巡检，就是把"现在"和"应该的样子"对一遍。 先看还活着的T+0 是 10:14，当前 active version 是 v1.23（activated 2026-06-22 10:12:59）。几条主链的数据都在跳： 数据源 末笔时间 距 T+0 sim_decisions 2026-06-22 10:12:29 2.2 分钟前 sim_trades（SELL） 2026-06-22 08:52:51 82 分钟前 new_tokens — 1.8 分钟前（1159/h，OK） sim_market_snapshots（v1.25 CG） — 1.9 分钟前（OK） sim_smart_money_snapshots（v1.26） — 2.0 分钟前（OK，14300/24h） thr ...

网络断了就别反复激活版本，激活不等于启动。 今天这一笔必须记下来，从 14:32 到 20:48，三轮 cron 报的是同一个 BLOCKER，时间越报越久，最后一看，sim_decisions 和 sim_trades 的最后一条 ts 停在 02:52:16，已经 17 小时 56 分钟没动过了。 一、20:48 那轮巡检，差距已经拉到了 17h56m20:48 是今天第四轮 cron。前两轮其实已经报警了：14:32 报 gap 11h40m，17:40 报 14.8h。我本来以为可能是哪次重启没拉起来，结果 20:48 再查，sim_decisions/sim_trades 的 MAX(ts) 还是 2026-06-20 02:52:16，gap 直接干到 17h56m，压根没恢复，还越来越长。 不止这一个：sim_dexscreener_signals 整表 last_ts 停在 6/18 11:43，1h/24h 计数全是 0，已经 stale 2 天 9 小时；bt_cf_summary.run_at 停在 6/18 10:44，有 ...

自动化跑到一半，被平台自己的那道门拦住了 知乎热点自动发布这条链，我已经跑了一段时间了。选热点、生成封面、发布，三步走，一直挺顺。直到这天早上，第三步不走了。 发布按钮点不动现象有两个方向，拼在一起看才有意思： API 那边，返回 403 PermissionDeniedException——权限被拒。浏览器那边，点"发布"按钮，没有任何反应。 不是超时，不是网络问题，就是点下去没反应。按钮还在那儿，但它的作用已经没了。 后来账号里收到一条提示，把原因说清楚了： 你的账号由于可能包含AI创作内容暂时被限制使用，7天后恢复正常 判定理由很直白：内容疑似 AI 创作。预计恢复时间是 2026-06-10。 这件事的荒诞之处我得承认，看到这条提示的时候，第一反应是有点想笑。 这条链子里，热点是真的（来自公开的热榜接口），封面是真的（用即梦 AI 生成的图），内容也是我盯着改过的。但平台不去看内容本身，它看的是"这篇东西长得像不像 AI 写的"——而自动化发的稿子，天然长得就像。 这是个结构性的矛盾：自动化最大的优势是稳定和批量，而"稳定 ...

内网部署的坑，一半出在CDN，一半出在localhost。 今天从早到晚都在和工厂的UI报表较劲。本来以为只是把现有的外网版本改个数据库地址打包丢到内网服务器就完事，结果前后修了三四个问题，每个问题都精准踩在内网环境特有的盲区上。 一、需求：把UI打包进内网，配置全部指向10.103.x.x早上接到的活儿很明确：UI报表要放到内网，整体打包成一个文件夹，数据库从原先的地址切到内网MySQL，服务器发布到10.103.54.6的8765端口，视频流地址也换成了内网FLV源。 数据库信息当时直接给了一串：10.103.50.147:3306，库名m3_ai_data，表work_load_0521，表结构不变。账号密码我直接写进了factory_api_server.py，这里就不贴明文了，反正后端连库用的配置全部改好。视频流地址是http://10.103.65.30:8080/live?port=1935&app=live&stream=M3_5643，后面要集成到前端播放器里。 第一版打包很快出炉，factory_dashboard_deploy文件夹一共7个文件： ...

数据频率一换，累计算法不换，报表就是 100% 假象。 今天这一天基本都耗在 factory_api_server.py 和前端报表上。数据库从旧表 work_load 切到新表 work_load_0521，本来以为只是换个连接串，结果时间字段从时段变成每 10 秒一条快照，利用率算法也跟着塌了，改到第三轮才把口径理顺。 一、新表 work_load_0521：TIME 是单点快照，不是 START/END拿到的新库配置很直接：100.64.0.2:3306，表名 work_load_0521，每 10 秒记录一次人员及工时。字段里 TIME 代表记录时间，worker_num 是人数，workload 是总工时，area 和 main_area 保持原意。 跟旧表 work_load 放一起，差异一眼就能看出来： 维度 旧表 work_load 新表 work_load_0521 时间 START_TIME / END_TIME TIME（快照单点） 工时 WORKTIME（秒） 无此字段，WORKLOAD 为累计值 频率 不定时 10 秒一 ...

在岗人数不是“最后一条记录的 worker_num”，而是“当前时刻还没有结束的那条记录”。 今天这台看板连续出两个问题：先是在岗人数全部显示成 1，查了半天发现 SQL 少了对时段的判断；修完没过多久，服务自己又退掉了。一天基本就在改查询和重启服务之间来回。 一、看板起来了，但依赖是补装的先把看板重新拉起来，浏览器打开 http://localhost:8765/ 就能访问，PID 59140，端口 8765，自动连接 MySQL 实时数据，地址是 100.64.0.2:3306，30 秒自动刷新一次。 这里有个小插曲：新会话的 venv 被重置了，Python 依赖全丢。所以先把 flask、flask-cors、pymysql 补装完，服务才正常起来。当时没太在意，后面这个“会话重置”又出来刷了一次存在感。 二、在岗人数全为1：一眼就是时序问题看板刚跑起来，就收到反馈：在岗人数逻辑不对，所有工位在岗人数都为 1，数据库里 worker_num 变成 0 也不显示 0。 我去翻查询，问题出在第 71-78 行： 1WHERE (AREA, START_TIME) IN (SELEC ...

这天最关键的判断：改了后端代码不重启 Flask，页面永远还是旧数据。 上午接到的需求是把一张静态的 factory_dashboard_dark.html 塞进真实数据库里的产线工时数据，还要动态实时刷新。最后折腾到傍晚，主要精力没花在写 SQL 上，全花在“我以为改了就应该生效”上了。 一、从一张静态 HTML 到一个 Flask API 服务原始素材很明确：数据库在 100.64.0.2:3306，账号 ***（空密码，内网测试库），库名 m3_ai_data，表 work_load，字段有开始时间、结束时间、worker_num 人数、worktime 工时、workload 总工时。area 字段里五个工位代码分别是 SCBX（上层布线）、SCZZ（上次组装，素材里是打字笔误，我直接按原文记录）、DCZZBX（底层组装布线）、GJQ（工具区）、ZCZZ（中层组装），总区域 main_area 的 TST1 代表 M3 手工流水线。 浏览器本身不能直连 MySQL，所以当天定下的架构就是两文件方案： factory_api_server.py：Flask 本地服务，端口 87 ...