หลังจากที่ OpenAI เปิดตัว GPT-5.1 Series มี Auto, Instant, Thinking เมื่อคืนที่ผ่านมา ยังแจกคู่มือการ Prompt GPT-5.1 ให้กับคนทั่วไปและ Dev มีบอก Tricks ต่าง ๆ มากมาย

คู่มือการ Prompt GPT-5.1

  • GPT-5.1 เป็นรุ่นต่อจาก GPT-5 ที่เน้น
  1. ความฉลาด + ความเร็ว
  2. เก่งเป็นพิเศษกับงานแนว Agent กับ Code
  3. มีโหมด reasoning แบบใหม่ชื่อ none
  • โหมด GPT-5.1 นี้จะไม่ใช้ Reasoning Token เลย → เร็วและเบากว่า

คำแนะนำการปรับ Prompt มี 4 ข้อ

  1. Persistence
    • ปรับการใช้ Reasoning Token ได้ดีขึ้น ใช้ Token ให้ฉลาดขึ้นด้วยการตอบ คำถามง่าย ใช้น้อย / คำถามยาก ใช้เท่าที่จำเป็น
    • ปรับบุคลิก, น้ำเสียง, รูปแบบคำตอบให้เป็น Persistence และ Completeness
  2. Output formatting และความยาว
    • GPT-5.1 จะเล่าได้ละเอียดขึ้น แต่บางจังหวะก็ยาวเกินที่ต้องการ เพราะงั้นให้ specify ไปเลยว่าต้องการความละเอียดระดับไหน
    • คุณควรกำหนดใน prompt เลยว่า
      • เคสนี้ให้ตอบประมาณกี่บรรทัด / กี่ bullet
      • ให้ใช้หัวข้อไหม / ห้ามใช้หัวข้อไหม
  3. Coding agents
    • ถ้า Agent ของคุณใช้ apply_patch อยู่ แนะนำให้เปลี่ยนมาใช้เวอร์ชันใหม่ เพื่อลดโอกาส patch พังลงได้เยอะ
  4. Instruction following
    • GPT-5.1 เชื่อฟังคำสั่งดีมาก ถ้าเราสั่งไม่ชัด มันจะ “เชื่อผิดอัน”
    • แนะนำว่า ก่อนรัน ให้เช็กว่า system prompt / instructions:
      • ไม่มีคำสั่งที่ขัดกันเอง
      • อธิบายเคลียร์ว่าต้องทำอะไร “ก่อน–หลัง–ไม่ต้องทำอะไร”

