Prompt library — สร้างเว็บด้วย vibe coding แบบตรวจรับได้

ใช้ prompt เป็น brief ให้เครื่องมือเสนอ/แก้ code แล้วตรวจ diff, run commands และทดสอบเองเสมอ. ก่อนเริ่มให้แทนค่าที่อยู่ใน [วงเล็บ]; อย่าส่ง token, .dev.vars, customer data หรือข้อมูลบัตรลง prompt. ทุก prompt ในหน้านี้จงใจบอกว่า “ไม่เพิ่ม dependency” เพื่อให้เห็น diff เล็กและ review ได้. หากต้องเพิ่ม library ให้ถามเหตุผล, license, bundle impact และแนวทาง fallback ก่อน.

เปิด prompt จากบทที่กำลังเรียน

แต่ละบทมี prompt สร้างเว็บฉบับเต็มก่อนเริ่มลงมือ พร้อม prompt ตรวจแก้และลิงก์ผลลัพธ์:

ใช้ prompt สร้างเว็บในสำเนา starter ของตนเอง แล้วรันขั้นตรวจในบทนั้นก่อนเทียบกับตัวอย่าง Prompt ภาพต้นฉบับและภาพที่ได้อยู่ใน ภาพประกอบ

เปิดแผนภาพ delivery loop แบบเต็มหน้า เพื่อเลือกว่าควรใช้ prompt ชุดใดในแต่ละช่วง เนื้อหาใน code block ด้านล่างเป็น canonical prompt จึงคงข้อความเดิมครบถ้วน ไม่ย่อเป็นแผนภาพ

โครง prompt ที่นำกลับใช้ได้

บริบท: [ธุรกิจ/กลุ่มผู้ใช้/งานหลักของหน้า]
พื้นที่งาน: [โฟลเดอร์หรือ route ที่อนุญาต]
ข้อมูลจริง/สมมติ: [catalog/content/source of images]
ต้องทำ: [vertical slice ที่ตรวจได้]
ข้อห้าม: [secret, dependency, client-trusted data, claim ที่พิสูจน์ไม่ได้]
คุณภาพ: semantic HTML, keyboard, visible focus, responsive, loading/empty/error,
prefers-reduced-motion, reserve image dimensions.
การตรวจรับ: [commands ที่มีจริง], manual cases [..].
ก่อนแก้: สรุปแผนและไฟล์ที่จะเปลี่ยน. หลังแก้: สรุป diff, commands ที่รัน,
และข้อจำกัดที่ยังเหลือ. หยุดหากต้องแก้นอกขอบเขต.

1) Company site — prompt เริ่มต้นที่สมบูรณ์

สร้างเว็บไซต์บริษัทสถาปัตยกรรมภาษาไทยชื่อ “เส้นตั้ง สตูดิโอ” ใน starter หลักสูตรนี้
เป้าหมาย: ผู้เข้าชมเข้าใจบริการ เห็นแนวทางออกแบบ และส่งข้อความสอบถามโครงการได้
เริ่มจากอ่าน package.json, DESIGN.md, examples/company/ และ contact route ใน src/worker.ts
ใช้ semantic HTML, CSS และ vanilla JavaScript ตาม stack เดิม ไม่เพิ่ม dependency
สรุปแผนและไฟล์ที่จะเปลี่ยน แล้วลงมือสร้างใน examples/company/{index.html,style.css,main.js}
รักษาเว็บตัวอย่างอื่นและ API เดิม หากขาด prerequisite ให้รายงานสิ่งที่ขาดตามจริง

แนวภาพ: สตูดิโอสถาปัตยกรรมร่วมสมัย สีกรมท่า ขาว และไม้ แสงธรรมชาติ พื้นที่ว่างอ่านสบาย
ใช้ฟอนต์ IBM Plex Sans Thai ที่มีใน public/fonts และภาพ /images/company-studio.webp
หน้าเว็บมีเมนู, hero พร้อม CTA “คุยเรื่องโครงการ”, บริการ, ผลงานสมมติ,
กระบวนการทำงาน, แบบฟอร์มติดต่อ และ footer ที่กลับไปยังหลักสูตรได้
ระบุว่าเป็นธุรกิจและผลงานสมมติ ห้ามแต่งคำรับรอง โลโก้ลูกค้า หรือสถิติเป็นข้อเท็จจริง
กำหนดขนาดภาพและ alt ที่เหมาะสม ทุก CTA ต้องนำไปยังเนื้อหาหรือการทำงานที่มีอยู่จริง

