วิธีแก้ Error และ Debug โค้ดใน Gemini Canvas แบบละเอียด

Gemini Canvas สามารถช่วยแก้ Error และ Debug โค้ดได้โดยไม่จำเป็นต้องเดาสาเหตุจากหน้าจอที่ “ใช้งานไม่ได้” เพียงอย่างเดียว เพราะ Canvas มีเครื่องมือสำหรับตรวจ

• Source Code
• Preview
• Errors
• Logs
• Recent Changes

โดยตรง

Workflow ที่ควรใช้คือ

เจอ Error → เปิด Show console → อ่าน Error → หา Root Cause → เปิด Code → แก้เฉพาะจุด → Preview → Test → ตรวจ Recent Changes

ไม่ควรใช้วิธี

เจอ Error → สั่ง Gemini เขียนแอปใหม่ทั้งหมด

ทันที

เพราะการ Rewrite Code จำนวนมากอาจแก้ Bug เดิมได้ แต่สร้าง Bug ใหม่ใน Feature ที่เคยใช้งานได้

Google ระบุว่า Canvas สามารถ

• แก้ Code โดยตรง
• ใช้ Prompt ให้ Gemini แก้ App
• เปิด Show console ดู Error และ Log
• เปิด Show recent changes ดู Code ที่เพิ่งถูกเปลี่ยน
• ใช้ Select & ask แก้เฉพาะส่วน

ได้

บทความนี้จะสอน วิธีแก้ Error และ Debug โค้ดใน Gemini Canvas แบบละเอียด ตั้งแต่หา Error ครั้งแรก วิเคราะห์ Root Cause แก้เฉพาะ Function ไปจนถึงทำ Regression Test ก่อนนำ Code ไปใช้งานจริง

🐞 Debug คืออะไร

Debug คือกระบวนการ

ค้นหา → วิเคราะห์ → แก้ไข → ทดสอบ

ข้อผิดพลาดในโปรแกรม

Bug สามารถเกิดได้หลายแบบ เช่น

• Syntax Error
• Runtime Error
• Logic Error
• UI Error
• State Error
• Network Error
• Data Error
• Integration Error

ตัวอย่าง:

กดปุ่ม Calculate แล้วไม่มีอะไรเกิดขึ้น

ปัญหาอาจมาจาก

• Event Listener ไม่ทำงาน
• Function Name ผิด
• Variable เป็น undefined
• Input ไม่ถูกอ่าน
• JavaScript Error ก่อนถึง Function

ดังนั้นสิ่งแรกที่ควรทำไม่ใช่ Rewrite App แต่คือ หา Error ให้เจอ

① ▶️ เริ่มจากทดลอง Bug ใน Preview

ก่อน Debug ต้องทำให้เกิดปัญหาได้ก่อน

ตัวอย่าง:

App มีปัญหาว่า

“กด Add Task แล้วรายการไม่เพิ่ม”

ให้ทดลองใน Preview ตามขั้นตอนเดิม

① เปิด App
② กรอก Task
③ กด Add
④ ดูว่าเกิดอะไรขึ้น

พยายามตอบให้ได้ว่า

• เกิดทุกครั้งหรือบางครั้ง
• Input แบบไหนทำให้เกิด
• บนมือถือเกิดไหม
• หลังทำ Action ไหนจึงเกิด

ยิ่ง Reproduce Bug ได้ชัด การ Debug ยิ่งง่าย

② 🔍 เขียน Steps to Reproduce

ก่อนสั่ง Gemini แก้ ควรบอกขั้นตอนให้ชัด

ตัวอย่าง:

“Bug เกิดตามขั้นตอนนี้

1. เปิด App
2. กรอก Task
3. เลือก Priority High
4. กด Add
5. ไม่มี Task เพิ่มในรายการ”

ดีกว่าบอกว่า

“แอปเสีย”

เพราะ Gemini จะรู้ว่าควรตรวจ Flow ไหน

③ 🖥️ เปิด Show console

Google ระบุว่าสามารถดู Error และ Log จาก Preview ได้โดยเลือก

Show console

ใน Canvas

นี่ควรเป็นหนึ่งในเครื่องมือแรกที่เปิดเมื่อ

• ปุ่มไม่ทำงาน
• App ไม่ Render
• หน้าขาว
• Feature หาย
• Data ไม่ขึ้น
• JavaScript Error

Console อาจแสดงข้อมูล เช่น

ReferenceError: total is not defined

หรือ

TypeError: Cannot read properties of undefined

Error เหล่านี้ช่วยระบุสาเหตุได้มากกว่าการมองหน้า Preview อย่างเดียว

④ 🔎 อ่าน Error Message ก่อนแก้

Error Message ไม่ใช่ข้อความที่ต้องรีบลบ

มันเป็นเบาะแส

ควรดู

