วิธีใช้ Gemini ตรวจหา Bug ในโค้ด - COMSIAM – ศูนย์รวมไอที รีวิว Gadget SEO และบทความเทคโนโลยี

Google Gemini สามารถช่วยตรวจหา Bug ใน Source Code วิเคราะห์ Error Message, Stack Trace, Logic และความสัมพันธ์ระหว่างไฟล์ เพื่อช่วยหาว่าปัญหาอาจเกิดจากส่วนใดของโปรแกรมได้ เหมาะทั้งกับ Code สั้น ๆ และโปรเจกต์หลายไฟล์ที่นำเข้าเป็น Code Folder หรือ GitHub Repository

แต่การใช้ Gemini หา Bug ให้ได้ผลดีไม่ควรเริ่มจากคำสั่งว่า “โค้ดพัง ช่วยแก้ให้หน่อย” เพราะข้อมูลไม่เพียงพอ วิธีที่แม่นกว่าคือส่ง อาการ + Error Message + Code ที่เกี่ยวข้อง + สิ่งที่คาดว่าจะเกิด + สิ่งที่เกิดจริง + Environment แล้วให้ Gemini วิเคราะห์ Root Cause ก่อนเสนอการแก้ไข

❶ 🐛 Bug ในโปรแกรมคืออะไร

Bug คือข้อผิดพลาดใน Software ที่ทำให้โปรแกรมทำงานไม่ตรงตามที่ออกแบบไว้

Bug ไม่ได้หมายถึงโปรแกรมเปิดไม่ได้เพียงอย่างเดียว แต่อาจเป็นปัญหาหลายรูปแบบ เช่น

โปรแกรม Crash
หน้าเว็บแสดงผลผิด
คำนวณผิด
Login ไม่ได้
Database ไม่บันทึก
API ตอบ Error
Button กดแล้วไม่ทำงาน
ข้อมูลหายบางส่วน
โปรแกรมช้า
Memory สูงผิดปกติ
Permission ผิด
Code ทำงานได้แต่ให้ผลลัพธ์ผิด

Bug บางประเภทเห็นได้ทันที แต่บางประเภทเกิดเฉพาะกับข้อมูลบางชุดหรือ Environment บางแบบ

❷ 🤖 Gemini ตรวจหา Bug ได้ไหม

ได้ Gemini สามารถช่วย Debug ปัญหา Code ได้หลายรูปแบบ เช่น

🔍 อ่าน Source Code
⚠️ วิเคราะห์ Error Message
📚 อ่าน Stack Trace
🧠 ตรวจ Logic
🔗 Trace Function Call
📊 ตรวจ Data Flow
🐛 หา Root Cause ที่เป็นไปได้
🔁 หา Race Condition เบื้องต้น
🗄️ วิเคราะห์ Database Query
🌐 วิเคราะห์ API Flow
🔐 ตรวจ Security Issue เบื้องต้น
🧪 เสนอ Test Case เพื่อ Reproduce Bug
♻️ เสนอ Patch
✅ ช่วยตรวจว่าการแก้อาจกระทบส่วนอื่นหรือไม่

Google ยังระบุว่า Gemini สามารถใช้ GitHub Repository เพื่อช่วยทำความเข้าใจ Codebase และ Debug Issues ได้

❸ 📋 ข้อมูลอะไรควรส่งให้ Gemini เวลาหา Bug

ยิ่ง Context ครบ การวิเคราะห์ก็ยิ่งมีประโยชน์

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

1. อาการ

อธิบายว่าเกิดอะไรขึ้น

เช่น

“กด Login แล้วหน้าจอหมุนค้าง”

2. สิ่งที่ควรเกิด

เช่น

“เมื่อ Username และ Password ถูกต้องควรเข้าสู่ Dashboard”

3. สิ่งที่เกิดจริง

เช่น

“API ตอบ 500 และหน้าเว็บไม่เปลี่ยนหน้า”

4. Error Message

ส่งข้อความ Error เต็ม ๆ

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

ส่ง Function หรือไฟล์ที่น่าจะเกี่ยวข้อง

6. Environment

เช่น

Operating System
Programming Language
Version
Framework
Library Version
Database
Browser
Runtime

ข้อมูลทั้งหมดนี้ช่วยลดการเดาของ AI

❹ 🧠 Prompt ที่ดีที่สุดสำหรับให้ Gemini หา Bug

