我們為何打造 PineForge.

為什麼要離線可重現

多數 Pine 策略住在 TradingView，有理 — 圖表旁即時迭代、龐大社群、社交分享。缺的是離線 runtime：你無法釘死引擎版本、無法在 CI 跑回測、無法在另一台機器逐位元重現成交列表。

瀏覽圖表點子時這些都不重要；若要押真金打造策略，全都重要。「瀏覽器看到一個數字」與「拿得出稽核軌跡」之間的落差，就是我們要補上的 — 而且不離開 Pine 這門語言。

為何不把東西上游給 PyneCore

PyneCore 是最有野心的開源 PineScript 引擎。我們自己也拿它當第二意見神諭。曾考慮把成果全部 upstream。最後沒做的兩個理由：

• Runtime 模型。 PyneCore 用 Python 直譯 Pine。PineForge 轉 C++ 並編成 `.so`。速度不同、對齊取捨不同、分發故事不同。沒有誰錯 — 但不可能不重寫雙方就硬接在一起。
• 分發。 編譯 `.so` 讓賣家能不曝光原始碼就把策略交給買家。這是 2027 市集的論述。不在 PyneCore roadmap，也不該在 — 不同產品。

我們把 PyneCore 當第二來源。每次 PineForge 發版都對 PyneCore 與 TradingView 跑對齊掃描。它們極佳比例夠高，兩引擎不一致時幾乎總有一邊是 bug — 通常是我們。

為何不擴充 Backtrader

Backtrader 是 Python 量化交易的苦力馬。穩、有人愛，但形狀不對。它是 Python 原生回測框架，順便支援自訂策略類別。Pine 是另一門語言、另一套語意 — 多寫 Python 也假裝不了 `request.security()` 前瞻、棒內委託處理或 `oca_name` 出場群組。

再者：Backtrader 策略是 Python 原始碼，自然當原始碼散播。編譯二進位市集需要 transpile 步驟產出可部署成品。Backtrader 表面拿不出這條路。

165/167 這條長跑

我們從 9 支策略、76% 嚴格對齊起步。兩年後：167 支、165 支嚴格。從 76% 到 98.8% 不是靠多寫 codegen — 是靠一支一支追小數點後四位的漂移，每個案例拖上數週。

那些週多半花在對齊 TradingView 對「出場」「成交」「trail」等詞的具體定義 — Pine 文件描述 API；委託處理的精確語意只有把成交列表逐棒 diff 才會浮現。我們就這麼做，一路問為何與參考不一致，再一支一支抹平。

剩下兩個強對齊案例最有意思 — 犄角旮旯、挖最深，仍排在 roadmap 要收攏。我們當研究，不當難堪。

接下來

2026 Q3： Optuna 整合上線。任何策略可用一行目標函式最佳化 — Sharpe、回撤、獲利因子、你自己的 Python lambda。內建 walk-forward；樣本外是預設流程。

2026 Q4： 託管 Studio 上線。專案工作區、回測、最佳化、比較、模擬交易 — 全在瀏覽器，跑的是你今日 CLI 本機同一顆 `.so`。第一波名額先給早鳥等候名單。

2027： 市集開張。賣家發布編譯 `.so`，授權維度自訂：時間、機器、券商、商品、參數範圍。買家用自己的資料跑，看不到原始碼。交付模型與 MQL5 成功案例同源 — 只是策略用 Pine 寫、runtime 可稽核、授權可撤。

那 1% 無法手寫完

我們讀過的對齊引擎故事，常在 90% 乏了就棄坑。最後 10% 重複、費力、不性感 — 得交給真的會為「兩份成交列表差 0.0001%」興奮的人。

這就是我們這隊。這份紀律。也是讓這個 runtime 值得你押資金的理由。