บทนำ: ศิลปะการป้อนคำสั่งให้โมเดลขนาดเล็กแต่ทรงพลัง
หากคุณเคยต้องการให้ AI ของคุณให้ความรู้สึกเหมือนเพื่อนร่วมทีมที่คิดเร็วมากกว่าที่ปรึกษาที่พูดมากและช้า Claude Haiku 4.5 คือโมเดลสำหรับคุณ ได้รับการออกแบบมาเพื่อความเร็ว ความหน่วงต่ำ และประสิทธิภาพด้านต้นทุน ซึ่งเหมาะสำหรับการทำซ้ำอย่างรวดเร็ว ปริมาณงานสูง และวงจรป้อนกลับที่รวดเร็ว แต่มีข้อแม้คือ การได้ผลลัพธ์ที่ยอดเยี่ยมจาก Haiku 4.5 ไม่ได้มาจากการเขียน prompt ที่ยาวขึ้น แต่มาจากการเขียน prompt ที่คมชัดยิ่งขึ้น ในคู่มือนี้ เราจะเปิดเผยกลยุทธ์ prompt ที่ให้ผลลัพธ์ที่คมชัดและเชื่อถือได้อย่างสม่ำเสมอจาก Claude Haiku 4.5 และแสดงวิธีปรับให้เข้ากับทุกสิ่งตั้งแต่การเขียนโค้ดไปจนถึงการสร้างเนื้อหาและการวิเคราะห์น้ำหนักเบา
อะไรที่ทำให้ Claude Haiku 4.5 แตกต่าง และทำไมจึงสำคัญสำหรับการป้อน prompt
Claude Haiku 4.5 อยู่ในระดับ "โมเดลขนาดเล็ก" สร้างขึ้นเพื่อความเร็วและขนาด ในขณะที่ยังคงการให้เหตุผลที่แข็งแกร่งสำหรับงานประจำวัน นั่นเปลี่ยนวิธีการป้อน prompt ของคุณ:
- คุณจะได้ผลลัพธ์ที่ดีที่สุดด้วยคำแนะนำที่เป็นระบบและชัดเจน
- Prompt ที่สั้นและมีสัญญาณสูงดีกว่า prompt ที่ยาวและวกวน
- การให้เหตุผลแบบมีขอบเขต (“คิดทีละขั้นตอนใน 3–5 ขั้นตอน”) ช่วยให้มีสมาธิ
- เหมาะสำหรับการร่างอย่างรวดเร็ว การวางโครงร่าง และการสนับสนุนการตัดสินใจด้วยข้อจำกัดที่ชัดเจน
Haiku 4.5 ได้รับการออกแบบมาให้คุ้มค่าเมื่อปรับขนาด ซึ่งทำให้เหมาะอย่างยิ่งสำหรับการจัดระเบียบเวิร์กโฟลว์แบบหลายรอบ การแปลงเนื้อหาจำนวนมาก และการสร้างโดยใช้การดึงข้อมูล (RAG) ที่ความหน่วงมีความสำคัญ
หมายเหตุรูปแบบ: บทความนี้ใช้วิธีการที่เน้นการปฏิบัติและแก้ปัญหา ซึ่งปรับให้เหมาะสมสำหรับการใช้งานทันทีในโครงการจริง
กฎทองสำหรับการป้อน prompt Claude Haiku 4.5
- เขียน prompt ที่สั้นที่สุดที่ยังคงขจัดความคลุมเครือ
- ดีกว่า: “สรุปรายงานนี้สำหรับผู้จัดการผลิตภัณฑ์ 5 bullet รวมถึง: ความเสี่ยง การพึ่งพา ขั้นตอนต่อไป สูงสุด 120 คำ”
เหตุผลที่ได้ผล: Haiku 4.5 เติบโตได้ดีเมื่อข้อจำกัดของคุณคมชัด ระบุกลุ่มเป้าหมาย รูปแบบ ความยาว และองค์ประกอบที่ต้องมี
- รักษาสถานะบทบาทและวัตถุประสงค์ให้ชัดเจนในการตั้งค่าแบบ system-style
- ตัวอย่าง: “คุณคือผู้ช่วยด้านเทคนิคที่กระชับ วัตถุประสงค์: (1) ตอบอย่างถูกต้อง (2) ลดโทเค็นให้เหลือน้อยที่สุด (3) แสดงโครงร่างการให้เหตุผล 3 ขั้นตอนเมื่อถูกถามเท่านั้น”
เหตุผลที่ได้ผล: บทบาท + วัตถุประสงค์ที่ชัดเจนนำทางการถอดรหัส ลดการเบี่ยงเบน และปรับปรุงความสามารถในการทำซ้ำในการเรียกแต่ละครั้ง
- ชอบรายการตรวจสอบมากกว่าวลีเปิด
- ตัวอย่างสำหรับการตรวจสอบโค้ด: “ตรวจสอบ: (a) ความถูกต้อง (b) ความปลอดภัย (c) ความสามารถในการอ่าน (d) การครอบคลุมการทดสอบ ผลลัพธ์: ผ่าน/ไม่ผ่านต่อรายการพร้อมเหตุผลประกอบ 1–2 บรรทัด”
เหตุผลที่ได้ผล: รายการตรวจสอบบีบอัดงานที่ซับซ้อนเป็นงานย่อยที่เชื่อถือได้และตรวจสอบได้
- ตัวอย่าง: “คิดไม่เกิน 4 ขั้นตอน จากนั้นนำเสนอคำตอบสุดท้ายเท่านั้น”
เหตุผลที่ได้ผล: คุณได้รับการให้เหตุผลที่มุ่งเน้นโดยไม่มีการพูดพล่ามที่ไม่สามารถควบคุมได้
- ต้องการผลลัพธ์ที่มีโครงสร้าง (เสมอ!)
- ตัวอย่าง: “ส่งคืน JSON ที่มีคีย์: decision, rationale, risks, next_steps ไม่มีข้อความเพิ่มเติม”
เหตุผลที่ได้ผล: โครงสร้างช่วยให้ระบบอัตโนมัติปลายทาง ป้องกันการพูดพล่าม และรักษาต้นทุนที่คาดการณ์ได้
- ตัวอย่าง Few-shot ควร: สั้น เป็นตัวแทน และสอดคล้องกับสไตล์ที่คุณต้องการ
- รูปแบบ: คำแนะนำ → ตัวอย่างขนาดกะทัดรัด 1–2 ตัวอย่าง → อินพุตใหม่
- เคล็ดลับ: เก็บตัวอย่างเฉพาะโดเมน (เช่น เสียงของแบรนด์ของคุณ สไตล์โค้ดของคุณ)
- จำกัดโทน ความยาว และรูปแบบ
- “รูปแบบ: 5 bullet แต่ละ bullet ≤18 คำ”
- สำหรับโค้ด: “เป้าหมาย: Python 3.11, Pydantic v2 ใช้ type hints รวมการทดสอบ 1 บล็อก”
- เพิ่ม: “หากข้อมูลหายไปหรือมีความคลุมเครือ ให้ถามคำถามที่ต้องการความกระจ่างเพียงข้อเดียวก่อน หากยังไม่แน่ใจ ให้พูดว่า ‘ไม่ทราบ’”
เหตุผลที่ได้ผล: ลดคำตอบที่ผิดพลาดอย่างมั่นใจและทำให้วงจรมีประสิทธิภาพ
- ใช้การดึงข้อมูลและส่งเฉพาะส่วนย่อยที่เกี่ยวข้อง ไม่ใช่ corpora ทั้งหมด
- ให้เฉพาะส่วนที่เกี่ยวข้อง 1–3 อันดับแรก
- ตัด boilerplate ล่วงหน้าเพื่อเพิ่มความหนาแน่นของสัญญาณ
- ติดป้ายกำกับส่วนย่อย: [Policy], [Excerpt], [Email], [Spec]
- นโยบาย: “ห้ามส่งออก PII เก็บให้น้อยกว่า 150 โทเค็น อ้างอิงแหล่งที่มาหากมีให้”
- งานของผู้ใช้: “สรุปอีเมลสำหรับหัวหน้าฝ่ายขาย”
เหตุผลที่ได้ผล: สถาปัตยกรรม prompt ที่สะอาดกว่า บำรุงรักษาง่ายกว่า
รูปแบบ prompt ที่ได้ผลอย่างสม่ำเสมอ
รูปแบบ A: “บทสรุปที่รัดกุม”
ใช้เมื่อคุณต้องการความเร็วและความสอดคล้องสำหรับงานประจำ
เทมเพลต:
- วัตถุประสงค์: “เป้าหมายของคุณคือ [objective]”
- ข้อจำกัด: กลุ่มเป้าหมาย ความยาว โทน รูปแบบ
- เกณฑ์การประเมิน: เกณฑ์ bullet 2–4 ข้อ
- ตัวคั่นอินพุต: “อินพุตเริ่มต้น/สิ้นสุดด้วย ===”
- สคีมาเอาต์พุต: “ส่งคืน [format] ไม่มีข้อความเพิ่มเติม”
รูปแบบ B: “วิจารณ์แล้วสร้าง”
สำหรับแบบร่างคุณภาพสูงกว่าโดยมีโทเค็นพิเศษน้อยที่สุด
- ขั้นตอนที่ 1 (ภายใน): “ประเมินความเกี่ยวข้อง ช่องว่าง และความเสี่ยงอย่างเงียบๆ ใน 3 bullet”
- ขั้นตอนที่ 2 (เอาต์พุต): “สร้างแบบร่างที่แก้ไขปัญหาเหล่านั้น”
- เพื่อให้เอาต์พุตสะอาด ให้ระบุ: “อย่าแสดงคำวิจารณ์ เพียงแค่นำไปใช้”
รูปแบบ C: “เปรียบเทียบและเลือก”
ใช้เมื่อการเลือกคืองาน
- “เมื่อพิจารณาจากตัวเลือก A–D ให้ให้คะแนนใน: ความถูกต้อง (40) ความชัดเจน (30) การปฏิบัติตามข้อกำหนด (30) ส่งคืนผู้ชนะและเหตุผลประกอบ 2 ประโยค”
รูปแบบ D: “Chain of Checks”
เพื่อความปลอดภัย การปฏิบัติตามข้อกำหนด หรือการปฏิบัติตามนโยบาย
- “ก่อนตอบ ให้ตรวจสอบ: (1) ได้รับอนุญาตตามนโยบาย (2) อยู่ในขอบเขต (3) ไม่มีข้อมูลหายไป หากมีสิ่งใดล้มเหลว ให้หยุดและถามคำถามที่ต้องการความกระจ่าง 1 ข้อ”
รูปแบบ E: “Delta-Edit”
สำหรับการแก้ไขข้อความที่มีอยู่
- “ส่งคืนเฉพาะ diff ขั้นต่ำ: ‘เปลี่ยน X เป็น Y เพราะ Z’ รักษาสไตล์เดิมไว้ เปลี่ยนแปลงได้สูงสุด 8 รายการ”
รูปแบบ F: “Code Scaffold”
- “สร้าง baseline ที่ใช้งานได้ขั้นต่ำพร้อม TODO รวมการทดสอบ รักษาส่วนย่อย ≤30 บรรทัด เพิ่ม docstrings และ type hints”
ตัวอย่างที่มีผลกระทบสูงสำหรับเวิร์กโฟลว์ประจำวัน
การสรุปเนื้อหา
Prompt:
“คุณคือนักวิเคราะห์ที่กระชับ สรุปรายงานต่อไปนี้สำหรับผู้นำผลิตภัณฑ์
- เอาต์พุต: 5 bullet (≤18 คำต่อ bullet) สำหรับ: ผลลัพธ์ ความเสี่ยง การพึ่งพา ขั้นตอนต่อไป เมตริก
- หากข้อมูลหายไป ให้เขียนว่า ‘ไม่ทราบ’ สำหรับ bullet นั้น
===
[วางรายงาน]
===”
การร่างอีเมล
Prompt:
“คุณคือผู้ช่วยมืออาชีพ ร่างคำตอบที่: สั้น อบอุ่น เด็ดขาด รวม: (1) ความชื่นชม (2) การตัดสินใจที่ชัดเจน 1 ข้อ (3) คำขอ 1 ข้อ
- สูงสุด 120 คำ ไม่มีการลงชื่อคำทักทาย ฉันจะเพิ่มเอง”
การสร้าง SQL จากสคีมา
Prompt:
“คุณคือผู้ช่วย SQL เมื่อกำหนดสคีมา Postgres ให้เขียนคิวรีเดียว
- ข้อจำกัด: ANSI SQL ไม่มี CTE เว้นแต่จำเป็น ใช้ดัชนีโดยนัย
- เอาต์พุต: เฉพาะบล็อกโค้ด จากนั้นคำอธิบาย 1 ประโยค
สคีมา:
===
[สคีมา]
===
งาน: [คำถาม]”
การตรวจสอบโค้ด
Prompt:
“คุณคือผู้ตรวจสอบโค้ดที่ใส่ใจเรื่องความปลอดภัย
- ตรวจสอบ: ความถูกต้อง ความปลอดภัย ความสามารถในการอ่าน การทดสอบ
- เอาต์พุต: อาร์เรย์ JSON ของข้อค้นพบที่มีฟิลด์: severity, file, line, issue, fix
- ข้อค้นพบสูงสุด 6 รายการ หากไม่มี ให้ส่งคืน []
===
[Diff หรือไฟล์]
===”
การตอบคำถาม RAG
Prompt:
“คุณคือผู้ตอบที่ยึดมั่น ใช้เฉพาะแหล่งที่มาที่ให้ไว้เท่านั้น
- อ้างอิง ID แหล่งที่มาในวงเล็บเช่น [S1] หากคำตอบไม่ได้อยู่ในแหล่งที่มา ให้พูดว่า ‘ไม่พบในแหล่งที่มา’
- เอาต์พุต: 2–4 ประโยค จากนั้น 3 bullet ที่มีป้ายกำกับว่า ‘Citations’
แหล่งที่มา:
[S1] …
[S2] …
คำถาม: …”
เกณฑ์การประเมินเพื่อใส่ลงใน prompt
- ความถูกต้องเป็นอันดับแรก: “ลงโทษการอ้างสิทธิ์ที่ไม่ได้รับการสนับสนุน ชอบ ‘ไม่ทราบ’ มากกว่าการเดา”
- ความกระชับ: “คำตอบที่มีมากกว่า 150 โทเค็นไม่เป็นไปตามข้อกำหนด”
- โครงสร้าง: “คำตอบที่ไม่ตรงกับสคีมา JSON ล้มเหลว”
- ความปลอดภัย: “ปฏิเสธงานที่มีข้อมูลประจำตัว ความลับ หรือ PII”
เคล็ดลับเพื่อความน่าเชื่อถือและความหน่วงต่ำ
- ใช้ตัวคั่นที่ชัดเจน (===, <<<json>>>) ป้องกันการปะปนกันโดยไม่ได้ตั้งใจระหว่างส่วนต่างๆ
- ติดป้ายกำกับทุกอย่าง Haiku 4.5 เคารพป้ายกำกับเช่น [Context], [Policy], [Task], [Output]
- ระบุงบประมาณโทเค็น: “เป้าหมาย 120–180 โทเค็น ไม่เกิน 220”
- ชอบคำง่ายๆ หลีกเลี่ยงภาษาเปรียบเทียบเว้นแต่จำเป็น
- หลีกเลี่ยงคำแนะนำแบบหลายขั้นตอนในประโยคเดียว แบ่งออกเป็นขั้นตอนที่มีหมายเลข
ข้อผิดพลาดทั่วไป และวิธีแก้ไข
- ข้อผิดพลาด: เป้าหมายที่ไม่ชัดเจน
แก้ไข: ระบุวัตถุประสงค์ + กลุ่มเป้าหมาย + ข้อจำกัด
- ข้อผิดพลาด: บริบทที่ยาวเกินไป
แก้ไข: ส่งเฉพาะส่วนย่อยที่เกี่ยวข้องมากที่สุด 1–3 ส่วน
- ข้อผิดพลาด: เอาต์พุตที่ไม่มีโครงสร้าง
แก้ไข: กำหนดสคีมา JSON หรือ bullet
- ข้อผิดพลาด: แหล่งที่มาที่สร้างขึ้นเอง
แก้ไข: สั่ง: “อ้างอิงเฉพาะแหล่งที่มาที่ให้ไว้ มิฉะนั้นให้พูดว่า ‘ไม่พบในแหล่งที่มา’”
- ข้อผิดพลาด: คำตอบที่ไม่เด็ดขาด
แก้ไข: จัดทำเกณฑ์การตัดสินใจและกำหนดให้มีการเลือกเพียงครั้งเดียว
ขั้นสูง: การสร้างไลบรารี prompt สำหรับ Haiku 4.5
- สร้างแมโครที่ใช้ซ้ำได้ (เช่น Tone: Neutral, Output: JSON Schema A, Safety: Basic)
- เวอร์ชัน prompt ด้วยชื่อเชิงความหมาย (email_draft_v3_compact)
- ตัวแปร AB-test: เปลี่ยนตัวแปรทีละตัว (รูปแบบเทียบกับโทนเทียบกับเกณฑ์)
- ดูแลรักษา “พิพิธภัณฑ์แห่งความล้มเหลว” ของ prompt ที่ให้ผลลัพธ์ที่ไม่ดีและเหตุผล
เมื่อใดควรเลือก Haiku 4.5 เทียบกับโมเดลที่ใหญ่กว่า
- เลือก Haiku 4.5 เมื่อคุณต้องการ: ความเร็ว การควบคุมต้นทุน การกำหนดเส้นทางงานปริมาณมาก เอาต์พุตที่มีโครงสร้าง หรือวงจรการทำซ้ำ
- เลือกรุ่นที่ใหญ่กว่าเมื่อคุณต้องการ: การให้เหตุผลแบบหลายขั้นตอนในเชิงลึก การสังเคราะห์แบบใหม่ในเอกสารที่มีสัญญาณรบกวน หรือการสร้างโค้ดที่ซับซ้อนในฐานโค้ดขนาดใหญ่
- รูปแบบไฮบริด: ใช้ Haiku 4.5 เพื่อคัดกรอง แบ่งส่วน และร่าง เพิ่มกรณีที่ยากขึ้นไปยังโมเดลที่ใหญ่กว่า
อีกอย่าง: หากคุณกำลังจัดระเบียบ prompt แบบหลายขั้นตอน พื้นที่ทำงาน AI ที่รองรับเทมเพลตที่บันทึกไว้ หน่วยความจำแบบหลายรอบต่อโครงการ และการตั้งค่า RAG ที่ง่ายดาย สามารถลดเวลาในการทำซ้ำได้อย่างมาก เครื่องมือที่ช่วยให้คุณกำหนดบทบาท ข้อจำกัด และสคีมาเอาต์พุตที่เป็นมาตรฐานใน prompt จะช่วยให้คุณปรับขนาดแนวทางปฏิบัติที่ดีที่สุดเหล่านี้ได้ทั่วทั้งทีม
เทมเพลต prompt แบบคัดลอกและวางที่คุณสามารถปรับเปลี่ยนได้ในวันนี้
- บทสรุปขนาดกะทัดรัดพิเศษ
“คุณคือ [role] เป้าหมาย: [objective]
กลุ่มเป้าหมาย: [audience] รูปแบบ: [format] ความยาว: [N คำ/โทเค็น]
ข้อจำกัด: [rules]
ส่งคืนเฉพาะเอาต์พุตสุดท้าย”
- บันทึกการตัดสินใจ
“คุณคือนักวิเคราะห์ผลิตภัณฑ์ ร่างบันทึกการตัดสินใจ
รวมส่วน: บริบท (2 ประโยค) ตัวเลือก (3 bullet) ความเสี่ยง (3 bullet) คำแนะนำ (1 ย่อหน้า) ขั้นตอนต่อไป (3 bullet) ความยาว ≤180 คำ”
- ชี้แจงแล้วตอบ
“คุณคือผู้ช่วยที่ระมัดระวัง หากงานขาดข้อมูลสำคัญ 1 ชิ้น ให้ถามคำถามที่ต้องการความกระจ่าง 1 ข้อ มิฉะนั้น ให้ตอบโดยตรงใน ≤120 คำ”
- ตัวตรวจสอบ JSON QA
“คุณคือผู้ตรวจสอบ ตรวจสอบความถูกต้องของคำตอบต่อไปนี้กับคำถาม
ส่งคืน JSON: { valid: boolean, reason: string, missing: string[] }”
- ผู้ตอบที่ยึดมั่นที่ปลอดภัย
“คุณยึดมั่น ใช้เฉพาะแหล่งที่มาที่ให้ไว้เท่านั้น หากไม่ได้รับการสนับสนุน ให้พูดว่า ‘ไม่ทราบ’ อ้างอิง ID แหล่งที่มาในวงเล็บ”
ประเด็นสำคัญ
- เฉพาะเจาะจง ไม่ยาว: บีบอัดความตั้งใจและข้อจำกัด
- โครงสร้างชนะ: ต้องการสคีมา รายการ หรือ JSON
- จำกัดการคิด: จำกัดขั้นตอน โทเค็น และขอบเขต
- ชอบตัวอย่าง: few-shot ที่สั้นและตรงเป้าหมาย
- แยกนโยบายออกจากงาน: prompt แบบแยกส่วนปรับขนาดได้ดีกว่า
- ใช้ Haiku 4.5 สำหรับงานที่ไวต่อความเร็ว ปริมาณมาก และมีโครงสร้าง และเพิ่มระดับเฉพาะเมื่อจำเป็น
ขั้นตอนต่อไป
- เปลี่ยนงานที่มีความถี่สูงสุดของคุณให้เป็นเทมเพลต prompt
- เพิ่มรายการตรวจสอบและสคีมาเอาต์พุตในทุก prompt
- AB-test สองเวอร์ชันของแต่ละ prompt เป็นเวลาหนึ่งสัปดาห์และนำผู้ชนะมาใช้
- สร้าง “ไลบรารี prompt” น้ำหนักเบาที่ทั้งทีมของคุณสามารถนำกลับมาใช้ใหม่ได้
คำถามที่พบบ่อย
Q1: Prompt ใดที่ทำงานได้ดีที่สุดกับ Claude Haiku 4.5
Prompt ที่สั้นและเฉพาะเจาะจงพร้อมบทบาท ข้อจำกัด และเอาต์พุตที่มีโครงสร้างที่ชัดเจน ใช้รายการตรวจสอบ ขีดจำกัดขั้นตอน และสคีมา JSON เพื่อเพิ่มความถูกต้องและความสอดคล้อง
Q2: ฉันจะลดการ hallucination ด้วย Haiku 4.5 ได้อย่างไร
ยึดโมเดลด้วยเฉพาะส่วนย่อยที่เกี่ยวข้องมากที่สุดและกำหนดให้อ้างอิงจากแหล่งที่มาที่ให้ไว้ หากไม่มีหลักฐาน ให้สั่งให้พูดว่า “ไม่ทราบ”
Q3: ฉันควรใช้ตัวอย่าง few-shot กับ Haiku 4.5 หรือไม่
ใช่ ให้ตัวอย่างขนาดกะทัดรัด 1–2 ตัวอย่างที่ตรงกับสไตล์และโครงสร้างที่คุณต้องการ เก็บตัวอย่างเฉพาะโดเมนและสั้นกว่าเอาต์พุตที่คุณคาดหวัง
Q4: เมื่อใดที่ฉันควรเลือก Haiku 4.5 มากกว่าโมเดลที่ใหญ่กว่า
เลือก Haiku 4.5 สำหรับงานที่รวดเร็วและคำนึงถึงต้นทุน ซึ่งได้รับประโยชน์จากโครงสร้าง: การสรุป คำตอบ RAG รายการตรวจสอบการตรวจสอบโค้ด และการร่าง ใช้โมเดลที่ใหญ่กว่าสำหรับการให้เหตุผลแบบหลายขั้นตอนที่ลึกซึ้งยิ่งขึ้น
Q5: รูปแบบเอาต์พุตที่เหมาะสมที่สุดสำหรับเวิร์กโฟลว์อัตโนมัติคืออะไร
JSON หรือ bullet ที่มีโครงสร้างแน่นหนา กำหนดคีย์ที่แน่นอน ขีดจำกัดความยาว และกฎการปฏิบัติตามข้อกำหนด เพื่อให้เอาต์พุตเข้าสู่ระบบปลายทางได้อย่างเรียบร้อย
