我们为何打造 PineForge.

为何执着离线可复现

绝大多数 Pine 策略活在 TradingView —— 图表迭代快、社区厚，这没错。缺的是离线运行时：锁不住引擎版本，CI 里跑不了同一批成交，换机器无法做到比特级一致的复盘。

刷灵感无所谓；要上真金白银，就得要审计链路。我们要弥合「浏览器里看到一个数」与「手里有一条版本化的成交记录」之间的鸿沟 —— 而且不抛弃 Pine 语法。

为什么不全力投入 PyneCore

PyneCore 是最大胆的开源 Pine 引擎；我们也拿它当第二意见。曾认真考虑过 upstream，两条硬理由让我们转向：

• 运行时模型 PyneCore 解释 Python；PineForge 提前编译为 `.so`。性能、对齐语义下的取舍、分发形态都不同 —— 没法简单缝合，只能重写两边之一。
• 分发命题 `.so` 才能「卖逻辑不卖源码」—— 2027 年集市路线图的核心假设；不该强加在 PyneCore 的路线图上。

我们把 PyneCore 当交叉校验：每次发布同时对 TV 与它做差异比对；只要出现分歧，大概率是我们还需要修。

为何不扩展 Backtrader

Backtrader 是 Python 世界的工作马；形状不对。它是通用回测框架，而 Pine 自带 `request.security()` 前瞻、`oca_name`、子 bar 撮合 —— 写再多 Python 也模拟不像。

再者 BT 策略本体仍是 .py 明文；要做二进制集市必须多一层可信转译 —— 这层不在其模型里。

245/246 的长征

起点是 9 套策略、76% 严格对齐；两年后 246 套里 245 套严格对齐。从 76% 到 99.6% 靠的不是堆 codegen 行数，而是对着小数点后四位逐一消除偏差——一个坑能啃好几周。

大量时间耗在 TV 对「exit / fill / trail」的自然语言定义；文档给 API，语义藏在成交列表 diff 里 —— 我们就一条条对齐。

剩下 1 套是已归档的 TV 侧异常——深度复盘、追溯到 TradingView、可从 TV 自身状态复现。最初三个异常中的两个（券商保证金边界 overshoot；session 边界 <code>time()</code> 返回 na）在净室重写中已修复。留存的那个是特定 Apr 5–14 窗口内的图表状态非确定性（Supertrend <code>var direction</code>）。零真实引擎 bug。

接下来

2026 Q3： Optuna 一键接入；Sharpe / 回撤 / 盈利因子 / 自定义 lambda；滚动前向分析默认样本外（OOS）。

2026 Q4： 托管 Studio：项目 · 回测 · 优化 · 对比 · 模拟盘；底层仍是今天 CLI 同款 `.so`。候补用户先行。

2027： 集市：卖家自定义许可证维度；买家只见二进制；运行时仍可审计 —— MQL5 跑通的路径，用 Pine 再走一遍。

最后 1% 没法靠热血手写

看过太多 parity 项目在 90% 熄火；尾巴工作枯燥高薪低 —— 只有真心痴迷「为何这两笔成交差 0.0001」的人才能啃完。

这是我们的团队审美，也是敢让你把钱交给这套运行时的原因。