事件量化交易耕耘 on aYu's 价值探索 logs

把生产验收闭环交给AI，在后朋克现场感受当下—— 周复盘 #1

Sun, 14 Jun 2026 08:00:00 +0800

继续记录我们的事件量化自动交易系统（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与工程的边界，与交易系统同成长—— 月复盘 #1

Mon, 08 Jun 2026 20:00:00 +0800

接上个月开发出了两个基于系统信息检索与 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，强制它在修复和实现功能前，验证方案无误后再进行实现。

用大模型做Polymarket事件量化交易系统五个月有感

Sun, 07 Jun 2026 12:00:00 +0800

简单的开始

我从2025年12月底开始探索使用系统的方式来代替手动进行Polymarket事件交易，除了年初工作忙一点、时间不多，到现在差不多五个月了。

这件事的想法很简单。

在这之前，我曾经尝试过一段时间Polymarket事件的手动交易。

那段时间手动交易的表现虽然不算好（做了二十来个事件，最后的结果是基本持平），不过对于亏损和盈利的事件，基本上都能看到比较明确的逻辑。如果能执行得很好，其实是可优化的。

所以我就想，既然依赖自己的交易纪律性实在靠不住，用程序的方式来复刻我的交易逻辑，不就会好很多吗？

Polytrader开发过程

目前我的系统（Polytrader）的各个部分，和刚开始时几乎都不太一样。

准确地说，要比我最开始预想的复杂很多倍。这并不是我想要的复杂度，但是我发现为了达到我当初的预期，很多事情你很难不做，很多规律很难不去遵守。

我之前的手动交易方法是，把适合LLM（大语言模型）做预测分析的事件的结构性特征总结出来，然后只做这类事件。

那个时候不算很系统，不过也有一些初步的标准。

比如总结了一些维度（并根据表现去优化），根据这些维度对新事件进行评分，这是筛选逻辑。

那时使用的LLM是Google的Deep Research，配合GPT的Deep Research，一个事件会跑十次深度研究。只有在其结论和分析概率比较一致的情况下（往往是极大或极小，极小居多），才会进行交易。

然后每笔事件交易会记录到Excel中，其中包括交易的时间、建仓成本、edge，以及d_edge（衡量事件在最迟到期前的预期日均edge），还有Kelly（不过那时只算参考），以及下次重新评估的时间。

然后对于持仓的重点事件会进行重新评估，以衡量其基本面发展的变化并做对应处理。

所以系统开发的逻辑，也完全是按照如何最简单、务实地符合我的交易逻辑去做的。

目前迭代的交易执行流

Polytrader的主要交易思路是：主要交易那些具有公开信息的事件（也就是市场参与方在信息层的能力是平等的），借助LLM的客观无情绪分析能力和模拟人的交易执行流程，通过确定性的交易纪律性和避免情绪认知偏差来获得优势。

这个思路应该挺好理解，不过其中确实有很多要解决和妥善处理的问题。

所以关于系统的流程如何设计以达到比较好的效果，目前已经迭代了好几版（不是因为现在的有多好，相反，是因为最初自己的理解远达不到效果的预期）。

目前的Polytrader执行流简要来说，分为以下步骤（均由LLM和代码来自动执行）：

阶段 0. 事件入库

阶段 1. 事件侧写环节（Profile） 明确事件主体、解决这个事件的"what"和"why"的问题。因为同样一个主体的名称在不同的场景下可能就有歧义，如有些LLM看到Trump默认就只记住他是45任总统（即使他也是47任），这就导致了其推理的信息默认前提差距很大。这些问题都会为系统埋下不可预测的未知隐患。所以这个流程是为了解决这个问题。

阶段 2. 明确事件判定规则 把冗长的事件判定规则使用LLM做理解和清洗，明确最重要的判定规则和判定源。所以后续的实际判定概率分析的LLM就可以专注于整合各阶段既有干净的信息进行高质量分析，而不需要损耗额外的注意力来解析判定Rules。

阶段 3. 匹配UMA历史相似事件争议率 争议风险环节：为当前事件检索历史上相似的事件，判定争议率是多少？争议率高的事件就不会交易。需要提前做RAG库，以实现事件的抽象匹配（即忽略不同的主体，只专注于判定模式和判定源的相似性）。

阶段 4. 信息检索环节

4-1. 使用几个不同的检索方式/渠道去获取：为了能够准确判定，应该搜索什么信息？以及执行搜索。

4-2. 信息搜索补足环节：根据 4-1 的结果，以最新的信息证据去考虑，还差哪些信息？是否需要补足搜索什么信息？然后执行信息补足搜索。

4-3. 信息归档、源分级：按时间线、信息源的可信度质量等级，结构化整理4-2的最终结果信息。这里有一个重点是：不同信息源的质量和可信度是不同的。比如判定官方源 > 国际主流媒体 > 区域性知名媒体 >= 地方性可信媒体 > 个人社媒。这一点非常重要，因为信息永远不缺，缺的是可信的信息。所以系统应该根据掌握信息的信息质量等级，来进行评估。

4-4. 信息完整性评估：回答"未知的未知"，而不是基于实际有缺失（但是目前十分高质量）的信息，做出自负的交易决策。即：为了准确判定这个事件，当前系统已掌握的信息的完整性分数是多少？这一点也非常重要，理论上你的系统信息检索流程设计的再好，只能接近100%的获取率，永远会存在遗漏的问题或可能，这一点则是为了这个考虑。

阶段 5. CEO评估环节 根据以上所有必要信息，去分析和输出这个事件的发生概率、概率的置信度（基于上述信息源的分级质量），以及分析结论、给出初步交易信号等。这个环节就相当于是系统的大脑，最终的分析和决策是它基于所有信息做出的。但是它的输出只为后续的交易门槛提供判断条件数据，不触发交易。

阶段 6. 交易策略分发及匹配 如果CEO评估通过了，那么系统会对当前已有交易策略的各项数据与结构性特征进行匹配，判断是否满足对应的交易策略。

阶段 6-1. edge交易门槛条件匹配 当阶段 6 的所有条件命中和满足之后，会进行edge/d_edge门槛条件匹配。若是在edge层也满足了合理的预期交易门槛，才会根据对应的策略仓位触发交易。