prompt ที่ดี (2) — บทบาทและหัวข้อ · กำหนดรูปแบบผลลัพธ์ · แก้ทีละรอบ

Next.js     v16.3.5     # npx next --version
TypeScript  5.9.3       # npx tsc --version
ESLint      v9.39.5     # npx eslint --version
node        v24.14.0
git         2.51.0

หลักข้อ 4–6 อยู่ตรงไหนของภาพใหญ่

สไลด์หน้า 20 (“Become a good prompt”) วางหลักไว้ 6 ช่อง บทที่แล้วเก็บแถวบนไปแล้ว บทนี้คือแถวล่าง:

ถ้าแถวบนคือ “เนื้อหาที่ต้องใส่ใน prompt” แถวล่างก็คือ “จัดวางเนื้อหานั้นยังไง · รับผลกลับมาหน้าตาแบบไหน · และทำอะไรต่อเมื่อผลยังไม่ตรง”

หลักข้อ 4 (ครึ่งแรก) — บอกบทบาทให้ AI

สไลด์หน้า 32 มีข้อความสองบรรทัด:

• Assigning a role also helps AI assume that role
• Set headers to separate section with XML or Markdown

พูดเป็นภาษาคน: ประโยคแรกของ prompt บอกว่า “คุณคือใคร” เช่น “You are an experienced instructional designer.”
ประโยคเดียวนี้เปลี่ยนหลายอย่างพร้อมกัน — AI จะหยิบศัพท์ของอาชีพนั้นมาใช้ · สนใจเรื่องที่คนอาชีพนั้นสนใจ · และตัดเรื่องที่คนอาชีพนั้นไม่สนออกไป
ถ้าไม่บอก AI จะตอบแบบ “คนทั่วไปที่รู้กว้าง ๆ” ซึ่งมักจะกลาง ๆ ไม่ลึกด้านไหนเลย

ภาพด้านขวาของสไลด์หน้า 32 เทียบสามช่อง: ช่องซ้าย NO ROLE OR STRUCTURE เป็นโน้ตสั่งงานกระจัดกระจาย (“Write a logo concept” · “Make it modern” · “Use blue colors?” · “Keep it simple!!!”) จนงานที่ได้ออกมาไม่เข้าชุดกัน · ช่องกลาง ORGANIZED PROMPT จัดเป็นกรอบ 5 ช่องเรียงจากบนลงล่าง · ช่องขวาคืองานออกแบบที่ได้เป็นชุดเดียวกัน · กรอบ 5 ช่องตรงกลางถอดได้แบบนี้:

สังเกตว่าโน้ตกระจัดกระจายในช่องซ้ายกับกรอบ 5 ช่องตรงกลาง มีข้อมูลพอ ๆ กัน — “ทำให้ดูทันสมัย” กับ “Modern, clean, minimal” คือเรื่องเดียวกัน
ที่ต่างคือข้อมูลถูกจัดลงช่อง: อะไรคือบริบท · อะไรคืองาน · อะไรคือข้อห้าม · AI ไม่ต้องเดาว่าประโยคไหนเป็นคำสั่ง ประโยคไหนเป็นแค่ข้อมูลประกอบ

หลักข้อ 4 (ครึ่งหลัง) — แบ่งหัวข้อด้วย XML

สไลด์หน้า 33 ให้ prompt สองแบบมาเทียบ (ถอดตามจริงทุกตัวอักษร):

Review this outline it's for a python course tell me whats wrong: Python basics, Functions, Build a full web app

You are an experienced instructional designer.

<task>Review the course outline for gaps and pacing issues.</task>

<outline>
  Module 1: Python basics
  Module 2: Functions
  Module 3: Build a full web app
</outline>

Return your top 3 concerns.

ต่างกันสี่จุด ไล่ทีละบรรทัด:

หลักข้อ 4 (อีกทาง) — แบ่งหัวข้อด้วย Markdown

สไลด์หน้า 34 ใช้ Bad Prompt ตัวเดิมเป๊ะ แต่ Good Prompt เปลี่ยนมาใช้หัวข้อ Markdown:

Review this outline it's for a python course tell me whats wrong: Python basics, Functions, Build a full web app

# Role
You are an experienced instructional designer.

# Task
Review the course outline below for gaps and pacing issues.

# Outline
- Module 1: Python basics
- Module 2: Functions
- Module 3: Build a full web app

# Output
Return your top 3 concerns as a numbered list.

หน้า 33:  Review the course outline       for gaps and pacing issues.
หน้า 34:  Review the course outline below for gaps and pacing issues.

หน้า 33:  Return your top 3 concerns.
หน้า 34:  Return your top 3 concerns as a numbered list.

XML หรือ Markdown — เลือกเมื่อไหร่

สไลด์บอกแค่ว่า “with XML or Markdown” ไม่ได้บอกว่าเลือกยังไง · ตารางนี้รวมจากเอกสารของ Anthropic (สองแถวที่มีป้าย 📄) กับเหตุผลเชิงปฏิบัติ (แถวที่เหลือ):

หลักข้อ 5 — บอกรูปแบบผลลัพธ์ที่ต้องการ

สไลด์หน้า 36 (“Why Specify?”) ให้เหตุผลไว้สองบรรทัด:

• Saves you from re-prompting to reshape the result structure.
  • Normally, the result doesn't come in the formatting you want

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

ภาพในหน้า 36 ใช้คำขอเดียว — “Give me a report on remote work best practices.” — แล้วโชว์ว่าถ้าไม่ระบุรูปแบบ อาจได้กลับมาได้ทั้งบทความยาวเกิน (Too long!) · ย่อหน้าเดียวสั้นเกิน (Too short!) · รายงานหนาเกิน (Way too much!) · bullet ที่หัวข้อไม่เข้ากัน (Not what I expected!) · หรือเลย์เอาต์ผิดแบบ (Wrong format!)
ช่องกลางคือ FORMAT SPECIFICATION ที่แจกแจงออกมาเป็น 6 เรื่อง:

แล้วสไลด์หน้า 37 ย่อทั้งหมดนั้นให้เหลือประโยคเดียว:

Give me some marketing channel ideas.

List 5 marketing channels in a table with columns: Channel, Best for, Est. cost (Low/Med/High). One line per channel.

Good Prompt ประโยคเดียวนี้ล็อกไว้ 5 อย่าง เทียบกับ 6 เรื่องในหน้า 36:

จุดที่คนมองข้ามคือ (Low/Med/High) — มันไม่ได้แค่บอกรูปแบบ แต่จำกัดคำตอบให้เหลือแค่สามค่า ซึ่งทำให้เรียงหรือกรองต่อได้ทันที เหมือน union type "EASY" | "MEDIUM" | "HARD" ที่คุณเขียนให้ level ของสูตรอาหารในแอป Wongnok

ใช้กับ Claude Code: บอกว่าจะให้รายงานผลกลับมายังไง

ตอนสั่ง Claude Code แก้โค้ด ผลลัพธ์หลักคือไฟล์ที่ถูกแก้ · แต่ยังมีผลลัพธ์รองคือข้อความสรุปตอนจบงาน ซึ่งถ้าไม่บอก ก็จะได้ความยาวและหน้าตาที่เดาไม่ได้เหมือนภาพหน้า 36
ตัวอย่างของบทนี้ — ท่อนท้าย prompt ที่บอกรูปแบบรายงาน:

# ตัวอย่างของบทนี้ (ไม่ได้มาจากสไลด์)
# Output
When you finish, reply with exactly these 3 sections:
1. Files changed — one line per file: path + what changed
2. Checks — the result of tsc, eslint, and next build (pass/fail)
3. Open questions — anything you assumed; write "none" if nothing

ถ้ารายงานนั้นจะถูกสคริปต์อ่านต่อ (ไม่ใช่คนอ่าน) ให้ขอเป็น JSON แล้ววางโครงให้ดู · โครงข้างล่างผ่าน JSON.parse จริง:

$ node -e 'const o = JSON.parse(`…โครงข้างล่าง…`); console.log("valid JSON, keys:", Object.keys(o).join(", "))'
{
  "summary": "Added name search and an empty state to RecipeList",
  "filesChanged": ["containers/RecipeList/RecipeList.tsx"],
  "checks": { "tsc": "pass", "eslint": "pass", "build": "pass" },
  "openQuestions": []
}
# output จริง:
valid JSON, keys: summary, filesChanged, checks, openQuestions

{ "checks": { "tsc": "pass", }, }

$ node -e 'try { JSON.parse(`{ "checks": { "tsc": "pass", }, }`) } catch (e) { console.log(e.name + ": " + e.message) }'
SyntaxError: Expected double-quoted property name in JSON at position 29 (line 1 column 30)

หลักข้อ 6 — แก้ทีละรอบ ถือว่าคำตอบแรกคือร่าง

สไลด์หน้า 39 (“Iterate What?”) มีประโยคหลักหนึ่งประโยค กับคำเตือนหนึ่งกล่อง:

• Treat the first output as a draft. Tell the model what to fix

⚠️ Warning:
Prompting is a conversation, not a one-shot.

ภาพในหน้า 39 เป็นวงจร 6 ขั้นที่วนจนกว่าจะได้ผลที่ต้องการ (Repeat Until Desired Outcome):

ด้านซ้ายของภาพเป็น prompt รอบแรกที่กว้างมาก — Write about productivity for my audience. — ตามด้วยคำตอบที่สไลด์วาดไว้ว่าจืดและทั่วไป · ด้านขวาคือ prompt รอบที่ปรับแล้ว:

# สไลด์หน้า 39 · IMPROVED PROMPT
Write a friendly, practical guide on productivity for remote workers. Include key strategies, examples, and a short checklist. Use clear headings and bullets. Keep it under 500 words.

