DESIGN.md — ฟอร์แมตไฟล์เดี่ยวสำหรับระบบออกแบบเพื่อเครื่องมือเขียนโค้ด AI (สรุปภาษาเกาหลี)

ผมสนใจฟอร์แมต DESIGN.md ที่ Google Labs เสนอในโปรเจกต์ Stitch มาก เลยใช้เวลาหลายวันไล่อ่านสเปกอย่างละเอียด แล้วรู้สึกว่าเสียดายถ้าอ่านคนเดียวจบ จึงสรุปอธิบายเป็นภาษาเกาหลีในรูปแบบคอร์ส 28 บทไว้เรียบร้อยแล้ว เพื่อให้คนที่กำลังศึกษาหัวข้อนี้ไม่ต้องเริ่มจากการไล่เปิดสเปกภาษาอังกฤษตั้งแต่ต้น และเพื่อให้คนที่มีคำถามแบบเดียวกับผมว่า "จะทำให้ AI อ่านระบบออกแบบได้อย่างไร" สามารถมองภาพรวมได้ในครั้งเดียว

DESIGN.md เป็นฟอร์แมตที่พยายามแสดงระบบออกแบบด้วยไฟล์ Markdown เพียงไฟล์เดียว โดยเก็บค่าต่างๆ เช่น สี, typography, spacing, radius, component token ไว้ใน YAML frontmatter ในรูปแบบที่เครื่องอ่านได้ และเขียนเกณฑ์การตัดสินใจด้านดีไซน์ไว้ใน Markdown ด้านล่าง เช่น "ทำไมถึงใช้สีนี้", "สไตล์ปุ่มนี้ใช้ในสถานการณ์ไหน", "ควรหลีกเลี่ยงแพตเทิร์นแบบใด" กล่าวอีกอย่างคือ มันไม่ใช่แค่ style guide ธรรมดา แต่ใกล้เคียงกับ "ไฟล์ต้นฉบับของระบบออกแบบ" ที่ AI coding agent อย่าง Claude Code, Cursor, Codex จะใช้อ้างอิงอยู่เสมอ

เบื้องหลัง — การเปลี่ยนแปลงที่ได้ทบทวนอีกครั้งระหว่างสรุป

• คำถามในอดีต: "จะจัดระบบออกแบบใน Figma ให้ดีได้อย่างไร"
• คำถามในปัจจุบัน: "จะทำให้เครื่องมือเขียนโค้ด AI อ่านระบบออกแบบของเราอย่างไร", "ถ้าสร้างหน้าใหม่ จะต้องมีอะไรบ้างเพื่อให้ AI ทำตามกฎเรื่องสี ระยะห่าง และคอมโพเนนต์ของแบรนด์เราได้"
• การเปลี่ยนแปลงที่สอดคล้องกับกระแสอย่าง Claude Design, Claude Code, Figma MCP ซึ่งทำให้ระบบออกแบบไม่หยุดอยู่แค่ใน Figma แต่เข้าสู่ codebase ถูกรีวิวใน PR และกลายเป็น "คอนเท็กซ์ต่อเนื่อง" ของ AI agent

แก่นสำคัญของฟอร์แมต DESIGN.md (ส่วนที่น่าประทับใจระหว่างอ่านสเปก)

• โครงสร้างสองชั้น YAML (สำหรับเครื่อง) + Markdown (สำหรับคนและ AI) — token ให้เครื่อง parse ส่วนเนื้อหาใช้เก็บเหตุผลในการตัดสินใจของมนุษย์
• token คือคำตอบ เนื้อหาคือเหตุผล — จุดที่กำหนดลำดับความสำคัญไว้ล่วงหน้าว่าถ้าสองส่วนไม่ตรงกันควรเชื่ออะไร ถือว่าชัดเจนและดีมาก
• ลำดับ 8 ส่วนถูกกำหนดตายตัว — sections อย่าง colors, typography, spacing, components ทำหน้าที่เป็น mental model ของระบบออกแบบเอง
• lint / diff / export / spec CLI — ตรวจสอบอัตโนมัติสำหรับรายการอย่าง broken reference, contrast ratio ไม่พอ, orphan token, การละเมิดลำดับ section
• ระบุนโยบายการทำงานร่วมกับ DTCG, Tailwind, Figma variables แยกไว้อย่างชัดเจน

โครงสร้างคอร์ส (28 บท, 7 โมดูล)

• M1 ปรัชญาของฟอร์แมต · 3 บท — ปัญหาที่ฟอร์แมตนี้พยายามแก้, โครงสร้างสองชั้น, ลำดับความสำคัญระหว่าง token กับเนื้อหา
• M2 สคีมาของ token · 5 บท — สคีมาทั้งหมด / สี / ความยาว·หน่วย / ฟอนต์ / การอ้างอิง token
• M3 โครงสร้าง section · 6 บท — ลำดับ 8 section และหลักการออกแบบของแต่ละส่วน
• M4 อ่านตัวอย่างจริง · 3 บท — เคส Atmospheric Glass, Paws & Paths, Totality Festival
• M5 CLI · 4 บท — lint, diff, export, spec
• M6 กฎ lint · 4 บท — 8 รายการ เช่น broken-ref, contrast, orphaned, section-order
• M7 การขยายต่อ · 2 บท — นโยบายการจัดการข้อมูลที่ไม่รู้, ความสัมพันธ์กับ DTCG·Tailwind
• สรุปท้าย · 1 บท — สรุป 27 บท + หลักการ 10 ข้อที่นำไปใช้ในงานจริงได้

