要求使用者在送單前確認
系統先建立可核對的訂單預覽，再由使用者明確確認。這犧牲部分速度，但將不可逆的金融操作保留在人類決策點，也讓錯誤能在送單前被發現。
交易系統與基礎設施·2026
Kaiyn Trading Bot
已部署於 Kaiyn Capital 實際營運
- 要解決的問題
- 社群交易訊號發布後，使用者仍得在時間壓力下核對標的、計算部位並下單。
- 我的角色
- Kaiyn Capital 創辦人、產品負責人與獨立開發者，完整負責產品需求、Telegram 使用流程、後端開發、部署與後續營運。
- 關鍵取捨
- 要求使用者確認訂單才送出，接受流程稍慢，讓涉及資金的操作保留在人為確認之後。
Signal Ingress
Telegram Auth
Confirm Execute
YES
NO
Audit State
StatusFilled
Latency42ms
1R Risk CheckEncrypted APIPostgreSQLDockerCI/CD
背景與實際營運問題
Kaiyn Capital 透過 Telegram 發布市場觀點與交易訊號。實際問題不只是如何解析訊息，使用者仍必須在時間壓力下核對交易標的、計算部位、確認交易所規則，並避免重複操作。
這套系統以明確的下單前確認、固定風險計算、狀態保存與稽核流程，銜接訊號發布與實際送單之間原本容易出錯的環節。
線上 Demo
關鍵決策與取捨
將工作流程狀態保存於 PostgreSQL
待處理訂單、訊號與預覽工作階段透過短 token 連回資料庫狀態。額外的資料結構與資料庫遷移成本，換來重啟後可恢復的流程、清楚的稽核紀錄，以及以資料列鎖定控制重複確認的能力。
不確定的交易所結果交由人工覆核
網路逾時或回應不明時，系統不直接視為失敗，也不自動重送。依固定規則產生的 client order ID、人工覆核狀態與後續查單能降低重複送單風險，代價是部分情況必須由管理員核對。
成果與驗證證據
系統已部署並用於 Kaiyn Capital 的實際營運，涵蓋 Telegram 訊號、訂單預覽、固定風險部位計算、交易所規則驗證、Bitget 送單、狀態保存與稽核紀錄。
Docker-first CI 會檢查資料庫遷移、型別、訂單安全規則與 PostgreSQL 整合流程；部署、健康檢查、加密異地備份與還原程序也納入正式營運設計。
目前限制
- 目前不追蹤限價單送出後的完整成交生命週期。
- 掛單取消、過期同步與自動止盈仍不在系統責任範圍內。
- 專案尚未進行大量壓測或交易量模擬，也不宣稱能完全避免重複訂單或保證交易獲利。
代表性產出
訊號解析流程
將非結構化 Telegram 訊息解析為符合明確規則並通過驗證的 JSON 資料。
Signal Webhook Payload
{
"asset": "BTC-USDT",
"action": "LONG",
"risk_level": "1R",
"timestamp": 1709283741
"action": "LONG",
"risk_level": "1R",
"timestamp": 1709283741
}
Strict JSON validation enforced
確認優先流程
透過 Telegram 互動介面，要求使用者在執行前明確確認。
Interactive Auth
Execute Trade?
BTC-USDT LONG @ 1R
後端稽核流程
以 PostgreSQL 為基礎的狀態追蹤，透過冪等性控制與明確的執行狀態降低重複送單風險。
Immutable Audit Trail
14:02:01Signal received[ok]
14:02:02Risk validated (1R)[ok]
14:02:05User confirmed[ok]
14:02:06Order executed[ok]
14:02:06State committed to DB[ok]
使用技術
PythonTelegramPostgreSQLSQLAlchemyDockerGitHub Actions
延伸閱讀
閱讀確認優先工作流程案例文章本專案僅作為工程與工作流程設計作品展示，不構成財務建議，也不宣稱具有交易獲利能力。