เขียน Prompt ให้ได้ผล: หลักการที่ใช้ได้จริง

คุณนั่งปรับ prompt ใน ChatGPT จนได้ output ที่พอใจ ตอบเป็นภาษาไทย จัด JSON ครบทุก field พอ copy ไปใส่ในสคริปต์จริงแล้วรัน — โปรแกรมกลับ crash ที่ json.loads() เปิด log ดูถึงรู้ว่าโมเดลห่อ JSON ด้วย Markdown code block (```json) ทำให้ parser พังตั้งแต่อักษรแรก นี่ไม่ใช่ bug ของโมเดล และไม่ใช่ความผิดของคุณ มันคือช่องว่างระหว่างสองสิ่งที่ฟังดูคล้ายกันแต่เป็นคนละโลก: prompt ที่ใช้ใน ChatGPT กับ prompt ที่อยู่ใน production code

ทำไม prompt เก่งใน ChatGPT พอใส่ API แล้วพัง

เวลาใช้ ChatGPT หรือ Claude ผ่านหน้าเว็บ คุณกำลังคุยกับ “product” ไม่ใช่ “model” เปล่าๆ ระหว่างทางมีของหลายอย่างทำงานให้โดยที่คุณไม่รู้ตัว: มี default system prompt ของผู้ให้บริการคอยกำกับโทน, มี Markdown renderer ที่แปลงข้อความให้สวยจนคุณไม่เห็น raw text จริง, มี temperature ค่าเริ่มต้นที่ผู้ให้บริการเลือกให้, และมี content filter เพิ่มเติม พอย้ายไป API คุณได้ “model เปล่าๆ” ที่ไม่มีของพวกนี้เลย output คือสิ่งที่โมเดลอยากตอบจริงๆ ภายใต้ instruction ที่คุณส่งไปเท่านั้น

ความต่างที่ใหญ่กว่านั้นคือ ใครเป็นคนอ่าน output ถ้าเป็นคนอ่าน format เพี้ยนนิดหน่อยก็ขอใหม่ได้ใน 5 วินาที แต่ถ้าเป็น code อ่าน — json.loads(), regex, downstream service — format เพี้ยนแปลว่า crash และเมื่อระบบรันเป็นแสนเป็นล้านครั้ง error rate แค่ 0.1% ก็คือพังหลักพันครั้ง

ลองถามตัวเองข้อเดียว: ถ้า code อ่าน output ของ prompt นี้แทนคุณ มันจะ crash ไหม? ถ้าคำตอบคือ “อาจจะ” คุณกำลังเขียน personal prompt ในที่ที่ต้องการ production prompt

Prompt คือ code ไม่ใช่เวทมนตร์

ถ้ายังคิดว่า prompt engineering คือ “ศิลปะของการพูดให้ AI ฟัง” คุณกำลังทำงานยากกว่าที่ควร ลองมองใหม่ว่า prompt ใน production คือ artifact ทาง engineering ที่ต้องดูแลเหมือน code ทั่วไป นั่นแปลว่า

• เก็บใน config file หรือ Git ไม่ hardcode ปนใน source code เพื่อให้ diff อ่านง่ายว่า PR ไหนแก้ prompt บรรทัดไหน
• มี version เช่น extract_ticket_v1, v2 ให้ track ได้ว่าเปลี่ยนอะไรเมื่อไหร่
• มี test set อย่างน้อย 10 เคส — happy path 5 เคส, edge case 5 เคส
• รัน regression ก่อน deploy เปลี่ยน prompt แล้วเคสเดิมยังผ่านไหม
• เทียบด้วย metric ไม่ใช่ความรู้สึก ไม่ใช่ “ผมว่ามันดีขึ้น”

หลักคิดนี้ตรงกับที่ทีม AI ในอุตสาหกรรมทำกันจริง และควรเริ่มสร้างเป็นนิสัยตั้งแต่ prompt แรกๆ

System prompt คือ JD ของพนักงานใหม่

System prompt คือ instruction ที่ถูกส่งไปก่อน user message ทุกครั้ง เปรียบได้กับ “job description” ของพนักงานคนหนึ่งในเซสชันนั้น ลองนึกถึงการจ้าง receptionist ด้วย JD สองแบบ แบบแรกเขียนว่า “receptionist ที่ดีของบริษัท” แบบที่สองระบุชัดว่าหน้าที่คืออะไร ห้ามทำอะไร ตอบด้วยภาษาไหน และถ้าไม่รู้คำตอบให้พูดประโยคไหนเป๊ะๆ คนที่ได้ JD แบบที่สองจะทำงานตรงและสม่ำเสมอกว่าชัดเจน

กรอบที่ใช้เขียน system prompt ได้ครบคือ RCFO — Role (โมเดลคือใคร ทำหน้าที่อะไร), Constraints (อะไรทำได้ อะไรห้าม), Format (output หน้าตาอย่างไร), Output language/edge case (ใช้ภาษาอะไร และทำอะไรเมื่อตอบไม่ได้) หลักสำคัญคือ system prompt ที่ดีต้อง measurable — อ่านแล้วบอกได้ว่า output แบบไหนถูก แบบไหนผิด ถ้าอ่านแล้วยังบอกไม่ได้ว่า “แบบไหนเรียกว่าผิด” แปลว่ามันยังหลวมเกินไป เช่น เปลี่ยนจาก “ตอบให้ดีและสุภาพ” เป็นการระบุ scope, ข้อห้าม, จำนวนย่อหน้า และประโยคสำรองเมื่ออยู่นอกขอบเขต — แบบหลังเขียน assertion ใน test ได้ทันที

Few-shot ใช้เมื่อจำเป็น ไม่ใช่ทุกครั้ง

Few-shot คือการใส่ตัวอย่างคู่ input–output ก่อนให้งานจริง เหมือนเปิดแฟ้มงานตัวอย่างให้พนักงานใหม่ดูแทนการอธิบายด้วยปาก แต่ข่าวดีคือโมเดลรุ่นใหม่ไม่ค่อยต้องการ few-shot เพื่อ reasoning แล้ว งานวิจัยปี 2025 พบว่าสำหรับโมเดลที่เก่งอยู่แล้ว บทบาทหลักของตัวอย่างคือ “จัด format ของ output ให้ตรง” ไม่ใช่ “เพิ่มความสามารถในการคิด” ดังนั้นถ้างานใช้ structured output อยู่แล้วและ instruction ชัดพอ ให้เริ่มจาก zero-shot ก่อนเสมอ ได้ผลก็จบ ประหยัด token

ถ้าจำเป็นต้องใช้ few-shot ก็ระวัง bias ที่งานวิจัย document ไว้ เช่น majority label bias (ถ้าตัวอย่างเอียงไปทาง label ใด โมเดลจะเอียงตาม) และ recency bias (ตัวอย่างตัวสุดท้ายมีอิทธิพลกว่าตัวอื่น) วิธีลดคือใช้ตัวอย่างที่ distribution สมดุลและลองสลับลำดับดูว่า output เปลี่ยนตามไหม

สิ่งที่แยก prompt มือสมัครเล่นออกจาก prompt ระดับ production ไม่ใช่ถ้อยคำสวยหรู แต่คือการมี contract, version และ test ที่วัดผลได้

หัวใจของ prompt engineering ที่ใช้ได้จริงจึงไม่ใช่การหาคำวิเศษ แต่คือการเปลี่ยน mental model จาก “เขียน prompt ให้สวย” เป็น “ออกแบบ prompt แบบวิศวกร” กำหนด contract ให้ชัด เลือกเครื่องมือ (system prompt, few-shot, structured output) ให้ตรงกับปัญหา แล้ววัดผลอย่างเป็นระบบ เมื่อนั้น prompt ของคุณจะนิ่งพอที่จะวางไว้ใน critical path ของระบบจริงได้