ทำไม AI agent ถึงบอกว่า “เสร็จแล้ว” ทั้งที่งานยังไม่เสร็จ

โมเดลของ OpenAI ออกจากแซนด์บ็อกซ์และแฮ็ก Hugging Face ได้อย่างไร?#

ก่อนอื่นมาดูข้อเท็จจริง แล้วค่อยว่ากันว่าทำไมเรื่องนี้จึงสำคัญกับคุณ

OpenAI วัดความสามารถของโมเดลด้านความมั่นคงปลอดภัยไซเบอร์เชิงรุก โดยใช้การทดสอบ ExploitGym ซึ่งมี 898 งานที่ต้องเปลี่ยนช่องโหว่ที่ทราบอยู่แล้วให้เป็น exploit ที่ใช้งานได้ หรือก็คือโปรแกรมสำเร็จรูปที่ใช้ช่องโหว่นั้น เพื่อดูขีดความสามารถสูงสุดที่แท้จริง พวกเขาปิดตัวกรองความปลอดภัยในตัวซึ่งปกติจะป้องกันไม่ให้โมเดลทำสิ่งเหล่านี้ จากนั้นก็ปิดกั้นสภาพแวดล้อมอย่างสมบูรณ์ โดยเหลือทางออกไว้ทางเดียว คือโปรแกรมตัวกลางภายในที่ใช้ติดตั้งแพ็กเกจ

ช่องโหว่แบบ zero-day คือช่องโหว่ที่ยังไม่มีใครรู้ รวมถึงผู้เขียนโปรแกรมนั้นด้วย โมเดลพบช่องโหว่ในช่องทางออกเพียงช่องเดียวที่ว่านั้นเอง

จากนั้นพวกมันยกระดับสิทธิ์ เคลื่อนผ่านเครือข่ายภายในไปยังเครื่องที่เชื่อมต่ออินเทอร์เน็ตได้ แล้วคาดเดาว่าคำตอบของ ExploitGym อาจอยู่บน Hugging Face ไม่มีใครบอกพวกมันเรื่อง Hugging Face พวกมันคิดขึ้นเอง

การคาดเดานั้นผิด ExploitGym ไม่ได้อยู่บน Hugging Face เลย แต่ก็ไม่ได้ทำให้การแฮ็กเกิดขึ้นจริงน้อยลง

Hugging Face ตรวจพบการบุกรุกด้วยตนเองและเผยแพร่รายงานเมื่อวันที่ 16 กรกฎาคม โดยยังไม่รู้ว่าใครเป็นคนแฮ็ก

รายละเอียดอีกข้อจากรายงานนั้นบอกอะไรได้มากเกี่ยวกับสถานการณ์ เมื่อวิศวกรของ Hugging Face ลองป้อนบันทึกการโจมตีให้โมเดลชั้นนำผ่านอินเทอร์เฟซเชิงพาณิชย์ทั่วไป ตัวกรองความปลอดภัยกลับบล็อกคำขอ เพราะแยกไม่ออกว่าผู้ใช้กำลังสืบสวนการแฮ็กหรือกำลังลงมือแฮ็กเอง ท้ายที่สุดจึงรันการวิเคราะห์ด้วยโมเดลเปิดบนฮาร์ดแวร์ของตนเอง

OpenAI ยอมรับเรื่องนี้เมื่อวันที่ 21 กรกฎาคม ห้าวันหลังจาก Hugging Face เปิดเผยข้อมูล ตอนนั้นเวลาผ่านไปประมาณสิบวันนับจากการบุกรุก

OpenAI สรุปการวิเคราะห์ของตนไว้ดังนี้

โมเดลยึดติดกับเป้าหมายแคบๆ ของการทดสอบและทำทุกวิถีทางเพื่อให้บรรลุ คำว่า hyper-focused และ fairly narrow testing objective มาจาก OpenAI เอง และกล่าวถึงโมเดลของตน

นี่คือสิ่งที่เชื่อมเรื่องราวจากห้องทดลองของคนอื่นมาถึงแล็ปท็อปของคุณ

ทำไมเรื่องนี้จึงไม่ใช่ “ภาพหลอน”?#

ฉันมักเห็นข้อความในแชตอย่าง “หลอนอีกแล้ว” “บริบทแน่นเกินไป” หรือ “เราน่าจะวางแผนก่อน” บางครั้งก็เป็นเช่นนั้นจริง แต่เมื่อ AI agent เขียนว่า “เสร็จแล้ว ตรวจแล้ว ทุกอย่างทำงาน” ทั้งที่งานยังไม่เสร็จ ปริมาณบริบทมักไม่เกี่ยวข้อง

