50 Prompt Gemini สำหรับโปรแกรมเมอร์ ช่วยเขียนและแก้โค้ดเร็วขึ้น

Google Gemini สามารถช่วยโปรแกรมเมอร์ได้หลายขั้นตอน ตั้งแต่ อธิบายโค้ด หา Bug เขียนฟังก์ชัน สร้าง Unit Test วิเคราะห์ Error ปรับ Performance Review Code เขียน Documentation ไปจนถึงช่วยออกแบบโครงสร้างระบบเบื้องต้น

แต่การใช้ AI เขียนโค้ดให้เร็วขึ้นไม่ได้หมายความว่าเราควรคัดลอก Code ที่ได้แล้วนำขึ้น Production ทันที

คำสั่งกว้าง ๆ เช่น

เขียนระบบ Login ให้หน่อย

อาจได้โค้ดจำนวนมาก แต่ Gemini ยังไม่รู้ว่า

• ใช้ภาษาอะไร
• Framework อะไร
• Version ไหน
• Database อะไร
• Authentication แบบไหน
• Environment เป็นอย่างไร
• Security Requirement มีอะไร
• ต้องรองรับ Load เท่าไร
• Codebase ปัจจุบันมี Structure แบบไหน

Prompt ที่ดีกว่าคือ

ฉันใช้ [ภาษา] + [Framework] เวอร์ชัน [Version] ต้องการสร้าง [Feature] โดยมี Requirement [รายละเอียด] และข้อจำกัด [Constraints] ช่วยเสนอ Approach ก่อน จากนั้นเขียนเฉพาะส่วนที่จำเป็น พร้อมอธิบาย Assumption, Edge Cases และ Test Cases

Prompt แบบนี้ทำให้ Gemini มี Context มากพอที่จะช่วยได้ตรงงานกว่าเดิม

บทความนี้รวม 50 Prompt Gemini สำหรับโปรแกรมเมอร์ ตั้งแต่การเรียนรู้ เขียน Code Debug Review Test Refactor ไปจนถึงการออกแบบระบบและ Documentation

วิธีใช้ Prompt Gemini สำหรับเขียนโค้ดให้ได้ผลดี

ก่อนส่ง Prompt ควรระบุข้อมูลสำคัญ เช่น

• Programming Language
• Framework
• Version
• Operating System
• Runtime
• Database
• Error Message
• Expected Behavior
• Actual Behavior
• Constraints
• Code ที่เกี่ยวข้อง

ตัวอย่าง

แทนที่จะถามว่า

ทำไมโค้ดนี้ Error?

ให้ใช้

ฉันใช้ Python 3.x โค้ดด้านล่างควรอ่านไฟล์ CSV แล้วคืนจำนวนแถว แต่ตอนรันได้ Error [ข้อความ Error] ช่วยวิเคราะห์ Root Cause จาก Code ที่ให้ก่อน อย่า Rewrite ทั้งโปรแกรม และเสนอวิธีแก้ที่เปลี่ยน Code ให้น้อยที่สุด

ยิ่ง Context ชัด การ Debug ก็ยิ่งมีประสิทธิภาพ

① Prompt อธิบายโค้ดสำหรับมือใหม่

อธิบาย Code ด้านล่างให้คนที่มีพื้นฐาน [ระดับ] เข้าใจ โดยอธิบายทีละส่วนว่าแต่ละบรรทัดหรือ Block ทำอะไร ข้อมูลไหลอย่างไร และ Output สุดท้ายคืออะไร

[CODE]

เหมาะกับการเรียน Code ที่คนอื่นเขียน

② Prompt อธิบายโค้ดแบบภาพรวมก่อนลงรายละเอียด

อ่าน Code ด้านล่างแล้วอธิบายก่อนว่าโปรแกรมนี้ทำอะไรในภาพรวม จากนั้นแบ่งเป็น Components หรือ Functions สำคัญ และอธิบาย Data Flow ตามลำดับการทำงาน

[CODE]

เหมาะกับ Codebase ที่ไม่คุ้นเคย

③ Prompt อธิบาย Function

อธิบาย Function นี้โดยตอบ:

1. รับ Input อะไร
2. คืนค่าอะไร
3. Logic หลักคืออะไร
4. มี Side Effects หรือไม่
5. Edge Cases คืออะไร
6. จุดไหนที่อาจเกิด Error

[FUNCTION]

④ Prompt อธิบาย Algorithm

อธิบาย Algorithm ใน Code นี้ด้วยภาษาง่ายก่อน จากนั้นวิเคราะห์ Time Complexity และ Space Complexity พร้อมอธิบายว่า Complexity มาจากส่วนไหนของ Code

[CODE]

⑤ Prompt แปลง Code เป็น Pseudocode

เปลี่ยน Code ด้านล่างเป็น Pseudocode ที่อ่านง่าย โดยรักษา Logic เดิมและตัดรายละเอียด Syntax ที่ไม่จำเป็น

[CODE]

มีประโยชน์เวลาต้องเข้าใจ Logic โดยไม่สนใจภาษาที่ใช้

⑥ Prompt สร้าง Function จาก Requirement

เขียน Function ด้วย [Language] สำหรับงาน [Task]

Input: [Input]

Expected Output: [Output]

Constraints:

• [Constraint 1]
• [Constraint 2]

ก่อนเขียน Code ให้สรุป Approach สั้น ๆ แล้วจึงเขียน Implementation พร้อมตัวอย่างการเรียกใช้

⑦ Prompt เขียน Code แบบ Minimal

เขียนวิธีแก้ [Problem] ด้วย [Language] โดยใช้ Code ให้น้อยและตรงที่สุด หลีกเลี่ยง Abstraction ที่ยังไม่จำเป็น และอธิบายเฉพาะส่วนสำคัญ

เหมาะกับ Utility หรือ Prototype ขนาดเล็ก

⑧ Prompt เขียน Code แบบ Production-Oriented

ออกแบบ Implementation สำหรับ [Feature] ด้วย [Language/Framework] โดยคำนึงถึง Validation, Error Handling, Logging, Testing, Maintainability และ Security ก่อนเขียน Code ให้ระบุ Assumptions และ Architecture ที่เลือก

ควร Review เพิ่มก่อนนำขึ้น Production จริง

⑨ Prompt สร้างหลาย Solution

แก้ปัญหา [Problem] ด้วย [Language] จำนวน 3 วิธี ได้แก่:

1. วิธีง่ายที่สุด
2. วิธีที่อ่านง่ายและ Maintainable
3. วิธีที่เน้น Performance

เปรียบเทียบ Complexity และ Trade-offs ก่อนแนะนำว่าควรใช้แบบใดในสถานการณ์ [Context]

⑩ Prompt แปลง Algorithm เป็นภาษาอื่น

แปลง Logic จาก Code [Language A] ด้านล่างเป็น [Language B] โดยรักษาพฤติกรรมเดิม อธิบายส่วนที่ไม่สามารถแปลงตรง ๆ ได้ และใช้แนวทางที่เป็น Idiomatic ของภาษาใหม่

[CODE]

⑪ Prompt หา Bug จาก Code

ตรวจ Code ด้านล่างเพื่อหา Bug โดย:

1. อธิบาย Expected Behavior
2. หา Root Cause ที่เป็นไปได้
3. ชี้บรรทัดหรือ Block ที่น่าสงสัย
4. เสนอ Fix ที่เปลี่ยน Code ให้น้อยที่สุด
5. สร้าง Test เพื่อพิสูจน์ว่าแก้แล้ว

[CODE]

⑫ Prompt Debug จาก Error Message

ฉันใช้ [Environment]

Error:

[ERROR MESSAGE]

Code ที่เกี่ยวข้อง:

[CODE]

ช่วยเรียงสาเหตุที่เป็นไปได้จากน่าจะเป็นมากที่สุด พร้อมวิธีตรวจทีละข้อ อย่าเสนอการติดตั้งหรือเปลี่ยน Configuration จำนวนมากพร้อมกัน

Prompt แบบนี้ดีกว่าถามเพียงว่า “Error นี้แก้ยังไง”

⑬ Prompt Debug แบบ Step-by-Step

ช่วย Debug ปัญหา [Problem] ทีละขั้น โดยเริ่มจากสิ่งที่ตรวจง่ายและปลอดภัยที่สุด หลังแต่ละขั้นให้บอกว่า:

• ถ้าผลเป็น A → ทำอะไรต่อ
• ถ้าผลเป็น B → ทำอะไรต่อ

อย่าเปลี่ยนหลายตัวแปรพร้อมกัน

เหมาะกับปัญหาที่ Root Cause ยังไม่ชัด

⑭ Prompt หา Logic Error

Code นี้รันได้แต่ผลลัพธ์ผิด

Expected:
[Expected Result]

Actual:
[Actual Result]

ช่วย Trace Logic ตามลำดับและหา Step แรกที่ค่าเริ่มแตกต่างจากสิ่งที่ควรเป็น

[CODE]

⑮ Prompt หา Edge Cases

สำหรับ Function ด้านล่าง ช่วยหา Edge Cases อย่างน้อย 15 กรณี แบ่งเป็น Empty Input, Boundary Values, Invalid Input, Duplicate Data, Large Input และ Unexpected Types

[CODE]

⑯ Prompt วิเคราะห์ Stack Trace

วิเคราะห์ Stack Trace นี้จากบนลงล่าง อธิบายว่าบรรทัดไหนเป็นต้นเหตุที่เป็นไปได้มากที่สุด และบรรทัดไหนเป็นเพียงผลต่อเนื่องของ Error

[STACK TRACE]

⑰ Prompt หา Race Condition

ตรวจ Code นี้ว่ามีความเสี่ยงเรื่อง Race Condition, Shared State หรือ Concurrency Bug หรือไม่ อธิบาย Scenario ที่ทำให้เกิดปัญหาและเสนอวิธีแก้ที่เหมาะกับ [Environment]

[CODE]

⑱ Prompt หา Memory Leak เบื้องต้น

วิเคราะห์ Code/Architecture นี้ว่ามี Pattern ที่อาจทำให้ Memory Leak หรือ Resource Leak หรือไม่ เช่น Listener ไม่ถูกถอด Connection ไม่ถูกปิด หรือ Cache โตไม่จำกัด พร้อมเสนอวิธีตรวจยืนยันก่อนแก้

⑲ Prompt หา Performance Bottleneck

วิเคราะห์ Code ด้านล่างเพื่อหา Performance Bottleneck โดยแยก CPU, Memory, I/O, Database Calls และ Algorithmic Complexity จากนั้นจัด Priority ว่าควร Profile จุดไหนก่อน

[CODE]

⑳ Prompt อธิบาย Error ให้เข้าใจง่าย

อธิบาย Error [Error Message] ให้โปรแกรมเมอร์ระดับ [Beginner/Intermediate] เข้าใจ โดยตอบว่า:

• Error หมายถึงอะไร
• มักเกิดจากอะไร
• ควรตรวจอะไรเป็นอันดับแรก
• มีวิธีแก้ใดที่ไม่ควรรีบทำ

㉑ Prompt Code Review

Review Code ด้านล่างในด้าน:

1. Correctness
2. Readability
3. Maintainability
4. Error Handling
5. Performance
6. Security
7. Testability

แบ่ง Finding เป็น Critical, High, Medium และ Low และอย่าเสนอ Refactor ที่ไม่สร้างคุณค่าชัดเจน

[CODE]

㉒ Prompt Review Pull Request

ช่วย Review การเปลี่ยนแปลงนี้เหมือนเป็น Pull Request โดยดู:

• Behavior ที่เปลี่ยน
• Regression Risk
• Missing Tests
• Breaking Changes
• Error Handling
• Naming
• Maintainability

สรุปท้ายสุดว่าอะไรควรแก้ก่อน Merge

[DIFF/CODE]

㉓ Prompt หา Code Smell

ตรวจ Code นี้และหา Code Smells เช่น Long Function, Deep Nesting, Duplication, Hidden Side Effects, God Object หรือ Tight Coupling พร้อมอธิบายว่าข้อไหนควรแก้จริงและข้อไหนยังปล่อยไว้ได้

㉔ Prompt ปรับ Naming

วิเคราะห์ชื่อ Variable, Function, Class และ Module ใน Code นี้ แล้วเสนอชื่อที่ชัดกว่าเฉพาะจุดที่ชื่อปัจจุบันทำให้เข้าใจผิดหรือคลุมเครือ หลีกเลี่ยงการ Rename เพียงเพื่อความแตกต่าง

[CODE]

㉕ Prompt ลด Code ซ้ำ

หา Duplication ใน Code นี้และเสนอวิธีรวม Logic โดยไม่สร้าง Abstraction ที่ซับซ้อนเกินไป อธิบายว่า Duplication ส่วนใดควรรวมและส่วนใดควรเก็บแยก

[CODE]

㉖ Prompt Refactor Function ใหญ่

Function นี้ยาวและทำหลายหน้าที่ ช่วยระบุ Responsibilities ที่ซ่อนอยู่ แล้วเสนอ Refactor Plan ก่อน อย่าเขียน Code ใหม่ทั้งหมดทันที

