Ui: Phân tích chuyên sâu cho nhà phát triển về dự án AI đang thịnh hành (2026)

Ui: Phân tích chuyên sâu cho nhà phát triển về dự án AI đang thịnh hành (2026)

Lúc 2:17 sáng, mô hình vẫn ổn. Sản phẩm thì không.

Chúng tôi có một trợ lý tăng cường bằng truy xuất, trả về câu trả lời có căn cứ trong khoảng 1.8 giây ở phân vị p95, truyền luồng token trơn tru và có điểm đánh giá khá tốt. Nhưng giao diện bao quanh nó lại làm chậm cả nhóm: bong bóng trò chuyện không nhất quán, trích dẫn khó đọc lướt, trạng thái tải nhảy vị trí liên tục, ngăn cài đặt làm hỏng thao tác điều hướng bằng bàn phím, và mỗi lần “sửa nhanh UI” lại biến thành một cuộc tranh luận nữa về hệ thống thiết kế.

Đó là bài toán kỹ thuật mà shadcn-ui/ui giải quyết tốt: không phải “làm AI thông minh hơn”, mà là giúp giao diện sản phẩm bao quanh các hệ thống AI dễ xây dựng, quản lý và sửa đổi hơn.

Kho mã GitHub shadcn-ui/ui đã trở thành một trong những dự án UI nguồn mở quan trọng nhất đối với các nhóm xây dựng ứng dụng web hiện đại, bao gồm cả sản phẩm AI. Dự án tự mô tả là “một tập hợp các thành phần được thiết kế đẹp mắt, có khả năng tiếp cận và một nền tảng phân phối mã”, hỗ trợ các framework được ưa chuộng và các chủ đề xoay quanh base-ui, components, laravel, nextjs, radix-ui, và react.

Ý tưởng cốt lõi đơn giản đến bất ngờ: thay vì cài một thư viện thành phần đóng làm phần phụ thuộc rồi vật lộn với các lớp trừu tượng của nó, bạn sao chép mã nguồn của các thành phần vào dự án của mình. Bạn sở hữu mã đó. Bạn có thể chỉnh sửa nó. Bạn có thể xóa những gì không cần.

Mô hình đó rất quan trọng đối với các ứng dụng AI, nơi UI không chỉ là phần trang trí. Nó là lớp điều khiển cho lời nhắc, công cụ, bản ghi truy vết, nội dung tải lên, trích dẫn, phê duyệt, đầu ra truyền luồng, khôi phục sau lỗi và phản hồi của con người.

Bài toán kỹ thuật: Ứng dụng AI cần nhanh chóng có UI đạt chuẩn sản phẩm

Phần lớn các nhóm phát triển ứng dụng AI đánh giá thấp phạm vi của giao diện người dùng.

Một “ứng dụng trò chuyện đơn giản” thường trở thành:

• Dòng thời gian tin nhắn truyền luồng
• Các điều khiển cho lời nhắc và chỉ dẫn hệ thống
• Lựa chọn mô hình giữa GPT, Claude, Gemini, Llama, Qwen, DeepSeek, Kimi hoặc các điểm cuối nội bộ
• Trạng thái tải lên và phân tích tệp
• Hiển thị nguồn truy xuất
• Kiểm tra lệnh gọi công cụ
• Các bảng đánh giá/gỡ lỗi
• Các trạng thái xác thực và thanh toán
• Các luồng phê duyệt của con người
• Xử lý lỗi do giới hạn tốc độ, hết thời gian chờ, vượt giới hạn ngữ cảnh và bộ lọc an toàn

Backend có thể khó hơn về mặt tư duy, nhưng frontend phải gánh những rắc rối mà người dùng thực sự cảm nhận được.

Các thư viện thành phần truyền thống có ích, nhưng chúng thường mang đến một loại chi phí khác:

• Bạn phụ thuộc vào các lớp trừu tượng ở cấp gói mà bạn không dễ thay đổi.
• Các phần ghi đè kiểu dáng trở nên dễ hỏng.
• Khả năng tiếp cận chỉ được xử lý một phần trừ khi bạn hiểu các thành phần nền tảng.
• Bạn đưa vào sản phẩm nhiều mã hơn mức cần thiết.
• Ứng dụng của bạn bắt đầu trông giống mọi ứng dụng khác dùng cùng thư viện.

