SE9 — กายวิภาคของ .claude/ · วางระบบให้ AI ทำงานเป็นทีม
ใช้ปุ่ม ← → เปลี่ยนสไลด์ได้SE TRACK · MODULE 9 · AGENT HARNESS
กายวิภาคของ .claude/ — เอากฎไปไว้ให้ถูกกลไก
อาการที่เจอกันทุกโปรเจกต์: เขียนกฎเพิ่มเข้าไปเรื่อย ๆ แต่ AI ยังพลาดเรื่องเดิม — ไม่ใช่เพราะกฎน้อยเกินไป แต่เพราะกฎถูกวางผิดที่ บทนี้เปิดโฟลเดอร์ .claude/ ทีละไฟล์ แล้วบอกว่ากฎแต่ละชนิดควรอยู่ตรงไหน
ใช้เวลาประมาณ 12 นาที
คู่กับบทนี้M11 — ฉบับ Cowork ที่ไม่ต้องใช้ terminal
เป้าหมายเปิดโฟลเดอร์แล้วรู้ว่าไฟล์ไหนทำอะไร
แนวคิดหลัก
โมเดลคือสมอง — Harness คือระบบการทำงานรอบสมอง
Agent Harness ไม่ใช่ไฟล์ใดไฟล์หนึ่ง แต่คือชุดของเครื่องมือ · การจัดบริบท · สิทธิ์เข้าถึง · หน่วยความจำ · และวงจรการทำงาน ที่เปลี่ยนโมเดลภาษาให้กลายเป็น Agent ที่ลงมือทำงานได้จริง
รู้ว่าโปรเจกต์คืออะไร ของอยู่ไหน
อ่าน/แก้ไฟล์ รันคำสั่ง ใช้เครื่องมือ
test · lint · gate · หลักฐาน
ไม่ผ่านก็วนกลับไปแก้
ภาพจำประจำบท — เปิดออฟฟิศให้ AI ทำงาน: คู่มือพนักงานที่อ่านทุกเช้า = CLAUDE.md · ป้ายกติกาติดเฉพาะบางห้อง = rules/ · แฟ้ม SOP ในลิ้นชัก = skills/ · พนักงานเฉพาะทาง = agents/ · คีย์การ์ด = settings.json · เครื่องสแกนที่ประตู = Hooks · สายตรงถึงระบบภายนอก = .mcp.json · สมุดจดของพนักงานเอง = Auto memory
แผนที่ประจำบท
เปิดดูทั้งโฟลเดอร์ — อะไรอยู่ตรงไหน
ในโปรเจกต์แชร์กับทีมผ่าน git
your-project/ ├── CLAUDE.md คู่มือ อ่านทุก session ├── .mcp.json ต่อระบบภายนอก └── .claude/ ├── settings.json สิทธิ์ · hooks · config ├── settings.local.json เฉพาะเครื่องเรา ├── rules/ กฎแยกหัวข้อ จำกัด path ได้ ├── skills/ SOP โหลดเมื่อใช้ ├── agents/ ผู้ช่วยเฉพาะทาง ├── workflows/ คุม agent จำนวนมาก └── output-styles/ รูปแบบการตอบ
~/.claude/ของเราคนเดียว ทุกโปรเจกต์
~/.claude/ ├── CLAUDE.md กติกาส่วนตัวทุกโปรเจกต์ ├── settings.json ค่าตั้งต้นของเรา ├── rules/ · skills/ ├── agents/ · workflows/ └── projects/<project>/memory/ ├── MEMORY.md Claude เขียนเอง — index └── debugging.md โน้ตแยกหัวข้อ
- ฝั่งซ้าย commit ได้ · settings.local.json ใส่ .gitignore
- ฝั่งขวาเป็น machine-local — ไม่ sync ข้ามเครื่อง
ไฟล์ที่ 1 · CLAUDE.md
คู่มือประจำโปรเจกต์ — มีได้ 4 ระดับ ต่อกันไม่ทับกัน
| ระดับ | ที่อยู่ | ใช้กับ | แชร์กับใคร |
|---|---|---|---|
| Managed policy | ตำแหน่งที่ IT กำหนดต่อ OS | ทั้งองค์กร | ทุกคนในองค์กร |
| User | ~/.claude/CLAUDE.md | ทุกโปรเจกต์ของเรา | เราคนเดียว |
| Project | ./CLAUDE.md หรือ ./.claude/CLAUDE.md | โปรเจกต์นี้ | ทีม (ผ่าน git) |
| Local | ./CLAUDE.local.md | โปรเจกต์นี้ เฉพาะเครื่องเรา | เราคนเดียว (ใส่ .gitignore) |
ลำดับโหลดกว้าง → แคบ
- user มาก่อน project · ไฟล์ที่ใกล้จุดที่เรารันที่สุดถูกอ่านทีหลัง
ไม่ทับกันต่อกันทั้งหมด
- ทุกไฟล์ที่เจอถูกนำมาต่อกันเข้า context ไม่ใช่เขียนทับ
ใน subfolderโหลดเมื่อเข้าไปทำงาน
- ไม่ได้โหลดตอนเปิด — เข้ามาเมื่อ Claude อ่านไฟล์ในโฟลเดอร์นั้น
อยากรู้ว่าไฟล์ไหนโหลดจริงในเซสชันนี้ — สั่ง /context แล้วดูหัวข้อ Memory files
ไฟล์ที่ 1 · ต่อ
ใส่อะไร ไม่ใส่อะไร — และทำไมต้องคุมความยาว
ควรอยู่สิ่งที่ต้องรู้ทุก session
- ภารกิจและขอบเขตของระบบ · แผนผังโปรเจกต์แบบย่อ
- แหล่งข้อมูลที่ถือเป็นของจริง
- คำสั่ง build · test · lint ที่ใช้ทุกครั้ง
- กฎที่ต้องถือทุกงาน + เกณฑ์ว่างานเสร็จ
ไม่ควรอยู่ย้ายไปที่อื่น
- SOP หลายสิบขั้นตอน → Skill
- เอกสาร API ยาว ๆ → ไฟล์อ้างอิง
- สถานะงาน · task list · log · ผลทดสอบ
- password · API key
- กฎที่ซ้ำกับ hook/permission แล้ว
ขนาดเป้าหมาย < 200 บรรทัด
- ยาวกว่านั้นกิน context และทำให้ทำตามได้ไม่สม่ำเสมอ
@importลึกได้ 4 ชั้น
- ไฟล์ที่ import โหลดตั้งแต่เปิด session — จัดระเบียบได้ แต่ไม่ได้ประหยัด context
กฎขัดกันClaude อาจเลือกเอง
- ต้องไล่เก็บกฎเก่าเป็นระยะ ไม่ใช่เขียนเพิ่มอย่างเดียว
ไฟล์ที่ 2 · .claude/rules/
กฎแยกหัวข้อ — และกฎที่โผล่มาเฉพาะตอนแตะไฟล์ที่เกี่ยว
.claude/rules/ ├── security.md ├── testing.md ├── api-design.md └── frontend/react.md — ตัวอย่างกฎที่จำกัด path — --- paths: - "src/api/**/*.ts" --- # API Rules - ตรวจ input ทุก endpoint - ใช้รูปแบบ error response มาตรฐาน - อัปเดต OpenAPI docs
- 1ไม่มี paths: = โหลดทุก session
ระดับเดียวกับ .claude/CLAUDE.md — แตกไฟล์แล้วแต่ยังกิน context เท่าเดิม
- 2มี paths: = โหลดเมื่อแตะไฟล์ที่ตรง
Claude อ่านไฟล์ใน src/api/ เมื่อไหร่ กฎถึงเข้ามา — ลด noise ลดกฎชนกัน
- 3ใส่ได้หลาย pattern
**/*.ts · src/**/* · src/**/*.{ts,tsx} — ค้นแบบ glob
- 4~/.claude/rules/ = กฎส่วนตัว
ใช้ได้ทุกโปรเจกต์ในเครื่อง โหลดก่อน project rules
เส้นแบ่งที่ใช้ตัดสินใจ: ทุกงานต้องรู้ → CLAUDE.md · เฉพาะบางโฟลเดอร์/ชนิดไฟล์ → rules/ · เฉพาะตอนรันกระบวนการหนึ่ง → Skill
ไฟล์ที่ 3 · .claude/skills/
SOP ที่โหลดเฉพาะตอนใช้ — ของถูกที่สุดใน harness
.claude/skills/weekly-report/ ├── SKILL.md ตัวหลัก ├── references/ rubric · นิยาม KPI ├── templates/ โครงรายงาน └── scripts/ ตัวตรวจอัตโนมัติ --- name: weekly-report description: สร้างรายงานยอดขาย รายสัปดาห์ตามเทมเพลตบริษัท disable-model-invocation: true --- 1. อ่านข้อมูลยอดขายสัปดาห์นี้ 2. เทียบกับสัปดาห์ก่อน 3. เขียนตามเทมเพลต 4. ตรวจตัวเลขก่อนส่ง
- 1Progressive disclosure — หัวใจของเรื่อง
ปกติ Claude เห็นแค่ name + description · เนื้อในโหลดเมื่อถูกเรียกหรือเกี่ยวข้องจริง → SOP ยาว ๆ แทบไม่กิน context จนกว่าจะใช้
- 2ขนาดที่เอกสารแนะนำ: ไม่เกิน 500 บรรทัด
ยาวกว่านั้นผลักรายละเอียดไป references/
- 3งานที่มีผลข้างเคียงต้องล็อก
deploy · commit · ส่งข้อความ · ลบข้อมูล → ใส่ disable-model-invocation: true ให้เรียกได้เฉพาะตอนเราสั่งเอง
- 4Commands ถูกรวมเข้ากับ Skills แล้ว
.claude/commands/deploy.md กับ .claude/skills/deploy/SKILL.md ต่างก็สร้าง /deploy · ของเดิมยังใช้ได้ แต่งานใหม่ให้เขียนเป็น Skill
ไฟล์ที่ 4 · .claude/agents/
ผู้ช่วยเฉพาะทาง — มีโต๊ะทำงานของตัวเอง
---
name: architecture-reviewer
description: ตรวจแผนและ ADR
หาความเสี่ยงเชิงสถาปัตยกรรม
tools: [Read, Grep, Glob]
---
คุณคือผู้ตรวจสถาปัตยกรรม
ห้ามแก้ไฟล์ implementation
ส่งกลับเป็น: ประเด็นที่พบ +
ระดับความรุนแรง + หลักฐาน +
ข้อเสนอว่าควรตัดสินใจอย่างไร
- 1กำหนดขอบเขตได้ละเอียด
ใช้โมเดลอะไร · ใช้เครื่องมืออะไรได้ · ห้ามทำอะไร · ต้องส่งผลกลับรูปแบบไหน
- 2ทำงานใน context แยก
อ่านไฟล์เยอะแค่ไหนก็ไม่ทำให้บทสนทนาหลักบวม — ส่งกลับมาแค่ "สรุป"
- 3แต่ไม่ได้แปลว่าใช้ token น้อยลง
ที่ลดคือ context ของห้องหลัก · subagent มี input/output ของตัวเองที่ต้องจ่าย
- 4Skill = วิธีทำงาน · Agent = คนที่ทำงาน
อย่าสร้าง agent หลายตัวที่มีอำนาจตัดสินใจซ้อนกัน — จะไม่มีใครเป็นเจ้าของงานจริง
⭐ สไลด์สำคัญที่สุดของบท
CLAUDE.md บอกว่า "ควรทำ" — Hook ทำให้มัน "ต้องเกิด"
| อยากได้อะไร | กลไกที่ถูก | ประเภท |
|---|---|---|
| บอกให้ตรวจงานก่อนส่ง | CLAUDE.md / Skill | คำแนะนำ |
| ปฏิเสธงานที่ไม่มีหลักฐานจริง ๆ | สคริปต์ตรวจ + Hook | บังคับ |
| บอกว่าห้าม push ขึ้น main | CLAUDE.md | คำแนะนำ |
| บล็อกการ push จริง ๆ | PreToolUse hook / permission deny | บังคับ |
| บอกว่าห้ามอ่านไฟล์ลับ | CLAUDE.md | คำแนะนำ |
| กันไม่ให้อ่านจริง ๆ | permissions.deny ใน settings.json | บังคับ |
settings.jsonตัวอย่างกันอ่านไฟล์ลับ
{
"permissions": {
"deny": [
"Read(./secrets/**)",
"Read(./.env)"
]
}
}
- ลำดับ: managed → CLI → local → project → user
- ประเมิน deny ก่อน ask ก่อน allow
HOOKSคำสั่งที่รันเองตาม event
- ก่อนใช้ tool · หลังแก้ไฟล์ · ตอนงานเสร็จ · ตอนเริ่ม session
- ใช้กับสิ่งที่ต้องเกิดทุกครั้งไม่มีข้อยกเว้น: รัน test หลังแก้โค้ด · เช็คว่ามีข้อมูลลับหลุดไหม · บล็อกการแก้ไฟล์สำคัญ
- เป็น shell command → ผลลัพธ์แน่นอน ไม่ขึ้นกับว่าโมเดลตีความยังไง
เอกสารทางการพูดตรง ๆ ว่า settings ถูก "บังคับใช้โดยตัวโปรแกรม ไม่ว่า Claude จะตัดสินใจอย่างไร" ส่วน CLAUDE.md เป็น "คำแนะนำเชิงพฤติกรรม ไม่ใช่ชั้นบังคับ" — เขียนคำว่า "ห้าม" ไว้เฉย ๆ จึงไม่ใช่การป้องกัน
ส่วนขยาย
ต่อโลกภายนอก · งานล็อตใหญ่ · และการแพ็กไปใช้ซ้ำ
.mcp.jsonต่อระบบภายนอก
- GitHub · Slack · Database · CRM · API ภายในบริษัท
- ระดับโปรเจกต์ commit แชร์ทีมได้ — Claude ขออนุมัติก่อนเชื่อม
- ห้าม hardcode token ลงไฟล์
workflows/คุม agent จำนวนมาก
- สคริปต์ที่กำหนดลูปและลำดับเอง ไม่ปล่อยให้โมเดลตัดสินทุกจังหวะ
- เหมาะกับ audit หลายร้อยไฟล์ · migration · review ทุกไฟล์ใน PR
- ใช้ token มากกว่าปกติ — ใช้เฉพาะงานที่คุ้ม
Pluginแพ็กไปใช้ข้ามโปรเจกต์
- รวม skills · agents · hooks · MCP เป็นชุดเดียว มีเวอร์ชัน
- เหมาะตอนของนิ่งแล้วและต้องใช้หลายที่
- ไม่ใช่จุดเริ่มต้น — แพ็กเร็วเกินไปจะเสียเวลาไปกับ versioning
ภาพจำ: MCP ให้ "มือและช่องทางเข้าถึงข้อมูล" · Skill ให้ "วิธีใช้มือนั้นให้ถูก" · settings ให้ "ใช้ได้แค่ไหน" · Agent บอก "ใครมีสิทธิ์ใช้" · Hook บอก "ก่อน/หลังใช้ต้องตรวจอะไร"
ส่วนที่ Claude เขียนเอง
Auto memory — สมุดจดของ Claude ไม่ใช่กฎหมาย
| CLAUDE.md | Auto memory | |
|---|---|---|
| ใครเขียน | เรา | Claude |
| เก็บอะไร | กติกาและบริบทที่เราตั้งใจกำหนด | สิ่งที่เรียนรู้จากการทำงาน — คำสั่ง build ที่เพิ่งค้นเจอ · วิธีแก้บั๊กที่เคยได้ผล · สิ่งที่เราแก้ซ้ำ ๆ |
| ขอบเขต | project · user · องค์กร | ต่อ repository (แชร์ข้าม worktree) |
| โหลดเข้า context | ทั้งไฟล์ | 200 บรรทัดแรก หรือ 25KB ของ MEMORY.md |
| ที่อยู่ | ในโปรเจกต์ / ~/.claude/ | ~/.claude/projects/<project>/memory/ |
ใช้ได้ดีความรู้ที่สะสมเอง
- วิธีแก้ปัญหาที่เคยได้ผล · จุดที่ต้องระวังใน codebase · preference ที่เราแก้ซ้ำ
- MEMORY.md เป็นสารบัญ · ไฟล์หัวข้อย่อยโหลดเมื่อต้องใช้
ห้ามใช้แทนของที่ต้องเถียงกันไม่ได้
- PRD · การตัดสินใจที่อนุมัติแล้ว · สถานะงาน · policy ความปลอดภัย
- เป็น machine-local ไม่ sync ข้ามเครื่อง และ Claude แก้เองได้
หลักที่ใช้ได้จริง: Memory "เสนอให้แก้กฎ" ได้ แต่ไม่ควร "กลายเป็นกฎ" เอง — ของสำคัญต้องย้ายขึ้นไฟล์ที่ทีมคุม
⭐ ตารางแปลภาษา AI
AI พูดแบบนี้ = กำลังจะทำอะไรกับ harness ของเรา
| AI พูดว่า | แปลว่า | เราควรทำ |
|---|---|---|
| "I've added this to CLAUDE.md" | กติกาถาวรเข้าไปแล้ว ทุก session จะเห็น | ✅ เช็คว่าไฟล์ยังไม่เกิน ~200 บรรทัด และไม่ขัดกับกฎเดิม |
| "Let me create a skill for this" | กำลังทำ SOP ไว้ใช้ซ้ำ | ✅ ถ้างานมีผลข้างเคียง สั่งให้ใส่ disable-model-invocation: true |
| "I'll delegate this to a subagent" | เปิด context แยกไปทำงานหนัก ๆ | 🟡 คาดหวังผลกลับมาเป็น "สรุป" ไม่ใช่รายละเอียดทั้งหมด |
| "This is blocked by a permission rule" | สิทธิ์ที่เราตั้งไว้ทำงานถูกต้อง | ⚠️ อย่าปลดกฎเพื่อให้ผ่าน — ถามก่อนว่าทำไมต้องแตะตรงนั้น |
| "I'll add a PreToolUse hook" | จะบังคับให้ตรวจก่อนใช้เครื่องมือทุกครั้ง | ✅ ดี — แต่ขอดูสคริปต์ว่าตรวจอะไรจริง ๆ |
| "Saved 2 memories" | Claude จดโน้ตของตัวเองเพิ่ม | 🟡 เปิด /memory ดูเป็นระยะว่าไม่มีอะไรผิดหรือล้าสมัย |
| "I'll connect via MCP" | จะต่อกับระบบภายนอกจริง | ⚠️ เช็คว่าเห็นข้อมูลอะไรบ้าง และ token เก็บที่ไหน |
แผ่นสรุปที่ใช้ได้จริง
กฎข้อนี้ควรอยู่ตรงไหน — เปิดตารางนี้แผ่นเดียวจบ
ROUTINGต้องการอะไร → ใช้อะไร
| ทุก session ต้องรู้ | CLAUDE.md |
| เฉพาะบาง path/ชนิดไฟล์ | rules/ + paths: |
| ขั้นตอนที่ใช้ซ้ำ | Skill |
| ผู้ปฏิบัติงานเฉพาะทาง | Agent |
| งาน fan-out ขนาดใหญ่ | Workflow |
| ต้องเกิดทุกครั้ง | Hook |
| สิทธิ์และการตั้งค่า | settings.json |
| ต่อระบบภายนอก | .mcp.json |
| สถานะงานปัจจุบัน | ไฟล์ state ในโปรเจกต์ |
| สิ่งที่เพิ่งเรียนรู้ | Auto memory |
| ใช้ซ้ำหลายโปรเจกต์ | Plugin |
คู่ที่มักสับสนต่างกันตรงไหน
| CLAUDE.md vs settings.json | แนะนำ vs บังคับ |
| Skill vs Agent | วิธีทำงาน vs คนที่ทำงาน |
| Rules vs Skills | โหลดตาม path/ทุก session vs โหลดเมื่อเรียกใช้ |
| Memory vs CLAUDE.md | Claude เขียน vs เราเขียน |
| MCP vs Skill | มือ vs วิธีใช้มือ |
| settings.json vs .local.json | ทีม (commit) vs เครื่องเรา (gitignore) |
QUICK CHECK
เช็คความเข้าใจก่อนปิดบท
ตอบในใจก่อน แล้วค่อยกดดูเฉลย
1 · เขียนใน CLAUDE.md ว่า "ห้าม push ขึ้น main" = ปลอดภัยแล้ว จริงไหม?
ไม่จริง — CLAUDE.md เป็นคำแนะนำใน context ไม่ใช่ชั้นบังคับ · ถ้าต้องกันจริงต้องใช้ hook หรือ permission deny ที่ตัวโปรแกรมบังคับให้
2 · ย้าย SOP 300 บรรทัดจาก CLAUDE.md ไปเป็น Skill แล้วประหยัด context จริงไหม?
จริง — เนื้อ skill โหลดเมื่อถูกใช้เท่านั้น ต่างจาก CLAUDE.md และไฟล์ที่ @import ซึ่งโหลดตั้งแต่เปิด session ทุกครั้ง
3 · ใช้ subagent แล้ว token รวมลดลงเสมอ ใช่ไหม?
ไม่ใช่ — ที่ลดคือ context ของบทสนทนาหลัก · subagent มี input/output ของตัวเองที่ต้องจ่ายเหมือนกัน · ประโยชน์คือห้องหลักไม่บวมและงานแยกกันสะอาด
4 · เพิ่งเริ่มโปรเจกต์ใหม่ ควรตั้ง agent 12 ตัว skill 20 ชุดเลยไหม?
ไม่ควร — เอกสารทางการเองระบุว่าผู้ใช้ส่วนใหญ่แตะแค่ CLAUDE.md กับ settings.json · ที่เหลือเพิ่มเมื่อมีปัญหาซ้ำจริง
สาระสำคัญ
สรุป SE9 — ลำดับการโตของ Harness
CLAUDE.md + settings.json
Rules ตาม path · Skills · Agents · Hooks
Plugin ไปใช้ข้ามโปรเจกต์
KEY TAKEAWAY
อย่าทำให้ Claude "จำทุกอย่าง" — ทำให้ Claude "รู้ว่าจะไปอ่านอะไร ใช้อะไร และใครมีอำนาจตัดสินใจ" ในแต่ละจังหวะของงาน · และจำเส้นแบ่งเดียวที่สำคัญที่สุด: CLAUDE.md บอกว่า "ควรทำ" · Hook กับ Permission ทำให้มัน "ต้องเกิด"