ไม่ใช่ทุกการกระทำ
ที่ต้องรอคน

คุณมีสองทางเวลาทำงานกับ AI agent แล้วมันบั่นทอนทั้งคู่ อนุมัติทุกอย่างที่มันทำ คุณก็กลายเป็นคอขวด ปล่อยให้มันวิ่งเอง สุดท้ายก็ได้เดโมที่ลบไฟล์ผิดตอนตีสอง คนส่วนใหญ่ที่เขียนเรื่อง "human in the loop" มองมันเป็นสวิตช์แบบนั้นพอดี คือเปิด หรือ ปิด

ที่มองเป็นเปิดปิดแบบนี้แหละที่ทำให้งาน AI หลายงานมันเหนื่อย ตั้งด่านอนุมัติทุกอย่าง AI ก็เหลือค่าแค่ autocomplete ราคาแพง ไม่มีด่านเลย มันก็กลายเป็นภาระที่ปล่อยทิ้งไว้ไม่ได้

เล่าก่อนว่าเราเป็นใคร เราสร้าง product ด้วย AI ผู้ช่วยแทบทุกวัน ส่วนใหญ่ทำคนเดียว สิ่งที่จะเล่าต่อจากนี้คือกฎที่เราใช้จริง ไม่ใช่ทฤษฎี

เดโมที่ AI ทำงานเสร็จมันง่าย ใครก็ทำได้ในบ่ายเดียว ส่วนที่ขึ้น production ได้จริง ส่วนที่แทบไม่มีใครเขียนถึง คือ guardrail ที่อยู่ข้างใต้ คือการรู้ว่าการตัดสินใจ "ไหน" ที่ AI ตัดสินเองได้ และอันไหนที่ต้องส่งกลับมาให้คุณ

ข้อคิดมันเล็กนิดเดียว แต่เปลี่ยนทุกอย่าง ไม่ใช่ทุกการกระทำที่ต้องรอคน คุณแบ่งระดับมันต่างหาก

โมเดลสามระดับ

เวลาเราทำงานกับ AI ผู้ช่วย ทุกการกระทำจะตกอยู่ในระดับใดระดับหนึ่งใน 3 ระดับ คำถามที่ใช้แบ่งมันเหมือนเดิมทุกครั้ง เรื่องนี้ใหญ่แค่ไหน และย้อนกลับได้ไหม

ทักษะทั้งหมดอยู่ที่การแบ่งให้เร็วและแบ่งให้ตรง ความผิดพลาดส่วนใหญ่ไม่ใช่ "AI ทำผิด" แต่เป็น "AI เอาเรื่อง 🟥 ไปใส่ถัง 🟩 ต่างหาก" คือมันรันอะไรที่ย้อนไม่ได้ราวกับว่ามันเป็นเรื่องเล็ก

ของจริงหน้าตาตอนมันทำงานจริง

ระดับพวกนี้ฟังดูสะอาดตาบนสไลด์ แต่ของจริงตอนนั่งทำงานหน้าตาเป็นแบบนี้ รวมถึงตอนที่ AI เดาผิด แล้ว framework จับได้ด้วย

ก่อนเข้าเรื่องโค้ด ขอแม็ปกับงานที่เจอกันทุกวันก่อน AI ร่างอีเมลตอบลูกค้าแล้วกดส่งเอง คือ 🟥 (ออกถึงคนนอก ย้อนยาก รอคุณก่อน) · AI เลือกผู้ขายให้จากสามเจ้า คือ 🟨 (ก้ำกึ่ง ชี้ tradeoff มาให้ตัดสินด้วยกัน) · AI จัดหมวดใบเสร็จเข้าระบบบัญชี คือ 🟩 (เล็ก ย้อนได้ ทำแล้วรายงาน) หลักเดียวกันเป๊ะ แค่เปลี่ยนโดเมน สองเรื่องข้างล่างนี้มาจากงาน dev ของเราเอง แต่เวลาอ่านลองแทนด้วยงานของคุณดู

🟩 สคริปต์ที่เกือบโดนลบ

ตอนเก็บกวาด AI เจอสคริปต์ตัวเล็กๆ ที่ดูจากชื่อแล้วเหมือนไฟล์ซ้ำที่หลงเหลือ แล้วกำลังจะลบ ดูเล็ก ดูย้อนได้ เป็นปลายน้ำชัดๆ เป็นเรื่องที่ AI ควรจัดการเองโดยไม่ต้องมากวนเรา

แต่มีนิสัยอันหนึ่งฝังไว้ก่อนลบทุกครั้ง อ่านมันก่อน พออ่านก็พบว่ามันไม่ใช่ไฟล์ซ้ำเลย มันคือสคริปต์ตัวที่ถอดเสียงสะอาดออกมาให้โปรเจกต์ ด้วยวิธีที่ฉลาดกว่าตัวที่เราเก็บไว้ด้วยซ้ำ AI เลยปล่อยมันไว้ ทำความสะอาดในส่วนที่ถูกสั่งให้ทำจริง แล้วรายงานสิ่งที่เจอ

นี่คือปลายน้ำที่ทำงานถูกต้อง AI จัดการเองแล้วบอกเราทีหลัง นิสัย "อ่านก่อนลบ" ไม่ใช่ด่านขออนุมัติจากคน แต่เป็น guardrail ที่ AI รันเอง บนการกระทำของตัวเอง ก่อนลงมือจริง ความต่างตรงนี้คือหัวใจทั้งหมด ปลายน้ำไม่ได้แปลว่าสะเพร่า แต่แปลว่าความระมัดระวังถูกฝังเข้าไปในกระบวนการของ AI เอง แทนที่จะวิ่งผ่านเรา

🟨 config ที่มันไม่ยอมเดา

ทีนี้เรื่องที่ยากขึ้น ขั้นตอนประมวลผลเสียงต้องเลือกขนาด "ก้อนเสียง" ที่ตัดส่งให้โมเดลทีละก้อน (ศัพท์เทคนิคเรียก chunk size) ระหว่าง 180 วินาที กับ 30 วินาที มีเหตุผลรองรับทั้งสองทางจริงๆ ก้อนใหญ่เรียกโมเดลน้อยครั้งกว่า ก้อนเล็กจัดการได้ละเอียดกว่าแต่ต้นทุนต่อครั้งรวมแล้วเยอะกว่า คำตอบที่ "ถูก" จากมุมที่ AI ยืนอยู่มันไม่ชัดเลยจริงๆ

ท่าที่ยั่วใจ ท่าที่ระบบเปิดปิดชวนให้ทำ คือให้ AI เลือกสักอันแล้วไปต่อ แต่มันกลับทำท่ากลางน้ำแทน คือชี้ tradeoff ออกมา นี่คือทางเลือก นี่คือสิ่งที่คิด และนี่คือเหตุผลที่ยังไม่แน่ใจ

เราเลือกคำตอบที่คนทำ product ส่วนใหญ่น่าจะคุ้น พิสูจน์ก่อน อย่าเถียงสมมติฐาน เทสมันเลย เราเลยรันการทดลองเล็กๆ แบบมีตัวควบคุม แล้วการทดลองนั้นก็ล้มสมมติฐานหลักของ AI เอง สิ่งที่มันคงจะเลือกเงียบๆ ถ้าเราปล่อยให้มันรันแบบปลายน้ำ คืออันที่ผิด

นี่คือจุดที่กลางน้ำคุ้มค่าตัวเอง ไม่ใช่เพราะ AI ไม่ฉลาด แต่เพราะมันเป็นโซนที่การเดาแบบมั่นใจคือกับดัก พอ "เช็คก่อน" ชนะ "เดาเอา" การกระทำส่วนใหญ่ไม่เคยมาถึงระดับนี้ มันคือพวกปลายน้ำน่าเบื่อที่จัดการเองแล้วรายงาน คุณจะรู้สึกถึง framework แค่ตอนอยู่ขอบๆ คือ 🟥 ที่ดีใจที่มันไม่แตะ กับ 🟨 ที่มันถามถูกแล้ว

แก่นเรื่องทำไมตรงนี้ถึงเป็นส่วนที่ขึ้น production ได้

ลองดูว่าทั้งสองเรื่องมีอะไรเหมือนกัน ความผิดพลาดที่น่าสนใจไม่เคยเป็น "AI โง่" ในเคส config นั้น AI ผิดแบบมั่นใจ และเหตุผลเดียวที่มันไม่หลุดไปคือการตัดสินใจถูกจัดระดับเป็นกลางน้ำอย่างถูกต้อง แล้วเอาไปเทสแทนที่จะเดาเอา