แถบล่างของภาพ (FEEDBACK THAT DRIVES IMPROVEMENT) คือสูตรแปลง “อาการ” เป็น “สิ่งที่ต้องบอก” — ตารางนี้ถอดจากภาพ แล้วผมเติมคอลัมน์ขวาว่าในงานโค้ดหน้าตาเป็นยังไง
(ภาพเดียวกันยังมีกล่อง REVIEW: WHAT'S NOT WORKING? ใต้คำตอบรอบแรก ที่ไล่อาการไว้ห้าข้อ: Missing requirements · Wrong tone · Incomplete information · Formatting problems · Unclear output — คือขั้น ③ Review กับ ④ Identify Issues ของวงจรข้างบนนั่นเอง)

แล้วสไลด์หน้า 40 เทียบให้เห็นว่า “แก้ทีละรอบ” ต่างจาก “เริ่มใหม่” ยังไง:

(first output is too formal) → start over with a brand-new prompt.

Good draft, but too formal. Rewrite it warmer, cut the jargon, and shorten the intro to one sentence.

Good Prompt ของหน้า 40 สั้นมาก แต่มีสามส่วนที่ครบ:

• Good draft, — บอกว่าส่วนไหนใช้ได้แล้ว AI จะได้ไม่รื้อของที่ดีทิ้ง
• but too formal. — บอกอาการ (ตรงกับแถว Too formal ในตารางข้างบนพอดี)
• Rewrite it warmer, cut the jargon, and shorten the intro to one sentence. — บอกวิธีแก้เป็นข้อ ๆ ที่ตรวจได้ · โดยเฉพาะ “one sentence” ที่นับได้ ไม่ต้องตีความ

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

รอบแก้ในงานโค้ด — เอา error จริงไปเป็น feedback

ในงานเขียนบทความ “อาการ” คือความรู้สึกของคนอ่าน · ในงานโค้ด อาการที่ดีที่สุดคือข้อความ error จริงจากขั้น Evaluate เพราะมันบอกไฟล์ บรรทัด และสาเหตุมาครบ
ข้างล่างนี้ผมเขียน RecipeList.tsx ในโปรเจกต์ทดลองโดยตั้งใจเรียก recipe.title ทั้งที่ type Recipe มีแต่ name แล้วรัน tsc จริง:

$ npx tsc --noEmit; echo "rc=$?"
containers/RecipeList/RecipeList.tsx(11,12): error TS2339: Property 'title' does not exist on type 'Recipe'.
rc=2

ข้อความรอบถัดไปที่ดีจะหน้าตาประมาณนี้ (ตัวอย่างของบทนี้):

tsc fails with the error below. Fix it by using the existing `name` field —
do not add a `title` field to the Recipe type. Then re-run tsc and eslint.

<tsc_output>
containers/RecipeList/RecipeList.tsx(11,12): error TS2339: Property 'title' does not exist on type 'Recipe'.
</tsc_output>

สังเกตว่าข้อความสั้นนี้ใช้หลักครบสามข้อของบทนี้: แปะ error ไว้ในแท็ก XML (④) · บอกทางแก้ที่ไม่ต้องการ (“do not add a title field”) เพราะมีสองทางที่ทำให้ error หาย แต่ถูกแค่ทางเดียว · และบอกว่าจบรอบแล้วต้องทำอะไร (⑤ + ⑥)

ภารกิจ — เขียน prompt สั่งงานจริงบนแอป Wongnok

ภาพหน้า All Recipes ในสไลด์ของกลุ่ม Next.js app มีช่อง Search recipes by name และแถบสลับ STATE สี่แบบ (Default · Loading · Empty · Error) · แต่ container RecipeList ที่คุณประกอบในบท 85 (ถอดจากสไลด์หน้า 49) ยังแค่ .map() ข้อมูล mock ออกมาทั้ง 8 สูตร — ยังไม่มีช่องค้นหา และยังไม่มี empty state ที่ผูกกับผลการค้นหา

add search to recipes page

# Role
You are a senior Next.js engineer who follows existing project conventions strictly.

# Context
- Next.js App Router project "Wongnok", TypeScript, Tailwind, shadcn/ui.
- `app/recipes/page.tsx` renders `RecipeList` from `containers/RecipeList/RecipeList.tsx`
  (a "use client" component), which maps over `RECIPES_MOCK_DATA` from `./recipes`
  and renders `RecipeCard` from `@/components/RecipeCard`.
- Convention: `components/` = pure presentational, `containers/` = stateful composition.

# Task
Add a "search by recipe name" input and an empty state to the All Recipes page.

# Requirements
- Filter while typing. Case-insensitive. Trim spaces before matching.
- Match on `name` only.
- Empty input shows all recipes.
- No match shows: No recipes match your search
- Keep `RecipeCard` presentational — put state and filtering in `RecipeList`.
- Do not change `RECIPES_MOCK_DATA`, `RecipeCard`'s props, or any other page.

# Examples
<examples>
input: ""            → all 8 recipes
input: "beef"        → only "Beef Wellington"
input: "  BEEF "     → same as "beef"
input: "pizza"       → empty state: No recipes match your search
</examples>

# Steps
1. Explore: read RecipeList.tsx, recipes.ts, RecipeCard, and app/recipes/page.tsx. Do not edit anything yet.
2. Plan: think step by step, then show me which files you will change, and why,
   plus any edge case you see. STOP and wait for my approval.
3. Code: implement only the approved plan.
4. Evaluate: run `npx tsc --noEmit`, `npx eslint .`, `npx next build`, and fix any failure.
   Then re-check every item in Requirements and Examples, one by one.
5. Commit: only after step 4 fully passes, commit with a clear conventional message.

# Output
When done, reply with exactly 3 sections:
1. Files changed — one line per file
2. Checks — tsc / eslint / build: pass or fail
3. Requirements — each requirement with ✅ or ❌

Good plan, but two changes before you code:
1. Keep the state in RecipeList, not page.tsx — page.tsx must stay a Server Component.
2. Do not add a prop to RecipeCard. Filtering happens before rendering the cards.
Show me the updated plan, then wait again.

$ npx tsc --noEmit; echo "rc=$?"
containers/RecipeList/RecipeList.tsx(11,12): error TS2339: Property 'title' does not exist on type 'Recipe'.
rc=2

# ↑ ขั้น Evaluate เจอ failure → วนกลับไปขั้น Code (สไลด์หน้า 17) · แก้ title เป็น name แล้วรันใหม่

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

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

$ npx next build
Route (app)
┌ ○ /
├ ○ /_not-found
└ ○ /recipes

○  (Static)  prerendered as static content

$ node probe.mjs
""         -> 8
"beef"     -> 1 Beef Wellington
"  BEEF "  -> 1 Beef Wellington
"pizza"    -> 0

$ git add -A && git diff --cached --stat
 containers/RecipeList/RecipeList.tsx | 35 ++++++++++++++++++++++++++---------
 1 file changed, 26 insertions(+), 9 deletions(-)

$ git commit -m "feat(recipes): add name search with empty state to recipe list"
$ git log --oneline -1
5486fd0 feat(recipes): add name search with empty state to recipe list

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

Recap ทั้งกลุ่ม — บท 86 ถึง 89

Workflow 5 ขั้น (สไลด์หน้า 14–18)

หลัก prompt 6 ข้อ (สไลด์หน้า 20)

สองตารางนี้เชื่อมกันยังไง

ถ้าจำได้อย่างเดียวจากกลุ่มนี้ ให้จำว่า workflow 5 ขั้นคือ “ลำดับของงาน” ส่วนหลัก 6 ข้อคือ “วิธีพูดในแต่ละขั้น” — prompt ที่ดีแต่ข้าม Evaluate ก็ยังได้โค้ดที่ดูถูกแต่ไม่ได้ตรวจ · workflow ครบแต่ prompt กำกวม ก็ได้แผนที่รีวิวไม่ได้

ลองตอบดู

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

เอา prompt ที่คุณเขียนในภารกิจมาคุยได้เลย โดยเฉพาะถ้า:
• คุณไม่แน่ใจว่าบรรทัดไหนควรเป็น Requirement บรรทัดไหนควรเป็น Constraint ·
• คุณใช้ prompt นั้นกับ Claude Code จริงแล้ว ได้แผนหรือโค้ดที่ไม่ตรง แล้วอยากรู้ว่าควรพิมพ์รอบที่สองว่าอะไร — เอาทั้ง prompt · แผนที่ได้ · และ output ของ tsc / eslint / next build มาทั้งก้อน
นี่คือบทสุดท้ายของเว็บในตอนนี้ · ถ้ามีเรื่องไหนตลอด 89 บทที่ยังค้างในหัว ถามกลับมาได้เหมือนกัน

อ้างอิง

• Anthropic — Prompting best practices · Structure prompts with XML tags — อ่านหัวข้อ Structure prompts with XML tags (ลิงก์นี้พาไปที่หัวข้อนั้นในหน้า Prompting best practices ให้เอง) · ใช้ยืนยันแถวในตาราง XML vs Markdown ว่า XML ช่วยแยก instructions · context · examples · inputs และแนะนำให้ตั้งชื่อแท็กให้สื่อความหมายและสม่ำเสมอ
• Anthropic — Prompting best practices · Give Claude a role — อ่านหัวข้อ Give Claude a role ซึ่งอยู่ถัดลงมาจากหัวข้อ XML · สั้นมาก ประเด็นคือบทบาทแค่ประโยคเดียวก็เปลี่ยนพฤติกรรมและน้ำเสียงได้ · แล้วเลื่อนลงไปอ่าน Control the format of responses ในส่วน Output and formatting ซึ่งเป็นที่มาของแถว “รูปแบบของ prompt มีผลต่อรูปแบบของคำตอบ”
• Claude Code — Best practices — อ่านสามหัวข้อ: Explore first, then plan, then code (ตรงกับ workflow บท 86–87 และบอกว่างานแบบไหนข้ามการวางแผนได้) · Course-correct early and often (ที่มาของกฎ “แก้เกินสองรอบให้ /clear” และคำสั่ง Esc · /rewind) · Avoid common failure patterns (โดยเฉพาะ The trust-then-verify gap ซึ่งคือเหตุผลที่ขั้น Evaluate ห้ามข้าม)
• Anthropic — Prompt engineering overview — หน้าแรกของหมวด prompt engineering · อ่านเมื่ออยากรู้ว่ามีเทคนิคอะไรอีกนอกจาก 6 ข้อในสไลด์ และควรลองเทคนิคไหนก่อนหลัง