AI & Generative AI

รวบรวมบทความ Claude (Part 1)

คู่มือเข้าใจ Claude Code: CLAUDE.md, Hooks, Skills, Agents และ MCP

1 May 2026104 min readLangGraphRAGMCPClaudeAI Agent

รวบรวมบทความ `Claude (Part 1)`

คู่มือเข้าใจ Claude Code: CLAUDE.md, Hooks, Skills, Agents และ MCP

ในช่วงที่ AI Coding Agent เริ่มเข้ามาเปลี่ยนวิธีทำงานของนักพัฒนา เครื่องมืออย่าง Claude Code ไม่ได้เป็นแค่ผู้ช่วยเขียนโค้ดอีกต่อไป แต่กำลังกลายเป็นระบบที่ช่วยจัดการ workflow, ตรวจคุณภาพ, เชื่อมต่อเครื่องมือ และทำงานร่วมกับทีมได้อย่างเป็นระบบมากขึ้น

บทความชุดนี้จะรวบรวมแนวคิดสำคัญเกี่ยวกับการใช้งาน Claude Code ตั้งแต่การจัดโครงสร้าง .claude/, การเขียน CLAUDE.md, การใช้ hooks, commands, skills, agents ไปจนถึง MCP และ workflow ขั้นสูง เพื่อให้เข้าใจว่า การใช้ Claude Code ให้ได้ผลจริงไม่ได้ขึ้นอยู่กับ prompt ที่ดีเท่านั้น แต่ขึ้นอยู่กับ “ระบบรอบตัว” ที่ออกแบบมาอย่างชัดเจน

อันนี้จะรวบรวมหลายๆบทความที่น่าสนใจเกี่ยวกับ Claude เริ่มกันที่ บทความแรกของ Reference: Youssef Hosni

1) วิธีจัดโครงสร้างโฟลเดอร์ `.claude/` ให้ทำงานได้มีประสิทธิภาพสูงสุด

ทำไมโครงสร้าง `.claude/` ถึงสำคัญ

หลายคนที่ใช้ Claude Code รู้ว่าในโปรเจกต์มีโฟลเดอร์ .claude/ อยู่ แต่ไม่ค่อยได้คิดจริงจังว่าควรจัดโครงสร้างอย่างไรให้ดี

ช่วงแรกอาจไม่ใช่ปัญหา เพราะโปรเจกต์เล็ก ๆ มักอยู่ได้ด้วยไฟล์ CLAUDE.md เพียงไฟล์เดียว มี settings.json นิดหน่อย และอาจมีไฟล์เสริมอีกไม่กี่ไฟล์ แต่เมื่อโปรเจกต์เริ่มใหญ่ขึ้น วิธีจัดแบบง่าย ๆ นี้จะเริ่มสร้างปัญหา เช่น คำสั่งกระจัดกระจาย กฎซ้ำซ้อน workflow หายาก หรือมีไฟล์ทดลองปะปนกับไฟล์สำคัญ

การจัดโครงสร้าง .claude/ ให้ดีจึงไม่ใช่แค่เรื่องความเป็นระเบียบ แต่เป็นการสร้าง “ชั้นควบคุมการทำงาน” ให้ Claude เข้าใจโปรเจกต์ ทำงานตามมาตรฐานทีม และขยายระบบได้โดยไม่กลายเป็นความยุ่งเหยิง

A) `.claude/` ไม่ควรเป็นที่เก็บไฟล์แบบสุ่ม

ข้อผิดพลาดที่พบบ่อยคือทีมเริ่มใส่ทุกอย่างลงไปใน .claude/ โดยไม่มีหลักคิดชัดเจน เช่น instruction, script, prompt, rule, hook และไฟล์ทดลองต่าง ๆ อยู่ปะปนกันไปหมด

ตอนโปรเจกต์เล็กอาจยังพอใช้ได้ แต่เมื่อทีมใหญ่ขึ้น ปัญหาจะเริ่มชัดเจน:

ไม่รู้ว่าไฟล์ไหนยังใช้งานอยู่
ไม่รู้ว่ากฎไหนเป็นมาตรฐานทีม
ไม่รู้ว่า workflow ควรเพิ่มไว้ตรงไหน
CLAUDE.md ยาวเกินไปจนอ่านยาก
script อัตโนมัติปะปนกับคำอธิบายทั่วไป

โครงสร้างที่ดีควรทำให้ทุกไฟล์มี “ที่อยู่” และ “หน้าที่” ชัดเจน ตัวอย่างภาพรวมที่ดีคือ:

your-project/
├── CLAUDE.md # คำสั่งหลักของโปรเจกต์
├── CLAUDE.local.md # ค่าปรับแต่งส่วนตัว ไม่ควร commit
└── .claude/
├── settings.json # ชั้นควบคุมการทำงาน
├── rules/ # กฎย่อยแบบแยกโมดูล
├── hooks/ # script อัตโนมัติ
├── commands/ # workflow prompt ที่ใช้ซ้ำ
├── skills/ # ความสามารถเฉพาะทางแบบแพ็กเกจ
└── agents/ # subagent หรือบทบาทเฉพาะทาง

แนวคิดสำคัญคือ .claude/ ไม่ควรเป็น “กล่องเก็บของ” แต่ควรเป็นโครงสร้างที่บอก Claude และทีมว่า แต่ละส่วนมีไว้ทำอะไร

B. เริ่มจากแกนหลัก: `CLAUDE.md` และ `.claude/settings.json`

ไฟล์ที่สำคัญที่สุดมักอยู่ในระดับบนสุดของโปรเจกต์และโฟลเดอร์ .claude/

**CLAUDE.md**: คู่มือหลักของโปรเจกต์

CLAUDE.md ควรเป็นไฟล์แรกที่ Claude ใช้ทำความเข้าใจโปรเจกต์ โดยควรมีข้อมูลที่จำเป็นในเกือบทุก session เช่น:

โปรเจกต์นี้คืออะไร
ใช้ tech stack อะไร
โครงสร้างโค้ดหลักเป็นอย่างไร
command สำคัญมีอะไรบ้าง
convention กว้าง ๆ ของทีมคืออะไร
ข้อควรระวังระดับโปรเจกต์มีอะไร

ตัวอย่าง CLAUDE.md สำหรับโปรเจกต์ FastAPI:

Project: Customer Insights API

Stack

FastAPI
PostgreSQL
SQLAlchemy
Pytest

Structure

app/api/ contains route definitions
app/services/ contains business logic
app/models/ contains ORM models
app/schemas/ contains request and response schemas

Commands

pytest runs the test suite
alembic upgrade head applies migrations
ruff check . runs linting
ruff format . formats the code

Conventions

Validate all request bodies with Pydantic schemas
Keep route handlers thin; business logic belongs in services
Do not expose internal exception details in API responses

ไฟล์นี้ควรเป็นภาพรวม ไม่ใช่ที่เก็บกฎละเอียดทุกเรื่อง

**.claude/settings.json**: ชั้นควบคุมการทำงาน

settings.json ควรอยู่ที่ระดับบนสุดของ .claude/ เพราะเป็นไฟล์ที่ควบคุมพฤติกรรมการทำงานของ Claude Code เช่น:

permission
hook
behavior ระดับโปรเจกต์
คำสั่งที่อนุญาตหรือห้ามใช้

สรุปง่าย ๆ คือ:

CLAUDE.md = บอก Claude ว่าโปรเจกต์นี้ทำงานอย่างไร
settings.json = ควบคุมว่า Claude ทำอะไรได้บ้าง
subfolders = เก็บรายละเอียดเฉพาะทาง

อย่านำทุกอย่างไปใส่ในระดับบนสุดของ .claude/ เพราะจะทำให้โครงสร้างรกเร็วมาก

C. แยกคำสั่งหลักออกจากกฎเฉพาะทาง: `CLAUDE.md` vs `rules/`

หนึ่งในปัญหาที่พบบ่อยที่สุดคือใส่ทุกอย่างไว้ใน CLAUDE.md

ตอนแรกอาจสะดวก แต่เมื่อโปรเจกต์ใหญ่ขึ้น ไฟล์นี้จะกลายเป็นเอกสารยาวที่รวมทุกอย่าง ตั้งแต่ architecture, frontend rule, backend rule, testing rule, security rule ไปจนถึง checklist ย่อย ๆ ทำให้ทั้งคนและ Claude จับประเด็นหลักได้ยากขึ้น

แนวทางที่ดีกว่าคือ:

CLAUDE.md = คำแนะนำระดับกว้าง
rules/ = คำแนะนำเฉพาะเรื่องหรือเฉพาะพื้นที่ของโค้ด

ตัวอย่างโครงสร้าง:

your-project/
├── CLAUDE.md
└── .claude/
└── rules/
├── frontend.md
├── backend-api.md
├── testing.md
└── data-pipelines.md

แต่ละไฟล์มีหน้าที่ชัดเจน:

frontend.md เก็บ convention ของ UI
backend-api.md เก็บกฎของ API และ validation
testing.md เก็บแนวทางเขียนและรัน test
data-pipelines.md เก็บกฎของ batch job หรือ scheduled task

ตัวอย่าง backend-api.md:

Backend API Rules

Every new endpoint must include request and response schemas
Use dependency injection for database sessions
Return paginated results for collection endpoints
Log external API failures with the shared logger
Prefer service-layer functions over logic inside route files

ตัวอย่าง frontend.md:

Frontend Rules

Prefer server components unless client interactivity is required
Keep UI state local unless it is shared across pages
Reuse design system components before creating new ones
Put page-specific components beside their route when possible

เมื่อแยกแบบนี้ CLAUDE.md จะยังอ่านง่าย ส่วนรายละเอียดเฉพาะทางก็ยังหาเจอง่ายและแก้ไขได้ตรงจุด

D. จัดไฟล์ที่ “ทำงานจริง” แยกจากไฟล์คำแนะนำ: `hooks/` และ `commands/`

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

**hooks/**: script ที่ทำงานอัตโนมัติ

hooks/ คือที่เก็บ script ที่รันอัตโนมัติตามจุดต่าง ๆ ใน workflow ของ Claude เช่น:

ป้องกันคำสั่งอันตราย
format ไฟล์หลังแก้ไข
run test ก่อนจบงาน
ตรวจสอบว่าไม่แตะไฟล์ลับ เช่น .env

ตัวอย่าง:

.claude/
├── settings.json
├── hooks/
│ ├── block-dangerous-commands.sh
│ ├── format-edits.sh
│ └── run-tests-before-stop.sh

ชื่อไฟล์ควรสื่อหน้าที่ทันที เช่น format-edits.sh ดีกว่า script1.sh หรือ helper.sh

**commands/**: workflow prompt ที่ใช้ซ้ำ

commands/ เหมาะสำหรับ prompt หรือ workflow ที่ทีมเรียกใช้บ่อย แต่ไม่ได้ต้องรันอัตโนมัติ เช่น:

review pull request
เขียน test เพิ่ม
สรุป change log
debug bug report
เตรียม release note

ตัวอย่าง:

.claude/
└── commands/
├── review-pr.md
├── write-tests.md
└── summarize-changes.md

ตัวอย่าง review-pr.md:

review-pr

Review the current changes with a focus on:

correctness
missing edge cases
API contract changes
test coverage gaps
Summarize:

critical issues
medium-risk issues
suggested improvements

สรุปโครงสร้างที่ชัดเจนคือ:

CLAUDE.md = อธิบายโปรเจกต์
rules/ = กฎเฉพาะทาง
hooks/ = script อัตโนมัติ
commands/ = prompt workflow ที่ใช้ซ้ำ

เมื่อแยกแบบนี้ ทีมจะรู้ทันทีว่าไฟล์ใหม่ควรอยู่ตรงไหน

E. ใช้ `skills/` และ `agents/` เมื่อ workflow เริ่มซับซ้อนจริง ๆ

skills/ และ agents/ เป็นส่วนที่มีประโยชน์มาก แต่ไม่ควรรีบสร้างตั้งแต่แรกเพียงเพราะดู advanced

**skills/**: workflow ที่มีหลายขั้นตอนและมีไฟล์ประกอบ

skills/ เหมาะกับ workflow ที่ซับซ้อนกว่าคำสั่ง prompt ธรรมดา เช่น:

release preparation
API audit
documentation audit
onboarding docs
migration review

โครงสร้างที่ดีคือให้แต่ละ skill เป็นโฟลเดอร์ของตัวเอง:

.claude/
└── skills/
├── api-review/
│ ├── SKILL.md
│ └── checklist.md
├── release-prep/
│ ├── SKILL.md
│ └── release-template.md
└── docs-audit/
├── SKILL.md
└── style-guide.md

แนวคิดคือ:

commands/ = งานสั้น ใช้ซ้ำได้ในไฟล์เดียว
skills/ = workflow ลึกกว่า มีหลายขั้นตอนหรือมีไฟล์ประกอบ

ตัวอย่างเช่น release preparation อาจต้องตรวจ change, migration, breaking change, version note และ draft release summary งานแบบนี้ควรเป็น skill มากกว่า command ธรรมดา

**agents/**: บทบาทเฉพาะทาง

agents/ ใช้เมื่อทีมต้องการ subagent ที่มีบทบาทชัดเจน เช่น:

code reviewer
security auditor
documentation editor
performance reviewer
migration checker

ตัวอย่าง:

.claude/
└── agents/
├── code-reviewer.md
├── security-auditor.md
├── docs-writer.md
└── performance-checker.md

แต่ละ agent ควรมีหน้าที่เดียว ไม่ควรทับซ้อนกันมากเกินไป หากมี code-reviewer.md, api-reviewer.md, backend-reviewer.md ที่ทำงานคล้ายกันมาก อาจต้องรวมให้ชัดขึ้น

หลักสำคัญคืออย่าใช้ skills/ และ agents/ เป็นที่เก็บไฟล์ทดลอง เพราะจะทำให้ระบบดูซับซ้อนแต่ใช้งานจริงยาก

F. แยกโครงสร้างของทีมออกจากโครงสร้างส่วนตัว

.claude/ ที่ดีควรแยกให้ชัดว่าอะไรเป็นมาตรฐานทีม และอะไรเป็น preference ส่วนตัวของ developer

ไฟล์ระดับทีม

ไฟล์ที่ช่วยให้ทุกคนในทีมทำงานสอดคล้องกันควรอยู่ใน repository เช่น:

your-project/
├── CLAUDE.md
└── .claude/
├── settings.json
├── rules/
│ ├── api.md
│ ├── testing.md
│ └── security.md
├── hooks/
│ ├── block-secrets-access.sh
│ └── run-tests-before-stop.sh
└── commands/
├── review-pr.md
└── investigate-bug.md

สิ่งเหล่านี้ควรเป็นมาตรฐานร่วม เช่น API convention, security rule, test workflow และ hook ที่ทีมต้องการใช้เหมือนกัน

ไฟล์ส่วนตัว

สิ่งที่เป็นนิสัยการทำงานส่วนบุคคลควรอยู่ใน local file หรือ global config เช่น:

~/.claude/
├── CLAUDE.md
├── skills/
│ ├── article-outline/
│ │ ├── SKILL.md
│ │ └── outline-template.md
│ └── sql-review/
│ ├── SKILL.md
│ └── checklist.md
└── agents/
├── documentation-editor.md
└── sql-reviewer.md

ตัวอย่างไฟล์ local ภายในโปรเจกต์:

your-project/
├── CLAUDE.md
├── CLAUDE.local.md
└── .claude/
├── settings.json
└── settings.local.json

CLAUDE.local.md และ settings.local.json เหมาะสำหรับ preference ส่วนตัวหรือการทดลองที่ไม่ควรถูก commit เป็นมาตรฐานทีม

หลักคิดง่าย ๆ คือ:

ถ้าช่วยให้ทั้งทีมทำงานสอดคล้องกัน → อยู่ใน project
ถ้าเป็นสไตล์หรือเครื่องมือส่วนตัว → อยู่ใน local หรือ ~/.claude/

G. Blueprint โครงสร้าง `.claude/` ที่ใช้งานได้จริง

สำหรับโปรเจกต์ที่เริ่มโตแล้ว โครงสร้างที่สมดุลอาจเป็นแบบนี้:

your-project/
├── CLAUDE.md
├── CLAUDE.local.md
└── .claude/
├── settings.json
├── settings.local.json
├── rules/
│ ├── backend.md
│ ├── frontend.md
│ ├── testing.md
│ └── security.md
├── hooks/
│ ├── block-dangerous-commands.sh
│ ├── format-edits.sh
│ └── run-checks-before-stop.sh
├── commands/
│ ├── review-pr.md
│ ├── write-tests.md
│ └── summarize-changes.md
├── skills/
│ └── release-prep/
│ ├── SKILL.md
│ └── release-template.md
└── agents/
├── code-reviewer.md
└── security-auditor.md

แต่ไม่ใช่ทุกโปรเจกต์ต้องเริ่มจากโครงสร้างเต็มแบบนี้

สำหรับโปรเจกต์เล็ก อาจพอแค่นี้:

your-project/
├── CLAUDE.md
└── .claude/
├── settings.json
├── rules/
│ ├── testing.md
│ └── security.md
└── hooks/
└── format-edits.sh

ลำดับการเติบโตที่เหมาะสมคือ:

เริ่มจาก CLAUDE.md และ settings.json
เพิ่ม rules/ เมื่อ CLAUDE.md เริ่มยาวหรือมีหลายบริบท
เพิ่ม hooks/ เมื่ออยากบังคับ automation หรือ safety
เพิ่ม commands/ เมื่อมี prompt workflow ที่ใช้ซ้ำบ่อย
เพิ่ม skills/ เมื่อ workflow ซับซ้อนและต้องมีไฟล์ประกอบ
เพิ่ม agents/ เมื่อต้องการบทบาทเฉพาะทางจริง ๆ

ประสิทธิภาพไม่ได้มาจากการมี folder เยอะ แต่มาจากการเพิ่มโครงสร้างเมื่อ workflow ต้องการจริง ๆ

G. ข้อผิดพลาดที่ควรหลีกเลี่ยง

ใส่ทุกอย่างไว้ใน CLAUDE.md CLAUDE.md ควรเป็นคู่มือหลัก ไม่ใช่คลังเก็บทุกกฎ ทุก checklist และทุก workflow หากเริ่มยาวเกินไป ให้แยกไปไว้ใน rules/
สร้าง folder ล่วงหน้าทั้งที่ยังไม่จำเป็น
อย่าสร้าง skills/, agents/ หรือ command จำนวนมากเพียงเพราะดูดี หากยังไม่มี workflow ที่ต้องใช้จริง โครงสร้างจะกลายเป็นภาระมากกว่าประโยชน์
ปนมาตรฐานทีมกับ preference ส่วนตัว
ไฟล์ที่ commit เข้า repo ควรสะท้อนมาตรฐานของทีม ไม่ใช่วิธีทำงานของคนใดคนหนึ่ง
ปล่อยไฟล์เก่าค้างไว้
ไฟล์ทดลองหรือ workflow ที่เลิกใช้แล้วควรถูกลบหรือย้ายออก ไม่อย่างนั้นทีมจะไม่รู้ว่าไฟล์ไหนยัง active อยู่
เอาสิ่งที่ควรเป็น config ของ tool มาเขียนเป็น instruction ให้ Claude
ถ้ากฎนั้นควรถูกบังคับโดย formatter, linter, test runner หรือ build tool ก็ควรอยู่ใน config ของ tool นั้น ไม่ใช่เขียนซ้ำใน .claude/
ตั้งชื่อไฟล์ไม่ชัด
ชื่ออย่าง misc.md, helper.sh, temp-review.md ทำให้โครงสร้างอ่านยาก ควรใช้ชื่อที่สื่อหน้าที่ เช่น:

review-pr.md
write-tests.md
block-dangerous-commands.sh
format-edits.sh

Terminology You Should Know

Key Takeaways

.claude/ ที่ดีไม่ใช่โฟลเดอร์ที่มีไฟล์เยอะที่สุด แต่คือโฟลเดอร์ที่ทุกไฟล์มีหน้าที่ชัดเจน
CLAUDE.md ควรเก็บภาพรวมของโปรเจกต์ ส่วนกฎเฉพาะทางควรแยกไปไว้ใน rules/
hooks/ ใช้สำหรับ automation ส่วน commands/ ใช้สำหรับ workflow prompt ที่เรียกใช้ซ้ำ
skills/ และ agents/ ควรถูกเพิ่มเมื่อ workflow ซับซ้อนพอ ไม่ใช่เพิ่มเพียงเพราะอยากให้โครงสร้างดู advanced
แยกมาตรฐานทีมออกจาก preference ส่วนตัวเสมอ เพื่อให้ shared config น่าเชื่อถือและดูแลต่อได้ง่าย

Closing: ประสิทธิภาพสูงสุดมาจากความชัดเจน

การจัดโครงสร้าง .claude/ ให้ดีคือการทำให้ Claude ทำงานในโปรเจกต์ได้อย่างมีทิศทาง ไม่ใช่แค่เพิ่มไฟล์ config ให้มากขึ้น

โครงสร้างที่ดีควรเริ่มเรียบง่าย มี CLAUDE.md เป็นศูนย์กลาง มี settings.json ควบคุมพฤติกรรม และค่อย ๆ เพิ่ม rules/, hooks/, commands/, skills/, agents/ เมื่อ workflow ต้องการจริง ๆ

ท้ายที่สุด .claude/ ที่มีประสิทธิภาพที่สุดไม่ใช่แบบที่ซับซ้อนที่สุด แต่คือแบบที่ทั้งทีมเปิดดูแล้วเข้าใจทันทีว่าอะไรอยู่ตรงไหน ใช้ทำอะไร และยังจำเป็นอยู่หรือไม่

ความชัดเจนคือหัวใจของประสิทธิภาพ ทั้งสำหรับคนในทีมและสำหรับ Claude เอง.

ต่อด้วยบทความที่สองที่ของ Reference: allglenn

2. ก้าวสู่ผู้ใช้ Claude Code ระดับ Top 1%: Playbook ฉบับครบสำหรับนักพัฒนาที่อยากใช้ Claude Code ให้เกินกว่า Autocomplete

หลายคนยังใช้ Claude Code ได้ไม่ถึงศักยภาพจริง

นักพัฒนาส่วนใหญ่ใช้ Claude Code เหมือนเป็น autocomplete ที่ฉลาดขึ้น หรือเป็น Stack Overflow เวอร์ชันเร็วกว่าเดิม พิมพ์คำสั่ง อธิบาย feature ให้ Claude เขียนไฟล์ แล้วเราค่อยตรวจ แก้ และส่งงาน

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

ผู้ใช้ Claude Code ระดับ Top 1% คิดต่างออกไป พวกเขาไม่ได้แค่ “prompt เก่งกว่า” แต่สร้างระบบให้ Claude ทำงานได้เหมือนทีมวิศวกรรมที่ตั้งโปรแกรมได้ มี CLAUDE.md ที่ให้ context ถูกต้องทุก session มี hooks ที่บังคับ quality gate อัตโนมัติ มี subagents ที่ทำงานคู่ขนาน และมี MCP integrations ที่เชื่อม Claude เข้ากับ GitHub, database, CI, Jira หรือ internal tools

บทความนี้จะพาไล่ตั้งแต่พื้นฐานสำคัญไปจนถึง workflow ขั้นสูง เพื่อให้คุณเปลี่ยนจากการใช้ Claude Code แบบผู้ช่วยเขียนโค้ดธรรมดา ไปสู่การใช้เป็น programmable engineering infrastructure

A. เข้าใจ Claude Code ให้ถูก: ไม่ใช่แค่ Coding Assistant แต่เป็น Agent Orchestration Framework

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

นักพัฒนาทั่วไปมักใช้ Claude Code เพียงชั้นเดียว คือให้ Claude อ่านคำสั่งและแก้โค้ด แต่ผู้ใช้ระดับสูงจะใช้หลายองค์ประกอบร่วมกัน เช่น:

CLAUDE.md สำหรับ memory และ project context
settings.json สำหรับ permission และ behavior
hooks สำหรับ automation และ quality gate
subagents สำหรับงานเฉพาะทางและงานคู่ขนาน
MCP servers สำหรับเชื่อมต่อข้อมูลและเครื่องมือภายนอก
commands และ skills สำหรับ workflow ที่ใช้ซ้ำได้

ความต่างสำคัญคือ นักพัฒนาทั่วไป “ใช้ Claude” ส่วนผู้ใช้ระดับสูง “ออกแบบระบบให้ Claude ทำงานได้ดี”

นี่คือ mindset ที่เปลี่ยนทุกอย่าง

B. Claude Code ต่างจาก Copilot และ Cursor อย่างไร

ตลาด AI coding tools มีตัวเลือกมากมาย เช่น GitHub Copilot, Cursor, Windsurf, Codeium และ Amazon Q แต่ Claude Code มีแนวคิดที่ต่างออกไป

GitHub Copilot: autocomplete ที่เก่งมาก

Copilot เหมาะกับการช่วยเติมโค้ดทีละบรรทัด แนะนำ syntax หรือช่วยเขียน function เล็ก ๆ ใน editor ได้รวดเร็ว จุดแข็งคือความลื่นไหลใน VS Code และการทำงานแบบ inline

แต่ข้อจำกัดคือ Copilot มักไม่มี memory ระดับโปรเจกต์ ไม่มีระบบ hook ไม่มี subagent และไม่ได้ถูกออกแบบให้รัน workflow ทั้งชุดแทนเรา

เหมาะกับคนที่ต้องการ suggestion เร็ว ๆ โดยไม่เปลี่ยน workflow เดิมมากนัก

Cursor: editor-first AI workflow

Cursor ขยายแนวคิดจาก autocomplete ไปสู่การแก้หลายไฟล์และมี UI ที่ใช้ง่ายกว่า AI coding tools หลายตัว เหมาะกับงานระดับกลาง เช่น refactor หลายไฟล์หรือสร้าง feature จาก prompt

แต่ยังมีข้อจำกัดเมื่อเทียบกับ Claude Code ในด้าน hook, subagent, CLI integration และ MCP workflow อีกทั้งยังผูกกับ editor ของ Cursor เอง

เหมาะกับนักพัฒนาที่ชอบ GUI และต้องการประสบการณ์ AI coding ที่ polished

Claude Code: project-level agent system

Claude Code ทำงานในระดับโปรเจกต์ สามารถอ่าน codebase วางแผนหลายไฟล์ แก้โค้ด รัน test อ่าน error แล้ววนแก้จนผ่านได้

จุดต่างสำคัญคือ Claude Code มีระบบที่ทำให้ workflow กลายเป็น infrastructure ได้ เช่น:

memory ผ่าน CLAUDE.md
automation ผ่าน hooks
parallel work ผ่าน subagents
external tools ผ่าน MCP
การทำงานผ่าน terminal, IDE หรือ browser

ความต่างเชิงปรัชญาคือ Copilot และ Cursor เป็น “เครื่องมือที่เราใช้” แต่ Claude Code เป็น “ระบบที่เราตั้งค่าและ orchestrate”

C. เชี่ยวชาญ `CLAUDE.md`: จุดเริ่มต้นของผู้ใช้ระดับสูง

ทุก session ของ Claude Code เริ่มจากศูนย์ เว้นแต่คุณจะให้ memory ที่ดีผ่าน CLAUDE.md

CLAUDE.md คือไฟล์ที่ Claude โหลดอัตโนมัติทุกครั้ง เพื่อเข้าใจโปรเจกต์ วิธีทำงาน และข้อควรระวังสำคัญ

ปัญหาคือหลายคนใส่ทุกอย่างลงไปใน CLAUDE.md จนไฟล์ยาวเกินไป แล้ว Claude ก็เริ่มละเลยบางส่วน

แนวคิดที่ถูกต้องคือ CLAUDE.md ไม่ควรเป็นคู่มือบริษัท 400 หน้า แต่ควรเป็น brief สั้น ๆ ที่มีเฉพาะสิ่งที่ Claude ต้องรู้จริง ๆ

โครงสร้างที่ดีของ `CLAUDE.md`

ควรตอบ 3 เรื่องหลัก:

WHAT = โปรเจกต์นี้ใช้ stack อะไร
WHY = ทำไมถึงตัดสินใจแบบนี้
HOW = Claude ควรทำงานอย่างไรใน codebase นี้

WHAT: บอก stack แต่ไม่ต้องยัดรายละเอียดทั้งหมด

ไม่จำเป็นต้อง copy package.json หรือ README ทั้งหมดลงไป ให้ reference แทน เช่น:

See @package.json for dependencies.
See @README.md for architecture overview.

WHY: บอกเหตุผลเบื้องหลัง decision

Claude จะตัดสินใจย่อย ๆ ได้ดีขึ้นเมื่อเข้าใจเหตุผล เช่น:

We use server-side rendering because many users are on slow connections in rural markets.

ประโยคนี้มีค่ากว่าแค่เขียนว่า “use SSR” เพราะทำให้ Claude เข้าใจ trade-off

HOW: ใส่สิ่งที่ Claude มักทำผิด

ส่วนนี้สำคัญที่สุด อย่าเสียพื้นที่ไปกับสิ่งที่ Claude ทำถูกอยู่แล้ว เช่น ถ้า Claude ใช้ TypeScript ถูกเสมอ ก็ไม่ต้องเขียนว่า “Use TypeScript”

แต่ถ้า Claude ชอบใช้ CommonJS ในโปรเจกต์ที่ใช้ ESM ให้เขียนให้ชัด:

Always use ESM imports. Do not use CommonJS require.

ลำดับตำแหน่งของ `CLAUDE.md`

~/.claude/CLAUDE.md = global ใช้กับทุก session
./CLAUDE.md = project root ควร commit เข้า git
./CLAUDE.local.md = preference ส่วนตัว ควรใส่ .gitignore
./src/api/CLAUDE.md = โหลดเมื่อทำงานใน directory นี้
./src/db/CLAUDE.md = โหลดเมื่อทำงานด้าน database

เทคนิคที่หลายคนมองข้ามคือการใช้ CLAUDE.md ใน subdirectory แทนที่จะยัดทุก module convention ไว้ใน root file

เช่น กฎของ API ควรอยู่ใน src/api/CLAUDE.md ส่วนกฎ database ควรอยู่ใน src/db/CLAUDE.md วิธีนี้ช่วยประหยัด instruction budget และทำให้ context เฉพาะพื้นที่ชัดเจนขึ้น

Anti-pattern ที่ทำให้ Claude ไม่ทำตาม

ข้อผิดพลาดที่ควรเลี่ยง:

ใส่ทุกอย่างไว้ในไฟล์เดียวจนยาวเกินไป
เขียนสิ่งที่ Claude ทำถูกอยู่แล้ว
ใช้คำสั่งห้ามแบบคลุมเครือ เช่น “Never use X” แต่ไม่บอกว่าควรใช้อะไรแทน
ใช้ CLAUDE.md กับสิ่งที่ควรถูกบังคับด้วย settings.json

หลักทดสอบง่าย ๆ ก่อนเพิ่มบรรทัดใหม่คือ:

ถ้าไม่มีบรรทัดนี้ Claude จะทำพลาดใน codebase นี้จริงไหม?

ถ้าคำตอบคือไม่ ให้ลบบรรทัดนั้นออก

D. Hooks: จุดที่ Claude Code เริ่มกลายเป็น Infrastructure

Hooks คือ shell command หรือ script ที่รันอัตโนมัติในจังหวะต่าง ๆ ของ lifecycle เช่น ก่อน Claude ใช้ tool หลังเขียนไฟล์ หรือเมื่อ session จบ

ข้อดีของ hooks คือมันไม่พึ่งดุลยพินิจของ Claude ถ้าตั้งไว้ มันจะรันเสมอ

นี่คือจุดที่ Claude Code เริ่มเปลี่ยนจาก “ผู้ช่วย” เป็น “ระบบที่ enforce workflow ได้”

ตัวอย่าง hooks ใน .claude/settings.json

{
"hooks": {
"PostToolUse": [
{
"matcher": "Write",
"hooks": [
{
"type": "command",
"command": "cd $PROJECT_ROOT && npm run lint --fix"
}
]
}
],
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "python .claude/hooks/block_dangerous.py"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "python .claude/hooks/session_summary.py"
}
]
}
]
}
}

ในตัวอย่างนี้:

หลัง Claude เขียนไฟล์ จะรัน lint อัตโนมัติ
ก่อนใช้ Bash จะตรวจว่าคำสั่งอันตรายหรือไม่
เมื่อ session จบ จะสร้าง summary

Hook สำหรับป้องกันคำสั่งอันตราย

ไฟล์อย่าง block_dangerous.py อาจอ่าน tool_input.command จาก stdin แล้ว block คำสั่งเช่น:

rm -rf
git push --force
DROP TABLE

หากพบคำสั่งอันตราย script สามารถ exit ด้วย code ที่ทำให้ Claude ได้รับ feedback และหยุดการกระทำนั้น

นี่คือ safety layer ที่ไม่ควรปล่อยให้เป็นแค่คำเตือนใน prompt

E. Subagents: ความสามารถที่ทำให้ Claude Code แตกต่างจริง ๆ

Subagents คือการสร้าง Claude instances ย่อยที่มี context, system prompt, permission และ model ของตัวเอง

แทนที่จะให้ session หลักทำทุกอย่าง คุณสามารถให้ subagent เฉพาะทางรับงานบางประเภท เช่น:

code review
security audit
test generation
documentation review
performance analysis
product spec writing

ข้อดีคือ session หลักยังสะอาดและโฟกัสที่ภาพรวม ส่วนงานหนักหรือการตรวจเฉพาะทางถูกแยกไปใน context อื่น

ตัวอย่าง subagent: code reviewer

สร้างไฟล์:

.claude/agents/code-reviewer.md

ตัวอย่างเนื้อหา:

name: code-reviewer
description: Reviews code for style, correctness, security, and performance. Use after any implementation is complete.
tools: Read, Grep, Glob, Bash
model: claude-opus-4-6

You are a staff engineer doing a thorough code review. Challenge every shortcut.
For each file changed, check:

Correctness - does this actually do what's intended?
Edge cases - what inputs would break this?
Security - any injection vectors, exposed secrets, auth gaps?
Performance - any O(n²) loops, unnecessary DB calls, memory leaks?
Readability - will a new team member understand this in 6 months?
Output: structured report with MUST FIX, SHOULD FIX, and CONSIDER sections.

Tool scoping สำคัญมาก

อย่าให้ subagent ทุกตัวมีสิทธิ์ทุกอย่างโดยไม่คิด

ถ้า agent มีหน้ที่อ่านอย่างเดียว ให้จำกัด tools:

name: safe-researcher
description: Reads codebase to answer questions. Cannot modify anything.
tools: Read, Grep, Glob

หลักคิดคือให้สิทธิ์เท่าที่จำเป็น โดยเฉพาะ agent ที่ใช้ตรวจสอบ security หรืออ่าน production data

F. Two-Claude Review Pattern: เทคนิคที่ให้ review ตรงไปตรงมามากที่สุด

หนึ่งในเทคนิคที่ทรงพลังมากคือใช้ Claude สอง session แยกกัน

Session A: implement feature

claude "implement the payment webhook handler, write tests, commit when passing"

Session A มี context ของการ implement ทั้งหมด รู้ว่าทำไมเลือกแบบนั้น และอาจมีอคติจาก decision ที่ตัวเองเพิ่งทำ

Session B: review แบบ cold read

claude "review the last commit on this branch as a staff engineer.
Check correctness, security, and edge cases.
Be harsh — this is going to production."

Session B ไม่มี context เดิม จึงอ่าน diff แบบสดใหม่และมักจับ shortcut, assumption หรือ edge case ที่ Session A มองข้าม

นี่คล้ายการมี reviewer อีกคนที่ไม่ติดกับเหตุผลเดิมของ implementer

G. MCP Servers: เชื่อม Claude Code เข้ากับโลกจริง

MCP หรือ Model Context Protocol คือวิธีเชื่อม Claude Code เข้ากับเครื่องมือและข้อมูลภายนอก เช่น:

GitHub
PostgreSQL
Jira
Slack
internal APIs
CI/CD systems
monitoring tools

เมื่อใช้ MCP Claude ไม่ได้แค่อ่านไฟล์ในเครื่อง แต่สามารถ query database, อ่าน issue, ตรวจ GitHub Actions หรือดึง context จาก ticket ได้โดยตรง

ตัวอย่าง MCP config

{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "ghp_your_token_here"
}
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost/mydb"
}
}
}
}

เมื่อเชื่อมแล้ว คุณสามารถสั่ง Claude ด้วยภาษาธรรมดา เช่น:

Check the last 5 failing GitHub Actions runs and identify the common pattern.

Query the users table to understand the schema before writing the migration.

Find the Jira ticket for this bug and add a comment with the fix approach.

Principle of Least Privilege สำคัญที่สุด

MCP ควรตั้งแบบ read-only เป็นค่าเริ่มต้น

ส่วนใหญ่ Claude ต้อง “อ่าน” database หรือ issue เพื่อเข้าใจบริบท ไม่ได้จำเป็นต้อง “เขียน” เสมอไป

แนวทางที่ปลอดภัยคือ:

มี MCP read-only สำหรับ debugging และ exploration
มี MCP read-write เฉพาะ dev environment
ไม่ให้ Claude เขียน production database โดยตรง
จำกัด permission ตามบทบาทของ subagent

ตัวอย่างเช่น code-reviewer อาจมีสิทธิ์อ่าน schema database แต่ไม่มีสิทธิ์แก้ข้อมูล ส่วน implementer อาจมีสิทธิ์เขียนเฉพาะ dev database เท่านั้น

H. Skills vs MCP: ควรใช้อะไรเมื่อไร

หลายคนสับสนว่าควรสร้าง skill หรือ MCP server

หลักคิดง่าย ๆ คือ:

Skills = สอน workflow หรือ domain knowledge ให้ Claude
MCP = ให้ Claude เข้าถึง live data หรือ external actions

ใช้ Skills เมื่อ

คุณต้องการบอก Claude ว่า “เราทำงานแบบนี้” เช่น:

วิธี deploy ไป staging หรือ production
database convention ของทีม
API design pattern
checklist สำหรับ release
style guide ของเอกสาร

ใช้ MCP เมื่อ

คุณต้องการให้ Claude เชื่อมกับข้อมูลหรือ tool จริง เช่น:

query database
อ่าน GitHub issue
ตรวจ CI status
สร้าง pull request
comment ใน Jira
อ่าน Slack thread

ถ้าไม่แน่ใจ ให้เริ่มจาก skill ก่อน เพราะ skill เป็น markdown อ่านง่าย audit ง่าย และปลอดภัยกว่า MCP server ที่อาจมี side effect จริง

I. ตัวอย่าง Workflow จริง: สร้าง API Endpoint ตั้งแต่ Spec ถึง PR

สมมติว่าคุณต้องสร้าง endpoint ใหม่:

/api/v2/recommendations

ต้อง return personalized content recommendation จาก user history มี Redis caching, auth middleware และ tests ครบ

Step 0: `CLAUDE.md` พร้อมอยู่แล้ว

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

ไม่ต้องเริ่มอธิบายใหม่ทุก session

Step 1: ใช้ interview pattern เพื่อสร้าง spec

claude "I want to build a /api/v2/recommendations endpoint.
Interview me using the AskUserQuestion tool.
Ask about auth, caching strategy, response shape, edge cases,
and performance constraints. Don't assume anything.
When we've covered everything, write a complete spec to SPEC.md."

แทนที่จะให้ Claude เดา requirement คุณให้มันถามกลับก่อนจน spec ชัด

Step 2: Implement พร้อม hooks ที่ทำงานอัตโนมัติ

เมื่อ Claude เริ่มเขียนไฟล์:

PostToolUse hook รัน lint อัตโนมัติ
PreToolUse hook block คำสั่งอันตราย
formatting เกิดขึ้นโดยไม่ต้องสั่งซ้ำ
test command พร้อมให้รันตาม workflow

คุณไม่ต้องคอยเตือนเรื่องพื้นฐานซ้ำ ๆ

Step 3: Review ด้วย subagent

หลัง implement หรือหลัง commit:

claude "Use the code-reviewer subagent on the changes in the last commit"

ตัวอย่างผลลัพธ์ที่ควรได้:

MUST FIX:

Redis connection not being released on error path
Auth middleware applied after rate limiter

SHOULD FIX:

Cache key doesn't include user locale
Missing test for empty history edge case
CONSIDER:
Could cache at CDN layer for anonymous user

Step 4: Fix และ validate

กลับมาที่ main session:

The reviewer found a Redis connection leak on the error path
and auth middleware in wrong order. Fix both, re-run tests.

Claude แก้ รัน test และ hooks ช่วยจัดคุณภาพให้อัตโนมัติ

Step 5: Security audit

claude "Use the security-auditor subagent on this feature"

security auditor ตรวจเรื่อง injection, auth gap, secret exposure และ rate limiting

Step 6: สร้าง PR อัตโนมัติ

claude "Create a PR for this feature. Include the spec,
what was changed and why, test coverage summary,
and any known limitations."

ถ้ามี GitHub MCP และ Jira MCP Claude สามารถสร้าง PR, ใส่ description, link ticket และ request reviewer ได้

นี่คือ workflow ที่เปลี่ยน Claude Code จาก “ผู้ช่วยเขียนโค้ด” เป็น “development pipeline”

J. Advanced Patterns ที่ผู้ใช้ระดับสูงควรรู้

จัดการ context ให้ดี

Context window มีจำกัด เมื่อเต็ม Claude จะ compact อัตโนมัติ แต่การ compact อัตโนมัติอาจทำให้รายละเอียดสำคัญหายไป

แนวทางที่ดีกว่า:

ใช้ /compact เองเมื่อ context ใช้ไปประมาณครึ่งหนึ่ง
บอกใน CLAUDE.md ว่าตอน compact ต้อง preserve อะไร

ตัวอย่าง:

When compacting, always preserve:

list of modified files
current test status
unresolved issues
pending decisions

ใช้ **/loop** สำหรับ monitoring

