เจาะลึก Claude Code: สถาปัตยกรรม การกำกับดูแล และแนวทางปฏิบัติทางวิศวกรรม

0. สรุปสั้นๆ (TL;DR)

บทความนี้เกิดจากประสบการณ์การใช้งาน Claude Code อย่างจริงจังเป็นเวลาหกเดือน และบทเรียนจากการใช้จ่ายเดือนละ $40 สำหรับสองบัญชี หวังว่าจะเป็นข้อมูลที่มีประโยชน์สำหรับทุกคนนะครับ

ตอนแรกๆ ผมก็ใช้มันแค่เป็น ChatBot แต่ไม่นานก็รู้สึกว่ามันเริ่มผิดปกติ: บริบทรก, เครื่องมือเยอะขึ้นแต่ประสิทธิภาพดันลดลง, กฎต่างๆ ก็ถูกเมินเฉยทั้งที่เขียนยาวขึ้น หลังจากศึกษา Claude Code จริงๆ จังๆ ก็พบว่ามันไม่ใช่ปัญหาที่ Prompts แต่เป็นปัญหาที่การออกแบบระบบ (System Design)

ผมอยากพูดถึง: Claude Code ทำงานเบื้องลึกยังไง, ทำไมบริบทถึงรกและจะจัดการมันยังไง, ออกแบบ Skills กับ Hooks ยังไง, การใช้ Subagents ที่ถูกต้อง, ผลกระทบทางสถาปัตยกรรมของ Prompt Caching, และวิธีเขียน CLAUDE.md ที่มีประโยชน์จริงๆ

วิธีทำความเข้าใจที่ตรงไปตรงมาที่สุดคือการแยก Claude Code ออกเป็นหกชั้น:

การเสริมแค่ชั้นใดชั้นหนึ่งจะทำให้เกิดความไม่สมดุล ถ้า CLAUDE.md ยาวเกินไป ก็จะไปรกบริบท; เครื่องมือมากเกินไปก็ทำให้สับสน; Subagents เยอะเกินไปก็เกิดสถานะคลาดเคลื่อน (State Drift); ข้ามขั้นตอนตรวจสอบก็จะหาจุดที่ผิดพลาดไม่เจอ

1. การทำงานเบื้องลึกของ Claude Code

หัวใจของ Claude Code ไม่ใช่แค่ "การตอบคำถาม" แต่เป็นลูปการทำงานแบบ Agentic Loop ที่วนซ้ำ:

1รวบรวมบริบท → ลงมือทำ → ตรวจสอบผลลัพธ์ → [เสร็จสิ้น หรือ วนซ้ำ]
2     ↑                    ↓
3  CLAUDE.md          Hooks / Permissions / Sandbox
4  Skills             Tools / MCP
5  Memory

ผมพบว่าคอขวด (Bottlenecks) มักไม่ใช่เพราะโมเดลไม่ฉลาดพอ แต่เป็นเพราะเราให้บริบทที่ผิด หรือไม่มีทางรู้ว่างานที่ออกมาถูกต้องหรือไม่ หรือไม่มีทางย้อนกลับ

ห้าชั้นที่ต้องโฟกัส:

การมองที่ชั้นเหล่านี้ทำให้การแก้ไขปัญหาง่ายขึ้น ผลลัพธ์ไม่เสถียร? ให้ตรวจสอบลำดับการโหลดบริบท ระบบอัตโนมัติหลุดมือ? ให้ตรวจสอบชั้นควบคุม (Control Layer) คุณภาพลดลงเรื่อยๆ ในเซสชั่นยาว? แสดงว่าผลลัพธ์ระหว่างทางไปปนเปื้อนบริบทแล้ว การเริ่มเซสชั่นใหม่ดีกว่าการไปแก้ Prompts

2. ขอบเขตแนวคิด: MCP / Plugin / Tools / Skills / Hooks / Subagents

กฎง่ายๆ: ใช้ Tools/MCP สำหรับการกระทำใหม่ๆ, ใช้ Skills สำหรับเวิร์กโฟลว์, ใช้ Subagents สำหรับสภาพแวดล้อมที่แยกเป็นอิสระ, ใช้ Hooks สำหรับข้อจำกัด/การตรวจสอบที่จำเป็น, และใช้ Plugins สำหรับการกระจายข้ามโปรเจกต์

3. Context Engineering: ข้อจำกัดของระบบที่สำคัญที่สุด

หลายคนมองว่าบริบทเป็นแค่ "ปัญหาเรื่องความจุ" แต่จริงๆ แล้วคอขวดที่แท้จริงคือสัญญาณรบกวน (Noise) ข้อมูลที่มีประโยชน์ถูกฝังอยู่ในเนื้อหาที่ไม่เกี่ยวข้อง

องค์ประกอบต้นทุนบริบทที่แท้จริง

บริบท 200K ของ Claude Code นั้นใช้ได้ไม่เต็มทั้งหมดนะครับ:

1บริบททั้งหมด 200K
2├── ค่าใช้จ่ายคงที่ (~15-20K)
3│   ├── คำสั่งระบบ: ~2K
4│   ├── คำอธิบาย Skill: ~1-5K
5│   ├── คำจำกัดความของเครื่องมือ MCP Server: ~10-20K  ← ตัวการที่ซ่อนเร้นมากที่สุด
6│   └── สถานะ LSP: ~2-5K
7│
8├── กึ่งคงที่ (~5-10K)
9│   ├── CLAUDE.md: ~2-5K
10│   └── Memory: ~1-2K
11│
12└── ส่วนที่ใช้ได้แบบไดนามิก (~160-180K)
13    ├── ประวัติการแชท
14    ├── เนื้อหาไฟล์
15    └── ผลลัพธ์จากเครื่องมือ

MCP Server ทั่วไป (อย่าง GitHub) จะมีคำจำกัดความของเครื่องมือ 20-30 อัน แต่ละอันประมาณ 200 โทเค็น รวมแล้ว 4,000-6,000 โทเค็น การเชื่อมต่อ 5 เซิร์ฟเวอร์จะกินพื้นที่ถึง 25,000 โทเค็น (12.5%) ซึ่งเป็นเรื่องสำคัญมากเวลาที่ต้องอ่านโค้ดปริมาณมาก

การแบ่งชั้นบริบทที่แนะนำ

1ติดถาวร             → CLAUDE.md: สัญญาโครงการ / คำสั่ง build / ข้อห้ามต่างๆ
2ตามเส้นทาง          → rules: กฎเฉพาะภาษา / ไดเรกทอรี / ประเภทไฟล์
3เรียกใช้เมื่อต้องการ  → Skills: เวิร์กโฟลว์ / ความรู้เฉพาะด้าน
4แยกออกไป           → Subagents: การสำรวจขนาดใหญ่ / การวิจัยแบบขนาน
5อยู่นอกบริบท        → Hooks: สคริปต์ที่ตายตัว / การตรวจสอบ / การบล็อก

อย่าโหลดสิ่งที่คุณใช้แค่บางโอกาสเข้ามา

แนวปฏิบัติที่ดีที่สุดสำหรับบริบท

• ทำให้ CLAUDE.md สั้น, คม, และปฏิบัติการได้จริง CLAUDE.md ของ Anthropic มีขนาดประมาณ 2.5K โทเค็นเท่านั้น
• ย้ายเอกสารอ้างอิงขนาดใหญ่ไปไว้ในไฟล์สนับสนุนของ Skills
• ใช้ .claude/rules/ สำหรับกฎเกี่ยวกับเส้นทางหรือภาษา
• ใช้คำสั่ง /context เพื่อตรวจสอบการใช้งาน

• ใช้ /clear สำหรับการสลับงาน และ /compact สำหรับการเริ่มเฟสใหม่
• เขียน Compact Instructions ใน CLAUDE.md เพื่อควบคุมสิ่งที่จะถูกเก็บรักษาไว้

สัญญาณรบกวนจากผลลัพธ์ของเครื่องมือ: ตัวการเงียบอีกตัว

ผลลัพธ์แบบไดนามิกจากเครื่องมือ (เช่น cargo test หรือ git log) สามารถเติมเต็มบริบทได้อย่างง่ายดาย Claude ไม่จำเป็นต้องเห็นทุกอย่าง

RTK (Rust Token Killer) เป็นแนวทางที่ดี: มันจะกรองผลลัพธ์จากคำสั่งก่อนที่จะส่งถึง Claude เช่น มันสามารถย่อผลลัพธ์ทดสอบหลายพันบรรทัดให้เป็นข้อความสำเร็จเพียงบรรทัดเดียว

กับดักของการบีบอัด

การบีบอัดแบบดีฟอลต์อาจลบการตัดสินใจทางสถาปัตยกรรมและข้อจำกัดต่างๆ ทิ้งไป

วิธีแก้: ระบุ Compact Instructions ใน CLAUDE.md เพื่อจัดลำดับความสำคัญของการตัดสินใจทางสถาปัตยกรรม, ไฟล์ที่ถูกแก้ไข, สถานะการตรวจสอบ, และสิ่งที่ต้องทำ (TODOs)

อีกวิธี proactive: ให้ Claude เขียนไฟล์ HANDOFF.md ก่อนเริ่มเซสชั่นใหม่เพื่ออธิบายความคืบหน้าและจุดที่เป็น Dead End

คุณค่าทางวิศวกรรมของ Plan Mode

Plan Mode แยกการสำรวจ (Exploration) ออกจากการลงมือทำ (Execution)

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

4. การออกแบบ Skills: เวิร์กโฟลว์ที่โหลดเมื่อต้องการ

Skills คือความรู้และเวิร์กโฟลว์ที่ถูกเรียกใช้เมื่อจำเป็น (On-demand)

อะไรที่ทำให้ Skill ดี

• คำอธิบาย (Description) ควรบอกว่า "เมื่อไหร่ควรใช้ฉัน" ไม่ใช่ "ฉันทำอะไร"
• มีขั้นตอนที่สมบูรณ์, Input, Output, และเงื่อนไขการหยุด
• เก็บเนื้อหาหลักไว้เพื่อการนำทางและข้อจำกัดหลัก; ย้ายรายละเอียดไปไว้ในไฟล์สนับสนุน
• ตั้งค่า disable-model-invocation: true สำหรับ Skills ที่มีผลข้างเคียง

Progressive Disclosure

Claude Code เน้น "การเปิดเผยแบบค่อยเป็นค่อยไป" (Progressive Disclosure): ให้ดัชนีและการนำทางก่อน จากนั้นค่อยดึงรายละเอียดเมื่อจำเป็น

Skill สามประเภทหลัก

1. Checklist (Quality Gate): เช่น release-check
2. Workflow (Standardized Ops): เช่น config-migration ที่มี Rollback
3. Domain Expert (Decision Framework): เช่น runtime-diagnosis

ทำให้ Descriptor สั้นเพื่อประหยัดพื้นที่บริบท

5. การออกแบบ Tools: ช่วยให้ Claude เลือกได้อย่างถูกต้อง

Tools สำหรับ Agent ควรเน้นที่ความง่ายในการใช้งานที่ถูกต้อง มากกว่าความครบถ้วนของฟีเจอร์

Tools ที่ดีกับ Tools ที่แย่

หลักการออกแบบ: ใช้คำนำหน้า (Prefix) เช่น github_pr_*, รองรับรูปแบบที่กระชับ, ให้ข้อความแสดงข้อผิดพลาดที่มีประโยชน์, และหลีกเลี่ยงการเปิดเผยเครื่องมือที่ย่อยเป็นชิ้นเล็กชิ้นน้อยมากเกินไป

วิวัฒนาการของ Tools ภายใน

วิวัฒนาการของเครื่องมือ AskUserQuestion แสดงให้เห็นว่าเครื่องมือเฉพาะกิจ (Dedicated Tool) มีเสถียรภาพมากกว่าการจัดรูปแบบ Markdown หรือพารามิเตอร์ Exit

เมื่อโมเดลแข็งแกร่งขึ้น Todo Tools ก็กลายเป็น "เครื่องพันธนาการ" (Shackle) ส่วน Search Tools ก็วิวัฒนาการจาก RAG ไปเป็น Grep เพื่อความยืดหยุ่นที่ดีกว่าและ "การเปิดเผยแบบค่อยเป็นค่อยไป"

6. Hooks: Logic บังคับก่อน/หลังการดำเนินการ

Hooks เป็นการนำการควบคุมแบบตายตัว (Deterministic Control) กลับมาสู่กระบวนการต่างๆ เช่น การจัดรูปแบบ, การป้องกันไฟล์, และการแจ้งเตือน

สิ่งที่เหมาะกับ Hooks

การบล็อกไฟล์ที่ได้รับการป้องกัน, การจัดรูปแบบอัตโนมัติหลังจากแก้ไข, การฉีดบริบทแบบไดนามิก (ชื่อ Git Branch), และการแจ้งเตือน

การตรวจจับข้อผิดพลาดตั้งแต่เนิ่นๆ

7. Subagents: อินสแตนซ์ Claude อิสระ

Subagents มีหน้าที่ในการแยกเป็นสัดส่วน (Isolation) งานต่างๆ เช่น การสแกน Repos หรือการรัน Tests จะสร้างผลลัพธ์จำนวนมากที่ไม่ควรมาเกะกะเธรดหลัก

ข้อจำกัดที่ชัดเจน

จำกัด Tools, เลือกโมเดลให้เหมาะสม (Haiku สำหรับการสำรวจ, Opus สำหรับการตรวจสอบ), และตั้งค่า maxTurns

8. Prompt Caching: แกนหลักของสถาปัตยกรรม Claude Code

Claude Code ถูกสร้างขึ้นมาโดยมี Prompt Caching เป็นแกนหลัก อัตราการ Cache Hit ที่สูงจะช่วยประหยัดเงินและเพิ่ม Rate Limits

โครงสร้าง Prompt สำหรับการแคช

ลำดับมีความสำคัญสำหรับการจับคู่คำนำหน้า (Prefix Matching): System Prompt → Tool Definitions → Chat History → User Input

อย่าสลับโมเดลระหว่างเซสชั่น

การสลับโมเดลจะทำให้ Cache แตก ให้ใช้ Subagents สำหรับการส่งต่องาน (Handoffs) แทน

การทำงานของ Compaction

Compaction จะใช้ Fork เพื่อสรุปประวัติ โดยมีต้นทุนเพียง 1/10 เนื่องจาก Cache Hit

9. Verification Loops: ไม่มี Verifier = ไม่มี Engineering Agent

"Claude บอกว่าเสร็จแล้ว" นั้นไร้ค่าหากไม่มีการตรวจสอบ ให้กำหนด Verification อย่างชัดเจนใน Prompt, Skill, และ CLAUDE.md

10. คำสั่งที่ใช้ความถี่สูง

คำสั่งเช่น /context, /clear, /compact, และ /memory ช่วยจัดการบริบทอย่างกระตือรือร้น

ธรรมาภิบาลและการขนาน (Parallelism)

คำสั่งซ่อนเร้นที่มีประโยชน์: /simplify (ตรวจสอบโค้ด), /rewind (สร้าง Checkpoint), /btw (คำถามข้างเคียง), /insight (วิเคราะห์เซสชั่นเพื่ออัปเดต CLAUDE.md)

11. วิธีเขียน CLAUDE.md ที่ดี

มันคือสัญญา (Contract) ไม่ใช่ฐานความรู้ (Knowledge Base)

รวมถึงคำสั่ง build/test, ขอบเขตทางสถาปัตยกรรม, หลักเกณฑ์การเขียนโค้ด, รั้วความปลอดภัย (Safety Rails), และ Compact Instructions ให้ Claude อัปเดต CLAUDE.md หลังจากที่มันแก้ไขข้อผิดพลาดของตัวเอง

12. ประสบการณ์ล่าสุด

บทเรียนจากการสร้าง Kaku (Rust + Lua): ความโปร่งใสของสภาพแวดล้อม (Environment Transparency) เป็นสิ่งสำคัญ (ใช้คำสั่ง 'doctor'), และ Hooks นั้นยอดเยี่ยมสำหรับโปรเจกต์ที่ใช้หลายภาษา

13. Anti-patterns (รูปแบบที่ไม่ควรทำ)

14. Health Check (การตรวจสอบสุขภาพ)

ใช้ npx skills add tw93/claude-health เพื่อตรวจสอบการตั้งค่าของคุณ

15. สรุป (Conclusion)

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