Debug Evidence Playbook สำหรับ Non-Coder | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand$ cat appendix-f-debug-evidence-playbook.mdDebug Evidence Playbook สำหรับ Non-Coder
ใช้ appendix นี้เมื่อไหร่
ใช้เมื่อ app พัง แต่คุณยังไม่รู้ว่าเกิดจากอะไร
เป้าหมายไม่ใช่ให้คุณอ่าน code เป็น
เป้าหมายคือให้คุณเก็บหลักฐานถูกชุดก่อนให้ Claude Code ช่วยแก้
จำประโยคนี้:
Error ที่ไม่มีหลักฐาน = AI ต้องเดา
Error ที่มีหลักฐาน = AI debug ได้เป็นระบบ
Debug workflow แบบสั้นที่สุด
ทุกครั้งที่เจอปัญหา ใช้ flow นี้:
หยุด
→ จดว่า expected คืออะไร
→ จดว่า actual คืออะไร
→ reproduce ให้ได้
→ เก็บ screenshot/log/error
→ บอก environment
→ ให้ Claude วิเคราะห์ก่อนแก้
→ แก้ทีละจุด
→ test ซ้ำ
ห้ามเริ่มด้วย:
ช่วยวิเคราะห์จากหลักฐานนี้ก่อน อย่าเพิ่งแก้ไฟล์
Error 6 แบบที่ควรแยกให้ได้
| ประเภท | เกิดตอนไหน | หลักฐานที่ต้องเก็บ |
|---|
| Install error | ตอน npm install | terminal output |
| Build error | ตอน npm run build หรือ Vercel build | build log |
| Runtime error | เปิดเว็บ/กดปุ่มแล้วพัง | browser console + screenshot |
| API/data error | form submit ไม่เข้า, 401/403/500 | network tab + server log |
| Permission/RLS error | Supabase block | error message + policy summary |
| Deploy error | Vercel deploy fail | Vercel build/deployment log |
แค่บอกถูกว่าอยู่กลุ่มไหน ก็ช่วย Claude ได้เยอะแล้ว
Evidence template หลัก
ฉันต้องการ debug ปัญหานี้แบบเป็นระบบ
อย่าเพิ่งแก้ไฟล์
## Environment
- local / preview / production:
- URL:
- browser/device:
- time happened:
## What I expected
[ควรเกิดอะไร]
## What actually happened
[เกิดอะไรขึ้นจริง]
## Steps to reproduce
1. ...
2. ...
3. ...
## Evidence
- screenshot:
- browser console error:
- network error/status:
- terminal log:
- Vercel log:
- Supabase error/policy info:
## Recent changes
[เพิ่งแก้อะไร / commit / deploy อะไร]
กติกา:
- อธิบายแบบ non-coder
- ชี้หลักฐานที่สำคัญที่สุด
- เสนอ root causes 2–3 แบบ
- บอกว่าจะตรวจอะไรเพื่อยืนยัน
- อย่าแก้ code จนกว่าจะมี plan
เก็บ Browser Console Error
- หน้า blank
- ปุ่มกดแล้วไม่เกิดอะไร
- form submit แล้วพัง
- UI ค้าง
- browser แสดง error
Browser console = เสียงบ่นของหน้าเว็บฝั่ง user
error message สีแดง
file name ถ้ามี
line number ถ้ามี
stack trace ถ้ามี
warning ที่เกี่ยวกับ env/API/network
อย่า copy แค่คำว่า “error”
นี่คือ browser console error
ช่วยอธิบายแบบ non-coder ว่า error นี้น่าจะเกี่ยวกับอะไร
Console error:
[paste error]
Context:
- หน้า/URL:
- กดอะไรแล้วเกิด:
- local/production:
กติกา:
- อย่าเพิ่งแก้ไฟล์
- แยกว่าเป็น UI bug, missing env, API error, หรือ code runtime error
- บอก evidence ที่ควรเก็บเพิ่ม
เก็บ Network Error
ใช้เมื่อ form/API ไม่ทำงาน
submit แล้วไม่เข้า database
login fail
dashboard โหลดข้อมูลไม่ได้
สิ่งที่ต้องดูใน Network tab:
request URL
status code เช่น 400 / 401 / 403 / 404 / 500
response body/message
method เช่น GET / POST
เวลาเกิด error
ห้าม paste token หรือ secret ที่อยู่ใน headers
ถ้าไม่แน่ใจ ให้บอก Claude:
ฉันจะ paste เฉพาะ status code, URL path, และ response body ที่ไม่มี token
นี่คือ network error จาก browser
ช่วยวิเคราะห์ก่อนแก้
Request:
- method:
- URL/path:
- status code:
- response body:
Context:
- user action:
- local/preview/production:
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อธิบาย status code แบบ non-coder
- แยกว่าเป็น validation, auth, permission, env, หรือ server error
- บอกหลักฐานที่ต้องเก็บเพิ่ม
Status code แบบคนทั่วไป
| Code | แปลแบบง่าย | มักเช็กอะไร |
|---|
| 400 | request ไม่ถูกต้อง | field, validation, payload |
| 401 | ยังไม่ authenticated | login/session/key |
| 403 | ไม่มี permission | role, RLS, authorization |
| 404 | หาไม่เจอ | URL, route, API path, table/resource |
| 409 | conflict | duplicate email, record ซ้ำ |
| 429 | rate limit | ส่งถี่เกิน quota/limit |
| 500 | server พัง | server log, env, code error |
| 502/503/504 | upstream/server unavailable | platform/API outage, timeout |
ใช้เพื่อรู้ว่าควรเก็บหลักฐานอะไรต่อ
เก็บ Terminal Error
ใช้เมื่อ command ในเครื่องพัง เช่น:
npm install
npm run dev
npm run build
npm test
command ที่รัน
error ตั้งแต่เริ่ม fail
บรรทัดที่บอก file/line
บรรทัดแรกที่เป็น root error
ถ้า output ยาวมาก ให้ copy ส่วนท้าย 100–200 บรรทัดก่อน แล้วถาม Claude ว่าต้องการส่วนไหนเพิ่ม
command นี้ fail ใน terminal
ช่วยวิเคราะห์ก่อนแก้
Command:
[command]
Output:
[paste output]
กติกา:
- อย่าเพิ่งแก้ไฟล์
- ชี้บรรทัดที่เป็น root error
- แยก install/build/runtime issue
- เสนอ fix ที่เปลี่ยนน้อยที่สุด
เก็บ Vercel Build Log
ใช้เมื่อ deploy fail หรือ build fail บน Vercel
deployment environment: preview หรือ production
branch/commit
build command
error log ส่วนที่ fail
file path/line ถ้ามี
- build command fail
- dependency ไม่ครบ
- env var missing
- TypeScript/lint error
- file path case sensitivity
- local มีไฟล์ที่ไม่ได้ commit
Vercel build fail
ช่วยวิเคราะห์จาก build log นี้
Environment:
- preview / production:
- branch:
- commit:
Build log:
[paste log]
กติกา:
- อย่าเพิ่งแก้ไฟล์
- ชี้บรรทัด root error
- แยกสาเหตุ env / dependency / build command / code error
- บอกวิธีตรวจแต่ละสาเหตุ
- เสนอ fix ที่เปลี่ยนน้อยที่สุด
เก็บ Vercel Runtime Evidence
บางครั้ง deploy ผ่าน แต่เว็บพังตอน user ใช้
หน้าเปิดได้ แต่ submit form แล้ว 500
API route fail
server action fail
production URL
user action
browser network status
response body
Vercel runtime/function log ถ้ามี
เวลาเกิดปัญหา
Vercel deploy ผ่าน แต่ runtime error ตอนใช้งาน
ช่วย debug จาก evidence นี้
URL:
User action:
Network status/response:
Runtime log:
Time:
Recent deploy/change:
กติกา:
- อย่าเพิ่งแก้ไฟล์
- ประเมินว่าควร rollback ไหมถ้ากระทบ user จริง
- แยก env var, server code, database permission, external API
- เสนอขั้นตอนตรวจทีละข้อ
เก็บ Supabase Evidence
ใช้เมื่อเกี่ยวกับ database, RLS, key, auth
insert ไม่เข้า
select ไม่ได้
permission denied
RLS block
401/403 จาก Supabase
สิ่งที่ต้องเก็บโดยไม่เปิดเผย secret:
table name
operation: select/insert/update/delete
role ที่คาดว่าใช้: anon/authenticated/admin
RLS enabled ไหม
policy names หรือ policy summary
error message
ใช้ local/production
secret key
service_role key
JWT token
database password
Supabase operation fail
ช่วยวิเคราะห์แบบ non-coder
Operation:
- table:
- action: select / insert / update / delete
- expected role: anon / authenticated / admin
- local/production:
Evidence:
- error message:
- RLS enabled:
- policy summary:
- network status if any:
กติกา:
- อย่าใช้ service_role เพื่อ bypass โดยไม่จำเป็น
- อย่าเสนอปิด RLS
- แยกสาเหตุ key / RLS policy / table schema / validation / env var
- เสนอวิธีตรวจแบบปลอดภัย
Local ใช้ได้ แต่ Production พัง
1. env var local กับ Vercel เหมือนกันไหม
2. Vercel redeploy หลังแก้ env var แล้วไหม
3. local มีไฟล์ที่ยังไม่ได้ commit ไหม
4. production ใช้ Supabase project/table เดียวกันไหม
5. build command บน Vercel เหมือนที่รัน local ไหม
6. RLS/policy ต่างกันไหมระหว่าง project
local ใช้ได้ แต่ production พัง
ช่วยทำ differential diagnosis
Local result:
[ใช้ได้อย่างไร]
Production result:
[พังอย่างไร]
Evidence:
- browser console:
- network status:
- Vercel log:
- Supabase info:
- recent changes:
กติกา:
- อย่าเพิ่งแก้ไฟล์
- ทำตาราง Local vs Production
- บอกหลักฐานที่ขาด
- เสนอ test ที่เร็วที่สุดเพื่อแยกสาเหตุ
Production พัง: rollback หรือ debug ก่อน?
ถ้ามี user จริง ให้คิดแบบ incident ก่อน
user ทำ flow หลักไม่ได้
มี payment/data/security impact
error กระทบ user หลายคน
ยังไม่รู้ root cause
rollback มี risk ต่ำกว่า hotfix
ยังไม่มี user จริง
เป็น preview/beta วงเล็ก
bug ไม่กระทบ flow หลัก
fix ชัดมากและ test ได้เร็ว
production พังหลัง deploy ล่าสุด
ช่วยตัดสินใจว่า rollback หรือ debug ก่อน
Impact:
[ใครได้รับผลกระทบ]
Evidence:
[log/error]
Recent change:
[deploy/commit]
กติกา:
- คิดแบบลดผลกระทบ user ก่อน
- ถ้าแนะนำ rollback ให้บอกสิ่งที่ต้องเช็กหลัง rollback
- ถ้าแนะนำ hotfix ให้บอก test ขั้นต่ำก่อน deploy ใหม่
ให้ Claude แก้หลังมี evidence แล้ว
เมื่อวิเคราะห์พอแล้ว ค่อยใช้ prompt แก้
จาก evidence และ analysis ก่อนหน้า
ช่วยแก้ root cause โดยเปลี่ยนน้อยที่สุด
กติกา:
- แก้เฉพาะ issue นี้
- อย่า refactor ส่วนอื่น
- อย่าเพิ่ม package ถ้าไม่จำเป็น
- ถ้าต้องเพิ่ม env var ให้บอกชื่อเท่านั้น ไม่ใส่ค่า
- หลังแก้ให้สรุป diff
- ระบุ manual test ที่ต้องทำ
- ระบุ risk ที่ยังเหลือ
หลังแก้ อย่าลืม test ซ้ำด้วย evidence เดิม
ถ้า error เดิมหาย แต่ error ใหม่มา ให้เริ่ม evidence template ใหม่
Bug report template สำหรับส่งให้ developer
ถ้าต้องส่งต่อให้ dev ใช้ template นี้
# Bug Report
## Summary
[สรุปปัญหา 1–2 บรรทัด]
## Environment
- local / preview / production:
- URL:
- browser/device:
- time:
- commit/deployment:
## Expected
[ควรเกิดอะไร]
## Actual
[เกิดอะไรขึ้น]
## Steps to reproduce
1. ...
2. ...
3. ...
## Evidence
- Screenshot:
- Browser console:
- Network status/response:
- Terminal log:
- Vercel log:
- Supabase error/policy summary:
## Recent changes
[commit/PR/deploy/feature]
## Impact
[low / medium / high]
## Tried already
[ลองอะไรแล้ว]
## Notes
[ข้อสังเกต]
Checklist ก่อนบอกว่า fixed
[ ] reproduce bug ได้ก่อนแก้
[ ] เข้าใจ root cause หรือมี evidence ชัด
[ ] fix เปลี่ยนน้อยที่สุด
[ ] test case เดิมผ่านแล้ว
[ ] ไม่มี secret/log แปลก ๆ เพิ่ม
[ ] build ผ่าน
[ ] preview/production test ตาม environment จริง
[ ] ถ้าเป็น production incident มี note ว่าเกิดอะไรและแก้อย่างไร
ถ้าคุณ reproduce ไม่ได้เลย ให้ระวังการบอกว่า fixed
อาจเป็นแค่ bug ที่ยังไม่เกิดซ้ำในรอบนั้น
Prompt รวมท้าย appendix
ใช้ prompt นี้เป็น default เวลาพัง
ช่วยเป็น debug evidence assistant
ฉันเป็น non-coder
เป้าหมาย:
เก็บหลักฐานให้ครบก่อนแก้ code
ปัญหา:
[อธิบายสั้น ๆ]
ช่วยถามฉันทีละขั้นว่าเราต้องเก็บ evidence อะไรบ้างจาก:
1. browser console
2. network tab
3. terminal
4. Vercel build/runtime logs
5. Supabase table/RLS/error
6. recent commits/deployments
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อย่าขอให้ฉัน paste secret/token/key
- ถ้าหลักฐานพอแล้ว ให้สรุป root causes ที่เป็นไปได้
- เสนอวิธีตรวจที่เร็วที่สุด
- ค่อยเสนอ fix หลังจากมี evidence พอ
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย