Lab — ให้ AI ช่วย research ข้อมูล สร้าง website brief และ brand kit

ต่อยอดโจทย์รายวิชาได้ใน สร้างเว็บไซต์หลักสูตรด้วย Codex แบบทีละขั้น พร้อม prompt ที่รันจริงและภาพผลลัพธ์แต่ละช่วง

AI Web Studio — ออกแบบและพัฒนาเว็บไซต์ด้วย AI · ส่วนหนึ่งของ 977-121 Module: Website Design and Development, มหาวิทยาลัยสงขลานครินทร์ วิทยาเขตภูเก็ต (Prince of Songkla University, Phuket Campus)

Lab เต็มประมาณ 150 นาทีสำหรับ prework / เรียนต่อด้วยตัวเอง ผู้สอนเลือกสาธิต inventory → research → brief 20 นาทีในช่วง design 30 นาทีที่มีอยู่ได้ ตาราง workshop ยังคง 2 วัน วันละ 4 ชั่วโมง รวม 8 ชั่วโมง รวมพักวันละ 10 นาที ไม่ต้องทำทุกขั้นให้จบในห้อง

เป้าหมายคือใช้ข้อมูลที่มีทำ brief ซึ่งย้อนตรวจแหล่งที่มาได้ แล้วพัฒนาต่อเป็น mini brandbook, UI icons, key visual และชุดส่งต่อสำหรับสร้างเว็บไซต์ ผู้เรียนต้องอธิบายได้ว่าอะไรมีหลักฐาน อะไร AI เสนอ และอะไรยังต้องถามเจ้าของ

เปิดตัวอย่างก่อนเริ่ม

• HUSH brand kit — เปิด style board และไฟล์ตัวอย่าง ต่อยอดจาก เว็บสินค้า HUSH
• Prompt ฉบับเต็ม P0–P8 สำหรับคัดลอกทำซ้ำทุกขั้น
• ผล research และแหล่งทางการ ตรวจเมื่อ 11 กันยายน 2026
• บทเรียน 04: Design และ assets และ บทเรียน 07: เว็บสินค้า GSAP

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

ผลงานที่ต้องส่ง

Logo คืออัตลักษณ์องค์กร, UI icon สื่อความหมายหรือการกระทำ, key visual เป็นภาพหลักของหน้า/แคมเปญ และ favicon/OG image เป็น asset ตามช่องทาง อย่าใช้คำเหล่านี้แทนกัน หากงานต้องมีโลโก้ใหม่ให้แยกเป็นข้อเสนอที่เจ้าของต้องพิจารณา Lab นี้ฝึก UI icons และ key visual โดยใช้ชื่อแบรนด์เดิม

1. รวบรวมข้อมูลที่มี — 10 นาที

เลือกเว็บไซต์ของตน หรือใช้ HUSH ตั้งโฟลเดอร์ brand-lab/ แล้วรวบรวม brief เก่า, notes จากเจ้าของ, หน้าเว็บปัจจุบัน, catalog/ราคา, screenshots, brandbook, logo, ภาพ และข้อจำกัดของระบบ ระบุไฟล์ที่ AI อ่านได้จริงและไฟล์ที่ยังไม่ได้รับ ใช้ P0 สร้าง source inventory ก่อนค้นเว็บ

สำหรับบริษัท Rawinnipa ให้ยึด brandbook ที่ /home/dev/projects/rawinnipa-brandbook ในเครื่องผู้สอน โดยใช้ฉบับที่เจ้าของอนุมัติ ผู้เรียนใช้ไฟล์หรือ excerpt ที่ได้รับอนุญาต ไม่คาดว่า cloud chat จะอ่าน local path นี้ได้เอง ส่วน HUSH เป็นแบรนด์สมมติของตัวอย่างสินค้า ใช้ชุดสี/รูปแบบ HUSH จาก source เดิม แยกจากอัตลักษณ์ Rawinnipa ของเว็บไซต์หลักสูตร

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

2. ใช้ research prompt สร้าง evidence — 25 นาที

เริ่มจากคำถามที่จะเปลี่ยนแบบเว็บได้จริง เช่น “ผู้ใช้ต้องเห็นข้อมูลอะไรจึงเลือกสินค้าได้” หรือ “เรายืนยันคำกล่าวใดบน hero ได้แล้ว” แยกแหล่งข้อมูลสามกลุ่ม: เจ้าของ/ระบบของเรา, เอกสารทางการสำหรับมาตรฐานและเครื่องมือ, และเว็บคู่แข่งสำหรับสังเกตรูปแบบที่เผยแพร่สาธารณะ ข้อมูลคู่แข่งไม่ยืนยันกลุ่มลูกค้าหรือยอดขายของเรา

ใน ChatGPT: หากบัญชีมี Deep Research ให้เลือกเครื่องมือ แนบข้อมูลที่อนุญาต ระบุเว็บไซต์ที่ใช้ได้ ตรวจ research plan แล้วจึงรัน เปิด citations ของข้อค้นพบสำคัญและเก็บรายงานพร้อมแหล่งที่มา ตัวเลือกเว็บไซต์/แอปและโควตาขึ้นกับบัญชี OpenAI Academy: Deep Research

ใน Claude: ใช้ Research พร้อม web search เมื่อบัญชีมีให้ใช้ แนบข้อมูลและกำหนดขอบเขตเดียวกัน integrations ต้องมีสิทธิ์พร้อมก่อนจึงจะใช้ข้อมูลได้ เมื่อรายงานเสร็จให้เปิด source links ตรวจทีละ claim Claude Research, Claude web search

หากไม่มี Research: ค้นและเปิดเอกสารเอง เก็บข้อความ/URL/วันที่ แล้วส่งให้ AI สังเคราะห์ด้วย prompt เดิม ระบุว่าใช้เฉพาะข้อมูลที่แนบ ห้ามเขียนว่าได้ค้นเว็บหากเครื่องมือไม่มี web access การแนบไฟล์ไม่ได้แปลว่าเชื่อม MCP แล้ว

คัดลอก P1 นี้และแทนช่อง <...> ก่อนใช้:

ช่วย research เพื่อเตรียม website brief สำหรับ <ชื่อโครงการ>
เป้าหมายการตัดสินใจ: <ผู้ใช้ควรเข้าใจอะไรและทำอะไรบนเว็บไซต์>
ข้อมูลตั้งต้น: <แนบ inputs.md พร้อมไฟล์/ข้อความที่อนุญาต>
ขอบเขตเว็บที่อนุญาต: <official URLs/domains หรือแหล่งที่เจ้าของกำหนด>
ช่วงเวลาข้อมูลที่ต้องการ: <วันที่หรือช่วงเวลา>
สิ่งที่ยังไม่รู้: <รายการ GAP จาก P0>

ก่อนค้น สรุปคำถามวิจัย 3–5 ข้อ และแผนค้นที่ผูกกับการตัดสินใจของเว็บไซต์
ใช้ข้อมูลของเจ้าของเพื่อยืนยันข้อเท็จจริงของธุรกิจ
ใช้แหล่งทางการภายนอกเพื่อศึกษาบริบท รูปแบบเว็บไซต์ มาตรฐาน และข้อจำกัดเครื่องมือ
ถ้าดูเว็บคู่แข่ง ให้บอกว่าเป็นสิ่งที่สังเกตบนเว็บ ไม่ใช่หลักฐานว่ายอดขายหรือ UX ดีกว่า
ห้ามนำคำอ้างของคู่แข่งมาเป็นข้อเท็จจริงของธุรกิจเรา

ส่ง research.md และ evidence.csv โดยแต่ละข้อมี:
ID | ข้อค้นพบ | FACT/INFERENCE/PROPOSAL/GAP | source ID + URL/ไฟล์และตำแหน่ง
วันที่เผยแพร่ถ้าทราบ + วันที่เข้าถึง | ข้อจำกัด | ผลต่อ brief
เปิดอ่านแหล่งที่อ้างจริง ตรวจว่าแหล่งสนับสนุนข้อค้นพบโดยตรง
แยกข้อมูลที่เจ้าของให้จากข้อมูลภายนอก และชี้เมื่อสองแหล่งขัดกัน
อย่าให้จำนวน citation ทดแทนคุณภาพของหลักฐาน

ท้ายรายงานสรุป: กลุ่มผู้ใช้ที่มีหลักฐานหรือเป็นสมมติฐาน,
งานสำคัญของหน้า, เนื้อหาที่พร้อมใช้, เนื้อหาที่ต้องขอเพิ่ม,
ข้อจำกัด brand/accessibility/assets และ 2–3 ทางเลือกที่มีเหตุผลจากหลักฐาน
อย่าสร้าง brandbook หรือเลือกทิศทางแทนเจ้าของในขั้นนี้
หากไม่มี web access ให้ทำรายงานจากไฟล์ที่มี พร้อมเขียนว่าไม่ได้ทำ web research
และระบุ URL/คำค้นที่ควรตรวจต่อ ห้ามสร้าง citation หรือผลสัมภาษณ์ขึ้นเอง

หลังได้รายงาน ใช้ P2 ตรวจข้อค้นพบที่กระทบ audience, ราคา, positioning และ product claims ก่อน เปิดแหล่งจริงและแก้ evidence.csv ด้วย ID เดิม เก็บข้อขัดแย้งไว้ หากแหล่งรองรับแค่บางส่วนให้ลดระดับหรือเขียน GAP การให้ AI อีกตัวเห็นด้วยไม่ใช่หลักฐานใหม่

3. สรุป website brief — 15 นาที

ส่ง inputs.md + research.md + evidence.csv ที่ตรวจแล้วเข้า P3 ให้สร้าง brief 1–2 หน้า: เป้าหมาย, audience/งานของผู้ใช้, value proposition, CTA หลักและผลหลังคลิก, sitemap/sections, เนื้อหาที่พร้อม, brand constraints, form/error/empty states, เกณฑ์ตรวจรับ และคำถามเจ้าของ

ใช้แนว Discover → Define ก่อนพัฒนา visual direction เพื่อให้ brief เกิดจากข้อมูลและการสังเคราะห์ ไม่ใช่เดาสิ่งที่ลูกค้าต้องการ Design Council: Double Diamond

ตัวอย่าง HUSH: ชื่อ HUSH ONE เป็นชื่อเล่าเรื่องบนหน้า ส่วน catalog/API ใช้ ID headphones และชื่อ “หูฟัง Studio One” ให้ทำ mapping ไว้ ไม่สร้างสินค้าใหม่เพื่อให้ชื่อตรงกัน ราคาใน seed เป็นข้อมูลตัวอย่าง; เมื่อทำร้านจริงให้แสดงราคาจาก API ส่วนข้อความ 40 mm / 30 ชั่วโมงเป็น concept copy สมมติ ไม่ใช่ผลทดสอบสินค้า การเลือก audience และน้ำเสียงใหม่ยังเป็นข้อเสนอ หากไม่มีข้อมูล warranty ให้แสดง GAP แทนคำว่า “รับประกัน 2 ปี”

ในชุดตัวอย่างใช้ S1 สำหรับ HTML/CSS ของเว็บ, S2 สำหรับ seed catalog, S3 สำหรับข้อกำหนด HUSH ใน DESIGN.md และ S4 สำหรับที่มาภาพ เช่น E01 ผูกชื่อ HUSH ONE กับ product ID ผ่าน S1/S2, E09 เป็น audience proposal และ E14 เป็นช่องว่างหลักฐาน performance เปิด inputs.md และ research.md เพื่อดู source locator และขอบเขตของแต่ละแหล่ง

เปิด brief ตัวอย่าง เทียบกับ evidence ledger แล้วเลือกหนึ่งประโยคใน brief ไล่กลับถึง source ที่ระบุ หากทำไม่ได้ให้แก้ก่อนสร้างภาพ

4. จาก brief สู่ mini brandbook — 20 นาที

ใช้ P4 โดยแนบ brandbook เดิมถ้ามี ให้ AI เสนอทิศทาง 2–3 แบบพร้อมเหตุผลและเลือกหนึ่งแบบสำหรับทดลอง บันทึกผู้เลือกและสถานะ draft/proposed ให้ตรงจริง งานนักเรียนไม่เท่ากับการอนุมัติจากเจ้าของบริษัท

ฉบับที่เลือกต้องมี positioning/หลักฐาน, voice พร้อม do/don’t, logo/wordmark ที่อนุญาต, palette, typography ไทย/ละติน, spacing/radius, UI icons, imagery และ component ตัวอย่าง ให้แยกกฎเดิมออกจากค่าที่เสนอเพิ่ม ใช้ semantic tokens เช่น surface, text, action พร้อมค่าตาม mode เพื่อส่งต่อได้ Figma: Variables

ดู HUSH mini brandbook และ tokens.css สำหรับเว็บไซต์หลักสูตรให้คง Light default และ Dark ตามข้อกำหนด ส่วน style board HUSH ใช้ทิศทางของตัวอย่างสินค้า ตรวจคู่สีข้อความ/พื้นจริง และอย่าอ้างว่าผ่าน WCAG ทั้งเว็บไซต์จากการตรวจสีเพียงคู่เดียว

5. ให้ AI ช่วยสร้าง UI icon system — 20 นาที

ใช้ P5 ให้ coding agent เขียน SVG ต้นฉบับ 4 ชิ้น: headphones, speaker, battery และ bag กำหนด viewBox="0 0 24 24", stroke 2, rounded caps/joins และ currentColor ให้สม่ำเสมอ ตรวจภาพที่ 24 และ 48 px รวมถึงรูปร่างที่คนอาจตีความผิด หลักการ grid และ alignment ช่วยให้ชุด icon มีน้ำหนักใกล้กัน Carbon: Icon contribution

ใช้ข้อความกำกับ icon เมื่อทำได้ ปุ่มที่มีแต่ icon ต้องมีชื่อที่สื่อการกระทำ เช่น “เปิดกระเป๋า” และ focus ที่เห็นได้ ส่วน icon ตกแต่งข้าง label ให้ซ่อนจาก screen reader เพื่อลดการอ่านซ้ำ อย่าเรียกปุ่มปิดว่า “X” W3C: SVG icons, W3C: Accessible names

ไฟล์ SVG ที่ใช้ผ่าน <img> ต้องใส่ alt ที่ element นั้น; currentColor ภายในไฟล์ภายนอกไม่ได้รับสีจาก CSS ของหน้าหลักโดยอัตโนมัติ หากต้องเปลี่ยนสีตามโหมดใช้ inline SVG ที่ตรวจแล้ว ดูรูปแบบจริงใน style board การสร้างภาพ icon ด้วยโมเดลภาพให้ผลเป็น raster จึงยังต้องมีงานออกแบบ vector ก่อนอ้างว่าส่ง SVG system แล้ว

6. สร้าง key visual สำหรับ website และ mobile — 20 นาที

ใช้ P6 พร้อม reference ที่มีสิทธิ์ใช้ ระบุสินค้า/สิ่งที่ห้ามเปลี่ยน, mood, palette, แสง, composition, ขนาด และพื้นที่สำหรับข้อความ สร้าง desktop 3:2 และ mobile 4:5 โดยจัดองค์ประกอบให้เหมาะแต่ละจอ ไม่พึ่ง crop กลางภาพอย่างเดียว ให้หัวเรื่อง/ราคา/CTA เป็น HTML เพื่อแก้ข้อความและรองรับการอ่านได้

ใช้เครื่องมือสร้างภาพใน Codex ตาม workflow gpt-image-2 เมื่อมีให้ใช้ตามการตั้งค่าของเครื่องมือ หาก UI ไม่เปิดเผยชื่อ model ให้บันทึกชื่อเครื่องมือที่ใช้จริง ไม่เดาว่าได้รัน model ใด OpenAI: GPT Image 2

ตัวอย่าง prompt พร้อมข้อกำหนด HUSH อยู่ใน keyvisual-prompt.md และ P6 ฉบับแก้ใช้กับเว็บไซต์อื่น บันทึก prompt และไฟล์ผลลัพธ์ลง assets.csv ตรวจรูปทรงสินค้า การตัดขอบ และความหมายของภาพก่อนใช้ หากภาพเป็นเพียงฉากตกแต่งใช้ alt ว่าง แต่ภาพที่สื่อสินค้า/สาระต้องมีข้อความทดแทนตามหน้าที่ W3C: Images Tutorial

สถานะตัวอย่างที่ให้: HUSH kit ใช้ภาพ headphones.webp ที่มีอยู่ในหลักสูตรแล้วจัด composition ด้วย HTML/CSS ไม่ได้สร้างภาพ raster ใหม่ใน Lab ฉบับนี้ keyvisual-prompt.md เป็น prompt สำหรับฝึกทำซ้ำ ชุด icon เป็น SVG ที่สร้างจากโค้ด อย่ารายงานว่ามี output จาก image model หากยังไม่ได้รันจริง

7. ทำ style board และส่งต่อเว็บไซต์ — 20 นาที

ใช้ P7 ให้สร้างหน้าเดียวที่เห็นสี typography, icon, hero, card, CTA, form/error/empty states และ asset usage จัด handoff เป็นตาราง section → evidence ID → copy → token → asset → interaction → acceptance check ให้ผู้พัฒนาอ่านแล้วรู้ว่าต้องทำอะไร ไม่ได้มีเพียงภาพตัวอย่าง

ดู handoff ของ HUSH แล้วส่ง brief/brandbook/tokens/assets ไปใช้กับ Claude Design, Stitch หรือ Figma MCP โดยใช้ prompt ของเครื่องมือนั้นเพิ่มเติม หากเครื่องมือเข้าถึงไฟล์ไม่ได้ให้แนบไฟล์ที่อนุญาตจริงและบอกว่าเป็น file handoff

กลับไปที่ เว็บสินค้า GSAP โดยรักษา product ID, API pricing และ checkout behavior เดิม สำหรับผู้ที่ต้องการออกแบบ mobile app ให้ทำต่อจาก Website → Mobile App และปรับ navigation/interaction ให้เหมาะกับงานของผู้ใช้ ไม่ใช่ย่อ screenshot ของ desktop

8. ตรวจรับและอธิบายเหตุผล — 20 นาที

ใช้ P8 รีวิวงาน แล้วผู้เรียนเปิดแหล่งจริงและทดสอบเอง ตรวจทุก claim สำคัญถึง evidence, draft/owner decisions, สี/ตัวอักษร/เส้น icon, key visual desktop/mobile, alt, keyboard, form states และราคาจากระบบ บันทึกสิ่งที่ทดสอบจริงแยกจากสิ่งที่ยังไม่ได้ทดสอบ

ส่งโฟลเดอร์งานพร้อมสรุปหนึ่งหน้า: “ข้อมูลใดเปลี่ยนแบบเว็บของเรา”, “ข้อเสนอใดเลือกเพราะอะไร” และ “เจ้าของต้องตอบอะไรต่อ” ตัวอย่าง HUSH เป็นคำตอบประกอบการเรียนจาก source ที่มี ไม่ใช่หลักฐานว่าได้สัมภาษณ์ผู้ใช้หรือทำ market research ของแบรนด์จริง ดาวน์โหลด source ของหลักสูตรได้จาก เอกสารและไฟล์ประกอบ

ฝึกต่อด้วย brandkit

เมื่อมี brief และทิศทางแบรนด์แล้ว ใช้ Lab brandkit สร้าง overview board 3 × 3 เพื่อฝึกส่ง prompt พร้อม reference, ตรวจผลราย panel และทำ website handoff มี ภาพ HUSH ที่สร้างจริงพร้อมไฟล์ต้นทาง สำหรับเปิดเทียบ เป็น Lab เสริม 60–90 นาที ไม่เพิ่มชั่วโมง workshop