ใช้ AI เขียนโพสต์ Facebook ด้วย n8n และให้คนอนุมัติก่อนเผยแพร่

คู่มือเชิงออกแบบและตัวอย่างจำลอง ไม่ใช่หลักฐานการโพสต์ Facebook Page จริง; ต้องตรวจสิทธิ์บัญชี Meta, API Version และการทดสอบก่อนเปิดใช้งาน.

เริ่มจาก Brief ที่มีเจ้าของข้อมูล

การให้ AI เขียนโพสต์ Facebook ควรเริ่มที่ปัญหาที่ผู้อ่านอยากรู้ ไม่ใช่สั่งให้โมเดลสร้างโพสต์จำนวนมาก. Brief ควรมีวัตถุประสงค์ ผู้ชม ช่องทาง โทนภาษา ข้อมูลสินค้าที่รับรองแล้ว สิ่งที่ห้ามกล่าวอ้าง และลิงก์ปลายทาง. ข้อมูลลูกค้า ข้อเสนอราคา และภาพหน้างานที่ไม่มีสิทธิ์ไม่ควรถูกส่งไปยังโมเดลโดยอัตโนมัติ. สำหรับหลักการสร้างคอนเทนต์ อ่าน ใช้ AI ช่วยทำคอนเทนต์.

ตัวอย่าง Prompt ที่ไม่ปล่อยให้ AI เดาตัวเลข

ให้ระบุเป็นคำสั่งว่า: Role: Facebook Page copy assistant; Audience: ผู้เริ่มใช้บริการ; Facts: ต้องทราบพื้นที่, ประเภทงาน และข้อมูลสำหรับติดต่อ; Must not invent: ราคา, รีวิวลูกค้า, ตัวเลขสถิติ, การรับประกัน; Output: caption, CTA, facts_to_verify, missing_information. ตัวอย่างนี้เป็น Prompt สมมติ สำหรับทีมบริการติดตั้งระบบ ไม่ใช่ข้อความที่ Prai.io เคยโพสต์หรือผลสำรวจลูกค้าจริง. ถ้า AI ส่งคำกล่าวอ้างที่ไม่อยู่ใน Facts ให้ส่งกลับตรวจ ห้ามให้ระบบอนุมัติให้ตัวเอง.

วาง State Machine ก่อนส่ง Approval

ใช้สถานะตัวอย่าง brief_ready → drafted → in_review → approved → scheduled → publishing → published; สถานะปฏิเสธคือ needs_revision, rejected, failed และ unknown. ทั้งหมดเป็นชื่อ State ที่เสนอในการออกแบบ ไม่ใช่สถานะมาตรฐานของ Meta/n8n. เมื่อมีการแก้ Caption ต้องเพิ่ม revision และทำให้ Approval เดิมใช้ไม่ได้; ให้ Publishing Gate ตรวจว่า approved_revision === current_revision และตรวจเนื้อหาฉบับที่ลงชื่ออนุมัติจริง.

บันทึกหลักฐานการอนุมัติที่ตรวจย้อนกลับได้

Approval Record ควรมี content_id, revision, approved_by, approved_at, content_hash, asset_reviewed และ expires_at. ผู้อนุมัติต้องมาจากตัวตน/สิทธิ์ในระบบ ไม่ใช่ใครพิมพ์ชื่อในชีตแล้วถือว่าอนุมัติแล้ว. ให้แยกผู้อนุมัติเนื้อหาจากผู้ถือ Credentials เพื่อโพสต์; เปิด Log แบบอ่านย้อนหลังได้ แต่ไม่บันทึกรหัสผ่านหรือ Token ลงแชตแจ้งเตือน.

เลือกวิธีให้คนตรวจจริง

n8n มีรูปแบบบาง Integration ที่รองรับการส่งข้อความแล้วรอคำตอบ เช่น Gmail Send and Wait for Approval; อย่างไรก็ตาม ปุ่มในอีเมลอย่างเดียวอาจไม่เพียงพอสำหรับการพิสูจน์ตัวตนในทุกบริบท. สำหรับองค์กรที่ต้องตรวจความรับผิดชอบ ใช้ Dashboard ภายในหรือระบบอนุมัติที่ผูกบัญชีผู้มีสิทธิ์. กำหนดอายุคำขอและป้องกัน Double Approve หรือ Approve หลังจากมีการแก้ข้อความ.

ตัวอย่าง Approval Record และการเปลี่ยน Revision

ตัวอย่างข้อมูลที่ใช้ตรวจย้อนหลังได้โดยไม่ใช้ตัวตนลูกค้าจริง:

```json { “content_id”: “FB-DEMO-004”, “revision”: 3, “approved_revision”: 3, “approval_status”: “approved”, “reviewer_role”: “content-editor”, “approved_at”: “2026-11-03T09:00:00+07:00”, “asset_reviewed”: true, “caption_hash”: “GENERATE_FROM_APPROVED_TEXT” } ```