• Error Type
• Function
• Variable
• File
• Line
• Stack

ตัวอย่าง:

ReferenceError: calculateTotal is not defined

แปลโดยทั่วไปว่า Code พยายามเรียกชื่อ calculateTotal แต่ใน Context นั้นไม่มี Definition ที่สามารถใช้งานได้

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

• Function ไม่ถูกสร้าง
• สะกดชื่อผิด
• Scope ผิด
• Code ไม่ถูกโหลด

ต้องตรวจต่อ ไม่ควรเดาว่า Function เสียทันที

⑤ 🧠 ให้ Gemini วิเคราะห์ Error ก่อนแก้

Prompt ที่ดีคือ

“วิเคราะห์ Error นี้ก่อน อย่าแก้ Code ทันที

ระบุ

1. Error หมายถึงอะไร
2. Root Cause ที่เป็นไปได้
3. Code ส่วนไหนควรตรวจ
4. วิธีทดสอบเพื่อยืนยัน Root Cause”

จากนั้นดูคำอธิบายก่อน

วิธีนี้ช่วยป้องกัน Gemini เปลี่ยน Code จำนวนมากเกินความจำเป็น

⑥ 🎯 Root Cause คืออะไร

Root Cause คือ สาเหตุจริงของปัญหา

ไม่ใช่อาการที่เห็น

ตัวอย่าง:

อาการ

กดปุ่มแล้วไม่มีผล

สาเหตุที่แท้จริง

JavaScript Error เกิดก่อน Event Handler ถูก Register

ถ้าเราแก้เฉพาะ Button CSS หรือสร้างปุ่มใหม่ Bug ก็ยังอยู่

Debug ที่ดีจึงต้องถามว่า

อะไรทำให้ปัญหานี้เกิดขึ้นจริง

ไม่ใช่แค่

ตรงไหนดูเสีย

⑦ 👨‍💻 เปิด Code View

หลังได้ Error แล้วให้เปิด

Code

Google ระบุว่าสามารถเปิดและแก้ Code โดยตรงใน Canvas ได้

จากนั้นหา

• Function ที่ Error
• Variable
• Component
• Event Handler
• Import
• State

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

อย่าเริ่มอ่านทั้ง Codebase หาก Error ชี้ Function มาแล้ว

เริ่มจากบริเวณที่เกี่ยวข้องก่อน

⑧ ✏️ แก้เฉพาะจุด

ถ้า Bug อยู่ใน Function เดียว ให้แก้เฉพาะ Function นั้น

ตัวอย่าง Prompt:

“แก้เฉพาะ function calculateTotal()

ปัญหาคือ variable discount เป็น undefined เมื่อไม่ได้เลือก Coupon

ให้ตั้ง Default ที่เหมาะสม

อย่าแก้ UI, CSS หรือ Function อื่น”

นี่เป็นวิธี Debug ที่ปลอดภัยกว่าการสั่ง

“แก้โค้ดทั้งหมด”

⑨ 🚫 อย่า Rewrite ทั้ง App เมื่อ Error เล็ก

สมมติ App มี Feature:

• Login
• Search
• Filter
• Dashboard
• Export

แต่ Bug อยู่ที่ Search

ถ้าสั่งให้ Gemini Rewrite App ทั้งหมด Feature อื่นสามารถเปลี่ยนตามได้

ผลที่เกิดขึ้นอาจเป็น

Bug เดิมหาย + Bug ใหม่ 3 จุด

ดังนั้นใช้หลัก

Smallest safe change

คือแก้ให้น้อยที่สุดเท่าที่จำเป็น

⑩ 🕘 ใช้ Show recent changes

Google ระบุว่าสามารถเลือก

Code → Show recent changes

เพื่อดูการแก้ Code ล่าสุด

Feature นี้มีประโยชน์มากเมื่อ Bug เพิ่งเกิดหลังการแก้ไข

ตัวอย่าง:

ก่อนหน้า

Login ใช้งานได้

สิ่งที่เพิ่งทำ

เพิ่ม Dark Mode

หลังจากนั้น

Login ใช้งานไม่ได้

ให้เปิด Recent Changes แล้วตรวจว่า Code ที่เกี่ยวกับ

• State
• Component
• Event
• Import

ถูกเปลี่ยนหรือไม่

นี่ช่วยหา Regression ได้เร็วขึ้น

⑪ 🔄 Regression Bug คืออะไร

Regression คือ Bug ที่เกิดเมื่อ Feature ที่เคยใช้งานได้ถูกทำให้เสียหลังการเปลี่ยนแปลงอื่น

ตัวอย่าง:

เพิ่ม Search แล้ว Filter พัง

หรือ

เปลี่ยน CSS แล้ว Modal เปิดไม่ได้

หรือ

เพิ่ม Gemini AI แล้ว Submit Form ไม่ทำงาน

