Debug แบบคนไม่ใช่ programmer | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand$ cat 09-debugging-for-noncoders.md บทที่ 9Debug แบบคนไม่ใช่ programmer
แก่นของบทนี้
Debug เริ่มจาก evidence ไม่ใช่การเดา
ก่อนให้ Claude แก้ bug ให้เก็บ expected, actual, steps, log, recent changes และ environment ก่อน
เวลาใช้ Claude Code สร้างเว็บหรือแอป คุณจะเจอ error แน่นอน
Error ไม่ได้แปลว่าคุณล้มเหลว
Error คือข้อมูล
ปัญหาของ non-coder ไม่ใช่ “อ่าน error ไม่ออก” อย่างเดียว
แต่คือไม่รู้ว่าจะเก็บข้อมูลอะไรให้ AI ช่วยแก้ได้แม่น
บทนี้จะสอน workflow ง่าย ๆ:
หยุด → เก็บหลักฐาน → อธิบาย expected behavior → ให้ Claude วิเคราะห์ก่อนแก้ → แก้ทีละจุด → test ซ้ำ
ถ้าคุณทำตามนี้ คุณไม่ต้องอ่าน code เก่ง ก็ debug ได้เป็นระบบขึ้นมาก
ถ้าเจอปัญหาจริงระหว่างทำ project ให้เปิด Appendix F — Debug Evidence Playbook คู่กับบทนี้ เพราะ appendix นั้นช่วยเก็บหลักฐานเป็นชุดก่อนส่งให้ Claude แก้
อย่าเริ่มด้วย “มันพัง แก้หน่อย”
คำสั่งนี้กว้างเกินไป:
Claude อาจต้องเดาว่า:
error message คืออะไร
expected behavior คืออะไร
เพิ่งแก้อะไรไป
รัน command อะไร
พังในเครื่องหรือ production
ยิ่งข้อมูลน้อย AI ยิ่งเดาเยอะ
และเมื่อ AI เดา มันอาจแก้ผิดจุด หรือเปลี่ยนหลายไฟล์โดยไม่จำเป็น
Debug ที่ดีเริ่มจากหลักฐาน ไม่ใช่อารมณ์
Error 5 แบบที่คุณจะเจอบ่อย
1. Install error
เกิดตอนติดตั้ง package หรือ dependency
npm install แล้ว fail
package version conflict
permission denied
2. Build error
เกิดตอน project compile/build ไม่ผ่าน
npm run build แล้ว error
TypeScript error
missing import
3. Runtime error
เว็บเปิดได้ แต่ใช้งานแล้วพัง
กด submit แล้ว error
หน้า blank
console มี error
4. Data/API error
เกี่ยวกับ Supabase, API, env, permission
insert ไม่เข้า database
RLS block
ใช้ env var ไม่เจอ
401/403/500
5. Deploy error
ใช้ได้ในเครื่อง แต่ deploy แล้วพัง
Vercel build fail
production URL เปิดไม่ได้
environment variable ไม่ถูกตั้งค่า
แค่แยก error ได้ว่าอยู่กลุ่มไหน คุณก็ช่วย Claude ได้เยอะแล้ว
Debug report template
เวลาเจอปัญหา ให้ copy template นี้ไปใช้
ฉันเจอปัญหานี้ ช่วยวิเคราะห์ก่อนแก้
## What happened
[เกิดอะไรขึ้น]
## Expected behavior
[ควรเกิดอะไร]
## Steps to reproduce
1. [ขั้นตอนที่ 1]
2. [ขั้นตอนที่ 2]
3. [ขั้นตอนที่ 3]
## Error message / log
[paste error/log เต็ม ๆ]
## Recent changes
[เพิ่งให้ Claude แก้อะไร หรือเพิ่งเปลี่ยนอะไร]
## Environment
- Local or production:
- Command used:
- URL/page:
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อธิบายสาเหตุที่เป็นไปได้ 2–3 แบบก่อน
- บอกว่าจะตรวจอะไรเพื่อยืนยัน
- เสนอวิธีแก้ที่เปลี่ยนน้อยที่สุด
มันเปลี่ยนคุณจาก “คนบอกว่าแอปพัง” เป็น “คนให้ข้อมูล debug”
Evidence pack ขั้นต่ำก่อนให้ Claude แก้:
1. ทำอะไรอยู่
2. คาดหวังว่าจะเกิดอะไร
3. เกิดอะไรจริง
4. error/log เต็ม ๆ
5. เพิ่งเปลี่ยนอะไรล่าสุด
6. local หรือ production
7. screenshot/URL ถ้ามี
ถ้ามีไม่ครบ ให้เก็บให้ครบก่อน ค่อยขอให้ Claude แก้
Copy error ให้ครบ
Browser console และ network เป็นหลักฐานสำคัญเมื่อหน้าเว็บพัง ให้ดู console/network เพื่อเก็บ error, status code และ request ที่เกี่ยวข้องโดยไม่เผย secret
มือใหม่มัก copy error แค่บรรทัดสุดท้าย
แต่หลายครั้งข้อมูลสำคัญอยู่ก่อนหน้านั้น
- command ที่รัน
- error ตั้งแต่เริ่ม fail
- stack trace ถ้ามี
- file path ที่ error ชี้
- line number ถ้ามี
- environment เช่น local หรือ Vercel
ถ้า error ยาวมาก ให้ถาม Claude ว่าควรดูส่วนไหน
error นี้ยาวมาก
ช่วยบอกว่าควรโฟกัสบรรทัดไหน และข้อมูลไหนสำคัญ
อย่าเพิ่งแก้ไฟล์
อย่าตัด error ตามความรู้สึกถ้าคุณยังไม่รู้ว่าอะไรสำคัญ
ให้ Claude อธิบายก่อนแก้
เวลาเจอ error อย่ารีบให้แก้ทันที
ช่วยอธิบาย error นี้แบบ non-coder ก่อน
มันน่าจะเกิดจากอะไร
มีสาเหตุที่เป็นไปได้กี่แบบ
เราควรตรวจอะไรก่อนแก้
เพราะถ้า Claude เข้าใจผิด คุณจะเห็นก่อนมันแก้ไฟล์
ถ้าคำอธิบายฟังดูไม่เกี่ยวกับสิ่งที่คุณทำ ให้ถามต่อ:
สาเหตุนี้เกี่ยวข้องกับการเปลี่ยนล่าสุดตรงไหน
มีหลักฐานจาก log บรรทัดไหนสนับสนุนไหม
ให้ AI อ้างหลักฐานจาก error ไม่ใช่เดาแบบมั่นใจ
แก้ทีละจุด
เวลา error เกิดขึ้น Claude อาจเสนอแก้หลายอย่างพร้อมกัน
สำหรับ non-coder ให้ระวัง
Debug ที่ดีควรแก้ทีละจุด เพื่อรู้ว่าอะไรเป็นสาเหตุจริง
ช่วยแก้ด้วยวิธีที่เปลี่ยนน้อยที่สุดก่อน
อย่า refactor ใหญ่
อย่าเพิ่ม package ใหม่ถ้าไม่จำเป็น
หลังแก้ ให้บอกว่าเปลี่ยนอะไร และต้อง test อะไร
ถ้า Claude เสนอแก้หลายไฟล์ ให้ถาม:
เราสามารถแก้ทีละขั้นได้ไหม
ขั้นแรกที่เล็กที่สุดและปลอดภัยที่สุดคืออะไร
เป้าหมายของ debug ไม่ใช่ทำ code สวยที่สุด
เป้าหมายคือหา root cause และทำให้ระบบกลับมาใช้ได้อย่างปลอดภัย
ใช้ Git เป็น safety net
ก่อนแก้ bug ใหญ่ ให้เช็กสถานะก่อน
ถ้ามี changes ที่ยังไม่ commit อยู่ ให้รู้ก่อนว่าเป็นของอะไร
ถ้าคุณปล่อยให้ Claude แก้ซ้อนบนงานที่ยังไม่บันทึก คุณอาจแยกไม่ออกว่าอะไรทำให้พัง
ก่อนแก้ bug ให้ถาม Claude:
ช่วยดู git status และสรุปว่าตอนนี้มีไฟล์อะไรเปลี่ยนอยู่
ก่อนเริ่มแก้ bug เราควร commit, stash, หรือแยกงานอย่างไร
อย่าแก้ไฟล์ก่อน
ช่วยอธิบาย diff จากการแก้ bug นี้แบบ non-coder
แยกว่าแก้ root cause ตรงไหน และมีผลข้างเคียงอะไรที่ต้อง test
เมื่อไหร่ควร revert หรือ rollback
บางครั้งการแก้ต่อไม่ใช่ทางที่ดีที่สุด
ถ้าแก้ไปหลายรอบแล้วยิ่งพัง ให้หยุด
- Claude แก้หลายไฟล์แต่ error ยังเหมือนเดิม
- error เปลี่ยนไปเรื่อย ๆ แต่ไม่เข้าใกล้สาเหตุ
- feature เดิมที่เคยใช้ได้เริ่มพัง
- คุณอธิบายไม่ได้แล้วว่า project เปลี่ยนอะไรไปบ้าง
- production พังและมี user จริงเจอปัญหา
ถ้าอยู่ใน local ให้ใช้ Git กลับ checkpoint ก่อนหน้า
ถ้าอยู่ production และ deploy บน Vercel อาจใช้ Instant Rollback เพื่อย้อน production deployment ไปเวอร์ชันก่อนหน้า
แต่ต้องเข้าใจว่า rollback แค่พาผู้ใช้กลับไปใช้ version เก่า
ไม่ได้อธิบายหรือแก้ root cause ให้คุณ
หลัง rollback ยังต้องกลับมาสืบว่า bug เกิดจากอะไร
Local พัง vs Production พัง
Local พังกับ Production พังต้องคิดคนละแบบถ้า production กระทบ user จริง ให้กู้บริการหรือ rollback ก่อน แล้วค่อย debug ลึก
Local พัง
- หยุด
- เก็บ error
- ให้ Claude วิเคราะห์
- แก้ทีละจุด
- test ซ้ำ
ยังไม่ต้อง panic เพราะ user จริงยังไม่กระทบ
Production พัง
- ประเมินว่า user กระทบไหม
- ถ้ากระทบหนัก ให้ rollback ก่อน
- จดเวลาและ deployment ที่พัง
- เก็บ error/log
- แยก branch หรือ local เพื่อแก้
- test ก่อน deploy ใหม่
ถ้า user จริงกำลังเจอปัญหา ให้กู้บริการก่อน แล้วค่อย debug ลึก
Session ยาวเกินไปก็ทำให้มั่วได้
บางครั้งคุณคุยกับ Claude นานมาก แก้ไปแก้มาหลายรอบ จน context เริ่มรก
Claude Code มีคำสั่งอย่าง /clear, /compact, /resume เพื่อจัดการ session
สำหรับ non-coder ให้ใช้หลักง่าย ๆ:
- ถ้า task เดิมยังต่อเนื่อง ใช้ session เดิมได้
- ถ้าแก้ผิดทางหลายรอบ ให้สรุปสิ่งที่เรียนรู้ แล้วเริ่ม session ใหม่
- ถ้ากลับมาทำต่อ ใช้ resume ได้
- ถ้า context รก ให้ขอ summary ก่อน clear
ช่วยสรุปสถานะ debug ตอนนี้ให้ฉันเอาไปเริ่ม session ใหม่
รวม:
1. ปัญหาคืออะไร
2. error/log สำคัญ
3. สิ่งที่ลองแล้ว
4. สิ่งที่ไม่น่าใช่สาเหตุ
5. next step ที่แนะนำ
แล้วค่อยเริ่ม session ใหม่ด้วย summary ที่สะอาดกว่า
Waitlist form submit แล้วไม่เข้า Supabase
แก้ Supabase ให้หน่อย
Waitlist form submit แล้วไม่เห็น row ใหม่ใน Supabase
Expected behavior:
- กรอก name/email/company/main_problem
- กด submit
- เห็น thank you message
- Supabase table waitlist_submissions มี row ใหม่
Actual behavior:
- กด submit แล้วเห็น error message: [ข้อความ]
- Supabase ไม่มี row ใหม่
Steps:
1. เปิด localhost:3000
2. กรอก form ด้วย [email protected]
3. กด submit
4. ดู Supabase table แล้วไม่มี row
Error/log:
[paste browser console/network/server log]
Recent changes:
- เพิ่งต่อ form กับ Supabase
กติกา:
- อย่าเพิ่งแก้ไฟล์
- ช่วยแยกสาเหตุที่เป็นไปได้ เช่น env, key, RLS, table name, validation, network
- บอกว่าควรตรวจอะไรทีละข้อ
Claude จะช่วยแยกปัญหาได้ดีกว่ามาก
Debug deploy fail: ตัวอย่าง workflow
Vercel build log ต้องอ่านบรรทัดที่ fail จริงเวลา deploy fail ให้ส่ง log ที่มี command, error แรก, file path และ line number ไม่ใช่แค่บอกว่า deploy fail
ใช้ได้ใน local แต่ Vercel build fail
Project นี้รันใน local ได้ แต่ Vercel deploy fail
Expected behavior:
- Vercel build ผ่าน
- production URL เปิดได้
Actual behavior:
- Vercel build fail
Vercel build log:
[paste log]
Local command ที่เคยรันผ่าน:
[paste command เช่น npm run build]
Recent changes:
[สรุปล่าสุด]
กติกา:
- อย่าเพิ่งแก้ไฟล์
- ช่วยชี้บรรทัด log ที่สำคัญ
- แยกสาเหตุที่เป็นไปได้ เช่น env var, dependency, build command, TypeScript error
- เสนอ fix ที่เปลี่ยนน้อยที่สุด
Deploy fail ส่วนใหญ่มักมีหลักฐานใน log
อย่าให้ AI เดาโดยไม่มี log
Checklist ก่อนบอกว่า bug fixed
หลัง Claude แก้ bug อย่าเพิ่งเชื่อทันที
ถ้า fix แล้วแต่ไม่รู้ root cause อย่างน้อยให้เขียนไว้ว่าเป็น assumption
อย่าเขียนว่า “แก้แล้ว” แบบไม่มีหลักฐาน
Prompt รวมท้ายบท
ใช้ prompt นี้เวลามี error
ฉันต้องการ debug ปัญหานี้แบบเป็นระบบ
## What happened
[เกิดอะไรขึ้น]
## Expected behavior
[ควรเกิดอะไร]
## Steps to reproduce
1. ...
2. ...
3. ...
## Error/log
[paste error/log]
## Recent changes
[เปลี่ยนอะไรล่าสุด]
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อธิบาย error แบบ non-coder
- ชี้บรรทัด log ที่สำคัญ
- เสนอ root causes ที่เป็นไปได้ 2–3 ข้อ
- บอกวิธีตรวจแต่ละข้อ
- แนะนำ fix ที่เปลี่ยนน้อยที่สุด
- ถ้าต้องแก้หลายไฟล์ ให้เสนอ plan ก่อน
ช่วย review bug fix นี้ก่อน commit
ตรวจว่า:
1. แก้ root cause หรือแค่กลบอาการ
2. เปลี่ยนไฟล์อะไรบ้าง
3. มีผลข้างเคียงอะไรที่ต้อง test
4. มี secret/package/config แปลก ๆ เพิ่มไหม
5. ต้องรัน manual test อะไร
6. commit message ควรเป็นอะไร
สรุป
Debug สำหรับ non-coder ไม่ได้แปลว่าต้องอ่าน code เก่ง
แต่ต้องเก็บหลักฐานให้ดี และไม่ปล่อยให้ AI แก้แบบเดา
- Error คือข้อมูล ไม่ใช่ความล้มเหลว
- Copy log ให้ครบ
- บอก expected behavior เสมอ
- ให้ Claude วิเคราะห์ก่อนแก้
- แก้ทีละจุดและดู diff
- ถ้าพังใน production ให้ rollback ก่อนถ้ากระทบ user จริง
บทต่อไป เราจะรวบทุกอย่างเป็น security checklist สำหรับ vibe coder ก่อนเปิดให้คนอื่นใช้จริง
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย