Prompt Templates สำหรับ Vibe Coding | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand$ cat appendix-a-prompt-templates.mdPrompt Templates สำหรับ Vibe Coding
วิธีใช้ appendix นี้
ส่วนนี้คือ prompt ที่เอาไป copy ใช้กับ Claude Code ได้ทันที
ไม่จำเป็นต้องใช้ทุก prompt
ให้เลือกตามสถานการณ์:
เริ่มไอเดีย → ใช้ Prompt 1–4
กำลัง build → ใช้ Prompt 5–9
เจอ error → ใช้ Prompt 10–11
ก่อน deploy → ใช้ Prompt 12–14
หลัง launch → ใช้ Prompt 15–17
ส่งต่อ dev → ใช้ Prompt 18
กติกาสำคัญ:
- แทนที่ข้อความใน
[วงเล็บ] ด้วยข้อมูลของคุณ
- อย่า paste secret/API key จริงลง prompt
- ถ้าเป็นงานใหญ่ ให้สั่ง “วางแผนก่อนแก้ไฟล์” เสมอ
- ถ้าไม่แน่ใจ ให้สั่ง “อธิบายแบบ non-coder”
- อย่าให้ Claude แก้หลายเรื่องพร้อมกันโดยไม่จำเป็น
Prompt 1 — สัมภาษณ์ไอเดียให้กลายเป็น project
ใช้เมื่อมีแค่ไอเดียกว้าง ๆ
ช่วยสัมภาษณ์ฉันเพื่อเปลี่ยนไอเดียนี้เป็น project ที่ Claude Code สร้างได้
ไอเดียของฉัน:
[อธิบายไอเดียสั้น ๆ]
บริบท:
- ฉันเป็น non-coder
- อยากทำ project ขนาดเล็กที่จบได้
- ยังไม่อยากทำระบบ production ซับซ้อน
ให้ถามทีละชุด ไม่เกิน 5 คำถามต่อรอบ
โฟกัสเรื่อง:
1. เป้าหมายของ project
2. user คือใคร
3. ปัญหาที่แก้
4. feature ที่จำเป็นจริง ๆ
5. feature ที่ยังไม่ควรทำ
6. data ที่ต้องเก็บ
7. ความเสี่ยงเรื่อง privacy/security
หลังถามครบ ให้สรุปเป็น project brief แบบสั้น
Prompt 2 — ทำ Project Brief หนึ่งหน้า
ใช้ก่อนเริ่มเขียน spec หรือ CLAUDE.md
ช่วยสร้าง project brief หนึ่งหน้าจากข้อมูลนี้
ข้อมูล:
[วางข้อมูล project]
รูปแบบที่ต้องการ:
# Project Brief
## Project name
[ชื่อ project]
## Goal
[เป้าหมายหลัก]
## Target user
[user คือใคร]
## Core problem
[ปัญหาที่แก้]
## Core user flow
1. ...
2. ...
3. ...
## Must-have features
- ...
## Nice-to-have features
- ...
## Non-goals
- สิ่งที่ยังไม่ทำตอนนี้
## Data collected
- field name
- reason to collect
- sensitivity level
## Risks
- security/privacy/product risks
เขียนให้ non-coder อ่านเข้าใจ
อย่าเพิ่ม feature เองถ้าไม่ได้จำเป็น
Prompt 3 — เขียน Product Spec ที่ AI เอาไป build ได้
ช่วยแปลง brief นี้เป็น product spec สำหรับให้ Claude Code build
Brief:
[วาง project brief]
Spec ต้องมี:
1. Goal
2. Target users
3. Pages/screens
4. User flows
5. Data fields
6. Empty/loading/error states
7. Validation rules
8. Acceptance criteria
9. Non-goals
10. Security/privacy notes
11. Manual test checklist
กติกา:
- เขียนแบบชัดเจน ไม่ยืดยาว
- ถ้าข้อมูลไม่พอ ให้ใส่คำถามท้าย spec
- อย่าเดาเรื่อง sensitive data
- แยก must-have กับ later ให้ชัด
Prompt 4 — สร้าง CLAUDE.md สำหรับ project
ใช้เพื่อให้ Claude Code รู้บริบทและกติกาของ project
ช่วยสร้างไฟล์ CLAUDE.md สำหรับ project นี้
Project brief/spec:
[วาง brief หรือ spec]
CLAUDE.md ต้องมี:
# Project Overview
- app นี้ทำอะไร
- user คือใคร
- goal หลัก
# Tech Stack
- framework:
- database:
- deploy:
- package manager:
# Working Rules
- ก่อนแก้ไฟล์ใหญ่ ให้เสนอ plan ก่อน
- เปลี่ยนทีละ scope
- หลังแก้ให้สรุป diff แบบ non-coder
- ห้ามใส่ secret/API key จริงใน code
- ห้ามปิด security เช่น RLS เพื่อแก้ปัญหาถาวร
# Test Commands
- install:
- dev:
- build:
- lint/test ถ้ามี:
# Manual QA Checklist
- core flow
- mobile
- form validation
- error state
- security checks
# Non-goals
- สิ่งที่ไม่ทำตอนนี้
กติกา:
- อย่าใส่ secret จริง
- ถ้าไม่รู้ stack ให้ใส่ TODO
- เขียนให้สั้นและชัด
Prompt 5 — Explore ก่อนแก้ไฟล์
ใช้เมื่อเปิด project เดิม หรือไม่แน่ใจว่า code ทำงานอย่างไร
ช่วยสำรวจ project นี้ก่อน
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อ่านโครงสร้าง project เท่าที่จำเป็น
- สรุปแบบ non-coder
ช่วยบอก:
1. project นี้น่าจะทำอะไร
2. folder/file สำคัญมีอะไรบ้าง
3. stack ที่ใช้คืออะไร
4. command ที่น่าจะใช้รัน/test/build
5. จุดเสี่ยงหรือสิ่งที่ควรระวัง
6. คำถามที่ควรถามก่อนเริ่มแก้
Prompt 6 — Plan before editing
ใช้ก่อนให้ Claude Code แก้ feature หรือ bug ที่เกิน 1 ไฟล์
ช่วยวาง implementation plan ก่อนแก้ไฟล์
Task:
[อธิบายสิ่งที่ต้องการ]
Context:
[วาง spec/bug/feedback ที่เกี่ยวข้อง]
กติกา:
- อย่าเพิ่งแก้ไฟล์
- เสนอ plan เป็นขั้นตอน
- ระบุไฟล์ที่คาดว่าจะเปลี่ยน
- ระบุ risk หรือ side effect
- ระบุ manual test ที่ต้องทำหลังแก้
- ถ้า scope ใหญ่เกิน ให้เสนอ scope ที่เล็กลง
- ถ้าต้องตัดสินใจ ให้ถามฉันก่อน
Prompt 7 — Build landing page
ใช้สร้าง landing page หน้าแรก
ช่วย build landing page จาก brief นี้
Brief:
[วาง landing page brief]
ต้องมี section:
1. Hero พร้อม headline/subheadline/CTA
2. Problem
3. Benefits 3–5 ข้อ
4. How it works
5. Social proof หรือ placeholder ถ้ายังไม่มี
6. FAQ
7. Final CTA
กติกา:
- ทำให้ responsive/mobile-friendly
- copy ต้องชัด ไม่ hype เกินจริง
- อย่าเพิ่ม tracking/payment/form ที่ไม่ได้ขอ
- ใช้ style เรียบ อ่านง่าย
- หลังแก้ให้สรุปว่าเปลี่ยนไฟล์อะไร
- บอก manual test ที่ควรทำ
Prompt 8 — Revise UI/copy แบบคุม scope
ใช้ปรับหน้าที่ build แล้ว
ช่วยปรับ UI/copy ของหน้านี้ตาม feedback
Feedback:
[วาง feedback]
กติกา:
- อย่าเปลี่ยน layout ทั้งหมดถ้าไม่จำเป็น
- อย่าเพิ่ม feature ใหม่
- เน้น clarity, mobile readability, CTA
- ถ้ามีหลายทางเลือก ให้เสนอ 2 options ก่อน
- หลังแก้ให้สรุป diff แบบ non-coder
เป้าหมายของการแก้รอบนี้:
[เช่น hero ชัดขึ้น / CTA เด่นขึ้น / mobile spacing ดีขึ้น]
Prompt 9 — Supabase schema สำหรับ waitlist
ใช้ก่อนสร้าง database/table
ช่วยออกแบบ Supabase table สำหรับ waitlist app
App context:
[อธิบาย app]
Data ที่คิดว่าจะเก็บ:
[รายการ field]
ช่วยตอบเป็น:
1. table name ที่แนะนำ
2. columns พร้อม type แบบเข้าใจง่าย
3. field ไหนจำเป็น / optional
4. field ไหนไม่ควรเก็บตอนนี้
5. validation rules
6. RLS policy แนวคิดแบบ non-coder
7. public user ควรทำ action อะไรได้บ้าง
8. public user ไม่ควรทำอะไรได้บ้าง
กติกา:
- ใช้ data minimization
- ห้ามเสนอให้ปิด RLS เพื่อความง่าย
- อย่าใช้ service_role ใน frontend
Prompt 10 — ต่อ Supabase เข้ากับ app แบบปลอดภัย
ใช้ตอนให้ Claude Code เชื่อม form กับ database
ช่วยต่อ form นี้เข้ากับ Supabase
Context:
- form อยู่ที่: [หน้า/ไฟล์ ถ้ารู้]
- table: [ชื่อ table]
- fields: [field list]
กติกา:
- ใช้ publishable key เฉพาะที่ public ได้
- secret/service_role ห้ามอยู่ใน frontend/browser
- ใช้ environment variables
- เพิ่ม validation ขั้นพื้นฐาน
- เพิ่ม success/error state แบบ user อ่านเข้าใจ
- อย่า log secret หรือข้อมูลส่วนตัวเกินจำเป็น
- หลังแก้ให้บอกว่า env var ต้องตั้งชื่ออะไรบ้าง แต่ห้ามใส่ค่าจริง
- ระบุ manual test checklist
Prompt 11 — Debug report
ฉันต้องการ debug ปัญหานี้แบบเป็นระบบ
## What happened
[เกิดอะไรขึ้น]
## Expected behavior
[ควรเกิดอะไร]
## Steps to reproduce
1. ...
2. ...
3. ...
## Error/log
[paste error/log เต็ม ๆ]
## Recent changes
[เปลี่ยนอะไรล่าสุด]
## Environment
- local / preview / production:
- command used:
- URL/page:
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อธิบาย error แบบ non-coder
- ชี้ log บรรทัดที่สำคัญ
- เสนอ root causes ที่เป็นไปได้ 2–3 ข้อ
- บอกวิธีตรวจแต่ละข้อ
- แนะนำ fix ที่เปลี่ยนน้อยที่สุด
Prompt 12 — แก้ bug แบบเปลี่ยนน้อยที่สุด
ใช้หลัง Claude วิเคราะห์ error แล้ว
จาก analysis ก่อนหน้า ช่วยแก้ bug นี้โดยเปลี่ยนน้อยที่สุด
กติกา:
- แก้เฉพาะ root cause ที่ยืนยันแล้ว
- อย่า refactor ส่วนอื่น
- อย่าเพิ่ม package ถ้าไม่จำเป็น
- ถ้าต้องเพิ่ม package ให้หยุดอธิบายก่อน
- หลังแก้ให้สรุปไฟล์ที่เปลี่ยน
- บอก command หรือ manual test ที่ต้องรัน
- บอก risk ที่ยังเหลือ
Prompt 13 — Review diff ก่อน commit
ช่วย review changes ตอนนี้ก่อน commit
ตรวจว่า:
1. เปลี่ยนไฟล์อะไรบ้าง
2. แต่ละไฟล์เปลี่ยนเพื่ออะไร
3. มี change นอก scope ไหม
4. มี secret/API key/.env หลุดไหม
5. มี package ใหม่ไหม และจำเป็นไหม
6. มีผลต่อ security หรือ data permission ไหม
7. ต้อง test อะไรเพิ่มไหม
8. commit message ควรเป็นอะไร ใช้ Conventional Commits
กติกา:
- อธิบายแบบ non-coder
- ถ้ามี red flag ให้บอกให้หยุดก่อน commit
Prompt 14 — Security review ก่อน deploy
ใช้ก่อนเปิดให้คนอื่นใช้จริง
ช่วยทำ security review ก่อน deploy สำหรับ project นี้
ฉันเป็น non-coder ขอให้อธิบายแบบเข้าใจง่าย
ขอบเขต:
- frontend
- API/server actions
- Supabase/database/RLS
- environment variables
- authentication/authorization
- input validation
- logging
- dependencies
- deployment settings
กติกา:
- อย่าเพิ่งแก้ไฟล์
- อย่า print secret จริง
- แยกผลเป็น Critical / High / Medium / Low
- ทุก issue ต้องมี: หลักฐาน, ความเสี่ยง, วิธีแก้ที่แนะนำ
- ถ้าไม่แน่ใจ ให้บอกว่าไม่แน่ใจ
- สรุปท้ายว่า launch ได้ไหมแบบ Green / Yellow / Red
Prompt 15 — Deploy readiness
ใช้ก่อน deploy preview หรือ production
ช่วยตรวจ deploy readiness ของ project นี้
แยก local / preview / production
ตรวจว่า:
1. command build คืออะไร
2. env var ที่จำเป็นมีอะไรบ้าง
3. ค่าไหน public ได้
4. ค่าไหนเป็น secret
5. production ยังมี test/dev value ไหม
6. database และ RLS พร้อมไหม
7. rollback plan คืออะไร
8. manual test หลัง deploy ต้องทำอะไร
กติกา:
- อย่า print ค่า secret จริง
- ถ้ามี blocker ให้แยกเป็นรายการชัดเจน
- สรุปเป็น Green / Yellow / Red
Prompt 16 — Small launch plan
ใช้ก่อนส่ง link ให้ user ชุดแรก
ช่วยวาง small launch plan สำหรับ app นี้
ฉันเป็น non-coder
App context:
[อธิบาย app]
ให้ตอบเป็น:
1. ควรเปิดให้ใครลองก่อน
2. จำนวน user แรกที่เหมาะสม
3. feature ไหนควรเปิด/ปิด
4. สิ่งที่ต้อง monitor
5. feedback ที่ควรถาม user
6. ถ้าเกิดปัญหา ต้องปิดหรือ rollback อย่างไร
7. เกณฑ์ว่าพร้อมขยาย audience หรือยัง
อย่าเสนอ launch ใหญ่ถ้ายังมี risk สำคัญ
Prompt 17 — Feedback to backlog
ใช้หลังได้ feedback จาก user
ฉันมี feedback จากผู้ใช้ชุดนี้
ช่วยแปลงเป็น backlog แบบเป็นระบบ
กติกา:
- อย่าเพิ่งเสนอ code
- รวม feedback ที่ซ้ำกัน
- แยกเป็น Bug / Improvement / New Feature / Question
- ให้ priority เป็น P0 / P1 / P2 / Later
- บอกเหตุผลของ priority แบบ non-coder
- ถ้าข้อมูลไม่พอ ให้ระบุว่าต้องถาม user อะไรเพิ่ม
Feedback:
[paste feedback]
Prompt 18 — Post-launch review
ช่วยทำ post-launch review สำหรับ app นี้
ฉันเป็น non-coder
ข้อมูล:
- app ทำอะไร:
- เปิดให้ใครใช้:
- feedback ที่ได้รับ:
- bug ที่พบ:
- metrics หรือ observation:
- สิ่งที่กังวล:
ให้ช่วย:
1. สรุปสิ่งที่เรียนรู้
2. แยก feedback เป็น Bug / Improvement / New Feature / Question
3. จัด priority P0 / P1 / P2 / Later
4. เสนอ iteration รอบถัดไปไม่เกิน 3 งาน
5. บอก risk ก่อนแก้
6. แนะนำว่าควรทำเองต่อหรือควรให้ developer review
กติกา:
- อย่าเพิ่งแก้ code
- อย่าเพิ่ม scope เกิน feedback
- อธิบายแบบ non-coder
Prompt 19 — Handoff document สำหรับส่งต่อ developer
ใช้เมื่อ project เริ่มจริงจัง หรือคุณต้องให้ dev ช่วยต่อ
ช่วยสร้าง handoff doc จาก project นี้
ฉันจะส่งต่อให้ developer
ต้องมี:
# Handoff Doc
## App purpose
[app นี้ทำอะไร เพื่อใคร]
## Current status
[prototype / beta / production]
## Main user flows
1. ...
2. ...
## Tech stack
- Frontend:
- Backend/API:
- Database:
- Deploy:
## Environment variables
| Name | Public/Secret | Used for | Where set |
|---|---|---|---|
## Database and permissions
- Tables:
- RLS policies:
- Roles:
## How to run locally
[คำสั่งและขั้นตอน]
## How to deploy
[branch, Vercel project, env notes]
## Known issues
[รายการ]
## Backlog
[P0/P1/P2/Later]
## Risks
[security, data, cost, operational]
กติกา:
- อย่าใส่ค่า secret จริง
- ถ้าไม่รู้ข้อมูลส่วนไหน ให้ใส่ TODO
- อธิบาย architecture แบบภาพรวม
- สรุป risks และ known issues ตรง ๆ
Prompt 20 — Monthly maintenance review
ใช้เดือนละครั้งถ้ายังดูแล app เอง
ช่วยทำ monthly maintenance review สำหรับ project นี้
ฉันเป็น non-coder
ตรวจเรื่อง:
1. account/admin access และ 2FA
2. secret/API key ที่ไม่ใช้แล้ว
3. Supabase RLS/policies
4. package/dependency risk
5. logs มีข้อมูล sensitive ไหม
6. backup/export ที่จำเป็น
7. Vercel/Supabase billing
8. domain/SSL/deployment
9. backlog priority
10. unused project/deployment/integration
กติกา:
- ให้ผลเป็น Green / Yellow / Red
- เสนอ action ไม่เกิน 5 ข้อ
- แยกสิ่งที่ต้องทำทันทีออกจากสิ่งที่รอได้
- อย่า print ค่า secret จริง
Prompt 21 — Cost review
ใช้เมื่อเริ่มมี user จริง หรือก่อนเปิด public
ช่วยทำ cost review สำหรับ project นี้
Context:
[อธิบาย app, services ที่ใช้, จำนวน user คาดการณ์]
แยกเป็น:
1. ค่าใช้จ่ายตอน prototype
2. ค่าใช้จ่ายเมื่อมี user 100 / 1,000 / 10,000 คน
3. cost driver ที่ต้อง monitor
4. feature ไหนอาจทำให้ค่าใช้จ่ายพุ่ง
5. วิธีลด cost โดยไม่ลดคุณค่าหลัก
6. จุดที่ต้องกลับไปเช็กราคา official ล่าสุด
กติกา:
- ถ้าไม่มีข้อมูลราคาแน่นอน ให้บอกว่าเป็น estimate
- อย่าคิดราคาเองแบบมั่นใจถ้าไม่ได้ตรวจ official pricing ล่าสุด
Prompt 22 — Stop and ask when scope grows
ใช้ใส่ท้าย prompt ใหญ่ ๆ เพื่อกัน AI ขยายงานเอง
ข้อจำกัดสำคัญ:
ถ้าระหว่างทำงานพบว่า scope ใหญ่ขึ้น เช่น
- ต้องเพิ่ม package ใหม่
- ต้องแก้ database schema
- ต้องเปลี่ยน auth/permission
- ต้องแตะไฟล์เกินที่คาด
- ต้องเปลี่ยน architecture
- ต้องใช้ secret/admin key
ให้หยุดและถามฉันก่อน
อย่าตัดสินใจเอง
Prompt 23 — Explain like I am a non-coder
ใช้ทุกครั้งที่คำตอบเริ่ม technical เกินไป
ช่วยอธิบายใหม่แบบ non-coder
ต้องตอบโดย:
- ใช้ภาษาคนทั่วไป
- ไม่ลงรายละเอียด code เกินจำเป็น
- เปรียบเทียบกับสิ่งที่เข้าใจง่าย
- บอกว่าฉันต้องตัดสินใจอะไร
- บอกว่าความเสี่ยงคืออะไร
- ถ้ามีศัพท์ technical ให้แปลเป็นภาษาง่าย ๆ
Prompt 24 — Final pre-launch checklist รวมทุกอย่าง
ทำ final pre-launch checklist ให้ project นี้
ฉันเป็น non-coder
ตรวจ:
1. product flow
2. mobile/responsive
3. form validation
4. empty/loading/error states
5. secrets/env vars
6. Supabase publishable vs secret/service_role keys
7. RLS และ database policies
8. auth vs authorization
9. logs/error messages
10. dependencies/packages
11. preview/production config
12. rollback plan
13. feedback collection
14. owner/maintenance plan
กติกา:
- อย่าแก้ไฟล์ก่อน
- อย่า print secret จริง
- ถ้าเจอ critical issue ให้หยุดและอธิบายก่อน
- ทำ report เป็นตาราง
- ให้ launch gate เป็น Green / Yellow / Red
- เสนอ next steps ไม่เกิน 5 ข้อ
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย