บริษัทอัตโนมัติ · THEAUTOMATION.BIZ

เข้าใจ Tech Stack
สาย Vibe Code

Next.js · Supabase · shadcn/ui · Vercel · Git · Superpowers
สำหรับคนที่สร้างแอปด้วย AI ได้แล้ว แต่ยังไม่รู้ว่าข้างในทำงานยังไง

สารบัญ · กดที่หัวข้อเพื่อข้ามไปบทนั้น

เนื้อหาทั้งหมด แบ่งเป็นเจ็ดบท

บทที่ 1

เส้นทางของข้อมูล

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

ระบบเว็บคือร้านอาหาร หน้าบ้าน หลังบ้าน ฐานข้อมูล เครื่องมือสี่ตัวอยู่ตรงไหน สั่ง AI ให้ครบเส้นทาง

ตอนคุณกดปุ่มบนเว็บ
เกิดอะไรขึ้นบ้าง

คุณพิมพ์สั่ง AI ว่า “สร้างปุ่มบันทึกข้อมูล” แล้วได้ปุ่มที่ใช้งานได้จริงในไม่กี่วินาที

ใต้ปุ่มนั้นมีชิ้นส่วนหลายตัวทำงานต่อกันเป็นทอด ๆ โดยอัตโนมัติ วันนี้เราจะเปิดฝาดูข้างใน

เข้าใจเบื้องหลัง = สั่ง AI ได้ตรงจุด ตรวจงานเป็น และปิดช่องโหว่ความปลอดภัยได้เอง

ระบบเว็บ คือร้านอาหาร

ทุกคำศัพท์ที่ AI พ่นใส่คุณ มีที่อยู่ของมันในร้านอาหารร้านนี้

ศัพท์เทคนิค	ความหมาย	เทียบกับร้านอาหาร
Client	อุปกรณ์ฝั่งผู้ใช้ หรือเว็บเบราว์เซอร์	ลูกค้าที่นั่งอยู่ที่โต๊ะ
Frontend	ส่วนหน้าบ้านที่ผู้ใช้เห็นและกดได้	หน้าเมนู จานชาม บรรยากาศร้าน
API	ช่องทางรับส่งข้อมูลระหว่างหน้าบ้านกับหลังบ้าน	พนักงานเสิร์ฟที่เดินเข้าออกครัว
Backend	ส่วนหลังบ้านที่ประมวลผลและตัดสินใจ	ห้องครัวและหัวหน้าเชฟ
Server	เครื่องคอมพิวเตอร์ที่รัน backend	ตัวอาคารครัวและเตา
Database	ระบบฐานข้อมูลที่เก็บข้อมูลถาวร	ห้องเก็บวัตถุดิบที่ล็อกกุญแจ
Request	คำขอที่ส่งจากผู้ใช้ไปหลังบ้าน	ใบสั่งอาหาร
Response	ข้อมูลที่หลังบ้านส่งกลับมา	จานอาหารที่เสิร์ฟกลับมา

เดินตามข้อมูลหนึ่งก้อน ครบวงจร

01 – 02 หน้าบ้านFrontend รวบรวมสิ่งที่ผู้ใช้กรอก แล้วแพ็กเป็น Request ส่งผ่าน API ออกไป

03 – 04 หลังบ้านBackend ตรวจว่าข้อมูลถูกต้องไหม และคนนี้มีสิทธิ์ทำสิ่งนี้จริงหรือเปล่า ก่อนสั่งเขียนลง Database

05 กลับสู่หน้าจอResponse เดินทางกลับผ่าน API แล้ว Frontend อัปเดตหน้าจอให้ผู้ใช้เห็นว่าทำสำเร็จ

เครื่องมือทั้งสี่ ยืนอยู่ตรงไหนของเส้นทาง

shadcn/ui — ชั้นบนสุดอยู่ฝั่ง Frontend วาดปุ่ม ฟอร์ม กล่องข้อความ เทียบกับจานชามและหน้าตาเล่มเมนู

Next.js — ครอบทั้งสองฝั่งเป็นทั้ง Frontend และ Backend ในตัวเดียว รับหน้าร้านและส่งงานเข้าหลังบ้านผ่าน Server Actions เทียบกับผู้จัดการร้านที่ดูแลทั้งสองฝั่ง

Supabase — หลังบ้านทั้งหมดDatabase ที่ใช้ Postgres พร้อมระบบสมาชิก ที่เก็บไฟล์ และ API อัตโนมัติ มี Row Level Security เป็นกุญแจล็อกห้องเก็บของ

Vercel — ที่ตั้งของร้านจัดหาเซิร์ฟเวอร์และเครือข่ายส่งข้อมูลทั่วโลก ทุกครั้งที่ push โค้ดจะ build และ deploy ให้อัตโนมัติ

สั่ง AI กว้างไป
ได้ของที่ต่อสายไม่ครบ

สั่งแบบเดิม“ทำปุ่มบันทึกให้ที”

สั่งแบบระบุเส้นทาง“สร้างปุ่มบันทึกโปรไฟล์ด้วย shadcn/ui บน Frontend เขียน Server Actions ด้วย Next.js ส่งไปบันทึกในตารางผู้ใช้บน Supabase และเปิด RLS ให้ผู้ใช้เห็นเฉพาะข้อมูลตัวเอง”

ช่องโหว่ที่พบมากที่สุด คือตารางใน Supabase ที่กฎกรองข้อมูลหลวมเกินไป คีย์ฝั่งหน้าเว็บฝังอยู่ในหน้าเว็บอยู่แล้ว ใครคัดไปก็ยิงตรงเข้า API อ่านข้อมูลของคนอื่นได้

AI เขียนโค้ดให้ ทำงานสำเร็จ ไม่ได้เขียนให้ ปลอดภัย
คนสั่งต้องเป็นคนตรวจ

บทที่ 2

Next.js

เครื่องมือที่ AI เลือกให้บ่อยที่สุด และเป็นตัวที่ทำให้หน้าบ้านกับหลังบ้านอยู่ในโปรเจ็คเดียวกัน รู้โครงของมันแล้วจะอ่านออกว่า AI วางไฟล์อะไรไว้ตรงไหน

ชื่อโฟลเดอร์กลายเป็น URL Server กับ Client Component Server Actions กับดักที่เจอบ่อย

Next.js คือ frontend
กับ backend ในตัวเดียว

React Framework ที่ทีมส่วนใหญ่เลือกใช้เมื่อจะทำเว็บจริง และเป็นตัวที่ AI เจนออกมาให้บ่อยที่สุด ออกแบบมาให้เขียนเว็บครบวงจรจบในโปรเจ็คเดียว

สมัยก่อนเขียน Frontend ด้วยเครื่องมือหนึ่ง เขียน Backend ด้วยอีกระบบ แล้วต่อกันผ่าน API

ตอนนี้ระบบ App Router รันโค้ดทั้งสองฝั่งในโฟลเดอร์เดียวกัน ดึงข้อมูลจาก Database ได้ตรงจากในหน้าเว็บเลย

โครงไฟล์จริง ชื่อโฟลเดอร์กลายเป็น URL

// โฟลเดอร์ app/blog/ กลายเป็น URL /blog
app/
├── layout.tsx      โครงร่างร่วมทุกหน้า
├── page.tsx        เนื้อหาหน้าแรก
├── loading.tsx     หน้าจอรอโหลด
├── error.tsx       หน้าจอเมื่อพัง
├── blog/
│   └── page.tsx    หน้า /blog
└── api/
    └── route.ts    จุดรับส่งข้อมูล

ไฟล์	หน้าที่
`page.tsx`	เนื้อหาหลักของหน้านั้น โฟลเดอร์ไหนมีไฟล์นี้ URL นั้นถึงจะเปิดได้
`layout.tsx`	โครงร่างร่วม เช่น แถบเมนู ไม่ประมวลผลซ้ำเวลาเปลี่ยนหน้า
`loading.tsx`	หน้าจอรอโหลด ระบบเอามาโชว์ให้เองระหว่างดึงข้อมูล ไม่ต้องสั่ง
`error.tsx`	รับมือ error เฉพาะจุด ไม่ให้เว็บดับทั้งหน้า
`route.ts`	API endpoint รับส่งข้อมูลดิบแบบ JSON ไม่มีหน้าจอ

ชิ้นส่วนที่คนกดได้
ต้องเขียนกำกับไว้หนึ่งบรรทัด

หน้าเว็บใน Next.js มีสองแบบ ค่าเริ่มต้นคือแบบที่ประกอบเสร็จบนเซิร์ฟเวอร์ ส่วนชิ้นที่ต้องตอบสนองคนใช้ ต้องบอกระบบว่าให้ส่งไปทำงานในเบราว์เซอร์

แค่แสดงผล หัวเรื่อง ข้อความ รูป ตารางที่ดึงข้อมูลมาโชว์เฉย ๆ

ไม่ต้องเขียนอะไรเพิ่ม

คนกดได้ พิมพ์ได้ ปุ่ม ฟอร์ม ช่องค้นหา dropdown แท็บ animation

ใส่ "use client" บรรทัดแรกของไฟล์

// error ที่จะได้เห็นบ่อยที่สุด
You're importing a component that
needs useState. This React Hook only
works in a Client Component. To fix,
mark the file with the "use client"
directive.

อ่านว่า ไฟล์นี้มีของที่ต้องตอบสนองคนใช้ แต่ยังไม่ได้บอกระบบไว้ สั่ง AI ว่า “ใส่ use client ให้ไฟล์นี้” จบในครั้งเดียว

อย่าใส่ที่หน้าหลัก ใส่เฉพาะไฟล์ชิ้นเล็กที่ต้องกดจริง ถ้าใส่ที่หน้าบนสุด ทั้งหน้าจะถูกส่งไปทำงานในเบราว์เซอร์ เว็บช้าลงและดึงข้อมูลตรงจาก Database ไม่ได้อีก

Server Actions ให้ปุ่มบนหน้าเว็บ สั่งงานหลังบ้านได้ตรง ๆ

เมื่อก่อนต้องสร้างช่องทางรับคำสั่งไว้อีกไฟล์ แล้วเขียนโค้ดสองฝั่งให้คุยกันเอง ตอนนี้เขียนฟังก์ชันเดียวแล้วผูกกับฟอร์มได้เลย

// lib/actions/user.ts
'use server';  // ทั้งไฟล์รันบนเซิร์ฟเวอร์

export async function saveProfile(formData) { … }

ทำไมต้องรู้ โค้ดใต้ 'use server' คือฝั่งที่คนดูซอร์สเว็บมองไม่เห็น เป็นที่เดียวที่ใส่คีย์ลับและต่อ Database ตรงได้อย่างปลอดภัย

สั่ง AI ให้เก็บไฟล์กลุ่มนี้ไว้ที่ /lib/actions/ ตั้งชื่อตามเรื่องที่มันดูแล เช่น auth.ts user.ts billing.ts จะหาเจอตอนต้องแก้

กับดักที่ AI ทำให้คุณติดบ่อยที่สุด

AI มักเจนโค้ดยุค Pages Router ปนมากับ App Router ทำให้โปรเจ็ครันไม่ผ่าน คุณต้องดูออกเอง

จุดสังเกต	App Router (ปัจจุบัน)	Pages Router (เก่า)
โฟลเดอร์	`/app`	`/pages`
ชื่อไฟล์	ตายตัว `page.tsx` `layout.tsx`	ตั้งชื่อตาม URL เช่น `about.tsx`
การดึงข้อมูล	`async/await` ในตัวหน้าเอง	`getServerSideProps`

สองโฟลเดอร์นี้อยู่ในโปรเจ็คเดียวกันได้ Next.js ออกแบบมาให้ย้ายทีละหน้า แต่ห้ามให้ URL เดียวกันมีทั้งสองที่ จะขึ้น Conflicting app and page file was found แล้ว build ไม่ผ่าน

ประโยคที่ควรต่อท้ายทุกครั้งเวลาสั่ง AI “ให้เขียนด้วย Next.js รุ่นล่าสุด รูปแบบ App Router เท่านั้น ห้ามใช้ pages/ หรือ getServerSideProps และจัดการข้อมูลผ่าน Server Actions”

รันได้ในเครื่อง ไม่ได้แปลว่าขึ้นเว็บได้

โค้ดต้องผ่านสองด่านที่เข้มไม่เท่ากัน ด่านแรกคือตอนแก้งานในเครื่อง ผ่อนปรนให้ทำงานต่อได้ ด่านสองคือตอนแปลงเป็นเว็บจริง เข้มงวดกว่ามาก และเป็นด่านที่ Vercel รันทุกครั้งที่คุณ push

หัวข้อ	`npm run dev` — ตอนแก้งาน	`npm run build` — ตอนขึ้นเว็บ
ประมวลผลกี่หน้า	เฉพาะหน้าที่เปิดดูอยู่	ทุกหน้าในโปรเจ็ค
เจอโค้ดผิดชนิดข้อมูล	เตือนไว้ แต่ยังเปิดเว็บต่อได้	หยุดทันที ไม่ได้ไฟล์เว็บออกมา
หน้าที่ยังไม่เคยเปิดดู	ไม่มีใครรู้ว่าพัง	เจอทันทีในรอบเดียว
ใครรันด่านนี้	คุณ ตอนนั่งทำงาน	Vercel ทุกครั้งที่ push

อาการคลาสสิก — เว็บในเครื่องใช้ได้ทุกหน้า แต่ push ขึ้นไปแล้ว Vercel ขึ้นแดงว่า Build Failed เพราะมีหน้าที่คุณไม่เคยเปิดดูเลยตั้งแต่ AI สร้างให้

นิสัยที่ต้องติดตั้งแต่วันนี้ ก่อนจะเชื่อว่างานเสร็จ สั่งว่า “รัน npm run build ให้ผ่านก่อน ถ้าไม่ผ่านให้แก้จนผ่าน แล้วค่อยบอกว่าเสร็จ” จะเจอปัญหาในเครื่องตัวเอง แทนที่จะไปเจอตอนเว็บขึ้นไม่ได้

บทที่ 3

Supabase

หลังบ้านสำเร็จรูปที่ให้ฐานข้อมูล ระบบสมาชิก และที่เก็บไฟล์มาในกล่องเดียว พร้อมสวิตช์ความปลอดภัยหนึ่งตัวที่ถ้าลืมเปิด ข้อมูลทั้งตารางเปิดสู่อินเทอร์เน็ตทันที

ห้าชิ้นส่วนในกล่องเดียว Row Level Security สองคีย์ที่ต้องแยกให้ออก ข้อจำกัดที่ควรรู้

Supabase คือ backend
ที่ไม่ต้องเขียนเอง

แพลตฟอร์มแบบ Backend-as-a-Service ที่เปิดซอร์สโค้ด สร้างบนฐาน PostgreSQL ที่นักพัฒนาทั่วโลกใช้จริง ไม่ใช่ฐานข้อมูลจำลอง

งาน	สมัยก่อน	ตอนนี้
ฐานข้อมูล	เช่าเซิร์ฟเวอร์ ติดตั้ง ตั้งค่าเอง	กดสร้างโปรเจ็ค เสร็จใน 2 นาที
API	เขียนโค้ดเองทุกเส้นทาง	สร้างอัตโนมัติจากตาราง
ระบบสมาชิก	เขียนสมัคร ล็อกอิน เข้ารหัสเอง	เปิดใช้ได้ทันที
อัปโหลดไฟล์	สร้างระบบเก็บไฟล์เอง	Storage พร้อมใช้