สิ่งที่คิดระหว่างสรุป

• ยิ่ง AI สร้าง UI มากขึ้นเท่าไร ก็ยิ่งรู้สึกว่าระบบออกแบบจะสำคัญมากขึ้นเท่านั้น ประเด็นไม่ได้อยู่ที่ "AI ออกแบบเก่งหรือไม่" แต่กำลังย้ายไปสู่คำถามว่า "ทีมได้ทิ้งเกณฑ์ที่ AI ต้องทำตามไว้อย่างชัดเจนแค่ไหน"
• DESIGN.md เป็นความพยายามเชิงปฏิบัติที่จะวางเกณฑ์นั้นไว้ใน codebase แทน Notion หรือ PDF และยังหมายความด้วยว่างานส่งมอบของดีไซเนอร์จะกลายเป็นสิ่งที่ถูกรีวิวในระดับ PR
• เลยอยากแชร์ให้คนที่กำลังสร้างระบบออกแบบ หรือกำลังสร้าง UI ด้วยเครื่องมือเขียนโค้ด AI แล้วเคยรู้สึกว่า "ทำไมผลลัพธ์ถึงออกมาไม่เหมือนกันทุกครั้ง" ได้ลองอ่านร่วมกัน หากมีส่วนไหนที่ผมเข้าใจหรือสรุปผิดไป รบกวนบอกในคอมเมนต์แล้วผมจะนำไปแก้ไขครับ

[m00nlygreat]

มีข้อสงสัยอยู่อย่างหนึ่งว่า ถ้ามองว่า DESIGN.md เป็นชุดคำสั่งสำหรับดึงดีไซน์ออกมา สุดท้ายมันก็น่าจะถูกใช้ในช่วงแรกไม่กี่หน้า... หรือหน้าเดียว เพื่อสร้างมู้ดบอร์ด แล้วหลังจากนั้นจะเกิดความไม่สอดคล้องกันระหว่างโค้ดกับไฟล์คำสั่ง .md จนต้องซิงก์กันแบบสองทางต่อเนื่องหรือเปล่าครับ?

ท้ายที่สุดแล้วดีไซน์ในระยะถัดไปก็ควรมองให้โค้ดเป็น source of truth และนำตัวแปรหรือชื่อเรียกต่าง ๆ กลับมาใช้ซ้ำอย่างสม่ำเสมอ แต่ถ้าไม่ได้อัปเดต DESIGN.md อย่างต่อเนื่องและดูแลให้เป็น SSoT ก็เหมือนจะลงเอยด้วยการฮาร์ดโค้ดโทเคนไปเรื่อย ๆ เลยสงสัยว่าในการใช้งานจริงมีปัญหาแบบนี้หรือไม่ครับ

[neostom432]

DESIGN.md => ทิศทางของโค้ดนั้นทำให้เป็นอัตโนมัติได้ง่าย แต่ในทางกลับกัน การยกแพตเทิร์นใหม่ที่เกิดขึ้นในโค้ดกลับขึ้นไปไว้ใน DESIGN.md ยังทำให้เป็นอัตโนมัติไม่ได้ เลยต้องให้คนคอยดูแลเอง เมื่อเวลาผ่านไป hardcoding เล็กๆ น้อยๆ จะค่อยๆ สะสมอยู่ในโค้ด แต่ไม่ถูกอัปเดตขึ้นเอกสาร และเรื่องแบบนี้ก็สะสมเพิ่มขึ้นเรื่อยๆ

อย่างไรก็ตาม ปรัชญาของฟอร์แมตนี้เองก็โน้มไปทาง "ค่อยๆ ดูแล design system ต่อเนื่องภายใน codebase" อยู่แล้ว ดังนั้นผมมองว่านี่ไม่ใช่ข้อเสีย แต่ใกล้เคียงกับวิธีใช้งานที่ตั้งใจไว้มากกว่า จากเดิมที่ไกด์ถูกแช่แข็งไว้ใน Notion หรือ PDF ก็ถูกดึงลงมาให้กลายเป็นสิ่งที่รีวิวกันได้ในระดับ PR เพราะแบบนั้น โครงสร้างนี้ก็ดูเหมือนจะมาพร้อมความรับผิดชอบที่คนต้องคอยปรับแก้เป็นระยะๆ ไปด้วย เราลองนำไปใช้ในโปรเจกต์ของเราแล้ว และความสม่ำเสมอของหน้าจอก็ดีขึ้นอย่างชัดเจนเมื่อเทียบกับก่อนใช้ พอสัมผัสได้ถึงประโยชน์นั้น การรีวิวแบบแมนนวลก็ไม่ได้รู้สึกเป็นภาระ สุดท้ายแล้วมันคือเรื่องที่ว่าทีมจะทิ้งเกณฑ์ที่ AI ต้องทำตามไว้ได้ชัดเจนแค่ไหน และก็สรุปได้ว่าโครงสร้างนี้คือให้มนุษย์เป็นผู้รับผิดชอบในการคงเกณฑ์นั้นให้ยังมีชีวิตอยู่ต่อไปด้วยมือของตัวเอง