Contact
Line : comsiam
Contact
Line : comsiam

Zero-Shot Prompting คือการสั่ง Google Gemini ให้ทำงาน โดยไม่ต้องให้ตัวอย่างคำตอบล่วงหน้า เราอธิบายเพียงว่างานคืออะไร มีเงื่อนไขอะไร และต้องการผลลัพธ์รูปแบบไหน จากนั้นให้ Gemini ใช้ความสามารถที่มีอยู่เพื่อทำงานทันที
ตัวอย่างง่ายที่สุดคือ
จัดข้อความต่อไปนี้เป็น Positive, Neutral หรือ Negative และตอบเฉพาะชื่อหมวดหมู่:
“สินค้าดี แต่การจัดส่งช้ามาก”
เราไม่ได้ให้ตัวอย่างว่า Positive ต้องหน้าตาอย่างไร หรือ Negative ต้องตอบแบบไหน แต่ Gemini สามารถเข้าใจงานจาก Instruction ได้โดยตรง
นี่คือ Zero-Shot Prompting
เทคนิคนี้เหมาะกับงานจำนวนมาก เช่น
ข้อดีสำคัญคือ Prompt สั้น สร้างเร็ว และไม่ต้องเตรียม Example แต่ถ้างานมีรูปแบบเฉพาะมากหรือ Gemini เข้าใจ Pattern ไม่ตรง การเพิ่มตัวอย่างแบบ Few-Shot Prompting อาจให้ผลลัพธ์ที่ดีกว่า
บทความนี้จะอธิบาย Zero-Shot Prompting ตั้งแต่พื้นฐาน วิธีใช้กับ Google Gemini ตัวอย่าง Prompt พร้อมใช้ ข้อดี ข้อจำกัด และวิธีตัดสินใจว่าเมื่อไรควรเปลี่ยนจาก Zero-Shot ไปใช้ Few-Shot
Zero-Shot Prompting หมายถึงการให้ AI ทำ Task โดยไม่มี Demonstration หรือตัวอย่าง Input → Output อยู่ใน Prompt
โครงสร้างง่าย ๆ คือ
Task + Input
ตัวอย่าง
สรุปข้อความต่อไปนี้เป็น 5 Bullet:
[ข้อความ]
หรือ
แปลข้อความต่อไปนี้เป็นภาษาไทย:
[ข้อความ]
หรือ
วิเคราะห์ข้อดีและข้อเสียของ
[ตัวเลือก]
ทั้งหมดนี้ถือเป็น Zero-Shot Prompting เพราะเราไม่ได้แสดงตัวอย่างคำตอบก่อนให้ Gemini ทำงาน
คำว่า
Zero
หมายถึงไม่มี Example หรือ Demonstration ให้ดู
ส่วน
Shot
ในบริบทนี้หมายถึงจำนวนตัวอย่างที่ให้โมเดลก่อนทำ Task
จึงมีแนวคิดที่เกี่ยวข้อง เช่น
ไม่มีตัวอย่าง
ให้ตัวอย่าง 1 ตัว
ให้ตัวอย่างหลายตัว
ไม่ได้หมายความว่า Zero-Shot ใช้ Prompt ได้เพียงหนึ่งประโยค
Prompt อาจยาวและมี
ได้ครบ
ตราบใดที่ไม่ได้ให้ตัวอย่าง Input → Output เพื่อสอน Pattern ก็ยังถือเป็น Zero-Shot ได้
จริง ๆ แล้วคำถามธรรมดาจำนวนมากที่เราใช้กับ Gemini คือ Zero-Shot อยู่แล้ว
ตัวอย่าง
Gemini คืออะไร?
หรือ
อธิบาย Blockchain ให้เด็ก 12 ปีเข้าใจ
เราไม่ได้ให้ตัวอย่าง แต่ Gemini เข้าใจ Task จาก Instruction
ดังนั้น Zero-Shot ไม่ใช่เทคนิคที่ต้องใช้รูปแบบพิเศษเสมอไป
จุดสำคัญคือ
เราสั่งงานจาก Description โดยตรง ไม่ได้สอนจาก Example
อธิบาย SEO สำหรับมือใหม่ใน 5 Bullet
Gemini ต้องเข้าใจเองว่า
ไม่มี Example ให้ดู
ถ้าเขียนว่า
Example:
Input: API คืออะไร
Output: API คือช่องทางที่ช่วยให้โปรแกรมต่าง ๆ ติดต่อกัน…ตอนนี้อธิบาย Database คืออะไรในรูปแบบเดียวกัน
นี่ไม่ใช่ Zero-Shot แล้ว เพราะมี Example หนึ่งชุด
ถือเป็น One-Shot Prompting
เพราะไม่ต้องเสียเวลาสร้างตัวอย่าง
เหมาะกับงานที่
ตัวอย่าง ถ้าต้องการ
สรุปบทความเป็น 5 Bullet
แทบไม่จำเป็นต้องสร้างตัวอย่างก่อน
ไม่ต้องใส่ Example หลายชุด
เหมาะกับคำถามประจำวัน
ถ้าผลไม่ตรง สามารถเพิ่ม
ได้ทันที
โดยเฉพาะงานที่ Input เองก็ยาวอยู่แล้ว
เช่น
Zero-Shot ไม่ได้เหมาะกับทุกงาน
ปัญหาที่อาจเจอคือ
เมื่อเจอปัญหาเหล่านี้ อาจต้องใช้
ใช้
Action + Input + Output
ตัวอย่าง
วิเคราะห์ข้อความด้านล่างและสรุปเป็น 5 Bullet
[INPUT]
หรือ
แปลข้อความต่อไปนี้เป็นภาษาไทย และรักษาชื่อ Product ภาษาอังกฤษไว้
[INPUT]
สำหรับงานที่ต้องควบคุมมากขึ้น ใช้
Task + Goal + Context + Constraints + Output Format
ตัวอย่าง
Task: สรุปรายงาน
Goal: ให้ผู้บริหารเห็นข้อมูลที่ต้องใช้ตัดสินใจ
Constraints:
- ใช้เฉพาะข้อมูลในรายงาน
- ไม่เกิน 250 คำ
- ห้ามเพิ่ม Fact
Output:
- Key Findings
- Risks
- Decisions Needed
ไม่มี Example แต่ Prompt ชัดมาก
Prompt:
อธิบาย
[หัวข้อ]สำหรับ[Audience]โดยเริ่มจาก Definition ง่าย ๆ จากนั้นอธิบายวิธีทำงานและยกตัวอย่าง 2 ตัวอย่าง หลีกเลี่ยงศัพท์ Technical ที่ไม่จำเป็น
ตัวอย่าง
อธิบาย DNS สำหรับคนที่ไม่มีพื้นฐาน Network โดยใช้ตัวอย่างเปรียบเทียบกับสมุดโทรศัพท์
สรุปข้อความต่อไปนี้เป็น 7 Bullet โดยเก็บ Key Facts, Numbers และ Conclusions ไว้ครบ และห้ามเพิ่มข้อมูลใหม่
[TEXT]
Rewrite ข้อความนี้ให้ Professional และกระชับขึ้นประมาณ 20% โดยรักษาความหมาย ตัวเลข วันที่ และชื่อเดิมทั้งหมด
[TEXT]
แปลข้อความนี้เป็นภาษาไทยธรรมชาติ รักษาชื่อ Product, Code และ Technical Terms ที่ไม่ควรแปลไว้เหมือนเดิม
[TEXT]
จัดข้อความต่อไปนี้เป็นหนึ่งใน 4 หมวด:
- Billing
- Technical Support
- Account
- Other
ตอบเฉพาะชื่อหมวดหมู่
[MESSAGE]
Gemini ไม่ได้รับ Example แต่มี Label ชัด
วิเคราะห์ Sentiment ของข้อความนี้เป็น Positive, Neutral หรือ Negative และตอบในรูปแบบ:
Sentiment:
[label]Reason:
[1 ประโยค]
[TEXT]
จากข้อความด้านล่าง ดึงข้อมูล:
- ชื่อ
- บริษัท
- Deadline
หากข้อมูลใดไม่มี ให้ใส่
N/A
[TEXT]
เปรียบเทียบ
[A]กับ[B]เป็นตาราง โดยมี:
- ราคา
- ฟีเจอร์
- ข้อดี
- ข้อจำกัด
- เหมาะกับใคร
สร้าง Checklist ก่อนเปิดเว็บไซต์ใหม่ ครอบคลุม Domain, Hosting, SSL, Backup, SEO, Analytics และ Security เรียงจากสิ่งที่ต้องทำก่อน Launch ไปหลัง Launch
อธิบายวิธี
[TASK]เป็น Step-by-Step สำหรับมือใหม่ แต่ละขั้นต้องมี Action และวิธีตรวจว่าทำสำเร็จแล้ว
สร้างไอเดีย 20 แบบสำหรับ
[GOAL]โดยแต่ละแนวคิดต้องต่างกันจริงที่วิธีการ ไม่ใช่เพียงเปลี่ยนชื่อ
เปรียบเทียบ
[A],[B]และ[C]ตาม Criteria[CRITERIA]จากนั้นแนะนำตาม Use Case แทนการประกาศตัวเลือกดีที่สุดเพียงหนึ่งตัว
วิเคราะห์ข้อดี ข้อเสีย และความเสี่ยงของ
[DECISION]โดยแยก Short-term กับ Long-term
ฉันกำลังตัดสินใจระหว่าง
[OPTIONS]เป้าหมายคือ[GOAL]และ Constraints คือ[CONSTRAINTS]ช่วยสร้าง Decision Matrix และอธิบาย Trade-offs
ปัญหาคือ
[PROBLEM]ข้อมูลที่มีคือ
[DATA]สร้าง Hypotheses ที่เป็นไปได้ เรียงจากควรตรวจง่ายที่สุด และระบุ Evidence ที่ต้องใช้ยืนยันแต่ละข้อ
วิเคราะห์ปัญหา
[PROBLEM]โดยแยก Symptoms, Possible Causes, Evidence Needed และ Next Diagnostic Step ห้ามสรุป Root Cause หากข้อมูลยังไม่เพียงพอ
วิเคราะห์ธุรกิจ
[BUSINESS]จากข้อมูล[DATA]ตอบเป็น:
- Facts
- Problems
- Opportunities
- Risks
- Missing Information
- Recommended Next Actions
สินค้า
[PRODUCT]Audience
[AUDIENCE]Goal
[GOAL]Budget
[BUDGET]สร้าง Marketing Experiments สูงสุด 10 แบบ พร้อม Hypothesis, Action, KPI และ Cost Level
คิด Content Ideas 30 หัวข้อเกี่ยวกับ
[TOPIC]สำหรับ[AUDIENCE]แบ่งเป็น How-to, Problems, Questions, Comparisons และ Mistakes และห้ามสร้างหัวข้อ Intent ซ้ำ
สร้าง Outline H1/H2/H3 สำหรับ Keyword
[KEYWORD]โดย Search Intent คือ[INTENT]แต่ละ H2 ต้องตอบคำถามที่แตกต่างกันและห้ามสร้างข้อมูล Search Volume
เขียน Follow-up Email สำหรับ
[SITUATION]ให้ Professional + Friendly ไม่เกิน 120 คำ มี CTA เดียว และไม่กดดันผู้รับ
เขียนคำตอบลูกค้าเรื่อง
[ISSUE]ให้สุภาพ รับรู้ปัญหา อธิบายขั้นตอนถัดไป และหลีกเลี่ยงการรับปากสิ่งที่ยังยืนยันไม่ได้
จาก Meeting Notes นี้ ดึงเฉพาะ:
- Decisions
- Action Items
- Owners
- Deadlines
หาก Owner หรือ Deadline ไม่ได้ระบุ ให้เขียน
N/A
[NOTES]
เปลี่ยนข้อมูลนี้เป็น Weekly Report มี:
- Progress
- Metrics
- Blockers
- Risks
- Next Week Priorities
ใช้เฉพาะข้อมูลที่ให้
เขียน Function ด้วย
[LANGUAGE]ที่ทำ[TASK]Input:
[INPUT]Output:
[OUTPUT]Constraints:
[CONSTRAINTS]ก่อน Code ให้สรุป Approach สั้น ๆ และหลัง Code ให้สร้าง Test Cases
ฉันใช้
[LANGUAGE/FRAMEWORK/VERSION]Expected:
[EXPECTED]Actual:
[ACTUAL]Error:
[ERROR]Code:
[CODE]วิเคราะห์ Root Cause ที่เป็นไปได้ก่อน และเสนอ Minimal Fix พร้อม Regression Test
Review Code ด้านล่างในด้าน Correctness, Security, Maintainability และ Error Handling แบ่ง Finding เป็น Critical, High, Medium และ Low
[CODE]
Review SQL Query นี้ในด้าน Correctness, Performance, Null Handling และ Index Usage โดยยังไม่เสนอ Index ใหม่จนกว่าจะอธิบาย Bottleneck ที่เป็นไปได้
[QUERY]
จาก Requirement
[REQUIREMENT]สร้าง Test Cases แบ่งเป็น Happy Path, Boundary, Invalid Input และ Failure Conditions พร้อม Expected Result
จาก Code นี้สร้าง Documentation มี Purpose, Inputs, Outputs, Exceptions, Side Effects และ Example Usage โดยห้ามสร้าง Behavior ที่ไม่มีใน Code
สอน
[TOPIC]ให้ฉันในระดับ[LEVEL]โดยใช้ Explain → Example → Question → Feedback อย่าเฉลยคำถามทันทีหากสามารถให้ Hint ได้ก่อน
สร้าง Quiz 10 ข้อเรื่อง
[TOPIC]ระดับ[LEVEL]ยังไม่ต้องเฉลยจนกว่าฉันจะตอบ
สร้าง Flashcards 20 ใบจากเนื้อหานี้ ในรูปแบบ Question | Answer ใช้เฉพาะข้อมูลจาก Source
สร้าง Study Plan 14 วันสำหรับเรียน
[TOPIC]โดยมีเวลาไม่เกิน 1 ชั่วโมงต่อวัน และมี Review Day อย่างน้อย 3 วัน
Review Resume นี้ในด้าน Clarity, Relevance, Achievement Statements และ Redundancy โดยห้ามสร้างประสบการณ์หรือผลงานใหม่ให้ผู้สมัคร
สร้าง Job Description สำหรับตำแหน่ง
[ROLE]โดยมี Responsibilities, Required Skills, Preferred Skills และ Success Metrics หลีกเลี่ยง Requirement ที่ไม่เกี่ยวกับงาน
เปลี่ยนขั้นตอนด้านล่างเป็น SOP ที่มี Purpose, Scope, Owner, Steps, Quality Check และ Escalation โดยใช้เฉพาะข้อมูลที่ให้
วิเคราะห์ Risk ของ
[PLAN]แบ่งเป็น Probability, Impact, Early Warning Sign และ Mitigation โดยไม่สร้างตัวเลข Probability หากไม่มีข้อมูล
สมมติว่าแผน
[PLAN]ล้มเหลวหลัง 6 เดือน ช่วยระบุสาเหตุที่เป็นไปได้และ Early Warning Signs โดย Label ทุกข้อว่าเป็น Scenario ไม่ใช่ Fact
สร้าง 3 Scenario สำหรับ
[DECISION]: Conservative, Base และ Upside โดยแสดง Assumption ของแต่ละ Scenario อย่างชัดเจน
ไม่จำเป็น
ตัวอย่าง Zero-Shot สามารถมี Prompt แบบนี้ได้
Role: Editor
Audience: Beginner
Goal: Rewrite ให้อ่านง่าย
Constraints:
- ห้ามเพิ่ม Fact
- รักษาตัวเลข
- ลดความยาว 20%
Output: Final Text
แม้มีรายละเอียดหลายบรรทัด ก็ยังเป็น Zero-Shot เพราะไม่มี Demonstration
ได้
ตัวอย่าง
ทำหน้าที่เป็น Code Reviewer ที่เน้น Security และ Correctness
Review Code ต่อไปนี้…
ยังเป็น Zero-Shot เพราะ Role ไม่ใช่ Example
ได้ และควรใช้เมื่อจำเป็น
ตัวอย่าง
สรุปข้อความนี้
Constraints:
- 5 Bullet
- ใช้เฉพาะ Source
- รักษาตัวเลข
- ห้ามเพิ่ม Fact
ไม่มี Example จึงยังเป็น Zero-Shot
ได้
ตัวอย่าง
<TASK>
สรุป Source เป็น 10 Bullet</TASK>
<SOURCE>[ข้อมูล]</SOURCE>
Delimiter ช่วยจัดโครงสร้าง แต่ไม่ได้เปลี่ยนประเภทเป็น Few-Shot
สามารถสั่งหลายขั้นโดยไม่มีตัวอย่าง
เช่น
- วิเคราะห์ข้อมูล
- หา Anomaly
- สร้าง Hypothesis
- เสนอ Next Check
ยังเป็น Zero-Shot
ใช้ Zero-Shot ก่อนเมื่อ
① Task เป็นที่เข้าใจง่าย
② Output Format มาตรฐาน
③ ไม่ต้องเลียนแบบ Style เฉพาะ
④ Labels เข้าใจได้ง่าย
⑤ ต้องการทำงานเร็ว
⑥ Prompt มี Context เพียงพอ
ตัวอย่าง
สรุป
แปล
Rewrite
เปรียบเทียบ
อธิบาย
มักเริ่มด้วย Zero-Shot ได้ดี
ควรพิจารณา Example เมื่อ
ในกรณีเหล่านี้ One-Shot หรือ Few-Shot อาจช่วยได้
สมมติเราสั่ง
จัดข้อความเป็น P1, P2 หรือ P3
Gemini ไม่รู้ว่า
ปัญหาไม่ได้อยู่ที่ไม่มี Example อย่างเดียว แต่ Definition ขาด
สามารถแก้ Zero-Shot ก่อนโดยเพิ่ม
P1 = ระบบล่มทั้งหมด
P2 = ฟังก์ชันหลักบางส่วนใช้ไม่ได้
P3 = ปัญหาที่มี Workaround
แล้วจึงให้ Classification
ถ้ายังไม่แม่น ค่อยเพิ่ม Example
ตัวอย่าง
จัด Ticket เป็น:
P1 = บริการหลักใช้งานไม่ได้สำหรับผู้ใช้ส่วนใหญ่
P2 = Function สำคัญมีปัญหาแต่ยังมี Workaround
P3 = ปัญหาเล็กหรือคำถามทั่วไป
Ticket:
[ข้อความ]ตอบเฉพาะ P1/P2/P3
แม้ไม่มี Example ก็อาจทำงานได้ดีเพราะ Criteria ชัด
เขียน Title ให้กระชับและระบุปัญหาชัด
ตัวอย่าง:
Input: มือถือชาร์จไม่เข้า
Output: มือถือชาร์จไม่เข้า แก้อย่างไร? รวมสาเหตุและวิธีตรวจInput ใหม่: Wi-Fi หลุดบ่อย
Output:
One-Shot มี Example หนึ่งตัวเพื่อแสดง Pattern
Few-Shot มีหลาย Example
เช่น
Input A → Output A
Input B → Output B
Input C → Output C
New Input → ?
เหมาะกับ Pattern ที่อธิบายด้วยข้อความยาก
สำหรับงานทั่วไป ควรเริ่มจาก
Zero-Shot ที่ชัดเจน
เพราะง่ายและสั้นกว่า
ถ้าผลไม่ตรง ให้ตรวจตามลำดับ
① Task ชัดหรือไม่
② Context พอหรือไม่
③ Constraints ชัดหรือไม่
④ Output Format ชัดหรือไม่
⑤ Definitions ชัดหรือไม่
ถ้าทั้งหมดชัดแล้วแต่ Pattern ยังไม่ตรง ค่อยเพิ่ม Example
สามารถใช้แนวทาง
Zero-Shot → One-Shot → Few-Shot
ไม่ต้องเริ่มด้วย Few-Shot ทันที
ลอง Zero-Shot
ถ้ารูปแบบไม่ตรง เพิ่ม Example หนึ่งตัว
ถ้ายังมี Edge Cases เพิ่มหลาย Example
ประหยัด Prompt กว่า
เพิ่ม Goal และ Scope
วิเคราะห์เว็บไซต์
วิเคราะห์ Landing Page นี้เฉพาะด้าน Conversion โดยดู Message, Trust, CTA และ Friction ไม่ต้องวิเคราะห์ Technical SEO
ยังเป็น Zero-Shot แต่ตรงขึ้น
เพิ่ม Length Constraint
สรุปเป็น 5 Bullet แต่ละ Bullet ไม่เกิน 2 ประโยค
กำหนด Output Schema
ตอบในรูปแบบ:
Issue:
Cause:
Fix:
Priority:
เพิ่ม Grounding Rule
ใช้เฉพาะข้อมูลที่ให้ หากไม่มีข้อมูลให้เขียน
N/A
เพิ่ม Tone Definition
ใช้ Tone Professional + Friendly ประโยคกระชับ หลีกเลี่ยง Slang และคำขายเกินจริง
เพิ่ม Fixed Structure
ทุกคำตอบต้องมี 4 Section ตามลำดับ:
Summary
Findings
Risks
Actions
ถ้ายังไม่สม่ำเสมอ ค่อยใช้ Few-Shot
ควรระบุ
ตัวอย่าง
Classify Ticket เป็น Billing, Technical หรือ Account
Billing = ราคา การชำระเงิน Invoice
Technical = Error การใช้งาน ระบบ
Account = Login Password Profileหากเกี่ยวข้องหลายหมวด ให้เลือก Intent หลัก
ตอบเฉพาะ Label เดียว
นี่เป็น Zero-Shot Classification ที่แข็งแรงกว่า
Prompt:
จากข้อความนี้คืนค่าเฉพาะ:
Name: Company: Email: Deadline:หากไม่มีข้อมูลให้ใช้
N/A
ไม่ต้องมี Example หาก Schema ชัด
ดึงข้อมูลออกมาเป็น JSON ตาม Schema:
{ "name": null, "company": null, "deadline": null }หากข้อมูลไม่มีให้ใช้
nullและห้ามสร้างค่า
การให้ Schema ไม่ถือเป็น Few-Shot เพราะไม่ได้เป็น Example Input → Output
จากข้อมูลนี้สร้างตาราง:
| Item | Owner | Deadline | Status |
ถ้าไม่มีข้อมูลให้ใส่ N/A
ง่ายและตรง
ใช้ได้เช่นกัน
คิดชื่อร้านกาแฟ 30 ชื่อที่ให้ความรู้สึก Modern + Local หลีกเลี่ยงชื่อที่มีคำว่า Coffee และแต่ละชื่อไม่เกิน 3 คำ
ไม่มี Example แต่มี Constraints ชัด
เขียน Headline โฆษณา 10 แบบสำหรับ
[PRODUCT]Audience[AUDIENCE]โดยเน้น Benefit[BENEFIT]ห้ามใช้ Fake Urgency หรือ Claim ที่ไม่มี Evidence
วิเคราะห์ Prompt นี้ในด้าน Ambiguity, Missing Context, Conflicting Rules และ Output Format จากนั้น Rewrite ให้ชัดขึ้นโดยรักษา Intent เดิม
นี่คือ Zero-Shot เพราะไม่ได้แสดง Example Prompt ที่ดี
จาก Source นี้ ให้ระบุ Claim ที่ได้รับการสนับสนุน Claim ที่ไม่ได้รับการสนับสนุน และข้อมูลที่ยังไม่สามารถยืนยันได้
จากรายการบทความ
[LIST]ช่วยหา Topic Gaps โดยห้ามเสนอหัวข้อที่มี Search Intent ซ้ำกับของเดิม
จัดหัวข้อเหล่านี้เป็น Topic Clusters และกำหนด Pillar กับ Supporting Articles โดยอธิบาย Logic ของการจัด
จากข้อมูลลูกค้าจริง
[DATA]สร้าง Persona โดยใช้เฉพาะข้อมูลที่มี ห้ามสร้าง Age, Income หรือ Demographic ที่ไม่ได้ให้
สร้าง Customer Journey สำหรับ
[AUDIENCE]แบ่ง Awareness, Consideration, Purchase, Retention และ Referral พร้อม Questions และ Barriers ในแต่ละ Stage
Review SOP นี้ในด้าน Missing Step, Ambiguity, Ownership, Failure Handling และ Verification Point โดยไม่ Rewrite ทั้งเอกสาร
วิเคราะห์ Workflow นี้และหา Bottleneck, Rework, Waiting Time และ Manual Steps ที่อาจลดได้ โดยเรียงตาม Impact
จาก Goal
[GOAL]เลือก KPI สูงสุด 5 ตัวที่เชื่อมกับ Goal โดยตรง พร้อมอธิบายว่าแต่ละ KPI บอกอะไร
เปรียบเทียบคู่แข่งจากข้อมูลนี้เท่านั้น แยก Price, Positioning, Offer, Strength และ Weakness หากข้อมูลใดไม่มีให้เขียน N/A
จาก Project Plan นี้สร้าง Risk Register มี Risk, Cause, Impact, Early Warning, Mitigation และ Owner หาก Owner ไม่ได้ให้ให้ใช้ N/A
สร้าง Project Plan สำหรับ
[PROJECT]ระยะเวลา[TIME]ทีม[TEAM]แบ่งเป็น Milestones, Tasks, Dependencies และ Risks
จัด Priority งานเหล่านี้ตาม Impact, Urgency และ Effort ให้คะแนน 1–5 พร้อมเหตุผลสั้น ๆ และห้ามสร้าง Business Impact ที่ไม่มีข้อมูล
จัด Tasks ต่อไปนี้เป็น Do, Schedule, Delegate และ Eliminate ตามข้อมูล Deadline และ Impact ที่ให้ หากข้อมูลไม่พอให้ระบุว่า Needs Review
สร้าง SWOT จากข้อมูลธุรกิจที่ให้ โดยแยก Internal Factors เป็น Strength/Weakness และ External Factors เป็น Opportunity/Threat ห้ามเติม Market Fact ที่ไม่ได้ให้
ใช้ 5 Whys กับปัญหา
[PROBLEM]แต่หากข้อมูลไม่พอในขั้นใด ให้หยุดและระบุ Evidence Needed แทนการเดาต่อ
จากข้อมูลนี้สร้าง Decision Memo มี Context, Decision, Options Considered, Rationale, Risks และ Next Steps
สรุปเอกสารนี้สำหรับผู้บริหารไม่เกิน 300 คำ เน้น Business Impact, Key Numbers, Risks และ Decisions Required
สร้าง FAQ 10 ข้อจากข้อมูลใน Source โดยใช้เฉพาะคำถามที่ Source สามารถตอบได้ ห้ามสร้างคำตอบที่ไม่มีข้อมูลรองรับ
ตรวจ Grammar, Spelling และ Punctuation ของข้อความนี้โดยรักษา Style และ Meaning เดิม ตอบเฉพาะข้อความที่แก้แล้ว
ตัด Redundancy จากบทความนี้โดยรักษาข้อมูลสำคัญทั้งหมด หากสอง Paragraph พูดเรื่องเดียวกันให้รวมเป็น Paragraph เดียว
Rewrite สำหรับผู้อ่านระดับ Beginner ลดศัพท์เฉพาะ ประโยคยาว และ Passive Voice ที่ไม่จำเป็น แต่รักษา Fact เดิม
เปลี่ยน Tone จาก Formal เป็น Conversational แต่รักษา Meaning, Data และ Structure เดิม
Rewrite ข้อความนี้ 5 เวอร์ชัน โดยแต่ละเวอร์ชันใช้ Angle ต่างกัน แต่รักษา Main Message และ Facts เดิม
ให้คะแนน Draft นี้ในด้าน Clarity, Relevance, Completeness และ Redundancy พร้อมระบุ 3 จุดที่ควรแก้ก่อน
วิจารณ์ Proposal นี้ในมุมผู้บริหารที่ต้องอนุมัติงบ โดยเน้น Missing Evidence, Risks, Assumptions และ Decision Gaps
สมมติว่า Recommendation นี้ผิด ช่วยหาเหตุผลที่สมเหตุสมผล 5 ข้อว่าทำไมอาจล้มเหลว และข้อมูลอะไรที่ต้องตรวจ
ตรวจ Draft นี้กับ Constraints ต่อไปนี้ทีละข้อ และแสดงเฉพาะข้อที่ไม่ผ่านพร้อมวิธีแก้
ก่อน Final ตรวจ Accuracy, Goal Alignment, Missing Information, Redundancy และ Format Compliance แล้วแก้เฉพาะจุดที่ไม่ผ่าน
<TASK>[งานที่ต้องการ]</TASK>
<GOAL>[เป้าหมาย]</GOAL>
<CONTEXT>[ข้อมูลพื้นฐาน]</CONTEXT>
<INPUT>[ข้อมูลของงาน]</INPUT>
<CONSTRAINTS>
[Constraint 1][Constraint 2][Constraint 3]</CONSTRAINTS>
<OUTPUT_FORMAT>[รูปแบบคำตอบ]</OUTPUT_FORMAT>หากข้อมูลไม่เพียงพอ ห้ามเดา ให้ระบุ Missing Information
Template นี้ไม่มี Example จึงเป็น Zero-Shot
ช่วย
[TASK]จาก[INPUT]โดยมีเป้าหมาย[GOAL]ภายใต้ข้อจำกัด[CONSTRAINTS]และตอบในรูปแบบ[OUTPUT]
ตัวอย่าง
ช่วยสรุปรายงานนี้เพื่อให้ผู้บริหารตัดสินใจ โดยใช้เฉพาะข้อมูลที่ให้ ไม่เกิน 300 คำ และตอบเป็น Key Findings / Risks / Decisions Needed
คุณจะได้รับ Task ใหม่ในแต่ละรอบ
ทุกครั้งให้:
- ทำความเข้าใจ Goal
- ใช้ Context และ Input ที่ให้
- ทำตาม Constraints
- หากข้อมูลขาด ห้ามสร้างข้อมูลเติม
- ตอบตาม Output Format
- ตรวจว่า Final Answer ไม่หลุด Scope
Input ของรอบนี้:
Task:
[TASK]
Goal:[GOAL]
Context:[CONTEXT]
Data:[INPUT]
Constraints:[CONSTRAINTS]
Output:[FORMAT]
ไม่มี Example แต่ใช้ซ้ำได้หลายงาน
จำ 6 ข้อนี้
เช่น
Summarize
Compare
Extract
Rewrite
Classify
อย่าให้ Gemini เดา
โดยเฉพาะ Classification
กำหนดสิ่งที่ห้ามหรือขอบเขต
ลดความคลุมเครือ
เช่น
ใช้ N/A
ช่วยวิเคราะห์ให้หน่อย
ไม่รู้ว่า
วิเคราะห์ข้อมูลยอดขายด้านล่างเพื่อหาช่วงที่ยอดลดผิดปกติ แยก Observation กับ Possible Cause และตอบเป็นตาราง Month / Observation / Evidence / Next Check
ยังไม่มี Example แต่ Task ชัดมาก
ทำให้ข้อความนี้ดีขึ้น
Rewrite ข้อความนี้ให้กระชับและ Professional ขึ้น โดยรักษาความหมาย ตัวเลข และ Deadline เดิมทั้งหมด และตอบเฉพาะข้อความ Final
นี่คือการปรับ Zero-Shot โดยเพิ่ม Constraints
ถ้า Output ไม่ดี อาจเป็นเพราะ
Format ไม่ชัด
ไม่ใช่เพราะต้อง Few-Shot
ตัวอย่าง
แทนเพิ่ม Example 5 ชุด
ลองกำหนด
ตอบใน Format: Problem | Cause | Fix
ก่อน
ถ้าทำงานได้ ก็ไม่ต้องใช้ Example
สมมติเรามี Naming Style เฉพาะบริษัทที่มี
อธิบายเป็นกฎอาจยาวมาก
ให้ Example 3–5 ตัวอาจชัดกว่า
Zero-Shot ไม่ได้ดีกว่า Few-Shot เสมอไป
เลือกให้เหมาะกับงาน
ถามตามลำดับ
ถ้าไม่ → เพิ่ม Instruction
ถ้าไม่ → เพิ่ม Output Format
ถ้าไม่ → เพิ่ม Definitions
ถ้าได้ → Zero-Shot ต่อ
ถ้าใช่ → เพิ่ม Example
นี่เป็นวิธีที่ประหยัดกว่าเริ่ม Few-Shot ทุกครั้ง
เช่น
วิเคราะห์นี่
Gemini ไม่รู้ว่าจะเน้นอะไร
ต้องเดาสถานการณ์
Classification ผิดง่าย
คำตอบไม่สม่ำเสมอ
AI ขยาย Scope
เพิ่ม Hallucination
ควรเพิ่ม Style Guide หรือ Example
Few-Shot อาจเหมาะกว่า
Zero-Shot ควร Iterate ได้เหมือน Prompt แบบอื่น
ตรวจว่า
① Task ชัดหรือไม่
② Goal มีหรือไม่
③ Context เพียงพอหรือไม่
④ Audience จำเป็นหรือไม่
⑤ Labels มี Definition หรือไม่
⑥ Input แยกชัดหรือไม่
⑦ Constraints มีหรือไม่
⑧ Output Format ชัดหรือไม่
⑨ ข้อมูลขาดต้องทำอย่างไร
⑩ ต้องใช้ Example จริงหรือไม่
ถ้าข้อ 1–9 ชัดแล้ว ลอง Zero-Shot ก่อน
สรุปข้อความนี้เป็น 5 Bullet ใช้เฉพาะข้อมูลที่ให้และรักษาตัวเลขสำคัญ
Rewrite ให้กระชับและเป็นธรรมชาติขึ้น รักษา Meaning และ Facts เดิม
วิเคราะห์ข้อมูลนี้เป็น Facts / Patterns / Risks / Missing Information
เปรียบเทียบตัวเลือกตาม Criteria เดียวกันและสรุป Best For
ดึงข้อมูลตาม Fields ที่กำหนด หากไม่มีให้ใช้ N/A
จัดข้อความเป็นหนึ่งใน Labels ที่กำหนดและตอบเฉพาะ Label
สร้าง Checklist เรียงจากสิ่งที่ต้องทำก่อนถึงหลัง
สร้าง Outline H1/H2/H3 ที่ไม่ซ้ำ Intent
หา 5 Weakness ที่มี Impact สูงที่สุดก่อน ยังไม่ต้อง Rewrite
แยก Facts / Assumptions / Options / Trade-offs / Recommendation
ถ้าจำทั้งหมดไม่ไหว ให้จำ
ชัดเจน + มี Context + มี Constraints + กำหนด Output + ไม่บังคับ AI ให้เดา
Prompt ตัวอย่าง
วิเคราะห์ข้อมูลนี้เพื่อหา Issue ที่ควรตรวจต่อ ใช้เฉพาะข้อมูลที่ให้ แยก Fact กับ Hypothesis และตอบเป็นตาราง Issue / Evidence / Next Check หากข้อมูลไม่พอให้ระบุว่า Missing Data
ไม่มี Example แต่มีองค์ประกอบสำคัญครบ
เหมาะมาก
เพราะไม่จำเป็นต้องเข้าใจ Prompt Engineering ขั้นสูงก่อน
เริ่มจากสูตร
ทำอะไร + กับอะไร + ต้องการแบบไหน
เช่น
สรุปบทความนี้เป็น 5 Bullet
จากนั้นค่อยเพิ่ม
เมื่อจำเป็น
ตัวอย่าง
วางแผนสิ่งที่ต้องทำวันนี้จากรายการนี้ เรียงตาม Urgency และ Impact
Rewrite ข้อความนี้ให้สุภาพขึ้น
สรุป Email นี้และบอกสิ่งที่ฉันต้องตอบ
เปรียบเทียบ 3 ตัวเลือกนี้
เปลี่ยน Notes นี้เป็น Checklist
งานเหล่านี้ไม่จำเป็นต้องใช้ Example ส่วนใหญ่
สามารถซับซ้อนได้มากขึ้น เช่น
วิเคราะห์ข้อมูล Campaign โดยแยก Facts, Anomalies, Hypotheses และ Experiments ใช้เฉพาะข้อมูลที่ให้ ห้ามสร้าง Market Data และตอบเป็น Executive Summary + Experiment Backlog
ยังเป็น Zero-Shot
จึงเห็นได้ว่า Zero-Shot ไม่ได้หมายถึง Prompt “ง่าย” เสมอไป
แต่หมายถึง
ไม่มี Example Demonstration
Master Prompt ก็สามารถเป็น Zero-Shot ได้
ถ้า Master Prompt มี
แต่ไม่มีตัวอย่าง Input → Output
ตัวอย่าง
ทุกครั้งที่ฉันส่งบทความ ให้ตรวจ Search Intent, Redundancy, Facts และ Format ตาม Checklist นี้…
ถือเป็น Zero-Shot Template
ควรเพิ่มเมื่อพบว่า
① Gemini ยังตีความ Pattern ผิดแม้ Instruction ชัด
② ต้องการ Format เฉพาะมาก
③ ต้องเลียนแบบ Style
④ Labels มี Nuance สูง
⑤ มี Edge Cases ที่อธิบายยาก
⑥ Output ต้องสม่ำเสมอมาก
Few-Shot ไม่ได้มาแทน Zero-Shot แต่เป็นขั้นต่อไปเมื่อจำเป็น
เริ่มจาก
สร้าง Title ให้สั้นและตรง Search Intent
ถ้า Title ยังไม่ตรง Style
เพิ่ม Example
ตัวอย่าง:
ปัญหา: มือถือเปิดไม่ติด
Title: มือถือเปิดไม่ติด แก้อย่างไร? รวมวิธีตรวจทีละขั้น
ตอนนี้ Prompt เปลี่ยนเป็น One-Shot
ถ้ายังไม่ Stable เพิ่ม 2–3 Example ก็กลายเป็น Few-Shot
<TASK>[ระบุสิ่งที่ต้องการให้ Gemini ทำ]</TASK>
<GOAL>[ผลลัพธ์ที่ต้องการ]</GOAL>
<CONTEXT>[ข้อมูลที่จำเป็นต่อการทำงาน]</CONTEXT>
<INPUT>[ข้อมูลของงาน]</INPUT>
<CONSTRAINTS>
[สิ่งที่ต้องรักษา][สิ่งที่ห้ามทำ][ขอบเขต]</CONSTRAINTS>
<OUTPUT_FORMAT>[รูปแบบคำตอบ]</OUTPUT_FORMAT>หากข้อมูลไม่เพียงพอสำหรับยืนยันข้อสรุป ให้ระบุ Missing Information แทนการเดา
ก่อนส่ง Final Answer ให้ตรวจว่า Task, Goal, Constraints และ Output Format ครบทุกข้อ
Template นี้ใช้หลัก Zero-Shot อย่างเต็มรูปแบบ เพราะสอน Gemini ด้วยคำสั่งและ Context โดยไม่ต้องแสดง Example
Zero-Shot Prompting คือการสั่ง Google Gemini ให้ทำ Task โดยไม่ให้ตัวอย่าง Input → Output ก่อน
ตัวอย่างง่าย ๆ คือ
สรุปบทความนี้เป็น 5 Bullet
หรือ
จัดข้อความนี้เป็น Positive, Neutral หรือ Negative
หรือ
Rewrite Email นี้ให้ Professional และกระชับ
ถ้าต้องการให้ Zero-Shot มีประสิทธิภาพมากขึ้น ให้เพิ่ม
Task + Goal + Context + Constraints + Output Format
สูตรพร้อมใช้คือ
ช่วย
[TASK]โดยมีเป้าหมาย[GOAL]ใช้ Context[CONTEXT]และข้อมูล[INPUT]ภายใต้ข้อจำกัด[CONSTRAINTS]ตอบในรูปแบบ[OUTPUT FORMAT]หากข้อมูลไม่เพียงพอ ห้ามเดา ให้ระบุสิ่งที่ยังขาด
หลักสำคัญคือ อย่ารีบเพิ่มตัวอย่างหากปัญหายังแก้ได้ด้วย Instruction ที่ชัดขึ้น
เริ่มจาก Zero-Shot เพราะเรียบง่ายและรวดเร็ว จากนั้นถ้า Gemini ยังไม่เข้าใจ Pattern หรือ Style ที่ต้องการ ค่อยขยับไปใช้ One-Shot หรือ Few-Shot Prompting
แนวทางที่ใช้ได้ดีกับงานจำนวนมากคือ
Zero-Shot → ตรวจผล → เพิ่ม Context/Constraints → ทดสอบอีกครั้ง → เพิ่ม Example เฉพาะเมื่อจำเป็น
เมื่อใช้วิธีนี้ เราจะได้ Prompt ที่ไม่ซับซ้อนเกินไป ใช้พื้นที่น้อย และยังควบคุมคำตอบของ Gemini ได้อย่างมีประสิทธิภาพ