บทเรียน 00 — ภาพรวม: จาก prompt แรก สู่เว็บที่ deploy แล้ว

workshop นี้ถอดจาก session จริงหนึ่ง session ที่ใช้ AI agent (ChatGPT) สร้างเว็บไซต์ทริปภูเก็ตชื่อ “เล ไปกัน” ตั้งแต่ไม่มีอะไรเลย จนได้เว็บที่ deploy บน Cloudflare ผูกโดเมนของตัวเอง และมีระบบหลังบ้านสำหรับจัดการข้อมูล — ผลลัพธ์เปิดดูได้จริงที่ lay-pai-gun.rawinlab.com

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

ผลลัพธ์ปลายทางที่เราจะสร้างร่วมกัน

หน้าแรกของ “เล ไปกัน” — ภาพ hero จาก GPT Image, ช่องค้นหาบนภาพ และทางลัดไปสิมิลัน กระบี่ และเกาะรอบภูเก็ต โทนสีเขียวทะเลตัดขาว อ่านสบายทั้งคอมพิวเตอร์และมือถือ

ลำดับหน้าเต็ม: hero → ช่องค้นหาพร้อมตัวกรอง จังหวัด และ ประเภทสถานที่ → การ์ดสถานที่ท่องเที่ยว 20 แห่งในภูเก็ต พังงา กระบี่ และระนอง แต่ละการ์ดมีชื่อไทย–อังกฤษ ป้ายหมวด และตำแหน่งจังหวัด

บนมือถือทุกส่วนเรียงเป็นคอลัมน์เดียว กดเมนูและค้นหาได้สะดวก — ความ responsive นี้ไม่ได้สั่งแยก แต่เกิดจาก skill ออกแบบที่ agent เลือกใช้

9 ขั้นของ session จริง

รวมเวลาที่ agent ทำงานจริงประมาณ 1 ชั่วโมงครึ่ง — เวลาที่เหลือของ workshop คือส่วนที่มนุษย์ต้องทำเอง: อ่านผลตรวจก่อนติดตั้ง skill, ยืนยันอีเมล FormSubmit, ตรวจไซต์หลังแต่ละขั้น และรักษาความปลอดภัยของ token กับรหัสผ่าน

สิ่งที่ต้องมีก่อนเริ่ม

• บัญชี ChatGPT ที่เปิดใช้ agent mode หรือ AI coding agent ที่ติดตั้ง skills ได้
• บัญชี Cloudflare ที่มีโดเมนของตัวเองอยู่ในระบบ (สำหรับขั้น 7–8)
• อีเมลที่ใช้รับข้อความจาก contact form (ขั้น 5)

ข้อควรระวังของทั้ง workshop

• อย่าเชื่อผลลัพธ์โดยไม่เปิดดู — ทุกขั้นจบด้วยการเปิดเว็บจริงและทดลองใช้ ไม่ใช่แค่เห็นข้อความ “เสร็จแล้ว”
• ความปลอดภัยเป็นขั้นตอน ไม่ใช่ตัวเลือก — ผลตรวจ skill, API token ใน .env และรหัสผ่านหลังบ้าน คือสามจุดที่ต้องระวังที่สุดของ session นี้
• ข้อมูลสถานที่ในเว็บใช้เพื่อการเรียนรู้ — เว็บไม่มีการรับชำระเงิน และรายละเอียดการเดินทางควรตรวจสอบอีกครั้งก่อนใช้จริง

พร้อมแล้วเริ่มจาก บท 01 — ติดตั้งและคัดเลือก skills

บทเรียน 01 — ติดตั้งและคัดเลือก skills ก่อนสร้างเว็บ

session เริ่มจากคำถามง่าย ๆ: จะให้ AI ทำเว็บสวยได้ ต้องมีเครื่องมืออะไรบ้าง แทนที่จะเดาชื่อ skill เอง เราใช้วิธีติดตั้ง “ตัวค้นหา skill” ก่อน แล้วให้มันแนะนำตัวที่เหมาะกับงาน — คือ find-skills สำหรับค้นหา และ ui-ux-pro-max สำหรับออกแบบ

เป้าหมายของบทนี้: ติดตั้ง skills แบบ global ให้เรียบร้อย และ อ่านผลตรวจความปลอดภัยก่อนกดยืนยันทุกครั้ง

ขั้น 1: ติดตั้ง find-skills

Prompt ที่ใช้

ติดตั้ง find-skills แบบ global

ช่วยติดตั้ง skill https://www.skills.sh/vercel-labs/skills/find-skills ใช้สำหรับ global

ผลลัพธ์ — agent ทำงาน 27 วินาที แล้วตอบว่าติดตั้งเรียบร้อยที่ SKILL.md พร้อมใช้ตั้งแต่ข้อความถัดไป โดยเรียกใช้ด้วย $find-skills

ขั้น 2: ถามหา skill สำหรับทำเว็บสวย

Prompt ที่ใช้

$find-skills อยากได้ skill ที่ไว้ทำเว็บสวยๆ

ผลลัพธ์ — agent แนะนำ frontend-design จาก Anthropic เป็นตัวหลัก (ยอดติดตั้งราว 876K) เหมาะกับการสร้างเว็บที่มีเอกลักษณ์ ไม่เป็นหน้าเว็บสไตล์ AI สำเร็จรูป รองรับ HTML/CSS/JS, React และ Vue พร้อมตัวเสริม web-design-guidelines สำหรับตรวจ UX, accessibility และความเรียบร้อยก่อนส่งงาน

ขั้น 3: ติดตั้ง ui-ux-pro-max

session นี้เลือก ui-ux-pro-max เพราะต้องการฐานข้อมูลดีไซน์ที่ค้นหาได้ (สไตล์, สี, ฟอนต์, UX guidelines) ซึ่งเหมาะกับเว็บทริปที่ต้องอารมณ์ทะเลใต้

Prompt ที่ใช้

ติดตั้ง skill https://www.skills.sh/nextlevelbuilder/ui-ux-pro-max-skill/ui-ux-pro-max

ผลลัพธ์ — agent ใช้เวลา 1 นาที 38 วินาที ติดตั้งไฟล์ทั้งหมด 73 ไฟล์ ทดสอบระบบค้นหา UI style แล้วใช้งานได้ พร้อมเรียกด้วย $ui-ux-pro-max ตั้งแต่ข้อความถัดไป

ข้อควรระวัง: การตรวจ skill ภายนอกก่อนติดตั้ง

agent รายงานไว้ชัดเจน: skills.sh แสดงผลตรวจ Socket และ Snyk ผ่าน แต่ Gen Agent Trust Hub ไม่ผ่าน — และเรายังติดตั้ง เพราะประเมินแล้วว่าตัวเองยอมรับความเสี่ยงนั้นได้ บทเรียนสำหรับคุณคือ:

อ่านผลตรวจทุกแหล่งก่อนติดตั้ง skill จากภายนอกทุกครั้ง — ผลตรวจหนึ่งชุดผ่านไม่ได้แปลว่าทุกชุดผ่าน ถ้าแหล่งใดไม่ผ่าน ให้หาข้อมูลเพิ่ม (ดู repo, ผู้เผยแพร่, จำนวนผู้ใช้) แล้วค่อยตัดสินใจ หรือเลือกตัวอื่นแทน

ข้อสังเกตเพิ่มเติมจากขั้น 2: agent บอกด้วยว่าเครื่องนั้นมี frontend-design อยู่แล้ว เรียกได้ด้วย $frontend-design — การรู้ว่ามีอะไรอยู่บนเครื่องแล้วช่วยประหยัดเวลา และลดจำนวน skill ภายนอกที่ต้องติดตั้งใหม่

ต่อไป: บท 02 — ใช้ skill ออกแบบและสร้างเว็บทริปภูเก็ต

บทเรียน 02 — ใช้ skill ออกแบบและสร้างเว็บทริปภูเก็ต

skills พร้อมแล้ว บทนี้คือหัวใจของ session: สั่งสร้างเว็บทั้งเว็บด้วย prompt เดียว แล้วปล่อยให้ agent ตัดสินใจเรื่องดีไซน์เอง — เรากำหนดแค่ “ธุรกิจอะไร มีเนื้อหาอะไร จะเอาภาพจากไหน”

เป้าหมายของบทนี้: เห็นว่า prompt สร้างเว็บที่ดีประกอบด้วยอะไร และ agent ใช้ดุลยพินิจตรงไหน

Prompt ที่ใช้

$ui-ux-pro-max สร้างเว็บไซต์สำหรับให้ข้อมูลเกี่ยวกับทริปที่จังหวัดภูเก็ต

ไปสิมิลันนะ ไปกระบี่ได้ ไปเกาะต่าง ๆ รอบภูเก็ตได้นะครับ

สามารถใช้ตัว GPT Image ในการช่วย generate รูปภาพเพื่อประกอบให้เว็บไซต์ดูสวยงามนะครับ

สังเกตว่า prompt นี้สั้นมากสำหรับงานขนาด “สร้างเว็บทั้งเว็บ” — มี 4 ส่วนสำคัญคือ (1) เรียก skill ที่ต้องการใช้ ($ui-ux-pro-max) (2) บอกประเภทเว็บและพื้นที่เนื้อหา (ทริปภูเก็ต) (3) ยกตัวอย่างเนื้อหาหลัก (สิมิลัน กระบี่ เกาะรอบภูเก็ต) และ (4) อนุญาตให้ใช้ GPT Image สร้างภาพประกอบ

ผลลัพธ์

agent ทำงาน 13 นาที 52 วินาที แล้วตอบว่า: สร้างเว็บ “เล ไปกัน” เรียบร้อย มีข้อมูลสิมิลัน กระบี่ และเกาะรอบภูเก็ต พร้อมรายละเอียดทริป คำแนะนำการเดินทาง และภาพจาก GPT Image โดยใช้ ui-ux-pro-max วางดีไซน์ รองรับมือถือและคอมพิวเตอร์ — จากนั้นเผยแพร่แบบส่วนตัวให้เจ้าของดูก่อน โดยแก้ไขไฟล์ราว 10 ไฟล์ (+238 บรรทัด)

สิ่งที่ agent ตัดสินใจเอง

เราไม่ได้สั่งเรื่องเหล่านี้เลย — ทั้งหมดเกิดจากดุลยพินิจของ agent ร่วมกับ skill:

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

ข้อควรระวังและบทเรียน

• ชื่อแบรนด์ที่ AI ตั้งให้อาจติดล้อไปเลย — “เล ไปกัน” โดนใจเจ้าของจึงเก็บไว้ ถ้าไม่ถูกใจให้สั่งแก้ทันทีก่อนงานต่อยอด เพราะชื่อจะไปอยู่ในโดเมน ข้อความ และอีเมลทดสอบในขั้นถัด ๆ ไป
• ภาพจาก GPT Image สวยแต่ไม่ใช่ภาพจริง — ใช้เป็นบรรยากาศได้ แต่ภายหลังเราเปลี่ยนมาใช้ภาพจริงพร้อมเครดิตใน บท 05
• การ “เผยแพร่แบบส่วนตัว” ไม่ใช่ deploy — ขั้นนี้เว็บยังอยู่บนตัว agent เท่านั้น การขึ้นอินเทอร์เน็ตจริงเกิดที่ บท 06

ต่อไป: บท 03 — เพิ่ม contact form ด้วย FormSubmit

บทเรียน 03 — เพิ่ม contact form ส่งถึงอีเมลจริงด้วย FormSubmit

เว็บเกิดแล้ว แต่ยังเป็น “หน้าอ่านอย่างเดียว” บทนี้เพิ่มช่องทางให้ลูกค้าติดต่อกลับ: contact form ที่ส่งข้อความถึงอีเมลจริง โดยไม่ต้องเขียน backend เอง — ใช้บริการ FormSubmit ซึ่ง agent เลือกให้ พร้อมขั้นตอนยืนยันเจ้าของอีเมลที่มนุษย์ต้องทำเอง

เป้าหมายของบทนี้: มีฟอร์มที่ใช้งานได้จริงบนหน้า contact และเข้าใจว่าทำไมการ activate อีเมลจึงหลีกเลี่ยงไม่ได้

Prompt ที่ใช้

อ่า ช่วยแก้ไขตัวเว็บไซต์ให้มี contact form ให้หน่อย เมื่อลูกค้ามีการกรอก contact form มาแล้ว ให้ส่งไปที่อีเมล sayhi@rawinsoft.com. ให้ค้นหาสถานที่ท่องเที่ยวทั่วใกล้ภูเก็ต แล้วก็ทำระบบ Searching ให้ด้วย. เมื่อเสร็จแล้วให้อัปเดตไซต์เดิม.

prompt นี้รวมสองงานในข้อความเดียว (contact form + ระบบค้นหา) — ทำได้ เพราะ agent แยกทำเป็น step ของมันเอง แต่ถ้าคุณเพิ่งเริ่ม แยกเป็นสอง prompt จะตรวจผลง่ายกว่า เราจะแยกพิจารณาเป็นสองบท: ฟอร์มในบทนี้ และระบบค้นหาใน บท 04

ผลลัพธ์

agent ทำงาน 19 นาที 30 วินาที ระหว่างนั้น หยุดถามกลับมาหาเราหนึ่งครั้ง — นี่คือจุดสำคัญของบทนี้:

FormSubmit ส่งอีเมลยืนยันไปที่ sayhi@rawinsoft.com แล้ว agent ขอให้เราเปิดอีเมลและกด “Activate Form” (ตรวจโฟลเดอร์สแปมด้วย) เพื่อเปิดรับข้อความจากฟอร์ม — เรากดยืนยันเสร็จแล้วตอบกลับ “ยืนยันอีเมลแล้ว” agent จึงทำต่อจนจบ และสรุปว่า:

• เพิ่มฟอร์มติดต่อไปยัง sayhi@rawinsoft.com พร้อมแจ้งข้อผิดพลาดและเก็บข้อความไว้ในเครื่องหากส่งไม่สำเร็จ
• (ส่วนระบบค้นหา — ดูบท 04)

จากนั้น agent ทดสอบยืนยันว่าอีเมลมาถึงจริง โดยถามหาข้อความทดสอบหัวข้อ “[เล ไปกัน] ทดสอบหลังยืนยัน — URL หลัก” — สังเกตว่ามันไม่หลอกตัวเองว่า “น่าจะส่งได้” แต่ขอหลักฐานจากปลายทาง ครั้งนี้แก้ไฟล์ 18 ไฟล์ (+454 บรรทัด)

ทำไมต้อง Activate Form และใครต้องกด

ข้อควรระวังและบทเรียน

• ฟอร์มที่ยังไม่ activate = ข้อความหายเงียบ — ถ้าลืมกดยืนยัน ลูกค้ากรอกแล้วเหมือนสำเร็จ แต่เจ้าของเว็บไม่มีอีเมอร์ใด ๆ ถึงมือ ตรวจสแปมทุกครั้งที่เปิดฟอร์มใหม่
• โดเมนใหม่ต้อง activate ใหม่ — หลัง deploy ขึ้นโดเมนจริงใน บท 07 agent เตือนไว้เองว่า “ฟอร์มอีเมลบนโดเมนใหม่ยังไม่ได้ทดสอบส่งจริง” — เปิดฟอร์มจากโดเมนไหนก็ต้องยืนยันและทดสอบที่โดเมนนั้น
• เตรียมรับว่า agent จะถามกลับ — งานที่แตะต้อง identity จริง (อีเมล โดเมน บัญชี) มนุษย์ต้องลงมือเสมอ ให้ถือว่าเป็นด่านตรวจ ไม่ใช่สะดุด
• การเก็บข้อความสำรองเมื่อส่งไม่สำเร็จเป็นแนวทางที่ดี — ผู้ใช้ไม่ต้องพิมพ์ใหม่ และเราไม่พลาด lead

ต่อไป: บท 04 — ระบบค้นหา 20 สถานที่ ไทย–อังกฤษ

บทเรียน 04 — ระบบค้นหา 20 สถานที่ ชื่อไทย–อังกฤษ พร้อมตัวกรอง

งานที่สองจาก prompt เดียวกับ บท 03: ระบบ Searching สำหรับสถานที่ท่องเที่ยวใกล้ภูเก็ต ความน่าสนใจคือ agent ไม่ได้หยิบสถานที่มา 5 ที่แล้วเรียบร้อย — แต่ค้นคว้าและรวบรวมข้อมูล 20 สถานที่ พร้อมรองรับการค้นหาทั้งชื่อไทยและอังกฤษ และกรองด้วยจังหวัดกับประเภท

เป้าหมายของบทนี้: เข้าใจว่าระบบค้นหาแบบ “ข้อมูลเยอะแต่โครงสร้างชัด” เกิดจากการจัดข้อมูลอย่างไร และจะตรวจมันอย่างไรให้เชื่อได้

Prompt ที่ใช้ (ส่วนค้นหา)

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

(ยกมาจาก prompt เต็มในบท 03 — agent แยกทำเป็นงานย่อยของตัวเอง)

ผลลัพธ์

agent สรุปผลงานส่วนค้นหาว่า: ค้นหา 20 สถานที่ด้วยชื่อไทย–อังกฤษ พร้อมกรองจังหวัดและประเภท — ทั้งหมดอยู่ในหน้าเดิมของเว็บ ไม่ต้องไปหน้าใหม่

หน้าค้นหาประกอบด้วย: ช่องค้นหาด้วยชื่อสถานที่, dropdown จังหวัด (ทุกจังหวัด / ภูเก็ต / พังงา / กระบี่ / ระนอง), dropdown ประเภทสถานที่ (หาด ธรรมชาติ วัฒนธรรม ตลาดและเมือง ฯลฯ) และตัวนับผลลัพธ์แบบ “พบ 20 สถานที่ · แสดง 6 จาก 20” ที่อัปเดตตามเงื่อนไข

ลองพิมพ์ “เกาะ” — ผลลัพธ์กรองเหลือเฉพาะเกาะ แต่ละการ์ดมีป้ายประเภท (เช่น ทะเล) และหมุดจังหวัด (ภูเก็ต พังงา กระบี่) ใช้เป็นแนวทางตรวจสอบว่าข้อมูลแต่ละสถานที่ถูกจัดโครงสร้างจริง ไม่ใช่แค่ข้อความยาว ๆ

โครงสร้างข้อมูลที่ทำให้ค้นหาได้

จากที่เห็นบนหน้าเว็บ ย้อนกลับไปที่ข้อมูลเบื้องหลัง — แต่ละสถานที่ต้องมีอย่างน้อย:

การค้นหาไทย–อังกฤษพร้อมกันได้ เพราะข้อมูลถูกเก็บเป็นฟิลด์แยกตั้งแต่ต้น ไม่ใช่การค้นหาในข้อความอิสระ — โครงสร้างนี้เองที่ทำให้ต่อยอดเป็นระบบหลังบ้านจัดการสถานที่ได้ง่ายใน บท 08

ข้อควรระวังและบทเรียน

• ตรวจความถูกต้องของข้อมูลที่ AI ค้นมาให้ — จำนวน 20 สถานที่น่าประทับใจ แต่ชื่อ จังหวัด และคำแนะนำการเดินทางควรตรวจกับแหล่งทางการก่อนใช้จริง AI รวบรวมได้เร็วแต่ไม่รับประกันความถูกต้อง 100%
• ค้นหาด้วยหลายภาษาต้องทดสอบด้วยหลายภาษา — ลองทั้ง “เกาะ”, “หาด”, “beach”, “old town” และชื่อจังหวัดตรง ๆ เพื่อยืนยันว่าจับคู่ไทย–อังกฤษทำงานจริง
• ตัวนับผลลัพธ์คือเครื่องมือตรวจงาน — ถ้ากรอง “กระบี่” แล้วตัวนับไม่เปลี่ยน หรือแสดงเลขที่ขัดกับจำนวนการ์ดบนจอ ให้แจ้ง agent แก้ทันที

ต่อไป: บท 05 — เติมรูปจริงในการ์ดพร้อมเครดิตภาพ

บทเรียน 05 — เติมรูปจริงในการ์ด พร้อมเครดิตภาพและสัดส่วนมือถือ

เวอร์ชันแรกของการ์ดสถานที่เป็นภาพบรรยากาศจาก GPT Image บทนี้เปลี่ยนเป็น ภาพจริงของสถานที่ ทั้ง 20 การ์ด — พร้อมสิ่งที่หลายคนลืม: เครดิตภาพ และสัดส่วนภาพที่สม่ำเสมอจนหน้าไม่เบี้ยว

เป้าหมายของบทนี้: อัปเกรดหน้าเว็บจาก “สวย” เป็น “น่าเชื่อ” ด้วยภาพจริง โดยไม่ทำลายระบบค้นหาเดิม

Prompt ที่ใช้

ปรับปรุง card ใน section ที่เที่ยวใกล้ภูเก็ต ที่อยากชวนไป อยากให้เพิ่มรูปใน card ด้วย.

สังเกตว่าไม่ได้สั่ง “ใช้รูปจริง + ใส่เครดิต + คุมสัดส่วน” เลย — สามอย่างนี้คือมาตรฐานที่ agent เลือกทำเอง ซึ่งเป็นเรื่องดี แต่เราต้องตรวจว่ามันทำจริง (ดูวิธีตรวจท้ายบท)

ผลลัพธ์

agent ทำงาน 13 นาที 28 วินาที แก้ไฟล์ 12 ไฟล์ (+427 บรรทัด) แล้วสรุปว่า:

• เพิ่มภาพจริงครบทั้ง 20 การ์ด
• ใส่เครดิตภาพให้ผู้ถ่าย/แหล่งภาพ
• คุมสัดส่วนภาพให้สม่ำเสมอ หน้าเว็บเรียงสวย
• เพิ่มภาพขนาดเหมาะกับมือถือ (ไฟล์เล็กลงเพื่อโหลดเร็ว)
• คงระบบค้นหาเดิมไว้ทั้งหมด

บนมือถือ แต่ละการ์ดแสดงรูปเต็มความกว้างสัดส่วนเดียวกัน ตามด้วยป้ายประเภท หมุดจังหวัด ชื่อไทย–อังกฤษ คำอธิบายสั้น ลิงก์อ่านข้อมูลการเดินทาง และลิงก์ “เครดิตภาพ” แบบกางออก — ให้เครดิตโดยไม่รกหน้าจอ

วิธีตรวจงานภาพแบบมืออาชีพ

ข้อควรระวังและบทเรียน

• สิทธิ์การใช้ภาพเป็นความรับผิดชอบของเจ้าของเว็บ — agent ใส่เครดิตให้ แต่เราควรยืนยันว่าภาพอนุญาตให้ใช้จริง (สัญญาอนุญาตของแหล่งภาพ) ก่อนเว็บไปเป็นสาธารณะ
• สั่งน้อยได้มาก แต่ต้องตรวจมากขึ้นตาม — เราสั่งแค่ “เพิ่มรูปใน card” แต่ได้เครดิตและ responsive image มาแนบ พฤติกรรมแบบนี้ดี แต่ต้องเปิดผลจริงทุกครั้ง ไม่สมมติว่า “น่าจะทำ”
• การกล่าวว่า “คงระบบเดิมไว้” ต้องพิสูจน์ — คำกล่าวของ agent ไม่ใช่หลักฐาน เราทดสอบค้นหาซ้ำตามบท 04 เพื่อยืนยันเอง

