การใช้ Google Gemini ให้ได้ผลดี ไม่จำเป็นต้องพยายามเขียน Prompt ครั้งแรกให้สมบูรณ์แบบทุกอย่าง เพราะงานจำนวนมากเหมาะกับการทำแบบ สร้างคำตอบ → ตรวจ → ให้ Feedback → ปรับ → ตรวจอีกครั้ง มากกว่า

ตัวอย่างเช่น ถ้าเราต้องการบทความหนึ่งชิ้น แล้วสั่งว่า

เขียนบทความเรื่อง Google Gemini ให้ดีที่สุด

Gemini อาจสร้างคำตอบที่ดูดี แต่บางส่วนอาจ

• ยาวเกินไป
• ไม่ตรง Search Intent
• มีหัวข้อซ้ำ
• Tone ไม่ตรง
• ตัวอย่างน้อยเกินไป
• ขาดข้อมูลบางส่วน
• Format ไม่เหมาะกับการใช้งานจริง

แทนที่จะทิ้งคำตอบทั้งหมดแล้วเริ่ม Prompt ใหม่ เราสามารถสั่ง Gemini ให้ ปรับเฉพาะจุดที่ยังไม่ดี ได้

ตัวอย่าง

ใช้คำตอบเดิมเป็น Draft อย่าเขียนใหม่ทั้งหมด ตรวจว่ามีส่วนใดซ้ำหรือหลุด Search Intent แล้วแก้เฉพาะจุดเหล่านั้น

จากนั้นอาจสั่งต่อ

ตอนนี้ตรวจเฉพาะ Introduction ให้ตอบคำถามหลักเร็วขึ้น โดยรักษา Section อื่นไว้เหมือนเดิม

แล้วต่อด้วย

ตรวจ Final Version อีกครั้งในด้าน Clarity, Redundancy และ Unsupported Claims ก่อนส่งฉบับสุดท้าย

วิธีทำงานลักษณะนี้เรียกว่า Iterative Prompting หรือการปรับคำตอบเป็นรอบ ๆ

หัวใจสำคัญคือไม่ต้องพยายามให้ Gemini ทำทุกอย่างสมบูรณ์ในคำตอบแรก แต่ใช้แต่ละรอบแก้ปัญหาที่ชัดเจนทีละส่วนจนได้ผลลัพธ์ที่เหมาะกับงานจริง

Iterative Prompting คืออะไร?

Iterative Prompting คือการใช้ Gemini ทำงานแบบหลายรอบ โดยแต่ละรอบนำผลจากรอบก่อนหน้ามาตรวจ ปรับ ขยาย ลด หรือแก้ไขต่อ

โครงสร้างพื้นฐานคือ

Prompt → Draft → Review → Feedback → Revision → Final Check

ตัวอย่าง

รอบที่ 1

สร้าง Outline สำหรับบทความเรื่อง [หัวข้อ]

รอบที่ 2

ตรวจ Outline นี้และหา Content Gaps

รอบที่ 3

ใช้ Outline ที่ปรับแล้วเขียน Draft

รอบที่ 4

ตัดส่วนที่ซ้ำและไม่ตอบ Search Intent

รอบที่ 5

ตรวจ Fact และ Format ก่อน Final

แทนที่จะสั่งทุกอย่างพร้อมกันใน Prompt เดียว

ทำไมการปรับหลายรอบจึงมีประโยชน์?

เพราะงานซับซ้อนมักมีคุณภาพหลายด้านที่ต้องตรวจ เช่น

• ความถูกต้อง
• ความครบ
• Tone
• Structure
• Length
• Logic
• Format
• Practical Value

ถ้าสั่งให้ Gemini ทำทั้งหมดพร้อมกัน มันอาจให้ความสำคัญบางข้อมากกว่าข้ออื่น

การแยกเป็นรอบช่วยให้เราตรวจแต่ละมิติได้ชัดขึ้น

① เริ่มจาก Draft ก่อน ไม่ต้องบังคับ Final ทันที

Prompt ที่มีประโยชน์คือ

สร้าง Draft ก่อน ยังไม่ต้องพยายามทำให้เป็น Final Version ฉันจะ Review แล้วให้ Feedback เพิ่ม

วิธีนี้เหมาะกับ

• บทความ
• Email
• Proposal
• Report
• Presentation Outline
• Business Plan

ข้อดีคือเราสามารถแก้ Direction ก่อนเสียเวลา Polish รายละเอียด

② ให้ Gemini วางโครงก่อนเขียนเต็ม

สำหรับงานยาว ไม่ควรเริ่มจาก Full Draft เสมอไป

ตัวอย่าง

ก่อนเขียนบทความฉบับเต็ม ให้สร้าง Outline H1/H2/H3 และอธิบายสั้น ๆ ว่าแต่ละ Section มีหน้าที่อะไร

จากนั้นตรวจว่า

• มีหัวข้อซ้ำหรือไม่
• ขาดอะไรหรือไม่
• ลำดับดีหรือไม่
• ตรง Intent หรือไม่

ถ้า Outline ผิด การแก้ก่อนเขียนเต็มจะง่ายกว่ามาก

③ ใช้คำตอบเดิมเป็นฐาน

ถ้าคำตอบเดิมดี 80% อย่าสั่ง

เขียนใหม่ทั้งหมด

เพราะอาจเสียส่วนที่ดีไป

ควรใช้

ใช้ Draft เดิมเป็นฐาน รักษาส่วนที่ดีไว้ และแก้เฉพาะ [ปัญหา]

ตัวอย่าง

รักษา Structure และข้อมูลเดิมทั้งหมด แต่ Rewrite ให้ภาษาเป็นธรรมชาติมากขึ้น

หรือ

รักษา Paragraph ที่ 1, 2 และ 4 ไว้ แก้เฉพาะ Paragraph 3 เพราะยังซ้ำกับ Section ก่อนหน้า

④ บอก Gemini ว่าอะไร “ห้ามเปลี่ยน”

ทุกครั้งที่แก้คำตอบ ควรกำหนด Must Preserve

ตัวอย่าง

ปรับคำตอบนี้ให้สั้นลง แต่ต้องรักษา:

• ตัวเลข
• วันที่
• ชื่อ
• Conclusion
• Key Recommendations

ช่วยป้องกันข้อมูลสำคัญหายระหว่าง Revision

⑤ แก้ทีละปัญหา

ถ้า Draft มีปัญหา 5 อย่าง ไม่จำเป็นต้องแก้ทั้งหมดในรอบเดียว

ตัวอย่าง Workflow

รอบ 1

แก้ Structure

รอบ 2

แก้ Fact

รอบ 3

แก้ Redundancy

รอบ 4

แก้ Tone

รอบ 5

ตรวจ Final

วิธีนี้ช่วยรู้ว่าการแก้แต่ละรอบส่งผลอย่างไร

⑥ บอกให้ Gemini ตรวจเฉพาะมิติเดียว

Prompt ตัวอย่าง

ในรอบนี้ตรวจเฉพาะ Redundancy อย่าแก้ Tone, Structure หรือข้อมูล เว้นแต่จำเป็นต่อการลบข้อความซ้ำ

หรือ

ตรวจเฉพาะ Grammar และ Clarity ห้ามเปลี่ยน Meaning

เหมาะมากกับ Editing

⑦ ใช้ Feedback ที่เจาะจง

Feedback แบบ

ยังไม่ดี

ไม่ได้บอก Gemini ว่าต้องแก้อะไร

ดีกว่าใช้

Introduction ยาวเกินไปและใช้เวลา 3 Paragraph กว่าจะตอบคำถามหลัก ให้ลดเหลือไม่เกิน 120 คำและตอบประเด็นหลักตั้งแต่ Paragraph แรก

หรือ

Section 3 กับ Section 5 พูดเรื่องเดียวกัน ให้รวมเป็น Section เดียวโดยรักษาตัวอย่างที่ดีที่สุดไว้

ยิ่ง Feedback ชัด Revision ยิ่งตรง

⑧ บอกเหตุผลของ Feedback เมื่อจำเป็น

ตัวอย่าง

ตัดศัพท์ Technical ที่ไม่จำเป็น เพราะ Audience เป็นมือใหม่

Gemini ไม่เพียงรู้ว่าต้องแก้อะไร แต่รู้ว่าเหตุใด

ช่วยให้มันปรับ Section อื่นให้สอดคล้องด้วย

⑨ ใช้ Before → Problem → Desired

เป็นรูปแบบ Feedback ที่ดี

ตัวอย่าง

ปัจจุบัน: Introduction อธิบาย Background ยาวเกินไป
ปัญหา: คนอ่านยังไม่เจอคำตอบเร็ว
ต้องการ: ตอบคำถามหลักภายใน 2–3 ประโยคแรก

ช่วยลดความกำกวมของคำว่า

ทำ Intro ให้ดีขึ้น

⑩ ให้ Gemini สร้างหลายเวอร์ชันก่อนเลือก

บางครั้งไม่รู้ว่าควรแก้แบบไหน

ใช้

สร้าง 3 เวอร์ชันของ Introduction:

1. Direct
2. Friendly
3. Expert

รักษาข้อมูลเหมือนกันทั้งหมด

จากนั้นเลือกอันที่เหมาะก่อนทำต่อ

⑪ Generate → Compare → Select

Workflow ที่มีประโยชน์มากคือ

สร้าง 3 ทางเลือก → เปรียบเทียบ → เลือก

ตัวอย่าง

สร้าง CTA 5 แบบ จากนั้นเปรียบเทียบว่าแต่ละแบบเหมาะกับ Goal ใด และแนะนำ 2 แบบที่เหมาะกับ Audience นี้มากที่สุด

ดีกว่าขอ CTA เดียวแล้วต้องเริ่มใหม่หากไม่ชอบ

⑫ Draft → Critique → Improve

เป็นหนึ่งในสูตรที่ใช้ได้กว้างที่สุด

Prompt:

สร้าง Draft ก่อน จากนั้นทำหน้าที่เป็น Reviewer และวิจารณ์ Draft ในด้าน Clarity, Completeness, Redundancy และ Practical Value แล้วสร้างเวอร์ชันปรับปรุง

ใช้ได้กับ

• Article
• Email
• Report
• Proposal
• Business Plan

⑬ ให้ Gemini Critique ก่อน Rewrite

บางครั้งควรรู้ปัญหาก่อนแก้

ใช้

ยังไม่ต้อง Rewrite ให้ระบุ 5 จุดอ่อนที่มีผลต่อคุณภาพมากที่สุดก่อน

จากนั้นเลือกว่าควรแก้ข้อไหน

ช่วยไม่ให้ AI เปลี่ยนส่วนที่เราชอบโดยไม่จำเป็น

⑭ จัด Priority ของสิ่งที่ต้องแก้

Prompt:

จากปัญหาที่พบ ให้เรียงตาม Impact ต่อ Goal แล้วแก้เฉพาะ 3 ข้อที่สำคัญที่สุดก่อน

เหมาะกับ Draft ใหญ่ที่มีปัญหาหลายจุด

⑮ ใช้ Impact vs Effort

สามารถสั่ง

แบ่งสิ่งที่ควรแก้เป็น:

• High Impact / Low Effort
• High Impact / High Effort
• Low Impact / Low Effort
• Low Impact / High Effort

แล้วเริ่มแก้จาก High Impact / Low Effort

มีประโยชน์กับงานจำนวนมาก

⑯ Rewrite เฉพาะ Section

ไม่จำเป็นต้องส่ง Draft ทั้งหมดให้เปลี่ยนใหม่

Prompt:

Rewrite เฉพาะ Section “วิธีเลือก…” โดยรักษา H2 และ Section อื่นทั้งหมดไว้เหมือนเดิม

ช่วยควบคุม Version ได้ดีขึ้น

⑰ Expand เฉพาะจุดที่บางเกินไป

Prompt:

Section นี้ยังตอบคำถามไม่ครบ ขยายเฉพาะเรื่อง [ประเด็น] เพิ่มประมาณ 2–3 Paragraph และห้ามเพิ่มหัวข้อใหม่

ป้องกันการขยายเกิน Scope

⑱ Shorten เฉพาะจุดที่ยาวเกินไป

Prompt:

ลด Section นี้ลงประมาณ 30% โดยรักษา Fact, Example และ Action Steps ไว้ ตัดเฉพาะคำเกริ่นและข้อความซ้ำ

ดีกว่า

ย่อให้หน่อย

เพราะบอกสิ่งที่ต้องรักษา

⑲ เปลี่ยน Tone โดยไม่เปลี่ยนเนื้อหา

Prompt:

ปรับ Tone ให้เป็น Professional + Friendly แต่รักษา Facts, Structure, Examples และ Conclusion เดิมทั้งหมด

เหมาะกับงานที่ Content ถูกแล้วแต่สำนวนไม่ตรง

⑳ เปลี่ยน Format โดยไม่เปลี่ยนข้อมูล

ตัวอย่าง

เปลี่ยน Paragraph นี้เป็น Checklist แต่ห้ามเพิ่มหรือลดข้อมูล

หรือ

เปลี่ยนข้อมูลนี้เป็นตาราง โดยรักษาทุก Fact เดิม

เป็น Transformation ที่ควรแยกจาก Content Editing

㉑ ให้ Gemini ตรวจ Requirement เดิม

เมื่อแก้หลายรอบ อาจเกิด Requirement Drift

Prompt:

เปรียบเทียบ Draft ปัจจุบันกับ Requirement แรก และระบุว่ามีข้อใดหายหรือถูกเปลี่ยนระหว่าง Revision

สำคัญมากกับงานยาว

㉒ ป้องกัน Scope Drift

หลังแก้หลายรอบ Gemini อาจเพิ่มสิ่งใหม่

ใช้

ห้ามขยาย Scope นอก [หัวข้อ] แม้จะเห็นว่าเกี่ยวข้อง หากมีไอเดียเพิ่มเติมให้แยกเป็น Suggestions ไม่ใส่ใน Final Draft

㉓ ป้องกัน Fact Drift

การ Rewrite หลายรอบอาจทำให้ตัวเลขหรือข้อมูลเปลี่ยน

Prompt:

ตรวจว่า Names, Dates, Numbers, Units และ Facts ยังตรงกับ Original Input ทุกจุด

เหมาะกับงานที่มีข้อมูลสำคัญ

㉔ ใช้ Original Source เป็น Ground Truth

ถ้าผ่าน Revision หลายทอด

อย่าใช้เฉพาะ Draft ล่าสุดเป็นฐานตลอด

ใช้

หาก Draft ล่าสุดขัดกับ Original Source ให้ยึด Original Source เป็น Ground Truth

ช่วยลดความคลาดเคลื่อนสะสม

㉕ ใช้ Version Labels

สำหรับงานยาว

สามารถเรียก

Draft v1
Draft v2
Final Candidate v3

Prompt:

ใช้ v2 เป็นฐานและสร้าง v3 โดยแก้เฉพาะ Issues 1–3

ช่วยไม่ให้สับสนว่า Version ไหนคืออะไร

㉖ เปรียบเทียบ Version ก่อนตัดสินใจ

Prompt:

เปรียบเทียบ v1 กับ v2 ในด้าน Clarity, Completeness, Length และ Goal Alignment และระบุว่า v2 เสียจุดแข็งอะไรจาก v1 หรือไม่

ไม่ควรคิดว่า Version ใหม่ดีกว่าเสมอ

㉗ Roll Back ได้เมื่อ Revision แย่ลง

ถ้าปรับแล้วแย่

ใช้

กลับไปใช้โครงสร้างของ Version 2 และรักษาเฉพาะการแก้ Grammar จาก Version 3

แนวคิดนี้คล้าย Version Control

㉘ Merge จุดดีจากหลาย Version

Prompt:

ใช้ Introduction จาก Version A, Structure จาก Version B และ Conclusion จาก Version C แล้วรวมเป็น Final Draft โดยแก้ Transition ให้ลื่น

มีประโยชน์เมื่อลองหลายแนวทาง

㉙ ให้ Gemini อธิบายสิ่งที่แก้

สำหรับงานสำคัญ

Prompt:

หลังแก้แล้ว สรุปเฉพาะการเปลี่ยนแปลงสำคัญ 5 ข้อ ห้ามเล่าทุกคำที่แก้

ช่วยตรวจ Revision ได้ง่าย

㉚ ใช้ Change Log

สำหรับ Prompt หรือ Document ที่แก้หลายรอบ

ตัวอย่าง

v1.1

• ตัด Introduction
• เพิ่ม Checklist
• รักษา Facts เดิม

v1.2

• เปลี่ยน Tone
• เพิ่ม FAQ

ช่วยย้อนดูเหตุผลของการเปลี่ยน

㉛ ให้ Gemini ตรวจเฉพาะ Delta

แทน Review ทั้งเอกสารทุกครั้ง

Prompt:

Review เฉพาะส่วนที่เปลี่ยนจาก v2 เป็น v3 และหา Regression ที่อาจเกิดจาก Changes เหล่านั้น

ช่วยประหยัดเวลาในงานใหญ่

㉜ ใช้ Checklist ในแต่ละรอบ

ตัวอย่าง Article Editing

Pass 1 — Intent

• ตอบ Search Intent หรือไม่

Pass 2 — Structure

• H2/H3 ซ้ำหรือไม่

Pass 3 — Content

• ขาดข้อมูลหรือไม่

Pass 4 — Language

• อ่านธรรมชาติหรือไม่

Pass 5 — Fact

• มี Unsupported Claim หรือไม่

Pass 6 — Final

• Format พร้อมใช้หรือไม่

เป็นระบบกว่าบอกว่า

ตรวจให้ดีที่สุด

㉝ ใช้ Editing Pass

การ Edit แบบหลาย Pass มีประสิทธิภาพมาก

Prompt:

รอบนี้คือ Structure Pass เท่านั้น ตรวจลำดับ Section, Heading และ Content Flow โดยยังไม่ Rewrite สำนวน

จากนั้น

รอบนี้คือ Clarity Pass รักษา Structure เดิม

แล้ว

รอบสุดท้ายคือ Fact & Constraint Check

