เปิด auto mode ใน Claude Code แล้วใครเป็นคนเบรก
เมื่อ permission prompt ใน Claude Code จบด้วยการกดอนุมัติถึง 97% ตามงานวิจัยภายในของ Anthropic auto mode จึงย้ายหน้าที่อนุมัติไปให้ classifier อีกตัว ส่วน dev ต้องย้ายไปกำหนดล่วงหน้าว่าจะปล่อยให้ระบบทำอะไรได้บ้าง

ก่อน Claude Code จะรันคำสั่ง ดึงข้อมูลจากเว็บ หรือแก้ไฟล์ ระบบจะหยุดถามทุกครั้ง คนใช้ต้องกดอนุมัติหรือปฏิเสธ งานจึงเดินต่อ กลไกนี้ทำให้คนใช้คุมทุกอย่างได้เต็มที่ แต่เมื่องานหนึ่งมีหลายสิบขั้น การต้องกดทีละ prompt ก็ทำให้ล้า งานวิจัยภายในของ Anthropic พบว่า 97% ของ permission prompt ใน Claude Code จบด้วยการกดอนุมัติ
เมื่อแทบทุก prompt ได้คำตอบเหมือนกัน มันก็ไม่ใช่จุดที่คนใช้ได้ตัดสินใจจริงๆ อีกต่อไป แต่กลายเป็นจังหวะสะดุดที่คนใช้กดผ่านโดยอัตโนมัติ Anthropic ทำ auto mode ขึ้นมาเพื่อตัดจังหวะนี้ออก คำถามจึงอยู่ที่ว่าอำนาจเบรกย้ายไปอยู่กับใคร
ตัวตัดสินที่ไม่ใช่ Claude

ทางลัดที่ง่ายที่สุดคือให้ Claude อนุมัติ action ของตัวเอง แต่ Anthropic ไม่เลือกทางนี้ตั้งแต่ต้น เพราะถ้าโมเดลตัวเดียวกันเป็นทั้งคนลงมือและคนตรวจ ทั้งสองบทบาทก็ย่อมมีความลำเอียงจากโค้ดชุดเดียวกันติดมาด้วย
Anthropic แยก classifier อีกตัวมารับทุก action ที่ Claude เสนอ แล้วตัดสินว่าจะอนุมัติหรือปฏิเสธ ความน่าเชื่อถือของกลไกนี้ขึ้นอยู่กับขอบเขตข้อมูลที่ classifier เห็น มันเห็นเพียงข้อความที่ผู้ใช้พิมพ์กับ tool call ที่ Claude กำลังจะเรียก แต่ไม่เห็นกระบวนการคิดของ Claude คำตอบที่ Claude เขียนกลับมา หรือ output จาก tool ข้อมูลสามส่วนนี้จึงใช้กล่อม classifier ไม่ได้ เกณฑ์ตัดสินมีข้อเดียวคือ action นั้นตรงกับคำสั่งของผู้ใช้หรือไม่ ถ้าตรงก็อนุมัติ
classifier จะจับตาเป็นพิเศษเมื่อ Claude ทำเกินเจตนาของผู้ใช้ไปแตะสิ่งที่กู้คืนไม่ได้ ตัวอย่างจาก Anthropic คือผู้ใช้สั่งให้เก็บกวาดเฉพาะ branch ในเครื่อง แต่ Claude กลับลบ remote branch ตามไปด้วย
เมื่อ classifier ปฏิเสธ Claude มักลองหาทางที่ปลอดภัยกว่าเพื่อเดินหน้าต่อเองก่อน เช่น ถ้า force push เข้า main ไม่ผ่าน ก็เปลี่ยนไป push ขึ้น branch ใหม่แทน แต่ถ้ายังถูกปฏิเสธซ้ำ auto mode จะหยุดและส่งกลับมาให้คนอนุมัติเอง สิ่งที่เห็นบนจอจึงมีทั้งการเปลี่ยนทางกับการหยุดรอ และ classifier คือคนสั่งให้เกิดพฤติกรรมทั้งสองแบบ
ไม่ใช่ทุก action ที่เดินไปถึงตัวตัดสิน
action ที่ Claude เสนอไม่ได้เดินตรงไปหา classifier ทุกครั้ง เพราะยังมีด่านก่อนหน้า กฎ deny กับ ask จะทำงานก่อน จากนั้นระบบจึงเช็ค tier ว่า action นั้นอยู่ในระดับที่ต้องให้ classifier ตัดสินหรือไม่
Anthropic บอกว่างานส่วนใหญ่ของ Claude เป็นงานที่แค่อ่านข้อมูลหรือย้อนกลับได้ เช่น ค้นในโค้ดเบสหรือแก้ไฟล์ในโปรเจกต์ action กลุ่มนี้จึงไม่ต้องผ่าน classifier ส่วน action ที่ต้องส่งให้ตัดสินคือกลุ่มที่เสี่ยงกว่า ได้แก่ shell command การดึงข้อมูลจากเว็บ และทุกอย่างที่ออกไปนอกสภาพแวดล้อมของผู้ใช้
คำว่านอกสภาพแวดล้อมกินความกว้างกว่าที่ชื่อบอก ค่าเริ่มต้นถือว่าเฉพาะ working directory ของผู้ใช้กับ git remote ของมันเป็นของภายใน นอกนั้นเป็นภายนอกทั้งหมด แม้แต่ infrastructure ของบริษัทเอง จนกว่าจะตั้งค่าไว้เป็นอย่างอื่น หลังเปิด auto mode จุดที่มักติดขัดก่อนจึงเป็นขอบเขตนี้ ไม่ใช่งานที่ทำอยู่ในโปรเจกต์
ด่านที่สองสำหรับสิ่งที่ Claude อ่านเข้ามา
เว็บเพจหรือไฟล์ที่ Claude อ่านระหว่างทำงานอาจซ่อนคำสั่งที่พยายามพา Claude ออกนอกเจตนาเดิมของผู้ใช้ ภัยแบบนี้คือ prompt injection นี่จึงเป็นเหตุผลว่าทำไมการมี classifier คอยตัดสินอย่างเดียวถึงยังไม่พอ
ก่อนเนื้อหาภายนอกจะเข้า context probe ฝั่งเซิร์ฟเวอร์จะสแกน tool result ทุกชิ้นเพื่อหาคำสั่งประสงค์ร้าย หากพบก็จะแปะคำเตือนให้ Claude ระวังเนื้อหานั้น จากนั้น classifier ยังเช็คอีกชั้นว่า action ถัดไปตรงกับคำสั่งของผู้ใช้อยู่หรือไม่ การโจมตีต้องผ่านทั้งสองด่าน จึงจะพา Claude ไปทำสิ่งที่เจ้าของเครื่องไม่ได้สั่งได้
Anthropic บอกว่าได้ทดสอบด้วยการยิง prompt injection ใส่ Claude Code และเมื่อเปิดทั้ง probe กับ auto mode อัตราการโจมตีสำเร็จใน eval ของพวกเขาลดลงเหลือ 0%
สี่ช่องเป็นคำแนะนำ ส่วนสองกฎบังคับใช้ได้จริง

เมื่อจุดตัดสินใจย้ายจากปุ่มอนุมัติไปอยู่ใน config คนใช้ก็ต้องหันมากำหนดให้ชัดว่าจะปล่อยให้ระบบทำอะไรได้บ้าง โดยเริ่มจากนิยามสภาพแวดล้อม ผู้ดูแลระบบตั้งค่านี้ผ่าน managed settings แล้วค่านั้นจะมีผลกับ developer ทุกคนในองค์กร คุณเพิ่มรายการของตัวเองใน user settings ได้ แต่เอาสิ่งที่ admin ตั้งไว้ออกไม่ได้
ในช่อง environment ให้เขียนเป็นภาษาอังกฤษทั่วไปว่า infrastructure ของคุณมีอะไรบ้าง เช่น GitHub org ของทีม bucket บนคลาวด์ หรือ internal service ที่ใช้อยู่ แต่เมื่อกรอกช่องนี้ รายการที่ Claude ให้มาแต่เดิมจะถูกแทนที่ ถ้ายังอยากเก็บรายการเดิมไว้ คุณต้องใส่ default string กลับเข้าไปเอง
ถ้าอยากกำหนดขอบเขตให้ละเอียดขึ้น ยังมีอีกสามช่อง
| ช่อง | สิ่งที่มันบอก classifier |
|---|---|
allow | ข้อยกเว้นที่ยอมให้ทำได้ |
soft deny | ห้าม เว้นแต่ผู้ใช้สั่งมาชัดเจน |
hard deny | ห้าม ต่อให้ผู้ใช้สั่งมาก็ตาม |
environment กับอีกสามช่องนี้รวมเป็นสี่ช่อง ทั้งหมดเป็นเพียงข้อมูลประกอบที่ classifier ใช้ชั่งน้ำหนักตอนตัดสิน ไม่ใช่กฎที่บังคับใช้ได้เอง แม้ชื่อ hard deny จะฟังดูเด็ดขาดก็ตาม
ส่วนกฎที่บังคับใช้ได้จริงอยู่คนละที่ กฎ deny จะบล็อก tool call ที่ตรงเงื่อนไขทันที ขณะที่กฎ ask บังคับให้ระบบเปิด prompt ถามคน แม้จะอยู่ใน auto mode ก็ตาม กฎ allow ก็มีให้ใช้ แต่ถ้ากว้างพอที่จะเปิดทางให้รัน arbitrary code ระบบก็ยังส่ง action นั้นเข้า classifier อยู่ดี
ปล่อยให้มันตัดสินใจเองได้แค่ไหน
Anthropic แนะนำให้เริ่มด้วยขอบเขตแคบๆ แล้วคอยดูว่า action ไหนถูกปฏิเสธบ้าง จากนั้นค่อยขยายออก ส่วนงานเสี่ยงสูง เช่น การเปลี่ยนแปลง production infrastructure พวกเขาแนะนำให้ผู้ใช้คอยอ่าน action ของ Claude เอง หรือทำ eval ขึ้นมาเพื่อให้มั่นใจ
ถ้ายังไม่มี eval ของตัวเอง การทำรายการกฎ ask สำหรับ operation ที่พลาดไม่ได้จะคุ้มแรงที่สุด เพราะนี่เป็นช่องทางเดียวที่ดึงคนกลับมาตัดสินใจได้แน่นอน แม้จะเปิด auto mode อยู่
ที่มา: คลิป How auto mode works with Claude Code
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
NotebookLM ฉบับเข้าใจง่าย โยนเอกสารให้ AI อ่าน แล้วได้สรุป พอดแคสต์ และคลังความรู้ส่วนตัว
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
Claude Cowork · The Business Playbook

ฉบับภาษาไทย 15 บท เรียนรู้ผ่านโปรเจกต์จำลองต่อเนื่องทั้งเล่ม ตั้งแต่ตั้งค่า Workspace จัดการไฟล์ เชื่อมแอป ตั้งระบบอัตโนมัติ จนถึงสร้าง Plugin


