วิธีเขียน Prompt และคำสั่งให้ Gemini Gem แบบละเอียด

การสร้าง Gemini Gem ให้ใช้งานได้ดีไม่ได้ขึ้นอยู่กับการตั้งชื่อ Gem หรือเพิ่มไฟล์ Knowledge เพียงอย่างเดียว แต่สิ่งสำคัญที่สุดคือ Instructions และ Prompt ที่เราเขียนให้ Gem

Google แนะนำให้พิจารณาองค์ประกอบหลัก 4 ส่วนเมื่อตั้งคำสั่งให้ Custom Gem ได้แก่

• Persona — ให้ Gem รับบทบาทอะไร
• Task — ต้องการให้ทำอะไร
• Context — มีข้อมูลพื้นฐานอะไรที่ Gem ควรรู้
• Format — ต้องการคำตอบออกมาในรูปแบบใด

สำหรับการใช้งานจริงสามารถเพิ่มส่วนที่ 5 คือ

• Constraints — สิ่งที่ห้ามทำหรือเงื่อนไขที่ต้องรักษา

ดังนั้นสูตรพื้นฐานที่ใช้ได้กับ Gems ส่วนใหญ่คือ

Persona → Task → Context → Format → Constraints

ตัวอย่างแทนที่จะเขียน Instructions ว่า

“ช่วยเขียนบทความ SEO”

ควรเขียนว่า

“คุณเป็น SEO Content Writer ภาษาไทย

เมื่อได้รับ Keyword ให้ระบุ Search Intent ก่อน จากนั้นสร้างบทความสำหรับผู้เริ่มต้น ใช้ H2/H3 มี Step-by-step, FAQ และ Summary

ห้ามสร้าง Search Volume ตัวเลข หรือข้อมูลที่ไม่มี Source และห้าม Keyword Stuffing”

Gem จะเข้าใจหน้าที่ได้ชัดกว่า และผลลัพธ์แต่ละครั้งมีโอกาสสม่ำเสมอขึ้น

นอกจาก Instructions ที่บันทึกใน Gem แล้ว ยังต้องแยกให้เข้าใจว่า Prompt ที่ส่งให้ Gem ในแต่ละงาน มีหน้าที่ต่างกัน

Instructions = กติกาประจำของ Gem

Prompt = งานปัจจุบันที่ต้องการให้ Gem ทำ

ตัวอย่าง:

Instructions กำหนดว่า Gem เป็น SEO Writer

แต่ Prompt ของวันนี้คือ

“เขียนเรื่อง Gemini Gems คืออะไร”

วันพรุ่งนี้ Prompt เปลี่ยนเป็น

“เขียนเรื่อง Gemini Canvas คืออะไร”

โดยไม่ต้องเขียนกฎ SEO ใหม่ทั้งหมด

บทความนี้จะสอน วิธีเขียน Prompt และคำสั่งให้ Gemini Gem ตั้งแต่โครงสร้าง Instructions การใส่ Role, Task, Context, Format และข้อห้าม ไปจนถึงตัวอย่าง Prompt สำหรับ SEO, Coding, Learning, Business และการใช้ Knowledge Files

💎 Prompt กับ Instructions ของ Gemini Gem ต่างกันอย่างไร

ก่อนเริ่มต้องแยกสองคำนี้ให้ชัด

Instructions

เป็นกติกาหลักที่บันทึกอยู่ใน Gem

เช่น

“ใช้ภาษาไทย”

“ตอบสำหรับมือใหม่”

“ห้ามสร้างตัวเลขที่ไม่มี Source”

กติกาเหล่านี้ถูกนำกลับมาใช้ซ้ำเมื่อต้องการทำงานกับ Gem

Prompt

เป็นคำสั่งของงานแต่ละครั้ง

เช่น

“อธิบาย DNS”

หรือ

“ตรวจ Code นี้”

หรือ

“เขียนบทความเรื่อง Wi-Fi 7”

ดังนั้น Workflow ที่ดีคือ

Instructions กำหนดวิธีทำงาน

ส่วน

Prompt กำหนดงาน

① 👤 เริ่ม Instructions ด้วย Persona

Persona คือการบอก Gem ว่า

“คุณคือใคร”

ตัวอย่าง:

“คุณเป็น Technical Writer”

“คุณเป็น JavaScript Code Reviewer”

“คุณเป็นติวเตอร์ภาษาอังกฤษ”

“คุณเป็น Business Analyst”

การกำหนด Persona ช่วยให้ Gemini รู้มุมมองและ Style ที่ควรใช้

แต่ Persona เพียงอย่างเดียวยังไม่พอ

ตัวอย่างที่ไม่ดี:

“คุณเป็นผู้เชี่ยวชาญ SEO”

เพราะยังไม่รู้ว่าให้ทำอะไร

ต้องมี Task ต่อ

② 🎯 เขียน Task ให้ชัด

Task คือสิ่งที่ Gem ต้องทำเป็นประจำ

ตัวอย่าง SEO Gem:

“เมื่อได้รับ Keyword ให้สร้างบทความที่ตอบ Search Intent”

Coding Gem:

“เมื่อได้รับ Code ให้ตรวจ Bug, Security และ Error Handling”

Study Gem:

“เมื่อได้รับหัวข้อให้สอน Concept และสร้างคำถามทบทวน”

Business Gem:

“เมื่อได้รับ Report ให้สรุป Performance, Risk และ Recommendation”

Task ควรบอก Action โดยตรง

③ 🧠 เพิ่ม Context

Context คือข้อมูลเบื้องหลังที่ช่วยให้ Gem ตัดสินใจได้ดีขึ้น

ตัวอย่าง:

“กลุ่มผู้อ่านเป็นมือใหม่ที่ไม่มีพื้นฐาน Technical”

หรือ