ตัวอย่าง:

/loop 5m check if the CI pipeline on branch feat/recommendations passed and report back

/loop 30m check for any new failing tests on main

เหมาะกับงานที่ต้องตรวจซ้ำเป็นระยะ เช่น CI, failing tests หรือ deployment status

เลือก model ให้เหมาะกับงาน

ไม่ใช่ทุกงานต้องใช้ model แพงหรือใหญ่ที่สุด

ตัวอย่างแนวคิด:

claude --model claude-sonnet-4-6 # งาน coding ทั่วไป
claude --model claude-opus-4-6 # architecture หรือ refactor ซับซ้อน
claude --model claude-haiku-4-5 # lookup ง่าย ๆ หรือ fix เล็ก

คุณยังสามารถกำหนด model ต่อ subagent ได้ เช่น ให้ code reviewer ใช้ model ที่เก่งกว่า แต่ให้ task ง่าย ๆ ใช้ model ที่เร็วกว่า

ใช้ voice workflow เมื่อคิดออกเสียงง่ายกว่าเขียน

สำหรับงาน exploratory หรือ brainstorming การใช้ voice mode ทำให้คุณอธิบายความคิดได้เร็วขึ้น โดยเฉพาะตอนที่ requirement ยังไม่ชัด

K. โครงสร้างโปรเจกต์ Claude Code ระดับ Production-grade

ตัวอย่างโครงสร้างที่ดี:

your-project/
├── CLAUDE.md
├── CLAUDE.local.md
├── .claude/
│ ├── settings.json
│ ├── agents/
│ │ ├── code-reviewer.md
│ │ ├── test-writer.md
│ │ ├── security-auditor.md
│ │ └── pm-spec.md
│ ├── skills/
│ │ ├── deploy.md
│ │ ├── database-patterns.md
│ │ └── api-design.md
│ ├── commands/
│ │ ├── review-pr.md
│ │ ├── ship.md
│ │ └── diagnose.md
│ └── hooks/
│ ├── block_dangerous.py
│ ├── auto_format.sh
│ └── session_summary.py

ตัวอย่าง **CLAUDE.md** แบบ minimum viable

Project: [Name]

Stack

Node.js 22, TypeScript 5.4, Fastify 4
PostgreSQL 16 + Drizzle ORM
Redis 7 for caching
Jest for testing
See @package.json for all dependencies.
See @docs/architecture.md for system design.

How to work on this project

Run tests: npm test
Run single test: npm test -- --testPathPattern=auth
Typecheck: npm run typecheck
Lint: npm run lint

Things to get right

Always use ESM imports (not CommonJS require)
Redis keys must include version prefix: v2:user:{id}:...
Auth middleware must run BEFORE rate limiting in route registration
All DB queries go through the service layer, never directly in routes

Git workflow

Never commit to main directly
Branch naming: feat/, fix/, chore/
Commit messages: conventional commits format

ไฟล์นี้สั้น แต่มีสิ่งที่ Claude ต้องใช้จริง นี่คือหัวใจของ CLAUDE.md ที่ดี

L. Mindset ของผู้ใช้ Claude Code ระดับ Top 1%

ความต่างหลักไม่ใช่การ prompt ให้สวยกว่า แต่คือการคิดแบบ system designer

คนทั่วไปคิดว่า:

“ฉันจะให้ Claude ทำ task นี้ แล้วดูว่ามันทำได้ดีแค่ไหน”

ผู้ใช้ระดับสูงคิดว่า:

“ฉันจะออกแบบระบบให้ Claude ทำงานได้ดี โดยต้อง supervision น้อยที่สุด”

นี่คือ infrastructure mindset

คุณลงทุนล่วงหน้าในการเขียน CLAUDE.md ที่ดี ตั้ง hooks สร้าง subagents จำกัด permission และเชื่อม MCP จากนั้นทุก session ในอนาคตจะได้ประโยชน์ซ้ำ ๆ

นักพัฒนาที่ใช้ Claude Code ได้ดีที่สุดไม่ใช่คนที่ prompt เก่งที่สุด แต่คือคนที่ออกแบบ workflow ได้ดีที่สุด

พวกเขาคิดว่า:

context จะเสื่อมตรงไหน
quality gate อะไรควรเป็นอัตโนมัติ
อะไรควรให้มนุษย์ตัดสินใจ
งานส่วนไหนรันขนานได้
agent ไหนควรมี permission แค่ไหน
workflow ไหนควรถูกทำซ้ำเป็น command หรือ skill

เปรียบเทียบง่าย ๆ คือ ไม่ใช่การขับรถเก่งขึ้น แต่คือการสร้างถนนที่ดีกว่า

M. Action Plan สำหรับเริ่มใช้ในสัปดาห์นี้