ห้าชิ้นส่วนที่ได้มาในกล่องเดียว

Postgres Databaseฐานข้อมูลจริง รองรับคำสั่ง SQL เต็มรูปแบบ ไม่ใช่ของเล่น

Authenticationสมัครและล็อกอินด้วยอีเมล, magic link, OAuth ผ่าน Google GitHub Apple, SMS และการยืนยันหลายชั้น

Storageเก็บรูป เอกสาร วิดีโอ บนคลาวด์แบบ S3-compatible

Auto-generated APIสร้างตารางเสร็จ ระบบแปลงเป็น API ให้อัตโนมัติ ไม่ต้องเขียนเอง

Realtimeส่งข้อมูลอัปเดตถึงหน้าจอทันทีผ่าน WebSocket เหมาะกับแชท กระดานร่วมงาน การแจ้งเตือน

ฐานข้อมูลเบื้องต้น Table = แผ่นงาน Excel 1 หน้า · Row = 1 บรรทัด คือผู้ใช้ 1 คน · Column = หัวตาราง เช่น ชื่อ อีเมล

Row Level Security
เรื่องสำคัญที่สุดในคอร์สนี้

กฎความปลอดภัยที่ทำงานอยู่ในตัวฐานข้อมูลเอง คอยเติมเงื่อนไขเข้าไปในทุกคำสั่งอ่านข้อมูลอัตโนมัติ เพื่อกรองให้เห็นเฉพาะแถวที่ผู้ใช้คนนั้นมีสิทธิ์

ทุกโปรเจ็ค Supabase มีช่องทาง API เปิดสู่อินเทอร์เน็ตเสมอ ถ้าสร้างตารางแล้วไม่เปิด RLS ข้อมูลในตารางนั้นเปิดให้ทั้งอินเทอร์เน็ตทันที

การเขียนโค้ดกรองที่หน้าจอไม่ช่วย เพราะคนร้ายยิงตรงเข้า API ได้เลยโดยไม่ผ่านหน้าเว็บของคุณ

งานของคุณไม่ใช่เขียนกฎ แต่คืออ่านกฎ เครื่องมือ AI รุ่นใหม่มักเปิด RLS และเขียน policy มาให้เองแล้ว สิ่งที่ต้องตรวจคือกฎนั้นกรองถูกคนหรือเปล่า เพราะสองแบบข้างขวานี้ Dashboard ขึ้นเขียวเหมือนกันทั้งคู่

-- แบบที่ AI เขียนให้บ่อย เปิด RLS จริง แต่ไม่กรอง
create policy "Enable read for authenticated"
on projects for select
to authenticated
using ( true );   -- ล็อกอินแล้วเห็นทุกแถว

-- แบบที่ต้องการจริง เห็นเฉพาะของตัวเอง
using ( user_id = auth.uid() );

ต่างกันบรรทัดเดียว บรรทัดล่างสั่งว่าให้ส่งกลับเฉพาะแถวที่คอลัมน์ user_id ตรงกับรหัสของคนที่ล็อกอินอยู่ ถ้าเห็นคำว่า true ตรงนี้ ให้สั่ง AI แก้ทันที

สองคีย์ที่ต้องแยกให้ออก

คีย์	ใส่ในโค้ดหน้าบ้านได้ไหม	ทำอะไรได้
`sb_publishable_…` โปรเจ็คเก่าเรียก `anon key`	ได้	ทำงานภายใต้กฎ RLS เสมอ ปลอดภัยก็ต่อเมื่อคุณตั้ง RLS ไว้ดีแล้วเท่านั้น
`sb_secret_…` โปรเจ็คเก่าเรียก `service_role key`	ห้ามเด็ดขาด	ข้ามกฎ RLS ทั้งหมด ใช้ได้เฉพาะฝั่งเซิร์ฟเวอร์

ถ้า service_role key หลุดไปอยู่ในโค้ดหน้าบ้าน ใครก็ตามที่เปิดดูซอร์สโค้ดหน้าเว็บจะขโมยคีย์ไปอ่านหรือลบข้อมูลทั้งหมดได้

RLS ทำหน้าที่แยกข้อมูลระหว่างผู้ใช้ แยกข้อมูลระหว่างองค์กร คุมสิทธิ์อ่านเขียนตามบทบาท

โค้ดแอปทำหน้าที่เปิดปิดฟีเจอร์ จำกัดจำนวนครั้ง ขั้นตอนอนุมัติที่ซับซ้อน สิ่งที่ SQL เขียนไม่สวย

ชื่อคีย์กำลังเปลี่ยน — Supabase ประกาศเลิกใช้ชื่อ anon กับ service_role ภายในสิ้นปี 2026 ระหว่างนี้ทั้งสองชุดใช้งานพร้อมกันได้ โปรเจ็คใหม่จะเห็นชื่อขึ้นต้นด้วย sb_ หลักการแบ่งฝั่งยังเหมือนเดิมทุกอย่าง

สี่เรื่องที่ควรรู้ตั้งแต่วันแรก

ไม่ใช่เหตุผลให้เลี่ยง Supabase ยังเป็นตัวที่ควรเริ่มสำหรับงานเกือบทั้งหมดในเล่มนี้ แต่รู้ไว้ก่อนแล้วจะไม่ตกใจตอนเจอ

1โปรเจ็คฟรีถูกพักถ้าไม่มีใครใช้ครบ 7 วัน กดปลุกคืนได้เอง งานที่เปิดให้คนใช้จริงค่อยขยับเป็นแพ็กเกจเสียเงิน

2ค่าใช้จ่ายพุ่งจากสองทาง ส่งข้อมูลออกเยอะ กับเก็บไฟล์สื่อขนาดใหญ่ เปิด Spend Cap ไว้ตั้งแต่วันแรกกันบิลบานปลาย

3งานซับซ้อนต้องอ่าน SQL ออก AI เขียนได้ระดับพื้นฐาน ให้มันอธิบายทีละบรรทัดก่อนกดรันทุกครั้ง

4ไม่มีสถิติพฤติกรรมผู้ใช้ในตัว อยากรู้ว่าคนใช้ฟีเจอร์ไหนบ่อย ค่อยต่อบริการภายนอกทีหลังได้ ไม่ต้องตัดสินใจตอนนี้

เคสจริงที่ข้อมูลรั่ว ผู้สร้างแอปสาย vibe code สั่ง AI สร้างตารางหลายสิบตาราง เว็บใช้งานได้ ล็อกอินได้ปกติ

แต่มีตารางที่ RLS ไม่ได้เปิด เครื่องมือยุคนี้เติมให้เองเป็นส่วนใหญ่แล้ว ที่ยังหลุดคือตารางที่เพิ่มทีหลังคนละรอบ ตารางเชื่อมความสัมพันธ์ และ bucket ใน Storage ซึ่งมี policy คนละชุด

ผลคือบอทสแกนช่องโหว่ยิงตรงเข้า API ดึงข้อมูลส่วนตัว ข้อมูลการเงิน และไฟล์ที่อัปโหลดออกไปได้ด้วยคำสั่งเดียว

การป้องกันใช้เวลาไม่ถึงนาทีต่อหนึ่งตาราง เทียบกับความเสียหายแล้วถูกที่สุดในเล่มนี้

บทที่ 4

หน้าตาเว็บ และการขึ้นออนไลน์

จากโค้ดในเครื่อง ถึงเว็บที่คนอื่นเปิดได้ พร้อมเรื่องที่ต้องเข้าใจก่อนกดขึ้นจริง ทั้งค่าบริการที่คิดตามการใช้งาน และคีย์ที่เผลอส่งไปอยู่หน้าบ้าน

shadcn/ui serverless Preview Deployment NEXT_PUBLIC_ ต่อโดเมนของตัวเอง

shadcn/ui ไม่ใช่ library แต่เป็นโค้ดของคุณ

หัวข้อ	component library ทั่วไป	shadcn/ui
โค้ดอยู่ที่ไหน	ใน `node_modules` นอกโปรเจ็ค	ใน `components/ui/` ของเราเอง
แก้ไส้ในได้ไหม	ไม่ได้	ได้ทั้งหมด
มีโค้ดที่มองไม่เห็นไหม	มี	ไม่มี
อัปเกรดเวอร์ชัน	รันคำสั่งอัปเดต ง่าย	รันคำสั่งเขียนทับไฟล์ อาจทับส่วนที่เราแก้ไว้

ความสัมพันธ์กับ Tailwind CSSshadcn/ui ใช้คลาสของ Tailwind กำหนดรูปลักษณ์ทั้งหมด ใน Tailwind v4 คุมโทนสีผ่าน CSS variables ในไฟล์สไตล์หลักได้เลย ไม่ต้องมีไฟล์ config แยก

ทำไม AI ทุกตัวเจนเป็น shadcn/uiโค้ด component เป็นไฟล์ปกติในโปรเจ็ค AI จึงอ่านและแก้ได้ทันทีเมื่อสั่งผ่านแชท ต่างจาก library ภายนอกที่ AI แตะไม่ได้ · โค้ดสะอาดคาดเดาได้ ผิดพลาดน้อย · ได้มาตรฐาน accessibility มาตั้งแต่ต้น

Serverless ไม่ได้แปลว่าไม่มีเซิร์ฟเวอร์

แปลว่าไม่ใช่เซิร์ฟเวอร์ของคุณ เครื่องยังมีอยู่ แต่คนอื่นเปิดปิดและดูแลให้ คุณจ่ายเฉพาะวินาทีที่โค้ดทำงานจริง

หัวข้อ	เช่าเซิร์ฟเวอร์แบบเดิม	Serverless
เปิดทิ้งไว้ไหม	เปิดตลอด 24 ชั่วโมง	ตื่นตอนมีคนเรียก แล้วดับ
คิดเงินยังไง	รายเดือน ใช้หรือไม่ใช้ก็จ่าย	ตามจำนวนครั้งและเวลาที่รัน
คนเข้าพุ่งกะทันหัน	ต้องสั่งเพิ่มเครื่องเอง	เพิ่มให้เองอัตโนมัติ
ใครอัปเดตความปลอดภัย	คุณ	ผู้ให้บริการ

ความหมายกับกระเป๋าเงินคุณเว็บที่ยังไม่มีคนใช้ ค่าใช้จ่ายเข้าใกล้ศูนย์ ไม่ต้องจ่ายค่าเครื่องเปล่ารอลูกค้า เหมาะกับการลองไอเดียที่สุด

Cold start คืออะไรคำขอแรกหลังไม่มีใครเรียกนาน ๆ จะช้ากว่าปกติเล็กน้อย เพราะระบบต้องปลุกเครื่องขึ้นมาก่อน คำขอถัดไปเร็วตามปกติ

ข้อจำกัดที่ต้องรู้มีเพดานเวลาต่อการเรียกหนึ่งครั้ง งานที่รันยาวเช่นตัดต่อวิดีโอหรือประมวลผลไฟล์ใหญ่ ต้องแยกไปทำที่อื่น · เก็บข้อมูลค้างในตัวเองไม่ได้ ทุกอย่างต้องเข้าฐานข้อมูล

คนใช้เยอะเกินคาดก็จ่ายเยอะเกินคาดได้ ตั้งเพดานค่าใช้จ่ายกับการแจ้งเตือนตั้งแต่วันแรก แต่ดูให้ดีว่าแพ็กเกจที่ใช้อยู่ตั้งได้จริง แพ็กเกจฟรีของหลายเจ้าไม่มีให้ตั้ง ใช้วิธีหยุดให้บริการเมื่อเกินโควตาแทน

จาก push โค้ด ถึงเว็บออนไลน์ ใน 90 วินาที

หน้าที่เนื้อหาคงที่ไปเก็บใน CDN เครือข่ายกระจายไฟล์ทั่วโลก เปิดได้ทันที

หน้าที่ดึงข้อมูลสดไปรันเป็น Serverless Function ทำงานเฉพาะตอนถูกเรียก ไม่ต้องเปิดเซิร์ฟเวอร์ทิ้งไว้

ย้อนกลับได้ทันทีRollback กดกลับไปเวอร์ชันที่เคยสำเร็จได้ตลอด

ขึ้น Build Failed ทำยังไง — ขั้นที่ 03 คือ npm run build ตัวเดียวกับที่รันในเครื่องได้ เปิดแท็บ Deployments กดรอบที่แดง เลื่อนหาบรรทัดแรกที่ขึ้นคำว่า Error คัดตั้งแต่บรรทัดนั้นลงไปสักสิบบรรทัดส่งให้ AI ทั้งก้อน อย่าเล่าด้วยคำพูดตัวเอง เว็บเดิมยังออนไลน์ปกติ รอบที่ build ไม่ผ่านจะไม่ถูกนำขึ้นแทน

เรื่องที่คนพลาดกันมาก — แพ็กเกจฟรีของ Vercel อนุญาตเฉพาะงานส่วนตัวที่ไม่หารายได้ ถ้าเว็บมีการขายของ รับเงิน หรือทำให้ธุรกิจ ต้องขยับเป็นแพ็กเกจเสียเงินตั้งแต่ต้น ไม่ใช่รอให้คนใช้เยอะก่อน

Preview Deployment
เว็บทดสอบที่ไม่ทำของจริงพัง

ทุกครั้งที่แก้โค้ดในสาขาอื่นหรือเปิด pull request Vercel สร้างเว็บจำลองพร้อม URL เฉพาะขึ้นมาแยกจากเว็บจริง

ไม่กระทบเว็บจริงทดสอบดีไซน์ ปุ่ม และระบบบนออนไลน์จริงได้ โดยเว็บที่ลูกค้าใช้อยู่ไม่พัง

สื่อสารตรงจุดVercel Toolbar ให้ลูกค้าและทีมพิมพ์ความเห็นลงบนจุดที่มีปัญหาได้ทันทีบนหน้าจอนั้น ไม่ต้องนัดประชุม

จับบั๊กที่การอ่านโค้ดจับไม่ได้การกดใช้จริงบน preview URL เจอปัญหาด้านภาพและการโต้ตอบที่ code review มองข้าม

ประเภท	เกิดเมื่อไหร่
Production deployment	push เข้าสาขาหลัก
Preview deployment	push เข้าสาขาอื่นหรือเปิด pull request
Rollback	กดย้อนกลับเมื่อไหร่ก็ได้

กฎเหล็กของ `NEXT_PUBLIC_`

ตัวแปรที่ขึ้นต้นด้วยคำนี้จะถูกฝังลงในโค้ดที่ส่งไปรันบนเบราว์เซอร์ ใครเปิดดูซอร์สหน้าเว็บก็เห็น

ใส่ได้รหัสระบบวัดสถิติผู้ใช้ · URL ของบริการภายนอกที่เปิดเผยอยู่แล้ว

ห้ามใส่เด็ดขาดคีย์ฐานข้อมูล · คีย์ฝั่งเซิร์ฟเวอร์ของ Supabase ที่ขึ้นต้นด้วย sb_secret_ หรือชื่อเดิม service_role · คีย์ระบบชำระเงิน · รหัสผู้ดูแลระบบ

Environment	ใช้กับอะไร
Production	ฐานข้อมูลจริง คีย์จริง
Preview	ฐานข้อมูลทดสอบ คีย์ทดสอบ
Development	เครื่องตัวเอง

ข้อผิดพลาดที่พบบ่อย — commit คีย์จริงลง GitHub แทนที่จะตั้งใน Vercel · ใช้ค่าตัวแปรชุดเดียวกันทั้ง Production กับ Preview จนข้อมูลทดสอบหลุดไปอยู่ในเว็บจริง · แก้ค่าตัวแปรใน Vercel แล้วคิดว่าเว็บเปลี่ยนตามทันที ต้องสั่ง deploy ใหม่อีกรอบเสมอ

ต่อโดเมนของตัวเอง

ประเภทโดเมน	ตัวอย่าง	ตั้ง DNS แบบไหน
Apex domain ไม่มี www	`myweb.com`	A record ชี้ไปที่หมายเลขที่ Vercel แสดง
Subdomain มีส่วนขยายหน้า	`www.myweb.com`	CNAME record ชี้ไปที่ค่าเฉพาะของโปรเจ็คคุณ

ตั้งค่าเสร็จ Vercel ออกใบรับรอง SSL ให้อัตโนมัติ เว็บใช้ https:// ได้ทันที ไม่มีค่าใช้จ่ายเพิ่ม

บทที่ 5

เลือก stack ให้ตรงงาน

เครื่องมือ AI แต่ละกลุ่มเหมาะกับคนละงาน และลำดับการสร้างที่ผิดทำให้ต้องรื้อทีหลัง บทนี้รวมสิ่งที่ควรตัดสินใจให้จบก่อนพิมพ์พรอมป์ตแรก

เลือกเครื่องมือให้ตรงงาน โปรเจ็คนี้ต้องใช้กี่ชิ้น ลำดับการสร้างจริง สี่ช่องโหว่ที่ AI ทำบ่อย

เลือกเครื่องมือ AI ให้ตรงกับคนใช้และขนาดงาน

เครื่องมือทุกตัวสร้างแอปได้เหมือนกัน สิ่งที่ต่างคือคุณต้องรู้เรื่องเทคนิคแค่ไหน และงานจะโตไปถึงระดับไหน

โปรเจ็คของคุณ ต้องใช้กี่ชิ้น

ประเภทโปรเจ็ค	Next.js	Supabase	shadcn/ui	Vercel	ต้องเพิ่มอะไร
Landing page แนะนำสินค้า	ใช่	ไม่	ใช่	ใช่	ไม่มี ยกเว้นมีฟอร์มติดต่อ
เว็บที่มีระบบสมาชิก	ใช่	ใช่	ใช่	ใช่	ไม่มี ใช้ของ Supabase ครบ
ร้านค้าออนไลน์	ใช่	ใช่	ใช่	ใช่	ระบบชำระเงิน เช่น Stripe
Dashboard ภายในองค์กร	ใช่	ใช่	ใช่	ใช่	SSO ลงชื่อเข้าใช้ด้วยบัญชีองค์กร และ audit log
แอปมือถือ	ไม่	ใช่	ไม่	ไม่	React Native และ Expo
เครื่องมือ AI	ใช่	ใช่	ใช่	ใช่	LLM API และ pgvector

เครื่องมือ AI ที่คุณใช้อยู่ เจนโค้ดออกมาแบบไหน

เครื่องมือ	กลุ่ม	Stack ที่ได้	เหมาะกับใคร	ข้อจำกัด	เริ่มต้น/เดือน
Lovable	Prompt-to-App	React + Supabase	เขียนโค้ดไม่เป็นเลย	ล็อกกับ React ไม่ทำแอปมือถือ	$25
Bolt.new	Prompt-to-App	Next.js, Vue, Svelte, Expo	อยากลองไอเดียให้เห็นผลเร็ว	โปรเจ็คโตแล้วโค้ดเริ่มสับสน	$25
v0	Prompt-to-App	Next.js + shadcn/ui	เน้นงานหน้าจอเป็นหลัก	ผูกกับระบบนิเวศของ Vercel	$20
Cursor	AI IDE	ทุกภาษา	มีพื้นฐาน อยากเห็นไฟล์	ต้องลงโปรแกรม ไม่มีโฮสติ้ง	$20
Claude Code · Codex	Terminal Agent	ทุกภาษา	โปรเจ็คระยะยาว แก้ข้ามไฟล์	สั่งด้วยการพิมพ์ ไม่มีหน้าจอไล่ไฟล์	$20 ขึ้นไป

เขียนโค้ดไม่เป็นเลยLovable หรือ Bolt.new

อยากได้หน้าจอสวยส่งต่อทีมv0

มีพื้นฐาน ทำโปรเจ็คระยะยาวCursor, Claude Code หรือ Codex

คุณอยู่ระดับไหน

หกระดับของการใช้ AI เขียนโค้ด เรียงตามว่าใครถือพวงมาลัย

ระดับ	ชื่อ	รูปแบบ	เครื่องมือตัวอย่าง
0	เขียนเองล้วน	มนุษย์พิมพ์ทุกบรรทัด	ไม่มี
1	AI ช่วยเติมประโยค	คนเขียนหลัก AI แนะนำคำสั่งถัดไป	GitHub Copilot
2	สั่งเจนทีละชิ้นส่วน	สั่งทำหน้าจอหรือ component เฉพาะจุด	v0
3	สั่งสร้างแอปทั้งตัวจากแชท	AI ทำทั้งหน้าบ้านและตั้งฐานข้อมูลให้	Lovable, Bolt.new
4	สั่งแก้ข้ามไฟล์ทั้งโปรเจ็ค	AI อ่านทั้งโปรเจ็ค รันโค้ด รันเทสต์ แก้เอง	Cursor, Claude Code
5	เอเจนต์ทำงานอัตโนมัติ	หลายเอเจนต์วางแผน เขียน ตรวจความปลอดภัย ขึ้นระบบเอง	ระบบ multi-agent

คนในห้องนี้ส่วนใหญ่อยู่ ระดับ 2–3 เป้าหมายของคอร์สนี้คือทำให้คุณขยับไป ระดับ 4 ได้อย่างเข้าใจ ไม่ใช่แค่กดตาม

ลำดับการสร้างโปรเจ็คจริง

1เขียนความต้องการเป็นภาษาปกติให้ละเอียด ระบุขอบเขตชัดว่าต้องการอะไร ไม่ต้องการอะไร

2ให้ AI ทำหน้าตาก่อน ปุ่ม เมนู ฟอร์ม โทนสี เพื่อเห็นภาพรวมแอป

3ออกแบบตารางข้อมูลใน Supabase พร้อมกำหนดว่าแถวไหนเป็นของผู้ใช้คนไหน

4ทำระบบล็อกอิน แล้วเปิด RLS ทันที อย่าเลื่อนไปทำทีหลัง

5ย้ายคีย์ลับทั้งหมดไปเก็บใน Vercel แยกค่าระหว่าง Production กับ Preview

6push ขึ้น GitHub เชื่อมกับ Vercel แล้วต่อโดเมนของตัวเอง

สี่ช่องโหว่ที่ AI
สร้างให้บ่อยที่สุด

1RLS ไม่ครบทุกที่ เปิดให้ตอนวางโครงรอบแรก แต่ตารางที่เพิ่มทีหลังและ bucket ใน Storage มักหลุด

2คีย์ฝั่งเซิร์ฟเวอร์หลุดไปหน้าบ้าน คีย์ sb_secret_ ข้าม RLS ทุกข้อ หลุดเมื่อไหร่ข้อมูลทั้งหมดเสีย

3policy หลวมเกินไป AI ชอบเขียนว่า “ถ้าล็อกอินแล้วเข้าถึงได้ทุกแถว” แทนที่จะเป็น “เห็นเฉพาะข้อมูลตัวเอง”

4คีย์ลับพิมพ์ค้างในโค้ด รั่วทันทีที่ push ขึ้น GitHub

Checklist ก่อนเปิดให้คนใช้จริง

เปิด RLS ครบทุกตาราง — ALTER TABLE … ENABLE ROW LEVEL SECURITY;

คีย์ sb_secret_ หรือชื่อเดิม service_role อยู่ฝั่งเซิร์ฟเวอร์เท่านั้น

policy เขียนแบบ auth.uid() = user_id และฝั่งเขียนข้อมูลใส่ WITH CHECK เสมอ

คีย์ลับทั้งหมดอยู่ในหน้าตั้งค่าของ Vercel ไม่ใช่ในไฟล์โค้ด

สร้าง index ให้คอลัมน์ที่ใช้ตรวจสิทธิ์ เช่น user_id กันระบบช้าเมื่อข้อมูลโต

ทดสอบด้วยการสวมบทบาทผู้ใช้คนอื่น ตรวจว่าดึงข้อมูลข้ามบัญชีไม่ได้จริง

บทที่ 6

Git และการเก็บงาน

ระบบที่ทำให้ย้อนกลับได้เมื่อ AI แก้จนพัง และเป็นทางเดียวที่โค้ดจะขึ้นเว็บจริงได้ ไม่ใช่เรื่องของทีมใหญ่เท่านั้น คนทำคนเดียวยิ่งต้องมี

commit และ push branch กับ checkout Pull Request .gitignore ตอนพัง ย้อนยังไง

โค้ดหนึ่งไฟล์ อยู่ได้สี่ที่พร้อมกัน

ความสับสนเรื่อง Git เกือบทั้งหมด มาจากไม่รู้ว่างานอยู่ตรงไหน คำสั่งทุกตัวคือการย้ายงานจากที่หนึ่งไปอีกที่

Git คือปุ่ม undo ของทั้งโปรเจ็คไม่ใช่แค่ย้อนไฟล์เดียว แต่ย้อนสภาพทั้งโฟลเดอร์กลับไปวันไหนก็ได้ที่เคยบันทึกไว้

GitHub ไม่ใช่ GitGit คือโปรแกรมที่ทำงานในเครื่องคุณ GitHub คือเว็บที่รับฝากสำเนา ใช้ Git โดยไม่มี GitHub ก็ได้

ทำไมคนใช้ AI ต้องรู้AI แก้ทีละหลายสิบไฟล์ ถ้าไม่ commit ไว้ก่อน คุณจะไม่รู้ว่ามันเปลี่ยนอะไร และย้อนกลับไม่ได้

วงจรที่ทำซ้ำทุกวัน

สี่คำสั่งนี้ครอบคลุมงานราว 90% ของการใช้ Git ในชีวิตจริง

1pull ก่อนเริ่มงานเสมอ ดึงของใหม่ที่คนอื่นหรือเครื่องอื่นทำไว้ลงมาก่อน กันแก้ทับกัน

2แก้งาน เขียนเอง หรือให้ AI เขียนก็ได้ ทำจนจบหนึ่งเรื่อง

3add แล้ว commit เลือกว่าจะบันทึกอะไร แล้วเขียนข้อความว่าทำอะไรไป

4push ส่งขึ้น GitHub ตอนนี้งานถึงจะปลอดภัยจากเครื่องพัง

# ดึงของใหม่ลงมาก่อนเริ่มงาน
git pull

# ดูว่าตอนนี้แก้อะไรไปบ้าง
git status

# เลือกไฟล์เข้ากองรอบันทึก จุดคือทุกไฟล์
git add .

# บันทึกพร้อมข้อความ
git commit -m "เพิ่มหน้าล็อกอินด้วย Supabase"

# ส่งขึ้น GitHub
git push

ข้อความ commit เขียนว่าทำอะไร ไม่ใช่แก้ไฟล์ไหน เขียนว่า "แก้ bug ตะกร้าสินค้าคำนวณราคาผิด" ไม่ใช่ "update files" เพราะสามเดือนหลังจากนี้คุณจะอ่านมันเพื่อหาจุดที่พัง

branch คือเลนทดลอง ที่ไม่กระทบของจริง

แยกเลนออกไปลองของใหม่ ถ้าเวิร์กก็รวมกลับ ถ้าไม่เวิร์กก็ลบทิ้ง ของบน main ไม่เคยพัง

สองคำสั่งที่ใช้จริงgit checkout -b feat/login แตกเลนใหม่แล้วย้ายไปอยู่บนนั้นทันที · git checkout main ย้ายกลับมาเลนหลัก

ตั้งชื่อให้อ่านออกใช้ feat/ สำหรับของใหม่ fix/ สำหรับแก้ bug ตามด้วยชื่อสิ่งที่ทำ เช่น fix/checkout-total

merge แล้วลบทิ้งbranch ที่รวมกลับ main แล้วไม่มีประโยชน์อีก ลบทิ้งเลย ประวัติ commit ยังอยู่ครบไม่หายไปไหน

Pull Request คือจุดตรวจ
ไม่ใช่พิธีกรรมของทีมใหญ่

PR คือการยื่นเรื่องขอรวม branch ของคุณเข้า main คนทำงานคนเดียวก็ควรเปิด เพราะสิ่งที่ได้ไม่ใช่การรีวิวจากเพื่อนร่วมงาน

1เห็นทุกบรรทัดที่เปลี่ยน โดยเฉพาะตอน AI แก้ให้ 40 ไฟล์รวด PR คือที่เดียวที่คุณจะอ่านมันได้ครบก่อนของขึ้นจริง

2Vercel สร้างเว็บทดลองให้อัตโนมัติ ทุก PR ได้ลิงก์ของตัวเอง กดทดสอบได้เหมือนของจริง แต่ไม่กระทบผู้ใช้

3ระบบตรวจให้ก่อน merge ถ้าโค้ดพังจนสร้างเว็บไม่ขึ้น PR จะขึ้นสีแดง ก่อนที่ลูกค้าจะเป็นคนเจอ

เชื่อมกับบทที่ 4Vercel preview deployment ที่เราพูดถึงตอนต้น เกิดขึ้นจากการเปิด PR นี่เอง ไม่ต้องตั้งค่าอะไรเพิ่ม แค่เชื่อม repo ครั้งเดียว

ลำดับที่เกิดขึ้นpush branch ขึ้น GitHub · กดปุ่ม Compare & pull request · Vercel เด้งลิงก์ทดสอบมาในหน้า PR · กดทดสอบ · กด Merge

ยังไม่พร้อมรวมเปิดเป็น Draft pull request ได้ ยังไม่ให้ใครกด merge แต่ได้ลิงก์ทดสอบมาแล้ว

.gitignore คือด่านกันคีย์ลับหลุด

ไฟล์ชื่อ .gitignore บอก Git ว่าอะไรห้ามเก็บ ห้ามส่งขึ้นคลาวด์ ทุกโปรเจ็คต้องมี

# คีย์ลับทั้งหมด ห้ามขึ้น GitHub เด็ดขาด
.env
.env.local

# โฟลเดอร์ที่สร้างใหม่ได้เสมอ ไม่ต้องเก็บ
node_modules/
.next/
dist/
.DS_Store

ใส่ .gitignore ก่อน commit แรกเสมอ เพราะ .gitignore กันได้แค่ไฟล์ที่ยังไม่เคยถูกเก็บ ไฟล์ที่ commit ไปแล้วต้องสั่งเอาออกจากประวัติต่างหาก

ถ้าคีย์หลุดขึ้น GitHub ไปแล้ว

ลบไฟล์แล้ว commit ใหม่ ไม่พอ เพราะคีย์ยังอยู่ในประวัติ ทำสามข้อนี้ตามลำดับ

1ยกเลิกคีย์เดิมทันที เข้าหน้าตั้งค่าของ Supabase กด revoke หรือ regenerate ข้อนี้ต้องทำก่อนเสมอ

2สร้างคีย์ใหม่ วางในหน้าตั้งค่าของ Vercel ไม่ใช่ในไฟล์โค้ด

3เพิ่มเข้า .gitignore แล้วค่อยลบไฟล์ออกจาก repo

ทำไมต้องยกเลิกก่อนrepo สาธารณะถูกบอตกวาดหาคีย์ตลอดเวลา นับเป็นนาทีไม่ใช่วัน ตราบใดที่คีย์เดิมยังใช้ได้ ความเสียหายยังเกิดต่อ ต่อให้ลบไฟล์แล้ว

merge conflict ไม่ใช่ error
แต่เป็นคำถาม

เกิดเมื่อสองฝั่งแก้บรรทัดเดียวกันคนละแบบ Git ตัดสินใจแทนไม่ได้ จึงหยุดแล้วถามคุณว่าจะเอาอันไหน

<<<<<<< HEAD
<h1>ยินดีต้อนรับ</h1>      // ของในเครื่องคุณ
=======
<h1>สวัสดีครับ</h1>        // ของที่ดึงมาจากคลาวด์
>>>>>>> main

อ่านสามบรรทัดนี้ให้ออก บนคือของคุณ ล่างคือของคนอื่น เส้นคั่นตรงกลางคือรอยต่อ ไม่มีอะไรพัง ยังไม่มีอะไรหาย

แก้ยังไง

1เลือกว่าจะเอาอะไร ของคุณ ของเขา หรือผสมกันเองแบบใหม่ก็ได้

2ลบเครื่องหมายทิ้งให้หมด ทั้งสามบรรทัดที่ขึ้นต้นด้วย <<< === >>> ต้องไม่เหลือในไฟล์

3เซฟ แล้ว add กับ commit เหมือนการแก้งานปกติ จบ

ให้ AI ช่วยได้วางทั้งก้อนให้ AI ดูแล้วบอกว่าต้องการผลลัพธ์แบบไหน แต่คุณต้องอ่านผลก่อนรับ เพราะ AI ไม่รู้ว่าธุรกิจคุณอยากได้อันไหน

ป้องกันไว้ดีกว่าconflict เกิดน้อยลงมากถ้า pull บ่อย commit ทีละเรื่องเล็ก ๆ และไม่ปล่อย branch ค้างไว้เป็นสัปดาห์

ตอนพัง ย้อนกลับยังไง

นี่คือเหตุผลที่แท้จริงที่คุณต้องใช้ Git จำสองตัวพอ ตัวหนึ่งปลอดภัยเสมอ อีกตัวลบงานถาวร

คำสั่ง	ทำอะไร	ใช้ตอนไหน	ปลอดภัยไหม
`git revert`	สร้าง commit ใหม่ที่ย้อนผลของ commit เก่า ประวัติเดิมยังอยู่ครบ	ของขึ้น production แล้วพัง ต้องย้อนด่วน หรือ push ไปแล้ว	ปลอดภัยเสมอ ใช้ตัวนี้เป็นหลัก
`git stash`	เก็บงานที่ค้างอยู่พักไว้ในลิ้นชัก โฟลเดอร์กลับไปสะอาด	ทำอยู่ครึ่งทางแล้วต้องรีบไปแก้ bug ด่วนที่ branch อื่น	ปลอดภัย เรียกคืนด้วย `git stash pop`
`git reset --hard`	ย้อนสภาพกลับไปจุดเดิม ทิ้งงานที่ยังไม่ commit ทั้งหมด	AI แก้จนพังเละ ยังไม่ได้ commit อยากล้างกลับจุดสะอาด	ลบถาวร เอาคืนไม่ได้
`git checkout .`	ทิ้งการแก้ในไฟล์ทั้งหมด กลับไปเท่า commit ล่าสุด	ลองอะไรไปแล้วไม่เอา อยากเริ่มใหม่จากจุดเดิม	ลบถาวร เฉพาะที่ยังไม่ commit

กฎง่าย ๆ ข้อเดียว ถ้า push ขึ้น GitHub ไปแล้ว ใช้ revert เท่านั้น · ถ้ายังอยู่ในเครื่องและแน่ใจว่าไม่เอางานนั้นแล้ว ค่อยใช้ reset --hard ได้ · ไม่แน่ใจเมื่อไหร่ ให้ commit ไว้ก่อน เพราะสิ่งที่ commit แล้วเอากลับมาได้เกือบเสมอ

บทที่ 7

Superpowers

ชุดวิธีทำงานที่บังคับให้ AI คิดให้จบ เขียนแผน แล้วค่อยลงมือ ช้าลงในหนึ่งฟีเจอร์ แลกกับการไม่ต้องรื้อทั้งโปรเจ็คตอนสัปดาห์ที่สาม

The Basic Workflow worktree test-driven development requesting code review ติดตั้ง

AI เขียนโค้ดเร็วมาก
แต่ไม่มีระเบียบให้ตัวเอง

สามวันแรกงานเดินฉิว พอโปรเจ็คโตขึ้นกลับช้าลงเรื่อย ๆ จนแก้อะไรก็พังอย่างอื่น สาเหตุไม่ได้อยู่ที่ AI เก่งไม่พอ

1ลงมือทันทีโดยไม่ถาม เดาสิ่งที่คุณต้องการแล้วเขียนไปเลย ผิดตั้งแต่โจทย์ก็แก้กันยาว

2ทำทีละงานใหญ่เกินไป แก้ 30 ไฟล์รวดเดียว พอพังก็หาไม่เจอว่าพังตรงไหน

3บอกว่าเสร็จแล้วทั้งที่ยังไม่ได้ลอง เพราะไม่มีเกณฑ์วัดว่าอะไรคือเสร็จ

4ไม่มีใครตรวจงาน คุณอ่านโค้ดไม่ออก และ AI ก็ไม่ได้ย้อนกลับมาตรวจของตัวเอง

Superpowers คือระเบียบที่ใส่เข้าไปชุดกติกาที่ติดตั้งเพิ่มให้ AI แล้วมันจะบังคับตัวเองให้ถามก่อนทำ แตกงานเป็นชิ้นเล็ก เขียนเกณฑ์วัดก่อนลงมือ และตรวจงานตัวเองก่อนส่ง

ไม่ใช่เครื่องมือใหม่ที่ต้องเรียนติดตั้งครั้งเดียวแล้วสั่งงานเหมือนเดิมทุกอย่าง สิ่งที่เปลี่ยนคือพฤติกรรมของ AI ไม่ใช่วิธีพิมพ์ของคุณ

ของฟรี เปิดโค้ดสร้างโดย Jesse Vincent เผยแพร่บน GitHub ที่ obra/superpowers ใช้ได้ทั้ง Claude Code และ Codex

The Basic Workflow · เจ็ดขั้นที่วนซ้ำทุกฟีเจอร์

AI จะหยิบขั้นที่ตรงกับสถานการณ์มาใช้เอง คุณไม่ต้องสั่งทีละขั้น หน้าที่คุณคือรู้ว่าตอนนี้อยู่ขั้นไหน และตอบคำถามที่มันถาม

ขั้น 01 – 03 คิดให้จบก่อนแตะโค้ด

สองในสามของขั้นตอนทั้งหมด เกิดขึ้นก่อนที่โค้ดบรรทัดแรกจะถูกเขียน นี่คือส่วนที่ทำให้ผลลัพธ์ต่างจากการสั่งลอย ๆ

1brainstorming AI ถามกลับก่อนแทนที่จะเดา ยิงคำถามทีละชุด เสนอทางเลือกให้เทียบ แล้วสรุปเป็นเอกสารออกแบบให้คุณกดอนุมัติ

2using-git-worktrees แยกพื้นที่ทำงานออกไปบน branch ใหม่ แล้วรันเทสต์เดิมให้ผ่านก่อนเริ่ม เพื่อยืนยันว่าจุดตั้งต้นสะอาดจริง

3writing-plans แตกงานเป็นชิ้นละ 2 – 5 นาที ระบุชื่อไฟล์และวิธีตรวจว่าชิ้นนั้นเสร็จ ครบทุกชิ้นก่อนลงมือ

ทำไมงานย่อยต้องเล็กระดับ 2 – 5 นาทีงานเล็กพอที่จะตรวจได้ด้วยตาเปล่า และถ้าพังก็รู้ทันทีว่าพังที่ชิ้นไหน ต่างจากการสั่งรวดเดียวแล้วมาไล่หาทีหลัง

คุณยังเป็นคนตัดสินใจทุกขั้นจบด้วยการรอคุณอนุมัติ ไม่ใช่ปล่อยให้ AI เดินเองยาว ๆ แล้วมาดูผลตอนจบ

ตอบคำถามให้สั้นแต่ตรงช่วงถามตอบคือจุดที่คุณมีค่าที่สุด เพราะคุณรู้ว่าธุรกิจต้องการอะไร ส่วน AI รู้แค่ว่าโค้ดเขียนยังไง

worktree คือโต๊ะทำงานตัวที่สอง

บทที่แล้วเราสอนว่า branch คือเลนทดลอง worktree คือการเอาเลนนั้นไปกางเป็นโฟลเดอร์แยกอีกอันบนเครื่อง

branch อย่างเดียวโฟลเดอร์เดียว สลับเลนไปมา ของค้างอยู่ในมือต้อง stash ก่อนทุกครั้ง

branch + worktreeสองโฟลเดอร์แยกกัน เปิดพร้อมกันได้ ของเดิมไม่ต้องเก็บ ไม่ต้องสลับ

ประโยชน์จริงกับคนที่ใช้ AI ปล่อยให้ AI ลุยงานใหญ่ในโฟลเดอร์ที่สอง โดยที่ของเดิมซึ่งใช้งานได้อยู่ ไม่ถูกแตะแม้แต่ไฟล์เดียว พังก็ลบโฟลเดอร์นั้นทิ้ง

# Superpowers สั่งให้เอง ไม่ต้องพิมพ์
git worktree add \
  ../myapp-feat-login \
  -b feat/login

# รันเทสต์เดิมก่อนเริ่ม
# ต้องเขียวก่อน ถึงจะลงมือ
npm test

ลบทิ้งเมื่อจบงานขั้นที่ 07 จะเก็บกวาดโฟลเดอร์นี้ให้เอง หลังคุณเลือกว่าจะ merge หรือทิ้ง

ขั้น 04 – 05 ลงมือแบบมีเกณฑ์วัด

4subagent-driven-development แต่ละงานย่อยส่งให้ผู้ช่วยคนใหม่ที่ไม่รู้เรื่องเก่าเลย ทำเสร็จแล้วมีการตรวจสองรอบ รอบแรกตรวจว่าตรงแผนไหม รอบสองตรวจคุณภาพโค้ด

5test-driven-development เขียนเทสต์ที่ยังไม่ผ่านก่อน ดูให้เห็นกับตาว่ามันแดงจริง แล้วค่อยเขียนโค้ดน้อยที่สุดที่ทำให้เขียว

คุณไม่ต้องเขียนเทสต์เป็น แต่ต้องอ่านผลออกสองอย่างเท่านั้น ผ่านกี่ตัว และตกกี่ตัว ถ้ายังมีตัวแดงแปลว่างานยังไม่เสร็จ ไม่ว่า AI จะบอกว่าอะไร

# รอบแรก ต้องแดงก่อน
✗ login rejects wrong password
  Expected 401, received 200

Tests:  1 failed, 4 passed

# เขียนโค้ดแล้วรันใหม่ ต้องเขียว
✓ login rejects wrong password

Tests:  5 passed, 0 failed

ทำไมต้องดูให้แดงก่อนถ้าเทสต์เขียวตั้งแต่ยังไม่เขียนโค้ด แปลว่าเทสต์นั้นไม่ได้ตรวจอะไรเลย เป็นกับดักที่ AI ตกบ่อยที่สุด

ขั้น 06 – 07 ตรวจแล้วปิดงาน

6requesting-code-review ตรวจงานเทียบกับแผนที่วางไว้ แล้วรายงานปัญหาแยกตามระดับความรุนแรง ปัญหาระดับวิกฤตจะบล็อกไม่ให้ไปงานถัดไป

7finishing-a-development-branch รันเทสต์ทั้งชุดอีกรอบ แล้วยื่นตัวเลือกให้คุณเลือกว่าจะ merge เปิด PR เก็บไว้ก่อน หรือทิ้ง จากนั้นเก็บกวาด worktree ให้

จุดที่เชื่อมกับบทที่ 6ถ้าเลือกเปิด PR ก็เข้าสู่จุดตรวจที่เราสอนไปแล้ว Vercel สร้างลิงก์ทดลองให้อัตโนมัติ คุณกดดูของจริงก่อนตัดสินใจ merge

อ่านรายงานตรวจงานยังไง

ระดับ	แปลว่า	คุณต้องทำอะไร
Critical	ของพัง หรือมีช่องโหว่ความปลอดภัย	หยุด ต้องแก้ก่อนไปต่อเสมอ
Important	ทำงานได้ แต่จะสร้างปัญหาภายหลัง	สั่งแก้ ถ้าไม่รีบส่งงานวันนี้
Minor	เรื่องความเรียบร้อยของโค้ด	ข้ามได้ ไม่ต้องแก้ทุกข้อ

อย่ากลัวรายงานยาวรายงานที่เจอปัญหาเยอะคือระบบทำงานถูกต้อง ไม่ใช่สัญญาณว่างานแย่ ที่น่ากลัวกว่าคือไม่มีใครตรวจเลย

ติดตั้งครั้งเดียว ใช้ได้ทุกโปรเจ็ค

# Claude Code
/plugin install superpowers@claude-plugins-official

# Codex CLI · เปิดหน้าค้นหาปลั๊กอิน
/plugins
# พิมพ์ค้น superpowers แล้วกด Install Plugin

พิมพ์แบบเดิมได้เลย ไม่มีคำสั่งให้ท่องAI จะหยิบ skill ที่ตรงกับสถานการณ์มาใช้เอง ประโยคสั่งงานที่ทำให้มันเข้าโหมดทำงานเป็นระบบ มีแค่แนวนี้

"ช่วย brainstorm ฟีเจอร์ระบบจองคิวก่อน อย่าเพิ่งเขียนโค้ด"
"เขียนแผนงานย่อยจากดีไซน์ที่ตกลงกันไว้"
"ขอ code review ของงานชิ้นนี้เทียบกับแผน"

ใช้ตอนไหน ไม่ใช้ตอนไหน

ใช้ เมื่องานจะมีคนอื่นใช้จริง แตะเงิน หรือแตะข้อมูลลูกค้า

ใช้ เมื่อโปรเจ็คใหญ่จนคุณเริ่มจำไม่ได้ว่าอะไรอยู่ตรงไหน

ไม่ต้องใช้ กับการลองไอเดียเล่น หรือ prototype ที่จะทิ้งภายในวันเดียว

แลกมาด้วยความช้าและโควตาที่กินมากขึ้น เพราะมันบังคับให้ถามก่อนเขียน แตกงานย่อย เขียนเทสต์ และตรวจซ้ำ งานที่เคยเสร็จใน 10 นาทีอาจกลายเป็น 30 นาที สิ่งที่ได้กลับมาคืองานที่ไม่ต้องกลับมารื้อ

คุณไม่ต้องเขียนโค้ดเป็น
แต่ต้องรู้ว่าข้อมูล
เดินทางไปทางไหน

เพราะ AI เขียนโค้ดให้ทำงานสำเร็จ ไม่ได้เขียนให้ปลอดภัย
คนสั่งจึงต้องเป็นคนที่รู้ว่าต้องตรวจอะไร