สามารถใช้ Prompt แม่แบบนี้ได้

“ช่วย Debug ปัญหานี้โดยยังไม่ต้อง Rewrite Code

อาการ:
[อธิบาย]

Expected Behavior:
[สิ่งที่ควรเกิด]

Actual Behavior:
[สิ่งที่เกิดจริง]

Error Message:
[Error]

Environment:
[ภาษา / Framework / Version / OS]

Code:
[แนบ Code]

ให้วิเคราะห์ตามลำดับ:

Error หมายถึงอะไร
จุดที่น่าจะเกี่ยวข้อง
Root Cause ที่เป็นไปได้
หลักฐานจาก Code ที่สนับสนุนแต่ละสาเหตุ
วิธีทดสอบว่าแต่ละสมมติฐานถูกหรือผิด
วิธีแก้ที่เปลี่ยน Code น้อยที่สุด
ผลกระทบที่อาจเกิดหลังแก้

แยกสิ่งที่ยืนยันได้จาก Code ออกจากสิ่งที่เป็นเพียงสมมติฐาน”

Prompt นี้เหมาะกว่าการสั่งให้ Gemini เขียน Code ใหม่ทันที

❺ ⚠️ ส่ง Error Message เต็ม ๆ อย่าตัดออก

Error Message มักมีข้อมูลสำคัญมาก

ตัวอย่าง

TypeError: Cannot read properties of undefined (reading 'name')
    at getUserProfile (user.js:42:17)
    at async profileController (profile.js:18:5)

อย่าส่งแค่

TypeError

เพราะ Stack Trace บอกได้ว่า

Error อยู่ไฟล์ไหน
บรรทัดไหน
Function ใด
Function ใดเรียกต่อมา

Prompt

“อ่าน Stack Trace นี้จากบนลงล่าง แล้วอธิบาย Call Stack ก่อน จากนั้นระบุจุดที่ควรเปิด Code ตรวจเป็นอันดับแรก”

วิธีนี้ทำให้ Debug เป็นระบบมากขึ้น

❻ 🔍 ให้ Gemini หา Root Cause ก่อนแก้ Code

สิ่งที่ควรหลีกเลี่ยงคือ

“แก้ Code นี้ให้หน่อย”

แล้ว Gemini Rewrite ทั้ง Function

เพราะอาจแก้อาการแต่ไม่แก้ต้นเหตุ

ควรสั่ง

“ยังไม่ต้องสร้าง Code แก้ไข ให้หา Root Cause ก่อน”

ตัวอย่าง

หน้าเว็บแสดง

Cannot read properties of undefined

สาเหตุอาจเป็น

API ไม่ส่ง Field ที่คาดไว้
Function ถูกเรียกก่อนข้อมูลโหลดเสร็จ
Object ถูกสร้างไม่ครบ
Property สะกดผิด
Database ไม่พบ Record

ต้องรู้ก่อนว่าสาเหตุใดจริง

❼ 🧪 ให้ Gemini สร้างวิธี Reproduce Bug

Bug ที่ Reproduce ไม่ได้จะแก้ยากมาก

ใช้ Prompt

“จากข้อมูลนี้ ช่วยสร้างขั้นตอน Reproduce Bug ที่สั้นที่สุด เพื่อให้ฉันทดสอบว่าปัญหาเกิดจริงภายใต้เงื่อนไขใด”

ตัวอย่าง

เปิดหน้า Login
ใส่ Account ที่ไม่มี Profile
กด Login
API /profile ตอบข้อมูลไม่มี name
Frontend Crash

เมื่อ Reproduce ได้ชัด การแก้และการสร้าง Test จะง่ายขึ้น

❽ 🪜 วิธี Debug ด้วย Gemini แบบ Step by Step

Workflow ที่แนะนำคือ

ขั้นที่ 1 Reproduce

ทำให้ Bug เกิดซ้ำได้

ขั้นที่ 2 เก็บ Error

เก็บ Error Message และ Stack Trace

ขั้นที่ 3 จำกัด Scope

หาว่า Bug น่าจะอยู่ Module ใด

ขั้นที่ 4 วิเคราะห์ Root Cause

ให้ Gemini อธิบายสาเหตุที่เป็นไปได้

ขั้นที่ 5 Test Hypothesis

ทดสอบทีละสมมติฐาน

ขั้นที่ 6 สร้าง Patch

แก้เฉพาะจุด

ขั้นที่ 7 Run Test

