Codex + một công cụ bí mật là quy trình thiết kế mà agency của tôi đang áp dụng... và kết quả đầu ra thực sự ở một đẳng cấp khác.
Tôi đã nói điều này trong nhiều tháng. Nếu ứng dụng của bạn trông giống như AI slop, thì đó không phải là vấn đề của Codex. Đó là vấn đề của quy trình.
Hầu hết các builder đều mắc kẹt trong một vòng lặp. Họ ship tính năng bằng AI. Backend hoạt động. Logic ổn định. Nhưng giao diện trông giống hệt mọi ứng dụng vibe code khác. Người dùng quyết định chỉ trong hai giây liệu nó có thực sự chuyên nghiệp hay không.
Cách khắc phục cũ là thuê một designer. Chờ đợi hàng tuần để có file Figma. Sau đó nhìn developer diễn giải những thiết kế đó và xây dựng lại chúng trong code. Đến khi thiết kế được đưa vào thực tế, bạn đã mất đà và đốt tiền một cách không cần thiết.
Toàn bộ quy trình đó giờ đây là tùy chọn.
Trong bài hướng dẫn này, tôi đã xây dựng Haven, một concept ứng dụng di động bất động sản. Toàn bộ hệ thống thiết kế trong 20 phút. Mọi màn hình được thiết kế trong vòng chưa đầy một giờ. Code sản phẩm được ship thông qua Codex mà không cần viết lại một dòng CSS nào.
Đây là quy trình tôi đang chạy. Và mọi builder ship sản phẩm bằng AI cần hiểu cách nó hoạt động.
Moonchild Thực Sự Là Gì
Công cụ bí mật là Moonchild.
Tôi đã thử nghiệm hầu hết mọi công cụ thiết kế AI ra mắt trong năm qua. Hầu hết trông ổn ở màn hình đầu tiên, nhưng sụp đổ ngay khi bạn xây dựng trang thứ hai. Sự nhất quán là vấn đề. Moonchild giải quyết nó theo cách chưa từng có công cụ nào làm được.
Đó là một canvas thiết kế dạng chat, bắt đầu từ hệ thống thiết kế của bạn. Không phải từ một prompt trống. Không phải từ một ảnh chụp màn hình. Từ hệ thống thực tế của bạn. Bạn đưa hệ thống của mình vào theo ba cách:
→ Import từ Figma, GitHub hoặc URL trực tiếp
→ Mô tả thương hiệu của bạn cho Agentic Design System Builder
→ Thả cảm hứng thiết kế từ Dribbble hoặc bất kỳ đâu khác
Khi hệ thống đó đã được thiết lập, bạn không prompt để có thiết kế theo cách cũ nữa. Bạn dán một PRD. Nó tạo ra toàn bộ màn hình dựa trên hệ thống của bạn. Từ đó bạn chỉ đạo nghệ thuật.
Và đường dẫn xuất là thứ khép kín vòng lặp. Moonchild ship một MCP connector chuyển trực tiếp các thiết kế của bạn vào Codex dưới dạng đầu ra có cấu trúc. Không phải ảnh chụp màn hình để Codex diễn giải. Dữ liệu thiết kế thực tế. Component, token, bố cục, mọi thứ.
Đó là quy trình. Bây giờ đây là cách thực sự sử dụng nó.
Vấn Đề Với Cách Hầu Hết Builder Sử Dụng AI Cho Thiết Kế
Đây là những gì hầu hết builder làm.
Họ yêu cầu Codex xây dựng một tính năng mới. Nó ship. Trông ổn. Sau đó họ yêu cầu tính năng tiếp theo. Trông hơi khác một chút. Đến tính năng thứ năm, ứng dụng trông giống như năm sản phẩm khác nhau được ghép lại.
Đây là điều mọi người muốn nói khi họ bảo thiết kế AI tệ.
Mô hình không tệ. Quy trình mới tệ.
Codex không biết ngôn ngữ thiết kế của bạn là gì. Mỗi prompt là một ngữ cảnh mới. Mỗi màn hình là một phỏng đoán. Mỗi component trôi dạt khỏi cái trước đó. Màu sắc thay đổi. Kiểu chữ thay đổi. Mọi thứ cộng dồn.
Cách khắc phục rất đơn giản. Cung cấp cho Codex một hệ thống để tuân theo. Sau đó cung cấp cho nó thiết kế thực tế để xây dựng.
Hầu hết các quy trình chỉ cung cấp một trong hai. Moonchild cùng với kết nối MCP cung cấp cả hai cùng một lúc.
Bước 1: Xây Dựng Hệ Thống Thiết Kế Của Bạn Trước. Luôn Luôn.
Đây là bước mọi người đều bỏ qua. Nó cũng là bước quan trọng nhất.
Tại @ignytlabs, chúng tôi xây dựng một hệ thống thiết kế cho mọi khách hàng trước khi chạm vào một màn hình nào. Trước đây việc này tốn của một designer hai ngày. Moonchild làm điều đó trong khoảng 20 phút.
Trong bài hướng dẫn này, tôi đã xây dựng Haven, một concept ứng dụng di động bất động sản. Có một vài cách để đưa hệ thống thiết kế vào Moonchild. Bạn có thể import từ Figma, GitHub hoặc URL trực tiếp. Bạn có thể mô tả thương hiệu của mình cho Agentic Design System Builder. Đối với Haven, tôi đã làm những gì tôi thường làm khi bắt đầu từ một vibe. Cảm hứng thiết kế từ Dribbble. Tôi thả vào ba ảnh chụp màn hình của các ứng dụng bất động sản di động đã thể hiện đúng cảm giác tôi muốn hướng tới và một mô tả ngắn về Haven là gì và nó dành cho ai. Công cụ đã trích xuất ngôn ngữ thiết kế và xây dựng hệ thống từ đầu.
Điều làm tôi ngạc nhiên là mọi thứ đều có thể xem trước. Hầu hết các công cụ AI, bao gồm quy trình Google Stitch mà tôi đã viết trong bài trước, đưa cho bạn một file token phẳng. Màu sắc. Phông chữ. Có thể là khoảng cách. Công cụ này làm một điều khác biệt. Nó xây dựng một thư viện component đầy đủ và một gallery. Mọi badge, button, card và chip được hiển thị theo cách chúng sẽ thực sự trông như thế nào bên trong ứng dụng của bạn. Nhấp vào bất kỳ component nào và bạn thấy nó trực tiếp, với các điều khiển để kiểm tra các biến thể và kích thước. Ngay bên dưới bản xem trước, bạn nhận được JavaScript, CSS, ví dụ và dependency thực tế cho component đó. Sẵn sàng để kéo vào codebase.
Gallery là phần thực sự thay đổi cách bạn thiết kế. Thay vì đoán xem một "badge thương hiệu" hoặc "badge đánh giá" nên trông như thế nào trong ngữ cảnh, bạn thấy tất cả chúng cạnh nhau. Đang bán. Cho thuê. Nổi bật. Toàn bộ các thành viên cùng một lúc. Bạn đưa ra quyết định thiết kế sáng suốt trước khi một màn hình nào được tạo ra.
Đó là sự khác biệt giữa một style sheet và một hệ thống thực sự.
Bước 2: Từ PRD Đến UI
Khi hệ thống thiết kế của bạn đã được thiết lập, bạn không prompt để có thiết kế theo cách cũ nữa.
Bạn dán một PRD.
Một bản tóm tắt tính năng một trang. Một đặc tả sản phẩm. Một tuyên bố mục tiêu. Bất cứ thứ gì bạn có.
Đối với Haven, tôi đã dán một PRD có cấu trúc bao gồm phần giới thiệu sản phẩm, mục tiêu, người dùng mục tiêu và vai trò, các tính năng chính và phạm vi MVP, toàn bộ hành trình người dùng, stack kỹ thuật và định hướng thiết kế. Khoảng một trang. Đủ cụ thể để cung cấp cho công cụ ngữ cảnh thực sự. Đủ cấu trúc để nó lấy đúng chi tiết vào đúng màn hình.
Sau đó tôi làm một điều mà hầu hết mọi người bỏ qua.
Tôi đã động não với nó trước khi tạo ra một màn hình nào.
Đây là điểm mấu chốt mà hầu hết builder bỏ lỡ. Chế độ chat giữ toàn bộ ngữ cảnh PRD. Thay vì đổ PRD và nhấn generate, bạn nói về sản phẩm trước. Xác nhận danh sách màn hình. Khóa mẫu điều hướng. Xác định trước hệ thống phân cấp của các màn hình chính trước khi bất kỳ pixel nào tồn tại.
Đối với Haven, tôi đã hỏi:
→ "Dựa trên PRD này, bạn đề xuất chúng ta nên xây dựng những màn hình nào trước? Tôi có thiếu gì cho một ứng dụng bất động sản không?"
→ "Điều hướng chính có nên là tab dưới cùng với Trang chủ, Tìm kiếm, Yêu thích, Hồ sơ không? Hay một cái gì đó khác?"
→ "Trước khi tạo, hãy cho tôi biết thứ tự ưu tiên cho màn hình Chi tiết Bất động sản. Ảnh trước, sau đó tên và giá, rồi thông số kỹ thuật, sau đó tiện ích, rồi đại lý. Xác nhận hoặc cải thiện."
→ "Được rồi, bây giờ hãy tiến hành và tạo các màn hình này ở cả chế độ sáng và tối trong khi tuân thủ hệ thống thiết kế mà tôi hiện đang có. Đảm bảo bạn hoàn thành toàn bộ hành trình người dùng và tạo tất cả các màn hình."
Khi tôi nhấn generate, công cụ đã biết sản phẩm tốt hơn hầu hết các designer sau cuộc gọi khách hàng đầu tiên của họ.
Bây giờ là một lưu ý nhanh về các biến thể. Hãy đọc kỹ điều này.
Một tính năng thú vị: bạn có thể tạo các biến thể khác nhau cho màn hình của mình. Bạn chỉ cần đề cập rõ ràng với Moonchild và nó sẽ xử lý. Đối với Haven, tôi muốn ba hướng thẩm mỹ khác nhau cho toàn bộ ứng dụng trước khi cam kết với một hướng. Đây là prompt chính xác tôi đã sử dụng:
“Tôi muốn bạn tạo 3 concept thiết kế UI di động hoàn chỉnh cho Haven:
Concept 1 - Warm Editorial: Nền kem, khoảng cách rộng rãi, tiêu đề serif cho tên bất động sản, đổ bóng mềm mại, xử lý ảnh theo phong cách tạp chí.
Concept 2 - Bold Modern: Chế độ tối, độ tương phản cao, sans-serif xuyên suốt, các góc sắc nét, do ảnh dẫn dắt với hình ảnh cạnh nhau.
Concept 3 - Premium Minimal: Bảng màu trung tính (trắng kem, than chì, một điểm nhấn), kiểu chữ tinh tế, nhiều không gian thở, các tương tác vi mô tinh tế.
Sử dụng hệ thống thiết kế đã kết nối làm nền tảng nhưng để mỗi concept kéo hệ thống theo một hướng thẩm mỹ khác nhau. Tạo toàn bộ màn hình, không chỉ các phần. Bạn sẽ làm gì?”
Hãy để ý câu "Bạn sẽ làm gì?" ở cuối. Đó là chi tiết nhỏ làm cho việc này hiệu quả. Thay vì chỉ tạo mọi thứ một cách mù quáng, công cụ đã quay lại với một kế hoạch.
Nó nói sẽ xây dựng 5 màn hình đại diện cho mỗi concept trước. Tôi sẽ xem xét ba hướng cạnh nhau. Khi tôi chọn hướng mình muốn, nó sẽ đi và thiết kế toàn bộ ứng dụng theo hướng đó.
Điều đó thay đổi hoàn toàn phương trình chi phí. Bạn không trả tiền cho ba bản dựng hoàn chỉnh. Bạn trả tiền cho ba bản dùng thử nhanh, sau đó là một bản dựng hoàn chỉnh duy nhất theo hướng bạn thực sự chọn.
Tôi đã chọn Warm Editorial. Toàn bộ bộ màn hình được trả về tiếp theo.
Bây giờ là phần thực sự làm tôi ngạc nhiên.
Mọi màn hình Moonchild tạo ra đều có thể tương tác ở chế độ xem trước. Không phải mockup tĩnh. Thực sự có thể tương tác.
Bạn có thể nhấp vào các trường nhập liệu. Chạm vào các nút. Di chuyển giữa các màn hình như một người dùng thực sự đang thử nghiệm prototype trước khi bất kỳ code nào được viết. Đối với Haven, tôi đã bắt được hai vấn đề về luồng trong bản xem trước mà nếu không sẽ được ship lên Codex. Màn hình chi tiết bất động sản không có cách rõ ràng để quay lại duyệt. CTA liên hệ đại lý ở quá xa phía dưới màn hình. Cả hai sẽ được ship nếu tôi đưa thiết kế cho Codex mà không nhấp qua trước.
Đó là điểm mấu chốt. Bạn kiểm tra sản phẩm trước khi bất kỳ code nào được viết.
Vòng lặp tinh chỉnh là phần cuối cùng.
Khi một màn hình cần chỉnh sửa, bạn không prompt lại từ đầu. Bạn chọn màn hình đó, bảo công cụ thay đổi gì, và nó tạo ra một phiên bản v2 tại chỗ. Muốn một hero điện ảnh hơn? v2. Muốn đổi bố cục card thành dạng danh sách? v3. Các biến thể xếp chồng lên nhau để bạn có thể so sánh và chọn cái mạnh nhất.
Đối với màn hình chi tiết bất động sản của Haven, tôi đã trải qua ba lần lặp. v1 có khối đại lý quá cao. v2 đã sửa hệ thống phân cấp nhưng thư viện ảnh có vẻ nhỏ. v3 hoàn thiện cả hai. Mất khoảng 8 phút qua lại.
Bạn không phải quản lý từ một bảng trống. Bạn đang tinh chỉnh một hướng đi thực sự. Đây là phần cảm thấy gần nhất với việc làm việc với một designer cao cấp.
Bước 3: Kết Nối Moonchild Với Codex Qua MCP
Đây là nơi quy trình trở nên TUYỆT VỜI.
Hệ thống thiết kế cung cấp cho Codex các quy tắc. Kết nối MCP cung cấp cho Codex một thứ mạnh mẽ hơn. Truy cập trực tiếp vào đầu ra thiết kế thực tế. Không phải ảnh chụp màn hình. Không phải mô tả văn bản về thiết kế. Dữ liệu thiết kế có cấu trúc mà Codex có thể đọc và xây dựng lại.
Đây là cách thiết lập:
→ Vào Cài đặt Moonchild, sau đó chọn MCP
→ Sao chép lệnh cài đặt cho thiết lập của bạn
→ Mở Codex CLI
→ Dán lệnh cài đặt
→ Xác thực với tài khoản Moonchild của bạn
→ Xong
Khi đã kết nối, Codex thấy cả hệ thống thiết kế của bạn và các màn hình Haven cụ thể mà bạn đã thiết kế.
Bước 4: Codex Ship Code
Bây giờ bạn yêu cầu Codex như thế này:
Lấy dự án Ứng dụng Di động Bất động sản Haven bằng Moonchild MCP và cho tôi biết chúng ta có những màn hình nào bên trong.
Prompt đầu tiên này thực hiện hai công việc. Nó xác nhận MCP được kết nối đúng cách. Và nó cho Codex thấy toàn bộ mọi màn hình bạn đã thiết kế.
Một mẹo nhanh trước khi bạn để Codex làm bất cứ điều gì nặng hơn. Hãy ở chế độ lập kế hoạch. Codex hiển thị những gì nó sắp làm trước khi thực thi. Đọc kế hoạch mọi lúc. Đảm bảo nó hiểu bạn muốn những màn hình nào, theo thứ tự nào và ở độ chính xác nào. Đây là sự khác biệt giữa Codex code những gì bạn thực sự cần và Codex code những gì nó nghĩ bạn cần.
Khi bạn đã xem xét kế hoạch và hướng nó đến màn hình bạn muốn, Codex lấy dữ liệu thiết kế trực tiếp từ Moonchild, tham chiếu hệ thống thiết kế của bạn và viết code. Nó thậm chí còn thêm các hover state, transition và xử lý cạnh vì nó đang làm việc từ dữ liệu thiết kế thực tế thay vì phỏng đoán từ một prompt.
Kết quả. UI đạt chuẩn sản phẩm trong codebase thực tế của bạn, khớp chính xác với thiết kế, trong vài phút.
Tại @ignytlabs, chúng tôi từng dự trù hai tuần cho thiết kế cho mỗi MVP của khách hàng. Một designer sẽ xây dựng file Figma. Một developer sẽ diễn giải nó. Sự diễn giải sẽ sai lệch. Chúng tôi sửa. Lặp lại. Với quy trình này, toàn bộ vòng lặp thu gọn thành một buổi chiều làm việc duy nhất. Chất lượng tương tự. Biên lợi nhuận cao hơn. Ít chuyển đổi ngữ cảnh hơn nhiều.
Khi Nào Nên Sử Dụng Quy Trình Này
Đây không phải là quy trình phù hợp cho mọi đội ngũ. Hãy trung thực về thời điểm nó phù hợp.
Sử dụng khi:
→ Bạn đang ship MVP với tư cách là builder solo hoặc đội nhóm nhỏ
→ Tính nhất quán của thiết kế liên tục bị phá vỡ giữa các màn hình
→ Bạn không muốn duy trì một quy trình riêng biệt từ Figma đến designer đến developer
→ Bạn đã có một hệ thống thiết kế và muốn nó được áp dụng ở mọi nơi
Bỏ qua khi:
→ Bạn ở quy mô lớn với một đội ngũ thiết kế nội bộ đầy đủ và một thư viện Figma trưởng thành
→ Bạn cần bàn giao pixel-hoàn hảo cho một trang web tiếp thị hoặc công việc thương hiệu nơi mọi bóng đổ đều quan trọng
→ Codebase của bạn có các mẫu UI tùy chỉnh cao cần công việc thiết kế chuyên biệt
Đối với 80% builder ship MVP và sản phẩm SaaS, quy trình này bao gồm mọi thứ bạn cần.
Những Điều Cần Lưu Ý
Một vài cảnh báo trung thực trước khi bạn chạy quy trình này.
Chất lượng hệ thống thiết kế của bạn quyết định chất lượng đầu ra. Rác vào, rác ra. Một file Figma nửa vời với ba token màu sắc sẽ tạo ra các màn hình tầm thường. Dành thời gian cho hệ thống ngay từ đầu. Nó sẽ mang lại lợi ích cho mọi màn hình sau này.
Chất lượng PRD rất quan trọng. Một bản tóm tắt mơ hồ sẽ cho bạn các màn hình chung chung. Một PRD cụ thể với luồng người dùng, các cạnh và hệ thống phân cấp rõ ràng sẽ cho bạn các thiết kế hữu ích. Đây không phải là hạn chế của công cụ. Đó là hạn chế về tư duy.
Bạn vẫn cần gu thẩm mỹ. Công cụ tạo ra. Bạn chỉ đạo. Việc chọn đúng biến thể và tinh chỉnh nó là nơi khả năng phán đoán của bạn sống. Nếu bạn bỏ qua bước quản lý, bạn sẽ quay lại vibe design.
Một số component cần chỉnh sửa thủ công. Các trạng thái hoạt ảnh phức tạp, các mẫu tương tác tùy chỉnh, bất cứ thứ gì nằm ngoài hệ thống thiết kế đều cần một lượt thủ công trong Codex. MCP đưa bạn đến 90%. 10% cuối cùng là gu thẩm mỹ của bạn.
Điều Này Thực Sự Có Nghĩa Là Gì
Đây là quan điểm trung thực của tôi.
Nút thắt cổ chai trong việc ship các sản phẩm do AI xây dựng chưa bao giờ là code. AI có thể viết code. Nút thắt cổ chai luôn là lớp thiết kế. Sự nhất quán, gu thẩm mỹ, hệ thống kết nối mọi thứ với nhau.
Nút thắt cổ chai đó vừa sụp đổ.
Tại agency của chúng tôi, chúng tôi từng dự trù hai tuần cho thiết kế cho mỗi MVP của khách hàng. Thuê một designer. Chờ file Figma. Nhìn developer diễn giải nó. Lặp lại. Những gì từng mất hai tuần giờ chỉ mất hai ngày. Chất lượng tương tự. Giao hàng nhanh hơn. Biên lợi nhuận cao hơn.
Đây là quy trình mà các đội ngũ có ngân sách đã có với quy trình Figma cộng với designer cộng với developer của họ. Sự khác biệt là giờ đây các builder solo, agency indie và studio nhỏ có được đòn bẩy tương tự mà không cần nhân sự.
Năm 2026 sẽ là một năm KHÔNG CÔNG BẰNG cho các agency và builder nào nắm bắt được điều này trước.
TLDR
→ Đừng đổ lỗi cho Codex về UI tệ. Codex không phải là vấn đề. Quy trình của bạn mới là vấn đề.
→ Bước 1: Xây dựng hệ thống thiết kế của bạn bên trong Moonchild. Import từ Figma, GitHub hoặc URL trực tiếp. Hoặc mô tả thương hiệu của bạn. Hoặc thả cảm hứng Dribbble như tôi đã làm cho Haven.
→ Bước 2: Dán PRD của bạn. Động não trong chế độ chat trước khi tạo. Khóa danh sách màn hình và mẫu điều hướng trước.
→ Mặc định tạo một biến thể. Yêu cầu rõ ràng nhiều biến thể trên các màn hình hero với các vibe khác nhau được chỉ định.
→ Sử dụng bản xem trước tương tác để kiểm tra luồng trước khi bất kỳ code nào được viết. Tinh chỉnh các màn hình với các lần lặp v2, v3 tại chỗ.
→ Bước 3: Kết nối Moonchild với Codex qua MCP. Điều này cung cấp cho Codex dữ liệu thiết kế thực tế, không phải ảnh chụp màn hình.
→ Bước 4: Yêu cầu Codex xây dựng từng màn hình bằng MCP. UI đạt chuẩn sản phẩm được ship trong vài phút.
→ Chất lượng hệ thống thiết kế của bạn quyết định chất lượng đầu ra. Hãy đầu tư vào đó.
→ Vòng lặp Figma đến bàn giao cho developer đã chết. Một quy trình duy nhất giờ đây chạy thiết kế và code cùng nhau.
Cùng nhau chiến thôi.
