轉眼間鐵人賽已來到第 15 天！在過去這半個月裡，我們從零開始建構了一套完整的「AI 智慧待辦事項自動化處理系統」。今天我們將針對前 15 天的研發成果進行階段性架構總盤點，並分享如何優化這套自動化管線的執行效能與穩定度！

前 15 天核心進程與架構總覽

我們的系統經歷了四個 key phase 的演進，成功將雜亂的自然語言轉化為結構化的資料庫看板：

[ 觸發層 (Trigger) ] ➔ [ AI 提煉層 (LLM) ] ➔ [ 邏輯解析層 (Parser) ] ➔ [ 落地與路由 (Persistence) ]
   Webhook (Day 10)     Dify API (Day 07)    n8n Code/JS (Day 08)     Notion DB (Day 09)
   Telegram (Day 11)   上下文記憶 (Day 13)    意圖判斷 (Day 14)       錯誤防禦 (Day 12)

1. Phase 1：LLM 結構化輸出 (Day 01 - Day 07)

• 運用 Dify 進行 Prompt 工程設計，將非結構化的日常話語精準收斂為標準 JSON 陣列。
• 使用 n8n 的 HTTP Request 節點打通兩端 API，實現跨系統呼叫。

2. Phase 2：資料解析與落地 (Day 08 - Day 09)

• 撰寫 JavaScript 腳本將 JSON 陣列拆解為獨立的 n8n Items。
• 串接 Notion API 建立欄位映射，利用 n8n 的自動迭代機制完成任務批次落地。

3. Phase 3：端到端觸發與通知閉環 (Day 10 - Day 11)

• 導入 Webhook 節點作為進入點，實現外部動態 POST 請求觸發。
• 串接 Telegram Bot 實現即時任務卡片推播，打造完整反饋閉環。

4. Phase 4：記憶、路由與高可用防禦 (Day 12 - Day 14)

• 透過全域 Error Trigger 打造防禦網，確保伺服器異常時能即時警報。
• 傳遞 conversation_id 賦予 AI 多輪對話記憶。
• 搭配 Switch 節點實現意圖分流，完成 Create / Update / Delete 多維度資料庫操作。

系統效能與穩定度優化策略

為了讓這套系統能真正達到 Production-Ready（生產環境可用）等級，以下是三個關鍵優化點：

1. 減少 API 呼叫延遲（Latency Tuning）

• Dify 模型選擇：對於單純的實體萃取與意圖分類，建議優先使用輕量級模型（如 GPT-4o-mini 或 Claude 3 Haiku），回應速度可提升 50% 以上，同時顯著降低 Token 成本。
• HTTP 逾時設定：在 n8n 的 HTTP Request 節點中將 Timeout 時間調至適當範圍（如 15 秒），避免極端情況下節點無限制掛起。

2. 避免重複寫入（Idempotency Check）

• 在寫入 Notion 之前，可先透過 Notion 節點查詢過去 1 小時內建立的任務名稱。若發現相同標題且時間一致的任務，則直接 Skip，防止因網路重試（Retry）導致資料庫出現重複卡片。

3. Executions 數據保存優化

• 本地部署的 n8n 在長期運行後，歷史執行紀錄（Executions Log）會占用大量 SQLite / PostgreSQL 資料庫空間。
• 建議在 n8n 的 .env 環境變數中開啟自動清理功能：

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168

下半場（Day 16 - Day 30），我們將開啟全新的篇章！我們將跨出單一待辦清單，導入「跨平台生態系整合」——包含 Google Calendar 行程自動同步、LINE 官方帳號圖像/語音多模態輸入，以及利用 Dify 工作流（Workflow）打造更複雜的智能體 Agent，敬請期待！