10 Prompt Patterns ที่เปลี่ยน
Claude จาก "ตอบได้" เป็น "ตอบเก่ง"
</ctx>
Audience →
Goal
in → out
in → ?
then.
answer.
| table |
md: ***
"…"
NOT Y
NEVER Z
critique →
revise
QA · User
views
qn → ans
(grounded)
ในเอกสารทางการของ Anthropic เองระบุไว้ว่า — techniques ที่ effective คือ being clear and detailed, using positive and negative examples, encouraging step-by-step reasoning, requesting specific XML tags, and specifying desired length or format Anthropic Prompt Engineering Docs
บทความนี้รวม 10 pattern ที่ใช้กับ Claude ได้ทันที — ไม่ต้องเขียน API ไม่ต้องติดตั้งอะไร แค่เปลี่ยนวิธีเขียน prompt ในช่องแชท. ทุก pattern มี ตัวอย่าง Before/After ให้เทียบชัด ๆ ว่าความแตกต่างในผลลัพธ์มาจากไหน
อ่านจบแล้วเอาไปใช้ได้ทั้ง Claude Pro, Claude Code, และ API — ทุก pattern ไม่ขึ้นกับ version ของ model. ใครเริ่มจากศูนย์แนะนำ pattern #01-#05, ใคร advanced แล้วให้ข้ามไป #06-#10 ได้เลย
ห่อทุกอย่างด้วย <xml tags> — แยกคำสั่งออกจากข้อมูล
Claude ถูก train ให้ อ่าน XML tags เป็นพิเศษ — เวลาคุณห่อ context ด้วย <context>, ตัวอย่างด้วย <example>, คำสั่งด้วย <task> Claude จะแยกแยะได้ชัดว่าส่วนไหนคือข้อมูลที่ต้องอ่าน ส่วนไหนคือสิ่งที่ต้องทำ
ช่วยสรุปอีเมลนี้ให้หน่อย จาก: somchai@example.com เรื่อง: อัพเดทโปรเจกต์ สวัสดีครับ โปรเจกต์ A ล่าช้า 2 สัปดาห์ เพราะรอ approval จาก legal... และให้บอกด้วยว่าควรทำอะไรต่อ
<email> จาก: somchai@example.com เรื่อง: อัพเดทโปรเจกต์ สวัสดีครับ โปรเจกต์ A ล่าช้า 2 สัปดาห์ เพราะรอ approval จาก legal... </email> <task> 1. สรุป email ใน 3 bullets 2. แนะนำ action ถัดไป 2 ข้อ </task>
เมื่อ context ยาว (PDF, ข้อมูลลูกค้า, log files) Claude จะรู้ได้ทันทีว่าต้องปฏิบัติตามส่วน <task> และอ้างอิง <email> — ไม่ "คิดว่า" เนื้อหาใน email คือคำสั่ง
Role + Audience + Goal — บอก Claude ว่ากำลังคุยกับใคร
Claude ไม่รู้ว่าคำตอบของมันไปถึงใคร — CTO, นักศึกษา ม.ปลาย, หรือลูกค้าที่ไม่เคยใช้แอพ? การบอก "บทบาทของตัวเอง + ผู้ฟัง + เป้าหมาย" ทำให้ Claude ปรับภาษา ความลึก และโทนให้เหมาะได้ทันที
อธิบาย blockchain ให้หน่อย
# Role ฉันเป็น CTO บริษัท SaaS # Audience ผู้ฟังคือ ทีม sales (non-technical) ต้องใช้ pitch ลูกค้า enterprise # Goal ต้องการให้ทีมเข้าใจว่า blockchain เหมาะ/ไม่เหมาะ กับ use case ไหน เพื่อตอบลูกค้าได้ตรงประเด็น อธิบายภายใน 400 คำ
คำอธิบาย blockchain ที่เหมาะกับ dev ≠ ที่เหมาะกับ sales. พอ Claude รู้ 3 มิติข้างต้น มันจะเลี่ยงศัพท์เทคนิคที่ไม่จำเป็น และเน้น "เมื่อไหร่ควรขาย/ไม่ขาย" แทน "hash function ทำงานยังไง"
Few-Shot — ตัวอย่าง 3 ชิ้น ชนะคำอธิบาย 3 ย่อหน้า
คำอธิบายเป็นสิ่งที่เข้าใจยากกว่าที่คิด — "เขียนให้ friendly แต่เป็นมืออาชีพ" คุณกับ Claude อาจตีความไม่เหมือนกัน. แต่ถ้าให้ตัวอย่างที่ "ดี" ไว้ 3 ชิ้น Claude จะจับ pattern ได้ทันทีโดยไม่ต้องอธิบาย
ช่วยเขียน tweet โปรโมตบล็อกใหม่ ให้ดูเหมือนนักเขียนมืออาชีพ แต่ไม่ทางการเกินไป และต้อง ติดตะขอผู้อ่านในประโยคแรก
<examples> ตัวอย่าง 1: "ผมเสียเวลา 2 ปีเรียน React ก่อนจะรู้ว่าอันนี้ต่างหาก ที่ควรเรียนตั้งแต่แรก ↓" ตัวอย่าง 2: "10 คำถามที่ทำให้ทีม product หยุดเถียงกันได้ในประชุมเดียว" ตัวอย่าง 3: "AI จะไม่เอางานคุณไป — แต่คนที่ใช้ AI เป็นจะเอาไป" </examples> เขียน tweet ในสไตล์เดียวกัน สำหรับบล็อกเรื่อง prompt patterns
Research จาก Anthropic ระบุว่า few-shot examples คือวิธี เพิ่ม output quality ที่ได้ผลที่สุดวิธีหนึ่ง — มากกว่าเพิ่ม instructions ยาว ๆ เสียอีก. ตัวอย่าง 3 ชิ้นมักจะพอ (เกิน 5 เริ่ม diminishing return)
Think Step-by-Step — ให้ Claude คิดก่อนตอบ
สำหรับงานที่ต้องคิดหลายขั้น (คำนวณ, วิเคราะห์, วางแผน) — การขอให้ Claude "คิดออกเสียง" ก่อนให้คำตอบสุดท้าย ทำให้ accuracy ดีขึ้นอย่างมีนัยสำคัญ. นี่คือหลักการเดียวกับ Chain-of-Thought ที่ใช้ใน research จริง
ถ้าฉันทำ startup SaaS ราคา $29/เดือน ลูกค้า 120 ราย churn 5%/เดือน และได้ลูกค้าใหม่ 15/เดือน — ใน 12 เดือน ฉันจะเหลือลูกค้าเท่าไหร่?
[โจทย์เดิม] <thinking> ก่อนตอบ ให้คิดทีละขั้น: 1. คำนวณลูกค้าที่เหลือหลัง churn 2. เพิ่มลูกค้าใหม่ 3. ทำซ้ำ 12 รอบ 4. แสดง work แต่ละเดือน </thinking> <answer> หลังจากคิดเสร็จ ให้ตอบสรุป เป็นตัวเลขสุดท้าย + insight </answer>
LLM คล้ายคนตอนทำเลขในใจ — ถ้าให้ "แสดงวิธี" จะผิดน้อยกว่า "ตอบตัวเลขเลย". การแยก <thinking> กับ <answer> ยังช่วยให้คุณอ่านแค่ส่วน answer ได้ ในขณะที่ Claude ยังได้ประโยชน์จากการคิดเต็ม
Output Contract — กำหนด format ที่ต้องการ ให้เป๊ะ
ปัญหาใหญ่ของการใช้ LLM ใน automation คือ output format ไม่คงที่ — บางครั้งได้ JSON บางครั้งได้ markdown บางครั้งมี preamble พ่วงมาก่อน. วิธีแก้คือ "contract" — บอก schema ที่ต้องการให้ชัด และบอกว่าห้ามมีอะไรอื่น
วิเคราะห์รีวิวลูกค้านี้ แล้วบอกว่าเป็น positive หรือ negative และให้เหตุผล: "อาหารอร่อย แต่รอนาน บริการเฉย ๆ จะมาอีก"
วิเคราะห์รีวิว แล้วตอบเป็น JSON เท่านั้น ตาม schema นี้: { "sentiment": "positive" | "negative" | "mixed", "score": number 1-5, "aspects": { "food": number | null, "service": number | null, "wait": number | null }, "will_return": boolean } ไม่ต้องมี preamble ไม่ต้องอธิบาย ตอบเป็น JSON เดียว ไม่มี markdown Review: "อาหารอร่อย..."
Claude มี Structured Outputs API อย่างเป็นทางการแล้ว — แต่แม้ในช่องแชทธรรมดา การ spec schema ชัดเจนก็ทำให้ output ไป parse ต่อได้โดย JavaScript / Python ในขั้นตอนถัดไปแบบไม่พัง
Prompt ไม่ใช่คำถาม — มันคือ การออกแบบบริบท— Chontechhub Editorial
ยิ่งบริบทออกแบบดี คำตอบยิ่งชัด
Prefill — เริ่มประโยคให้ Claude แทน
Trick นี้คนใช้ API รู้ดีแต่น้อยคนใช้ในช่องแชท — คุณสามารถ "เริ่มคำตอบ" ให้ Claude แล้วขอให้มันเขียนต่อ. วิธีนี้ช่วยล็อค format และ tone ได้เด็ดขาดกว่าทุก instruction
สรุปข่าวนี้เป็น JSON พร้อม fields: title, date, summary, entities
สรุปข่าวเป็น JSON ตาม schema [...ข่าว...] ตอบโดยเริ่มจาก: { "title": "
LLM ตอบต่อจากสิ่งที่ "อยู่ก่อนหน้า" เสมอ — ถ้าคำตอบเริ่มด้วย { แล้ว Claude แทบเป็นไปไม่ได้ที่จะตอบด้วย prose ก่อน. เทคนิคนี้ลด "preamble noise" ได้ 95%+
assistant turn prefill ได้โดยตรงและได้ผลดีกว่า
Negative Prompting — บอก "ห้ามทำ" ให้ชัด
บางอย่างอธิบาย "สิ่งที่ต้องการ" ยาก — แต่อธิบาย "สิ่งที่ไม่ต้องการ" ง่ายกว่า. Claude ตอบสนองต่อ negative constraints ดีมาก โดยเฉพาะถ้าเขียนแบบตัวหนาหรือเน้น
เขียน product description ที่กระชับ น่าอ่าน มืออาชีพ
เขียน product description # Do - กระชับ ไม่เกิน 80 คำ - เริ่มด้วย benefit หลัก # Do NOT - ห้ามใช้คำว่า "革命ation / innovative / game-changer" - ห้ามขึ้นต้นด้วย "แนะนำให้รู้จัก..." - ห้ามใช้ emoji - ห้าม superlatives (ดีที่สุด, เร็วที่สุด, ฯลฯ) โดยไม่มี ตัวเลขรองรับ
"มืออาชีพ" เป็นคำที่ subjective — แต่ "ห้ามใช้คำว่า game-changer" เป็นคำสั่งที่ testable ได้. Negative constraints ทำให้ output มี "ลายเซ็น" ของคุณ ไม่ใช่ลายเซ็น default ของ LLM
Self-Critique Loop — ให้ Claude ตรวจงานตัวเอง
Pattern นี้ใช้หลักการ "คำตอบครั้งที่ 2 มักจะดีกว่าครั้งที่ 1". แทนที่จะ iterate โดยการส่ง feedback ไป-กลับหลายรอบ — คุณสั่งให้ Claude วิจารณ์งานของตัวเอง แล้ว revise ในคำสั่งเดียว
เขียน cover letter สำหรับ ตำแหน่ง Senior Product Manager ที่ Grab
ทำ 3 ขั้นต่อไปนี้ตามลำดับ: <step1>เขียน cover letter draft แรก สำหรับตำแหน่ง Senior PM ที่ Grab</step1> <step2>วิจารณ์ draft นั้นเอง อย่าง honest: ตรงไหนดูทั่วไป? ตรงไหนไม่มีหลักฐาน? ตรงไหน cliché?</step2> <step3>เขียนเวอร์ชันที่ 2 ที่แก้ประเด็นที่วิจารณ์ทั้งหมด</step3> แสดงผลทั้ง 3 step แต่ไฮไลท์ step 3 เป็น คำตอบสุดท้าย
Draft แรกของ LLM มักจะ "ปลอดภัย" เกินไป — Self-critique บังคับให้มัน ออกจาก local minimum และเขียนแบบกล้ากว่า. Opus 4.7 ทำ self-verification แบบนี้เป็น default อยู่แล้ว แต่บอกตรง ๆ จะชัดกว่า
Perspective Shift — ขอหลายมุมมองในเทิร์นเดียว
สำหรับการตัดสินใจที่ซับซ้อน — แทนที่จะถาม Claude ว่า "ควรทำไหม?" (แล้วได้คำตอบกลาง ๆ) ให้สั่งมันเล่น หลายบทบาทที่เห็นต่างกัน. คุณจะได้ data ครบมุมกว่าและตัดสินใจได้ดีกว่า
ฉันคิดจะ launch feature ใหม่ แบบ beta แค่ 10% ของ user ก่อน — ดีไหม?
วิเคราะห์แผน beta 10% launch จาก 4 มุมมอง ต่อไปนี้: <pm> จากมุม Product Manager: อะไรคือ metric ที่ต้องดู?</pm> <engineer> จากมุม Senior Engineer: risk ด้าน infra หรือ data integrity?</engineer> <user> จากมุม user ใน 10% นั้น: ประสบการณ์จะ เป็นยังไง ดี/แย่?</user> <ceo> จากมุม CEO ที่กังวล revenue: ผลกระทบระยะสั้น และยาวคืออะไร?</ceo> ให้แต่ละบทบาทพูดอย่างเต็มเสียง แล้วสรุปท้าย: จุดที่ทุกมุม เห็นตรงกัน และจุดที่ขัดกัน
คำตอบของ LLM เมื่อถูก "บังคับบทบาท" จะไปสุดทางของ persona นั้น — PM จะพูดเรื่อง metric, CEO จะพูดเรื่องเงิน. การเอา perspective ที่สุดโต่งมาชนกันได้ข้อสรุปที่ balance กว่าความเห็นกลาง ๆ แต่แรก
Reference Anchoring — บังคับให้ตอบจากข้อมูลที่ให้เท่านั้น
นี่คือ pattern สำคัญที่สุดสำหรับ ลด hallucination — เมื่อคุณให้ Claude เอกสาร แล้วถามคำถามจากเอกสารนั้น บอกมันชัดๆ ว่าห้ามตอบจากความรู้ทั่วไป และต้อง cite ที่มา
[แนบ PDF สัญญา] ลูกค้าจ่ายช้าได้กี่วัน?
<document> [เนื้อหาสัญญา] </document> <instructions> ตอบคำถามโดยใช้ข้อมูลจาก <document> เท่านั้น หากคำตอบไม่อยู่ในเอกสาร ให้ตอบตรง ๆ ว่า "ไม่พบข้อมูลในสัญญานี้" ห้ามเดา ห้ามใช้ความรู้ทั่วไป ทุกคำตอบต้อง quote ประโยคจากเอกสารประกอบ แบบ: "ตามข้อ X: ..." </instructions> คำถาม: ลูกค้าจ่ายช้า ได้กี่วันตามสัญญา?
กฎหมาย, การแพทย์, การเงิน — 3 domain ที่ hallucination = หายนะ. การ anchor ให้ Claude ตอบจาก source ที่เรา control ได้ เปลี่ยนมันจาก "oracle ที่เดาเก่ง" เป็น "เครื่องมือค้นเอกสารที่แม่น"
<role> ใครกำลังถาม + ใครคือผู้ฟัง </role> # Pattern 02 <context> # Pattern 01 ข้อมูลดิบทั้งหมด · PDF · code · data </context> <examples> # Pattern 03 2-3 ตัวอย่างของ "output ที่ดี" </examples> <task> # Pattern 04, 08, 09 1. คิดเป็นขั้นใน <thinking> 2. เขียน draft 3. วิจารณ์ draft 4. revise เป็น final </task> <output> # Pattern 05, 07 Format: JSON / Table / Markdown Schema: {...} Do NOT: preamble, superlatives, emoji </output> <grounding> # Pattern 10 ตอบจาก <context> เท่านั้น ไม่พบ → ตอบว่า "ไม่พบ" </grounding> # แล้วปิดด้วย prefill เริ่มคำตอบให้ # Pattern 06 ตอบโดยเริ่มจาก: {
10 patterns นี้ไม่ใช่ "magic spells" — มันคือการลดช่องว่างระหว่างหัวคุณกับหัว Claude
ทุก pattern ข้างต้นใช้หลักการเดียวกัน: ยิ่งระบุบริบท สคีมา และข้อจำกัด ชัดเท่าไหร่ Claude ยิ่งตอบตรงเท่านั้น. "prompt engineering" ในความหมายที่ใช้งานได้จริง ไม่ใช่ศาสตร์ลับของคนเก่ง — มันคือนิสัยของการ เขียนให้คนอ่านเข้าใจ ซึ่งคุณก็ฝึกมาตั้งแต่เขียน email แล้ว
ถ้าจะเริ่มจาก pattern เดียว — เริ่มที่ #01 XML Tags และ #05 Output Contract. 2 ตัวนี้จะยกระดับ Claude สำหรับเกือบทุก use case โดยไม่ต้องเปลี่ยนอะไรในวิธีคิดคุณมาก
อย่างที่ Anthropic เขียนไว้ในเอกสาร prompt engineering ของตัวเอง — "being clear and detailed" เป็นคำที่สั้น แต่ยากที่สุดที่จะทำจริง. 10 patterns ข้างต้นคือเครื่องมือที่ช่วยให้การ "ชัดเจน" เกิดขึ้นได้แบบ systematic ไม่ใช่โชคช่วย
คำตอบที่ดีของ Claude — ไม่ได้เริ่มจาก Claude มันเริ่มจากคุณ.
References
-
Prompt Engineering Overview — Anthropic Documentation docs.claude.com
-
Use XML tags to structure your prompts Anthropic Docs
-
Let Claude think (chain of thought prompting) Anthropic Docs
-
Prefill Claude's response for greater output control Anthropic Docs
-
Structured Outputs — API Guide Anthropic Platform Docs
-
Giving Claude a role with a system prompt Anthropic Docs