Day 1: สร้าง CLAUDE.md ที่ดี
ใช้ /init ในโปรเจกต์หลัก แล้วลบส่วนที่ไม่จำเป็นออกให้มากที่สุด ใส่เฉพาะสิ่งที่ Claude มักทำผิด และเริ่มจากไฟล์ไม่เกิน 50 บรรทัด
Day 2: เพิ่ม hook แรก
เริ่มจาก PostToolUse hook ที่รัน linter หลัง Claude เขียนไฟล์ แค่นี้ก็ลดงานตรวจ manual ได้มาก
Day 3: ลอง Two-Claude Review
หลังทำ feature เสร็จ เปิดอีก session ให้ Claude review commit แบบ cold read แล้วเทียบกับสิ่งที่คุณตรวจเจอเอง
Day 4: สร้าง subagent ตัวแรก
เริ่มจาก code-reviewer ใน .claude/agents/ แล้วใช้กับ PR จริง
Day 5: เชื่อม MCP server หนึ่งตัว
เริ่มจาก GitHub MCP เพื่อให้ Claude อ่าน issue, PR หรือ CI context ได้โดยไม่ต้อง copy-paste
Week 2+: ค่อย ๆ เพิ่มระบบ
ปรับ CLAUDE.md จากข้อผิดพลาดจริง เพิ่ม skills สำหรับ domain-specific workflow และค่อย ๆ สร้าง pipeline ที่เหมาะกับทีม

Terminology You Should Know

Key Takeaways

ผู้ใช้ Claude Code ระดับ Top 1% ไม่ได้แค่ prompt เก่ง แต่สร้างระบบให้ Claude ทำงานได้ดีซ้ำ ๆ
CLAUDE.md ควรสั้น ชัด และใส่เฉพาะสิ่งที่ Claude ต้องรู้จริง โดยเฉพาะสิ่งที่มันมักทำผิดใน codebase ของคุณ
Hooks ช่วยเปลี่ยน quality gate จากคำแนะนำให้กลายเป็น automation ที่รันจริงทุกครั้ง
Subagents ทำให้คุณแยกงานเฉพาะทาง เช่น review, security audit และ test generation ออกจาก session หลักได้
MCP ทำให้ Claude เชื่อมกับโลกจริง เช่น GitHub, database, CI และ internal tools แต่ต้องใช้ด้วยหลัก least privilege เสมอ

Claude Code มีองค์ประกอบครบสำหรับสร้าง development workflow ที่เกือบอัตโนมัติได้แล้ว ไม่ว่าจะเป็น CLAUDE.md, hooks, subagents, skills, commands และ MCP integrations

แต่เครื่องมือเหล่านี้จะไม่สร้างผลลัพธ์ระดับสูงเอง หากเรายังใช้ Claude Code เหมือน chatbot ใน terminal

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

สร้าง CLAUDE.md ให้กระชับ ตั้ง hooks เพื่อบังคับคุณภาพ สร้าง subagents สำหรับงานเฉพาะทาง เชื่อม MCP อย่างปลอดภัย แล้วปรับปรุงจากสิ่งที่พังจริง

กลุ่ม Top 1% ไม่ใช่กลุ่มปิด แต่คือคนที่มอง AI tooling แบบวิศวกร: เป็นระบบที่ต้องออกแบบ วัดผล ปรับปรุง และทำให้ดีขึ้นเรื่อย ๆ

ต่อด้วยบทความที่สามของ Tort Mario

3. Skills สำหรับ Claude Code: คู่มือฉบับครบจากประสบการณ์ใช้งานจริงภายใน Anthropic

ทำไม Skills ถึงกลายเป็นจุดต่อขยายสำคัญของ Claude Code

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

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

บทความนี้สรุปแนวคิดจากประสบการณ์ใช้งาน Skills จำนวนมากภายใน Anthropic โดยแก่นสำคัญคือ Skills ไม่ใช่แค่ไฟล์ Markdown แต่เป็น “โฟลเดอร์ความสามารถ” ที่สามารถมีทั้งคำแนะนำ script, assets, data, template, hooks และ logic สนับสนุนให้ Claude ทำงานได้ฉลาดและแม่นยำขึ้น

A. Skills คืออะไรใน Claude Code

หลายคนเข้าใจว่า Skill คือไฟล์ Markdown ที่บอก Claude ว่าต้องทำอะไร แต่จริง ๆ แล้ว Skill ที่ทรงพลังไม่ได้เป็นแค่ไฟล์เดียว

Skill คือ โฟลเดอร์หนึ่งชุด ที่สามารถประกอบด้วย:

SKILL.md สำหรับอธิบายวัตถุประสงค์และวิธีใช้
scripts สำหรับรันงานซ้ำ ๆ
examples สำหรับตัวอย่างการใช้งาน
templates สำหรับ output หรือ boilerplate
reference docs สำหรับข้อมูลเชิงลึก
assets เช่น ไฟล์ตัวอย่างหรือแบบฟอร์ม
data หรือ log สำหรับเก็บ memory
hooks ที่ทำงานเฉพาะเมื่อ skill ถูกเรียกใช้

จุดแข็งของ Skill คือ Claude สามารถ “ค้นพบ สำรวจ และใช้” สิ่งที่อยู่ในโฟลเดอร์นั้นได้เองตามบริบท

ดังนั้น Skill ที่ดีจึงไม่ใช่แค่การเขียน prompt ยาว ๆ แต่คือการออกแบบ mini-toolkit ให้ Claude ใช้ทำงานเฉพาะทางได้ดีขึ้น

B. ประเภทของ Skills ที่พบบ่อย

จากการใช้งานจริง Skills ที่ดีมักตกอยู่ในหมวดหมู่ชัดเจน หาก Skill หนึ่งพยายามทำหลายอย่างเกินไป มักทำให้ทั้ง Claude และผู้ใช้สับสน

1) Library & API References

Skill ประเภทนี้ใช้สอน Claude ว่าควรใช้ library, CLI, SDK หรือ internal tool อย่างไรให้ถูกต้อง

เหมาะมากกับกรณีที่ Claude มักใช้ API ผิด ลืม edge case หรือไม่เข้าใจ library ภายในองค์กร

ตัวอย่าง Skill:

billing-lib
internal-platform-cli
frontend-design

สิ่งที่ควรมีใน Skill ประเภทนี้:

ตัวอย่างการใช้งานจริงใน examples/
รายการ gotchas หรือข้อผิดพลาดที่พบบ่อย
reference ของ function, CLI command หรือ SDK method
คำแนะนำว่าเมื่อไหร่ควรใช้หรือไม่ควรใช้ API นั้น

ตัวอย่างเช่น billing-lib อาจอธิบายว่า internal billing library มี edge case อะไรบ้าง หรือ function ไหนห้ามเรียกตรง ๆ เพราะต้องผ่าน service layer ก่อน

2) Product Verification

Skill ประเภทนี้ใช้ช่วย Claude ตรวจสอบว่าพฤติกรรมของ product ถูกต้องจริง ไม่ใช่แค่โค้ด compile ผ่าน

มักใช้ร่วมกับเครื่องมืออย่าง:

Playwright
tmux
browser automation
test scripts
visual verification

ตัวอย่าง Skill:

signup-flow-driver
checkout-verifier
tmux-cli-driver

เช่น signup-flow-driver อาจให้ Claude เปิด browser แบบ headless แล้วทดสอบ flow ตั้งแต่ signup → email confirmation → onboarding พร้อม assertion ทุกขั้น

Skill ประเภทนี้มีคุณค่ามาก เพราะช่วยลดปัญหา “โค้ดดูถูก แต่ product ใช้จริงไม่ได้”

ถ้า workflow สำคัญ เช่น checkout หรือ onboarding การลงทุนให้วิศวกรใช้เวลาสักสัปดาห์เพื่อ polish Skill ประเภทนี้อาจคุ้มค่ามาก

3) Data Retrieval & Analysis

Skill ประเภทนี้ช่วย Claude ดึง วิเคราะห์ และตีความข้อมูลจาก data stack หรือ monitoring stack ของทีม

ตัวอย่าง Skill:

funnel-query
cohort-compare
grafana

เช่น funnel-query อาจบอกว่า funnel จาก signup → activation → payment ต้อง join event ไหน ใช้ user_id จาก table ใด และควรกรองข้อมูลอย่างไร

ส่วน grafana อาจเก็บ:

dashboard IDs
data source UIDs
cluster names
mapping ระหว่างปัญหากับ dashboard ที่ควรดู

Skill ประเภทนี้เหมาะกับทีมที่ต้องวิเคราะห์พฤติกรรมผู้ใช้, conversion, retention, incident หรือ production metrics บ่อย ๆ

4) Business Processes & Team Automation

Skill ประเภทนี้ใช้ automate workflow ซ้ำ ๆ ของทีม เช่น standup, ticket, weekly recap หรือ internal process อื่น ๆ

ตัวอย่าง Skill:

standup-post
create-ticket
weekly-recap

เช่น standup-post อาจรวบรวมข้อมูลจาก task tracker, GitHub และ Slack แล้วสรุปเฉพาะสิ่งที่เปลี่ยนไปตั้งแต่วันก่อนหน้า

สิ่งที่น่าสนใจคือ Skill ประเภทนี้มักได้ประโยชน์จากการเก็บ log ของรอบก่อน ๆ เช่น:

standups.log
weekly-recaps.log
previous_runs.json

เมื่อ Claude อ่านประวัติเดิมได้ ก็จะรู้ว่าวันนี้มีอะไรใหม่จริง ๆ ไม่ใช่สรุปซ้ำทุกครั้ง

5) Code Templates & Scaffolding

Skill ประเภทนี้ใช้สร้าง boilerplate หรือโครงสร้างไฟล์ตามมาตรฐานของ codebase

ตัวอย่าง Skill:

new-workflow
new-migration
create-app

เช่น new-migration อาจมี template migration พร้อม common pitfalls ส่วน create-app อาจสร้าง internal app ที่ตั้งค่า auth, logging และ deploy config ไว้พร้อม

Skill ประเภทนี้เหมาะเมื่อการ scaffold ไม่ได้เป็นแค่ code generation ธรรมดา แต่มี requirement เชิงภาษา เช่น:

ต้องตั้งชื่อไฟล์ตาม convention
ต้องใส่ annotation บางแบบ
ต้องผูกกับ internal framework
ต้องเตือนเรื่อง pitfall ที่เกิดบ่อย

6) Code Quality & Code Review

Skill ประเภทนี้ใช้ช่วยตรวจคุณภาพโค้ด หรือ enforce review standard ของทีม

ตัวอย่าง Skill:

adversarial-review
code-style
testing-practices

เช่น adversarial-review อาจสร้าง subagent เพื่อ review โค้ดแบบ fresh eyes แล้ววน feedback จนเหลือแต่ประเด็นเล็ก ๆ

Skill ประเภทนี้อาจทำงานร่วมกับ:

deterministic scripts
linters
hooks
GitHub Actions
subagents

สิ่งสำคัญคืออย่าพึ่งคำแนะนำอย่างเดียว หาก quality rule สำคัญมาก ควรใช้ script หรือ tool ที่ตรวจได้จริงประกอบด้วย

7) CI/CD & Deployment

Skill ประเภทนี้ช่วยเรื่อง build, ship, deploy และ monitor หลัง deploy

ตัวอย่าง Skill:

babysit-pr
deploy-service
cherry-pick-prod

เช่น deploy-service อาจมีขั้นตอน:

build → smoke test → gradual traffic shift → compare error rate → rollback ถ้ามี regression

ส่วน babysit-pr อาจ monitor PR, retry flaky CI, resolve merge conflict และเปิด auto-merge เมื่อทุกอย่างผ่าน

Skill ประเภทนี้มักเกี่ยวข้องกับ production จึงควรมี safety guard ที่ชัดเจน เช่น confirmation ก่อนทำ destructive action หรือจำกัด environment ที่เข้าถึงได้

8) Runbooks

Runbook Skill ใช้สำหรับจัดการ incident หรือ investigation จาก symptom บางอย่าง เช่น alert, Slack thread, error signature หรือ request ID

ตัวอย่าง Skill:

service-debugging
oncall-runner
log-correlator

เช่น oncall-runner อาจรับ alert แล้วตรวจ usual suspects เช่น recent deploy, error rate, dependency outage, queue backlog และสรุปเป็น report

Skill ประเภทนี้ช่วยให้ incident response มีโครงสร้าง ไม่ต้องเริ่มเดาใหม่ทุกครั้ง

9) Infrastructure Operations

Skill ประเภทนี้ใช้กับงาน operation และ maintenance ของ infrastructure

ตัวอย่าง Skill:

resource-orphans
dependency-management
cost-investigation

เช่น resource-orphans อาจค้นหา pod หรือ volume ที่ไม่มีเจ้าของ แจ้ง Slack รอ cooldown ขอ user confirmation แล้วค่อย cleanup

เพราะ Skill ประเภทนี้อาจมี action ที่เสี่ยง ควรมี guardrail เช่น:

dry-run mode
confirmation step
allowlist environment
block destructive command
log ทุก action

C. วิธีเขียน Skill ที่ดี

เมื่อรู้แล้วว่า Skill มีหลายประเภท คำถามต่อมาคือจะเขียนอย่างไรให้ Claude ใช้ได้จริง

1) อย่าเขียนสิ่งที่ Claude รู้อยู่แล้ว

Claude Code รู้เรื่อง coding พื้นฐานดีอยู่แล้ว Skill ที่ดีควรเติมสิ่งที่ Claude “ไม่รู้” หรือ “มักทำพลาด” ไม่ใช่อธิบายเรื่องทั่วไปซ้ำ

ตัวอย่างที่ไม่ค่อยมีประโยชน์:

Use clear variable names.
Write tests for important code.
Handle errors properly.

สิ่งเหล่านี้เป็นคำแนะนำกว้างเกินไปและ Claude มักรู้อยู่แล้ว

ตัวอย่างที่ดีกว่า:

In our billing service, never call createInvoice() directly.
Use BillingWorkflow.createDraftInvoice() first because it records audit metadata.

Skill ควรเน้น context เฉพาะของทีม เช่น internal API, design taste, architecture decision หรือ gotcha ที่พบจริง

2) สร้าง Gotchas Section จากปัญหาจริง

ส่วนที่มักมีค่าที่สุดใน Skill คือ Gotchas

เพราะมันบอก Claude ว่า “จุดไหนที่เคยพลาดมาแล้ว”

ตัวอย่าง:

Gotchas

Do not use CommonJS imports. This package is ESM-only.
The checkout API returns pending before Stripe webhook confirmation.
Never assume user.email is verified unless email_verified_at is set.
For Redis cache keys, always include locale and version prefix.

Gotchas ที่ดีควรมาจากเหตุการณ์จริง ไม่ใช่คิดเผื่อแบบกว้าง ๆ

เมื่อ Claude ทำผิดซ้ำ ให้เพิ่ม gotcha เข้าไป Skill จึงควรเป็นเอกสารที่พัฒนาไปพร้อมกับการใช้งานจริง

3) ใช้ File System เพื่อทำ Progressive Disclosure

Skill เป็นโฟลเดอร์ ไม่ใช่แค่ไฟล์ Markdown ดังนั้นควรใช้โครงสร้างไฟล์ให้เป็นประโยชน์

แทนที่จะใส่ทุกอย่างไว้ใน SKILL.md ให้แยกข้อมูลตามระดับความละเอียด เช่น:

my-skill/
├── SKILL.md
├── references/
│ ├── api.md
│ └── edge-cases.md
├── examples/
│ ├── basic.md
│ └── advanced.md
├── scripts/
│ └── verify_flow.py
└── assets/
└── output-template.md

SKILL.md ควรบอก Claude ว่ามีไฟล์อะไรอยู่บ้าง และควรอ่านไฟล์ไหนเมื่อเจอสถานการณ์ใด

