วิธีตั้งค่า CLAUDE.md ในปี 2026: เทมเพลตและกฎ 6 ข้อ

เนื้อหาเกี่ยวกับ vibe coding: เครื่องมือ กรณีศึกษา และข้อผิดพลาด Ailoot Guides.

ทำไมคุณจึงต้องมี CLAUDE.md และทำไม Claude ถึงลืมโปรเจกต์หากไม่มีไฟล์นี้?#

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

พอถึงวันพฤหัสบดี แชตเดิมก็จบไปแล้ว คุณจึงต้องอธิบายทุกอย่างซ้ำอีกครั้ง วันเสาร์ก็อีกครั้ง วันจันทร์ก็อีกครั้ง

การทำงานกับเอเจนต์ที่ไม่มี CLAUDE.md เป็นแบบนี้: ทุกหน้าต่างใหม่คือเด็กฝึกงานที่เริ่มจากศูนย์ ซึ่งคุณต้องบอกเรื่องเดิมซ้ำแล้วซ้ำเล่า เมื่อก่อนฉันใช้เวลา 5-10 นาทีพิมพ์เกริ่นนำแบบนี้ทุกเซสชัน พรอมต์ยิ่งยาวขึ้นเพราะฉันต้องใส่บริบททั้งหมดด้วยตัวเอง แต่ผลลัพธ์ก็ยังเป็นแบบทั่ว ๆ ไปอยู่ดี: เอเจนต์ไม่รู้จักกลุ่มเป้าหมาย เศรษฐศาสตร์ หรือหลักการของฉัน

เมื่อมี CLAUDE.md ที่อัปเดตอยู่เสมอ ก็ไม่ต้องเกริ่นนำอีก กฎทั้งหมดที่คุณเคยต้องพูดซ้ำในทุกแชตจะอยู่ในไฟล์เดียว และปรากฏโดยอัตโนมัติเมื่อเริ่มแต่ละเซสชัน พรอมต์จึงสั้นลงเหลือแค่ “ทำ X” แทนที่จะเป็น “ฉันกำลังทำงานกับโปรเจกต์ Y เครื่องมือคือ Z อย่าทำ A หรือ B แล้วก็อย่าลืม C ด้วย”

จากนั้นข้อผิดพลาดเดิม ๆ ก็จะหายไป

ความผิดพลาดของเอเจนต์ทุกครั้งเป็นเหตุผลให้เพิ่มหนึ่งบรรทัดใน CLAUDE.md ผ่านไปหนึ่งเดือน คุณจะมี “ธรรมนูญประจำโปรเจกต์” ที่มีชีวิต และ Claude จะเลิกติดกับดักเดิม ๆ ซ้ำแล้วซ้ำเล่า

ยังมีอีกชั้นหนึ่ง: เอเจนต์จะไม่เขียนงานโดยไม่มีบริบทอีกต่อไป ฉันใช้ CLAUDE.md นำทาง Claude ไปยังโฟลเดอร์ที่มีบริบท เช่น แหล่งข้อมูลเกี่ยวกับกลุ่มเป้าหมาย ราคา และแบรนด์ หากไม่มีการนำทางนี้ เอเจนต์จะเขียน “โซลูชันคุณภาพสูง” โดยไม่รู้จักเศรษฐศาสตร์ของฉัน ผลงานจึงออกมาเป็นนามธรรม เป็นสูตรสำเร็จ และ “เหมือนของคนอื่นไปหมด”

CLAUDE.md คืออะไร และ Claude อ่านไฟล์เหล่านี้ตามลำดับใด?#

Anthropic อธิบาย CLAUDE.md ไว้ในเอกสารประกอบอย่างเป็นทางการดังนี้:

ตำแหน่งทั้งสี่ที่ Claude Code ค้นหา CLAUDE.md เรียงตามลำดับความสำคัญจากน้อยไปมาก:

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

มีรายละเอียดทางเทคนิคอย่างหนึ่งที่แทบไม่มีใครเขียนถึง แต่ช่วยอธิบายพฤติกรรมแปลก ๆ ได้มาก

กล่าวอีกอย่างคือ CLAUDE.md ไม่ใช่ “พรอมต์ระบบ” ในความหมายอย่างเคร่งครัด แต่เป็นข้อความแรกจากผู้ใช้ที่ Claude เห็น ดังนั้นกฎในไฟล์จึงเป็นคำแนะนำที่หนักแน่น ไม่ใช่กฎหมาย หากกฎต้องบังคับ ให้ใช้ hook ที่ทดสอบสำหรับ event ที่ครอบคลุม และใช้สิทธิ์หรือแยกสภาพแวดล้อมสำหรับขอบเขตกว้างกว่า การรัน hook อัตโนมัติไม่ทำให้การตรวจครบถ้วน ฉันจะอธิบายขอบเขตระหว่าง hooks กับ CLAUDE.md ด้านล่าง

เขียน CLAUDE.md ขั้นต่ำให้เสร็จใน 5 นาทีได้อย่างไร (เทมเพลตพร้อมใช้)?#

ด้านล่างคือเทมเพลตที่ฉันทดลองใช้กับโปรเจกต์ของตัวเองหลายสิบโปรเจกต์แล้ว ช่วยให้ไฟล์มีความยาวประมาณ 80-120 บรรทัด อยู่ในคำแนะนำ Anthropic ให้ตั้งเป้าต่ำกว่า 200 บรรทัด เทมเพลตนี้ช่วยให้เอเจนต์ได้ผลลัพธ์ที่สมเหตุสมผลที่สุด

# [PROJECT NAME] - project navigation

This document is the project map. Read it at the start of every session
to understand where things are and how to work with them.

## What this project is

**[NAME]** - [one sentence: what it is and who it’s for].
[1-2 sentences: what problem it solves and how].

Details are in `business/INDEX.md`.

## Reading order at the start of every session

1. `about-me/INDEX.md` - who I am and how I think
2. `business/INDEX.md` - what we do (product, audience, economics)
3. `CLAUDE.md` (this file) - repo rules, tools, navigation
4. Task area: the relevant file from `business/`, `plans/<current plan>`,
   `mastery/<area>` or the feature folder in the code

Principle: layer 1 (about me) comes before layer 2 (business) for a reason.
First, **who** is thinking, then **about what**.