“บริษัทขายสินค้าให้ลูกค้า SME ในประเทศไทย”

หรือ

“ผู้เรียนพูดภาษาไทยและเพิ่งเริ่มภาษาอังกฤษ”

หรือ

“Code ที่ส่งมาส่วนใหญ่เป็น JavaScript สำหรับ Web App”

Context ช่วยลดการตอบแบบกว้างเกินไป

④ 📋 กำหนด Format

Format คือการบอกว่า Output ต้องมีโครงสร้างอย่างไร

ตัวอย่าง SEO:

“ทุกบทความต้องมี

1. คำตอบหลักช่วงต้น
2. H2/H3
3. Step-by-step
4. ข้อควรระวัง
5. FAQ
6. Summary”

ตัวอย่าง Code Review:

“ผล Review ต้องแบ่ง

• Critical
• High
• Medium
• Low”

ตัวอย่าง Business:

“ตอบเป็น

• Executive Summary
• Findings
• Risks
• Recommendations”

Format ที่ชัดช่วยให้ Gem ตอบสม่ำเสมอมากขึ้น

⑤ 🚫 เพิ่ม Constraints

แม้ Google จะเน้น Persona, Task, Context และ Format แต่การใช้งานจริงควรเพิ่ม Constraints ด้วย

Constraints คือสิ่งที่

• ห้ามทำ
• ต้องรักษา
• ต้องตรวจ

ตัวอย่าง:

“ห้ามสร้างราคา”

“ห้ามสร้าง Source ที่ไม่มีจริง”

“ห้ามเปลี่ยน Fact”

“ห้าม Rewrite Code ทั้งหมด”

“หากไม่มีข้อมูลให้บอกว่าไม่พบข้อมูล”

“ห้ามรับประกันอันดับ Google”

ส่วนนี้สำคัญมากสำหรับลดพฤติกรรม AI ที่เราไม่ต้องการ

⑥ 🧱 สูตร Instructions ที่แนะนำ

ใช้ Template นี้ได้กับ Gems เกือบทุกประเภท:

Role:
คุณคือ...

Goal:
หน้าที่หลักคือ...

Context:
ผู้ใช้/กลุ่มเป้าหมายคือ...

Process:
เมื่อได้รับงาน ให้ทำตามขั้นตอน...

Output:
ตอบในรูปแบบ...

Constraints:
ห้าม...
หากข้อมูลไม่พอให้...

ไม่จำเป็นต้องใช้คำภาษาอังกฤษเหล่านี้จริง ๆ

แต่การแบ่ง Section ช่วยให้เราอ่านและแก้ Instructions ง่ายขึ้น

⑦ ✍️ ตัวอย่าง Instructions ที่สั้นเกินไป

ตัวอย่าง:

คุณเป็น SEO Writer ช่วยเขียนบทความดี ๆ

ปัญหาคือไม่รู้ว่า

• เขียนภาษาอะไร
• กลุ่มผู้อ่านใคร
• Structure แบบไหน
• Search Intent อย่างไร
• ห้ามทำอะไร
• Fact ต้องตรวจไหม

Gem ต้องเดาเองเยอะ

⑧ ✅ ปรับ Instructions ให้ชัดขึ้น

ตัวอย่าง:

คุณเป็น SEO Content Writer ภาษาไทย

หน้าที่:
เขียนบทความที่ตอบ Search Intent ของ Keyword ที่ผู้ใช้ให้

กลุ่มผู้อ่าน:
ผู้ใช้ทั่วไปและผู้เริ่มต้น

โครงสร้าง:
1. ตอบคำถามหลักช่วงต้น
2. อธิบาย Concept
3. Step-by-step เมื่อเหมาะสม
4. Common Problems
5. FAQ
6. Summary

ข้อกำหนด:
- ใช้ภาษาธรรมชาติ
- หลีกเลี่ยง Keyword Stuffing
- ห้ามสร้าง Search Volume
- ห้ามสร้างสถิติที่ไม่มี Source
- ห้ามรับประกันอันดับ Google

Gem จะมีกรอบการทำงานชัดกว่ามาก

⑨ 🎯 Instructions ควรเฉพาะเจาะจงแค่ไหน

ควรเฉพาะเจาะจงเท่าที่จำเป็นต่อ Repeatable Workflow

ไม่จำเป็นต้องบอกทุกอย่างเกี่ยวกับทุกงาน

ตัวอย่างหาก Gem ใช้เขียนบทความ IT เท่านั้น

กำหนด:

“กลุ่มผู้อ่านเป็นผู้เริ่มต้นด้าน IT”

ได้

แต่ไม่จำเป็นต้องเขียนกฎเกี่ยวกับ

• สูตรอาหาร
• ท่องเที่ยว
• Finance

เพราะอยู่นอก Scope

หลักคือ

Specific enough to guide, not bloated enough to conflict

⑩ 🧩 อย่าใส่ Instructions ที่ขัดกันเอง

ตัวอย่าง:

“ตอบให้ละเอียดมากที่สุด”

แต่บรรทัดถัดไป:

“ทุกคำตอบต้องไม่เกิน 100 คำ”

สองกติกานี้อาจขัดกัน

หรือ

“ห้ามถามคำถามกลับ”

แต่

“ถ้าข้อมูลไม่ครบให้ถามก่อน”

ควรระบุ Priority ให้ชัด

เช่น

“ถ้าข้อมูลสำคัญไม่ครบ ให้ถามก่อน แม้ว่าปกติจะตอบโดยตรง”

Instructions ที่ไม่ขัดกันจะช่วยลด Output ที่ไม่แน่นอน

⑪ 📐 กำหนดลำดับความสำคัญ

หากมีหลายกฎ สามารถบอก Priority

ตัวอย่าง:

ลำดับความสำคัญ:

1. ความถูกต้องของข้อมูล
2. ใช้ข้อมูลจาก Knowledge
3. ตอบ Search Intent
4. ความครบถ้วน
5. ความกระชับ

ถ้า Source ไม่พอ Gem จะรู้ว่าความถูกต้องสำคัญกว่าการพยายามตอบให้ครบทุกข้อ

⑫ 🛑 สั่งให้หยุดเดาเมื่อข้อมูลไม่พอ

นี่เป็น Constraint ที่มีประโยชน์มาก

ตัวอย่าง:

“หาก Knowledge ไม่มีข้อมูล ให้ตอบว่าไม่พบข้อมูลใน Source และอย่าสร้างคำตอบขึ้นเอง”

หรือ

“หากผู้ใช้ไม่ได้ให้ราคา อย่าประมาณราคา”

หรือ

“หาก Requirement สำคัญหาย ให้ถามเฉพาะข้อมูลที่จำเป็น”

ช่วยลด Hallucination

⑬ ❓ กำหนดเมื่อไรให้ Gem ถามกลับ

ไม่ใช่ทุก Task ต้องถาม

ตัวอย่าง:

ถ้า Prompt คือ

“อธิบาย DNS”

Gem สามารถตอบได้ทันที

แต่ถ้า Prompt คือ

“เขียน Proposal”

และไม่มี

• Scope
• Budget
• Timeline

อาจควรถาม

ดังนั้น Instructions สามารถเขียนว่า:

“ถามคำถามกลับเฉพาะเมื่อข้อมูลที่ขาดมีผลต่อความถูกต้องของงานอย่างมีนัยสำคัญ”

ช่วยลดการถามมากเกินไป

⑭ 🗣️ กำหนด Tone

สามารถระบุ Tone เช่น

• Professional
• Friendly
• Formal
• Casual
• Educational
• Concise

ตัวอย่าง:

“ใช้ Tone Friendly Professional ไม่ใช้ภาษาขายเกินจริง”

หรือ

“อธิบายแบบครูที่ใจเย็นและใช้คำง่าย”

Tone ควรสอดคล้องกับ Audience

⑮ 🇹🇭 กำหนดภาษา

ถ้าต้องการให้ Gem ตอบภาษาไทยทุกครั้ง ให้เขียนชัด

“ตอบเป็นภาษาไทย เว้นแต่ผู้ใช้ขอภาษาอื่น”

หรือถ้าเป็น English Tutor:

“คำอธิบาย Grammar เป็นภาษาไทย แต่ตัวอย่างประโยคเป็นภาษาอังกฤษ”

ช่วยลดการสลับภาษาโดยไม่ตั้งใจ

⑯ 🧑‍🎓 กำหนดระดับผู้อ่าน

คำว่า

“อธิบายให้ง่าย”

ยังตีความได้หลายแบบ

ดีกว่าระบุ:

“อธิบายสำหรับผู้เริ่มต้นที่ไม่เคยเรียนเรื่องนี้มาก่อน”

หรือ

“อธิบายสำหรับ Developer ที่มีประสบการณ์ JavaScript 2 ปี”

ระดับผู้ใช้ส่งผลต่อ

-ศัพท์

• ความละเอียด
• ตัวอย่าง

โดยตรง

⑰ 📏 กำหนดความยาว

ถ้าต้องการ Consistency สามารถกำหนด Length

เช่น

“คำตอบทั่วไปไม่เกิน 500 คำ เว้นแต่ผู้ใช้ขอรายละเอียด”

หรือ

“Product Description ไม่เกิน 150 คำ”

หรือ

“Summary ไม่เกิน 5 Bullet”

แต่ไม่ควรกำหนดความยาวแคบเกินจนเสียข้อมูลสำคัญ

⑱ 🧱 กำหนด Heading Structure

สำหรับ Gem เขียน Content สามารถบอกว่า

“ใช้ H2 สำหรับหัวข้อหลัก และ H3 สำหรับหัวข้อย่อย”

หรือ

“ไม่ใช้ Heading มากกว่า 3 ระดับ”

ช่วยให้ Article Structure คงที่

โดยเฉพาะเมื่อนำ Content ไปใช้ใน CMS

⑲ 📝 กำหนด Style ของประโยค

ตัวอย่าง:

“ใช้ประโยคสั้น อ่านง่าย”

“หลีกเลี่ยงศัพท์ Technical หากไม่อธิบาย”

“อย่าเปิด Paragraph ด้วยคำเดิมซ้ำ”

“หลีกเลี่ยงภาษาการตลาดเกินจริง”

เหมาะกับ Content Gem

แต่ไม่ควรใส่ Style Rules จำนวนมากจนคุณภาพเนื้อหาถูกบีบเกินไป

⑳ 🔍 กำหนด Fact-check Behavior

สามารถเขียน:

“ถ้าคำตอบมี

• ราคา
• วันที่
• สถิติ
• Version
• กฎหมาย
• Product Feature

ให้ระบุว่าต้องตรวจ Source ล่าสุดก่อนนำไปเผยแพร่ หากไม่มี Source ที่ยืนยัน”

เหมาะมากกับงานที่ข้อมูลเปลี่ยนเร็ว

㉑ 📚 วิธีสั่ง Gem ให้ใช้ Knowledge

ถ้ามี Knowledge Files ควรเขียนวิธีใช้ไว้ด้วย

ตัวอย่าง:

“สำหรับข้อมูลสินค้า ให้ใช้ Knowledge Files เป็น Source หลัก”

หรือ

“หาก Answer อยู่ใน Knowledge ให้ยึด Knowledge มากกว่าความรู้ทั่วไป”

หรือ

“ถ้า Knowledge ไม่มีคำตอบ ห้ามเดา”

แค่ Upload Files อย่างเดียวอาจไม่พอสำหรับ Workflow ที่ต้องการ Grounding เคร่งครัด

㉒ 📎 ใช้ Citation จาก Knowledge

Google รองรับ Knowledge Citations ในคำตอบของ Gem

ถ้างานต้องตรวจ Source สามารถกำหนดใน Instructions:

“เมื่อใช้ข้อมูลจาก Knowledge ให้รักษา Citation ที่ระบบแสดงไว้”

เหมาะกับ

• Policy
• Manual
• Research
• Product Information

ช่วยให้ตรวจกลับได้ง่าย

㉓ ☁️ Prompt สำหรับ Gem ที่ใช้ Google Drive

สมมติมี Brand Guide ใน Drive

Instructions:

ใช้ Brand Guidelines ใน Knowledge เป็น Source หลักสำหรับ Tone และ Style

หาก User Request ขัดกับ Brand Guidelines ให้แจ้ง Conflict ก่อนเขียน

อย่าสร้าง Brand Rule ที่ไม่มีใน Knowledge

Gem จะมีกรอบใช้ไฟล์ชัดกว่าการบอกเพียง

“อ่านไฟล์นี้”

㉔ 🪄 ใช้ Gemini ช่วย Rewrite Instructions

Google มีตัวเลือก Use Gemini to rewrite instructions

Workflow:

① เขียนเป้าหมาย 1–2 ประโยค
② ใช้ Gemini Rewrite
③ อ่าน Instructions ที่ได้
④ ตัดสิ่งที่ไม่ต้องการ
⑤ เพิ่ม Constraints
⑥ Preview
⑦ Save

เหมาะกับมือใหม่ที่ยังไม่รู้จะ Structure Instructions อย่างไร

㉕ ⚠️ อย่าเชื่อ Instructions ที่ Gemini Rewrite 100%

Gemini สามารถช่วยขยายคำสั่ง แต่บางครั้งอาจเพิ่ม

• Rule ที่ไม่ได้ต้องการ
• Assumption
• Output Format
• Tone

ที่ไม่ตรงกับงาน

ดังนั้นต้อง Review เหมือน Code ที่ AI สร้าง

หลักคือ

AI Draft → Human Edit

㉖ 👀 ใช้ Preview เพื่อ Test Instructions

Google มี Preview ทางด้านขวาของ Gem Builder

ใช้ส่ง Prompt ทดลอง

ตัวอย่าง:

“Wi-Fi 7 คืออะไร”

แล้วดูว่า Gem

• ใช้ภาษาไทยหรือไม่
• Structure ถูกไหม
• ตอบ Intent ไหม
• ทำตามข้อห้ามไหม

ถ้าไม่ตรง ให้แก้ Instructions แล้ว Test ใหม่

㉗ 💾 อย่าลืม Save หลัง Preview

Google ระบุชัดว่า

Preview ไม่ได้ Save Gem อัตโนมัติ

ดังนั้นหลังแก้และ Test แล้วต้องกด

Save

ทุกครั้งที่ต้องการเก็บ Version ใหม่ของ Gem

นี่เป็นข้อผิดพลาดเล็ก ๆ ที่ทำให้หลายคนคิดว่าแก้ Instructions แล้ว แต่พอกลับมาใช้จริงยังเป็น Version เดิม

㉘ 🧪 Test Prompt อย่างน้อย 5 ประเภท

Gem ที่ดีไม่ควร Test ด้วย Prompt เดียว

ลองอย่างน้อย:

Normal

งานปกติ

Short

ข้อมูลสั้น

Missing Information

ข้อมูลไม่ครบ

Out-of-scope

ถามนอกหน้าที่

Knowledge Gap

ถามข้อมูลที่ไม่มีใน Source

ถ้าพฤติกรรมถูกต้องหลายกรณี Gem จึงเริ่มพร้อมใช้จริง

㉙ 🎯 Prompt ที่ส่งให้ Gem ควรเขียนอย่างไร

เมื่อ Instructions ดีแล้ว Prompt รายวันไม่จำเป็นต้องยาว

แต่ควรระบุสิ่งที่เปลี่ยนไปใน Task

สูตร:

Task-specific goal + Input + Extra constraints

ตัวอย่าง SEO Gem:

“เขียนเรื่อง Gemini Gems คืออะไร สำหรับผู้เริ่มต้น ความยาวประมาณ 2,000 คำ”

Rules อื่นอยู่ใน Gem อยู่แล้ว

㉚ 🚫 อย่าใส่ Instructions เดิมซ้ำในทุก Prompt

ถ้า Gem บันทึกไว้ว่า

• ภาษาไทย
• H2/H3
• FAQ
• Summary

แล้ว Prompt ใหม่ไม่จำเป็นต้องเขียนทั้งหมดอีก

ไม่เช่นนั้นประโยชน์ของ Gems จะลดลง

Prompt ควรเน้นข้อมูลเฉพาะงาน

㉛ ➕ แต่ Prompt สามารถ Override บางอย่างได้

สมมติ Instructions ปกติให้เขียน 2,000 คำ

แต่ครั้งนี้ต้องการสั้น

Prompt:

“หัวข้อนี้ทำฉบับสั้นประมาณ 700 คำ”

Gem สามารถใช้ Requirement ของ Task ปัจจุบันร่วมกับ Instructions

เพื่อความชัดเจนสามารถเขียนใน Instructions ว่า

“หากผู้ใช้ระบุ Format หรือ Length เฉพาะใน Prompt ปัจจุบัน ให้ใช้ Requirement นั้นแทนค่า Default”

㉜ 📦 Default กับ Override

แนวคิดที่ดีสำหรับ Gem คือ

Instructions

เป็น Default

User Prompt

Override ได้เมื่อระบุชัด

ตัวอย่าง:

Default:

“ตอบภาษาไทย”

แต่ User:

“ตอบเป็นภาษาอังกฤษสำหรับงานนี้”

ถ้าต้องการรองรับแบบนี้ ให้ระบุใน Gem ว่า User สามารถ Override Language ได้

㉝ 🔁 Prompt งานซ้ำควรสั้นมากได้

ตัวอย่างมี Product Writer Gem

Prompt แรก:

Product:
Router ABC

Features:
Wi-Fi 7
2.5GbE
Mesh

Audience:
บ้านขนาดกลาง

Gem ใช้ Instructions เดิมสร้าง Description

Product ถัดไปก็เพียงเปลี่ยนข้อมูล

นี่คือ Use Case ที่ Gems ทำได้ดีมาก

㉞ 🧱 ใช้ Template Prompt ร่วมกับ Gem

แม้มี Instructions แล้ว สามารถสร้าง Prompt Template สำหรับ Input ที่เปลี่ยน

ตัวอย่าง:

Topic:
[หัวข้อ]

Primary Audience:
[กลุ่มผู้อ่าน]

Goal:
[เป้าหมาย]

Special Requirements:
[เงื่อนไขเฉพาะ]

ช่วยให้ผู้ใช้หลายคนในทีมส่ง Input ในรูปแบบเดียวกัน

㉟ 📋 Structured Input ช่วยลดความกำกวม

ตัวอย่างแทน

“เขียน Product นี้ให้ดี”

ใช้

Product name:
...

Key features:
...

Target customer:
...

Tone:
...

Length:
...

Gem ไม่ต้องเดาว่าส่วนไหนคือชื่อสินค้าและส่วนไหนคือ Feature

เหมาะกับ Workflow ที่ต้องใช้ซ้ำจำนวนมาก

㊱ ✍️ Prompt สำหรับ SEO Writer Gem

Keyword:
Gemini Canvas

Search intent:
Informational

Audience:
Beginner

Special requirement:
อธิบายวิธีเริ่มใช้แบบ Step-by-step

Instructions ถาวรของ Gem ดูแล

• Language
• Structure
• FAQ
• Fact rules

อยู่แล้ว

㊲ 🔍 Prompt สำหรับ SEO Outline Gem

Keyword:
Wi-Fi 7

สร้างเฉพาะ Outline

ต้องครอบคลุม:
- คืออะไร
- ต่างจาก Wi-Fi 6
- อุปกรณ์ที่ต้องใช้
- เหมาะกับใคร

ถ้า Gem ถูกตั้งไว้สำหรับ SEO Planning อยู่แล้ว ไม่ต้องเขียนว่า “วิเคราะห์ Intent” ซ้ำหาก Instructions มีอยู่แล้ว

㊳ 👨‍💻 Prompt สำหรับ Code Reviewer Gem

Language:
JavaScript

Goal:
ตรวจ Function นี้ก่อนนำขึ้น Production

Code:
[วางโค้ด]

Gem Instructions อาจกำหนดไว้แล้วว่า

• Bug
• Security
• Performance
• Error Handling

ต้องตรวจทุกครั้ง

㊴ 🐞 Prompt สำหรับ Debug Gem

Problem:
กด Submit แล้วไม่มี Response

Expected:
แสดง Success Message

Actual:
ไม่มีอะไรเกิดขึ้น

Console:
[วาง Error]

Gem สามารถใช้ Workflow Debug ที่บันทึกไว้โดยไม่ต้องอธิบายใหม่ว่าให้หา Root Cause ก่อน

㊵ 🎓 Prompt สำหรับ Study Tutor Gem

Topic:
DNS

Goal:
ฉันต้องการเข้าใจพื้นฐานก่อนเรียน Network Troubleshooting

Gem Instructions อาจบอกไว้แล้วว่า

• อธิบายง่าย
• มี Example
• Quiz 3 ข้อ
• ไม่เฉลยก่อน

จึงไม่ต้องใส่รายละเอียดเหล่านั้นซ้ำ

㊶ 🇬🇧 Prompt สำหรับ English Tutor Gem

Check this sentence:

I has been working here since 2020.

Gem Instructions อาจกำหนดให้

① แก้ Grammar
② แสดงประโยคที่ถูก
③ อธิบายเป็นภาษาไทย
④ ให้ตัวอย่างเพิ่ม

ได้โดยอัตโนมัติ

㊷ 💼 Prompt สำหรับ Business Analyst Gem

ใช้ Report ที่แนบ

วิเคราะห์เฉพาะ:
- Revenue
- Gross margin
- Customer growth
- Main risk

เปรียบเทียบกับเดือนก่อน

Gem Instructions อาจกำหนด Format Executive Summary ไว้แล้ว

㊸ 📣 Prompt สำหรับ Social Media Gem

Platform:
Facebook

Product:
Wi-Fi Router ABC

Key message:
ติดตั้งง่าย เหมาะกับบ้าน

CTA:
สอบถามข้อมูลเพิ่มเติม

Gem จะใช้ Tone และข้อห้ามจาก Instructions

เช่นห้ามสร้างราคาเอง

㊹ 🛍️ Prompt สำหรับ Product Writer Gem

Product:
Access Point XYZ

Features:
- Wi-Fi 6
- PoE
- Ceiling mount

Audience:
สำนักงานขนาดเล็ก

Gem ควรเขียนเฉพาะจากข้อมูลที่ให้และ Knowledge

ไม่ควรเพิ่ม

• ราคา
• จำนวน User
• Coverage

ถ้าไม่ได้มี Source

㊺ 📧 Prompt สำหรับ Email Gem

Purpose:
ขอเลื่อนประชุม

Old date:
วันพุธ

New date:
วันศุกร์

Reason:
ติดงานลูกค้า

Gem Instructions ควบคุม

• Professional Tone
• Subject
• Length
• Closing

อยู่แล้ว

㊻ 🔬 Prompt สำหรับ Research Review Gem

ตรวจ Report ที่แนบ

เน้น:
- Claims ที่ไม่มี Citation
- Numbers
- Dates
- Forecast
- Limitations

ยังไม่ต้อง Rewrite

ช่วยแยก Review ออกจาก Editing

㊼ 🔐 Prompt สำหรับ Security Review Gem

Review Code นี้ก่อน Deploy

Environment:
Web Application

Focus:
- Secrets
- XSS
- Authentication
- Authorization
- Input validation

Instructions ของ Gem สามารถกำหนด Severity และวิธีรายงานไว้ล่วงหน้า

㊽ 🧠 สั่ง Gem ให้คิดเป็นขั้นตอนโดยไม่ต้องขอเหตุผลภายใน

ไม่จำเป็นต้องสั่ง AI ว่า

“แสดงความคิดทั้งหมดทีละขั้น”

สำหรับงานที่ต้องการความแม่น ควรสั่งผลลัพธ์ที่ตรวจสอบได้แทน เช่น

“ระบุ Assumptions”

“แสดง Formula”

“แสดง Test Cases”

“บอก Source ที่ใช้”

“อธิบายเหตุผลสั้น ๆ ของ Recommendation”

ช่วยให้ตรวจคำตอบได้โดยไม่ต้องพึ่งกระบวนการภายในของโมเดล

㊾ 📊 ขอ Evidence แทนคำตอบกว้าง ๆ

ตัวอย่าง:

ไม่ดี:

“วิเคราะห์ว่าบริษัทเป็นอย่างไร”

ดีกว่า:

“สำหรับทุก Finding ให้ระบุข้อมูลหรือ Metric ใน Report ที่รองรับ Finding นั้น”

นี่ช่วยให้ Gem ผูก Conclusion กับ Evidence มากขึ้น

㊿ 🔢 งานตัวเลขควรกำหนด Formula

ตัวอย่าง Instructions:

“ถ้ามีการคำนวณ Percentage Change ให้แสดง

(New – Old) / Old × 100

พร้อมค่าที่นำมาใช้”

ลดความเสี่ยงจาก Calculation ที่ตรวจสอบไม่ได้

51 ⚠️ Prompt ยาวกว่าไม่ได้หมายความว่าดีกว่าเสมอ

Prompt ที่ดีคือ ชัด

ไม่จำเป็นต้องยาว

ตัวอย่าง 500 คำที่มี Rule ซ้ำและขัดกันอาจแย่กว่า Prompt 100 คำที่ Structure ดี

เน้น

• Information Gain
• Explicit Requirements
• Clear Scope

มากกว่าจำนวนคำ

52 🧹 ลบ Instructions ที่ซ้ำกัน

ถ้า Gem มี

“ตอบแบบกระชับ”

หลายจุด

หรือ

“ห้ามสร้างข้อมูล”

ซ้ำ 5 รอบ

ควรรวมให้เหลือกฎเดียวที่ชัด

Instructions ที่อ่านง่ายจะดูแลและปรับ Version ได้ง่ายกว่า

53 🧩 แยก Gem เมื่อ Rules เริ่มขัดกัน

ตัวอย่าง Gem เดียวต้อง

• เขียนบทความยาว
• เขียน Caption สั้น
• Review Code
• แปลภาษา

Instructions จะซับซ้อนเร็วมาก

ควรแยก

• SEO Writer
• Social Writer
• Code Reviewer
• Translator

แต่ละ Gem มี Scope เดียวชัดเจน

54 🔄 Refine Gem จาก Error ที่เกิดจริง

ถ้า Gem ทำผิดแบบเดิมซ้ำ ให้แก้ Instructions

ตัวอย่าง:

ปัญหา

ชอบสร้างราคา

เพิ่มกฎ

“หากไม่มีราคาใน Input หรือ Knowledge ให้ไม่กล่าวถึงราคา”

ปัญหา

ชอบ Rewrite Code ทั้งหมด

เพิ่มกฎ

“แก้เฉพาะส่วนที่เกี่ยวข้องกับ Root Cause เว้นแต่ผู้ใช้ขอ Full Rewrite”

นี่คือการทำ Prompt Engineering จากพฤติกรรมจริง

55 🧪 สร้าง Regression Test สำหรับ Gem

เก็บ Prompt ตัวอย่าง 5–10 ชุดไว้

ทุกครั้งที่แก้ Instructions ให้ Test Prompt เดิม

เช่น:

• Normal
• Missing Data
• Out-of-scope
• Long Input
• Knowledge Gap

ถ้าแก้กฎใหม่แล้ว Prompt เก่าพัง แสดงว่าเกิด Regression

แนวคิดนี้เหมือน Testing Software

56 📊 วัดว่า Gem ดีขึ้นหรือไม่

กำหนด Criteria เช่น

• Instruction compliance
• Accuracy
• Relevance
• Format consistency
• Hallucination
• Length
• Need for manual editing

ใช้ Prompt Test เดิมแล้วเปรียบเทียบ Version

ช่วยปรับ Gem แบบมีหลักฐานมากกว่าความรู้สึก

57 🏷️ Version Instructions

ถ้า Gem สำคัญกับงานบริษัท ควรเก็บ Version ของ Instructions แยกไว้

เช่น

SEO Writer Instructions v1
SEO Writer Instructions v2
SEO Writer Instructions v3

เพื่อรู้ว่า Rule ไหนถูกเพิ่มเมื่อไร

โดยเฉพาะเมื่อหลายคนช่วยปรับ Gem

58 👥 Instructions สำหรับ Gem ที่แชร์ให้ทีม

ควรหลีกเลี่ยงข้อความเช่น

“ทำแบบที่ฉันชอบ”

เพราะคนอื่นไม่รู้ว่าหมายถึงอะไร

เปลี่ยนเป็นกฎ Explicit เช่น

“ใช้ประโยคเฉลี่ยไม่ยาวเกิน 25 คำ”

หรือ

“ใช้ Tone Friendly Professional”

หรือ

“ไม่ใช้คำว่าอันดับ 1 หากไม่มีหลักฐาน”

ยิ่ง Rule ชัด ทีมยิ่งใช้ Gem ได้สม่ำเสมอ

59 🔐 อย่าใส่ Secret ใน Instructions

Instructions ไม่ใช่ที่เก็บ

• Password
• API Key
• Private Token
• Credential

โดยเฉพาะ Gem ที่แชร์ให้คนอื่น เพราะผู้มี Access อาจเห็น Instructions และ Knowledge ที่เกี่ยวข้องตามระบบ Sharing

ใช้ Secret Management ที่เหมาะสมแทน

60 🚀 Workflow เขียน Instructions ที่แนะนำ

ใช้ลำดับนี้:

① เลือก Repeatable Task

เช่น SEO Writer

② กำหนด Persona

ใคร

③ กำหนด Task

ทำอะไร

④ เพิ่ม Context

ทำให้ใคร/สถานการณ์อะไร

⑤ กำหนด Format

ผลลัพธ์หน้าตาอย่างไร

⑥ เพิ่ม Constraints

ห้ามอะไร

⑦ เพิ่ม Knowledge

ถ้าจำเป็น

⑧ Preview

ทดลอง

⑨ Test หลาย Prompt

หาจุดอ่อน

⑩ Refine

แก้ Instructions

⑪ Save

บันทึก

หลังใช้งานจริงให้วน

Use → Observe → Refine → Retest

⚠️ ข้อผิดพลาดที่พบบ่อยเวลาเขียน Prompt ให้ Gemini Gem

❌ ① มีแต่ Persona

ไม่บอก Task

❌ ② Task กว้างเกินไป

Gem ต้องเดา

❌ ③ ไม่มี Context

คำตอบไม่ตรงผู้ใช้

❌ ④ ไม่กำหนด Format

Output เปลี่ยนไปทุกครั้ง

❌ ⑤ ไม่มี Constraints

AI เติมข้อมูลเอง

❌ ⑥ Rules ขัดกัน

Gem ตัดสินใจยาก

❌ ⑦ Upload Knowledge แต่ไม่บอกวิธีใช้

Gem อาจตอบนอก Source

❌ ⑧ Prompt รายวันใส่ Rules เดิมซ้ำทั้งหมด

เสียประโยชน์ของ Gem

❌ ⑨ Test Prompt เดียว

ไม่เห็น Edge Case

❌ ⑩ Preview แล้วลืม Save

การแก้ Instructions ไม่ถูกบันทึก

✅ Checklist Instructions ของ Gemini Gem

ก่อน Save ตรวจว่า Gem มี

① Persona
② Task
③ Context
④ Output Format
⑤ Constraints
⑥ Language
⑦ Tone
⑧ Scope
⑨ Behavior เมื่อข้อมูลไม่ครบ
⑩ Behavior เมื่อถามนอก Scope
⑪ วิธีใช้ Knowledge
⑫ สิ่งที่ห้ามเดา

ไม่จำเป็นต้องใส่ทุกข้อในทุก Gem แต่ Gem สำคัญควรตอบคำถามเหล่านี้ได้

✅ Checklist Prompt ที่ส่งให้ Gem แต่ละครั้ง

Prompt งานใหม่ควรมี

① งานที่ต้องการ
② Input
③ เป้าหมาย
④ Requirement เฉพาะงาน
⑤ Source/ไฟล์ที่เกี่ยวข้อง
⑥ Override จาก Default หากมี

ไม่ต้อง Copy Instructions ถาวรทั้งหมดซ้ำ

✅ Checklist ทดสอบ Gem

ลอง Prompt แบบ

① ปกติ
② สั้น
③ ข้อมูลไม่ครบ
④ กำกวม
⑤ ยาว
⑥ นอก Scope
⑦ ไม่มีคำตอบใน Knowledge
⑧ มีข้อมูลขัดกัน
⑨ ต้องใช้ Format เฉพาะ
⑩ ต้อง Override Default

แล้วดูว่า Gem ตอบตามที่ออกแบบไว้หรือไม่

❓ คำถามที่พบบ่อยเกี่ยวกับการเขียน Prompt ให้ Gemini Gem

Gemini Gem ควรเขียน Prompt อย่างไร

ใช้ Instructions กำหนดกฎถาวร และใช้ Prompt แต่ละครั้งระบุงานและข้อมูลเฉพาะของ Task นั้น

Google แนะนำโครงสร้าง Instructions แบบไหน

Google แนะนำ 4 ส่วนหลัก ได้แก่ Persona, Task, Context และ Format

ต้องใช้ครบทั้ง 4 ส่วนไหม

ไม่จำเป็น Google ระบุว่าไม่จำเป็นต้องใช้ครบทุกส่วน แต่การใช้หลายองค์ประกอบช่วยให้คำสั่งมีรายละเอียดและตรงเป้าหมายขึ้น

ควรเพิ่ม Constraints ไหม

แนะนำสำหรับงานจริง โดยเฉพาะสิ่งที่ห้าม AI เดา สร้าง หรือเปลี่ยน

Instructions ควรยาวแค่ไหน

ไม่มีจำนวนคำตายตัว ควรยาวเท่าที่จำเป็นเพื่อให้ Role, Task, Context, Format และข้อจำกัดชัด โดยหลีกเลี่ยงกฎซ้ำหรือขัดกัน

ให้ Gemini เขียน Instructions ให้ได้ไหม