นี่เรียกว่า progressive disclosure คือให้ Claude เริ่มจากข้อมูลสั้น ๆ ก่อน แล้วค่อยเปิดรายละเอียดเมื่อจำเป็น

4) อย่าล็อก Claude ด้วยกฎที่แข็งเกินไป

Claude มักพยายามทำตาม instruction อย่างจริงจัง ถ้า Skill เขียนกฎแข็งเกินไป อาจทำให้ Claude ปรับตัวตามสถานการณ์ไม่ได้

ตัวอย่างที่เสี่ยง:

Always use exactly this 7-step process for every bug.
Never skip any step.

ปัญหาคือ bug แต่ละแบบไม่เหมือนกัน บางครั้งขั้นตอนบางอย่างไม่จำเป็น

แนวทางที่ดีกว่า:

Use this investigation flow as the default path.
Skip steps that are clearly irrelevant, but explain why.

Skill ที่ดีให้กรอบและข้อมูล แต่ยังเปิดพื้นที่ให้ Claude ใช้วิจารณญาณ

5) วางแผน Initial Setup

บาง Skill ต้องมีข้อมูลจากผู้ใช้ก่อนใช้งานครั้งแรก เช่น:

Slack channel ที่ต้องโพสต์ standup
project key ใน Jira
service name
environment
owner team
preferred output format

รูปแบบที่ดีคือเก็บค่าเหล่านี้ใน config.json ภายใน Skill

ตัวอย่าง:

standup-post/
├── SKILL.md
└── config.json

ถ้า config.json ยังไม่มี Claude ควรถามผู้ใช้ก่อน และถ้าต้องถามแบบมีตัวเลือก ควรใช้เครื่องมือถามผู้ใช้แบบ structured question

แนวคิดคือ Skill ควรรู้ว่าต้อง initialize ตัวเองอย่างไร ไม่ใช่ให้ผู้ใช้ต้องอธิบายใหม่ทุกครั้ง

6) เขียน `description` เพื่อให้ Model ตัดสินใจเรียก Skill ได้ถูก

ใน Claude Code, เมื่อ session เริ่มขึ้น Claude จะเห็นรายชื่อ Skills พร้อม description แล้วใช้ description เพื่อตัดสินใจว่า request นี้ควรเรียก Skill ไหน

ดังนั้น description ไม่ใช่แค่ summary สำหรับมนุษย์ แต่เป็น trigger condition สำหรับ model

ตัวอย่าง description ที่ไม่ดี:

Helps with deployment.

กว้างเกินไปและไม่บอกว่าควรถูกใช้เมื่อไร

ตัวอย่างที่ดีกว่า:

Use when deploying a backend service to staging or production, checking rollout health, comparing error rates, or deciding whether to rollback.

description ที่ดีควรบอก:

ใช้กับงานอะไร
ใช้เมื่อเกิดสถานการณ์ใด
ไม่ควรใช้กับอะไรถ้าจำเป็น
มีขอบเขตชัดเจน

7) ใช้ Skill เป็น Memory Store ได้ แต่ต้องระวัง

บาง Skill สามารถเก็บข้อมูลภายในตัวเอง เช่น:

append-only text log
JSON file
SQLite database
run history
previous output

ตัวอย่าง standup-post อาจเก็บ:

standups.log

เมื่อรันครั้งถัดไป Claude อ่าน log เดิมแล้วรู้ว่าวันนี้มีอะไรเปลี่ยนไปจากเมื่อวาน

อย่างไรก็ตาม มีข้อควรระวังสำคัญ: ข้อมูลใน skill directory อาจถูกลบเมื่อมีการ update Skill

ดังนั้นข้อมูลที่ต้องอยู่ถาวรควรเก็บใน directory ที่ stable เช่น ${CLAUDE_PLUGIN_DATA} แทนการเก็บไว้ในโฟลเดอร์ Skill โดยตรง

8 ใส่ Scripts และ Helper Libraries ให้ Claude ใช้

หนึ่งในเครื่องมือที่ทรงพลังที่สุดของ Claude คือ code

หาก Skill มี script หรือ helper library ที่ดี Claude จะไม่ต้องเขียน logic ซ้ำทุกครั้ง แต่สามารถใช้พลังไปกับการตัดสินใจและประกอบ workflow แทน

ตัวอย่างสำหรับ data science skill:

data-analysis-skill/
├── SKILL.md
├── lib/
│ ├── events.py
│ ├── cohorts.py
│ └── stats.py
└── examples/
└── retention_analysis.py

เมื่อผู้ใช้ถามว่า “เกิดอะไรขึ้นกับ conversion วันอังคาร” Claude สามารถ generate script ใหม่โดยใช้ helper functions ที่มีอยู่แล้ว แทนที่จะเริ่มเขียน data access ตั้งแต่ศูนย์

นี่ทำให้ Skill แม่นยำขึ้น เร็วขึ้น และลดข้อผิดพลาดซ้ำ ๆ

9 ใช้ Hooks แบบ On Demand

Skills สามารถมี hooks ที่ activate เฉพาะเมื่อ Skill ถูกเรียกใช้ และ active ต่อใน session นั้น

เหมาะกับ hook ที่สำคัญในบางสถานการณ์ แต่ถ้าเปิดตลอดเวลาจะน่ารำคาญ

ตัวอย่าง:

/careful

ใช้เมื่อทำงานกับ production หรือคำสั่งเสี่ยง

สามารถตั้ง PreToolUse hook เพื่อ block:

rm -rf
DROP TABLE
git push --force
kubectl delete

/freeze

ใช้เมื่อต้อง debug โดยอยากเพิ่ม logs เฉพาะบางที่ แต่ไม่อยากให้ Claude แก้ไฟล์อื่นโดยไม่ตั้งใจ

hook อาจ block Edit/Write นอก directory ที่กำหนด

แนวคิดคือ hook ไม่จำเป็นต้องเปิดตลอดเวลา แต่เปิดเมื่อบริบทนั้นต้องการ safety เพิ่ม

D. การแชร์ Skills กับทีม

หนึ่งในข้อดีหลักของ Skills คือแชร์ให้ทีมใช้ร่วมกันได้

มีสองวิธีหลัก:

Commit skills ลง repository ใน ./.claude/skills
สร้าง plugin แล้วแจกผ่าน Claude Code plugin marketplace

1) แชร์ผ่าน repository

เหมาะกับทีมเล็กหรือโปรเจกต์ที่มีไม่กี่ repo

ตัวอย่าง:

your-project/
└── .claude/
└── skills/
├── deploy-service/
├── api-design/
└── testing-practices/

ข้อดีคือทุกคนที่ clone repo จะได้ Skill เดียวกันทันที

ข้อควรระวังคือ Skills ที่ commit เข้า repo จะเพิ่ม context ให้ model ทีละน้อย ถ้าองค์กรมี Skill เยอะมาก อาจทำให้ session หนักเกินไป

2) แชร์ผ่าน plugin marketplace

เหมาะกับองค์กรใหญ่ที่มีหลายทีม หลาย repo และต้องการให้ทีมเลือกติดตั้งเฉพาะ Skill ที่จำเป็น

Marketplace ช่วยให้:

แจกจ่าย Skill ได้เป็นระบบ
เลือกติดตั้งตามความต้องการ
ลด context ที่ไม่เกี่ยวข้อง
ควบคุม version ได้ดีขึ้น
ทำ discovery ได้ง่ายขึ้น

E) การจัดการ Marketplace ของ Skills

ในองค์กรขนาดใหญ่ คำถามคือ Skill ไหนควรเข้า marketplace และใครเป็นคนตัดสิน

แนวทางที่ยืดหยุ่นคือเริ่มแบบ organic:

ใครมี Skill ที่คิดว่ามีประโยชน์ ให้แชร์ใน sandbox folder
โพสต์ link ใน Slack หรือ forum ภายใน
ให้คนอื่นลองใช้
ถ้า Skill ได้รับความนิยม ค่อยเปิด PR เข้า marketplace หลัก

ข้อควรระวังคือ Skills สร้างง่ายมาก จึงมีโอกาสเกิด Skill คุณภาพต่ำหรือ Skill ซ้ำกันเยอะ

ดังนั้นควรมีกลไกคัดกรองก่อน release เช่น:

review โดยเจ้าของ domain
ตรวจว่าซ้ำกับ Skill เดิมหรือไม่
ตรวจ permission และ safety
ดูว่ามี description ชัดหรือไม่
ดูว่ามี gotchas และ examples เพียงพอหรือไม่

Marketplace ที่ดีควรสนับสนุนการทดลอง แต่ต้องมีการ curate ก่อนใช้งานวงกว้าง

F. การประกอบ Skills เข้าด้วยกัน

บาง Skill อาจต้องใช้ Skill อื่นร่วมด้วย เช่น:

Skill สร้าง CSV
Skill upload file

เมื่อผู้ใช้ต้องการ “สร้าง CSV แล้วอัปโหลด” Claude อาจต้องใช้ทั้งสอง Skill ต่อกัน

ปัจจุบัน dependency management ระหว่าง Skills อาจยังไม่ได้สมบูรณ์ แต่สามารถ reference Skill อื่นด้วยชื่อได้ ถ้าติดตั้งอยู่ Claude จะเรียกใช้เมื่อเหมาะสม

ตัวอย่างใน SKILL.md:

If the task requires uploading the generated CSV, use the file-upload skill after generating the file.

แนวคิดนี้ทำให้ Skill กลายเป็น building blocks ที่ประกอบเป็น workflow ใหญ่ได้

แต่ควรระวังไม่ให้ dependency ซับซ้อนเกินไป เพราะจะทำให้ debug ยากและทำให้ Claude เลือก Skill ผิดได้ง่ายขึ้น

G. การวัดผลการใช้งาน Skills

ถ้าทีมมี Skills จำนวนมาก ควรรู้ว่า Skill ไหนถูกใช้จริง และ Skill ไหนแทบไม่ถูกเรียก

วิธีหนึ่งคือใช้ PreToolUse hook เพื่อ log การใช้ Skill ภายในองค์กร

ข้อมูลที่ควรเก็บ เช่น:

Skill ไหนถูกเรียก
เรียกบ่อยแค่ไหน
ใช้ใน repo ใด
task ประเภทไหนเรียกใช้
มี error หรือ fallback บ่อยไหม

ข้อมูลนี้ช่วยให้เห็นว่า:

Skill ไหนเป็นที่นิยม
Skill ไหน description อาจไม่ชัด
Skill ไหนควรปรับปรุง
Skill ไหนควรถูก archive
Skill ไหนควรเลื่อนเข้า marketplace หลัก

Skill management ที่ดีควรมี feedback loop เหมือน product จริง

H. ตัวอย่างโครงสร้าง Skill ที่ดี

ตัวอย่าง Skill สำหรับตรวจสอบ checkout flow:

checkout-verifier/
├── SKILL.md
├── config.json
├── gotchas.md
├── examples/
│ ├── successful-checkout.md
│ └── failed-payment.md
├── scripts/
│ ├── run_checkout_flow.ts
│ └── assert_invoice_state.ts
├── assets/
│ └── report-template.md
└── logs/
└── previous-runs.log

ตัวอย่าง SKILL.md:

name: checkout-verifier
description: Use when verifying checkout behavior, Stripe test card flows, invoice state, payment failure handling, or post-checkout onboarding.

Checkout Verifier

This skill verifies the checkout flow end to end.

When to use

Use this skill when code changes affect:

checkout
invoices
Stripe webhooks
payment status
post-payment onboarding

Files

gotchas.md contains common mistakes and edge cases.
examples/ contains known good flows.
scripts/run_checkout_flow.ts runs the browser flow.
scripts/assert_invoice_state.ts checks invoice state.
assets/report-template.md provides the final report format.

Default workflow

Read config.json.
If config is missing, ask the user for required environment details.
Run the checkout flow script.
Check invoice state.
Compare results with expected behavior.
Produce a report using assets/report-template.md.

Gotchas

Read gotchas.md before making conclusions.

โครงสร้างแบบนี้ทำให้ Claude ไม่ต้องเดาเอง เพราะมีทั้ง workflow, script, examples และ gotchas รองรับครบ

Terminology You Should Know

Key Takeaways

Skill ไม่ใช่แค่ Markdown file แต่เป็นโฟลเดอร์ที่รวม instructions, scripts, examples, assets, data และ hooks ได้
Skill ที่ดีควรมีขอบเขตชัดเจน อยู่ในหมวดใดหมวดหนึ่ง ไม่ควรพยายามทำทุกอย่างในตัวเดียว
ส่วนที่มีค่าที่สุดของ Skill มักเป็น Gotchas เพราะช่วยป้องกันข้อผิดพลาดที่ Claude เคยทำจริง
ใช้ file system ให้เป็นประโยชน์ แยกรายละเอียดออกเป็น references, examples, scripts และ templates เพื่อให้ Claude อ่านเท่าที่จำเป็น
การแชร์ Skills ควรเริ่มจากทีมเล็กหรือ repo ก่อน แล้วค่อยขยายเป็น plugin marketplace เมื่อองค์กรเริ่มมี Skills จำนวนมาก

Skills เป็นหนึ่งใน primitive ที่ทรงพลังที่สุดของ Claude Code เพราะช่วยเปลี่ยนความรู้ กระบวนการ และข้อควรระวังของทีมให้กลายเป็นสิ่งที่ Claude ใช้ซ้ำได้

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

แนวทางสำคัญคืออย่าเขียน Skill เพื่อบอกสิ่งที่ Claude รู้อยู่แล้ว แต่ให้เขียนเพื่อเติมสิ่งที่เฉพาะกับงาน ทีม ระบบ และข้อผิดพลาดจริงของคุณ

เมื่อออกแบบดี Skills จะกลายเป็นคลังความรู้เชิงปฏิบัติที่ช่วยให้ Claude ทำงานได้แม่นขึ้น สม่ำเสมอขึ้น และแชร์มาตรฐานการทำงานของทีมได้อย่างมีประสิทธิภาพ.

ต่อด้วยบทความที่ 4 ของ Anubhav

4. ผมใช้เวลา 6 เดือนปรับแต่ง Claude Code: นี่คือ Setup ที่ลงตัวที่สุด

Claude Code ไม่ได้เก่งขึ้นเพราะ Prompt ดีขึ้น แต่เพราะระบบรอบตัวดีขึ้น

หลายทีมเริ่มใช้ Claude Code ด้วยการเปิด terminal แล้วพิมพ์คำสั่งให้ช่วยเขียนโค้ด แก้ bug หรือสร้าง feature บางอย่าง ถ้าโปรเจกต์ยังเล็ก วิธีนี้อาจดูเพียงพอ แต่เมื่อเริ่มใช้กับงานจริงที่มี test, eval, pull request, deployment, context จำนวนมาก และข้อจำกัดด้านความปลอดภัย การใช้ Claude Code แบบไม่มีโครงสร้างจะเริ่มเผยข้อจำกัดทันที

บทความนี้อธิบาย setup ของผู้ใช้ Claude Code ระดับ power user ที่ผ่านการปรับแต่งมาหลายเดือน โดยเน้นองค์ประกอบหลัก เช่น CLAUDE.md, path-scoped rules, subagents, skills, hooks, MCP servers, worktrees และ headless automation

แก่นสำคัญคือ “prompt” เป็นเพียงส่วนท้ายของระบบเท่านั้น สิ่งที่ทำให้ Claude Code ทำงานได้เร็ว แม่น และปลอดภัยขึ้นจริง คือ configuration stack ที่ออกแบบมาอย่างตั้งใจ

A. ภาพรวม Setup ของ Claude Code ที่ใช้งานจริง

ถ้าเปิดโปรเจกต์ AI ทั่วไปแล้วรันคำสั่ง:

tree .claude

หลายโปรเจกต์อาจยังไม่มีโฟลเดอร์นี้ หรือมีแค่ไฟล์เดียวที่เขียนประมาณว่า “write clean code” ซึ่งช่วยได้น้อยมาก

แต่ในโปรเจกต์ที่ตั้งค่าแบบ power user โครงสร้างอาจหน้าตาแบบนี้:

.claude/
├── CLAUDE.md
├── rules/
│ ├── langgraph.md
│ ├── retrieval.md
│ ├── tests.md
│ └── python-types.md
├── agents/
│ ├── retrieval-reviewer.md
│ ├── prompt-auditor.md
│ └── eval-runner.md
├── skills/
│ ├── new-rag-eval/
│ │ └── SKILL.md
│ └── claude-pr-checklist/
│ └── SKILL.md
├── settings.json
└── .mcp.json

สิ่งสำคัญคือไฟล์เหล่านี้ไม่จำเป็นต้องยาว CLAUDE.md หลักควรสั้นมาก rule แต่ละไฟล์ควรเฉพาะทาง subagent แต่ละตัวควรมีหน้าที่เดียว hook ควรเรียบง่าย และ MCP servers ควรมีเฉพาะตัวที่จำเป็นจริง

ความเร็วไม่ได้มาจากการพิมพ์ prompt เก่งกว่า แต่มาจากระบบที่ทำให้ Claude มี context ถูกต้อง มี guardrails ชัดเจน และมีเครื่องมือที่เหมาะกับงานตั้งแต่เริ่ม session

B. Layer 1: Memory Hierarchy — เริ่มจากไฟล์ความจำที่สั้นและแม่น

Claude Code มีลำดับชั้นของ memory หลายระดับ เช่น:

~/.claude/CLAUDE.md = preference ส่วนตัวระดับ global
./CLAUDE.md = memory หลักของโปรเจกต์
.claude/rules/*.md = rule เฉพาะ path หรือ module
CLAUDE.local.md = override ส่วนตัว ไม่ commit
automatic session memory = memory ที่เกิดระหว่าง session

ไฟล์ที่สำคัญที่สุดคือ CLAUDE.md ระดับ project root เพราะมันถูกโหลดทุกครั้งที่เริ่ม session ดังนั้นทุกบรรทัดในไฟล์นี้คือ token cost ถาวร

ข้อผิดพลาดที่พบบ่อยคือทีมเอา engineering wiki ทั้งหมดมายัดไว้ใน CLAUDE.md ทั้งที่ไฟล์นี้ควรทำหน้าที่เหมือน hot cache ไม่ใช่ knowledge base ขนาดใหญ่

หลักการที่ดีคือ:

ให้ไฟล์สั้นที่สุดเท่าที่ทำได้
เขียนเป็นคำสั่งชัดเจน ไม่ใช่คำแนะนำกว้าง ๆ
ทุกบรรทัดต้องเปลี่ยนพฤติกรรม Claude ได้จริง
อย่าเขียนประโยคทั่วไป เช่น “write clean code”
ให้เขียน rule ที่ตรวจจับได้ เช่น “all functions must have TypeScript type annotations”

ตัวอย่าง CLAUDE.md สำหรับ RAG service:

citation-rag

Retrieval + answer-generation service. LangGraph-based pipeline,
PostgreSQL+pgvector retrieval, Gemini answer generation, eval harness
in evals/.

Layout

services/retrieval/ - chunking, embedding, reranker, citation packer
services/answer/ - prompt templates, generator node, guardrails
shared/ - schemas, tracing, settings
evals/ - golden sets, runners, scoring

Build & test

Install: uv sync
Unit tests: uv run pytest -q
Eval harness: uv run python -m evals.run --suite citations
Lint + types: uv run ruff format . && uv run mypy .

Canonical conventions

The canonical answer prompt lives at services/answer/prompts/v4.md.
Do not edit v3.md because it is frozen for regression evals.
All LLM outputs are validated with the pydantic models in
shared/schemas/answers.py. No raw dict returns from generator nodes.
Retrieval always returns Chunk objects with a citation_id.
The answer node must emit citations using those exact ids.

Guardrails

Never bump the model version string without updating
evals/snapshots/<version>.json in the same commit.
Never introduce network calls inside tests/unit/. Use fixtures in
tests/fixtures/ and the fakes in tests/fakes/.
Prefer editing existing modules over adding new top-level packages.
If a change touches services/retrieval/, read .claude/rules/retrieval.md
before planning.
Keep functions under ~40 lines. Split by responsibility, not by length.

Before opening a PR

Run the eval harness and attach the diff output to the PR body.
Update CHANGELOG.md under ## Unreleased.
Use the claude-pr-checklist skill.

ไฟล์นี้ดีเพราะบอกสิ่งที่ Claude ต้องรู้จริง เช่น layout, command, citation contract, guardrails และขั้นตอนก่อนเปิด PR โดยไม่ใส่รายละเอียดส่วนเกิน

C. Layer 2: Path-Scoped Rules — แยกกฎเฉพาะทางออกจาก memory หลัก

เมื่อ CLAUDE.md ถูกทำให้สั้นแล้ว สิ่งที่เหลือคือกฎเฉพาะของแต่ละส่วนใน codebase เช่น retrieval, tests, migration, frontend หรือ prompt templates

กฎเหล่านี้ไม่ควรอยู่ใน root memory ทั้งหมด เพราะจะกิน token ทุก session แม้งานนั้นไม่ได้เกี่ยวข้องเลย

ทางออกคือใช้ path-scoped rules หรือ rule ที่โหลดเฉพาะเมื่อ Claude ทำงานกับ path ที่ตรงกัน

ตัวอย่าง rule สำหรับ retrieval service:

name: retrieval-rules
description: Conventions for services/retrieval/**. Loaded only when
Claude is editing or planning changes inside the retrieval service.
globs:

"services/retrieval/**"
"tests/retrieval/**"

Retrieval service rules

Chunking

Use shared/chunking.semantic_chunker for all document ingest.
Do not introduce a second chunker without updating the eval snapshot.
Chunk size target: 512 tokens, 64 overlap. Changes require an ADR.

Reranker

The reranker interface is services/retrieval/reranker.Reranker.
New backends must implement it, not parallel it.
Never rerank more than the top 50 hits from vector search. Rerank latency
is the #1 service SLO risk.

Citations

Every Chunk returned from retrieval must carry a stable citation_id.
Citation ids are produced by shared/citations.make_citation_id. Do not
hand-roll ids anywhere else.
The answer node assumes citation_id is URL-safe. Do not change that
without updating services/answer/citation_packer.py in the same diff.

Tests

Unit tests for retrieval must never hit the embedding API. Use the fake
embedder in tests/fakes/embeddings.py.
Integration tests live under tests/retrieval/integration/ and are
opt-in via pytest -m integration.

ข้อดีของแนวทางนี้คือ:

root memory ไม่บวม
Claude ได้ rule ที่เกี่ยวข้องเฉพาะตอนต้องใช้
module owner สามารถดูแล rule ของตัวเองได้
ลด noise ใน context
ประหยัด token ในทุก turn

กฎสั้น ๆ 3–4 ไฟล์มักดีกว่าไฟล์ใหญ่ไฟล์เดียวเสมอ

D. Layer 3: Plan Mode — แยกการคิดออกจากการลงมือแก้ไฟล์

หลายคนใช้ Claude Code โดยให้มันแก้ไฟล์ทันทีหลัง prompt แรก ซึ่งเสี่ยงมากในงานที่มีหลายไฟล์หรือมีผลกระทบสูง

Plan Mode ช่วยแยก “การสำรวจและวางแผน” ออกจาก “การลงมือแก้” ทำให้คุณตรวจสอบแผนก่อนเกิดการเปลี่ยนแปลงจริง

โดยทั่วไป Plan Mode มีหลายระดับ:

Simple Plan = งานเล็ก ไฟล์เดียวหรือขอบเขตแคบ
Visual Plan = งานหลายไฟล์ที่ต้องเห็นโครงสร้าง
Deep Plan = งานหลาย service หรือ refactor ที่มีความเสี่ยง

สำหรับงานซับซ้อน เช่น เพิ่ม citation-backed answer generation ใน RAG service ควรใช้ Deep Plan เพราะต้อง trace หลายส่วน เช่น retrieval path, answer generation, citation packer และ eval harness

ข้อดีคือ planning subagent สามารถถูกตั้งเป็น read-only ได้ มันอ่านไฟล์ วิเคราะห์ dependency และเสนอ plan ได้ แต่แก้ codebase ไม่ได้ จึงลดความเสี่ยงจากการ mutate ไฟล์โดยไม่ตั้งใจ

ตัวอย่างผลลัพธ์จาก plan:

Implementation Plan: Citation-Backed Generation

Modify services/retrieval/search.py
Ensure Chunk objects attach citation_id via
shared.citations.make_citation_id.
Update services/answer/generator.py
Inject [Source: {citation_id}] into the Gemini system prompt context block.
Create Eval
Add evals/suites/citations/defective-charger.json
to verify strict citation formatting.

จากนั้นคุณ review, แก้ plan และ lock-in ก่อนให้ Claude ลงมือจริง

E. Layer 4: Custom Subagents — แยกงานเฉพาะทางออกจาก session หลัก

Subagents คือหนึ่งในฟีเจอร์ที่ทรงพลังแต่ถูกใช้น้อยมาก

แนวคิดคือไม่ควรให้ main session ทำทุกอย่าง เพราะ main session ควรเก็บภาพรวม ส่วนงานเฉพาะทาง เช่น review, prompt audit, eval running หรือ retrieval check ควรถูกส่งไปให้ agent เฉพาะด้าน

ตัวอย่าง subagents ใน RAG service:

agents/
├── retrieval-reviewer.md
├── prompt-auditor.md
└── eval-runner.md

ตัวอย่าง retrieval-reviewer.md:

name: retrieval-reviewer
description: Reviews changes under services/retrieval/ for chunking,
reranker, and citation-contract regressions. Read-only. Invoke
proactively before opening a PR that touches retrieval code.
tools: Read, Grep, Glob, Bash(git diff:), Bash(uv run pytest:)
model: sonnet

You are a retrieval-service reviewer for the citation-rag repo.
Scope:

Only review files under services/retrieval/** and their tests.
Do not comment on unrelated files even if they appear in the diff.
Review checklist, in order:

Chunking: does the change respect the 512/64 target, and does it keep
shared.chunking.semantic_chunker as the single entry point?
Reranker: if the reranker interface changed, is every implementation
updated, and is the top-k cap still ≤ 50?
Citations: every returned Chunk must have a citation_id produced
by shared.citations.make_citation_id. Flag any hand-rolled ids.
Tests: no new network calls in unit tests. Integration tests gated
by pytest -m integration.
Eval impact: if behavior changed, confirm evals/snapshots/*.json
has been regenerated in the same commit.
Output format:

A short "Verdict" (pass / needs-changes / blocker).
Bullet list of findings, each with the file path and a one-line fix.
Do not suggest unrelated refactors.

สิ่งที่ดีในตัวอย่างนี้คือ:

agent มี scope ชัดเจน
tool ถูก allowlist อย่างแคบ
Bash ใช้ได้เฉพาะคำสั่งที่กำหนด
model ถูกลดเป็น Sonnet เพื่อประหยัดต้นทุน
output format ชัดเจน
ไม่แนะนำ refactor นอก scope

นี่คือการเปลี่ยน review จาก prompt ชั่วคราวให้กลายเป็น workflow ที่ reusable และควบคุมได้

F. Layer 5: Skills — แพ็ก workflow ที่ใช้ซ้ำให้เรียกด้วยชื่อเดียว

Skills คือการแพ็ก workflow ให้ Claude เรียกใช้ได้ซ้ำอย่างเป็นระบบ

Skill ไม่ใช่แค่ markdown file แต่เป็นโฟลเดอร์ที่สามารถมี instruction, script, template, fixture และ resource อื่น ๆ ได้

จุดสำคัญคือ Skills ใช้หลัก progressive disclosure:

metadata โหลดตอนเริ่ม session
instruction โหลดเมื่อเรียก skill
resource โหลดเฉพาะเมื่อถูกใช้งาน

ดังนั้นคุณสามารถมี Skills หลายตัวโดยไม่ทำให้ ambient context หนักเกินไป

ตัวอย่าง Skill ชื่อ new-rag-eval:

name: new-rag-eval
description: Support a new RAG eval case from a golden example, wire it
into the eval harness, run it against the current pipeline, and write
a result summary. Use when the user asks to "add an eval for ..."
or "cover this regression with an eval."
allowed-tools: Read, Write, Edit, Bash(uv run:), Bash(git add:)

new-rag-eval

When to use

Trigger when the user wants to add a new eval case to
evals/suites/citations/ or reproduce a regression in the eval harness.

Inputs to gather first

A natural-language description of the query.
The expected citation ids (or the expected answer text).
Optional: the failing trace id from production.

Steps

Read evals/templates/case.json - this is the case template.
Ask the user for the query, expected citations, and any notes.
Write a new case file at evals/suites/citations/<slug>.json using
the template. Slug is kebab-case from the query.
Run the harness for just this case:
uv run python -m evals.run --suite citations --case <slug>
Parse the JSON output at evals/out/<slug>.json. Summarize:
- pass / fail
- grounded-citation rate
- unsupported-claim rate
- any new latency outliers
If failing, add a short "why this is expected to fail today" note
to the case file under notes:.
Stage the new case with git add evals/suites/citations/<slug>.json.

Do not

Do not edit evals/templates/case.json.
Do not touch other eval suites.
Do not open a PR from this skill. The PR flow lives in the
claude-pr-checklist skill.

จุดเด่นคือ Skill นี้มีขอบเขตชัดเจนมาก มันเพิ่ม eval case ได้ รัน harness ได้ stage file ได้ แต่ไม่สามารถ push หรือเปิด PR เอง เพราะ PR flow อยู่ในอีก Skill หนึ่ง

นี่คือการออกแบบ workflow แบบ composable และปลอดภัย

G. Layer 6: Hooks and Determinism — เพิ่มความแน่นอนให้ระบบที่เป็น probabilistic

Claude เป็นระบบ probabilistic แต่ hooks ช่วยเพิ่ม deterministic guardrails

Hooks คือคำสั่งที่รันอัตโนมัติตาม lifecycle เช่น ก่อนใช้ tool หลังแก้ไฟล์ หรือเมื่อ permission ถูกปฏิเสธ

ตัวอย่าง settings:

{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": ".claude/hooks/gate_git_push.sh"
}
]
}
],
"PostToolUse": [
{
"matcher": "Write|Edit|MultiEdit",
"hooks": [
{
"type": "command",
"command": "uv run ruff format $CLAUDE_TOOL_FILE_PATH >/dev/null 2>&1 || true"
}
]
}
],
"PermissionDenied": [
{
"hooks": [
{
"type": "command",
"command": "jq -c . >> .claude/logs/denied.jsonl"
}
]
}
]
}
}

ในตัวอย่างนี้มี hook หลัก 3 แบบ:

PreToolUse ตรวจ command ก่อนใช้ Bash
PostToolUse format file หลัง Write/Edit
PermissionDenied log operation ที่ถูกปฏิเสธ

ตัวอย่าง shell script สำหรับ defer การ push เข้า main:

#!/usr/bin/env bash
set -euo pipefail

payload="$(cat)"
cmd="$(printf '%s' "$payload" | jq -r '.tool_input.command // empty')"
case "$cmd" in
"git push""origin main"|"git push"" main")
jq -nc '{
"permissionDecision": "defer",
"reason": "Push to main requires human approval."
}'
;;
*)
jq -nc '{"permissionDecision": "allow"}'
;;
esac

แนวคิดสำคัญคือ actions ที่เสี่ยง เช่น push เข้า main ไม่ควรถูกตัดสินด้วย prompt อย่างเดียว แต่ควรมี hook ที่ block, deny หรือ defer ได้จริง

ส่วน formatting hook แม้ดูธรรมดา แต่ให้ผลตอบแทนสูงมาก เพราะ Claude จะไม่สับสนกับ indentation หรือ style ที่ตัวเองเพิ่งเขียนผิด

H. Layer 7: Server Stack — MCP Servers ต้องน้อย แต่ใช่

Model Context Protocol หรือ MCP ช่วยให้ Claude เชื่อมต่อ external tools เช่น GitHub, filesystem, web search, documentation และ database

แต่การติดตั้ง MCP servers เยอะเกินไปทำให้ Claude สับสนและเพิ่ม token cost เพราะ tool schemas ต้องถูกนำเข้า context

แนวทางที่ดีคือเลือกเฉพาะ servers ที่จำเป็นจริง

ตัวอย่าง server stack ที่พอดีสำหรับ engineering setup:

{
"mcpServers": {
"vexp": {
"command": "npx",
"args": ["-y", "@vexp/mcp-server@latest"],
"env": {
"VEXP_PROJECT": "citation-rag",
"VEXP_MEMORY_DIR": ".vexp"
}
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
},
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"${HOME}/code/citation-rag",
"${HOME}/code/shared-prompts"
]
},
"brave-search": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-brave-search"],
"env": { "BRAVE_API_KEY": "${BRAVE_API_KEY}" }
},
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp@latest"]
}
}
}

server ที่จำเป็นใน setup นี้มี 5 ประเภท:

Serverหน้าที่Code graph / memory serverเข้าใจ codebase และเก็บ session memoryGitHub serverจัดการ branch, commit, PRFilesystem serverเข้าถึง directory ข้าม projectWeb search serverหา documentation ปัจจุบันContext/documentation serverดึงเอกสาร library ตาม version

ถ้าเป็นงาน AI engineering ที่ต้อง query database อาจเพิ่ม database server เป็นตัวที่หกได้ แต่ควรเริ่มจากหลัก least privilege และ read-only ก่อน

หลักสำคัญคืออย่าติดตั้ง MCP 15 ตัวเพราะ “เผื่อใช้” เพราะทุก tool ที่เพิ่มเข้ามามีต้นทุนด้าน context และความสับสน

I. Layer 8: Parallel Worktrees และ Headless Automation

Worktrees ช่วยให้ Claude ทำงานหลาย branch หรือหลาย task พร้อมกันได้ โดยแต่ละ worktree มี session, context, editor state และ process ของตัวเอง

ตัวอย่างการแบ่งงาน:

worktree 1 = implement core generation change
worktree 2 = rewrite evaluation harness
worktree 3 = add tracing to retrieval path
worktree 4 = draft pull request

ถ้า scope งานแยกกันดี เช่น evals อยู่ pane หนึ่ง core logic อยู่ pane หนึ่ง tracing อยู่อีก pane หนึ่ง merge conflict จะน้อยกว่าที่คิด

ส่วน headless mode คือการรัน Claude แบบ non-interactive ใน CI/CD เช่น nightly eval job

ตัวอย่าง GitHub Actions:

name: claude-nightly-evals
on:
schedule: [{cron: "0 7 * * *"}]
workflow_dispatch:

jobs:
run-evals-and-open-pr:
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: actions/checkout@v4
- uses: astral-sh/setup-uv@v3
- run: uv sync

  - name: Install Claude Code  
    run: npm i -g @anthropic-ai/claude-code@latest  
      
  - name: Run nightly eval + draft PR  
    id: claude  
    run: |  
      set -o pipefail  
      claude -p \  
        --bare \  
        --output-format stream-json \  
        --allowedTools "Bash(uv run:*),Read,Grep,Glob,Write,Edit,mcp__github__*" \  
        --append-system-prompt "You are the nightly eval runner. \  
          Run the citations eval suite. If regressions appear, \  
          open a draft PR with a fix attempt and the eval diff." \  
        "Run: uv run python -m evals.run --suite citations. \  
         If any case regresses, implement the minimal fix and open \  
         a draft PR against main via the GitHub MCP." \  
      | tee claude.ndjson

จุดสำคัญของ headless mode คือ:

จำกัด allowed tools ให้ชัดเจน
ใช้ --bare เพื่อให้ behavior reproducible
output เป็น stream JSON เพื่อให้ CI parse ได้
ใช้ hook เพื่อ defer operation ที่เสี่ยง
ให้มนุษย์อนุมัติขั้นตอนสำคัญ เช่น push เข้า main

นี่ทำให้ Claude สามารถรัน eval, ตรวจ regression, draft fix และเปิด PR ได้แบบ automation แต่ยังมี human gate ในจุดที่เสี่ยง

J. ภาพรวม Workflow จริง: จาก Feature ถึง PR

สมมติ task คือเพิ่ม citation-backed answer generation ให้ retrieval service

ระบบที่ตั้งค่าดีจะทำงานประมาณนี้:

เริ่ม session
memory file และ rules โหลดอัตโนมัติ
MCP servers เชื่อมต่อ
engineer เข้า Deep Plan mode
explore subagent map retrieval path
planner สร้าง implementation plan
engineer review และ lock plan
Claude implement core logic
retrieval-reviewer ตรวจ domain-specific rules
hook format ไฟล์หลังแก้ทุกครั้ง
parallel worktree เพิ่ม eval case
eval harness รันและสร้างผลลัพธ์
PR checklist skill เตรียม PR body
GitHub MCP เปิด PR
push หรือ action เสี่ยงถูก defer เพื่อรอ human approval

ตัวอย่างผล review จาก subagent:

Verdict: blocker

services/retrieval/search.py:
You hand-rolled a UUID for the citation ID.
Rule requires shared.citations.make_citation_id.
tests/retrieval/test_search.py:
Missing @pytest.mark.integration on the new database test.

Claude แก้ตาม feedback แล้วรัน eval ได้ผลประมาณนี้:

{
"suite": "citations",
"cases_run": 45,
"grounded_citation_rate": {
"previous": 0.82,
"current": 0.98,
"delta": "+0.16"
},
"unsupported_claims": {
"previous": 12,
"current": 0,
"delta": "-12"
},
"status": "PASS"
}

สิ่งที่สำคัญคือผลลัพธ์นี้ไม่ได้เกิดจาก prompt เดียว แต่เกิดจาก stack ทั้งชุดที่ช่วย Claude วางแผน ทำงาน ตรวจสอบ แก้ไข และส่งมอบอย่างเป็นระบบ

K. สิ่งที่ควรทำขั้นต่ำ ถ้ายังไม่พร้อมสร้างเต็มระบบ

คุณไม่จำเป็นต้องเริ่มจาก setup ใหญ่ทันที ถ้าจะทำให้น้อยที่สุด ควรเริ่มจากสิ่งเหล่านี้:

สร้าง CLAUDE.md ที่สั้น ชัด และเป็น imperative
เขียน path-scoped rules 2 ไฟล์สำหรับ directory ที่แตะบ่อยที่สุด
เพิ่ม formatting hook หลัง Write/Edit
ติดตั้ง MCP servers แค่ 3 ตัวแรก: GitHub, filesystem, documentation
ใช้ Plan Mode กับงานที่มีความเสี่ยงหรือหลายไฟล์

จากนั้นค่อยเพิ่ม:

subagents = เมื่อมีงาน review หรือ audit ที่เกิดซ้ำ
skills = เมื่อ workflow เริ่มนิ่งพอจะ package ได้
worktrees = เมื่อคุณสลับ branch บ่อยหรืออยากทำงานขนาน
headless = เมื่ออยากให้ Claude ทำงานอัตโนมัติใน CI

อย่าทำกลับกัน อย่าเริ่มจาก MCP 15 ตัว subagent 20 ตัว และ memory file ยาวหลายพันคำ เพราะจะทำให้ระบบช้าลง สับสน และดูแลยาก

Terminology You Should Know

Key Takeaways

Claude Code ที่ทรงพลังไม่ได้เกิดจาก prompt ดีอย่างเดียว แต่เกิดจาก configuration stack ที่ดี
CLAUDE.md ควรสั้น ชัด และมีเฉพาะ rule ที่เปลี่ยนพฤติกรรม Claude ได้จริง
Path-scoped rules ช่วยลด token cost และทำให้ Claude ได้ context เฉพาะตอนที่จำเป็น
Subagents และ Skills ควรใช้เมื่อมีงานเฉพาะทางหรือ workflow ที่ทำซ้ำ ไม่ใช่สร้างไว้เพื่อความซับซ้อน
Hooks, MCP servers, worktrees และ headless mode ทำให้ Claude Code กลายเป็นระบบ engineering automation ที่ใช้งานจริงได้

บทเรียนสำคัญจาก setup นี้คือ Claude Code ไม่ได้ควรถูกใช้เหมือน chatbot ใน terminal แต่ควรถูกออกแบบเหมือน infrastructure สำหรับงานวิศวกรรม

เริ่มจาก memory file ที่สั้นและแม่น เพิ่ม rules เฉพาะ path ใช้ Plan Mode ก่อนงานเสี่ยง แยก review ไปให้ subagents แพ็ก workflow เป็น Skills ใช้ hooks เพื่อบังคับ guardrails และเลือก MCP servers เท่าที่จำเป็นจริง

เมื่อ stack นี้ถูกออกแบบดี งานที่เคยต้องใช้เวลาหลายชั่วโมงสามารถถูกย่อเหลือหลักสิบนาทีได้ เพราะ Claude ไม่ต้องเริ่มจากศูนย์ทุกครั้ง

สุดท้าย prompt เป็นเพียง 5% สุดท้ายของกระบวนการ ส่วนที่สร้างผลลัพธ์จริงคือระบบที่คุณวางไว้รอบตัว Claude Code.

ต่อด้วยคนสุดท้ายของ series นี้ Yanli Liu

4 บรรทัดที่ CLAUDE.md ทุกไฟล์ควรมี

เมื่อ AI เขียนโค้ดเก่งขึ้น ปัญหาจึงไม่ใช่ “ความสามารถ” แต่คือ “พฤติกรรม”

ในยุคที่ AI coding agent พัฒนาเร็วมาก เครื่องมือใหม่ ๆ ถูกปล่อยออกมาแทบทุกสัปดาห์ ไม่ว่าจะเป็น Claude Code, Codex, Cursor, Copilot หรือเครื่องมือช่วยเขียนโค้ดอื่น ๆ หลายทีมเริ่มให้ AI มีบทบาทจริงในงานพัฒนา software ตั้งแต่เขียนฟีเจอร์ แก้บั๊ก ไปจนถึง refactor โค้ด

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

นี่คือเหตุผลที่ไฟล์ markdown ธรรมดา ๆ อย่าง CLAUDE.md ซึ่งมีหลักคิดเพียงไม่กี่บรรทัด กลับได้รับความสนใจจากนักพัฒนาจำนวนมาก เพราะมันไม่ได้สอน AI ว่า “ต้องใช้ framework อะไร” หรือ “ต้องเขียน code style แบบไหน” แต่มันสอนว่า AI ควร “ทำตัวอย่างไร” ระหว่างช่วยเราเขียนโค้ด

หัวใจของบทความนี้คือ 4 บรรทัดสำคัญที่ควรอยู่ใน CLAUDE.md ทุกไฟล์:

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

A. สิ่งที่ Karpathy ชี้ให้เห็น: AI ไม่ได้ล้มเหลวเพราะเขียนโค้ดไม่ได้ แต่ล้มเหลวเพราะ “ตัดสินใจแทนเรา” ผิด

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

ตัวอย่างเช่น เราบอก AI ว่า

“เพิ่มฟีเจอร์ export user data”

AI อาจเขียนโค้ด export เป็น JSON ทันที ดึงข้อมูล user ทุกคนทันที บันทึกลงไฟล์ทันที และรวม field ทั้งหมดทันที โดยไม่เคยถามเลยว่า:

ต้อง export user ทั้งหมดหรือแค่บางกลุ่ม?
ต้องการ JSON, CSV หรือ API endpoint?
field ไหนเป็นข้อมูลอ่อนไหว?
จำนวนข้อมูลเยอะไหม ต้องมี pagination หรือไม่?

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

ดังนั้นบรรทัดแรกจึงสำคัญมาก:

Don’t assume. Don’t hide confusion. Surface tradeoffs.
อย่าเดา อย่าซ่อนความไม่แน่ใจ ให้แสดงทางเลือกและข้อแลกเปลี่ยนออกมา

หลักนี้บังคับให้ AI หยุดก่อนลงมือ และพูดออกมาตรง ๆ ว่ามีอะไรที่ยังไม่ชัดเจน

B. บรรทัดที่ 1: อย่าเดา อย่าซ่อนความไม่แน่ใจ ให้แสดง tradeoff

AI language model ถูกฝึกมาให้ “เติมข้อความต่อ” อย่างลื่นไหล จึงมีแนวโน้มจะเดินหน้าต่อ แม้ข้อมูลจะไม่ครบ มันไม่ค่อยหยุดพูดว่า “ฉันไม่แน่ใจ” เว้นแต่เราจะสั่งให้มันทำแบบนั้น

ถ้าไม่มีหลักนี้ คำสั่งง่าย ๆ อย่าง “ทำระบบ export user data” อาจกลายเป็นโค้ดที่เต็มไปด้วย assumption:

def export_users(format='json'):
users = User.query.all()
if format == 'json':
with open('users.json', 'w') as f:
json.dump([u.to_dict() for u in users], f)
return f"Exported {len(users)} users"

โค้ดนี้ไม่ได้ผิดทาง syntax แต่มี assumption ซ่อนอยู่เต็มไปหมด เช่น export เป็น JSON, export ทุกคน, เขียนลงไฟล์, ใช้ทุก field

ถ้าใส่หลัก “Don’t assume” ไว้ใน CLAUDE.md คำตอบที่ดีควรเริ่มแบบนี้แทน:

ก่อนเริ่ม implement ขอ clarify ก่อน: 1. ต้อง export user ทั้งหมดหรือเฉพาะบางกลุ่ม?
2. ต้องการ output เป็น JSON, CSV หรือ API endpoint?
3. field ไหนควรถูก export และ field ไหนเป็นข้อมูลอ่อนไหว?
4. จำนวน user มากแค่ไหน เพราะมีผลต่อ pagination และ performance

สิ่งนี้เปลี่ยน AI จาก “คนที่เดาแล้วทำ” เป็น “ผู้ช่วยที่รู้จักถามก่อนทำ”

C. บรรทัดที่ 2: เขียนโค้ดให้น้อยที่สุดเท่าที่แก้ปัญหาได้ อย่าทำเผื่ออนาคต

ปัญหาใหญ่อีกอย่างของ AI coding agent คือมันมัก over-engineer หรือออกแบบเกินความจำเป็น

เราขอแค่ function คำนวณส่วนลด แต่ AI อาจสร้าง architecture ขนาดย่อมขึ้นมา:

class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount: float) -> float:
pass

class PercentageDiscount(DiscountStrategy):
def init(self, percentage: float):
self.percentage = percentage
def calculate(self, amount: float) -> float:
return amount * (self.percentage / 100)

จากนั้นอาจมี FixedDiscount, DiscountCalculator, DiscountConfig และโค้ด setup อีกหลายสิบบรรทัด ทั้งที่โจทย์จริง ๆ ต้องการแค่:

def calculate_discount(amount: float, percent: float) -> float:
return amount * (percent / 100)

บรรทัดที่ 2 จึงคือ:

Minimum code that solves the problem. Nothing speculative.
เขียนโค้ดให้น้อยที่สุดเท่าที่แก้ปัญหาได้ อย่าเขียนเผื่อสิ่งที่ยังไม่เกิดขึ้น

ประเด็นสำคัญคือ โค้ดที่ซับซ้อนไม่ได้ผิดเสมอไป Design pattern อย่าง Strategy pattern อาจเหมาะในระบบ billing ขนาดใหญ่ แต่ถ้า requirement ยังเล็ก การสร้าง abstraction ล่วงหน้าจะเพิ่มต้นทุนทันที:

reviewer ต้องอ่านมากขึ้น
bug surface เพิ่มขึ้น
เปลี่ยนทิศทางยากขึ้น
ทีมต้องแบกโครงสร้างที่อาจไม่จำเป็นเลย

โค้ดที่ดีไม่ใช่โค้ดที่ดูฉลาดที่สุด แต่คือโค้ดที่แก้ปัญหาปัจจุบันได้ชัดเจนที่สุด

D. บรรทัดที่ 3: แตะเฉพาะส่วนที่จำเป็น เก็บกวาดเฉพาะสิ่งที่ตัวเองทำรก

AI coding agent มักแก้บั๊กหนึ่งจุด แต่เปลี่ยนไฟล์ไปหลายจุดเกินจำเป็น เช่น เราขอให้แก้บั๊กกรณี email ว่างแล้วระบบ crash แต่ AI กลับปรับ email validation เพิ่ม username validation เปลี่ยนชื่อตัวแปร และจัด format ใหม่ทั้งไฟล์

ผลลัพธ์คือ bug fix ที่ควรเปลี่ยน 3 บรรทัด กลายเป็น diff 40 บรรทัด

ปัญหานี้ไม่ได้แค่ทำให้โค้ดรก แต่ทำให้ review ยากขึ้น เพราะ reviewer ต้องถามว่า:

บรรทัดนี้เกี่ยวกับ bug จริงไหม?
validation ใหม่ทำให้ behavior เปลี่ยนหรือเปล่า?
การเปลี่ยนชื่อตัวแปรมีผลข้างเคียงไหม?
โค้ดที่ถูก rewrite มี logic เดิมครบไหม?

บรรทัดที่ 3 จึงคือ:

Touch only what you must. Clean up only your own mess.
แตะเฉพาะส่วนที่จำเป็น เก็บกวาดเฉพาะสิ่งที่ตัวเองทำให้รก

ตัวอย่างการแก้ที่ดีควรเล็กและตรวจสอบง่าย:

if not user_data.get('email'):

email = user_data.get('email', '')
if not email or not email.strip():
raise ValueError("Email required")

if '@' not in user_data['email']:

if '@' not in email:
raise ValueError("Invalid email")

ทุกบรรทัดที่เปลี่ยนต้องโยงกลับไปยัง bug report ได้โดยตรง

หลักนี้สำคัญมากสำหรับทีมจริง เพราะความน่าเชื่อถือของ AI-generated code ไม่ได้มาจากความยาวของคำตอบ แต่มาจากความสามารถในการ review ได้เร็วและมั่นใจ ถ้า diff เล็กและตรงประเด็น ทีมจะกล้าใช้ AI มากขึ้น

E. บรรทัดที่ 4: กำหนดเกณฑ์ความสำเร็จ แล้ววนทำจนพิสูจน์ได้ว่าเสร็จจริง

สามบรรทัดแรกเป็นเหมือน guardrail หรือรั้วกันพฤติกรรมไม่ดี แต่บรรทัดที่ 4 เป็นสิ่งที่ปลดล็อกพลังของ agent อย่างแท้จริง

Define success criteria. Loop until verified.
กำหนดเกณฑ์ความสำเร็จ แล้ววนทำจนตรวจสอบได้ว่าเสร็จจริง

AI agent เก่งมากในการทำงานซ้ำ วนแก้ วนทดสอบ และปรับปรุงจนกว่าจะถึงเป้าหมาย แต่ปัญหาคือเรามักให้เป้าหมายที่คลุมเครือ เช่น:

“แก้ระบบ authentication ให้หน่อย”

ถ้าไม่มี success criteria AI อาจตอบว่า:

จะตรวจโค้ด หาปัญหา แก้ไข และทดสอบ

ฟังดูดี แต่ไม่มีอะไรตรวจสอบได้จริงว่า “เสร็จ” แปลว่าอะไร

คำสั่งที่ดีกว่าคือให้ agent สร้างเกณฑ์ตรวจสอบชัดเจน เช่น:

เขียน test ว่าเมื่อ user เปลี่ยน password แล้ว session เก่าต้องใช้ไม่ได้
-ตรวจสอบ: test ต้อง fail ก่อน เพื่อยืนยันว่า reproduce bug ได้
implement logic สำหรับ invalidate session
-ตรวจสอบ: test ผ่าน
เพิ่ม edge case เช่นหลาย session หรือเปลี่ยน password พร้อมกัน
-ตรวจสอบ: test เหล่านี้ผ่าน
รัน regression test ของ auth ทั้งหมด
-ตรวจสอบ: test suite ต้อง green

เมื่อ AI รู้ว่า “เสร็จ” วัดจากอะไร มันสามารถวนทำงานเองได้ดีขึ้นมาก เราไม่ต้องคอยบอกทีละขั้นทุกครั้ง

นี่คือความแตกต่างระหว่าง “สั่งให้ AI ทำงาน” กับ “ตั้งเป้าหมายให้ AI พิสูจน์ผลลัพธ์”

F. ทำไม 4 บรรทัดนี้จึงทรงพลัง: มันเปลี่ยนวิธีคิด ไม่ใช่แค่เปลี่ยนวิธีเขียนโค้ด

หลายทีมพยายามแก้ปัญหา AI ด้วยการเพิ่ม rule เข้าไปเรื่อย ๆ เช่น:

ห้ามใช้ semicolon
ต้องใช้ TypeScript strict mode
ต้องใช้ functional style
ต้องใส่ error handling ทุกครั้ง
ต้องตั้งชื่อตาม pattern นี้
ห้ามแก้ไฟล์นั้น
ต้อง import แบบนี้

ปัญหาคือเมื่อ rule เยอะเกินไป AI จะเริ่มสับสน ข้อความสำคัญปะปนกับรายละเอียดเล็ก ๆ จน signal ถูกกลบด้วย noise

นี่คือสิ่งที่เรียกว่า Configuration Paradox:

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

4 บรรทัดนี้ได้ผล เพราะมันไม่ใช่ checklist ของ feature แต่เป็น behavioral constraints หรือข้อกำกับพฤติกรรม:

“อย่าเดา” ใช้ได้กับทุกภาษาและทุก project
“เขียนให้น้อยที่สุด” ใช้ได้กับทุก codebase
“แตะเฉพาะที่จำเป็น” ใช้ได้กับทุก bug fix
“กำหนด success criteria” ใช้ได้กับทุกงานที่ต้อง verify

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

G. แล้วควรใส่อะไรใน CLAUDE.md จริง ๆ?

โครงสร้างที่เหมาะสมของ CLAUDE.md ควรมี 2 ชั้น:

ชั้นที่ 1: Behavioral Foundation

ใส่ 4 บรรทัดหลัก:

Behavior

Don't assume. Don't hide confusion. Surface tradeoffs.
Minimum code that solves the problem. Nothing speculative.
Touch only what you must. Clean up only your own mess.
Define success criteria. Loop until verified.

นี่คือฐานพฤติกรรมที่ควรใช้ข้าม project ได้

ชั้นที่ 2: Project-Specific Context

หลังจากนั้นค่อยเพิ่ม context เฉพาะ project ที่ AI อ่านจาก codebase ไม่ได้ง่าย ๆ เช่น build command:

Project

Build: npm run build
Test: npm test
Lint: npm run lint -- --fix

เพิ่ม convention ที่มองจากโค้ดอาจไม่ชัด:

Conventions

API errors return { error: string, code: number }, never throw
All dates stored as UTC, displayed in user's timezone
Feature flags live in config/flags.ts, not inline

เพิ่ม warning จากประสบการณ์จริง:

Watch out

The payments service timeout is 30s, not the default 5s
Don't import from /internal -- it breaks the public API build

หลักตัดสินใจง่าย ๆ คือ:

ถ้าลบบรรทัดนี้ออก AI จะทำผิดพลาดที่มันแก้เองไม่ได้หรือไม่?

ถ้าคำตอบคือ “ไม่” ก็ไม่ควรใส่

H. อะไรที่ไม่ควรใส่ใน CLAUDE.md

อย่าใส่สิ่งที่ AI สามารถอ่านเองได้จาก repository เช่น:

architecture overview ที่โค้ดบอกอยู่แล้ว
dependency list ที่อยู่ใน package.json
style guide ที่ infer ได้จากไฟล์เดิม
documentation ที่อยู่ใน repo อยู่แล้ว
rule เล็ก ๆ ที่ไม่ได้ป้องกันความผิดพลาดจริง

จำไว้ว่า AI agent อ่าน codebase ได้อยู่แล้ว หน้าที่ของ CLAUDE.md ไม่ใช่การคัดลอกข้อมูลซ้ำ แต่คือการให้บริบทที่อ่านจากโค้ดไม่ได้ และกำกับพฤติกรรมที่โมเดลมักพลาด

I. เมื่อไหร่ที่ 4 บรรทัดยังไม่พอ

แม้ 4 บรรทัดนี้จะเป็นฐานที่ดี แต่ก็ไม่ได้แก้ทุกปัญหา

1) งาน refactor ขนาดใหญ่

ถ้าต้องย้าย module หลายไฟล์ เปลี่ยน import chain และกระทบหลายส่วนของระบบ AI ต้องการ architectural context เพิ่มเติม ไม่ใช่แค่ behavioral rule

ในกรณีนี้ควรเพิ่ม architecture section แบบสั้น ๆ หรือแบ่งงานเป็น task เล็ก ๆ ที่มี scope ชัดเจน

2) อุตสาหกรรมที่มี regulation

ถ้าเป็น healthcare, fintech หรือระบบที่เกี่ยวกับข้อมูลส่วนบุคคล ต้องมี guardrail เฉพาะ domain เช่น:

ห้าม log PII
API change ต้องผ่าน security review
ต้องเก็บ audit trail
ห้ามเปลี่ยน encryption logic โดยไม่ได้รับอนุญาต

สิ่งเหล่านี้ควรเพิ่ม “ข้าง ๆ” 4 บรรทัด ไม่ใช่แทนที่ 4 บรรทัด

3) ทีมขนาดใหญ่

สำหรับทีม 20 คนขึ้นไป ปัญหาไม่ใช่แค่ไฟล์ config แต่คือข้อตกลงร่วมกันว่าทีมต้องการให้ AI ทำงานแบบไหน อาจต้องใช้ไฟล์กลาง เช่น AGENTS.md หรือ convention ร่วมของทีม

4) เครื่องมือคนละตัว พฤติกรรมอาจต่างกัน

หลักคิดเหล่านี้ใช้ได้กับ Claude Code, Cursor, Copilot หรือ Codex แต่แต่ละเครื่องมืออาจตอบสนองต่อ prompt ต่างกัน ต้องปรับ wording และทดสอบกับ workflow จริง

Terminology You Should Know

Key Takeaways

ปัญหาหลักของ AI coding agent ไม่ใช่การเขียนโค้ดไม่ได้ แต่คือการเดาเอง แก้เกิน scope และไม่ verify ผลลัพธ์ให้ชัดเจน
4 บรรทัดสำคัญใน CLAUDE.md ทำหน้าที่กำกับพฤติกรรมของ AI มากกว่ากำหนดรายละเอียดทางเทคนิค
Rule ที่ดีควรเปลี่ยน “วิธีคิด” ของ agent เช่น อย่า assume, ทำให้น้อยที่สุด, แก้เฉพาะจุด และตรวจสอบจนผ่าน
การเพิ่ม rule มากเกินไปอาจทำให้ AI สับสน เพราะรายละเอียดเล็ก ๆ ไปแข่งกับหลักสำคัญ
CLAUDE.md ที่ดีควรมี behavioral foundation สั้น ๆ แล้วเสริมเฉพาะ project context ที่ AI อ่านจาก codebase เองไม่ได้

AI coding agent จะเขียนโค้ดเก่งขึ้นเรื่อย ๆ เครื่องมือจะมีฟีเจอร์มากขึ้นเรื่อย ๆ และ model ใหม่จะถูกปล่อยออกมาอย่างต่อเนื่อง แต่ปัญหาที่นักพัฒนาต้องเจอจะยังคล้ายเดิม: AI ต้องรู้ว่าเมื่อไหร่ควรถาม เมื่อไหร่ควรหยุด เมื่อไหร่ควรแก้ให้น้อยที่สุด และเมื่อไหร่ต้องพิสูจน์ว่างานเสร็จจริง

นั่นคือเหตุผลที่ 4 บรรทัดใน CLAUDE.md มีพลังมากกว่าที่ดูจากภายนอก มันไม่ใช่แค่ prompt สั้น ๆ แต่เป็นกรอบพฤติกรรมที่ช่วยให้ AI ทำงานเหมือนผู้ช่วยวิศวกรที่น่าเชื่อถือมากขึ้น

สุดท้ายแล้ว ความสามารถของโมเดลเป็นเรื่องสำคัญ แต่ความสามารถอย่างเดียวไม่พอ สิ่งที่ทำให้ AI มีประโยชน์จริงในงานพัฒนา software คือ judgment หรือวิจารณญาณในการทำงาน และจนกว่าโมเดลจะจัดการวิจารณญาณของตัวเองได้ดีพอ 4 บรรทัดนี้ก็ยังเป็นหนึ่งในเครื่องมือที่คุ้มค่าที่สุดที่นักพัฒนาควรมีไว้ใน project ของตัวเอง.

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

ไม่ว่าจะเริ่มจาก CLAUDE.md ไฟล์เดียว หรือค่อย ๆ ขยายไปสู่ rules, hooks, skills, agents และ MCP สิ่งสำคัญคือทุกส่วนต้องมีหน้าที่ชัดเจน ใช้งานจริงได้ และช่วยให้ทั้งคนและ AI ทำงานร่วมกันได้ดีขึ้นอย่างต่อเนื่อง.

📌 Connect with me and follow our journey: Linkedin, Facebook

Data Science Explore the world of data science with Donato_Story

Dashboard Discover the power of data visualization with Donato_Story

Donato_Journey Join me on my journey (Thai version)

Course_Review Discover the training courses with Donato_Story (Thai version)

Let’s Connect!

Your thoughts and feedback are invaluable. Feel free to share them in the comments or connect with me on

🌐 Medium: medium.com/donato-story
📘Facebook: web.facebook.com/DonatoStory
💼 Linkedin: linkedin.com/in/nattapong-thanngam

Originally published on Medium

AI & Generative AI

10 เรื่องเกี่ยวกับ Claude ที่น่าเอาไปใช้ต่อ — EP.1

รวมแนวคิดจากหลายบทความและ Open Source Project สำหรับคนที่อยากใช้ AI ให้เก่งกว่าแค่ถาม-ตอบ

22 Aug 202636 min

AI & Generative AI

Adaptive RAG

Data Mastery Series — Episode 52: ปรับ RAG ให้ “รู้จักประเมินสถานการณ์” ก่อนลงมือค้นข้อมูล

14 Apr 202517 min

AI & Generative AI

Agent Skills คืออะไร

ทำความเข้าใจ Skill สำหรับ AI Coding Agent และต่างจาก MCP อย่างไร

22 Aug 20261 min

AI & Generative AI

Agentic RAG

Data Mastery Series — Episode 51: เปลี่ยน RAG ให้ “คิด” ได้

14 Apr 202514 min