ต่อไป: บท 06 — deploy ขึ้น Cloudflare ด้วย API token

บทเรียน 06 — deploy ขึ้น Cloudflare ด้วย API token จากไฟล์ .env

เว็บสมบูรณ์บนเครื่องแล้ว บทนี้พามันขึ้นอินเทอร์เน็ตจริง — deploy ขึ้น Cloudflare โดยให้ agent ใช้ API token ที่เตรียมไว้ในไฟล์ .env ขั้นนี้สั้นที่สุดของ session (6 นาที 6 วินาที) แต่แตะเรื่องความปลอดภัยมากที่สุด: token คือกุญแจเข้าบัญชี Cloudflare ของเรา

เป้าหมายของบทนี้: เว็บเปิดได้จาก URL จริง และ token ไม่รั่วออกไปไหนทั้งในโค้ด ใน log และใน repository

ก่อนสั่ง: เตรียม token ให้พร้อม

สิ่งที่เราเตรียมไว้ก่อน prompt ของบทนี้:

• สร้าง Cloudflare API token ใน dashboard (สิทธิ์เฉพาะงาน deploy — ไม่ใช่ Global API Key)
• ใส่ token ไว้ในไฟล์ .env ของโปรเจกต์ และมั่นใจว่า .gitignore กันไฟล์นี้ออกจาก git

การเตรียมแบบนี้ทำให้ prompt ในการ deploy สั้นเหลือบรรทัดเดียว:

Prompt ที่ใช้

deploy เว็บขึ้น cloudflare โดยการใช้ api token ที่อยู่ในไฟล์ .env

ผลลัพธ์

agent รายงานว่า deploy สำเร็จ พร้อมลิงก์เปิดเว็บไซต์ และย้ำเรื่องความปลอดภัยของตัวเอง:

• ไฟล์ .env และ API token ไม่ถูกเผยแพร่ — ไม่ขึ้นไปกับไฟล์ที่ deploy และไม่หลุดออกในผลลัพธ์
• เว็บเดิมบน Cloudflare Sites ยังอยู่ครบถ้วน — deploy ครั้งนี้ไม่ทำลายงานเดิม
• หมายเหตุ: ฟอร์มอีเมลบนโดเมนใหม่ยังไม่ได้ทดสอบส่งจริง — เชื่อมโยงกับบทเรียน Activate Form ในบท 03

ไฟล์ที่แก้ทั้งหมด 6 ไฟล์ (+39 บรรทัด) ที่น่าสนใจคือ agent แก้ .gitignore เพิ่ม (กัน .env ให้แน่นขึ้น), เพิ่ม dist/.assetsignore (บอก Cloudflare ว่าไฟล์ไหนไม่ต้องขึ้นไป) และบันทึกวิธี deploy ลง README

ความปลอดภัยของ token: กฎ 3 ข้อ

ถ้าสงสัยว่า token รั่ว (เช่น เผลอ commit หรือแปะในแชท) — เพิกถอนทันทีแล้วสร้างใหม่ ไม่ต้องรอดูก่อน

ข้อควรระวังและบทเรียน

• deploy สำเร็จ ≠ งานเสร็จ — agent เปิดลิงก์ให้ดู แต่เราควรเปิดเองจากอุปกรณ์จริง กดเมนู ค้นหา และลองฟอร์ม อย่างน้อยหนึ่งรอบ
• ยอมรับว่าบางอย่างยังไม่ได้ตรวจ — agent ระบุเองว่าฟอร์มบนโดเมนใหม่ยังไม่ได้ทดสอบส่งจริง การที่ AI รู้ขอบเขตของตัวเองเป็นสัญญาณที่ดี หน้าที่เราคือปิดช่องนั้นต่อ
• ให้ agent อ่านค่าจาก .env ดีกว่าวาง token ใน prompt — prompt เป็นข้อความที่ถูกเก็บ ส่งต่อ และสอนกันได้ อย่าวาง credential ในนั้นเด็ดขาด

ต่อไป: บท 07 — ผูก custom domain lay-pai-gun.rawinlab.com

บทเรียน 07 — ผูก custom domain lay-pai-gun.rawinlab.com

เว็บขึ้น Cloudflare แล้วแต่ยังใช้ URL ที่ระบบกำหนด บทนี้ผูกเว็บเข้ากับ โดเมนของตัวเอง เพื่อให้ลูกค้าจำได้ ค้นเจอ และเชื่อถือ — เงื่อนไขสำคัญคือโดเมนแม่ rawinlab.com ต้องอยู่ในบัญชี Cloudflare เดียวกัน อยู่แล้ว การผูกจึงเป็นแค่การเพิ่ม subdomain

เป้าหมายของบทนี้: เปิดเว็บจาก lay-pai-gun.rawinlab.com ด้วย HTTPS โดยลิงก์เดิมไม่ตาย

Prompt ที่ใช้

ให้ Mapping เว็บไซต์นี้ไปใช้ domain lay-pai-gun.rawinlab.com โดยโดเมน rawinlab.com อยู่ใน cloudflare แล้ว.

จุดที่ทำให้ prompt นี้เดินได้เร็ว: เราบอกสถานะของโดเมนแม่ไว้ใน prompt เลย ว่าอยู่ใน Cloudflare แล้ว agent จึงไม่ต้องถามกลับหรือเดาว่าจะต้องโยน DNS จากผู้ให้บริการรายอื่น

ผลลัพธ์

agent ทำงาน 7 นาที 30 วินาที แก้เพียง 2 ไฟล์ (README และ wrangler.jsonc) แล้วรายงานว่า:

• ผูกโดเมนเรียบร้อย: lay-pai-gun.rawinlab.com
• ตรวจแล้ว HTTPS ใช้งานได้ และไฟล์เว็บตรงกับเวอร์ชันล่าสุด (ไม่ใช่ของเก่าค้างจาก cache)
• ลิงก์เดิมยังใช้งานได้ — คนที่จด URL เดิมไว้ไม่หลง
• เตือนว่า บางเครือข่ายอาจต้องรอ DNS cache อัปเดตอีกสักครู่ จึงจะเปิดโดเมนใหม่ได้

การแก้ wrangler.jsonc คือหัวใจของขั้นนี้ — เพิ่มการ mapping ชื่อโดเมนเข้ากับเว็บที่ deploy ไว้ ส่วน README บันทึกวิธีผูกไว้ทบทวน

ทำไมต้องรอ DNS cache (และรอนานแค่ไหน)

เมื่อเพิ่ม subdomain ใหม่ ระบบ DNS ทั่วโลกต้องค่อย ๆ รับรู้ว่า lay-pai-gun.rawinlab.com ชี้ไปที่ใด:

ในทางปฏิบัติ: ถ้าเปิดไม่ได้ อย่าสั่งแก้อะไรทันที — รอ 5–15 นาทีแล้วลองใหม่ (หรือลองจากเครือข่ายอื่น/มือถือ) ก่อนสรุปว่าผูกโดเมนพลาด การสั่งแก้ซ้ำขณะ DNS กำลังอัปเดตมักสร้างงานเพิ่ม ไม่ได้แก้ปัญหา

ข้อควรระวังและบทเรียน

• บอกบริบทของโดเมนใน prompt เสมอ — โดเมนอยู่ที่ไหน ใครถือ control อยู่ จะช่วยให้ agent เลือกวิธีที่ถูกต้องได้ทันที
• ตรวจ HTTPS ให้เป็นขั้นตอนหลังผูกโดเมนเสมอ — เว็บที่เปิดได้แต่ certificate ไม่ตรงจะโดนเบราว์เซอร์เตือนและทำลายความเชื่อมั่นทันที Cloudflare ออก certificate ให้อัตโนมัติเมื่อโดเมนอยู่ในระบบ แต่ต้องยืนยันว่าใช้งานจริง
• อย่าลืมทดสอบฟอร์มบนโดเมนใหม่ — ตามคำเตือนจากบท 03 และ 06 ฟอร์มอีเมลต้อง activate และทดสอบส่งจริงจากโดเมนที่ใช้งานจริง
• เก็บลิงก์เดิมไว้ทำงาน — การคง URL เดิมช่วยกันคนหลง และให้เราเทียบเวอร์ชันได้ขณะโดเมนใหม่ยังโดน cache

ต่อไป: บท 08 — ระบบหลังบ้าน /admin และสรุปท้าย workshop

บทเรียน 08 — ระบบหลังบ้าน /admin จัดการสถานที่และข้อความติดต่อ

ขั้นสุดท้ายของ session: เปลี่ยนเว็บ “แก้ได้เฉพาะตอนสั่ง AI” ให้เป็นเว็บที่เจ้าของบริหารเองได้ — ระบบหลังบ้านที่ /admin สำหรับจัดการข้อมูลสถานที่ท่องเที่ยว (รวมรูปภาพ) ดูข้อความจาก contact form และจัดการ user ของระบบหลังบ้าน จบด้วยการ deploy ขึ้นโดเมนที่ผูกไว้

เป้าหมายของบทนี้: ได้หลังบ้านครบสามส่วน และปิด workshop ด้วย checklist ความปลอดภัยก่อนเว็บออกสู่โลกจริง

Prompt ที่ใช้

session จริงส่งรหัสผ่าน default ไปใน prompt ตรง ๆ — ในบทเรียนนี้เราปิดบังรหัสและใช้สูตรเดิมกับรหัสของคุณเองแทน (เหตุผลอยู่ในกล่องเตือนด้านล่าง)

