Claude Code (เอเจนต์เขียนโค้ดของ Anthropic ที่ทำงานผ่านเทอร์มินัล คือหน้าต่างพิมพ์คำสั่งของโปรแกรมเมอร์) เก่งขึ้นแทบทุกเดือน แต่มีเรื่องหนึ่งที่ไม่ค่อยมีใครพูดถึง คือไม่ว่าจะเวอร์ชันไหน มันก็ยังทำงานแบบ "คนเดียว" อยู่ดี งานหนักทั้งก้อนมันรับไว้เอง ทุกขั้นตอนมันบรรยายให้ฟังยืดยาว แล้วพอความจำในเซสชัน (ที่เรียกกันว่า context) เต็มหรือเปิดเซสชันใหม่ มันก็ลืมว่าเมื่อกี้ตกลงอะไรกันไว้ สามอาการนี้แหละที่ค่อย ๆ กินทั้งเวลาและค่า token (หน่วยที่ AI คิดเงินตามปริมาณข้อความเข้าออก) ของคนใช้จริง

ตอนนี้มีสกิลโอเพนซอร์สฟรีจากชุมชนนักพัฒนา 3 ตัวที่จับจุดอ่อนพวกนี้คนละจุด ตัวแรกชื่อ antigravity-agents แบ่งงานหนักไปให้ AI อีกตัวทำขนานเบื้องหลัง ตัวที่สองชื่อ justsaydone ตัดการบรรยายให้เหลือคำเดียว และตัวที่สามชื่อ handoff เขียนไฟล์ส่งต่องานข้ามเซสชันจากข้อมูลที่ตรวจแล้ว รวมกันแล้วมันเปลี่ยน Claude Code จาก "เอเจนต์เดี่ยว" ให้ทำงานเหมือน "หัวหน้าทีม" ที่แบ่งงานให้คนอื่นทำ พูดสั้นลง และจำงานได้ข้ามวัน ข้อที่ต้องรู้ไว้ก่อนคือทั้งสามเป็นผลงานของนักพัฒนาอิสระคนละคน ไม่เกี่ยวข้องกันเอง และไม่ใช่ฟีเจอร์ทางการของ Anthropic เพราะงั้นให้มองว่าเป็นของฟรีที่หยิบมาลองและอ่านทำความเข้าใจก่อน ไม่ใช่มาตรฐานที่การันตีอะไร

แบ่งงานหนักให้อีกตัวช่วยทำ

จุดอ่อนข้อแรกคืองานหนัก เวลาสั่งให้ Claude Code ตรวจโค้ดทั้งรีโป (repository ที่เก็บโค้ดทั้งโปรเจกต์) รื้อโครงสร้างครั้งใหญ่ หรือค้นข้อมูลยาว ๆ มันต้องอ่านและคิดทุกอย่างเองในเซสชันเดียว ยิ่งงานใหญ่ ความจำของมันก็ยิ่งเต็มเร็ว แล้วค่า token ก็บานปลายตามไปด้วย

antigravity-agents (สร้างโดย Mark Fulton ภายใต้สัญญาอนุญาตแบบ MIT ที่ให้เอาไปใช้และแก้ได้ฟรี) เป็นสกิลไฟล์เดียวที่เปลี่ยนบทบาทของ Claude Code จาก "คนลงมือทำ" ให้เป็น "orchestrator" หรือหัวหน้างานที่คอยสั่งและรวมงาน วิธีทำงานคือ Claude เขียนบรีฟที่อ่านจบแล้วเข้าใจงานได้ในตัว แล้วส่งต่อให้ Google Antigravity CLI (โปรแกรมสั่งงานผ่านการพิมพ์คำสั่ง เป็นเอเจนต์เทอร์มินัลของ Google ที่ขับด้วยโมเดล Gemini และโมเดลอื่น เรียกใช้ผ่านคำสั่ง agy) ไปรันเบื้องหลัง ระหว่างที่ตัวช่วยอีกตัวกำลังลุยงานหนักอยู่ Claude Code ก็ทำงานเดิมที่ค้างอยู่ต่อได้เลยโดยไม่ต้องรอ

ข้อดีที่ได้มามี 3 อย่าง หนึ่งคือประหยัดทั้งความจำและ token ของ Claude เพราะโยนงานหนักไปไว้อีกฝั่ง สองคือได้ความเห็นที่สองจากคนละโมเดล เพราะ Gemini มองปัญหาคนละมุมกับ Claude และสามคือรันได้หลายงานพร้อมกันขณะที่ Claude ยังคุยกับเราได้ลื่น ๆ

