กรณีศึกษาที่ 3: เครื่องมือทำงานอัตโนมัติส่วนตัว

ไอเดีย

โปรเจกต์เพื่อความสะดวกส่วนตัวล้วน ๆ สคริปต์ที่ทุกเช้าจะดึงกิจกรรมในปฏิทินของวันนั้นและสภาพอากาศ จัดรูปแบบเป็นสรุปหนึ่งบรรทัด แล้วส่งไปยังแชท Telegram ส่วนตัว จุดประสงค์คือเพื่อไม่ต้องเปิดสามแอปก่อนดื่มกาแฟทุกเช้า

สเปก

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 จะไม่คาดเดามันเอง ถ้าไม่พูดออกมา ค่าเริ่มต้นที่โมเดลมักเลือกใช้คือ "โยน error ออกไปเลย" ซึ่งสำหรับงาน cron ตอนตีเจ็ดแล้ว หมายถึงเช้าเงียบ ๆ ที่ไม่มีข้อความอะไรมาเลย และไม่มีเบาะแสว่าทำไม

สแต็กที่เลือกใช้

ฟังก์ชัน serverless แบบมีตารางเวลาเดียว (Worker ที่ทริกเกอร์ด้วย Cron) เพื่อไม่ต้องมีเครื่องอะไรที่ต้องคอยเปิดทิ้งไว้ ทั้งหมดคือไฟล์เดียวบวกกับตารางเวลาหนึ่งอัน สำหรับเครื่องมือส่วนตัว เรื่องนี้สำคัญกว่าที่ฟังดู เพราะอะไรก็ตามที่มีเซิร์ฟเวอร์ต้องคอยดูแลเป็นสิ่งที่คุณจะลืมจ่ายเงินให้ในที่สุด และโปรเจกต์ก็จะตายเพราะถูกทอดทิ้ง ไม่ใช่เพราะความล้มเหลว

ทริกเกอร์หนึ่งตัวกระจายไปสองแหล่งข้อมูล แล้วรวมกลับมาเป็นข้อความเดียว try/catch รอบแต่ละแหล่งข้อมูลคือสิ่งที่ทำให้ความล้มเหลวจุดเดียวลดระดับอย่างสง่างามแทนที่จะทำให้การรันทั้งหมดตายไปด้วย:

                    ┌─────────────────┐
  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

พรอมต์สำคัญ

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.

พอเราอยากปรับแต่งถ้อยคำโดยไม่ต้องรอถึงตีเจ็ด:

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 อธิบายว่า weather API (Application Programming Interface — ประตูที่บริการหนึ่งเปิดไว้ให้โปรแกรมอื่นดึงข้อมูลของมันไปใช้) ส่งค่ากลับมาเป็นสตริงที่แปลงเป็นเวลาท้องถิ่นแล้วอยู่แล้ว ในขณะที่ calendar API ส่งกลับเป็น timestamp แบบ UTC ที่เรานำมาแสดงตรง ๆ โดยไม่แปลง มันเพิ่มการแปลงเขตเวลาเข้าไปหนึ่งจุดตรงขั้นตอนจัดรูปแบบปฏิทิน การจำกัดขอบเขตของการแก้ไขให้เหลือแค่ "เฉพาะเส้นทางปฏิทินเท่านั้น" หยุดไม่ให้มันไปเขียนโค้ด weather ที่ใช้งานได้ดีอยู่แล้วซ้ำ ซึ่งเป็นวิธีที่ AI มักทำพังในสิ่งที่เคยดีอยู่แล้ว ส่วนครึ่งหลังของพรอมต์นั้น ที่บอกว่า "tell me why the weather path was already right" ทำหน้าที่สองอย่างพร้อมกัน คือให้สาเหตุที่แท้จริงแก่เราแทนที่จะเป็นการเดา และบังคับให้ AI ต้องอธิบายความแตกต่างของทั้งสองเส้นทาง เพื่อไม่ให้มันเผลอ "ทำให้เหมือนกัน" ทั้งสองเส้นทางจนกลายเป็นพังทั้งคู่โดยไม่ตั้งใจ

การเปิดตัว

"การเปิดตัว" ในที่นี้หมายถึงแค่การดีพลอย Worker ตั้งตารางเวลา cron และเพิ่มโทเคน API เป็นความลับแบบเข้ารหัส เรายิงเข้าเอนด์พอยต์ ?test=1 สองสามครั้งเพื่อยืนยันว่าข้อความอ่านลื่นดี แล้วก็ปล่อยให้มันทำงานไป มันรันทุกเช้ามาตั้งแต่นั้น และบรรทัดที่บอกให้ลดระดับอย่างสง่างามก็พิสูจน์คุณค่าของมันในอีกหนึ่งเดือนต่อมา เมื่อ weather API ล่ม แต่ข้อความก็ยังส่งมาถึงอยู่ดี เพียงแต่ไม่มีพยากรณ์อากาศเท่านั้น