167 套策略：数字里的版图

数字已按 2026-05-09 的语料规模更新（参照策略 167 支，其中 165 支为严格对齐）。

说「167 支里有 165 支通过严格对齐」只有在你知道 这 167 支到底是什么 时才有分量。下面这篇当作参观画廊的导览。

为什么需要固定语料

没有固定的参照集合，「对齐」只是一种感觉。跑几条策略觉得差不多就上线，用户一旦用上 OCA 出场组或在循环里调用 request.security，立刻对不上。Bug 一直都在，只是你从没专门测过。

冻结语料会改变游戏规则。每次引擎发布都用 同一套 167 支、同一份规范 OHLCV。通过数上升说明有改进；下降说明进了回归。这套语料披着回测展厅的外衣，本质是 回归安全带。

这 167 支也承担 公开背书：我们把交易笔数、总收益、Sharpe 等指标提交到画廊，任何人都能看到引擎真实产出。这和新闻稿里「宣称对齐」不是一回事。

三个文件夹

语料分成 basic、community、validation。这不是质量排名，而是说明 脚本从哪来、主要压测什么。

basic — 9 支

经典教科书型策略：均线交叉、Supertrend、Stochastic Slow、抛物线 SAR、肯特纳通道、Inside Bar、唐奇安突破、波动扩张等。任何入门量化课都会先碰到这类例子。

放进语料是因为 编译器最先在这里丢人：如果连 MACD 交叉都对不出交易列表，别的就更不可信。basic 是理智检查层。

这 9 支的交易笔数从 14（非常挑剔的动量策略 greedy）到 7,580（15 分钟 K 上频繁触发的波动扩张策略）。在所谓「简单」类别内部就有约 500 倍跨度——更多反映 选择性，而不是抽象的复杂度。

community — 11 支

来自社区的实盘 Pine 脚本。作者各异，代码风格、builtins 用法、仓位与出场接线上的边角都不一样。

11 支里包括 4-EMA+RSI 过滤、类 BOS 曲线检测、流动性扫单、MarketShift 趋势跟随、VCP、IES 等。交易笔数从 71（非常挑剔的形态扫描 VCP）到 2,541（几乎每根 K 都触发的 IES）。收益跨度也很大：MarketShift 在窗口内 +$3,231，IES **−$162,977`。进语料不代表策略赚钱，只代表能编译、能产生交易。

社区脚本是最难维持对齐的一类。作者多样性会榨出验证套件未必预料得到的 Pine 组合。我们发现新的对齐裂缝时，往往 先出现在这里。

validation — 147 支

167 支里有 147 支在这里。它们是 合成策略：目的不是赚钱，而是证明某条 Pine 语义是否正确落到 C++。

举例：

• 49-partial-exit-qty-percent — 测 strategy.exit(qty_percent=...) 分批平仓；若出场成交过度发射，会被它抓住。
• request.security 各种变体 — 多周期引用是否在正确 K 线上解析，含 lookahead=barmerge.lookahead_off 与否。
• OCA 出场组 — 一笔出场触发后，竞争出场是否被取消。
• 移动止损变体 — 跳空、限价成交之下，高点跟踪是否正确。
• UDT 方法 — Pine v6 用户自定义类型方法是否编译成预期的 struct 操作。

「这条策略过了，功能 X 就算覆盖」在我们往文件夹里加东西时是显式约定的。社区脚本暴露新角点时，通常会写一个最小合成 repro 放进 validation。

数字长什么样

当前 167 支都在同一标的、同一周期：ETHUSDT 15 分钟。这是刻意约束：单一规范 OHLCV 让跨策略比较有意义，也把资产特有因素从对齐分析里拿掉。

交易笔数分布：

语料的中位数是 757 笔交易；最少 14（greedy），最多 11,218。这种分散在对齐测试里很重要：14 笔的策略若错一笔出场，误差率约 7%；5,000 笔量级上，多数成交仍可能对，但会在汇总指标里暴露。

Sharpe 分布：

语料里的 Sharpe 普遍低于精选策略库。多数条目是为 Pine 功能覆盖面入选，而不是为风险调整后回报。167 支的中位 Sharpe 是 0.023；窗口内总收益为正的有 109 支，负的有 58 支。

我们在画廊里 诚实展示这些数字，而不是只筛选「好看」的策略。若是找灵感，看收益和 Sharpe 列就够。若是做 对齐核验，绝对数值次要——关键是 PineForge 与 TradingView 是否给出 相同 数字。

进入语料的四条要求

1. 能在 PineForge codegen 下编译。 编不过就谈不上测试；门槛比听起来高：不少社区脚本 import 了尚未纳入支持子集的库。
2. 在规范 OHLCV 上至少产生 1 笔交易。 只编译从不入场，就无法与任何交易列表做 diff。
3. 有 TradingView 参照 CSV。 每条语料策略都有来自 TV「交易列表」导出的 engine_trades.csv，并按 OHLCV 跨度裁剪。这是引擎输出要比对的地面真值。
4. 引擎输出与 Pine 源码一并提交。 画廊从这些已提交的快照提供内容，而不是即时生成——反映策略加入或最后更新那天的引擎输出。

为什么只发汇总、不发全部源码

画廊公布交易笔数、收益、Sharpe、迷你走势图等，但 不会 对所有策略公开 Pine 源码或原始 engine_trades.csv。

原因很简单：社区脚本有原作者，我们没有 blanket 再分发权限；TV 的 CSV 导出也受各自服务条款约束；内部 LEGAL.md 与之对齐。

我们能发布、也确实发布的是 汇总统计与可视化产物：sparkline、对齐 tier 徽章、画廊元数据。它们足够「是我们的衍生成果」，又足够具体可核验：只要你有 TV Premium 账户和同一份 Pine，就能复现同一交易列表，与我们提交的输出自行比对。

画廊服务谁

独自翻点子的人。 167 支覆盖进场、出场与指标类型的足够变化，浏览一圈能大致了解「今天引擎能编译跑通的世界长什么样」。按收益排序、按类别筛选、看 sparkline。

要核对对齐主张的工程师。 想知道 PineForge「165 / 167 严格对齐」是否站得住，从这里入门：每张卡片有 tier 与已提交的交易笔数。tier 如何评定见 PyneCore 交叉验证。

引擎发布的 CI 基线。 每次发布前跑完整 167 支扫掠；画廊快照是最近一次提交的基线。若某条语料策略输出变了，会在出货前被 diff 抓住。

接下来

• 浏览完整画廊 — 全部 167 支，可按类别、交易笔数、收益排序与筛选。
• 试用 codegen API — 在 Claude 或 Cursor 里一次工具调用即可转译 Pine 并在自有 OHLCV 上运行。
• 申请 early access — 免费档每月 100 次转译，足够搭自己的本地语料。