ตรวจว่า Bug หาย

ขั้นที่ 8 Regression Test

ตรวจ Feature อื่น

ขั้นที่ 9 Review

ตรวจ Code ที่เปลี่ยน

นี่เป็น Workflow ที่ปลอดภัยกว่าการสุ่มแก้ Code หลายจุดพร้อมกัน

❾ 💻 วิธีให้ Gemini ตรวจ Bug ใน Function สั้น ๆ

ตัวอย่าง Python

def average(numbers):
    return sum(numbers) / len(numbers)

Code นี้ทำงานได้ถ้า numbers มีข้อมูล

แต่ถ้าเรียก

average([])

จะเกิดปัญหา Division by Zero

สามารถถาม Gemini

“Review Function นี้และหา Input ที่ทำให้โปรแกรม Error หรือให้ผลลัพธ์ไม่ถูกต้อง โดยยังไม่ต้องแก้ Code”

Gemini อาจช่วยหา Edge Case เช่น

Empty List
ค่าไม่ใช่ Number
None
Data Type ผิด

จากนั้นจึงสร้าง Test ก่อนแก้

❿ 🧩 วิธีหา Logic Bug ที่ไม่มี Error Message

Logic Bug ยากกว่า Syntax Error เพราะโปรแกรมรันได้ปกติ แต่ผลลัพธ์ผิด

ตัวอย่าง

def discount(price, percent):
    return price - percent

ถ้าต้องการลดราคาเป็นเปอร์เซ็นต์ Code นี้มี Logic ผิด แม้จะไม่มี Exception

ควรถาม

“ตรวจ Function นี้เทียบกับ Requirement ว่า Discount ต้องคำนวณเป็นเปอร์เซ็นต์ และหา Logic ที่ไม่ตรง Requirement”

สิ่งสำคัญคือ Gemini ต้องรู้ Requirement

หากไม่มี Requirement AI ก็ไม่รู้ว่าผลลัพธ์ใดคือสิ่งที่ถูกต้อง

🐍 วิธีใช้ Gemini หา Bug ใน Python

Python มักเจอปัญหา เช่น

TypeError
ValueError
KeyError
IndexError
AttributeError
ModuleNotFoundError
IndentationError

Prompt ตัวอย่าง

“Python Code นี้เกิด KeyError: 'email'

Trace ว่าค่า Dictionary มาจากที่ใด และตรวจว่ามี Case ใดที่ Key email ไม่มีอยู่ โดยยังไม่ต้องแก้ Code”

จากนั้นอาจถามต่อ

“เสนอวิธีแก้ที่ไม่ซ่อน Error จริง และยังรักษา Behavior เดิม”

⚙️ วิธีใช้ Gemini หา Bug ใน JavaScript

JavaScript มักมี Bug จาก

undefined
null
Promise
async/await
Event
DOM
Scope
Type Coercion

ตัวอย่าง

const userName = user.profile.name;

ถ้า profile ไม่มีค่า Code จะ Error

Prompt

“Trace ว่า user.profile ถูกกำหนดค่าจากที่ใด และหาเส้นทางที่ทำให้ profile เป็น undefined”

ดีกว่าถามว่า

“เพิ่ม Optional Chaining ให้หน่อย”

เพราะ Optional Chaining อาจเพียงซ่อน Bug ต้นเหตุ

🐘 วิธีใช้ Gemini หา Bug ใน PHP

PHP Application สามารถมีปัญหาจาก

Undefined Variable
Database Connection
Query
Session
Header
Include
Permission
PHP Version

ตัวอย่าง Prompt

“PHP Code นี้ Login สำเร็จแต่ Session ไม่ถูกเก็บ

Trace ตั้งแต่รับ Form → ตรวจ Password → สร้าง Session → Redirect และหา Step ที่อาจผิด”

หากใช้ WordPress ควรระบุเพิ่มว่า

WordPress Version
PHP Version
Plugin
Theme
Hook

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

🗄️ วิธีใช้ Gemini หา Bug ใน SQL

SQL Bug อาจไม่ได้เกิด Error เสมอไป

ตัวอย่าง Query อาจรันได้แต่ได้ข้อมูลซ้ำหรือยอดรวมผิด

Prompt

“Query นี้ให้ยอดรวมสูงกว่าความจริง ตรวจ JOIN และ GROUP BY แล้วอธิบายว่ามีโอกาสเกิด Row Duplication ตรงไหน”

