นี่ไม่ใช่เรื่องราวการท่องเที่ยว หากคุณเข้ามาเพื่อหาข้อมูลพาโร วัดทักซัง หรือช่วงเวลาที่ควรบินไปภูฏาน ส่วนที่เหลือของเว็บไซต์อยู่ทางนั้น แต่หน้านี้คือเรื่องราวของการสร้างเว็บไซต์นี้ขึ้นมา — เพราะทั้งหมดนี้ ทุกหน้าที่คุณคลิกได้ ถูกออกแบบและสร้างขึ้นเองภายในองค์กรโดยทีมเล็ก ๆ ที่กำกับ AI และผมคิดว่า "วิธีการ" นั้นควรค่าแก่การบันทึกไว้
ผมเขียนในฐานะคนที่ดูแลโครงการนี้ให้กับ OMG Experienceตัวแทนขายทั่วไป (GSA) ที่ได้รับการแต่งตั้งของ Bhutan Airlines ในประเทศไทย ผมไม่ใช่วิศวกรฝั่งหน้าเว็บ ผมไม่ได้จ้างเอเจนซี สิ่งที่ผมมีคือภาพที่ชัดเจนว่าประสบการณ์การจองของสายการบินควรให้ความรู้สึกอย่างไร ความใส่ใจในรายละเอียด และเครื่องมือเขียนโค้ดด้วย AI สมัยใหม่ ทุกวันนี้ผู้คนเรียกสิ่งนี้ว่า "vibe coding": คุณไม่ได้เขียนโค้ดเอง แต่บอกความตั้งใจ ตรวจสอบสิ่งที่ได้กลับมา และตัดสินใจไปเรื่อย ๆ จนกว่าจะถูกต้อง นั่นคือสิ่งที่เกิดขึ้นจริง — พร้อมการตรวจทานอย่างมาก
เริ่มจากระบบ ไม่ใช่จากหน้าเว็บ
สิ่งที่ยั่วยวนใจในการทำเว็บไซต์คือการรีบลงมือทำหน้าแรกทันที เราทำตรงกันข้าม ก่อนที่จะมีหน้าเว็บจริงสักหน้า เราสร้าง design system — "UI kit" ที่กำหนดสี ตัวอักษร ระยะห่าง และทุกองค์ประกอบที่นำกลับมาใช้ซ้ำได้ ไว้ในที่เดียว
นั่นหมายถึงการตั้งชื่อชุดสีของเรา (Dragon Gold, OMG Taupe, Rice Paper, Warm Mist) การล็อกฟอนต์สำหรับพาดหัวและฟอนต์ซานส์ที่สะอาดตาสำหรับเนื้อความ และการกำหนดโทเคนสำหรับระยะห่างและมุม เพื่อไม่ให้มีการด้นสดในภายหลัง จุดประสงค์ของโทเคนคือความน่าเบื่ออย่างตั้งใจ: เมื่อค่าเดียวกันขับเคลื่อนทุกปุ่ม ทุกการ์ด และทุกส่วน เว็บไซต์ทั้งหมดก็ดูเหมือนมาจากมือเดียวกัน ของเราก็เป็นเช่นนั้น
เมื่อหน้าแลนดิงเสร็จสมบูรณ์ตามระบบนั้นแล้ว มันก็กลายเป็นแบบอ้างอิง ทุกหน้าที่สร้างขึ้นหลังจากนั้นต้องสืบทอดระยะขอบ จังหวะของส่วนต่าง ๆ และสไตล์การ์ดแบบเดียวกัน เมื่อใดที่หน้าใหม่เริ่มเบี่ยงเบน คำสั่งก็ง่ายมาก: "ดูหน้าแรกแล้วทำให้เหมือนกัน" กำหนดมาตรฐานให้เสร็จครั้งเดียว แล้วทำให้ทุกอย่างเป็นไปตามนั้น
สร้างทีละหน้า
จากนั้นก็ทำทีละหน้า: แผงจอง จุดหมายปลายทางอย่างพาโร คยา และโกลกาตา ข้อมูลการเดินทาง โปรโมชั่น แพ็กเกจทัวร์ การติดต่อ — และหน้าที่สำคัญที่สุดสำหรับเราในเชิงธุรกิจ Book & Hold.
Book & Hold แตกต่างจากการชำระเงินของสายการบินทั่วไปอย่างแท้จริง และความแตกต่างนั้นเป็นตัวขับเคลื่อนการออกแบบมากมาย เราไม่รับชำระเงินด้วยบัตรออนไลน์ ในฐานะ GSA ทีมสำรองที่นั่งของเราจะยืนยันที่นั่งและราคาสุดท้ายกับคุณก่อน แล้วจึงชำระเงินภายหลังผ่านการโอนเงินผ่านธนาคาร ดังนั้น "ระบบจอง" จึงต้องดูและให้ความรู้สึกเหมือนของจริง — เส้นทาง วันที่ ผู้โดยสาร ชั้นโดยสาร — แต่จบลงด้วยการส่งคำขอ ไม่ใช่การชำระเงิน การทำให้สิ่งนี้ดูน่าเชื่อถือแทนที่จะน่าสงสัยต้องใช้หลายรอบ: ข้อความ "ยังไม่ต้องชำระเงินตอนนี้" ที่ชัดเจน โลโก้ OMG และ Bhutan Airlines แสดงคู่กันเพื่อยืนยันว่าเราเป็นช่องทางอย่างเป็นทางการ และขั้นตอนที่สั้นและซื่อตรง
เพื่อการตัดสินใจที่ดี เราศึกษาผู้ที่เก่งที่สุดในวงการ ด้วยเครื่องมือค้นคว้าข้อมูลบนเว็บที่เชื่อมกับตัวแก้ไขโค้ด เราแยกวิเคราะห์ว่า Emirates, Etihad, Qatar Airways และ Singapore Airlines จัดการรายละเอียดยิบย่อยอย่างไร — แผงจองที่เพรียวบาง ตัวเลือกวันที่แบบรวมเดียว หน้าข้อมูลการเดินทางแบบแท็บ และวิธีที่ FAQ accordion ที่ดีทำงานเมื่อชี้เมาส์ เราไม่ได้ลอกเลียนพวกเขา แต่ยืมรูปแบบที่ได้รับการพิสูจน์แล้วกับนักเดินทางนับล้าน มาปรับให้เข้ากับแบรนด์ของเรา
ตัวอย่างหนึ่งที่ผมยังชอบอยู่: ตารางเที่ยวบินในแต่ละหน้าจุดหมายปลายทางถูกออกแบบให้เหมือนบอร์ดดิงพาส ไปจนถึงขอบรอยปรุ มันเป็นเรื่องเล็ก ๆ แต่เปลี่ยนตารางเวลาที่น่าเบื่อให้กลายเป็นสิ่งที่ให้ความรู้สึกเหมือนสายการบิน
จังหวะที่แท้จริงของงานนี้ดูไม่หวือหวาเท่ากับคำว่า "AI สร้างเว็บไซต์" มันคือวงจร: อธิบายการเปลี่ยนแปลง ให้เอเจนต์ลงมือทำ ถ่ายภาพหน้าจอ แล้ววิจารณ์ — การ์ดใบนี้ไม่ตรงกับไอคอน ช่องว่างก่อน FAQ ใหญ่กว่าที่อื่น ปุ่มนี้ให้ความรู้สึก "AI เกินไป" ด้วยลูกศร สองส่วนที่อยู่ติดกันนี้เป็นสีเดียวกันซึ่งไม่ควรเป็น แล้วก็วนอีกรอบ AI นั้นรวดเร็วและไม่รู้จักเหน็ดเหนื่อย แต่รสนิยม การจัดวาง และความยับยั้งชั่งใจเป็นการตัดสินใจที่ผมต้องทำอยู่ตลอด
Cursor ในฐานะคู่หูสร้างสรรค์
เครื่องมือที่เป็นศูนย์กลางของทั้งหมดนี้คือ Cursorตัวแก้ไขโค้ดที่ขับเคลื่อนด้วย AI สิ่งที่ทำให้มันดีพอที่จะสร้างผลิตภัณฑ์จริงไม่ใช่การเติมข้อความอัตโนมัติ — แต่คือ Agent Mode: คุณมอบหมายงานให้ แล้วมันจะอ่านโค้ดเบส แก้ไขไฟล์ รันคำสั่ง ตรวจผลลัพธ์ และทำซ้ำจนกว่าจะเสร็จหรือชนกับขอบเขตที่ตั้งไว้ มันทำตัวน้อยกว่าแชตบอต และเหมือนวิศวกรรุ่นน้องที่รวดเร็วซึ่งคุณสั่งงานได้มากกว่า
สองฟีเจอร์ที่ทำงานหนักที่สุด อย่างแรกคือ plan mode ที่บังคับให้เอเจนต์ค้นคว้าและเสนอแนวทางก่อนจะแตะต้องอะไร — เพื่อให้ผมจับความคิดที่ไม่ดีได้บนกระดาษแทนที่จะเป็นในโค้ด อย่างที่สองคือ Model Context Protocol (MCP)มาตรฐานเปิดที่ให้ตัวแก้ไขโค้ดเข้าถึงเครื่องมือจริง ๆ ได้: ตัวรวบรวมข้อมูลบนเว็บที่ผมกล่าวถึง เบราว์เซอร์ที่มันควบคุมเพื่อเปิดหน้าและถ่ายภาพหน้าจอเองได้ การค้นหาภาพ ไปจนถึงบัญชีคลาวด์ของเรา เอเจนต์สามารถดูเว็บไซต์คู่แข่ง ดูหน้าเว็บที่เรนเดอร์ของเราเอง และลงมือทำกับทั้งสองอย่างในวงจรเดียวกัน
ผมจะพูดตรง ๆ เรื่องข้อจำกัด เพราะกระแสความนิยมมักข้ามส่วนนี้ไป AI ไม่เคยตัดสินใจว่าแบรนด์ควรให้ความรู้สึกอย่างไร ลูกค้าต้องการอะไรจริง ๆ หรือเมื่อใดที่บางอย่าง "ดีพอแล้ว" มันจัดวางผิด ออกแบบเกินความจำเป็น และสร้างบั๊ก — โดยเฉพาะครั้งแรกที่ iPhone จริงมาเจอกับเลย์เอาต์ของเรา มันเป็นตัวคูณที่ยอดเยี่ยมในการลงมือทำ แต่เป็นตัวแทนที่แย่สำหรับการใช้วิจารณญาณ คุณค่าอยู่ที่การจับคู่กัน: การกำกับของผม กับความเร็วของมัน
ทำให้เป็นจริงบน AWS
ชุดไฟล์ HTML ที่สวยงามยังไม่ใช่เว็บไซต์ จนกว่ามันจะออนไลน์ รวดเร็ว และเชื่อถือได้ มีสองทางเลือกที่กำหนดสิ่งนั้น
อย่างแรกคือ Astro เป็นเฟรมเวิร์ก สำหรับเว็บไซต์เนื้อหาอย่างของเรา — หลายหน้า แต่ไม่ค่อยมีการโต้ตอบแบบแอป — Astro ส่งออกเป็น HTML ธรรมดาเป็นส่วนใหญ่ พร้อม JavaScript เพียงเล็กน้อย นั่นทำให้หน้าเว็บเร็วและเบา ซึ่งเป็นสิ่งที่คุณต้องการสำหรับนักเดินทางที่ใช้โทรศัพท์และเครือข่ายมือถือที่ไม่เสถียร เราจึงย้าย design system ที่สร้างด้วยมือเข้าสู่โปรเจกต์ Astro ที่สร้างทุกหน้าจากคอมโพเนนต์ของเรา
อย่างที่สองคือ AWS สำหรับโฮสติง ผู้ชมส่วนใหญ่ของเราอยู่ในประเทศไทย ค้นหาบนโทรศัพท์ และเราต้องการให้เว็บไซต์ให้ความรู้สึกทันใจและไม่ล่ม AWS ให้บริการเว็บไซต์ผ่านเครือข่ายกระจายเนื้อหาระดับโลก ซึ่งภายในกลางปี 2026 ทำงานจาก จุดให้บริการกว่า 750 แห่งใน 100+ เมืองใน 50+ ประเทศ — ดังนั้นหน้าเว็บจึงถูกส่งจากตำแหน่งที่ใกล้ผู้เข้าชมแทนที่จะเป็นเซิร์ฟเวอร์ที่อยู่ไกลเพียงเครื่องเดียว เพราะเป็นเว็บไซต์แบบสแตติกที่อยู่เบื้องหลังเครือข่ายนั้น จึงแทบไม่มีเซิร์ฟเวอร์แอปพลิเคชันที่จะล่มเมื่อมีโหลดสูง ชั้นจัดเก็บข้อมูลเพียงอย่างเดียวก็ออกแบบมาให้มีความทนทานระดับสิบเอ็ดเก้า และปริมาณการเข้าชมถูกรองรับที่ขอบเครือข่าย ในทางปฏิบัติ: เร็วสำหรับประเทศไทย ทนทานในช่วงพีค และประหยัดในการดูแล
เทคโนโลยีเบื้องหลังเติบโตขึ้นเมื่อเราจำเป็นต้องใช้ ไม่ใช่ก่อนหน้านั้น:
- Amplify + CloudFront โฮสต์และกระจายเว็บไซต์ที่สร้างเสร็จแล้ว พร้อม HTTPS และไปป์ไลน์การสร้างและเผยแพร่ที่เหมาะสม
- DynamoDB จัดเก็บสิ่งที่เราต้องเปลี่ยนแปลงจริง ๆ — ราคาค่าโดยสารและเนื้อหาบล็อก — เพื่อให้สามารถสร้างเว็บไซต์ใหม่ด้วยข้อมูลล่าสุดได้
- Lambda รับคำขอ Book & Hold แพ็กเกจ และการติดต่อสอบถาม; SES ส่งอีเมลยืนยัน (ถึงลูกค้าและถึงทีมงานของเรา)
- Cognito รักษาความปลอดภัยการเข้าสู่ระบบสำหรับ แผงผู้ดูแลระบบ ของเราเอง — ระบบ CMS และ mini-CRM ภายในองค์กรขนาดเล็กที่เราใช้แก้ไขราคา เผยแพร่บทความ และดูทุกคำขอที่เข้ามา
- ไปป์ไลน์การสร้าง (CodeBuild) จะรวมราคาและโพสต์ล่าสุดเข้าไปในเว็บไซต์สแตติกทุกครั้งที่เราเผยแพร่ ดังนั้นการแก้ไขราคาในแผงผู้ดูแลจะไหลกลับไปทั่วทั้งเว็บไซต์อย่างเงียบ ๆ
- สำหรับบทความท่องเที่ยว เราเชื่อมต่อกับ Gemini ของ Google เพื่อช่วยร่างเนื้อหาและสร้างภาพประกอบที่เข้ากัน — โดยมีคนตรวจแก้ทุกชิ้นก่อนเผยแพร่
ไม่มีสิ่งใดในนี้แปลกใหม่ในตัวเอง สิ่งที่ผมภูมิใจคือทีมที่ไม่มีแผนกวิศวกรรมแบบดั้งเดิมสามารถประกอบมันขึ้นเป็นสิ่งที่กลมกลืนและอยู่ในระดับใช้งานจริง และเข้าใจว่าแต่ละชิ้นส่วนประกอบเข้ากันอย่างไร
20% ที่ไม่หวือหวา
ช่วงสุดท้ายคือส่วนที่ไม่มีใครถ่ายภาพ การย้ายโดเมนจริงมาที่ AWS หมายถึงการโอนออกจากโฮสต์เดิมและสร้าง DNS ขึ้นใหม่ โดยไม่ ทำให้อีเมลบริษัทของเราล่มแม้แต่นาทีเดียว — ซึ่งหมายถึงการจำลองทุกระเบียนอีเมล (MX, SPF, DKIM, DMARC) ให้ถูกต้องเป๊ะ ตรวจสอบกับเซิร์ฟเวอร์ใหม่ แล้วจึงค่อยสับสวิตช์ หากทำผิดพลาด กล่องจดหมายของสายการบินก็จะดับ เราจึงจัดการมันด้วยความระมัดระวังอย่างที่มันสมควรได้รับ
จากนั้นก็มีการตรวจสอบบนมือถือ การเข้าชมส่วนใหญ่ของเราอยู่บนโทรศัพท์ ดังนั้นทุกหน้าในราว 20 หน้าของเราจึงถูกตรวจสอบบนขนาดอุปกรณ์จริง ทั้งแนวตั้งและแนวนอน เพื่อค้นหาระยะห่างที่คับแคบ ตัวควบคุมที่ไม่อยู่กึ่งกลาง และส่วนที่ควรเปลี่ยนเป็นคารูเซลปัดได้บนหน้าจอเล็ก เรายังทำให้หมายเลขอ้างอิงการจองเป็นมิตรกับคน — รหัสสั้น ๆ แบบ OMG-#### แทนที่จะเป็นสตริงทางเทคนิคที่ยาว — เพราะคนจริง ๆ ต้องอ่านมันออกเสียงทางโทรศัพท์
สิ่งที่ผมอยากบอกคุณ
เมื่อปีที่แล้ว โครงการแบบนี้ — เว็บไซต์หลายหน้าเต็มรูปแบบ ขั้นตอนการจอง แผงผู้ดูแลที่สร้างเอง โครงสร้างพื้นฐานคลาวด์จริง การย้ายโดเมนสด — คงต้องใช้เอเจนซี งบประมาณ และการโต้ตอบไปมาหลายเดือน เราทำมันเองภายในองค์กร โดยกำกับ AI ด้วยความมุ่งมั่นในสองสิ่ง: เริ่มจากระบบ ไม่ใช่จากหน้าจอและ คอยตัดสินใจในสิ่งที่ AI ทำไม่ได้.
เครื่องมือเหล่านี้น่าทึ่งและดีขึ้นทุกสัปดาห์ แต่เว็บไซต์นี้ดีเพราะมีคนใส่ใจช่องว่างก่อน FAQ และสีของสองส่วนที่อยู่ติดกัน — ไม่ใช่เพราะ AI ทำ นั่นคือบทเรียนที่ซื่อตรงจากการสร้างสิ่งนี้: AI ขจัดข้ออ้างที่ว่าคุณสร้างมันไม่ได้ แต่ไม่ได้ขจัดความรับผิดชอบที่จะรู้ว่า "ดี" หน้าตาเป็นอย่างไร
หากคุณอยากเห็นผลลัพธ์ ก็คือเว็บไซต์ที่คุณกำลังใช้อยู่นี้ เริ่มที่ หน้าแรกหรือไปที่ Book & Hold แล้วดูขั้นตอนที่เราทุ่มเทกับมัน