`caption_hash` ในตัวอย่างนี้เป็น Placeholder ไม่ใช่ Hash ที่คำนวณจริง ระบบที่ใช้งานต้องคำนวณจากเนื้อหาและไฟล์ที่อนุมัติ โดยใช้วิธีที่ชัดเจนและตรวจเทียบก่อนโพสต์. ถ้า Editor เปลี่ยน Caption หลังจาก Approve แล้ว Revision ต้องเป็น 4 ขณะที่ `approved_revision` ยังคง 3; ระบบจึงต้อง BLOCKED จนกว่าผู้มีสิทธิ์จะตรวจฉบับ 4 และลงชื่อใหม่.

อย่าถือว่า Google Sheets ช่อง `approved_by` ที่ผู้ใช้แก้เองได้เป็นหลักฐานการอนุมัติที่น่าเชื่อถือสำหรับทุกระบบ ต้องอาศัย Authentication/Authorization ของเครื่องมือที่ใช้ลงชื่อและ Audit Log ตามความเสี่ยงของงาน รวมถึงวิธีถอนการอนุมัติเมื่อพบข้อมูลผิด.

ตัวอย่างเกณฑ์ให้คนตรวจ Caption

สิ่งที่ AI ร่าง	ทีมควรตรวจ	ผลตัดสิน
“บริการติดตั้งเสร็จภายใน 1 วัน”	มีหลักฐานและเงื่อนไขเวลาจริงหรือไม่	ไม่มีหลักฐาน → แก้/Reject
“ดูคู่มือก่อนติดต่อเพื่อขอประเมินงาน”	URL ถูกต้องและบทความมีคำตอบจริงหรือไม่	ผ่านเมื่อ Link ใช้ได้
“ลูกค้าส่วนใหญ่พอใจ 99%”	มีการสำรวจจริงหรือไม่	ไม่มี → ห้ามโพสต์
รูปก่อน/หลังงาน	สิทธิ์ภาพและข้อมูลบุคคลในภาพ	ต้องได้รับอนุญาตก่อน

Checklist คุณภาพก่อนเปิดคิว

ตรวจชื่อบริษัทและบริการถูกต้อง, ตัวเลข/สถิติมีแหล่งอ้างอิง, ข้อมูลทางกฎหมาย/ราคาให้ผู้รับผิดชอบยืนยัน, ภาพมี License, ข้อความไทยอ่านได้, ลิงก์เป็น HTTPS และไม่มีข้อมูลส่วนบุคคล. เมื่อทีมปฏิเสธโพสต์ให้บันทึกเหตุผลเพื่อปรับ Prompt รอบถัดไป ไม่ปิดการตรวจเพียงเพื่อให้ Workflow รันเร็วขึ้น.

ทดสอบ Human Gate แบบไม่ยิง Facebook

ทดสอบ Draft ปกติ, Draft ที่ AI แต่งข้อมูล, การปฏิเสธ, การแก้ Caption หลัง Approve, การกดซ้ำ และ Approval หมดอายุ. ทุกกรณีที่ไม่ผ่านต้องหยุดก่อน Publishing Node. ตัวอย่าง Workflow JSON ใน Repository เป็น Dry Run และจะไม่ส่ง API ไป Facebook เพื่อป้องกันการโพสต์จริงโดยไม่ตั้งใจ.

ตัวอย่าง Gate สำหรับลองแบบ Dry Run

ทดลองด้วยข้อมูลจำลองใน n8n ของตัวเอง: เริ่มจาก Manual Trigger สร้างข้อมูลที่มี revision, approved_revision, approval_status และ publish_at จากนั้นใช้ IF/Code Node ตรวจเงื่อนไขว่า Draft, Revision ไม่ตรง หรือเวลายังไม่ถึง ต้องเข้าสู่ทาง BLOCKED ทุกครั้ง ยังไม่ต้องเพิ่ม Facebook Publishing Node หรือ Credentials

อ่านต่อ

หลังอนุมัติให้ไปที่ Content Calendar จาก Google Sheets และ ตั้งเวลาโพสต์. หากมีงานเกี่ยวกับ LINE หรือข้อความลูกค้า ให้ดู รวมลีดจากเว็บไซต์ LINE OA และ Facebook ซึ่งเป็นคนละ Workflow จากการสร้างโพสต์เพจ.

แหล่งอ้างอิงและขอบเขตการตรวจ

ข้อมูล n8n ตรวจวันที่ 3 พฤศจิกายน 2026: Facebook Graph API Node, Schedule Trigger, Executions และ Gmail Approval. หากจะเผยแพร่บน Facebook Page ให้ตรวจ Meta Pages API สำหรับ Permissions, App Review, Media Endpoints และ Graph API Version กับบัญชีผู้พัฒนาที่ได้รับสิทธิ์จริงก่อน Deploy. บทความนี้ไม่ได้ใช้บัญชี Page เพื่อโพสต์จริง.