คลิป "The prompting playbook" ของ Margot van Laar ที่ Anthropic เพิ่งปล่อยลงช่อง Claude เมื่อ 22 พฤษภาคม 2026 ความยาว 33 นาที เป็นเซสชั่นปิดท้ายของงาน Code with Claude ที่ลอนดอน ในฐานะ Applied AI Engineer ของ Anthropic Margot ไม่ได้พรีเซนต์เป็น list ของ do/don't แต่หยิบ 2 สถานการณ์ที่ engineer เจอบ่อยในงานจริงมาเล่าผ่าน worked example สถานการณ์แรกคือ prompt ของ customer support bot ในธุรกิจ telco ที่อยู่ใน production มานาน หลายคนช่วยกันแก้จนไม่มีเจ้าของชัดเจน แล้วต้องย้ายไปโมเดลใหม่ ส่วนสถานการณ์ที่สองคือการสร้าง agentic system ใหม่ทั้งหมดสำหรับจัดตารางงานพนักงานร้านค้าปลีก โดยต้องเลือกระหว่าง prompt ตัวใหญ่กับ agentic loop ที่แยกหน้าที่ บทความนี้สรุปทั้งคลิปสำหรับ dev ไทยที่ทำงานกับ Claude หรือ LLM ตัวอื่น ๆ และเรียบเรียงเป็น 5 หลักที่หยิบไปใช้กับ project ของตัวเองได้ทันที ทุกข้อยึดตามตัวอย่าง Meridian Mobile กับ retail scheduler ที่ Margot อธิบายในคลิป เพื่อให้เห็นภาพจริงในแต่ละหลัก ไม่ใช่ทฤษฎีลอย ๆ
1. ช่องว่างระหว่าง "prompt ที่ใช้งานได้" กับ "prompt ที่รอดผ่าน production"
Margot เปิดคลิปด้วยข้อสังเกตว่า prompting เป็นทักษะแรกที่ engineer ต้องเรียนตอนเริ่มทำงานกับ LLM และยังเป็นทักษะสำคัญที่สุดในการสร้าง AI system ที่ใช้งานได้จริง แต่ความยากของงานจริงคือ prompt ส่วนใหญ่ที่ engineer ต้องจัดการไม่ได้เพิ่งเขียนเสร็จ แต่ผ่านการแก้ร่วมกันมาหลายปี ครอบคลุมทั้ง policy, tone และ process มี patch สำหรับโมเดลรุ่นเก่าซ้อนทับกันอยู่ และไม่มีเจ้าของชัดเจน
ในคลิป Margot ยกตัวอย่างว่าเมื่อ engineer ต้องย้าย prompt แบบนี้ไปยังโมเดลใหม่ มักพบว่า test case จำนวนมากเริ่มทำงานผิดพลาด ทั้งที่ก่อนหน้านี้ผ่านหมด คำถามแรกคือต้องรู้ว่าปัญหาเกิดจากอะไรกันแน่ Margot ชี้ว่ามี 2 ความเป็นไปได้ คือโมเดลใหม่มี capability พอแต่พฤติกรรมเปลี่ยน จึงปรับ prompt ให้กลับมาใช้ได้ หรือโมเดลใหม่ capability ไม่ถึง ซึ่งไม่มี prompt ใดแก้ได้ การแยกสองกรณีนี้ต้องมี evaluation suite ที่วัดได้จริงว่า change ใน prompt ทำให้ performance ดีขึ้นหรือไม่ ไม่ใช่เดาเอาจากการทดสอบสองสามครั้ง
นี่คือ frame หลักของทั้งคลิป: prompting ที่ดีในระดับ production ไม่ใช่การหาคำพูดที่สวยที่สุด แต่เป็นกระบวนการที่ผูกกับ eval อย่างเข้มงวด ทำซ้ำได้ และทิ้ง audit trail ไว้ให้รุ่นถัดไปย้อนกลับมาดูได้ หลักการที่เหลือทั้งหมดในคลิปต่อยอดจาก frame นี้
2. กรอบของ playbook: 2 สถานการณ์ที่ Anthropic หยิบมาสอน
Margot อธิบายว่า prompt ที่ใช้สาธิตในวันนี้เป็นเวอร์ชั่นย่อ เพราะ prompt จริงที่ engineer ทำงานด้วยมักยาวและซับซ้อนกว่านี้มาก แต่ตัวอย่างที่เลือกมายังแทนปัญหาที่เจอบ่อยได้ดี สถานการณ์ทั้งสองที่หยิบมาเล่าในคลิปคือ
สถานการณ์ A คือการ debug prompt ที่อยู่ใน production มานานหลังย้ายโมเดล ตัวอย่างคือ customer support bot ของบริษัท telco สมมุติชื่อ Meridian Mobile ซึ่งมี prompt ครอบคลุมทั้ง policy, tone และ process พร้อม patch สำหรับโมเดลรุ่นก่อนผสมอยู่ Margot ใช้ eval 5 test case ที่ออกแบบให้ครอบคลุมทั้ง control case, edge case และเคสที่ต้อง escalate หรือปฏิเสธ เพื่อให้เห็นว่าควร debug failure mode แต่ละแบบอย่างไร
สถานการณ์ B คือการสร้าง agentic system ใหม่จากศูนย์ ตัวอย่างคือ agent ที่สร้างตารางเวรพนักงานร้านค้าปลีกหนึ่งสัปดาห์ ภายใต้ hard constraint เช่น headcount ขั้นต่ำและความพร้อมของพนักงานแต่ละคน ในสถานการณ์นี้ engineer ไม่ได้พิจารณาแค่ prompt แต่ต้องเลือก model และ harness ด้วย คลิปจึงเปรียบเทียบ 4 แนวทางคือ Sonnet 4.6 prompt ธรรมดา, Opus 4.7 prompt เดียวกัน, Opus 4.7 พร้อม adaptive thinking และ agentic loop แบบ generate-evaluate-repair
ทั้งสองสถานการณ์ Margot เลือกมาเพื่อให้ engineer เห็นทั้งฝั่ง maintenance และฝั่ง greenfield ในที่เดียว เพราะในงานจริงคนเดียวกันมักต้องสลับบทบาททั้งสองนี้ภายในสัปดาห์เดียว
3. Scenario A: Meridian Mobile กับ 5 eval test case ที่ครอบคลุมทุกพฤติกรรม
Margot เริ่มสถานการณ์ A ด้วยการอธิบาย eval suite ก่อน เพราะถ้าไม่มี eval การแก้ prompt ทุกครั้งก็เป็นแค่การเดาว่าดีขึ้นหรือไม่ ตัวอย่างในคลิปใช้แค่ 5 test case แต่งานจริง eval suite ของ engineer ควรมีมากกว่านี้ ประเด็นไม่ได้อยู่ที่จำนวน แต่อยู่ที่ทั้ง 5 case ครอบคลุม 3 แบบหลักที่ Margot บอกว่าทุก eval suite ต้องมี
แบบที่ 1 คือ control case ที่ควรผ่านเสมอ เป็นกรณีที่โมเดลจัดการได้ดีอยู่แล้วและไม่มีจุดให้ตีความ ในตัวอย่างของ Meridian Mobile คือคำถาม "data limit ของ basic plan เท่าไหร่" ซึ่งมีคำตอบตรงไปตรงมา แบบที่ 2 คือ edge case ที่เคยเห็นโมเดลตอบผิดมาก่อน จึงใส่ instruction เข้าไปใน prompt เพื่อกัน behavior แบบเดิมไม่ให้หลุดกลับมาอีก แบบที่ 3 และสำคัญที่สุดคือเคสที่ทดสอบว่าโมเดลเข้าใจขอบเขต capability ของตัวเอง รู้ว่าเมื่อไหร่ต้องส่งต่อให้มนุษย์ หรือเมื่อไหร่ต้องปฏิเสธ
5 test case ที่ Margot เลือกใน Meridian Mobile กระจายครบทั้ง 3 แบบ ประกอบด้วย control case เรื่อง data limit ของ basic plan, การคำนวณ proration ตอนสลับ plan กลางเดือน, การ escalate ไปหา human agent เมื่อมี billing error, การไม่ withhold ข้อมูลที่โมเดลมีอยู่ในมือจากลูกค้า และเคส hotspot ที่ลูกค้าอยู่บน legacy plan ทำให้ policy ปัจจุบันใช้ไม่ได้
ตามที่ Anthropic อธิบายในคลิป eval suite ลักษณะนี้ไม่ได้มีไว้แค่ทดสอบ แต่ยังทำหน้าที่เป็น contract กับโมเดลด้วย เพราะทุก test case แสดงเจตนาว่าระบบควรทำอะไรในกรณีเฉพาะ เมื่อมีปัญหา eval จึงช่วยชี้ทิศการแก้
4. Hygiene first: ก่อน debug failure mode รายตัว ต้องล้าง prompt ก่อน
หลังจากรันรอบแรกบน prompt ตั้งต้น Margot ได้ผลที่คาดเดาได้คือ control case ผ่าน ส่วนที่เหลือพังตามที่ออกแบบไว้ แทนที่จะรีบเจาะรายข้อทันที Margot เลือกทำ general cleanup ก่อน เพราะถ้า prompt ยังไม่ผ่าน prompting 101 การแก้รายเคสก็เท่ากับวาง patch บน foundation ที่ไม่มั่นคง
จุดที่ Margot ชี้ใน prompt ตั้งต้นมีหลายอย่างที่ดูเหมือนเล็กแต่ส่งผลใหญ่ จุดแรกคือบอกบอตว่าเป็น human ทั้งที่ไม่ใช่ จุดที่สองคือมีข้อความที่ copy ตรงจากเว็บไซต์ติดมาด้วย เช่น reference ของ hero image และบรรทัดเรื่อง cookie ที่หลุดมา ทั้งหมดนี้คือ noise ที่ทำให้โมเดลต้องเสีย attention มาตีความ จุดที่สามคือ instruction ทั้งหมดถูกยัดไว้ใน paragraph เดียว ไม่ได้แยก reasoning, role และ critical instruction ออกจากกัน
วิธีแก้ที่ Margot เลือกใช้คือเพิ่ม XML tag เพื่อแบ่ง prompt เป็น role, general guideline, policy และ tone of voice ให้ชัดเจน พอรัน eval อีกครั้งบน prompt ที่มี structure ใหม่ proration case ที่ก่อนหน้านี้ล้มเหลวก็เริ่มขยับขึ้นทันที ทั้งที่ยังไม่ได้แตะ instruction รายตัวด้วยซ้ำ Margot สรุปกฎที่หยิบไปใช้ได้ว่า ถ้าอ่าน prompt แล้วยังแยก guideline ออกจาก policy ออกจาก data ไม่ได้ ก็มีโอกาสสูงที่โมเดลจะแยกไม่ได้เช่นกัน
ขั้นถัดมาคือ output contract Margot เพิ่ม section ใหม่ที่กำหนดให้โมเดลตอบกลับใน XML tag เฉพาะ จากนั้นไปที่ฝั่ง harness เพื่อเพิ่ม stop sequence ใน API call ให้ตรวจจับ closing XML tag และหยุดสร้าง response ในจังหวะที่ควร ในเคส customer support bot ที่ตอบเป็น conversation อาจไม่เห็นผลทันตา แต่ถ้าเป็นระบบที่ต้อง output JSON ซ้อนหลายชั้น output contract แบบนี้จะช่วยกัน downstream parsing ระเบิด Margot เสริมว่าเครื่องมือแบบ structured output ช่วยบังคับ consistency นี้แบบ programmatic ได้ละเอียดกว่าการใช้ instruction ใน prompt อย่างเดียว
ผลของ general hygiene + output contract คือ test case ผ่าน 2 จาก 5 อย่าง consistent ส่วนที่เหลืออีก 3 case คือ proration, billing error และ hotspot ที่ต้อง isolate ออกมาเจาะรายตัวในขั้นถัดไป
5. Scenario A ต่อ: 3 failure mode 3 บทเรียนที่ใหญ่กว่าตัวเคส
จาก 3 failure mode ที่เหลือ Margot แก้ทีละ case และแต่ละ case เผย pattern ที่ใหญ่กว่าตัว Meridian Mobile เอง บทเรียนทั้งสามจึงเป็นใจกลางของ playbook ฝั่ง maintenance
5.1 Hotspot case: defensive patch ที่ overfit บนโมเดลใหม่
เคส hotspot คือกรณีที่ลูกค้าอยู่บน legacy plan จน policy ปัจจุบันใช้ไม่ได้ ข้อมูลลูกค้าที่ส่งให้ prompt ระบุชัดว่ามี hotspot 5 GB แต่โมเดลกลับตอบว่า unlimited plan ปัจจุบันมี 4 GB และให้ลูกค้าไปเช็กที่ URL ของ customer account เอง ทั้งที่มีข้อมูลที่ถูกต้องอยู่ในมือแล้ว
Margot เจาะกลับไปที่ prompt และพบว่ามีบรรทัดเขียนว่า "never give a customer the wrong plan details. instead point them to the URL" เป็น instruction ที่โมเดลกำลัง optimize อยู่ ในคลิปอธิบายว่า instruction แบบนี้น่าจะเป็น patch ที่ใส่เข้าไปตอนใช้โมเดลรุ่นก่อน เพื่อกัน behavior ที่โมเดลเก่ามักให้ข้อมูล plan ผิด แต่เมื่อโมเดลรุ่นใหม่ตามคำสั่งได้ดีขึ้น instruction แบบ defensive นี้กลับกลายเป็นภาระ เพราะโมเดลจะเลือก path ที่ปลอดภัยที่สุด นั่นคือการไม่ตอบ
วิธีแก้ของ Margot คือเปลี่ยน instruction ให้สมดุลกว่าเดิม โดยบอกว่าลูกค้าที่อยู่บน grandfathered plan มี allowance ต่างกัน และข้อมูลที่ถูกต้องอยู่ใน customer information ที่ส่งให้แล้ว จึงให้ใช้ข้อมูลนั้นเป็น source of truth พอรัน eval ใหม่ hotspot case ผ่านครบทุก test case บทเรียนของ case นี้คือ hallucination เป็นปัญหาที่คุยกันบ่อย แต่ behavior ตรงข้ามอย่างการ withhold ข้อมูลที่โมเดลมีอยู่จริงก็เกิดได้เหมือนกัน และมักมาจาก defensive patch ที่ใส่ไว้เพื่อกัน behavior ของโมเดลรุ่นเก่า Margot จึงแนะนำให้ใช้ version control ทุกครั้งที่ใส่ patch แบบนี้ พร้อมบันทึกเหตุผลว่าทำไมถึงใส่ เพื่อให้รุ่นถัดไปกลับมา audit ได้
5.2 Proration case: don't tell the model to do a good job, ให้ tool แทน
เคส proration คือลูกค้าถามว่าถ้าขยับไป 30 GB plan บิลเดือนหน้าจะเท่าไหร่ ผลที่โมเดลส่งกลับมาคือตัวเลขลอย ๆ จากการ reason แบบครึ่ง ๆ กลาง ๆ ไม่มีตัวเลขปลายทางชัดเจน จึงไม่ควรเอาไปยืนยันกับลูกค้าจริง
Margot เปิด prompt มาดู instruction ที่เกี่ยวข้อง ซึ่งเขียนไว้ว่า "don't ever give a customer a vague answer. critical: always calculates any pr-rated amounts correctly" นี่เป็นรูปแบบที่หลายคนคุ้น คือใช้คำว่า critical หรือ always เพื่อกดดันให้โมเดลทำงานถูกต้อง แต่ Margot ชี้ตรง ๆ ว่าการสั่งให้โมเดลทำงานให้ดีขึ้นไม่ได้เพิ่ม capability โมเดลก็ยังคำนวณในหัวอยู่ดี และ mental math ของ LLM ไม่ใช่จุดแข็ง
ทางแก้ที่ถูกต้องคือไม่สั่งให้ทำงานให้ดีขึ้น แต่ให้ tool ที่ทำงานนั้นได้จริง Margot เพิ่ม tool ชื่อ calculate_proration พร้อม schema ที่บอกโมเดลว่า tool นี้ทำอะไร และควรเรียกใช้ตอนไหน จากนั้น implement ฝั่ง backend ให้ tool คำนวณ proration ได้แม่นยำจริง พอรัน eval ใหม่ test case ผ่านทุก trial บทเรียนของ case นี้ตรงไปตรงมาคือ instruction ไม่เพิ่ม capability แต่ tool เพิ่มได้ โมเดลควรใช้ความสามารถในการ reason กับปัญหาที่ยาก และให้ tool execute ขั้นตอนที่ต้องการความแม่นยำสูง
5.3 Billing error case: ระบุทั้งสองด้านของ trade-off ไม่ใช่แค่ฝั่งเดียว
เคสสุดท้ายของ Scenario A คือ billing error ที่ระบบควร escalate ให้ human agent แต่ผลที่ได้คือ bot พยายาม diagnose ปัญหาเองแทนที่จะส่งต่อ Margot เปิด prompt และพบบรรทัดที่เขียนว่า "avoid escalating or transferring to a care specialist unless absolutely necessary as it cost approximately $8 and it counts against our team's fast contract resolution"
ปัญหาของ instruction นี้คือเล่าด้านเดียว ระบุชัดว่า escalate มี cost $8 แต่ไม่ได้บอกอีกด้านว่าถ้าไม่ escalate แล้วผิดจะเกิดอะไร โมเดลจึง optimize ไปที่การไม่ escalate ตาม instruction ที่อ่านเจอ ซึ่งขัดกับเจตนาที่ eval ระบุไว้โดยตรง
วิธีแก้ของ Margot คือเล่าทั้งสองด้านของ trade-off พูดตรง ๆ ว่า escalate ราคา $8 แต่ถ้าผิดต้องคืนเงินและเสีย customer trust ซึ่งราคาแพงกว่ามาก พอรัน eval ใหม่ก็ผ่านครบ บทเรียนของ case นี้คือ instruction รูปแบบนี้พบบ่อยและคล้ายกับเคส hotspot คือเป็น patch ที่ใส่เพื่อกัน behavior แบบเดียว โดยไม่ได้คิดถึงพฤติกรรมตรงข้าม ยิ่งโมเดลรุ่นใหม่ชั่งน้ำหนักได้ดีขึ้น engineer ก็ยิ่งต้องระบุทั้งสองด้านของ trade-off ให้โมเดลคำนวณเองได้ ไม่ใช่บังคับทิศทางเดียว
จบ Scenario A ได้เห็น pattern ครบทั้ง 4 ข้อคือ hygiene first, eval-anchored iteration, defensive patch ที่ overfit ได้, และต้องระบุทั้งสองด้านของ trade-off
6. Scenario B: retail scheduler และทางแยกระหว่าง prompt ตัวใหญ่กับ agentic loop
สถานการณ์ B เป็น greenfield ทั้งหมด Margot สร้าง agent สำหรับจัดตารางเวรพนักงานหนึ่งสัปดาห์ มีพนักงาน 8 คน ต้องเติม headcount ตาม schedule ทางขวา ภายใต้ constraint ที่ต้องทำตามทุกกรณี เพราะ constraint เป็น hard rule ที่ verify ได้ การให้คะแนนของ eval จึงไม่ใช้ LLM judge เหมือนใน Scenario A แต่ใช้ Python function ตรวจตรงว่า schedule ที่ออกมามี violation กี่จุด
Margot เล่าผ่าน 4 แนวทางที่เปรียบเทียบในคลิป ทำให้เห็นว่าการเลือกระหว่าง prompt, model และ harness ไม่ใช่ตัวเลือกที่แยกกัน แต่ต้องเลือกควบคู่กันตาม trade-off ของแต่ละ project
แนวทางที่ 1 เริ่มจาก baseline ที่เรียบง่ายที่สุด ใช้ Sonnet 4.6 พร้อม prompt ตั้งต้นที่ผ่าน general hygiene แล้ว มี XML tag แบ่ง section และระบุ output format เป็น JSON เพื่อกัน parsing error ปลายทาง พอรัน 5 trial ปรากฏว่าทุก case ล้มเหลว โมเดลเริ่ม reason เรื่อง schedule ได้ แต่ใช้ token ไปเยอะและไม่ตรวจงานของตัวเอง ผลคือไม่ได้คำตอบที่ถูกต้อง
แนวทางที่ 2 ขยับขึ้นไปใช้ Opus 4.7 และเก็บทุกอย่างอื่นไว้เหมือนเดิม ผลที่ได้คือยังล้มทุก case แต่จำนวน violation ลดลงอย่างเห็นได้ชัด สัญญาณนี้บอกว่าทิศทางถูก คือ reasoning capability ที่มากขึ้นช่วยให้ใกล้คำตอบที่ถูกต้องมากขึ้น แม้ยังไม่ถึงระดับที่ ship ได้
แนวทางที่ 3 ใช้ Opus 4.7 พร้อม adaptive thinking เปลี่ยนแค่ฝั่ง API ไม่แตะ prompt ผลที่ได้คือ schedule ผ่าน constraint อย่างน่าเชื่อถือ แต่ token ที่ใช้เพิ่มเป็น 3 เท่า และ latency ก็เพิ่ม 3 เท่าเช่นกัน ในคลิป Margot รัน async เพื่อย่นเวลา แต่ก็ระบุชัดว่า Opus 4.7 ไม่ได้เร็วขึ้นแบบ magic ระหว่างวันที่อัดคลิป ดังนั้นแม้ correctness จะดี ก็ยังต้องชั่ง trade-off เรื่อง cost และ latency
แนวทางที่ 4 เป็นการลองกลับมาที่ Sonnet 4.6 พร้อม prompt ที่ปรับใหม่ เพิ่มรายละเอียดเรื่องวิธี reason และที่สำคัญที่สุดคือสั่งให้โมเดลตรวจงานของตัวเองก่อน output ผลที่ได้คือผ่าน 2 จาก 5 case ส่วนที่ล้มเหลวไม่ใช่ violation ของ schedule แต่เป็นกรณีที่โมเดลทำงานไม่จบใน output token limit ที่กำหนด ต่อให้ปลดล็อก max token ให้ใหญ่ขึ้น ก็ทำให้ token รวมและ latency สูงขึ้นกว่าเดิมอีก ทางนี้จึงไม่ใช่ทางที่ควรเลือก
หลังผ่าน 4 แนวทางแรก บทเรียนที่ Margot สรุปชัดคือ model capability กับ prompt เป็นตัวเลือกที่ต้องชั่งกันจริง ไม่ใช่แค่เพิ่ม instruction เข้าไปใน prompt แล้วจะได้ผลเสมอ แต่ทางนี้ก็ยังไม่ดีที่สุด เพราะ Opus 4.7 + adaptive thinking ที่ใช้ได้จริงต้องแลกกับ cost และ latency สูง
7. Scenario B ต่อ: agentic loop ที่ชนะ monolith ทั้งเรื่อง correctness และ cost
แนวทางสุดท้ายของ Scenario B คือสิ่งที่ Margot เรียกว่า generate-evaluate-repair loop แทนที่จะใช้ prompt เดียวใหญ่ ๆ คลิปสาธิตการแยกออกเป็น 3 prompt เรียบง่ายที่ทำงานต่อเนื่องกัน
prompt แรกคือ generator ที่สร้าง first draft ของ schedule ออกมา prompt ที่สองคือ evaluator ที่อ่าน schedule แล้วรายงาน violation รายข้อ พร้อม evidence สำหรับแต่ละ rule ที่ผิด การ verify นี้ไม่ใช่ Python function ที่ตรวจแบบ deterministic แต่เป็น LLM ที่ตรวจตามหลักเดียวกัน ส่วน prompt ที่สามคือ repair ที่รับ list ของ violation แล้วแก้แบบ targeted ก่อนส่งกลับเข้า schedule ใหม่
ผลที่ได้คือ agentic loop ผ่าน case ทั้งหมด โดยใช้ token รวมและ latency ต่ำกว่าแนวทาง Opus 4.7 + adaptive thinking ที่ดีที่สุดก่อนหน้านี้ Margot จึงสรุปว่าทางเลือกต่อจากนี้มี 2 ทางที่เหมาะสม คือใช้ Opus 4.7 + adaptive thinking ตรง ๆ หรือใช้ agentic loop พร้อม optimization เพิ่มเติม
ข้อดีอีกข้อของ agentic loop ที่ Margot เน้นในตอนท้ายคือการใส่ soft requirement ระหว่าง runtime ได้ Python function ของ evaluator จะ verify เฉพาะ hard rule แต่ evaluator prompt ใส่ requirement เพิ่มทีหลังได้ เช่น Harry ไม่ชอบทำงานร่วมกับ Sally จึงควรพยายามแยกตารางทั้งสองเท่าที่ทำได้ หรือต้องการเพิ่ม shift ที่ 3 ในวันพุธ ทั้งหมดนี้เพิ่มได้โดยไม่ต้องไปแก้ Python function ทุกครั้งที่มีข้อยกเว้นเฉพาะกิจ
บทเรียนใหญ่ของ Scenario B จึงอยู่ที่วิธีคิด ก่อนจะยัด instruction ใหม่ใส่ prompt ตัวเดียวให้ใหญ่ขึ้นเรื่อย ๆ engineer ควรถามก่อนว่างานนี้แยกเป็น sub-task ที่ทำซ้ำได้และตรวจสอบแยกกันได้ไหม ถ้าได้ การแยกเป็น agentic loop ที่มี 3 prompt เรียบง่าย มักให้ correctness สูงขึ้น ใช้ cost ต่ำลง และเสริม soft requirement ได้ flexible กว่ามาก
8. 5 หลักจาก Anthropic ที่เอาไปใช้กับ project ของตัวเองวันจันทร์เช้า
จากทั้งสองสถานการณ์ที่ Margot พาไล่ดูในคลิป สามารถสกัดเป็น 5 หลักที่ engineer ไทยหยิบไปใช้กับ project Claude ของตัวเองได้ทันที โดยทุกข้อมีรากจากตัวอย่าง Meridian Mobile หรือ retail scheduler ที่อธิบายไปแล้ว
หลักที่ 1 คือ eval-first ก่อนทุกอย่าง prompt ใด ๆ ที่ไม่มี eval suite จับอยู่ คือ prompt ที่ไม่มีทางรู้ว่า change ที่ใส่เข้าไปทำให้ดีขึ้นหรือแย่ลง eval suite ที่ดีควรครอบคลุม control case ที่ควรผ่านเสมอ, edge case ที่เคยพังมาก่อน และเคสที่ทดสอบว่าโมเดลรู้ขอบเขตของตัวเอง รวมถึงรู้ว่าเมื่อไหร่ต้องส่งต่อให้มนุษย์หรือปฏิเสธ
หลักที่ 2 คือ hygiene ก่อน patch ตัว prompt ต้องผ่าน prompting 101 ก่อน คือมี role ชัดเจน มี XML tag แบ่ง section ระหว่าง guideline, policy และ data ไม่มีข้อความ noise ที่ติดมาจากการ copy เว็บไซต์ มี output contract และมี stop sequence ตรวจ closing tag ใน harness Margot สรุปสั้น ๆ ว่าถ้าอ่าน prompt แล้วยังแยก guideline ออกจาก policy และ data ไม่ได้ โมเดลก็แยกไม่ได้เหมือนกัน
หลักที่ 3 คือ defensive patch ต้องอยู่ใต้ version control ทุก instruction ที่ใส่เพื่อกัน behavior ของโมเดลรุ่นก่อน ควรบันทึกเหตุผลและวันที่ใส่ไว้ในระบบเดียวกับ prompt เพราะเมื่อย้ายโมเดล patch แบบนี้มักกลายเป็น instruction ที่ overfit จนทำให้โมเดลเลือก path ที่ปลอดภัยเกินเหตุ เมื่อมี audit trail engineer จะตัดสินใจถอน patch ออกได้อย่างมั่นใจ ไม่ใช่กลัวว่าจะพังของเก่า
หลักที่ 4 คือ instruction ไม่เพิ่ม capability แต่ tool เพิ่มได้ ทุกครั้งที่เห็นตัวเองเขียนคำว่า critical หรือ always ใน prompt ให้หยุดและถามว่ามี tool ที่ทำงานนี้ได้แม่นกว่าหรือไม่ การคำนวณ proration, การ query database และการ check fact ภายนอกควรเป็น tool ที่มี schema ชัดเจน ไม่ใช่บรรทัดใน prompt ที่บอกให้โมเดลทำให้ดี ส่วน reasoning เป็นจุดแข็งของโมเดล จึงควรปล่อยให้โมเดล reason แล้วให้ tool execute ขั้นตอนที่ต้องแม่น
หลักที่ 5 คือระบุทั้งสองด้านของ trade-off ทุก trade-off ที่เกี่ยวกับการตัดสินใจของระบบควรอธิบายให้โมเดลฟังทั้งสองด้าน ไม่ใช่บอกแค่ราคา หรือบอกแค่ benefit ตัวอย่างของ Margot คือ escalate มี cost $8 แต่ถ้าไม่ escalate แล้วผิด ต้องคืนเงินและเสีย customer trust หลักนี้ยิ่งสำคัญเมื่อโมเดลรุ่นใหม่ชั่งน้ำหนักเองได้ดีขึ้นเรื่อย ๆ engineer ที่ให้ข้อมูลครบจะได้ behavior ที่ตรงกว่า engineer ที่บังคับทิศทางเดียว
หลักโบนัสจาก Scenario B ที่หยิบไปได้คือ ก่อนยัด instruction เข้า prompt ตัวเดียวให้ใหญ่ขึ้น ให้ถามก่อนว่าแยกเป็น generate-evaluate-repair loop ที่มี 3 prompt เรียบง่ายได้ไหม ถ้าได้ มักจะให้ผลที่ดีกว่าทั้งเรื่อง correctness, token cost และความสามารถในการเสริม soft requirement ตอน runtime
9. สรุป + ที่มา
playbook ที่ Margot จากทีม Applied AI Engineering ของ Anthropic วางไว้ในคลิปนี้ตอบโจทย์ engineer สองกลุ่มที่จริง ๆ แล้วมักเป็นคนเดียวกัน คือคนที่ต้องดูแล prompt เก่าใน production พร้อมย้ายโมเดล และคนที่ต้องสร้าง agentic system ใหม่จากศูนย์ในสัปดาห์เดียวกัน บทเรียนทั้ง 5 ข้อเชื่อมกันที่จุดเดียวคือ prompting ที่ดีในระดับ production ต้องเป็นกระบวนการที่ผูกกับ eval ทุกการตัดสินใจต้องวัดได้ และทุก patch ต้องมี audit trail ส่วน prompt ที่ดูสวยใน notebook อย่างเดียวยังไม่พอ
สำหรับ dev ไทยที่ทำงานกับ Claude หรือ LLM ตัวอื่น ขั้นแรกที่หยิบไปทำได้คือสร้าง eval suite ของตัวเองที่ครอบคลุม 3 แบบที่ Margot อธิบาย จากนั้นเปิด prompt ปัจจุบันมาแบ่ง XML tag แยก guideline ออกจาก policy และ data แล้วทดลองถอน defensive patch ที่เคยใส่ตอนใช้โมเดลรุ่นก่อนทีละข้อ โดยมี eval เป็นตัวจับว่าผลดีขึ้นจริงหรือไม่ ส่วน project ใหม่ ก่อนยัด instruction เข้า prompt ตัวเดียวให้ใหญ่ ให้ลองถามว่าแยกเป็น agentic loop 3 prompt ได้ไหม
ที่มา: The prompting playbook โดย Margot van Laar (Anthropic) บน YouTube channel Claude เผยแพร่ 22 พฤษภาคม 2026 ความยาว 33 นาที 49 วินาที
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!