Lab — สร้างเว็บไซต์หลักสูตรด้วย Codex แบบ step by step

ภาพและ transcript ใน walkthrough นี้เก็บ snapshot เดิม 11 บทเรียนไว้ตามการทดลองจริง ปัจจุบันคลังคอร์สเพิ่ม บท 11 — บริการ Cloudflare เป็นบทที่ 12 และมี Lab RW Web Skills สำหรับฝึก workflow เพิ่มเติม

Lab นี้พาผู้เรียนสร้างเว็บไซต์ตัวอย่างสำหรับ AI Web Studio — ออกแบบและพัฒนาเว็บไซต์ด้วย AI ซึ่งเป็นหน่วย workshop ส่วนหนึ่งของ 977-121 Module: Website Design and Development, มหาวิทยาลัยสงขลานครินทร์ วิทยาเขตภูเก็ต (Prince of Songkla University, Phuket Campus) ตั้งแต่ข้อมูลตั้งต้นจนเป็นหน้าเว็บที่ตรวจได้ ชื่อ module และสถาบันตรวจเทียบได้จาก หน้าหลักสูตร Digital Engineering ของวิทยาลัยการคอมพิวเตอร์ ม.อ. ภูเก็ต

ตัวอย่างนี้เป็น สื่อประกอบการเรียน ไม่ใช่เว็บไซต์หรือบริการทางการของมหาวิทยาลัย ไม่สร้างตรามหาวิทยาลัย ชื่อผู้สอน จำนวนหน่วยกิต เกณฑ์คะแนน ตารางภาคเรียน ช่องทางสมัคร หรือระบบ login ขึ้นเอง เวลา 2 วัน × 4 ชั่วโมง รวม 8 ชั่วโมงและพักวันละ 10 นาที หมายถึง workshop ใน repository นี้ ไม่ใช่ชั่วโมงทั้งหมดหรือคำอธิบายรายวิชาฉบับมหาวิทยาลัย

เวลาทำ Lab เต็มประมาณ 160–180 นาทีสำหรับเรียนต่อด้วยตัวเอง ผู้สอนสามารถเลือกสาธิตบางช่วงใน workshop โดยไม่เพิ่มเวลารวม 8 ชั่วโมง เป้าหมายไม่ใช่ให้ Codex สร้างทุกอย่างในคำสั่งเดียว แต่ให้เห็นว่าแต่ละ prompt เปลี่ยน artifact ใด และผู้เรียนตรวจผลอย่างไรก่อนสั่งขั้นถัดไป

ผลงานเมื่อจบ Lab

ผู้เรียนจะมี:

• source inventory ที่แยก FACT, PROPOSAL และ GAP
• website brief ที่อ้างกลับไปยังข้อมูลตั้งต้น
• semantic HTML ก่อนแต่งภาพ
• responsive Light/Dark design ตามข้อกำหนด Rawinnipa สำหรับสื่อหลักสูตร
• JavaScript สำหรับค้นหาและกรองบทเรียน Day 1 / Day 2 / ทั้งหมด
• QA record พร้อม prompt แก้ไขรอบสุดท้าย
• release packet ที่มี source, prompt, transcript และภาพแต่ละช่วง

เปิด เว็บไซต์ตัวอย่างฉบับสุดท้าย และใช้หน้านี้อ่านลำดับการสร้าง อย่าดูเฉพาะภาพสุดท้าย เพราะหลักฐานสำคัญอยู่ที่ prompt, diff และจุดตรวจของแต่ละรอบ

แผนเวลา

Artifact ที่ใช้ติดตามการทำงาน

ภาพ Terminal ใน Lab แสดง Codex CLI ผ่าน terminal viewer แบบอ่านอย่างเดียว ไม่ใช่หน้าต่าง Codex Desktop ส่วนภาพ browser เป็นผลของหน้าเว็บที่ preview จริง Transcript และภาพมีไว้ช่วยตรวจย้อนหลัง แต่ไม่แทนการอ่านไฟล์หรือรัน test

ตัวอย่างใช้ codex exec --json เพื่อเก็บ event stream เป็น JSON Lines (JSONL) แล้วเลือกเฉพาะเหตุการณ์ที่ช่วยอธิบายการทำงานมาแสดง เอกสารทางการระบุว่า stream นี้อาจมี event ของข้อความ agent, command, file change และ tool call; ผู้เรียนจึงต้อง redact path หรือข้อมูลลับก่อนเผยแพร่ ดู Codex non-interactive mode การมี JSONL ยืนยันว่า event ถูกบันทึก แต่ไม่ยืนยันว่าโค้ดหรือหน้าเว็บถูกต้อง

เริ่มจากศูนย์: ดาวน์โหลด เปิด Terminal และเตรียมพื้นที่ฝึก

1. เปิดหน้า Resources ของหลักสูตร แล้วดาวน์โหลด Source ZIP
2. แตก ZIP จะได้โฟลเดอร์ ai-web-studio/ จากนั้นเปิด Terminal ที่โฟลเดอร์นี้ ไม่ใช่ที่ Downloads หรือโฟลเดอร์ชั้นนอก
3. ตรวจว่าเห็น package.json, README.md, public/ และ docs/ แล้วติดตั้ง dependency ตาม lockfile

ตัวอย่าง Bash บน Linux/macOS/WSL หลังแตก ZIP แล้ว:

cd /path/to/ai-web-studio
pwd
ls
npm ci
npm run setup
npm run build

npm run setup สร้าง local secret ใน .dev.vars ตาม README อย่าเปิด คัดลอก หรือถ่ายค่า secret ลงภาพ หากต้องการตรวจ baseline ให้เปิด server ด้วย:

npm run preview

เปิด http://127.0.0.1:3320/ แล้วหยุดด้วย Ctrl+C เมื่อดูเสร็จ พอร์ต 3320 และ inspector 3322 เป็นพอร์ตที่ project จองไว้ตาม shared-infra; อย่าเปลี่ยนไปใช้พอร์ตของ project อื่น คำสั่งทางเลือก npm run dev จะรัน build แล้วเปิด preview เดียวกัน จึงใช้แทน npm run build ตามด้วย npm run preview ได้

สร้าง workspace แยกเพื่อไม่ทับตัวอย่างสำเร็จ

กลับมาที่ root ai-web-studio/ แล้วสร้าง practice/psu-course/ คัดลอกเฉพาะ input snapshot ก่อน clarification และ scope เข้าไป:

mkdir -p practice/psu-course
cp public/labs/course-website-build/stages/01/inputs.md practice/psu-course/inputs.md
cp public/labs/course-website-build/stages/01/scope.txt practice/psu-course/scope.txt
ls practice/psu-course

ถ้าไม่ได้ใช้ Bash/WSL ให้สร้างโฟลเดอร์และ Copy/Paste สองไฟล์นี้ด้วย file manager หรือ editor โดยรักษาชื่อ inputs.md และ scope.txt จุดสำคัญคือ Codex แก้ได้เฉพาะ workspace ฝึก และ source ตัวอย่างสุดท้ายใน /examples/course-website/ ยังไม่ถูกทับ

เลือกวิธีส่ง prompt

วิธีโต้ตอบ เหมาะกับผู้เริ่มต้น: เปิด session ที่ workspace ฝึก แล้วคัดลอก prompt ของแต่ละขั้น จากลิงก์ในแต่ละขั้นวางทีละชุด รอให้งานรอบหนึ่งจบและตรวจไฟล์ก่อนส่งรอบถัดไป

codex -C practice/psu-course

วิธี CLI/JSONL สำหรับผู้ที่ต้องการ transcript: ตัวอย่างนี้ส่ง prompt 01 ผ่าน stdin และบันทึก event stream โดยไม่ให้ Codex แตะ source ตัวอย่างสุดท้าย:

codex exec -C practice/psu-course \
  --sandbox workspace-write \
  --json - \
  < public/labs/course-website-build/prompts/01-brief.txt \
  > practice/psu-course/01-events.jsonl

คำสั่งนี้เป็นตัวอย่างรูปแบบหนึ่ง ไม่บังคับให้ผู้เรียนใช้ JSONL ทุกขั้น ผู้ใช้ interactive สามารถเก็บ prompt files กับภาพ Terminal แทนได้ ตรวจไฟล์ใน practice/psu-course/ ทุกครั้งก่อนเดินต่อ และอย่าส่ง credential หรือเนื้อหา JSONL ทั้งก้อนขึ้นเว็บโดยไม่ตรวจข้อมูล

0. เตรียมข้อมูลและขอบเขต — 15 นาที

อ่านตามลำดับ:

1. บทเรียน 00 — เตรียมเครื่องและพื้นฐานเว็บ เพื่อแยก source, build output และ URL ที่ browser เปิด
2. บทที่ 1 — พื้นฐาน Vibe Coding เพื่อกำหนดขอบเขต, evidence และ stop condition
3. Lab Research → Website brief → Brandbook เพื่อแยก FACT, INFERENCE, PROPOSAL และ GAP
4. บทที่ 3 — Specs และ Prompts เพื่อเขียน acceptance criteria ก่อนแก้ code

ข้อมูลตั้งต้นของตัวอย่างอยู่ใน inputs.md และขอบเขตอยู่ใน scope.txt ของ workspace แยก โดยมี source ID สำคัญดังนี้:

• S1: ชื่อ module และมหาวิทยาลัยที่ผู้ใช้ให้
• S2: ขอบเขต workshop 2 วัน × 4 ชั่วโมงจาก course data และคู่มือผู้สอน
• S3: excerpt ของกฎ Rawinnipa และ DESIGN.md ที่จำเป็นต่อสื่อหลักสูตร ไม่ได้แนบ DESIGN.md ทั้งไฟล์ให้การรันแยก
• S4: รายการบทเรียน 00–10 และ URL ที่มีจริง
• S5: ปลายทางหลัก เช่น resources, handbook และ labs
• S6: font assets ที่ repository มีอยู่

GAP ต้องคงเป็น GAP จนได้ข้อมูลจากเจ้าของ เช่น ชื่อผู้สอน หน่วยกิต เกณฑ์คะแนน ตารางภาคเรียน LMS และช่องทางสมัคร การมีพื้นที่ว่างบนหน้าเว็บไม่ใช่เหตุผลให้ AI แต่งข้อมูลเติม

การแบ่งบทเรียนเป็น Day 1: 00–05 และ Day 2: 06–10 ยังไม่มีใน brief รอบแรก จึงถูกบันทึกเป็น GAP แล้วผู้ควบคุมงานให้คำชี้แจงเพิ่มก่อนรอบ interaction นี่เป็นตัวอย่างสำคัญของการทำงานทีละขั้น: เมื่อข้อมูลไม่พอให้หยุดถามหรือเพิ่ม source ที่ตรวจได้ แล้วค่อยเปลี่ยน dataset อย่าให้ AI แบ่งวันเองและเขียนย้อนหลังว่าเป็นข้อมูลเดิม

ใช้ worksheet นี้ก่อนเปิด Codex:

ก่อนเริ่ม session ตรวจ working directory และไฟล์ที่อนุญาตให้แก้ แล้วบอก Codex ชัดเจนว่าไม่ให้ deploy, เพิ่ม dependency หรือแก้ส่วนอื่นของ repository ในรอบ brief

1. ให้ Codex สร้าง website brief — 20 นาที

รอบแรกยังไม่สร้าง HTML ให้ Codex อ่าน inputs.md และ scope.txt ใน workspace แยก แล้วเขียน brief ที่แยกข้อมูลยืนยันแล้วออกจากข้อเสนอ กฎการออกแบบที่ต้องใช้มีอยู่ใน excerpt S3; agent ไม่ได้อ่าน DESIGN.md ทั้งไฟล์ในรอบนี้ จุดนี้ตรงกับ บทที่ 3 และต่อจาก evidence workflow ใน Research-to-Brand Lab

Prompt 01 ที่ส่งจริง — brief

อ่าน inputs.md และ scope.txt แล้วสร้าง brief.md กับ evidence.csv เท่านั้น ยังไม่สร้างหน้าเว็บ
brief: เป้าหมาย audience ที่ติดป้ายข้อเสนอ CTA หลัก/รองและปลายทาง ลำดับsection content inventory states light/dark responsive accessibility acceptance checks และ GAP ที่ต้องถามเจ้าของ
ยึดชื่อรายวิชาและ PSU Phuket ตามข้อมูล; workshop 2วัน×4ชั่วโมงเป็นเพียงส่วนหนึ่งของmodule. แยก FACT/INFERENCE/PROPOSAL/GAP และ source IDs S1–S6 ใน evidence.csv
อธิบายทางเลือกภาพ2แบบและเลือกหนึ่งเป็น draft โดยยึดแบรนด์เดิม ไม่สร้างตรามหาวิทยาลัยหรือข้อมูลผู้สอน/หน่วยกิต
ไม่รันweb researchในรอบนี้ รายงานว่าเป็นการสังเคราะห์ข้อมูลที่แนบ

