案例研究 3：一個個人自動化小工具
想法
一個純粹利己的專案：一個指令碼，每天早上抓取當天的日曆事件和天氣，格式化成一行摘要，傳送到一個私人的 Telegram 聊天裡。重點是別在喝咖啡之前還要開啟三個應用。
Spec
A scheduled job that runs at 7am my timezone. It reads today's
events from my calendar, fetches the forecast for my city, and
sends one Telegram message like: "3 events today, first at 9:30.
High 24C, rain after 4pm." If any source fails, still send what
you have and note what's missing.
最後那句話——優雅地降級而不是崩潰——是那種你必須明確提出來要求的行為。AI 不會自動假定它。不說出來，模型會去抓的預設就是"出錯就拋異常"，而對一個早上 7 點的 cron 任務來說，那意味著一個靜悄悄的早晨，以及對原因毫無頭緒。
技術棧
一個單獨的、定時觸發的 serverless 函式（一個由 Cron 觸發的 Worker），這樣就沒有一臺需要保持執行的機器。整個東西就是一個檔案加一份排程計劃。對一個個人小工具來說，這比聽上去更要緊：任何有一臺需要照看的伺服器的東西，你遲早會忘了續費，於是這個專案死於荒廢，而不是死於失敗。
一個觸發器扇出到兩個資料來源，再匯聚回一條訊息。包住每個資料來源的 try/catch，讓單個失敗優雅降級，而不是殺掉整次執行：
┌─────────────────┐
早7點 cron ─────▶ │ WORKER │
│ │ try ┌──────────────┐
│ 抓取資料來源 ────┼──────▶│ WEATHER API │
│ (各自 │ └──────────────┘
│ try/catch) │ try ┌──────────────┐
│ ┼──────▶│ CALENDAR API │
│ 生成摘要 │ └──────────────┘
│ │ │
└───────┼─────────┘
▼
┌─────────────────┐
│ TELEGRAM BOT │ "今天有 3 個日程… 最高24C"
└─────────────────┘
只要有一個數據源失敗 → 把已有內容發出去，並標註缺失的部分
關鍵的 prompt
Write a Cloudflare Worker triggered by cron at 7am Asia/Seoul.
It calls a weather API and a calendar API (I'll provide both
tokens as secrets), builds a one-line summary, and POSTs it to
the Telegram Bot API. Wrap each external call in try/catch so one
failure doesn't kill the message. Read every token from env.
當我們想要打磨措辭，又不想等到早上 7 點時：
Add a manual trigger: if the Worker is hit with a GET request and
a ?test=1 query param, run the same logic immediately and return
the message text in the response instead of sending it. Keep this
behind a secret token so only I can trigger it.
這個測試觸發器把我們從一個殘酷的反饋迴圈裡救了出來——我們可以隨時按需看到輸出，而不必每天只看一次。這是個值得偷師的通用招式：每當你的程式碼按計劃執行時，在你認命去等時鐘之前，先給自己造一個能現在就按需跑它的法子。
障礙
Telegram 訊息到了，但時間是錯的：事件顯示的是 UTC，而不是韓國時間。天氣倒是沒問題。我們把它隔離了出來：
Calendar times are 9 hours off — showing UTC, not Asia/Seoul.
The weather time ("rain after 4pm") is correct. Here's how I
format both: [pasted]. Fix only the calendar formatting and tell
me why the weather path was already right.
AI 解釋說，天氣 （Application Programming Interface，應用程式程式設計介面）已經返回了本地化的字串，而日曆 API 返回的是我們直接原樣打印出來的 UTC 時間戳。它在日曆格式化那一步加上了一次時區轉換。把修復範圍限定在"只改日曆路徑"，阻止了它去重寫那段本來就工作正常的天氣程式碼——這是 AI 的修復弄壞本來好端端的東西的一種常見方式。那個 prompt 的後半句——"tell me why the weather path was already right"——一身二任：它給了我們真正的根因而不是一個猜測，並且逼著 AI 把這個差別講清楚，好讓它的修復不至於把兩條路徑意外"統一"成一條壞的。
上線
這裡的"上線"只不過意味著部署 Worker、設定 cron 排程計劃，以及把 API token 作為加密金鑰加進去。我們點了幾次 ?test=1 端點以確認訊息讀起來不錯，然後就放著不管了。從那以後它每天早上都在執行——而那條優雅降級的話，在一個月後天氣 API 出故障時證明了它的價值：訊息照樣到了，只是少了天氣預報而已。