Claude วางแผน worker เขียนโค้ด แล้ว Claude ตรวจทุกบรรทัด

ระบบนี้ให้ Claude เป็นหัวหน้างาน รับงานจากผู้ใช้ เขียนคำสั่งงานแบบละเอียด ส่งให้โมเดลภายนอกทำใน branch แยก แล้วตรวจผลเองก่อนรวมเข้างานจริง

เวอร์ชันนี้สร้างโดย deepseek-v4.1-flash#high ผ่าน opencode go

เลื่อนลงเพื่อดูการทำงานทีละขั้น

ใครทำอะไร

ทุกงานเริ่มที่ main session ของ Claude ซึ่งคุยกับผู้ใช้ วางแผน และตัดสินว่างานไหนควรส่งให้ใคร

Claude (main session)

วางแผน เขียน brief ตรวจงาน และเป็นผู้อนุมัติขั้นสุดท้าย

deepseek-v4.1-flash

worker หลักผ่าน opencode go ใช้ effort high เป็นค่าเริ่มต้น

gpt-6.1-sol

โมเดลที่เก่งที่สุดผ่าน codex สำหรับงานยากมาก

gpt-6-luna

ทางเลือกที่ประหยัดผ่าน codex เมื่อผู้ใช้เลือกใช้

qwen3.8-flash

ผู้ตรวจคนที่สองสำหรับงานเสี่ยง

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

งานไหนไปหาใคร

งานโค้ดที่มีวิธีตรวจที่รันได้จริง

deepseek-v4.1-flash#high

งานยากมาก เช่น แก้หลายไฟล์ อัลกอริทึมซับซ้อน หรือ debug ยาก

Claude แนะนำ gpt-6.1-sol พร้อมระดับ effort แล้วถามผู้ใช้ก่อน

ไม่มีวิธีตรวจที่รันได้ โค้ดลับ หรือเรื่องที่ผู้ใช้ยังไม่ตัดสินใจ

ไม่ส่งออกนอกเครื่อง ให้ sonnet-worker หรือ Opus ทำ

งานง่ายหรืองานซ้ำ ๆ เช่น ค้นหาไฟล์หรือเปลี่ยนชื่อ

haiku-worker

deepseek ใช้ token ได้เต็มที่ ส่วนโมเดลของ codex ต้องประหยัด จึงเลือก effort ต่ำสุดที่ทำสำเร็จแน่นอน ไม่ใช่แค่น่าจะสำเร็จ

ถามผู้ใช้ก่อนส่งงานทุกรอบ

ก่อนส่งงานทุกรอบ ทั้งรอบแรก รอบแก้ และรอบตรวจโดยโมเดลที่สอง Claude จะบอกผู้ใช้ว่าส่งให้โมเดลไหน ใช้ effort ระดับไหน โค้ดจะไปที่ provider ไหน และเพราะอะไร แล้วรอให้ผู้ใช้ตอบตกลง

• effort ตั้งแต่ high ขึ้นไปต้องได้รับอนุมัติชัดเจน ยกเว้น deepseek
• ครั้งแรกในแต่ละโปรเจกต์ Claude ถามก่อนว่าส่งโค้ดออกนอกเครื่องได้ไหม แล้วจำคำตอบไว้
• ถ้างานแตะไฟล์นอก repo ใช้ network หรือมีข้อมูลสำคัญอยู่ใกล้ ๆ จะมีคำเตือนความเสี่ยงสูง

brief ที่ worker ทำตามได้โดยไม่ต้องถาม

worker ทำงานแบบ headless จึงถามกลับไม่ได้ Claude เขียน brief ให้ครบ 8 ส่วน แล้วอ่านทวนในมุมของ worker ก่อนส่ง ถ้ายังมีคำถามเหลือ ต้องตอบไว้ใน brief

1. เป้าหมาย: หนึ่งประโยค พร้อมเหตุผล
2. บริบท: path ของไฟล์ที่ต้องอ่าน และโค้ดเดิมที่ควรใช้ซ้ำ
3. สิ่งที่ต้องแก้: signature กฎการทำงาน และ edge case ทุกข้อพร้อมผลที่ต้องได้
4. สิ่งที่ตัดสินใจแล้ว: ทุกจุดที่กำกวมมีคำตอบ
5. นอกขอบเขต: ไฟล์ที่ห้ามแตะ ห้ามเพิ่ม dependency และห้ามลด test
6. วิธีตรวจ: คำสั่งที่ต้องรันและผลที่ต้องได้
7. รูปแบบรายงาน: ไฟล์ที่แก้ ผลการรัน สมมติฐาน และคำสั่งที่ถูกปฏิเสธ
8. ปิดท้าย: ทำงานในโฟลเดอร์ปัจจุบันเท่านั้น และถ้าคำสั่งถูกปฏิเสธห้ามหาทางเลี่ยง

brief ส่งเป็นไฟล์จึงยาวได้ไม่จำกัด งานที่ส่งให้ gpt-6.1-sol Claude จะสัมภาษณ์ผู้ใช้จนไม่เหลือข้อสงสัยก่อนเขียน brief

เส้นทางของงานหนึ่งรอบ

สคริปต์ oc-delegate.sh ทำทุกขั้นนี้ในคำสั่งเดียว

1. ตรวจ repo: ต้องเป็น git repo ไม่มีงานค้างที่ยังไม่ commit และไม่มี config ของ worker เป็นของตัวเอง
2. สร้าง worktree และ branch ext/<task> แยกจากงานของผู้ใช้
3. ใส่ config ที่ปฏิเสธคำสั่งเสี่ยง และเปิดเฉพาะ skill ที่ brief ระบุ
4. health check ถาม worker ให้ตอบ ok ภายใน 30 วินาที (เฉพาะ opencode)
5. ถ่าย snapshot ไฟล์สำคัญนอก worktree
6. รัน worker โดยมี timeout 600 วินาทีสำหรับ opencode และ 900 วินาทีสำหรับ codex
7. ลบ trust entry ที่ codex เพิ่มเองในรอบนี้
8. เทียบ snapshot ถ้าไฟล์สำคัญเปลี่ยนให้หยุดทันที
9. สรุปผล: สถานะ diff คำสั่งที่ถูกปฏิเสธ และสมมติฐานของ worker

DONE

พร้อมให้ Claude ตรวจ

REFUSED

เงื่อนไขก่อนเริ่มไม่ผ่าน แจ้งผู้ใช้

API_DOWN API_ERROR TIMEOUT

ลบ worktree แจ้งผู้ใช้ แล้วรอผู้ใช้เลือกทางต่อ

INTEGRITY_CHANGED

หยุด เก็บ worktree ไว้ตรวจ และไม่ merge

รั้วกั้นรอบตัว worker

worker รันบนเครื่องจริงโดยไม่มี sandbox จึงมีการป้องกันหลายชั้นซ้อนกัน

• deny คำสั่งเสี่ยง 30 รายการ เช่น git push rm -rf curl pip install
• ตัด CLI ของ agent ทุกตัวออกจาก PATH และตั้ง CLAUDE_EXT_WORKER=1 เพื่อกันการสั่งงานซ้อน
• ลบ env ที่มีคำว่า KEY SECRET TOKEN PASSWORD หรือ CREDENTIAL ก่อนส่งให้ worker
• เฝ้าไฟล์สำคัญ เช่น CLAUDE.md settings skills memory config ของ codex และ shell profile
• hidden test เก็บไว้นอก repo และมีรหัสลับฝังอยู่ ถ้ารหัสโผล่ใน log ของ worker ผลรอบนั้นใช้ไม่ได้
• รายงานของ worker เป็นข้อมูลที่ไม่น่าเชื่อถือ Claude ไม่ทำตามคำขอที่อยู่ในนั้น

ความเสี่ยงที่ยอมรับไว้: worker ยังเขียนไฟล์นอก worktree ผ่าน shell ได้ จึงมีคำเตือนในรอบที่เสี่ยงสูง

ตรวจ 8 ชั้นก่อนรวมงาน

Claude เป็นผู้อนุมัติขั้นสุดท้ายเสมอ และไม่รายงานว่าสำเร็จเพียงเพราะ worker บอก

1. hidden test ที่เขียนไว้ก่อนส่งงาน
2. test ทั้งชุดและ lint
3. อ่าน diff ทุกบรรทัดเทียบกับ brief
4. ตรวจขอบเขต: ไฟล์ที่แก้ dependency และ test ที่ถูกลด
5. ตรวจสมมติฐานทุกข้อของ worker
6. edge case ที่ตั้งใจหาจุดอ่อนจาก diff
7. งานเสี่ยงให้ qwen3.8-flash ตรวจซ้ำ แล้ว Claude ตัดสิน
8. รายงานผู้ใช้ว่าตรวจอะไรไปแล้วบ้าง

ชั้นที่ 2 4 และ 6 รันพร้อมกันใน oc-verify.sh คำสั่งเดียว

ตรวจแบบเบาใช้ได้กับ gpt-6.1-sol เท่านั้น หลังผ่าน 5 งานแรกที่ตรวจเต็มโดยไม่พบจุดที่การตรวจแบบเบาจะพลาด และยังต้องอ่านทุกบรรทัดของ logic หลักกับไฟล์เสี่ยง

เมื่องานไม่ผ่านหรือระบบล่ม

งานไม่ผ่าน (deepseek)

แก้ใน session เดิมด้วย high แล้วจึงใช้ max ถ้ายังไม่ผ่าน Claude แนะนำ gpt-6.1-sol หรือ sonnet-worker

งานไม่ผ่าน (codex)

แก้ได้ 1 รอบ แล้วรายงานผู้ใช้

API ล่ม error หรือ timeout

ไม่สลับไปตัวอื่นเอง แจ้งผู้ใช้ว่าอะไรพัง เสนอทางเลือก แล้วรอผู้ใช้ตัดสินใจ

ทุกรอบแก้ต้องถามผู้ใช้ก่อนเหมือนรอบแรก

รวมงาน แต่ไม่ push เอง

• stage เฉพาะไฟล์ที่อนุญาต ไม่ใช้ git add -A
• commit มีบรรทัด Worker: <model>#<effort> บอกว่าใครเขียน
• merge เฉพาะเมื่อ branch ของผู้ใช้ยัง clean ถ้าชนกันจะยกเลิกและแจ้งชื่อ branch
• ถ้าเครื่องยังไม่มี git identity Claude ถามผู้ใช้ ไม่ตั้งเอง
• git push ทำเมื่อผู้ใช้สั่งเท่านั้น

ผล benchmark

ทดสอบ 11 งาน Python ทุกโมเดลได้คะแนนราว 100% ความต่างจึงอยู่ที่เวลาและความละเอียดในการตรวจ

ข้อสรุป: deepseek-v4.1-flash#high ดีที่สุดโดยรวม ส่วน #max แม่นเท่ากันแต่ช้ากว่าราว 2.5 เท่า qwen ช้าที่สุด และ gpt-6-luna ระดับ medium กับ high พลาด bug ในงาน review 1 จุด