shadcn-ui/ui có một cách tiếp cận khác: các thành phần không phải là sản phẩm lúc chạy để bạn sử dụng; chúng là mã nguồn để bạn đưa vào dự án.

Trong thực tế, điều đó thay đổi mô hình bảo trì. Nếu khoảng cách của nút không phù hợp trong quy trình rà soát AI của bạn, bạn chỉnh sửa components/ui/button.tsx. Nếu menu lệnh của bạn cần nhãn hiển thị độ trễ mô hình, bạn sửa trực tiếp. Nếu thẻ trích dẫn cần hiển thị điểm truy xuất hoặc các đoạn tài liệu, bạn nắm quyền kiểm soát mã đánh dấu.

Điều đó nghe có vẻ bình thường cho đến khi bạn phải phát hành một giao diện AI tùy chỉnh mỗi tuần.

Ý nghĩa của shadcn-ui/ui Thực chất là gì

Cách hiểu phù hợp nhất về dự án là hai phần có liên quan với nhau:

1. Một bộ sưu tập thành phần
2. Một nền tảng phân phối mã nguồn

Bộ sưu tập thành phần cung cấp các khối xây dựng UI có thể tái sử dụng: nút, hộp thoại, thẻ, ô nhập liệu, bảng, menu, bảng trượt, biểu mẫu, bảng lệnh và các thành phần cơ sở tương tự thường xuất hiện trong ứng dụng web hiện đại.

Mô hình phân phối là điều tạo nên sự khác biệt. Thay vì làm như sau:

npm install some-ui-library

và nhập các thành phần có mã nguồn bị che khuất từ node_modules, một quy trình shadcn/ui điển hình sẽ thêm các tệp mã nguồn thành phần vào ứng dụng của bạn:

npx shadcn@latest init
npx shadcn@latest add button card dialog input textarea

Sau đó, bạn nhập từ dự án cục bộ của mình:

import { Button } from "@/components/ui/button"
import {
  Card,
  CardContent,
  CardHeader,
  CardTitle,
} from "@/components/ui/card"

Sự khác biệt nằm ở kiến trúc, chứ không phải hình thức. Thành phần trở thành một phần trong cơ sở mã của bạn. Bạn có thể kiểm tra, tái cấu trúc, điều chỉnh theo các token thiết kế hoặc tích hợp nó theo các quy ước của framework.

Hệ sinh thái của dự án thường gắn với React, Next.js, Radix UI, các lớp tiện ích kiểu Tailwind CSS và các tích hợp framework. Các chủ đề của kho mã cũng bao gồm Laravel, phản ánh tham vọng rộng hơn: đây không chỉ là một tập hợp thành phần React, mà còn là cách tiếp cận phân phối mã nguồn cho UI có thể tái sử dụng trên nhiều ngăn xếp ứng dụng.

Kiến trúc: Sở hữu mã nguồn thành phần thay vì trừu tượng hóa lúc chạy

Cách rõ ràng nhất để giải thích kiến trúc là so sánh ranh giới quyền sở hữu.

shadcn-ui/ui nằm giữa một thư viện thành phần và một bộ khởi tạo hệ thống thiết kế. Nó cung cấp các thành phần hoạt động được, nhưng không mặc định rằng những thành phần đó phải được giữ nguyên.

Một ngăn xếp phổ biến có dạng như sau:

app/
  chat/
    page.tsx
components/
  ai/
    model-picker.tsx
    message-list.tsx
    citation-card.tsx
    tool-call-panel.tsx
  ui/
    button.tsx
    card.tsx
    dialog.tsx
    input.tsx
    sheet.tsx
    textarea.tsx
lib/
  ai/
    stream.ts
    models.ts
    retrieval.ts

Ranh giới quan trọng là components/ui. Đó là các thành phần cơ sở dùng chung. Các giao diện dành riêng cho AI của bạn nằm ở lớp phía trên chúng, trong components/ai.

Một nguyên tắc hữu ích trong thực tế:

• components/ui: dùng chung, có thể tái sử dụng, đơn giản
• components/ai: các mẫu tương tác AI dành riêng cho sản phẩm
• lib/ai: định tuyến mô hình, truyền luồng, truy xuất, thực thi công cụ
• app/: định tuyến của framework, hành động phía máy chủ, kết hợp các phần của trang

Điều này tránh biến các thành phần UI cơ sở thành nơi chứa đủ loại hành vi dành riêng cho từng mô hình.

Quy trình thực tế: Xây dựng bảng điều khiển xét duyệt AI

Giả sử bạn đang xây dựng một bảng điều khiển xét duyệt AI nội bộ cho các phiếu hỗ trợ. Backend thực hiện truy xuất trên các phiếu trước đó và soạn bản nháp câu trả lời đề xuất bằng một mô hình như GPT-5.5, Claude Sonnet 4.6, Gemini 3 hoặc một endpoint mô hình mở. Frontend cần hiển thị:

• Phiếu hỗ trợ của khách hàng
• Bản nháp được tạo
• Bằng chứng được truy xuất
• Chỉ báo độ tin cậy
• Thao tác phê duyệt của con người
• Bộ chọn mô hình để gỡ lỗi

Bắt đầu bằng cách thêm các thành phần UI cốt lõi:

npx shadcn@latest init
npx shadcn@latest add button card badge textarea select separator skeleton

Sau đó, định nghĩa rõ ràng cấu hình mô hình của bạn. Đừng giấu cấu hình này trong các nhãn UI.

// lib/ai/models.ts
export type ModelId =
  | "gpt-5.5"
  | "claude-sonnet-4.6"
  | "gemini-3"
  | "qwen"
  | "deepseek"

export const models: Array<{
  id: ModelId
  label: string
  contextHint: string
}> = [
  {
    id: "gpt-5.5",
    label: "GPT-5.5",
    contextHint: "General reasoning and agentic workflows",
  },
  {
    id: "claude-sonnet-4.6",
    label: "Claude Sonnet 4.6",
    contextHint: "Long-form drafting and coding workflows",
  },
  {
    id: "gemini-3",
    label: "Gemini 3",
    contextHint: "Multimodal and general assistant tasks",
  },
  {
    id: "qwen",
    label: "Qwen",
    contextHint: "Open-model route",
  },
  {
    id: "deepseek",
    label: "DeepSeek",
    contextHint: "Open-model route",
  },
]

Bây giờ, hãy kết hợp các thành phần UI cục bộ để tạo bảng xét duyệt:

import { Badge } from "@/components/ui/badge"
import { Button } from "@/components/ui/button"
import {
  Card,
  CardContent,
  CardHeader,
  CardTitle,
} from "@/components/ui/card"
import { Textarea } from "@/components/ui/textarea"

type Evidence = {
  title: string
  snippet: string
  score?: number
}

export function TicketReviewCard({
  ticket,
  draft,
  evidence,
  isStreaming,
}: {
  ticket: string
  draft: string
  evidence: Evidence[]
  isStreaming: boolean
}) {
  return (
    <Card>
      <CardHeader>
        <CardTitle>AI Draft Review</CardTitle>
      </CardHeader>

      <CardContent className="space-y-6">
        <section className="space-y-2">
          <Badge variant="secondary">Customer ticket</Badge>
          <p className="text-sm leading-6 text-muted-foreground">{ticket}</p>
        </section>

        <section className="space-y-2">
          <Badge>{isStreaming ? "Generating" : "Draft ready"}</Badge>
          <Textarea value={draft} className="min-h-40" readOnly />
        </section>

        <section className="space-y-3">
          <h3 className="text-sm font-medium">Retrieved evidence</h3>
          {evidence.map((item) => (
            <div key={item.title} className="rounded-md border p-3">
              <div className="flex items-center justify-between">
                <p className="text-sm font-medium">{item.title}</p>
                {item.score !== undefined && (
                  <span className="text-xs text-muted-foreground">
                    score {item.score.toFixed(2)}
                  </span>
                )}
              </div>
              <p className="mt-2 text-sm text-muted-foreground">
                {item.snippet}
              </p>
            </div>
          ))}
        </section>

        <div className="flex gap-2">
          <Button>Approve reply</Button>
          <Button variant="outline">Request revision</Button>
        </div>
      </CardContent>
    </Card>
  )
}

Đây là lúc cách tiếp cận sở hữu mã nguồn phát huy giá trị. Nếu nút phê duyệt của bạn cần một hộp thoại xác nhận đặc biệt cho nhật ký kiểm toán, bạn không phải chờ thư viện cung cấp prop phù hợp. Nếu khối bằng chứng cần phím tắt, cách xử lý tiêu điểm tùy chỉnh hoặc kiểu giao diện doanh nghiệp có mật độ thông tin cao, bạn có thể xây dựng trực tiếp trên các thành phần cơ sở cục bộ.

Vị trí trong một ngăn xếp AI hiện đại

shadcn-ui/ui không phải là framework suy luận, cơ sở dữ liệu vector, bộ định tuyến mô hình hay môi trường thực thi tác nhân. Nó thuộc lớp sản phẩm.

Một ngăn xếp AI điển hình trong 2026 có dạng như sau:

User Interface
  Next.js / React / Laravel frontend
  shadcn-style components
  streaming state and interaction design

Application Layer
  auth, billing, projects, teams
  prompt templates
  eval dashboards
  human approval workflows

AI Orchestration
  model routing
  tool execution
  retry and timeout policies
  structured outputs

Model Providers
  Claude Opus 4.8 / Sonnet 4.6 / Haiku 4.5
  GPT-5.5
  Gemini 3
  Fable 5 with large-context workflows
  Llama / Qwen / DeepSeek / MiniMax / Kimi

Data Layer
  vector search
  document stores
  event logs
  traces and feedback

Lớp UI là nơi người dùng quyết định liệu họ có tin tưởng hệ thống hay không. Với các sản phẩm AI, niềm tin thường đến từ những chi tiết giao diện bình thường:

• Việc truyền luồng có giúp thấy rõ tiến độ không?
• Các nguồn được truy xuất có dễ đọc không?
• Người dùng có thể kiểm tra các lệnh gọi công cụ không?
• Có thể nhận biết rõ khi mô hình không chắc chắn không?
• Con người có thể ghi đè kết quả đầu ra không?
• Các thao tác gây phá hủy có yêu cầu xác nhận trước khi thực hiện không?
• Điều hướng bằng bàn phím có hoạt động trong các quy trình xét duyệt nhiều thông tin không?

Các thành phần cơ sở giúp giải quyết những câu hỏi này, nhưng không tự động giải quyết chúng. Bạn vẫn cần khả năng phán đoán về sản phẩm.

Một vấn đề thường gặp: các đội ngũ xây dựng cửa sổ trò chuyện đẹp mắt nhưng bỏ qua quy trình gỡ lỗi. Rồi sự cố đầu tiên trong môi trường sản xuất xảy ra — truy xuất kém, định tuyến sai mô hình, JSON sai định dạng, công cụ hết thời gian chờ — và không có UI để kiểm tra những gì đã xảy ra. Với các thành phần có mã nguồn do bạn sở hữu, việc xây dựng các bảng nội bộ để xem dấu vết thực thi, payload của prompt, số liệu độ trễ và quyết định của mô hình rất đơn giản, không cần nhập thêm một framework UI quản trị riêng.

Ví dụ, hãy hiển thị rõ dữ liệu thời gian:

{
  "request_id": "req_92f1",
  "model": "claude-sonnet-4.6",
  "retrieval_ms": 142,
  "first_token_ms": 610,
  "total_ms": 1840,
  "input_tokens": 3912,
  "output_tokens": 428
}

Sau đó, hiển thị dữ liệu đó dưới dạng một thẻ chẩn đoán nhỏ cho người dùng nội bộ. Không phải người dùng nào cũng cần, nhưng mọi đội ngũ kỹ thuật AI rồi sẽ cần.

Ai nên sử dụng

shadcn-ui/ui rất phù hợp với các đội ngũ muốn có quyền kiểm soát mà không phải bắt đầu từ con số không.

Hãy sử dụng nếu:

• Bạn đang xây dựng một sản phẩm sử dụng chủ yếu React hoặc Next.js.
• Bạn cần các thành phần UI cơ sở hiện đại, hỗ trợ khả năng tiếp cận.
• Bạn dự kiến sẽ tùy chỉnh sâu các thành phần.
• Bạn muốn sở hữu mã nguồn thay vì phụ thuộc vào hành vi thư viện dạng hộp đen.
• Ứng dụng của bạn có các quy trình AI cần bảng điều khiển, dòng thời gian, trình soạn thảo hoặc trạng thái xét duyệt tùy chỉnh.
• Đội ngũ của bạn tự tin trong việc bảo trì mã frontend.

