ในงาน Code with Claude ณ กรุงลอนดอน Margot van Laar วิศวกร Applied AI จาก Anthropic ได้แชร์มุมมองสำคัญผ่านเซสชัน "The Prompting Playbook" โดย Margot ไม่ได้มาแจกเช็กลิสต์ do/don't ทั่วไป แต่หยิบ 2 สถานการณ์จริงในโลกการทำงานมาผ่าให้ดู:

1. การ Debug และ Migrate Prompt เดิมใน Production ผ่านกรณีศึกษาบอตบริการลูกค้าของธุรกิจโทรคมนาคม
2. การสร้างระบบ Agentic System ใหม่จากศูนย์ (Greenfield) ผ่านกรณีศึกษาการจัดตารางกะพนักงานร้านค้าปลีก

บทความนี้สรุป 5 หลักคิดสำคัญที่นักพัฒนาสามารถนำไปประยุกต์ใช้กับระบบที่ใช้ Claude หรือ LLM อื่นๆ ได้ทันที

ดูคลิปต้นฉบับ The prompting playbook บนช่อง YouTube ของ Claude

1. ช่องว่างระหว่าง "Prompt ที่ใช้ได้" กับ "Prompt ที่รอดใน Production"

Margot ชี้ว่า Prompt ส่วนใหญ่ในระดับ Production มักผ่านการแก้ไขร่วมกันมาหลายมือจนขาดโครงสร้างที่ชัดเจน มีการแปะแพตช์แก้ปัญหาเฉพาะหน้าของโมเดลรุ่นเก่าซ้อนทับกันอยู่ เมื่อต้องย้ายไปใช้โมเดลรุ่นใหม่ ปัญหาคลาสสิกที่พบบ่อยคือ เทสต์เคสเดิมที่เคยผ่านกลับพังลง

การแก้ปัญหาอย่างมีหลักการต้องเริ่มจากการสร้าง Evaluation Suite (Eval) ที่วัดผลได้จริง เพื่อพิสูจน์ว่าการปรับ Prompt ช่วยให้ผลลัพธ์ดีขึ้นจริงหรือไม่ แทนที่จะเป็นการเดาจากการทดสอบเพียงไม่กี่ครั้ง

2. Scenario A: Meridian Mobile กับ 5 Eval Test Cases

ตัวอย่างแรกคือบอตบริการลูกค้าของบริษัทโทรคมนาคมสมมุติชื่อ Meridian Mobile โดย Margot ได้ออกแบบ Eval 5 เทสต์เคสที่สะท้อน 3 รูปแบบสำคัญที่ทุก Eval Suite ควรมี:

1. Control Case กรณีพื้นฐานที่ควรตอบถูกเสมอ (เช่น ถามเรื่องแพ็กเกจเน็ตพื้นฐาน)
2. Edge Case เคสที่มีความซับซ้อนและเคยตอบผิดในอดีต (เช่น การคำนวณเฉลี่ยตามสัดส่วนวัน หรือ Proration)
3. Escalation & Safety Case เคสทดสอบว่าโมเดลรู้ขอบเขตความสามารถของตนเองหรือไม่ รู้ว่าเมื่อใดต้องส่งต่อให้เจ้าหน้าที่มนุษย์ และเมื่อใดต้องปฏิเสธ

3. จัดระเบียบ Prompt ก่อน (Hygiene First)

ก่อนจะเจาะแก้ปัญหาเฉพาะจุด Margot แนะนำให้ทำความสะอาด Prompt ตั้งต้นก่อนเสมอ:

• ตัด Noise ออก: ลบข้อความที่ไม่จำเป็น เช่น ข้อความลิขสิทธิ์ หรือแท็ก cookie ที่ติดมาจากการ copy หน้าเว็บ
• ใช้ XML Tags จัดโครงสร้าง: แยกบทบาท (Role), แนวทางทั่วไป (Guidelines), กฎระเบียบ (Policy) และข้อมูลลูกค้า (Data) ออกจากกันอย่างชัดเจน
• กำหนด Output Contract: บังคับให้โมเดลตอบกลับในแท็ก XML เฉพาะ และตั้งค่า Stop Sequence ใน API เพื่อป้องกันข้อความส่วนเกิน

เมื่อปรับโครงสร้างให้อ่านง่ายทั้งสำหรับมนุษย์และ AI ผลการทดสอบบางข้อย่อยจะผ่านขึ้นมาทันทีโดยยังไม่ต้องแตะเนื้อหาคำสั่งด้วยซ้ำ

4. ถอดรหัส 3 Failure Modes สำคัญ

4.1 ปัญหา Patch เก่าทำให้โมเดลใหม่ปลอดภัยเกินเหตุ (Overfitting)

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