ที่สำคัญคือมันไม่เชื่อผลจากตัวช่วยดื้อ ๆ พอ sub-agent (เอเจนต์ลูกที่รับงานไปทำ) ทำเสร็จ Claude จะไม่รวมงานเข้ามาเฉย ๆ แต่ "ตรวจก่อนเชื่อ" โดยเปิด git diff (git คือระบบเก็บประวัติการแก้โค้ด) ดูว่าโค้ดเปลี่ยนไปจริงตรงไหน แล้วรัน typecheck กับ build เพื่อตรวจอัตโนมัติว่าโค้ดยังผ่านการตรวจชนิดข้อมูลและยังคอมไพล์ (แปลงโค้ดให้กลายเป็นโปรแกรมที่รันได้) สำเร็จ ก่อนจะยอมรับผลนั้นเข้ามาในงาน

กฎเหล็กข้อเดียวคุมทั้งหมด งานของ Antigravity ห้ามเขียนทับไฟล์ที่ Claude Code กำลังแก้อยู่ในตอนนั้นเด็ดขาด งานที่แค่อ่านอย่างเดียว เช่น ตรวจโค้ด วิเคราะห์สถาปัตยกรรมหรือความปลอดภัย ค้นข้อมูล หรือตรวจ dependency (โค้ดสำเร็จรูปจากที่อื่นที่โปรเจกต์เรียกใช้) รันขนานได้เลยในพื้นที่จำกัดสิทธิ์อ่านอย่างเดียว ส่วนงานที่ต้องเขียนไฟล์ เช่น เขียนโค้ดใหม่หรือรื้อใหญ่ ให้ไปรันในสำเนาโปรเจกต์แยกที่เรียกว่า git worktree เพื่อไม่ให้สองฝั่งเขียนชนกัน

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

ให้มันตอบสั้นลงเหลือคำเดียว

จุดอ่อนข้อสองคือมันพูดเยอะ Claude Code ชอบเปิดด้วยประโยคแบบ "I'll start by…" เล่าทุกขั้นตอนที่กำลังทำ แล้วปิดท้ายด้วยย่อหน้าสรุปว่าแก้อะไรไปบ้าง ทั้งที่เปิดดู diff เองก็เห็นอยู่แล้ว คำบรรยายพวกนี้คือ output token ที่ต้องจ่ายเงินและเสียเวลาอ่านโดยไม่จำเป็น

justsaydone (สร้างโดย Raiyan Yahya ภายใต้สัญญา MIT) แก้ตรงนี้ด้วยการเปลี่ยน "สไตล์การตอบ" (output style คือโหมดกำหนดวิธีที่ Claude เรียบเรียงคำตอบ) ให้พอทำงานเสร็จมันตอบแค่คำเดียวว่า done จุดที่ควรเน้นคือมันตัดเฉพาะการบรรยายทิ้ง แต่ยัง plan · แก้โค้ด · รัน · ตรวจสอบ เหมือนเดิมทุกอย่าง เปลี่ยนแค่วิธีพูด ไม่ได้แตะวิธีเขียนโค้ดเลย

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

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

ตัวเลขตรงนี้ต้องอ่านให้ละเอียด จำนวนคำในคำตอบลดฮวบจริง งานแก้บั๊กหดจาก 22 คำเหลือคำเดียว หรือราว 95% แต่ "ค่าใช้จ่ายรวมทั้งเซสชัน" ขยับน้อยกว่านั้นมาก จากการทดสอบเทียบผลที่ Raiyan Yahya รันเอง โดยวัดงาน 5 ประเภทเทียบกันระหว่างมีกับไม่มีปลั๊กอิน โทเคนรวมเฉลี่ยลดราว 19% เท่านั้น บางงานอย่างการสร้างไฟล์กลับเพิ่มขึ้น 5% ซึ่งเขาบอกเองว่าเป็นความคลาดเคลื่อนปกติ เหตุผลคือโค้ดที่ Claude เขียนออกมาจริง ๆ ซึ่งเป็นส่วนที่กินโทเคนหนัก สกิลนี้ไม่ได้ไปยุ่งด้วยเลย ที่หดคือคำบรรยายในแชทเท่านั้น เพราะงั้นอย่าเข้าใจว่านี่คือการ "ลดบิลลงครึ่งหนึ่ง" เจ้าของสกิลย้ำเองว่าไม่ได้กล่าวอ้างแบบนั้น