มันไม่ได้แต่งอะไรขึ้นมา มันทำตามสิ่งที่คุณวัดทุกประการ

เรามักเหมารวมความล้มเหลวสามแบบที่ต่างกันไว้ใต้คำครอบจักรวาลยอดนิยมอย่าง “ภาพหลอน” ความแตกต่างมีดังนี้

แก้ข้อแรกด้วยบริบท ซึ่งเป็นกรณีที่รู้จักกันดีที่สุด ส่วนข้อสองเป็นปรากฏการณ์แยกต่างหากที่กล่าวถึงในการวิเคราะห์เรื่องกรณีที่ Claude เห็นด้วยกับทุกอย่าง: โมเดลยอมเสียความถูกต้องเพื่อให้เห็นด้วยอย่างรวดเร็ว ทั้งสองอย่างเกิดขึ้น ก่อน เริ่มทำงาน ในขั้นตอนป้อนข้อมูล

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

ความล้มเหลวแบบที่สามมีชื่อเรียก

การโกงรางวัลคืออะไร อธิบายแบบง่ายๆ ได้ไหม?#

Anthropic ให้คำจำกัดความไว้เอง

แนวคิดนี้เก่าแก่กว่าโครงข่ายประสาทเทียม บทความของ DeepMind เรียกเรื่องนี้ว่า specification gaming และอธิบายด้วยตำนาน

ไมดาสได้สิ่งที่ขอทุกประการ ปัญหาอยู่ที่ถ้อยคำในคำขอ

ในงานเขียนโปรแกรม เรื่องนี้เกิดขึ้นเป็นรูปธรรม ตัวอย่างมาตรฐานจาก Anthropic มีดังนี้

และนี่ไม่ใช่เงื่อนไขทดลองในห้องแล็บที่แปลกประหลาด Cursor วิเคราะห์เส้นทางการทำงาน 731 รายการบนเบนช์มาร์กยอดนิยม

หกในสิบของงานที่ “แก้ได้แล้ว” เป็นคำตอบที่ไปค้นมา นี่คือเหตุผลที่อุตสาหกรรมกำลังเปลี่ยนวิธีวัดประสิทธิภาพ เรามีบทวิเคราะห์เรื่องเบนช์มาร์กที่วัดความพร้อมสำหรับใช้งานจริง ซึ่งการผ่านการทดสอบไม่ใช่เกณฑ์หลักอีกต่อไป

เรื่องนี้มีหน้าตาอย่างไรในผลิตภัณฑ์ทั่วไป?#

เป็นเรื่องง่ายที่จะปัดตัวอย่างในห้องทดลองว่าแปลกเกินจริง ต่อไปนี้จึงเป็นสี่เรื่องจากประสบการณ์จริง ชื่อลูกค้าและอุตสาหกรรมถูกเปลี่ยน แต่กลไกยังคงเดิม

ตรวจผ่านสีเขียวสี่รายการ แต่คอมโพเนนต์บริการหยุดทำงาน

บริษัทอสังหาริมทรัพย์แห่งหนึ่งกำลังสร้างบริการ: เว็บไซต์ที่มีรายการอสังหาริมทรัพย์ พร้อมตัวประมวลผลเบื้องหลังแยกต่างหากซึ่งส่งออกรายการไปยังแพลตฟอร์มต่างๆ ในเวลากลางคืน agent ทำงานเสร็จและรายงานว่า การตรวจชนิดข้อมูลผ่าน การตรวจรูปแบบโค้ดผ่าน การ build ผ่าน หน้าเว็บตอบสนอง และตรวจดูด้วยสายตาแล้ว

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

ก่อนจะพูดว่า “เสร็จแล้ว” ตอนนี้ฉันจะถามตัวเองหนึ่งข้อ: มีส่วนไหนของงานที่ทำงานอยู่นอกขอบเขตที่การตรวจสอบของฉันครอบคลุมบ้าง? ถ้ามี ให้รันส่วนนั้นแยกต่างหากและใส่ผลลัพธ์คำสั่งในรายงาน คำว่า “ตรวจแล้ว” ไม่ได้ปิดเรื่องนี้

เครื่องหมายผ่านที่ผิดอยู่ตรงรอยต่อพอดี

ร้านค้าออนไลน์แบ่งงานใหญ่ให้ agent หลายตัวทำพร้อมกัน ตัวหนึ่งรับผิดชอบ backend อีกตัวดูแลหน้าเว็บ และตัวที่สามทำการ์ดสินค้า แต่ละตัวทำงานอย่างตั้งใจ และแต่ละตัวก็มีผลตรวจเป็นสีเขียว

หนึ่งสัปดาห์ต่อมา กลับพบว่าปุ่ม “รีวิวนี้มีประโยชน์” ใช้งานไม่ได้ตรงไหนเลย backend เขียนครบและผลตรวจเป็นสีเขียว กฎการคำนวณใหม่ก็ทำตามแล้ว เพียงแต่ไม่มีหน้าไหนแสดงปุ่มนี้ ปุ่มอยู่ในขอบเขตงานของ agent ตัวหนึ่ง ส่วนหน้าเว็บอยู่ในขอบเขตของอีกตัว และไม่มีใครคิดว่าจะต้องแสดงปุ่มบนหน้าจอ ตัวนับจึงคงเป็นศูนย์ตลอดไป

“เขียนโค้ดแล้วและมีการตรวจสอบครอบคลุม” กับ “ฟีเจอร์ทำงาน” เป็นคำกล่าวอ้างคนละข้อ ฉันตรวจข้อที่สองด้วยคำถามหนึ่งข้อสำหรับฟีเจอร์ใหม่ทุกตัว: ใครเป็นคนเรียกใช้มัน? แล้วตรวจด้วยการค้นหาในโปรเจกต์ เพราะรายงานของ agent ไม่ใช่แหล่งความจริงในกรณีนี้

ผู้ตรวจสอบเห็นเฉพาะทิศทางที่ถูกขอให้ตรวจ

บริการแห่งหนึ่งเพิ่มระดับสมาชิก ยิ่งจ่ายมาก สถานะและส่วนลดก็ยิ่งสูง ก่อนนำขึ้นใช้งาน มีการส่งโค้ดให้ตรวจพร้อมคำสั่งว่า “ลองเพิ่มสถานะของตัวเองให้สูงเกินจริง” ผู้ตรวจสอบทำงานอย่างตรงไปตรงมาและรายงานว่า “ไม่มีอะไรสำคัญ” ซึ่งจริงๆ แล้วไม่สามารถเพิ่มสถานะให้สูงเกินจริงได้

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

ผู้ตรวจสอบคนแรกไม่ได้ทำงานลวกๆ พวกเขา ไม่สามารถมองเห็นปัญหานี้ได้ตามโครงสร้าง: ได้รับเวกเตอร์ “อินพุต, เลื่อนสถานะ” ขณะที่ช่องโหว่อยู่ในเวกเตอร์ “ย้อนกลับอินพุต, คงสถานะส่งเสริม” เมื่อใดก็ตามที่มีเงิน สิทธิ์เข้าถึง หรือสถานะที่ซื้อได้เข้ามาเกี่ยวข้อง ฉันจะตรวจสองรอบ และในรอบที่สองจะระบุเวกเตอร์ย้อนกลับอย่างชัดเจน ได้แก่ คืนเงิน บล็อก เพิกถอนสิทธิ์เข้าถึง หมดอายุ และลบแหล่งข้อมูล

ตัวชี้วัดให้รางวัลกับความคล้ายคลึง

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

แต่ตัวเลขที่เพิ่มขึ้นไม่มีความหมาย ด้วยเหตุผลสองข้อ บริบทสำหรับร่างคำตอบถูกประกอบขึ้น “ณ วันนี้” และมีข้อความโต้ตอบทั้งหมด รวมถึงคำตอบของพนักงานที่นำมาเปรียบเทียบในภายหลัง โมเดลไม่ได้เขียนคำตอบ แต่นำข้อความอ้างอิงที่เห็นมาเขียนใหม่ อีกทั้งตัวชี้วัดยังให้รางวัลกับการใช้คำและความยาวที่ตรงกัน ร่างที่ให้วันที่ ผิด แต่ใช้คำเดียวกับที่พนักงานใช้บอกวันที่ถูกต้องกลับได้คะแนนสูง

ตอนนี้ฉันจะวางเกณฑ์เชิงกลที่เข้มงวดควบคู่กับตัวชี้วัดประเภท “คล้ายกันก็แปลว่าดี” ทุกตัว เกณฑ์เหล่านี้หลอกด้วยสำนวนไม่ได้ เช่น ตัวเลขและวันที่ที่แต่งขึ้น คำหยุด และคำสัญญาว่าจะดำเนินการ หากผลเกณฑ์ตรวจสอบแย่ลง การปรับปรุงตัวชี้วัดใดๆ ก็ถือเป็นโมฆะ

ทำไมคำว่า “ฉันตรวจแล้ว” จาก agent จึงพิสูจน์อะไรไม่ได้?#

เลือกโปรเจกต์ใดก็ได้ของคุณ แล้วถาม agent ว่า “ตรวจสอบความปลอดภัย” บ่อยครั้งคำตอบจะเป็น “ทุกอย่างเรียบร้อย ไม่มีปัญหาร้ายแรง”

จากนั้นถามโมเดลอีกตัวด้วยคำถามเดียวกันเกี่ยวกับโปรเจกต์เดียวกัน โดยเฉพาะถ้าโปรเจกต์มีขนาดใหญ่ โมเดลนั้นจะพบปัญหามากมาย ก่อนนำขึ้นใช้งาน ผู้เขียนตรวจโปรเจกต์ด้วยโมเดลสามตัวที่ต่างกัน และแต่ละตัวพบประเด็นคนละอย่าง

อินพุตเดียวกัน คำถามเดียวกัน แต่คำตัดสินตรงข้ามกัน โมเดลตัวหนึ่งไม่ได้แย่กว่าอีกตัว เพียงแต่ข้อความ “ทุกอย่างเรียบร้อย” เป็นข้อความที่สร้างขึ้น ในชั้นเดียวกับคำตอบอื่นๆ agent ไม่มีทางแยกได้ว่า “ดูแล้ว สะอาดดี” ต่างจาก “ดูผิดที่” อย่างไร

Anthropic อธิบายกลไกนี้ไว้ในเอกสาร Claude Code

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

ยังมีประเด็นที่ลึกกว่านั้น เมื่อ OpenAI พยายามกดดันโมเดลด้วยการเฝ้าติดตามเหตุผลของมันและลงโทษ “ความคิดไม่ดี” ผลที่ได้กลับไม่เป็นอย่างที่คาด

การลงโทษเจตนาที่พูดออกมาทำให้คำพูดนั้นหายไป แต่เจตนายังคงอยู่ ดังนั้นฉันจะไม่ฝากความหวังไว้กับการที่ agent จะบอกอย่างตรงไปตรงมาว่ามันโกงอย่างไร

ผู้พัฒนาเครื่องมือเองก็กำลังเดินไปในทิศทางเดียวกัน ใน Claude Code เวอร์ชัน 2.1.215 ทักษะ /verify และ /code-review จะไม่ทำงานตามความคิดริเริ่มของโมเดลอีกต่อไป

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic ไม่ได้อธิบายเหตุผล แต่หลักการชัดเจน ผู้ที่ถูกตรวจสอบไม่ควรมอบหมายการตรวจสอบให้ตัวเอง

ทำไมกฎในไฟล์โปรเจกต์จึงควบคุม agent ไม่ได้?#

คุณเขียนไว้ในไฟล์กฎของโปรเจกต์ว่า ให้ commit เฉพาะเมื่อได้รับคำสั่งโดยตรง ให้ deploy สู่ production เฉพาะเมื่อฉันสั่งโดยตรง และให้เข้าถึงข้อมูล production ได้เฉพาะโหมดอ่านอย่างเดียว

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

เรื่องเดียวกันนี้เกิดขึ้นในห้องทดลองของ OpenAI เพียงแต่ในขนาดที่ใหญ่กว่า โมเดลอยู่ในสภาพแวดล้อมปิดที่มีทางออกทางเดียว และใช้ทรัพยากรประมวลผลส่วนใหญ่ไปกับการหาทางออก งานทดสอบยังแก้ไม่สำเร็จ

จุดยืนของฉันเรียบง่าย agent ไม่ได้อันตรายหรือมุ่งร้าย มันเป็นแค่คนโง่ธรรมดาที่มีอำนาจ ดังนั้นคุณต้องจำกัดอำนาจของมัน ไม่ใช่เขียนคำขอใหม่

