Prompt ที่ใช้งานได้จริง

บทที่แล้วคุณยิง Messages API ดิบเห็นทุก byte ทั้ง field system ที่ระดับบนสุด และ messages ที่ใส่ turn ของผู้ใช้ บทนี้ตอบคำถามที่ตามมาทันที: จะ เขียนอะไร ลงในสองช่องนั้นให้ model ทำงานได้อย่างที่ตั้งใจ คนที่เพิ่งเริ่มมักคิดว่า Prompt Engineering คือการหาถ้อยคำวิเศษหรือคาถาลับ — มันไม่ใช่เลย prompt ที่เชื่อถือได้มาจาก โครงสร้าง ไม่ใช่ความฉลาดของสำนวน คุณจะได้เห็นสี่เทคนิคที่ยกผลลัพธ์จากเดาสุ่มเป็นเสถียร แล้วประกอบมันเข้าเป็น system prompt ของ agent support Order ที่คอร์สนี้จะใช้ยาวไปจนถึง capstone

📦 code ตัวอย่าง

คอร์สนี้ค่อยๆ ประกอบ agent สำหรับ support ลูกค้าบน domain Order ของบริการฟู้ดเดลิเวอรี จาก repo kaen-food-ordering (กำลังจัดทำ) เป็นตัวอย่างเดินเรื่องตลอดคอร์ส — system prompt (persona บวกกฎคืนเงิน) ที่เราสร้างในบทนี้คือชิ้นเดียวกับที่บทที่ 8 หยิบไปใช้ประกอบ agent ตัวเต็ม

กฎทองข้อเดียวที่ต้องจำก่อน

ก่อนเทคนิคใดๆ Anthropic ให้เกณฑ์วัดที่ใช้ได้เสมอ: “Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they’d be confused, Claude will be too.” — เอา prompt ไปให้เพื่อนร่วมงานที่แทบไม่รู้บริบทของงานลองทำตาม ถ้าเขางง model ก็งงเหมือนกัน กรอบความคิดที่ควรถือคือ “Think of Claude as a brilliant but new employee who lacks context on your norms and workflows.” — มอง model เป็นพนักงานใหม่ที่เก่งมาก แต่ยังไม่รู้ธรรมเนียมและขั้นตอนภายในของทีมคุณเลย

จุดที่วิศวกร C# ต้องปรับความคิด: นี่ไม่ใช่การเรียก method ที่ signature บังคับ input ให้ถูกต้อง model จะเติมช่องว่างที่คุณไม่ได้บอกด้วยการเดา งานของ prompt คือปิดช่องว่างนั้นด้วยบริบทและโครงสร้าง ไม่ใช่ด้วยคำสั่งที่ดังขึ้น

เทคนิคที่หนึ่ง — บอกให้ชัด และให้เหตุผลกำกับกฎ

model ไม่รู้สิ่งที่คุณไม่ได้เขียน ถ้าคุณกำกวม มันจะเลือกทางเอง เอกสารยกตัวอย่างที่ชัด: ถ้าคุณเขียนว่า “‘can you suggest some changes,’ Claude will sometimes provide suggestions rather than implementing them.” — ขอแบบเปิดช่องให้ตีความว่า “แค่แนะนำ” ก็ได้ model ก็จะแค่แนะนำ ไม่ลงมือทำจริง สำหรับ agent ที่ต้อง ลงมือ เรียก tool ประเด็นนี้สำคัญมาก และเราจะย้ำมันอีกครั้งในบทที่ 4 ตอนสั่งให้ model เรียก code C#

ที่ทรงพลังกว่าการสั่งเปล่าๆ คือการบอก เหตุผล เบื้องหลังกฎ Anthropic ระบุว่า “Providing context or motivation behind your instructions… can help Claude better understand your goals” และ “Claude is smart enough to generalize from the explanation.” — model ฉลาดพอจะ generalize จากคำอธิบายไปยังเคสที่คุณไม่ได้ list ไว้ แปลว่ากฎคืนเงินของเราไม่ควรเป็นแค่ตัวเลขเปล่าๆ แต่ควรมีเหตุผลติดไปด้วย เทียบสองแบบ:

❌ version ดิบ — กฎเปล่า ไม่มีเหตุผล
คืนเงินได้ถ้ายอดไม่เกิน 500 บาท

✅ version มีเหตุผลกำกับ
คืนเงินอัตโนมัติได้ถ้ายอดไม่เกิน 500 บาท เพราะเป็นเพดานที่ทีมยอมรับ
ความเสี่ยงได้โดยไม่ต้องให้คนอนุมัติ ยอดที่สูงกว่านี้ต้องส่งต่อให้
เจ้าหน้าที่ตรวจก่อน เพื่อกันการคืนเงินผิดพลาดจำนวนมาก

