接上个月开发出了两个基于系统信息检索与 LLM 分析判断的交易策略 s1/s2。它们主要针对市场公开信息，且有较为明确的决策主体和信息透明性。这个月花了大量的时间来检查和确保系统的执行与策略当初的设计预期保持一致。

系统成功实现了两笔无干预的自动买入，且经核对符合完整的交易条件。但也暴露出一些在执行和判断上不符合预期的问题，所以这个月主要也是围绕这些问题进行系统性的补足和优化。

这一个月做了什么

1. 系统核心设施优化

  • 系统执行流依赖的 LLM 中转服务商的稳定性优化

    • 去除了之前可用性较差的分组，保留了三个访问相对较为稳定的性价比尚可的服务商。
    • 以及也为其适配了可访问性状态的记录，用于长期监测和优化。

  • 对于 Polymarket 的价格定期刷新和交易的地区限制，准备了专门更稳定用于价格刷新和交易转发的 VPS。

  • 系统依赖服务状态异常的可观测性实现

    • 系统所依赖的各外部 API、以及带余量的部分 key 等在仪表盘进行异常监控和警告提醒。

  • 系统错估事件的溯源链路建立

    根据系统错估的事件，初步适配开发了一个方便后续通过数据表快速溯源错误事件分析链路的机制。 其中包括了事件溯源相关信息会提前保存到溯源相关数据表，这样 AI 需要的溯源分析数据就从十多处查询收集减少到了两三次查询。

    • 另外针对长期的损失事件溯源任务，撰写并优化了复用 prompt，预期可降低 40%-50% 的 Token 消耗并节省执行时间。

2. 系统能力强化

  • 为事件的预测执行流接入了官方为市场事件提供的 Context，为信息检索环节增强事件的辅助背景信息。

  • 三层信息源接入：在原有的 Tavily 检索基础之上，又增加了两个独立信息源，以及 6 个垂直权威数据源，作为补充信息检索。—— 实现稳定运行之后再来记录。

  • 增加信息完整性分数这个指标

    • 用于应对系统不知其已掌握的信息是否足够的问题。

3. 交易安全

  • 实现了买入前二次复核机制，算是一个很好的安全实践。
  • 适配开发了一键暂停交易的全局安全开关，尽量降低测试运行期的损失风险。

4. 开发协作耕耘

5 月的开发过程中（我们目前完全使用 Claude 进行系统的开发），也逐渐比之前更加明显地感受到了 Claude 的能力边界。

随着 Claude 到目前的实现能力越强，我甚至感觉它的能力边界和问题就越明显。

它默认会按照常规软件开发的标准去为你实现和执行任务。比如常规软件行业如果一个好的实现办法验证不通过，默认会回退到次好甚至稍微有些缺陷的办法。但问题是对于交易系统来说，默认的回退就意味着为系统埋下健壮性的隐患，和收益亏损风险。

这只是其中一个比较显著的例子，实际上还有很多 Claude 默认的糟糕行为。

比如其二就是为 Claude 初步适配了验证驱动开发的约束：通过 CLAUDE.md 和 memory，强制它在修复和实现功能前，验证方案无误后再进行实现。

在协作过程中，针对其出现的错误和本有能力却没有考虑到的地方，也为其适配了 CLAUDE.md 和 memory 约束。

学到的主要的东西

坦白说，这个月系统的进度是缓慢的。由于发现系统信息检索的能力需要明显提升，以及对于自身信息掌握程度的感知不够（会导致过于自信，也算是结构性设计缺陷）。

主要体现出两点问题：

1. 难以避免的必经之路：系统迭代与设计经验不足

之前的系统执行流设计的信息获取环节主要是依靠 Tavily 的两层搜索（第二层根据第一层的差距针对性补足搜索）、 以及使用 Profile 环节（提供事件主体的无歧义背景信息）、还有市场事件官方 Rules 原文本作为辅助信息。

但是运行了一小段时间，又测试了一些信息源与 Tavily 并行搜索事件相关信息，单独提供的信息增量之后， 我挺吃惊地发现，即使同样的一组问题在 Tavily 已经得到了结果之后，另外一些信息源仍然能够拿到和其几乎完全相等量的增量信息。

所以不得不花了一些时间重新设计和实现这个多层信息检索架构。以及对应的 IC（信息完整性分数，与现有的信息源置信度进行配合）。

2. 可以避免的系统设计/AI协作的掌控问题

上个月系统的开发计划和实现都较为顺利，但确实缺少对重要机制的细节协作设计，以及任务执行/实现后的验收。

所以导致这个月遗留了不少的技术债。 比如上个月我们实现了一个 Tavily 信息继承的机制（即一个事件执行了多次预测执行流之后，会复用前面轮次已掌握的信息）， 但是 AI 为了节约 LLM 的 token 输入上下文，默认设置了一个比较小的继承信息条数限制，让这个功能变得十分鸡肋、以及失去了预期效果。

–

所以总结下来，5 月最主要的两个收获是：

1. 凡是会直接或间接影响到系统最终收益表现的功能，都必须亲自参与细节参数/阈值的设计协作与审阅。

  • 这样才可能确保系统在工程方面的运行表现与实现任务的预期是一致的。工程方面的坑很多。

2. 任何会直接或间接影响到系统最终收益表现的功能，必须有确定性的生产验收。

  • 不仅是实现时的测试、验收，而是实现后的生产验收，只有这一点符合预期，这个功能才算是实现完毕。 这应该作为一个标准，不然一些功能或机制实现后（即使当时的测试、验收很仔细），也可能一段时间才在生产环境中发现其运行行为不符合设计预期。 这往往也是过程问题、或者是当时设计有地方没有考虑到。

生活方面

这个月给自己配置了一个自动升降桌、还有个空气笔记本支架。

目前用了半个月，感觉确实不错。这种其实花费不高，但是对于健康和配得感都是挺好的事情。

以及给自己买了个还不错的，Carver 的滑板（陆地冲浪板）。

玩滑板有几个月了，之前的玩具板已经问题多多。

这件事也比较让人放松，也是一个挺好的事情。

总结

这个月系统目前的成长暂时较为缓慢，不过我们也从中学到了一些东西、更加熟悉了一些自身以及系统的边界。

与系统一起成长。

–

排版和内容可能不够精细，主要还是希望记录一下踩到的坑以及足迹。谢谢理解 ~

配图：我的新桌子 /smile