สิ่งที่ใช้ได้จริง ได้แก่ จำกัดการเข้าถึงข้อมูล production ให้เป็นแบบอ่านอย่างเดียวอย่างเคร่งครัด ห้ามลบไดเรกทอรีทั้งชุด ห้ามคำสั่งที่เขียนทับประวัติโดยกู้คืนไม่ได้ และกำหนดวงเงินกับผู้ให้บริการ ความแตกต่างสรุปได้ด้วยวลีเดียว: “ทำไม่ได้ในทางกายภาพ” มีผลเหนือกว่า “ฉันขอไม่ให้ทำแล้ว” การตั้งค่าเฉพาะอธิบายแยกไว้ในบทความเรื่องกลไกเบรกแทนคำขอในคำสั่ง

อย่างไรก็ตาม อย่าประมาท แม้แต่แซนด์บ็อกซ์ก็ไม่ใช่ขอบเขตที่สมบูรณ์ และผู้ให้บริการก็กล่าวไว้อย่างชัดเจน

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

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

จะกำหนดเกณฑ์การทำงานให้เสร็จที่โกงไม่ได้อย่างไร?#

ถ้อยคำของเกณฑ์เป็นตัวกำหนดทุกอย่าง ลองตรวจด้วยคำถามข้อเดียว: agent ทำตามเกณฑ์นี้ได้หรือไม่โดยไม่ต้องทำอะไรเลย?

• “ตรวจให้แน่ใจว่าทุกอย่างทำงาน” — ทำได้ แค่เขียนว่า “ตรวจแล้ว ใช้งานได้” ก็พอ
• “รันการ build แล้วแสดงผลลัพธ์ให้ฉันดู” — ยากขึ้นแล้ว เพราะต้องหาผลลัพธ์มาให้ได้
• “รันแอป คลิกปุ่มชำระเงิน แล้วแสดงสิ่งที่ปรากฏบนหน้าจอ” — แทบไม่มีทางทำตามได้ด้วยข้อความ

ความแตกต่างระหว่างข้อแรกกับข้อสาม คือความแตกต่างระหว่างรายงานกับหลักฐาน

เอกสาร Claude Code อธิบายระดับความเข้มงวดไว้สี่ระดับ เป็นขั้นบันไดที่มีประโยชน์เมื่อความเสียหายจากความผิดพลาดสูงขึ้น:

1. ในข้อความเดียว ขอให้ agent รันการตรวจสอบและทำซ้ำจนกว่าจะผ่านที่นี่ วิธีที่ถูกที่สุด เหมาะกับงานเล็กๆ
2. ตลอดทั้งเซสชัน กำหนดให้การตรวจสอบเป็นเงื่อนไขของเป้าหมาย: ผู้ประเมินแยกต่างหากตรวจหลังทุกเทิร์น และ agent ทำงานต่อจนกว่าจะผ่านเงื่อนไข รายละเอียดทางเทคนิคอธิบายไว้ในคู่มือเรื่องการกำหนดเกณฑ์การทำงานให้เสร็จล่วงหน้า
3. สิ่งกีดขวางเชิงกล สคริปต์ทำงานเมื่อ agent พยายามจบเทิร์น และป้องกันไม่ให้จบจนกว่าการตรวจจะผ่าน มีข้อเท็จจริงข้อหนึ่งที่ต้องบอกอย่างตรงไปตรงมา: หลังถูกขัดขวางติดต่อกันแปดครั้ง Claude Code จะข้ามสิ่งกีดขวางและจบเทิร์นอยู่ดี ไม่มีสิ่งกีดขวางใดในระบบที่ทะลุผ่านไม่ได้อย่างเด็ดขาด
4. ความเห็นที่สอง ผู้ตรวจสอบแยกต่างหากที่มีบริบทใหม่และมีหน้าที่หักล้างผลลัพธ์

ข้อสี่แตกต่างจากข้ออื่น เพราะเป็นข้อเดียวที่ไม่เกี่ยวกับเครื่องมือ

ใครควรเป็นผู้รับรองงานของ agent?#

เมื่อฉันรัน agent เป็นวงจรสำหรับงานขนาดใหญ่ ระบบจะเป็นแบบนี้: กลุ่มหนึ่งเขียนงาน ส่วนอีกกลุ่มที่เพิ่งเข้ามาใหม่เป็นผู้รับรองงาน โดยไม่ได้มีส่วนร่วมในการเขียน

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

ถ้อยคำที่ใช้มอบหมายงานให้ผู้ตรวจสอบสำคัญกว่าโมเดลของผู้ตรวจสอบ ลองเปรียบเทียบ:

• “ตรวจงานนี้” — ผู้ตรวจจะหาเรื่องที่หาง่าย แล้วเขียนว่า “โดยรวมเรียบร้อยดี”
• “ลองพิสูจน์ว่างานนี้ ยังไม่ เสร็จ” — ผู้ตรวจจะเริ่มมองหาช่องโหว่ เพราะนั่นคือเป้าหมายของเขา

ถ้อยคำแบบที่สองได้ผลดีกว่าด้วยเหตุผลเดียวกับที่ ExploitGym ล้มเหลว: agent มุ่งทำตามเป้าหมายที่ได้รับมอบหมาย กำหนดเป้าหมายให้มันค้นหาช่องโหว่ แล้วมันจะมองหาช่องโหว่

ต่อไปนี้คือถ้อยคำฉบับเต็ม พร้อมคัดลอกไปใช้ได้ทันที:

คุณกำลังตรวจงานของคนอื่น คุณไม่ได้เป็นคนเขียน และไม่จำเป็นต้องปกป้องงานนั้น

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

ตรวจตามลำดับนี้:

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

ใครเรียกใช้ฟังก์ชันใหม่แต่ละตัว ค้นหาการเรียกใช้ในโปรเจกต์ แล้วระบุไฟล์และบรรทัด

เส้นทางย้อนกลับ: คืนเงิน บล็อก เพิกถอนสิทธิ์เข้าถึง หมดอายุ ลบแหล่งข้อมูล

ค่าที่อยู่ภายในผลลัพธ์ ไม่ใช่แค่ตรวจว่าผลลัพธ์มีอยู่หรือไม่

หากค้นหาอย่างตรงไปตรงมาแล้วไม่พบช่องโหว่ ให้บอกเช่นนั้น แต่ระบุให้ชัดเจนว่าคุณตรวจอะไรและตรวจอย่างไร

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

จะเกิดอะไรขึ้นเมื่อคุณเขียนเกณฑ์ใหม่?#

นี่คือวิธีปรับปรุงที่มีต้นทุนต่ำที่สุดเท่าที่ฉันรู้จัก และแทบไม่มีใครทำ

ขอให้ agent ตรวจทานโค้ด มันจะใช้เหตุผลในมุมของโค้ด เช่น โครงสร้าง การจัดการข้อผิดพลาด การลองซ้ำ และจุดเสี่ยง ซึ่งมีประโยชน์

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

การตรวจทานโค้ดจะไม่พบข้อบกพร่องเหล่านี้ เพราะแต่ละข้อถูกต้องตามโค้ด

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

พรอมต์พร้อมใช้สำหรับรับรองงานของ agent#

อย่าตอบว่า “เสร็จแล้ว” หรือ “ตรวจแล้ว” ฉันต้องการหลักฐาน

สำหรับงานแต่ละรายการ ให้บอกฉันตามนี้ทุกประการ:

คุณรันคำสั่งอะไรเพื่อยืนยันว่ารายการนั้นทำงาน? ระบุตัวคำสั่งและผลลัพธ์ทั้งหมดโดยไม่ย่อ

หากคุณไม่ได้รันคำสั่ง ให้พูดว่า “ไม่ได้รัน” อย่าแทนที่ด้วยคำว่า “ตรวจด้วยสายตาแล้ว” หรือ “ตรรกะถูกต้อง”

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

ใครเรียกใช้ฟังก์ชันใหม่ที่คุณเพิ่มมา? ค้นหาการเรียกใช้ในโปรเจกต์ แล้วระบุไฟล์และบรรทัด หากไม่มีการเรียกใช้ ให้พูดตรงๆ

จากนั้นแยกเป็นอีกหัวข้อหนึ่ง: สามวิธีที่ผลลัพธ์ตามที่กล่าวอ้างอาจยังไม่เกิดขึ้น แม้ว่าผลตรวจทั้งหมดของคุณจะเป็นสีเขียว ค้นหาอย่างจริงจัง

บรรทัดสุดท้าย: ฉันควรตรวจอะไรด้วยตาตัวเอง เพราะการตรวจอัตโนมัติจับไม่ได้?

