继续记录我们的事件量化自动交易系统（Polytrader）的耕耘足迹
本周复盘
这周主要还是完善系统的信息检索能力，以及进行实现后的实际运行情况验收，并对系统目前的执行效率进行优化。
目前系统经过最近几个月的迭代和发现的问题的修复，算是初步具备了相对之前更健壮、更完善的信息检索架构和运行能力。
目前有了 Tavily 以及 Perplexity 作为双主要信息检索渠道，配合一些前置的基础或背景信息提供，以及后置的一些信息按需补充环节，对于公开信息的事件，已经具备了不错的信息检索、收集、整合以及分析的能力。
并且相关实现了信息置信度以及信息完整性分数这两个指标，用于作为当前阶段策略开发的一部分。
目前实盘已继续运行，进入更长期、稳定的数据和市场反馈收集阶段。
具体来看
一、系统核心功能与基建
1. 完成了多层信息检索架构的实盘运行验收（最新 Tavily + Perplexity，以及一些垂直渠道源协作的信息检索流程）
- 为信息检索架构设计并执行了 L1-L5 层的全面测试，分 4 次子阶段补跑了一批之前因为相关问题导致信息收集结果不太准确的历史事件的数据。
2. 系统执行流效率优化：
- 清除了系统执行流的一些涉及 LLM 阶段的定期大量冗余重复运行，每日减少了明显的 LLM 冗余调用浪费，适当提升了执行效率。
- 实现了交易前二次复核机制，在未通过的情况下系统会自动进行妥善的退避处理，代替之前的手动审核确认。
- 这样对于市场事件的预测和交易的执行流的状态流转更流畅、自洽。
本周最大的收获
这周最大的收获是在交易系统的工程方法上：工程方法论。
建立并应用了初步的任务验收闭环
——利用Claude CLI 窗口在任务实现后直接进行生产验收检查，较大程度上增加了 AI 代理执行任务成果的预期确定性。
经过这几个月的量化交易系统的实现，我发现在功能和任务实现后，处理不符合预期的工程 bug 问题上，占用了较多不必要的时间。
所以这段时间，我就在想如何实现一个功能、机制或任务，从和 AI 协作实现，一直到生产环境中确定性表现符合预期，形成这样一个通过的闭环。
这样才能算是真正的实现，并且可以在很大程度上避免一个功能在实现之后（即使当时做了不少测试、审计甚至是一些验收），过了一段时间才发现问题。这个时候再去调试和解决，时间以及影响成本其实都会大很多。
所以目前我想到的最好办法是：理论上，一个功能或机制的实现，及其最终在生产环境中的通过，与这个任务的实现是一个整体。
就像吃饭与刷碗是一个整体一样（虽然我吃饭后，并不常常刷碗，哈哈）。
这样肯定要比之前更好。
这周在工作的过程中发现了一个比较务实的初步闭环方式，我觉得还挺有帮助的。
首先我需要简单说一下，我是如何与 AI 协作实现功能的，这样对于理解这个办法很重要。
我的开发工具是 Claude CLI。
任务协作方式是：每次几乎任何问题或实现，我都会起一个 tasks/task{num}.md，在里面写上本次的任务（无论是功能实现、debug，还是 ask）。
任务实现进度管理方式：我一般也是多窗口使用 Claude。无论大小任务，都会记录在项目的 working_memory.txt 中。其中简要记录了对应 Claude 窗口在做什么任务、以及当前的进度状态，包括如下：
- 正在执行...
- 正在写实现文档...
- 正在按实现文档执行...
- 已实现，待确认
- ———— 生产验收通过（OK）
备注：
- 好处： 这样做的主要好处是，多窗口开发中的确定性协作，可以释放你的大脑的上下文切换。
- 关于多窗口开发： 虽然时常会多窗口 Claude 开发，但实际上我还是以理解深度和实现效果为主，不会刻意去追求更多窗口的效率。
- 注意力抽离： 另外一个可能被我们忽略的好处是，这样我们就可以从对 Claude 执行过程的关注中抽离出来，把注意力放在更有价值的思考流上面。我们可以通过其最终的反馈来进行验收，这个主要的意义是，我们是主动的，而不是它执行完了我们就要去处理它。
那么这个实现与确定性生产验收的方式其实很简单：就是在这个基础上，每次任务实现完成之后，就让 Claude 去检查生产环境中的运行是否已确定表现符合预期。
只有当这一步验收通过之后，这个任务才能够算是真正实现完成。
备注：
- 这里可能需要提前妥善制定一下对应任务的明确的验收标准，以及 Claude 需要报告给你通过的证据。不过这一点不难。
- 这个流程其实用两次之后很简单，除了最后的生产验收之外，我今年一直都是这样和 Claude 协作的（task 文件发任务、以及多窗口进度管理文件记录）。我认为这是对效率的很好投资，也解放了不必要的上下文切换带来的精力损耗。
总结
这周其实还有一些其他挺有意义的事情。
比如我认真了解和测试了 Claude Fable 5 的能力，以及用它来执行了一些任务，能力的表现确实很不错。
而且这个模型相对于 Opus 4.8 有明显的提升，不是微弱的提升。我更愿意把它看作是新一代模型，是一个里程碑。
而 Opus 4.8 的问题在于过于谨慎，以及其任务执行速度相对于前一两代降低明显。
所以对比之下，我目前仍然使用 Opus 4.7 进行开发。
不过 Claude Fable 5 在上架几天后就被官方下架了，实在是很可惜。
另外和 Fable 5 探讨之后，虽然之前担心Fable5相对于 Opus 4.7/4.8 有数十倍的成本提升，但是基于以下原因，我也改变了看法。
对于个体交易系统开发者来说，虽然成本明显高很多，但是它带来的生产力以及对系统实现迭代速度的提升，是个体开发者能获得的为数不多的优势。
另外，对于生活方面涉及决策（如健康、人际关系、工作等）的问题，使用目前这种综合能力最好的模型所带来的帮助，应该会远大于我们付出的成本（用 Fable 5 的话说就是，帮助你做出一个更好的决策，可能就是相对其成本数年的收益）。
所以还是要利用起来的，也期待它与同类能力模型尽早重新上架的一天。
系统下一步耕耘：
鉴于目前开发空窗期不是太多了，所以打算先把核心功能尽快稳固实现并稳定运行。
接下来再根据后续逐步收集到的市场反馈数据，逐步迭代和维护。
所以下一步应该是以下功能的实现：
-
持仓中事件的概率重评
- 实现系统预期与市场预期差的持续监测，持仓中的事件若是没有优势，就不应该继续持仓。
-
数据基建（预期获得长期策略开发迭代的数据基础）
- 高质量的丰富数据的积累应该是长期的主要竞争力，这一点还需要仔细考虑和探讨，如何做比较好。
- 目前我们已经实现了初步的系统基础数据的影子数据同步收集（用于策略回测和初步挖掘），但是还远远不够。
- 这其中还有不少问题要妥善解决，比如平衡成本与数据收集的颗粒度（量可能会非常大）等。
生活
这周我去听了一个后朋克（后来我才知道这个风格的名字，这是一种略带忧郁的摇滚风格）摇滚乐队的音乐会。
歌手名气不大，但我挺喜欢他们的音乐，现场的氛围也很好。
我试着不依靠思考，而是跟随音乐的节奏以及现场的氛围，去摇摆和蹦跶。
那感觉真不错。