黄兵的个人博客

量化交易记录更改

现在我通过 Codex 编写 AI 加密货币量化交易，每次更改代码经过多天的测试。经过测试之后，效果不是很好，需要回滚，但是已经过去了一段时间，不知道回滚到哪里，为什么要产生这些更改。

能否通过博客的形式记录为什么更改，以及更改了什么，需要测试到什么时候。或者是有更好的方式记录代码为何更改，方便以后查证。同时更改的代码会提交到 github。

同时 codex 会记录更改说明：

Summary

在 main.py 中新增未收盘 K 线的双档扫描节奏：空仓 15 分钟一次、持仓 60 秒一次，并按仓位状态动态选择限流窗口，从而把入场扫描频率降到你要求的 15 分钟。

在 PureAIReasoningStrategy 中重构了 AI 触发前置剪枝逻辑：不再“只要有持仓就必调 AI”，改为“持仓时仅当出现反转/破位风险才唤醒 AI”；横盘无风险时直接跳过，减少 token 消耗。

新增 _has_reversal_risk 本地判定，分别对多头/空头持仓使用 MA 斜率、RSI 反转、支撑/阻力破位条件来决定是否需要唤醒 AI。

将默认 min_ai_call_interval_sec 从 600 调整为 900（15 分钟），与当前 4H + 降频方案一致。

同步更新 README FAQ，明确了“空仓 15 分钟扫描 + 持仓仅反转风险唤醒 AI”的新行为和建议区间。

在使用 Codex 检查更改了那些，查询不便。现在需要一个可以记录更改以及为什么更改，更改效果怎么样的方式。

对于这种需要长时间测试（多天）且逻辑复杂的量化交易项目，单纯靠代码注释或零散的记录确实会导致“记忆断层”。

针对你的需求，建议构建一套“实验日志 + Git 规范 + 自动化追踪”的体系。

1. 推荐方案：建立“量化实验记录本”（Research Log）

与其写随意的博客，不如在 GitHub 项目根目录下建立一个 experiments/ 文件夹或一个 CHANGELOG_RESEARCH.md 文件。

记录模板建议：

每次重大更改（如你提到的“双档扫描节奏”），在 Commit 的同时，在该文件中记录以下维度：

2. 优化 GitHub 的使用：利用 Tag 和 Release

既然你已经有详细的 Summary，不要只把它塞进 Commit Message，要善用 Git Tag。

• 标记测试起点：当你完成代码修改准备开始跑测试时，打一个 Tag： git tag -a v2.1-beta-scan-logic -m "开始测试：双档扫描与 AI 剪枝逻辑"

• 使用 Release 功能：在 GitHub 上基于这个 Tag 创建一个 Release。将 Codex 生成的那段详细 Summary 直接粘贴到 Release Description 中。

  • 好处：GitHub 的 Release 页面有非常清晰的 UI，你可以一眼看到每个版本的变更重点，而不需要在成百上千个 Commit 中翻找。

3. 在代码中实施“逻辑溯源”

为了防止你回滚后看不懂代码，建议在关键函数（如 _has_reversal_risk）顶部加入一个简短的 Issue/Ref 链接：

def _has_reversal_risk(self):
    """
    判定逻辑参考实验记录：[Exp-20260401-ScanOptimization]
    主要针对 MA 斜率和 RSI 反转做前置过滤
    """
    # ... code ...

4. 更好的自动化工具建议：Weights & Biases (W&B)

如果你想更专业地记录量化实验，可以尝试 Weights & Biases。它虽然常用于深度学习，但非常适合量化交易：

• 自动记录代码版本：它会自动关联当前的 Git Commit。

• 记录测试指标：你可以把测试期间的收益率、Token 消耗、AI 唤醒次数实时推送到 W&B 画布。

• 备注功能：你可以直接在网页端给某次运行打标签（如“失败”、“待观察”、“扫描频率优化版”）。

5. 针对当前 Summary 的填写建议

目前的 Summary 写得非常专业且详细。要解决“查找不方便”的问题，只需要在 Commit 时增加一个 标题前缀：

[Optimization] 双档扫描频率与 AI 唤醒逻辑重构

• main.py: 新增未收盘 K 线双档扫描...

• PureAIReasoningStrategy: 重构 AI 触发前置剪枝...

• _has_reversal_risk: 新增本地风险判定...

总结建议： 不要依赖博客（太零散），直接在 GitHub 项目里维护一个 EXPERIMENT_LOG.md。每一行记录一个版本、更改原因和测试结果。这样当你想要回滚时，直接看这个 Markdown 里的“测试结论”，找到效果最好的那个 Commit ID 即可。