รายละเอียดการ Prompt ของ GPT-5.1 แบบละเอียดและชัดเจน มีดังนี้

  1. การตั้ง บุคลิก ให้ Agent (Personality & Style)
    • การกำหนด Persona ชัดเจนว่า Agent ตัวนี้เป็นใคร ให้ Agent ทำงานได้ดีที่สุด โดยเฉพาะกรณีเป็น Customer Facing Agent ที่ต้องมี Emotional Intelligence พอจะรับมือสถานการณ์และอารมณ์ของผู้ใช้ได้หลากหลาย ว่าต้องอุ่นแค่ไหน ยาวแค่ไหน
    • ให้บอกว่า AI ตัวนี้ เป็นใคร และ ต้องทำงานแบบไหน เน้น 3 อย่าง:
      • 1. ทำงานอะไร
      • 2. บุคลิกประมาณไหน
      • 3. คุยกับใคร / ระดับไหน
    • รวมถึงเลี่ยงการพูดเยิ่นเย้อแบบ เข้าใจค่า, ขอบคุณที่สอบถาม แบบซ้ำๆ
  2. การคุมความยาวคำตอบ (Compactness rules)
    • คุณสามารถกำหนดแบบนี้ใน Prompt ได้ เช่น:
      • 1. ถ้าเปลี่ยนเป็นโค้ดเล็กๆ (≤ 10 บรรทัด):
        • ตอบ 2–5 ประโยค หรือ ≤ 3 bullet
        • ถ้าจำเป็นค่อยแปะโค้ดสั้นๆ ไม่เกิน 2–3 บรรทัด
      • 2. ถ้าเปลี่ยนระดับกลาง:
        • ใช้ไม่เกิน 6 bullet หรือ 6–10 ประโยค
      • 3. ถ้าทำหลายไฟล์:
        • สรุปเป็นไฟล์ๆ ไม่ต้องแปะโค้ดยาว
    • โดยภาพรวมแล้ว ระบุให้ชัดว่า Case ไหนตอบสั้น / Case ไหนตอบยาว
  3. การคุม “โหมดสั้นมาก” ด้วย output_verbosity_spec
    • คุณสามารถบอกโมเดลให้ตอบสั้นมากๆ แบบนี้ได้ตรงๆ:
      • พิมพ์ Prompt ไม่เกิน 2 ประโยค
      • เริ่มต้นด้วย สรุปว่าทำอะไรให้แล้ว ก่อน
      • ถ้าเกี่ยวกับโค้ด ให้พูดถึง path ของไฟล์แทนที่จะแปะโค้ดยาวๆ
  4. User updates / Preambles การให้ Agent อัปเดตสถานะ ตอนใช้ tools
    • เวลาคุณให้ Agent ทำงานยาวๆ หลายขั้นตอน เช่น แก้โค้ดทั้ง feature, รัน tools หลายตัวติดๆ กัน จะมีปัญหาว่า คนใช้ไม่รู้ว่า ตอนนี้มันทำถึงไหนแล้ว
    • เราเลยให้มี User Updates แทรกเป็นระยะๆ
    • แนวทางตั้งกติกา:
      • เรื่องความถี่และความยาว
      • ทุกๆ ไม่กี่ครั้งที่เรียก Tools ถ้ามีอะไรใหม่ → แวะอัปเดตสั้นๆ 1–2 ประโยค
      • อย่างน้อยทุก 6 หรือ 8 Steps tool call → ต้องมีอัปเดตหนึ่งครั้ง
      • ถ้ารู้ว่าจะ ก้มหน้าทำยาว
        • 1. บอกผู้ใช้ก่อนว่า: จะขอไปทำอะไร แล้วจะกลับมาสรุปเมื่อไหร่
        • 2. พอกลับมา ต้องสรุปให้ว่าไปเจออะไรมา
      • เนื้อหาที่ควรเล่า
        • 1. เวลาอัปเดต:
          • ก่อนเรียก tool ครั้งแรก → บอกแผนคร่าวๆ ว่าจะทำอะไรบ้าง
          • ระหว่างทำ → บอกสิ่งที่ค้นพบสำคัญ เช่น เจอว่า test พังที่ไฟล์ไหนแล้ว
          • ทุกครั้งต้องมี อย่างน้อย 1 อย่างที่ทำเสร็จแล้ว ไม่ใช่ เดี๋ยวจะไปทำ…
          • ตอนจบ → ทำ recap สั้นๆ + ใส่ checklist ของงานที่ตั้งใจจะทำไว้ ว่าอันไหน Done / อันไหน Cancel
        • 2. User_Update_Immediacy
          • ก่อนที่โมเดลจะไป คิดยาวๆ หรือเรียก tools เยอะๆ ให้ส่งข้อความแบบ comment สั้นๆ ก่อนเสมอ เพื่อให้ผู้ใช้รู้ว่า ตอนนี้ระบบเริ่มทำอะไรแล้วนะ
          • หรืออธิบายสิ่งที่คุณกำลังทำในข้อความแสดงความคิดเห็นเสมอ ก่อนที่จะวิเคราะห์ข้อความและคิดต่อ สิ่งนี้สำคัญมาก เพื่อให้สามารถสื่อสารกับผู้ใช้ได้ทันที
  5. Solution persistence ทำยังไงให้โมเดล ไม่ทิ้งงานกลางคัน
    • ให้มองตัวเองเป็น Senior Dev/Pair Programmer แล้วบอกโมเดลว่า:
      • 1. ไม่เอาแค่การวิเคราะห์
      • 2. แต่ให้ ลงมือทำจนจบเคส ภายในคำตอบเดียว ถ้าทำได้ โดยไม่ต้องรอให้ผู้ใช้ไล่สั่งทีละ step
      • 3. อย่าทิ้งผู้ใช้กลางทาง
    • ตัวอย่างเช่น
      • 1. เมื่อผู้ใช้ให้โจทย์มาแล้ว ให้คุณ: หาข้อมูล, วางแผน, ลงมือแก้, เช็ก, และสรุปผลให้จบในคำตอบเดียว ถ้าเป็นไปได้
      • 2. ห้ามหยุดแค่การวิเคราะห์หรือแนะนำครึ่งๆ กลางๆ
      • 3. ถ้าผู้ใช้ถามว่า “ควรทำ X มั้ย” แล้วคำตอบ คือ “ควร” ให้ลงมือเสนอ action plan หรือ draft ทันที
  6. Tool-calling การออกแบบรูปแบบการเรียก Tools
    • GPT-5.1 ไม่ปล่อยให้โมเดลเดาว่า เมื่อไหร่ต้องเรียก tool ทำตาม Pattern นี้:
    • อธิบาย tool ว่าทำอะไร
    • ระบุ ใช้เมื่อไหร่
    • ระบุ ห้ามทำอะไร
    • Tricks
      • 1. เมื่อ user ขอให้ book, reserve หรือ schedule โต๊ะ คุณต้องเรียก create_reservation ทุกครั้ง (MUST)
      • 2. ห้ามเดาเวลา หรือชื่อจองเองเด็ดขาด ถ้าข้อมูลไหนหายไป ให้ถามเอาส่วนนั้น
      • 3. ถ้า user ยังไม่ได้ให้ชื่อมา ให้ถามว่า ขอชื่อสำหรับใช้ในการจองหน่อยครับ/ค่ะ? (แทน What name should I put on the reservation?)
      • 4. ถ้า user ยังไม่ได้ให้วันที่/เวลา ให้ถามว่า อยากจองวันไหน เวลาเท่าไหร่ครับ/ค่ะ? (แทน What date and time would you like to reserve?)
      • 5. หลังจากเรียก tool แล้ว ให้ยืนยันการจองกลับ หมายถึง ตอบกลับไปแบบธรรมชาติ เช่น: จองสำเร็จแล้วนะครับ/ค่ะ เป็นชื่อ [name] เวลา [date/time]
    • ตัวอย่างเช่น
      • Example 1: User: Book a table for Sarah tomorrow at 7pm.
      • Assistant → (calls tool) →
      • {“name”: “create_reservation”, “arguments”: { “name”: “Sarah”, “datetime”: “2025-11-01T19:00” } }
      • Tool returns: { “confirmation_number”: “R12345” }
      • Assistant: “เรียบร้อยแล้ว — จองโต๊ะให้ Sarah สำหรับพรุ่งนี้เวลา 7:00pm ให้แล้วนะครับ หมายเลขยืนยันคือ R12345.”
      • Example 2:
      • User: “I want to make a reservation.”
      • Assistant: “ได้เลยครับ/ค่ะ ขอทราบชื่อสำหรับใช้จอง แล้วก็วันที่กับเวลาที่อยากจองหน่อยครับ/ค่ะ”
      • Example 3:
      • User: “Reserve a table under Daniel at 6 tonight.”
      • Assistant → (calls tool) →
      • {“name”: “create_reservation”, “arguments”: { “name”: “Daniel”, “datetime”: “2025-10-31T18:00” } }
      • Tool returns: { “confirmation_number”: “R67890” }
      • Assistant: “จัดการให้แล้วครับ/ค่ะ จองโต๊ะในชื่อ Daniel เวลา 6:00pm คืนนี้ เรียบร้อยแล้ว หมายเลขยืนยันคือ R67890.”
  7. โหมด reasoning = none
    • โหมด none คือ สั่งให้ model ไม่ใช้ Reasoning Token เลย
    • behavior จะใกล้กับรุ่นอย่าง GPT-4.1 หรือ GPT-4o มาก
    • แต่ต่างจากรุ่นเก่าว่า:
      • 1. ยังใช้ web search, file search, function calling ฯลฯ ได้ดี
      • 2. ประสิทธิภาพการเรียก Custom Tools ดีขึ้น
    • สอนให้ AI เข้าใจว่า
      • 1. ก่อนเรียก tool ให้ วางแผนคร่าวๆ ว่าจะเรียกอะไรบ้าง
      • 2. เวลาเลือกของแทน (เช่นสินค้า) ให้ verify ก่อนว่าตรงเงื่อนไขลูกค้าครบ
      • 2.1. ถูกที่สุด, ยี่ห้อที่ต้องการ, สเปกตรง ฯลฯ
      • 2.2. แล้ว quote id + ราคา กลับไปให้เห็น
  8. ดัน performance ด้านโค้ดด้วย plan tool
    • เหตุผลที่ควรมี plan tool:
      • 1. Reasoning Summary ที่อยู่ ในหัวโมเดล ตามไม่ค่อยทัน
      • 2. คนอ่าน log หรือดู trace อยากเห็น “แผนงานเป็นข้อๆ” ชัดๆ
    • หลักการคือ:
      • 1. งานระดับกลาง–ใหญ่ → อย่าให้โมเดลวิ่งมั่ว ให้มันเขียน plan 2–5 ข้อก่อน
      • 2. แต่ละข้อเป็นเป้าหมาย เช่น:
        • 1. หา root cause ของ bug
        • 2. เสนอวิธีแก้และผลกระทบ
    • ตัวอย่างคำสั่งที่ดัดแปลงได้:
      • 1. ถ้างานไม่ใช่แค่แก้ข้อความเล็กๆ ให้คุณ:
      • 2. เขียนแผนเป็นข้อๆ 2–5 ข้อ
      • ห้ามแตกเป็น micro-step อย่าง เปิดไฟล์, รัน test
      • 3. ทำตามแผนทีละข้อ โดยบอกให้ผู้ใช้รู้ว่าอยู่ข้อไหน
      • 4. ตอนจบ สรุปว่าแต่ละข้อทำเสร็จแล้วเกิดผลอะไร
  9. บังคับใช้ Design System ด้านออกแบบ Frontend/UXUI
    • ถ้าคุณมี Design System ของตัวเอง เช่น สี ปุ่ม การ์ด ฯลฯ สามารถบังคับ GPT-5.1 ให้ เล่นอยู่ในกรอบ ได้แบบนี้:
    • หลักการ:
      • 1. ห้าม hard-code สี (เช่น #FFFFFF, rgb(…) ฯลฯ)
      • 2. ให้ใช้แต่ตัวแปรจาก globals.css เช่น –background, –foreground, –primary, –accent, –border, –ring
      • 3. ถ้าจะเพิ่มสีแบรนด์:
        • 1. ไปเพิ่มตัวแปรใน :root และ .dark ก่อน เช่น –brand, –brand-foreground, –brand-muted, –brand-ring, –brand-surface
        • 2. ถ้ามี gradient / glow ให้ใช้ตัวแปร เช่น –gradient-1, –gradient-2
    • การใช้งานใน Tailwind ใช้รูปแบบ
      • 1. bg-[hsl(var(–primary))]
      • 2. text-[hsl(var(–foreground))]
      • 3. ring-[hsl(var(–ring))]
      • 4. Default ให้ใช้โทนกลางของระบบ
    • ถ้าผู้ใช้ขอหน้าตาแบบแบรนด์เฉพาะ ค่อยแมปแบรนด์นั้นกับ Token ก่อน
  10. ใช้ Metaprompt ให้ GPT ช่วยออกแบบ Prompt ตัวมันเอง
    • แทนที่เราจะเดาเองว่า ต้องแก้ System Prompt ตรงไหน ใช้ GPT-5.1 มาช่วย อ่าน Prompt + อ่าน log ที่พัง แล้ววิเคราะห์ให้
    • ตัวอย่างเช่น
      • 1. Agent วางแผนงานอีเวนต์ชื่อ GreenGather
        • มี scope ช่วยเลือกสถานที่, วางตาราง, อาหาร, การเดินทาง, งบ, ความยั่งยืน ฯลฯ
        • มี tone มืออาชีพ, สุภาพ, ไม่เยอะอารมณ์
        • มี rules เรื่องใช้ tools, ความยาวคำตอบ, การใช้หน่วย km/°C ฯลฯ
    • ปัญหาที่เจอ:
      • คำถามเล็กๆ แต่ไปเรียก tools เยอะเกิน
      • บางครั้งตอบยาวเป็น essay หลาย section
      • บางครั้งกลับถามผู้ใช้เยอะเกิน ทั้งที่ควรตัดสินใจให้
      • ใช้หน่วยผิด (เมืองยุโรปแต่ใช้ mile / °F)
    • Step 1: ให้ GPT-5.1 วิเคราะห์ว่า พังตรงไหน
    • เราส่งให้มัน:
      • system prompt ปัจจุบัน (ทั้งก้อน)
      • ชุด log ตัวอย่างที่พัง (failure traces):
        • 1. query
        • 2. Tools ที่เรียกจริง
        • 3. คำตอบสุดท้าย
        • 4. สัญญาณว่าไม่โอเค (เช่น thumbs_down, คอมเมนต์มนุษย์)
    • แล้วให้มันตอบว่า:
      • มี failure modes อะไรบ้าง เช่น ใช้ tools ไม่คงเส้นคงวา, ตอบยาว/สั้นผิดจังหวะ, unit ผิด ฯลฯ
      • อ้างบรรทัดใน system prompt ที่น่าจะทำให้เกิด behavior นั้น
      • อธิบายว่า ทำไมบรรทัดนั้นถึงมีผล
    • Step 2: ให้ GPT-5.1 เสนอ “patch” แบบเฉพาะจุด
      • เมื่อได้ analysis แล้ว:
        • 1. ส่ง system prompt เดิม + failure-mode analysis กลับเข้าไปอีกครั้ง
        • 2. ขอให้มัน:
          • ลิสต์ patch_notes สั้นๆ ว่าแก้ตรงไหน ทำไม
          • สร้าง revised_system_prompt เวอร์ชันปรับแล้ว
          • ใส่เงื่อนไข:
            • ไม่ให้รื้อ agent ใหม่ทั้งตัว
            • เน้นแก้ทีละจุด:
              • เคลียร์ว่าตอนไหนต้องใช้ tools / ตอนไหนห้าม
              • เคลียร์ว่าควรตอบสั้น/ยาวเมื่อไหร่
              • ตัดคำสั่งที่ซ้ำกันหรือขัดกันออก
      • 3. โครงและความยาวโดยรวมใกล้ของเดิม
    • หลังจากได้เวอร์ชันใหม่:
      • เอาไปเทสต์กับชุด query เดิม
      • ดูว่าพฤติกรรมดีขึ้นไหม / มีอะไร regress ไหม
      • วนทำแบบนี้ทุกครั้งที่:
        • เพิ่มความสามารถใหม่
        • เพิ่ม tools ใหม่เข้าไป

ข้อสรุป:

คู่มือ GPT-5.1 Prompt Guide ไม่ได้ใช้งานกับ Developer แต่ใช้งานกับประชาชนทั่วไป ทั้งการ Coding, Agent, Chatbot, RAG และอื่น ๆ ประยุกต์กับผลงานอื่นหรือทำ Project

Source:

OpenAI Cookbook