交易系统

记录一次优化清单（2026-09-04）系统跑得动，不代表它没有一堆欠账 那天没有急着写新功能，而是做了一次系统深潜——把交易系统从上到下过了一遍，把"该修、但一直没修"的事一条条捞出来，收成一份优化队列。深潜的副产品，是几个早就该做的接通和改造。 一、先把清单本身立起来清单不是随手记的备忘，它得能当队列用。所以它的形态是一个结构化目录：optimization_todos，落在 1viking://resources/craw_app1_wz/queue/optimization_todos_1 它来自 2026-09-04 的一次系统深潜，用途写得很明确——作为交易系统改进任务的有序队列，按优先级排。 先有清单，再谈排期。 没有清单的时候，优化永远是"想起来才做"，而想起来的，往往是最不痛的那一条。 这件事看着像在整理文档，其实是先给自己立一个"可执行的容器"。一套系统跑久了，欠账是散着的：有的藏在某个脚本的注释里，有的只在某次事故的复盘里被提过一句，有的就是"知道有问题但没空管"。深潜的作用，就是 ...

记录一次夜里的异常（2026-08-23）一晚上三条"死因"，长得像同一个症状 有些夜里，你会以为在处理一个 bug，其实是四个。那天从 OOS 停写查起，查到最后发现：一条 3 天的数据空洞、一个设错位置的超时、一笔拖了 4.6 天才被硬止损的仓，还有一行缺了 global 的赋值。它们互不相干，却在同一晚一起发作。 一、停写三天的 OOS先看最表面的：factor_ic_oos.db.oos_ticks 从 08-20 18:08 之后就再没写入了，空了 3 天。 runtime_state 给出了另一半答案：next_run_at=None，last_run_at=1787220565（≈08-20 18:08）——调度器在那之后就没再排下一次运行。automation 配置本身还是 ACTIVE，状态显示正常，那只是假象。 代码侧的根因，是 compute_regime()（L177）里的 fetch_candles 没有任何 try/except： 沙箱/网络异常 → fetch_candles 抛异常 → 冒泡到 main()（无 ...

记录一次毕业门槛的落地（2026-08-17）一个策略能不能"毕业"，不该由它自己说了算 前几周 factor_ic 一直在攒样本，但"攒到什么时候算成、什么时候算废"，始终没被写成硬规则——靠人看、靠感觉判。这天我把这件事做完了：把门槛冻进 PREREG，再落一个每小时跑一次的跟踪器，让它替人盯着。 一、先把门槛冻死动手写码之前，第一件事是冻结。 PREREG 的三处关键约定——L73 / L75 / L104——逐条核验通过，完全冻结生效。§10 里原本还留着两处"未冻结项：7 天阈值、3 次 tick 阈值——实施阶段按实际数据决定"，这次一并回填成硬值： KILL 触发 = 7 天（一周复盘周期，够短能响应、够长不误杀） regime halt 升级 = 连续 ≥3 tick tracker tick = 1h（故 3 tick = 3h） tick 为什么定 1h，也写明了理由：5min 太密、OOS 没意义；6h 太慢、KILL 响应要等 18h。1 ...