## Repository structure

[NAME]/
├── CLAUDE.md            ← this file, navigation
├── about-me/            ← digital projection of you (how you think, what you value)
│   └── INDEX.md
├── business/            ← the business’s second brain
│   ├── INDEX.md
│   ├── audience/        ← customer profile
│   ├── products/        ← products, prices
│   ├── goals/           ← goals, metrics
│   └── economics/       ← unit economics, revenue
├── plans/               ← technical plans (one plan = one feature)
├── retrospectives/      ← reflections after each session
└── (project code)

### Where to find things

| What you need | Where to look |
|---|---|
| Why we’re building the project, and for whom | `business/INDEX.md` |
| Target customer, pains, desires | `business/audience/` |
| Product, plans, prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics | `business/economics/` |
| Technical plans | `plans/` |

## Tools

[INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL].

## Repo rules

1. Never hardcode dynamic data (prices, dates, figures) -
   get everything from files in `business/` and the LIVE marker.
2. Don’t publish without my explicit command.
3. Before `git push`, run `npm run build` and check that it
   builds without errors or warnings.
4. Add files by name with `git add`. Never use `git add .` or `git add -A`.
5. Don’t read `.env` in full. To check a variable, use
   `grep "^VAR=" .env`.

## Big features = a plan in `plans/`