ขั้น 01 ภาพ Terminal replay ของ prompt ที่ส่งจริงเพื่อสร้าง brief

เปิดภาพขนาดเต็ม

ขั้น 01 คำตอบจริงจาก Codex ระบุไฟล์ brief และข้อมูลที่ยังขาด

เปิดภาพขนาดเต็ม

เปิด brief ที่ Codex สร้างในรอบแรก คู่กับภาพผลตอบกลับ

ภาพขั้นนี้ควรให้เห็น prompt file ที่ใช้, event สำคัญของ Codex CLI และ brief ที่เกิดขึ้น สังเกตว่า agent เก็บ Day mapping เป็น GAP หรือไม่ ภาพเป็นหลักฐานลำดับเหตุการณ์ ไม่ใช่หลักฐานว่า brief ถูกต้องครบถ้วน

ไฟล์ prompt ฉบับคัดลอกอยู่ที่ 01-brief.txt และ transcript ของรอบนี้อยู่ในชุด transcripts/ ของ Lab

ตรวจ brief ก่อนผ่าน

• ชื่อหลักสูตรและสถาบันตรงกับ S1
• อธิบาย 8 ชั่วโมงว่าเป็น workshop subset
• มี audience เป็น PROPOSAL ไม่อ้างว่าเป็นผลวิจัยผู้เรียน
• มีเป้าหมายหลัก, information hierarchy, CTA, section list และ acceptance criteria
• รายการบทเรียนอ้าง S4 และไม่มีบท/URL ที่แต่งขึ้น
• เก็บข้อมูลผู้สอน หน่วยกิต คะแนน สมัครและ LMS เป็น GAP
• ไม่อ้างว่า prototype เป็นระบบทางการหรือได้รับการรับรองเพิ่ม

ถ้า brief เติมข้อมูลที่ไม่มี source ให้แก้ brief ก่อนเดินต่อ อย่ารอแก้ด้วยการซ่อนข้อความใน CSS

หลังตรวจรอบ 01 ผู้ควบคุมงานยืนยันการแบ่งวันแล้ว ให้เพิ่ม clarification ลง inputs.md ของ workspace ก่อนส่ง prompt 02 วิธีที่ทำซ้ำตัวอย่างได้คือคัดลอก updated snapshot ซึ่งมี source เดิมพร้อม Day mapping ที่เพิ่มภายหลัง:

cp public/labs/course-website-build/inputs.md practice/psu-course/inputs.md

อ่าน diff หรือเปิดไฟล์เทียบก่อน เพื่อยืนยันว่าการเปลี่ยนแปลงคือ Day 1: 00–05 และ Day 2: 06–10 ไม่ใช่การเพิ่มข้อมูลมหาวิทยาลัยส่วนอื่น หากทำงานจากเว็บแทน source tree ให้ดาวน์โหลด /labs/course-website-build/inputs.md แล้วแทนเฉพาะ practice/psu-course/inputs.md

2. สร้าง semantic HTML ก่อนแต่งภาพ — 25 นาที

ให้ Codex อ่าน brief ที่ผ่านการตรวจ แล้วสร้างหน้า HTML ซึ่งยังทำงานได้เมื่อปิด CSS และ JavaScript ลำดับเนื้อหาควรเป็น header/navigation → hero → จุดเริ่มต้นของผู้เรียน → ภาพรวม 2 วัน → รายการ 11 บท → resources → footer

ขั้นนี้ใช้หลักจาก บทเรียน 04 — Design, assets และคุณภาพ เฉพาะเรื่อง content hierarchy, semantic landmarks, headings และ links ยังไม่ต้องเพิ่ม form controls หรือพยายามทำหน้าให้เหมือนภาพสำเร็จ

Prompt 02 ที่ส่งจริง — HTML

อ่าน inputs.md, scope.txt และ brief.md สร้าง index.html เท่านั้น ใช้ semantic HTML ภาษาไทยที่ทำงานได้โดยยังไม่มี CSS/JS
หน้าที่ของเว็บ: อธิบายบริบท 977-121 Module: Website Design and Development ที่ PSU Phuket และพาผู้เรียนเข้าสู่สื่อ AI Web Studio
ต้องมี skip link ไป main tabindex=-1, header/nav, hero พร้อมชื่อรายวิชาและป้ายเว็บไซต์ตัวอย่างเพื่อการเรียน, เป้าหมายworkshop, แผน2วัน (4ชั่วโมงต่อวันรวมพัก), รายการบทเรียนครบ11บท, แหล่งเรียนต่อ และ footer ที่ลิงก์ rawinsoft.com ในฐานะผู้จัดทำสื่อ
CTAหลักไป /learn/lessons/00-course-map/ (ตรวจชื่อจริงใน inputs.md ก่อนใช้; หากต่างให้ใช้ URL ใน inputs)
CTAรองไป #lessons; linkคู่มือไป /handbook/ และ /resources/
แบ่งบท00–05 เป็น day1, 06–10 เป็น day2 ตามคลังบทเรียน ไม่สัญญาว่าจะสอนครบทุกบทใน8ชั่วโมง
วางแต่ละบทเป็น article[data-lesson][data-day="day1" หรือ "day2"] โดยมีชื่อ ลิงก์อ่าน คำอธิบายสั้นจากชื่อบท และลำดับที่จริง
ยังไม่สร้าง search หรือ theme button ที่กดแล้วไม่มีผล ปุ่มเหล่านั้นเพิ่มในขั้นJS
ไม่สร้างฟอร์มสมัคร login ข้อมูลผู้สอน หน่วยกิต คะแนน review หรือโลโก้มหาวิทยาลัย
ไม่ใช้ภาพหรือรันserver ไม่แก้ brief/evidence. ส่งท้ายสรุปสิ่งที่ทำและสิ่งที่ยังไม่ทำอย่างสั้น

เปิด prompt ที่ 02-html.txt

ใน interactive session เดิม ให้วาง prompt 02 แล้วตรวจไฟล์ที่เปลี่ยน หากปิด session ไปแล้วให้เปิด codex -C practice/psu-course ใหม่ก่อนวาง prompt นี้ การใช้ workspace เดิมทำให้รอบถัดไปอ่านผลที่สร้างไว้ได้ แม้จะเป็น session ใหม่

จุดตรวจ HTML

1. ปิด stylesheet ชั่วคราวแล้วอ่านหน้าไล่จากบนลงล่างได้
2. มี header, nav, main, section headings และ footer เหมาะกับความหมาย
3. ลิงก์บทเรียนทั้ง 11 รายการชี้ไปยัง path จาก S4
4. รายการบทเรียนมีข้อมูลที่รอบ interaction จะนำไปสร้าง search/filter ได้ โดยยังไม่ต้องมี control
5. ไม่มี search, day filter หรือ theme toggle ใน stage นี้ เพราะจะเพิ่มหลัง content และ visual structure ผ่านการตรวจ
6. ไม่มีข้อมูลสมมติที่ทำให้เข้าใจว่าเป็นกำหนดการหรือบริการจริง

ภาพระหว่างทาง — ขั้น 02 HTML

ขั้น 02 prompt สร้าง semantic HTML ที่ส่งจริง

เปิดภาพขนาดเต็ม

ขั้น 02 หน้า HTML ก่อนแต่ง CSS ที่ viewport 1440 × 1000

เปิดภาพขนาดเต็ม

เปิด snapshot HTML ขั้น 02 — อ่านเนื้อหาและลองกดลิงก์ก่อนดูความสวยงาม

เก็บ snapshot ขั้นนี้ไว้ใน stages/02/ ภาพควรช่วยตอบว่าโครงเนื้อหาครบและอ่านตามลำดับได้หรือไม่ การยังไม่เห็น search/theme control เป็นผลที่ตั้งใจไว้ ภาพไม่ใช่หลักฐานว่า interaction หรือ accessibility ผ่านแล้ว

3. เพิ่ม Rawinnipa-consistent responsive design — 35 นาที

เมื่อ HTML ถูกต้องแล้วจึงให้ Codex เพิ่ม CSS ตาม บทเรียน 04 และ excerpt S3 ที่คัดจาก visual source of truth สำหรับ course teaching media เท่านั้น ไม่ใช้กฎนี้ไปเปลี่ยนแบรนด์ตัวอย่าง HUSH, บ้านสบาย หรือเว็บธุรกิจอื่น Stage นี้เขียน style สำหรับ Light และ Dark ให้ครบ แต่ยังไม่เพิ่ม theme toggle; control และ persistence จะอยู่ในรอบ interaction

ข้อกำหนดหลัก:

• Light เป็นค่าเริ่มต้น: canvas #F7F7F7, text #0A0A0A, surface สีขาว
• ใช้ Rawin Green #3EDC81 เป็น accent อย่างจำกัด; ปุ่มพื้นเขียวใช้ข้อความเข้ม
• ข้อความเขียวบนพื้นอ่อนใช้ #17653F เมื่อเหมาะสม
• Dark ใช้ canvas #0A0A0A, surface #171717, text #F7F7F7
• Inter สำหรับ Latin และ Noto Sans Thai สำหรับภาษาไทยจาก /fonts/
• mobile 390px ต้องไม่เกิด horizontal overflow และ controls ต้องแตะ/กดได้สะดวก
• focus ต้องมองเห็น, reduced motion ต้องยังใช้เนื้อหาได้ และ print กลับเป็นกระดาษขาว
• ไม่สร้างหรือดัดแปลงตรามหาวิทยาลัย

Prompt 03 ที่ส่งจริง — responsive design

อ่าน inputs.md, scope.txt, brief.md และ index.html ปรับ index.html เท่าที่ต้องใช้ class และสร้าง style.css กับ design-notes.md
ห้ามเปลี่ยนข้อมูลชื่อรายวิชา สถาบัน เส้นทางบทเรียน หรือแต่งข้อมูลวิชาการเพิ่ม
ออกแบบหน้า course website ให้ชวนเรียน มีเนื้อหาอ่านง่าย ใช้หลักfrontend-design: heroบอกงานชัด เส้นทางการเรียนเป็นจุดเด่นหนึ่งแห่ง ลำดับจริงช่วยนำทาง ไม่ใช้heroภาพstock
ยึดแบรนด์Rawinnipaของสื่อการสอนตามS3 ไม่อ้างเป็นPSUcorporatebrand. ใช้Inter + Noto Sans Thai localfontsจากS6; defaultlight แม้ระบบOSdark
สร้าง CSS semantic tokens สำหรับsurface/text/muted/line/action/focus และ dark override html[data-theme="dark"] พร้อมprintlight
ภาพรวม lightเป็นกระดาษoffwhite/textดำ มีgreenaccentที่CTAเดียว ส่วนcourseheroมีการจัดวางชื่อและpreviewเส้นทาง Brief→Build→Verify→Publish ที่เป็นHTML/CSS
รองรับ320/390/1440px: ไม่ใช้fixedwidthจนล้น, หัวข้อไทยไม่ตัด, navwrap, cardsเรียง1columnบนมือถือ, focusvisible, ลิงก์ชัด, hitareaเหมาะสม, ไม่มีanimationที่จำเป็นต่อเนื้อหา
stylelight/darkทั้งสองผ่านคู่สีข้อความพื้นหลัง; form/controls stylesเตรียมไว้ตามroleแต่ยังไม่เพิ่มJSในขั้นนี้
เก็บสิ่งที่เลือก/เหตุผล/evidenceID/ข้อจำกัดในdesign-notes.md สั้นๆ. ห้ามใช้remoteCDNใหม่

ขั้น 03 prompt ออกแบบ responsive CSS ตามแบรนด์สื่อหลักสูตร

เปิดภาพขนาดเต็ม

ขั้น 03 หลังเพิ่ม CSS โหมด Light บนคอมพิวเตอร์ 1440 × 1000

เปิดภาพขนาดเต็ม

ขั้น 03 การจัดหน้า Light บนมือถือ 390 × 844

เปิดภาพขนาดเต็ม

เปิด snapshot CSS ขั้น 03 — เนื้อหาเดิมถูกจัดลำดับด้วย typography พื้นที่ว่าง และสี ยังไม่มีปุ่มสลับโหมดในช่วงนี้

ภาพขั้นนี้ควรแสดงหน้าเดียวกันที่ desktop/mobile และ Light/Dark ตามวิธีตั้งสถานะเพื่อ preview สังเกต hierarchy, overflow และ readability อย่าตีความภาพว่า theme toggle หรือ persistence ผ่าน เพราะสองอย่างนั้นยังไม่ถูกสร้าง

เปิด prompt ที่ 03-design.txt

ส่ง prompt 03 ใน practice/psu-course/ เดิม Codex ควรแก้ style ของงานที่มีอยู่ ไม่สร้าง project ชุดที่สอง ตรวจรายชื่อไฟล์หลังจบและเก็บภาพ stage 03 ก่อนส่ง prompt 04

ตรวจ design ด้วยสถานะจริง

ภาพระหว่างทาง — ขั้น 03 responsive design

เก็บ desktop และ mobile อย่างน้อย mode ละหนึ่งภาพใน stages/03/ พร้อมชื่อ viewport/theme ภาพสวยไม่ถือว่าผ่านถ้ายังไม่ได้ตรวจ overflow, keyboard และข้อความจริง ภาพจะถูกรวมกับ terminal capture ในหัวข้อหลังจบ QA

4. เพิ่ม search และ Day filter — 25 นาที

เพิ่ม controls และ JavaScript หลังจากหน้า static ใช้ได้แล้ว ฟังก์ชันมีเพียงค้นหาบทเรียน, กรอง ทั้งหมด / Day 1 / Day 2 จาก dataset 11 บทเรียน, และสลับ Light/Dark พร้อมจำค่าที่ผู้ใช้เลือก ไม่ต้องใช้ API หรือฐานข้อมูลสำหรับข้อมูลสาธารณะนี้ รอบนี้ใช้คำชี้แจงใหม่ว่า Day 1 คือ 00–05 และ Day 2 คือ 06–10 พร้อมบันทึกว่าเป็น source clarification หลัง brief แรก

ขั้นนี้เชื่อมกับ บทเรียน 05 — เว็บบริษัท ในแง่ progressive enhancement และ UI states และกับ บทเรียน 06 — Data authority ในแง่ไม่เปลี่ยนข้อมูลต้นทางเป็นค่าที่เดาใน client แต่ตัวอย่างนี้เป็น static content จึงไม่ควรเพิ่ม Worker/D1 โดยไม่มีเหตุผล

Prompt 04 ที่ส่งจริง — interaction

อ่าน inputs.md, scope.txt, index.html และ style.css เพิ่ม progressive enhancement โดยสร้าง main.js และแก้ HTML/CSS เฉพาะที่จำเป็น
1) มีปุ่ม #theme-toggle: defaultLight, toggleDark/Light, data-themeบนhtml, aria-pressed=trueเมื่อDark, ข้อความบอกโหมด/การกระทำชัดเจน. จำเฉพาะค่าที่ผู้ใช้เลือกใน localStorage key psu-course-website-theme-v1. storageถูกปิดต้องยังใช้ได้ด้วยtry/catch. ไม่มีค่าที่บันทึกแล้วให้Lightแม้OSDark
2) ค้นหาบทเรียน #lesson-search มีlabelจริง: trimช่องว่าง ใช้ชื่อ+คำอธิบายของ11บท matchอย่างปลอดภัย (ไม่ใช้innerHTMLจากผู้ใช้)
3) filter buttons data-filter=all/day1/day2 มีaria-pressedที่ตรง, ค้นหากับfilterทำงานร่วมกันบน article[data-lesson][data-day]. วัน1บท00–05, วัน2บท06–10
4) #lesson-status role=status aria-live=politeแจ้งจำนวนที่พบ, #lesson-empty แสดงเมื่อ0ผล, #clear-search คืนqueryว่างและfilterall แล้วfocussearch ไม่ทำให้focusกระโดดขณะพิมพ์
5) controlsค้นหา/filter/themeเริ่มมีhiddenในHTMLและแสดงเฉพาะเมื่อJSพร้อม ถ้าJSปิดยังเห็น11บทและเข้าเรียนด้วยanchorได้. ให้CSSรักษาความหมาย [hidden] { display:none !important }
ไม่ต้องเพิ่มprogress tracking analytics forms API framework หรือdependencies. ไม่มีcredentials/login. reducedmotionและprintยังทำงาน. เก็บ acceptance-notes.md ระบุการตรวจที่ทำได้จริงและสิ่งที่ยังรอbrowser ไม่อ้างรันbrowserถ้ายังไม่ได้รัน

ขั้น 04 prompt เพิ่ม search day filters และ theme toggle

เปิดภาพขนาดเต็ม

ขั้น 04 ตัวอย่างค้น GSAP ร่วมกับ Day 2 แล้วแสดงจำนวนผล

เปิดภาพขนาดเต็ม

ขั้น 04 คำค้นที่ไม่มีผลและปุ่มล้างการค้นหาพร้อมตัวกรอง

เปิดภาพขนาดเต็ม

เปิด snapshot interaction ขั้น 04 — ลองเปลี่ยนเงื่อนไขด้วยตนเอง

ภาพขั้นนี้ควรให้เห็น prompt clarification เรื่อง Day mapping และหน้าเว็บหลังมี search, filters และ theme toggle แล้ว สังเกต active state, result count และ empty state จาก browser ภาพหนึ่งสถานะยังไม่พิสูจน์ keyboard behavior, persistence หรือทุกชุดคำค้น

เปิด prompt ที่ 04-interaction.txt

ส่ง prompt 04 ใน workspace เดิม ขั้นนี้จึงเห็น updated inputs.md, HTML และ CSS จากรอบก่อนพร้อมกัน หลังจบให้ลอง controls ใน browser preview ก่อนส่งรอบ review

กรณีทดสอบขั้นต่ำ

อย่าใช้สีเพียงอย่างเดียวบอก filter ที่ active ใส่ข้อความ/สถานะเชิงโปรแกรม และอย่าซ่อนจำนวนผลจาก screen reader หากจำนวนนั้นเปลี่ยนจากการค้นหา

5. ให้ Codex review แล้วแก้จากหลักฐาน — 25–40 นาที

การ review ต้องเกิดหลังมีหน้าให้ตรวจ ส่งขอบเขตไฟล์และ acceptance criteria ให้ Codex ตรวจ source, links, responsive states, keyboard, theme persistence และข้อมูลที่อาจกล่าวเกินหลักฐาน ขอให้รายงาน finding พร้อมตำแหน่งและวิธีพิสูจน์ รอบนี้อนุญาตให้แก้ข้อผิดพลาดที่ชี้จาก source ได้ และต้องบันทึกเหตุผลกับขอบเขตที่ยังไม่ได้ทดสอบ

Prompt 05 review ที่ส่งจริง

อ่าน inputs.md, brief.md, index.html, style.css, main.js และ acceptance-notes.md แล้วทบทวนเฉพาะsourceในโฟลเดอร์นี้
ตรวจข้อมูลจริงเทียบsource, mapping11บท/Day1Day2, defaultlight+dark storageerror, การค้นร่วมกับfilter/empty/reset, noJSfallback, semanticHTML keyboardfocus alt printและreducedmotion
รัน node --check main.js ได้ แต่อย่ารันserverหรืออ้างbrowser/contrastผ่านจากการอ่านโค้ด
หากพบข้อผิดพลาดที่พิสูจน์ได้ให้แก้ไฟล์ที่เกี่ยวข้องและเขียน review.md ระบุสาเหตุ สิ่งที่เปลี่ยน ผลคำสั่ง และbrowserchecksที่ยังรอ
หากไม่พบให้บันทึกตามจริง ไม่สร้างปัญหาหรือผลทดสอบขึ้นเอง. เว็บไซต์นี้เป็นตัวอย่างสื่อรายวิชา ไม่ใช่LMSหรือเว็บมหาวิทยาลัยที่รับรองแล้ว

ขั้น 05 prompt ให้ Codex ตรวจ source และแก้สิ่งที่ชี้ได้

เปิดภาพขนาดเต็ม

ขั้น 05 คำตอบจริงรายงานการปรับ CSS และแยก browser checks ที่ยังไม่ได้รัน

เปิดภาพขนาดเต็ม

รอบ 05 Codex เพิ่ม reduced-motion fallback ให้ skip link จากการอ่าน source ผลนี้เป็นการทบทวนของผู้สร้างเอง จึงยังต้องตรวจใน browser โดยอีกขั้นหนึ่ง อ่าน review.md ของรอบ 05

ภาพขั้น review ควรแสดง prompt กับ finding ที่อ้างตำแหน่งไฟล์หรือ evidence ได้ สังเกตว่า agent แยก Verified, Finding และ Not tested หรือไม่ ภาพรายงานไม่พิสูจน์ว่า finding ถูกแก้แล้ว

เปิด prompt ที่ 05-review.txt

ส่ง prompt 05 ใน workspace เดิม โดยให้ตรวจ source ก่อนแก้และบันทึกสิ่งที่แก้ตามจริง หากใช้ non-interactive mode ให้เปลี่ยนเฉพาะชื่อ prompt/input และชื่อไฟล์ JSONL ในตัวอย่างคำสั่ง อย่า redirect ทับ 01-events.jsonl

จัดผล review เป็นสามกลุ่ม:

• Verified: มี command/browser evidence รองรับ
• Finding: พบปัญหาและชี้ตำแหน่ง/ผลกระทบได้
• Not tested: ยังไม่มีเครื่องมือหรือ evidence พอ

คำว่า “looks good” ไม่ใช่หลักฐาน และการไม่มี error ใน console ไม่ได้ยืนยัน keyboard, contrast, link target หรือ mobile overflow

รอบ 06 — ปิด GAP ที่ยืนยันแล้วและส่งต่องาน

หลังทดสอบหน้าเว็บ พบว่า brief/evidence ฉบับแรกยังเก็บบางเรื่องเป็น GAP แม้เราให้ข้อมูลเพิ่มเติมใน prompt 02 และ 04 แล้ว จึงมีรอบ 06 เพื่ออัปเดตเอกสารให้ตรงกับ implementation โดยไม่แก้โค้ดหน้าเว็บ

แนบ implementation-decisions.md และผล browser ที่ตรวจจริงก่อนส่ง prompt นี้ ในตัวอย่างใช้ผลจาก parent runner ส่วน Codex รอบ 06 อ่านรายงานและสรุปส่งต่อ ไม่ได้เป็นผู้รัน browser เอง

อ่าน inputs.md, implementation-decisions.md, browser-verification.json, brief.md, evidence.csv และ source ที่มี
รอบนี้ห้ามแก้ index.html/style.css/main.js และห้ามรัน server/deploy/modelอื่น
แก้ brief.md และ evidence.csv ให้สะท้อนข้อกำหนดที่ได้รับเพิ่มจริง:
- Day1 บท00–05 และDay2บท06–10 ยืนยันแล้วจาก dayData ของโครงการ
- มี theme toggle Light/Dark ยืนยันแล้วใน prompt04; Lightเป็นdefaultและเก็บเฉพาะตัวเลือกของผู้ใช้
- CTAรองดูบทเรียนทั้งหมดไป #lessons ยืนยันในprompt02 ไม่ใช่ปลายทาง / ที่ยังสงสัยในbriefแรก
บันทึกแหล่งการยืนยันและการเปลี่ยนสถานะ GAP โดยไม่ลบประวัติรอบแรก (snapshotเดิมเก็บแยกแล้ว)
อย่าอ้างว่าข้อมูลผู้สอน หน่วยกิต เกณฑ์คะแนน หรือLMSได้รับการยืนยันแล้ว
สร้าง handoff.md ที่สรุปไฟล์/CTA/interaction/token/หลักฐานตรวจ/สิ่งที่ยังไม่ทำ
อ่านผล browser ที่แนบแล้วรายงานว่า parent runner เป็นผู้ทดสอบ ไม่อ้างว่าคุณรัน browser เอง
เกณฑ์ที่ผ่านคือเฉพาะในรายงาน; ยังไม่อ้างเผยแพร่ public จนมีหลักฐานจากขั้นdeploy
อธิบายสั้นๆ ว่าเมื่อข้อกำหนดได้รับคำตอบแล้ว ต้องแก้ทั้ง brief/evidence และimplementationให้ตรงกัน

ขั้น 06 prompt ปิดช่องว่างใน brief ด้วยข้อมูลที่ยืนยันแล้วและผลทดสอบที่แนบ

เปิดภาพขนาดเต็ม

ขั้น 06 คำตอบจริงเกี่ยวกับ brief evidence และ handoff ที่อัปเดต

เปิดภาพขนาดเต็ม

เปิด handoff รอบ 06 — ระบุผลตรวจ local ตามหลักฐาน ณ รอบนั้น ยังไม่ใช่หลักฐาน public deployment

เปิด prompt 06-handoff.txt, การตัดสินใจที่ส่งเพิ่ม และ ผล browser ที่ใช้ แล้วเทียบ brief รอบแรก กับ brief ที่อัปเดตแล้ว เพื่อดูการปิดช่องว่างโดยไม่แต่งข้อมูลธุรกิจเพิ่ม

รอบ 07 — แก้จากการตรวจหน้าตาจริง แล้วเพิ่ม regression check

แม้ browser suite รอบแรกผ่าน การตรวจเพิ่มพบว่าขอบช่องค้นหากลืนกับพื้น ทั้ง Light และ Dark เราจึงเพิ่ม --control-line แยกจากเส้นแบ่งตกแต่ง และใช้กับ controls เพื่อให้มองเห็นขอบชัดเจนขึ้น

กรณีช่องกรอกที่ต้องใช้ขอบเพื่อบอกตำแหน่ง control ให้ตรวจ contrast อย่างน้อย 3:1 กับสีที่ติดกัน ไม่ได้หมายความว่าเส้นตกแต่งทุกเส้นต้องผ่านเกณฑ์เดียวกัน W3C: Non-text Contrast

การตรวจ browser โดย parent/reviewer พบปัญหาที่ต้องแก้ตามหลักฐานนี้:
- ขอบ input/button ที่ไม่ได้เลือกกลืนกับพื้น .lesson-controls: light #D0D0D0 บน #FFF =1.54:1; dark #555 บน #171717 =2.40:1
  เพราะfillของcontrolเหมือนcontainer ขอบนี้จึงเป็น visual boundary ของcontrolและต้องมีcontrastอย่างน้อย3:1
- ลิงก์ walkthrough ใน footer ยังมีข้อความ กำลังสร้าง ซึ่งจะไม่ตรงกับฉบับเผยแพร่
แก้เฉพาะ index.html, style.css และบันทึก review-fix.md/อัปเดต handoff.md:
เพิ่ม semantic token --control-line สำหรับขอบcontrol โดยใช้ light #767676 และ dark #858585
นำไปใช้กับ input, filter buttons และ clear/theme buttons ตามที่ต้องมีขอบ ไม่จำเป็นต้องเปลี่ยนdividerตกแต่งทั้งหมด
รักษาfocus, layout, lightdefault/dark, storagefailure, search/filter/reset/noJS behaviorเดิม ไม่แก้main.js
เปลี่ยนข้อความท้ายลิงก์walkthroughเป็นข้อความที่อ่านได้ตามปกติและยังชี้URLเดิม
อย่าแก้historical snapshotsนอกรอบนี้ อย่ารันserverหรือdeploy
บันทึกว่าbrowser/contrastrecheckรอparentrunner ไม่อ้างผ่านเองจากการอ่านโค้ด

รอบ 07 prompt แก้ control boundary จาก finding ที่ตรวจได้

เปิดภาพขนาดเต็ม

ก่อนแก้ ขอบช่องค้นหาและตัวกรอง Light ของ snapshot 04

เปิดภาพขนาดเต็ม

หลังแก้ Light ใช้ semantic control-line และตรวจสีจาก browser

เปิดภาพขนาดเต็ม

หลังแก้ Dark ทำให้ขอบ controls ชัดกับพื้นเข้ม

เปิดภาพขนาดเต็ม

เพิ่ม regression assertion จากสีที่ browser คำนวณจริงสำหรับช่องค้นหา ปุ่มกรองที่ยังไม่เลือก และปุ่มล้าง โดยตรวจทั้งสองโหมดที่ 320/390/1440px เก็บ snapshot รอบ 07 และ prompt แก้จริง แยกจากภาพก่อนแก้ เพื่อไม่เขียนทับประวัติการเรียนรู้

ตารางบันทึก QA

ใช้ targeted checks ก่อน แล้วค่อยรัน lint/build/document checks ที่ repository กำหนด บันทึก command, exit code และขอบเขตของสิ่งที่ตรวจจริง ถ้า test รันไม่ได้ให้บอกเหตุผลและใช้ next-best check โดยไม่เปลี่ยน not tested เป็น passed

6. ตรวจ final page และเตรียมเผยแพร่ — 15–20 นาที

เปิด บทเรียน 08 — Cloudflare deployment และ บทเรียน 09 — Production Operations ก่อนเผยแพร่ เว็บไซต์ที่เผยแพร่พร้อมเอกสารชุดนี้ใช้ deployment path ของ เว็บไซต์หลักสูตรที่ผู้สอนมีอยู่ และเพิ่มตัวอย่างที่ /examples/course-website/; นี่ไม่ใช่ปลายทางที่ผู้เรียนควร deploy ทับ และไม่ใช่บริการ production ในนามมหาวิทยาลัย

Preview งานของผู้เรียนโดยไม่ทับ worked example

เมื่อ practice/psu-course/ มี index.html, style.css และ main.js แล้ว ให้คัดลอกเฉพาะสามไฟล์ไปยัง static practice path:

mkdir -p public/practice/course-website
cp practice/psu-course/index.html public/practice/course-website/index.html
cp practice/psu-course/style.css public/practice/course-website/style.css
cp practice/psu-course/main.js public/practice/course-website/main.js
npm run build
npm run preview

เปิด http://127.0.0.1:3320/practice/course-website/ และหยุด server ด้วย Ctrl+C เมื่อเสร็จ ถ้า agent ใช้ชื่อ CSS/JS ต่างจากนี้ ให้อ่าน index.html แล้วคัดลอกไฟล์ local ที่หน้านั้นอ้างจริง ห้ามคัดลอก dependency จาก URL ภายนอกมาโดยไม่ตรวจสิทธิ์และที่มา

ไม่ควรคัดลอกงานฝึกไปทับ examples/course-website/ เพราะ path นั้นเป็น worked example ของ source bundle หากจำเป็นต้องทดลอง integration ที่ path เดียวกัน ให้เก็บสำเนาไฟล์เดิมก่อนและทำใน source copy ของตนเองเท่านั้น

ตรวจตามลำดับ:

1. เปิด final page ที่ desktop/mobile ทั้ง Light และ Dark
2. ตรวจ 11 lesson links, resources, handbook, labs และ https://rawinsoft.com/
3. ทดลอง search, filter, empty state, reset และ theme persistence
4. ตรวจ keyboard, visible focus, reduced motion และ print
5. รัน targeted tests, documentation checks, lint และ build ตาม repository
6. ทำ deployment dry-run และแยกผล dry-run ออกจาก public deployment
7. เมื่อเผยแพร่ในระบบที่มีสิทธิ์แล้ว จึงเก็บ public URL, version และ HTTP/browser smoke evidence
8. อัปเดต PDF/source bundle ผ่านหน้า Resources และตรวจว่า download ตรงกับ source รุ่นเดียวกัน

อย่าเขียนว่า deploy สำเร็จจาก build หรือ dry-run เพียงอย่างเดียว และอย่าใส่ token, cookies, account ID ที่ไม่จำเป็น หรือ secret ลง transcript/screenshot

ทำต่อที่ Lab Deploy เว็บตัวอย่างขึ้น Cloudflare ทีละขั้น: export เฉพาะ HTML/CSS/JS/fonts ของเว็บนี้เป็น Static Assets และ deploy ด้วยชื่อ Worker ของผู้เรียน ไม่ต้องสร้าง D1 ส่วน บทเรียน 08 ใช้เมื่อ deploy เว็บไซต์หลักสูตรทั้งชุดที่มี API และฐานข้อมูล ทั้งสองเส้นทางใช้ config คนละไฟล์

ภาพผลสุดท้ายและลำดับคำสั่ง

เว็บไซต์ฉบับสุดท้าย Light ที่ desktop 1440 × 1000

เปิดภาพขนาดเต็ม

เว็บไซต์ฉบับสุดท้าย Dark ที่ desktop 1440 × 1000

เปิดภาพขนาดเต็ม

เว็บไซต์ฉบับสุดท้าย Light ที่ mobile 390 × 844

เปิดภาพขนาดเต็ม

เว็บไซต์ฉบับสุดท้าย Dark ที่ mobile 390 × 844

เปิดภาพขนาดเต็ม

ดูทั้งหน้า desktop · ดูทั้งหน้า mobile · เปิดชุดไฟล์/ภาพทุกขั้น

อ่านเอกสารนี้เป็น PDF แยกเล่มหรือดาวน์โหลด source ได้ที่ Resources

ภาพในชุดนี้มี caption ระบุ ขั้น, viewport, theme และสิ่งที่กำลังพิสูจน์ หากภาพ Terminal มี path, username หรือ credential ที่ไม่จำเป็นให้ redact ก่อนเผยแพร่ แต่เก็บ prompt สำคัญครบในไฟล์ข้อความเพื่อให้ทำซ้ำได้

เชื่อม Lab นี้กับ 11 บทเรียน

หากต้องการออกแบบผ่านเครื่องมือภาพก่อนเขียน code ให้ใช้ Claude Design, Google Stitch และ Figma MCP ระหว่าง brief กับ HTML หากต้องการสร้าง brand system จากข้อมูลดิบ ให้ทำ Research-to-Brand Lab ก่อน Lab นี้ ทั้งสองทางเลือกเป็นเนื้อหาเรียนต่อ ไม่เพิ่ม workshop 8 ชั่วโมง

Worksheet ส่งงาน

กรอกและแนบไฟล์นี้กับงาน:

ชื่อโครงการ:
วันที่ทำ:
Codex client/version ที่เห็นจริง:

Source IDs ที่ใช้:
FACT สำคัญ 3 ข้อ:
PROPOSAL ที่เลือก 2 ข้อและเหตุผล:
GAP ที่ยังไม่เติม:

Primary user task:
Primary CTA และผลหลังคลิก:
Sections ที่สร้าง:

Prompt files ที่ส่งจริง:
ไฟล์ที่ Codex แก้ในแต่ละรอบ:
Finding สำคัญจาก review:
การแก้และ evidence หลังแก้:

Targeted test:
Lint/build/document check:
Mobile/keyboard/theme evidence:
สถานะ deploy: not run / dry-run / public verified
Public URL และ version (เมื่อมีจริง):

สิ่งที่ยัง not tested:
ข้อควรรู้สำหรับผู้ดูแลคนถัดไป:

Rubric 20 คะแนน

คะแนนเต็มไม่ได้หมายความว่าเป็นระบบมหาวิทยาลัยพร้อมใช้งานจริง งานนี้ประเมินกระบวนการเปลี่ยนข้อมูลเป็นเว็บที่ตรวจย้อนกลับได้ตามขอบเขตของ workshop

Definition of Done

• final page เปิดได้ที่ /examples/course-website/
• เนื้อหาตรง source inventory และไม่มีข้อมูล GAP ถูกแต่งเติม
• ลิงก์บทเรียน 00–10 และ resources สำคัญเปิดได้
• Light เป็นค่าเริ่มต้นและผู้ใช้เลือก Dark ได้
• search/filter/empty/reset ใช้ได้ด้วย mouse และ keyboard
• หน้า 390px ไม่มี horizontal overflow ที่เกิดจาก component
• prompt ที่ส่งจริงและ transcript ที่เผยแพร่ไม่ปะปนกับคำอธิบายย้อนหลัง
• QA findings มี evidence ก่อนและหลังแก้ หรือระบุว่า not tested
• PDF/source bundle รุ่นเผยแพร่เข้าถึงผ่าน Resources
• public/deploy claim มีหลักฐานจากปลายทางจริง; หากยังไม่ deploy ให้สถานะคงเป็น local หรือ dry-run

เมื่อครบรายการนี้ ผู้เรียนจะไม่ได้เพียงหน้าเว็บหนึ่งหน้า แต่มีร่องรอยการตัดสินใจที่อธิบายได้ว่า Codex ได้ข้อมูลอะไร ถูกสั่งอย่างไร เปลี่ยนไฟล์ใด และผู้เรียนตรวจรับผลด้วยหลักฐานใด

เอกสาร brief/evidence/handoff ที่ระดับรากได้รับการปรับให้ตรงกับ build โดยผู้รวมงานหลังรอบ 07 ดู บันทึกการรวมงาน และ ผลทดสอบสุดท้าย ส่วน snapshot แต่ละรอบยังเก็บข้อมูลเดิมตามลำดับจริง