很多量化项目一上来就堆概念、堆框架，但真正能帮你看明白“怎么跑起来”的并不多。
okcoin-leeks-reaper 算一个：仓库不大，核心几乎都在一个 Groovy 脚本里，把 行情、仓位、下单、撤单这些关键环节老老实实写出来。作者在 README 也说得很清楚——后来平台开始收取交易费、停止配资，这套策略就不再适用。所以别把它当成“现在也能直接赚钱”的工具，更适合当成一个交易机器人样本来复盘。
这是什么项目
它是面向 OKCoin 的自动交易脚本，代码里用到 btc_cny（BTC/CNY）。
项目的思路在 README 里总结成两条：
- 趋势策略：价格走出趋势时跟进去，直白点就是追涨杀跌
- 平衡策略：仓位偏离 50% 时用小单慢慢拉回，尽量别在趋势末端反转时把回撤吃满
技术栈（讲人话版）
- Groovy 脚本：入口文件是
trading_okcoin.groovy，用 @Grab 拉依赖，偏“能跑就行”的风格
- OKCoin REST 客户端：
org.oxerr:okcoin-client-rest
- 并发：线程池
Executors.newCachedThreadPool()，多个循环并行跑
- 日志：SLF4J + Log4j
如果你平时在云栈社区也折腾过交易系统，会很熟悉这种写法：先把闭环跑通，再谈抽象和工程化。
代码里最值得看的几个细节
1）成交量不是“看一眼就算”，而是做了增量和平滑
脚本会拉取近期成交（getTrades("btc_cny", null)），用 lastTradeId 只统计这段时间新发生的成交量，然后再做一次平滑：
vol = 0.7 * vol + 0.3 * incrementalVolume
它想解决的问题很实际：成交数据抖动大，直接用容易误判，先稳一稳再用。
2）价格也不是只取最后成交价，而是看了盘口的多档中间价
脚本会更新订单簿（getOrderBook），并维护一个长度为 15 的 prices 序列。每次更新时，把前几档买卖的中间价加权合成一个“更稳一点”的短期价格。
你可以把它理解成：尽量别被某一笔成交带偏，更关心盘口的整体位置。
3）再平衡做得很“执行派”：批量小单 + 短等待 + 撤单
它用这个比例来衡量仓位偏离程度：
p = btc * price / (btc*price + cny)
当 p < 0.48 或 p > 0.52，就触发再平衡：
- 用
batchTrade 一次挂 3 笔小单（每笔 0.010 BTC），价格贴近买一/卖一略作偏置
sleep 400 ms 之后撤单（你给到的 raw 代码在撤单处截断，但行为逻辑已经很明显）
这一段其实挺“教科书式”的：策略再怎么讲得漂亮，最后都要落到成交质量、滑点、撤单时机上。
为什么作者说它现在已经失效
这点不需要猜。README 明确写了：后来平台停止配资，并开始收取交易费，该策略实际上已经失效。
对这种依赖频繁小单、频繁撤单的策略来说，成本结构一变，很多优势会直接被磨没。
延伸学习
想补一点工程与数据基础，可以顺手看下这些学习路径：
（ 🔗 https://yunpan.plus ）
结尾
这类仓库的价值，往往不在“参数是多少”，而在它把交易机器人最关键的几件事摆在台面上：数据怎么取、信号怎么粗算、订单怎么发、仓位怎么控。
如果你想继续看这种“能从代码读出交易行为”的项目复盘，可以关注《alphaFind》。云栈社区那边我也会不定期整理一些更偏工程实践的笔记，但不会刷屏。
标签：#okcoin-leeks-reaper #Github #量化交易 #高频交易 #订单簿 #策略复盘
项目地址 & 官方文档 / 网站
- 项目地址：
https://github.com/richox/okcoin-leeks-reaper
- 相关依赖（项目 README 致谢 / 代码引用）：
- okcoin-client：
https://github.com/sutra/okcoin-client
- XChange：
https://github.com/timmolter/xchange
- 编程学习：
https://yunpan.plus/f/14-1
| 
发表于 4 天前
|
查看: 14|
回复: 0