[FUNCTION]

จากนั้นค่อยสั่งให้ Refactor ทีละส่วน

㉗ Prompt ลด Nested If

Refactor Code นี้เพื่อลด Nested Conditions โดยพิจารณา Guard Clauses, Early Returns หรือแยก Function แต่ต้องรักษาพฤติกรรมเดิมและอธิบาย Trade-offs

[CODE]

㉘ Prompt ปรับ Code ให้อ่านง่าย

Rewrite Code นี้ให้ Readable ขึ้นโดยรักษา Behavior เดิมทั้งหมด เน้น Naming, Function Size และ Control Flow ห้ามเปลี่ยน Architecture หากไม่จำเป็น

㉙ Prompt Refactor แบบ Conservative

Refactor แบบ Conservative เปลี่ยนเฉพาะสิ่งที่ช่วยให้อ่านง่ายหรือแก้ Bug โดยรักษา Public API, Output, Exceptions และ Side Effects เดิม

เหมาะกับ Legacy Code ที่ไม่ต้องการความเสี่ยงสูง

㉚ Prompt ตรวจว่า Refactor เปลี่ยน Behavior หรือไม่

เปรียบเทียบ Version A กับ Version B และวิเคราะห์ว่ามีพฤติกรรมใดเปลี่ยนหรือไม่ โดยดู Input, Output, Exceptions, Side Effects และ Edge Cases

<VERSION_A>
[CODE A]
</VERSION_A>

<VERSION_B>
[CODE B]
</VERSION_B>

㉛ Prompt สร้าง Unit Test

สร้าง Unit Tests สำหรับ Function นี้ด้วย [Test Framework]

ครอบคลุม:

• Happy Path
• Boundary Cases
• Invalid Input
• Empty Input
• Error Cases

อธิบายสั้น ๆ ว่าแต่ละ Test ป้องกัน Regression อะไร

[FUNCTION]

㉜ Prompt หา Missing Test Cases

Review Tests และ Production Code ด้านล่าง แล้วหา Behavior สำคัญที่ยังไม่มี Test Coverage โดยเน้น Risk มากกว่าเปอร์เซ็นต์ Coverage

<CODE>
[CODE]
</CODE>

<TESTS>
[TESTS]
</TESTS>

㉝ Prompt สร้าง Test Cases จาก Requirement

จาก Requirement ต่อไปนี้ [Requirement] สร้าง Test Cases แบ่งเป็น Positive, Negative, Boundary และ Permission Cases พร้อม Expected Result ของแต่ละกรณี

㉞ Prompt สร้าง Integration Test Plan

สำหรับ Feature [Feature] ที่เชื่อม [Components] ช่วยสร้าง Integration Test Plan ครอบคลุม Success, Failure, Timeout, Retry, Partial Failure และ Data Consistency

㉟ Prompt สร้าง Regression Test

Bug เดิมคือ [Bug Description] และแก้ด้วย [Fix] ช่วยสร้าง Regression Test ที่ล้มเหลวก่อน Fix และผ่านหลัง Fix โดยทดสอบเฉพาะ Behavior ที่เกี่ยวข้อง

㊱ Prompt สร้าง Mock Data

สร้าง Mock Data สำหรับทดสอบ Schema [Schema] จำนวน [จำนวน] รายการ โดยครอบคลุม Normal, Boundary และ Invalid Examples และห้ามใช้ข้อมูลส่วนบุคคลจริง

㊲ Prompt ตรวจ Test ว่าทดสอบ Implementation มากเกินไปหรือไม่

Review Unit Tests นี้และระบุว่าข้อใดผูกกับ Implementation Detail มากเกินไปจน Refactor แล้ว Test แตกทั้งที่ Behavior ไม่เปลี่ยน พร้อมเสนอวิธีเน้น Behavior แทน

㊳ Prompt สร้าง Property-Based Test Ideas

สำหรับ Function [Function Behavior] ช่วยเสนอ Properties หรือ Invariants ที่ควรเป็นจริงสำหรับ Input จำนวนมาก แทนการสร้างเพียง Example Cases

㊴ Prompt สร้าง API Test Cases

สำหรับ Endpoint:

[METHOD] [PATH]

Request: [Schema]

Response: [Schema]

ช่วยสร้าง API Test Cases ครอบคลุม Authentication, Validation, Success, Not Found, Conflict, Rate Limit และ Server Error ตาม Requirement ที่ให้

㊵ Prompt ตรวจ Coverage เชิงคุณภาพ

อย่าดูเพียงเปอร์เซ็นต์ Coverage ช่วยวิเคราะห์ว่า Tests ชุดนี้ครอบคลุม Business-Critical Behaviors และ Failure Modes สำคัญหรือยัง

㊶ Prompt สร้าง README

สร้าง README สำหรับ Project นี้จากข้อมูล [ข้อมูล] โดยมี:

• Project Overview
• Requirements
• Installation
• Configuration
• Running Locally
• Tests
• Common Errors
• Deployment Notes

ห้ามสร้าง Command หรือ Environment Variable ที่ฉันไม่ได้ให้

㊷ Prompt สร้าง Documentation ให้ Function

เขียน Documentation สำหรับ Function นี้ โดยอธิบาย Purpose, Parameters, Return Value, Exceptions, Side Effects และ Example Usage ให้ตรงกับ Code จริง

[CODE]

㊸ Prompt สร้าง API Documentation

จาก API Definition ด้านล่าง สร้าง Documentation ที่มี Endpoint, Authentication, Request, Response, Error Codes และ Example โดยห้ามสร้าง Field ที่ไม่มีใน Schema

㊹ Prompt สร้าง Code Comment

เพิ่ม Comment เฉพาะส่วนของ Code ที่ “ทำไมต้องทำแบบนี้” ไม่ใช่อธิบาย Syntax ที่เห็นชัดอยู่แล้ว หลีกเลี่ยง Comment ทุกบรรทัด

[CODE]

㊺ Prompt สร้าง Changelog

จากรายการ Changes [รายการ] สร้าง Changelog แบบกระชับ แบ่ง Added, Changed, Fixed, Deprecated และ Removed โดยอย่าแต่งรายละเอียดที่ไม่มีใน Input

㊻ Prompt ออกแบบ Database Schema เบื้องต้น

ฉันกำลังสร้างระบบ [ระบบ] มี Entities [รายการ] และ Use Cases [รายการ] ช่วยเสนอ Database Schema เบื้องต้น พร้อม Relationships, Keys, Constraints และ Index Candidates ก่อนเขียน SQL

อย่าข้าม Requirement แล้วเริ่มสร้างตารางทันที

