prompt ที่ดี (1) — ชัดเจน · ให้ตัวอย่าง · ให้คิดทีละขั้น

Next.js     16.3.5   # npx next build (บรรทัดแรกของ output)
react       19.2.8
typescript  5.9.3
eslint      9.39.5
node        v24.14.0

6 หลักของ prompt ที่ดี — แผนที่ของสองบท

สไลด์หน้า 20 ชื่อ Become a good prompt วางไว้ 6 ภาพ:

สามข้อแรกมีจุดร่วมกันข้อเดียว: ลดจำนวนสิ่งที่ AI ต้องเดา
ข้อ 1 ลดด้วยคำอธิบาย · ข้อ 2 ลดด้วยตัวอย่าง · ข้อ 3 ลดด้วยการบังคับลำดับความคิด

หลักที่ 1 · Be Clear and Specific

สไลด์หน้า 22 (Why clear?) มีสองประโยค — ถอดตามจริง:

ภาพข้างขวาของหน้าเดียวกันเทียบกระดาษสองแผ่น
แผ่นซ้าย UNCLEAR REQUEST เขียนแค่ “Need something about our project update” แล้วรอบ ๆ เต็มไปด้วยคำถามที่คนรับงานต้องเดาเอง: For stakeholders? · Who is the audience? · What tone? · What to include?? (not sure) · How long? · Format?? · What’s the goal?
แผ่นขวา CLEAR & SPECIFIC REQUEST ตอบคำถามพวกนั้นครบเป็นหกช่อง: GOAL · AUDIENCE · TONE · KEY POINTS · CONSTRAINTS (Max 200 words · Use plain language · No technical jargon) · EXPECTED OUTCOME

พูดภาษาคน: ทุกคำถามที่คุณไม่ได้ตอบใน prompt ไม่ได้หายไปไหน — AI ตอบแทนคุณ
และมันจะตอบด้วย “ค่าที่พบบ่อยที่สุด” ซึ่งแทบไม่เคยตรงกับงานของคุณพอดี
นี่คือเรื่องเดียวกับบท 78 ที่โจทย์ Customer Search บรรทัดครึ่งซ่อนคำถามไว้ 5 ข้อ — แค่คราวนี้คนที่ต้องตัดสินใจแทนคุณคือ AI ไม่ใช่ตัวคุณเอง

คู่ Bad/Good ของสไลด์หน้า 23

Write something about our new feature.

Write a 150-word announcement for our new dark-mode
feature, aimed at existing users, highlighting that
it reduces eye strain and syncs across devices.
Tone: friendly and concise.

(ในสไลด์ Good Prompt เป็นบรรทัดเดียว (เลขบรรทัด 1) ที่ตัดขึ้นบรรทัดใหม่ตามความกว้างกล่อง · ผมตัดบรรทัดตรงจุดเดียวกับสไลด์)

แยก Good Prompt ออกเป็นห้าชิ้น — สามชิ้นแรก (task · scope · constraints) คือคำในบรรทัดของสไลด์หน้า 22 ตรง ๆ · อีกสองชิ้น (audience · tone) มาจากช่อง AUDIENCE กับ TONE ในภาพฝั่งขวาของหน้าเดียวกัน ซึ่งเป็น “details that matter” ของงานเขียน — แล้วดูว่า Bad Prompt มีชิ้นไหนบ้าง:

สังเกตว่า Good Prompt ยาวขึ้นจาก 6 คำเป็น 27 คำ (นับด้วย wc -w) ไม่ได้ยาวเป็นหน้า · มันไม่ได้ “สุภาพขึ้น” หรือ “ใช้คำสวยขึ้น” เลย — มันแค่ตอบคำถามที่ต้องตอบอยู่ดีไว้ล่วงหน้า

Add a loading state to the recipes page.

หลักที่ 2 · Give Examples (Few-shot prompting)

สไลด์หน้า 25 (How Write Example) — ถอดตามจริง:

ภาพข้างขวาของหน้านี้แบ่งเป็นสามคอลัมน์: NO EXAMPLES PROVIDED (ผลลัพธ์ที่ได้ปนกันมั่ว — สั้นไป · ยาวไป · น้ำเสียงไม่คงที่ · I’m not sure what you want?) → EXAMPLE PIPELINE (ตัวอย่าง 1–3 ค่อย ๆ เติม structure · tone · format · style) → PATTERN LEARNED (โมเดลจับแพตเทิร์นร่วมได้ แล้วผลลัพธ์สุดท้ายออกมาเป็นแนวเดียวกัน)
แถบล่างสุดสรุปว่า Without examples ผลไม่คงที่ · With examples โมเดลเรียนรู้แพตเทิร์น · With learned patterns ผลคงที่และตรงเป้า

พูดภาษาคน: บางอย่างอธิบายด้วยคำยากกว่าโชว์ให้ดู
ลองอธิบายว่า “ticket แบบไหนเรียกว่าด่วน” เป็นคำพูด — คุณจะเขียนได้เป็นย่อหน้าแล้วก็ยังไม่ครบ
แต่โชว์สองตัวอย่างว่า “อันนี้ด่วน อันนี้ไม่ด่วน” AI เห็นเกณฑ์ที่คุณใช้ทันที

คู่ Bad/Good ของสไลด์หน้า 26

Classify these support tickets by urgency

Classify these tickets by urgency.

**Examples:**
- "App won't open, demo in 10 min" -> High.
- "Typo on the About page" -> Low.

Now classify: [tickets]

หลักที่ 3 · Step-by-step Reasoning

สไลด์หน้า 28 (Involved Logic) — ถอดตามจริง:

ภาพข้างขวาเทียบสองทาง: ฝั่ง DIRECT GUESS เจอโจทย์ซับซ้อนแล้วคิดว่า “This looks complicated… I’ll just guess.” → SKIP ANALYSIS → ได้คำตอบสามรอบไม่ตรงกันเลย · ฝั่ง STEP-BY-STEP REASONING ไล่ 7 ขั้น: Understand the Problem → Gather Information → Identify Key Requirements → Break into Smaller Steps → Analyze and Reason → Verify Logic → Form Final Conclusion

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

$ node -e 'console.log("6*40 + 4*60 + 8*80 =", 6*40 + 4*60 + 8*80)'
6*40 + 4*60 + 8*80 = 1120

สไลด์แยกการใช้หลักนี้เป็นสองกรณี ซึ่งเขียน prompt ต่างกันคนละแบบ:

กรณีที่ 1 — ไม่รู้ขั้นตอน (สไลด์หน้า 29 · When doesn’t know working steps)

A shirt costs $40 after a 20% discount. What was
the original price?

A shirt costs $40 after a 20% discount. Work
through it step by step, then give the original
price.

A shirt costs $40 after a 20% discount. What was
the original price?

$ node -e '
console.log("40 / (1 - 0.20) =", 40 / (1 - 0.20));
console.log("40 * (1 + 0.20) =", 40 * (1 + 0.20));
console.log("50 * 0.80       =", 50 * 0.80);
console.log("48 * 0.80       =", 48 * 0.80);'
40 / (1 - 0.20) = 50
40 * (1 + 0.20) = 48
50 * 0.80       = 40
48 * 0.80       = 38.400000000000006

สังเกตโครงของ Good Prompt หน้า 29: ไม่ได้บอกว่าขั้นตอนคืออะไร บอกแค่ว่า ให้มีขั้นตอน และลำดับ — “step by step” ก่อน “then give the original price” · ใช้เมื่อคุณเองก็ไม่รู้ว่าต้องคิดกี่ขั้น ปล่อยให้ AI แตกขั้นเอง (ตรงกับบรรทัด Reasoning first, conclusion second ของหน้า 28)

กรณีที่ 2 — รู้ขั้นตอนอยู่แล้ว (สไลด์หน้า 30 · When know working steps)