㉞ ใช้ Quality Gate ก่อนเข้าสู่ขั้นต่อไป

ตัวอย่าง

อย่าเริ่มเขียน Full Draft จนกว่า Outline จะผ่าน Criteria:

• ไม่ซ้ำ
• ครบ Intent
• ลำดับ Logic ชัด

เหมาะกับ Workflow ซับซ้อน

㉟ ใช้ Success Criteria

Prompt:

Draft ถือว่าผ่านเมื่อ:

• ตอบ Primary Goal ครบ
• ไม่มีข้อมูลที่ไม่ได้ให้
• ไม่มี Section ซ้ำ
• Format ถูก
• มี Actionable Next Step

แล้วสั่ง

ตรวจ Draft กับ Criteria นี้ก่อน Revision รอบต่อไป

㊱ ให้ Gemini ให้คะแนนเพื่อหา Weak Point

ตัวอย่าง

ให้คะแนน 1–10 ในด้าน:

• Clarity
• Completeness
• Relevance
• Structure
• Practical Value

แล้วเลือกคะแนนต่ำสุด 2 ด้านมาปรับก่อน

คะแนนเป็นเพียงเครื่องมือจัด Priority ไม่ใช่มาตรฐานตายตัว

㊲ อย่าแก้ตามคะแนนอย่างเดียว

สิ่งสำคัญกว่าคะแนนคือเหตุผล

ถ้า Gemini ให้

Clarity 7/10

ควรถาม

อะไรทำให้ไม่เป็น 9/10? ระบุประโยคหรือ Section ที่มีปัญหา

จากนั้นแก้จุดจริง

㊳ ใช้ Adversarial Review

Prompt:

อ่าน Draft นี้เหมือน Reviewer ที่พยายามหาเหตุผลว่าทำไมยังไม่ควรอนุมัติ ระบุ Weakness ที่มีผลจริงเท่านั้น

เหมาะกับ Proposal หรือ Decision Memo

㊴ ใช้ Skeptical Reader

สำหรับ Marketing

อ่าน Landing Page นี้เหมือนลูกค้าที่ไม่เชื่อโฆษณาง่าย ๆ ระบุ Claim หรือจุดที่ยังทำให้ลังเล แล้วเสนอการแก้ที่ไม่สร้างข้อมูลใหม่

ช่วยปรับ Trust

㊵ ใช้ Beginner Review

สำหรับบทความมือใหม่

อ่านเหมือนคนที่ไม่รู้เรื่องนี้มาก่อน ระบุศัพท์หรือขั้นตอนที่ทำให้สับสน

㊶ ใช้ Expert Review

Prompt:

อ่านเหมือนผู้เชี่ยวชาญด้าน [เรื่อง] และหา Simplification ที่ผิด, Missing Edge Cases และข้อสรุปที่กว้างเกิน Evidence

ช่วยเพิ่ม Depth

㊷ ใช้ Multiple Reviewer Roles

สามารถ Review แยก

Editor

Clarity

Fact Checker

Accuracy

User

Usability

Expert

Technical Depth

แต่ควรทำแยกรอบ ไม่จำเป็นต้องให้ทุก Role ทำพร้อมกัน

㊸ ให้ Gemini ตรวจคำตอบตัวเองแบบเฉพาะเจาะจง

แทน

ตรวจตัวเอง

ใช้

ตรวจ Final Draft โดยเฉพาะ:

1. Claims ที่ไม่มี Source
2. Paragraph ซ้ำ
3. Heading ที่ไม่ตอบ Intent
4. ตัวเลขที่เปลี่ยนจาก Input

มีเป้าหมายชัดกว่า

㊹ ใช้ “What is still weak?”

หลังปรับแล้วถาม

หลัง Revision นี้ ยังเหลือ Weakness อะไรที่มี Impact สูงและควรแก้ก่อน Final?

ถ้าเหลือแต่จุดเล็ก อาจหยุดปรับได้

㊺ รู้ว่าเมื่อไรควรหยุดปรับ

การแก้ไม่สิ้นสุดอาจทำให้งานแย่ลง

หยุดเมื่อ

• Goal ครบ
• Constraints ผ่าน
• ไม่มี Error สำคัญ
• การแก้ต่อให้ผลเพิ่มน้อยมาก

ไม่จำเป็นต้องทำ Version 20 เพื่อให้ “สมบูรณ์แบบ”

㊻ ใช้ Diminishing Returns เป็นเกณฑ์

ถาม

การแก้รอบต่อไปจะเพิ่มคุณค่าจริงหรือเพียงเปลี่ยน Style?

ถ้าเป็นเพียง Preference เล็กน้อย อาจไม่จำเป็นต้องทำต่อ

㊼ อย่าให้ Gemini Rewrite เพราะ “อยากให้ดีขึ้น” อย่างเดียว

Prompt เช่น

ทำให้ดีกว่านี้

อาจทำให้มันเปลี่ยนสิ่งที่ดีอยู่แล้ว

ดีกว่า

ปัญหาหลักคือ [ปัญหา] แก้เฉพาะจุดนี้และรักษาส่วนอื่น

㊽ ใช้ Minimal Revision

Prompt:

ทำ Minimum Changes ที่จำเป็นเพื่อแก้ [ปัญหา] ห้าม Rewrite ส่วนที่ไม่ได้เกี่ยวข้อง

เหมาะมากกับ

• Code
• Legal/Business Draft
• SEO Article
• Policy Document

㊾ ใช้ Full Rewrite เมื่อ Structure ผิดจริง

บางครั้ง Patch ต่อไม่ได้

เช่น

• Structure พังทั้งชิ้น
• Goal เปลี่ยน
• Audience เปลี่ยน
• Source เปลี่ยนมาก

ในกรณีนี้ใช้

สร้าง Draft ใหม่จาก Requirement ล่าสุด โดยใช้ Draft เดิมเป็น Reference เฉพาะข้อมูลที่ยังถูกต้อง

ไม่ควร Patch งานที่ Architecture ผิดตั้งแต่ต้น

㊿ Prompt อเนกประสงค์สำหรับการปรับงานหลายรอบ

ใช้คำตอบปัจจุบันเป็น Draft

Goal หลักคือ [GOAL]

Requirement ที่ต้องรักษาคือ [REQUIREMENTS]

ปัญหาที่ต้องแก้ในรอบนี้คือ [ISSUE]

ทำตามขั้นตอน:

1. ระบุว่าปัญหาอยู่ตรงไหน
2. อธิบายสั้น ๆ ว่าทำไมจึงเป็นปัญหา
3. แก้เฉพาะส่วนที่เกี่ยวข้อง
4. รักษา Facts, Numbers, Names, Structure หรือส่วนที่ฉันกำหนดไว้
5. ตรวจว่าการแก้ไม่ได้สร้างปัญหาใหม่

ห้าม Rewrite ส่วนที่ไม่จำเป็น

หลังแก้ให้ส่ง Revised Version และสรุป Changes สำคัญสั้น ๆ

สูตร Iterative Prompting ที่ควรจำ

สูตรง่ายที่สุดคือ

Draft → Review → Fix → Validate

หรือแบบละเอียดขึ้น

Create → Critique → Prioritize → Revise → Compare → Validate

ตัวอย่าง

สร้าง Draft
หา 5 Weakness
เลือก 3 จุดที่ Impact สูงที่สุด
แก้เฉพาะ 3 จุด
เปรียบเทียบกับ Draft เดิม
ตรวจ Requirement ก่อน Final

วิธีปรับบทความด้วย Gemini แบบเป็นระบบ

ตัวอย่าง Workflow

Step 1 — Search Intent

วิเคราะห์ว่า Draft ตอบ Search Intent หรือไม่

Step 2 — Structure

ตรวจ H1/H2/H3 และหัวข้อซ้ำ

Step 3 — Coverage

หา Missing Questions

Step 4 — Redundancy

ตัดเนื้อหาซ้ำ

Step 5 — Style

ปรับภาษาให้อ่านธรรมชาติ

Step 6 — Fact

หา Unsupported Claims

Step 7 — Final

ตรวจ Format และ Summary

นี่มีประสิทธิภาพกว่าสั่ง

ปรับบทความให้ดีที่สุด

Prompt สำหรับ Article Revision รอบแรก

Review Draft นี้ในด้าน Search Intent และ Structure เท่านั้น ยังไม่ต้อง Rewrite

ระบุ:

• Section ที่ตอบ Intent ดี
• Section ที่หลุด
• Section ซ้ำ
• Missing Sections

จากนั้นเสนอ Revised Outline

Prompt สำหรับ Article Revision รอบสอง

ใช้ Revised Outline และ Draft เดิม เขียนเวอร์ชันใหม่โดยรักษา Facts และ Examples ที่ถูกต้อง แต่จัด Section ตาม Outline ใหม่

Prompt สำหรับ Article Revision รอบสาม

ตรวจเฉพาะ Redundancy และ Filler ลดความยาวส่วนที่ไม่เพิ่มข้อมูล แต่ห้ามตัดขั้นตอนหรือตัวอย่างที่จำเป็น

Prompt สำหรับ Article Revision รอบสี่

ปรับ Tone ให้ภาษาไทยธรรมชาติ Professional + Friendly โดยรักษา Facts และ Structure เดิม

Prompt สำหรับ Final Article Check

ก่อน Final ตรวจ:

• Search Intent
• H1/H2/H3
• Missing Information
• Unsupported Claims
• Redundancy
• Conclusion

แก้เฉพาะจุดที่ยังไม่ผ่าน

วิธีปรับ Email หลายรอบ

Draft

เขียน Email

Review

ตรวจว่าอ่านแล้วรู้ Required Action หรือไม่

Shorten

ลดเหลือ 120 คำ

Tone

ปรับให้ Friendly ขึ้น

Final

ตรวจ Deadline และชื่อ

ไม่ต้องเขียน Email ใหม่ทุกครั้ง

วิธีปรับ Business Plan

Workflow:

Assumptions → Risks → Numbers → Options → Recommendation

ตัวอย่าง

รอบแรกตรวจ Assumptions
รอบสองหา Risks
รอบสามตรวจ Numbers
รอบสี่เปรียบเทียบ Options
รอบห้าสรุป Recommendation

ช่วยไม่ให้ AI กระโดดไป Recommendation เร็วเกินไป

วิธีปรับ Marketing Campaign

ใช้

Hypothesis → Campaign → Measurement → Review → Iterate

ตัวอย่าง

Hypothesis คืออะไร?
Campaign ทดสอบอะไร?
Metric คืออะไร?
ผลออกมาอย่างไร?
รอบต่อไปควรเปลี่ยนอะไร?

Gemini สามารถช่วยทุกขั้น

วิธีปรับ Code ด้วย Gemini

อย่าใช้

Rewrite Code ให้ดีขึ้น

ใช้

Step 1

หา Bug

Step 2

เสนอ Minimal Fix

Step 3

สร้าง Test

Step 4

Review Regression

Step 5

Refactor หากจำเป็น

Correctness ควรมาก่อน Style

Prompt Coding Revision

ใช้ Code เดิมเป็นฐาน แก้เฉพาะ Bug [BUG] ห้ามเปลี่ยน Public API หรือเพิ่ม Dependency หลังแก้ให้สร้าง Regression Test และตรวจว่า Behavior อื่นยังเหมือนเดิม

วิธีให้ Gemini ปรับ Prompt ตัวเองหลายรอบ

Iterative Prompting ใช้กับ Prompt ได้เช่นกัน

รอบ 1

Review Prompt

รอบ 2

ลดความกำกวม

รอบ 3

ลบ Rule ซ้ำ

รอบ 4

เพิ่ม Output Format

รอบ 5

Test ด้วย Sample Input

สุดท้ายได้ Prompt Template ที่แข็งแรงขึ้น

Prompt Optimization Loop

Prompt v1 → Test → Find Failure → Minimum Change → Prompt v2 → Retest

นี่เหมือนการ Debug Software

อย่าแก้ Prompt จากปัญหาครั้งเดียวทุกครั้ง

ถ้า Output ผิดเพียงครั้งเดียว อย่ารีบเพิ่ม Global Rule

