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 เซกชันถูกกำหนดตายตัว — เซกชันอย่าง colors, typography, spacing, components ทำหน้าที่เป็น mental model ของระบบดีไซน์เอง
• lint / diff / export / spec CLI — ตรวจสอบอัตโนมัติเรื่องอย่าง broken reference, contrast ไม่พอ, orphan token, การผิดลำดับเซกชัน
• ระบุนโยบาย interoperability กับ DTCG, Tailwind, Figma variables แยกไว้อย่างชัดเจน

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

• M1 ปรัชญาของฟอร์แมต · 3 บท — ปัญหาที่ฟอร์แมตนี้พยายามแก้, โครงสร้างสองชั้น, ลำดับความสำคัญระหว่าง token กับเนื้อหา
• M2 token schema · 5 บท — schema ทั้งหมด / สี / ความยาว·หน่วย / ฟอนต์ / การอ้างอิง token
• M3 โครงสร้างเซกชัน · 6 บท — ลำดับ 8 เซกชันและหลักการออกแบบของแต่ละเซกชัน
• 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 ต้องทำตามไว้ได้ชัดเจนแค่ไหน และก็สรุปได้ว่าโครงสร้างนี้คือให้มนุษย์เป็นผู้รับผิดชอบในการคงเกณฑ์นั้นให้ยังมีชีวิตอยู่ต่อไปด้วยมือของตัวเอง