วันนี้มาสรุป Claude Code Best Practices ให้อ่านกันครับเผื่อเป็นแนวทางให้กับคนที่สนใจเริ่มใช้ Claude Code
—
1. ให้ Claude ตรวจงานตัวเองได้
Claude เขียนโค้ดเก่ง แต่ถ้าไม่มีวิธีการตรวจผลลัพธ์ มันก็แค่ “ดูเหมือนถูก” เราควรหาแนวทางให้มันเช็คตัวเองได้ เช่น การสร้าง test suite, lint, หรือ screenshot เปรียบเทียบ จะทำให้คุณภาพงานเราดีขึ้นทันที
ตรวจยังไงได้บ้าง
– ถ้าโค้ดทั่วไป ควรเตรียม test ไว้ให้ แล้วสั่ง Claude รันหลังแก้โค้ดเสมอ
– ถ้าทำ UI ลองให้ screenshot ต้นฉบับ แล้วสั่ง Claude ถ่าย screenshot ผลลัพธ์เพื่อเทียบความต่าง
– ถ้าทำ Bug fix ให้ paste error log แล้วบอกว่า “แก้ให้ build ผ่าน” หรือ “แก้ให้ test X ผ่าน”
– ก่อนจะ ship ให้สั่งรัน test && lint && build (production) ให้ครบเสมอก่อนใช้จริง
ตัวอย่าง prompt
Implement `validateEmail(email: string): boolean`.
Test cases:
– “user@example.com” → true
– “user@.com” → false
– “” → false
After implementing, run `npm test — test/validateEmail.test.ts`
and fix any failures.
หลักง่ายๆ คือ ถ้า verify ไม่ได้ อย่าเพิ่ง ship ไม่ว่าจะเป็นคนเขียนหรือ AI เขียนก็ตาม
.
2. สำรวจ Codebase ก่อน วางแผนก่อน แล้วค่อยเขียนโค้ด
ถ้าปล่อยให้ Claude กระโดดเขียนโค้ดเลย บ่อยครั้งมันจะแก้ผิดปัญหา แยกขั้นตอนให้ชัดจะดีกว่า
2.1 ให้ Explore ก่อน คือ ใช้ Plan Mode ให้ Claude อ่านโค้ดตอบคำถาม ยังไม่ต้องแก้อะไร เช่น
Read @src/auth and explain how session/token flow works.
2.2 ให้ Plan (ใช้ Plan Mode) ให้สร้างแผนไฟล์ที่ต้องแก้, tests ที่ต้องเขียน, risks ต่างๆ เช่น
Create a plan to add Google OAuth: files to change, DB schema, tests.
กด `Ctrl+G` ถ้าอยากแก้แผนเองก่อนให้ Claude ลงมือจริง
2.3 เริ่ม Implement (Normal Mode) จากนั้นสั่งให้ทำตามแผน และบังคับรัน test เช่น
Implement OAuth per plan. Write tests and run them.
2.4 ให้ Commit งานเสมอ ถ้าเสร็จแล้ว ให้ Claude commit + เปิด PR เช่น
Commit: “feat(auth): add google oauth” and open PR.
ถ้างานเล็กๆ เช่น fix typo หรือเพิ่ม log line ให้ข้ามไปสั่งทำเลยได้ ไม่ต้อง plan ทุกเรื่อง
.
—
3. เขียน Prompt ให้เจาะจง และให้ข้อมูลที่ครอบคลุม
ยิ่งเราบอก Claude ละเอียดเจาะจงมากเท่าไหร่ ก็ยิ่งลดจำนวนรอบที่ต้องกลับมาแก้มากขึ้นเท่านั้น ควรระบุให้ครบ เช่น ไฟล์ไหน, ข้อจำกัดอะไร, ตรวจยังไง เป็นต้น
แบบนี้ กว้างเกินไป
“Fix the login bug.”
แบบนี้เจาะจงกว่า
Users report login fails after session timeout.
Check auth flow in src/auth/, especially token refresh.
Write a failing test that reproduces the issue, then fix it.
Constraint: no new dependencies.
Run `pnpm test — tests/session.test.ts` to verify.
และควรให้ข้อมูลแบบ Rich Input ด้วย Claude สามารถรับได้มากกว่าแค่ข้อความ
– `@path/to/file`** ควรชี้ไปที่ไฟล์ตรงๆ แทนบอกด้วยคำพูด
– Paste screenshot สำหรับงาน UI ลากวางได้เลย
– `cat error.log | claude` ใช้ pipe log เข้าไปให้วิเคราะห์
– ให้ URL ของ docs/API reference ให้ Claude fetch เองได้
– ชี้ pattern ที่มีอยู่แล้ว เช่น “ดู CourseService.ts แล้วทำตาม pattern เดียวกัน”
.
—
4. ตั้งค่า Environment ให้พร้อม (ทำครั้งเดียว ใช้ได้ตลอด)
4.1 สร้าง CLAUDE.md กฎต่างๆ ของโปรเจกต์เราที่ Claude จะอ่านทุก session
คือให้รัน /init ให้มันสร้าง starter file แล้ว refine เอง ใส่แค่สิ่งที่ Claude เดาเองไม่ได้ เช่น
– Test: `npm test:unit`
– Build: `npm build`
– Style: Prettier + ESLint, prefer named exports
– Git: feature branches `feat/<short-desc>`, PR template required
– When compacting: keep list of modified files and test commands
กฎง่ายๆ คือ ถ้าลบบรรทัดนี้ออก แล้ว Claude ยังทำถูกอยู่ ควรลบทิ้ง อย่ายาวเกิน ยาวไป Claude จะ ignore กฎที่สำคัญจริงๆ
ตรวจสอบ CLAUDE.md เข้า git ให้ทีมใช้ร่วมกัน มันจะ compound value ขึ้นเรื่อยๆ
4.2 การจัดการ Permissions เพื่อลดการกดอนุญาตซ้ำๆ
– ใช้ `/permissions` allowlist คำสั่งที่ปลอดภัย เช่น `npm run test`, `git commit`
– ใช้ `/sandbox` สำหรับ OS-level isolation
– ใช้คำสั่ง `–dangerously-skip-permissions` → เฉพาะใน container ที่ไม่มี internet เท่านั้น
4.3 CLI Tools ติดตั้ง CLI ให้ Claude ใช้
Claude ใช้ CLI tools ได้เก่งมาก ติดตั้ง `gh`, `aws`, `gcloud`, `sentry-cli` ไว้ให้ Claude จะดึง context ได้เร็วและถูกต้องกว่าการเรียก API ตรงๆ
Claude ยังเรียนรู้ CLI ใหม่ได้เองด้วย เช่น สั่งว่า
Use `foo-cli –help` to learn about foo, then use it to solve X.
4.4 ใช้ MCP Servers เพื่อเชื่อม external tools
ใช้คำสั่ง claude mcp add เชื่อม Notion, Figma, database, issue tracker ฯลฯ ให้ Claude ดึงข้อมูลจาก external services ได้โดยตรง
4.5 ใช้ Hooks คือ action ที่ต้องเกิดทุกครั้ง ไม่มีข้อยกเว้น
ต่างจาก CLAUDE.md ที่เป็น “คำแนะนำ” ส่วน Hooks เป็น deterministic จะรันอัตโนมัติทุกครั้ง เช่น
– รัน eslint หลังทุก file edit
– Block writes ไปที่ migrations folder เป็นต้น
สั่ง Claude เขียน hook ให้ก็ได้นะ เช่น สั่งว่า “Write a hook that runs eslint after every file edit.”*
4.6 ใช้ Skills domain knowledge เฉพาะทาง
สร้าง `SKILL.md` ใน `.claude/skills/` สำหรับ conventions หรือ workflows ที่ใช้บ่อย Claude จะโหลดมาใช้เมื่อเกี่ยวข้อง ไม่โหลดทุก session
ทำ repeatable workflows ได้ด้วย เช่น `/fix-issue 1234` สั่งให้ Claude ดึง issue → แก้ → test → commit → PR ครบจบ
4.7 Subagents ผู้ช่วยเฉพาะทางที่รันใน context แยก
นิยามใน `.claude/agents/` เช่น security-reviewer มี tools set เฉพาะ ไม่เปลือง context ของ session หลัก
4.8 Plugins ติดตั้งชุดเครื่องมือสำเร็จรูป
`/plugin` ค้นหาใน marketplace จะได้ทั้ง skills + hooks + subagents + MCP มาครบในตัวเดียว
.
—
5. จัดการ Context Window ทรัพยากรที่สำคัญที่สุด
Context window เก็บทุกอย่าง ทุกข้อความ ทุกไฟล์ที่อ่าน ทุก command output แค่ debug session เดียวก็กินไปหลายหมื่น tokens แล้ว พอ context เต็ม Claude จะเริ่มลืม instruction เก่า ทำผิดบ่อยขึ้น
กฎปฏิบัติ คือ
– ใช้คำสั่ง `/clear` บ่อยๆ เปลี่ยนหัวข้อ ก็ clear เลย อย่าเอาหลายเรื่องยัดใน session เดียว
– แก้ซ้ำเกิน 2 ครั้ง ควร `/clear` แล้วเริ่มใหม่ เขียน prompt ใหม่ที่ดีกว่า รวม feedback จากรอบก่อน คือ session ใหม่ + prompt ดีกว่า เกือบทุกครั้งจะดีกว่า session ยาวๆ ที่สะสม context ขยะ
– ใช้ /compact <instructions> เช่น `/compact Focus on the API changes คือ สรุปเฉพาะสิ่งสำคัญ เพื่อลดขนาด context
– ใช้ Subagent สำหรับงานสำรวจ เช่น สั่งว่า “use subagents to investigate X” มันจะสำรวจใน context แยก แล้วส่งสรุปกลับมาสั้นๆ ไม่ดึงไฟล์ทั้งหมดเข้า session หลัก
.
—
6. สื่อสารกับ Claude อย่างมีประสิทธิภาพ
คือ ถามเหมือนถาม Senior Engineer เลย
ไม่ต้อง prompt พิเศษ ถามตรงๆ เหมือนถามเพื่อนร่วมทีมที่รู้ codebase ดี
– “Logging ทำงานยังไง?”
– “สร้าง API endpoint ใหม่ต้องทำยังไง?”
– “ทำไม line 333 เรียก foo() แทน bar()?”
– “มี race condition ใน cart checkout ไหม ชี้ line references ให้หน่อย”
ใช้ท่านี้ตอน onboard เข้าโปรเจคใหม่ดีมาก ลด ramp-up time และไม่ต้องรบกวนคนในทีม
ให้ Claude สัมภาษณ์เราก่อนทำ feature ใหญ่ สำหรับงานที่ scope ยังไม่ชัด ให้ Claude ถามเราก่อน เช่น
I want to build [brief description]. Interview me in detail.
Ask about technical implementation, edge cases, UX, performance tradeoffs.
Keep going until we’ve covered everything, then write SPEC.md.
Claude จะถามสิ่งที่เราอาจไม่ได้คิดถึง พอได้ spec ครบ เปิด session ใหม่เพื่อ implement ด้วย context ที่สะอาด
.
—
7. ใช้ Rewind / Checkpoints อย่างกล้าหาญ
Claude สร้าง checkpoint อัตโนมัติทุกครั้งที่แก้โค้ด ไม่ต้องกลัวว่าจะพังย้อนได้เสมอ
– ใช้ปุ่ม `Esc` เพื่อหยุด Claude ทันที context ยังอยู่ สั่งต่อได้
– ใช้ปุ่ม `Esc + Esc` หรือ `/rewind` เลือก checkpoint แล้ว revert ได้ทั้ง conversation, code, หรือทั้งคู่
– ใช้ “Undo that” ให้ Claude ย้อนการเปลี่ยนแปลงล่าสุด
Checkpoints persist ข้าม sessions ปิด terminal แล้วเปิดมา rewind ได้
การ Resume conversations
– `claude –continue` เพื่อกลับไปต่อ session ล่าสุด
– `claude –resume` เพื่อเลือกจาก session เก่าๆ
– `/rename` ตั้งชื่อ session เช่น “oauth-migration” ให้หาง่าย
.
—
8. Scale ทำงานหลายอย่างพร้อมกัน
ใช้ Headless Mode เพื่อรัน Claude ใน CI/scripts
ใช้ Parallel Sessions เพื่อรันหลาย Claude พร้อมกัน
– Claude Code desktop app: จัดการหลาย session แบบ visual
– Claude Code on the web: รันบน cloud VMs
– Agent teams: หลาย session ประสานงานกันอัตโนมัติ
Pattern ที่ดีมาก: Writer/Reviewer Session A เขียนโค้ด, Session B review ด้วย context สะอาด (ไม่ bias ต่อโค้ดที่ตัวเองเขียน), Session A แก้ตาม feedback เป็นต้น
.
—
สรุป
Anti-patterns ที่เจอบ่อย เจอเร็ว แก้เร็ว
– Kitchen Sink Session ถามหลายเรื่องใน session เดียว context เต็มขยะ ควร /clear ทุกครั้งที่เปลี่ยนเรื่อง
– แก้ซ้ำไม่จบ ถ้าสั่งไป 3-4 รอบ ยิ่งแก้ยิ่งแย่ ถ้าแก้เกิน 2 ครั้ง ควร /clear แล้วเขียน prompt ใหม่ที่ดีกว่า
- CLAUDE.md ยาวเกิน กฎสำคัญโดนกลบ Claude ignore แล้วลบออก ถ้า Claude ยังทำถูกอยู่ แปลว่าไม่ต้องใส่
– Infinite Exploration สั่ง investigate ไม่ scope อ่านร้อยไฟล์ context หมด ควร scope ให้แคบ หรือใช้ subagent
- Trust-then-verify โค้ดดูดีเลยเชื่อเลย ไม่ test หรือ verify ไม่ได้ อย่า ship ให้ Claude รัน test ก่อนจบงานทุกครั้ง
—
แนะนำ Prompt Templates ใช้ได้เลย
Bug fix เล็กๆ
Fix failing tests in tests/session.test.ts.
– Read src/auth/session.ts and the test file
– Run `pnpm test — tests/session.test.ts`
– Fix without adding new dependencies
– Commit: “fix(auth): session token handling”
ถ้าสร้าง Feature ใหม่ (ใช้ Plan Mode)
(Plan Mode)
Explore src/auth and explain current session flow in 5-7 bullets.
Then create a plan to add Google OAuth: files, DB schema, tests, edge cases.
(Normal Mode)
Implement the plan. Write tests, run them, fix failures.
Commit: “feat(auth): add google oauth” and open PR.
.
ถ้าต้องการ สำรวจ codebase อาจสั่งว่า
Use subagents to investigate:
1. How authentication handles token refresh
2. Whether we have existing OAuth utilities to reuse
Summarize findings — don’t modify any files.
.
Best practices เปล่านี้เป็นจุดเริ่มต้น ไม่ใช่กฎตายตัว บางทีก็ต้อง skip plan mode บางทีก็ต้องปล่อยให้ context สะสมเพราะกำลัง deep dive ปัญหาเดียว
สิ่งที่สำคัญคือ ให้สังเกตว่า Claude ทำงานดีตอนไหน ใช้ prompt structure แบบไหน, context แค่ไหน, mode ไหน แล้วปรับให้เข้ากับ workflow ของตัวเอง
.
ยิ่งใช้เยอะ ยิ่งจะรู้เองว่า ตอนไหนควรสั่งละเอียด ตอนไหนปล่อยให้ Claude คิดเอง ตอนไหนควร clear context ตอนไหนปล่อยให้มันสะสมไป อันนี้อ่าน guide กี่รอบก็ไม่ช่วย ต้องลองใช้เองถึงจะรู้สึกได้ครับ
ขอให้สนุกกับการใช้ AI เขียนโค้ดครับ
.
โค้ชเอก