ทางแก้: ปรับคำสั่งให้ชัดเจนว่าข้อมูลลูกค้าที่แนบไปคือ Source of Truth และควรเก็บบันทึกประวัติ (Version Control) ของการใส่คำสั่งป้องกันเหล่านี้ไว้เสมอ เพื่อให้ตรวจสอบและถอดออกได้เมื่อย้ายโมเดล

4.2 อย่าสั่งให้โมเดลทำงานดีขึ้น แต่จงให้ Tool ที่เหมาะสม

ในเคสคำนวณค่าบริการตามสัดส่วน (Proration) คำสั่งเดิมเขียนย้ำว่า "critical: always calculate correctly" แต่ผลลัพธ์ก็ยังผิด เพราะโมเดลภาษาไม่ได้ถูกออกแบบมาเพื่อคิดเลขในใจอย่างแม่นยำ

ทางแก้: เพิ่ม Tool calculate_proration เข้าไปในระบบ เพื่อให้โมเดลเรียกใช้ฟังก์ชันคำนวณทางคณิตศาสตร์ที่ถูกต้อง การใส่คำสั่งกำชับไม่ช่วยเพิ่มความสามารถของโมเดล แต่ Tool ต่างหากที่ช่วยเพิ่มขีดความสามารถ

4.3 อธิบายทั้งสองด้านของ Trade-off

ในเคสแจ้งปัญหาบิลผิดพลาด โมเดลพยายามแก้ปัญหาเองแทนที่จะส่งต่อให้เจ้าหน้าที่มนุษย์ เพราะใน Prompt ระบุเพียงว่า "หลีกเลี่ยงการส่งต่อเจ้าหน้าที่เพราะมีต้นทุนครั้งละ 8 ดอลลาร์"

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

5. Scenario B: สร้าง Retail Scheduler ด้วย Agentic Loop

ในโจทย์การจัดตารางเวรพนักงานร้านค้าปลีกที่มีเงื่อนไขบังคับ (Hard Constraints) ซับซ้อน Margot ได้เปรียบเทียบ 4 แนวทาง:

1. Sonnet 4.6 (Prompt เดี่ยว): ผลลัพธ์ไม่ผ่านเกณฑ์ โมเดลไม่ตรวจสอบงานของตนเอง
2. Opus 4.7 (Prompt เดี่ยว): ผ่านเกณฑ์ดีขึ้น แต่ยังมีข้อผิดพลาด
3. Opus 4.7 + Adaptive Thinking: ผ่านเกณฑ์ทั้งหมด แต่ใช้ Token และมี Latency เพิ่มขึ้น 3 เท่า
4. Agentic Loop (Generate-Evaluate-Repair): ใช้ 3 Prompt ขนาดเล็กทำงานประสานกัน

พลังของ Generate-Evaluate-Repair Loop

แทนที่จะรวมทุกอย่างไว้ใน Prompt ขนาดยักษ์ตัวเดียว ทีมงานแบ่งงานออกเป็น 3 ขั้นตอน:

• Generator: สร้างร่างตารางเวรแรกขึ้นมา
• Evaluator: อ่านตารางและระบุจุดที่ผิดเงื่อนไขพร้อมหลักฐาน
• Repairer: รับรายการข้อผิดพลาดไปแก้ไขเฉพาะจุด

ผลลัพธ์คือ Agentic Loop สามารถทำคะแนนผ่านทุกเคส โดยใช้ Token รวมและ Latency ต่ำกว่าการใช้ Prompt ก้อนเดียว แถมยังเปิดให้เพิ่มเงื่อนไขยืดหยุ่น (Soft Requirements) ในระหว่างรันไทม์ได้ง่ายขึ้น

6. สรุป 5 หลักการเขียน Prompt ฉบับ Anthropic

1. Eval-First เสมอ: สร้างชุดทดสอบที่วัดผลได้จริงก่อนเริ่มปรับแก้ Prompt
2. รักษาความสะอาดของโครงสร้าง (Hygiene First): ใช้ XML tags แยกแยะข้อมูล และกำหนด Output Contract ให้รัดกุม
3. คุม Defensive Patch ด้วย Version Control: จดบันทึกเหตุผลทุกครั้งที่ใส่คำสั่งป้องกันพฤติกรรม เพื่อให้พร้อมถอดออกเมื่ออัปเกรดโมเดล
4. ใช้ Tool เสริมขีดความสามารถ: ขั้นตอนที่ต้องการความแม่นยำสูง (เช่น การคำนวณ) ให้ส่งต่อเป็น Tool แทนการสั่งให้โมเดลพยายามทำเอง
5. แจกแจง Trade-off ให้ครบทั้งสองด้าน: ให้ข้อมูลผลดีและผลเสียที่รอบด้าน เพื่อให้โมเดลตัดสินใจได้อย่างแม่นยำ

ที่มา: The prompting playbook โดย Margot van Laar (Anthropic)