// happener × it24hrs · one-day course
VIBE CODING
FOR SERIOUS BUILDERS
ก้าวข้าม vibe coding → สร้างแอปแบบมืออาชีพด้วย spec-driven development (agentic engineering)
สำหรับครีเอเตอร์ / คนทำคอนเทนต์ — สร้างเครื่องมือของตัวเองได้ โดยไม่ต้องเป็นโปรแกรมเมอร์
// course
formatone-day · onsite
editioncodex v2.0
projectCollabInbox — deal intake → /inbox
statusพร้อมสอน
// m1 · opening & ai foundations
· 10 min
วันนี้จบแล้วคุณจะได้อะไร
- แอปจริงที่ deploy แล้ว (live URL) — CollabInbox ของคุณ
- Spec (Lite PRD) ของตัวเอง
- GitHub repo ที่คุณเป็นเจ้าของ 100%
Journey วันนี้: Wow → Ouch → Aha → Ship · Ground rules
// m1 · opening & ai foundations
· 25 min
LLM คืออะไร — แบบภาษาคน
- โมเดลที่ “เดาคำถัดไป” จากข้อมูลมหาศาลที่เคยอ่าน
- ไม่ใช่ฐานข้อมูลความจริง — มัน “คาดเดาอย่างมีหลักการ”
// m1 · opening & ai foundations
Token = ชิ้นส่วนย่อยที่ AI หั่นข้อความออกมา (ไม่ใช่ “คำ”)
collab
in
box
“collabinbox” ถูกหั่นเป็น 3 ชิ้น (ไม่ใช่ 1 token)
is
ready
= 5 tokens
กติกาคร่าว ๆ (อังกฤษ): 1 token ≈ 4 ตัวอักษร ≈ ¾ คำ → 4 คำ ≈ 5–6 tokens · คำสั้นที่พบบ่อยมักเป็น 1 token (ชิ้นเขียว = คำแบบนี้ · ชิ้นฟ้า = คำที่ถูกหั่นย่อย)
💰
ภาษาไทยเปลืองกว่า: ข้อความไทยกินโทเคน ~2–4 เท่าของอังกฤษ (ตัวอักษรไทยถูกหั่นละเอียดกว่า + ไม่มีเว้นวรรคระหว่างคำ) — ยิ่งยาว = ยิ่งเปลือง/ช้า
โยงกับ โควตาของ ChatGPT Plus (มีจำกัด) → ทำไมต้องสั่งงานให้กระชับ
// m1 · opening & ai foundations
Context window = ความจำระยะสั้น (ทำไมมัน “ลืม”)
เรื่อง Aหลุดจากความจำ
// กรอบความจำ (จำกัด)
เรื่อง Aเก่าสุด
เรื่อง Bเก่า
เรื่อง C
เรื่อง Dล่าสุด
ข้อความใหม่เพิ่งพิมพ์
“แล้วเรื่อง A ที่คุยกันตอนแรก สรุปว่ายังไงนะ?”
“เรื่อง A สรุปแล้วว่า … (ตอบมั่นใจมาก — แต่ผิด เพราะเรื่อง A ไม่อยู่ในความจำแล้ว)”
// hallucination
คุยยาว ๆ ของเก่าจะ “หลุด” ออกจากกรอบ → AI เลยเหมือนลืม และมั่วแทนที่จะบอกว่าไม่รู้
// m1 · opening & ai foundations
Prompt = คำสั่ง · Hallucination = AI มั่ว
Prompt ที่ดี
ชัด, มี context, บอกผลลัพธ์ที่ต้องการ — “ยิ่งชัด ยิ่งได้ตรง”
⚠️ Hallucination
AI มั่นใจแต่ผิด → ทำไมต้อง verify เสมอ (ปูทางแนวคิด harness)
// m1 · opening & ai foundations
จาก generative AI → agentic AI
Generative
AI “ตอบ/สร้าง” ข้อความ-รูป
Agentic
AI “ลงมือทำงานบนเครื่อง” เอง
ปูทางสู่ Codex: “agent ที่ใช้ code เพื่อทำงานบนเครื่องคุณให้เสร็จ”
// m1 · opening & ai foundations
เส้นทางวันนี้: Wow → Ouch → Aha → Ship
Hook: “vibe coding ฮิตปี 2025 — คนคิดคำนี้ (Karpathy) บอกเองปี 2026 ว่ามัน ‘ตกยุค (passé)’ แล้วชูแนวใหม่ agentic engineering = ทำแบบ spec-driven มีคนกำกับ”
แนะนำ CollabInbox — ลิงก์เดียวให้แบรนด์กรอกดีลเข้ามาเอง → รวมใน /inbox ของคุณ
// m2 · prompt-to-app
สร้างเร็วมากใน 5 นาที…
แล้วพัง
อินเทอร์เน็ตเต็มไปด้วยเครื่องมือ AI + คลิป YouTube สั้น ๆ ที่สอน “vibe coding” ให้ได้แอปสวย ๆ ใน 5 นาที
ทำตามได้จริง — แต่พอแก้/ต่อยอดไปเรื่อย ๆ มันเริ่มเพี้ยนแล้วพัง
สิ่งที่คลิปพวกนั้น ไม่สอน = จะเอาไปใช้จริง/ต่อยอดยังไงไม่ให้พัง → นั่นคือเหตุผลที่คุณมาที่นี่
09:45 – 10:00 · 15 นาที · pain
// m2 · prompt-to-app
กำแพง 4 ด้านที่เจอตอน “มันพัง”
บอกไม่ได้ว่า “เสร็จจริงไหม”
ไม่ได้เป็นเจ้าของ/ไม่เข้าใจ code
กำแพงไม่ได้อยู่ที่ “ยี่ห้อ tool” — อยู่ที่ วิธีทำ · “มันรันได้” ≠ “เสร็จถูกต้องแล้ว”
สิ่งที่ขาด = Spec (แบบแปลน) + Verify (harness) → พระเอกของ M3
// m3 · เข้าใจก่อนสร้าง
Spec & harness —
พระเอกของวันนี้
กำแพง 4 ด้านจาก M2 ไม่ใช่ความผิดของ tool แต่มีสาเหตุตรงตัว
บอกไม่ได้ว่า “เสร็จจริงไหม” → ไม่มีใครตรวจของจริง (verify/harness)
ต่อยอด/แก้ของเดิมยาก → ไม่มี version control — แก้แล้วพัง ย้อนไม่ได้
ไม่มี spec ให้ยึด → ข้ามขั้นแบบแปลน (spec) ไป build เลย
ไม่ได้เป็นเจ้าของ/ไม่เข้าใจ code → ไม่มี spec/doc ให้อ่าน-ส่งต่อ
wow → wall → SPEC → build → verify → ship
10:15 – 11:15 · 60 นาที · concept
// m3 · spec & harness
เปรียบเทียบ: สร้างบ้าน “ไม่มีแบบแปลน” + “ไม่มีคนตรวจรับงาน”
ไม่มีแบบแปลน (spec)
สร้างมั่ว แก้ยาก
+
ไม่มีคนตรวจรับงาน (verify)
“บอกไม่ได้ว่าเสร็จ”
// m3 · spec & harness
Product thinking 101 — คิดก่อนสร้าง
- ปัญหาจริงของ user คืออะไร? ใครใช้? ใช้ตอนไหน?
- สร้าง “สิ่งที่ถูก” ก่อน “สร้างให้ถูกวิธี”
// m3 · spec & harness
User story — สูตรเขียนความต้องการ
ตัวอย่าง CollabInbox: “ในฐานะแบรนด์ ฉันต้องการกรอกฟอร์มขอร่วมงานจากลิงก์ของครีเอเตอร์ เพื่อให้ดีลถึงมือครีเอเตอร์โดยตรง ไม่ตกหล่นใน DM”
มุมครีเอเตอร์ (อีก user หนึ่ง): เห็นทุกดีลรวมใน inbox เดียว + ไม่ลืม follow-up
// m3 · spec & harness
Requirement ที่ดี vs ไม่ดี
คลุมเครือ
“ทำระบบดีลให้หน่อย”
“ให้มันดูดี ๆ”
“จัดการแบรนด์ได้”
ชัด + ตรวจได้
“ฟอร์มสาธารณะต้องมีชื่อแบรนด์ + ยอด · ส่งแล้วดีลเด้งเข้า inbox · หน้า inbox แสดงดีลเรียงตามเดดไลน์”
เกณฑ์ง่าย ๆ: requirement ที่ดี = “ตรวจได้ว่าทำสำเร็จหรือไม่”
// m3 · spec & harness
The pro workflow — เส้นทางของมืออาชีพ
2 จุดที่ vibe coding ข้าม → Spec และ Verify
// m3 · spec & harness
Spec = “แบบแปลน” ของแอป — วันนี้เขียนในรูปแบบ PRD
- PRD (Product Requirements Document) = แบบแปลนของแอป: จะสร้างอะไร · เพื่อใคร · เสร็จแล้วต้องทำอะไรได้ — ไม่ใช่บอกวิธีเขียนโค้ด
- เขียนครั้งเดียว → คน + AI เข้าใจตรงกัน · วันนี้ใช้ Lite PRD 1 หน้า (spec ไม่ใช่เอกสาร 40 หน้า)
problemusersfeaturesrequirements (given/when/then)data fields
ตัวอย่าง collabs fields: ชื่อแบรนด์ · ผู้ติดต่อ (อีเมล/LINE) · ช่องทาง (IG/TikTok/YT) · deliverable · ยอดดีล · เดดไลน์ · สถานะ — แบรนด์กรอกผ่านฟอร์ม ยกเว้น สถานะ ที่ครีเอเตอร์คุม
// m3 · spec & harness
Harness (คนตรวจรับงาน) — คำฮิตปี 2026
= ระบบรอบ ๆ agent ที่บังคับให้มัน “ตรวจผลงานจริง ก่อนบอกว่าเสร็จ”
vibe coding: agent พิมพ์เสร็จ = เคลมว่าเสร็จ
มี harness: เสร็จ = ผ่านการตรวจ
// m3 · spec & harness
Codex ตรวจงานเองได้ — คุมเบราว์เซอร์ + เช็คผลจริง
ตัวอย่าง: สั่งให้ Codex เปิดแอป CollabInbox → ส่งฟอร์มดีลทดสอบ (สวมบทแบรนด์) → มันมองหน้าจอเองว่าดีลนั้นขึ้นใน /inbox จริงไหม ก่อนบอกว่า “เสร็จ”
// m3 · spec & harness
Harness ที่เราจะเห็นวันนี้ — 2 ระดับ
01 · ระดับ process
ขั้น code-review ของ Dev agent
agent ตรวจงานตัวเองแบบ adversarial ตาม acceptance criteria (BMAD)
• ไล่เช็คทีละข้อว่าโค้ดตรงตาม acceptance criteria ของ story
• “ฟอร์มรับดีลต้องมีช่องชื่อแบรนด์ + ยอด” → มีครบไหม
• เช็ค field ที่ลืม / error handling / naming ตาม quality gate
• รัน lint หรือ test ถ้ามี
02 · ระดับ runtime
Codex เปิดแอปจริง แล้วเช็ค
in-app browser / Computer Use — “เห็นกับตา” ก่อนบอกว่า done
• เปิดแอป local → ส่งฟอร์มดีลทดสอบ → เปิด /inbox → เห็นดีลใหม่จริง
• ส่งฟอร์มโดยเว้นช่องยอด → ต้องขึ้น error ตามที่ควร
• กดปุ่มเลื่อนสถานะ → สถานะเปลี่ยนจริง (บันทึกลง DB)
• ถ่าย screenshot หน้าจอเทียบกับผลที่คาด
// m4 · ลงมือจริง
ลงมือจริง: ให้ AI agent
เขียน spec ของ CollabInbox
hands-on แรกกับ BMAD v6 บน Codex — ทุกคนได้ PRD ของตัวเอง
▸ วันนี้เริ่มที่ planning (PM → PRD)
มี BMad-Help เป็นไกด์คอยบอก “ทำอะไรต่อ” ตลอดทาง
11:15 – 12:00 · 45 นาที · hands-on บน codex
// m4 · ให้ agent เขียน spec
BMAD คืออะไร? — Breakthrough Method for Agile AI-Driven Development
- Framework ที่จัด “ทีม AI agent ผู้เชี่ยวชาญ” (PM, Architect, Developer, UX …) ให้ทำงานเป็นทีมแบบ agile
- ฟรี + open source · มี bmad-help คอยไกด์ว่า “ทำอะไรต่อ”
- ไม่ใช่ AI คิดแทนเรา — แต่ ช่วยดึงความคิดที่ดีที่สุดของเราออกมาอย่างมีระบบ
เปลี่ยน AI จาก “คนพิมพ์โค้ดคนเดียว” → “ทีมพัฒนาที่มีขั้นตอน”
ชื่อจำง่าย (ไม่เป็นทางการ): “Build More Architect Dreams”
// m4 · ให้ agent เขียน spec
BMAD v6 = จัดทีม AI agent เหมือนทีม agile · 4 เฟส
Solutioning
Architect + PM
BMad-Help คอยบอก “ทำอะไรต่อ” ตลอดทุก phase
วันนี้โฟกัส Planning (ทำ) + Solutioning (ดู) · Implementation = ตอนบ่าย (M6)
// m4 · ให้ agent เขียน spec
3 tracks — เลือกตามขนาดงาน (ปรับตามสเกล · level 0–4)
Quick Flow
lv 0–1 · tech-spec
~1–2 stories
BMad Method
lv 2–3 · PRD + arch + UX
~10–50+ stories
Enterprise
lv 4 · + security/devops
30+ stories
จำนวน story เป็นตัวเลข คร่าว ๆ · CollabInbox เล็ก → Quick Flow ก็พอ แต่วันนี้เดิน BMad Method แบบ lite เพื่อ “ฝึกจนขึ้นใจ” spec-driven
// m4 · ลงมือจริง
ทุกคนทำ
สร้างโปรเจกต์เอง 3 ขั้น (ไม่ต้องมี starter kit)
- 01สร้างโฟลเดอร์ —
~/collabinbox (ว่าง)
- 02เปิดใน Codex — Open project → มี terminal ในตัว
- 03init BMAD —
npx bmad-method install → ตอบ prompts → เลือก module BMM + เลือก tool = Codex → ได้โฟลเดอร์ _bmad/ (agents/workflows) + AGENTS.md
ก่อนสั่ง: ตั้ง approval mode = Auto (การ install ต้องต่อเน็ต Codex จะขออนุญาต — กดอนุมัติได้เลย · ความหมายของโหมดต่าง ๆ เดี๋ยวเรียนละเอียดใน M5)
ล็อก: from-scratch (ผู้เรียนติดตั้งสด) — เพื่อความเป็นเจ้าของ 100% · safeguard: TA 1:6–8 · checkpoint repo ทุกสเตจ · pin BMAD version · ทดสอบทั้ง macOS + Windows ก่อนเปิดรุ่น
// m4 · ลงมือจริง
ทุกคนทำ · ผู้สอนนำทีละคำถาม
ลงมือ: PM agent สัมภาษณ์เรา → ร่าง PRD ให้
- 01ตอบคำถาม ไม่ใช่เขียนเอง — PM agent ถามทีละข้อ → เราตอบด้วยภาษาคน → agent ร่าง PRD ให้
- 02ถาม ≈ 5 เรื่อง (= 5 ส่วนของ PRD จาก M3-7): ปัญหา · ใครใช้ · ฟีเจอร์ · เงื่อนไข “เสร็จ” · ข้อมูลที่เก็บ
- 03สิ่งที่ได้: features (ฟอร์มรับดีล
/ · หน้า /inbox · เลื่อนสถานะ) · requirements แบบ Given / When / Then · data fields ของ collabs
// m4 · ลงมือจริง
ทุกคนทำ · generate สด
Solutioning — generate เอง: จาก PRD → พร้อมลงมือ build
bmad-architecture
Architect สร้าง architecture.md
(ADRs: Next.js + Neon)
bmad-create-epics-and-stories
PM แตก epics/ + stories
bmad-check-implementation-readiness
Architect ตรวจความพร้อม —
ประตูด่านแรกของ “verify”
v6: ทำ epics/stories หลัง architecture เพื่อให้ story มีคุณภาพ · ⚠️ วาง “Scope-Guard Prompt” ก่อนสั่ง generate
Scope-Guard Prompt (พิมพ์ก่อนสั่ง generate): “ห้าม over-engineer: จำกัดขอบเขตที่ 1 entity · 1 epic · 2–3 stories · 3–4 ADR เท่านั้น ไม่ต้องคิดเผื่ออนาคต”
ศัพท์: epic = กลุ่มก้อนใหญ่ของงาน (รวมหลาย story) · ADR = บันทึกการตัดสินใจทางเทคนิค (เลือกอะไร เพราะอะไร)
// m4 · output
จบเช้า — คุณ generate “แบบแปลน” ของตัวเอง ครบแล้วด้วย agent จริง
- PRD (ของตัวเอง)
- architecture.md
- epics / stories
บ่ายนี้ (M6): ให้ Dev agent เดินวงจร create-story → dev-story → code-review เปลี่ยน spec เป็นแอปจริง
// m5 · codex fundamentals
ขับ Codex ให้เป็น
ก่อนลงมือสร้าง
รู้จัก agent loop · approval modes · AGENTS.md · git = “save game” · สั่ง BMAD v6 บน Codex
13:00 – 13:35 · 35 นาที · build
// m5 · ขับ codex ให้เป็น
· 5 min
เช็คก่อนเริ่ม: ทุกคนพร้อมไหม
- เปิด Codex app + โปรเจกต์
~/collabinbox ได้
- BMAD ติดตั้งแล้วจาก M4 (มีโฟลเดอร์
_bmad/ + AGENTS.md)
ใครติด → TA ช่วยแก้เฉพาะราย
// m5 · ขับ codex ให้เป็น
Agent loop — Codex ทำงานเป็นวงจร
CHECK
ตรวจผลจริง = harness
Tools ที่ Codex มี: อ่าน/เขียนไฟล์ · รัน terminal · เปิด browser
// m5 · ขับ codex ให้เป็น
ขับให้ปลอดภัย: โหมดขออนุญาต (approval modes)
Auto
แก้ไฟล์ + รันคำสั่ง
ขอตอน network
Full Access
ไม่ถามทุกก้าว
วันนี้ใช้ Auto เป็นหลัก — สมดุลระหว่างเร็วกับปลอดภัย
// m5 · ขับ codex ให้เป็น
AGENTS.md = “กติกา/บรีฟงาน” ที่ Codex อ่านก่อนทำงาน
- บอก tech stack, สิ่งที่ห้ามทำ, มาตรฐานของโปรเจกต์
- เช็คเข้า repo → แชร์ทั้งทีมได้ (มาตรฐานกลาง)
- ของ CollabInbox: Next.js + Neon Postgres · ไม่มี auth · entity เดียว =
collabs · 2 routes: / (ฟอร์ม) + /inbox
เทียบ: เหมือน brief งานให้ทีมก่อนเริ่ม
// m5 · ขับ codex ให้เป็น
Git = “save game” ของ code · GitHub = คลาวด์ที่ฝากเซฟ
ศัพท์ 3 คำ: repo = โฟลเดอร์โปรเจกต์ที่ git ดูแล · commit = กดเซฟ 1 ครั้ง (ย้อนกลับได้) · push = ฝากเซฟขึ้น GitHub
กติกาวันนี้: story ขึ้น done เมื่อไร → commit ทันที (จะทำจริงใน M6/M7) · ตอน M8 การ push จะกลายเป็น “อัปเดตเว็บอัตโนมัติ”
// m5 · ขับ codex ให้เป็น
เรียก agent/workflow = พิมพ์ชื่อ bmad-*
เช่น bmad-agent-pm, bmad-prd, bmad-create-story · มี BMad-Help คุมทั้งทีม
💰
มารยาทการสั่ง (ประหยัดโควตา — ทั้งห้องยิงพร้อมกัน): สั่งทีละขั้น · กระชับ · fresh chat ทุก workflow (ดีต่อคุณภาพ แต่กิน quota → ยิ่งต้องกระชับ)
// m6 · build-along part 1
เปลี่ยน spec → แอปที่
ต่อ database ได้จริง
เดินวงจร Implementation ของ BMAD v6 ด้วย Dev agent
13:35 – 14:55 · 80 นาที · build-along — นำโดยผู้สอน ทุกคนทำตาม
// m6 · spec → แอปจริง
· 8 min
เริ่ม Phase 4: เปิดโปรเจกต์ + ดู planning artifacts
- เปิด
~/collabinbox → ชี้ AGENTS.md
_bmad-output/ มี PRD.md, architecture.md, epics/
ล็อก: artifacts มาจาก M4 (generate สด) · เผื่อบางเครื่องไม่ครบ → checkout checkpoint repo แล้วไปต่อทันที
// m6 · spec → แอปจริง
· 12 min
ต่อฐานข้อมูล (database): ให้ Codex provision Neon ผ่าน vercel CLI
สั่ง Codex (ภาษาคน)
“ต่อ Neon DB ให้โปรเจกต์นี้”
vercel link
สร้าง/เชื่อม Vercel project
provision Neon
ผ่าน CLI (Marketplace)
DATABASE_URL
vercel env pull
Codex ทำให้ทุกขั้นผ่าน vercel CLI — ไม่ต้องสลับ account/copy keys เอง · เปิด Vercel/Neon dashboard ไว้แค่ ดูผล (เห็น DB โผล่จริง) · project ที่ link ตรงนี้ = ตัวเดียวกับที่ M8 จะเชื่อม GitHub
// m6 · spec → แอปจริง · 10 min
Sprint planning + สร้างโครงตาราง (schema)
- Dev agent →
bmad-sprint-planning → ได้ sprint-status.yaml
- สร้าง
collabs table ตาม architecture + ใส่ test data → ดูใน Neon
test data ตัวอย่าง: CafeLatté Skincare (IG · 15,000) · GameGear TH (YouTube · 40,000) · อร่อยดี Delivery (TikTok · 8,000)
backlog
ready-for-dev
in-progress
review
done
สถานะของทุก story เดินตามท่อนี้ — “เสร็จ” มีนิยามชัด ไม่ใช่ความรู้สึก
// m6 · เปลี่ยน spec → แอปที่ต่อ database ได้จริง
วงจร build ของ v6 (ขับด้วย dev agent)
01
bmad-create-story
สร้าง story + context
02
bmad-dev-story
ลงมือ implement
03
bmad-code-review
ตรวจเอง = process harness
Story #1 = “ฟอร์มรับดีลสาธารณะ / + หน้า inbox /inbox” (public create + read) ต่อ database จริง
// m6 · spec → แอปจริง
· 45 min
เดิน story #1 ทีละขั้น
- 01create-story → story ขึ้นสถานะ
ready-for-dev
- 02dev-story → ฟอร์มรับดีลสาธารณะ (
/) + หน้า inbox เรียงตามเดดไลน์ (/inbox) ต่อ DB จริง
- 03code-review → ผ่าน AC + quality gate → สถานะ
done
- 04เซฟผลงาน: สั่ง Codex
git init + commit แรก (“story-1 done”) — ตามกติกา M5-6: done = เซฟ
ปิดท้าย: รัน dev server เปิดใน Codex in-app browser → สวมบทแบรนด์ส่งฟอร์มดีลทดสอบ → เห็นดีลเด้งเข้า /inbox จริง
// m6 · key message
“เสร็จ” นิยามใหม่ — งานไม่เสร็จเพราะ agent พิมพ์เสร็จ
แต่เสร็จเมื่อผ่าน create-story → dev-story → code-review
แล้วสถานะขึ้น done
// m6 · output
ได้อะไรจาก M6
- ฟอร์มรับดีล + inbox ใช้ได้จริง
- ต่อ Neon DB ของตัวเอง
- เดินวงจร BMAD v6 ครบ 1 รอบ (
done)
- commit แรกใน git (จุดเซฟที่ 1)
// m7 · build-along part 2
เติมสถานะ + ตรวจของจริง
+ เป็นเจ้าของ code
เลื่อนสถานะดีล · harness ตรวจจริง (demo) · git (เป็นเจ้าของ code)
15:10 – 16:10 · 60 นาที · build
// m7 · build part 2 + harness + git
· 20 min
Story #2 → “เลื่อนสถานะดีล” (เดินวงจรอีกรอบให้ชิน)
- งานหลัก (ทุกคนทำ): ปุ่มเลื่อนสถานะ ใหม่ → คุยอยู่ → ตกลงแล้ว → จ่ายแล้ว ผ่าน
create-story → dev-story → code-review
- Edit / Delete ดีล = optional — ทำถ้าเวลาพอ หรือให้ผู้สอนนำ (ไม่บังคับเดินเต็มรอบ)
- จบ story → commit รอบ 2 (“story-2 done”) — รอบนี้เร็ว เพราะทำเป็นแล้ว
คราวนี้เร็วขึ้นเพราะรู้จังหวะแล้ว → อัปเดต sprint-status.yaml = done
// m7 · demo · 10 min
“Verify before done” — ให้เห็นกับตา
ทางหลัก = in-app browser ของ Codex app (Mac/Windows · เหมาะกับ local dev): ผู้สอนสั่ง Codex เปิดแอป → ส่งฟอร์มดีลทดสอบ → ตรวจว่าขึ้นใน /inbox จริง ก่อนบอกเสร็จ · Computer Use (ฟีเจอร์ desktop ของ Codex app · ตอนนี้ Mac) = โชว์เฉย ๆ ไม่ใช่ทางหลัก
// m7 · build part 2 + harness + git
ทุกคนทำ
เอา code ขึ้น GitHub — เป็นเจ้าของ repo 100%
สั่งผ่าน Codex คำสั่งเดียว: gh repo create collabinbox --private --source=. --push — สร้าง repo บน GitHub + push ทุก commit ที่มี (gh = GitHub CLI · login มาแล้วจาก pre-work)
จุดเซฟจาก M6/M7 ขึ้นคลาวด์แล้ว — เหมือน version history ของ Google Docs · repo นี้ = ประตูสู่ auto-deploy ใน M8
// m7 · output
ได้อะไรจาก M7
- CollabInbox ใช้งานได้ (ฟอร์มรับดีล + inbox + เลื่อนสถานะ)
- เห็น verify loop ของจริง
- repo บน GitHub (เจ้าของ 100%)
// m8 · ship it
เอาแอปขึ้นจริง —
มี live URL
local → production · push แล้วเว็บอัปเดตเอง (auto-deploy)
16:10 – 16:45 · 35 นาที · ship
// m8 · ship it · 5 min
รันบนเครื่อง (local) vs รันออนไลน์ (production)
Local
รันบนเครื่องเรา (คนเดียวเห็น)
Production
รันบน Vercel (ใคร ๆ ก็เปิดได้)
Environment variables = ค่าลับ (เช่น DATABASE_URL) ที่ไม่ฝังในโค้ด
// m8 · ship it
Deploy: เชื่อม Vercel project (ตัวเดิมจาก M6) กับ GitHub repo
Vercel project เดิม
(DB Neon อยู่แล้วจาก M6)
Settings → Git
connect repo collabinbox
⚠️
ใช้ project เดิม ที่ provision Neon ไว้ — ไม่ต้อง import สร้าง project ใหม่ → DATABASE_URL ถูก inject ใน production อยู่แล้วอัตโนมัติ
ทางลัดเสริม: Codex มี vercel-deploy Skill สั่งประโยคเดียวก็ได้ (ของแถม — วันนี้ใช้เส้นทาง GitHub เป็นหลัก)
// m8 · ship it
ทุกคนทำ
Auto-deploy: push แล้วเว็บอัปเดตเอง
แก้เล็ก ๆ
เช่น title/ข้อความ
ลองจริง: ให้ Codex แก้อะไรเล็ก ๆ → commit → push → ดู Vercel build แป๊บเดียว → refresh live URL เห็นของใหม่
นี่คือเหตุผลที่เราหัด commit/push: push 1 ครั้ง = เว็บจริงอัปเดต 1 ครั้ง — ต่อจากนี้ไม่ต้อง “deploy เอง” อีกเลย
// m8 · ship it
ทุกคนทำ · จับคู่
ลิงก์ฟอร์มของคุณใช้ได้จริงแล้ว — ให้ “แบรนด์” กรอกสดต่อหน้า
https://collabinbox-xxx.vercel.app
แลกลิงก์กับเพื่อนข้าง ๆ → สวมบทแบรนด์กรอกฟอร์มของกันและกัน → เปิด /inbox บนมือถือ เห็นดีลเด้งเข้าสด ๆ 🎉
ลิงก์นี้เอาไปวางใน bio ได้เลย — ลิงก์ = ตัวโปรดักต์
// m9 · closing · 15 min
ทบทวนเส้นทางของวันนี้ — Wow ถึง Ship
วันนี้ได้: deployed app + Lite PRD + GitHub repo — ทำทั้งหมดด้วย Codex บน ChatGPT Plus ที่มีอยู่แล้ว
// m9 · closing
ไปต่อทางไหน
ยกระดับแอป
เพิ่ม auth (ระบบล็อกอิน) ให้ “เฉพาะคุณ” เห็น inbox — ตอนนี้ /inbox ยังเปิดสาธารณะ · ทำได้ 2 ทาง: เพิ่ม auth บน stack เดิม (เช่น Auth.js บน Next.js+Neon) หรือย้ายไป Supabase ถ้าอยากได้ DB+auth รวมในที่เดียว · ต่อยอด: แชร์ให้ทีม/ผู้จัดการช่วยดู · scaling · เมื่อไรควรจ้าง dev
ยกระดับ workflow
BMAD v6 เต็ม (Analysis, UX, Enterprise, retrospective) · Codex Skills / Automations / Subagents · harness ระดับ CI
→ ชี้ไปคอร์ส Advanced
// m9 · closing
ขอบคุณ + ก้าวต่อไป
คุณคือ “Serious Builder” แล้ว 🎉
feedbackcertificatecommunity / resources