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

19 ข้อผิดพลาดที่ช่อง Simon Scrapes รวบรวมไว้ เจาะจงคนที่ "ใช้เป็นแล้ว" โดยเฉพาะ เพราะยิ่งใช้มานาน เราก็ยิ่งติดนิสัยและสูตรเดิมๆ ที่คิดว่าดี ทั้งที่จริงล้าสมัยไปแล้ว แถมหลายข้อยังอ้างอิงจากเอกสารทางการของ Anthropic โดยตรง

เรื่องที่พลิกความเชื่อเดิมมากที่สุดคือ Persona หรือเทคนิคสั่งให้โมเดลสวมบทบาท ผลการทดสอบจับคู่ Persona 162 แบบเข้ากับชุดคำสั่ง 2,500 พรอมต์ พบว่าการสวมบทบาทไม่ได้ช่วยให้ผลลัพธ์ดีขึ้นกว่าการสั่งตรงๆ เลยแม้แต่น้อย

ถ้าไม่ใช้ persona แล้ว ควรใส่อะไรแทน

ทาง Anthropic เองก็ปรับทิศทางแบบเดียวกัน โดยทีมพัฒนา Claude Code ตัดชุดคำสั่งตั้งต้นของระบบอย่าง System Prompt ลงราว 80% พร้อมระบุชัดเจนว่า การใส่ตัวอย่างเข้าไปเยอะๆ ไม่ใช่วิธีที่ดีที่สุดอีกต่อไป

แล้วถ้าไม่ใส่ Persona หรือบทบาท เราควรใส่ข้อมูลอะไรแทน? คำแนะนำเรื่องการเขียนพรอมต์ของ Anthropic สรุปไว้ 3 ข้อหลัก:

• ระบุแหล่งข้อมูลให้ชัดเจน: บอกตรงๆ ว่าต้องไปอ่านไฟล์ไหนหรือค้นหาจากที่ใด อย่าปล่อยให้โมเดลเดาเอง
• กำหนด Definition of Done หรือเกณฑ์วัดว่างานเสร็จสมบูรณ์: ระบุให้ชัดเจนว่างานที่เสร็จต้องมีหน้าตาอย่างไร และมีเกณฑ์วัดผลอย่างไร
• สั่งให้ตรวจงานตัวเองก่อนส่ง: เช่น ปิดท้ายพรอมต์ด้วย Before you finish, verify your answer against... แล้วระบุไฟล์หรือเงื่อนไขที่ใช้ตรวจ

หัวใจสำคัญของทั้ง 3 ข้อนี้คือ บอกให้ Claude รู้ว่าต้องทำอะไร ไม่ใช่ต้องเป็นใคร

นอกจากนี้ อีกจุดที่คนมักพลาดคือการเขียนคำสั่งเชิง "ห้ามทำ" เพราะเมื่อคำสั่งห้ามไปขัดกับสิ่งที่เราขอในประโยคถัดไป โมเดลจะเริ่มสับสนว่าต้องทำตามเงื่อนไขไหนกันแน่ เช่น แทนที่จะสั่งว่า do not return this as markdown text ให้เปลี่ยนเป็นสั่งตรงๆ ว่า write it as smooth flowing text paragraphs เพื่อไม่ให้เหลือคำสั่งที่ขัดแย้งกันเองค้างอยู่ในพรอมต์

CLAUDE.md อ่านครั้งเดียวตอนเปิดเซสชัน

ไฟล์ CLAUDE.md คือไฟล์รวมกฎและแนวทางของโปรเจกต์ที่ Claude Code ใช้อ่านทำความเข้าใจก่อนเริ่มงาน แต่เอกสารของ Anthropic ระบุชัดเจนว่า ไฟล์นี้ไม่ว่าจะเป็นระดับโปรเจกต์หรือระดับบัญชีผู้ใช้ ระบบจะอ่าน แค่ครั้งเดียวตอนเปิดเซสชัน แล้วโหลดเก็บไว้ในหน่วยความจำ