version ล่างช่วยให้ model รับมือเคสที่คุณไม่ได้เขียนไว้ตรงๆ ได้ เช่น “ยอด 500 พอดี” หรือ “ออเดอร์ที่น่าสงสัยว่าเป็นการฉ้อโกง” เพราะมันเข้าใจ เจตนา ของเพดาน ไม่ใช่แค่ท่องตัวเลข

เทคนิคที่สอง — ยกตัวอย่าง (few-shot)

การใส่ตัวอย่างของ input กับ output ที่ต้องการลงไปใน prompt เรียกว่า Few-shot และเอกสารบอกตรงๆ ว่า “Examples are one of the most reliable ways to steer Claude’s output format, tone, and structure.” — เป็นวิธีที่เชื่อถือได้ที่สุดวิธีหนึ่งในการคุมรูปแบบ น้ำเสียง และโครงสร้างของคำตอบ อธิบายเป็นย่อหน้ายาวสิบบรรทัดว่าอยากได้โทนไหน สู้ยกตัวอย่างสามอันให้ดูไม่ได้

เกณฑ์ของตัวอย่างที่ดีมีสามข้อ — Relevant / Diverse / Structured คือตรงกับงานจริง ครอบคลุมหลายสถานการณ์ (ไม่ใช่เคสง่ายซ้ำๆ) และห่อไว้ในโครงสร้างชัดเจน และปริมาณที่แนะนำคือ “Include 3–5 examples for best results.” ตัวอย่างสำหรับ agent support ของเรา (ในบทนี้ขอยกมาสองอันพอเพื่อประหยัดพื้นที่ แม้เป้าจริงคือ 3–5) ห่อแต่ละอันด้วยแท็ก <example>:

<example>
ลูกค้า: อาหารมาช้ากว่าที่แจ้งไปเกินหนึ่งชั่วโมง
ตอบ: ขอโทษด้วยจริง ๆ ครับ ผมขอตรวจสถานะออเดอร์ให้ก่อนนะครับ
      แล้วจะดูแนวทางชดเชยที่เหมาะสมให้
</example>

<example>
ลูกค้า: ขอคืนเงินออเดอร์ ORD-1042 หน่อย ได้ของไม่ครบ
ตอบ: รับทราบครับ ผมขอเช็กรายละเอียดออเดอร์ ORD-1042 ก่อน
      ถ้ายอดอยู่ในเกณฑ์ที่คืนได้ทันที ผมจะดำเนินการให้เลยครับ
</example>

สองตัวอย่างนี้ แสดง โทนที่สุภาพ การเช็กข้อมูลก่อนตัดสิน และการอ้างกฎคืนเงิน โดยไม่ต้องบรรยายเป็นคำสั่งยาวๆ model จะเลียนโครงสร้างนี้กับเคสใหม่ที่ไม่เคยเห็น

เทคนิคที่สาม — ห่อส่วนต่างๆ ด้วย XML tag

พอ prompt เริ่มมีหลายส่วน — คำสั่ง ตัวอย่าง ข้อมูลออเดอร์ กฎ — model ต้องแยกออกว่าตรงไหนคืออะไร Anthropic แนะนำ XML tag: “XML tags help Claude parse complex prompts unambiguously… Wrapping each type of content in its own tag… reduces misinterpretation.” — ห่อเนื้อหาแต่ละชนิดไว้ในแท็กของตัวเอง ลดโอกาสที่ model จะเข้าใจผิดว่าส่วนไหนเป็นส่วนไหน

มองแบบวิศวกร มันคือการให้ schema เบาๆ กับข้อความ prompt — เหมือนคุณ deserialize JSON ได้ง่ายกว่าการ regex string ก้อนเดียว model ก็อ้างอิง <rules> หรือ <order_data> ได้ตรงกว่าการเดาจากย่อหน้าปนกัน แท็กจะใช้ชื่ออะไรก็ได้ ขอแค่เปิด-ปิดให้ครบและตั้งชื่อให้สื่อความ

เทคนิคที่สี่ — ตั้งบทบาทผ่าน system prompt

เทคนิคสุดท้ายคือหัวใจของบทนี้ System Prompt คือช่องที่คุณกำหนด บทบาท ให้ model ก่อนบทสนทนาจะเริ่ม และมันได้ผลจริง: “Setting a role in the system prompt focuses Claude’s behavior and tone for your use case. Even a single sentence makes a difference.” — แค่ประโยคเดียวก็เปลี่ยนพฤติกรรมและน้ำเสียงได้แล้ว เอกสารยกตัวอย่างพื้นฐานว่า System = "You are a helpful coding assistant specializing in Python." — สำหรับคอร์สนี้เราเปลี่ยนเป็นบทบาทเจ้าหน้าที่ support ฟู้ดเดลิเวอรี

