Chapter 4 / 6 · April 24, 2026

Vibe Coding และ Extension

ทำงานสนุกขึ้นด้วย Agent, Skill, MCP และ Plugin ที่เพิ่มความสามารถ

บทที่ 4 | การ Vibe Coding กลุ่มเป้าหมาย: ทุกระดับ — มือใหม่ที่ต้องการเริ่มต้น และมือเก่าที่ต้องการเพิ่มประสิทธิภาพ

Vibe Coding คืออะไร และทำไมถึงเปลี่ยนวงการ

Vibe Coding คือแนวคิดที่ Andrej Karpathy (อดีตหัวหน้า AI ของ Tesla และ OpenAI) บัญญัติขึ้นในปี 2025 หมายถึงการเขียนโปรแกรมโดยใช้ภาษาธรรมชาติบอก AI แล้วปล่อยให้ AI สร้างโค้ดให้ ผู้ใช้มีหน้าที่กำหนดทิศทาง ทดสอบ และบอก feedback ไม่ต้องเขียนโค้ดทุกบรรทัดด้วยมือ

ความแตกต่างระหว่าง Developer แบบเดิม vs Vibe Coder

Developer แบบเดิม	Vibe Coder ด้วย Claude
เขียนทุก function ด้วยตัวเอง	บอก requirement แล้วให้ Claude เขียน
ต้องจำ Syntax ทุกภาษา	ต้องรู้ว่าต้องการอะไร ไม่ต้องจำ Syntax
Google หา solution ทีละอัน	บอกปัญหา Claude เสนอ solution พร้อม tradeoffs
Debug ด้วยตัวเองทั้งหมด	บอก Error log ให้ Claude วิเคราะห์และแก้
ต้องรู้ library API ทั้งหมด	บอกว่าต้องการทำอะไร Claude เลือก library ที่เหมาะ
ประมาณ 50-100 บรรทัด/ชั่วโมง	ประมาณ 500-2000 บรรทัด/ชั่วโมง (ขึ้นกับงาน)

Vibe Coding ไม่ได้แปลว่า “ไม่ต้องรู้อะไรเลย”

ความเข้าใจผิดที่พบบ่อยที่สุด คือคิดว่า Vibe Coding แปลว่าไม่ต้องรู้โปรแกรมมิ่งเลย ความจริงคือ:

⚠️ สิ่งที่ยังต้องรู้แม้จะใช้ Vibe Coding
รู้ว่าต้องการ Output แบบไหน: “API ที่ return JSON” ดีกว่า “ทำให้มันทำงาน”
รู้เพียงพอที่จะ Review: อ่าน logic หลักได้ รู้ว่าโค้ดนี้ทำอะไร
รู้จัก Red Flag: เห็น console.log ที่ไม่ควรอยู่, เห็น hardcoded password
รู้เมื่อไหร่ควรหยุด: ถ้า Claude วน loop 5 รอบแล้วยังแก้ไม่ได้ = ต้องเปลี่ยนวิธี
รู้ขอบเขต: งานที่ต้องการ security สูง ต้อง review ละเอียดกว่าปกติ

เหมาะกับงานประเภทไหนบ้าง?

เหมาะมาก ✅	เหมาะปานกลาง ⚠️	ระวังเป็นพิเศษ 🔴
Prototype & MVP	Core business logic	Authentication / Authorization
Internal tools	API integration	Payment / Financial system
Script อัตโนมัติ	Performance-critical code	Cryptography
Data processing	Multi-threaded code	Compliance / HIPAA / GDPR
CRUD features	Database schema design	Mission-critical infrastructure
Boilerplate code	Algorithm ซับซ้อน	Smart contract / Blockchain

Mindset ที่ถูกต้องสำหรับ Vibe Coding

คิดว่าตัวเองเป็น Product Manager ไม่ใช่ Programmer

บทบาทของคุณเปลี่ยนจาก “คนเขียนโค้ด” เป็น “คนกำหนดทิศทาง” คุณต้องรู้ว่าต้องการอะไร กำหนด requirement ให้ชัด และ review ผลลัพธ์ ส่วน Claude รับหน้าที่ implementation

💡 Analogy ที่ช่วยให้เข้าใจ
คุณ = สถาปนิก: กำหนดว่าบ้านต้องมีกี่ห้อง อยู่ตรงไหน วัสดุอะไร
Claude = ช่างก่อสร้าง: รู้วิธีสร้าง รู้เทคนิค ทำได้เร็ว
ถ้าสถาปนิกบอกคลุมเครือ ช่างก็สร้างผิดแบบ ไม่ใช่ความผิดของช่าง

Law of Vibe Coding

Law #1: ชัดเจน > ฉลาด	Prompt ที่ชัดเจนและธรรมดาให้ผลดีกว่า Prompt ที่ฟังดูฉลาดแต่คลุมเครือ
Law #2: เล็ก > ใหญ่	แบ่งงานเป็นชิ้นเล็กๆ ดีกว่าส่งทุกอย่างครั้งเดียว
Law #3: Test ทุกอย่าง	อย่าเชื่อว่า Claude ถูกเสมอ ทดสอบทุกอย่างก่อนใช้งานจริง
Law #4: Context คือทอง	Claude ทำงานดีขึ้นมากเมื่อได้รับ context ที่ดี
Law #5: Fail Fast	ถ้า Claude แก้ไม่ได้ใน 3 รอบ เปลี่ยนวิธีหรือแยกปัญหาออก
Law #6: Commit บ่อย	Commit ทุกครั้งที่ได้โค้ดที่ทำงานได้ เผื่อ Claude พังทุกอย่างในรอบถัดไป

การเขียน Prompt สำหรับ Vibe Coding

ทักษะสำคัญที่สุดของ Vibe Coder ไม่ใช่การเขียนโค้ด แต่คือการเขียน Prompt ที่ดี ต่อไปนี้คือ Framework ที่ใช้ได้จริง

Framework CLEAR สำหรับ Prompt ที่ดี

C — Context	บอกว่าโปรเจคคืออะไร tech stack อะไร อยู่ในส่วนไหนของระบบ
L — Language/Library	ระบุภาษา, framework, version ที่ใช้ให้ชัดเจน
E — Expected Output	บอกว่าต้องการอะไร รูปแบบไหน ยาวแค่ไหน
A — Assumptions	บอก assumption ที่ Claude ควรมี เช่น “assume user ผ่าน auth แล้ว”
R — Restrictions	ข้อห้ามและข้อจำกัด เช่น “ห้ามใช้ any”, “ต้องรองรับ Node 18”

ตัวอย่าง: Prompt ไม่ดี vs ดี เปรียบเทียบจริง

❌ ไม่ดี
ทำ login form ให้ผม

✅ ดี
สร้าง Login Form ด้วย React + TypeScript
ใช้ React Hook Form สำหรับ validation
Field: email (format validation), password (min 8 chars)
มี loading state ระหว่าง submit
Error: แสดงใต้ field ที่ผิด ไม่ใช่ alert
เมื่อ success → redirect ไป /dashboard
ใช้ Tailwind CSS, รองรับ dark mode

ตัวอย่างที่ 2: แก้บัก

❌ ไม่ดี ทำไม code ไม่ทำงาน (แปะโค้ด 200 บรรทัด)	✅ ดี ใน @src/api/user.ts function getUserById เมื่อ userId เป็น null ได้รับ error: “Cannot read properties of null” Expected: return null ถ้า user ไม่มี ใช้ Prisma + TypeScript strict mode

ตัวอย่างที่ 3: สร้าง Feature ใหม่

❌ ไม่ดี
เพิ่ม search ให้ระบบ

✅ ดี
เพิ่ม Search ใน Product List Page
Tech: Next.js 14, Prisma, PostgreSQL
Requirements:
- Search by: ชื่อสินค้า, ยี่ห้อ, หมวดหมู่
- Debounce 300ms (ไม่ hit API ทุก keystroke)
- แสดง loading skeleton ระหว่าง search
- URL เปลี่ยนตาม search term (?q=xxx)
- รองรับ pagination ร่วมกับ search

Prompt Patterns ที่ใช้บ่อยใน Vibe Coding

	Pattern 1: “Act as” — กำหนด Persona ให้ Claude

บอก Claude ให้เล่นบทบาทเฉพาะทาง จะทำให้คำตอบมีมุมมองและมาตรฐานที่ต้องการ:

> Act as Senior Backend Engineer ที่เชี่ยวชาญ Node.js
  และ PostgreSQL performance optimization
  Review @src/db/queries.ts แล้วระบุ N+1 queries
  ทั้งหมดและเสนอวิธีแก้ด้วย Prisma
 
> Act as Security Auditor
  ตรวจสอบ @src/api/auth.ts หาช่องโหว่ทั้งหมด
  จัดเรียงตาม severity (Critical/High/Medium/Low)
 
> Act as UX Developer ที่ดูแล Accessibility
  Review @src/components/Form.tsx
  ให้ผ่าน WCAG 2.1 AA standard

	Pattern 2: Step-by-step — แบ่งงานเป็นขั้นตอน

สำหรับงานซับซ้อน ให้ระบุขั้นตอนที่ต้องการ แทนที่จะบอกผลลัพธ์อย่างเดียว:

> ทำทีละขั้นตอน รอให้ผม approve ก่อนไปขั้นต่อไป:
 
  ขั้นที่ 1: วิเคราะห์ @prisma/schema.prisma
  แล้ว list ทุก relationship ที่มี
 
  ขั้นที่ 2: ระบุ query ที่ expensive ที่สุด 3 อัน
  จาก @src/server/actions/*.ts
 
  ขั้นที่ 3: เสนอ index strategy สำหรับแต่ละ query
 
  ขั้นที่ 4: สร้าง Prisma migration พร้อม rollback plan

	Pattern 3: Constraint-first — บอกข้อจำกัดก่อน

บอกสิ่งที่ต้องการหลีกเลี่ยงก่อนบอกสิ่งที่ต้องการ Claude จะไม่ต้องแก้ซ้ำ:

> ข้อจำกัด (อ่านก่อนทำ):
  - ห้าม install dependency ใหม่
  - ห้ามแก้ไฟล์นอก src/features/payment/
  - ต้องรองรับ Node 18 (ห้ามใช้ API ที่ใหม่กว่า)
  - error messages ต้องเป็นภาษาไทย
 
  งาน: สร้าง retry mechanism สำหรับ payment API
  ถ้า API fail ให้ retry 3 ครั้ง exponential backoff
  log ทุก retry attempt

	Pattern 4: Example-driven — ให้ตัวอย่างที่ต้องการ

แทนที่จะอธิบายด้วยคำ ให้แสดงตัวอย่าง Input/Output ที่ต้องการ:

> สร้าง function formatCurrency ตามตัวอย่างนี้:
 
  Input → Expected Output:
  1000      → "1,000 บาท"
  1500.50   → "1,500.50 บาท"
  0         → "0 บาท"
  -500      → "-500 บาท"
  1000000   → "1,000,000 บาท"
 
  ใช้ TypeScript, handle null/undefined ด้วย
  เขียน unit test ครอบคลุมทุก case ด้วย Vitest

	Pattern 5: Iterative Refinement — ปรับแบบ Loop

ไม่ต้องได้ผลลัพธ์ perfect ในครั้งแรก ใช้วิธี iterate:

# รอบที่ 1: สร้าง Draft
> สร้าง Product Card component คร่าวๆ ก่อน
  ยังไม่ต้องสวย แค่โครงสร้างถูกต้อง
 
# รอบที่ 2: เพิ่มรายละเอียด
> ดี ตอนนี้เพิ่ม:
  - Hover effect
  - Loading skeleton state
  - Error state ถ้า image โหลดไม่ได้
 
# รอบที่ 3: Responsive
> ทำให้ responsive:
  - Mobile: แสดงเป็น list (1 column)
  - Tablet: grid 2 column
  - Desktop: grid 3 column
 
# รอบที่ 4: Accessibility
> เพิ่ม aria-label, role, keyboard navigation

Vibe Coding Workflow ที่ใช้ได้จริง

Workflow นี้ทดสอบจากการทำงานจริงหลายร้อยชั่วโมง ออกแบบมาให้ผลลัพธ์ดีที่สุดโดยไม่เสี่ยงโค้ดพัง

Phase 1: Setup — ก่อนเริ่มทุกครั้ง (5 นาที)

1	สร้าง Branch ใหม่เสมอ อย่าทำงานบน main โดยตรง สร้าง branch ทุกครั้งแม้งานเล็ก

git checkout -b vibe/feature-name
# ตัวอย่าง: git checkout -b vibe/user-profile-page

2	อ่าน CLAUDE.md ก่อนเริ่ม ให้ Claude อ่าน context ของโปรเจคก่อนเสมอ

> อ่าน @CLAUDE.md แล้วบอกผมว่าเราทำอะไรอยู่
  และโปรเจคนี้มีกฎอะไรที่ต้องระวัง

3	กำหนด Scope ชัดเจน บอก Claude ว่าจะทำอะไรใน Session นี้ อะไรอยู่นอก scope

> Session นี้เราจะทำ User Profile Page
  Scope: แสดงข้อมูล user, แก้ไข profile, upload avatar
  Out of scope: email change, password change (ทำ session อื่น)
  เริ่มจาก data layer ก่อน แล้วค่อย UI

Phase 2: Build — วงจรหลักของการทำงาน

วงจรนี้ทำซ้ำสำหรับทุก feature จนกว่าจะเสร็จ:

A	Describe — อธิบายสิ่งที่ต้องการ ใช้ CLEAR framework เขียน Prompt ที่ชัดเจน บอก context, expected output, constraints

B	Claude Builds — รอให้ Claude สร้าง อย่าขัด ปล่อยให้ Claude ทำงานจบก่อน แล้วค่อย review ทั้งหมด

C	Check — ตรวจสอบโค้ด อ่าน logic หลัก ดูว่า handle edge case ไหม มี security issue ไหม ก่อน run

D	Run — รันและทดสอบ รัน test, รัน dev server, คลิกทดสอบ ดู console ว่ามี error ไหม

E	Feedback — บอก Claude ผล ถ้าทำงานได้ commit แล้วไปต่อ ถ้ามี issue บอก Claude พร้อม error log ที่ชัดเจน

F	Commit — บันทึกทุก milestone Commit เมื่อโค้ดทำงานได้แต่ละ feature ย่อย ไม่ต้องรอให้ทุกอย่างเสร็จ

# ตัวอย่าง session จริง
 
# A: Describe
> สร้าง Prisma query สำหรับดึง User Profile
  include: posts (5 ล่าสุด), followers count, following count
  exclude: password, resetToken
  type-safe ด้วย TypeScript
 
# D: Run - รัน query test
npx ts-node -e "const {getUserProfile} = require('./src/lib/user'); getUserProfile(1).then(console.log)"
 
# E: Feedback - ถ้ามี error
> ได้ error นี้:
  PrismaClientKnownRequestError: Invalid `prisma.user.findUnique()`
  The column `User.followersCount` does not exist
  Schema ของเราไม่มี column นี้ ต้องนับจาก relation แทน
 
# F: Commit เมื่อผ่าน
git add -A && git commit -m "feat(user): add getUserProfile query with relations"

Phase 3: Review — ก่อน Merge ทุกครั้ง

ขั้นตอนนี้สำคัญมาก อย่าข้ามแม้จะรีบ ใช้ Claude ช่วย Review โค้ดของ Claude เอง:

# Self-review ด้วย Claude
git diff main...HEAD | claude -p \
"รีวิวโค้ดนี้แบบ Senior Developer
 ตรวจสอบ:
 1. Security vulnerabilities
 2. Error handling ครบถ้วนไหม
 3. Edge cases ที่อาจพลาด
 4. Performance issues
 5. TypeScript any ที่ไม่จำเป็น
 ให้ output เป็น list priority สูง-ต่ำ"
 
# Security check เฉพาะทาง
git diff main...HEAD | claude -p \
"ตรวจสอบเฉพาะ security:
 - SQL Injection
 - XSS
 - IDOR (Insecure Direct Object Reference)
 - Missing authorization checks
 - Sensitive data exposure"

ตัวอย่างการ Vibe Coding จริง — ตั้งแต่ต้นจนจบ

ตัวอย่างทั้งหมดในส่วนนี้เป็น prompt และ workflow จริงที่ใช้ได้กับโปรเจค Next.js + TypeScript + Prisma ปรับ tech stack ตามต้องการได้

	ตัวอย่าง 1: สร้าง REST API Endpoint ใหม่

สถานการณ์: ต้องการ API สำหรับให้ User ดู Order History พร้อม pagination

# Prompt ที่ 1: วิเคราะห์ก่อนสร้าง
> ดู @prisma/schema.prisma และ @src/types/
  แล้วออกแบบ API endpoint สำหรับ GET /api/orders
  Requirements:
  - Pagination: ?page=1&limit=10
  - Filter: ?status=pending|completed|cancelled
  - Sort: ?sort=date_desc|date_asc|amount_desc
  - Return: orders array + totalCount + totalPages
  บอกผมว่า schema ขาด field อะไรไหม
  ก่อน implement จริง
 
# (Claude วิเคราะห์แล้วบอกว่า schema ขาด index)
 
# Prompt ที่ 2: สร้าง migration ก่อน
> สร้าง Prisma migration เพิ่ม index ที่แนะนำ
  ตั้งชื่อ migration: add_order_query_indexes
 
# Prompt ที่ 3: สร้าง service layer
> สร้าง getOrderHistory function ใน src/server/services/order.ts
  รับ: userId, page, limit, status?, sort?
  Return type: { orders: OrderWithItems[], totalCount: number }
  ใช้ Prisma transaction สำหรับ count + fetch
  Handle: invalid userId → throw NotFoundError
 
# Prompt ที่ 4: สร้าง API route
> สร้าง src/app/api/orders/route.ts
  - GET handler เรียก getOrderHistory
  - Validate query params ด้วย zod
  - Auth check ด้วย getServerSession
  - Error handling: 400, 401, 404, 500
  - Rate limiting: 60 requests/minute
 
# Prompt ที่ 5: เขียน test
> เขียน unit tests สำหรับ getOrderHistory
  ครอบคลุม cases:
  - Happy path: ได้ orders ถูกต้อง
  - Empty result: user ไม่มี orders
  - Invalid userId: throw error
  - Pagination: page 2 ได้ข้อมูลถูก
  ใช้ Vitest + Prisma mock

	ตัวอย่าง 2: แก้บัก Performance

สถานการณ์: หน้า Dashboard โหลดช้า 8 วินาที ต้องแก้ให้เหลือ < 2 วินาที

# Prompt ที่ 1: วิเคราะห์ปัญหา
> หน้า Dashboard ใน @src/app/dashboard/page.tsx
  โหลดช้ามาก ต้องการ profiling
  ช่วย:
  1. เพิ่ม console.time/timeEnd เพื่อวัดแต่ละ section
  2. ระบุจุดที่น่าจะช้าที่สุดจาก code
  3. แนะนำวิธี profiling ที่ดีกว่า
 
# (รันแล้วได้ข้อมูล: DB query ใช้เวลา 7 วินาที)
 
# Prompt ที่ 2: วิเคราะห์ query
> นี่คือ query ที่ช้า (7 วินาที):
  [แปะ query code]
 
  ปัญหาที่เห็นคือ:
  - ดึง users ทุกคน แล้วค่อย filter ใน JS
  - ไม่มี index บน created_at
  - ไม่ได้ใช้ pagination
 
  ช่วย rewrite ให้ดีขึ้น:
  - Filter ใน DB ไม่ใช่ JS
  - เพิ่ม index ที่จำเป็น
  - เพิ่ม pagination
 
# Prompt ที่ 3: ทำ Parallel fetching
> Dashboard ดึงข้อมูล 4 อย่างแยกกัน:
  totalRevenue, newUsers, activeOrders, topProducts
 
  ตอนนี้รันทีละอัน (sequential)
  Refactor ให้รัน parallel ด้วย Promise.all
  และ cache ผลลัพธ์ด้วย unstable_cache (Next.js)
  TTL: 5 นาที

	ตัวอย่าง 3: Refactor โค้ดเก่า

สถานการณ์: มี function เก่าที่เขียนไว้แย่มาก ต้องการ refactor โดยไม่ให้ behavior เปลี่ยน

# Prompt ที่ 1: วิเคราะห์ก่อน
> วิเคราะห์ @src/utils/pricing.ts
  บอกผมว่า:
  1. function แต่ละตัวทำอะไร
  2. มี code smell อะไรบ้าง
  3. มี bug ที่ซ่อนอยู่ไหม
  อย่าแก้ก่อน แค่วิเคราะห์
 
# Prompt ที่ 2: เขียน test ก่อน refactor
> เขียน comprehensive tests สำหรับ
  ทุก function ใน @src/utils/pricing.ts
  ก่อน refactor เพื่อให้มั่นใจว่า behavior ไม่เปลี่ยน
  ครอบคลุม edge cases ที่เห็นจากการวิเคราะห์
 
# Prompt ที่ 3: Refactor ทีละ function
> Refactor function calculateDiscount ใน pricing.ts
  Goals:
  - ลบ duplicated code
  - แยก pure functions ออกมา
  - เพิ่ม TypeScript types ที่ขาด
  - อย่าเปลี่ยน behavior (tests ต้องผ่านทั้งหมด)
  ทำทีละ function รอผม approve ก่อนไปต่อ

	ตัวอย่าง 4: สร้างทั้ง Feature ตั้งแต่ต้น (Mini Project)

สถานการณ์: สร้าง Notification System ตั้งแต่ Database schema จนถึง UI

# Session 1: Database Design
> ออกแบบ Notification system สำหรับโปรเจคนี้
  Requirements:
  - Types: order_update, payment_success, promo, system
  - Status: unread/read/archived
  - Delivery: in-app (ก่อน), email (ทีหลัง)
  - Scalability: user บางคนอาจมี 10,000+ notifications
 
  สร้าง:
  1. Prisma schema
  2. Migration
  3. Seed data สำหรับ testing
 
# Session 2: Backend
> สร้าง notification service ครบ:
  - createNotification(userId, type, data)
  - getNotifications(userId, { unreadOnly, limit, cursor })
  - markAsRead(userId, notificationIds[])
  - markAllAsRead(userId)
  - deleteNotification(userId, notificationId)
 
  ใช้ cursor pagination (ไม่ใช่ offset)
  เพิ่ม optimistic update สำหรับ markAsRead
 
# Session 3: API Routes
> สร้าง API routes:
  GET  /api/notifications
  POST /api/notifications/read
  POST /api/notifications/read-all
  DELETE /api/notifications/:id
 
  Auth required บน ทุก route
  Rate limit: 100 req/minute
 
# Session 4: Real-time ด้วย Server-Sent Events
> เพิ่ม real-time notification:
  - GET /api/notifications/stream (SSE endpoint)
  - Client subscribe ด้วย EventSource
  - เมื่อมี notification ใหม่ push ไปทันที
  - Reconnect automatically ถ้า connection หลุด
 
# Session 5: UI
> สร้าง NotificationBell component:
  - Badge แสดงจำนวน unread
  - Dropdown list 10 รายการล่าสุด
  - Mark as read เมื่อคลิก
  - "Mark all as read" button
  - "View all" link ไปหน้า /notifications
  - Animate เมื่อมี notification ใหม่

การแก้บักแบบ Vibe Coding

การ Debug ด้วย Claude มีศิลปะของมัน การให้ข้อมูลที่ถูกต้องและชัดเจนคือกุญแจสำคัญ

โครงสร้าง Bug Report ที่ Claude แก้ได้เร็ว

# Template Bug Report สำหรับ Claude
> Bug Report:
 
  ## Environment
  - OS: macOS 14.3
  - Node: 20.10
  - Browser: Chrome 122 (ถ้า frontend bug)
 
  ## Error Message (copy ทั้งหมด)
  TypeError: Cannot read properties of undefined (reading "map")
    at ProductList (./src/components/ProductList.tsx:45:23)
    at renderWithHooks (...)
 
  ## Steps to Reproduce
  1. Login ด้วย account ปกติ
  2. ไปหน้า /products
  3. กด filter "On Sale"
  4. Error เกิดทันที
 
  ## Expected
  แสดง list สินค้า sale
 
  ## Actual
  หน้าพัง, error ใน console
 
  ## Code ที่น่าจะเกี่ยวข้อง
  @src/components/ProductList.tsx บรรทัด 40-50
 
  ## สิ่งที่ลองแล้ว
  - console.log products ก่อน .map → ได้ undefined
  - filter ปกติ (ไม่กด On Sale) → ทำงานได้

เทคนิค Debug แบบ Systematic ด้วย Claude

วิธีที่ 1: Binary Search Bug

> ปัญหา: checkout flow ทำงานผิด ไม่รู้ว่า step ไหน
 
  ช่วย add logging เพื่อหาว่าปัญหาอยู่ที่ไหน:
  เพิ่ม console.log ที่ beginning ของ:
  - validateCart()
  - calculateTotal()
  - createPaymentIntent()
  - updateInventory()
  - sendConfirmationEmail()
 
  Log format: "✓ [function name] completed: [result]"
  หรือ "✗ [function name] failed: [error]"

วิธีที่ 2: Hypothesis Testing

> Bug: User บางคน login ไม่ได้ บางคนได้
 
  Hypothesis ที่ผมมี:
  H1: Email case-sensitive (john@test.com vs John@test.com)
  H2: Password มี special character บางตัวที่ escape ไม่ถูก
  H3: Session expire เร็วเกินไป
 
  ช่วย:
  1. วิเคราะห์ @src/lib/auth.ts ว่า H1, H2, H3 เป็นไปได้ไหม
  2. เพิ่ม logging เพื่อ test แต่ละ hypothesis
  3. เสนอ fix สำหรับ hypothesis ที่เป็นไปได้มากที่สุด

วิธีที่ 3: Rubber Duck Debugging

> ผมจะอธิบาย logic ที่ผมเข้าใจ คุณช่วยหา flaw:
 
  ความเข้าใจของผม:
  1. User กด "Add to Cart"
  2. Frontend เรียก POST /api/cart
  3. Server บวก quantity ของ product ที่มีอยู่แล้ว
  4. Return cart ใหม่
  5. Frontend update state
 
  Bug: เมื่อ add product เดิม 2 ครั้งเร็วๆ
  quantity เป็น 1 ไม่ใช่ 2
 
  (Claude มักจะหา race condition ได้เร็ว)

เทคนิค Advanced สำหรับ Vibe Coding

เทคนิคที่ 1: Two-Claude Technique

ใช้ Claude สองตัวในงานเดียวกัน ตัวหนึ่งสร้าง อีกตัว review ช่วยหา blind spot:

# Claude ตัวที่ 1: สร้าง implementation
> สร้าง authentication middleware สำหรับ Express
  [implementation...]
 
# Claude ตัวที่ 2 (Session ใหม่): Review
> นี่คือ authentication middleware ที่เพิ่งสร้าง:
  [แปะโค้ดจาก Claude ตัวที่ 1]
 
  รีวิวในฐานะ Security Expert:
  - ช่องโหว่ที่เห็น
  - Attack vectors ที่เป็นไปได้
  - Missing edge cases
  อย่ามองแค่ logic ให้มองจากมุม attacker

เทคนิคที่ 2: Documentation-Driven Development

เขียน Documentation ก่อน แล้วให้ Claude implement ตาม Doc ทำให้ได้โค้ดที่ตรง spec กว่า:

# ขั้นที่ 1: เขียน API Doc ก่อน
> ช่วยเขียน API Documentation สำหรับ
  Payment Webhook endpoint
  ในรูปแบบ OpenAPI 3.0
  ครอบคลุม: request format, response codes,
  error cases, security requirements
 
# ขั้นที่ 2: ให้ Claude implement ตาม Doc
> Implement endpoint ตาม API Doc นี้:
  @docs/api/payment-webhook.yaml
  อย่าเพิ่มหรือลด behavior จาก spec
  ถ้า spec ไม่ชัด ถามก่อนอย่า assume

เทคนิคที่ 3: Test-First Vibe Coding

ให้ Claude เขียน test ก่อน แล้ว implement ทีหลัง ได้โค้ดที่ครอบคลุมกว่ามาก:

# ขั้นที่ 1: เขียน test spec
> เขียน test cases สำหรับ coupon validation:
  - coupon หมดอายุ → error
  - coupon ใช้เกิน limit → error
  - coupon ไม่ match user tier → error
  - ราคาต่ำกว่า minimum → error
  - happy path → return discount amount
  - coupon แบบ % และแบบ fixed amount
 
  ใช้ Vitest, mock Prisma
  ยังไม่ต้อง implement function จริง
 
# ขั้นที่ 2: ให้ tests เป็น spec สำหรับ implementation
> ตอนนี้ implement validateCoupon function
  ให้ pass tests ทั้งหมดใน @src/__tests__/coupon.test.ts
  ห้าม modify tests

เทคนิคที่ 4: Scaffolding + Customization

ให้ Claude สร้าง Boilerplate ก่อน แล้วปรับแต่งทีหลัง เร็วกว่าทำทุกอย่างในครั้งเดียว:

# ขั้นที่ 1: สร้าง Scaffold เร็วๆ
> สร้าง CRUD boilerplate สำหรับ Product entity
  - Service layer (create, read, update, delete, list)
  - API routes
  - TypeScript types
  - Basic tests
  ใช้ pattern เดียวกับ @src/features/user/
 
# ขั้นที่ 2: ปรับแต่ง business logic
> Scaffold ของ Product ได้แล้ว
  ตอนนี้เพิ่ม business rules เฉพาะ:
  - ราคาต้องไม่ต่ำกว่า cost (ดูจาก product.cost)
  - สินค้าใน category "featured" ต้องมีรูปอย่างน้อย 3 รูป
  - เมื่อ stock เหลือ < 10 ส่ง alert ให้ admin

เทคนิคที่ 5: Progressive Enhancement

เริ่มจาก MVP ที่ทำงานได้ แล้ว enhance ทีละ layer ทำให้ได้ feedback เร็วและ risk ต่ำ:

# Layer 1: ทำให้ทำงานได้ก่อน (no frills)
> สร้าง search สำหรับ products
  Version 1: basic SQL LIKE search
  ไม่ต้อง fancy แค่ทำงานได้
 
# Layer 2: เพิ่ม UX
> ตอนนี้เพิ่ม:
  - Debounce 300ms
  - Loading state
  - "No results" empty state
 
# Layer 3: Performance
> Optimize:
  - เพิ่ม full-text search index
  - Cache ผลลัพธ์ที่ search บ่อย
 
# Layer 4: Advanced features
> เพิ่ม:
  - Search suggestions
  - Recent searches
  - Filter ร่วมกับ search

Anti-patterns ที่ต้องหลีกเลี่ยง

Vibe Coding มี pitfalls ที่พบบ่อย รู้ไว้ก่อนจะช่วยประหยัดเวลาได้มาก

Anti-pattern 1: Prompt Spaghetti

การแก้ปัญหาด้วยการ prompt ซ้ำๆ โดยไม่เข้าใจปัญหา ทำให้โค้ดยิ่งยุ่งขึ้นเรื่อยๆ

❌ Prompt Spaghetti > ทำไมมัน error > แก้แล้วยัง error อีก > ลอง approach อื่น > ยังไม่ได้เลย ลองอีกที (วน 10 รอบ โค้ดยิ่งพัง)	✅ วิธีที่ถูก > หยุด reset กลับ git stash > อธิบายปัญหาใหม่ตั้งแต่ต้น > บอก error ที่แน่ชัด + context > ทำทีละขั้น approve ก่อนไปต่อ (แก้ได้ใน 1-2 รอบ)

Anti-pattern 2: Context Overload

การส่งไฟล์ทุกอย่างให้ Claude ทีเดียว ทำให้ Claude สับสนและ Context เต็มเร็ว

❌ Context Overload > อ่านทุกไฟล์ใน src/ แล้วบอกว่าจะ refactor อะไรได้บ้าง (ส่ง 50 ไฟล์ 5,000 บรรทัด) Claude: สับสน ตอบคลุมเครือ	✅ Focused Context > ดูเฉพาะ @src/features/payment/ มีอะไร refactor ได้บ้าง เน้น error handling (ส่ง 5 ไฟล์ 300 บรรทัด) Claude: ตอบชัดเจน ทำได้จริง

Anti-pattern 3: ไม่ Commit ก่อนให้ Claude แก้ใหญ่

เป็นข้อผิดพลาดที่เจ็บปวดที่สุด Claude แก้ไปแล้ว ทุกอย่างพัง ไม่มีทางกลับ:

⚠️ กฎเหล็ก: Commit ก่อนเสมอ
ก่อนให้ Claude ทำงานอะไรที่เปลี่ยนหลายไฟล์ → git commit
ก่อนให้ Claude refactor ขนาดใหญ่ → git commit
ก่อน Agentic mode (ทำงานอัตโนมัติ) → git commit
ถ้าลืม commit แล้ว Claude เปลี่ยนไฟล์ไปแล้ว → git stash เพื่อเก็บงานเก่าไว้
Commit message ไม่ต้องสวย แค่ “WIP before Claude refactor” ก็พอ

Anti-pattern 4: Vibe โดยไม่ Test

❌ ไม่มี Testing Culture “Claude เขียนให้แล้ว น่าจะถูก” “ไม่มีเวลาเขียน test” “เดี๋ยวค่อย test ตอน launch” → Bug เจอตอน production → แก้ยากเพราะไม่มี test	✅ มี Testing Culture ทุก feature ใหม่มี test อย่างน้อย happy path ให้ Claude เขียน test พร้อม implementation รัน test ก่อน commit ทุกครั้ง → Bug เจอใน development → Refactor ได้มั่นใจ

Anti-pattern 5: ไม่อ่าน Code ที่ Claude เขียน

Claude อาจสร้างโค้ดที่ทำงานได้แต่มีปัญหาซ่อนอยู่ การไม่อ่านเลยเป็น risk ที่ไม่ควรรับ:

อ่านอย่างน้อย	Function signatures, return types, error handling pattern
สิ่งที่ต้อง flag	hardcoded values, TODO comments, console.log ที่ลืมลบ
Red flags	any type, eval(), raw SQL string, missing auth check
ถ้าอ่านไม่เข้าใจ	ให้ Claude อธิบาย logic หลักก่อน แล้วค่อย approve

Vibe Coding สำหรับผู้ที่ไม่มีพื้นฐาน Programming

Vibe Coding ไม่ได้จำกัดอยู่แค่ Developer ผู้ที่ไม่เคยเขียนโค้ดก็สามารถใช้ Claude สร้างสิ่งที่ต้องการได้ แต่ต้องเข้าใจ approach ที่ต่างออกไป

สิ่งที่ต้องเตรียมพร้อมก่อนเริ่ม

รู้ว่าต้องการอะไร: ไม่ต้องรู้ว่า implement ยังไง แต่ต้องรู้ว่า output เป็นแบบไหน

มีสภาพแวดล้อมพร้อม: Node.js installed, VS Code, Terminal เปิดได้

ใจเย็นและพร้อม iterate: ผลลัพธ์แรกอาจไม่สมบูรณ์ ต้อง refine

รู้จัก copy-paste: รู้วิธีคัดลอก error message ทั้งหมดให้ Claude

Workflow สำหรับ Non-Developer

1	บอกสิ่งที่ต้องการในภาษาธรรมชาติ ไม่ต้องใช้คำศัพท์ tech พูดตามที่เข้าใจ Claude จะถามถ้าไม่ชัด

> ผมต้องการโปรแกรมที่:
  - รับ CSV file ที่มีชื่อลูกค้าและยอดซื้อ
  - คำนวณยอดรวมต่อลูกค้า
  - ส่ง email สรุปให้ตัวเองทุกวันอาทิตย์
  ใช้ Windows ครับ ไม่ค่อยรู้เรื่อง coding

2	ให้ Claude แนะนำ approach Claude จะเสนอวิธีที่เหมาะกับระดับความรู้ของเรา

3	ขอให้ Claude อธิบายทุก step ไม่ต้องเดาว่าต้องทำอะไร ถามได้ตลอด

> บอกทีละขั้นเลยว่าต้องทำอะไร
  และอธิบายว่าทำไมต้องทำแบบนั้น
  ถ้าต้องพิมพ์อะไรใน terminal บอกให้ชัดเจน

4	Copy error ทั้งหมดให้ Claude เมื่อมี error ให้ copy ทั้งหมดไม่ต้องแปล

> รันแล้วได้ error นี้:
  [copy error ทั้งหมดมาวาง]
  ผมทำตาม step ที่บอกครบแล้ว

ตัวอย่าง Tools ที่ Non-Developer สร้างได้ด้วย Vibe Coding

Tool	ความยากในการ Vibe Code	ประโยชน์
Excel → Google Sheets automation	ง่าย	ประหยัดเวลาสรุปข้อมูล
Email digest อัตโนมัติ	ง่าย	ไม่ต้องสรุปเอง
PDF → Text extraction	ง่าย	ค้นหาข้อมูลในเอกสาร
Dashboard ข้อมูลส่วนตัว	ปานกลาง	เห็น KPI ทันที
Chatbot ตอบคำถาม FAQ	ปานกลาง	ลด support workload
เว็บไซต์ง่ายๆ	ปานกลาง	ไม่ต้องจ้างฟรีแลนซ์
Internal admin tool	ปานกลาง	จัดการข้อมูลสะดวก

วัดความสำเร็จของ Vibe Coding Session

เมื่อสิ้นสุดแต่ละ Vibe Coding Session ควร Review ว่าเป็นไปได้ดีไหม เพื่อพัฒนาทักษะต่อเนื่อง

Metrics ที่ควรติดตาม

Prompt Efficiency	ได้ผลลัพธ์ที่ต้องการใน prompt กี่ครั้ง? ยิ่งน้อยยิ่งดี
Iteration Count	ต้องแก้กี่รอบก่อนโค้ดทำงานได้? เป้าหมาย < 3 รอบ/feature
Test Coverage	โค้ดที่ได้มี test ครอบคลุมกี่ %? เป้าหมาย > 70%
Bug Rate	หลัง deploy มี bug เกิดจาก vibe code กี่ครั้งต่อสัปดาห์?
Velocity	ทำ feature ได้กี่ชิ้นต่อวัน เทียบกับก่อนใช้ Claude?
Token Cost	ใช้ token เฉลี่ยเท่าไหร่ต่อ feature? ลดได้ไหม?

Session Retrospective — ทบทวนหลังทำงาน

ใช้ Claude ช่วย retrospective หลังจบ session ใหญ่:

> ช่วยทำ Retrospective สำหรับ session นี้:
 
  เราทำงาน [X] ชั่วโมง สร้าง [Y] features
  ติดปัญหาที่ [describe problems]
  ใช้ [Z] prompts โดยรวม
 
  ช่วยวิเคราะห์:
  1. Prompt ไหนที่ให้ผลดีที่สุด ทำไม?
  2. Prompt ไหนที่ waste เวลามากที่สุด?
  3. ถ้าทำใหม่ จะเปลี่ยน approach อะไร?
  4. มี pattern ที่ควรเพิ่มใน CLAUDE.md ไหม?

คำศัพท์ประจำบท

Vibe Coding	การเขียนโปรแกรมโดยใช้ภาษาธรรมชาติบอก AI แล้วให้ AI สร้างโค้ด
Prompt Engineering	ศิลปะการเขียน Prompt ที่ทำให้ AI เข้าใจและทำงานได้ตรงต้องการ
CLEAR Framework	Context, Language, Expected Output, Assumptions, Restrictions
Iteration	การทำซ้ำเพื่อปรับปรุง ทำรอบแรกดร้าฟ รอบถัดไปเพิ่มรายละเอียด
Scaffold	โครงสร้างพื้นฐานของโค้ดที่สร้างเร็ว ยังไม่มี business logic
Progressive Enhancement	เริ่มจาก version ง่าย แล้วค่อย enhance ทีละ layer
Two-Claude Technique	ใช้ Claude ตัวหนึ่งสร้าง อีกตัว review เพื่อหา blind spot
Test-First	เขียน test ก่อน แล้ว implement ทีหลัง ได้โค้ดที่ถูกต้องกว่า
Anti-pattern	วิธีทำที่ดูเหมือนสมเหตุสมผล แต่มักนำไปสู่ปัญหาในระยะยาว
Prompt Spaghetti	การ prompt ซ้ำๆ โดยไม่เข้าใจปัญหา ทำให้โค้ดยิ่งยุ่ง
Context Overload	การส่งข้อมูลมากเกินไปจน Claude สับสนและ Context เต็ว
Rubber Duck Debugging	เทคนิคอธิบายปัญหาให้คนอื่นฟัง มักทำให้หาสาเหตุเจอเอง
Binary Search Debug	หาบัคโดยการแบ่งครึ่งปัญหา ทดสอบครึ่งแรก ถ้าปกติก็ปัญหาอยู่ครึ่งหลัง
Retrospective	การทบทวนสิ่งที่ทำไปเพื่อเรียนรู้และพัฒนาต่อ

บทที่ 4 | การ Vibe Coding — ภาคต่อ (หน้า 20+) กลุ่มเป้าหมาย: ทุกระดับ — เทคนิค Debug, ทางออกสำหรับ Non-Coder, AI Wiki และ RAG สำหรับ Developer

เทคนิคหยุด Claude ไม่ให้วน Loop เมื่อเจอบัก

ปัญหาที่น่าหงุดหงิดที่สุดใน Vibe Coding คือ Claude วนซ้ำแก้บักโดยไม่หายขาด ลองวิธีหนึ่ง ไม่ได้ → ลองวิธีสอง ยังไม่ได้ → กลับไปวิธีแรก วนอยู่อย่างนี้ได้นานเป็นชั่วโมง ส่วนนี้จะสอนวิธีหนีออกจาก Loop อย่างเป็นระบบ

ทำไม Claude ถึงวน Loop?

การเข้าใจสาเหตุช่วยให้หาทางออกได้ถูกต้อง Loop เกิดจาก 4 สาเหตุหลัก:

สาเหตุที่ 1: Context ขาดหาย	Claude ไม่รู้ว่าลองวิธีไหนไปแล้ว เสนอซ้ำโดยไม่รู้ตัว เพราะบทสนทนายาวเกินไป
สาเหตุที่ 2: ปัญหาอยู่ที่อื่น	แก้ที่ A แต่ต้นเหตุจริงอยู่ที่ B Claude จึงแก้ A ซ้ำๆ โดยไม่รู้ว่าปัญหาอยู่ที่อื่น
สาเหตุที่ 3: Hallucination	Claude ไม่แน่ใจในคำตอบ แต่ยังพยายาม generate คำตอบ ผลลัพธ์จึงผิดซ้ำๆ
สาเหตุที่ 4: Prompt คลุมเครือ	บอก requirement ไม่ชัด Claude ตีความต่างกันในแต่ละรอบ ได้ผลลัพธ์คนละแบบ

Protocol หยุด Loop — ทำตามลำดับนี้ทุกครั้ง

เมื่อ Claude ลองแก้บักครบ 2 รอบแล้วยังไม่สำเร็จ หยุดทันที แล้วทำตาม Protocol นี้:

	ขั้นที่ 1: Hard Stop — หยุดทุกอย่างก่อน

# พิมพ์คำสั่งนี้ทันทีเมื่อ Claude วน loop
> หยุดก่อน อย่าลองวิธีใหม่
  รวบรวมสิ่งที่ลองไปแล้วทั้งหมด:
  1. วิธีที่ลองแล้วไม่สำเร็จ (list ทั้งหมด)
  2. สิ่งที่รู้แน่ๆ จากการทดลอง
  3. สิ่งที่ยังไม่รู้และต้องการข้อมูลเพิ่ม
  4. hypothesis ว่าปัญหาอยู่ที่ไหนจริงๆ
  อย่าเสนอวิธีแก้ใหม่จนกว่าจะตอบ 4 ข้อนี้

	ขั้นที่ 2: Reset Context — ล้าง Bias

บทสนทนาที่ยาวเกินไปทำให้ Claude ติด Bias จากสิ่งที่ลองไปแล้ว การ Reset ช่วยให้มองปัญหาใหม่:

# Option A: /compact แล้วทำต่อ
/compact
# จากนั้น brief Claude ใหม่ว่าปัญหาคืออะไร
  โดยไม่บอกวิธีที่เคยลอง
 
# Option B: เปิด Session ใหม่ทั้งหมด
# ปิด claude แล้วเปิดใหม่
claude
 
# จากนั้นบอก context ใหม่ด้วย Bug Report Format นี้:
> Fresh start: มีบัก [อธิบาย] ใน @[file]
  Error message: [copy ทั้งหมด]
  Expected: [อธิบาย]
  Actual: [อธิบาย]
  Context: [tech stack, environment]
  ห้ามอ้างอิง session ก่อนหน้า วิเคราะห์ใหม่จาก scratch

	ขั้นที่ 3: Isolate — แยกปัญหาออก

แทนที่จะแก้ทั้งระบบ ให้สร้าง Minimal Reproducible Example (MRE) — โค้ดที่เล็กที่สุดที่ยังแสดงปัญหาได้:

> ช่วยสร้าง Minimal Reproducible Example สำหรับบักนี้:
  ต้องการโค้ดที่:
  1. เล็กที่สุดเท่าที่ยังแสดงปัญหาได้
  2. รันได้โดยไม่ต้องพึ่ง database หรือ external API
  3. แสดง error เดียวกับที่เจอ
 
  ถ้าสร้าง MRE แล้วปัญหาหายไป แปลว่าปัญหาอยู่ที่
  interaction ระหว่าง component ไม่ใช่ logic หลัก

ตัวอย่าง: สร้าง MRE จริง

# ปัญหา: User.findMany() ใน production crash
# แต่ใน development ทำงานได้ปกติ
 
# MRE: สร้างไฟล์ test เล็กๆ
> สร้างไฟล์ test-db.ts ที่:
  1. เชื่อม database ตรงๆ ไม่ผ่าน middleware
  2. รัน User.findMany() เดียวกับที่ crash
  3. log ผลลัพธ์
  จากนั้นรันใน production environment
  เพื่อดูว่า crash ที่ query เองหรือที่ middleware

	ขั้นที่ 4: Change Strategy — เปลี่ยน Approach

ถ้าลองแก้ตรงๆ ไม่ได้ ให้เปลี่ยน strategy แก้ปัญหาทั้งหมด:

Strategy	เมื่อไหร่ใช้	วิธีทำ
Rewrite ใหม่	โค้ดยุ่งเกินจนแก้ไม่ได้	ลบโค้ดนั้น เขียนใหม่จาก spec
Workaround	แก้ต้นเหตุยาก ต้องการ solution เร็ว	หาวิธีเลี่ยงปัญหา แม้ไม่ elegant
Simplify	Feature ซับซ้อนเกินไป	ลด requirement ลง ทำแบบง่ายกว่า
Library เปลี่ยน	Library นั้นมีบัก	เปลี่ยนไปใช้ library อื่น
Skip ชั่วคราว	บักไม่ critical	ข้ามไปก่อน TODO comment ไว้
External help	Claude แก้ไม่ได้จริงๆ	Stack Overflow, GitHub Issues, Discord

เทคนิคสำหรับบักประเภทต่างๆ

	บักประเภท 1: บักที่ทำซ้ำไม่ได้ (Intermittent Bug)

บักที่เกิดบางครั้งเท่านั้น เป็นประเภทที่แก้ยากที่สุด Claude มักวน loop กับบักแบบนี้

> บักนี้เกิดไม่สม่ำเสมอ อย่าพยายามแก้ตรงๆ
  ให้ทำสิ่งนี้แทน:
 
  1. เพิ่ม comprehensive logging ก่อน:
     - timestamp ที่ทุก step
     - state ของ variables สำคัญ
     - request ID สำหรับ tracking
 
  2. สร้าง log aggregation เพื่อเห็น pattern:
     บัคเกิดตอนไหน? ทุกกี่ครั้ง? user ประเภทไหน?
 
  3. เมื่อมี log เพียงพอ วิเคราะห์หา common factor
 
  อย่าแก้โค้ดจนกว่าจะรู้ root cause จาก log

	บักประเภท 2: บักที่ขึ้นกับ Environment

ทำงานได้ใน local แต่พังใน staging/production เป็นบักที่ Claude แก้ยากเพราะไม่เห็น environment จริง

> บักนี้เกิดใน production เท่านั้น
  วิเคราะห์ความแตกต่างระหว่าง environments:
 
  Local:
  - Node version: [x]
  - Database: local PostgreSQL
  - ENV vars: [list]
 
  Production:
  - Node version: [x]
  - Database: AWS RDS
  - ENV vars: [list]
 
  ช่วยสร้าง checklist ทุกอย่างที่อาจต่างกัน
  และวิธี verify แต่ละอย่าง
 
  ห้าม assume ว่า code ผิด จนกว่าจะ rule out
  environment issues ทั้งหมดแล้ว

	บักประเภท 3: บักจาก Race Condition

เกิดเมื่อ code หลายส่วนทำงานพร้อมกันและ share state — Claude มักเข้าใจยาก ต้องอธิบายให้ชัด

> ผมสงสัยว่านี่อาจเป็น Race Condition
  อธิบาย scenario:
 
  1. User A กด "Add to Cart" (async)
  2. User A กด "Add to Cart" อีกครั้งก่อนรอบแรกเสร็จ
  3. ทั้งสองรอบอ่าน cart เดิมก่อน update
  4. รอบแรก save quantity = 1
  5. รอบสองก็ save quantity = 1 (ไม่ใช่ 2)
 
  ช่วย:
  1. ยืนยันว่านี่คือ race condition จริงไหม
  2. เสนอ solution ที่เหมาะสม (optimistic lock,
     pessimistic lock, queue, หรืออื่นๆ)
  3. อธิบาย tradeoffs ของแต่ละ solution
  4. Implement solution ที่ดีที่สุดสำหรับ use case นี้

CLAUDE.md สำหรับป้องกัน Loop ล่วงหน้า

เพิ่ม section นี้ใน CLAUDE.md เพื่อให้ Claude รู้วิธีจัดการบักอย่างเป็นระบบตั้งแต่ต้น:

## 🐛 Bug Fixing Protocol
 
### เมื่อเจอบัก ทำตามลำดับนี้เสมอ:
1. **Understand first**: อธิบายว่าเข้าใจปัญหาอย่างไรก่อน
2. **Hypothesize**: เสนอ hypothesis 2-3 อัน ไม่ใช่แค่ 1
3. **Test hypothesis**: หาวิธี verify ที่เร็วที่สุด
4. **Fix root cause**: แก้ต้นเหตุ ไม่ใช่ symptom
 
### Loop Prevention Rules:
- ถ้าลองแก้แล้วไม่ได้ 2 รอบ → STOP แล้วถามก่อน
- ห้ามลองวิธีเดิม ถ้า error message เหมือนเดิม
- ถ้าไม่รู้ root cause → บอกตรงๆ อย่า guess
- ถ้าต้องการข้อมูลเพิ่ม → ให้ผู้ใช้หาก่อน
 
### เมื่อ stuck:
1. สรุปสิ่งที่รู้แน่ๆ และสิ่งที่ไม่รู้
2. เสนอ diagnostic steps ที่ผู้ใช้ทำได้
3. ถ้าต้องการ external info บอก url หรือ doc

เทคนิค “Explain Like I’m Wrong” — ให้ Claude ท้าทาย Assumption ของตัวเอง

เทคนิคนี้ทรงพลังมาก บังคับให้ Claude วิเคราะห์จากมุมใหม่แทนที่จะ confirm bias เดิม:

> เราลองแก้ auth bug มา 3 รอบแล้วไม่สำเร็จ
  ตอนนี้ขอให้คุณ assume ว่า
  "สิ่งที่เราคิดว่าเป็นปัญหา อาจไม่ใช่ปัญหาจริงๆ"
 
  วิเคราะห์ใหม่จาก zero:
  1. ถ้า JWT token ไม่ใช่ปัญหา ปัญหาอาจอยู่ที่ไหน?
  2. อะไรที่เราไม่ได้ test เลย?
  3. มี assumption อะไรที่เราอาจผิด?
  4. ถ้าคุณเป็น bug ตัวนี้ คุณซ่อนอยู่ที่ไหน?

Decision Tree: เมื่อไหร่ควรหยุด Vibe แล้วทำอย่างอื่น

บางครั้งการ Vibe Coding ไม่ใช่ solution ที่ถูกต้อง รู้จักสัญญาณว่าควรเปลี่ยนวิธี:

Claude ลอง > 3 รอบ ไม่สำเร็จ	→ Reset Context แล้วเริ่มใหม่ หรือแบ่งปัญหาย่อยลง
Error message เปลี่ยนแต่ยังพัง	→ บัคใหม่จาก fix เก่า git revert แล้วใช้ strategy ต่างออกไป
Claude บอกว่าไม่มั่นใจ	→ หยุด Vibe ไปหาข้อมูลจาก Stack Overflow หรือ official docs ก่อน
ปัญหาเกี่ยวกับ library third-party	→ ดู GitHub Issues ของ library นั้นก่อน อาจเป็น known bug
Error ภาษา infra (DNS, SSL, port)	→ ออกจาก Claude Code ไปดู server logs โดยตรง
บักเกิดเฉพาะใน production	→ ต้องการ production debugging tools: Sentry, Datadog, CloudWatch
ลองมา 30 นาทีแล้วยังไม่ได้	→ พักก่อน ถามคนอื่น หรือ post ใน community

เทคนิคสำหรับผู้ที่ไม่รู้โค้ด: หาทางออกอย่างชาญฉลาด

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

หลักการพื้นฐาน: “อธิบายให้ชัด Claude จัดการให้”

ผู้ไม่รู้โค้ดได้เปรียบในเรื่องหนึ่ง คือไม่มี Bias ด้าน technical ทำให้อธิบายปัญหาจาก “มุมผู้ใช้” ซึ่งมักตรงจุดกว่า ใช้จุดแข็งนี้ให้เป็นประโยชน์

Workflow แก้ปัญหาสำหรับ Non-Coder

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

❌ ตีความสาเหตุเอง “Database น่าจะพัง” “น่าจะมีปัญหาเรื่อง memory” “JavaScript น่าจะ error” (Claude จะแก้ตามที่บอก ไม่ใช่ปัญหาจริง)	✅ อธิบายพฤติกรรม “กดปุ่ม Save แล้วหน้าขาว” “รูปภาพไม่แสดง เห็นแต่กล่องเปล่า” “เมื่อกรอก email ผิด ไม่มีอะไรเกิดขึ้น” (Claude วิเคราะห์จากพฤติกรรมจริง)

2	Copy ทุกอย่างที่เห็นให้ Claude Error message, หน้าจอ, log — ยิ่งมีข้อมูลมากยิ่งดี

# วิธี copy error จาก browser console
1. กด F12 เพื่อเปิด Developer Tools
2. คลิก tab "Console"
3. เห็นข้อความสีแดง → คลิกขวา → Copy
4. วางใน Claude Code
 
# วิธี copy error จาก Terminal
1. เลือกข้อความ error ทั้งหมด
2. Ctrl+C (Windows) หรือ Cmd+C (Mac)
3. วางใน Claude Code
 
# บอก Claude ว่า copy มาจากไหน
> นี่คือ error จาก browser console:
  [วาง error]
 
> นี่คือ error จาก terminal เมื่อรัน npm start:
  [วาง error]

3	บอก Claude ว่าทำอะไรก่อนหน้านี้ ลำดับ action สำคัญมาก บอกทุก step ที่ทำก่อนเกิดปัญหา

> ก่อนเกิด error ผมทำแบบนี้:
  1. แก้ไขไฟล์ src/pages/home.js
     (เพิ่ม button สีแดงตรงกลาง)
  2. บันทึกไฟล์
  3. refresh browser
  4. เห็น error นี้ทันที
 
  ก่อนหน้านี้ทำงานได้ปกติครับ

4	ให้ Claude อธิบายก่อนแก้ ให้ Claude อธิบายว่าปัญหาคืออะไรและจะแก้อย่างไรก่อนทำจริง

> ก่อนแก้ อธิบายให้ผมเข้าใจก่อนว่า:
  1. ปัญหานี้คืออะไร (อธิบายแบบไม่ใช้ technical terms)
  2. จะแก้อย่างไร
  3. มีความเสี่ยงอะไรไหม เช่น อาจทำให้ส่วนอื่นพัง
  4. ถ้าแก้ไม่ได้ มี Plan B ไหม
  รอผม approve ก่อนแก้จริง

5	ทำทีละ Step ช้าๆ ไม่ต้องรีบ ให้ Claude ทำทีละอย่าง แล้วบอกผลก่อนไปต่อ

> แก้ทีละ step แล้วรอให้ผมบอกผลก่อน
  ถ้าขั้นตอนไหนไม่เข้าใจ ผมจะถาม
  ถ้า step ไหนเกิด error ใหม่ ผมจะ copy ให้

Template ถามปัญหาสำหรับ Non-Coder

Copy template นี้ไปใช้ได้ทันทีเมื่อเจอปัญหา:

------- Template: Bug Report สำหรับ Non-Coder -------
 
> ผมเจอปัญหาครับ ขอความช่วยเหลือ
 
  สิ่งที่ต้องการให้เกิด:
  [อธิบายว่าอยากให้อะไรทำงาน]
 
  สิ่งที่เกิดขึ้นจริง:
  [อธิบายว่าเกิดอะไรแทน]
 
  ขั้นตอนที่ทำ:
  1. [ทำอะไร]
  2. [ทำอะไร]
  3. เกิด error
 
  Error message (copy ทั้งหมด):
  [วาง error ตรงนี้]
 
  ระบบที่ใช้:
  - Windows / Mac / Linux
  - Browser: Chrome / Firefox / Safari
 
  ก่อนหน้านี้ทำงานได้ไหม: ได้ / ไม่เคยได้เลย
 
  กรุณา:
  1. อธิบายปัญหาเป็นภาษาธรรมดาก่อน
  2. บอก step แก้ไขทีละขั้น
  3. รอให้ผม confirm ทุก step
------- จบ Template -------

เมื่อ Claude ตอบไม่เข้าใจ — วิธีถาม Follow-up

ถ้า Claude ตอบแล้วยังไม่เข้าใจ ไม่ต้องอาย ถามต่อได้เลย นี่คือ prompts ที่ใช้บ่อย:

อธิบายใหม่แบบง่ายกว่า	> อธิบายอีกครั้งแบบที่คนไม่รู้โปรแกรมเข้าใจได้ ไม่ต้องใช้คำ technical
ขอตัวอย่าง	> ยกตัวอย่างที่เป็นรูปธรรมมากกว่านี้ได้ไหม
ขอ step ละเอียดขึ้น	> ช่วยอธิบาย step นี้ให้ละเอียดขึ้น ทำอย่างไรกันแน่
ยืนยันความเข้าใจ	> ผมเข้าใจว่า [สรุปสิ่งที่เข้าใจ] ถูกต้องไหม
ขอ alternative	> มีวิธีที่ง่ายกว่านี้ไหม ที่ไม่ต้องเขียนโค้ดเองเลย
ถ้าใส่ผิด	> ถ้าทำผิดพลาดใน step นี้ จะเกิดอะไร และแก้ได้ไหม

No-Code Alternatives — เมื่อ Vibe Coding ยากเกินไป

บางกรณีมีทางออกที่ไม่ต้องเขียนโค้ดเลย Claude ช่วยแนะนำ tool ที่เหมาะสมได้:

> ผมต้องการ [อธิบายสิ่งที่ต้องการ]
  แต่ไม่มีพื้นฐาน programming
  มี tool หรือ platform ที่ทำได้โดยไม่ต้องเขียนโค้ดไหม?
  budget: [ระบุ หรือ "ฟรีถ้าเป็นไปได้"]
 
# ตัวอย่าง tools ที่ Claude มักแนะนำ:
- สร้างเว็บ: Webflow, Framer, Squarespace
- Automation: Zapier, Make (Integromat), n8n
- Database/App: Airtable, Notion, Glide
- Chatbot: Voiceflow, Landbot
- Forms: Typeform, Tally
- Dashboard: Retool, AppSmith

AI Wiki — คลังความรู้ที่ Claude ค้นหาได้

AI Wiki คือการจัดระเบียบ knowledge ในโปรเจคให้อยู่ในรูปแบบที่ Claude ค้นหาและใช้ได้ทันที แทนที่จะต้องอธิบายบริบทเดิมซ้ำๆ ทุก session มีผลอย่างมากต่อคุณภาพของ code ที่ Claude สร้าง

ทำไม AI Wiki ถึงสำคัญ?

ลองนึกภาพ: Developer ใหม่เข้าโปรเจค ไม่รู้อะไรเลย ถ้าไม่มีเอกสาร เขาจะถามทุกอย่างซ้ำๆ กับ Claude ก็เหมือนกัน AI Wiki คือ “onboarding document” ที่ Claude อ่านแล้วทำงานได้ทันทีโดยไม่ต้องถาม

โครงสร้าง AI Wiki ที่แนะนำ

docs/                          ← โฟลเดอร์หลักของ Wiki
  README.md                    ← Index ของทุก doc
  architecture/
    overview.md                ← ภาพรวมระบบ + diagram
    data-flow.md               ← ข้อมูลไหลผ่านระบบอย่างไร
    decisions.md               ← ADR (ทำไมถึงเลือก X แทน Y)
  domain/
    business-rules.md          ← กฎ business ที่ซับซ้อน
    glossary.md                ← คำศัพท์เฉพาะของ domain
    user-journeys.md           ← User flow หลักทั้งหมด
  api/
    endpoints.md               ← API reference ครบ
    error-codes.md             ← ทุก error code + ความหมาย
    auth.md                    ← วิธี authenticate
  database/
    schema.md                  ← ER diagram + field descriptions
    indexes.md                 ← Index ที่มีและเหตุผล
    migrations.md              ← ประวัติ migration สำคัญ
  runbooks/
    deploy.md                  ← วิธี deploy step-by-step
    rollback.md                ← วิธี rollback ฉุกเฉิน
    common-issues.md           ← ปัญหาที่เจอบ่อย + วิธีแก้
  development/
    setup.md                   ← วิธี setup local env
    testing.md                 ← Testing strategy + วิธีรัน
    code-style.md              ← Conventions ละเอียด

วิธีใช้ AI Wiki ใน Claude Code

วิธีที่ 1: อ้างอิงตรงๆ ใน Prompt

# อ้างอิงก่อนทำงาน
> ก่อน implement payment feature
  อ่าน @docs/domain/business-rules.md ส่วน Payment
  และ @docs/api/auth.md เพื่อเข้าใจ auth flow
  แล้วออกแบบ solution ที่ consistent กับ pattern ที่มีอยู่
 
# อ้างอิงเมื่อมีข้อสงสัย
> ดู @docs/architecture/decisions.md
  ว่าเราตัดสินใจเรื่อง caching อย่างไร
  และ implement ให้ consistent กับ decision นั้น

วิธีที่ 2: ระบุใน CLAUDE.md ให้ Claude อ่านอัตโนมัติ

# ใน CLAUDE.md เพิ่ม section นี้
## 📚 Documentation (อ่านก่อนทำงาน)
 
### ก่อน implement feature ใดๆ:
- อ่าน @docs/domain/business-rules.md
- อ่าน @docs/architecture/overview.md
 
### ก่อน database change:
- อ่าน @docs/database/schema.md
- อ่าน @docs/database/migrations.md
 
### ก่อน API change:
- อ่าน @docs/api/endpoints.md
- อ่าน @docs/api/error-codes.md

สร้าง AI Wiki ดีๆ — หลักการและตัวอย่าง

	ตัวอย่าง 1: business-rules.md ที่ดี

# Business Rules
 
## Pricing Rules
 
### Discount Calculation
ลำดับการ apply discount (สำคัญมาก ต้อง apply ตามลำดับนี้เสมอ):
1. Coupon discount (ลดจากราคาเต็ม)
2. Member discount (ลดจากราคาหลัง coupon)
3. Bundle discount (ลดจากราคาหลัง member)
4. ราคาสุดท้ายต้องไม่ต่ำกว่า cost price
 
ตัวอย่าง:
- ราคาเต็ม: 1,000 บาท
- Coupon 10%: 1,000 × 0.9 = 900
- Member Gold 5%: 900 × 0.95 = 855
- Bundle 3%: 855 × 0.97 = 829.35
- Cost price: 800 → OK (829 > 800)
 
### Free Shipping Rules
- ฟรีค่าส่ง: ยอดซื้อ >= 500 บาท (หลัง discount)
- ยกเว้น: สินค้า "Heavy" category ไม่มีฟรีค่าส่ง
- ยกเว้น: ส่งต่างจังหวัดต้องยอดซื้อ >= 800 บาท
 
## Order Status Rules
| Status | เปลี่ยนเป็นได้ | เปลี่ยนเป็นไม่ได้ |
|--------|--------------|----------------|
| pending | confirmed, cancelled | shipped, completed |
| confirmed | shipped, cancelled | completed |
| shipped | completed | pending, confirmed, cancelled |
| completed | (ไม่มี) | ทุก status |
| cancelled | (ไม่มี) | ทุก status |

	ตัวอย่าง 2: error-codes.md ที่ดี

# API Error Codes Reference
 
## Format
ทุก error response มีรูปแบบ:
{ "error": { "code": "E001", "message": "...", "details": {} } }
 
## Error Codes
 
### Authentication (E1xx)
| Code | HTTP | ความหมาย | User ควรเห็น | Action |
|------|------|---------|------------|--------|
| E101 | 401 | Token หมดอายุ | "กรุณา login ใหม่" | Redirect to login |
| E102 | 401 | Token ไม่ถูกต้อง | "Session ผิดพลาด" | Clear token + login |
| E103 | 403 | ไม่มีสิทธิ์ | "ไม่มีสิทธิ์เข้าถึง" | แสดง 403 page |
 
### Validation (E2xx)
| Code | HTTP | ความหมาย | User ควรเห็น | Action |
|------|------|---------|------------|--------|
| E201 | 400 | Email format ผิด | "รูปแบบ email ไม่ถูกต้อง" | Highlight field |
| E202 | 400 | Password สั้นเกิน | "Password ต้องมีอย่างน้อย 8 ตัว" | Highlight field |
| E203 | 409 | Email ซ้ำ | "Email นี้มีบัญชีแล้ว" | แสดง login link |
 
## ข้อควรระวัง
- E500 ห้าม expose internal error message ให้ user เด็ดขาด
- ทุก E5xx ต้อง log ใน Sentry พร้อม request ID
- E101 และ E102 ต้อง clear cookie ด้วยเสมอ

ให้ Claude ช่วยสร้างและ Maintain AI Wiki

ไม่ต้องเขียน Wiki เองทั้งหมด ให้ Claude ช่วยสร้างและอัปเดตได้:

# สร้าง Wiki จาก codebase
> วิเคราะห์โปรเจคแล้วสร้าง AI Wiki
  เริ่มจากไฟล์เหล่านี้:
  @src/server/actions/ @src/lib/ @prisma/schema.prisma
 
  สร้าง:
  1. docs/api/endpoints.md จาก route handlers ทั้งหมด
  2. docs/database/schema.md จาก Prisma schema
  3. docs/domain/business-rules.md จาก validation logic
 
# อัปเดต Wiki หลัง implement feature
> เพิ่งเพิ่ม Notification system เรียบร้อย
  อัปเดต docs ที่เกี่ยวข้อง:
  - เพิ่ม Notification endpoints ใน @docs/api/endpoints.md
  - เพิ่ม notification table ใน @docs/database/schema.md
  - เพิ่ม notification rules ใน @docs/domain/business-rules.md
 
# สร้าง Runbook จากประสบการณ์
> เมื่อกี้แก้ปัญหา Redis connection ตาย
  สร้าง runbook ที่ @docs/runbooks/common-issues.md
  อธิบาย symptoms, root cause, และวิธีแก้
  เพื่อให้ครั้งต่อไปแก้ได้เร็วขึ้น

RAG (Retrieval-Augmented Generation) สำหรับ Claude Code

RAG คือเทคนิคที่ให้ Claude ค้นหาข้อมูลจาก knowledge base ขนาดใหญ่ก่อนตอบ แทนที่จะต้องโหลดทุกอย่างเข้า Context เหมาะมากสำหรับ codebase ขนาดใหญ่ เอกสารจำนวนมาก หรือข้อมูลที่เปลี่ยนบ่อย

เมื่อไหร่ควรใช้ RAG?

ใช้ RAG เมื่อ	ไม่ต้องใช้ RAG เมื่อ
Codebase > 100 ไฟล์	โปรเจคเล็ก < 50 ไฟล์
มี Documentation จำนวนมาก	Doc น้อยใส่ใน CLAUDE.md ได้
ข้อมูลอัปเดตบ่อย เช่น API docs	ข้อมูล static ไม่ค่อยเปลี่ยน
ต้องการค้นหาข้ามหลาย repository	ทำงานกับ repo เดียว
Context เต็มบ่อยจากไฟล์ใหญ่	Context ยังมีพื้นที่เพียงพอ
ทีมใหญ่ แต่ละคนต้องการ knowledge เดียวกัน	Solo developer, rote ง่าย

RAG แบบง่าย: ใช้ MCP Filesystem + Search

วิธีที่ง่ายที่สุดไม่ต้องตั้ง infrastructure เพิ่ม ใช้ MCP Filesystem ที่มีอยู่แล้ว บวกกับ Claude’s built-in search:

# setup MCP Filesystem ที่ครอบคลุม docs ทั้งหมด
// ~/.claude/settings.json
{
  "mcpServers": {
    "docs": {
      "command": "npx",
      "args": [
        "-y", "@modelcontextprotocol/server-filesystem",
        "/Users/john/Projects/myapp/docs",
        "/Users/john/Projects/myapp/src"
      ]
    }
  }
}
 
# จากนั้น Claude ค้นหาได้เอง
> ค้นหาใน docs ทั้งหมด ว่ามีที่ไหนพูดถึง
  "rate limiting" บ้าง แล้วสรุปให้
 
> หา function ทั้งหมดที่เกี่ยวกับ payment ใน src/
  แล้ว list ว่าแต่ละตัวทำอะไร

RAG แบบกลาง: LlamaIndex + Claude

LlamaIndex เป็น framework ที่ได้รับความนิยมมากที่สุดสำหรับ RAG ตั้งค่าได้ภายใน 30 นาที รองรับ Claude โดยตรง

ขั้นตอนการตั้งค่า

1	ติดตั้ง Dependencies ต้องการ Python 3.9+ และ pip

pip install llama-index llama-index-llms-anthropic
pip install llama-index-embeddings-huggingface
# ใช้ HuggingFace embeddings (ฟรี) แทน OpenAI

2	สร้าง Index จาก Documents Indexing ครั้งแรกอาจใช้เวลา ขึ้นกับขนาด docs

# build_index.py
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.llms.anthropic import Anthropic
from llama_index.core import Settings
import os
 
os.environ["ANTHROPIC_API_KEY"] = "sk-ant-..."
 
# โหลด documents จากโฟลเดอร์
documents = SimpleDirectoryReader(
    input_dir="./docs",
    recursive=True,           # อ่าน subfolder ด้วย
    required_exts=[".md", ".txt", ".py"]  # เฉพาะ file type ที่ต้องการ
).load_data()
 
# ตั้งค่า Claude เป็น LLM
Settings.llm = Anthropic(model="claude-sonnet-4")
 
# สร้าง vector index
index = VectorStoreIndex.from_documents(documents)
 
# บันทึก index ลงดิสก์ (ไม่ต้อง rebuild ทุกครั้ง)
index.storage_context.persist(persist_dir="./index_storage")
print(f"Indexed {len(documents)} documents")

3	Query ผ่าน RAG หลัง index พร้อมแล้ว ค้นหาได้ทันที

# query_rag.py
from llama_index.core import StorageContext, load_index_from_storage
from llama_index.llms.anthropic import Anthropic
from llama_index.core import Settings
 
# โหลด index ที่บันทึกไว้
storage_context = StorageContext.from_defaults(
    persist_dir="./index_storage"
)
index = load_index_from_storage(storage_context)
 
Settings.llm = Anthropic(model="claude-sonnet-4")
 
# สร้าง query engine
query_engine = index.as_query_engine(
    similarity_top_k=5,  # ดึง 5 documents ที่เกี่ยวข้องที่สุด
    response_mode="tree_summarize"  # สรุปจากหลาย docs
)
 
# ถามคำถาม
response = query_engine.query(
    "วิธี calculate discount สำหรับ member Gold tier"
)
print(response)
print("\nSources:")
for node in response.source_nodes:
    print(f"  - {node.metadata['file_path']}  (score: {node.score:.2f})")

4	เชื่อม RAG กับ Claude Code ผ่าน MCP ทำให้ Claude Code เรียก RAG ได้โดยตรง

# rag_server.py — สร้าง simple HTTP server
from flask import Flask, request, jsonify
from llama_index.core import StorageContext, load_index_from_storage
from llama_index.llms.anthropic import Anthropic
from llama_index.core import Settings
 
app = Flask(__name__)
 
# โหลด index ตอน startup
storage_context = StorageContext.from_defaults(persist_dir="./index_storage")
index = load_index_from_storage(storage_context)
Settings.llm = Anthropic(model="claude-sonnet-4")
query_engine = index.as_query_engine(similarity_top_k=5)
 
@app.route("/query", methods=["POST"])
def query():
    question = request.json["question"]
    response = query_engine.query(question)
    return jsonify({
        "answer": str(response),
        "sources": [n.metadata["file_path"] for n in response.source_nodes]
    })
 
if __name__ == "__main__":
    app.run(port=8765)
 
# รัน server: python rag_server.py
 
# ใน Claude Code ถามผ่าน bash:
> รัน: curl -X POST http://localhost:8765/query
  -H "Content-Type: application/json"
  -d '{"question": "วิธีจัดการ payment retry"}'
  แล้วนำคำตอบมาใช้ implement feature

RAG แบบ Advanced: Codebase Search ด้วย Embeddings

สำหรับ Codebase ขนาดใหญ่ การค้นหาด้วย Semantic Search ทรงพลังกว่า grep มาก ค้นหาด้วยความหมายได้แม้ชื่อ function ต่างกัน

# code_search.py — ค้นหาโค้ดด้วย semantic search
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.core.node_parser import CodeSplitter
from llama_index.llms.anthropic import Anthropic
from llama_index.core import Settings
 
# โหลดเฉพาะ source code
documents = SimpleDirectoryReader(
    input_dir="./src",
    recursive=True,
    required_exts=[".ts", ".tsx", ".js", ".py"]
).load_data()
 
# ใช้ CodeSplitter แบ่งโค้ดตาม function/class
splitter = CodeSplitter(
    language="typescript",
    chunk_lines=50,       # โค้ดประมาณ 50 บรรทัดต่อ chunk
    chunk_lines_overlap=5
)
 
nodes = splitter.get_nodes_from_documents(documents)
Settings.llm = Anthropic(model="claude-sonnet-4")
index = VectorStoreIndex(nodes)
 
# ค้นหาโค้ดด้วยความหมาย
retriever = index.as_retriever(similarity_top_k=10)
 
# ตัวอย่าง: ค้นหา code ที่เกี่ยวกับ authentication
results = retriever.retrieve("check if user is logged in")
for r in results:
    print(f"File: {r.metadata['file_path']}:{r.metadata['start_char_idx']}")
    print(f"Score: {r.score:.3f}")
    print(r.text[:200])
    print("---")

RAG Workflow สำหรับ Vibe Coding จริง

นี่คือ workflow ที่นำ RAG มาใช้จริงใน daily development:

# .claude/commands/rag-search.md
# RAG Search Command
 
# ค้นหาข้อมูลจาก knowledge base ก่อน implement
# Usage: /project:rag-search [topic]
 
ทำสิ่งต่อไปนี้:
1. รัน: curl -s -X POST http://localhost:8765/query
   -H "Content-Type: application/json"
   -d {"question": "ข้อมูลเกี่ยวกับ $ARGUMENTS"}
 
2. อ่านผลลัพธ์และ sources
 
3. สรุปว่า knowledge base รู้อะไรเกี่ยวกับ topic นี้
   และ source files ที่เกี่ยวข้องคือไฟล์ไหน
 
4. เสนอว่า implement ใหม่ควรทำยังไง
   ให้ consistent กับ pattern ที่มีอยู่
 
# ใช้งาน:
> /project:rag-search payment retry logic
> /project:rag-search user authentication
> /project:rag-search error handling pattern

Auto-update RAG Index เมื่อโค้ดเปลี่ยน

ถ้า index ไม่อัปเดต Claude จะได้ข้อมูลเก่า ตั้ง auto-update ด้วย Git Hook:

# .git/hooks/post-commit
#!/bin/bash
 
# หาไฟล์ที่เพิ่งแก้ไข
CHANGED=$(git diff --name-only HEAD~1 HEAD)
 
# ถ้ามีไฟล์ .md หรือ source code เปลี่ยน
if echo "$CHANGED" | grep -qE ".(md|ts|tsx|py)$"; then
  echo "🔄 Updating RAG index..."
  python build_index.py --incremental
  echo "✅ RAG index updated"
fi
 
# ทำให้รันได้
chmod +x .git/hooks/post-commit
 
# หรือใช้ watch mode (รัน background)
# watchmedo shell-command \
#   --patterns="*.md;*.ts;*.py" \
#   --command="python build_index.py --incremental" \
#   --recursive \
#   ./docs ./src

RAG สำหรับ Third-party Documentation

นอกจาก internal docs แล้ว RAG ยังใช้กับ documentation ของ library ที่ใช้ได้ ทำให้ Claude ตอบคำถามเกี่ยวกับ library version เฉพาะได้ถูกต้องกว่า Training data

# ดาวน์โหลด docs ของ library ที่ใช้
# ตัวอย่าง: Next.js docs, Prisma docs
 
# scrape_docs.py
import requests
from bs4 import BeautifulSoup
import os
 
def scrape_docs(base_url, output_dir, max_pages=200):
    """ดาวน์โหลด docs เป็น markdown files"""
    os.makedirs(output_dir, exist_ok=True)
    # ... implementation
 
# ตัวอย่าง docs ที่ควร index:
# - Prisma docs (เพราะอัปเดตบ่อยมาก)
# - Next.js App Router docs (version specific)
# - Internal API docs ของ partner
# - Company knowledge base
 
# จากนั้น build index รวมกับ internal docs
python build_index.py --dirs ./docs ./external-docs
 
# ใน Claude Code
> ดู @docs/external/prisma/ แล้วบอกว่า
  Prisma 5.x เปลี่ยน API อะไรบ้างจาก 4.x
  ที่กระทบกับโค้ดเรา

RAG vs ทางเลือกอื่น: เลือกอะไรดี?

Solution	ความยาก Setup	เหมาะกับ	ข้อดี	ข้อเสีย
CLAUDE.md เท่านั้น	ง่าย	โปรเจคเล็ก < 50 ไฟล์	ไม่ต้อง setup อะไร	จำกัดขนาด, อ่านทุกครั้ง
MCP Filesystem	ง่าย	โปรเจคกลาง 50-200 ไฟล์	Claude ค้นหาเองได้	ไม่มี semantic search
LlamaIndex RAG	กลาง	โปรเจคใหญ่ > 200 ไฟล์	Semantic search	ต้อง maintain index
Embedded Vector DB	ยาก	Enterprise, ทีมใหญ่	เร็ว scale ได้	Complex setup
External RAG Service	ง่าย-กลาง	ทีมที่ไม่ต้องการ infra	Managed, ไม่ต้อง maintain	ค่าใช้จ่ายเพิ่ม, privacy concern

💡 แนะนำสำหรับมือใหม่
เริ่มจาก CLAUDE.md + MCP Filesystem ก่อน
เมื่อโปรเจคใหญ่ขึ้นจนรู้สึกว่า Context เต็มบ่อย ค่อยเพิ่ม LlamaIndex
RAG ที่ดีที่สุดคือ RAG ที่ทีม maintain ได้จริง ไม่ใช่ที่ซับซ้อนที่สุด

สรุป: Vibe Coding Checklist ที่ใช้ทุกวัน

รวม checklist ทุกอย่างในบทนี้ไว้เป็นไฟล์เดียว ใช้เป็น quick reference ได้ทันที:

# .claude/commands/daily-checklist.md
# Daily Vibe Coding Checklist
 
## ก่อนเริ่ม Session (5 นาที)
□ git checkout -b feature/[ชื่อ feature]
□ อ่าน CLAUDE.md: > อ่าน @CLAUDE.md สรุปว่าทำอะไรอยู่
□ RAG search ถ้าโปรเจคใหญ่: /project:rag-search [topic]
□ กำหนด scope ชัด: บอก Claude ว่าทำอะไร และ out of scope คืออะไร
 
## ระหว่าง Build (ทุก iteration)
□ Prompt ชัด: ใช้ CLEAR framework
□ ทำทีละชิ้นเล็ก: ไม่ส่ง requirement ทั้งหมดในครั้งเดียว
□ Review ก่อน run: อ่าน logic หลัก หา red flags
□ Test ทุกอย่าง: รัน tests ก่อน commit
□ Commit บ่อย: commit เมื่อ feature ย่อยเสร็จ
 
## เมื่อเจอบัก
□ < 2 รอบ: ลองแก้ตรงๆ
□ ครบ 2 รอบ: Hard Stop → วิเคราะห์ใหม่
□ ยังไม่ได้: Reset Context → เริ่ม Session ใหม่
□ ยังไม่ได้: สร้าง MRE → Isolate ปัญหา
□ ยังไม่ได้: Change Strategy → อย่าดัน
 
## ก่อนปิด Session
□ /project:review — รีวิวโค้ดทั้งหมด
□ รัน tests ทั้งหมด ต้องผ่านก่อน commit
□ /project:handoff — สร้าง handoff document
□ อัปเดต Wiki ถ้ามี doc ที่เปลี่ยน
□ git push origin [branch]

คำศัพท์เพิ่มเติมประจำบท (ต่อ)

Loop Bug	การที่ Claude วนซ้ำลองแก้บักโดยไม่สำเร็จ ต้องหยุดและ reset
Hard Stop	การหยุดทุกอย่างทันทีและให้ Claude สรุปสิ่งที่รู้ก่อนลองต่อ
MRE (Minimal Reproducible Example)	โค้ดเล็กสุดที่ยังแสดงบักได้ ช่วย isolate ปัญหา
Race Condition	บักที่เกิดเมื่อสอง process ทำงานพร้อมกันและ share state
Intermittent Bug	บักที่เกิดไม่สม่ำเสมอ ยากแก้เพราะ reproduce ไม่ได้ทุกครั้ง
AI Wiki	คลังความรู้ในรูป Markdown ที่ออกแบบให้ Claude อ่านและค้นหาได้
RAG (Retrieval-Augmented Generation)	เทคนิคให้ AI ค้นหาข้อมูลก่อนตอบ แทนการจำทุกอย่าง
Vector Index	โครงสร้างข้อมูลที่เก็บ embedding ของ text เพื่อค้นหาความหมาย
Embedding	การแปลง text เป็นตัวเลข (vector) ที่แสดง semantic meaning
Semantic Search	การค้นหาด้วยความหมาย ไม่ใช่แค่ keyword matching
LlamaIndex	Framework Python สำหรับสร้าง RAG pipeline ใช้กับ LLM ได้ง่าย
Incremental Indexing	การอัปเดต index เฉพาะไฟล์ที่เปลี่ยน ไม่ต้อง rebuild ทั้งหมด
ADR (Architecture Decision Record)	เอกสารบันทึก decision สำคัญ ว่าทำไมถึงเลือกวิธีนั้น