คู่มือสร้าง System Prompt ระดับโปรดักชันด้วย System Prompt Builder

System prompt ที่อ่อนแอคือสาเหตุเงียบ ๆ ที่ทำให้ฟีเจอร์ที่ใช้ LLM หลายตัวสร้างความผิดหวัง โมเดลก็เก่ง input จากผู้ใช้ก็ปกติ แต่คำตอบที่ได้กลับมาด้วย tone ที่ผิด ไม่ยึดกฎที่ตั้งไว้ หรือเป็นร้อยเรียงยาวเหยียดทั้งที่ต้องการ output แบบมีโครงสร้าง สาเหตุเบื้องหลังแทบทุกครั้งคือ คำสั่งถูกเขียนแบบหยั่งรู้เอา ไม่ได้ออกแบบอย่างเป็นระบบ

System Prompt Builder แก้ปัญหานี้ด้วยการเปลี่ยนการเขียน system prompt ให้เป็นการ "ประกอบจากบล็อก" แทนการพิมพ์ใหม่ตั้งแต่ต้นทุกครั้ง คุณกรอกส่วนที่แยกกันชัดเจนสำหรับ role, tone, audience, numbered constraints, output format และ few-shot examples แล้วเครื่องมือจะประกอบทุกอย่างเป็น system prompt ที่สะอาด พร้อมคัดลอกไปวางใช้ได้ทันที โดยทำงานทั้งหมดในเบราว์เซอร์ ไม่ต้องใช้ API key และไม่ต้องสมัครบัญชี

บทความนี้จะพาไปดูว่าทำไม prompt แบบมีโครงสร้างจึงชนะแบบพิมพ์สด ๆ วิธีใช้เครื่องมือทีละขั้น กายวิภาคของ system prompt ระดับโปรดักชัน และกรณีใช้งานจริงที่คุณปรับใช้ได้ทันทีในวันนี้

ทำไมต้องใช้ System Prompt Builder?

• โครงสร้างชนะการเดาสด ๆ role, tone, constraints และ format อยู่ในบล็อกแยกกัน ไม่มีอะไรจมอยู่ในก้อนข้อความยาว ๆ ทุกคำสั่งมีบรรทัดของตัวเอง และมีน้ำหนักของตัวเอง
• Numbered constraints ที่โมเดลทำตามได้ คำแนะนำคลุมเครืออย่าง "กระชับและเป็นประโยชน์" ไม่ให้อะไรที่โมเดลจับต้องได้เลย บล็อก constraints จะเปลี่ยนกฎเป็นลิสต์ตัวเลขที่โมเดลไล่ทีละข้อ ทำตาม และตรวจสอบย้อนหลังได้
• สัญญา output ที่คงเส้นคงวา บล็อก output format ระบุได้ชัดว่าคำตอบต้องมีรูปร่างแบบไหน — JSON, ตาราง markdown, bullet สรุปสั้น ๆ — โค้ด parse ปลายทางของคุณจึงไม่พังอีก
• Few-shot examples โดยไม่รกสมอง ตัวอย่างคำสั่งอย่าง "Never suggest rewriting whole files" หรือ "Reference the exact line numbers" เข้ากับบล็อก constraints ได้พอดี ส่วน few-shot examples ช่วย anchor พฤติกรรมได้ดีกว่าคำอธิบายยาว ๆ เสมอ
• ไม่มีขั้นตอนติดขัด ไม่ต้องสมัคร ไม่ต้องใช้ API และไม่มีอะไรออกจากเครื่องของคุณ เปิดเครื่องมือ สร้าง prompt แล้ววางลง ChatGPT, Claude หรือ LLM ตัวไหนก็ได้
• ปรับปรุงได้เร็วขึ้น แต่ละบล็อกแก้ไขได้อิสระ การปรับ constraint เพียงข้อเดียวจึงไม่ต้องเขียน prompt ทั้งก้อนใหม่

ฟีเจอร์หลัก

จุดที่ควรรู้เพิ่มเติม:

• ตัวประกอบสร้างผลลัพธ์เป็น plain text จึงใช้ได้ทุกที่ที่มีช่อง system prompt ทั้งหน้าแชท การเรียก API agent framework และผู้ช่วยใน IDE
• บล็อกถูกเรียงตามลำดับที่โมเดลอ่านได้ดีที่สุด คือ identity ก่อน ตามด้วยพฤติกรรม และปิดท้ายด้วย format ซึ่งช่วยให้โมเดลทำตามคำสั่งได้ดีขึ้นจับต้องได้จริง
• คำแนะนำในตัวเครื่องมืออย่าง "Never suggest rewriting whole files" ทำหน้าที่เป็นตัวอย่างว่า constraint ที่ดีหน้าตาเป็นอย่างไร คุณจึงได้เรียน prompt engineering ไปพร้อมกับการสร้างงาน

วิธีใช้งาน System Prompt Builder

1. กำหนด role เริ่มจากว่าโมเดลควรเป็นใคร เจาะจงดีกว่ากว้าง ๆ: "You are a meticulous code reviewer for a TypeScript monorepo" ให้พฤติกรรมที่คมกว่า "You are a helpful assistant" อย่างเห็นได้ชัด
2. ตั้ง tone และ audience เลือกว่าโมเดลควรฟังดูเป็นอย่างไร และกำลังคุยกับใคร prompt สำหรับวิศวกรภายในตรงไปตรงมาและเน้นเทคนิคได้ แต่ prompt สำหรับผู้ใช้ปลายทางควรอบอุ่นและไม่มีศัพท์เทคนิคเกินจำเป็น
3. เพิ่ม numbered constraints เขียนกฎเป็นประโยคสั้น ๆ ที่ตรวจสอบได้ เช่น "Reference the exact line numbers", "Limit findings to the five most critical issues", "Suggest a fix for every finding" คุณภาพสำคัญกว่าปริมาณ
4. ระบุ output format ประกาศสัญญาให้ชัด เช่น "Return findings as a markdown table with columns Severity, File, Line, Issue, Fix" แล้วโมเดลจะหยุดแต่งโครงสร้างเอง
5. คัดลอก prompt ที่ประกอบเสร็จ เครื่องมือรวมทุกอย่างเป็นข้อความพร้อมใช้ วางลงช่อง system prompt ลองกับ input ทดสอบไม่กี่ชุด แล้วค่อยปรับแต่งรายบล็อกตามจำเป็น

กายวิภาคของ System Prompt ระดับโปรดักชัน

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

Role framing ช่วยกระชับขอบเขต LLM ที่เทรนจากอินเทอร์เน็ตเป็นอะไรก็ได้ role คือสิ่งที่บอกว่าควรเปิดใช้ส่วนไหนของตัวเอง "You are a senior TypeScript reviewer" ผลักโมเดลเข้าหาภาษาแบบงานรีวิว การตัดสินความรุนแรงของปัญหา และความละเอียดระดับโค้ด role ยิ่งแคบและน่าเชื่อถือเท่าไหร่ persona ยิ่งคงเส้นคงวาเท่านั้น

Tone และ audience กำหนดระดับภาษา tone ตัดสินความยาวประโยค ความกลมกล่อม และความตรงไปตรงมา ส่วน audience ตัดสินคำศัพท์และปริมาณพื้นหลังที่ต้องอธิบาย ข้อความเดียวกันว่า "this function has a race condition" อ่านต่างกันมากระหว่าง staff engineer กับ product manager การระบุ audience ใน prompt ช่วยตัดการเดาของโมเดลออกไป

Numbered constraints ทำตามได้ แต่ย่อหน้ายาว ๆ ไม่ได้ โมเดลจัดการกับ "1. Reference exact line numbers. 2. Limit output to five findings. 3. Suggest a fix for each" ได้ดีกว่าย่อหน้าที่สื่อความเดียวกันอย่างชัดเจน ตัวเลขสร้างหน่วยที่แยกกันและตรวจสอบได้ คุณยังขอให้โมเดลตรวจทานตัวเองกับลิสต์นี้ได้อีกด้วย

สัญญา output format ทำให้คำตอบ parse ได้ ถ้ามีแอปพลิเคชันอ่าน output ของโมเดล การประกาศรูปแบบไม่ใช่เรื่องที่เลือกได้ ประโยค "respond only with JSON matching the schema below" เปลี่ยนผู้ช่วยที่ช่างพูดให้กลายเป็นคอมโพเนนต์ที่เชื่อถือได้ บล็อกนี้มีไว้เพื่อทำให้สัญญาชัดเจนโดยไม่ตีความได้

Few-shot examples anchor พฤติกรรมได้ดีกว่าคำบรรยาย ตัวอย่าง input/output ที่สมบูรณ์แบบหนึ่งชุดสื่อสไตล์ ความยาว และการจัดการ edge case ได้เร็วกว่าคำคุณศัพท์ใด ๆ สองถึงสามตัวอย่าง รวมถึงตัวอย่างที่โชว์วิธีตอบว่า "no findings" มักกำจัดปัญหา format เพี้ยนได้เกือบทั้งหมด

กรณีใช้งานจริง

ผู้ช่วยรีวิวโค้ด

ประกอบ reviewer ที่ทำงานเหมือนวิศวกรอาวุโส: role เป็น "senior TypeScript reviewer" constraints อย่าง "Reference the exact line numbers", "Never suggest rewriting whole files" และ "Limit findings to critical and high severity" จากนั้นกำหนด output เป็นตาราง markdown (Severity | File | Line | Issue | Fix) รีวิวจึงอ่านง่ายและเทียบกันได้สะดวก

การคัดแยกตั๋วซัพพอร์ต

สร้าง prompt ที่จัดหมวดตั๋วตามประเภท ความเร่งด่วน และ sentiment แล้วร่างจดหมายตอบฉบับแรก constraints อย่าง "Never invent SLA commitments" และ "Escalate billing disputes to a human" ฝังนโยบายลงใน prompt โดยตรง ส่วน output แบบ JSON ป้อนเข้าระบบ routing ได้อย่างสะอาด