㊼ Prompt วิเคราะห์ Query ช้า

Query นี้ช้า:

[QUERY]

Schema และ Index ที่มี:

[SCHEMA/INDEXES]

ช่วยวิเคราะห์สาเหตุที่เป็นไปได้ก่อนเสนอ Index ใหม่ โดยดู Query Pattern, Selectivity, Join, Sorting และ Data Volume

ควรใช้ Execution Plan จริงประกอบถ้ามี

㊽ Prompt ออกแบบ REST API

ออกแบบ REST API สำหรับ [Feature] จาก Use Cases [รายการ]

ระบุ:

• Resources
• Endpoints
• Methods
• Request/Response
• Validation
• Errors
• Pagination
• Authentication Requirements

อธิบาย Design Decisions ก่อนสร้างตัวอย่าง Code

㊾ Prompt Review Architecture

Architecture ปัจจุบันคือ [อธิบาย] และมี Requirement [Requirements] ช่วย Review ในด้าน Scalability, Reliability, Complexity, Cost, Security และ Operational Burden พร้อมระบุจุดที่ยังไม่ควร Optimize ก่อนเวลา

㊿ Prompt อเนกประสงค์สำหรับโปรแกรมเมอร์

ฉันกำลังทำ [Task/Feature]

Language: [Language]

Framework: [Framework + Version]

Environment: [Environment]

Current Code/Architecture: [ข้อมูล]

Expected Behavior: [Expected]

Actual Behavior: [Actual]

Constraints: [Constraints]

ช่วยทำตามลำดับ:

1. สรุปสิ่งที่เข้าใจจาก Requirement
2. ระบุข้อมูลที่ยังขาด
3. วิเคราะห์ Approach หรือ Root Cause
4. เสนอ Solution ที่ง่ายที่สุดก่อน
5. เขียน Code เฉพาะส่วนที่จำเป็น
6. อธิบาย Edge Cases
7. สร้าง Tests
8. ระบุ Risk หรือ Assumption

อย่าเปลี่ยน Library, Framework, Architecture หรือ Configuration โดยไม่อธิบายเหตุผล

สูตร Prompt สำหรับ Coding ที่ควรจำ

หากไม่อยากจำทั้ง 50 Prompt ให้จำสูตรนี้

Goal + Environment + Input + Expected + Actual + Constraints + Output

ตัวอย่าง

Goal

แก้ API Error

Environment

Node.js + Express

Input

Request Body

Expected

HTTP 200

Actual

HTTP 500

Constraints

ห้ามเปลี่ยน Database Schema

Output

Root Cause + Minimal Fix + Test

รวมเป็น Prompt ได้ว่า

ฉันใช้ Node.js + Express Endpoint นี้ควรคืน HTTP 200 แต่ปัจจุบันคืน 500 เมื่อส่ง Request Body [ข้อมูล] Error คือ [Error] และห้ามเปลี่ยน Database Schema ช่วยหา Root Cause จาก Code ก่อน เสนอ Minimal Fix และสร้าง Regression Test

ชัดกว่า

API พัง แก้ให้หน่อย

มาก

Prompt สำหรับเรียน Programming โดยไม่ให้ Gemini ทำแทนทั้งหมด

ถ้ากำลังเรียน ไม่ควรเริ่มด้วย

เขียน Code ให้ฉัน

ลองใช้

ฉันกำลังเรียน [Concept] อย่าเขียน Solution เต็มทันที ช่วยอธิบาย Logic แล้วถามฉันว่าควรทำ Step แรกอย่างไร หากฉันติดให้ Hint เพิ่มทีละระดับ

วิธีนี้ช่วยให้ได้ฝึกคิดจริง

Prompt ให้ Gemini อธิบายก่อนเขียน Code

ก่อนเขียน Code ให้บอก:

1. Approach
2. Data Structure
3. Complexity
4. Edge Cases
5. Trade-offs

แล้วค่อยเขียน Implementation

มีประโยชน์มาก เพราะช่วยให้เราตรวจแนวคิดก่อนเจอ Code หลายร้อยบรรทัด

อย่าให้ Gemini Rewrite ทั้งไฟล์ถ้าต้องแก้ Bug เล็ก

Prompt ที่ดีกว่า

เสนอ Patch ที่เปลี่ยน Code ให้น้อยที่สุด และแสดงเฉพาะ Function หรือ Block ที่ต้องแก้

ช่วยลด Regression Risk

ใช้ Minimal Reproduction

ถ้า Bug ซับซ้อน

ให้ลด Code เหลือส่วนที่ยังทำให้ปัญหาเกิด

Prompt:

จาก Code นี้ ช่วยระบุว่ามีส่วนใดที่ตัดออกได้เพื่อสร้าง Minimal Repro ของ Bug โดยยังทำให้ Error เกิดเหมือนเดิม

Minimal Reproduction ช่วย Debug ได้เร็วขึ้นมาก

ให้ Gemini สร้าง Hypotheses ก่อน Fix

อย่าเริ่มจากสุ่มแก้

Prompt:

ก่อนเสนอ Fix ให้สร้าง Hypotheses 5 ข้อว่า Error นี้อาจเกิดจากอะไร พร้อม Evidence ที่สนับสนุนหรือหักล้างแต่ละข้อ

ช่วยให้ Debug มีระบบมากขึ้น

ใช้ Binary Search Debugging

สำหรับระบบที่มีหลาย Component

Prompt:

ช่วยออกแบบวิธี Debug แบบแบ่งครึ่งระบบเพื่อหาว่าปัญหาเกิดก่อนหรือหลัง [Component] โดยเลือก Test ที่ลดพื้นที่ค้นหาได้มากที่สุดในแต่ละขั้น

ให้ Gemini ช่วยอ่าน Log

Prompt:

วิเคราะห์ Log ด้านล่างโดยแยก:

• Normal Events
• Warnings
• First Anomaly
• Cascading Errors
• Likely Root Cause

อย่าถือว่า Error บรรทัดสุดท้ายคือต้นเหตุโดยอัตโนมัติ

ให้ Gemini ช่วยสร้าง Logging Plan

สำหรับ Flow [Flow] ช่วยเสนอ Logging Points ที่ช่วย Debug Production ได้โดยไม่ Log ข้อมูลลับหรือสร้าง Noise มากเกินไป

ควรหลีกเลี่ยงการ Log

• Password
• Token
• Secret
• ข้อมูลส่วนตัวที่ไม่จำเป็น

Prompt ตรวจ Error Handling

ตรวจ Code นี้ว่าจัดการ Error ครบหรือไม่ โดยดู:

• Validation Errors
• Network Failures
• Database Failures
• Timeouts
• Partial Failures
• Unexpected Exceptions