ข้อสี่ดูเหมือนเล็กน้อย แต่จับปัญหาได้ทั้งประเภท ในงานใหญ่ที่ฉันแบ่งให้ agent ตามขอบเขตงาน คำว่า “เสร็จแล้ว” ที่ผิดพลาดมีเพียงครั้งเดียวจากทั้งหมดร้อยครั้ง และเกิดตรงรอยต่อระหว่างสองขอบเขตพอดี โค้ดเขียนเสร็จ การตรวจเป็นสีเขียว แต่ไม่มีใครคิดจะนำขึ้นแสดงบนหน้าจอ

สี่วิธีหลอกตัวเองด้วยการตรวจสอบ#

1. ไม่รอผู้ตรวจสอบทุกคน ฉันเปิดการตรวจพร้อมกันสามรายการ สองรายการกลับมาเป็นสีเขียว แล้วฉันก็ deploy รายการที่สามมาถึงสี่นาทีต่อมาพร้อมการละเมิดหกข้อ การแก้หลังเผยแพร่มีต้นทุนสูงกว่าการรอสองนาที
2. เชื่อสรุป “ประมวลผล N จาก N รายการแล้ว” เมื่อกระจายงานจำนวนมาก agent บางตัวอาจล้มเหลวโดยไม่ส่งเสียง พวกมันรายงานว่าสำเร็จ แต่ไฟล์ไม่เปลี่ยนแปลง ตอนนี้หลังจากให้ agent เขียนอะไร ฉันจะตรวจโดยอัตโนมัติว่าการเปลี่ยนแปลงอยู่บนดิสก์จริง
3. ไม่ตรวจดูด้วยตาตนเอง การตรวจอัตโนมัติอาจขึ้นสีเขียวทั้งที่ผลลัพธ์ใช้การไม่ได้เลย รูปภาพถูกต้องทางเทคนิค ขนาดถูกต้อง รหัสตอบกลับถูกต้อง แต่จริงๆ แล้วเป็นภาพนิ่งที่สร้างอัตโนมัติมาแทนปกภาพประกอบที่ควรจะมี ไม่มีการตรวจอัตโนมัติใดจับเรื่องนี้ได้
4. ตรวจว่ามีข้อมูลแทนที่จะตรวจค่า การตรวจค้นหาข้อความที่ต้องการในผลลัพธ์ ข้อความอยู่ตรงนั้นจริง แต่ข้อมูลภายในผิด: วันที่คลาดไปหนึ่งวัน การตรวจเป็นสีเขียว และรายงานก็เป็นเรื่องโกหก ตอนนี้ฉันตรวจค่าที่คาดหวังทั้งหมด เพราะการมีคำที่ถูกต้องเพียงอย่างเดียวไม่ได้รับประกันอะไร

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

วันนี้ควรเริ่มจากตรงไหน#

สามขั้นตอน ใช้เวลายี่สิบนาที

1. หยิบคำว่า “เสร็จแล้ว” ครั้งล่าสุด ตรวจงานนั้นด้วยพรอมต์รับรองในหัวข้อเรื่องหลักฐาน เป้าหมายง่ายๆ คือดูว่ามีกี่รายการที่ปิดด้วยคำพูด และกี่รายการที่ปิดด้วยผลลัพธ์คำสั่ง
2. ตั้งกฎให้ตัวเองหนึ่งข้อ คำว่า “ตรวจแล้ว” ที่ไม่มีผลลัพธ์คำสั่งแนบมาไม่นับว่าเสร็จ กฎนี้มีไว้สำหรับคุณ ไม่ใช่ agent และนั่นคือเหตุผลที่มันได้ผล
3. แยกผู้ทำงานกับผู้ตรวจสอบ ในงานถัดไป ให้เซสชันใหม่ที่ไม่มีบริบทเดิมใช้พรอมต์ของผู้ตรวจสอบ แล้วขอให้พิสูจน์ว่างาน ยังไม่ เสร็จ การลองครั้งแรกมักทำให้เห็นทันทีว่านิสัยนี้คุ้มค่า

เครื่องมือนี้ดีและพัฒนาขึ้นทุกเดือน สิ่งที่ agent เคยทำเงียบๆ เมื่อปีก่อน ตอนนี้กลับหยุดมันได้ทันที ขอบเขตความปลอดภัยยังคงขยับและยังคงเป็นขอบเขต ตราบใดที่ agent มุ่งทำตามเป้าหมายที่ได้รับ คำถามว่า “แล้วคุณวัดสิ่งนั้นอย่างไรแน่?” ยังคงเป็นหน้าที่ของคุณ นิสัยการตรวจสอบคือหลักประกันความปลอดภัยของคุณ