昨天建立了成員知識庫後，我初步的修改實作了「AI 摘要與任務提取」節點，但處理結果變得不穩定、摘要品質下降、任務指派錯誤，並且無法應對多個不同的任務期限。

今天的目標是專注在透過更準確的 Prompt 設計和程式碼邏輯，來引導並輔助 AI 做出更精準的判斷。

今天的目標與挑戰

• 設計由程式碼來做輔助邏輯
• 調整 Prompt，引導 AI 針對多個任務回傳結構化的資料
• 在程式碼中加入更完善的清理、錯誤處理與重試機制

Step 1：目前的 Prompt 設計思路

我嘗試讓每個 Prompt 都像一個專注於特定任務的專家角色，我的設計思路大致如下

1. generateDynamicParticipantPrompt （參與者辨識專家）：這個 Prompt 就是專心從轉錄後的逐字稿中找出「誰在場」，透過成員清單和一些通用詞彙，像是「各位」、「大家」給它參考，幫助它聚焦在比對和辨識上。
2. generateDynamicTaskExtractionPrompt （結構化任務專家）：這是我為了解決任務混亂問題做的主要嘗試，不再讓 AI 回傳格式不定的 Markdown，而是透過這個 Prompt 引導 AI 輸出一個 JSON 陣列。
3. generateDynamicMeetingAnalysisPrompt （會議分析專家）：我設計這個 Prompt 來讓 AI 專注完成會議摘要、判斷會議類型等綜合性任務，希望能提升摘要的品質。

Step 2：建立程式碼層級的輔助機制

我發現單靠強化 Prompt 仍然不夠，AI 的判斷有時還是會出現偏差。因此，我這次花了不少心力與時間😿，在程式碼中建立了後處理的輔助機制，用來檢視、補強 AI 的輸出結果。

2-1 嘗試名稱正規化與多重映射

我為了解決人名辨識不準確的問題，因此建立了 buildAdvancedNameMappingTable 和 normalizePersonName 這兩個函式。

• 設計思路：會議對話中充滿了各種暱稱、職稱或非正式稱呼，我的想法是如果能先建立一個詳細的「名稱映射表」，將各種稱呼全都對應到一個標準的「正式姓名」，或許就能大幅降低 AI 辨識的難度。
• 實際作用：這個機制會在 AI 分析前後都進行介入。
  • 分析前，我嘗試用 smartReplaceNamesInText 將逐字稿中的暱稱事先換成全名。
  • 分析後，再用 normalizePersonName 整理一次 AI 的輸出，確保最終結果的一致性。

2-2 任務指派的輔助推論

我為了改善「張冠李戴」的問題，因此建立了 advancedTaskAssignment 函式，也是所設計的第二道防線。

• 設計思路：不完全依賴 AI 的指派結果，這個函式扮演了輔助推論的角色。
• 執行流程：

1. 尊重 AI 的明確指派：如果 AI 已經明確指派了任務，那程式碼就予以採納。
2. 觸發輔助分配：如果 AI 回傳的 assignee 是空的或無法辨識，就會觸發這個函式。
3. 基於技能的推論：它會先用 intelligentTaskCategorization 嘗試分析任務描述，給任務貼上「技術」、「設計」等標籤。
4. 尋找合適人選：接著它會去我建立的 skillDatabase（由成員職位和關鍵字推斷而來）中，從實際與會者裡，尋找具備相應技能的成員，同時它還會考慮每個人的工作量（已分配任務數），嘗試找出一個最合適的人選。
5. 提供信心度參考：最後它會給出一個「指派信心度分數」，讓我知道這次的分配結果是來自 AI 的直接指派，還是程式的輔助推論。

Step 3：執行流程的重構與容錯嘗試

為了管理這些複雜的 AI 呼叫和後處理邏輯，我對節點的執行流程也進行了調整。

• 並行與串行結合的策略：在主要的流程中，我使用 Promise.all 讓一些可以獨立運作的 AI 呼叫並行處理，希望能縮短整體的等待時間，然後在這些初步結果都回傳後，再串行執行後續需要依賴這些結果的步驟。
• 更安全的 JSON 解析：AI 回傳的 JSON 常常不標準，我有設計 safeJsonParse 函式整合了多種正規表示式和修復邏輯，嘗試從混亂的字串中出找出可用的 JSON 物件。

今天的成果與現況

✅ 初步成效

• 透過職責更單一的 Prompt 和對結構化 JSON 的要求，AI 的輸出結果比之前更加穩定
• 透過名稱正規化和對「全員」等詞彙的判斷，全員被標記為參與者的準確度有所改善
• 任務指派的準確度有所改善
• 結構化的 task_list 格式，讓每項任務都能擁有獨立的屬性

❌ 尚待改善

• 雖然功能變強，但現在節點過於臃腫，所有的邏輯都集中在「AI 摘要與任務提取」這一個節點裡，程式碼變得龐大而複雜，對後續的維護和修改造成了困擾。
• 儘管單次 AI 呼叫的容錯能力增強了，但目前這種複雜的執行鏈全在單一節點內，一旦某個環節的邏輯出錯，除錯會非常困難，牽一髮而動全身。

心得

我今天透過更詳細的 Prompt 設計和更聰明的程式碼後處理，在一個節點裡面，建立了一套微型的分析流水線，嘗試去「輔導」而不是「命令」AI，讓它能更好地完成任務。

看到 Notion 裡的結果趨於穩定和正確，確實很有成就感，但同時我也意識到，目前的架構已經不太OK了，它現在就是一個功能強大但結構複雜的「巨石應用 (Monolith)」，繼續堆疊功能只會讓它越來越難以維護，也因為這個巨石應用導致我心力憔悴😭。

雖然如此，基於鐵人賽的精神，我可是不會放棄的！

🎯 明天計劃

導入 AI 任務鏈重構架構，將單一 AI 呼叫拆分為三個獨立節點，並為各節點分別設計簡化、目標單一的 Prompt。