Feature 建議與修正建議¶

這一頁不是描述「目前系統已經有什麼」，而是整理：

如果要把這個專案繼續做下去，最值得新增哪些 feature
如果要把這個專案做得更穩，最值得先修哪些問題

你可以把這頁當成：

roadmap 草稿
技術債清單
產品化前的整改方向

先講結論¶

如果只能先做少數幾件事，我建議優先順序是：

把全域狀態改成 request / session scoped
把 multi_params 與主流程統一成真正 strategy-aware
把 quote adapter 正式介面化
把最佳化任務改成真正 background worker 模型
補正式 schema / migration / versioning

Feature 建議¶

1. 使用者 / 工作區隔離¶

目前系統比較像單人操作工具。

若未來要變成多人可用，最值得補的是：

使用者帳號
workspace / project 概念
每個使用者自己的 ticker / timeframe / strategy / params 狀態
各自獨立的回測歷史與備註

價值：

避免全域狀態互相污染
前端可以保存個人工作情境
系統更接近正式產品

2. 最佳化任務佇列化¶

目前最佳化雖然已經有 task API，但本質上仍然偏 API 內直接執行。

建議升級成：

POST /optimization/tasks 只負責建立任務
worker 背景處理真正計算
API 只負責查詢進度與結果

可延伸 feature：

任務取消
任務重試
任務優先序
併發數限制
執行節點分散化

3. 正式的策略 schema 系統¶

目前策略參數雖然已經可分 strategy 儲存，但 schema 還不夠正式。

建議補上：

每個策略的參數 schema
欄位型別
預設值
最小 / 最大值
UI 顯示名稱與說明
是否可最佳化

這樣前端可以自動產生表單，而不是手寫欄位。

4. 回測報表與比較頁¶

現在已經有回測分析與最佳化結果，但如果要更產品化，可以新增：

回測結果比較
多組參數績效比較
equity curve
drawdown curve
monthly pnl breakdown
trade distribution

價值：

使用者不用再自己導出資料分析
也更容易判斷策略是否穩定

5. 資料來源抽換中心¶

你前面其實已經很在意這件事，所以這個 feature 很值得正式做。

建議新增：

統一 QuoteProvider 介面
provider registry
provider health check
provider fallback
provider metadata API

例如：

當 shioaji 不可用時，自動 fallback 到自家 provider
前端可查目前是哪個資料源提供資料

6. 版本化 state / backtest artifact¶

目前 state 與 backtest_state_*.json 可用，但還沒有正式版本資訊。

建議補：

schema_version
strategy_version
generated_at
source_provider
app_version

這會讓之後：

回放
除錯
歷史相容
跨版本升級

更容易維護。

7. 策略測試框架¶

現在策略邏輯複雜，但文件多、機器可驗證測試少。

很值得補：

strategy fixture
指定 K 棒序列回放測試
進出場快照測試
指標計算一致性測試

這能大幅降低之後你調整策略時的回歸風險。

8. 前端真正可用的 metadata API¶

如果前端要做完整 UI，建議後端補幾個 metadata API：

可見策略列表
各策略參數 schema
支援的資料源
支援的 timeframe 範圍
分析欄位定義

這樣前端就不用把規則硬編碼在 UI。

修正建議¶

1. `app.py` 過胖¶

這是目前最大的可維護性問題。

它同時負責：

API route
全域狀態
回測 orchestration
最佳化流程
訓練功能
備註管理

建議：

拆成 service layer
route 只處理 request / response
業務邏輯集中到 service

2. 全域狀態風險高¶

目前系統有很多像這樣的全域狀態：

ticker
current_strategy_name
current_timeframe_minutes
current_start_time
current_end_time

問題：

多人使用會互相覆蓋
測試不穩定
API 行為依賴呼叫順序
很難水平擴展

建議：

優先改成 request-scoped
或至少做 session / workspace state

3. `multi_params` 與主流程規格不一致¶

這是目前很重要的一個結構性問題。

主流程現在已經逐步變成：

strategy-aware
timeframe 可自訂
parameter isolation by strategy

但 multi_params 還保留較舊設計。

建議：

統一使用 strategy registry
統一 strategy_name 維度
統一參數 schema
統一分析輸出格式

4. Quote adapter 規格仍偏隱性¶

你已經意識到這點了，這也是重做時最容易出問題的地方。

目前問題是：

adapter 介面靠慣例存在
DataFrame 欄位要求分散在程式中
替換 provider 時容易漏掉細節

建議：

明確定義 QuoteProvider protocol / abstract base class
寫成文件與測試雙重規格
對輸出 DataFrame 做 validation

5. Migration 機制不正式¶

目前 migration 已經有做一些保護，但整體仍是手工式。

風險：

多環境 schema 演進不一致
後續欄位再增加時更難維護

建議：

導入 Alembic
schema 版本化
每次變更都留 migration history

6. 啟動副作用應減少¶

目前啟動流程混合了：

載入資料
初始化全域狀態
可能接觸外部 provider
初始化 DB 與 cache

風險：

不容易測試
部署啟動時間不穩
某些外部依賴失敗時會影響整體服務

建議：

啟動只做必要初始化
把資料抓取改成 lazy / on-demand
將健康檢查與真正資料抓取分開

7. State schema 尚未正式固定¶

目前文件雖然已補出 state / broker / order_history 的實際形狀，但系統內還沒有真正固定 schema。

風險：

前端整合容易踩到欄位變動
不同策略的 strategy.to_json() 結構可能不一致

建議：

定義正式 StateSchema
定義正式 BrokerStateSchema
定義正式 StrategyStateSchema

8. 測試覆蓋仍不足¶

這個專案的風險不是「功能太少」，而是：

狀態轉移多
策略分支多
API 回傳物件大

建議至少補：

repository 測試
backtest service 測試
optimization task 測試
strategy regression 測試

9. CORS / 金鑰 / 營運設定應再正式化¶

如果目標是正式部署，還有幾塊值得先修：

CORS 不要長期維持過度寬鬆
外部 API key 不要散落或硬編碼
不同環境的設定分層化

建議實作順序¶

如果你要分階段做，我建議：

第一階段：先修穩定性¶

app.py service 化
移除核心全域狀態依賴
統一 multi_params
quote adapter 正式介面化

第二階段：補產品能力¶

任務佇列化
metadata API
報表比較頁
state schema 正式化

第三階段：補平台能力¶

使用者 / workspace
migration 正式化
版本化 artifact
更完整測試體系

最後建議¶

如果你的目標是把這份專案往「可以長期維護的正式系統」推進，那最重要的不是先加最多功能，而是先讓：

狀態有邊界
schema 有版本
adapter 有介面
任務有生命週期

這四件事先穩下來。