สามารถส่ง

Schema
Query
Sample Data
Expected Result
Actual Result

ไปพร้อมกัน

ยิ่ง Context ครบ ยิ่ง Debug ง่าย

🌐 วิธีใช้ Gemini Debug API

ถ้า API มีปัญหา ควรให้ข้อมูลทั้ง Request และ Response

ตัวอย่าง

POST /api/login

Request:
{
  "email": "test@example.com"
}

Response:
500 Internal Server Error

พร้อม Log ฝั่ง Server

จากนั้นถาม

“Trace API Request นี้จาก Route → Controller → Service → Database และระบุจุดที่สามารถทำให้เกิด 500”

ช่วยแยกปัญหาออกเป็น Layer

🔄 วิธี Trace Bug ข้ามหลายไฟล์

โปรเจกต์จริงอาจมี Flow เช่น

Frontend
↓
API Route
↓
Controller
↓
Service
↓
Repository
↓
Database

ถ้า Import Code Folder หรือ GitHub Repository เข้า Gemini สามารถถาม

“Trace Feature Checkout ตั้งแต่ผู้ใช้กดปุ่มจน Order ถูกบันทึก Database และระบุจุดที่สามารถทำให้ Order ซ้ำได้”

นี่เป็นจุดที่การให้ Gemini เห็นหลายไฟล์มีประโยชน์มาก

📂 ใช้ Code Folder หา Bug อย่างไร

Gemini Web App รองรับ Import Code Folder

หลังนำ Project เข้าแล้ว Prompt ที่แนะนำคือ

“Error นี้เกิดใน Project ที่แนบมา

ก่อนแก้:

หาไฟล์ทั้งหมดที่เกี่ยวข้อง
Trace Flow
หา Root Cause
แยก Cause ที่ยืนยันได้ออกจาก Hypothesis
เสนอ Test เพื่อยืนยัน
ค่อยเสนอ Patch”

เหมาะกับ Bug ที่เกี่ยวข้องหลาย Module

🐙 ใช้ GitHub Repository Debug อย่างไร

Google ระบุโดยตรงว่าสามารถ Import GitHub Repository เข้า Gemini แล้วถามให้ช่วย Debug Issues ได้

หลัง Import สามารถใช้ Prompt

“ค้นหา Source Code ที่เกี่ยวข้องกับ Error นี้จาก Repository แล้วสร้าง Dependency Chain ของ Function ที่เกี่ยวข้อง”

หรือ

“หา Commit ไม่ต้องทำ เพราะ Repository ที่ Import ผ่าน Gemini ไม่ได้ให้ Commit History ผ่านฟีเจอร์นี้ ให้ตรวจเฉพาะ Codebase ปัจจุบันที่มองเห็น”

สิ่งนี้ช่วยไม่ให้ Prompt ขอข้อมูลที่ Integration ไม่ได้มี

🧪 วิธีให้ Gemini สร้าง Regression Test ก่อนแก้ Bug

แนวทางที่ดีคือสร้าง Test ที่ทำให้ Bug Fail ก่อน

Prompt

“จาก Bug นี้ ช่วยสร้าง Regression Test ที่ควร Fail กับ Code ปัจจุบัน และ Pass หลังจากแก้ Bug”

Workflow

Bug
↓
Create Failing Test
↓
Fix Code
↓
Test Pass
↓
Run Full Test Suite

ข้อดีคือป้องกัน Bug เดิมกลับมาอีกในอนาคต

🧠 ให้ Gemini สร้าง Hypothesis หลายข้อ

อย่าให้ AI ฟันธงสาเหตุเดียวเร็วเกินไป

ใช้ Prompt

“เสนอ Root Cause ที่เป็นไปได้สูงสุด 5 ข้อ เรียงจากมีหลักฐานมากที่สุดไปน้อยที่สุด และบอกวิธีทดสอบแต่ละข้อ”

ตัวอย่าง

ลำดับ	สาเหตุ	วิธีตรวจ
1	Response ไม่มี field	Inspect API Response
2	State ยังโหลดไม่เสร็จ	Log State
3	Property ชื่อผิด	ตรวจ Schema

ทำให้ Debug เป็นกระบวนการทดสอบ ไม่ใช่เดา

🔎 วิธีใช้ Log ช่วย Gemini หา Bug

Log เป็นข้อมูลที่มีประโยชน์มาก

