主題一：前三堂課程交流與補充

本主題旨在對前三週的學習重點進行深度沉澱與補充，並針對同仁在實務開發中遇到的盲點進行診斷與解答。

---

📌 常見提醒與交付規範 (台灣時間 UTC+8)

本課程與專案之所有宣告、作業交付截止日期等時間，皆統一宣告並以台灣時間 (UTC+8) 為唯一準則。

• 雙軌標準規範 (md + html): 所有提問集、作業及大綱，必須同時提交 Markdown (.md) 檔（供 AI/LLM 結構理解）與 HTML (.html) 網頁檔（供人類閱讀），落實雙軌並行標準。
• 壓縮包命名習慣 (ZIP 檔案): 凡提交程式碼或專案資源壓縮包時，請遵循 「[時間戳記]_[重要更新事項].zip」 命名規範（例如：20260622_class04_project.zip）。

---

💬 前三週重點補充與問題解答

1. 人機協作模式 (HITL - Human in the Loop)

在複雜的企業流程（如 ERP 自動入帳、智慧對帳）中，AI 無法達到 100% 的精準度。因此，必須建立合理的人機協作機制：

• AI 負責 90% 的繁重工作：包括非結構化憑證的 OCR 辨識、初步分類、欄位清洗與比對。
• 人類負責 10% 的高風險決策：當 AI 信心指數（Confidence Score）低於閾值（例如 85%），或是稽核引擎觸發異常警示時，系統自動將任務分流至人工審核界面，確保數據品質。

2. 雙軌文件策略

在 AI-Native 的開發模式下，文件不只是給人看的，更是給 AI 助理（如 Antigravity）讀取的關鍵上下文：

• Markdown (.md)：語意結構清晰，便於 LLM 進行 RAG 檢索、代碼生成與上下文控制。
• HTML (.html)：具備豐富的視覺樣式與互動效果，方便團隊成員、管理層以及客戶直觀理解。

---

🛠️ 同學專案方向交流與診斷

現場開放式的交流與診斷環節。學員可分享各自的專案構想或工作痛點，由講師現場診斷並給予可行性建議，協助同仁順利完成謝總交代的作業與功課。

診斷核心指標

1. 痛點真實性：該流程是否每日重複、耗費高昂人工工時？

2. AI 必要性：是否必須使用 LLM 語意理解，還是傳統的 Rule-based / Regex 就能解決？

3. 資料可得性：是否有足夠且合規的樣本數據供 AI 學習與測試？

4. 落地經濟性：Token 消耗與運行成本是否可控？

---

🙋 學員課前提問與解答 (FAQ)

Q: 如果有想討論的專案構想，需要提前準備什麼嗎？

A: 建議提前整理出：

1. 目前的人工作業流程與痛點（例如：每週需花費 4 小時手動比對 ERP 報表與電子發票）。

2. 期望達成的自動化效果（例如：系統能自動收信、下載發票、辨識金額並與 ERP 沖帳，異常時通知會計）。

哪怕只有文字大綱或螢幕截圖，只要提前傳給講師，便能方便講師事先準備相關案例，讓課程診斷更貼近您的需求！ *[標籤: 專案診斷, 課前準備]*