เมื่อเจอ Regression ให้ถามก่อนว่า

Bug เริ่มเกิดหลัง Change ไหน

จากนั้นดู Recent Changes

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

ก่อนให้ Geminiเปลี่ยน Code ควรรู้ Behavior เดิม

ตัวอย่าง:

ก่อนแก้

• Add ทำงาน
• Delete ทำงาน
• Search พัง

หลังแก้

ต้องเป็น

• Add ทำงาน
• Delete ทำงาน
• Search ทำงาน

ไม่ใช่ตรวจเฉพาะ Search แล้วจบ

นี่เรียกว่า Regression Testing

⑬ 🧪 Test Bug เดิมหลังแก้

หลังแก้ Code ให้ทำ Steps to Reproduce เดิมอีกครั้ง

ถ้า Bug เดิมคือ

① ใส่ Task
② เลือก High
③ Add
④ Task ไม่ขึ้น

หลังแก้ต้องทดลองลำดับเดียวกัน

อย่าเปลี่ยน Test Case แล้วสรุปว่า Bug หาย

⑭ 🧪 Test Feature รอบข้างด้วย

ถ้าแก้ Add Task ควรลอง

• Edit
• Delete
• Filter
• Search

ด้วย

เพราะ Function เหล่านี้อาจใช้ State หรือ Data Structure เดียวกัน

Bug อาจหาย แต่สร้างผลกระทบต่อ Feature ใกล้เคียง

⑮ 📝 Debug ด้วย Prompt อย่างไรให้ดี

Prompt ควรมี

Problem

เกิดอะไรขึ้น

Reproduction

ทำอย่างไรจึงเกิด

Expected

ควรเกิดอะไร

Actual

ตอนนี้เกิดอะไร

Constraint

ห้ามเปลี่ยนอะไร

ตัวอย่าง:

“Problem: ปุ่ม Submit ไม่ทำงาน

Steps:

1. กรอก Name
2. กรอก Email
3. กด Submit

Expected:
แสดง Success Message

Actual:
ไม่มี Response

Constraint:
ห้ามเปลี่ยน Layout หรือ CSS

ตรวจ Console และ Root Cause ก่อนแก้”

นี่เป็น Debug Prompt ที่ชัดมาก

⑯ 🐞 Syntax Error คืออะไร

Syntax Error คือ Code เขียนไม่ถูกตามไวยากรณ์ของภาษา

เช่น

• ปิดวงเล็บไม่ครบ
• Quote ไม่ครบ
• Comma ผิด
• Keyword ผิด

ตัวอย่าง JavaScript:

function test( {
  console.log("hello");
}

Code ลักษณะนี้มี Syntax ผิด

Gemini สามารถช่วยตรวจได้ แต่ควรดู Error ที่ Parser หรือ Console แสดงด้วย

⑰ ⚡ Runtime Error คืออะไร

Runtime Error คือ Code ผ่านขั้นตอน Syntax แล้ว แต่เกิด Error ตอนโปรแกรมทำงาน

ตัวอย่าง:

user.name

แต่ user เป็น undefined

จะเกิด Error ตอน Runtime

วิธีแก้ไม่ใช่เพียงเติม Syntax

ต้องตรวจว่า

ทำไม user ถึงไม่มีค่า

⑱ 🧠 Logic Error คืออะไร

Logic Error อันตรายกว่าบาง Error เพราะ App อาจไม่ Crash

แต่ผลลัพธ์ผิด

ตัวอย่าง:

total = price - tax;

ทั้งที่ต้องเป็น

total = price + tax;

Console อาจไม่แสดง Error เพราะ Code ทำงานถูกตาม Syntax

แต่ Business Logic ผิด

จึงต้องใช้ Test Case ตรวจผลลัพธ์

⑲ 🎨 UI Bug คืออะไร

UI Bug เช่น

• Button ซ้อนกัน
• Text ล้น
• Menu เปิดไม่ได้
• Modal อยู่หลัง Element อื่น
• Mobile Layout แตก

Console อาจไม่มี Error เสมอไป

ต้องดู Preview และตรวจ

• CSS
• Layout
• Z-index
• Responsive
• Event

ร่วมกัน

⑳ 📱 Debug Responsive Error

ตัวอย่าง Desktop ปกติ แต่มือถือมี Horizontal Scroll

Prompt:

“ตรวจเฉพาะ Responsive Bug

ที่ viewport 375px มี Horizontal Overflow

หา Element ที่กว้างเกิน Container

แก้เฉพาะ Mobile Layout และรักษา Desktop Layout เดิม”

เจาะจงกว่าคำสั่ง

“ทำเว็บ Responsive”

㉑ 🖱️ ปุ่มกดไม่ได้ Debug อย่างไร

ตรวจตามลำดับ

① ปุ่ม Render หรือไม่
② Button ถูก Disabled หรือไม่
③ Event Handler ถูกผูกหรือไม่
④ Console มี Error หรือไม่
⑤ Element อื่นซ้อนทับหรือไม่
⑥ Function ถูกเรียกหรือไม่

สามารถเพิ่ม Log ชั่วคราว เช่น

console.log("button clicked");

เพื่อดูว่า Event ถูกเรียกหรือไม่

จากนั้นลบ Log ที่ไม่จำเป็นออกหลังแก้เสร็จ

㉒ 📥 Form Submit ไม่ทำงาน

ตรวจ

• Required Field
• Event
• preventDefault
• Validation
• Network Request
• Error Handling

Prompt:

“Debug Form Submit

ตรวจตั้งแต่ Event Handler → Validation → Request → Response

อย่าเปลี่ยน Form UI”

วิธีนี้ช่วย Debug เป็น Pipeline

㉓ 🔢 Calculation Error

หาก Calculator แสดงตัวเลขผิด ต้องแยกจาก JavaScript Error

ตัวอย่าง BMI ผิด

ให้ตรวจ

• Formula
• Unit Conversion
• Parsing
• Decimal
• Rounding

Prompt:

“ตรวจ Calculation Logic โดยใช้ Test Case นี้

น้ำหนัก 70 kg
ส่วนสูง 170 cm

คำนวณ Expected Result แยกก่อน แล้วเปรียบเทียบกับ Function ปัจจุบัน”

ช่วยพิสูจน์ว่า Error อยู่ที่ Formula หรือ Input Handling

㉔ 🔄 State Error

Web App สมัยใหม่มักมี State

ปัญหา เช่น

• UI ไม่ Update
• ข้อมูลเก่ายังค้าง
• Filter เปลี่ยนแต่รายการไม่เปลี่ยน

อาจเป็น State Management

ควรตรวจ

• State Update
• Mutation
• Dependency
• Re-render
• Async Timing

อย่าแก้ UI ก่อนถ้า State ไม่เปลี่ยน

㉕ ⏳ Async Error

ปัญหา Async มักเกิดกับ

• Fetch
• AI Request
• API
• Timer

เช่น User กด Generate 2 ครั้ง แล้ว Response รอบแรกกลับมาทีหลังและเขียนทับ Response รอบสอง

ต้องตรวจ

• Loading State
• Race Condition
• Cancellation
• Request ID

โดยเฉพาะ AI App

㉖ 🌐 Network Error

หาก App เรียก API ให้ดูว่า Error มาจาก Network หรือ Code

เช่น

• 400
• 401
• 403
• 404
• 429
• 500

ตัวเลขแต่ละประเภทบอกปัญหาไม่เหมือนกัน

เช่น

401 มักเกี่ยวกับ Authentication

429 มักเกี่ยวกับ Rate Limit

ไม่ควรแก้ Front-end UI เพื่อพยายามแก้ HTTP Error โดยไม่ดู Response

㉗ 🔐 Permission Error

ถ้า Feature ต้องใช้สิทธิ์ เช่น

• Camera
• Location
• File

Bug อาจไม่ได้เกิดจาก Code Logic โดยตรง

ต้องตรวจ

• Permission
• Browser
• User Denial
• Device Support

และมี Error Message ให้ผู้ใช้เข้าใจ

㉘ 📦 Import หรือ Dependency Error

ตัวอย่าง:

Module not found

ต้องตรวจ

• Package Name
• Import Path
• Dependency
• Version
• Environment

อย่าเปลี่ยน Code Business Logic ก่อน

เพราะปัญหาอาจเกิดจาก Module ไม่ถูกโหลดตั้งแต่แรก

㉙ 🧩 Component ไม่ Render

ถ้า Component หาย ตรวจ

• Conditional Rendering
• Props
• Import
• State
• Return

ตัวอย่าง:

{isLoggedIn && <Dashboard />}

ถ้า isLoggedIn เป็น false Dashboard จะไม่ Render และไม่ใช่ UI Bug

จึงต้องตรวจ State ก่อน

㉚ 📊 Data ไม่แสดง

ตรวจ Flow:

Data Source → Fetch → Parse → State → Render

หาว่าข้อมูลหายตรงไหน

สามารถใส่ Log ชั่วคราวแต่ละขั้น

เช่น

console.log("API response", data);

ถ้า API มี Data แต่ UI ไม่มี ปัญหาอยู่ช่วง Render หรือ State

㉛ 🗄️ Local Storage Bug

ถ้า App บันทึกข้อมูลใน Browser แล้วข้อมูลหายหลัง Reload ให้ตรวจ

• setItem
• getItem
• JSON.stringify
• JSON.parse
• Key Name
• Initialization

และ Test

① เพิ่มข้อมูล
② Reload
③ ตรวจว่ากลับมาหรือไม่

อย่าสรุปว่า Auto-save ของ Canvas เท่ากับ App Data Persistence

เป็นคนละเรื่องกัน

㉜ 🐞 JSON Parse Error

ตัวอย่าง:

Unexpected token

อาจเกิดเพราะข้อมูลไม่ใช่ JSON ที่ถูกต้อง

ถ้าเป็น AI-generated JSON ยิ่งควร Validate

อย่า assume ว่า AI จะคืน JSON ถูก Format ทุกครั้ง

ควรมี

• Try/Catch
• Schema Validation
• Fallback

ตามความเหมาะสม

㉝ 🤖 AI Feature Error

ถ้า App ใช้ Gemini AI แล้วไม่ตอบ ให้ตรวจ

① User Input
② Prompt Construction
③ Request
④ Loading
⑤ Response
⑥ Parsing
⑦ Render
⑧ Error State

ไม่ควรโทษ Model ทันที

บางครั้ง AI ตอบแล้ว แต่ Code Parse Output ผิด

㉞ 🧠 Hallucination ไม่ใช่ Code Error

ถ้า Gemini-powered App ทำงานทางเทคนิคสมบูรณ์ แต่สร้างข้อมูลผิด

นี่ไม่ใช่ Bug ของ JavaScript โดยตรง

แต่เป็น AI Quality Issue

ต้องแก้ด้วย

• Prompt
• Context
• Source
• Output Validation
• Human Review

Debug AI App ต้องแยกระหว่าง

Software Error

กับ

Model Output Error

㉟ 🎯 ใช้ Select & ask Debug เฉพาะ Component

Google รองรับ Select & ask สำหรับ App

ถ้าปัญหาอยู่ใน Pricing Component

เลือกเฉพาะ Component แล้วสั่ง

“ตรวจว่าทำไมปุ่มนี้ไม่อัปเดต State”

ช่วย Scope งานให้เล็กลง

ดีกว่าให้ Gemini วิเคราะห์ App ทั้งตัวทุกครั้ง

㊱ 📝 ให้ Gemini เพิ่ม Log ชั่วคราว

ถ้าไม่รู้ว่าค่าเปลี่ยนตรงไหน สามารถสั่ง

“เพิ่ม Debug Logs ชั่วคราวที่

• User Input
• Function Start
• Calculated Value
• State Update

เพื่อหา Step ที่ค่าผิด”

จากนั้นเมื่อพบปัญหาแล้วให้ลบ Log ที่ไม่จำเป็นออก

㊲ 🧪 ใช้ Test Case เล็กที่สุด

ถ้า Function มี Input 10 ตัว แต่ Bug เกิดจากเพียง 2 ตัว

ให้สร้าง Minimal Reproduction

เช่น

แทน Test Form ทั้งระบบ

ทดสอบเฉพาะ

price = 100
discount = undefined

การลดปัญหาให้เล็กช่วยหา Root Cause ได้เร็วขึ้น

㊳ 📌 Fix หนึ่งเรื่องต่อหนึ่งรอบ

ถ้าเจอ

• Search Bug
• CSS Bug
• Login Bug

พร้อมกัน

ไม่ควรสั่ง

“แก้ทุกอย่าง”

ให้แยก

รอบ 1

Search

รอบ 2

Test

รอบ 3

CSS

รอบ 4

Test

รอบ 5

Login

ทำให้รู้ว่า Change ไหนสร้างผลกระทบอะไร

㊴ 🔄 ทดสอบ Regression หลังทุก Fix

หลัง Fix แต่ละครั้ง ให้ Test Feature สำคัญเดิม

ตัวอย่าง Checklist:

• Login
• Add
• Edit
• Delete
• Search
• Filter

ถ้า Project ใหญ่ควรมี Automated Tests เพิ่ม

Canvas ช่วย Debug ได้ แต่ไม่ได้แทน Testing Infrastructure

㊵ ✅ เมื่อไรถือว่า Bug แก้แล้ว

อย่าถือว่า Bug แก้แล้วเพราะ Error หายจาก Console

ควรผ่านอย่างน้อย

① Steps เดิมไม่เกิด Bug
② Expected Output ถูก
③ Feature รอบข้างยังทำงาน
④ Console ไม่มี Critical Error ใหม่
⑤ Edge Case ที่เกี่ยวข้องผ่าน

นี่จึงถือว่า Fix มีความมั่นใจมากขึ้น

㊶ 🔙 ถ้า Gemini แก้แล้วแย่กว่าเดิมทำอย่างไร

ทำ 3 อย่าง

① หยุดเพิ่ม Change ใหม่
② เปิด Recent Changes
③ ระบุ Change ที่ทำให้เกิด Regression

จากนั้นขอ Gemini:

“ย้อนเฉพาะการเปลี่ยนแปลงล่าสุดที่เกี่ยวกับ Search โดยรักษาการแก้ Bug ก่อนหน้านี้ไว้”

อย่าสั่ง

“ย้อนทั้งหมด”

หากมี Change ที่ดีอยู่ด้วย

㊷ 🧹 Refactor หลัง Bug Fix หรือก่อน

ทั่วไปควรทำ

Fix Bug ก่อน → Test → Refactor

เพราะถ้า Refactor พร้อมแก้ Bug เราจะไม่รู้ว่าพฤติกรรมเปลี่ยนเพราะอะไร

เมื่อ Bug หายแล้วค่อยปรับ Code ให้สะอาดขึ้น

แล้ว Test อีกครั้ง

㊸ 🛡️ Bug ด้าน Security ต้องให้ความสำคัญสูง

ตัวอย่าง:

• Login Bypass
• Data Exposure
• Hard-coded Secret
• XSS
• Authorization Bypass

ไม่ควรแก้เพียงให้ Error หาย

ต้องตรวจ Root Cause และผลกระทบ

สำหรับ Production ควรมี Security Review และ Testing เพิ่มเติมนอก Canvas

㊹ 🔑 Error จาก API Key

หาก API ใช้ไม่ได้ อย่ารีบใส่ Key ลง Front-end เพียงเพื่อให้ Preview ทำงาน

Secret ไม่ควรถูกเปิดเผยใน Client Code

ต้องแก้ Architecture ให้เหมาะสม

“ทำงานได้” ไม่ควรแลกกับ Credential Leakage

㊺ ⚡ Performance Bug

บาง App ไม่มี Error แต่

• ช้า
• กระตุก
• Render ซ้ำ
• Browser ค้าง

ให้ตรวจ

• Loop
• Re-render
• Large Data
• Expensive Calculation
• Network Call ซ้ำ

Prompt:

“วิเคราะห์ Performance Bottleneck ก่อน โดยอย่า Optimize Code ที่ไม่มีหลักฐานว่าเป็นปัญหา”

㊻ 📱 Mobile Bug

หากเกิดเฉพาะมือถือ ให้ระบุ

• Viewport
• Device
• Browser
• Orientation

ตัวอย่าง:

“Bug เกิดที่ความกว้าง 375px เมื่อเปิด Menu”

ช่วย Gemini Scope CSS และ Event ได้ดีขึ้น

㊼ 🌐 Browser-specific Bug

หาก Chrome ใช้ได้ แต่ Browser อื่นไม่ได้

อย่าสั่ง Gemini ว่า

“โค้ดเสีย”

ต้องระบุ Browser

อาจเกี่ยวกับ

• API Support
• CSS
• Permission
• Storage
• Compatibility

Production Web App ควร Test Browser ที่ผู้ใช้จริงใช้

㊽ 💾 Canvas Auto-save กับการ Debug

Google ระบุว่า Changes ใน Canvas Auto-save

นี่สะดวกในการทำ Iteration

แต่มีข้อควรระวัง:

ถ้าสั่ง Gemini เปลี่ยน Code หลายรอบติดกันโดยไม่ Test เราอาจมี Change จำนวนมากก่อนรู้ว่า Bug เริ่มตรงไหน

จึงควรใช้ Rhythm:

Change → Test → Change → Test

ไม่ใช่

Change ×10 → Test ครั้งเดียว

㊾ 🧑‍💻 ใช้ Git ร่วมกับ Canvas ดีไหม

หาก Code จะพัฒนาเป็น Project จริง ควรใช้ Version Control เช่น Git หลังนำ Code เข้าสู่ Development Environment

ประโยชน์คือ

• Commit
• Diff
• Branch
• Rollback
• Code Review

Recent Changes ใน Canvas ช่วยดูการเปลี่ยนล่าสุดได้ แต่ไม่ควรถูกมองว่าแทน Version Control เต็มรูปแบบสำหรับ Production Engineering

㊿ 🧪 Automated Test ยังจำเป็นไหม

จำเป็นสำหรับ Project ที่มีความซับซ้อน

Gemini สามารถช่วยสร้าง Test

แต่ควรรัน Test จริงใน Environment ที่เหมาะสม

เช่น

• Unit Test
• Integration Test
• End-to-end Test

ช่วยป้องกัน Bug เดิมกลับมา

51 📝 Prompt Debug ที่แนะนำ

“Debug App นี้ตามขั้นตอนต่อไปนี้

1. อ่าน Error จาก Console
2. Reproduce Bug
3. หา Root Cause
4. ระบุ Code ที่เกี่ยวข้อง
5. อธิบาย Fix ก่อนแก้
6. แก้เฉพาะส่วนที่จำเป็น
7. รักษา Feature อื่น
8. ทดสอบ Bug เดิม
9. ทำ Regression Test
10. รายงาน Recent Changes ที่เกิดขึ้น”

Prompt นี้เหมาะกับ Bug ที่ต้องการให้ Gemini ทำงานเป็นขั้นตอน

52 🐞 Prompt สำหรับ JavaScript Error

“Console มี JavaScript Error นี้

[วาง Error]

อธิบายว่า Error หมายถึงอะไร

หา Variable หรือ Function ที่เกี่ยวข้อง

อย่า Rewrite ทั้ง File

แก้เฉพาะ Root Cause และตรวจว่าไม่มี Error ใหม่หลังแก้”

53 🧮 Prompt Debug Calculation

“ผลคำนวณไม่ถูก

Input:
[ค่า]

Expected:
[ค่าที่ควรได้]

Actual:
[ค่าปัจจุบัน]

ตรวจ

• Formula
• Unit Conversion
• parseInt/parseFloat
• Rounding

อย่าแก้ UI”

54 📱 Prompt Debug Responsive

“หน้าเว็บมี Horizontal Overflow ที่ Mobile Width 375px

ตรวจ Element ที่ทำให้กว้างเกิน Viewport

แก้เฉพาะ Responsive CSS

รักษา Desktop Design”

55 🤖 Prompt Debug Gemini AI Feature

“กด Generate แล้ว AI ไม่มี Output

ตรวจ Flow นี้ทีละขั้น

1. Input
2. Prompt construction
3. AI request
4. Response
5. Parsing
6. State
7. Rendering

เปิด Console หา Error และแก้เฉพาะ Root Cause”

56 🔄 Prompt Regression Test

“หลังแก้ Search Bug ให้ตรวจ Feature ต่อไปนี้อีกครั้ง

• Add
• Edit
• Delete
• Filter
• Search

รายงานเฉพาะ Feature ที่ Behavior เปลี่ยนจากเดิม”

57 🛡️ Prompt Security Bug

“ตรวจ Bug นี้ว่าเกี่ยวกับ Security หรือไม่

อธิบาย Impact

ตรวจ Authentication, Authorization, Input และ Data Exposure

อย่าแก้เพียงให้ Error หาย หาก Root Cause เป็น Security Design ให้ระบุ Architecture ที่ต้องแก้”

⚠️ ข้อผิดพลาดที่พบบ่อยตอน Debug ด้วย Gemini Canvas

❌ ① บอกแค่ว่า “มันไม่ทำงาน”

ไม่มีข้อมูลพอ

❌ ② ไม่เปิด Console

เสียเบาะแสสำคัญ

❌ ③ ให้ Gemini Rewrite ทั้ง App

สร้าง Regression

❌ ④ แก้หลาย Bug พร้อมกัน

หา Root Cause ยาก

❌ ⑤ ไม่ Test Bug เดิม

ไม่รู้ว่า Fix จริงหรือไม่

❌ ⑥ ไม่ดู Recent Changes

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

❌ ⑦ แก้ UI ทั้งที่ Logic ผิด

แก้ผิดชั้น

❌ ⑧ Error หายแล้วคิดว่าจบ

Logic อาจยังผิด

❌ ⑨ ไม่ Test Edge Case

Bug กลับมาเมื่อ User ใช้จริง

❌ ⑩ ใช้ Fix ที่เปิดเผย Secret

แก้หนึ่งปัญหาแต่สร้าง Security Risk

✅ Checklist Debug ใน Gemini Canvas

ก่อนแก้

① Reproduce Bug ได้
② รู้ Steps to Reproduce
③ รู้ Expected Result
④ รู้ Actual Result
⑤ เปิด Console แล้ว

ระหว่างแก้

⑥ อ่าน Error
⑦ หา Root Cause
⑧ เปิด Code
⑨ ตรวจ Recent Changes
⑩ แก้เฉพาะส่วน

หลังแก้

⑪ Test Bug เดิม
⑫ Test Feature รอบข้าง
⑬ Test Edge Case
⑭ Console ไม่มี Error ใหม่
⑮ ตรวจ Recent Changes อีกครั้ง

สำหรับ Production

⑯ Code Review
⑰ Automated Test
⑱ Security Review เมื่อจำเป็น
⑲ Version Control
⑳ Deployment Test

❓ คำถามที่พบบ่อยเกี่ยวกับการ Debug ใน Gemini Canvas

Gemini Canvas แก้ Error ได้ไหม

ได้ สามารถใช้ Gemini ช่วยแก้ App/Code ผ่าน Prompt และสามารถเปิด Code แก้ด้วยตัวเองได้

ดู Error ตรงไหน

บน Desktop เปิด Show console ใน Canvas เพื่อดู Errors และ Logs จาก Preview

ดู Code ตรงไหน

เลือก Code บริเวณด้านขวาบนของ Canvas Panel

Gemini แก้ Code เองได้ไหม

ได้ สามารถพิมพ์ Prompt ให้ Gemini อัปเดต App หรือเข้า Code View แล้วแก้ Code ด้วยตัวเอง

ดูว่า Gemini เพิ่งแก้อะไรได้ไหม

ได้ ใช้ Code → Show recent changes

แก้เฉพาะส่วนได้ไหม

ได้ ใช้ Select & ask เพื่อเลือก Section ของ App ที่ต้องการแก้

Canvas บันทึก Code อัตโนมัติไหม

ได้ Google ระบุว่า Changes ใน Canvas Auto-save

Console ใช้ทำอะไร

ใช้ดู Error และ Log จาก Preview เพื่อช่วยหา Root Cause ของปัญหา

Error หายแล้วถือว่า Bug หายไหม

ไม่เสมอ ต้อง Test Expected Behavior และ Regression ด้วย

Gemini Debug Logic Error ได้ไหม

ช่วยได้ แต่ Logic Error อาจไม่มี Console Error จึงต้องมี Test Case ที่รู้ Expected Result

Gemini แก้ Error แล้วสร้าง Bug ใหม่ได้ไหม

เป็นไปได้ จึงควรแก้เฉพาะจุดและทำ Regression Test หลังทุก Fix

ถ้า Gemini แก้แล้วแย่กว่าเดิมทำอย่างไร

ตรวจ Show recent changes หา Change ล่าสุด แล้วแก้หรือย้อนเฉพาะส่วนที่ทำให้เกิด Regression

Debug บนมือถือได้ไหม

Google ระบุว่า Gemini Canvas บน Android รองรับ Preview และ Show console สำหรับ App ในระบบที่รองรับ

Canvas แทน Debugger ใน IDE ได้ไหม

Canvas มี Preview, Console, Code และ Recent Changes ที่ช่วย Debug Prototype ได้ดี แต่ IDE เต็มรูปแบบยังมี Debugger, Breakpoint, Terminal, Test Runner และเครื่องมือ Development อื่นที่ละเอียดกว่า

Code ที่ Debug เสร็จใน Canvas ใช้ Production ได้ทันทีไหม

ไม่ควรถือว่าพร้อม Production โดยอัตโนมัติ ควรมี Code Review, Testing และ Security Review ตามความเสี่ยงของระบบ

✅ สรุปวิธีแก้ Error และ Debug โค้ดใน Gemini Canvas

วิธี Debug ที่ถูกต้องใน Gemini Canvas ไม่ใช่การเห็นว่า App ใช้ไม่ได้แล้วสั่งว่า

“แก้ทั้งหมดให้หน่อย”

แต่ควรทำตาม Workflow

① Reproduce → ② Show console → ③ อ่าน Error → ④ หา Root Cause → ⑤ Code View → ⑥ แก้เฉพาะจุด → ⑦ Preview → ⑧ Test → ⑨ Show recent changes → ⑩ Regression Test

Google มีเครื่องมือที่ช่วยกระบวนการนี้โดยตรง ได้แก่

• Code สำหรับดูและแก้ Source Code
• Show console สำหรับ Error และ Logs
• Show recent changes สำหรับดู Code ที่เพิ่งเปลี่ยน
• Select & ask สำหรับให้ Gemini ช่วยแก้เฉพาะ Section

หลักสำคัญที่สุดของการ Debug คือ

แก้ Root Cause ไม่ใช่แก้อาการ

หากปุ่มไม่ทำงาน ต้องรู้ก่อนว่าเป็น

• Event
• State
• Function
• JavaScript Error
• Element Overlay

แบบไหน

หาก Calculation ผิด ต้องตรวจ Formula ไม่ใช่ Design

หาก AI สร้างข้อมูลผิด ต้องแก้ Prompt และ Context ไม่ใช่ JavaScript อย่างเดียว

และหลัง Fix ต้องทำ Regression Test เพื่อให้แน่ใจว่า Feature เดิมยังทำงาน

สูตรที่ควรจำคือ

Observe → Reproduce → Diagnose → Fix → Verify

ไม่ใช่

Guess → Rewrite → Hope

สำหรับ Prototype ขนาดเล็ก Canvas สามารถทำให้ Debug ได้รวดเร็วมาก

แต่ถ้า Code จะนำไป Production ควรเพิ่ม

• Automated Tests
• Version Control
• Code Review
• Security Review
• Deployment Testing

ตามความเหมาะสม

เมื่อใช้ Gemini Canvas เป็นผู้ช่วย Debug ในลักษณะนี้ AI จะช่วยลดเวลาในการหาและแก้ปัญหาได้มาก โดยผู้พัฒนายังคงเป็นคนตรวจ Root Cause ผลกระทบ และความถูกต้องของ Code ก่อนนำระบบไปใช้งานจริง