Nó đặc biệt hữu ích cho các sản phẩm AI mà UI không phải là một bảng tổng quan tĩnh. Trình soạn thảo prompt, màn hình đánh giá, dòng thời gian trò chuyện, dấu vết thực thi của tác nhân và hàng đợi phê duyệt đều cần thiết kế tương tác tùy chỉnh.

Hãy cân nhắc kỹ hơn nếu:

• Đội ngũ của bạn muốn một hệ thống thiết kế doanh nghiệp được đóng gói hoàn chỉnh.
• Bạn không muốn mã thành phần nằm trong kho mã của mình.
• Bạn thiếu chuyên môn frontend để bảo trì các thành phần được sao chép.
• Bạn yêu cầu quản trị thiết kế tập trung nghiêm ngặt trên nhiều ứng dụng.
• Bạn kỳ vọng việc nâng cấp gói sẽ tự động giải quyết công việc bảo trì UI.

Nói cách khác, shadcn-ui/ui trao cho bạn quyền sở hữu. Quyền sở hữu mang lại sức mạnh, nhưng cũng có cái giá của nó.

Ưu điểm, nhược điểm và hạn chế

Những điểm hiệu quả

Ưu điểm lớn nhất là khả năng kiểm soát cục bộ. Bạn có thể kiểm tra mọi thành phần, hiểu rõ những gì được đưa vào sản phẩm và điều chỉnh chúng cho ứng dụng của mình. Với giao diện AI, điều này cực kỳ thiết thực vì các yêu cầu sản phẩm thay đổi nhanh chóng.

Các điểm mạnh khác:

• Nền tảng hỗ trợ khả năng tiếp cận: Hệ sinh thái thường được xây dựng trên các thành phần cơ sở chú trọng khả năng tiếp cận như Radix UI.
• Giao diện mặc định đẹp: Các thành phần đủ trau chuốt để sử dụng ngay.
• Cấu trúc dễ kết hợp: Các thành phần hoạt động tốt như những khối xây dựng cho giao diện dành riêng cho sản phẩm.
• Ít áp lực từ lớp trừu tượng hóa: Bạn không bị buộc phải dùng một API thành phần đồ sộ.
• Định hướng thân thiện với framework: Định hướng phân phối mã nguồn của dự án giúp nó thích ứng với nhiều dạng ứng dụng, thay vì chỉ một dạng ứng dụng cụ thể.

Những điểm có thể gây bất lợi

Nhược điểm chính là công việc bảo trì. Khi mã nguồn đã được đưa vào kho mã của bạn, bạn chịu trách nhiệm về nó.

Điều đó có nghĩa là:

• Bạn cần theo dõi các thay đổi theo cách thủ công khi những mẫu triển khai từ dự án gốc được cải thiện.
• Các thành phần có thể dần khác biệt giữa nhiều ứng dụng.
• Kỹ sư có thể tùy chỉnh quá mức các thành phần cơ sở thay vì kết hợp chúng để xây dựng thành phần ở cấp cao hơn.
• Việc giữ thiết kế nhất quán đòi hỏi tính kỷ luật.
• Khả năng tiếp cận có thể suy giảm nếu các chỉnh sửa cục bộ làm hỏng cơ chế quản lý tiêu điểm hoặc ngữ nghĩa.

Một ví dụ cụ thể: thành phần hộp thoại ban đầu có thể đáp ứng yêu cầu về khả năng tiếp cận, nhưng một kỹ sư làm việc vội vàng vẫn có thể xóa các nhãn cần thiết, làm hỏng cơ chế trả lại tiêu điểm hoặc che giấu trạng thái quan trọng khỏi trình đọc màn hình. Quyền sở hữu mã nguồn không loại bỏ công việc đảm bảo khả năng tiếp cận; nó giúp bạn thấy rõ cách triển khai.

Một hạn chế khác: shadcn-ui/ui không quyết định mô hình tương tác AI của bạn. Nó sẽ không chỉ cho bạn cách thể hiện mức độ không chắc chắn, cách so sánh đầu ra của các mô hình hay cách thiết kế quy trình phê duyệt an toàn. Nó cung cấp các thành phần nền tảng chất lượng cao, chứ không phải một sản phẩm AI hoàn chỉnh.

Lời khuyên thực tế về kiến trúc

Trong thực tế, tôi khuyên bạn nên xem shadcn/ui các thành phần như một lớp nền tảng cục bộ.

Giữ các thành phần UI dùng chung của bạn gọn sạch:

components/ui/button.tsx
components/ui/dialog.tsx
components/ui/table.tsx
components/ui/tabs.tsx

Xây dựng riêng các thành phần chuyên biệt cho AI:

components/ai/model-selector.tsx
components/ai/streaming-message.tsx
components/ai/retrieval-sources.tsx
components/ai/tool-call-log.tsx
components/ai/eval-result-card.tsx

Tránh cách làm sai này:

components/ui/ai-button.tsx
components/ui/prompt-dialog.tsx
components/ui/rag-card.tsx

Khi các khái niệm chuyên biệt cho AI len vào components/ui, các thành phần cơ sở sẽ khó tái sử dụng hơn.

Với các ứng dụng AI nhạy cảm với độ trễ, cũng nên tránh gắn trạng thái hiển thị trực tiếp với một đối tượng phản hồi khổng lồ. Giao diện truyền phát dễ bảo trì hơn khi trạng thái được tách riêng:

type AssistantRunState = {
  status: "idle" | "retrieving" | "generating" | "complete" | "error"
  draftText: string
  evidence: Evidence[]
  timings: {
    retrievalMs?: number
    firstTokenMs?: number
    totalMs?: number
  }
}

Cách này tương ứng tự nhiên với các thành phần UI: khung chờ trong lúc truy xuất, văn bản truyền phát trong lúc tạo nội dung, thẻ bằng chứng khi truy xuất hoàn tất và huy hiệu chẩn đoán khi có dữ liệu thời gian.

Hướng phát triển của dự án

Điểm thú vị của shadcn-ui/ui không chỉ nằm ở bộ thành phần. Đó còn là ý tưởng phân phối mã nguồn.

Các nhóm hiện đại ngày càng muốn có phần mềm tái sử dụng được mà họ có thể sao chép, kiểm tra và chỉnh sửa, đặc biệt khi các công cụ lập trình AI trở thành một phần của công việc phát triển hằng ngày. Mô hình thành phần do người dùng sở hữu mã nguồn phù hợp với bối cảnh đó. Kỹ sư có thể yêu cầu trợ lý lập trình AI điều chỉnh một thành phần cục bộ vì mã nguồn đã có trong kho mã. Không cần phân tích ngược lớp trừu tượng của một gói hay vật lộn với các chi tiết nội bộ không được ghi lại trong tài liệu.

Điều đó không khiến nó trở thành phép màu. Nó chỉ khiến mô hình thành phần phù hợp với cách nhiều nhóm thực sự làm việc: sao chép một cách triển khai tốt, điều chỉnh rồi tiếp tục đưa sản phẩm đến người dùng.

Với các nhóm phát triển sản phẩm AI, đó thường là sự đánh đổi phù hợp.

Những điểm thực tiễn cần ghi nhớ

• shadcn-ui/ui giải quyết một vấn đề thực tế trong kỹ thuật sản phẩm: xây dựng giao diện trau chuốt, dễ tiếp cận và có thể tùy chỉnh mà không từ bỏ quyền sở hữu các thành phần.
• Kiến trúc của nó đặt mã nguồn lên hàng đầu: các thành phần được thêm vào kho mã của bạn và được bảo trì như mã cục bộ, thay vì chỉ được sử dụng qua API của các gói có phần triển khai không minh bạch.
• Nó phù hợp nhất với lớp UI của các hệ thống AI: trò chuyện, hàng đợi xét duyệt, bảng điều khiển đánh giá, bộ chọn mô hình, dấu vết thực thi công cụ và phần hiển thị nguồn truy xuất.
• Sự đánh đổi chính là công việc bảo trì: khi sao chép các thành phần, nhóm của bạn chịu trách nhiệm về tính nhất quán, khả năng tiếp cận và việc nâng cấp.
• Lưu components/ui mang tính dùng chung và đặt hành vi chuyên biệt cho AI vào components/ai để tránh đưa các đặc thù đó vào thành phần cơ sở.
• Hãy dùng nó khi bạn cần cả tốc độ lẫn khả năng kiểm soát; tránh dùng nếu bạn muốn một hệ thống thiết kế được quản lý toàn diện, nâng cấp tập trung và chỉ phải chịu trách nhiệm tối thiểu về giao diện phía người dùng.