ได้ Google มี Use Gemini to rewrite instructions สำหรับช่วยขยายคำสั่งที่ผู้ใช้เริ่มเขียนไว้

ต้อง Review Instructions ที่ Gemini Rewrite ไหม

ควร Review ทุกครั้ง เพราะ AI อาจเพิ่ม Requirement ที่ไม่ตรงกับเป้าหมาย

Preview Gem ได้ไหม

ได้ ในหน้า Gem Builder มีพื้นที่ Preview ทางด้านขวา

Preview แล้ว Save อัตโนมัติไหม

ไม่ Google ระบุชัดว่า Preview ไม่ Save Gem อัตโนมัติ ต้องกด Save

Prompt ที่ใช้กับ Gem ต้องเขียน Persona ซ้ำไหม

ปกติไม่จำเป็น หาก Persona บันทึกใน Instructions แล้ว

Prompt รายวันควรมีอะไร

ระบุ Task, Input, Goal และ Requirement ที่แตกต่างจาก Default ของ Gem

ใช้ Knowledge แล้วต้องเขียน Prompt อย่างไร

ควรกำหนดใน Instructions ว่า Knowledge เป็น Source หลักหรือ Reference และ Prompt ระบุว่าจะใช้ File ใดหรือข้อมูลใดหากมีหลาย Source

สั่งให้ Gem ตอบเฉพาะ Knowledge ได้ไหม

สามารถกำหนดว่าให้ใช้ Knowledge เป็น Source หลักและหากไม่พบข้อมูลให้บอกว่าไม่พบแทนการเดา แต่ยังควรตรวจคำตอบสำคัญกับ Source ต้นฉบับ

ควรสร้าง Gem ตัวเดียวสำหรับทุกงานไหม

ไม่แนะนำหากแต่ละงานมี Instructions แตกต่างกันมาก เพราะ Rules อาจขัดกัน ควรแยก Gems ตามหน้าที่

Prompt ยิ่งยาวยิ่งดีไหม

ไม่จำเป็น Prompt ที่สั้นแต่ชัดและไม่ขัดกันมักดีกว่า Prompt ยาวที่มีคำสั่งซ้ำ

Gem ใช้ Context จาก Conversation ไหม

Google ยกตัวอย่าง Instructions ของ Premade Gems ที่สามารถรักษา Context ของ Conversation ได้ตามการสนทนา แต่ความยาวและการใช้งานยังอยู่ภายใต้ระบบ Context และ Limits ของ Gemini Apps

ควรเปิด Chat ใหม่เมื่อไร

เมื่อเปลี่ยน Project, Client หรือ Topic ใหญ่ เพื่อไม่ให้ Context เก่ารบกวนงานใหม่ โดยยังใช้ Gem เดิมได้

Instructions ช่วยลด Hallucination ได้ไหม

ช่วยลดได้เมื่อกำหนด Source และข้อห้ามชัด แต่ไม่สามารถรับประกันว่าคำตอบถูก 100% จึงยังต้อง Fact-check

✅ สรุปวิธีเขียน Prompt และคำสั่งให้ Gemini Gem

การเขียน Prompt สำหรับ Gemini Gem ที่มีประสิทธิภาพควรแยกออกเป็นสองระดับ

ระดับที่ 1 — Instructions

เป็นกฎประจำของ Gem

ใช้โครงสร้างหลัก:

Persona → Task → Context → Format

และสำหรับการใช้งานจริงควรเพิ่ม

Constraints

เช่น

• ห้ามเดาข้อมูล
• ห้ามสร้างตัวเลข
• รักษา Fact
• ใช้ Knowledge เป็น Source หลัก

ระดับที่ 2 — Prompt

เป็นคำสั่งของงานแต่ละครั้ง

ควรใส่เฉพาะสิ่งที่เปลี่ยน เช่น

• Topic
• Input
• Audience เฉพาะ
• Goal
• Requirement เพิ่มเติม

ไม่จำเป็นต้อง Copy Instructions ทั้งชุดมาทุกครั้ง

ตัวอย่าง:

Gem มี Instructions สำหรับ SEO Writer อยู่แล้ว

Prompt ใหม่จึงอาจมีเพียง

“เขียนบทความเรื่อง Gemini Gems คืออะไร สำหรับผู้เริ่มต้น”

แทนการเขียน Prompt ยาวหลายสิบบรรทัด

Google แนะนำอย่างเป็นทางการให้คิดเรื่อง

Persona

Gem รับบทอะไร

Task

Gem ต้องทำอะไร

Context

มีข้อมูลพื้นฐานอะไร

Format

ผลลัพธ์ต้องเป็นรูปแบบไหน

และ Google ยังมีฟังก์ชัน

Use Gemini to rewrite instructions

เพื่อช่วยเขียน Instructions จากคำอธิบายสั้น ๆ

แต่หลังจากนั้นต้อง

Review → Preview → Test → Save

ไม่ควรกด Save โดยไม่ทดลอง

โดยเฉพาะควร Test

• Input ปกติ
• ข้อมูลไม่ครบ
• Out-of-scope
• Knowledge Gap
• Prompt ที่กำกวม

เพื่อดูว่า Gem ทำงานอย่างที่ต้องการจริงหรือไม่

สูตรสุดท้ายที่ควรจำคือ

Clear Role → Clear Task → Relevant Context → Stable Format → Strong Constraints → Test

เมื่อ Instructions ถูกออกแบบดี Prompt ที่ใช้ในแต่ละวันจะสั้นลงอย่างมาก และ Gemini Gem จะกลายเป็น AI Assistant ที่ทำงานตาม Workflow เดิมได้สม่ำเสมอกว่าการเริ่ม Chat ใหม่แล้วเขียนคำสั่งทุกอย่างจากศูนย์ทุกครั้ง