ส่งเฉพาะช่วงที่เกี่ยวข้อง เช่น

10:01:05 Login request
10:01:05 User found: 182
10:01:06 Profile: null
10:01:06 TypeError...

แล้วถาม

“เชื่อมเหตุการณ์ใน Log กับ Code และอธิบายว่าจุดเปลี่ยนจากข้อมูลปกติไปเป็น Error อยู่ตรงไหน”

อย่าส่ง Log ทั้ง Server หลาย GB โดยไม่จำเป็น

เลือกเฉพาะช่วงก่อนและหลัง Error

⏱️ วิธีหา Bug ที่เกิดเป็นบางครั้ง

Intermittent Bug มักเกี่ยวข้องกับ

Race Condition
Timing
Network
Cache
Concurrent Request
Session
External API

Prompt

“Bug นี้ไม่ได้เกิดทุกครั้ง ช่วยสร้างรายการข้อมูลที่ควร Log เพิ่มเพื่อแยก Race Condition, Network Problem และ State Problem ออกจากกัน”

นี่มีประโยชน์กว่าการให้ AIเดา Patch จาก Code อย่างเดียว

🚀 Gemini ช่วยหา Performance Bug ได้ไหม

ได้ในระดับ Code Review เบื้องต้น

ตัวอย่าง

“Function นี้ใช้เวลานานมากเมื่อข้อมูลเพิ่มขึ้น ตรวจ Time Complexity, Loop, Database Query และ Network Call ที่อาจเป็น Bottleneck”

แต่ Performance ต้องใช้ข้อมูล Runtime ประกอบ เช่น

Profiler
Query Time
CPU
Memory
Response Time

AI ไม่ควรฟันธง Performance จาก Source Code เพียงอย่างเดียวหากไม่มีหลักฐาน

🔐 Gemini ช่วยหา Security Bug ได้ไหม

สามารถช่วย Review จุดเสี่ยง เช่น

SQL Injection
XSS
Input Validation
Authentication
Authorization
Secret Handling
Path Traversal
Insecure Configuration

Prompt

“ตรวจเฉพาะ Security Bug ที่มีหลักฐานจาก Code และแยกข้อสงสัยที่ต้องใช้ Static Scanner หรือ Runtime Test เพิ่ม”

Gemini ไม่ควรถูกใช้แทน Security Tools ทั้งหมด

สำหรับ Production ควรใช้

SAST
Dependency Scanner
Secret Scanner
DAST
Manual Review

ร่วมด้วย

♻️ วิธีให้ Gemini เสนอ Patch แบบเปลี่ยน Code น้อยที่สุด

หลังยืนยัน Root Cause แล้ว ให้สั่ง

“เสนอ Minimal Patch สำหรับ Bug นี้ โดย:

เปลี่ยน Code ให้น้อยที่สุด
ไม่ Refactor ส่วนอื่น
รักษา Public API เดิม
อธิบายแต่ละบรรทัดที่เปลี่ยน
ระบุ Regression Risk
เพิ่ม Test สำหรับ Bug นี้”

Minimal Patch ทำให้ Review ง่ายกว่าการ Rewrite ทั้ง Module

🆚 ขอ Patch เดียวหรือหลายทางเลือก

Bug บางชนิดแก้ได้หลายแบบ

สามารถถาม

“เสนอวิธีแก้ 3 แบบ:

Minimal Fix
Clean Fix
Long-term Architecture Fix

เปรียบเทียบ Risk และผลกระทบของแต่ละแบบ”

ช่วยให้ Developer เลือกตามสถานการณ์

Production Hotfix อาจต้องการ Minimal Fix

ส่วน Version ใหญ่ในอนาคตอาจเลือก Architecture Fix

🚫 อย่าให้ Gemini เปลี่ยน Library เพื่อแก้ Bug โดยไม่จำเป็น

บางครั้ง AI อาจเสนอ

เปลี่ยน Framework
Upgrade Package
เพิ่ม Library
Rewrite Module

ทั้งที่ Bug แก้ได้ไม่กี่บรรทัด

ก่อนยอมรับ ให้ถาม

“Bug นี้แก้ได้โดยไม่เพิ่มหรือเปลี่ยน Dependency หรือไม่”

ถ้า Package Version เป็นต้นเหตุจริง ค่อยพิจารณา Upgrade

🔢 Version สำคัญมาก

Syntax และ API สามารถต่างกันตาม Version

ควรส่งข้อมูล เช่น