ควรดูว่า

ปัญหานี้เกิดซ้ำกับหลาย Input หรือไม่?

ถ้าไม่ อาจใช้ Feedback เฉพาะรอบแทน

ช่วยป้องกัน Prompt Bloat

Prompt Bloat คืออะไร?

Prompt Bloat คือ Prompt ที่ค่อย ๆ ยาวขึ้นเพราะเพิ่ม Rule ทุกครั้งที่เจอ Output ไม่ถูกใจ

สุดท้ายอาจมี

• Rule ซ้ำ
• Conflict
• Exception มาก
• Prompt แก้ยาก

ควร Review Prompt เป็นระยะและลบกฎที่ไม่จำเป็น

วิธีลด Prompt Bloat

Prompt:

ตรวจ Prompt นี้และแบ่งทุก Rule เป็น:

• Essential
• Useful
• Redundant
• Conflicting

จากนั้นสร้างเวอร์ชันสั้นลงโดยรักษา Essential Rules

Iterative Prompting ไม่เท่ากับสั่ง “ทำต่อ” อย่างเดียว

คำว่า

ทำต่อ

มีประโยชน์เมื่อ Context ชัดและ Task เป็นงานต่อเนื่อง

แต่ถ้าต้องการปรับคุณภาพ ควรบอก

ทำอะไรต่อ

เช่น

ทำต่อโดยตรวจเฉพาะ Fact

ทำต่อและลดความยาว 20%

ทำต่อจาก Outline โดยเขียนเฉพาะ H2 แรก

Feedback แบบนี้ควบคุมผลได้มากกว่า

วิธีใช้ Follow-up สั้น ๆ แต่มีประสิทธิภาพ

ตัวอย่าง

สั้นลง 20% รักษา Fact เดิม

เพิ่มตัวอย่าง 2 ตัว ห้ามเพิ่มหัวข้อใหม่

Professional ขึ้น แต่ไม่แข็ง

รวม H2 3 กับ H2 4 เพราะ Intent ซ้ำ

ตรวจเฉพาะตัวเลข

Follow-up ไม่ต้องยาวหาก Context เดิมชัด

อย่าส่ง Requirement เดิมซ้ำทั้งหมดทุกครั้ง

หากอยู่ใน Conversation เดียวกันและ Context ยังชัด อาจอ้าง

ใช้ Rules เดิมทั้งหมด และเพิ่ม Constraint นี้…

ช่วยลด Prompt ยาว

แต่ถ้าเริ่ม Conversation ใหม่ ควรใส่ Requirement สำคัญกลับเข้าไป

วิธีใช้ Reference Point

Prompt:

ใช้ Final Structure จากคำตอบก่อนหน้าเป็น Baseline และอย่าเปลี่ยน Heading เว้นแต่ฉันสั่ง

ช่วยล็อกสิ่งที่ตกลงกันแล้ว

“ล็อก” ส่วนที่ผ่านแล้ว

สามารถบอก

Section 1–3 ผ่านแล้ว ให้ถือว่าล็อก ห้ามเปลี่ยนโดยไม่จำเป็น แก้เฉพาะ Section 4

นี่มีประโยชน์มากกับงานยาว

Progressive Locking

Workflow

รอบแรก

ล็อก Outline

รอบสอง

ล็อก Facts

รอบสาม

ล็อก Tone

รอบสี่

Final Polish

เมื่อส่วนหนึ่งผ่านแล้ว ไม่ต้องให้ AI กลับไปเปลี่ยนซ้ำ

วิธีป้องกัน Gemini เปลี่ยนส่วนที่ล็อก

Prompt:

ข้อความใน <LOCKED> ถือเป็น Final ห้ามแก้ เปลี่ยน หรือลบ ใช้เป็น Context เท่านั้น

<LOCKED>
[ข้อความ]
</LOCKED>

และ

แก้เฉพาะ <EDITABLE>

ใช้ Editable Scope

ตัวอย่าง

<EDITABLE>
[ส่วนที่จะปรับ]
</EDITABLE>

Rewrite เฉพาะส่วนนี้

ช่วยควบคุมการแก้ได้ดีมาก

วิธีให้ Gemini เปรียบเทียบก่อนและหลัง

Prompt:

แสดงเฉพาะ Change Summary:

• Removed
• Added
• Rewritten
• Preserved

ไม่ต้องแสดงการเปลี่ยนคำเล็ก ๆ ทุกจุด

ช่วยตรวจ Revision อย่างรวดเร็ว

ใช้ Diff เมื่อแก้ Code

Prompt:

แสดงเฉพาะ Diff หรือ Block ที่เปลี่ยน ห้ามส่งทั้งไฟล์

เหมาะกับ Bug Fix ขนาดเล็ก

ใช้ Change Log กับเอกสาร

Prompt:

หลัง Revision ให้สรุป Changes ไม่เกิน 5 Bullet เพื่อให้ฉันตรวจว่า Scope ไม่ขยาย

วิธีให้ Gemini เลือก Revision Strategy

ถ้าไม่แน่ใจว่า Patch หรือ Rewrite

ใช้

ประเมินก่อนว่าควร:

A. Edit เฉพาะจุด
B. Restructure บาง Section
C. Rewrite ทั้งชิ้น

เลือกวิธีที่เปลี่ยนน้อยที่สุดแต่แก้ Root Problem ได้

Minimal Change Principle

แนวคิดที่ควรจำคือ

ถ้าส่วนเดิมยังดี อย่าเปลี่ยน

Prompt:

Preserve working parts. Change only what is necessary to satisfy the new requirement.

ใช้ได้กับทั้งเอกสารและ Code

วิธีให้ Gemini หาความเสี่ยงของ Revision

Prompt:

ก่อนแก้ ระบุว่าการเปลี่ยนนี้อาจทำให้ Requirement ไหนเสีย เช่น Length, Tone, Fact หรือ Compatibility แล้วตรวจจุดเหล่านั้นหลัง Revision

เป็น Revision Safety Check

Regression ในงานเขียนคืออะไร?

ไม่ใช่เฉพาะ Code

ตัวอย่าง

Draft v1 มี Fact ครบ

