AutoQuant 每日自动优化：健康扫描 0 问题 + 自动 devlog 推送的 PDCA 闭环

每天凌晨 01:10，AutoQuant 跑一遍健康扫描；01:30，每日优化任务接管。扫描结果 29 个端点 0 error / 0 slow，前端 30 个 JS 文件完整，持仓价格通道无断链。然后系统自己把过程写进 devlog，推送，收工。这套「健康扫描 + 自动 devlog」的 PDCA 闭环最近 12 天里有 10 天零问题，中间还顺手修掉了几个隐患。

要解决什么问题

量化系统不是写完就完事的。数据源会停更、价格通道会断链、前后端构建产物会漂移——任何一个坏掉，第二天早上你看到的持仓数据可能就是假的。

之前这套检查靠人肉：每天手动 curl 一下健康接口、看一遍持仓、翻一下 git log。忙起来就漏，漏一次就可能在假数据上做决策。

我要的是：机器每天自己检查一遍，把结果落成一份可追溯的记录，出了问题当天就知道。

系统总览：PDCA 闭环

AutoQuant 的每日优化按 PDCA 组织，跑在本机 ModelBase 上：

• Plan：每天健康扫描 + 前一天 devlog 里的待办
• Do：有 bug 派 OpenCode 改代码，没 bug 只记录
• Check：健康扫描验证改动没有引入回归
• Act：写 devlog，把结论和待办回写给明天的 Plan

调度是系统 crontab，两个任务：01:10 健康扫描，01:30 每日优化。所有 AI 推理走 llama.cpp 多模型模式，通过 new-api 代理。

健康扫描查什么

每日健康扫描 01:10 自动执行，覆盖三层：

后端

• /api/health 返回 ok
• 29 个数据端点全部可访问，0 error / 0 slow

数据中台

• ReShare（8200）scheduler 运行中
• 数据源健康：available / testing / unavailable 分类，last_success_time 有值才算可用

前端 + 框架

• 30 个 JS 文件，965KB 构建产物完整
• /api/positions 持仓可读，day_change_pct 非 0 = 价格通道未断链
• git 工作区干净，~/.autoquant/ 配置在位

扫描结果带状态码，全部通过才写「0 问题」。

自动优化怎么跑

01:30 的每日优化任务读健康扫描结果，分两种情况：

有 bug / 有优化点：派 OpenCode 改代码，跑测试，验证后再合入。比如 08-30 那次删掉了过时的 param_grid_search.py.backup，顺带补强 .gitignore 加了 *.backup 规则。

没 bug：不派工，只记录。08-31 和 09-01 连续两天健康扫描零问题，优化任务全程只做检查 + 写 devlog，没有一次多余的代码改动。

优化不是为改而改——没问题就不动，这是这套系统最克制的地方。

自动 devlog 推送

每天一份 devlog，写在 .devlog/YYYY-MM-DD.md，固定结构：

• 系统状态：后端 / 数据中台 / 前端 / 健康扫描结果
• 完成的工作：今天改了什么，为什么改
• 代码变更：git diff --stat 实际输出
• 验证结果：curl 实测、价格通道核验
• 发现的问题：按 P0/P1/P2 分级
• 下次待办：留给明天的 Plan

要点：devlog 里所有数据都是当天的实测输出，git diff --stat 是原样贴的，验证结果里有具体的 curl 命令和返回。

踩过的坑

坑 1：把「预期行为」当 bug

08-30 的一致性检查出了 3 个 warning：实盘持仓无交易记录、操作日志无对应交易、账户余额与流水不一致。看起来都是数据问题。

排查后确认：实盘持仓（161226/601318/517520）是直接登记进系统的，不走交易流水，所以没有交易记录是预期行为。真实值 vs 假数据，要先对照数据源的原始返回再下结论——09-01 那次 512000.SH 的 day_change_pct=0.0，对照 ReShare 原始返回确认是昨收=现价的真实值，不是断链。

坑 2：devlog 双轨分裂

夜间优化日志写在 .devlog/dev-logs/YYYY-MM-DD.md，每日开发日志写在 .devlog/YYYY-MM-DD.md——两套并存，08-31 的优化日志还漏提交过。

这是个 P2 问题，隐患是记录会散。修法待确认路径标准后统一，本次只补归档、不动结构——发现问题先记录，不擅自重构。

坑 3：别在假数据上做决策

健康扫描存在意义就是拦住「静默的坏」。价格通道断了不会报错，只会给你返回一个 stale 的 day_change_pct。所以扫描专门核验 day_change_pct 是否非 0、是否与 ReShare 原始返回一致——用数据源的原始响应交叉验证，而不是只看系统自己算出来的值。

验证：最近 12 个记录日 10 天 0 问题

从 08-19 到 09-01，AutoQuant 共有 12 个 devlog 记录日（08-23、08-26 无记录），其中 10 天记录「无新问题」（08-19/20/21/22/24/25/27/29/30/31）。这里的「无新问题」指当日健康扫描未发现新问题，不包含事后追溯发现的记录遗漏：

• 29 个端点 0 error / 0 slow
• /api/health 每天 ok
• 前端构建产物持续完整
• 持仓价格通道无断链

另外 2 天记录到真实隐患：08-28 ReShare 进程卡死（原因未明，疑似资源泄漏）、09-01 devlog 双轨分裂 P2（结构隐患）。也就是说：健康扫描和 devlog 把真实隐患照出来了，其余日子多数是「无代码改动」——这说明系统稳定，也说明自动化把检查从人肉负担变成了零成本例行。

核心代码

调度入口是 cron 里的两个任务：

10 1 * * * cd /home/tony/projects/autoquant && run_health_scan >> logs/health.log 2>&1
30 1 * * * cd /home/tony/projects/autoquant && run_daily_optimize >> logs/daily.log 2>&1

健康扫描的核心判据就两条：

# 后端 + 数据端点
curl -s http://localhost:8100/api/health          # {"status":"ok"}
curl -s http://localhost:8200/api/v1/data-sources/health | jq '.data.summary'

# 价格通道核验：day_change_pct 非 0，且与 ReShare 原始返回一致
curl -s "http://localhost:8100/api/positions?account_id=1"

这套逻辑的价值不在代码多复杂，而在「每天必跑、结果必留痕」。健康扫描 + 自动 devlog，把「系统还健康吗」从需要人惦记的问题，变成了每天自动回答并记录在案的问题。

参考文献

本文数据来自本地记录 ~/projects/autoquant/.devlog/（每日开发日志，未公开）。公开可访问的参考：

• Hexo 文档 — 博客发布平台
• AutoQuant 项目主页 — 系统部署与开发日志归档