Python 3.13
Node.js 24
PHP 8.x
Framework Version
Package Version

แทนการบอกเพียง

“ใช้ Python”

โดยเฉพาะ Bug จาก Library ควรระบุ Exact Version จาก

package.json
requirements.txt
pyproject.toml
composer.json
Lock File

ตามระบบที่ใช้

🧹 ใช้ Gemini ตรวจ Bug จาก Diff ได้ไหม

ถ้า Bug เพิ่งเกิดหลังแก้ Code สามารถส่ง Diff ให้ดู

Prompt

“Feature นี้ทำงานก่อนการเปลี่ยนแปลง แต่พังหลัง Diff นี้ ช่วยตรวจเฉพาะการเปลี่ยนแปลงที่อาจทำให้เกิด Regression”

เหมาะมากเมื่อ Scope ของปัญหาเล็ก

ยิ่ง Diff เล็ก การหา Bug ยิ่งง่าย

📋 Debug Checklist ที่ควรให้ Gemini ตรวจ

ก่อนสรุป Root Cause สามารถให้ตรวจ Checklist

Input

ข้อมูลเข้าถูกหรือไม่

Validation

ตรวจข้อมูลครบหรือไม่

State

ค่าปัจจุบันถูกหรือไม่

Type

Data Type ตรงหรือไม่

Null / Undefined

มีค่าหายหรือไม่

Async

รอ Promise ครบหรือไม่

Database

Query ถูกหรือไม่

API

Request/Response ตรง Contract หรือไม่

Permission

มีสิทธิ์หรือไม่

Environment

Config ต่างกันหรือไม่

Dependency

Version ตรงหรือไม่

Checklist นี้ช่วยให้ไม่โฟกัสสาเหตุเดียวเร็วเกินไป

⚠️ Code ที่ Gemini เสนออาจสร้าง Bug ใหม่ได้

แม้ Patch ดูถูกต้อง แต่สามารถสร้าง Regression เช่น

เปลี่ยน Behavior
ปิด Error โดยไม่แก้ต้นเหตุ
ทำ Validation หลวม
ทำ Performance แย่ลง
ทำ Security ลดลง
ทำ Test อื่น Fail

ทุก Patch ควรผ่าน

Unit Test
Integration Test
Regression Test
Code Review

ก่อน Deploy

Google เองแนะนำให้ตรวจสอบและทดสอบ Code ที่ Generative AI สร้างขึ้นก่อนนำไปพึ่งพาหรือใช้งานจริง

🚫 10 ข้อผิดพลาดเวลาใช้ Gemini Debug Code

❶ บอกเพียง “ไม่ทำงาน”

Context ไม่พอ

❷ ไม่ส่ง Error Message

AI ต้องเดามากขึ้น

❸ ตัด Stack Trace

ข้อมูลสำคัญหาย

❹ ไม่บอก Expected Result

AI ไม่รู้ว่าพฤติกรรมถูกต้องคืออะไร

❺ ไม่บอก Version

อาจวิเคราะห์ API ผิด Version

❻ ให้ Rewrite ทั้ง File

เพิ่ม Regression Risk

❼ แก้หลายจุดพร้อมกัน

ไม่รู้ว่าอะไรแก้ Bug จริง

❽ ไม่สร้าง Test

Bug อาจกลับมา

❾ ไม่ Review Security

Patch อาจเพิ่มช่องโหว่

❿ Deploy ทันที

ยังไม่ผ่าน Regression Test

🔐 ระวัง Secret เวลาเอา Code ไป Debug

ก่อนส่ง Code, Log หรือ Configuration ให้ Gemini ควรตรวจหา

API Key
Password
Access Token
Private Key
Database Credential
Session Token
Cookie
Customer Data

ตัวอย่างไม่ควรส่ง

DATABASE_PASSWORD=my-real-password

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

DATABASE_PASSWORD=YOUR_PASSWORD

หาก Secret รั่วไปแล้ว ควร Rotate หรือ Revoke Secret ตามระบบนั้น ไม่ใช่เพียงลบออกจาก Prompt หรือ Source Code

สำหรับงานของ comsiam แนวทางที่ควรใช้คือสร้างชุด Debug Context ที่มีเฉพาะ Code, Error และ Log ที่จำเป็น และลบข้อมูลลับก่อนทุกครั้ง

💡 10 Prompt ตรวจหา Bug ด้วย Gemini