พอ v2 ทำให้สั้นลง กลับตัดข้อมูลสำคัญ

นี่คือ Regression

จึงควรตรวจ

สิ่งที่เคยถูกต้องยังถูกต้องอยู่หรือไม่?

Regression Check Prompt

เปรียบเทียบ Original กับ Revised Version และหา:

• Facts ที่หาย
• Meaning ที่เปลี่ยน
• Requirements ที่หลุด
• New Claims
• Formatting ที่เสีย

Refinement Loop สำหรับงานทั่วไป

ใช้ Workflow นี้ได้แทบทุกงาน

Round 1 — Create

สร้าง Draft

Round 2 — Diagnose

หา Weakness

Round 3 — Prioritize

เลือกสิ่งสำคัญ

Round 4 — Revise

แก้

Round 5 — Validate

ตรวจ Requirement

Round 6 — Stop

หยุดเมื่อผ่าน Criteria

Refinement Loop แบบ Prompt พร้อมใช้

ทำงานนี้เป็นรอบ:

Round 1: สร้าง Draft
Round 2: หา 5 Weakness ที่มีผลมากที่สุด
Round 3: แก้เฉพาะ Weakness เหล่านั้น
Round 4: ตรวจว่า Revision ไม่ทำให้ Fact หรือ Requirement เดิมเสีย
Round 5: สร้าง Final Version

Goal คือ [GOAL]

Constraints คือ [CONSTRAINTS]

วิธีไม่ให้ Gemini “วนแก้” ไปเรื่อย ๆ

กำหนด Stop Condition

ตัวอย่าง

หยุด Revision เมื่อ:

• ไม่มี Critical Issue
• ทุก Must-have ผ่าน
• ไม่มี Unsupported Claim
• การแก้ที่เหลือเป็นเพียง Style Preference

มีประโยชน์กับงานสำคัญ

Maximum Revision Rounds

สามารถกำหนด

ทำ Revision ไม่เกิน 3 รอบ และในแต่ละรอบแก้เฉพาะ Issue ที่มี Impact สูงที่สุด

ช่วยไม่ให้ Process ใหญ่เกินไป

ใช้ Human Checkpoint

สำหรับงานสำคัญควรให้คนตรวจระหว่าง Stage

เช่น

Outline → Human Approve → Draft → Human Review → Final

ไม่จำเป็นต้องให้ Geminiทำทุกขั้นโดยอัตโนมัติ

งานแบบไหนควรปรับหลายรอบ?

เหมาะมากกับ

• บทความยาว
• Proposal
• Strategy
• Business Plan
• Code
• Report
• Presentation
• Important Email

เพราะมี Requirement หลายด้าน

งานแบบไหนไม่ควร Over-Iterate?

เช่น

• คำตอบสั้น
• การคำนวณง่าย
• Translation สั้น
• Rewrite หนึ่งประโยค

ถ้าคำตอบตรงแล้ว ไม่ต้องทำ Review 5 รอบ

10 Follow-up Prompt ที่ควรเซฟไว้

①

ตรวจเฉพาะจุดที่ยังไม่ตอบ Goal

②

ลดความยาว 20% โดยรักษาข้อมูลสำคัญ

③

แก้เฉพาะ Section นี้

④

รักษา Structure เดิม เปลี่ยนเฉพาะ Tone

⑤

หา 5 จุดอ่อนก่อน ยังไม่ต้อง Rewrite

⑥

เลือก 3 จุดที่ Impact สูงที่สุดแล้วแก้

⑦

เปรียบเทียบ Version ก่อนและหลัง

⑧

ตรวจ Regression จากการแก้ครั้งล่าสุด

⑨

ตรวจ Constraints ก่อน Final

⑩

หากเหลือแต่ Style Preference ให้หยุด Revision

5 Prompt สำหรับปรับคำตอบที่ใช้บ่อยที่สุด

ถ้าต้องจำเพียง 5 อัน

1. Critique

หา 5 จุดที่ควรแก้ก่อน อย่า Rewrite

2. Focused Revision

แก้เฉพาะ [ISSUE] และรักษาส่วนอื่น

3. Preserve

รักษา Fact, Number, Date และ Meaning เดิม

4. Compare

เปรียบเทียบ Revised กับ Original และหา Regression

5. Validate

ตรวจ Requirement และ Constraints ก่อน Final

เพียง 5 อย่างนี้ก็ครอบคลุม Iterative Workflow ได้มาก

ข้อผิดพลาดที่พบบ่อยในการปรับคำตอบหลายรอบ

1. สั่ง “ทำให้ดีขึ้น” โดยไม่บอกปัญหา

Gemini ต้องเดา

2. Rewrite ทั้งหมดทุกครั้ง

เสียส่วนที่ดี

3. ไม่ล็อกข้อมูลสำคัญ

Facts เปลี่ยนระหว่างรอบ

4. แก้หลายมิติพร้อมกัน

ไม่รู้ว่าอะไรดีขึ้นหรือแย่ลง

5. ไม่เปรียบเทียบ Version

คิดว่าใหม่ต้องดีกว่า

6. ไม่ตรวจ Regression

Requirement เดิมหาย

7. เพิ่ม Rule ทุกครั้ง

Prompt Bloat

8. ปรับต่อทั้งที่ผ่านแล้ว

เสียเวลาและอาจทำให้งานแย่ลง

9. ไม่ใช้ Original Source

ข้อมูลค่อย ๆ Drift

10. ไม่มี Stop Condition

Revision ไม่จบ

Checklist ก่อนสั่ง Gemini ปรับคำตอบ

ตรวจว่า

① Goal คืออะไร
② Draft ปัจจุบันมีปัญหาอะไร
③ รอบนี้จะแก้เพียงเรื่องอะไร
④ ส่วนไหนห้ามเปลี่ยน
⑤ Facts อะไรต้องรักษา
⑥ ต้อง Rewrite ทั้งหมดจริงหรือไม่
⑦ มี Version ก่อนหน้าที่ดีกว่าบางส่วนหรือไม่
⑧ Success Criteria คืออะไร
⑨ ต้อง Compare Version หรือไม่
⑩ ต้องทำ Regression Check หรือไม่
⑪ มี Original Source สำหรับตรวจหรือไม่
⑫ เมื่อไรควรหยุด