Review this code, please.

Review this code and check each item. Mark ✅ or ❌
with a short note:

- [ ] No hardcoded secrets
- [ ] All functions have error handling
- [ ] Variable names are descriptive
- [ ] Tests cover edge cases

คราวนี้คุณรู้ขั้นอยู่แล้ว — ทีมมีเกณฑ์รีวิวสี่ข้อ · ไม่ต้องให้ AI คิดขั้นเอง ให้ขั้นไปเลย
Bad Prompt Review this code, please. ปล่อยให้ AI เลือกเองว่าจะรีวิวเรื่องอะไร — อาจได้ความเห็นเรื่องการตั้งชื่อยาวสิบข้อ แต่ไม่พูดถึง secret ที่ hardcode ไว้เลยสักคำ
Good Prompt ทำสามอย่าง:

• ให้ขั้นตอนตายตัว — 4 ข้อ เรียงไว้ ข้ามไม่ได้
• บังคับให้ตอบทุกข้อ — check each item · ข้อที่ไม่มีปัญหาก็ต้องติ๊ก ✅ ทำให้คุณแยกได้ว่า “ตรวจแล้วผ่าน” กับ “ลืมตรวจ”
• กำหนดหน้าตาคำตอบ — Mark ✅ or ❌ with a short note (คาบเกี่ยวกับหลักที่ 5 ในบท 89)

เอามาใช้จริง — สั่ง Claude Code แก้ RecipeCard ในแอป Wongnok

ตัวอย่างในสไลด์เป็นงานเขียนประกาศ · จัดระดับ ticket · คิดเลข · แต่งานที่คุณจะใช้ Claude Code จริง ๆ คือแก้โค้ด — ลองเอาสามหลักมาใช้กับแอปที่เพิ่งสร้างในบท 79–85

สถานการณ์: การ์ดสูตรอาหารตอนนี้แสดงระดับความยากเป็นคำดิบ ๆ จาก type "EASY" | "MEDIUM" | "HARD" อยากให้เป็นป้าย Badge ภาษาไทยแทน
(ชื่อไฟล์ในตัวอย่างนี้คือ components/recipe/RecipeCard.tsx — ถ้าโปรเจกต์ของคุณวางไฟล์ไว้ที่อื่น ให้เปลี่ยนเป็น path จริงของคุณ)

ทำให้ level บนการ์ดสูตรอาหารดูดีขึ้นหน่อย

งาน: ใน components/recipe/RecipeCard.tsx
ตอนนี้ level แสดงเป็นคำดิบ เช่น "EASY"
ให้เปลี่ยนเป็น <Badge variant="secondary">
จาก @/components/ui/badge ที่มีอยู่แล้ว

ข้อความบนป้าย (ตัวอย่างครบทุกค่า):
- "EASY"   -> ง่าย
- "MEDIUM" -> ปานกลาง
- "HARD"   -> ยาก

ข้อห้าม:
- ห้ามแก้ไฟล์ใน components/ui/
- ห้ามติดตั้ง package ใหม่
- ห้ามเปลี่ยน type RecipeLevel

ตรวจก่อนบอกว่าเสร็จ ทำทีละข้อ:
1. npx tsc --noEmit ต้องไม่มี error
2. npx eslint . ต้องไม่มี error
3. npx next build ต้องผ่าน
4. git diff --stat ต้องมีแค่ RecipeCard.tsx
แปะ output จริงของทั้ง 4 ข้อมาให้ดู

ชำแหละ prompt ฝั่งขวาทีละส่วน — แต่ละส่วนมาจากหลักไหน:

ข้อ “วิธีตรวจ” คือส่วนที่คนมักลืมที่สุด และเป็นส่วนที่เอกสาร Claude Code ยกเป็นหัวข้อแรกของ best practices (Give Claude a way to verify its work) · เอกสารบอกว่าถ้าไม่มีสิ่งที่รันแล้วได้ผ่าน/ไม่ผ่าน คุณจะกลายเป็นคนตรวจเองทุกรอบ และแนะนำให้ขอหลักฐาน (output ของคำสั่ง) แทนคำยืนยันว่า “เสร็จแล้ว”
ตรงกับขั้น Evaluate ในบท 87 พอดี — prompt ที่ดีคือ prompt ที่ใส่ขั้น Evaluate ไว้ในตัว

เช็คลิสต์ 4 ข้อนั้นคืนผลอะไรจริง ๆ

เพื่อให้เห็นว่าคำสั่งตรวจในเช็คลิสต์ไม่ใช่พิธีกรรม ผมแก้โค้ดตามโจทย์นี้เองด้วยมือ ในโปรเจกต์ Next.js + shadcn แล้วรันทั้งสี่ข้อ
รอบแรกผมจงใจลืม HARD ไว้หนึ่งค่า — เป็นความผิดพลาดแบบที่ทั้งคนและ AI ทำได้:

const LEVEL_LABEL: Record<RecipeLevel, string> = {
  EASY: "ง่าย",
  MEDIUM: "ปานกลาง",
};

$ npx tsc --noEmit; echo "rc=$?"
components/recipe/RecipeCard.tsx(11,7): error TS2741: Property 'HARD' is missing in type '{ EASY: string; MEDIUM: string; }' but required in type 'Record<RecipeLevel, string>'.
rc=2

$ npx eslint .; echo "rc=$?"
rc=0

ข้อ 1 จับได้ · ข้อ 2 ปล่อยผ่าน — eslint ไม่ได้ตรวจ type · นี่คือเหตุผลที่เช็คลิสต์ต้องมีหลายข้อ
และ tsc จับได้เพราะใช้ Record<RecipeLevel, string> ซึ่งบังคับให้มีครบทุกค่าของ union · ถ้าเขียนเป็น object ธรรมดาไม่ใส่ type จะไม่มีอะไรฟ้องเลย (ประโยชน์ของการใช้ union แทน string อิสระ)

เติม HARD: "ยาก", แล้วรันทั้งสี่ข้ออีกรอบ:

$ npx tsc --noEmit; echo "rc=$?"
rc=0

$ npx eslint .; echo "rc=$?"
rc=0

$ npx next build
▲ Next.js 16.3.5 (Turbopack)
…
✓ Compiled successfully in 3.5s
  Running TypeScript ...
  Finished TypeScript in 641ms ...
…
Route (app)
┌ ○ /
├ ○ /_not-found
└ ○ /recipes

$ git diff --stat
 components/recipe/RecipeCard.tsx | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

(ตัวเลขใน git diff --stat ขึ้นกับหน้าตาไฟล์ก่อนแก้ — ของผมก่อนแก้เป็น <CardContent>{level}</CardContent> บรรทัดเดียว ของคุณจะได้เลขไม่ตรงกันก็ไม่แปลก ที่ต้องดูคือรายชื่อไฟล์)
ข้อ 4 คือตัวที่ตรวจข้อห้าม — ถ้ามีไฟล์ใน components/ui/ โผล่ในรายการ แปลว่ามีการแตะของที่สั่งห้ามไว้ ไม่ต้องไปไล่อ่าน diff ทีละบรรทัดก็รู้
(tsc กับ eslint ที่ผ่านจะไม่พิมพ์อะไรเลย จึงต้องต่อ echo "rc=$?" ให้เห็น exit code — 0 คือผ่าน)

app/layout.tsx(20,50): error TS2304: Cannot find name 'LayoutProps'.

งาน: เพิ่ม Empty state ในหน้า /recipes
ไฟล์: components/recipe/RecipeList.tsx
(ตัวที่ map รายการสูตรอาหารเป็น RecipeCard)

พฤติกรรมที่ต้องการ:
- ถ้า array สูตรอาหารว่าง ให้แสดงกล่องตรงกลางแทนตาราง
- ข้อความ "ยังไม่มีสูตรอาหาร" และข้อความรอง
  "เริ่มแชร์สูตรแรกของคุณได้เลย"
- ปุ่ม <Button> จาก @/components/ui/button ข้อความ "เพิ่มสูตรอาหาร"
  (ยังไม่ต้องทำให้กดแล้วไปไหน)

ตัวอย่าง:
- recipes = []          -> เห็นกล่อง Empty state, ไม่มี RecipeCard
- recipes มี 3 รายการ   -> เห็น RecipeCard 3 ใบ, ไม่มีกล่อง Empty state

ข้อห้าม:
- แก้เฉพาะ RecipeList.tsx (ถ้าจำเป็นต้องแก้ไฟล์อื่น ให้ถามก่อน)
- ห้ามแก้ไฟล์ใน components/ui/
- ห้ามติดตั้ง package ใหม่

ตรวจก่อนบอกว่าเสร็จ ทำทีละข้อ แล้วแปะ output จริง:
1. npx tsc --noEmit ไม่มี error
2. npx eslint . ไม่มี error
3. npx next build ผ่าน
4. git diff --stat มีแค่ RecipeList.tsx
5. บอกวิธีที่คุณใช้ตรวจว่าทั้งสองกรณีในหัวข้อ "ตัวอย่าง" แสดงผลถูกจริง

ลองตอบดู

ถามกลับได้เลย

ถ้าคุณมี prompt ที่เคยใช้กับ Claude Code แล้วได้ผลไม่ตรงใจ เอามาวางได้เลย — เราจะไล่ดูด้วยกันว่าขาดชิ้นไหนในตาราง ไฟล์ · พฤติกรรม · ตัวอย่าง · ข้อห้าม · วิธีตรวจ
หรือถ้าไม่แน่ใจว่างานของคุณเป็นแบบ “ไม่รู้ขั้นตอน” (หน้า 29) หรือ “รู้ขั้นตอน” (หน้า 30) เล่างานมาได้ ส่วนใหญ่เป็นแบบผสม — ขั้นหาสาเหตุไม่รู้ขั้น แต่ขั้นตรวจก่อน commit รู้ขั้นเสมอ

อ้างอิง

• Claude Docs — Prompting best practices — อ่านหัวข้อ Be clear and direct (มี Golden rule เรื่องยื่น prompt ให้เพื่อนร่วมงานอ่าน) กับ Use examples effectively (เกณฑ์ Relevant · Diverse · Structured และคำแนะนำ 3–5 ตัวอย่าง) · ลิงก์เดิม docs.claude.com/…/be-clear-and-direct และ …/multishot-prompting redirect มาที่หน้านี้
• Claude Docs — Leverage thinking & interleaved thinking capabilities — อ่านสองย่อหน้าแรก ที่อธิบายว่า Claude รุ่นใหม่ใช้ adaptive thinking คิดเองตามความยากของงาน · ใช้ประกอบกล่อง “ที่ไม่เหมือนกัน” ของหลักที่ 3 (ลิงก์เดิม …/chain-of-thought redirect มาที่หัวข้อนี้)
• Claude Code Docs — Best practices for Claude Code — อ่านหัวข้อ Give Claude a way to verify its work (ที่มาของ “วิธีตรวจ” ใน prompt แก้ RecipeCard และเรื่องขอหลักฐานแทนคำยืนยัน) กับ Provide specific context in your prompts ซึ่งมีตาราง Before/After ของงานโค้ดโดยตรง (ระบุไฟล์ · ชี้ pattern ที่มีอยู่ · บอกอาการและนิยามของคำว่า “แก้แล้ว”)
• Claude Docs — Prompt engineering overview — อ่านหัวข้อ Before prompt engineering ที่บอกให้มีเกณฑ์ความสำเร็จและวิธีทดสอบก่อนลงมือปรับ prompt (แนวคิดเดียวกับเช็คลิสต์ตรวจในบทนี้) · เป็นทางต่อไปยังหลัก 4–6 ในบท 89