เคยทำ feature ใหม่ในระบบ แล้วลืมว่า "แล้วของเก่าล่ะ?" ไหมครับ — ผมเป็นบ่อย 555 เมื่อวานทิมเพิ่งช่วยแก้เคสนี้ให้ผมเคสหนึ่ง 58 โพสต์เก่าของเพจ EN ของผม ลืมแปะ source link ในคอมเมนต์ไว้ — สั่งทิมรอบเดียว backfill ครบทั้ง Facebook ทั้ง Instagram ในเย็นเดียว
เรื่องไม่ใหญ่หรอกครับ แต่ตัว script ที่ทิมเขียนออกมามันละเอียดมากในแบบที่ผมว่าน่าเล่า — เพราะมันคือสิ่งที่แยก AI Agent ที่ใช้ทำงานได้จริง ออกจาก ChatGPT ที่แค่เขียน code ส่งให้
ปัญหา: เพิ่ม feature ใหม่ ลืมของเก่า
เล่า context ก่อน — Documentor คือระบบ content automation ของผม ที่โพสต์ลง FB + IG เพจ EN วันละหลายครั้ง คอนเทนต์มาจากการที่ทิมไป research หัวข้อ AI agent ใหม่ๆ ทุกวัน
เมื่อ 2 อาทิตย์ก่อน ผมเพิ่ม feature ใหม่ — ให้ทุกโพสต์มี คอมเมนต์ source link อัตโนมัติใต้โพสต์ คนอ่านจะได้เข้าไปดูแหล่งที่มาต่อได้
label ของคอมเมนต์ก็เปลี่ยนตาม category ของเนื้อหา:
youtube→ "Full video here:"oss→ "Repo:"case_study/news/how_to/failure→ "Source:"
โพสต์ใหม่ใช้ได้เลย ทุก content ที่ออกตั้งแต่วันที่ผม ship feature มี source link ครบ — แต่โพสต์เก่าที่ออกไปก่อนหน้านี้แล้ว 58 ตัว ไม่มีอ่ะ
ผมเปิดเข้าไปดูเพจตัวเอง รู้สึกขัดใจ — ครึ่งหนึ่งของ feed มีคอมเมนต์ source ครบ อีกครึ่งหายไป ดูไม่สม่ำเสมอ
เลยบอกทิมว่า "ขอ script backfill หน่อย — โพสต์เก่าที่ยังไม่มี source link comment ให้ใส่ย้อนหลังหมด"
ขอ dry-run ก่อน — เพราะ FB rate limit ลงโทษหนัก
เรื่อง backfill บน Facebook API นี่ผมระวังมากครับ ถ้ายิงเร็วเกินไป มันลงโทษด้วยการ block API ของเพจคุณเลย — เคยโดนมาแล้วครั้งหนึ่ง ตอนทดสอบ FB Marketing API รอบเดียวก็เข็ดละ
ผมเลยบอกทิมก่อนว่า "อย่าเพิ่งยิงจริงนะ — รัน --dry-run ก่อน ดูว่ามันจะทำอะไรกับโพสต์ไหนบ้าง"
ทิมรู้ทันที — เพิ่ม flag --dry-run ลง script ตั้งแต่ตอนแรกเลย ไม่ต้องเตือนซ้ำ:
- มี flag → print ว่าจะโพสต์อะไรลงตรงไหน แต่ไม่ยิงจริง
- ไม่มี flag → ลุยจริง + commit DB
รัน dry-run รอบแรก เจอ candidates = 58 โพสต์ ทุก category มาครบ news 21 ตัว, how_to 8 ตัว, case_study 7 ตัว, failure 7 ตัว, youtube 7 ตัว, oss 6 ตัว — ดูแล้วเลขดูสมเหตุสมผล (เพจรัน auto-content มาประมาณเดือนนึง วันละหลายโพสต์ก็ได้เลขประมาณนี้)
เปิดดู preview message ของแต่ละตัวอีกรอบ — label ตรง, link ตรง, format ตรงกับโพสต์ใหม่ๆ ที่ออกมา 100%
เอาล่ะ ลุยจริง
3 วินาทีต่อโพสต์ — กับเหตุผลที่ทำไมเลขนี้
ทิมใส่ time.sleep(3) ระหว่างทุก API call — ไม่ใช่แค่ระหว่างโพสต์ แต่ระหว่างทุกครั้งที่ยิง FB API
คือใน loop แต่ละรอบ มันยิง 2 ครั้ง: 1) post comment ลง FB, 2) post comment ลง IG ผ่าน Graph API เดียวกัน ทิมเลย sleep 3 วินาทีหลังยิง FB เสร็จก่อน + อีก 3 วินาทีหลังยิง IG ก่อนเข้ารอบถัดไป
รวมแล้วประมาณ 6-7 วินาทีต่อ 1 โพสต์ — 58 โพสต์ก็คือ 6 นาทีกว่าๆ ผมไปกินข้าวข้าวล่างก่อนกลับมาก็เสร็จละ
ผมเคยอยากเร่งให้เร็วกว่านี้ — ทิมเถียงผมว่า "อย่าเร่งครับ ค่าเสียเวลา 6 นาที vs ค่าเสียโอกาสโดน block API เป็นวันๆ ไม่คุ้มกัน" จริงครับ จุดนี้ AI ของผมคิดแทนผมเรียบร้อย
เกร็ดเล็กๆ ที่ทำให้ script นี้ดี — FB ผ่าน แต่ IG fail ไม่ตาย
นี่คือส่วนที่ผมชอบที่สุดของ script ตัวนี้ครับ
ในโพสต์ของผม Documentor มัน cross-post ลง FB + IG พร้อมกัน ใช้ token เดียวกันผ่าน Graph API — แต่บางครั้ง FB ส่งคอมเมนต์ได้สำเร็จ แล้ว IG fail ด้วยเหตุผลแปลกๆ เช่น media id หมดอายุ, หรือ comment policy ของ IG เข้มกว่า FB
ถ้าเขียน script แบบ "ถ้า fail ตรงไหนหยุดทั้งหมด" — เจอ IG พังโพสต์เดียว เลิกเลย เหลืออีก 57 ไม่ได้ backfill
ทิมเลยทำแบบนี้แทน:
- ยิง FB ก่อน → fail = count fail, skip ทั้งโพสต์นี้ ขึ้นโพสต์ถัดไป
- ยิง FB สำเร็จ → ยิง IG ต่อ
- IG fail = print warning แต่นับเป็น success + commit DB ด้วย
fb_comment_idที่ได้ แต่ig_comment_id = NULL
ผลลัพธ์: 58 candidates → ok = 58 (FB ครบทุกตัว, IG มีบางตัวพลาด แต่ไม่ทำให้ทั้ง batch หยุด)
นี่คือ defensive coding ที่ผมเคยเขียนถึงตอนแก้ Documentor พังเงียบ 3 วัน — ทิมเรียนรู้ว่าระบบ production จริงต้องไม่ครบทันที 100% เสมอ ต้องวางแผนว่า "ถ้าบางจุดพังจะยังทำส่วนที่เหลือต่อได้ยังไง"
หลังโพสต์เสร็จ — ต้อง record ลง DB ทันที
ส่วนสุดท้ายที่ทำให้ script นี้สมบูรณ์ — หลังโพสต์คอมเมนต์ลง FB/IG สำเร็จ ทิม INSERT row ใหม่ลงตาราง blocks เก็บ fb_comment_id + ig_comment_id ไว้ทันที
ทำไมต้อง record? เพราะ cron ตัวจริงที่โพสต์ใหม่ทุกวัน ใช้ตาราง blocks นี้แหละในการเช็คว่า "โพสต์ไหนมี source comment แล้ว ไม่ต้องยิงซ้ำ"
ถ้าทิม backfill comment ลง FB/IG จริง แต่ไม่ insert row — รอบหน้าที่ cron มันรัน มันจะเห็นว่า "โพสต์นี้ยังไม่มี block!" แล้ว backfill ซ้ำอีกรอบ ลงเป็น duplicate comment ใต้โพสต์เดียวกัน 2 ครั้ง ฝันร้าย
ทิม commit DB หลังทุก loop iteration ทันที — ไม่รอ batch จบค่อย commit รอบเดียว เพราะถ้า script ตายระหว่างทาง (network drop, FB error อะไรก็ตาม) อย่างน้อยรอบที่ผ่านมาแล้วจะถูก save ไว้ รัน script รอบสองจะ skip โพสต์ที่ทำไปแล้ว ไม่ duplicate
idempotent — รันกี่รอบก็เหมือนเดิม นี่คือ property ที่ดีของ script backfill ที่อยู่กับ external API
ทำไมเรื่องเล็กแบบนี้ถึงสำคัญสำหรับคนทำธุรกิจ
ผมเล่าเรื่องนี้ไม่ใช่เพราะ feature สลักสำคัญอะไรกับธุรกิจ — แต่เพราะมันคือตัวอย่างของ "งานที่ดีมาก ถ้ามีคนทำ — แต่ไม่มีค่ามากพอจะจ้างคน"
คิดดูครับ ถ้าผมไม่มีทิม:
- ทำเอง — เปิด FB business suite ทีละโพสต์ 58 ครั้ง ก็อปลิงก์ source ใส่คอมเมนต์เอง ใช้เวลา 1-2 ชั่วโมง แล้วยังต้องทำ IG ซ้ำอีกรอบ
- จ้าง VA — สอน 1 ครั้ง ตามดู QA อีก เสียเวลามากกว่าทำเองอีก สำหรับงานครั้งเดียว
- ไม่ทำเลย — feed ดูไม่สม่ำเสมอ คนอ่านที่ไปดูโพสต์เก่าก็เข้าใจว่าเพจไม่ใส่ใจ source
กับทิม — ผมพิมพ์ประโยคเดียว "ขอ script backfill comment ให้โพสต์เก่าที่ยังไม่มี" รอ 10 นาทีก็ได้ script พร้อมรัน รวม dry-run อีก 1 รอบ แล้วยิงจริง — เสร็จก่อนผมกินข้าวเย็นเสร็จด้วยซ้ำ
นี่คือ "งานที่ดีที่จะได้ทำ ถ้าค่าทำต่ำพอ" — AI Agent ลด threshold ตรงนั้นลง ทุกงานเล็กๆ ที่ปกติเรา "ปล่อยเลย" กลายเป็นทำได้หมด
ของแถมที่ทิมเก็บไว้ให้ผม
หลังรันเสร็จ ทิม print สรุปท้าย script ออกมา:
ok=58 fail=0 dry=False- candidates ครบทุก category ตรงกับ dry-run ที่เห็นก่อนหน้า
- บอกผมว่า "เก็บ script ไว้ที่
/root/scripts/inc-content-backfill-comments.pyใช้รอบหน้าได้ ถ้าเปลี่ยน executor หรือเพิ่ม category ใหม่"
คือมันไม่ใช่แค่ทำงานให้เสร็จแล้วลบ — ทิมทำให้มันเป็น tool ที่อยู่ในระบบ ใช้ซ้ำได้ พอวันหลังผมเพิ่ม feature ใหม่อีก (เช่น เพิ่ม "Tag co-authors" comment) ก็มาดู script นี้เป็น reference ได้เลย ทำนองเดียวกับตอนที่ผมให้ทิมสร้างบอทคอยตอบคอมเมนต์ใต้โพสต์อัตโนมัติ — งานคอมเมนต์ FB ซ้ำๆ ที่ AI Agent ทำแทนได้หมด
คำถามที่พบบ่อย
เพิ่ม feature ใหม่แล้ว ของเก่าไม่มี จะ backfill ย้อนหลังด้วย AI ทำได้ไหม?
ได้ครับ AI Agent สามารถเขียน script backfill ให้ได้เลย โดยปกติ pattern คือสั่งให้ทำ dry-run ก่อนเพื่อดูว่าจะแก้อะไรบ้าง พอ approve แล้วค่อยรันจริง แนะนำให้มี flag --dry-run ทุกครั้งที่ backfill บน external API เพราะพลาดแล้วแก้ยากกว่างานในระบบเรา
ทำไม backfill บน Facebook API ต้องระวังเรื่อง rate limit?
Facebook จะ block API ของเพจถ้า request เยอะเกินไปในเวลาสั้นครับ โดนครั้งหนึ่งต้องรอเป็นวันกว่าจะ unblock ระยะ sleep 3 วินาทีต่อ API call เป็น trade-off ระหว่างความเร็วกับความเสี่ยง ถ้าต้อง backfill 58 โพสต์ใช้เวลา 6 นาทีแค่นั้น เทียบกับรอ 1 วันถ้าโดน block คุ้มกว่ามาก
backfill script ที่ดีต้องมีอะไรบ้าง?
อย่างน้อยต้องมี: dry-run mode เพื่อตรวจก่อนรันจริง, rate limiting กันโดน block, idempotent คือรันซ้ำกี่รอบก็ผลเหมือนกัน, บันทึก state ลง DB ทันทีหลังแต่ละ record เพื่อกัน duplicate ถ้า script ตายกลางทาง และ error handling แยก partial failure ออกจาก full failure
งานเล็กๆ แบบ backfill ที่ไม่คุ้มจ้างคน AI ช่วยได้ไหม?
นี่แหละคือจุดที่ AI Agent มีประโยชน์สูงสุดครับ งานที่ทำได้แต่ค่าทำเองหรือค่าจ้างไม่คุ้ม พอมี AI Agent ทำให้ threshold มันต่ำลง งานที่ปกติปล่อยทิ้งเพราะไม่คุ้มก็ทำได้หมด ระบบที่สมบูรณ์กว่าโดยไม่ต้องเสียเวลาเองหรือเสียเงินจ้างคน
ถ้าคุณรัน ระบบ content / e-commerce / SaaS ของตัวเอง แล้วเคยเจอเคสแบบนี้ — เพิ่ม feature ใหม่ ลืมของเก่า แล้วไม่อยากเสียเวลานั่ง backfill ทีละตัว — มี AI Agent ของตัวเองช่วยตรงนี้ดีกว่าครับ ลอง Newton ดู — เป็น server ส่วนตัวพร้อม AI Agent ติดตั้งมาให้แล้ว สั่งให้เขียน backfill script แบบนี้ พร้อม dry-run + rate limit + idempotent ครบ ไม่ต้อง dev เองสักบรรทัด