Master Prompt สำหรับปรับคำตอบเป็นรอบ ๆ

<GOAL>
[เป้าหมายหลัก]
</GOAL>

<ORIGINAL_REQUIREMENTS>
[Requirement ที่ต้องรักษา]
</ORIGINAL_REQUIREMENTS>

<CURRENT_DRAFT>
[Draft ปัจจุบัน]
</CURRENT_DRAFT>

<ISSUE_THIS_ROUND>
[ปัญหาที่ต้องแก้ในรอบนี้]
</ISSUE_THIS_ROUND>

<MUST_PRESERVE>

• [Fact]
• [Number]
• [Structure]
• [ส่วนที่ล็อก]
</MUST_PRESERVE>

ทำตามขั้นตอน:

1. ตรวจเฉพาะ Issue ของรอบนี้
2. ระบุ Root Problem แบบสั้น
3. แก้เฉพาะจุดที่เกี่ยวข้อง
4. รักษา MUST_PRESERVE
5. เปรียบเทียบ Revised กับ Current Draft
6. ตรวจ Regression
7. ตรวจ Goal และ Requirements

หาก Draft ปัจจุบันผ่าน Requirement แล้วในส่วนใด ห้ามแก้ส่วนนั้นเพียงเพื่อเปลี่ยน Style

Output:

Revised Version

[เวอร์ชันที่แก้แล้ว]

Change Summary

สรุปการแก้ไม่เกิน 5 Bullet

Master Refinement Loop สำหรับ Gemini

หากต้องการให้ Gemini ช่วยตั้งแต่ Draft จน Final สามารถใช้

งานคือ [TASK]

Goal คือ [GOAL]

Input คือ [INPUT]

Constraints คือ [CONSTRAINTS]

ทำงานเป็นขั้น:

Phase 1 — Draft
สร้าง Draft ที่ตอบ Goal

Phase 2 — Review
หา Critical Issues และ High-impact Improvements

Phase 3 — Revise
แก้เฉพาะ Issues ที่สำคัญ

Phase 4 — Regression Check
ตรวจว่า Fact, Meaning และ Requirements เดิมไม่เสีย

Phase 5 — Final Validation
ตรวจ Goal, Constraints, Format และ Unsupported Claims

หากผ่านทุก Must-have แล้ว หยุด Revision และส่ง Final Version

ห้ามเปลี่ยนส่วนที่ผ่านแล้วโดยไม่มีเหตุผลชัดเจน

Prompt สำหรับแก้คำตอบเดิมแบบเร็ว

ถ้าไม่ต้องการ Template ใหญ่ ใช้ประโยคนี้

ใช้คำตอบเดิมเป็นฐาน แก้เฉพาะ [สิ่งที่ต้องแก้] รักษา [สิ่งที่ห้ามเปลี่ยน] และก่อนส่งให้ตรวจว่าการแก้ไม่ได้ทำให้ Requirement เดิมส่วนใดเสีย

สั้น แต่มีหลักสำคัญครบ

สูตรที่ดีที่สุดสำหรับการปรับคำตอบ

จำสูตร

Issue + Change + Preserve + Validate

ตัวอย่าง

Issue: Introduction ยาวเกินไป
Change: ลดเหลือ 100 คำและตอบ Main Question ตั้งแต่ต้น
Preserve: Facts และ Tone
Validate: ตรวจว่า Key Message ยังครบ

นี่เป็นรูปแบบ Feedback ที่ Gemini เข้าใจง่ายมาก

สรุป วิธีสั่ง Gemini ทำงานซ้ำและปรับคำตอบจนได้ผลลัพธ์ที่ดีที่สุด

การใช้ Gemini อย่างมีประสิทธิภาพไม่จำเป็นต้องสร้าง Prompt ครั้งแรกที่สมบูรณ์แบบ

งานซับซ้อนควรใช้วิธี

Draft → Review → Feedback → Revision → Validation

แทนการ

สั่งครั้งเดียวแล้วหวังว่าจะได้ Final ที่สมบูรณ์

หลักสำคัญคือ

• สร้าง Draft ก่อน
• Review ก่อน Rewrite
• แก้ทีละปัญหา
• ให้ Feedback ที่เจาะจง
• รักษาส่วนที่ดีไว้
• ล็อก Facts และ Requirement สำคัญ
• เปรียบเทียบ Version
• ตรวจ Regression
• ใช้ Original Source เป็น Ground Truth
• หยุดเมื่อผ่าน Success Criteria

Prompt พร้อมใช้ที่ควรเซฟไว้คือ

ใช้คำตอบปัจจุบันเป็น Draft โดย Goal หลักคือ [GOAL] ปัญหาที่ต้องแก้ในรอบนี้คือ [ISSUE] ให้แก้เฉพาะจุดที่เกี่ยวข้องและรักษา [FACTS / STRUCTURE / NUMBERS / PARTS TO PRESERVE] ไว้ทั้งหมด หลังแก้ให้เปรียบเทียบกับ Draft เดิม ตรวจว่าไม่มีข้อมูลหรือ Requirement สำคัญหาย และตรวจว่า Revision ไม่สร้างปัญหาใหม่ หากส่วนใดผ่านแล้ว ห้าม Rewrite เพียงเพื่อเปลี่ยนสำนวน

หัวใจของการทำงานแบบ Iterative คือ อย่าถามว่า “จะทำ Prompt ให้สมบูรณ์แบบตั้งแต่ครั้งแรกได้อย่างไร?” แต่ให้ถามว่า “รอบต่อไปควรแก้อะไรเพียงหนึ่งหรือสองเรื่องเพื่อให้งานดีขึ้นอย่างชัดเจน?”

เมื่อใช้ Gemini แบบนี้ เราจะควบคุมงานได้ง่ายขึ้น ลดการ Rewrite ซ้ำโดยไม่จำเป็น และค่อย ๆ พาคำตอบจาก Draft ธรรมดาไปสู่เวอร์ชันที่ตรง Goal และพร้อมใช้งานมากขึ้น