นั่นหมายความว่า ถ้าเราแก้ CLAUDE.md ระหว่างทำงาน Claude จะไม่รู้ถึงการเปลี่ยนแปลงเลย จนกว่าเราจะรีสตาร์ทเซสชันใหม่ สั่ง clear หรือสั่ง compact บทสนทนา ซึ่งคำสั่งเหล่านี้จะทำให้โหลดไฟล์ใหม่อีกรอบ ใครที่เคยสงสัยว่าแก้กฎแล้วทำไม Claude ยังทำงานแบบเดิม นี่คือคำตอบ

อีกเรื่องคือ ความยาวของไฟล์ ตัว System Prompt ของ Claude Code มีคำสั่งพื้นฐานอยู่แล้วราว 50 ข้อ ขณะที่โมเดลทำตามคำสั่งได้อย่างแม่นยำไม่เกิน 150–200 ข้อ ส่วนไฟล์คำสั่งที่ให้ผลดีที่สุดยาวราว 300–350 คำ (นับจำนวนคำภาษาอังกฤษ ไม่ใช่จำนวนข้อ)

ถ้าไม่แน่ใจว่าจะย่อส่วนไหนดี ลองพิมพ์คำสั่ง /doctor แล้วสั่งต่อว่า propose trims to my CLAUDE.md that won't impact performance ให้ระบบช่วยวิเคราะห์และแนะนำจุดที่ตัดทอนได้ (อ่านรายละเอียดเชิงลึกว่าทำไมไฟล์นี้ถึงส่งผลต่อระบบมากขนาดนั้นได้ใน Claude Code ทำงานยังไง)

context ใหญ่ขึ้น แต่หาของเจอน้อยลง

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

Anthropic ทดสอบโมเดลรุ่นท็อปอย่าง Opus 4.6 โดยซ่อนข้อมูล 8 จุดไว้ใน Context แล้วให้โมเดลค้นหา ที่ขนาด 256,000 Token โมเดลค้นหาได้ถูกต้องถึง 93% แต่เมื่อขยาย Context ชุดเดิมเป็น 1,000,000 Token ความแม่นยำกลับลดลงเหลือเพียง 76% ทั้งที่เป็นโมเดลตัวเดิมและโจทย์ชุดเดิม ความผิดพลาดกลับเพิ่มขึ้นเป็น 1 ใน 4

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

(อ่านรายละเอียดเรื่องผลกระทบของ Context ในงานขนาดใหญ่เพิ่มเติมได้ใน Beyond the Basics กับ Claude Code)

auto compact ไม่ใช่เปอร์เซ็นต์อีกแล้ว

ทางออกของปัญหาข้างต้นคือการใช้ Compact หรือการสรุปย่อบทสนทนาช่วงก่อนหน้า เพื่อคืนพื้นที่ว่างให้กับ Context ซึ่งระบบการทำงานส่วนนี้เปลี่ยนไปจากเดิม

คำอธิบายชุดเดิมบอกว่า Claude Code จะรอให้ Context เต็มประมาณ 95% ก่อนค่อยสรุปย่อ และเราปรับค่าเปอร์เซ็นต์นั้นได้ แต่ปัจจุบันระบบไม่ได้ใช้เกณฑ์เปอร์เซ็นต์แล้ว ถ้าเราไม่ได้กำหนดค่า Auto Compact Window ไว้เอง ระบบจะสรุปย่อเมื่อปริมาณข้อมูลแตะขีดจำกัดของโมเดลตัวนั้นๆ ซึ่งแตกต่างกันไปในแต่ละโมเดล (บางโมเดลเริ่มย่อเมื่อใกล้เต็ม บางโมเดลรอจนชนขอบ 200,000 Token)

สิ่งที่พัฒนาขึ้นคือ ตอนนี้เราสามารถกำหนด Auto Compact Window เป็นจำนวน Token คงที่ได้เอง เช่น ตั้งไว้ที่ 50K หรือ 100K Token เพื่อสรุปย่อเนื้อหาก่อนที่ Context จะบวมจนความแม่นยำเริ่มตก

