Nghiên cứu tình huống 3: Một công cụ tự động hóa cá nhân

Ý tưởng

Một ý tưởng hoàn toàn ích kỷ: một đoạn script mỗi sáng lấy các sự kiện trong lịch của ngày hôm đó và thời tiết, định dạng thành một bản tóm tắt một dòng, rồi gửi vào một cuộc trò chuyện Telegram cá nhân. Mục đích là để không phải mở ba ứng dụng trước khi uống cà phê.

Bản đặc tả

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.

Câu cuối đó — xuống cấp một cách nhẹ nhàng (degrade gracefully) thay vì bị sập — là kiểu hành vi bạn phải yêu cầu một cách rõ ràng. AI sẽ không tự giả định điều đó. Nếu không nói ra, mặc định mà một mô hình chọn là "ném lỗi khi có sự cố" (throw on error), mà với một công việc chạy theo lịch (cron job) lúc 7 giờ sáng thì điều đó có nghĩa là một buổi sáng im lặng và chẳng biết vì sao.

Stack công nghệ

Một hàm chạy theo lịch duy nhất (một Worker được kích hoạt theo Cron) để không cần máy nào phải chạy liên tục. Toàn bộ chỉ là một tệp cộng với một lịch chạy. Với một công cụ cá nhân, điều này quan trọng hơn vẻ ngoài của nó: bất cứ thứ gì có máy chủ phải trông nom là thứ mà rồi bạn sẽ quên trả tiền, và dự án chết dần vì bị bỏ bê chứ không phải vì thất bại.

Một điểm kích hoạt tỏa ra đến hai nguồn và hội tụ lại thành một tin nhắn. Khối try/catch quanh mỗi nguồn chính là thứ cho phép một lỗi đơn lẻ xuống cấp nhẹ nhàng thay vì làm sập toàn bộ tiến trình:

                    ┌─────────────────┐
  7am cron ───────▶ │  WORKER         │
                    │                 │   try ┌──────────────┐
                    │  fetch sources ─┼──────▶│ WEATHER API  │
                    │  (each in       │       └──────────────┘
                    │   try/catch)    │   try ┌──────────────┐
                    │                 ┼──────▶│ CALENDAR API │
                    │  build summary  │       └──────────────┘
                    │       │         │
                    └───────┼─────────┘
                            ▼
                    ┌─────────────────┐
                    │  TELEGRAM BOT   │  "3 events today… High 24C"
                    └─────────────────┘
   one source fails → send what you have, note what's missing

Những câu lệnh then chốt

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.

Khi chúng tôi muốn tinh chỉnh câu chữ mà không phải chờ đến 7 giờ sáng:

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.

Điểm kích hoạt thử nghiệm đó đã cứu chúng tôi khỏi một vòng lặp phản hồi (feedback loop) tàn khốc — chúng tôi có thể xem kết quả theo yêu cầu thay vì một lần mỗi ngày. Đây là một nước đi tổng quát đáng để học theo: bất cứ khi nào code của bạn chạy theo lịch, hãy tự tạo cho mình một cách để chạy nó ngay bây giờ, theo yêu cầu, trước khi bạn phải cam kết chờ đợi theo đồng hồ.

Trở ngại

Tin nhắn Telegram đã đến, nhưng giờ giấc lại sai: các sự kiện hiển thị theo giờ UTC, không phải giờ Hàn Quốc. Thời tiết thì đúng. Chúng tôi cô lập vấn đề lại:

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 giải thích rằng thời tiết (Application Programming Interface — giao diện lập trình ứng dụng, cánh cửa mà một dịch vụ mở ra cho một chương trình khác lấy dữ liệu của nó) đã trả về các chuỗi đã được bản địa hóa (localized) sẵn, trong khi API lịch trả về các dấu thời gian (timestamp) theo UTC mà chúng tôi đang in ra thô nguyên. Nó thêm một bước chuyển đổi múi giờ duy nhất tại bước định dạng của lịch. Việc giới hạn phạm vi sửa lỗi vào "chỉ đường dẫn của lịch" đã ngăn nó viết lại đoạn code thời tiết vốn đang hoạt động tốt — một cách phổ biến mà các bản sửa lỗi của AI lại làm hỏng những thứ vốn không có vấn đề gì. Nửa sau của đó — "tell me why the weather path was already right" (cho tôi biết tại sao đường dẫn thời tiết vốn đã đúng) — làm được hai việc cùng lúc: nó cho chúng tôi biết nguyên nhân gốc rễ thực sự thay vì một lời đoán, và nó buộc AI phải nói rõ sự khác biệt để bản sửa lỗi của nó không vô tình "hòa hợp hóa" hai đường dẫn thành một đường dẫn hỏng chung.

Ra mắt

"Ra mắt" ở đây chỉ đơn giản là triển khai Worker, đặt lịch cron, và thêm các API dưới dạng bí mật đã mã hóa. Chúng tôi gọi điểm cuối ?test=1 vài lần để xác nhận tin nhắn đọc ổn, rồi để nó chạy tự nhiên. Nó đã chạy mỗi sáng kể từ đó — và dòng xuống cấp nhẹ nhàng đã chứng minh giá trị của nó một tháng sau, khi API thời tiết bị gián đoạn dịch vụ (outage) mà tin nhắn vẫn đến, chỉ là không có dự báo thời tiết.