❶ หา Root Cause

“วิเคราะห์ Root Cause จาก Error และ Code นี้ก่อน โดยยังไม่ต้องแก้”

❷ Trace Stack

“อธิบาย Stack Trace จากต้นเหตุไปจนถึงจุดที่ Error ถูกแสดง”

❸ หา Logic Bug

“ตรวจ Code เทียบกับ Expected Behavior และหา Logic ที่ไม่ตรง Requirement”

❹ สร้าง Hypothesis

“สร้าง 5 Root Cause ที่เป็นไปได้ พร้อมวิธีทดสอบทีละข้อ”

❺ Reproduce

“สร้างขั้นตอน Reproduce Bug ที่สั้นที่สุด”

❻ Trace ข้ามไฟล์

“Trace Flow ตั้งแต่ Entry Point จนถึง Function ที่มีปัญหา”

❼ Minimal Patch

“สร้าง Patch ที่เปลี่ยน Code น้อยที่สุดหลังจากยืนยัน Root Cause แล้ว”

❽ Regression Test

“สร้าง Test ที่ Fail ก่อนแก้และ Pass หลังแก้ Bug”

❾ ตรวจผลกระทบ

“Patch นี้อาจกระทบ Feature หรือ Module ใดบ้าง”

❿ Review หลังแก้

“ตรวจ Code หลังแก้อีกครั้งว่ามี Regression, Security Issue หรือ Edge Case ใหม่หรือไม่”

❓ คำถามที่พบบ่อย

Gemini หา Bug ใน Code ได้ไหม

ได้ Gemini สามารถช่วยอ่าน Source Code, Error Message และ Stack Trace เพื่อวิเคราะห์ Bug และเสนอแนวทาง Debug ได้

Gemini Debug Code หลายไฟล์ได้ไหม

ได้ สามารถ Import Code Folder หรือ GitHub Repository เพื่อให้ Gemini ใช้ Context จากหลายไฟล์ในการวิเคราะห์ปัญหาได้

ต้องส่ง Error Message ให้ Gemini ไหม

ควรส่ง เพราะ Error Message และ Stack Trace ช่วยลด Scope และชี้ไปยังไฟล์ Function หรือบรรทัดที่เกี่ยวข้องได้มาก

Gemini แก้ Bug ให้เลยได้ไหม

สามารถเสนอ Patch ได้ แต่ควรหา Root Cause และสร้างวิธี Reproduce ก่อน จากนั้นต้อง Review และ Test Patch ก่อนใช้งานจริง

Gemini ตรวจ Logic Bug ได้ไหม

ได้ หากให้ Requirement, Expected Behavior และ Actual Behavior ที่ชัดเจน เพราะ Logic Bug มักไม่มี Error Message

Gemini Debug ถูกต้อง 100% หรือไม่

ไม่ควรถือว่าถูกต้อง 100% AI สามารถเข้าใจ Logic หรือ Environment ผิดได้ ต้องยืนยัน Root Cause ด้วย Test, Log และ Runtime จริง

🎯 สรุป

วิธีใช้ Gemini ตรวจหา Bug ในโค้ดให้ได้ผลดีที่สุดคือให้ข้อมูลครบและ Debug อย่างเป็นขั้นตอน เริ่มจาก Reproduce → Error → Stack Trace → Scope → Root Cause → Hypothesis Test → Minimal Patch → Regression Test

อย่าเริ่มต้นด้วยการให้ Gemini Rewrite Code ทั้ง File เพราะอาจทำให้ต้นเหตุจริงถูกซ่อนและสร้าง Bug ใหม่ ควรให้ AI อธิบายหลักฐานที่สนับสนุน Root Cause และบอกวิธีทดสอบแต่ละสมมติฐานก่อน

สำหรับ Codebase หลายไฟล์ สามารถใช้ Code Folder หรือ GitHub Repository เพื่อช่วย Trace Flow ข้าม Module ได้ และเมื่อ Gemini เสนอ Patch แล้วต้องผ่าน Test และ Code Review ก่อน Deploy เสมอ

แนวทางของ comsiam คือใช้ Gemini เป็นผู้ช่วยตั้งสมมติฐานและลดพื้นที่ค้นหา Bug ส่วนการยืนยันว่า Bug อยู่ตรงไหนและ Patch ถูกต้องหรือไม่ยังต้องอาศัย Runtime, Test และการตรวจสอบจาก Developer