ก่อน commit แผนใหญ่ ให้ AI โจมตีแผนตัวเองก่อน: Adversarial Self-Critique

งานหลักของผมในแบงก์คือ model validation — พูดง่าย ๆ คือมีคนสร้างโมเดลขึ้นมา แล้วหน้าที่ผมคือพยายามหาว่ามันจะพังตรงไหน ก่อนที่มันจะพังกับเงินจริง สิ่งที่อาชีพนี้สอนผมมาตลอดคือ คำตอบที่ฟังดูดีที่สุดมักเป็นคำตอบที่อันตรายที่สุด เพราะมันชวนให้เราเลิกตั้งคำถาม พอผมมาใช้ Claude Code รันงานทั้งวัน ผมก็เอานิสัยเดียวกันนี้มาใช้กับ AI — ก่อนจะ commit แผนใหญ่อะไรก็ตาม ผมให้ AI โจมตีแผนของตัวเองก่อน บทความนี้คือวิธีคิดเบื้องหลังสิ่งที่ผมเรียกว่า adversarial self-critique และทำไมมันถึงเป็นขั้นที่ผมไม่ยอมข้าม

1. ปัญหา: AI เห็นด้วยกับคุณเก่งเกินไป

ถ้าคุณเคยขอให้ AI ช่วยวางแผน แล้วมันตอบกลับมาด้วยแผนที่ดูครบถ้วนสวยงาม คุณคงเคยรู้สึกดีกับมัน — และนั่นแหละคือกับดัก โมเดลภาษาถูกฝึกมาให้ "เป็นประโยชน์" ซึ่งในทางปฏิบัติมักออกมาเป็นการ เห็นด้วยกับสมมติฐานของคุณ มากกว่าจะท้าทายมัน ร่างแรกจึงมักเป็นแผนที่ฟังดูสมเหตุสมผล แต่ยังไม่มีใครลองหาจุดที่มันพังเลยสักครั้ง

ในงานเสี่ยง เราเรียกของแบบนี้ว่า "plausible but wrong" — ถูกต้องตามหน้าตา แต่ผิดในสาระ และมันอันตรายกว่าคำตอบที่ผิดแบบเห็นชัด เพราะคำตอบที่ผิดชัด ๆ เราจับได้เอง แต่คำตอบที่ฟังดูดีจะลื่นผ่านการตรวจไปเงียบ ๆ จนไปโผล่ตอน production

กฎจากงานวัดความเสี่ยง: ถ้าแผนหรือคำตอบฟังดูดีเกินจริงและไม่มีข้อโต้แย้งเลย ให้สงสัยไว้ก่อน — ไม่ใช่เพราะมันผิดเสมอ แต่เพราะยังไม่มีใครพยายามทำให้มันผิด ความเงียบของข้อโต้แย้งไม่ใช่สัญญาณว่าแผนแข็งแรง

2. Adversarial self-critique คืออะไร

หลักการง่ายมาก: ก่อนจะลงมือทำตามแผน ให้ AI สวมหมวก "ฝ่ายค้าน" แล้วพยายาม หักล้างแผนของตัวเอง ราวกับว่ามันคือคนที่อยากให้แผนนี้ล้มเหลว ไม่ใช่ถามแบบสุภาพว่า "แผนนี้มีจุดอ่อนไหม" (ซึ่งมักได้คำตอบกลาง ๆ กลับมา) แต่สั่งให้มันโจมตีจริง ๆ — หาเคสที่แผนพัง หาสมมติฐานที่ไม่ได้พิสูจน์ หาขั้นตอนที่ถ้าลำดับสลับแล้วเกิดความเสียหาย

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

มุมคนทำ model validation: การ validate ไม่ใช่การถามว่า "ดีไหม" แต่คือการตั้งสมมติฐานว่า "มันพังได้ยังไงบ้าง" แล้วไล่ทดสอบทีละทาง คำถามที่ดีของผู้ค้านไม่ใช่ "คุณมั่นใจแค่ไหน" แต่คือ "ต้องเกิดอะไรขึ้นแผนนี้ถึงจะล้ม"

3. ทำไมต้องใช้ "คนละหัว" มาตรวจ

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

หลักการ model validation ข้อแรกสุดคือ ผู้ตรวจต้องเป็นอิสระจากผู้สร้าง ผมเอาหลักนี้มาใช้ตรง ๆ กับ AI — ให้ผู้วิจารณ์เป็นคนละบริบท คนละ session หรือถ้าทำได้ คนละโมเดลไปเลย เพื่อให้มันโจมตีแผนโดยไม่ติดอคติจากการที่เคยเป็นคนสร้างมันเอง แนวคิด "แยกผู้สร้างออกจากผู้ตรวจ" นี้คือหัวใจเดียวกับที่ผมเขียนไว้ในModel Risk ในยุค AI Agent และมันต่อยอดได้ดีกับการกระจายงานให้ subagent หลายตัวทำขนานกัน — ตัวหนึ่งสร้าง อีกตัวรับบทมือปราบ