ระบุว่าตรงไหนควร Handle และตรงไหนควรปล่อยให้ระดับบนจัดการ

Prompt วิเคราะห์ Exception ที่ถูกกลืน

ตรวจ Code ว่ามี Catch Block ที่กลืน Error, Return ค่า Default แบบทำให้ Debug ยาก หรือ Log แล้วทำงานต่อทั้งที่ State ไม่ปลอดภัยหรือไม่

Prompt ตรวจ Async Code

Review Async Code นี้ในด้าน Missing Await, Unhandled Promise, Error Propagation, Parallelization และ Resource Cleanup

[CODE]

Prompt ตรวจ SQL Query

Review SQL Query นี้ในด้าน Correctness, SQL Injection Risk, Index Usage, Join Logic, Null Handling และ Scalability

[QUERY]

Prompt ตรวจ API Input Validation

สำหรับ Endpoint นี้ช่วยหา Inputs ที่ควร Validate ทั้ง Type, Length, Format, Range, Required Fields และ Cross-field Rules พร้อมเสนอ Error Responses ที่สม่ำเสมอ

Prompt ตรวจ Security เบื้องต้น

Review Code นี้เพื่อหา Security Issues ที่เกี่ยวกับ Input Validation, Authorization, Authentication, Secret Handling, Injection และ Sensitive Data Exposure พร้อมเรียงตาม Severity

[CODE]

การตรวจโดย AI ไม่ควรแทน Security Review จริงสำหรับระบบสำคัญ

Prompt ตรวจ Authorization

วิเคราะห์ Flow นี้ว่ามีจุดใดตรวจเพียง Authentication แต่ยังไม่ได้ตรวจว่า User มีสิทธิ์เข้าถึง Resource นั้นจริงหรือไม่

นี่เป็นข้อผิดพลาดที่พบได้บ่อยในระบบหลายประเภท

Prompt ตรวจ Secret

ตรวจ Config และ Code นี้ว่ามี Secret, Password, Token หรือ Credential ที่ไม่ควร Hard-code หรือ Log ออกมาหรือไม่ และเสนอวิธีแยก Secret ออกจาก Source Code

Prompt วิเคราะห์ Dependency

ฉันกำลังพิจารณาเพิ่ม Library [ชื่อ] เพื่อทำ [งาน] ช่วยสร้าง Decision Checklist ว่าควร Evaluate อะไรก่อนเพิ่ม Dependency เช่น Maintenance, Size, Security, License, API Stability และความจำเป็นจริง

สำหรับ Version หรือสถานะ Library ปัจจุบันควรตรวจ Documentation ล่าสุดเพิ่มเติม

อย่าเปลี่ยน Dependency เพียงเพราะ AI แนะนำ

Gemini อาจเสนอ Library ที่ไม่เหมาะกับ Version ของ Project

ควรตรวจ

• Compatibility
• Version
• Maintenance
• Documentation
• License
• Security

ก่อนติดตั้ง

Prompt วิเคราะห์ Build Error

Build ล้มเหลวด้วย Error [Error]

Environment [Environment]

Changes ล่าสุด [Changes]

ช่วยหา Root Cause ที่เป็นไปได้และเรียงวิธีตรวจจากสิ่งที่เปลี่ยนล่าสุดก่อน

Prompt วิเคราะห์ Deployment Error

Deployment ก่อนหน้าสำเร็จ แต่ Version ปัจจุบันล้มเหลว ข้อมูลคือ [Logs/Changes] ช่วยเปรียบเทียบสิ่งที่เปลี่ยนและสร้าง Rollback/Diagnosis Checklist โดยไม่แนะนำให้ล้างระบบหรือข้อมูลเป็นขั้นแรก

Prompt Review Migration

Review Database Migration นี้ในด้าน Data Loss, Locking, Backward Compatibility, Rollback และ Deployment Order

[MIGRATION]

Prompt ออกแบบ Backward-Compatible Change

ฉันต้องเปลี่ยน [API/DB Schema] จาก [Old] เป็น [New] โดยมี Client เก่ายังใช้งานอยู่ ช่วยออกแบบ Migration แบบ Backward Compatible เป็นขั้นตอน

Prompt วิเคราะห์ Breaking Change

เปรียบเทียบ API Version A กับ B และหา Breaking Changes ที่อาจกระทบ Existing Clients พร้อมเสนอ Migration Strategy

Prompt สร้าง Git Commit Message

จาก Diff ต่อไปนี้ ช่วยสร้าง Commit Message ที่อธิบาย “สิ่งที่เปลี่ยนและเหตุผล” แบบกระชับ หลีกเลี่ยงรายละเอียด Implementation ที่ไม่จำเป็น

[DIFF]

Prompt สร้าง Pull Request Description

จาก Changes [Diff/Summary] สร้าง PR Description มี:

• Problem
• Solution
• Key Changes
• Testing
• Risks
• Screenshots/Notes ที่ควรแนบ

ห้าม Claim ว่า Test ผ่านหากฉันไม่ได้ให้ผล Test

Prompt สร้าง Release Notes

จากรายการ Changes [ข้อมูล] สร้าง Release Notes สำหรับผู้ใช้ทั่วไป โดยอธิบาย Impact มากกว่า Technical Implementation

Prompt สร้าง Technical Documentation จาก Code

อ่าน Module นี้แล้วสร้าง Documentation ที่อธิบาย Architecture, Public API, Data Flow, Dependencies และ Common Failure Modes โดยอิงเฉพาะ Code ที่เห็น

Prompt สร้าง Onboarding Guide สำหรับ Developer ใหม่

จากข้อมูล Project [ข้อมูล] สร้าง Developer Onboarding Guide โดยเรียง:

1. Setup
2. Architecture
3. Main Modules
4. Local Development
5. Tests
6. Debugging
7. Deployment
8. Common Gotchas

Prompt อธิบาย Legacy Code

Code นี้ไม่มี Documentation ช่วย Reverse Engineer แบบระมัดระวัง แยกว่าอะไร “ยืนยันได้จาก Code” และอะไรเป็น “สมมติฐานเกี่ยวกับ Intent ของผู้เขียน”

นี่สำคัญ เพราะ AI อาจเดาเหตุผลของ Code เดิม

Prompt หา Dead Code

วิเคราะห์ Codebase Section นี้และระบุ Code ที่ “อาจ” ไม่ถูกใช้งาน พร้อมหลักฐานที่ต้องตรวจต่อก่อนลบ เช่น References, Dynamic Calls หรือ Configuration

ไม่ควรลบ Dead Code จากการเดาเพียงอย่างเดียว

