前言
前四階段,我們把範本本身打磨得相當扎實了——結構清楚、防呆到位、有版本控制、有客觀驗證方法。但到目前為止,你每次使用範本,還是得手動打開對話介面、貼上資料、複製輸出。今天要開始的最後一階段,目標是把這個「手動操作」的環節,也串接成自動化流程的一部分。
第一步,我們要先搞懂一個概念:API。

一、你現在的操作方式,其實是「人類在當中間人」
回顧你現在的工作流程:你打開公司 AI 工具的對話介面 → 貼上 System Prompt(或它已經記住了)→ 貼上這週的資料 → AI 生成 .md → 你複製貼上到公司系統。
這個流程裡,你自己扮演了「把資料從一個系統,搬到另一個系統」的角色。這件事本身,其實也是一種可以被自動化取代的機械性工作——這正是 Day 15 談過「機械性工作交給程式」的邏輯,延伸到整個工作流程的層次。
二、API 是什麼:用一句話理解
API(應用程式介面)可以簡單理解為:讓兩個不同的軟體系統,不透過人類操作介面,直接互相溝通的一種標準化管道。
你現在用的對話介面,本質上是「人類友善的操作方式」——按鈕、輸入框、聊天視窗,這些都是設計給人看、給人點擊用的。但很多 AI 工具,在這層介面底下,同時也提供了一種「給程式用」的溝通方式:你的程式碼直接把 prompt 送過去,AI 直接把結果傳回來,中間完全不需要人去點擊任何按鈕。
用一個比喻理解:對話介面就像你去餐廳,親自跟服務生點餐;API 就像餐廳同時提供了一個「電話點餐專線」,讓另一個系統(例如外送 App)可以直接打電話下單,不需要真人服務生在中間傳話。
三、有了 API,你的工作流程可以變成什麼樣子
一旦你的公司 AI 工具提供 API(或者,你的自動化改用可以呼叫 API 的服務),原本手動的流程,理論上可以變成:

① 程式自動從監控平台撈取資料
② 程式自動把資料套進你設計好的範本(套用 Day 18 的佔位符邏輯)
③ 程式透過 API,把組好的 prompt 送給 AI
④ AI 回傳結果,程式自動接收
⑤ 程式自動把結果存成 .md 檔案,甚至直接推送到 Slack / Teams / Email
這五個步驟裡,你需要真正動手的部分,可能只剩下最初設定流程、以及偶爾檢查輸出品質——這才是真正意義上的「自動化」,而不是「手動操作,只是操作的內容變成跟 AI 對話」。
四、跨出這一步之前,該先確認的事
在真的動手寫程式串接之前(這是 Day 26 的內容),建議先確認幾件事:

1. 你們公司的 AI 工具,是否提供 API 存取? 這需要跟工具的技術文件或負責建置這套系統的同事確認,不是每個內部工具一開始就有開放這個功能
2. 串接 API 是否需要額外的權限申請? 通常涉及金鑰(API Key)的申請與管理,這部分會直接關係到 Day 29 談的安全性考量
3. 你的自動化程度,現階段真的需要走到「完全自動」嗎? 有時候,「半自動化」——例如程式自動整理好資料、自動組好 prompt,但仍由你手動貼上去執行最後一步——已經能省下大部分重複工作,不一定每個環節都要立刻做到全自動
   五、今天的行動練習
   去了解一下你們公司的 AI 工具,是否有提供 API 或類似的程式化存取方式(可以請教負責維運這套系統的同事,或查閱內部技術文件)。如果目前沒有這個功能,也可以先評估:你的自動化流程,有沒有辦法先做到「半自動化」,把資料整理與範本組裝的部分先用程式處理,减少手動操作的環節。

小結
今天我們跨出了從「使用 AI 工具」到「串接 AI 工具」的第一步概念。API,就是讓你不再需要親自坐在對話介面前操作的關鍵管道。這一步的價值,不在於技術本身有多複雜,而在於它把你之前建立好的整套範本邏輯,從「需要人手動觸發」,升級成「可以被排程、被串接、被完全交給系統執行」。
明天,我們要正式動手寫一段簡單的 Python 腳本,示範怎麼讀取資料、並實際呼叫 API 完成一次自動化請求。