ส่งต่องานข้ามเซสชันด้วยข้อมูลที่ตรวจแล้ว

จุดอ่อนข้อสามเจ็บที่สุดสำหรับงานยาว พอเซสชันหนึ่งคุยกันมานาน ความจำเริ่มเต็ม โมเดลจะค่อย ๆ เพี้ยน ลืม decision (สิ่งที่ตัดสินใจร่วมกันไปแล้ว) กลับไปลองวิธีที่เคยพังมาแล้วซ้ำ หรืออธิบายเนื้อหาในไฟล์ผิดไปจากที่เป็นจริงในตอนนี้ อาการนี้เรียกว่า context rot คือยิ่งเซสชันยาว ความจำของโมเดลยิ่งเชื่อถือไม่ได้

claude-code-handoff-skill (สร้างโดย ostikwhy-blip ภายใต้สัญญา MIT) แก้ด้วยการให้พิมพ์ /handoff ตอนท้ายเซสชัน แล้วมันจะเขียนไฟล์ชื่อ HANDOFF.md ไว้ที่โฟลเดอร์หลักของโปรเจกต์ เป็นบันทึกส่งต่อให้เซสชันหน้ารับช่วงงานต่อได้โดยไม่ต้องเดางานใหม่ตั้งแต่ต้น

หัวใจอยู่ที่กฎข้อเดียว: ห้ามเขียนอะไรลงไฟล์จากความจำล้วน ๆ ก่อนเขียนแต่ละบรรทัด Claude ต้องรันคำสั่งของ git อย่าง git status git log และ git diff เพื่อเช็คว่าอะไรเปลี่ยนไปจริง ไม่ใช่สิ่งที่มันเชื่อว่าเปลี่ยน ต้องเปิดอ่านไฟล์ทุกไฟล์ที่จะพูดถึงซ้ำอีกรอบ และถ้าจะเขียนว่า "เทสต์ผ่าน" ก็ต่อเมื่อรันเทสต์จริงระหว่างทำ handoff เท่านั้น

ทุกข้อความในไฟล์ติดแท็กบอกชัดว่าเชื่อได้แค่ไหน [V] คือตรวจกับรีโปแล้วระหว่างทำ handoff เชื่อได้ ส่วน [?] คือจำมา ยังไม่ได้ตรวจซ้ำ ให้ถือเป็นแค่เบาะแส พอเซสชันหน้าพิมพ์ว่า resume from the handoff มันจะไม่เชื่อไฟล์ทันที แต่เอาข้อที่ติดแท็ก [V] มาตรวจกับสภาพรีโปปัจจุบันอีกรอบ แล้วรายงานตรง ๆ ว่ามีอะไรเพี้ยนไปจากตอนเขียน เท่ากับตรวจซ้ำทั้งฝั่งตอนเขียนและฝั่งตอนรับช่วงงาน

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

บทเรียนที่ใช้ได้แม้ไม่ลงสกิลสักตัว

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

ข้อดีคือแม้จะไม่ลงสกิลพวกนี้สักตัว วิธีคิดสามข้อนี้ก็หยิบไปใช้กับ Codex (เอเจนต์เขียนโค้ดของ OpenAI) หรือเอเจนต์เขียนโค้ดตัวไหนก็ได้ แยกงานหนักไปทำขนานแทนที่จะรับเองทั้งหมด สั่งให้มันตอบสั้นเข้าเรื่อง และก่อนเปิดเซสชันใหม่ให้มันจดสิ่งที่ตรวจแล้วไว้ส่งต่อ แต่ก็ควรจำไว้ว่าทั้งสามเป็นสกิลของนักพัฒนาอิสระคนละคนที่เพิ่งทำออกมา ไม่ใช่ฟีเจอร์ทางการของ Anthropic เพราะงั้นก่อนเอาไปใช้กับงานจริง ควรเปิดอ่าน SKILL.md ของแต่ละตัวให้เข้าใจก่อนว่ามันทำอะไรบ้าง

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

---

ที่มา:

• antigravity-agents โดย Mark Fulton
• justsaydone โดย Raiyan Yahya
• claude-code-handoff-skill โดย ostikwhy-blip