นั่นแหละคือ guardrail เดโมคือ "AI ทำงาน" แต่ product คือ "AI รู้เพดานว่าตัวเองตัดสินอะไรเองได้บ้าง และการเดาผิดในเรื่องที่เป็นการตัดสินใจจริงจะถูกจับได้ก่อนที่มันจะทำให้คุณเสียหาย" อันแรกคือกลเม็ดเรียกเสียงฮือฮา อันหลังคือความต่างระหว่างผู้ช่วยที่คุณปล่อยให้รันทิ้งไว้ได้ กับผู้ช่วยที่ต้องนั่งเฝ้า

คนละเรื่องกับ access นะ access ตอบคำถามว่า "เรื่องไหนที่ AI ควรเริ่มลงมือได้บ้าง" (เรื่องนั้นมีโพสต์ของมันเอง) ส่วนโพสต์นี้สมมติว่า AI ลงมือไปแล้ว แล้วถามต่อว่าใครเป็นเจ้าของการตัดสิน พูดง่ายๆ access คุมประตูหน้า ส่วนการแบ่งระดับคุมพวงมาลัย

สรุปสิ่งที่เอากลับไปใช้

1. Human in the loop ไม่ใช่เรื่องมีคนหรือไม่มีคน คำถามที่ใช้ได้จริงไม่เคยเป็น "มีคนหรือไม่มีคน" แต่เป็น "การตัดสินใจ 'ไหน' ที่เป็นของคน และอันไหนที่ AI เป็นเจ้าของ"
2. แบ่งตามขนาดและความย้อนกลับได้ ใหญ่หรือย้อนไม่ได้ คุณตัดสิน (🟥) ปานกลางและไม่ชัด ตัดสินด้วยกัน (🟨) เล็กและย้อนได้ AI ตัดสินแล้วรายงาน (🟩)
3. ระดับที่อันตรายคือตรงกลาง การเดาแบบมั่นใจบน tradeoff จริงคือความพังคลาสสิก พอคำตอบที่ถูกยังไม่ชัด ก็ชี้ออกมาเลย อย่าตั้งเป็นค่า default
4. ปลายน้ำไม่ได้แปลว่าสะเพร่า "AI ตัดสิน" ยังพก guardrail ที่ AI รันบนตัวเองอยู่ ดูก่อนลบ ตรวจก่อนเคลมว่าเสร็จ ความระมัดระวังย้ายเข้าไปอยู่ในกระบวนการของ AI มันไม่ได้หายไป
5. รายงานแทนการขออนุญาต งานปลายน้ำคุณไม่ต้องอนุมัติ คุณแค่ต้องได้รับแจ้ง การรายงานเชิงรุกคือสิ่งที่ทำให้ปล่อยให้ AI รันเองได้อย่างปลอดภัย

🔒 ขอเก็บไว้รับวิธีที่ใช้ได้จริง

หลักการอยู่ตรงนี้แล้ว ฟรี คือแบ่งระดับการกระทำของคุณ แล้วลูปก็จะเลิกเป็นคอขวด

สิ่งที่เรายังไม่ได้ใส่ในโพสต์นี้คือส่วนที่ทำให้มัน "ใช้งานได้จริง" คือ rubric ที่เราใช้แบ่งการกระทำใหม่ลงระดับภายในไม่กี่วินาที ถ้อยคำที่ทำให้ AI ชี้ tradeoff ออกมาแทนที่จะเดา และตัวบังคับอัตโนมัติที่คุมระดับพวกนี้ตอน AI ทำงานจริง เพื่อให้ "AI ตัดสิน" ไม่แอบรั่วกลายเป็น "AI ตัดสินอะไรที่ย้อนไม่ได้ไปแล้ว" นั่นคือความต่างระหว่างไอเดียสวยๆ กับ guardrail ที่ AI ของคุณทำตามจริง

🔒 รับวิธีที่ใช้ได้จริง → rubric แบ่งระดับ + hook ที่บังคับมันตอน runtime หลักการอยู่ข้างบนนี้ฟรีแล้ว ส่วนวิธีที่เอาไปใช้งานได้จริงคือเวอร์ชันที่เก็บไว้

ครั้งแรกที่ framework นี้คุ้มค่าตัวจริงๆ ไม่ใช่เพราะ AI ทำอะไรเจ๋ง แต่เพราะ AI กำลังจะผิดแบบมั่นใจ การตัดสินใจนั่งอยู่ในระดับที่ถูก แล้ว "พิสูจน์ก่อน" ชนะ "เชื่อตามที่ AI เดา" นั่นแหละคือทั้งซีรีส์ในโมเมนต์เดียว เดโมมันง่าย guardrail คือเนื้องาน