จำจากบทที่ 2 ได้ว่าในการเรียกดิบ system เป็น field ที่ระดับบนสุดของ request ไม่ใช่ message ที่มี role: "system" เราเอาสี่เทคนิคข้างบนมารวมกันเป็น string ก้อนเดียวที่จะไปอยู่ใน field นั้น:

// system prompt ของ agent support — ไปอยู่ใน field system ที่ระดับบนสุด
// ของ request ดิบจากบทที่ 2 (ไม่ใช่ message ที่มี role: "system")
var systemPrompt = """
    You are a customer-support agent for a food-delivery service.
    Be warm, concise, and always look up real data before acting.

    <rules>
    - คืนเงินอัตโนมัติได้ถ้ายอดไม่เกิน 500 บาท เพราะเป็นเพดานที่ทีมยอมรับ
      ความเสี่ยงได้โดยไม่ต้องให้คนอนุมัติ ยอดที่สูงกว่านี้ต้องส่งต่อ
      ให้เจ้าหน้าที่ตรวจก่อน เพื่อกันการคืนเงินผิดพลาดจำนวนมาก
    - ตรวจสถานะออเดอร์จริงก่อนเสมอ ห้ามเดาจากความจำ
    - ถ้าไม่มีข้อมูลพอ ให้ถามลูกค้ากลับ อย่าแต่งข้อมูลออเดอร์ขึ้นเอง
    </rules>
    """;

var body = new {
    model = "claude-opus-4-8",   // ตัวอย่าง ณ 2026-07 — id ของ model เลื่อนตามเวลา
    max_tokens = 1024,
    system = systemPrompt,       // ← persona บวกกฎ อยู่ตรงนี้ ไม่มี temperature
    messages = new[] {
        new { role = "user", content = "ขอคืนเงินออเดอร์ ORD-1042 หน่อยครับ" }
    }
};

สังเกตว่ายังคงกติกาเดิมจากบทที่ 2 ครบ — header จริงคือ x-api-key และ anthropic-version: 2023-06-01 (ใน code ตั้งค่าตอนสร้าง HttpClient) และ ไม่มี temperature ในตัว body เลย เราคุมพฤติกรรมของ model ผ่านถ้อยคำใน system prompt ล้วนๆ นี่คือความหมายที่แท้จริงของ “กำกับผ่าน prompt แทน temperature” ที่ปักไว้ตั้งแต่บทแรก

2 surface ของคำว่า message ใน C# — อย่าปนกัน

system prompt ก้อนนี้อยู่ใน field system ของ request ดิบ (บทที่ 2–4) แต่พอถึงบทที่ 5 เราจะเขียนการเรียกเดิมด้วยสำนวน .NET ผ่าน IChatClient ของ Microsoft.Extensions.AI — ตรงนั้น system prompt เดิมนี้จะถูกแปลงร่างเป็น message ที่มี role เป็น ChatRole.System (คือ new ChatMessage(ChatRole.System, systemPrompt)) ไม่ใช่ field ที่ระดับบนสุดอีกต่อไป เนื้อหาเหมือนเดิมเป๊ะ แค่คนละ API — จำไว้ว่าเป็นคนละ surface กัน จะได้ไม่เอา shape ของ2 API มาปนกันตอนเขียนจริง

หยุดตะโกน CRITICAL / MUST

ข้อสุดท้ายที่คนเพิ่งเริ่มต้องได้ยิน คือนิสัยเก่าที่ควรเลิก เอกสารตัวอย่างจากยุคก่อนชอบเน้นด้วยคำสั่งตัวใหญ่ๆ ว่า CRITICAL: You MUST... แต่กับ model รุ่นปัจจุบัน Anthropic แนะนำตรงข้าม: “Where you might have said ‘CRITICAL: You MUST use this tool when…’, you can use more normal prompting like ‘Use this tool when…’.” — เขียนแบบปกติธรรมดาก็พอ ไม่ต้องตะโกน

เหตุผลเชื่อมกับกฎทองต้นบท: model รุ่นใหม่ทำตามคำสั่งที่เขียนชัดเจนได้ดีอยู่แล้ว การอัดตัวพิมพ์ใหญ่กับเครื่องหมายอัศเจรีย์ไม่ได้เพิ่มความเชื่อฟัง มีแต่ทำให้ prompt อ่านยากและดูแลยากขึ้น ความชัดมาจากโครงสร้างและเหตุผล ไม่ใช่จากระดับเสียง