แบบฟอร์มมี label สำหรับ name, email, message และ consent พร้อม honeypot ชื่อ website
ส่ง JSON {name,email,message,consent,website} ไป POST /api/contact ที่ origin เดียวกัน
ส่ง Idempotency-Key และใช้ key เดิมเมื่อ retry ข้อมูลเดิมหลัง network error
อ่าน success {id,message} และ error {error:{code,message}} ตาม response จริง
ทำสถานะเริ่มต้น/ข้อมูลไม่ครบ/กำลังส่ง/สำเร็จ/ส่งไม่สำเร็จ พร้อมข้อความภาษาไทย
ปิดปุ่มเฉพาะระหว่างส่ง ไม่ล้างข้อความเมื่อเกิด error และไม่แสดงสำเร็จก่อน server ยืนยัน
ใช้ข้อมูลติดต่อสมมติและแจ้งว่า Worker ปกปิด name/email/message ก่อนบันทึก D1
ไม่มีการส่งอีเมลจริง ไม่มี secret ใน client และไม่เปลี่ยน DEMO_MODE ของ starter

รองรับ desktop และมือถือ 390px ไม่มีเนื้อหาล้นแนวนอน มี skip link,
heading ตามลำดับ, focus ที่เห็น, keyboard navigation, status ที่ screen reader อ่านได้,
ปุ่มใช้งานสะดวกอย่างน้อย 44px และ prefers-reduced-motion
ตรวจด้วย npm run build และ npm run lint จากนั้นทดลองกรอกผิด/ส่งสำเร็จ/จำลอง network error
ใช้ preview ตามพอร์ตที่โปรเจกต์จองไว้ ห้ามใช้พอร์ตของโครงการอื่น
ส่งสรุปไฟล์ที่สร้าง วิธีเปิดหน้า ภาพผลลัพธ์ และผลตรวจจริง; สิ่งที่ยังไม่ได้รันทดสอบให้ระบุไว้

Follow-up prompts ที่ใช้รีวิว company site

Review เฉพาะ diff ของ `/examples/company/`, `examples/company/main.js` และ `/api/contact` ใน `src/worker.ts`. อย่าแก้ code.
หา client-trusted state, SQL string concatenation, missing form/error states,
keyboard/focus problems, image CLS risks, hard-coded secrets และ claims ที่เป็น demo แต่ไม่มีป้าย.
รายงานเป็นรายการเรียงตาม severity พร้อม file:line และวิธีพิสูจน์แต่ละข้อ.

เขียน tests/commands ที่เล็กที่สุดเพื่อพิสูจน์ POST /api/contact: valid demo payload
พร้อม `Origin: http://localhost:3320` ได้ 201 `{id,message}`, invalid ได้ 400 envelope,
และ row ที่สำเร็จใน local D1 เป็น `[demo-redacted]`. ใช้ `npm run db:local` แล้ว test
stack ที่มีอยู่เท่านั้น; อย่าเพิ่ม package.

2) Rental equipment — prompt ที่บังคับ model ธุรกิจ

สร้างเว็บไซต์ให้เช่าอุปกรณ์ถ่ายภาพภาษาไทยชื่อ “หยิบยืม” ใน starter หลักสูตรนี้
ให้ผู้เรียนเลือกกล้อง ไฟ หรือชุดเสียง เลือกช่วงวันและจำนวน ตรวจของว่าง และจองสาธิตได้
อ่าน package.json, examples/rental/, src/worker.ts และ migrations/0001_initial.sql
กับ 0002_demo_retention.sql ก่อนลงมือ เพื่อใช้ contract และกติกาที่มีอยู่จริง
ใช้ HTML/CSS/vanilla JavaScript ไม่เพิ่ม dependency ไม่เพิ่มระบบชำระเงิน
สรุปแผนและ state ของฟอร์ม แล้วสร้าง examples/rental/{index.html,style.css,main.js}
รักษา API เดิมและเว็บอื่น ไม่แก้ migration ที่ apply แล้ว; ถ้าขาด API ให้รายงาน prerequisite

แนวภาพ: เหลืองสด ดำ ขาว จัดข้อมูลอุปกรณ์ให้ดูง่ายและใช้งานได้เร็ว
ใช้ฟอนต์ไทยใน public/fonts และภาพ /images/rental-kit.webp
มี hero, รายการอุปกรณ์, ตัวเลือกช่วงวัน/จำนวน, ผลตรวจของว่าง,
ฟอร์มข้อมูลสาธิต, ขั้นตอนการเช่า และข้อความว่าการจองไม่มีผลทางการค้า
โหลดอุปกรณ์ ราคา และ stock จาก GET /api/catalog ไม่ใช้ราคาที่ hard-code เป็น authority

ฟอร์มใช้ equipmentId, start, end, quantity โดยวันที่เป็นปฏิทิน UTC
ใช้ช่วง [start,end): รวมวันรับ ไม่รวมวันคืน ช่วงเช่า 1–30 วันตาม server validation
เรียก GET /api/availability?equipmentId=...&start=...&end=...&quantity=...
แสดง loading/available/unavailable/error และ totalPrice/currency/days ตาม API
เมื่อเปลี่ยนตัวเลือก ให้ปิดการส่งทันที ยกเลิกผลเก่า และป้องกัน response ที่มาช้าทับค่าปัจจุบัน

ส่ง JSON {equipmentId,start,end,quantity,name,email,consent,website} ไป POST /api/rentals
ส่ง Idempotency-Key และใช้ key เดิมเมื่อ retry ข้อมูลเดิม
ไม่ส่ง price,totalPrice,stock หรือ status ให้ server เชื่อจาก client
D1 และ capacity trigger เป็นผู้ตัดสินจำนวนว่างตอนเขียนข้อมูล; preview ไม่ใช่การยืนยันจอง
เมื่อ 201 แสดง id,totalPrice,status และ expiresAt; demo hold หมดอายุภายใน 30 นาที
เมื่อ 409 UNAVAILABLE ให้แจ้งว่าของเพิ่งถูกจองและตรวจ availability ใหม่
แสดง error.message ให้ผู้ใช้เข้าใจ เก็บข้อมูลฟอร์มไว้แก้ไขหรือ retry
ใช้ข้อมูลติดต่อสมมติ แจ้งการปกปิดชื่อ/อีเมลก่อนบันทึก D1 และไม่อ้างว่าเป็นสัญญาเช่าจริง

ทุก input มี label ใช้ keyboard ได้ มี focus/status ชัดเจน และมือถือ 390px ไม่ล้น
ตรวจ npm run build, npm run lint และใช้ชุดทดสอบ API เดิมสำหรับวันไม่ถูกต้อง,
ช่วงติดกันไม่ทับกัน, ของเต็ม, concurrent requests และ idempotency
ใช้เฉพาะพอร์ตที่จองไว้และ local D1 ของชุดทดสอบ ไม่ reset ฐานข้อมูลจริง
ส่งสรุป source, ภาพหน้าเว็บ, request/response ตัวอย่าง และผลทดสอบที่รันจริง

3) GSAP product showcase — prompt ที่ป้องกัน motion หลอกผู้ใช้

ใช้ Prompt ฉบับเต็ม — HUSH product story ซึ่งตรงกับ prompt ใน บทเรียน 07 Prompt พา AI สร้างเรื่องราวตั้งแต่ HUSH ONE, highlights, sound stage แบบ pinned, listening scenarios ที่เป็นภาพสาธิต, วัสดุ, การใช้งาน 30 ชั่วโมง, สเปกสมมติ, ตารางเปรียบเทียบสินค้าจาก API, shop, FAQ จนถึง closing CTA

