ตัวตั้งเวลาไม่ใช่บรรณาธิการที่คิดเองได้
“เอา Markdown ต้นฉบับมา แก้ แล้วเผยแพร่”
ฟังดูง่ายมาก
จนกระทั่งลองทำให้เป็นอัตโนมัติ
ระบบต้องอ่าน Markdown ตัดสินว่าใช้ได้หรือยัง ตรวจ 12 ภาษา ลบหัวข้อแปลก ๆ เช็กลิงก์ เผยแพร่ เปิดหน้าเว็บจริงดู ถ้าพังก็ย้อนกลับไปหาสาเหตุ แก้ รันใหม่ แล้วตรวจอีกว่าการแก้ไม่ได้ทำอย่างอื่นพังตามไปด้วย
ไม่ทันไรสายพานก็ถูกเลื่อนตำแหน่งเป็นบรรณาธิการใหญ่
ปัญหาไม่ใช่ Cloudflare Workers งานตามเวลา หรือ GitHub Actions ไม่เก่ง
แต่งานที่มันเก่งคนละแบบ
ระบบอัตโนมัติทั่วไปเก่งมากกับงานที่รู้ขั้นตอนล่วงหน้า แต่โรงงานคอนเทนต์เจอข้อความไม่เหมือนกันทุกครั้ง และข้อผิดพลาดก็ไม่เหมือนกัน บางกรณีต้องอ่าน ตีความ แก้ และตรวจผลจริง
นี่ใกล้กับงานของ AI agent มากกว่างาน cron
1. Pipeline เดิม ไม่ได้แปลว่างานจริงเหมือนเดิม
โรงงานบทความดูเหมือนการผลิตจำนวนมาก
อินพุตคือ Markdown เอาต์พุตคือบทความที่เผยแพร่แล้ว
จึงดูเหมือนแค่รันขั้นตอนเดียวกัน 100 รอบก็พอ
แต่ข้อความไม่ใช่น็อตมาตรฐาน
บทความ A ชื่อเรื่องแปลก บทความ B หายไปหนึ่งภาษาจาก 12 ภาษา บทความ C แปลแล้ว แต่ใช้คำที่คนในประเทศนั้นไม่ใช้ค้นหา บทความ D เผลอเอาหมายเหตุ SEO ภายในไปลงในเนื้อหา บทความ E มีลิงก์พันธมิตรที่ใช้ได้จริง แต่ตำแหน่งไม่เข้ากับบทความ บทความ F เผยแพร่สำเร็จแล้ว แต่สถานะยังค้างว่า “กำลังทำงาน”
ทั้งหมดเกิดใน pipeline เดียวกัน
แต่ต้องแก้คนละวิธี
เมื่ออินพุตเปลี่ยนทุกครั้ง รูปแบบของความล้มเหลวก็เปลี่ยนตาม
2. Scheduler เก่งกับงานที่รู้ล่วงหน้าว่าต้องทำอะไร
GitHub Actions ทำงานตาม workflow ที่กำหนดไว้ล่วงหน้าเมื่อมี event การสั่งรันเอง หรือถึงเวลาที่ตั้งไว้.[1]
ChatGPT Scheduled Tasks ก็ทำงานตามเวลาหรือ event ที่รองรับ.[2]
Cloudflare Workers เก่งกับการรับคำขอ งานตามเวลา และการเชื่อมบริการต่าง ๆ
เครื่องมือเหล่านี้ตอบคำถามได้ดีว่า:
“จะรันเมื่อไร?” “ต้องรันสคริปต์ไหน?” “คำสั่งสำเร็จไหม?” “ถ้าเงื่อนไขนี้จริง ขั้นต่อไปคืออะไร?”
แต่คำถามแบบนี้ไม่เหมือนกัน:
“ชื่อเรื่องนี้ฟังเหมือนแปลด้วยเครื่องเกินไปไหม?” “ย่อหน้านี้ถูกต้อง แต่มีประโยชน์ต่อผู้อ่านหรือเปล่า?” “ลิงก์ใช้ได้ แต่ทำไมถึงอยู่ตรงนี้?” “ความล้มเหลววันนี้เหมือนเมื่อวานจริงไหม?”
Scheduler มีนาฬิกา
แต่ไม่ได้แถมสัญชาตญาณของบรรณาธิการมาให้
3. ส่วนที่ยากคือทำวงจรปรับปรุงให้จบจริง
เรื่องยากไม่ใช่แค่ “แก้หนึ่งครั้ง”
แต่ต้องทำครบ:
เจอความล้มเหลว วิเคราะห์สาเหตุ แก้ รันใหม่ ตรวจผลจริง ดูผลข้างเคียง ถ้ายังไม่ใช่ก็ลองสมมติฐานใหม่
คนทำเรื่องนี้ได้ค่อนข้างเป็นธรรมชาติ
ระบบอัตโนมัติต้องออกแบบทุกสถานะอย่างชัดเจน
กรณีที่น่าปวดหัวที่สุดคือ “สำเร็จครึ่งเดียว”
หน้าเว็บเผยแพร่แล้ว แต่สถานะยังไม่อัปเดต
งานแปลเสร็จแล้ว แต่หนึ่งภาษาเป็นค่าว่าง
ไฟล์ใน repository เปลี่ยนแล้ว แต่ production ไม่อัปเดต
ถ้ารันซ้ำแบบไม่คิด อาจเกิดการเผยแพร่ซ้ำหรือทำงานซ้ำ
ดังนั้นระบบที่ทนทานไม่ได้ตั้งเป้าแค่ “ห้ามล้ม”
แต่ต้อง:
รันซ้ำได้โดยผลสุดท้ายไม่พัง
Cloudflare Workflows รองรับขั้นตอนที่เก็บสถานะได้ การ retry และการทำงานต่อจากขั้นที่สำเร็จแล้ว โดยเอกสารก็เน้นให้การทำซ้ำปลอดภัย.[3][4]
4. Cloudflare เก่งเรื่องกู้กระบวนการ แต่การกู้ไม่ใช่การตัดสินเชิงบรรณาธิการ
Cloudflare Workflows สามารถเก็บสถานะของงานหลายขั้น retry เฉพาะส่วนที่ล้ม และทำต่อจากจุดที่เสร็จแล้วได้.[3]
Cloudflare Queues สามารถ retry และส่งข้อความที่ล้มซ้ำ ๆ ไปยัง Dead Letter Queue แยกต่างหากได้.[5]
เหมาะมากกับ:
เน็ตล่มชั่วคราว API ล้ม timeout ข้อความที่ประมวลผลไม่ผ่านซ้ำ ๆ งานที่ต้องกลับมาทำภายหลัง
แต่ปัญหาอีกแบบคือ:
“ภาษาสเปนอ่านรู้เรื่อง แต่คนท้องถิ่นไม่ค้นหาด้วยคำนี้”
“เนื้อหาถูก แต่หัวข้อนี้ทำให้บทความอ่านแย่ลง”
เพิ่ม retry จาก 3 เป็น 10 ครั้ง ไม่ได้ทำให้ระบบมีวิจารณญาณด้านเนื้อหา
มันอาจแค่ทำผิดแบบเดิม 10 ครั้งอย่างมีวินัย
Retry ไม่ใช่การคิด
5. GitHub Actions คือโต๊ะทำงานที่ดี ไม่ใช่บรรณาธิการอัตโนมัติ
GitHub Actions เหมาะมากกับงานที่ตัดสินได้ชัด
รัน test ตรวจไฟล์ build deploy เมื่อผ่านเงื่อนไข รันสคริปต์ตามเวลา
นี่คือจุดแข็งของมัน.[1]
แต่ Actions จะไม่อ่านบทความแล้วคิดเองว่า:
“จริง ๆ ปัญหาอยู่ที่บทนำ ไม่ใช่ชื่อเรื่อง”
เราสามารถเรียก AI จาก workflow ได้
แต่ทันทีที่ทำ ปัญหาหลักจะกลายเป็น:
ให้ AI เห็นบริบทอะไร อนุญาตให้แก้อะไร ตรวจผลอย่างไร ถ้าล้มแล้วกลับมาทำต่อจากไหน
เอาวาระประชุมกองบรรณาธิการไปให้สว่านไฟฟ้า แล้วโกรธที่มันประชุมไม่เป็น ก็ดูจะโหดกับสว่านไปหน่อย
6. แยกเส้นทางปกติกับเส้นทางข้อยกเว้น ดีกว่าไล่ล่าอัตโนมัติ 100%
โรงงานที่ใช้งานจริงควรมีสองเส้นทาง
เส้นทางปกติ: ให้เครื่องจัดการสิ่งที่ตรวจได้ชัด
เช่น:
- มีไฟล์ที่จำเป็น
- มีครบ 12 ภาษา
- ไม่มีช่องว่าง
- URL ถูกโครงสร้าง
- ID ไม่ซ้ำ
- คำสั่งเผยแพร่สำเร็จ
- หน้า production เปิดได้
Workers สคริปต์ และ Actions เหมาะกับงานนี้
เส้นทางข้อยกเว้น: แยกออก แล้วให้สายพานเดินต่อ
บทความหนึ่งพัง ไม่ควรทำให้ทั้งโรงงานหยุด
บันทึกเหตุผล แยกบทความนั้นออก ไปบทความถัดไป
หมวดตัวอย่าง:
- ภาษาไม่ครบ
- โครงสร้างผิด
- ลิงก์ผิด
- เผยแพร่ล้มเหลว
- ต้องตรวจเนื้อหา
- ไม่รู้สาเหตุ
ถ้า 90 จาก 100 บทความผ่านอัตโนมัติ ก็เผยแพร่ 90 ก่อน
ไม่ต้องให้ 90 บทความปกติยืนเข้าแถวรอ เพราะอีก 10 บทความกำลังมีปัญหาชีวิต
ข้ามข้อยกเว้น แล้วทำต่อ
7. ส่งข้อยกเว้นให้ AI agent ที่อ่าน repository ได้
ข้อยกเว้นมักต้องการการอ่าน การคิด การแก้ และการตรวจผล
นี่คือจุดที่ coding agent เหมาะ
เอกสาร Codex Cloud อธิบายว่าสามารถทำงานในสภาพแวดล้อมโปรเจกต์ที่เตรียมไว้ สืบปัญหา แก้โค้ด รันการทดสอบ และทำงาน cloud task เดิมต่อบนอุปกรณ์ที่รองรับได้.[6]
ในโรงงานคอนเทนต์ agent สามารถเป็นโต๊ะซ่อม:
หยิบบทความที่ล้ม อ่าน Markdown ต้นฉบับ ดูผลที่สร้าง อ่านบันทึกความล้มเหลว ดูโค้ดถ้าจำเป็น แก้ รันตรวจ เผยแพร่อีกครั้ง แล้วเปิดหน้าเว็บจริงดู
ไม่จำเป็นต้องใช้ความสามารถของ AI กับทุกบทความปกติ
งานง่ายให้เครื่อง
งานประหลาดให้ agent
8. เมื่อข้อยกเว้นเกิดบ่อย ให้ย้ายมันกลับไปเป็นกฎอัตโนมัติ
คิวข้อยกเว้นไม่ควรเป็นกองขยะถาวร
ถ้าปัญหาเดิมเกิดบ่อย มันไม่ใช่ข้อยกเว้นแล้ว แต่มันคือรูปแบบ
ถ้าภาษาใดหายบ่อย เพิ่มตัวตรวจอัตโนมัติ
ถ้าหัวข้อเดิมหลุดเข้ามาบ่อย เพิ่ม validator
ถ้าเผยแพร่สำเร็จแต่สถานะอัปเดตพลาดบ่อย ให้ตรวจหน้า production ก่อน แล้วซ่อมสถานะอัตโนมัติ
ลำดับที่เหมาะคือ:
ให้โรงงานทำงานก่อน เก็บความล้มเหลวจริง ให้ AI ซ่อมกรณีแปลก หา pattern ที่เกิดซ้ำ แล้วค่อยทำ pattern เหล่านั้นเป็นกฎตายตัว
ถ้าพยายามทำนายทุกความล้มเหลวก่อนเริ่มผลิต โรงงานอาจสร้างไม่เสร็จตลอดกาล
สรุป: Scheduler คือสายพาน ส่วน AI agent คือโต๊ะซ่อม
Cloudflare งานตามเวลา และ GitHub Actions จะดูน่าผิดหวัง ถ้าเราคาดหวังให้มันเป็นบรรณาธิการอิสระ
แต่จริง ๆ บทบาทต่างกัน
ระบบตามเวลาควร:
เริ่มงาน ตรวจสิ่งที่ชัดเจน ส่งของปกติไปต่อ แยกของเสีย รักษาสายการผลิตให้เดิน
AI agent ควรตอบ:
“ทำไมบทความนี้ถึงแปลก?” “ต้องแก้อะไร?” “แก้แล้วดีจริงไหม?”
โครงสร้างที่ใช้งานได้จริงคือ:
ทำเส้นทางง่ายให้เป็นอัตโนมัติ อย่าให้ข้อยกเว้นหนึ่งตัวหยุดทั้งชุด ส่งเฉพาะข้อยกเว้นให้ agent ข้อยกเว้นที่เกิดซ้ำค่อยเปลี่ยนเป็นกฎอัตโนมัติ
โรงงานคอนเทนต์ไม่ต้องการสายพานที่คิดได้ทุกเรื่อง
มันต้องการสายพานที่ไม่หยุด กับโต๊ะซ่อมที่ฉลาดพอสำหรับกล่องที่หลุดออกจากสาย
เอกสารอ้างอิง (6 รายการ)
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
