167 套策略：数字里的版图

本文中的数据测于 2026年5月9日，现保留原样。最新结果请参阅我们如何衡量一致性。

数字已于 2026-05-09 更新，以反映新的语料库规模（167 套参照策略，其中 165 套严格一致）。

2026 年 5 月，我们说过「167 套策略中有 165 套通过严格一致性检查」。只有知道这 167 套策略当时具体是什么，这句话才有分量。下面就按语料库当时的样子，带你导览一遍。

为什么需要语料库

没有固定的参照集合，「一致」只是一种感觉：跑几套策略，看着差不多，就发布了。然后某个用户用上 OCA 出场组，或者在循环里调用 request.security，结果什么都对不上。这些 bug 一直都在，只是你从没专门测过。

独立留存的语料库改变了这一点。当时，只要某项改动可能影响一致性，维护者就会在自己的机器上，用同一份标准 OHLCV 把同样的 167 套策略重跑一遍。通过的策略数上升，说明有所改进；下降，说明引入了回归。这个语料库本质上是一套回归测试工具，只是披着回测画廊的外衣。

这 167 套策略当时也起到了公开证明的作用。我们把引擎输出（交易笔数、总收益、夏普比率）提交到了画廊，让任何人都能看到引擎实际产出了什么。这和一份宣称「已实现一致」的新闻稿是两回事。

三个类别

2026-05-09 时，这 167 套策略分布在三个文件夹中：basic、community 和 validation（另有第四个文件夹 parity-anomalies，放着一个不计入总数的探针）。它们并不按质量排名，而是说明策略从哪里来、测的是什么。（如今的公开语料库把参与评级的 312 套策略都放在 validation/ 下。）

basic——9 套策略

basic 类收录经典、知名的策略类型：均线交叉、Supertrend、慢速随机指标（Stochastic Slow）、抛物线 SAR、肯特纳通道、Inside Bar、枢轴点延伸（Pivot Extension），以及一种波动率扩张方法。这些都是任何一门算法交易入门课里都能找到的教科书式例子。

把它们放进语料库，是因为编译器恰恰最容易在教科书式例子上出丑。如果连均线交叉都产出不了正确的交易列表，其他一切都值得怀疑。basic 是健全性检查层。

语料库里这 9 套 basic 策略，当时的交易笔数从 13 笔（greedy 策略，出手非常挑剔）到 7,299 笔（波动率扩张策略，在 15 分钟 K 线上频繁触发）不等。仅在「简单」这一类里，跨度就超过 500 倍——这更多反映的是策略的选择性，而不是策略的复杂度。

community——11 套策略

community 类收录算法交易社区贡献的 Pine 脚本。真实作者写出的脚本，自然带着真实世界的差异：编码风格不同，内置函数的用法不同，仓位计算和出场逻辑的接法也各有各的边界情况。

这 11 套社区策略包括一个 4-EMA RSI 过滤器、一个 Break-of-Structure（结构突破）曲线检测器、一个流动性扫单策略、一个名为 MarketShift 的趋势跟踪系统，等等。当时的交易笔数从 72 笔（VCP，一个出手非常挑剔的多信号策略）到 2,643 笔（IES，交易最活跃的一套）不等。收益差距也很大：在回测窗口内，IES 收益 +$58,430，MarketShift 收益 +$3,388，而表现最差的社区策略亏损 $678。被纳入语料库并不代表策略能赚钱，只代表它能编译、能产生交易。

社区脚本是最难保持一致性的一类。作者五花八门，脚本就会用到验证套件未必预料得到的 Pine 特性组合。我们每发现一个新的一致性缺口，它通常最先出现在这里。

validation——147 套策略

validation 是当时规模最大的类别，远超另外两类：语料库 167 个条目中占了 147 个。这些是合成策略，专门用来检验特定的 Pine 语义——目的不是盈利，而是证明某个语言特性能正确映射到 C++ 输出。

举几个例子，看看当时各套验证策略分别针对什么：

• 41-partial-exit-qty-percent——测试 strategy.exit(qty_percent=...) 的分批平仓。如果引擎多发了出场成交，就靠这套策略抓出来。
• request.security 的各种变体——验证在 lookahead=barmerge.lookahead_off 下，更高周期的取值是否在正确的 K 线上解析，开启和关闭 gaps 的情况都要覆盖。
• OCA 出场组——验证 strategy.oca.reduce 组里的某个出场成交后，组内另一个出场会按已成交的数量相应减少。
• 移动止损的各种变体——测试移动止损的棘轮逻辑在跳空和限价成交时，能否正确跟踪最高水位。
• UDT 方法测试——验证 Pine v6 用户自定义类型的方法能编译成正确的 C++ struct 操作。

「这套策略通过了，功能 X 就算覆盖到了」——我们往这个文件夹里添加策略时，遵循的正是这条明确的逻辑。当某个社区脚本暴露出新的边界情况，我们通常会写一个最小的合成复现用例，加进 validation。

数字实际长什么样

当时语料库中的全部 167 套策略都跑在同一标的、同一周期上：ETHUSDT，15 分钟 K 线。这是有意为之的约束——只用一份标准 OHLCV，跨策略比较才有意义，也能把标的特有的因素排除在一致性分析之外。

交易笔数分布：

当时语料库中的策略在回测窗口内产生的交易笔数，中位数为 732 笔。最少的是 13 笔（greedy 策略，出手极为挑剔），最多的是 11,851 笔。这种跨度对一致性测试很重要：一套只有 13 笔交易的策略，错放一次出场，误差率就是 8%；同样的 bug 放在一套 5,000 笔交易的策略上，即便大部分交易都对得上，也会在汇总指标里显露出来。

夏普比率分布：

当时画廊里的夏普比率是按单笔交易计算的（各笔交易百分比收益的均值除以其标准差，未做年化），所以数值都很小。大多数语料库策略是因为能覆盖 Pine 特性才入选的，而不是因为风险调整后收益好。167 套策略的夏普比率中位数为 0.021。在回测窗口内，167 套中有 106 套总收益为正，61 套为负。

当时我们直接在画廊里展示这些数字，而没有只筛出「好看」的策略。如果你是来找灵感的，那时画廊里的收益和夏普比率两列会告诉你该看哪些。如果你是来核验一致性的，数字本身并不重要——重要的是 PineForge 和 TradingView 给出的数字是否相同。

每套语料库策略必须满足的条件

进入语料库需要满足四个条件：

1. 能在 PineForge codegen 中编译。 编译不过，就无从测试。这个门槛比听起来要高——有些社区 Pine 脚本会 import 外部库，而只有把每个库的源码都提供给 codegen，它才能编译这些脚本。

2. 在标准 OHLCV 上至少产生一笔交易。 能编译却从不入场的策略，它的交易列表没法跟任何东西比对。

3. 有 TradingView 参照 CSV。 每套语料库策略都有一份已提交的 TradingView「交易列表」导出文件，即 tv_trades.csv（有一个自测策略例外，它为每种模式各提交一份 trades-<mode>.csv）。这就是引擎输出比对差异时所依据的基准真值。

4. 引擎输出与 Pine 源码一并提交。 画廊展示的就是这些已提交的输出。画廊里没有任何内容是即时生成的——展示的是策略加入或最后一次更新当天，引擎产出结果的快照。

当时为什么只发布汇总数据，不发布源码

直到 2026 年 5 月中旬，画廊公布的都是交易笔数、收益、夏普比率和迷你走势图（sparkline），并没有公布 Pine 源码或原始交易列表。

对社区脚本来说，原因至今不变：它们出自原作者之手，我们没有再分发其源码的许可。而我们自己编写的策略，此后已作为公开的 pineforge-corpus 完整发布：每套策略都附有 Pine 源码、生成的 C++、TradingView 的导出文件和引擎的交易列表。画廊为所有这些文件都提供了链接。

画廊能帮你做什么

画廊面向三类读者：

寻找灵感的独立量化交易者。 这些策略在入场逻辑、出场逻辑和指标类型上有足够多的变化，浏览一遍画廊，就能大致了解哪些东西能在引擎上编译并跑通。按类别筛选，再看看迷你走势图即可。

核验一致性声明的工程师。 想核实一条一致性声明，就从画廊入手：每张卡片都会标出该策略有多少笔交易在 TradingView 和 PineForge 的两份交易记录中完全一致，策略页面则同时展示两份交易列表。评定等级的标准见评测方法页面。

引擎发布的 CI 基线。 当时，完整的 167 套策略扫描是在维护者自己的机器上运行的，引擎的 CI 并不执行它。如今，语料库一致性工作流每晚都会在 main 分支上把公开语料库的全部 312 套策略重跑一遍；PR 也必须等维护者完整跑完一遍、一致性判定通过后才能合并。因此，任何策略的输出一旦发生变化，都会在发布前被发现。

接下来

• 浏览策略画廊：公开语料库目前的 312 套策略，可按类别筛选。
• 在 Claude 或 Cursor 中回测：使用免费的托管 MCP 服务器，或用本地 Docker 服务器在你自己的 OHLCV 上回测。
• 我们如何衡量一致性：最新结果及其数据来源。