ต้องการระบบบริหารจัดการหลังบ้าน /admin ที่จะใช้ในการจัดการข้อมูลสถานที่ท่องเที่ยว ซึ่งจะต้องใส่ข้อมูลที่เป็นรูปภาพแล้วก็ข้อมูลของสถานที่ท่องเที่ยวได้ และส่วนที่ดูว่ามีใครกรอก Contact form มาบ้าง โดยระบบหลังบ้านให้มีระบบจัดการ user ด้วย และต้องการให้มีดีฟอลต์ยูเซอร์สำหรับการใช้งานก็คือ admin / (รหัสถูกปิดบัง — ตั้งรหัสของตัวเองเสมอ) ถ้าเสร็จแล้ว deploy ได้เลย.

prompt นี้กำหนดความต้องการเป็นสามก้อนชัดเจน — (1) จัดการข้อมูลสถานที่ + รูปภาพ (2) ดูข้อความจาก contact form (3) จัดการ user พร้อมบัญชี default — และปิดท้ายด้วยคำสั่ง deploy เลย เมื่อความต้องการชัด เท่านี้ก็พอให้ agent ออกแบบระบบได้ทั้งหมด

อย่าวางรหัสผ่านจริงใน prompt — prompt และบทสนทนาถูกเก็บ ส่งต่อ และนำมาสอนกันได้ (บทเรียนชุดนี้ก็มาจาก session จริง) ให้ตั้งรหัสผ่านหลังจากระบบพร้อม หรือใช้ตัวแปรสภาพแวดล้อม/secret แล้วเปลี่ยนทันทีหลัง login ครั้งแรก

ผลลัพธ์

agent ทำงานยาวนานที่สุดของ session — 22 นาที 32 วินาที — แก้ไฟล์ถึง 42 ไฟล์ (+427 บรรทัด) แล้ว deploy ขึ้นโดเมนที่ผูกไว้ในบท 07

สิ่งที่ได้เพิ่มบนเว็บที่ lay-pai-gun.rawinlab.com:

Checklist ความปลอดภัยก่อนใช้งานจริง

ระบบหลังบ้านคือประตูที่มีค่าที่สุดของเว็บ — เช็กสามข้อนี้เสมอ ก่อนและหลัง deploy ทุกครั้ง:

เพิ่มเติมสำหรับระบบที่โตขึ้น: เปิด two-factor authentication ถ้าผู้ให้บริการรองรับ และแยกบัญชีผู้ใช้เป็นรายคนแทนการใช้บัญชี admin ร่วมกันหลายคน

สรุปท้าย workshop: สิ่งที่ได้และสิ่งที่ควรฝึกต่อ

เมื่อทำครบ 9 ขั้น คุณมีในมือ:

• เว็บไซต์จริงบนโดเมนของตัวเอง พร้อม hero, ระบบค้นหา 20 สถานที่ ไทย–อังกฤษ, ฟอร์มติดต่อที่ส่งถึงอีเมลจริง, การ์ดพร้อมภาพจริงและเครดิต และหลังบ้าน /admin
• กระบวนการทำงานกับ AI agent ที่ทำซ้ำได้: เตรียมเครื่องมือ (skills) → สั่งด้วย prompt ที่มีบริบท → รอจุดที่ agent ต้องถามกลับ → ตรวจผลจริงทุกขั้น → รักษาความปลอดภัยของสิ่งที่ agent แตะไม่ได้ (อีเมล โดเมน token รหัสผ่าน)
• ต้นแบบ prompt 9 ชุด ที่คัดลอกไปปรับกับธุรกิจของคุณได้ทันที

สิ่งที่ควรฝึกต่อ:

1. เปลี่ยนที่นั่งคนขับ — ลองสร้างเว็บหัวข้อที่คุณสนใจจริงด้วย prompt ชุดเดียวกัน แล้วสังเกตจุดที่คุณต้องเสริมบริบทเพิ่มจากตัวอย่างนี้
2. ฝึกอ่านผลตรวจและผลทดสอบ — ลองตั้ง acceptance criteria ง่าย ๆ ก่อนสั่งงาน (เช่น “ค้นหาไทย–อังกฤษได้ กรองจังหวัดได้ ฟอร์มเก็บข้อความสำรอง”) แล้วตรวจทุกข้อเอง
3. ทำความรู้จัก Cloudflare ให้ลึกขึ้น — ต่อยอดจาก static site ไปสู่ Workers, D1 และระบบที่มีข้อมูลจริง

ย้อนดูภาพรวมทั้ง 9 ขั้นได้ที่ บท 00 — ภาพรวม และเปิดผลงานจริงที่ lay-pai-gun.rawinlab.com