记录一次优化清单（2026-09-04）

系统跑得动，不代表它没有一堆欠账

那天没有急着写新功能，而是做了一次系统深潜——把交易系统从上到下过了一遍，把"该修、但一直没修"的事一条条捞出来，收成一份优化队列。深潜的副产品，是几个早就该做的接通和改造。

一、先把清单本身立起来

清单不是随手记的备忘，它得能当队列用。所以它的形态是一个结构化目录：optimization_todos，落在

1	viking://resources/craw_app1_wz/queue/optimization_todos_1

它来自 2026-09-04 的一次系统深潜，用途写得很明确——作为交易系统改进任务的有序队列，按优先级排。

先有清单，再谈排期。 没有清单的时候，优化永远是"想起来才做"，而想起来的，往往是最不痛的那一条。

这件事看着像在整理文档，其实是先给自己立一个"可执行的容器"。一套系统跑久了，欠账是散着的：有的藏在某个脚本的注释里，有的只在某次事故的复盘里被提过一句，有的就是"知道有问题但没空管"。深潜的作用，就是把这些散落的欠账从各个角落里翻出来，塞进同一个容器、排好序。 没有这个动作，再好的想法也只是想法。

二、清单上的第一件：把 OpenViking 接通

第一条大件是记忆服务的接入。bootstrap 那天跑通了，用的两个脚本职责很清楚：

codex_ov_bootstrap.py —— 一次性播种（seed）
codex_ov_session_start.py —— 每个会话开始时装载上下文

挂载点是 viking://resources/craw_app1_wz/ 下的 {CONTEXT, SESSION_LOG, queue} 三个目录；凭据放在 ~/.hermes/.env 的 OPENVIKING_API_KEY（这条随后被轮换过）。

为什么要把记忆服务接进工作流？ 因为很多坑不是难，是忘：同一个口径、同一个路径写法、同一个授权位置，隔两个月就会重新踩一次。把上下文持久化下来，等于给"记性"这件事上了个外挂。

坑也记了一条：0.4.12 版本里 /api/v1/content/write 返回 404，写内容要走 add_resource，用 k=v 标签传参。还有一个清理项——bootstrap 重跑时要 rm 掉 CONTEXT_test / CONTEXT_1，否则会留下重复目录。接通一个新服务，真正的成本往往不在主路径，而在这些边角上的"已知怪癖"。

三、验收也是一个条目

接通之后还有一步，被单独当成里程碑记下来：完成 OpenViking 技能的端到端读取验收。

"接通"和"验收"是两件事。脚本跑通了、目录挂上了，只说明链路搭起来了；端到端读一遍，确认写进去的东西能完整读出来，才算真的可用。 所以这一条在清单上不是"顺手的收尾"，而是一个独立勾选项——因为记忆服务最常见的坏法，恰恰是"看起来接通了、实际读不出来"。

验收里还留了一条尾巴：清理 OpenViking 的重复目录。它不影响功能，但会影响整洁和排查。清单的价值之一，就是这种"不急但该做"的小项不会被无限期地拖着。

四、清单上的第二件：链上原生止损单

第二条大件，是给 smart_money_trader 接 持久化的 HL 原生 reduce-only 市价止损触发单。它不是一个孤立的函数，而是一组动作：

开仓后挂单：仓位建好，立刻挂上对应的止损触发单
平仓前撤单：正常平仓时先把挂单撤掉，避免留孤儿单
旧库自动迁移：老记录迁移到新字段 hl_sl_oid
链上仓位先消失时：按当前价核销 PnL

这一步的意义，是把"止损"从策略逻辑里挪到交易所侧——止损单挂在链上，就不依赖本地进程还活着。本地进程会卡、会僵、会没，但挂在链上的挂单不会因为你的进程死了就消失。把安全边界从"我的代码"挪到"交易所"，本身就是一种冗余设计。

那个"链上仓位先消失时按当前价核销 PnL"的分支，背后是同一条原则：本地账本和现实分叉的时候，以现实为准。

那天完成了语法与数据库迁移验证，但运行态的真实回执还没验：要等重启、等一次真实新开仓，看 API 的实际应答。所以这条在清单上**只能算"开发完成"，不能算"验收通过"**。

五、清单要能滚动

清单的另一个作用，是让"下一步"可指。接通那天写下的下一条推荐就很具体：item #2 —— 把 SL 触发单接到 HL 上，正是上面那一条。

一份清单如果只是躺着，它就跟没有一样。能指向下一条，它才是活的。

而且清单是要滚动的——做完一条划掉一条，新发现的问题再补进去，优先级也跟着现实重排。一次深潜产出的清单，不该是一张一次性的表，而是一个会随系统一起长大的队列。它记的是"欠账"，但真正管的是"顺序"：先做哪条、后做哪条，这个判断本身就是价值。

清单的生命力，全在"滚动"这两个字上。 它每被取用一次、每被更新一次，就离"活文档"近一点、离"一次性产物"远一点。

最后

那次深潜本身没产出收益，但我觉得它比任何一次调参都值得。

最表面的是那份队列：optimization_todos，按优先级排好，随时可以取。

中间一层是"先立清单"这个习惯：优化这件事最大的敌人不是难，是散。把欠账从脑子里搬进一个有序队列，它才有机会被真正做掉。

最里面一层，是那份对"完成"的克制。 止损单那条，代码写完、迁移验完，很容易就报"做完了"。但真实 API 回执拿到之前，它只能躺在清单上标着"待运行态验证"。分清"写完了"和"验过了"，是这份清单最想守住的一条线。