flowchart TB
  subgraph VAGUE["prompt กำกวม ไม่มีโครงสร้าง"]
    V1["ช่วยจัดการคำขอคืนเงินหน่อย"] --> V2["model เดาเอง"]
    V2 --> V3["ตอบไม่นิ่ง<br/>เดายอด ข้ามการเช็ก โทนหลุด"]
  end
  subgraph SOLID["system prompt มีโครงสร้าง"]
    S1["บทบาท บวกกฎมีเหตุผล"] --> S4["model มีกรอบ"]
    S2["ตัวอย่าง few-shot"] --> S4
    S3["ห่อด้วย XML tag"] --> S4
    S4 --> S5["ตอบเสถียร<br/>เช็กก่อน อ้างกฎ โทนคงเส้น"]
  end
  classDef bad fill:#dc2626,stroke:#7f1d1d,color:#f8fafc;
  classDef good fill:#16a34a,stroke:#065f46,color:#f8fafc;
  class V3 bad;
  class S5 good;

คำบรรยายภาพ: บน (แดง) — prompt กำกวมปล่อยให้ model เดาช่องว่างเอง ผลจึงไม่นิ่ง เดายอดคืนเงิน ข้ามการเช็กข้อมูล โทนหลุดได้ ล่าง (เขียว) — system prompt ที่ประกอบจากสามชิ้น (บทบาทบวกกฎที่มีเหตุผล ตัวอย่าง few-shot และการห่อด้วย XML tag) ให้กรอบที่ชัด ผลจึงเสถียร เช็กข้อมูลก่อนลงมือ อ้างกฎถูก และคงโทนเดิม ความเชื่อถือได้มาจากโครงสร้าง ไม่ใช่ถ้อยคำที่ฉลาดหรือดังกว่า

สิ่งที่จะทำต่อ

ตอนนี้คุณมี system prompt ที่ตั้งบทบาทและกฎคืนเงินให้ agent แล้ว แต่มันยัง พูด ได้อย่างเดียว — ยังเช็กสถานะออเดอร์จริงไม่ได้ ตรง ORD-1042 ในตัวอย่างข้างบน model ได้แต่บอกว่า “ขอเช็กก่อน” โดยไม่มีทางไปเช็กจริง บทต่อไปเติมมือให้มัน: บทที่ 4 สอน tool use — ให้ model เรียก code C# ของคุณอย่าง getOrder(orderId) เพื่อไปดึงข้อมูลจริงมาตอบ แทนการเดา และคุณจะเห็นว่ากฎ “บอกให้ชัดว่าต้องลงมือ” จากบทนี้กลับมาสำคัญอีกครั้งตอนสั่งให้ model เลือกใช้ tool

🔗 อ้างอิงต้นทางของบทนี้

บทนี้สังเคราะห์จากหน้าเดียวรวบยอดของ Anthropic อ่านต่อได้ที่ต้นทางโดยตรง:

Anthropic, “Prompt engineering overview” — กฎทอง “ให้เพื่อนลองทำตาม” กรอบ “พนักงานใหม่ที่เก่งแต่ยังไม่รู้บริบท” การให้เหตุผลกำกับคำสั่ง การยก example (Relevant/Diverse/Structured, 3–5 อัน) การห่อด้วย XML tag การตั้งบทบาทผ่าน system prompt และคำแนะนำให้เลิกตะโกน CRITICAL/MUST กับ model รุ่นปัจจุบัน เข้าถึง 2026-07-19

เช็กความเข้าใจ — บทที่ 3

ข้อ 1 / 3

ทำไมเอกสารจึงแนะนำให้ใส่ 'เหตุผล' กำกับกฎคืนเงิน แทนที่จะเขียนแค่ตัวเลขเพดานเปล่าๆ?

Prompt ที่​ใช้งาน​ได้​จริง

กฎ​ทอง​ข้อ​เดียว​ที่​ต้อง​จำ​ก่อน

เทคนิค​ที่​หนึ่ง — บอก​ให้​ชัด และ​ให้​เหตุผล​กำกับ​กฎ

เทคนิค​ที่​สอง — ยก​ตัวอย่าง (few-shot)

เทคนิค​ที่​สาม — ห่อ​ส่วน​ต่างๆ ด้วย XML tag

เทคนิค​ที่​สี่ — ตั้ง​บทบาท​ผ่าน system prompt

หยุด​ตะโกน CRITICAL / MUST

สิ่ง​ที่​จะ​ทำ​ต่อ