Prompt สร้าง Refactoring Plan

ฉันต้องการปรับ Module [Module] แต่ห้ามหยุด Development งานอื่น ช่วยสร้าง Refactoring Plan แบบ Incremental ที่แต่ละขั้น Deploy ได้และมี Test รองรับ

Prompt ประเมิน Technical Debt

จากรายการปัญหา [รายการ] ช่วยจัด Technical Debt ตาม Impact, Frequency, Risk และ Cost to Fix แล้วแบ่งเป็น Fix Now, Schedule และ Accept

Prompt ช่วยตัดสินใจ Build vs Buy

เราต้องการ [Capability] มีทางเลือก Build เองหรือใช้ [Service/Library] ช่วยเปรียบเทียบ Development Cost, Maintenance, Flexibility, Vendor Risk, Security และ Time to Market

Prompt ออกแบบ Cache

System [รายละเอียด] มี Bottleneck [ปัญหา] ช่วยวิเคราะห์ก่อนว่าควรใช้ Cache หรือไม่ หากควรใช้ ให้เสนอ Cache Key, TTL, Invalidation Strategy และ Failure Mode

อย่าเพิ่ม Cache ก่อนรู้ Bottleneck จริง

Prompt วิเคราะห์ N+1 Query

Code นี้โหลดข้อมูลช้าและอาจมี N+1 Query ช่วย Trace Database Access Pattern และอธิบายว่าจะยืนยันปัญหานี้จาก Log หรือ Query Count อย่างไร

Prompt ออกแบบ Pagination

API ต้องคืนข้อมูลประมาณ [จำนวน] Records ช่วยเปรียบเทียบ Offset Pagination กับ Cursor Pagination ตาม Use Case [Use Case] แล้วเสนอ API Contract ที่เหมาะสม

Prompt ออกแบบ Retry

Operation [Operation] อาจ Fail ชั่วคราว ช่วยวิเคราะห์ว่าควร Retry หรือไม่ ถ้าควรใช้ ให้เสนอ Max Attempts, Backoff, Jitter และเงื่อนไข Error ที่ควร/ไม่ควร Retry

Prompt วิเคราะห์ Idempotency

Endpoint [Endpoint] อาจถูก Client Retry ช่วยวิเคราะห์ว่าต้องทำ Idempotent หรือไม่ และเสนอ Idempotency Strategy ที่ป้องกันการสร้างข้อมูลซ้ำ

Prompt ออกแบบ Rate Limiting

API [API] มี Use Case [Use Case] ช่วยเสนอ Rate Limiting Strategy โดยพิจารณา User, IP, Token, Burst และ Legitimate High-volume Clients

Prompt ออกแบบ Logging แบบ Structured

สร้าง Logging Schema สำหรับ Service [Service] โดยมี Request ID, Event Name, Severity และ Error Context แต่ห้าม Log Sensitive Data

Prompt ออกแบบ Metrics

สำหรับ Service [Service] ช่วยเลือก Metrics ที่ควรติดตามด้าน Traffic, Errors, Latency และ Saturation พร้อมอธิบายว่า Metric ไหนควรมี Alert

Prompt สร้าง Incident Checklist

สำหรับ Incident [ประเภทปัญหา] ช่วยสร้าง Checklist สำหรับ Detect → Triage → Mitigate → Verify → Communicate → Postmortem โดยเน้นลดผลกระทบก่อนหา Root Cause เต็มรูปแบบ

Prompt สร้าง Postmortem

จากข้อมูล Incident [ข้อมูล] สร้าง Postmortem แบบ Blameless มี Timeline, Impact, Root Cause, Contributing Factors, Detection, Response และ Action Items ห้ามเดาข้อมูลที่ไม่ได้ให้

Prompt สร้าง Architecture Decision Record

ช่วยสร้าง ADR สำหรับการตัดสินใจ [Decision]

มี:

• Context
• Options
• Decision
• Consequences
• Trade-offs

ใช้เฉพาะข้อมูลที่ให้และแยก Assumption ชัดเจน

Prompt เปรียบเทียบ Technology

เปรียบเทียบ [Technology A] กับ [Technology B] สำหรับ Use Case [Use Case] โดยดู Performance, Ecosystem, Learning Curve, Operational Cost, Maintainability และ Migration Risk อย่าสรุปว่าอันไหนดีกว่าโดยไม่อิง Requirement

ถ้าเป็น Version หรือ Technology ที่เปลี่ยนเร็ว ควรตรวจ Documentation ปัจจุบันก่อนตัดสินใจ

วิธีให้ Gemini ไม่แก้ Code เกินขอบเขต

เพิ่ม Constraint:

ห้ามเปลี่ยน Public API
ห้ามเปลี่ยน Database Schema
ห้ามเพิ่ม Dependency
ห้ามแก้ไฟล์อื่น
ห้ามเปลี่ยน Behavior ที่ไม่เกี่ยวกับ Bug

นี่ช่วยลด Scope Creep จาก AI

วิธีให้ Gemini แสดง Patch แทนทั้งไฟล์

Prompt:

แสดงเฉพาะ Code Block ที่ต้องแก้ พร้อม Before/After หรือ Diff ที่เล็กที่สุด อย่า Rewrite ทั้งไฟล์

มีประโยชน์กับ Code ขนาดใหญ่

วิธีให้ Gemini ระบุ Assumption

Prompt:

ก่อนเขียน Code ให้ระบุ Assumption ที่กำลังใช้ เช่น Input Format, Runtime Version, Thread Model หรือ Database Behavior หาก Assumption ใดไม่แน่ใจให้ทำเครื่องหมาย

ช่วยจับจุดที่ AI อาจกำลังเดา

วิธีให้ Gemini ไม่สร้าง API ที่ไม่มีจริง

Prompt:

ใช้เฉพาะ API, Function และ Library ที่อยู่ใน Code หรือ Documentation ที่ฉันให้ หากต้องใช้ API อื่นให้ระบุว่าต้องตรวจ Documentation ก่อน

สำคัญมาก เพราะ AI อาจสร้างชื่อ Method ที่ดูสมจริงแต่ไม่มีอยู่จริง

วิธีให้ Gemini ตรวจ Code ที่ตัวเองเพิ่งเขียน

หลังได้ Code สั่งต่อว่า

Review Code ที่คุณเพิ่งสร้างเหมือนเป็น Reviewer คนอื่น หา Bug, Missing Validation, Edge Cases, Unsupported API และ Tests ที่ยังขาด ก่อนเสนอ Final Version

ช่วยเพิ่ม Quality Check อีกชั้น

วิธีให้ Gemini สร้าง Test ก่อน Code

ใช้แนวทาง Test-First

Prompt:

จาก Requirement [Requirement] สร้าง Test Cases ก่อนโดยยังไม่เขียน Implementation หลังจาก Test ครบแล้วค่อยเสนอ Code ที่ทำให้ Tests ผ่าน

เหมาะกับ Feature ที่ Behavior ชัด

วิธีให้ Gemini แยก Correctness กับ Optimization

Prompt:

ตรวจ Correctness ก่อน หาก Logic ยังผิดห้าม Optimize เมื่อยืนยัน Behavior แล้วจึงเสนอ Performance Improvements แยกอีก Section

ป้องกันการ Optimize Code ที่ยังผิด

วิธีให้ Gemini หลีกเลี่ยง Premature Optimization

เสนอ Optimization เฉพาะจุดที่มีเหตุผลจาก Complexity, Profile หรือ Usage Pattern ที่ให้ หากไม่มีหลักฐาน Bottleneck ให้ระบุว่าควร Measure ก่อน

วิธีใช้ Gemini กับ Performance

Workflow ที่เหมาะคือ

Measure → Hypothesize → Profile → Change → Benchmark

ไม่ใช่

Guess → Rewrite ทุกอย่าง

Prompt:

จาก Performance Data นี้ [ข้อมูล] ช่วยสร้าง Hypotheses และสิ่งที่ควร Profile ก่อนเสนอ Refactor

วิธี Benchmark Code

Prompt:

สร้าง Benchmark Plan สำหรับเปรียบเทียบ Version A กับ B โดยควบคุม Input, Warm-up, Iterations และ Metrics ให้เหมือนกัน พร้อมระบุปัจจัยที่อาจทำให้ผล Benchmark หลอกได้

วิธีใช้ Gemini กับ Database

ควรให้ข้อมูลอย่างน้อย

• Schema
• Index
• Query
• Data Volume
• Query Frequency
• Execution Plan ถ้ามี

ไม่ควรถามเพียง

ทำ SQL ให้เร็วขึ้น

เพราะไม่มี Context เพียงพอ

วิธีใช้ Gemini กับ System Design

เริ่มจาก Requirements

Prompt:

ก่อนออกแบบระบบ ให้แยก Functional Requirements, Non-functional Requirements, Scale, Availability, Data Consistency และ Constraints จากข้อมูลที่ฉันให้ แล้วระบุสิ่งที่ยังไม่รู้

จากนั้นค่อยออกแบบ Components

อย่าเริ่ม System Design จาก Technology

คำถามแบบ

ใช้ Kafka ดีไหม?

ควรเปลี่ยนเป็น

Requirement ของเราคือ [Requirement] ช่วยวิเคราะห์ก่อนว่าต้องมี Message Broker หรือไม่ แล้วจึงเปรียบเทียบ Options

Technology ควรตาม Requirement ไม่ใช่กลับกัน

Prompt System Design แบบครบ

ระบบที่ต้องการคือ [System]

Users: [จำนวน]

Traffic: [ข้อมูล]

Data: [ข้อมูล]

Availability: [Requirement]

Consistency: [Requirement]

Constraints: [Constraints]

ช่วย:

1. สรุป Requirements
2. ระบุ Assumptions
3. เสนอ High-level Architecture
4. อธิบาย Data Flow
5. หา Bottlenecks
6. วิเคราะห์ Failure Modes
7. เสนอ Scaling Strategy
8. ระบุสิ่งที่ไม่ควรสร้างเกินความจำเป็น

Gemini เขียน Code ได้ แต่ต้องตรวจอะไรบ้าง?

ก่อนใช้ Code จริง ควรตรวจอย่างน้อย

① Logic ถูกหรือไม่
② API มีจริงหรือไม่
③ Version Compatible หรือไม่
④ Error Handling ครบหรือไม่
⑤ Input Validation มีหรือไม่
⑥ Security มีปัญหาหรือไม่
⑦ Edge Cases ครบหรือไม่
⑧ Tests ผ่านหรือไม่
⑨ Performance เหมาะหรือไม่
⑩ License หรือ Dependency มีข้อจำกัดหรือไม่

อย่าคัดลอก Code ไป Production ทันที

Workflow ที่ปลอดภัยกว่าคือ

1. Generate

ให้ Gemini สร้าง Draft

2. Understand

อ่านให้เข้าใจว่าทำอะไร

3. Review

ตรวจ Logic และ Security

4. Test

รัน Test

5. Integrate

รวมเข้ากับ Codebase

6. Monitor

ตรวจผลหลัง Deploy

ถ้าเราอธิบายไม่ได้ว่า Code ทำอะไร ก็ไม่ควรรีบนำไปใช้ในระบบสำคัญ

ใช้ Gemini ช่วยเขียน Test มากกว่าข้าม Test

หนึ่งในประโยชน์ที่ดีของ AI คือช่วยสร้าง Test Cases

หลัง Gemini เขียน Code ให้ถามทันทีว่า

มี Test อะไรที่อาจทำให้ Code นี้พัง?

หรือ

สร้าง Adversarial Test Cases สำหรับ Implementation นี้

ช่วยให้เห็นกรณีที่ไม่ได้คิดตั้งแต่แรก

ให้ Gemini ท้าทาย Solution ตัวเอง

Prompt:

สมมติว่า Solution นี้ผิดหรือไม่เหมาะ ช่วยหาเหตุผล 10 ข้อว่ามันอาจล้มเหลวใน Production และบอกวิธีตรวจแต่ละข้อ

เหมาะกับ Code หรือ Architecture สำคัญ

ใช้ Gemini เป็น Reviewer มากกว่า Generator อย่างเดียว

หลายครั้งการนำ Code ที่เราเขียนเองมาให้ Gemini Review ให้คุณค่ามากกว่าขอให้มันสร้างตั้งแต่ศูนย์

เพราะเรายังคงควบคุม

• Architecture
• Intent
• Business Logic

แล้วใช้ AI ช่วยหา Blind Spots

10 Prompt ที่โปรแกรมเมอร์ควรเซฟไว้ก่อน

ถ้าไม่ต้องการเก็บครบ 50 Prompt ให้เริ่มจาก

① อธิบาย Code
② หา Bug
③ Debug จาก Error Message
④ Code Review
⑤ หา Edge Cases
⑥ Refactor แบบ Conservative
⑦ สร้าง Unit Tests
⑧ หา Missing Tests
⑨ Review Architecture
⑩ Prompt อเนกประสงค์ข้อ 50

ชุดนี้ครอบคลุมงาน Coding ประจำวันที่พบได้บ่อยมาก

