เมื่อใช้ AI เขียนบทความ สร้างหน้าเว็บ หรือร่างอีเมล งานตรวจและแก้ไขยังเป็นส่วนหนึ่งของ workflow คลิปนี้เสนอให้แยกงานสร้างกับงานตรวจ แล้วส่งข้อแก้ไขกลับไปเป็นวงรอบ
คลิปของ Julian Goldie บนช่อง Julian Goldie SEO เสนอแนวคิด Self-Checking Factory หรือ AI agent loops ที่ให้ Builder สร้างงาน และให้ Judge ตรวจตามเกณฑ์ก่อนส่งต่อ จุดที่นำมาพิจารณาได้คือมาตรฐานและจุดตรวจใน workflow
สรุปนี้เป็นภาพรวมแนวคิดจากตัวอย่างของผู้สร้าง จุดเริ่มต้นที่เขาเสนอคือระบุว่า “งานที่เสร็จแล้ว” ต้องเป็นอย่างไร ก่อนให้ agent สร้าง ตรวจ และปรับแก้ตามเกณฑ์นั้น ส่วนการติดตั้งและผลด้านเวลา ต้นทุน หรือคุณภาพยังไม่มีหลักฐานทดสอบที่บันทึกไว้ให้ตรวจซ้ำ
วิดีโอต้นทางเผยแพร่วันที่ 15 กรกฎาคม 2026 เวลา 15:00:01 น. ตามเวลาไทย (08:00:01 UTC) ดูวิดีโอต้นทาง
เปลี่ยนมุมมองจากใช้ AI เป็นคนทำงาน ไปเป็นระบบผลิตงาน
Julian เปรียบการส่งงานจาก AI ให้เราโดยไม่มีการตรวจ เหมือนร้านเบเกอรีที่นำขนมออกจากเตาแล้วส่งถึงลูกค้าทันที โดยไม่มีใครชิมหรือตรวจว่าอบสุกหรือไม่ บางชิ้นอาจดี แต่บางชิ้นอาจยังดิบตรงกลาง และคนที่พบปัญหาคือลูกค้า
ตัวอย่างการนำกรอบนี้มาคิดกับงานธุรกิจคือการสั่ง AI เขียนบทความ สร้าง landing page ทำแผนคอนเทนต์ หรือร่างอีเมลขาย แล้วตรวจลิงก์ คำผิด และความครบถ้วนก่อนใช้งาน
ในภาพเปรียบเทียบของ Julian คนวางเป้าหมาย มาตรฐาน และเงื่อนไขการอนุมัติ ส่วน agent ช่วยผลิตและตรวจงานเป็นรอบ การแยกบทบาทเช่นนี้ไม่ได้ทำให้ความรับผิดชอบในการตรวจและอนุมัติของคนหมดไป
ตัวอย่างสมมติสำหรับธุรกิจไทยคือร้านค้าออนไลน์ที่ต้องผลิตโพสต์ขายสินค้า 30 ชิ้นต่อเดือน อาจวาง flow ให้ Builder เขียนโพสต์ แล้วให้ Judge ตรวจโทนภาษา ข้อมูลสินค้า คำกระตุ้นการซื้อ และข้อความที่ต้องมี โดยเจ้าของงานยังตรวจข้อเท็จจริงก่อนเผยแพร่
เขียน Definition of Done ให้ AI เข้าใจตรงกัน
Julian ให้ความสำคัญกับ Definition of Done หรือเกณฑ์ว่างานใดถือว่าเสร็จ ก่อนเลือก Builder และ Judge หากเกณฑ์คลุมเครือ ผู้สร้างและผู้ตรวจอาจตีความต่างกัน
ตัวอย่าง brief ที่บทความนี้เสนอประกอบคือ “สร้างบทความ SEO สำหรับกลุ่มเจ้าของธุรกิจ ความยาว 1,200 คำ มีหัวข้อย่อย มีตัวอย่าง มีคำค้นหลักอย่างเป็นธรรมชาติ และไม่มีคำกล่าวอ้างเกินข้อมูลที่ให้” เงื่อนไขต้องเลือกให้ตรงกับงานที่จะทำ
คำสั่งแบบ “เขียนบทความดี ๆ” ยังไม่ระบุวิธีตัดสินความดีให้ชัด รายการต่อไปนี้เป็นตัวอย่างเกณฑ์ที่เจ้าของงานอาจกำหนดเพิ่มเติม:
- ผลลัพธ์ที่ต้องการ: บทความ หน้าเสนอขาย ชุดอีเมล สรุปรายงาน หรือแผนคอนเทนต์
- กลุ่มเป้าหมาย: ผู้ซื้อ ลูกค้าเดิม ทีมขาย หรือผู้บริหาร
- เงื่อนไขบังคับ: หัวข้อ ภาษา โทน และข้อมูลที่ห้ามตกหล่น
- เกณฑ์คุณภาพ: ความถูกต้อง ความชัดเจน ความครบ และความสอดคล้องกับแบรนด์
- เงื่อนไขผ่าน: ผูกกับหลักฐานและข้อกำหนดของงาน ไม่ถือว่าคะแนนของ Judge ยืนยันความถูกต้องได้เอง
ผู้สร้างเสนอว่างานที่เขียนเป้าหมายและตรวจเทียบกับเป้าหมายได้อาจนำมาทำเป็น loop ได้ ตัวอย่างในบทความนี้ เช่น สรุปประชุม คัดกรอง lead หรือร่างข้อเสนอขาย เป็นแนวทางประยุกต์ที่ต้องทดสอบกับข้อมูลและเกณฑ์ของแต่ละงาน
แยก Builder และ Judge ออกจากกัน
โครงสร้างที่ Julian นำเสนอมีสองบทบาท คือ Builder ผู้สร้างงาน และ Judge ผู้ตรวจตามเกณฑ์ ในตัวอย่างของเขาใช้ model ต่างกันสำหรับสองบทบาท
ผู้สร้างให้เหตุผลว่าให้ AI ตรวจงานตัวเองอาจมองข้ามข้อบกพร่อง เช่น หัวข้อหาย คำสั่งถูกละเลย หรือปุ่มใช้งานไม่ได้ จึงเพิ่ม Judge อีกตัวเข้ามาตรวจ ยังไม่มีการเปรียบเทียบที่บันทึกไว้ให้ยืนยันว่าจะลด bias หรือตรวจพบข้อผิดพลาดได้มากเพียงใด
Judge เป็นผู้ประเมินอีกชุดหนึ่งที่ยังผิดได้ การให้ AI ตรวจ AI จึงควรอ่านคำตัดสินและหลักฐานประกอบ แทนการถือว่าผลผ่านยืนยันความถูกต้องหรือทดแทนการตัดสินใจเชิงธุรกิจของคน
ตั้งวงรอบ คะแนน และ Ship Gate ให้ชัด
ใน workflow ที่ผู้สร้างอธิบาย Builder ส่งงานให้ Judge ให้คะแนนพร้อมคำตัดสินและข้อแก้ไข จากนั้นส่ง feedback กลับไปสร้างรอบใหม่ เขายกตัวอย่างการกำหนดเพดาน 20 รอบ เจ้าของ workflow ยังต้องกำหนดว่าจะทำอย่างไรเมื่อครบเพดานหรือเกิดข้อผิดพลาด
Julian เล่าตัวอย่างคะแนนจาก 8 เป็น 85 และ 100 ตามลำดับ คะแนนเหล่านี้เป็นผลประเมินที่ผู้สร้างรายงาน ไม่ใช่ benchmark คุณภาพที่ตรวจสอบอิสระ เพราะไม่มี rubric, run log หรือผลรันทดสอบซ้ำที่บันทึกไว้ คะแนน 100 จึงไม่ยืนยันว่าชิ้นงานไม่มีข้อผิดพลาด
เจ้าของ workflow ต้องกำหนดเงื่อนไขผ่าน ขอบเขตการวน และกรณีส่งกลับให้คนตรวจตามงานจริง โดยใช้คะแนนประกอบหลักฐานและข้อกำหนดของงาน
Ship Gate คือจุดตัดสินว่าจะส่งงานต่อหรือเก็บไว้ตรวจ ในการประยุกต์กับธุรกิจ อาจส่งเข้า CMS เป็นร่าง ส่งให้ทีมขายตรวจ หรือเก็บในคลังคอนเทนต์ก่อนอนุมัติ การวนครบจำนวนรอบไม่ใช่หลักฐานว่างานผ่านแล้ว
เลือกรูปแบบ workflow ให้เหมาะกับระดับความซับซ้อน
Julian นำเสนอวิธีจัด workflow สามรูปแบบในคลิป:
1. Loop Engineering สำหรับงานเดี่ยวที่ต้องการมาตรฐาน
ในแบบ Loop Engineering ผู้สร้างใส่เป้าหมาย เลือก Builder และ Judge แล้วตั้งเงื่อนไขคะแนนและจำนวนรอบ งานอย่างบทความ หน้า landing page รายงานสรุป หรืออีเมลเป็นตัวอย่างการประยุกต์
2. Kanban Board สำหรับงานที่มีหลายขั้นและหลาย agent
ในแบบ Kanban Board ผู้สร้างแบ่งงานเป็นขั้นและมอบหมายหลายบทบาท เช่น วางแผน สร้าง ตรวจ และปรับแก้ แนวคิดคือให้เห็นงานย่อยและสถานะ แทนการรวมทุกอย่างไว้ในคำสั่งเดียว
ตัวอย่างสมมติคือบริษัทท่องเที่ยวไทยที่ทำหน้าโปรโมตแพ็กเกจ โดยแบ่ง agent ให้ร่างโครง เขียนคำขาย และตรวจข้อมูลที่ต้องมี แล้วให้ Judge เทียบกับข้อเสนอ จุดเด่น และโทนแบรนด์
3. Agent Group Chat สำหรับระดมและต่อยอดไอเดีย
ในแบบ Agent Group Chat ผู้สร้างให้ agent สนทนา เสนอและโต้แย้งไอเดีย ก่อนส่งไอเดียเข้ากระบวนการสร้างงาน การคิดบริการหรือแคมเปญเป็นแนวทางประยุกต์ที่ยังต้องมีเจ้าของเลือกและตรวจความเหมาะสม
ข้อเสนอในการนำไปลองคือเริ่มจากงานซ้ำที่มีเกณฑ์ชัดหนึ่งงาน แล้วบันทึกว่า Builder และ Judge ทำอะไรและพลาดตรงไหน เพื่อจำกัดขอบเขตและทบทวนผลการทดลอง
เก็บทุกงานใน Workspace เพื่อสร้างทรัพย์สินของธุรกิจ
ผู้สร้างกล่าวถึง workspace ที่เก็บงานซึ่งผ่านกระบวนการแล้ว พร้อมดูสถานะและคำตัดสินได้ จึงย้อนดูตัวอย่างของ workflow ได้
ในการประยุกต์กับทีม บทความนี้เสนอให้เก็บ brief เวอร์ชันงาน คำตัดสินของ Judge และเกณฑ์ที่ใช้ตรวจ เพื่อย้อนทบทวนการอนุมัติ
งานที่ Judge ให้คะแนนสูงยังอาจมีข้อมูลผิด จึงต้องตรวจคำกล่าวอ้างเทียบกับแหล่งข้อมูลของงาน และระบุผู้รับผิดชอบก่อนเผยแพร่ คะแนนเป็นข้อมูลประกอบการตรวจ ไม่ใช่ใบรับรองความถูกต้อง
