Nếu bạn từng thử nhờ AI thiết kế giúp bộ token màu sắc, typography, spacing cho sản phẩm, chắc bạn cũng từng gặp cảnh: kết quả nghe rất kêu nhưng dùng không được, vì Claude không biết gì về sản phẩm của bạn ngoài vài câu prompt ngắn ngủi. Yummy Labs — một nhóm chuyên làm workshop về AI cho dân thiết kế — vừa chia sẻ lại cách họ giải quyết vấn đề này trong một buổi workshop có hơn 250 designer tham gia. Cách làm của họ không có gì cao siêu, nhưng đủ hệ thống để bạn áp dụng ngay cho dự án của mình.
Cách dùng Claude để xây một design system từ số 0, không cần code trước
Vấn đề không nằm ở prompt, mà ở ngữ cảnh
Nhiều người nghĩ chỉ cần viết prompt “khôn” hơn là Claude sẽ ra kết quả tốt hơn. Thực tế theo Yummy Labs, gốc rễ nằm ở chỗ khác: nếu bạn đổ hết mọi thứ vào một cuộc trò chuyện dài, hai chuyện sẽ xảy ra.
Thứ nhất, Claude bắt đầu “lơ đãng”. Cửa sổ ngữ cảnh (context window) không phải là ổ cứng, càng nhồi nhiều chữ vào không có nghĩa là Claude nhớ càng chính xác — ngược lại, khi hội thoại quá dài, việc tìm đúng thông tin quan trọng giữa hàng đống chữ sẽ khó hơn. Hiện tượng này giới chuyên môn gọi là context rot.
Thứ hai, mọi thứ bạn giải thích trong chat đều mất sạch khi bạn đóng cửa sổ đó lại. Lần sau mở chat mới, bạn lại phải giải thích lại từ đầu.
Giải pháp của Yummy Labs là tách toàn bộ ngữ cảnh về sản phẩm ra thành các file .md riêng biệt — brief sản phẩm, chân dung người dùng, nguyên tắc thiết kế, giới hạn kỹ thuật — rồi đưa vào phần project instructions của Claude. Mỗi file chỉ lo một việc, có tiêu đề rõ ràng ngay từ dòng đầu để Claude biết khi nào cần đọc file đó. Cách làm này thực chất giống hệt cơ chế Skills mà Claude dùng nội bộ: chỉ load mô tả ngắn trước, đọc toàn bộ nội dung khi thực sự cần — vừa tiết kiệm ngữ cảnh, vừa giúp Claude không bị “ngợp”.
Mẹo nhỏ: nếu bạn đang làm nội dung dài hạn cho một dự án (không riêng gì thiết kế), thử tách tài liệu tham chiếu thành nhiều file nhỏ, mỗi file một chủ đề, thay vì dán hết vào một prompt khổng lồ. Bạn sẽ thấy Claude bám sát ngữ cảnh tốt hơn hẳn.
Vì sao chọn Markdown, không phải PDF hay Word
Markdown được chọn vì nó vừa đọc được bằng mắt người, vừa “đọc” được bằng máy. Các tiêu đề (#), danh sách, bảng biểu tạo ra một cấu trúc rõ ràng mà Claude nhận diện được là đâu là ý chính, đâu là ý phụ — điều mà văn bản thuần chảy không làm được. Markdown cũng tốn ít token hơn nhiều so với HTML hay định dạng rich text, nên còn chừa nhiều chỗ hơn cho nội dung thật sự.
Hai giai đoạn: trò chuyện để quyết định, code để triển khai
Điểm hay nhất trong cách làm của Yummy Labs là tách rõ quy trình thành hai pha, dùng hai công cụ khác nhau — không phải vì công cụ nào “giỏi hơn”, mà vì mỗi công cụ hợp với một loại việc.
Giai đoạn 1 — Claude (bản chat), kết nối với Figma qua MCP.
Đây là lúc bạn còn đang cân nhắc: chọn màu nào, đặt tên token ra sao, hệ thống chữ nên co giãn thế nào giữa di động và web. Đây là công việc mang tính gu thẩm mỹ và phán đoán, cần qua lại nhanh kiểu “thử tông ấm hơn xem”, chứ chưa phải lúc viết code. Trong workshop, nhóm dùng model Claude Opus 4.8 ở mức Effort trung bình, kết nối Figma qua một công cụ MCP mã nguồn mở tên Figma Console MCP (còn gọi là Desktop Bridge) — đây là dự án cộng đồng (repo southleft/figma-console-mcp trên GitHub), không phải công cụ MCP chính chủ do Figma phát hành. Vì hoạt động qua plugin chạy trong Figma Desktop chứ không gọi thẳng REST API của Figma, công cụ này đọc/ghi được biến thiết kế (variables) ngay cả trên gói Free hoặc Professional — điều mà REST API chính thức của Figma không cho phép, vì phần Variables API bị khóa sau gói Enterprise.
Claude sẽ đọc các file ngữ cảnh, tóm tắt các quyết định thiết kế mà tài liệu gợi ý, rồi cùng bạn đề xuất từng nhóm token một — màu sắc trước, sau đó đến typography, spacing, bo góc, đổ bóng, lưới bố cục. Mỗi token đi kèm giá trị cụ thể và mô tả khi nào nên dùng, theo quy ước đặt tên kiểu category/role/variant (ví dụ color/text/primary). Việc ghi Figma chỉ diễn ra sau khi bạn đã chốt xong, không làm song song.
Giai đoạn 2 — Claude Code, để dựng ra sản phẩm thật.
Khi hệ thống token đã ổn, việc còn lại là kỹ thuật thuần túy: sinh file cấu hình Style Dictionary, xuất biến CSS cho web, theme Dart cho Flutter, dựng Storybook để tài liệu hóa, viết script đồng bộ khi token thay đổi trong Figma. Đây là việc đọc — sửa nhiều file — chạy lệnh — commit vào repo, đúng sở trường của Claude Code chứ không phải bản chat.
Cách chia này khá hợp lý: bạn ở lại bản chat khi còn đang quyết định, chuyển qua Claude Code khi đã đến lúc triển khai. Gộp hai việc vào một công cụ duy nhất thường chỉ khiến quy trình rối hơn chứ không nhanh hơn.
Prompt mẫu cho từng giai đoạn
Dưới đây là bản dịch và rút gọn hai prompt mà Yummy Labs dùng trong workshop. Bạn có thể chép ra, thay các phần trong ngoặc vuông bằng thông tin của dự án mình rồi dùng luôn.
Prompt giai đoạn 1 — dán vào Claude (bản chat)
Trước khi dán, nhớ mở Figma Desktop Bridge (nếu không mở, Claude sẽ không đọc được file Figma), chọn model Claude Opus 4.8 (mức nỗ lực trung bình), và thêm quy tắc sau vào phần project instructions:
Quy tắc Figma MCP: chỉ dùng các công cụ figma-console:* (Desktop Bridge /
Console MCP) cho mọi thao tác với Figma. Không dùng Figma:use_figma hay
Figma:get_design_context. Khi cần chạy code Plugin API tùy chỉnh, dùng
figma-console:figma_execute.Sau đó gửi tin nhắn đầu tiên như sau:
Mình muốn xây một design system "đọc được bằng AI" cho [tên sản phẩm] trong
Figma, dùng Console MCP. Mình sẽ làm theo 2 giai đoạn: trước tiên mình cùng
bạn ý tưởng hóa toàn bộ hệ thống token ngay tại đây, xong xuôi mới bắt tay
dựng trong Figma.
Việc cần bạn làm:
1. Đọc ngữ cảnh. Xem qua brief sản phẩm, chân dung người dùng, nguyên tắc
thiết kế và giới hạn nền tảng mình đã thêm vào project này. Tóm tắt nhanh
các quyết định thiết kế mà tài liệu gợi ý. Bạn thấy pattern gì? Có mâu thuẫn
nào không (ví dụ: vui tươi và gọn gàng, nội dung dày và bố cục dễ lướt)?
Nên ưu tiên điều gì dựa trên chân dung người dùng?
2. Xem style tile. Đây là style tile của [tên sản phẩm]: [LINK FIGMA STYLE
TILE]. Nó có bảng màu thương hiệu hiện tại, font chữ đang dùng, và các
nhân vật linh vật (nếu có). Cứ lấy những gì bạn thấy làm nguyên liệu ban
đầu, đừng coi đó là bản cuối. Mình muốn bạn sáng tạo ở bước này — cho mình
biết cái gì đang ổn, cái gì có thể đẩy xa hơn, và có màu hay font nào bạn
nghĩ nên đổi/thêm để phục vụ sản phẩm và người dùng tốt hơn.
3. Giờ cùng mình ý tưởng hóa toàn bộ hệ thống token. Dùng style tile làm
điểm khởi đầu (không phải giới hạn bắt buộc), kết hợp mọi thứ bạn biết từ
các file ngữ cảnh, tạo ra bộ token đầy đủ cho từng nhóm — không chỉ cấu
trúc hay quy ước đặt tên, mà cả giá trị cụ thể. Cho mình xem toàn bộ hệ
thống để cùng xem và chỉnh sửa.
Đi qua từng nhóm một, mỗi token cần có: tên ngữ nghĩa, giá trị, và mô tả
khi nào/cách nào nên dùng.
Bắt đầu với màu sắc. Nhìn màu thương hiệu từ style tile và đề xuất hệ
thống màu đầy đủ. Bạn có thể:
- Giữ lại màu nào đang hợp
- Điều chỉnh, thay thế, hoặc đề xuất màu nhấn mới nếu có hướng tốt hơn
- Đề xuất bảng màu phụ/màu nhấn riêng nếu bảng hiện tại chưa phục vụ tốt
người dùng
- Giải thích lý do cho mỗi lựa chọn
Mình cần thấy:
- Bảng màu thương hiệu (chính, phụ, màu nhấn và các sắc độ)
- Vai trò màu ngữ nghĩa: chữ (chính, phụ, vô hiệu, đảo ngược, liên kết),
nền (mặc định, phụ, nổi, lớp phủ), viền (mặc định, đậm, nhạt), trạng thái
tương tác (mặc định, hover, nhấn, vô hiệu), phản hồi (thành công, cảnh
báo, lỗi, thông tin)
- Với mỗi token, cho mình mã hex và một dòng mô tả khi nào dùng
Trình bày dưới dạng bảng hoặc danh sách rõ ràng để mình xem lại. Mình sẽ
góp ý và cùng chỉnh trước khi qua nhóm tiếp theo.
Sau khi chốt màu, làm tương tự với:
- Typography — font hiện tại là [tên font], nhưng cứ đề xuất font khác
nếu bạn nghĩ phù hợp hơn. Đưa ra thang chữ đầy đủ với kích thước, độ
đậm, line-height, letter-spacing và tên ngữ nghĩa cụ thể.
- Spacing — token khoảng cách ngữ nghĩa dựa trên hệ cơ số 4px
- Bo góc — thang bo góc gắn với từng ngữ cảnh component
- Đổ bóng/độ nổi — nếu cần
- Bố cục — lưới, margin, độ rộng tối đa
Sản phẩm chạy trên [các nền tảng], nên nhớ điều đó khi đề xuất giá trị.
File giới hạn nền tảng có chi tiết về kích thước màn hình và yêu cầu.
Mình sẽ đi qua từng phần trong chat, chỉnh đến khi ổn mới chuyển qua Figma
để dựng. Đừng tạo gì trong Figma cho đến khi mình nói.
Về quy ước đặt tên, dùng mẫu: category/role/variant (ví dụ:
color/text/primary, spacing/content/gap, radius/component/card). Mỗi
token bắt buộc phải có mô tả — chính mô tả này giúp hệ thống "đọc được
bằng AI".
Bắt đầu nhé. Đọc ngữ cảnh, xem style tile mình sắp gửi, rồi đưa ra đề xuất
hệ thống màu đầy đủ.Prompt giai đoạn 2 — dán vào tab Code của Claude Desktop
Đây là design system của mình: [LINK FIGMA CỦA BẠN]
Đọc toàn bộ file — kiểm tra hết các variable collection, mode, tên token,
scope và mô tả bằng Figma Console MCP.
Cho mình xem kế hoạch dựng trước khi tạo bất cứ thứ gì.
Dựng Storybook v8 để trình bày trực quan các token — bảng màu, mẫu chữ,
biểu đồ spacing. Dùng các mô tả mình đã viết trong Figma làm hướng dẫn sử
dụng cạnh mỗi token. Thêm nút chuyển giữa giá trị Mobile và Web. Ai có link
cũng xem được toàn bộ design system mà không cần tài khoản Figma.
Dùng Style Dictionary để sinh code cho dev dùng trực tiếp: CSS custom
properties cho web, theme Dart cho Flutter (sản phẩm chạy trên
iOS + Android qua Flutter).
Thêm changelog: mỗi lần mình đồng bộ token mới từ Figma, ghi lại thay đổi
kèm giá trị trước/sau, hiển thị thành một trang trong Storybook để dev biết
cần cập nhật gì.
Ghim toàn bộ gói Storybook ở bản v8 để tránh xung đột phụ thuộc.
Danh sách cần giao:
1. File JSON token — bản gốc (primitives, màu, kích thước, kèm giá trị
Mobile + Web), lưu vào repo, được cập nhật bởi script đồng bộ.
2. Bản build Style Dictionary — CSS custom properties cho web, file Dart
riêng cho màu/typography/spacing/theme.
3. Storybook v8 — tab màu (bảng gốc + bảng ngữ nghĩa kèm chuỗi alias), tab
typography (toàn bộ kiểu chữ dạng mẫu sống), tab spacing (thước đo trực
quan), tab kiểm tra độ tương phản WCAG, tab changelog có thể lọc.
4. Nút chuyển Mobile/Web trên thanh công cụ Storybook, cập nhật giá trị
token trực tiếp trên mọi trang.
5. Mô tả sử dụng — mô tả token mình viết trong Figma hiển thị rõ ràng cạnh
từng giá trị, không ẩn đi.
6. Copy nhanh — bấm vào tên biến CSS hoặc Dart là copy được ngay, có xác
nhận khi copy thành công.
7. Huy hiệu link Figma — mỗi token có link quay lại đúng node trong file
Figma gốc.
8. Ví dụ dùng thực tế — hiển thị token đang được dùng ở đâu (ví dụ: nút
dùng màu nền hành động, thông báo lỗi dùng màu chữ lỗi).
9. Script đồng bộ + changelog — một lệnh để so sánh token hiện tại với
Figma, ghi lại thay đổi theo ngày, cập nhật file JSON.
Gợi ý thêm bất cứ điều gì khác nên có trong tài liệu Storybook để dev dùng
dễ hơn.Lưu ý: cả hai prompt trên đều giả định bạn đã chuẩn bị sẵn các file ngữ cảnh (brief sản phẩm, chân dung người dùng, nguyên tắc thiết kế, giới hạn nền tảng) trong phần project instructions từ trước — nếu bỏ qua bước này, Claude vẫn chạy được nhưng kết quả sẽ chung chung hơn nhiều.
Một bài học đáng nhớ về việc đồng bộ dữ liệu
Nhóm Yummy Labs kể lại rằng ban đầu họ định viết script gọi thẳng REST API của Figma để đồng bộ token, nhưng gặp lỗi 403 vì Variables API bị giới hạn ở gói Enterprise — dù token và quyền truy cập đều hợp lệ. Giải pháp thay thế là để Claude Code giao tiếp với plugin console chạy ngay trong Figma Desktop, vốn đọc được biến thiết kế bất kể gói dịch vụ nào. Bài học rút ra khá thực tế cho ai đang tích hợp API bên thứ ba: kiểm tra trước xem phần nào của API bị giới hạn theo gói trả phí, trước khi thiết kế cả quy trình dựa trên nó — nhiều khi đường vòng qua desktop app lại rẻ và ổn định hơn.
Vài lưu ý nếu bạn muốn thử
- Bạn cần cài Figma Desktop (không phải bản web) và mở plugin Desktop Bridge trước khi bắt đầu chat, nếu không Claude sẽ không đọc được file.
- Công cụ MCP này là dự án mã nguồn mở của cộng đồng, không phải sản phẩm chính thức từ Figma — nên khi làm theo, bạn tự cài đặt và cấp token truy cập Figma cho nó, cần cân nhắc về bảo mật như với bất kỳ plugin bên thứ ba nào.
- Storybook trong ví dụ này được ghim ở phiên bản v8 để tránh xung đột gói phụ thuộc khi cài đặt.
Quy trình này không phải phép màu — nó chỉ là cách tổ chức ngữ cảnh gọn gàng và chọn đúng công cụ cho đúng giai đoạn công việc. Nếu bạn đang định dùng Claude cho một dự án thiết kế hay bất kỳ việc gì cần ngữ cảnh dài hạn, thử tách tài liệu thành các file nhỏ có mục đích rõ ràng trước — phần còn lại sẽ dễ thở hơn nhiều.
Để lại một bình luận