นอกจากนี้ การ Compact ยังยืดหยุ่นกว่าเดิมมาก แค่กด Escape สองครั้งระหว่างสนทนา ระบบจะเข้าสู่โหมด Rewind เพื่อย้อนกลับไปยังจุดก่อนหน้า พร้อมตัวเลือกอย่าง restore code, restore conversation และ summarize up to here ซึ่งตัวเลือกสุดท้ายนี้จะช่วยสรุปย่อเนื้อหาทั้งหมดก่อนหน้าจุดที่เราเลือก และให้เราทำงานต่อจากจุดนั้นได้ทันที ช่วยให้เราเลือกย่อเฉพาะช่วงที่จบไปแล้ว และเก็บบริบทงานปัจจุบันไว้ครบถ้วน

ต้นทุนที่ไม่โผล่บนหน้าจอ

Sub-agent คือตัวช่วยแยกงานย่อยออกไปทำแบบคู่ขนาน ข้อดีคือช่วยให้ Context ในเซสชันหลักสะอาด แต่มีต้นทุนแฝงสูงกว่าที่คิด

เอกสารของ Anthropic ระบุว่า การใช้งาน Agent Teams หรือระบบทำงานร่วมกันหลายตัว อาจกิน Token มากกว่าเซสชันปกติถึง 7 เท่า เมื่อผู้ช่วยแต่ละตัวในทีมทำงานในโหมด Plan หรือโหมดวางแผนก่อนลงมือทำ เพราะ Sub-agent แต่ละตัวมี Context Window แยกเป็นเอกเทศ จึงต้องส่งข้อมูลใหม่ทั้งหมด และไม่สามารถแชร์ Prompt Cache ร่วมกับเซสชันหลักได้

เกณฑ์ตัดสินใจใช้ Sub-agent จึงอยู่ที่ ปริมาณ Context ที่ต้องใช้:

• งานค้นหาและสำรวจโค้ดแบบคู่ขนานที่ใช้ Context น้อย -> เหมาะกับการใช้ Sub-agent มาก
• งานที่ต้องอาศัยบริบทโปรเจกต์เดิมเยอะๆ -> ทำในเซสชันหลักคุ้มกว่าในแง่ Token

การสลับโมเดลระหว่างทำงานก็มีกับดักเรื่องต้นทุนเช่นกัน สมมติคุยกับ Opus จน Context สะสมไปถึง 100,000 Token แล้วอยากสลับไปใช้โมเดลรุ่นเล็กอย่าง Haiku ที่ค่าใช้จ่ายต่ำกว่าเพื่อถามคำถามง่ายๆ สุดท้ายอาจ เสียเงินมากกว่าตอนให้ Opus ตอบ เพราะ Prompt Cache แยกตามโมเดล เมื่อสลับไป Haiku ระบบต้องสร้าง Cache ใหม่หมดทั้ง 100,000 Token และถ้าสลับกลับมาใช้ Opus ก็ต้องจ่ายค่าสร้าง Cache ใหม่อีกรอบ

โหมด Fast ที่ช่วยให้ Opus ทำงานเร็วขึ้นราว 2.5 เท่า ก็มีข้อควรรู้ 3 ข้อ:

• ใช้ได้เฉพาะเมื่อจ่ายผ่าน API หรือ Usage Credits ซึ่งเป็นเครดิตการใช้งาน: คิดค่าบริการตามจริง ไม่ครอบคลุมในแพ็กเกจสมาชิกรายเดือนปกติ
• การตั้งค่าจะค้างอยู่ข้ามเซสชัน: ถ้าเปิดทิ้งไว้ ระบบจะรันโหมดนี้ต่อไปเรื่อยๆ จนกว่าเราจะพิมพ์สั่ง fast off
• การเปิดใช้ครั้งแรกในบทสนทนามีค่าใช้จ่ายสูงที่สุด: เพราะต้องเสียค่าประมวลผล Context ทั้งหมดที่มีอยู่เดิมแบบเต็มจำนวนโดยไม่มี Cache ช่วย

นี่คือเหตุผลที่การสลับโหมดกลางคันในบทสนทนายาวๆ มีค่าใช้จ่ายพุ่งสูงผิดคาด (อ่านเพิ่มเติมเรื่องกลไกแคชได้ใน บทเรียนจากการสร้าง Claude Code)