ข้อผิดพลาดที่พบบ่อยเมื่อใช้ Gemini เขียน Code

1. ไม่ระบุ Version

AI อาจใช้ API คนละ Version

2. ไม่ส่ง Error Message จริง

ทำให้ Debug จากการเดา

3. ส่ง Code ไม่ครบ Context

Root Cause อาจอยู่นอก Function ที่ส่ง

4. ให้ Rewrite ทั้งไฟล์

ทั้งที่ Bug มีจุดเดียว

5. ติดตั้ง Library เพิ่มทันที

ทั้งที่ Standard Library อาจเพียงพอ

6. ไม่อ่าน Code ก่อนใช้

เสี่ยงได้ Behavior ที่ไม่ต้องการ

7. ไม่สร้าง Tests

ไม่รู้ว่าการแก้ทำให้ส่วนอื่นพังหรือไม่

8. เชื่อ API ที่ Gemini พิมพ์มา

Method หรือ Parameter อาจไม่มีจริง

9. Optimize ก่อน Measure

Code ซับซ้อนขึ้นแต่ไม่ได้เร็วขึ้นจริง

10. ใช้ AI แทน Code Review ทั้งหมด

ระบบสำคัญยังควรมี Human Review และการทดสอบจริง

Checklist ก่อนใช้ Code จาก Gemini

ตรวจว่า

① Language ถูกหรือไม่
② Framework ถูกหรือไม่
③ Version ถูกหรือไม่
④ Requirement ครบหรือไม่
⑤ Assumption มีอะไร
⑥ API ทุกตัวมีจริงหรือไม่
⑦ Input Validation ครบหรือไม่
⑧ Error Handling ครบหรือไม่
⑨ Security ตรวจแล้วหรือไม่
⑩ Edge Cases มี Test หรือไม่
⑪ Unit Tests ผ่านหรือไม่
⑫ Integration Tests ผ่านหรือไม่
⑬ ไม่มี Secret ใน Code หรือไม่
⑭ Dependency จำเป็นจริงหรือไม่
⑮ Performance วัดแล้วหรือไม่
⑯ Code สอดคล้องกับ Style ของ Project หรือไม่
⑰ มี Regression Risk หรือไม่
⑱ คนในทีมเข้าใจ Code นี้หรือไม่

Prompt Template สำหรับ Debug แบบครบ

<ENVIRONMENT>
Language: [Language]
Framework: [Framework]
Version: [Version]
OS/Runtime: [Environment]
</ENVIRONMENT>

<EXPECTED>
[Expected Behavior]
</EXPECTED>

<ACTUAL>
[Actual Behavior]
</ACTUAL>

<ERROR>
[Error Message]
</ERROR>

<CODE>
[Relevant Code]
</CODE>

<RECENT_CHANGES>
[Changes]
</RECENT_CHANGES>

ช่วย:

1. สร้าง Hypotheses
2. เรียงตามความน่าจะเป็น
3. ระบุวิธีพิสูจน์แต่ละข้อ
4. หา Root Cause
5. เสนอ Minimal Fix
6. สร้าง Regression Test

อย่าเปลี่ยน Dependency หรือ Architecture เว้นแต่จำเป็น

Prompt Template สำหรับ Code Review

<CONTEXT>
[Code ทำหน้าที่อะไร]
</CONTEXT>

<CODE>
[Code]
</CODE>

Review:

• Correctness
• Security
• Maintainability
• Performance
• Error Handling
• Testability

แบ่ง Finding เป็น Critical / High / Medium / Low และเสนอ Fix เฉพาะ Issue ที่มีเหตุผลชัดเจน

Prompt Template สำหรับ Refactor

<CODE>
[Code]
</CODE>

Goal: [เหตุผลที่ต้อง Refactor]

Constraints:

• Behavior ต้องเหมือนเดิม
• Public API ต้องเหมือนเดิม
• ห้ามเพิ่ม Dependency
• Tests เดิมต้องผ่าน

ก่อนเขียน Code ให้สร้าง Refactoring Plan แล้วแก้ทีละขั้น

Prompt Template สำหรับ Test

<REQUIREMENT>
[Requirement]
</REQUIREMENT>

<CODE>
[Code]
</CODE>

สร้าง Test Plan ครอบคลุม:

• Happy Path
• Boundaries
• Invalid Input
• Error Conditions
• Regression Risks

จากนั้นเขียน Tests ด้วย [Framework]

Prompt Template สำหรับ System Design

System: [System]

Users/Traffic: [Scale]

Data: [Data]

Functional Requirements: [Requirements]

Non-functional Requirements: [Availability/Latency/etc.]

Constraints: [Constraints]

ก่อนเสนอ Architecture:

1. สรุป Requirement
2. ระบุ Missing Information
3. ระบุ Assumption

จากนั้นออกแบบ Components, Data Flow, Storage, APIs, Failure Handling และ Scaling พร้อม Trade-offs

สรุป 50 Prompt Gemini สำหรับโปรแกรมเมอร์

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

แทนที่จะถามว่า

Code นี้พัง ทำไง?

ควรให้

Goal + Language + Framework + Version + Expected + Actual + Error + Code + Constraints

Prompt อเนกประสงค์ที่ควรเซฟไว้คือ

ฉันกำลังทำ [Task] ด้วย [Language] และ [Framework + Version] Environment คือ [Environment] Expected Behavior คือ [Expected] แต่ Actual Behavior คือ [Actual] และ Error ที่ได้คือ [Error] Code ที่เกี่ยวข้องคือ [Code] Constraints คือ [Constraints] ช่วยวิเคราะห์ก่อนว่า Root Cause ที่เป็นไปได้มีอะไร เรียงตามความน่าจะเป็นและบอกวิธีตรวจทีละข้อ จากนั้นเสนอ Minimal Fix ที่เปลี่ยน Code ให้น้อยที่สุด สร้าง Tests สำหรับ Happy Path, Edge Cases และ Regression พร้อมตรวจ Security, Error Handling และ Assumptions ก่อนส่ง Final Code

หัวใจสำคัญคือ อย่าใช้ Gemini เพียงเพื่อผลิต Code ให้เร็วที่สุด แต่ใช้มันเพื่อทำให้กระบวนการคิด Debug Review และ Test เร็วขึ้นด้วย

เมื่อใช้แบบนี้ AI จะไม่ได้แทนทักษะของโปรแกรมเมอร์ แต่จะช่วยลดเวลาที่ใช้กับงานซ้ำ เพิ่มมุมมองในการตรวจ Code และช่วยให้เรามีเวลามากขึ้นกับ Architecture, Business Logic และการตัดสินใจที่ต้องอาศัยความเข้าใจระบบจริง