MCP กับ CLI ใน Figma คนมักจะสับสนว่าจะใช้ตัวไหนดี ทั้งที่มันไม่ได้ทำงานเหมือนกัน
.
ช่วงนี้คำถามที่เข้ามาเยอะคือ จะดึง design system กับ token ออกจาก Figma ควรใช้ MCP หรือ CLI ดี แอดจะบอกก่อนเลย ว่าคำถามนี้ไม่ควรถามเช่นนี้ เพราะสองตัวนี้ไม่ใช่คู่แข่งกัน มันคือเครื่องมือคนละหน้าที่ ที่คนเอามาใช้งานก็เท่านั้น เอาล่ะ
.
เริ่มจาก CLI ก่อน เวลาพูดถึง CLI ในบริบทนี้แอดหมายถึงสายไปป์ไลน์ คือใช้ Figma REST API ดึง variable ออกมาเป็น Design Token JSON ตามสเปค W3C แล้วส่งต่อเข้า Style Dictionary เพื่อแปลงเป็น CSS เป็นตัวแปรฝั่ง iOS ฝั่ง Android ทั้งหมดรันอยู่ใน CI/CD จุดเด่นของมันมีคำเดียวคือ deterministic อินพุตเหมือนเดิม เอาต์พุตเหมือนเดิมทุกครั้งที่รัน
.
ลองนึกภาพการทำงานจริง designer แก้สีใน Figma กดปุ่มหนึ่งปุ่ม Pull Request เด้งขึ้นมาใน GitHub โชว์ diff ชัดๆ ว่า token ตัวไหนเปลี่ยนจากค่าอะไรไปเป็นค่าอะไร dev เปิดดู กด merge แล้ว GitHub Action ก็รัน Style Dictionary แปลงเป็นโค้ด deploy จบ ทุกขั้นตอนตรวจย้อนหลังได้ มี version history มี source of truth ที่ชัดเจน
.
ทีนี้ MCP มันทำงานคนละมุมเลย MCP คือการเปิดให้ AI agent ดึง context จาก Figma แบบเรียลไทม์ในจังหวะที่มันกำลัง generate code อยู่ เครื่องมืออย่าง get_variable_defs ดึงชื่อ variable กับค่าที่ใช้ใน frame ที่เราเลือกออกมาให้ AI อ้างอิงได้ ส่วน get_design_context ส่งโครงเป็น React กับ Tailwind ให้ AI เอาไปแปลต่อเป็นภาษาหรือสไตล์ที่เราอยากได้ จุดเด่นคือมันยืดหยุ่นสุดๆ สั่งด้วยภาษาคนได้ สร้าง component ใหม่จาก design ได้ทันที แต่สิ่งที่ต้องเข้าใจให้ลึกคือมันเป็น non-deterministic รันสองรอบได้โค้ดไม่เหมือนกัน และมันไม่มี diff ไม่มี version ไม่มี source of truth
.
พอเห็นภาพทั้งสองตัวแล้ว เราจะสามารถแยกวิธีการใช้งานได้
.
ถ้างานของเราต้องการ sync token ลง production ให้เลือกใช้ CLI เพราะ token มันคือ data และ data ต้องการความ deterministic ต้องการประวัติ ต้องการรู้ว่าใครเปลี่ยนอะไรเมื่อไหร่ ลองนึกภาพปล่อยให้ AI sync ค่าสีลง production แบบเชื่อใจมันเต็มร้อย แล้ววันดีคืนดีมันดึง dark mode ออกมาไม่ครบ เรื่องนี้ไม่ได้สมมตินะครับ เป็นปัญหาจริงที่คนบ่นกันใน forum ของ Figma ว่า MCP ดึง variable ที่มีหลาย mode หลาย theme ออกมายังไม่ครบ สุดท้ายต้อง dump ทั้งก้อนแล้วมานั่งไล่เอง ถ้าเกิดเคสแบบนี้บนไปป์ไลน์ที่ไม่มี diff ให้ดู เราจะไม่มีทางรู้เลยว่ามันพังตรงไหน
.
แต่ถ้างานคือสร้าง component หรือ feature ใหม่จาก design ทีนี้ MCP ชนะ เพราะงานสร้างมันคือการแปลความ ไม่ใช่การก๊อปปี้ค่า การที่ AI เห็นว่า frame นี้ใช้ token ชื่ออะไร ผูกกับ component ตัวไหน มันช่วยลด hallucinate และลด token ที่ต้องเสียไปกับการให้ AI ไล่ค้นใน codebase เอง ยิ่ง design system เราเชื่อมระหว่าง design กับ code ไว้ดีเท่าไหร่ MCP จะทำให้ผลลัพธ์ที่ต้องการแม่นยำมากขึ้น
.
วิธีจำง่ายๆ ของแอดเป็นแบบนี้ครับ MCP ตอบคำถามว่า token นี้ชื่ออะไร ใช้อยู่ตรงไหน ได้ดีมากในจังหวะที่กำลัง generate ส่วนไปป์ไลน์ฝั่ง CLI ตอบคำถามว่า token นี้เปลี่ยนค่าเมื่อไหร่ ใครเป็นคนเปลี่ยน อยู่เวอร์ชันไหน rollback ได้ไหม และพอ design system โตขึ้นเรื่อยๆ คำถามชุดหลังนี่แหละที่กลายเป็นเรื่องคอขาดบาดตาย ไม่ใช่คำถามชุดแรก
.
ในคลาส AI Design System ที่แอดสอน แอดสอนทั้งสองตัวเลยครับ ไม่ได้บังคับให้เลือกอันใดอันหนึ่ง เพราะงานจริงมันใช้ทั้งคู่ แค่คนละจังหวะกัน
.
หลักที่แอดให้นักเรียนจำคือ งานที่ทำครั้งเดียวจบ เช่น อยากได้ component ตัวนี้ อยากดึง token ก้อนนี้มาดูตอนนี้ ให้ใช้ MCP เพราะมันเร็วและสั่งเป็นภาษาคนได้เลย แต่ถ้าเป็นงานที่ต้องทำซ้ำ อยากให้มันอัปเดตเองทุกครั้งที่ design เปลี่ยน แบบนี้คืองาน automation ต้องใช้ CLI เพราะมีแต่ pipeline เท่านั้นที่นิ่งพอจะปล่อยให้รันเองโดยไม่ต้องมีคนมานั่งเฝ้า
.
พูดให้สั้นกว่านั้นคือ ทำครั้งเดียวใช้ MCP ทำให้เป็นระบบใช้ CLI
.
สรุปสั้นๆ token เป็นเรื่องของ pipeline ใช้ CLI ส่วนการ generate เป็นเรื่องของ context ใช้ MCP วันไหนเอาสองอย่างนี้ไปทำงานแทนกัน หรือสับสนงานของเราจะใช้เวลามากขึ้นและผลลัพธ์ไม่มีประสิทธิภาพ แถมเปลือง token อีกด้วย
.
#DesignLazyyy #DesignSystem #DesignTokens #FigmaMCP #StyleDictionary #DesignToCode #DesignOps #UXUI