เช็กก่อนเชื่อ: อย่าให้ AI ตัวที่เพิ่งเชียร์แผนเป็นคนตรวจแผนนั้นเอง ความเป็นอิสระของผู้ตรวจคือสิ่งที่ทำให้คำวิจารณ์มีน้ำหนัก ไม่ใช่ความฉลาดของตัวโมเดลอย่างเดียว

4. เอาไปใช้จริงยังไง (โครงคร่าว ๆ)

หน้าตาที่ผมใช้แบ่งเป็นสามจังหวะ: ให้ AI ร่างแผน → สั่งให้มันสวมบทผู้ค้านและโจมตีแผนนั้น → แล้วค่อยให้มันสังเคราะห์แผนใหม่ที่อุดช่องที่เพิ่งเจอ พรอมป์ตั้งต้นสั้น ๆ ที่พอเห็นภาพคือ:

นี่คือแผนของฉัน: [แผน]
สวมบทบาทผู้ตรวจที่อยากให้แผนนี้ล้มเหลว
ระบุ 3 จุดที่แผนนี้จะพังจริง พร้อมเงื่อนไขที่ทำให้มันพัง
ห้ามเสนอทางแก้ — หน้าที่ตอนนี้คือหาจุดอ่อนอย่างเดียว

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

มีอีกสองเรื่องที่ต้องตัดสินให้เป็นระบบ ไม่ใช่ทำตามอารมณ์: หนึ่ง ไม่ใช่ทุกงานต้องผ่านขั้นนี้ — งานเล็กที่กลับตัวง่าย ข้ามได้ แต่งานที่แตะ infra, ความปลอดภัย, หรือเงินจริง ห้ามข้าม สอง ทุกครั้งที่ผ่านขั้นนี้ควรบันทึกไว้ว่า critique เจออะไรและตัดสินใจอย่างไร เพื่อให้ย้อนตรวจได้ทีหลัง เหมือน control ที่มีร่องรอย ไม่ใช่พิธีกรรมลอย ๆ การบังคับให้ขั้นตอนสำคัญ "ลืมไม่ได้" แบบนี้เข้ากันดีกับการวางritual และ hooks ต้น/ท้าย session ที่ใช้กลไกระดับ harness บังคับ ไม่ใช่หวังว่าจะจำเอง

เส้นที่ห้ามข้าม: งานที่กลับตัวยาก — แก้ infra, ลบข้อมูล, อะไรที่แตะเงินหรือความปลอดภัย — ต้องผ่าน adversarial critique ก่อนเสมอ ส่วนงานเล็กที่ผิดแล้วแก้ทันข้ามได้ การรู้ว่าเมื่อไหร่ "ต้องตรวจเข้ม" กับ "ปล่อยได้" คือทักษะ ไม่ใช่กฎตายตัว

5. อย่าให้การวิจารณ์กลายเป็นพิธีกรรม

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

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

ขอย้ำให้ชัด: เป้าหมายของ adversarial self-critique ไม่ใช่ทำให้ทุกอย่างช้าลง แต่คือกล้าลงมือเร็วขึ้นในงานที่ตรวจแล้ว และตั้งการ์ดให้ทันในงานที่กลับตัวยาก — เหมือน control ที่ดี มันไม่ได้ห้ามคุณทำ แต่บอกให้รู้ว่ากำลังเสี่ยงตรงไหน

ภาพรวม

Adversarial self-critique คือการนำหลัก model validation มาใช้กับวิธีทำงานกับ AI ในชีวิตประจำวัน — แยก "ผู้สร้างแผน" ออกจาก "ผู้โจมตีแผน", แยกจังหวะ "หาจุดพัง" ออกจาก "ซ่อม", และบันทึกผลไว้ให้ตรวจย้อนได้ ไม่ใช่ทุกงานต้องผ่านขั้นนี้ แต่งานที่กลับตัวยากห้ามข้าม ใครที่อยากเข้าใจว่าทำไมการเขียนกฎไว้เฉย ๆ ถึงไม่พอ ลองอ่านทำไม CLAUDE.md ไม่ใช่หลักประกัน ต่อได้

ส่วนของจริงที่ผมใช้ — ทั้งชุด system prompt สำหรับโหมดผู้ค้านแบบเต็ม เงื่อนไขว่างานแบบไหนข้ามขั้นนี้ได้บ้าง และสคีมาไฟล์ log ที่ผมใช้เก็บผลทุกรอบให้ย้อนตรวจได้ — ผมรวบไว้ให้ก็อปไปปรับใช้กับ workspace ของคุณได้เลยในคอร์ส Claude Code