Any task lasting more than an hour must be written up as a plan in the `plans/` folder:
1. Filename: `YYYY-MM-DD-feature-name.md`.
2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`.
3. At the end of the plan, add a summary: whether it was fully implemented and what remains.

## End-of-feature cycle

After each feature is complete, go through these 5 steps:
1. Find errors → prove them with an example → fix them.
2. What was missed (edge cases, input validation, error handling).
3. Is this a real problem in our project? Check `business/` and `plans/`.
4. Take a fresh look: reread the diff as if you’re seeing it for the first time.
5. Security review. Especially: personal data and third-party materials.

## End-of-session reflection

In `retrospectives/YYYY-MM-DD_short-name.md`, record:
1. What the task was.
2. How it was solved.
3. Whether it was solved - yes / no / partially.
4. What could have been done better.
5. What was learned about the user or project.

## Language

Always respond in the user’s preferred language. Use hyphens only, not em dashes.

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

Create a CLAUDE.md file at the project root using this template:

[INSERT THE ENTIRE TEMPLATE FROM ABOVE]

Proceed as follows:

Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author.

Fill in all the square-bracketed fields in the template based on what you find in those folders.

If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options.

ตั้งเป้า CLAUDE.md ที่ได้ต่ำกว่า 200 บรรทัด หากยาวกว่าให้ตรวจซ้ำและย้ายขั้นละเอียดไปไฟล์ลิงก์ คงกฎวางแผน ทบทวน และ repository ที่สำคัญ แล้วลองงานตัวแทนยืนยัน

Show me the final file and ask what should be revised.

Always respond in the user’s preferred language.

หากคุณยังไม่มีโฟลเดอร์ about-me/ และ business/ ก็ไม่เป็นไร Claude จะถามคำถามเพื่อขอข้อมูลเพิ่มเติมและจัดทำ CLAUDE.md ขั้นต่ำจากข้อมูลที่มี คุณสร้างโฟลเดอร์เหล่านี้ภายหลังได้ เมื่อรู้แล้วว่าจะใส่อะไรลงไป

กฎ 6 ข้อใดทำให้ CLAUDE.md เป็นเอกสารที่มีชีวิต?#

กฎข้อ 1 ทำให้ไฟล์มีความยาวไม่เกิน 200 บรรทัด

Anthropic สรุปไว้อย่างกระชับในเอกสารประกอบอย่างเป็นทางการ:

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

เอกสารแนะนำตั้งเป้าต่ำกว่า 200 บรรทัดเพื่อลดบริบทและช่วยทำตาม ไม่ได้กำหนดจุดล้มชัดที่บรรทัด 201 ต้องทบทวนความเกี่ยวข้อง ความขัดกัน ปริมาณโทเค็นที่โหลด และผลจริงของงานก่อนย้ายเนื้อหา

กฎข้อ 2 ปิดท้ายทุกเซสชันด้วยการทบทวน

เขียนไว้ใน CLAUDE.md ว่า “เมื่อจบแต่ละเซสชัน ให้บันทึกสิ่งที่ทำและเรียนรู้ลงใน retrospectives/YYYY-MM-DD_*.md” เมื่อเพิ่มบรรทัดนี้แล้ว Claude จะเริ่มปิดท้ายแต่ละเซสชันด้วยการทบทวนเอง คุณไม่ต้องขอ

เหตุผลที่ควรทบทวน:

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

กฎข้อ 3 commit หลังเสร็จแต่ละงาน

CLAUDE.md ของฉันระบุว่า “หลังเสร็จแต่ละงาน ให้สร้าง git commit พร้อมข้อความที่สื่อความหมาย” Claude จะเริ่มแบ่งงานเป็น commit ย่อย ๆ เอง

สิ่งนี้ให้ประโยชน์สองอย่าง อย่างแรก หากมีบางอย่างพัง คุณสามารถย้อนกลับได้ทีละการดำเนินการ แทนที่จะย้อนกลับ “ทุกอย่างที่ทำวันนี้” อย่างที่สอง ประวัติ commit จะกลายเป็นบันทึกการทำงานที่แสดงว่าอะไรเปลี่ยนไปและเรียงลำดับอย่างไร

กฎข้อ 4 เปิดดูโฟลเดอร์ business/ เสมอ

สำหรับงานใดก็ตามที่เกี่ยวกับลูกค้า ผลิตภัณฑ์ หรือข้อความ เอเจนต์ควรเปิด business/INDEX.md และไฟล์ที่เกี่ยวข้องจากที่นั่นก่อน CLAUDE.md ของฉันระบุไว้ชัดเจนว่า “เมื่อทำงานกับ UI หรือข้อความ ให้ตรวจ business/audience/avatar.md และ business/assets/brand-guidelines.md ก่อน”

หากไม่มีกฎนี้ Claude จะเขียนข้อความใน “สไตล์ทั่วไปของเว็บไซต์คุณภาพดี” แต่เมื่อมีกฎ ข้อความก็จะเป็นสไตล์ของคุณ เหมาะกับลูกค้าของคุณ และไม่มีคำต้องห้ามของคุณ

กฎข้อ 5 เพิ่มกฎหลังจากเอเจนต์ทำผิดทุกครั้ง

นี่คือกฎหลักที่ทำให้ CLAUDE.md มีชีวิตอยู่

ตัวอย่างจาก CLAUDE.md ของฉันที่เพิ่มหลังจากเกิดข้อผิดพลาดจริง:

• “ห้าม commit ไฟล์ WIP ที่คนอื่นกำลังทำอยู่ด้วย git add . ให้เพิ่มไฟล์เข้า staging โดยระบุชื่อไฟล์”
• “ก่อน push ไปยัง main ให้ตรวจ git log origin/main..main --oneline หากผลลัพธ์ไม่ว่าง ห้าม push”
• “ห้ามแต่งค่าขึ้นมาเอง ให้ดึงค่าจาก .env หรือโค้ด โดยเฉพาะ URL ชื่อผู้ใช้ และโทเคน”

แต่ละบรรทัดคือร่องรอยของเหตุการณ์เฉพาะ ครั้งหนึ่งเอเจนต์ commit branch ที่เพื่อนร่วมงานยังทำไม่เสร็จ ครั้งหนึ่งฉันรวม commit ที่คนอื่นยังไม่ได้ push และอีกครั้งเอเจนต์แต่ง URL ที่ไม่มีอยู่จริง ทุกข้อผิดพลาดกลายเป็นกฎ และบาดแผลที่เกิดจากตัวเองก็จะไม่เกิดซ้ำ

กฎข้อ 6 ใส่กฎความปลอดภัยไว้ใน .claude/settings.json ไม่ใช่ CLAUDE.md

ใน CLAUDE.md คุณเขียนได้ว่า “ห้ามแตะ .env” แต่เป็นเพียงคำขอ Claude อาจฝ่าฝืนได้ เพราะ CLAUDE.md ถูกโหลดเป็นข้อความจากผู้ใช้ ไม่ใช่กฎหมาย หากต้องการความปลอดภัยที่สำคัญ ให้ใช้ .claude/settings.json ซึ่งสามารถบล็อกคำสั่งบางอย่างได้อย่างเคร่งครัด

รายการบล็อกที่ฉันเพิ่มให้ทุกโปรเจกต์ใหม่:

• rm -rf (ลบไฟล์ใด ๆ แบบเรียกซ้ำ)
• อ่าน .env ทั้งไฟล์ (Read .env)
• ใช้ export และ curl ในคำสั่งเดียวกัน (รูปแบบหนึ่งที่อาจทำให้ข้อมูลลับรั่วไหลออกไปภายนอก)
• git push --force โดยไม่ได้รับอนุมัติอย่างชัดเจน

อ่านคู่มืออื่น ๆ ได้ที่ Ailoot.

CLAUDE.md ในธุรกิจที่กำลังดำเนินงานมีโครงสร้างอย่างไร (วิเคราะห์ไฟล์ 280 บรรทัด)?#

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

ด้านล่างคือโครงสร้าง CLAUDE.md ที่ฉันใช้งานจริง ฉันลบกฎและเส้นทางเฉพาะออกแล้ว เพราะสะท้อนการดำเนินงานภายในของฉัน แต่โครงสร้างและตรรกะของส่วนต่าง ๆ นำไปใช้กับโปรเจกต์ใดก็ได้ เพียงใส่สถานการณ์ของคุณเอง ก็จะได้ไฟล์ที่ใช้งานได้

1. คำอธิบายโปรเจกต์โดยย่อ (15 บรรทัด) เราทำอะไร กลุ่มเป้าหมายคือใคร และมีผลิตภัณฑ์อะไรบ้าง ไม่ใช่ข้อความสรุปจากเว็บไซต์การตลาด แต่เป็นสรุปสำหรับเอเจนต์เพื่อให้เข้าใจว่า “เรากำลังมุ่งไปทางไหน”

2. เกี่ยวกับฉัน (10 บรรทัด) ลิงก์ไปยังโฟลเดอร์ about-me/ ซึ่งเป็นภาพสะท้อนดิจิทัลของวิธีคิด น้ำเสียง ค่านิยม หลักการ และคำต้องห้ามของฉัน เมื่อ Claude เขียนข้อความ “ในนามฉัน” มันจะอ่านโฟลเดอร์นี้ก่อนเพื่อให้เสียงตรงกัน

3. โครงสร้าง repository (20 บรรทัด) ผังพร้อมคำอธิบายว่ามีโค้ดอยู่ที่ไหน บริบททางธุรกิจอยู่ตรงไหน และมีแผนกับบันทึกทบทวนอยู่ที่ใด หากไม่มีแผนที่นี้ Claude จะค้นหาไฟล์แบบสุ่มทุกครั้ง

4. ตาราง “จะหาอะไรได้จากที่ไหน” (25 บรรทัด) เส้นทางจาก “คำถาม → ไฟล์” ตัวอย่างเช่น สำหรับบริษัทอสังหาริมทรัพย์ อาจระบุว่า “ต้องการเงื่อนไขสินเชื่อที่อยู่อาศัย → business/products/mortgage.md” หรือ “ต้องการน้ำเสียงของโพสต์ → business/assets/voice.md” ให้แทนที่ด้วยไฟล์ของคุณเอง ตารางนี้คือหัวใจของ CLAUDE.md หากไม่มี เอเจนต์จะเดาว่าไฟล์ไหนมีคำตอบ แต่ถ้ามี เอเจนต์จะไปที่แหล่งข้อมูลโดยตรง

5. หลักการสำคัญของโปรเจกต์ (40 บรรทัด, 10-15 ข้อ) ส่วนนี้ค่อย ๆ สะสมและใช้ความพยายามมากที่สุด แต่ละข้อเป็นร่องรอยของข้อผิดพลาดเฉพาะ ตัวอย่างเช่น สำหรับร้านค้าออนไลน์ กฎอาจเป็น “ห้ามกำหนดราคาและเวลาในการจัดส่งไว้ตายตัว” “ห้ามเผยแพร่สินค้าโดยไม่มีคำสั่งอย่างชัดเจน” และ “ตรวจสอบสไตล์กับอภิธานศัพท์แบรนด์ก่อนเผยแพร่รายการสินค้า” ส่วนนี้คือ “ธรรมนูญประจำโปรเจกต์”

6. การวางแผนการดำเนินงาน (20 บรรทัด) ตารางตัวกระตุ้นที่จับคู่ “คำพูดของผู้ใช้ → การดำเนินการ” ตัวอย่างเช่น “เมื่อฉันพูดว่า ‘วางแผนสัปดาห์นี้’ ให้เปิด ops/monthly.md แล้วสร้างไฟล์ของสัปดาห์นี้” วิธีนี้เปลี่ยน Claude ให้เป็นผู้ช่วยด้านปฏิบัติการที่เข้าใจบริบทของคำสั่ง

7. เครื่องมือ (5 บรรทัด) เทคโนโลยี เขียนสั้น ๆ ไม่ต้องเติมน้ำ

8. การเผยแพร่ (15 บรรทัด) ขั้นตอนเผยแพร่การเปลี่ยนแปลงขึ้น production ว่าต้องเรียกใช้คำสั่งใด ตามลำดับไหน และต้องตรวจอะไรบ้าง เมื่อก่อนฉันต้องอธิบายทุกครั้ง ตอนนี้ Claude รู้แล้ว

9-12. ความปลอดภัย (35 บรรทัด) แบ่งเป็นส่วนย่อย 4 ส่วน ได้แก่ กฎการใช้ .env การเข้าถึงฐานข้อมูล production คำสั่งที่ปลอดภัยสำหรับการสาธิต (การบันทึกหน้าจอ สตรีม และภาพหน้าจอ เพื่อป้องกันไม่ให้โทเคนรั่วไหลโดยไม่ตั้งใจ) และกฎการหมุนเวียนข้อมูลลับ

13. โฟลเดอร์ plans/ (10 บรรทัด) มาตรฐานของแผน ได้แก่ ชื่อไฟล์ โครงสร้างเฟส และสิ่งที่ควรใส่ในบล็อกสรุป

14. โฟลเดอร์ retrospectives/ (5 บรรทัด) มาตรฐานการทบทวน ได้แก่ เทมเพลต ชื่อไฟล์ และเนื้อหาที่ควรมี

15. ข้อมูลฐานข้อมูลแบบสด (15 บรรทัด) กฎสำหรับระบุว่า “ข้อมูลต้องเป็นปัจจุบัน”: เมื่อไฟล์ระบุว่าตัวเลขต้องเป็นข้อมูลล่าสุด เอเจนต์จะดึงข้อมูลจากแหล่งที่มาแทนการใช้ข้อมูลเก่า ช่วยลดความเสี่ยงที่ Claude จะใช้ตัวเลขของเมื่อวาน

16. ภาษา (3 บรรทัด) “ตอบเป็นภาษาที่ผู้ใช้ต้องการเสมอ ใช้ยัติภังค์เท่านั้น ห้ามใช้ em dash”

รวมประมาณ 280 บรรทัด เกินเป้ากระชับแต่ไม่ทำให้ไฟล์ใช้ไม่ได้ ตัวอย่างนี้ยังมีประโยชน์ การเก็บควรขึ้นกับบริบทที่วัดและงานตัวแทนที่ตรวจ ตารางไม่ได้ใช้โทเค็นถูกกว่าร้อยแก้วอัตโนมัติ

คำสั่ง /init ทำอะไร และทำไมจึงไม่เพียงพอ?#

Anthropic อธิบายคำสั่งนี้ไว้ในเอกสารดังนี้:

สิ่งที่ /init ทำได้ดี:

• ตรวจหาเครื่องมือจาก package.json, Cargo.toml และ pyproject.toml
• แสดงคำสั่ง build และ test
• ตรวจพบธรรมเนียมจากไฟล์ที่มีอยู่ (.eslintrc, .prettierrc)
• สังเกตกฎของ Cursor ที่มีอยู่ (.cursorrules, .cursor/rules/) และกฎของ Copilot แล้วนำส่วนที่เกี่ยวข้องมารวมไว้ โดยจะตรวจพบ AGENTS.md ในโหมด CLAUDE_CODE_NEW_INIT=1

สิ่งที่ /init ทำไม่ได้:

• ไม่รู้ว่าลูกค้าของคุณคือใคร
• ไม่ใส่คำต้องห้ามสำหรับข้อความของคุณ
• ไม่เพิ่มกฎเกี่ยวกับข้อผิดพลาดของเอเจนต์ เพราะยังไม่มีข้อผิดพลาดเกิดขึ้น
• ไม่สร้างตาราง “จะหาอะไรได้จากที่ไหน” สำหรับโครงสร้างธุรกิจของคุณ

ดังนั้นเวิร์กโฟลว์ที่เหมาะสมคือ:

1. เรียกใช้ /init ใน Claude Code

   คุณจะได้ CLAUDE.md ตั้งต้นความยาว 30-50 บรรทัด พร้อมเครื่องมือและคำสั่ง ซึ่งเป็นพื้นฐานทางเทคนิค

2. เติมเทมเพลตจากบทความนี้ลงไป

   ใช้ส่วน “CLAUDE.md ขั้นต่ำใน 5 นาที” เพิ่มส่วนการนำทาง การชี้ไปยังไฟล์ และหลักการ

3. กรอกข้อมูลในช่องวงเล็บเหลี่ยม

   ส่งพรอมต์ให้ Claude ว่า “อ่านโปรเจกต์ของฉันแล้วเติมเทมเพลต” หากยังไม่มีโฟลเดอร์ business/ และ about-me/ Claude จะถามคำถามเพื่อขอข้อมูลเพิ่มเติม

4. ทดสอบความทนทาน

   บอก Claude ว่า “อ่าน CLAUDE.md ของฉัน แล้วหาความกำกวม 10 จุดที่อาจทำให้คุณในฐานะเอเจนต์เข้าใจผิด” คุณจะได้รายการสิ่งที่ควรแก้ไข

5. จากนั้นใช้ชีวิตร่วมกับไฟล์นี้

   เพิ่มหนึ่งบรรทัดหลังจากเอเจนต์ทำผิดทุกครั้ง อีกหนึ่งเดือนคุณจะมี CLAUDE.md ที่มีชีวิตและปรับให้เข้ากับธุรกิจของคุณ

พรอมต์สำหรับขั้นตอนที่สี่:

I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it.

Your task is to stress-test it. Find 10 reasons we could potentially fail:

where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it

where there are gaps that would force you to make things up

where rules contradict one another

where I overestimate how much can be done in one day

where I underestimate things (this is even worse)

Don’t hold back. Criticize it harshly. I want to find these issues now, not in production.
At the end, give me a list of specific changes: what to change and how, so these problems don’t happen.

CLAUDE.md, AGENTS.md และ MEMORY.md ต่างกันอย่างไร: ใครอ่านอะไรในปี 2026?#

คำถามหลักที่ทำให้ผู้ใช้ใหม่สับสนคือ Claude Code อ่าน AGENTS.md หรือไม่? ก่อนเดือนกันยายน 2026 คำตอบคือ “ไม่”: เอกสารของ Anthropic แนะนำให้สร้าง CLAUDE.md ที่นำเข้า AGENTS.md ตั้งแต่เวอร์ชัน 2.1.277 (เผยแพร่วันที่ 18 กันยายน 2026) Claude Code อ่าน AGENTS.md ได้เอง แต่จะอ่านก็ต่อเมื่อไม่มี CLAUDE.md, .claude/CLAUDE.md หรือ CLAUDE.local.md ในโฟลเดอร์ทำงานหรือโฟลเดอร์ระดับบน

หากโปรเจกต์มี CLAUDE.md Claude Code จะอ่านเฉพาะไฟล์นั้นตามค่าเริ่มต้น และข้าม AGENTS.md คุณเปลี่ยนการตั้งค่านี้ได้ที่ /config ในหัวข้อ Project instructions เช่น ตั้งค่า claude-md-and-agents-md เพื่อให้อ่านทั้งสองไฟล์ อีกวิธีหนึ่งที่ใช้ได้ทุกเวอร์ชันคือเพิ่มการนำเข้าใน CLAUDE.md:

@AGENTS.md

## Claude Code

Additional rules for Claude Code that other agents don’t need.

ไวยากรณ์ @filename ใช้นำเข้าไฟล์อื่น Claude จะอ่านไฟล์นั้นและโหลดเข้าสู่บริบทพร้อมกับ CLAUDE.md การนำเข้านี้ไม่ทำให้ไฟล์ถูกอ่านซ้ำ แม้ Claude Code จะอ่าน AGENTS.md ได้เองก็ตาม

เมื่อใดจึงต้องใช้ AGENTS.md หากคุณทำงานร่วมกันโดยใช้ Claude Code และ Codex CLI, Cursor หรือ Copilot ให้สร้าง AGENTS.md เป็นแหล่งข้อมูลหลักเพียงแห่งเดียว ใส่ @AGENTS.md ใน CLAUDE.md และเพิ่มกฎเฉพาะ Claude ไว้ด้านบน หากไม่มีกฎเฉพาะเหล่านั้น คุณไม่จำเป็นต้องสร้าง CLAUDE.md เพราะตั้งแต่เวอร์ชัน 2.1.277 Claude Code จะอ่าน AGENTS.md เอง หากใช้เฉพาะ Claude Code ก็ไม่จำเป็นต้องมี AGENTS.md ให้ใช้ CLAUDE.md ไฟล์เดียว สำหรับตัวเลือกทั้งหมดแบบทีละขั้นตอน ดูได้ที่ คู่มือการใช้ AGENTS.md และ CLAUDE.md ร่วมกันในโปรเจกต์เดียว

MEMORY.md คืออะไร? ตั้งแต่อัปเดตครั้งล่าสุด Claude Code จะเก็บบันทึกเกี่ยวกับคุณโดยอัตโนมัติไว้ที่ ~/.claude/projects/<project-name>/memory/MEMORY.md ซึ่งรวมถึงพฤติกรรมในการสนทนา (“ผู้ใช้ชอบคำตอบสั้น ๆ”) วลีที่ใช้ซ้ำ (“ห้ามใช้อีโมจิในโค้ด”) และข้อสังเกตด้านพฤติกรรม (“ใช้ macOS และ zsh”)

นี่เป็นระบบความจำแยกต่างหาก ไม่ใช่ CLAUDE.md คุณไม่ต้องเขียนด้วยตนเอง Claude เขียนขึ้นจากบทสนทนาของคุณ หาก MEMORY.md มีสิ่งที่ควรกลายเป็นกฎ ให้ย้ายไปไว้ใน CLAUDE.md หากมีเนื้อหาที่ไม่จำเป็นหรือไม่ถูกต้อง คุณลบด้วยตนเองได้ เพราะเป็นไฟล์ข้อความ

CLAUDE.md ขนาดใดมีประโยชน์ และควรทบทวนไฟล์ยาวอย่างไร?#

ในทุกหน้าต่างของ Claude Code มีบริบทหลายชั้นถูกโหลดเข้ามา ได้แก่ พรอมต์ระบบของ Anthropic (คาดว่ามีหลายหมื่นโทเคน), CLAUDE.md ของคุณ, ไฟล์ที่นำเข้าด้วย @, MEMORY.md, ประวัติแชตปัจจุบัน และเนื้อหาในไฟล์ที่ Claude เปิด ทั้งหมดนี้ต้องอยู่ภายในบริบทของโมเดล (200K โทเคนสำหรับ Sonnet, 1M สำหรับ Opus)

ยิ่ง CLAUDE.md ใหญ่ขึ้น พื้นที่สำหรับงานปัจจุบันก็ยิ่งน้อยลง ไฟล์ 1,000 บรรทัดมีประมาณ 8,000 โทเคน และถูกนำเข้าไปซ้ำทุกเซสชัน สำหรับการสมัคร Pro (จากประสบการณ์ของฉัน พรอมต์ “หนัก” ประมาณ 10-12 ครั้งต่อวัน) จะทำให้ความสามารถลดลงหนึ่งในสี่

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

ดังนั้นแนวทางคร่าว ๆ สำหรับขนาดไฟล์คือ:

• 80-120 บรรทัด - ช่วงเริ่มที่สะดวกสำหรับแผนที่โปรเจกต์กระชับ ไม่ใช่คะแนนทำตามที่รับประกัน
• 150-200 บรรทัด - เตือนให้ทบทวนความเกี่ยวข้องและย้ายขั้นละเอียดไปไฟล์ที่ลิงก์
• 200-300 บรรทัด - ตรวจโทเค็น ความซ้ำ และผลของงาน ตัวอย่างธุรกิจ 280 บรรทัดด้านบนอาจยังทำงานดี
• 400+ บรรทัด - เหตุผลหนักแน่นให้ทบทวนเฉพาะจุด ไม่พิสูจน์ว่าไฟล์ใช้ไม่ได้ คงข้อจำกัดสำคัญและย้ายรายละเอียดหลังตรวจว่าลิงก์กับกฎยังทำงาน

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

Anthropic ให้เกณฑ์ทดสอบโดยตรงไว้ในเอกสาร:

ใช้คำถามนี้กับทุกบรรทัด หากคำตอบคือ “ยังทำถูกอยู่” ให้ลบบรรทัดนั้น CLAUDE.md ไม่ใช่ที่สำหรับเอกสาร ประวัติการตัดสินใจ หรือปรัชญา แต่มีไว้สำหรับกฎที่เอเจนต์ต้องใช้เพื่อหลีกเลี่ยงความผิดพลาดเท่านั้น

ข้อผิดพลาด 7 แบบใดทำให้ CLAUDE.md ไร้ประโยชน์?#

ข้อผิดพลาด 1 “จงเป็นวิศวกรที่ดี”

นี่เป็นข้อผิดพลาดที่พบมากที่สุด ผู้คนเขียนความปรารถนาทั่วไปไว้ใน CLAUDE.md เช่น “เขียนโค้ดให้สะอาด” “ใช้แนวปฏิบัติที่ดีที่สุด” หรือ “คิดแบบวิศวกรอาวุโส”

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

แทนที่ “เขียนโค้ดให้สะอาด” ด้วย “ใช้การเยื้อง 2 ช่องว่าง” “ห้ามใช้ any ใน TypeScript” หรือ “ฟังก์ชันต้องยาวไม่เกิน 30 บรรทัด” สิ่งเหล่านี้เฉพาะเจาะจงและตรวจสอบได้

ข้อผิดพลาด 2 เขียนซ้ำสิ่งที่ Claude รู้อยู่แล้ว

คำอธิบายธรรมเนียมทั่วไปของภาษา (“ใน JavaScript ฟังก์ชันเป็น first-class citizen” หรือ “TypeScript เป็นภาษาที่มี static typing”) คำอธิบายวิธีทำงานของ npm, git หรือ docker

Claude เรียนรู้เรื่องเหล่านี้ระหว่างการฝึกแล้ว การเขียนซ้ำใน CLAUDE.md ไม่ได้เพิ่มอะไร มีแต่ลดพื้นที่บริบทของคุณ

ข้อผิดพลาด 3 คำสั่งทีละขั้นตอนที่ยาวใน CLAUDE.md

คำสั่งยาว ๆ เกี่ยวกับ “วิธี deploy โปรเจกต์” “วิธีเขียน database migration” หรือ “วิธีตั้งค่า component ใหม่” ที่มีหลายสิบขั้นตอน

ที่นี่ไม่ใช่ที่สำหรับคำสั่งทีละขั้นตอนที่ยาว แต่มีไว้สำหรับกฎหนึ่งบรรทัด ให้ใส่คำสั่งยาว ๆ ไว้ใน skills/ (กลไกแยกต่างหากของ Claude Code ที่โหลดเมื่อต้องการ) หรือใน docs/ ส่วน CLAUDE.md ให้ใส่ลิงก์หนึ่งบรรทัด เช่น “เมื่อสร้าง migration ใหม่ ให้อ่าน docs/migrations.md”

ข้อผิดพลาด 4 กฎที่เครื่องมือตรวจโค้ดอัตโนมัติตรวจอยู่แล้ว

“ใช้เครื่องหมายอัฒภาค” “อย่าปล่อยให้มี import ที่ไม่ได้ใช้” “ห้ามใช้ var” ESLint, Prettier และ Biome ตรวจจับสิ่งเหล่านี้ได้ทั้งหมด เพราะเป็น linter (เครื่องมือตรวจโค้ดอัตโนมัติ)

Linter ทำงานอย่างแน่นอน: เรียกใช้ ตรวจพบข้อผิดพลาด แล้วแก้ไข ส่วนกฎใน CLAUDE.md เป็นแบบอาศัยความน่าจะเป็น เอเจนต์อาจลืม ไม่จำเป็นต้องเขียนซ้ำ ตั้งค่า linter ง่ายกว่า

ข้อผิดพลาด 5 มีความลับใน CLAUDE.md

ฉันเคยเห็นรหัสผ่านบัญชีทดสอบ โทเคน API สำหรับ sandbox และลิงก์ไปยังแผงผู้ดูแลระบบที่ต้องยืนยันตัวตน ทั้งหมดอยู่ในไฟล์ที่ commit เข้า git และโหลดเข้าไปในบริบทโมเดลของ Anthropic

ห้ามทำเด็ดขาด ข้อมูลลับควรอยู่ใน .env ซึ่งอยู่ใน .gitignore อย่างมากที่สุด CLAUDE.md ควรระบุว่า “อย่าอ่าน .env ทั้งไฟล์ ให้ใช้ grep เพื่อดูตัวแปรเฉพาะรายการ”

ข้อผิดพลาด 6 ไฟล์รกที่ยาวกว่า 500 บรรทัดและไม่ได้ทำความสะอาดมาหกเดือน

CLAUDE.md ยาวขึ้น เนื้อหาซ้ำกับ docs/ ครึ่งหนึ่ง ขัดแย้งกันหลายจุด และไม่มีใครจำได้ว่ามีอะไรอยู่ในนั้น เอเจนต์เริ่มละเลยเนื้อหาส่วนใหญ่ ทีมบ่นว่า “Claude ไม่ทำตามคำสั่ง” แล้วเพิ่มกฎเข้าไปอีก ทำให้ปัญหาแย่ลง

สัญญาณว่า CLAUDE.md ถูกละเลย ได้แก่ ยาวเกิน 300 บรรทัด มีกฎซ้ำในหลายส่วน มีลิงก์เก่าไปยังไฟล์ที่ไม่มีแล้ว และมีบันทึก “ประวัติ” เช่น “ในปี 2024 เราตัดสินใจทำแบบนี้ แล้วเปลี่ยนใจในภายหลัง”

วิธีแก้: ทุกสองสัปดาห์ ให้ Claude ตรวจไฟล์ด้วยเกณฑ์ของ Anthropic ว่า “หากลบบรรทัดนี้ เอเจนต์จะทำผิดหรือไม่?” ลบทุกอย่างที่คำตอบคือ “ไม่”

ข้อผิดพลาด 7 สร้าง CLAUDE.md แล้วลืม

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

สัญญาณที่เห็นได้ชัดคือคุณต้องพูดคำสั่งเดิมซ้ำในทุกเซสชัน เช่น “อย่าทำ X” “อย่าแตะ Y” หรือ “จำ Z ไว้” หากต้องพูดซ้ำมากกว่าสองครั้ง กฎนั้นควรอยู่ใน CLAUDE.md ไม่ใช่ในหัวของคุณ

ทำให้ CLAUDE.md เรียนรู้ด้วยตนเองด้วยกฎ “อัปเดตเมื่อจบเซสชัน” ได้อย่างไร?#

CLAUDE.md ของฉันมีส่วนสั้น ๆ ดังนี้:

## Self-learning

At the end of every session, check:
- Have I learned anything new about the user or how to work with them?
- Did I break any rule that should now be recorded?

If so, create or update a file in `about-me/feedback/` in this format:
Rule (one-line rule) → Why (why it was added)
→ How to apply (when it applies).

I don’t write the rules by hand - I say, “not like that, because this is how,”
and you put it into a file.

หลังจากเพิ่มส่วนนี้ลงใน CLAUDE.md แล้ว Claude ก็เริ่มถามตอนจบทุกเซสชันว่า “มีอะไรใหม่ที่ควรบันทึกไหม?” หากมี Claude จะเสนอร่างกฎ ฉันชี้แจง แล้วจึงสร้างไฟล์

หลังทำงานด้วยวิธีนี้สองเดือน ฉันมีไฟล์มากกว่าสองโหลใน about-me/feedback/ ซึ่งเป็นกฎที่เรียนรู้จากข้อผิดพลาดเฉพาะ แต่ละไฟล์เป็นหนึ่งหน้าในรูปแบบ กฎ → เหตุผล → วิธีใช้ โฟลเดอร์นี้กลายเป็น “ความจำที่สอง” ซึ่งบันทึกความชอบและข้อห้ามเฉพาะของฉัน

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

เพิ่มกฎด้านกฎหมาย การตลาด และการปฏิบัติงานลงใน CLAUDE.md ได้อย่างไร?#

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

เมื่อผู้ประกอบการดูแล CLAUDE.md ก็ควรเพิ่มส่วนทางธุรกิจด้วย โดยมีสามส่วนสำคัญที่สุด:

กฎทางกฎหมาย (สำหรับตลาดที่มีกฎควบคุม)

หากคุณเผยแพร่ข้อความในอุตสาหกรรมที่มีกฎควบคุม (การเงิน การแพทย์ โฆษณายา และผลิตภัณฑ์สำหรับเด็ก) คำต้องห้ามมีผลทางกฎหมายและควรระบุเป็นกฎอย่างชัดเจนใน CLAUDE.md ไม่ควรอยู่ในหัวของใครหรือในภาพหน้าจอของบรรณาธิการ แต่ควรอยู่ในไฟล์ที่เอเจนต์เห็นทุกเซสชัน

ตัวอย่างสำหรับโปรเจกต์ฟินเทคที่ไม่มีใบอนุญาตธนาคาร:

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

🚨 สำคัญอย่างยิ่ง - ห้ามใช้ถ้อยคำทางการเงิน ในสื่อที่สื่อสารกับลูกค้า ห้ามใช้คำว่า “เงินฝาก” “ผลตอบแทนที่รับประกัน” หรือ “ผลิตภัณฑ์การลงทุน” ให้ใช้ “บัญชีออมทรัพย์” “ผลตอบแทนที่คาดหวัง” และ “ผลิตภัณฑ์อัตราดอกเบี้ยผันแปร” เหตุผลคือข้อกำหนดทางกฎหมายที่ใช้บังคับกับการโฆษณาบริการทางการเงินของโปรเจกต์นี้

บล็อกนี้ใน CLAUDE.md ทำสิ่งง่าย ๆ: ทุกครั้งที่คุณขอให้ Claude เขียนข้อความถึงลูกค้า เอเจนต์จะตรวจข้อความกับข้อห้ามเหล่านี้ หากไม่มีกฎ คำต้องห้ามจะปรากฏในทุก ๆ แคมเปญที่สาม แต่เมื่อมีกฎ คุณก็ลืมไปได้เลยว่ามีคำเหล่านี้อยู่

แนวทางเดียวกันนี้ใช้ได้กับ:

• โปรเจกต์การแพทย์ (ห้ามกล่าวอ้างว่าสิ่งใด “รักษา” หรือ “เยียวยา”)
• โฆษณายา (ห้ามกล่าวอ้างว่า “มีประสิทธิภาพที่สุด” และต้องมีคำเตือน)
• อุตสาหกรรมที่มีกฎควบคุมอื่น ๆ ซึ่งมีกฎโฆษณาของตนเอง

สไตล์การตลาดและรูปแบบข้อความ

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

เมื่อเขียนโพสต์ในช่องทาง ให้ดู style/posts.md ใช้เครื่องหมายการจัดรูปแบบที่ช่องทางอนุญาต และหลีกเลี่ยงอักขระพิเศษที่ “เป็นอันตราย” ปิดท้ายด้วย CTA ที่มี UTM tag ตามรูปแบบนี้: utm_source=<channel>&utm_medium=<type>&utm_campaign=<slug>

เมื่อก่อน Claude เขียนโพสต์ใน “สไตล์ทั่วไปของเว็บไซต์การตลาด” ตอนนี้มันทำตามรูปแบบของคุณ ใช้ UTM ของคุณ และไม่เผยให้เห็นว่าเขียนด้วย AI

แนวปฏิบัติในการดำเนินงาน

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

“วางแผนสัปดาห์นี้” → เปิด ops/monthly.md สร้าง YYYY-WNN.md ในโฟลเดอร์เดียวกัน และย้ายงานจาก ops/backlog.md ไปไว้ใต้วันที่เหมาะสม “มีอะไรในรายการค้าง?” → อ่าน ops/backlog.md และแสดงเป็นรายการ “ปิดสัปดาห์” → กรอกส่วน “สรุปสัปดาห์” ในไฟล์ของสัปดาห์ปัจจุบัน

เมื่อมีตารางแบบนี้ Claude จะเปลี่ยนจาก “ตัวช่วยเขียนโค้ด” เป็น “ผู้ปฏิบัติงาน” ที่รู้กิจวัตรทางธุรกิจของคุณ ทุกวันจันทร์ ฉันพูดว่า “มาวางแผนสัปดาห์กัน” แล้ว Claude ก็เปิดไฟล์ที่ถูกต้อง อ่านเป้าหมายรายเดือน และเสนอวิธีแบ่งงาน

ตรวจสอบ CLAUDE.md ด้วยรายการตรวจสอบ 12 ข้อใน 5 นาทีได้อย่างไร?#

1. ขนาด กระชับเหมาะกับงานหรือไม่ โดยใช้ราว 200 บรรทัดเป็นเป้าทบทวน ไม่ใช่เพดานผ่าน/ตก
2. ชื่อ ชื่อไฟล์ตรงกับ CLAUDE.md โดยใช้อักษรตัวพิมพ์ใหญ่ ไม่ใช่ claude.md หรือไม่?
3. ตำแหน่ง ไฟล์อยู่ที่รูทของโปรเจกต์หรือใน ./.claude/CLAUDE.md หรือไม่?
4. คำอธิบายโปรเจกต์ 5 บรรทัดแรกทำให้เข้าใจชัดเจนหรือไม่ว่าโปรเจกต์คืออะไรและทำเพื่อใคร?
5. เครื่องมือ ระบุเทคโนโลยีไว้อย่างชัดเจนและไม่เติมน้ำหรือไม่?
6. โครงสร้าง มีแผนผัง repository พร้อมคำอธิบายหรือไม่?
7. การนำทาง มีตาราง “คำถาม → ไฟล์” ที่แสดงว่าจะหาคำตอบได้ที่ไหนหรือไม่?
8. หลักการ มีส่วนที่มีกฎซึ่งขึ้นต้นด้วย “ห้าม” และ “ต้อง” หรือไม่?
9. ความเฉพาะเจาะจง ตรวจสอบกฎทุกข้อได้หรือไม่ (เช่น “ใช้ช่องว่าง 2 ช่อง” ไม่ใช่ “เขียนให้สวยงาม”)?
10. การอัปเดตตนเอง มีกฎให้ “ตรวจสอบสิ่งที่ควรเพิ่มเมื่อจบเซสชัน” หรือไม่?
11. การทบทวน มีกฎให้ “บันทึกสรุปเซสชันไว้ใน retrospectives/” หรือไม่?
12. ความปลอดภัย มีข้อห้ามสำคัญ (.env, rm -rf) อยู่ใน .claude/settings.json ด้วยหรือไม่?

หากตอบ “ไม่” มากกว่าห้าข้อ ให้เปิด Claude แล้วส่งพรอมต์นี้:

Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix.

Checklist:

กระชับพอสำหรับงาน ทบทวนเมื่อใกล้ 200 บรรทัดโดยไม่ถือเป็นเพดานบังคับ

Project description in the first 5 lines

Tools listed explicitly

Repository structure diagram included

“Question → file” table included

Principles section with rules included

Every rule is specific and verifiable

“Update at the end of the session” rule included

“Reflect at the end of the session” rule included

Critical prohibitions included in .claude/settings.json

No duplicates of the same rule in different sections

No dangling links to files that no longer exist

After the audit, give me a list of specific changes that will make the file living.

หลังจาก CLAUDE.md ควรใช้ Plan Mode, Skills หรือ sub-agents?#

CLAUDE.md เป็นรากฐาน เมื่อใช้งานได้แล้ว คุณสามารถเพิ่มกลไกสามอย่างของ Claude Code ซึ่งช่วยเสริมกันได้

Plan Mode โหมดที่ Claude สร้างแผนการเปลี่ยนแปลงก่อน รอการอนุมัติจากคุณ แล้วจึงเริ่มทำงาน เปิดใช้ด้วย Shift+Tab หรือคำสั่ง /plan วิธีนี้แก้ปัญหาหลักของ vibe coding ที่ว่า “ฉันขอให้ Claude แก้เรื่องหนึ่ง แต่มันเขียนโปรเจกต์ไปครึ่งหนึ่งใหม่” เรื่องนั้นจะไม่เกิดใน Plan Mode เพราะคุณเห็นแผนก่อนที่เอเจนต์จะแตะไฟล์ใด ๆ

Skills ไฟล์ .md แยกต่างหากในโฟลเดอร์ .claude/skills/ ที่มีความรู้สำหรับงานประเภทใดประเภทหนึ่ง ตัวอย่างเช่น skill “วิธีเขียน database migration” มีขั้นตอนเฉพาะ เทมเพลต และตัวอย่าง ความรู้นี้ไม่ได้อยู่ใน CLAUDE.md เพราะยาวเกินไป แต่เมื่อ Claude พบงานอย่าง “เขียน migration” มันจะโหลด skill ที่เกี่ยวข้องและทำตาม

Sub-agents เมื่องานต้องใช้บริบทมาก (เช่น ตรวจสอบฟีเจอร์ขนาดใหญ่) Claude สามารถเริ่ม sub-agent แยกต่างหากที่มีบริบทใหม่ของตนเอง sub-agent จะทำงานและส่งผลลัพธ์กลับมาโดยไม่ทำให้บริบทของแชตหลักรก

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

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

หากต้องการสร้างกรอบการทำงานครบชุดรอบ CLAUDE.md ซึ่งประกอบด้วยโฟลเดอร์ business/ สำหรับสมองที่สอง โฟลเดอร์ about-me/ สำหรับภาพสะท้อนดิจิทัลของคุณ skills พื้นฐาน และ Plan Mode ที่ตั้งค่าไว้ ให้ใช้ขั้นตอนและตัวอย่างในบทความนี้ คู่มือ Ailoot.

อ่านคู่มือของ Ailoot ต่อ.