คำแนะนำให้ปิด MCP server ใช้ไม่ได้แล้ว

MCP Server คือส่วนเชื่อมต่อเครื่องมือภายนอกเข้ากับ Claude คำแนะนำเดิมๆ มักบอกให้ปิดเซิร์ฟเวอร์ที่ไม่ได้ใช้งาน เพื่อไม่ให้คำอธิบาย Tool กินพื้นที่ Context

แต่ปัจจุบันเทคนิคนี้ไม่จำเป็นแล้ว เพราะฟีเจอร์ค้นหาเครื่องมืออย่าง Tool Search เปิดใช้งานเป็นค่าเริ่มต้นอยู่แล้ว ระบบจะโหลดเข้ามาแค่ชื่อเครื่องมือ ซึ่งกินพื้นที่ราว 120 Token ต่อตัวเท่านั้น ส่วนรายละเอียดการใช้งานแบบเต็ม ระบบจะดึงมาเฉพาะเมื่อจำเป็นต้องเรียกใช้จริงๆ การติดตั้ง MCP Server ไว้หลายตัวจึงแทบไม่ส่งผลกระทบต่อ Context Window อีกต่อไป

ตรวจสอบด้วยตัวเองได้ง่ายๆ เพียงพิมพ์คำสั่ง /context และ /mcp เพื่อดูปริมาณ Token ที่ใช้จริงในเครื่อง

sub-agent ไม่ได้เห็นสิ่งที่คุณเห็น

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

เมื่อเรียก Sub-agent ข้อมูลที่ส่งไปมีเพียง System Prompt ของตัวมันเอง ข้อความคำสั่งงาน และเนื้อหาไฟล์ CLAUDE.md เกือบทั้งหมด ส่วนข้อมูลที่ ไม่ได้ส่งไปเลย ได้แก่ ประวัติการสนทนาก่อนหน้า รูปแบบผลลัพธ์ Auto Memory หรือระบบจำข้อมูลอัตโนมัติของเซสชันหลัก และไฟล์ต่างๆ ที่เซสชันหลักเคยอ่านเข้ามาใน Context แล้ว

ยิ่งไปกว่านั้น Agent สำเร็จรูปอย่าง explore และ plan ที่ Claude ดึงมาใช้เองอัตโนมัติ ยิ่งได้รับข้อมูลน้อยลงไปอีก เพราะจะ ข้ามการอ่าน CLAUDE.md ไปเลย ทำให้กฎต่างๆ ที่เราเขียนไว้ไม่มีผลกับมัน

วิธีรับมือแบ่งออกเป็น 2 ทางเลือกตามลักษณะงาน:

• ถ้ามีกฎสำคัญที่ห้ามหลุด: ให้ระบุกฎเหล่านั้นซ้ำลงไปในข้อความสั่งงาน Sub-agent โดยตรง
• ถ้างานจำเป็นต้องพึ่งพาบริบททั้งหมดของบทสนทนาเดิม: ให้ใช้การ Fork บทสนทนา เพื่อแตกแขนงงานแทนการเรียก Sub-agent เพราะการ Fork จะส่งต่อ Context ทั้งชุดไปทำงานต่อได้ทันที

verification คือข้อเดียวที่ Anthropic บอกว่าสำคัญที่สุด

ในคู่มือสำหรับผู้ใช้ระดับสูงอย่าง Power User ของ Anthropic ระบุไว้อย่างชัดเจนว่า:

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

ระดับการทำ Verification มี 4 ขั้น ไล่จากง่ายไปจนถึงเข้มงวดที่สุด โดยเลือกใช้ตามระดับความเสี่ยงของงาน:

• สั่งให้ตรวจสอบในพรอมต์เดียวกัน: ประหยัดและสะดวกที่สุด เหมาะกับงานทั่วไปที่ไม่ได้มีความเสี่ยงสูง
• ใช้คำสั่ง /goal: มีตัวประเมินผลอย่าง Evaluator แยกออกมาคอยตรวจเช็กเงื่อนไขซ้ำหลังจบแต่ละรอบคำสั่ง เหมาะกับงานยาวที่มีเป้าหมายชัดเจน
• ใช้ Stop Hooks: เขียนสคริปต์บล็อกไม่ให้จบรอบทำงานจนกว่าผลการตรวจสอบจะผ่าน เช่น รันชุดทดสอบหรือตรวจความถูกต้องของโค้ด
• ใช้ Adversarial Review Agent: ตั้ง Agent อีกตัวมาคอยจับผิดโค้ดอย่างเข้มงวด เหมาะกับงานที่มีความสำคัญสูงและห้ามผิดพลาดเด็ดขาด

สำหรับระดับสุดท้ายอย่าง Review Agent ควรกำชับให้แจ้งเตือนเฉพาะจุดที่กระทบต่อความถูกต้องของงานหรือขัดกับ Definition of Done เท่านั้น ไม่เช่นนั้น Agent จะติเรื่องยิบย่อยไม่รู้จบ จนทำให้เสีย Token ไปกับการถกเถียงเรื่องสไตล์การเขียนโค้ดโดยไม่จำเป็น

สี่คำสั่งที่ติดมากับ Claude Code อยู่แล้ว

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

• /doctor: ตรวจเช็กความสมบูรณ์ของการตั้งค่าทั้งหมด ช่วยหาเครื่องมือเสริมอย่าง Skill, MCP Server และ Plugin ที่ไม่ได้ใช้งาน พร้อมแสดงว่าแต่ละตัวกิน Token ไปเท่าไร รวมถึงช่วยหาข้อความซ้ำซ้อนใน CLAUDE.md เพื่อแนะนำจุดที่ตัดทอนได้
• /insights: สร้างรายงานสถิติเป็นไฟล์ HTML โดยวิเคราะห์ข้อมูลการทำงานย้อนหลังได้สูงสุดถึง 200 เซสชัน
• btw: ใช้แทรกคำถามสั้นๆ ระหว่างทำงาน โดยไม่ขัดจังหวะงานหลักที่กำลังรันอยู่
• branch: แตกแขนงบทสนทนาปัจจุบันออกไปทดลองแนวทางใหม่ โดยที่ประวัติการทำงานเดิมยังอยู่ครบถ้วน

ข้อควรรู้ของคำสั่ง /insights คือ รายงานจะมีประโยชน์ก็ต่อเมื่อยังมีประวัติเซสชันเดิมเหลืออยู่ ซึ่งค่าเริ่มต้นจะเก็บไว้เพียง 30 วัน โดยสามารถพิมพ์ /resume เพื่อดูเซสชันที่ยังเหลืออยู่ได้ ถ้าต้องการเก็บประวัติไว้นานขึ้น สามารถปรับค่า cleanUpPeriodDays ในไฟล์ settings.json ได้ เช่น:

{
  "cleanUpPeriodDays": 365
}

การตั้งค่าเป็น 365 หมายถึงเก็บไว้นาน 1 ปีเต็ม ทั้งนี้มีจุดที่ต้องระวังคือ ค่า 0 ไม่ได้แปลว่าเก็บไว้ตลอดไป แต่หมายถึงให้ล้างประวัติทิ้งทันที แม้ระบบจะไม่ลบไฟล์ Auto Memory แต่ประวัติบทสนทนาที่ล้างไปแล้วจะไม่สามารถใช้ /resume เรียกกลับมาได้อีก

กฎใหม่ทั้งหมดสะท้อนข้อสรุปเดียวกัน

หากมองภาพรวมการเปลี่ยนแปลงทั้งหมด ทั้งการตัด Persona ออก, การลดขนาด System Prompt ลง 80%, การจำกัดไฟล์ CLAUDE.md ให้กระชับเหลือ 300–350 คำ, การตั้งเพดาน Context ให้ต่ำกว่าจุดที่ความแม่นยำจะเริ่มตก ไปจนถึงการเลือกใช้ Sub-agent เฉพาะกับงานที่มีบริบทไม่เยอะ

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

ที่มา: คลิป 19 Claude Code Mistakes "Pro" Users Are Still Making จากช่อง Simon Scrapes