ข้อกำหนดสำคัญคือ pin เฉพาะ viewport อย่างน้อย 1024×700px ที่ไม่ได้ขอ Reduce Motion ส่วนมือถือ จอเตี้ยและ reduced motion ต้องเป็น natural flow. Prompt ยังรักษา catalog IDs headphones, speaker, earbuds, ราคา D1 ฝั่ง server, idempotency, keyboard/focus และ quote-demo contract เดิมครบถ้วน ใช้ Apple เป็น reference เฉพาะโครงสร้างการเล่าเรื่องโดยห้ามคัดลอกข้อความ ภาพ โลโก้ ชื่อสินค้า หรือหน้าตาแบบจุดต่อจุด

4) Real estate — prompt สร้างบ้านสบายด้วย ui-ux-pro-max

เตรียม skill และ design system ตาม lab ก่อนใช้ prompt นี้ ข้อความตรงกับ prompt ที่มอบหมายสร้างตัวอย่างจริง ชื่อ course เดิมใน block เป็นหลักฐานประวัติศาสตร์และเก็บไว้ verbatim; prompt ใหม่ควรใช้ชื่อ AI Web Studio

สร้างเว็บอสังหาริมทรัพย์ภาษาไทยชื่อ บ้านสบาย เป็นตัวอย่างที่สี่ของหลักสูตร Vibe to Production
ใช้ semantic HTML, CSS, vanilla JavaScript ตาม stack เดิม ไม่เพิ่ม dependencies
อ่านผลลัพธ์จริงจาก skill ui-ux-pro-max ใน design-system/baan-sabai/MASTER.md
และ page override design-system/baan-sabai/pages/home.md ก่อนลงมือ

ออกแบบเว็บค้นหาบ้านที่อ่านสบาย ใช้ teal/blue ภาพใหญ่และตัวอักษรไทยที่อ่านได้
ใช้ฟอนต์ IBM Plex Sans Thai ที่มีอยู่ และภาพ AI /images/real-estate-home.webp
แสดงรายการอสังหาริมทรัพย์สมมติ 6 รายการ พร้อมทำเล ประเภท ราคา จำนวนห้อง และพื้นที่
ทำตัวกรองทำเล ประเภท งบสูงสุด การเรียงราคา บันทึกรายการโปรดในเครื่อง
แสดงจำนวนผลลัพธ์และ empty state พร้อมปุ่มล้างตัวกรอง
เปิดรายละเอียดด้วย dialog ที่ใช้คีย์บอร์ดได้และคืน focus เมื่อปิด
ปุ่มสนใจทรัพย์เลือก property ในแบบฟอร์ม แล้วส่ง inquiry ผ่าน POST /api/contact
ใช้ข้อมูลสาธิตและแจ้งนโยบาย redact ชื่อ/อีเมล/ข้อความก่อนเขียน D1
มี loading, validation error, server error และ success state กันส่งซ้ำด้วย idempotency key
ไม่มีธุรกรรม จ่ายเงิน ลงประกาศ หรือคำรับรองผลตอบแทนจริง

ทุก CTA ต้องทำงานจริง มือถือ 390px ไม่ล้นแนวนอน มี skip link, focus visible,
labels, accessible status และ reduced-motion ไม่ใส่ testimonial หรือสถิติที่แต่งขึ้น
ส่ง source ที่ examples/real-estate/{index.html,style.css,main.js}
บันทึกสิ่งที่ทำ ข้อจำกัด และวิธีตรวจผล โดยให้ผู้ประสานงานรัน build/browser tests

5) Portfolio (ตัวอย่างเสริม) — prompt สำหรับ freelancer

สร้าง /examples/portfolio/ เป็น portfolio ของ product designer ที่รับงาน B2B SaaS.
ผู้เข้าชมต้องเข้าใจ specialty, ดู case study 2 เรื่อง และส่ง project inquiry ได้ภายใน 2 นาที.
ใช้ข้อมูล/รูป placeholder ที่ติดป้าย DEMO; ห้ามสร้างบริษัท ลูกค้า ผลลัพธ์ หรือ testimonial
ปลอมเป็นข้อเท็จจริง. ออกแบบจาก research notebook และ flow diagram: visual signature คือ
case study timeline ที่อ่านได้แม้ CSS/JS ไม่ทำงาน. ใช้ semantic article/figure/caption,
responsive, keyboard focus, alt ที่มีสาระ, layout-reserved images และ reduced motion.

ใช้ contact API contract เดียวกับ company example โดยเปลี่ยน copy ให้บอก SLA การตอบตาม
ข้อมูลสมมติ. ห้ามเพิ่ม dependency/analytics/payment. เริ่มด้วย content model + states;
หลังแก้ build และตรวจ 375px, keyboard, no-JS readability และ invalid/valid form request.

Prompt ภาพประกอบที่ reuse ได้

Company hero

ภาพ editorial สำหรับเว็บไซต์บริษัทออกแบบพื้นที่ร้านในกรุงเทพฯ: close-up ของโมเดลไม้
แผ่นคอนกรีตและเส้นดินสอบนโต๊ะทำงานจริง, แสงเช้า diffuse, texture ชัด,
เว้น negative space ด้านซ้าย 35% สำหรับ headline, landscape 3:2, ไม่มีข้อความ โลโก้
ใบหน้าระบุตัวตน หรือ brand mark. ใช้ภาพเป็น concept mockup; ตรวจสิทธิ์ commercial use
และเก็บ source/license ก่อนเผยแพร่.

Rental card

ภาพสินค้า studio สำหรับการ์ดเช่าเลนส์กล้อง mirrorless สีดำ, มุม 3/4,
พื้นหลังเทาอ่อนเรียบ, shadow นุ่ม, product อยู่กลางภาพ, square 1:1,
ไม่มีโลโก้ ข้อความ serial number หรือ brand ที่มีลิขสิทธิ์. ต้องใช้ asset ที่มีสิทธิ์ชัดเจน
หรือถ่ายสินค้าเองก่อน production.

Store material scene

ภาพ macro ของลำโพงตั้งโต๊ะทรงเรขาคณิต วัสดุ brushed aluminium และผ้า acoustic สี graphite,
แสง amber เฉพาะจุด, dark background, room tone สงบ, crop แนวตั้ง 4:5,
ไม่มีชื่อแบรนด์ โลโก้ UI ตัวหนังสือ คนที่จำแนกได้ หรือการเลียนแบบสินค้ายี่ห้อใด.

ทักษะ/เครื่องมือที่ช่วยงาน (แต่ไม่แทนการตรวจ)

หากงานต้องอธิบาย architecture, state หรือ journey ที่ prose เริ่มคลุมเครือ ให้ใช้ Lab Diagram Design และ prompt สำหรับสร้าง/ตรวจแผนภาพ ก่อนเริ่มวาด อย่าเปลี่ยน checklist หรือรายการ source ธรรมดาเป็นภาพเมื่อ table/bullets ยังอ่านง่ายกว่า

คำสั่งสั้นที่ใช้ใน Codex/agent environment แตกต่างตามการติดตั้ง ให้บรรยาย outcome มากกว่าพึ่งชื่อ tool เช่น “ค้น official docs version-pinned ก่อนแก้ Worker”, “หาเฉพาะ route ที่กระทบ”, “review diff เฉพาะ security/accessibility”. แบ่งงานอิสระได้ แต่ให้คนหนึ่งรับผิดชอบ integration และ verification สุดท้าย.

Rubric สำหรับ prompt ที่ผู้เรียนเขียนเอง

• 25 คะแนน: ระบุ user/job, content/data และ scope file/route ชัด
• 25 คะแนน: ระบุ server authority, error states และข้อห้ามต่อ secret/payment/claims
• 20 คะแนน: ระบุ accessibility, responsive, reduced motion และ image dimensions
• 20 คะแนน: มี executable acceptance checks และ expected results
• 10 คะแนน: ขอ plan/diff/test output แทน “ทำให้สวย” อย่างเดียว

อ้างอิงมาตรฐานและ payment boundary: มาตรฐานคุณภาพและ commerce. สำหรับ motion ดู บทเรียน 07.

เอกสารต้นทางสำหรับข้อกำหนดสำคัญ: W3C WCAG 2.2, GSAP matchMedia(), Cloudflare Workers Static Assets และ Stripe webhook verification.