TSP（tick-stock-panel）：把 A 股選股、監控與回測裝進一台自架主機

它要解決的是工具鏈割裂，不是選股準確率

做 A 股量化研究的常見狀態是：資料抓取寫一套腳本，指標計算寫另一套，回測再寫第三套，盤中想看訊號又得開一個終端。每一段都能跑，但中間的欄位對不上、時間戳對不上、除權處理對不上。TSP 的定位就是把這幾段收進同一個自架服務，README 把它描述為「自託管、零運維的 A 股『選股 + 監控 + 回測』量化工作台」。注意「零運維」指的是部署形態，不是說你不需要維護資料。專案自己也把邊界畫得很清楚：README 寫「小白請繞路」，並聲明「不對標同花順 / 通達信，不內建 AI 薦股 / 漲停預測」。這句話決定了它的適用人群。它服務的是願意自己讀 docs/strategy.md、自己接資料源、自己解讀因子檢驗結果的人。如果你要的是一個打開就能看的行情軟體，這個專案從第一段就勸退了。

能力路由：資料源不是一個，而是一組可替換的能力

這個專案在資料層的設計比多數同類專案細。README 把「能力路由」列為第一個核心模組，說明是「多數據集（日K/除權/實時/分鐘/盤口/財務，持續擴展）按源能力獨立路由，任選組合」。也就是說，系統不假設某一個資料源什麼都有，而是先偵測每個來源具備哪些能力，再讓不同資料集各自路由到能提供它的來源。設定頁裡有「數據源與能力檢測（能力路由矩陣、檔位徽章）」，對應的是同一套邏輯。資料源本身是插件化的，README 列出 TickFlow、fuyao、stock-sdk 三個既有接入，並支援以 YAML 撰寫自訂源，細節指向 docs/custom-data-source.md。這裡有一個容易被忽略的推論：能力路由把「資料完整性」的責任交回使用者。如果某個來源沒有分鐘資料，系統不會幫你補，你只會在某個策略需要分鐘週期時發現它跑不動。README 也提到時序表（例如人氣排行）「支持按日歷史回補，接口配日期參數即可逐日補齊」，但這同樣取決於你的來源支不支援日期參數。

從日 K 到 enriched Parquet：指標流水線與策略掃描

README 描述的策略模組是「25 個內置策略 + 分鐘策略 + 自定義信號 + AI 生成，Polars 毫秒級掃全 A 股」。毫秒級這個說法來自專案自述，我沒有實測，但它背後的機制是合理的：指標不是每次查詢現算，而是走一條「指標流水線」，README 寫「MA/EMA/MACD/RSI/KDJ/布林/量比等 68 列指標與信號，一次掃表落盤 enriched Parquet」。先把指標算完落成 Parquet，之後的策略掃描就只是在寬表上做條件過濾，Polars 在這種列式過濾上確實有優勢。日線策略與分鐘策略在介面上是「統一單池」，由「按策略聲明週期自動路由執行」，也就是策略自己宣告要哪個週期，系統決定用哪份資料。這個設計的副作用是：enriched Parquet 的更新時機決定了你能看到什麼。盤後管道跑完之前，當天的指標不會出現在掃描結果裡。README 在資料頁列出「維表/日K/除權/Enriched/指數/ETF/分鐘K/財務」與「盤後管道與歷史擴展」，暗示這是一條批次管線而非即時計算。

因子平台與挖掘：DSL、樣本外與永不自動上線

因子部分是這個專案投入最多的區塊。README 說因子頁有「檢驗/因子庫/編輯器/組合四 tab」，包含「IC·分層·Newey-West 檢驗」，自訂因子用 DSL 撰寫，編輯器提供「25 算子點選、雙語欄位、我的因子模板」，並有版本與生命週期管理。因子庫可以「一鍵生成排名策略」，策略的觸發器也能直接引用因子條件，回測報告對評分型策略附帶「因子歸因」，做法是比較勝單與敗單在入場信號日的因子值。挖掘模組的措辭值得注意：README 寫「嵌套樣本外因子與策略挖掘：訓練區間因子方向重估 + 相關性去重 + 多因子排名組合搜索」，並且「候選入庫，顯式確認後才發布，永不自動上線」。把「永不自動上線」寫進文件，是一個明確的產品立場：它假設使用者會自己看過樣本外結果再決定，而不是讓搜尋出來的組合直接進實盤。回測端另有「驗證」視圖做「參數敏感性與滾動樣本外」，以及「蒙卡回撤」。這些名詞在文件裡都有對應頁面，但文件沒有交代各項檢驗的具體參數與預設值，這是我在閱讀時無法確認的部分。

部署：Docker 映像、CI 與設定入口

倉庫根目錄有 Dockerfile，並有 .github/workflows/docker.yml 這條 Docker CI，README 的徽章也把部署標為 Docker。這意味著最直接的路徑是建置這個映像，而不是在宿主機上直接跑 Python 依賴。專案同時提供 React 前端（topics 裡有 react）與 FastAPI 後端（topics 裡有 fastapi），資料層用 DuckDB 與 Polars，所以映像裡會包含前端建置產物與 Python 執行環境。設定集中在「設置」頁，README 列出四類：數據源與能力檢測、AI 接口、實時監控、擴展頁面與菜單與系統設置。需要留意的是 AI 相關功能（個股四維分析、盤後復盤、AI 生成信號）都依賴你在設定裡填的 AI 接口，README 沒有指定任何預設供應商，也沒有給出可複製的環境變數範例，這部分只能照設置頁的欄位填。我沒有實際建置過這個映像，所以無法給出資源佔用的數字；README 也沒有提供最低硬體需求。如果你要評估，第一步應該是先把 Dockerfile 讀完，確認它拉取的基礎映像與建置步驟在你的環境可行。

監控與異動：規則引擎、偏離值口徑與推送通道

監控中心支援四類規則：策略、個股信號、價格、異動，條件可以用 AND/OR 組合，並可限定自選分組作用域，觸發時有彈窗、語音播報（播報個股名稱與信號）與飛書推送，觸發記錄會持久化。異動監控按交易時間線分成三個 tab。競價異動用的是同花順盤前風向標，附當日與次日真實收益對照與追高風險標記，全市場競價掃描則標為「待採集任務」，這是一個尚未完成的功能。盤中異動是把漲停、炸板、翹板、跌停、新高、新低、放量這些當日信號聚合起來，README 特別註明「零新增採集」，意思是它複用既有資料，不額外抓取。偏離異動採用交易所的異動偏離值口徑，README 列出主板 3 日 ±20%、創業板與科創板 ±30%、北交所 ±40%，以及 10 日 +100%/−50%、30 日 +200%/−70%，並顯示實時接近度。把交易所口徑直接寫進規則，好處是預警與監管定義一致，壞處是這些閾值屬於交易所規則，會隨規則修訂而變，而專案是個人維護，更新是否即時無法從文件判斷。

什麼情況下不該用它

最明顯的限制是資料。README 通篇把資料源當成可替換的外部元件，沒有內建任何行情訂閱或授權資料。這代表兩件事：第一，你的研究品質上限取決於你接的來源；第二，來源一旦斷線或改介面，你得自己修 YAML 或插件。第二個限制是專案形態。README 開頭自行標註「本項目為個人開源，非隸屬任何官方項目」，並在頂部聲明「僅供學習研究使用，嚴禁商業用途」，同時倉庫檢索不到任何 release。沒有 release 表示沒有版本化的升級路徑，你只能跟 main 分支。第三，功能成熟度不均。README 自己把個股分析與復盤標為 Beta，把全市場競價掃描標為待採集任務，這說明部分頁面仍在施工。如果你的需求是穩定的生產級訊號服務，這些標記就是風險。最後是操作門檻：README 明說「小白請繞路」，這不是姿態，而是事實陳述，因為從資料源設定到因子 DSL 都需要你理解自己在做什麼。

替代方案：Backtrader 與 QuantConnect LEAN 的取捨

如果你的核心需求是回測本身，Backtrader 是常見的對照點。差異在架構重心：Backtrader 是一個回測框架，資料由你自己餵進去，它不管資料源、不管指標落盤、也不管盤中監控。TSP 把資料源插件化、能力路由、指標落盤成 enriched Parquet、再把監控與推送接在同一套規則上，換來的是更完整的鏈路，代價是更多需要自己維護的元件與更強的 A 股假設（T+1、漲跌停、連板梯隊、同花順概念維度）。另一個方向是 QuantConnect LEAN，它走的是託管平台加本地引擎的雙軌路線，語言支援更廣、社群與資料整合更完整，但它的資料模型與交易規則以美股為起點，A 股細節要靠社群或自建。TSP 的取捨剛好相反：它把 A 股的口徑（交易所偏離值、連板梯隊、同花順概念）寫進產品，但把資料與維運責任留給使用者。選擇的關鍵不是哪個功能多，而是你願意承擔哪一段。

編輯結論

TSP 適合已經有 Python 與 Docker 基礎、手上握有（或願意自行接上）A 股行情資料源、想把選股、因子研究與盤中監控收斂到單一自架服務的個人研究者或小型團隊。它不適合想要開箱即用看盤工具的人，也不適合期待內建 AI 薦股或漲停預測的人，README 在開頭就寫明「明確不做」這兩件事。採用前請先確認三件事：你的資料源能否對上 docs/custom-data-source.md 描述的能力矩陣，Dockerfile 與 .github/workflows/docker.yml 的映像建置流程在你的環境能否跑通，以及回測的 T+1、手續費與滑點參數預設值是否符合你要驗證的口徑。

官方來源

1. Issues
2. License: MIT
3. README
4. shy3130/tick-stock-panel on GitHub