การบังคับใช้สไตล์คอนเทนต์

วาง style guide ลงในบล็อก constraints เช่น กำหนดความยาวประโยค คำที่ห้ามใช้ รูปแบบหัวข้อ แล้วตั้ง tone ให้ตรงแบรนด์ few-shot examples ที่วางย่อหน้าตรงแบรนด์คู่กับย่อหน้าที่เพี้ยน ช่วยให้ร่างบทความคงน้ำเสียงเดิมทุกครั้ง

เอเจนต์สกัดข้อมูล

สำหรับการดึงฟิลด์ที่มีโครงสร้างจากข้อความรก ๆ ให้กำหนด role เป็น "extraction agent" ผูกด้วยกฎ "Return only values present in the input; use null when a field is missing" และประกาศ JSON schema ที่แน่นอน โมเดลจะเลิกมโนค่าที่ดูน่าเชื่อขึ้นมาเอง แล้วเริ่มทำงานเหมือน parser

แนวปฏิบัติที่ดีที่สุด

• เลือกประโยคบอกสิ่งที่ควรทำ "Use bullet points for findings" ถูกทำตามได้ดีกว่า "Don't write walls of text" บอกให้ชัดว่าต้องทำอะไร และสงวนคำว่า "never" ไว้กับพฤติกรรมที่เสี่ยงจริง ๆ เท่านั้น
• จำกัด constraints ไม่เกินราว 10 ข้อ ลิสต์ที่ยาวทำให้ความสนใจเจือจาง ถ้าเกินสิบข้อ ให้รวมกฎที่เกี่ยวข้องกันเข้าด้วยกัน หรือย้ายนโยบายระดับบริษัทไปไว้ในเอกสารอ้างอิงแยกต่างหาก
• ทดสอบด้วย input แบบโจทย์ยาก ลองวางไฟล์ว่าง ข้อความที่ไม่เป็นมิตร หรือคำขอนอกประเด็น แล้วดูว่า prompt ยังยืนอยู่ไหม กฎที่รอดเฉพาะเคสปกติยังไม่นับเป็นกฎ
• ทำ version ให้ prompt เก็บข้อความที่ประกอบแล้วไว้ใน version control พร้อม changelog เมื่อพฤติกรรมเปลี่ยนหลังอัปเดตโมเดล คุณจะรู้ทันทีว่า constraint ข้อไหนคือตัวการ
• หมั่นเปลี่ยน few-shot examples ตัวอย่างมีอายุตามที่ผลิตภัณฑ์ของคุณเปลี่ยนไป ตัวอย่างที่เก่าคือกำลังสอนพฤติกรรมล้าสมัยให้โมเดลอย่างเงียบ ๆ

พร้อมเลิกเดาสุ่มแล้วหรือยัง เปิด System Prompt Builder ประกอบ system prompt แรกของคุณในเวลาราวห้านาที แล้ววางลงเซสชัน LLM ถัดไปได้เลย ไม่ต้องสมัครบัญชี ไม่ต้องใช้ API มีแต่ prompt ที่ดีขึ้น

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Token Counter — เช็กว่า system prompt และ context ของคุณกิน token เท่าไรก่อนส่งของจริง
• AI Tool Schema Builder — สร้าง function-calling schema ที่จับคู่ได้ลงตัวกับ system prompt ที่มีโครงสร้างดี
• Regex Tester — ทดสอบ pattern สกัดข้อมูลสำหรับเอเจนต์ที่คุณนิยามด้วย prompt

ขอให้สนุกกับการเขียน prompt!

คำถามที่พบบ่อย

ถ: System Prompt Builder ใช้ฟรีหรือไม่? ตอบ: ฟรี เครื่องมือทำงานทั้งหมดในเบราว์เซอร์ ไม่ต้องสมัครบัญชี ไม่ต้องใช้ API key และไม่จำกัดจำนวนครั้ง ข้อความที่คุณพิมพ์ไม่ถูกส่งไปยังเซิร์ฟเวอร์ใด ๆ

ถ: prompt ที่ได้ใช้กับ LLM ตัวไหนได้บ้าง? ตอบ: ใช้ได้กับทุกโมเดลที่รับ system prompt ทั้ง ChatGPT, Claude, Gemini, โมเดล open source และ agent framework เพราะตัวประกอบสร้างผลลัพธ์เป็น plain text ที่พกพาไปได้ทุกที่

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

ถ: เก็บ prompt หลายเวอร์ชันได้อย่างไร? ตอบ: เครื่องมือไม่จัดเก็บอะไรฝั่งเซิร์ฟเวอร์ ให้คัดลอก prompt ที่ประกอบแล้วแต่ละเวอร์ชันไปเก็บในโน้ตหรือ version control ของคุณเพื่อรักษาประวัติย้อนหลัง