feat: add full stage-2 multilingual support for 8 locales
Translate all 24 stage-2 chapters (frontend, backend, AI capabilities, assignments) to ja-jp, ko-kr, zh-tw, es-es, fr-fr, de-de, ar-sa, vi-vn. Update VitePress config with sidebar labels, nav links, and sidebar entries for each locale. Images reference zh-cn originals via absolute paths. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
sanbuphy
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,346 @@
|
||||
# Thực chiến phát triển SaaS AI tạo văn bản marketing
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn xoay quanh một PRD thực tế, hoàn thành từ con số không một sản phẩm SaaS AI tạo văn bản marketing dành cho nhà phát triển độc lập và đội nhóm nội dung. Bạn sẽ sử dụng Supabase làm dịch vụ backend, Stripe làm hệ thống thanh toán, hoàn thành toàn bộ quá trình từ phân tích yêu cầu đến triển khai lên mạng.
|
||||
|
||||
Đây là phần thực chiến tổng hợp của Stage 2. Trong các chương trước, bạn đã học riêng biệt các kỹ năng đơn lẻ như搭建 trang frontend, phát triển interface backend, thao tác cơ sở dữ liệu, tích hợp thanh toán — dự án này yêu cầu bạn kết nối tất cả lại, bàn giao một nguyên mẫu sản phẩm có thể chạy được.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm vững các nội dung sau:
|
||||
|
||||
- Thiết kế trang frontend và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển interface backend ([Viết mã interface](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Tích hợp thanh toán ([Hệ thống thanh toán Stripe](../../backend/stripe-payment/))
|
||||
- Quy trình làm việc Git và triển khai ([Học sử dụng Git và Github](../../backend/git-workflow/), [Triển khai ứng dụng web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành thực chiến này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc và hiểu một PRD thực tế, từ đó trích xuất danh sách nhiệm vụ phát triển
|
||||
2. Sử dụng AI hỗ trợ tạo trang frontend và interface backend từng bước
|
||||
3. Sử dụng Supabase thực hiện xác thực người dùng, thao tác cơ sở dữ liệu
|
||||
4. Tích hợp Stripe thực hiện chức năng đăng ký trả phí
|
||||
5. Xây dựng trang quản lý backend và hoàn thành tích hợp end-to-end
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một SaaS AI tạo văn bản marketing, bao gồm ba hệ thống con:
|
||||
|
||||
| Hệ thống con | Trách nhiệm |
|
||||
|--------|------|
|
||||
| **Trang chủ frontend** | Giới thiệu sản phẩm, giá cả, FAQ, chuyển đổi đăng ký |
|
||||
| **Bàn làm việc người dùng** | Nhập thông tin sản phẩm, tạo văn bản, xem lịch sử, nâng cấp gói |
|
||||
| **Bảng quản lý backend** | Quản lý người dùng, bản ghi tạo, dữ liệu thanh toán, tổng quan vận hành |
|
||||
|
||||
Backend sử dụng Supabase cung cấp cơ sở dữ liệu và xác thực, Stripe xử lý thanh toán, mô hình AI tạo văn bản marketing.
|
||||
|
||||
::: tip Lối vào PRD
|
||||
Tài liệu yêu cầu của dự án này trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/copywriting-platform-supabase/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, làm rõ trang, chức năng, xác thực, phạm vi thanh toán' },
|
||||
{ title: 'Xây dựng khung', description: 'Dùng AI tạo ba bộ khung frontend (www / app / admin)' },
|
||||
{ title: 'Tích hợp backend', description: 'Xác thực Supabase, interface tạo, thanh toán Stripe' },
|
||||
{ title: 'Tích hợp lên mạng', description: 'Chạy end-to-end, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Hệ thống có mấy lối vào? Mỗi cái bao phủ những trang nào?
|
||||
- Chức năng cốt lõi của mỗi trang là gì?
|
||||
- Backend bao gồm những module và bảng dữ liệu nào?
|
||||
- Thiết kế giá gói, quy trình thanh toán, hạn mức miễn phí như thế nào?
|
||||
- Phạm vi MVP là gì? Phiên bản đầu tiên làm gì, không làm gì?
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu không rõ yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận kiến trúc hệ thống
|
||||
|
||||
Dựa trên PRD, sắp xếp kiến trúc tổng thể của hệ thống:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["Trang chủ frontend"]
|
||||
prd --> app["Bàn làm việc người dùng"]
|
||||
prd --> admin["Bảng quản lý backend"]
|
||||
app --> auth["Xác thực"]
|
||||
app --> gen["Nhiệm vụ tạo văn bản"]
|
||||
gen --> db["Cơ sở dữ liệu"]
|
||||
billing["Thanh toán & Gói"] --> db
|
||||
admin --> analytics["Bảng điều khiển Người dùng / Tạo / Thanh toán"]
|
||||
```
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo trang frontend
|
||||
|
||||
Sử dụng AI tạo trước cấu trúc cơ bản và dữ liệu giả cho tất cả các trang.
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Dựa trên PRD hiện tại, giúp tôi tạo khung frontend cho một SaaS AI tạo văn bản marketing.
|
||||
|
||||
Yêu cầu:
|
||||
1. Chia thành ba lối vào: www, app, admin
|
||||
2. Trang chủ bao gồm: trang chính, giá cả, FAQ
|
||||
3. app bao gồm: đăng nhập, đăng ký, bàn làm việc tạo, lịch sử, trang gói
|
||||
4. admin bao gồm: trang chính backend, quản lý người dùng, bản ghi tạo, đơn hàng thanh toán
|
||||
5. Trước tiên chỉ tạo cấu trúc trang và dữ liệu giả, không kết nối interface thực
|
||||
6. Phong cách giống SaaS hiện đại, không giống demo lớp học
|
||||
```
|
||||
|
||||
### 2.2 Hoàn thiện trang cốt lõi
|
||||
|
||||
Sau khi搭建 khung, tập trung hoàn thiện trang bàn làm việc tạo văn bản (Dashboard):
|
||||
|
||||
```text
|
||||
Xin tiếp tục hoàn thiện trang /dashboard.
|
||||
|
||||
Đây là bàn làm việc AI tạo văn bản marketing.
|
||||
|
||||
Các trường form bên trái:
|
||||
- Tên sản phẩm
|
||||
- Giới thiệu một câu
|
||||
- Người dùng mục tiêu
|
||||
- 3 điểm bán hàng
|
||||
- Kênh投放 (trang chủ, moments, Xiaohongshu, Douyin, email)
|
||||
|
||||
Vùng kết quả bên phải dự phòng:
|
||||
- Tiêu đề chính
|
||||
- Tiêu đề phụ
|
||||
- CTA
|
||||
- 3 phiên bản văn bản ngắn
|
||||
- Văn bản dài
|
||||
|
||||
Trước tiên dùng mock data chạy thông tương tác.
|
||||
|
||||
Yêu cầu:
|
||||
- Sau khi nhấp "Tạo văn bản" có trạng thái loading
|
||||
- Vùng kết quả thiết kế trạng thái trống
|
||||
- Layout responsive, màn hình rộng và hẹp đều hiển thị bình thường
|
||||
```
|
||||
|
||||
### 2.3 Xác minh cấu trúc trang
|
||||
|
||||
Kiểm tra từng mục:
|
||||
|
||||
- [ ] Route của ba lối vào có độc lập không
|
||||
- [ ] Số lượng trang có nhất quán với PRD không
|
||||
- [ ] Layout vùng form và vùng kết quả của Dashboard có hợp lý không
|
||||
- [ ] Dữ liệu giả đã thể hiện trạng thái UI cơ bản chưa
|
||||
|
||||
### Gặp trở ngại?
|
||||
|
||||
Nếu bạn bị kẹt ở giai đoạn搭建 frontend, có thể ôn lại các chương sau:
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Thiết kế trang và nút bấm theo quy chuẩn UI](../../frontend/multi-product-ui/)
|
||||
- [Làm cho giao diện đẹp hơn bằng LLM và Skills](../../frontend/llm-skills-beautiful/)
|
||||
- [Từ nguyên mẫu thiết kế đến code dự án](../../frontend/design-to-code/)
|
||||
- [Cập nhật giao diện với thư viện component hiện đại](../../frontend/modern-component-library/)
|
||||
|
||||
## Phần 3: Tích hợp Backend
|
||||
|
||||
### 3.1 Kết nối đăng nhập Supabase
|
||||
|
||||
```text
|
||||
Xin coi tôi là người mới bắt đầu hoàn toàn, hướng dẫn tôi từng bước hoàn thành kết nối đăng nhập Supabase.
|
||||
|
||||
Cần bạn giúp tôi hoàn thành:
|
||||
1. Kết nối dự án với Supabase
|
||||
2. Thực hiện chức năng đăng ký, đăng nhập, đăng xuất
|
||||
3. Sau khi đăng nhập thành công chuyển đến /dashboard
|
||||
4. Người dùng chưa đăng nhập truy cập /dashboard, /billing, /admin tự động chuyển đến /login
|
||||
5. Tạo bảng profiles
|
||||
6. Sau khi người dùng đăng ký thành công tự động tạo bản ghi trong bảng profiles
|
||||
7. Bảng profiles bao gồm các trường email, role, plan
|
||||
|
||||
Yêu cầu thực hiện:
|
||||
- Mỗi bước đều nói rõ đang sửa những file nào
|
||||
- Không hardcode key
|
||||
- Nơi cần thao tác thủ công trong trang quản lý Supabase hãy đánh dấu rõ
|
||||
- Sau khi hoàn thành nói rõ cách xác minh đăng ký và đăng nhập
|
||||
```
|
||||
|
||||
### 3.2 Kết nối interface tạo và cơ sở dữ liệu
|
||||
|
||||
```text
|
||||
Xin coi tôi là người mới bắt đầu hoàn toàn, giúp tôi hoàn thành chức năng cốt lõi của trang web: tạo và lưu văn bản marketing.
|
||||
|
||||
Hiệu quả mục tiêu:
|
||||
1. Người dùng điền form tại /dashboard, nhấp "Tạo văn bản"
|
||||
2. Backend nhận: tên sản phẩm, giới thiệu, người dùng mục tiêu, điểm bán hàng, kênh投放
|
||||
3. Backend gọi mô hình tạo kết quả
|
||||
4. Trang hiển thị kết quả tạo
|
||||
5. Đầu vào và đầu ra đều lưu vào cơ sở dữ liệu
|
||||
6. Người dùng lần sau vào có thể xem lịch sử
|
||||
|
||||
Cần bạn hoàn thành:
|
||||
- Tạo interface tạo /api/generate
|
||||
- Tạo bảng generations
|
||||
- Thiết kế trường đầu vào và đầu ra
|
||||
- Trang Dashboard đọc lịch sử của người dùng hiện tại
|
||||
|
||||
Trải nghiệm người dùng:
|
||||
- Trạng thái loading của nút
|
||||
- Thông báo lỗi khi tạo thất bại
|
||||
- Trạng thái trống khi không có lịch sử
|
||||
|
||||
Sau khi hoàn thành xin nói rõ:
|
||||
- Vị trí file trang frontend
|
||||
- Vị trí file interface backend
|
||||
- Vị trí logic ghi dữ liệu vào cơ sở dữ liệu
|
||||
- Cách kiểm tra liên kết tạo hoàn chỉnh
|
||||
```
|
||||
|
||||
### 3.3 Kết nối thanh toán Stripe
|
||||
|
||||
```text
|
||||
Xin coi tôi là người mới bắt đầu hoàn toàn, giúp tôi thêm thanh toán Stripe đơn giản nhất cho LaunchKit.
|
||||
|
||||
Không cần hệ thống phức tạp, trước tiên chạy thông liên kết thanh toán cơ bản nhất.
|
||||
|
||||
Cần bạn hoàn thành:
|
||||
1. Trang /billing hiển thị hai gói free và pro
|
||||
2. Sau khi người dùng nhấp nâng cấp chuyển đến Stripe Checkout
|
||||
3. Sau khi thanh toán thành công quay lại trang web
|
||||
4. Kết quả thanh toán lưu vào bảng subscriptions
|
||||
5. Đồng bộ cập nhật trường profile.plan
|
||||
6. Người dùng free giới hạn 3 lần tạo mỗi ngày, người dùng pro không giới hạn
|
||||
|
||||
Nguyên tắc thực hiện:
|
||||
- Trước tiên chạy thông quy trình chính, tạm không xem xét biên phức tạp
|
||||
- Nơi cần cấu hình trong trang quản lý Stripe hãy viết rõ
|
||||
- Sau khi hoàn thành nói rõ cách kiểm tra quy trình thanh toán hoàn chỉnh
|
||||
```
|
||||
|
||||
### 3.4 Xây dựng trang quản lý backend
|
||||
|
||||
```text
|
||||
Xin coi tôi là người mới bắt đầu hoàn toàn, giúp tôi làm một trang quản lý backend đơn giản và sử dụng được.
|
||||
|
||||
Chỉ dành cho quản trị viên truy cập.
|
||||
|
||||
Cần bạn hoàn thành:
|
||||
1. Chỉ người dùng có role = admin mới có thể truy cập /admin
|
||||
2. Backend bao gồm 3 Tab: danh sách người dùng, bản ghi tạo, trạng thái đăng ký
|
||||
3. Danh sách người dùng hiển thị: email, plan, thời gian tạo
|
||||
4. Bản ghi tạo hiển thị: người dùng, tên sản phẩm, kênh, thời gian tạo
|
||||
5. Trạng thái đăng ký hiển thị: người dùng, gói, trạng thái thanh toán
|
||||
|
||||
Yêu cầu:
|
||||
- Giao diện đơn giản rõ ràng
|
||||
- Sử dụng bảng, Tab, Badge của thư viện component hiện có
|
||||
- Sau khi hoàn thành nói rõ cách đặt tài khoản thành admin
|
||||
```
|
||||
|
||||
### Gặp trở ngại?
|
||||
|
||||
Nếu bạn bị kẹt ở giai đoạn phát triển backend, có thể ôn lại các chương sau:
|
||||
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình lớn hỗ trợ viết mã giao diện và tài liệu giao diện](../../backend/ai-interface-code/)
|
||||
- [Cách tích hợp hệ thống thanh toán Stripe](../../backend/stripe-payment/)
|
||||
|
||||
## Phần 4: Tích hợp và lên mạng
|
||||
|
||||
### 4.1 Kiểm thử end-to-end
|
||||
|
||||
Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Đăng ký -> Đăng nhập -> Tạo văn bản -> Xem lịch sử -> Nâng cấp gói
|
||||
- Quản trị viên đăng nhập -> Xem dữ liệu người dùng -> Xem bản ghi tạo -> Xem trạng thái thanh toán
|
||||
|
||||
Kiểm tra trước khi triển khai:
|
||||
|
||||
```text
|
||||
Xin coi tôi là người mới bắt đầu hoàn toàn, giúp tôi kiểm tra dự án có đủ điều kiện triển khai chưa.
|
||||
|
||||
Trọng tâm kiểm tra:
|
||||
- Biến môi trường đã đầy đủ chưa
|
||||
- Địa chỉ callback đăng nhập đã chính xác chưa
|
||||
- Địa chỉ callback thanh toán Stripe đã chính xác chưa
|
||||
- Trang có thiếu loading, trạng thái trống, thông báo lỗi không
|
||||
- README có bao gồm hướng dẫn khởi động và triển khai không
|
||||
|
||||
Cần bạn:
|
||||
1. Liệt kê các mục cần sửa theo mức độ ưu tiên
|
||||
2. Đánh dấu những cái cần sửa trước
|
||||
3. Nêu rõ các bước triển khai sau khi sửa
|
||||
```
|
||||
|
||||
### 4.2 Triển khai
|
||||
|
||||
Triển khai dự án lên môi trường mạng công cộng. Hướng dẫn triển khai tham khảo: [Học sử dụng Git và Github](../../backend/git-workflow/), [Triển khai ứng dụng web](../../backend/zeabur-deployment/).
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Screenshot các trang cốt lõi (trang chủ, Dashboard, Billing, Admin)
|
||||
- [ ] Video demo 60 giây (bao gồm đăng ký -> tạo -> thanh toán -> backend)
|
||||
|
||||
README ít nhất bao gồm: giới thiệu dự án, mô tả trang cốt lõi, tech stack, bước khởi động cục bộ, danh sách biến môi trường.
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Độ hoàn thiện sản phẩm | Trang chủ, đăng nhập, Dashboard, Billing, Admin đều có thể truy cập | Văn bản và phong cách thị giác trang chủ giống SaaS thực tế |
|
||||
| Vòng lặp nghiệp vụ | Đăng ký -> đăng nhập -> tạo -> xem lịch sử có thể chạy thông | Sự khác biệt quyền Free/Pro rõ ràng có thể nhìn thấy |
|
||||
| Tính chính xác dữ liệu | Kết quả tạo và trạng thái thanh toán đều ghi vào cơ sở dữ liệu | Có thông báo lỗi rõ ràng, trạng thái trống và loading |
|
||||
| Quyền & an ninh | Người dùng chưa đăng nhập không thể truy cập trang được bảo vệ, người dùng thường không vào được Admin | Có xác thực đầu vào cơ bản và xác thực server-side |
|
||||
| Bàn giao kỹ thuật | Dự án có thể khởi động cục bộ, cũng có thể triển khai lên mạng công cộng | README rõ ràng, video demo có cấu trúc hoàn chỉnh |
|
||||
|
||||
::: tip
|
||||
Nếu bạn thấy nhiệm vụ quá lớn, hãy nhớ một nguyên tắc: **Trước đảm bảo "chạy được", rồi mới theo đuổi "làm đẹp".**
|
||||
:::
|
||||
|
||||
## Kiểm tra trước khi nộp
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">Nhìn lại lần cuối trước khi nộp</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> Trang chủ, trang đăng nhập, Dashboard, Billing, Admin đều đã hoàn thành</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Người dùng có thể đăng ký, đăng nhập, đăng xuất</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Kết quả tạo thực sự ghi vào cơ sở dữ liệu</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Quy trình thanh toán chính đã chạy thông</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Quản trị viên có thể xem người dùng, bản ghi tạo và trạng thái thanh toán</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Dự án đã triển khai lên mạng công cộng</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Thiết kế trang và nút bấm theo quy chuẩn UI](../../frontend/multi-product-ui/)
|
||||
- [Làm cho giao diện đẹp hơn bằng LLM và Skills](../../frontend/llm-skills-beautiful/)
|
||||
- [Từ nguyên mẫu thiết kế đến code dự án](../../frontend/design-to-code/)
|
||||
- [Cập nhật giao diện với thư viện component hiện đại](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình lớn hỗ trợ viết mã giao diện và tài liệu giao diện](../../backend/ai-interface-code/)
|
||||
- [Học sử dụng Git và Github](../../backend/git-workflow/)
|
||||
- [Triển khai ứng dụng web](../../backend/zeabur-deployment/)
|
||||
- [Cách tích hợp hệ thống thanh toán Stripe](../../backend/stripe-payment/)
|
||||
@@ -0,0 +1,210 @@
|
||||
# Thực hành phát triển nền tảng Agent thông minh kiểu Dify
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn hoàn thành một nền tảng Agent thông minh mô phỏng trải nghiệm cốt lõi của Dify dựa trên một PRD thực tế, xây dựng từ đầu. Bạn sẽ xây dựng bảng điều khiển người dùng, back-office quản trị và backend nền tảng, triển khai các chức năng cốt lõi như quản lý Agent, hội thoại, nhật ký và cơ sở tri thức.
|
||||
|
||||
Đây là phần thực hành tổng hợp của Stage 2. Khác với các dự án trang đơn hoặc chức năng đơn lẻ trước đó, dự án này yêu cầu bạn xây dựng một sản phẩm AI có "cảm giác nền tảng" — bao gồm đa vai trò, đa module, lưu trữ dữ liệu bền vững và chuỗi gọi mô hình.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm được các nội dung sau:
|
||||
|
||||
- Thiết kế trang frontend và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển API backend ([Viết code API](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Quy trình làm việc Git và triển khai ([Git và GitHub](../../backend/git-workflow/), [Triển khai ứng dụng Web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc và hiểu một PRD thực tế, từ đó trích xuất danh sách công việc phát triển
|
||||
2. Thiết kế kiến trúc trang và mô hình dữ liệu cho nền tảng Agent
|
||||
3. Triển khai chuỗi hoàn chỉnh tạo Agent, hội thoại, ghi nhật ký
|
||||
4. Sử dụng AI hỗ trợ phát triển sản phẩm kiểu nền tảng
|
||||
5. Hoàn thành liên hợp đầu cuối, bàn giao một nguyên mẫu nền tảng AI có thể demo
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một nền tảng Agent thông minh kiểu Dify, bao gồm hai hệ thống con:
|
||||
|
||||
| Hệ thống con | Trách nhiệm |
|
||||
|--------|------|
|
||||
| **Bảng điều khiển người dùng** | Tạo Agent, cấu hình Prompt, khởi động hội thoại, xem nhật ký, quản lý cơ sở tri thức |
|
||||
| **Back-office quản trị** | Xem dữ liệu người dùng, tình hình sử dụng tài nguyên nền tảng, thống kê lượt gọi |
|
||||
|
||||
Backend cần hỗ trợ các khả năng cốt lõi sau: quản lý Agent, quản lý phiên hội thoại, lưu trữ tin nhắn, gọi mô hình, ghi nhật ký lượt gọi, kết nối cơ sở tri thức.
|
||||
|
||||
::: tip Đường dẫn PRD
|
||||
Tài liệu yêu cầu của dự án này nằm trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/custom-dify-agent-platform/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, xác định trang, ranh giới khả năng, xác thực, mô hình dữ liệu' },
|
||||
{ title: 'Xây dựng khung', description: 'Dùng AI tạo khung bảng điều khiển người dùng và back-office quản trị' },
|
||||
{ title: 'Phát triển lặp', description: 'Bổ sung từng module: Agent, hội thoại, nhật ký, cơ sở tri thức' },
|
||||
{ title: 'Liên hợp & triển khai', description: 'Chạy đầu cuối, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Agent, phiên hội thoại, nhật ký, cơ sở tri thức — cái nào cần vào MVP?
|
||||
- Danh sách trang và định tuyến đã chốt chưa?
|
||||
- Ranh giới giữa gọi mô hình và ghi nhật ký là gì?
|
||||
- Đa tenant và workflow phức tạp có nên tạm thời không làm không?
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu sai yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận kiến trúc hệ thống
|
||||
|
||||
Dựa trên PRD, hệ thống hóa kiến trúc tổng thể của hệ thống:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> app["Bảng điều khiển người dùng"]
|
||||
prd --> admin["Back-office quản trị"]
|
||||
app --> auth["Xác thực"]
|
||||
app --> agent["Cấu hình Agent"]
|
||||
app --> chat["Phiên hội thoại"]
|
||||
chat --> llm["Gọi mô hình"]
|
||||
chat --> db["Cơ sở dữ liệu"]
|
||||
app --> kb["Kết nối cơ sở tri thức"]
|
||||
admin --> logs["Nhật ký lượt gọi & tổng quan nền tảng"]
|
||||
logs --> db
|
||||
```
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo trang frontend
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng dựa trên PRD hiện tại, giúp tôi tạo khung frontend của nền tảng Agent thông minh kiểu Dify.
|
||||
|
||||
Yêu cầu:
|
||||
1. Phía người dùng bao gồm: đăng nhập, danh sách Agent, cấu hình Agent, trang hội thoại, trang nhật ký, trang cơ sở tri thức
|
||||
2. Phía back-office bao gồm: trang chủ back-office, tổng quan người dùng, tổng quan sử dụng tài nguyên
|
||||
3. Trước tiên chỉ tạo cấu trúc trang và dữ liệu giả, không kết nối API thực tế
|
||||
4. Phong cách phải giống nền tảng AI hiện đại
|
||||
```
|
||||
|
||||
### 2.2 Xác minh cấu trúc trang
|
||||
|
||||
Kiểm tra từng mục:
|
||||
|
||||
- [ ] Điểm vào bảng điều khiển người dùng và back-office quản trị đã tách biệt
|
||||
- [ ] Trang danh sách Agent, cấu hình, hội thoại, nhật ký, cơ sở tri thức đã hoàn chỉnh
|
||||
- [ ] Trang chủ back-office, trang tổng quan người dùng có thể truy cập
|
||||
- [ ] Dữ liệu giả hiển thị trạng thái UI cơ bản
|
||||
|
||||
## Phần 3: Phát triển lặp
|
||||
|
||||
### 3.1 Triển khai theo module
|
||||
|
||||
Trên cơ sở khung, bổ sung chức năng theo thứ tự module sau:
|
||||
|
||||
1. **Xác thực**: Đăng ký, đăng nhập, phân biệt vai trò
|
||||
2. **Quản lý Agent**: Tạo, chỉnh sửa, xóa, cấu hình Prompt
|
||||
3. **Chức năng hội thoại**: Tạo phiên hội thoại, gửi/nhận tin nhắn, gọi mô hình
|
||||
4. **Ghi nhật ký**: Thời gian xử lý, token sử dụng, ghi lỗi
|
||||
5. **Kết nối cơ sở tri thức** (mục điểm cộng): Tải lên tài liệu, tìm kiếm, chèn kết quả
|
||||
6. **Back-office quản trị**: Dữ liệu người dùng, sử dụng tài nguyên, thống kê lượt gọi
|
||||
|
||||
Sau khi hoàn thành mỗi module, sử dụng bảng dưới đây để tự kiểm tra:
|
||||
|
||||
| Mục kiểm tra | Phương pháp xác minh |
|
||||
|--------|----------|
|
||||
| Tính nhất quán trang | Số lượng trang, chức năng có khớp với PRD không |
|
||||
| Chuỗi API | API agents, chat, logs, knowledge có hoàn chỉnh không |
|
||||
| Cách ly phân quyền | Người dùng có chỉ quản lý được agent và phiên hội thoại của mình không |
|
||||
| Tính nhất quán dữ liệu | Dữ liệu messages, logs, documents có khớp nhau không |
|
||||
| Khả năng demo | Có thể demo chuỗi hoàn chỉnh "tạo agent → hội thoại → xem nhật ký" không |
|
||||
|
||||
### 3.2 Kết nối cơ sở tri thức (mục điểm cộng)
|
||||
|
||||
Nếu bạn muốn tăng khả năng cơ sở tri thức, có thể thêm "công tắc cơ sở tri thức" cho mỗi Agent:
|
||||
|
||||
- Khi bật, trước tiên tìm kiếm đoạn tài liệu, sau đó gửi cùng câu hỏi của người dùng cho mô hình
|
||||
- Khi tắt, phản hồi theo chế độ hội thoại thông thường
|
||||
|
||||
Phiên bản đầu tiên không cần theo đuổi RAG phức tạp, chỉ cần "kết quả tìm kiếm có thể thấy, chuỗi gọi có thể giải thích".
|
||||
|
||||
## Phần 4: Liên hợp và Triển khai
|
||||
|
||||
### 4.1 Kiểm thử đầu cuối
|
||||
|
||||
Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Đăng ký → Tạo Agent → Cấu hình Prompt → Khởi động hội thoại → Xem nhật ký
|
||||
- Quản trị viên đăng nhập → Xem dữ liệu người dùng → Xem thống kê lượt gọi
|
||||
|
||||
Kiểm tra trước khi triển khai:
|
||||
|
||||
- [ ] Tất cả API cốt lõi đều đã kiểm tra đăng nhập
|
||||
- [ ] Kiểm tra quyền sở hữu Agent thông qua
|
||||
- [ ] Bản ghi phiên hội thoại, bản ghi nhật ký thực sự lưu vào cơ sở dữ liệu
|
||||
- [ ] Key mô hình sử dụng biến môi trường, không hard-code
|
||||
- [ ] Thông báo lỗi có thể thấy trên frontend, không chỉ in ra console
|
||||
|
||||
### 4.2 Triển khai
|
||||
|
||||
Triển khai dự án lên môi trường mạng công cộng. Tham khảo hướng dẫn triển khai: [Quy trình làm việc Git và GitHub](../../backend/git-workflow/), [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/).
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Ảnh chụp màn hình các trang cốt lõi (trang quản lý Agent, trang hội thoại, trang nhật ký, trang chủ back-office)
|
||||
- [ ] Video demo 60 giây (bao gồm tạo Agent → hội thoại → xem nhật ký)
|
||||
|
||||
README tối thiểu bao gồm: giới thiệu dự án, mô tả kiến trúc, công nghệ sử dụng, bước khởi động cục bộ, danh sách biến môi trường, mô tả API.
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Độ hoàn thiện nền tảng | Ba trang agents / chat / logs có thể sử dụng | Có điều hướng rõ ràng và ngôn ngữ thiết kế thống nhất |
|
||||
| Chuỗi nghiệp vụ | Có thể tạo Agent và hội thoại thực sự | Hỗ trợ chuyển đổi đa Agent và phiên hội thoại lịch sử |
|
||||
| Dữ liệu & theo dõi | Tin nhắn và nhật ký lượt gọi có thể truy vấn | Có bảng thống kê token / thời gian xử lý |
|
||||
| Phân quyền bảo mật | Chỉ người dùng đã đăng nhập mới có thể truy cập API cốt lõi | Kiểm tra quyền sở hữu tài nguyên hoàn thiện |
|
||||
| Bàn giao kỹ thuật | Có thể triển khai, có thể demo, README rõ ràng | Kết nối cơ sở tri thức và có thể giải thích kết quả tìm kiếm |
|
||||
|
||||
## Kiểm tra trước khi nộp
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">Nhìn lại lần cuối trước khi nộp</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> Sau khi đăng nhập có thể truy cập trang quản lý Agent, hội thoại, nhật ký</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Ít nhất có thể tạo 1 Agent và hội thoại thành công</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Mỗi vòng hỏi đáp đều có thể tìm thấy bản ghi trong cơ sở dữ liệu</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Khi gọi thất bại, thông tin lỗi có thể thấy trên frontend và nhật ký đã ghi</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Dự án đã được triển khai, README và video demo đầy đủ</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình hỗ trợ viết code API và tài liệu API bằng mô hình lớn](../../backend/ai-interface-code/)
|
||||
- [Quy trình làm việc Git và GitHub](../../backend/git-workflow/)
|
||||
- [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,306 @@
|
||||
# Thực hành phát triển hệ thống quản lý và thi trực tuyến
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn hoàn thành một hệ thống thi và quản lý trực tuyến dựa trên một PRD thực tế, xây dựng từ đầu. Điểm đặc biệt của dự án này là nó chứa nhiều vai trò (học sinh và quản trị viên), mỗi vai trò nhìn thấy các trang khác nhau và có thể thực hiện các thao tác khác nhau. Bạn sẽ sử dụng Express để xây dựng backend, triển khai toàn bộ chuỗi nghiệp vụ thi.
|
||||
|
||||
Đây là phần thực hành tổng hợp của Stage 2. Hệ thống phân quyền đa vai trò rất phổ biến trong thực tế công việc, sau khi nắm vững mô hình này, bạn có thể ứng phó với các kịch bản nghiệp vụ như giáo dục, SaaS, quản lý back-office, v.v.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm được các nội dung sau:
|
||||
|
||||
- Thiết kế trang前端 và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển API backend ([Viết code API](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Quy trình làm việc Git và triển khai ([Git và GitHub](../../backend/git-workflow/), [Triển khai ứng dụng Web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc và hiểu một PRD thực tế, từ đó trích xuất danh sách công việc phát triển
|
||||
2. Thiết kế kiểm soát phân quyền và định tuyến trang cho hệ thống đa vai trò
|
||||
3. Sử dụng Express để triển khai API backend hoàn chỉnh
|
||||
4. Triển khai chuỗi nghiệp vụ thi, nộp bài, tự động chấm điểm
|
||||
5. Hoàn thành liên hợp đầu cuối, bàn giao một nguyên mẫu hệ thống nghiệp vụ có thể demo
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một hệ thống thi và quản lý trực tuyến, bao gồm ba hệ thống con:
|
||||
|
||||
| Hệ thống con | Trách nhiệm |
|
||||
|--------|------|
|
||||
| **Trang chủ** | Giới thiệu nền tảng, điểm đăng nhập |
|
||||
| **Trang học sinh** | Danh sách bài thi, làm bài, nộp bài, xem điểm |
|
||||
| **Back-office quản trị** | Quản lý ngân hàng đề, quản lý bài thi, hồ sơ nộp bài, thống kê điểm |
|
||||
|
||||
Backend sử dụng Express, cần hỗ trợ: xác thực đăng nhập, phân quyền vai trò, quản lý bài thi và ngân hàng đề, quy trình nộp bài và tự động chấm điểm, quản lý điểm và thống kê.
|
||||
|
||||
::: tip Đường dẫn PRD
|
||||
Tài liệu yêu cầu của dự án này nằm trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/exam-management-express/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, xác định vai trò, trang, chuỗi bài thi và mô hình dữ liệu' },
|
||||
{ title: 'Xây dựng khung', description: 'Dùng AI tạo khung trang học sinh và trang quản trị' },
|
||||
{ title: 'Phát triển backend', description: 'Express kết nối đăng nhập, bài thi, nộp bài, chấm điểm' },
|
||||
{ title: 'Liên hợp & triển khai', description: 'Chạy đầu cuối, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Hệ thống bao gồm những vai trò nào? Mỗi vai trò có thể làm gì?
|
||||
- Danh sách trang đã hoàn chỉnh chưa? Trang học sinh và trang quản trị lần lượt có những trang nào?
|
||||
- Hỗ trợ những loại câu hỏi nào? Logic chấm điểm cho từng loại là gì?
|
||||
- Quy trình hoàn chỉnh của bài thi là gì? (Phát hành → Bắt đầu → Trả lời → Nộp → Chấm điểm → Xem điểm)
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu sai yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận kiến trúc hệ thống
|
||||
|
||||
Dựa trên PRD, hệ thống hóa kiến trúc tổng thể của hệ thống:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["Trang chủ"]
|
||||
prd --> student["Trang học sinh"]
|
||||
prd --> admin["Back-office quản trị"]
|
||||
student --> auth["Xác thực"]
|
||||
student --> exam["Bài thi & trả lời"]
|
||||
exam --> db["Cơ sở dữ liệu"]
|
||||
admin --> question["Quản lý ngân hàng đề"]
|
||||
admin --> submission["Hồ sơ nộp bài & thống kê điểm"]
|
||||
question --> db
|
||||
submission --> db
|
||||
```
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo trang frontend
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng dựa trên PRD hiện tại, giúp tôi tạo khung frontend của hệ thống thi và quản lý trực tuyến.
|
||||
|
||||
Yêu cầu công nghệ:
|
||||
- Next.js App Router
|
||||
- TypeScript
|
||||
- Tailwind CSS
|
||||
- shadcn/ui
|
||||
|
||||
Danh sách trang:
|
||||
1. Trang chủ /
|
||||
2. Trang đăng nhập /login
|
||||
3. Trang danh sách bài thi học sinh /student/exams
|
||||
4. Trang làm bài thi học sinh /student/exams/[id]
|
||||
5. Trang điểm học sinh /student/history
|
||||
6. Trang chủ back-office quản trị /admin
|
||||
7. Trang quản lý bài thi /admin/exams
|
||||
8. Trang quản lý ngân hàng đề /admin/questions
|
||||
9. Trang hồ sơ nộp bài /admin/submissions
|
||||
|
||||
Yêu cầu:
|
||||
- Trang học sinh nhấn mạnh sự rõ ràng, tập trung, dễ làm bài
|
||||
- Trang quản trị sử dụng bố cục thanh bên + thanh trên
|
||||
- Trước tiên sử dụng mock data, không kết nối API thực tế
|
||||
- Chú ý khả năng sử dụng cơ bản trên máy tính để bàn và thiết bị di động
|
||||
```
|
||||
|
||||
### 2.2 Hoàn thiện trang làm bài thi học sinh
|
||||
|
||||
Trang làm bài là trang cốt lõi của học sinh, tập trung hoàn thiện:
|
||||
|
||||
```text
|
||||
Vui lòng tiếp tục hoàn thiện trang làm bài thi học sinh.
|
||||
|
||||
Đây là trang làm bài của hệ thống thi trực tuyến, cần bao gồm:
|
||||
- Phần trên hiển thị tiêu đề bài thi, đếm ngược, số câu đã trả lời
|
||||
- Phần giữa hiển thị nội dung câu hỏi và các lựa chọn
|
||||
- Hỗ trợ ba loại câu hỏi: trắc nghiệm, đúng/sai, tự luận
|
||||
- Bên trái hoặc trên có bảng trả lời, hiển thị từng câu đã trả lời hay chưa
|
||||
- Hiện xác nhận trước khi nhấn nộp bài
|
||||
|
||||
Trước tiên sử dụng mock data để triển khai tương tác, không kết nối API thực tế.
|
||||
|
||||
Yêu cầu:
|
||||
- Giao diện đơn giản, không giống trang bảng back-office
|
||||
- Đếm ngược cần nổi bật nhưng không tạo áp lực quá mạnh
|
||||
- Có trạng thái trống và trạng thái loading
|
||||
```
|
||||
|
||||
### 2.3 Hoàn thiện back-office quản trị
|
||||
|
||||
Phiên bản đầu tiên của back-office quản trị tập trung vào ba khu vực cốt lõi:
|
||||
|
||||
- **Quản lý bài thi**: Tạo bài thi, thiết lập thời gian, trạng thái phát hành
|
||||
- **Quản lý ngân hàng đề**: Thêm câu hỏi mới, chỉnh sửa câu hỏi, lọc theo loại câu hỏi
|
||||
- **Hồ sơ nộp bài**: Xem bài nộp của học sinh, điểm số, thời gian
|
||||
|
||||
### 2.4 Xác minh cấu trúc trang
|
||||
|
||||
Kiểm tra từng mục:
|
||||
|
||||
- [ ] Điểm vào trang học sinh và trang quản trị đã tách biệt
|
||||
- [ ] Trang đăng nhập, danh sách bài thi, trang làm bài, trang điểm đã hoàn chỉnh
|
||||
- [ ] Trang quản lý ngân hàng đề, quản lý bài thi, hồ sơ nộp bài đã có thể truy cập
|
||||
- [ ] Phong cách trang học sinh và trang quản trị có sự khác biệt rõ ràng
|
||||
|
||||
### Gặp khó khăn?
|
||||
|
||||
Nếu bạn gặp khó khăn trong giai đoạn xây dựng frontend, bạn có thể xem lại các chương sau:
|
||||
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Thiết kế và phát triển API backend ứng dụng](../../backend/ai-interface-code/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
|
||||
## Phần 3: Phát triển Backend
|
||||
|
||||
### 3.1 Đăng nhập và kiểm soát phân quyền
|
||||
|
||||
```text
|
||||
Vui lòng coi tôi là người mới bắt đầu, giúp tôi hoàn thành đăng nhập và kiểm soát phân quyền của hệ thống thi trực tuyến.
|
||||
|
||||
Backend sử dụng Express.
|
||||
|
||||
Mục tiêu:
|
||||
1. Cả học sinh và quản trị viên đều có thể đăng nhập
|
||||
2. Sau khi đăng nhập trả về vai trò người dùng
|
||||
3. Học sinh chỉ có thể truy cập các API liên quan đến /student/*
|
||||
4. Quản trị viên chỉ có thể truy cập các API liên quan đến /admin/*
|
||||
5. Người dùng chưa đăng nhập khi truy cập trang được bảo vệ sẽ chuyển hướng đến /login
|
||||
|
||||
Yêu cầu triển khai:
|
||||
- Đưa ra gợi ý cấu trúc thư mục rõ ràng
|
||||
- Giải thích rõ middleware chịu trách nhiệm cho việc gì
|
||||
- Không hard-code các biến môi trường liên quan
|
||||
- Sau khi hoàn thành, giải thích cách xác minh phân quyền có hiệu lực hay không
|
||||
```
|
||||
|
||||
### 3.2 API quản lý bài thi và ngân hàng đề
|
||||
|
||||
Khuyến nghị triển khai theo các module sau:
|
||||
|
||||
| Module | API khuyến nghị |
|
||||
|------|----------|
|
||||
| Quản lý bài thi | `GET /api/exams`, `POST /api/admin/exams`, `PATCH /api/admin/exams/:id` |
|
||||
| Quản lý ngân hàng đề | `GET /api/admin/questions`, `POST /api/admin/questions` |
|
||||
| Bắt đầu bài thi | `POST /api/submissions/start` |
|
||||
| Nộp bài thi | `POST /api/submissions/:id/submit` |
|
||||
| Hồ sơ điểm | `GET /api/student/history`, `GET /api/admin/submissions` |
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi thiết kế và triển khai Express API cho hệ thống thi trực tuyến.
|
||||
|
||||
Phạm vi chức năng:
|
||||
- Quản trị viên tạo bài thi
|
||||
- Quản trị viên duy trì ngân hàng đề
|
||||
- Học sinh xem bài thi đã phát hành
|
||||
- Học sinh bắt đầu bài thi và tạo submission
|
||||
- Học sinh nộp câu trả lời và tự động chấm câu trắc nghiệm và đúng/sai
|
||||
- Câu tự luận trước tiên đánh dấu là chờ phê duyệt
|
||||
- Học sinh xem điểm lịch sử của mình
|
||||
- Quản trị viên xem tất cả hồ sơ nộp bài
|
||||
|
||||
Yêu cầu:
|
||||
- Tên API rõ ràng
|
||||
- Trả về cấu trúc JSON thống nhất
|
||||
- Code phân biệt các lớp controller, service, middleware, db
|
||||
- Giải thích cách kiểm tra từng API
|
||||
```
|
||||
|
||||
### 3.3 Logic chấm điểm
|
||||
|
||||
Logic chấm điểm là quy tắc nghiệp vụ cốt lõi của hệ thống thi:
|
||||
|
||||
- **Câu trắc nghiệm**: Câu trả lời của người dùng khớp với đáp án thì được điểm
|
||||
- **Câu đúng/sai**: Cũng có thể tự động chấm
|
||||
- **Câu tự luận**: Phiên bản đầu tiên chỉ lưu câu trả lời, điểm để trống, trạng thái `reviewed = false`
|
||||
|
||||
::: tip Mục điểm cộng
|
||||
Nếu bạn muốn tăng khả năng AI, quản trị viên có thể nhập "chủ đề + độ khó" trong back-office, model sẽ tạo một loạt câu hỏi ứng viên, sau đó người sẽ phê duyệt và đưa vào ngân hàng đề. Nhưng đây là mục điểm cộng, không bắt buộc.
|
||||
:::
|
||||
|
||||
## Phần 4: Liên hợp và Triển khai
|
||||
|
||||
### 4.1 Kiểm thử đầu cuối
|
||||
|
||||
Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Học sinh đăng nhập → Xem danh sách bài thi → Bắt đầu làm bài → Nộp bài → Xem điểm
|
||||
- Quản trị viên đăng nhập → Tạo bài thi → Thêm câu hỏi → Phát hành → Xem hồ sơ nộp bài
|
||||
|
||||
### 4.2 Triển khai
|
||||
|
||||
- Frontend triển khai lên Vercel / Zeabur
|
||||
- Express API triển khai lên Zeabur / Railway / Render
|
||||
- Cơ sở dữ liệu sử dụng Supabase Postgres hoặc PostgreSQL được quản lý
|
||||
|
||||
Kiểm tra trước khi triển khai:
|
||||
|
||||
- [ ] Biến môi trường đã đầy đủ chưa
|
||||
- [ ] Địa chỉ API frontend và backend đã chính xác chưa
|
||||
- [ ] Trạng thái đăng nhập có hoạt động bình thường trong môi trường production không
|
||||
- [ ] Tài khoản quản trị viên có thể thực sự truy cập back-office không
|
||||
- [ ] README có bao gồm hướng dẫn khởi động, triển khai, kiểm thử không
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Ảnh chụp màn hình các trang cốt lõi (trang chủ, danh sách bài thi học sinh, trang làm bài, back-office quản trị)
|
||||
- [ ] Video demo 60 giây (bao gồm quy trình học sinh làm bài và quy trình quản trị viên quản lý)
|
||||
|
||||
README tối thiểu bao gồm: giới thiệu dự án, mô tả trang cốt lõi, công nghệ sử dụng, bước khởi động cục bộ, danh sách biến môi trường.
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Độ hoàn thiện trang | Các trang chính của học sinh và quản trị viên đều có thể truy cập | Phong cách trang thống nhất, thiết bị di động cơ bản có thể sử dụng |
|
||||
| Chuỗi nghiệp vụ | Học sinh có thể đăng nhập, tham gia thi, nộp bài và xem điểm | Quản trị viên có thể tạo và phát hành bài thi hoàn chỉnh |
|
||||
| Tính chính xác dữ liệu | Sau khi nộp câu trả lời có thể ghi vào cơ sở dữ liệu, câu khách quan có thể tự động chấm điểm | Câu tự luận hỗ trợ phê duyệt thủ công hoặc hỗ trợ AI |
|
||||
| Kiểm soát phân quyền | Ranh giới truy cập giữa học sinh và quản trị viên rõ ràng | API backend cũng có kiểm tra vai trò |
|
||||
| Bàn giao kỹ thuật | Dự án có thể chạy, có thể triển khai, README rõ ràng | Có video demo và hướng dẫn kiểm thử |
|
||||
|
||||
## Kiểm tra trước khi nộp
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">Nhìn lại lần cuối trước khi nộp</div>
|
||||
</template>
|
||||
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> Trang chủ, trang đăng nhập, trang học sinh, trang quản trị đều đã hoàn thành</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Học sinh có thể bắt đầu bài thi và nộp câu trả lời bình thường</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Quản trị viên có thể tạo bài thi và xem hồ sơ nộp bài</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Điểm câu khách quan có thể tự động tính toán và ghi vào cơ sở dữ liệu</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Ranh giới phân quyền giữa học sinh và quản trị viên đã được xác minh</label></li>
|
||||
<li><label><input type="checkbox" disabled /> Dự án đã được triển khai hoặc có hướng dẫn chạy cục bộ hoàn chỉnh</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình hỗ trợ viết code API và tài liệu API bằng mô hình lớn](../../backend/ai-interface-code/)
|
||||
- [Quy trình làm việc Git và GitHub](../../backend/git-workflow/)
|
||||
- [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,211 @@
|
||||
# Thực hành phát triển SaaS tạo ảnh AI hiện đại
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn hoàn thành một sản phẩm SaaS tạo ảnh AI tham khảo trải nghiệm Midjourney dựa trên một PRD (tài liệu yêu cầu sản phẩm) thực tế, xây dựng từ đầu. Bạn sẽ trải nghiệm toàn bộ quá trình phân tích yêu cầu, phân tách dự án, phát triển lặp, liên hợp và triển khai.
|
||||
|
||||
Đây là phần thực hành tổng hợp của Stage 2. Trong các chương trước, bạn đã học riêng biệt các kỹ năng thiết kế trang frontend, phát triển API backend, thao tác cơ sở dữ liệu, tích hợp thanh toán, v.v. — dự án này yêu cầu bạn kết hợp tất cả lại với nhau, bàn giao một nguyên mẫu sản phẩm có thể chạy được.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm được các nội dung sau:
|
||||
|
||||
- Thiết kế trang frontend và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển API backend ([Viết code API](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Tích hợp thanh toán ([Hệ thống thanh toán Stripe](../../backend/stripe-payment/))
|
||||
- Quy trình làm việc Git và triển khai ([Git và GitHub](../../backend/git-workflow/), [Triển khai ứng dụng Web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc và hiểu một PRD thực tế, từ đó trích xuất danh sách công việc phát triển
|
||||
2. Phân tách module dựa trên PRD, lập kế hoạch triển khai từng bước
|
||||
3. Sử dụng AI hỗ trợ hoàn thành xây dựng khung frontend và phát triển API backend
|
||||
4. Xác minh và tối ưu hóa lặp từng module
|
||||
5. Hoàn thành liên hợp đầu cuối, đưa dự án từ "chạy được" đến "có thể bàn giao"
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một nền tảng SaaS tạo ảnh AI hiện đại, bao gồm ba hệ thống con:
|
||||
|
||||
| Hệ thống con | Trách nhiệm |
|
||||
|--------|------|
|
||||
| **Trang chủ** | Giới thiệu sản phẩm, bảng giá, FAQ, chuyển đổi đăng ký |
|
||||
| **Bàn làm việc người dùng** | Nhập Prompt, tạo ảnh, thư viện ảnh, tín dụng, gói dịch vụ, tương tác cộng đồng |
|
||||
| **Back-office quản trị** | Quản lý người dùng, quản lý tác vụ, quản lý thanh toán, kiểm duyệt nội dung, chỉ số SaaS, giám sát hệ thống |
|
||||
|
||||
Backend cần hỗ trợ các khả năng cốt lõi sau: xác thực người dùng, tác vụ tạo ảnh, lưu trữ đối tượng OSS, tín dụng và thanh toán gói dịch vụ, tương tác xã hội ảnh, giám sát dữ liệu vận hành.
|
||||
|
||||
::: tip Đường dẫn PRD
|
||||
Tài liệu yêu cầu của dự án này nằm trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/modern-landing-page/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, trích xuất trang, module, mô hình dữ liệu và ranh giới' },
|
||||
{ title: 'Xây dựng khung', description: 'Dùng AI tạo ba bộ khung frontend (www / app / admin)' },
|
||||
{ title: 'Phát triển lặp', description: 'Bổ sung từng module: API, phân quyền, thanh toán, giám sát' },
|
||||
{ title: 'Liên hợp & triển khai', description: 'Chạy đầu cuối, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Hệ thống có mấy điểm vào? Mỗi điểm bao phủ những trang nào?
|
||||
- Chức năng cốt lõi của mỗi trang là gì?
|
||||
- Backend bao gồm những module và bảng cơ sở dữ liệu nào?
|
||||
- Phạm vi MVP là gì? Phiên bản đầu tiên làm gì, không làm gì?
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu sai yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận kiến trúc hệ thống
|
||||
|
||||
Dựa trên mô tả trong PRD, hệ thống hóa kiến trúc tổng thể của hệ thống:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["Trang chủ"]
|
||||
prd --> app["Bàn làm việc người dùng"]
|
||||
prd --> admin["Back-office quản trị"]
|
||||
app --> auth["Xác thực"]
|
||||
app --> gen["Tác vụ tạo ảnh"]
|
||||
gen --> oss["Lưu trữ đối tượng OSS"]
|
||||
gen --> db["Cơ sở dữ liệu"]
|
||||
billing["Thanh toán & gói dịch vụ"] --> db
|
||||
social["Chia sẻ / Thích / Bình luận / Chuyển tiếp"] --> db
|
||||
admin --> analytics["Bảng chỉ số SaaS"]
|
||||
admin --> observability["Giám sát API / DB / Provider"]
|
||||
```
|
||||
|
||||
Khuyến nghị bạn vẽ lại sơ đồ kiến trúc bằng lời của mình, xác nhận rằng sự hiểu biết của bạn về hệ thống là hoàn chỉnh.
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo trang frontend
|
||||
|
||||
Sử dụng AI để tạo cấu trúc cơ bản và dữ liệu giả cho tất cả các trang. Mục tiêu của bước này là tạo ra kiến trúc thông tin và định tuyến, không cần kết nối API thực tế.
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng dựa trên PRD hiện tại, giúp tôi tạo khung frontend của SaaS tạo ảnh AI hiện đại.
|
||||
|
||||
Yêu cầu:
|
||||
1. Chia thành ba điểm vào: www, app, admin
|
||||
2. Trang chủ bao gồm: trang chủ, bảng giá, FAQ
|
||||
3. app bao gồm: đăng nhập, đăng ký, bàn làm việc tạo ảnh, thư viện ảnh, gói dịch vụ, tín dụng, cộng đồng, chi tiết tác phẩm, trang cá nhân
|
||||
4. admin bao gồm: trang chủ back-office, quản lý người dùng, quản lý tác vụ, quản lý nội dung, quản lý gói dịch vụ, đơn thanh toán, cấu hình vận hành, chỉ số SaaS, giám sát hệ thống
|
||||
5. Trước tiên chỉ tạo cấu trúc trang và dữ liệu giả, không kết nối API thực tế
|
||||
6. Phong cách tham khảo Midjourney, đơn giản, hiện đại, có cảm giác sản phẩm
|
||||
```
|
||||
|
||||
### 2.2 Xác minh cấu trúc trang
|
||||
|
||||
Sau khi tạo khung, kiểm tra từng mục:
|
||||
|
||||
- [ ] Định tuyến của ba điểm vào có độc lập không (`/`, `/app`, `/admin`)
|
||||
- [ ] Số lượng trang có khớp với PRD không
|
||||
- [ ] Mỗi trang có thể truy cập và điều hướng bình thường không
|
||||
- [ ] Dữ liệu giả có hiển thị trạng thái UI cơ bản không (danh sách, trạng thái trống, biểu mẫu, v.v.)
|
||||
|
||||
## Phần 3: Phát triển lặp
|
||||
|
||||
### 3.1 Triển khai theo module
|
||||
|
||||
Trên cơ sở khung, bổ sung chức năng theo thứ tự module sau:
|
||||
|
||||
1. **Xác thực**: Đăng ký, đăng nhập, phân biệt vai trò
|
||||
2. **Cơ sở dữ liệu**: Tạo bảng dữ liệu, API đọc/ghi
|
||||
3. **Nghiệp vụ cốt lõi**: Tác vụ tạo ảnh, lưu trữ kết quả
|
||||
4. **Lưu trữ OSS**: Tải lên và truy cập ảnh
|
||||
5. **Thanh toán**: Gói dịch vụ, tín dụng, tích hợp Stripe
|
||||
6. **Tương tác xã hội**: Chia sẻ, thích, bình luận
|
||||
7. **Quản lý back-office**: Quản lý người dùng, quản lý tác vụ, kiểm duyệt nội dung
|
||||
8. **Giám sát dữ liệu**: Bảng chỉ số SaaS, giám sát hệ thống
|
||||
|
||||
Sau khi hoàn thành mỗi module, sử dụng bảng dưới đây để tự kiểm tra:
|
||||
|
||||
| Mục kiểm tra | Phương pháp xác minh |
|
||||
|--------|----------|
|
||||
| Tính nhất quán trang | Số lượng trang, điểm vào, chức năng có khớp với PRD không |
|
||||
| Tính chính xác API | Tham số yêu cầu, cấu trúc trả về, xử lý trạng thái có hợp lý không |
|
||||
| Cách ly phân quyền | Người dùng thông thường và quản trị viên có cách ly nhau không |
|
||||
| Tính nhất quán dữ liệu | Cơ sở dữ liệu, OSS, thanh toán, tín dụng có khớp nhau không |
|
||||
| Khả năng demo | Có thể demo hoàn chỉnh một chuỗi nghiệp vụ cho người khác không |
|
||||
|
||||
::: tip
|
||||
Nếu phát hiện nội dung do AI tạo ra sai lệch so với PRD, đừng lật đổ toàn bộ trang, hãy để AI sửa trực tiếp module cụ thể.
|
||||
:::
|
||||
|
||||
### 3.2 Vai trò và phân công
|
||||
|
||||
Trong quá trình lặp, bạn cần đóng đồng thời ba vai trò:
|
||||
|
||||
- **Quản lý sản phẩm**: Xác nhận chức năng của mỗi module có khớp với PRD không
|
||||
- **Trưởng nhóm kỹ thuật**: Xác nhận phương án triển khai có hợp lý không
|
||||
- **Kỹ sư kiểm thử**: Xác nhận chức năng có chạy được không
|
||||
|
||||
## Phần 4: Liên hợp và Triển khai
|
||||
|
||||
### 4.1 Kiểm thử đầu cuối
|
||||
|
||||
Trọng tâm của giai đoạn cuối không phải là bổ sung trang mới, mà là chạy qua toàn bộ chuỗi nghiệp vụ. Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Đăng ký → Mua tín dụng → Tạo ảnh → Xem lịch sử → Chia sẻ tương tác
|
||||
- Quản trị viên đăng nhập → Xem dữ liệu người dùng → Xem thống kê tác vụ → Xem giám sát hệ thống
|
||||
|
||||
### 4.2 Triển khai
|
||||
|
||||
Triển khai dự án lên môi trường mạng công cộng, đảm bảo:
|
||||
|
||||
- Cấu hình biến môi trường hoàn chỉnh
|
||||
- Địa chỉ callback đăng nhập chính xác
|
||||
- Địa chỉ callback thanh toán chính xác
|
||||
- Trang không thiếu trạng thái loading, trạng thái trống, thông báo lỗi
|
||||
|
||||
Tham khảo hướng dẫn triển khai: [Quy trình làm việc Git và GitHub](../../backend/git-workflow/), [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/).
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Ảnh chụp màn hình các trang cốt lõi (trang chủ website, bàn làm việc tạo ảnh, thư viện ảnh, trang gói dịch vụ, trang chủ back-office)
|
||||
- [ ] Video demo 60 giây (bao gồm đăng ký → tạo ảnh → xem → quản lý back-office)
|
||||
|
||||
README tối thiểu bao gồm: giới thiệu dự án, mô tả trang cốt lõi, công nghệ sử dụng, bước khởi động cục bộ, danh sách biến môi trường.
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Căn chỉnh PRD | Trang, chức năng, cấu trúc dữ liệu cơ bản khớp với PRD | Có thể giải thích rõ ràng mỗi quyết định thiết kế tương ứng với PRD như thế nào |
|
||||
| Chuỗi sản phẩm | Đăng ký → Mua tín dụng → Tạo ảnh → Xem lịch sử → Chia sẻ tương tác có thể chạy qua | Trạng thái thanh toán, số dư tín dụng, số lần tạo ảnh nhất quán về dữ liệu |
|
||||
| Khả năng back-office | Người dùng, tác vụ, thanh toán, quản lý nội dung có thể xem | Bảng chỉ số SaaS và trang giám sát hệ thống hoàn chỉnh có thể sử dụng |
|
||||
| Độ hoàn thiện kỹ thuật | Frontend, backend, cơ sở dữ liệu, OSS, chuỗi thanh toán đã kết nối | Có xử lý lỗi, trạng thái trống, trạng thái loading |
|
||||
| Chất lượng bàn giao | Có thể triển khai, có thể chạy | README rõ ràng, cấu trúc video demo hoàn chỉnh |
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Tham khảo quy phạm thiết kế UI để thiết kế trang và nút](../../frontend/multi-product-ui/)
|
||||
- [Dùng LLM và Skills làm cho giao diện đẹp hơn](../../frontend/llm-skills-beautiful/)
|
||||
- [Từ nguyên mẫu thiết kế đến code dự án](../../frontend/design-to-code/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình hỗ trợ viết code API và tài liệu API bằng mô hình lớn](../../backend/ai-interface-code/)
|
||||
- [Quy trình làm việc Git và GitHub](../../backend/git-workflow/)
|
||||
- [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/)
|
||||
- [Cách tích hợp hệ thống thanh toán như Stripe](../../backend/stripe-payment/)
|
||||
@@ -0,0 +1,162 @@
|
||||
# Thực hành phát triển hệ thống đề xuất phim bằng Spring Boot
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn hoàn thành một trang web phim có khả năng đề xuất dựa trên một PRD thực tế, sử dụng Spring Boot. Thách thức cốt lõi của dự án này là: nó không phải là thao tác CRUD đơn giản, mà cần bạn suy nghĩ "hành vi người dùng ảnh hưởng đến kết quả đề xuất như thế nào" và "đề xuất có thể giải thích như thế nào".
|
||||
|
||||
Đây là phần thực hành tổng hợp của Stage 2. Bạn sẽ lần đầu tiên tiếp xúc với mô hình phát triển sản phẩm kiểu "nội dung + hành vi + đề xuất", mô hình này rất phổ biến trong các kịch bản thương mại điện tử, nền tảng nội dung, Feed cá nhân hóa, v.v.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm được các nội dung sau:
|
||||
|
||||
- Thiết kế trang frontend và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển API backend ([Viết code API](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Quy trình làm việc Git và triển khai ([Git và GitHub](../../backend/git-workflow/), [Triển khai ứng dụng Web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc PRD và từ đó trích xuất danh sách công việc phát triển hệ thống đề xuất
|
||||
2. Sử dụng Spring Boot để xây dựng dự án backend và triển khai RESTful API
|
||||
3. Thiết kế chuỗi dữ liệu hoàn chỉnh "hành vi người dùng → đề xuất"
|
||||
4. Triển khai logic đề xuất có thể giải thích
|
||||
5. Hoàn thành liên hợp đầu cuối, bàn giao nguyên mẫu sản phẩm có thể demo
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một trang web phim có khả năng đề xuất:
|
||||
|
||||
| Chức năng | Mô tả |
|
||||
|------|------|
|
||||
| **Duyệt và tìm kiếm** | Người dùng có thể duyệt và tìm kiếm phim |
|
||||
| **Đánh giá và收藏** | Người dùng có thể đánh giá phim, thêm收藏 |
|
||||
| **Đề xuất cá nhân hóa** | Hệ thống đưa ra kết quả đề xuất dựa trên hành vi người dùng |
|
||||
| **Back-office quản trị** | Quản trị viên duy trì dữ liệu phim, xem hiệu quả đề xuất |
|
||||
|
||||
::: tip Đường dẫn PRD
|
||||
Tài liệu yêu cầu của dự án này nằm trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/movie-recommendation-springboot/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, xác định chiến lược đề xuất, dữ liệu hành vi và phạm vi back-office' },
|
||||
{ title: 'Xây dựng khung', description: 'Dùng AI tạo trang danh sách, trang chi tiết, trang đề xuất và trang back-office' },
|
||||
{ title: 'Phát triển lặp', description: 'Bổ sung logic đề xuất, ghi hành vi và quản lý back-office' },
|
||||
{ title: 'Liên hợp & triển khai', description: 'Chạy đầu cuối, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Chiến lược đề xuất là gì? Phiên bản đầu tiên có sử dụng phiên bản có thể giải thích (như dựa trên độ tương tự đánh giá) không?
|
||||
- Dữ liệu hành vi người dùng cần lưu những gì? (Đánh giá,收藏, bản ghi duyệt, v.v.)
|
||||
- Quản trị viên cần xem những chỉ số hiệu quả đề xuất nào?
|
||||
- Danh sách trang đã hoàn chỉnh chưa?
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu sai yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận kiến trúc hệ thống
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> web["Trang frontend"]
|
||||
web --> auth["Xác thực người dùng"]
|
||||
web --> movie["Danh sách / Chi tiết phim"]
|
||||
web --> behavior["Đánh giá / 收藏"]
|
||||
behavior --> reco["Logic đề xuất"]
|
||||
reco --> db["Cơ sở dữ liệu"]
|
||||
admin["Back-office quản trị"] --> db
|
||||
```
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo trang frontend
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng dựa trên PRD hiện tại, giúp tôi tạo khung frontend của hệ thống đề xuất phim bằng Spring Boot.
|
||||
|
||||
Yêu cầu:
|
||||
1. Trang bao gồm: trang chủ, danh sách phim, chi tiết phim, trang đề xuất, trang cá nhân, back-office quản trị
|
||||
2. Trước tiên chỉ tạo cấu trúc trang và dữ liệu giả, không kết nối API thực tế
|
||||
3. Phong cách phải giống sản phẩm nội dung thực tế, chứ không phải demo lớp học
|
||||
```
|
||||
|
||||
### 2.2 Xác minh cấu trúc trang
|
||||
|
||||
Kiểm tra từng mục:
|
||||
|
||||
- [ ] Trang danh sách phim hỗ trợ tìm kiếm và lọc
|
||||
- [ ] Trang chi tiết phim bao gồm nút đánh giá và收藏
|
||||
- [ ] Trang đề xuất có thể hiển thị kết quả đề xuất và lý do đề xuất
|
||||
- [ ] Back-office quản trị có thể hiển thị dữ liệu phim và hiệu quả đề xuất
|
||||
|
||||
## Phần 3: Phát triển lặp
|
||||
|
||||
### 3.1 Triển khai theo module
|
||||
|
||||
1. **Xây dựng dự án Spring Boot**: Cấu trúc dự án, cấu hình cơ sở dữ liệu, CRUD cơ bản
|
||||
2. **Quản lý dữ liệu phim**: Danh sách phim, chi tiết, API tìm kiếm
|
||||
3. **Hành vi người dùng**: API đánh giá,收藏, ghi dữ liệu hành vi
|
||||
4. **Logic đề xuất**: Triển khai thuật toán đề xuất dựa trên hành vi người dùng
|
||||
5. **Hiển thị đề xuất**: Hiển thị kết quả đề xuất, bao gồm lý do đề xuất
|
||||
6. **Back-office quản trị**: Duy trì dữ liệu phim, xem hiệu quả đề xuất
|
||||
|
||||
### 3.2 Tự kiểm tra module
|
||||
|
||||
| Mục kiểm tra | Phương pháp xác minh |
|
||||
|--------|----------|
|
||||
| Chức năng cơ bản | Danh sách, chi tiết, đánh giá,收藏 có thành chuỗi hoàn chỉnh không |
|
||||
| Liên kết đề xuất | Hành vi người dùng có ảnh hưởng đến kết quả đề xuất không |
|
||||
| Tính có thể giải thích của đề xuất | Người dùng có thể hiểu tại sao được đề xuất những phim này không |
|
||||
| Dữ liệu back-office | Quản trị viên có thể xem dữ liệu phim và hiệu quả đề xuất không |
|
||||
|
||||
## Phần 4: Liên hợp và Triển khai
|
||||
|
||||
### 4.1 Kiểm thử đầu cuối
|
||||
|
||||
Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Duyệt phim → Đánh giá →收藏 → Xem trang đề xuất, xác nhận kết quả đề xuất thay đổi
|
||||
- Quản trị viên đăng nhập → Thêm phim → Xem thống kê hiệu quả đề xuất
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Ảnh chụp màn hình các trang cốt lõi (danh sách phim, chi tiết phim, trang đề xuất, back-office quản trị)
|
||||
- [ ] Video demo 60 giây
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Căn chỉnh PRD | Trang, chức năng, cấu trúc dữ liệu cơ bản khớp với PRD | Có thể giải thích rõ ràng quyết định thiết kế |
|
||||
| Chuỗi sản phẩm | Duyệt → Đánh giá →收藏 → Đề xuất có thể chạy qua | Hành vi đánh giá rõ ràng ảnh hưởng đến kết quả đề xuất |
|
||||
| Chất lượng đề xuất | Kết quả đề xuất hợp lý, lý do đề xuất có thể giải thích | Hỗ trợ nhiều chiến lược đề xuất |
|
||||
| Khả năng back-office | Dữ liệu phim và hiệu quả đề xuất có thể xem | Có chỉ số thống kê như độ chính xác đề xuất |
|
||||
| Độ hoàn thiện kỹ thuật | Frontend, backend Spring Boot, chuỗi cơ sở dữ liệu đã kết nối | API đề xuất có bộ nhớ đệm hoặc tối ưu hiệu suất |
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình hỗ trợ viết code API và tài liệu API bằng mô hình lớn](../../backend/ai-interface-code/)
|
||||
- [Quy trình làm việc Git và GitHub](../../backend/git-workflow/)
|
||||
- [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,172 @@
|
||||
# Thực hành phát triển hệ thống microservices thương mại điện tử thực phẩm tươi sống
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn hoàn thành một hệ thống microservices thương mại điện tử thực phẩm tươi sống dựa trên một PRD thực tế, xây dựng từ đầu. Khác với các dự án dịch vụ đơn lẻ trước đó, backend của dự án này được chia thành nhiều dịch vụ độc lập theo nghiệp vụ, thông qua API Gateway thống nhất对外. Bạn sẽ học cách thiết kế ranh giới dịch vụ, cách xử lý vấn đề nhất quán dữ liệu cross-service.
|
||||
|
||||
Đây là phần thực hành tổng hợp của Stage 2. Kiến trúc microservices rất phổ biến trong thực tế công việc, sau khi nắm vững tư duy cơ bản về phân tách dịch vụ và định tuyến gateway, bạn có thể ứng phó với thiết kế hệ thống backend phức tạp hơn.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm được các nội dung sau:
|
||||
|
||||
- Thiết kế trang frontend và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển API backend ([Viết code API](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Quy trình làm việc Git và triển khai ([Git và GitHub](../../backend/git-workflow/), [Triển khai ứng dụng Web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc PRD và trích xuất danh sách công việc phát triển hệ thống microservices
|
||||
2. Phân tách ranh giới dịch vụ theo lĩnh vực nghiệp vụ (xác thực, sản phẩm, tồn kho, đơn hàng)
|
||||
3. Thiết kế và triển khai định tuyến API Gateway
|
||||
4. Xử lý các vấn đề cross-service như trừ tồn kho và nhất quán đơn hàng
|
||||
5. Hoàn thành liên hợp đầu cuối, bàn giao nguyên mẫu microservices có thể demo
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một hệ thống microservices thương mại điện tử thực phẩm tươi sống:
|
||||
|
||||
| Hệ thống con | Trách nhiệm |
|
||||
|--------|------|
|
||||
| **Trang người dùng** | Duyệt sản phẩm, đặt hàng, xem đơn hàng |
|
||||
| **Trang quản trị** | Quản lý sản phẩm, quản lý tồn kho, quản lý đơn hàng |
|
||||
|
||||
Backend được phân tách theo nghiệp vụ thành các dịch vụ sau:
|
||||
|
||||
| Dịch vụ | Trách nhiệm |
|
||||
|------|------|
|
||||
| **API Gateway** | Điểm vào thống nhất, chuyển tiếp định tuyến, kiểm tra xác thực |
|
||||
| **Auth Service** | Đăng ký người dùng, đăng nhập, cấp JWT |
|
||||
| **Catalog Service** | Quản lý thông tin sản phẩm |
|
||||
| **Inventory Service** | Quản lý số lượng tồn kho |
|
||||
| **Order Service** | Tạo đơn hàng, quản lý trạng thái |
|
||||
|
||||
::: tip Đường dẫn PRD
|
||||
Tài liệu yêu cầu của dự án này nằm trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/simple-grocery-microservices/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, xác định phân tách dịch vụ, trang và chuỗi giao dịch' },
|
||||
{ title: 'Xây dựng khung', description: 'Tạo khung frontend, gateway và các dịch vụ' },
|
||||
{ title: 'Phát triển lặp', description: 'Bổ sung API từng module, sửa nhất quán tồn kho và đơn hàng' },
|
||||
{ title: 'Liên hợp & triển khai', description: 'Chạy đầu cuối, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Dịch vụ được phân tách như thế nào? Ranh giới trách nhiệm của mỗi dịch vụ là gì?
|
||||
- Frontend và trang quản trị lần lượt có những trang nào?
|
||||
- Chiến lược trừ tồn kho sau khi đặt hàng là gì? Xử lý thành công / thất bại / timeout mỗi loại như thế nào?
|
||||
- Phiên bản đầu tiên những khả năng phức tạp nào (như giao dịch phân tán, hàng đợi tin nhắn) tạm thời không làm?
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu sai yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận kiến trúc hệ thống
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> fe["Trang frontend"]
|
||||
fe --> gw["API Gateway"]
|
||||
gw --> auth["Auth Service"]
|
||||
gw --> catalog["Catalog Service"]
|
||||
gw --> inventory["Inventory Service"]
|
||||
gw --> order["Order Service"]
|
||||
order --> inventory
|
||||
```
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo cấu trúc dự án
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng dựa trên PRD hiện tại, giúp tôi tạo cấu trúc dự án của hệ thống microservices thương mại điện tử thực phẩm tươi sống.
|
||||
|
||||
Yêu cầu:
|
||||
1. Tạo khung frontend trang người dùng và trang quản trị
|
||||
2. Tạo năm thư mục: api-gateway, auth-service, catalog-service, inventory-service, order-service
|
||||
3. Mỗi dịch vụ trước tiên chỉ làm điểm vào có thể chạy tối thiểu
|
||||
4. Trước tiên không kết nối cơ sở dữ liệu thực tế và thanh toán
|
||||
```
|
||||
|
||||
### 2.2 Xác minh cấu trúc dự án
|
||||
|
||||
Kiểm tra từng mục:
|
||||
|
||||
- [ ] Cấu trúc thư mục của năm dịch vụ rõ ràng
|
||||
- [ ] API Gateway có thể khởi động và chuyển tiếp yêu cầu
|
||||
- [ ] API kiểm tra sức khỏe của mỗi dịch vụ có thể sử dụng
|
||||
- [ ] Trang frontend trang người dùng và trang quản trị có thể truy cập
|
||||
|
||||
## Phần 3: Phát triển lặp
|
||||
|
||||
### 3.1 Triển khai theo module
|
||||
|
||||
1. **API Gateway**: Cấu hình định tuyến, middleware kiểm tra JWT
|
||||
2. **Auth Service**: Đăng ký, đăng nhập, cấp JWT
|
||||
3. **Catalog Service**: CRUD sản phẩm, truy vấn danh sách
|
||||
4. **Inventory Service**: Truy vấn tồn kho, trừ tồn kho
|
||||
5. **Order Service**: Tạo đơn hàng, chuyển trạng thái, liên kết tồn kho
|
||||
6. **Trang quản trị**: Quản lý sản phẩm, quản lý tồn kho, quản lý đơn hàng
|
||||
|
||||
### 3.2 Tự kiểm tra module
|
||||
|
||||
| Mục kiểm tra | Phương pháp xác minh |
|
||||
|--------|----------|
|
||||
| Định tuyến gateway | API của mỗi dịch vụ có được chuyển tiếp chính xác qua gateway không |
|
||||
| Cách ly phân quyền | API trang người dùng và trang quản trị có cách ly không |
|
||||
| Nhất quán dữ liệu | Dữ liệu sản phẩm và tồn kho có đồng bộ không |
|
||||
| Chuỗi giao dịch | Sau khi đặt hàng, trừ tồn kho, trạng thái đơn hàng có nhất quán không |
|
||||
| Xử lý thất bại | Khi tồn kho không đủ hoặc timeout có cơ chế bù đắp không |
|
||||
|
||||
## Phần 4: Liên hợp và Triển khai
|
||||
|
||||
### 4.1 Kiểm thử đầu cuối
|
||||
|
||||
Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Duyệt sản phẩm → Thêm vào giỏ hàng → Đặt hàng → Xem đơn hàng
|
||||
- Quản trị viên → Thêm sản phẩm → Cập nhật tồn kho → Xem đơn hàng
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Ảnh chụp màn hình các trang cốt lõi (danh sách sản phẩm, trang đặt hàng, trang đơn hàng, back-office quản trị)
|
||||
- [ ] Video demo 60 giây
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Căn chỉnh PRD | Trang, chức năng, phân tách dịch vụ cơ bản khớp với PRD | Có thể giải thích rõ ràng lý do phân tách dịch vụ |
|
||||
| Chuỗi sản phẩm | Duyệt → Đặt hàng → Trừ tồn kho → Xem đơn hàng có thể chạy qua | Timeout đơn hàng hoặc tồn kho không đủ có cơ chế bù đắp |
|
||||
| Kiến trúc dịch vụ | Mỗi dịch vụ có thể khởi động độc lập, truy cập thống nhất qua gateway | Giao tiếp giữa dịch vụ có xử lý lỗi và thử lại |
|
||||
| Khả năng back-office | Quản lý sản phẩm, tồn kho, đơn hàng có thể thao tác | Trang quản trị có thống kê dữ liệu |
|
||||
| Độ hoàn thiện kỹ thuật | Frontend, gateway, dịch vụ, chuỗi cơ sở dữ liệu đã kết nối | Có Docker Compose hoặc điều phối tương tự |
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình hỗ trợ viết code API và tài liệu API bằng mô hình lớn](../../backend/ai-interface-code/)
|
||||
- [Quy trình làm việc Git và GitHub](../../backend/git-workflow/)
|
||||
- [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,163 @@
|
||||
# Thực hành phát triển nền tảng phân tích dữ liệu giao thông bằng Go
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn hoàn thành một nền tảng phân tích dữ liệu giao thông dựa trên một PRD thực tế, sử dụng Go. Hướng của dự án này khác với các hệ thống CRUD trước đó — bạn cần xây dựng một chuỗi dữ liệu hoàn chỉnh "nhập dữ liệu → tổng hợp → cảnh báo → trực quan hóa". Loại sản phẩm dữ liệu này rất phổ biến trong các kịch bản IoT, giám sát, phân tích vận hành, v.v.
|
||||
|
||||
Đây là phần thực hành tổng hợp của Stage 2, cũng là lần đầu tiên bạn tiếp xúc với ngôn ngữ Go. Đừng lo lắng, với nền tảng JavaScript / TypeScript trước đó, học Go không khó — trọng tâm là hiểu tư duy thiết kế chuỗi dữ liệu.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm được các nội dung sau:
|
||||
|
||||
- Thiết kế trang frontend và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển API backend ([Viết code API](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Quy trình làm việc Git và triển khai ([Git và GitHub](../../backend/git-workflow/), [Triển khai ứng dụng Web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc PRD và trích xuất danh sách công việc phát triển sản phẩm dữ liệu
|
||||
2. Sử dụng Go (Gin hoặc Fiber) để xây dựng dịch vụ API backend
|
||||
3. Thiết kế chuỗi hoàn chỉnh nhập dữ liệu, tổng hợp cửa sổ và cảnh báo
|
||||
4. Giữ cho dữ liệu backend và bảng điều khiển frontend nhất quán
|
||||
5. Hoàn thành liên hợp đầu cuối, bàn giao nguyên mẫu sản phẩm dữ liệu có thể demo
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một nền tảng phân tích dữ liệu giao thông bằng Go:
|
||||
|
||||
| Module | Trách nhiệm |
|
||||
|------|------|
|
||||
| **Nhập dữ liệu** | Nhận sự kiện giao thông thô và lưu vào cơ sở dữ liệu |
|
||||
| **Tổng hợp dữ liệu** | Tính toán xu hướng và chỉ số tắc nghẽn theo cửa sổ thời gian |
|
||||
| **Cảnh báo** | Tạo bản ghi cảnh báo dựa trên quy tắc |
|
||||
| **Hiển thị bảng điều khiển** | Hiển thị biểu đồ xu hướng, bảng xếp hạng và danh sách cảnh báo trên frontend |
|
||||
|
||||
::: tip Đường dẫn PRD
|
||||
Tài liệu yêu cầu của dự án này nằm trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/traffic-data-visualization-go/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, xác định nguồn dữ liệu, định nghĩa chỉ số và quy tắc cảnh báo' },
|
||||
{ title: 'Xây dựng khung', description: 'Dùng AI tạo dịch vụ Go API và khung bảng điều khiển frontend' },
|
||||
{ title: 'Phát triển lặp', description: 'Bổ sung logic tổng hợp, quy tắc cảnh báo và API bảng điều khiển' },
|
||||
{ title: 'Liên hợp & triển khai', description: 'Chạy đầu cuối, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Nguồn dữ liệu là gì? Có những trường nào?
|
||||
- Định nghĩa của các chỉ số cốt lõi là gì? (Ví dụ tiêu chuẩn cụ thể của "tắc nghẽn")
|
||||
- Quy tắc cảnh báo là gì? Phiên bản đầu tiên có nên thu hẹp lại thành quy tắc đơn giản không?
|
||||
- Bảng điều khiển bao gồm những trang và biểu đồ nào?
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu sai yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận chuỗi dữ liệu
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> ingest["API nhập dữ liệu"]
|
||||
ingest --> raw["Bảng dữ liệu thô"]
|
||||
raw --> agg["Tác vụ tổng hợp"]
|
||||
agg --> alert["Quy tắc cảnh báo"]
|
||||
agg --> dashboard["API bảng điều khiển"]
|
||||
alert --> dashboard
|
||||
```
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo dịch vụ Go API
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng dựa trên PRD hiện tại, giúp tôi tạo khung nền tảng phân tích dữ liệu giao thông bằng Go.
|
||||
|
||||
Yêu cầu:
|
||||
1. Sử dụng Gin hoặc Fiber
|
||||
2. Cung cấp API nhập dữ liệu
|
||||
3. Cung cấp khung tác vụ tổng hợp
|
||||
4. Cung cấp khung API dashboard và alerts
|
||||
5. Trước tiên không làm phân tích phức tạp thực tế, chỉ làm cấu trúc có thể chạy
|
||||
```
|
||||
|
||||
### 2.2 Xác minh cấu trúc dự án
|
||||
|
||||
Kiểm tra từng mục:
|
||||
|
||||
- [ ] Dịch vụ Go có thể khởi động bình thường
|
||||
- [ ] API nhập dữ liệu có thể nhận và lưu trữ dữ liệu
|
||||
- [ ] Khung tác vụ tổng hợp đã được xây dựng
|
||||
- [ ] Trang bảng điều khiển frontend có thể hiển thị biểu đồ cơ bản
|
||||
|
||||
## Phần 3: Phát triển lặp
|
||||
|
||||
### 3.1 Triển khai theo module
|
||||
|
||||
1. **API nhập dữ liệu**: Nhận sự kiện giao thông thô, ghi vào cơ sở dữ liệu
|
||||
2. **Tổng hợp dữ liệu**: Tổng hợp theo cửa sổ thời gian, tính toán xu hướng và chỉ số tắc nghẽn
|
||||
3. **Quy tắc cảnh báo**: Tạo bản ghi cảnh báo dựa trên ngưỡng
|
||||
4. **API bảng điều khiển**: Cung cấp dữ liệu xu hướng, dữ liệu xếp hạng, danh sách cảnh báo
|
||||
5. **Bảng điều khiển frontend**: Trang biểu đồ xu hướng, bảng xếp hạng, danh sách cảnh báo
|
||||
|
||||
### 3.2 Tự kiểm tra module
|
||||
|
||||
| Mục kiểm tra | Phương pháp xác minh |
|
||||
|--------|----------|
|
||||
| Nhập dữ liệu | Dữ liệu thô có được lưu vào cơ sở dữ liệu chính xác không |
|
||||
| Khẩu vị tổng hợp | Logic tính toán chỉ số xu hướng, xếp hạng có nhất quán không |
|
||||
| Quy tắc cảnh báo | Điều kiện kích hoạt cảnh báo có khớp với kỳ vọng không |
|
||||
| Tính nhất quán dữ liệu | Hiển thị bảng điều khiển và dữ liệu backend có khớp nhau không |
|
||||
| Quy phạm API | Có cấu trúc trả về thống nhất và xử lý lỗi không |
|
||||
|
||||
## Phần 4: Liên hợp và Triển khai
|
||||
|
||||
### 4.1 Kiểm thử đầu cuối
|
||||
|
||||
Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Nhập một loạt dữ liệu thử nghiệm → Thực thi tác vụ tổng hợp → Cập nhật hiển thị bảng điều khiển
|
||||
- Kích hoạt điều kiện cảnh báo → Tạo bản ghi cảnh báo → Trang cảnh báo hiển thị
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Ảnh chụp màn hình các trang cốt lõi (demo nhập dữ liệu, bảng điều khiển xu hướng, danh sách cảnh báo)
|
||||
- [ ] Video demo 60 giây
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Căn chỉnh PRD | Chức năng và cấu trúc dữ liệu cơ bản khớp với PRD | Có thể giải thích rõ ràng khẩu vị chỉ số và logic tổng hợp |
|
||||
| Chuỗi dữ liệu | Nhập → Tổng hợp → Cảnh báo → Bảng điều khiển có thể chạy qua | Tác vụ tổng hợp hỗ trợ cập nhật gia tăng |
|
||||
| Khả năng phân tích | Ba module xu hướng, xếp hạng, cảnh báo có thể sử dụng | Chỉ số có thể cấu hình, quy tắc cảnh báo có thể tùy chỉnh |
|
||||
| Hiển thị frontend | Bảng điều khiển có thể hiển thị biểu đồ cơ bản | Biểu đồ hỗ trợ lọc phạm vi thời gian |
|
||||
| Độ hoàn thiện kỹ thuật | Chuỗi Go API, cơ sở dữ liệu, frontend đã kết nối | API có xử lý lỗi thống nhất và nhật ký |
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình hỗ trợ viết code API và tài liệu API bằng mô hình lớn](../../backend/ai-interface-code/)
|
||||
- [Quy trình làm việc Git và GitHub](../../backend/git-workflow/)
|
||||
- [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,164 @@
|
||||
# Thực hành phát triển nền tảng Agent lập kế hoạch du lịch thông minh
|
||||
|
||||
## Tổng quan
|
||||
|
||||
Dự án thực chiến này yêu cầu bạn hoàn thành một nền tảng Agent lập kế hoạch du lịch thông minh dựa trên một PRD thực tế, xây dựng từ đầu. Bạn sẽ xây dựng một sản phẩm AI hoàn chỉnh có thể nhận đầu vào có cấu trúc, tạo lịch trình hàng ngày, hỗ trợ lưu trữ và tái sử dụng — không chỉ là chatbot, mà là một sản phẩm có khả năng quản lý tác vụ.
|
||||
|
||||
Đây là phần thực hành tổng hợp của Stage 2. Thách thức cốt lõi của dự án này là: làm thế nào để AI tạo ra kế hoạch lịch trình có cấu trúc và sử dụng được, chứ không phải một đoạn văn bản dài không thể thao tác.
|
||||
|
||||
## Kiến thức tiên quyết
|
||||
|
||||
Trước khi bắt đầu dự án này, bạn nên đã nắm được các nội dung sau:
|
||||
|
||||
- Thiết kế trang frontend và sử dụng thư viện component ([Thiết kế UI](../../frontend/ui-design/), [Thư viện component hiện đại](../../frontend/modern-component-library/))
|
||||
- Thiết kế và phát triển API backend ([Viết code API](../../backend/ai-interface-code/))
|
||||
- Cơ sở dữ liệu cơ bản và Supabase ([Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/))
|
||||
- Quy trình làm việc Git và triển khai ([Git và GitHub](../../backend/git-workflow/), [Triển khai ứng dụng Web](../../backend/zeabur-deployment/))
|
||||
|
||||
## Mục tiêu học tập
|
||||
|
||||
Sau khi hoàn thành bài thực hành này, bạn sẽ có thể:
|
||||
|
||||
1. Đọc PRD và từ đó trích xuất danh sách công việc phát triển nền tảng Agent
|
||||
2. Thiết kế biểu mẫu đầu vào có cấu trúc và định dạng đầu ra có cấu trúc
|
||||
3. Triển khai lớp điều phối Agent, xử lý đầu vào người dùng, gọi mô hình và lưu trữ kết quả
|
||||
4. Xây dựng chuỗi nghiệp vụ "tạo → lưu → tái sử dụng"
|
||||
5. Hoàn thành liên hợp đầu cuối, bàn giao nguyên mẫu sản phẩm AI có thể demo
|
||||
|
||||
## Giới thiệu dự án
|
||||
|
||||
Sản phẩm bạn cần xây dựng là một nền tảng Agent lập kế hoạch du lịch thông minh:
|
||||
|
||||
| Chức năng | Mô tả |
|
||||
|------|------|
|
||||
| **Lập kế hoạch lịch trình** | Người dùng nhập điểm xuất phát, điểm đến, ngày, ngân sách và sở thích, hệ thống tạo lịch trình hàng ngày |
|
||||
| **Phân bổ ngân sách** | Kết quả lịch trình bao gồm phân bổ ngân sách và đề xuất |
|
||||
| **Quản lý lịch sử** | Người dùng có thể lưu kế hoạch lịch sử, tạo lại, xuất |
|
||||
| **Back-office quản trị** | Quản trị viên xem điểm đến phổ biến, tác vụ thất bại và phản hồi người dùng |
|
||||
|
||||
::: tip Đường dẫn PRD
|
||||
Tài liệu yêu cầu của dự án này nằm trên GitHub: [Xem PRD](https://github.com/datawhalechina/easy-vibe/blob/main/docs/zh-cn/stage-2/assignments/travel-planning-agent-platform/PRD.md)
|
||||
:::
|
||||
|
||||
<div style="margin: 32px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'Phân tích yêu cầu', description: 'Đọc PRD, xác định trang, điều phối Agent, cấu trúc đầu vào/đầu ra' },
|
||||
{ title: 'Xây dựng khung', description: 'Dùng AI tạo khung trang chủ, trang lập kế hoạch, trang lịch sử, trang back-office' },
|
||||
{ title: 'Phát triển lặp', description: 'Bổ sung từng module: đầu ra có cấu trúc, trạng thái tác vụ, quản lý lịch sử' },
|
||||
{ title: 'Liên hợp & triển khai', description: 'Chạy đầu cuối, triển khai và chuẩn bị demo' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## Phần 1: Phân tích yêu cầu
|
||||
|
||||
### 1.1 Đọc PRD
|
||||
|
||||
Mở tài liệu PRD, tập trung trả lời các câu hỏi sau:
|
||||
|
||||
- Phiên bản đầu tiên có chỉ làm một điểm đến không?
|
||||
- Đầu ra lịch trình có bắt buộc phải có cấu trúc không? Cấu trúc là gì?
|
||||
- Khả năng xuất sâu đến đâu? (Liên kết chia sẻ / PDF / Hình ảnh)
|
||||
- Phạm vi thống kê back-office và nhật ký tác vụ là gì?
|
||||
|
||||
::: warning
|
||||
Nếu các câu hỏi trên chưa có câu trả lời rõ ràng, đừng bắt đầu viết code. Hiểu sai yêu cầu là nguyên nhân phổ biến nhất dẫn đến phải làm lại.
|
||||
:::
|
||||
|
||||
### 1.2 Xác nhận kiến trúc hệ thống
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
prd["PRD"] --> planner["Trang lập kế hoạch"]
|
||||
planner --> agent["Lớp điều phối Agent"]
|
||||
agent --> model["Gọi mô hình"]
|
||||
agent --> db["Cơ sở dữ liệu"]
|
||||
db --> history["Kế hoạch lịch sử"]
|
||||
db --> admin["Thống kê & nhật ký back-office"]
|
||||
```
|
||||
|
||||
## Phần 2: Xây dựng khung dự án
|
||||
|
||||
### 2.1 Tạo trang frontend
|
||||
|
||||
Tham khảo prompt:
|
||||
|
||||
```text
|
||||
Vui lòng dựa trên PRD hiện tại, giúp tôi tạo khung frontend của nền tảng Agent lập kế hoạch du lịch thông minh.
|
||||
|
||||
Yêu cầu:
|
||||
1. Trang bao gồm: trang chủ, trang lập kế hoạch, trang chi tiết lịch trình, trang lịch sử, trang quản lý
|
||||
2. Trang lập kế hoạch bên trái là biểu mẫu, bên phải là xem trước kết quả
|
||||
3. Trước tiên chỉ tạo cấu trúc trang và dữ liệu giả, không kết nối API thực tế
|
||||
4. Phong cách phải giống sản phẩm AI hiện đại
|
||||
```
|
||||
|
||||
### 2.2 Xác minh cấu trúc trang
|
||||
|
||||
Kiểm tra từng mục:
|
||||
|
||||
- [ ] Trường biểu mẫu trang lập kế hoạch có khớp với PRD không
|
||||
- [ ] Khu vực xem trước kết quả có thể hiển thị dữ liệu lịch trình có cấu trúc
|
||||
- [ ] Trang lịch sử có thể hiển thị nhiều kế hoạch
|
||||
- [ ] Trang back-office quản trị có thể hiển thị dữ liệu thống kê
|
||||
|
||||
## Phần 3: Phát triển lặp
|
||||
|
||||
### 3.1 Triển khai theo module
|
||||
|
||||
1. **Xác thực**: Đăng ký, đăng nhập
|
||||
2. **Biểu mẫu lập kế hoạch**: Đầu vào có cấu trúc (điểm xuất phát, điểm đến, ngày, ngân sách, sở thích)
|
||||
3. **Điều phối Agent**: Nhận đầu vào → Gọi mô hình → Phân tích đầu ra có cấu trúc
|
||||
4. **Hiển thị kết quả**: Lịch trình hiển thị theo ngày, phân bổ ngân sách, đề xuất
|
||||
5. **Quản lý lịch sử**: Lưu kế hoạch, tạo lại, xuất
|
||||
6. **Back-office quản trị**: Điểm đến phổ biến, tác vụ thất bại, phản hồi người dùng
|
||||
7. **Trạng thái tác vụ**: Quản lý trạng thái đang tạo / thành công / thất bại và ghi lỗi
|
||||
|
||||
### 3.2 Tự kiểm tra module
|
||||
|
||||
| Mục kiểm tra | Phương pháp xác minh |
|
||||
|--------|----------|
|
||||
| Tính đầy đủ đầu vào | Trường biểu mẫu có khớp với PRD không |
|
||||
| Tính cấu trúc đầu ra | Kết quả lịch trình có phải là dữ liệu có cấu trúc (chứ không phải một đoạn văn bản dài) không |
|
||||
| Tính nhất quán dữ liệu | Dữ liệu trip, itinerary, logs có khớp nhau không |
|
||||
| Xác minh chuỗi hoàn chỉnh | Có thể demo "nhập → tạo → lưu → tạo lại" không |
|
||||
|
||||
## Phần 4: Liên hợp và Triển khai
|
||||
|
||||
### 4.1 Kiểm thử đầu cuối
|
||||
|
||||
Ít nhất xác minh các kịch bản sau:
|
||||
|
||||
- Nhập tham số lịch trình → Tạo lịch trình hàng ngày → Xem phân bổ ngân sách → Lưu vào lịch sử
|
||||
- Tạo lại lịch trình từ bản ghi lịch sử
|
||||
- Quản trị viên xem thống kê tác vụ và nhật ký thất bại
|
||||
|
||||
## Sản phẩm bàn giao
|
||||
|
||||
Sau khi hoàn thành dự án này, bạn cần nộp các nội dung sau:
|
||||
|
||||
- [ ] Liên kết demo trực tuyến có thể truy cập
|
||||
- [ ] Liên kết kho mã nguồn (bao gồm README)
|
||||
- [ ] Tài liệu PRD
|
||||
- [ ] Ảnh chụp màn hình các trang cốt lõi (trang lập kế hoạch, trang chi tiết lịch trình, trang lịch sử, back-office quản trị)
|
||||
- [ ] Video demo 60 giây
|
||||
|
||||
## Tiêu chí chấm điểm
|
||||
|
||||
| Chiều | Yêu cầu cơ bản | Yêu cầu nâng cao |
|
||||
|------|---------|---------|
|
||||
| Căn chỉnh PRD | Trang, chức năng, cấu trúc dữ liệu cơ bản khớp với PRD | Có thể giải thích rõ ràng quyết định thiết kế |
|
||||
| Chuỗi sản phẩm | Lập kế hoạch → Lưu → Lịch sử → Tạo lại có thể chạy qua | Hỗ trợ xuất và chia sẻ |
|
||||
| Chất lượng đầu ra | Kết quả lịch trình có cấu trúc và dễ đọc | Phân bổ ngân sách hợp lý, đề xuất có tính định hướng |
|
||||
| Khả năng back-office | Thống kê tác vụ và nhật ký thất bại có thể xem | Có phân tích điểm đến phổ biến |
|
||||
| Độ hoàn thiện kỹ thuật | Frontend, backend, cơ sở dữ liệu, chuỗi gọi mô hình đã kết nối | Quản lý trạng thái tác vụ hoàn thiện, lỗi có thể truy vết |
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Thiết kế UI](../../frontend/ui-design/)
|
||||
- [Sử dụng thư viện component hiện đại để cập nhật giao diện](../../frontend/modern-component-library/)
|
||||
- [Từ cơ sở dữ liệu đến Supabase](../../backend/database-supabase/)
|
||||
- [Mô hình hỗ trợ viết code API và tài liệu API bằng mô hình lớn](../../backend/ai-interface-code/)
|
||||
- [Quy trình làm việc Git và GitHub](../../backend/git-workflow/)
|
||||
- [Cách triển khai ứng dụng Web](../../backend/zeabur-deployment/)
|
||||
@@ -0,0 +1,161 @@
|
||||
# Mô hình lớn hỗ trợ viết mã giao diện và tài liệu giao diện
|
||||
|
||||
Trong các bài học trước, chúng ta đã học cách sử dụng các công cụ như Figma để hoàn thành bản thiết kế UI, cách借助 AI nhanh chóng tạo trang tĩnh frontend, và cách sử dụng Supabase để xây dựng cơ sở dữ liệu và thực hiện xác thực người dùng cơ bản. Bây giờ, một câu hỏi tự nhiên xuất hiện: sau khi nhấn các nút đầy动感 trên trang frontend, dữ liệu thực sự đã được âm thầm lưu vào Supabase như thế nào? Khi chúng ta cần thực hiện logic nghiệp vụ phức tạp hơn (như thanh toán đồng thời, đẩy thông báo định kỳ, xử lý dữ liệu nhạy cảm), việc để frontend kết nối trực tiếp với cơ sở dữ liệu có an toàn không?
|
||||
|
||||
Điều này dẫn đến một khâu then chốt trong kiến trúc phát triển Web hiện đại — **giao diện API backend**.
|
||||
|
||||
So với việc trước đây phải tự gõ hàng trăm hàng nghìn dòng route backend, controller và logic xác thực tham số, giờ đây chúng ta hoàn toàn có thể借助 sức mạnh tạo mã của mô hình lớn, giao phó phần code cơ sở rườm rà cho AI viết. Trong bài học này, chúng ta sẽ thoát khỏi vòng lặp "AI viết rất hời hợt", dựa trên các kịch bản nghiệp vụ thực tế, hướng dẫn bạn cách thông qua các prompt chất lượng cao (Prompt) dẫn dắt mô hình lớn viết các giao diện backend Node.js mạnh mẽ, tuân thủ quy chuẩn ngành, và tự động hoàn thành việc tạo tài liệu giao diện và test case.
|
||||
|
||||
> 💡 **Kiến thức tiên quyết**
|
||||
>
|
||||
> Trước khi học phần này, bạn nên tìm hiểu các nội dung sau:
|
||||
> - [Từ cơ sở dữ liệu đến Supabase](../database-supabase/) - Hiểu về khái niệm cơ sở dữ liệu và mô hình dữ liệu.
|
||||
> - [Học sử dụng Git và Github](../git-workflow/) - Làm quen với cách kiểm soát phiên bản trong phát triển dự án.
|
||||
> - [Terminal/Dòng lệnh là gì](/vi-vn/appendix/2-development-tools/command-line-shell) - Khởi tạo và chạy dự án không thể tách khỏi các thao tác dòng lệnh cơ bản.
|
||||
|
||||
# Bạn sẽ học được gì
|
||||
|
||||
1. **Giao diện API là gì**: Hiểu cầu nối giao tiếp frontend-backend và quy chuẩn thiết kế RESTful.
|
||||
2. **Mô hình lớn hỗ trợ xây dựng dịch vụ**: Cách thông qua Prompt có cấu trúc để AI giúp bạn xây dựng dự án cơ bản Node.js + Express.
|
||||
3. **Phát triển logic giao diện**: Dẫn dắt mô hình lớn tạo các giao diện CRUD (thêm, đọc, sửa, xóa) bao gồm xác thực nghiệp vụ nghiêm ngặt và kết nối cơ sở dữ liệu Supabase.
|
||||
4. **Tài liệu giao diện tự động**: Để mô hình_large dựa trên code tạo tài liệu OpenAPI/Swagger tiêu chuẩn cho cộng tác liên đội.
|
||||
5. **Vòng lặp kiểm thử và tích hợp**: Sử dụng mô hình_large để tạo bộ kiểm thử Postman và unit test Jest, đảm bảo chất lượng code.
|
||||
|
||||
---
|
||||
|
||||
# 1. Tại sao chúng ta cần giao diện API?
|
||||
|
||||
Trong cách hiểu truyền thống, frontend là "phần có thể nhìn thấy", cơ sở dữ liệu là "kho chứa đồ". Nhưng ở giữa thiếu một người điều phối. Nếu bạn tưởng tượng toàn bộ ứng dụng là một nhà hàng:
|
||||
- **Frontend (Client)** là menu và bàn đặt món của nhà hàng, khách hàng duyệt món và đưa ra yêu cầu tại đây.
|
||||
- **Cơ sở dữ liệu (Supabase, v.v.)** là kho của bếp nhà hàng, nơi lưu trữ tất cả nguyên liệu và sổ kế toán.
|
||||
- **Giao diện API backend** là nhân viên phục vụ của nhà hàng. Khách hàng không thể trực tiếp chạy vào bếp lấy nguyên liệu (không chỉ lộn xộn mà còn dễ gây vấn đề an toàn), mà cần đưa "yêu cầu đặt món" (HTTP Request) cho nhân viên phục vụ. Nhân viên phục vụ tiến hành xác nhận (xác thực tham số, xác thực quyền), sau đó vào bếp lấy nội dung tương ứng, rồi mang "món đã làm xong" (HTTP Response, thường là dữ liệu dạng JSON) ra cho khách hàng.
|
||||
|
||||
Thông qua giao diện API, chúng ta thực hiện **tách biệt frontend-backend** rõ ràng: frontend chỉ quan tâm đến cách render trang, backend chỉ tập trung vào logic nghiệp vụ, xử lý dữ liệu và bảo vệ an toàn.
|
||||
|
||||
---
|
||||
|
||||
# 2. Thiết kế kiến trúc dự án và khởi tạo
|
||||
|
||||
Một cấu trúc dự án rõ ràng là điều kiện tiên quyết để mô hình_large có thể viết code tốt. Trước khi để AI viết code, bản thân chúng ta phải hiểu rõ cấu trúc dự án.
|
||||
|
||||
## 2.1 Cấu trúc dự án API phổ biến
|
||||
Ngay cả khi sử dụng mô hình_large để tạo code, chúng ta tuyệt đối không nên nhét tất cả code vào một file `server.js`. Một kiến trúc backend Node.js dễ bảo trì thường có dạng như sau:
|
||||
|
||||
```text
|
||||
my-api-project/
|
||||
├── .env # Biến môi trường nhạy cảm (như API Keys, chuỗi kết nối cơ sở dữ liệu)
|
||||
├── server.js # Điểm vào dự án (khởi động server, đăng ký middleware toàn cục)
|
||||
├── package.json # File quản lý dependency
|
||||
├── src/
|
||||
│ ├── routes/ # Lớp route: định nghĩa đường dẫn URL và phương thức yêu cầu
|
||||
│ ├── controllers/ # Lớp controller: xử lý tham số yêu cầu nghiệp vụ, gọi service và trả về response
|
||||
│ ├── services/ # Lớp service: đóng gói tương tác cơ sở dữ liệu và logic nghiệp vụ cốt lõi
|
||||
│ └── middlewares/ # Middleware: xác thực đăng nhập, bắt lỗi toàn cục
|
||||
└── docs/ # Thư mục lưu tài liệu API
|
||||
```
|
||||
|
||||
## 2.1借助 AI hoàn thành khởi tạo dự án
|
||||
Thay vì tự `npm init` và cài đặt từng dependency, tốt hơn là đưa quy chuẩn trên cho mô hình_large dưới dạng Prompt:
|
||||
|
||||
> 🗣️ **Prompt cho mô hình_large (Ví dụ Prompt):**
|
||||
> "Giúp tôi xây dựng một dự án backend Node.js, có thể kết nối cơ sở dữ liệu Supabase, cấu trúc rõ ràng, thuận tiện bảo trì sau này."
|
||||
|
||||
Sau khi chạy code mà AI trả về, bạn sẽ có một ứng dụng backend với quy mô doanh nghiệp tại `localhost:3000`.
|
||||
|
||||
---
|
||||
|
||||
# 3. Thực hành cốt lõi: Mô hình_large hỗ trợ phát triển giao diện
|
||||
|
||||
Đây là phần cốt lõi nhất của chương này. Code do mô hình_large viết thường dễ có "lỗ hổng logic" hoặc "xào nấu hời hợt", nguyên nhân là do ngữ cảnh mà developer cung cấp không đủ. **Mô hình_large không sợ yêu cầu phức tạp, chỉ sợ yêu cầu mơ hồ.**
|
||||
|
||||
Lấy ví dụ về interface thêm mới cho bảng `menu_items` (bảng menu) được đề cập trong [chương cơ sở dữ liệu](../database-supabase/), hãy xem cách viết một Prompt chất lượng cao.
|
||||
|
||||
## 3.1 Cung cấp đầy đủ ngữ cảnh cho mô hình_large
|
||||
Trước khi yêu cầu AI viết giao diện, nhất định phải cung cấp **định nghĩa trường cơ sở dữ liệu (Schema)** và **điều kiện ràng buộc cụ thể**.
|
||||
|
||||
> 🗣️ **Mẫu Prompt chất lượng cao:**
|
||||
> "Giúp tôi viết một interface thêm menu mới, menu có tên sản phẩm, giá, phân loại (burger, đồ ăn nhẹ, đồ uống), và thông tin có上架 hay không. Tên sản phẩm và giá là bắt buộc, giá không thể là số âm. Khi người dùng nhập sai cần hiện thông báo lỗi."
|
||||
|
||||
## 3.2 Xem xét code do mô hình_large tạo
|
||||
Code do mô hình_large tạo thường sẽ phân tách trách nhiệm rõ ràng như sau:
|
||||
|
||||
```javascript
|
||||
// services/menuService.js
|
||||
const { createClient } = require('@supabase/supabase-js')
|
||||
const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY)
|
||||
|
||||
exports.createMenuItem = async (menuData) => {
|
||||
// Gọi Supabase SDK đẩy dữ liệu vào bảng
|
||||
const { data, error } = await supabase
|
||||
.from('menu_items')
|
||||
.insert([menuData])
|
||||
.select()
|
||||
|
||||
if (error) throw new Error(`Chèn cơ sở dữ liệu thất bại: ${error.message}`)
|
||||
return data[0]
|
||||
}
|
||||
```
|
||||
|
||||
Bạn có thể thấy, code được tạo theo cách này không chỉ có cấu trúc hợp lý mà còn tính đến khởi tạo Supabase, bắt lỗi và xử lý ngoại lệ, hoàn toàn khác biệt với Spaghetti Code khi chỉ đơn giản yêu cầu "viết một interface thêm mới".
|
||||
|
||||
---
|
||||
|
||||
# 4. Giải phóng đôi tay: Tự động tạo tài liệu giao diện
|
||||
|
||||
Đối với đội ngũ phát triển, một API không có tài liệu giống như một món đồ bí ẩn. Kỹ sư frontend không thể đoán được bạn cần truyền vào tham số gì, cũng không thể dự đoán cấu trúc trả về sẽ như thế nào. Quy chuẩn mô tả API phổ biến nhất trong ngành là **OpenAPI (trước đây còn gọi là Swagger)**.
|
||||
|
||||
Trước đây, việc tự viết tài liệu Swagger dạng YAML hoặc JSON cực kỳ đau đớn và dễ sai. Bây giờ, đây cũng trở thành lĩnh vực mà mô hình_large giỏi nhất.
|
||||
|
||||
Bạn có thể chọn trực tiếp code `routes` và `controllers` vừa viết, rồi đưa cho mô hình_large:
|
||||
|
||||
> 🗣️ **Prompt tạo tài liệu:**
|
||||
> "Giúp tôi dựa trên code trên tạo một tài liệu giao diện, cần ghi rõ ý nghĩa của từng tham số, trả về dữ liệu gì, thuận tiện cho đồng nghiệp frontend đối接."
|
||||
|
||||
Trong quá trình này, bạn thậm chí có thể yêu cầu AI bổ sung mô tả trường (Description) và dữ liệu Mock (ví dụ `price_cents: 1200` đại diện cho 12 USD), giảm đáng kể chi phí giao tiếp.
|
||||
|
||||
---
|
||||
|
||||
# 5. Bảo đảm chất lượng: Tạo code kiểm thử và bộ sưu tập Postman
|
||||
|
||||
Code đã viết, tài liệu đã hoàn thành, còn thiếu bước cuối cùng: xác minh xem code có thực sự chạy được hay không.
|
||||
|
||||
## 5.1 Tạo cấu hình kiểm thử Postman / Apifox
|
||||
Trong phát triển giao diện, chúng ta thường sử dụng các công cụ trực quan như Postman để mô phỏng frontend gửi yêu cầu HTTP. Nếu không sử dụng mô hình_large, bạn cần tự nhập URL, thêm từng Header (tiêu đề yêu cầu) và nối JSON request body.
|
||||
|
||||
Bạn chỉ cần gửi lệnh cho AI:
|
||||
> "Giúp tôi chuyển tài liệu giao diện này sang định dạng có thể import vào Postman, cần bao gồm cả ví dụ yêu cầu bình thường và yêu cầu lỗi."
|
||||
|
||||
Sau khi nhận được văn bản JSON, lưu thành `menu_api.json` và kéo vào Postman, bạn ngay lập tức có một bảng điều khiển kiểm thử sẵn sàng sử dụng.
|
||||
|
||||
## 5.2 Viết unit test tự động
|
||||
Nếu bạn theo đuổi chất lượng kỹ thuật nghiêm ngặt hơn, có thể để mô hình_large giúp bạn sử dụng framework kiểm thử như `Jest` để viết unit test, kiểm tra biên cho logic nghiệp vụ cốt lõi (ví dụ: khi truyền vào giá âm, liệu xác thực ở tầng cơ sở dữ liệu có hiệu lực hay không).
|
||||
|
||||
---
|
||||
|
||||
# 6. Thực hành tốt nhất cần biết về giao diện backend
|
||||
|
||||
Ngay cả khi có sự hỗ trợ của AI, với tư cách là "người gác cổng" của toàn bộ hệ thống, bạn vẫn cần hiểu và kiểm duyệt các nguyên tắc cốt lõi sau:
|
||||
|
||||
1. **Đặt tên đường dẫn theo quy chuẩn RESTful**:
|
||||
- Thiết kế tốt: `GET /api/users` (lấy danh sách người dùng), `POST /api/users` (tạo người dùng). URL nên là danh từ đại diện cho "tài nguyên".
|
||||
- Thiết kế sai: `POST /api/getUser` hoặc `POST /api/createUser`. Động từ nên được thể hiện bằng HTTP Method (GET/POST/PUT/DELETE).
|
||||
2. **Mã trạng thái HTTP theo quy chuẩn**:
|
||||
- 200/201: Yêu cầu thành công / Tạo tài nguyên thành công.
|
||||
- 400: Bad Request, định dạng tham số truyền từ frontend sai, thiếu mục bắt buộc.
|
||||
- 401/403: Unauthorized / Forbidden, người dùng chưa đăng nhập hoặc không có quyền thao tác.
|
||||
- 404: NotFound, tài nguyên không tồn tại.
|
||||
- 500: Server Error, code backend bị lỗi hoặc cơ sở dữ liệu sập, tuyệt đối tránh hiển thị error call stack cho frontend (có rủi ro an ninh).
|
||||
3. **Không bao giờ tin tưởng đầu vào của người dùng**: Đầu vào từ frontend có thể bị giả mạo, tất cả xác thực tham số cốt lõi phải được thực hiện lại tại giao diện backend.
|
||||
|
||||
# 7. Tổng kết
|
||||
|
||||
Thông qua việc học chương này, bạn đã thực sự chuyển đổi góc nhìn phát triển: bạn không còn là "người đánh máy" bị mắc kẹt trong cú pháp và dấu câu, mà đã trở thành **nhà thiết kế hệ thống và chỉ huy kiến trúc**.
|
||||
Bạn đã nắm được:
|
||||
1. Tư duy hệ thống cốt lõi về **giao diện API và tách biệt frontend-backend**.
|
||||
2. **Cách cung cấp ngữ cảnh và khái niệm cấu trúc phân tầng**, nâng cao đáng kể chất lượng code backend do mô hình_large tạo.
|
||||
3. Biến công việc **viết tài liệu** và **xây dựng test case** rườm rà thành tác vụ tự động hóa mà AI giỏi thực hiện.
|
||||
4. Kết hợp kiến thức **Supabase** đã học trước đó, hoàn thành dòng dữ liệu từ yêu cầu client đến cập nhật cơ sở dữ liệu.
|
||||
|
||||
::: tip 💡 Bước tiếp theo
|
||||
Khi dòng dữ liệu và dịch vụ backend của bạn đã sẵn sàng, hiện tại nó vẫn chỉ có thể "tự giải trí" trên máy tính cục bộ của bạn. Trong các chương tiếp theo, chúng ta sẽ học cách **triển khai (Deploy)** dịch vụ này lên máy chủ công cộng, để sản phẩm của bạn có thể được truy cập bởi người dùng trên toàn thế giới.
|
||||
:::
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,261 @@
|
||||
# Học sử dụng Git và Github
|
||||
|
||||
Trong các bài học trước, chúng ta đã học cách viết code bằng các công cụ vibe coding dựa trên Web. Mỗi cuộc trò chuyện sẽ tạo ra một phiên bản code mới. Nhưng hãy nghĩ về một vấn đề: nếu chúng ta muốn quay lại sửa đổi trước đó, có cách nào tiện lợi không? Có công cụ nào có thể ghi lại code của chúng ta ở các giai đoạn khác nhau, cho phép chúng ta chuyển đổi và sửa đổi giữa các phiên bản bất kỳ lúc nào không?
|
||||
|
||||
Để đáp ứng nhu cầu này, phần mềm kiểm soát phiên bản đã ra đời. Trong bài viết này, chúng ta sẽ giới thiệu chương trình kiểm soát phiên bản nổi tiếng nhất — Git — và nền tảng lưu trữ code tốt nhất — GitHub. Chúng ta sẽ học cách sử dụng Git để quản lý code, cách lấy code của người khác từ GitHub, cách tải lên code của chính mình, và cách hợp tác với người khác trong các dự án lớn.
|
||||
|
||||
Cho dù là theo dõi phiên bản dự án cá nhân, đồng bộ code trong hợp tác đội nhóm, hay đóng góp cho cộng đồng mã nguồn mở, Git và GitHub đều là công cụ không thể thiếu của developer hiện đại. Bằng cách làm chủ chúng, bạn sẽ có thể quản lý code hiệu quả hơn, tạo checkpoint theo cần, chuyển đổi tự do giữa các giai đoạn code khác nhau, và dễ dàng xử lý mọi thứ từ thay đổi file đơn lẻ đến phát triển dự án lớn — làm cho mỗi lần lặp code đều có thể kiểm soát và truy xuất nguồn gốc.
|
||||
|
||||
> 💡 **Kiến thức tiên quyết**
|
||||
>
|
||||
> Trước khi học Git, bạn nên tìm hiểu các khái niệm sau:
|
||||
> - [Terminal/Dòng lệnh là gì](/vi-vn/appendix/2-development-tools/command-line-shell) - Học cách sử dụng dòng lệnh để tương tác với máy tính
|
||||
> - [Git là gì](/vi-vn/appendix/2-development-tools/git-version-control) - Hiểu các khái niệm cốt lõi của hệ thống kiểm soát phiên bản Git
|
||||
>
|
||||
> Bài viết này sẽ tập trung vào quy trình làm việc GitHub và thao tác thực tế, vui lòng tham khảo các liên kết phụ lục cho kiến thức cơ bản nói trên.
|
||||
|
||||
# Bắt đầu nhanh với Git
|
||||
|
||||
Trước khi bắt đầu sử dụng Git, hãy đảm bảo bạn đã đọc nội dung về [dòng lệnh](/vi-vn/appendix/2-development-tools/command-line-shell) và [cơ bản về Git](/vi-vn/appendix/2-development-tools/git-version-control) trong phần phụ lục. Bài viết này sẽ giả định bạn đã có kiến thức cơ bản này và trực tiếp hướng dẫn cách cài đặt, cấu hình Git và sử dụng GitHub để cộng tác.
|
||||
|
||||
## Cách cài đặt Git
|
||||
|
||||
Chúng ta sẽ giới thiệu ba phương pháp cài đặt Git trên các hệ điều hành máy tính khác nhau. Vui lòng làm theo hướng dẫn phù hợp với phiên bản hệ thống của bạn:
|
||||
|
||||
### Windows
|
||||
|
||||
1. Truy cập [Trang tải Git chính thức](https://git-scm.com/download/win) và tải về trình cài đặt phù hợp với hệ thống của bạn: [Gói cài đặt](https://github.com/git-for-windows/git/releases/download/v2.51.0.windows.1/Git-2.51.0-64-bit.exe). Theo mặc định, khuyến nghị sử dụng trình cài đặt x64.
|
||||
2. Nhấp đúp vào trình cài đặt và làm theo hướng dẫn của thuật sĩ cài đặt:
|
||||
|
||||
1. Khuyến nghị giữ các tùy chọn mặc định. Nếu bạn cần tùy chỉnh, lưu ý các điểm sau: (Trong hầu hết trường hợp, bạn có thể nhấp "Next" liên tục)
|
||||
- Chọn trình soạn thảo mặc định Git sử dụng: Chọn trình soạn thảo bạn thích (như VS Code). Bạn có thể chọn tùy chọn đầu tiên theo mặc định, tức là Vim (một trình soạn thảo văn bản), hoặc chọn tùy chọn "Visual Studio Code as Git's default editor" (cần cài đặt VS Code trước). Bạn có thể giữ lựa chọn mặc định và nhấp "Next" để tiếp tục.
|
||||
|
||||
- Chọn cách sử dụng Git: Ba tùy chọn này kiểm soát khả năng truy cập của Git trong hệ thống. Khuyến nghị chọn tùy chọn 2 ("from command line and 3rd-party software") — nó thêm các công cụ Git cơ bản vào PATH, cho phép bạn sử dụng Git trong Git Bash, Command Prompt, PowerShell và IDE mà không làm rối hệ thống.
|
||||
|
||||
|
||||
3. Sau khi cài đặt, nhấp chuột phải trên màn hình. Nếu bạn thấy "Git Bash Here" trong menu, cài đặt đã thành công.
|
||||
|
||||
|
||||
|
||||
### MacOS
|
||||
|
||||
Đối với macOS, bạn có thể nhập `git --version` trong terminal để kiểm tra xem Git đã được cài đặt chưa. Nếu chưa, hệ thống sẽ nhắc bạn cài đặt — chỉ cần làm theo hướng dẫn để hoàn tất cài đặt.
|
||||
|
||||
1. Phương pháp 1: Cài đặt qua Homebrew
|
||||
Nếu bạn đã cài đặt [Homebrew](https://brew.sh/) (trình quản lý gói Mac), hãy mở terminal và nhập
|
||||
```bash
|
||||
brew install git
|
||||
```
|
||||
2. Phương pháp 2: (Khuyến nghị) Cài đặt qua Xcode: https://developer.apple.com/xcode/, Xcode đã tích hợp sẵn Git. Sau khi cài đặt, chỉ cần làm theo hướng dẫn để tiếp tục.
|
||||
|
||||
### Linux
|
||||
|
||||
Hầu hết các bản phân phối Linux có thể cài đặt Git thông qua trình quản lý gói:
|
||||
|
||||
- Ubuntu/Debian:
|
||||
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install git
|
||||
```
|
||||
|
||||
- CentOS/RHEL:
|
||||
|
||||
```bash
|
||||
sudo yum install git
|
||||
```
|
||||
|
||||
- Xác minh cài đặt: Nhập git --version trong terminal. Nếu hiển thị số phiên bản, cài đặt đã thành công.
|
||||
|
||||
## Khởi tạo Git
|
||||
|
||||
Sau khi cài đặt Git, đầu tiên bạn cần cấu hình thông tin người dùng — đây là bước cơ bản khi sử dụng Git để kiểm soát phiên bản. Thực hiện các lệnh sau trong terminal (thay thế nội dung trong ngoặc bằng thông tin của bạn):
|
||||
|
||||
```bash
|
||||
# Đặt tên người dùng toàn cục (sẽ hiển thị trong bản ghi commit)
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
# Đặt email toàn cục (khuyến nghị sử dụng email đã đăng ký trên GitHub/GitLab)
|
||||
git config --global user.email "your.email@example.com"
|
||||
```
|
||||
|
||||
Git sẽ nhúng thông tin này vào mỗi bản ghi commit, làm "thông tin tác giả" cho mỗi lần sửa đổi. Khi xem lịch sử phiên bản (ví dụ: sử dụng git log), bạn có thể thấy rõ ai đã sửa đổi mỗi dòng code, thuận tiện cho việc truy trách nhiệm và giao tiếp. Trong dự án cộng tác, thông tin danh tính thống nhất giúp thành viên nhóm nhanh chóng nhận diện ai đã thực hiện thay đổi nào, từ đó nâng cao hiệu quả cộng tác (ví dụ: tìm developer liên quan thông qua bản ghi commit để thảo luận vấn đề).
|
||||
|
||||
Bạn có thể nhập `git config --list` trong dòng lệnh để xem thông tin cấu hình Git hiện tại và xác nhận cài đặt thành công.
|
||||
|
||||
# GitHub là gì
|
||||
|
||||
GitHub là một nền tảng lưu trữ code dựa trên Git. Nó không chỉ cung cấp lưu trữ từ xa cho các kho lưu trữ Git mà còn bao gồm các công cụ cộng tác (như Issues, Pull Requests, Projects), giúp developer dễ dàng chia sẻ code và hợp tác hơn. Nói một cách đơn giản, Git là công cụ kiểm soát phiên bản cục bộ, còn GitHub là "đĩa cloud kho code + cộng đồng cộng tác" từ xa.
|
||||
|
||||
GitHub không chỉ là nền tảng lưu trữ code lớn nhất thế giới mà còn là cộng đồng mã nguồn mở năng động và có sức ảnh hưởng nhất toàn cầu. Ý tưởng cốt lõi của "mã nguồn mở" ở đây là bất kỳ ai cũng có thể tải xuống và chạy mã nguồn của phần mềm. Mô hình này cho phép mọi người trên thế giới kiểm tra code của nhau và thực hiện sửa đổi, hoặc tạo dự án mới dựa trên đó. Ví dụ: bạn có thể tìm thấy nhiều hướng dẫn học tập cũng như mã nguồn hoàn chỉnh của framework huấn luyện mô hình GPT (như PyTorch) trên GitHub. Mỗi ngày, vô số người trên toàn thế giới cộng tác kiểm tra và cải thiện code.
|
||||
|
||||
|
||||
|
||||
Nhiều công ty lớn mở mã nguồn chương trình hoặc hướng dẫn của họ trên GitHub để đạt lợi thế cạnh tranh trong ngành — điều này cũng có thể xem là một hình thức quảng cáo. Trong cộng đồng GitHub, số "ngôi sao (stars)" mà dự án nhận được là thước đo chính về giá trị của dự án; dự án hoặc tổ chức càng có nhiều sao thì uy tín và sức ảnh hưởng càng lớn.
|
||||
|
||||
|
||||
|
||||
Trong khóa học của chúng ta, tài nguyên hỗ trợ và bài tập cũng sẽ được tải lên kho lưu trữ GitHub chuyên dụng. Thông qua quá trình tải lên bài tập, bạn sẽ dần làm quen và nắm vững việc sử dụng GitHub, tạo nền tảng vững chắc cho việc kiểm soát phiên bản trong phát triển ứng dụng tương lai.
|
||||
|
||||
## Đăng ký tài khoản GitHub
|
||||
|
||||
1. Truy cập [Trang chủ GitHub](https://github.com/) và nhấp "Sign up" ở góc trên bên phải.
|
||||
|
||||
2. Nhập địa chỉ email của bạn (khuyến nghị sử dụng email thường xuyên sử dụng, vì xác minh và thông báo sẽ được gửi đến đó), đặt mật khẩu (phải bao gồm chữ cái, số và ký tự đặc biệt).
|
||||
3. Hoàn thành xác minh con người, xác minh email theo hướng dẫn, tài khoản của bạn đã được tạo.
|
||||
|
||||
## Tạo kho lưu trữ đầu tiên trên GitHub
|
||||
|
||||
Tiếp theo, chúng ta sẽ tạo thư mục lưu trữ đầu tiên, còn được gọi là kho lưu trữ hoặc "repo".
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. Repository name: Tên kho lưu trữ hiển thị cho người khác.
|
||||
2. Description: Mô tả chi tiết về kho lưu trữ.
|
||||
3. Choose visibility: Đối với kho cá nhân, nếu đặt là private, chỉ bạn và những người được mời đặc biệt mới có thể xem. Nếu đặt là public, tất cả mọi người đều có thể xem.
|
||||
Đối với kho trong tổ chức, nếu là Private, chỉ người trong tổ chức mới có thể xem.
|
||||
Nếu là Public, người ngoài tổ chức cũng có thể xem.
|
||||
4. README: Thông thường, mỗi kho đều nên có file README. Bạn có thể coi nó như bản giới thiệu đầy đủ về kho, bao gồm hướng dẫn sử dụng, danh sách file và cách thao tác.
|
||||
5. Add .gitignore and license:
|
||||
1. File .gitignore báo cho Git biết bỏ qua một số thư mục hoặc file nhất định khi tải lên GitHub, do đó chúng sẽ không được theo dõi hoặc thêm vào staging area. Điều này rất hữu ích cho các file kiểm thử tạm thời, gói dependency hoặc file lớn. Khi đã chỉ định, các file này sẽ không còn được theo dõi.
|
||||
2. license là loại giấy phép mã nguồn mở bạn chọn. Các giấy phép khác nhau quy định chi tiết việc người khác có thể sử dụng code của bạn cho mục đích thương mại hay không, cùng với các điều khoản và điều kiện khác.
|
||||
|
||||
Khuyến nghị tích "Add README", đặt khả năng hiển thị kho là "Private", điền tên kho và mô tả theo sở thích của bạn, sau đó nhấp "Create repository" để hoàn tất việc tạo kho lưu trữ từ xa đầu tiên.
|
||||
|
||||
|
||||
|
||||
Sau đó, bạn sẽ có một kho sạch không có file bổ sung nào. Tiếp theo bạn có thể bắt đầu tải file lên.
|
||||
|
||||
|
||||
|
||||
Lệnh để lấy kho là `git clone`, nhưng nó cần địa chỉ kho. Bạn có thể tìm địa chỉ kho bằng cách nhấp nút "Code" màu xanh lá, bạn sẽ thấy các tùy chọn HTTPS và SSH. Thông thường, bạn có thể sử dụng bất kỳ phương pháp nào trong hai phương pháp này để tải kho về máy cục bộ (chỉ có như vậy bạn mới có thể sửa đổi và tải file lên).
|
||||
|
||||
|
||||
|
||||
Nói chung, kho được clone qua HTTP phù hợp để tải xuống và kiểm thử tạm thời kho của người khác, nhưng không khuyến nghị cho phát triển cá nhân. Để có trải nghiệm học tập tốt hơn, bạn nên thiết lập xác thực SSH trước.
|
||||
|
||||
## Liên kết SSH cục bộ
|
||||
|
||||
Trong GitHub, "liên kết giao thức SSH" về bản chất là việc liên kết SSH public key của thiết bị cục bộ với tài khoản GitHub của bạn, cho phép GitHub nhận diện thiết bị của bạn thông qua giao thức SSH. Điều này cho phép bạn vận hành kho lưu trữ từ xa một cách an toàn mà không cần mật khẩu (như clone, push hoặc pull code).
|
||||
|
||||
Nói đơn giản: Điều này giống như cấp cho thiết bị của bạn một "thẻ kiểm soát truy cập GitHub chuyên dụng". Sau khi liên kết, khi thiết bị của bạn truy cập kho GitHub thông qua giao thức SSH, GitHub sẽ xác minh "thẻ kiểm soát truy cập" (SSH public key của bạn). Khi đã xác nhận là thiết bị được ủy quyền, bạn có thể trực tiếp vận hành — không cần nhập tài khoản và mật khẩu mỗi lần.
|
||||
|
||||
> 💡 SSH là gì
|
||||
|
||||
### Tại sao cần liên kết giao thức SSH?
|
||||
|
||||
GitHub hỗ trợ hai giao thức vận hành kho chính: giao thức HTTPS và giao thức SSH:
|
||||
|
||||
- Giao thức HTTPS: Mỗi thao tác (như push) đều cần nhập tài khoản và mật khẩu GitHub (hoặc Personal Access Token PAT). Quá trình xác minh phức tạp và có rủi ro rò rỉ mật khẩu.
|
||||
- Giao thức SSH: Xác thực được hoàn thành thông qua "cặp khóa", do đó không cần nhập mật khẩu lặp lại, và truyền tải được mã hóa an toàn hơn.
|
||||
|
||||
"Liên kết giao thức SSH" là bước tiên quyết để kích hoạt xác thực SSH GitHub — chỉ khi liên kết SSH public key cục bộ với tài khoản GitHub, GitHub mới có thể nhận diện thiết bị của bạn và cho phép vận hành SSH trên kho.
|
||||
|
||||
### Logic cốt lõi của "liên kết": Vai trò của cặp khóa SSH
|
||||
|
||||
Xác thực SSH dựa vào cặp khóa (public key + private key), chúng là các file mã hóa khớp nhau. Sau khi tạo, bạn cần cung cấp "public key" cho GitHub ("liên kết"), và giữ "private key" trên thiết bị cục bộ:
|
||||
|
||||
1. Private key: Được lưu trữ trong thư mục được chỉ định (thường là ~/.ssh/) trên thiết bị cục bộ (như máy tính), đóng vai trò là "chìa khóa chuyên dụng của bạn", tuyệt đối không chia sẻ với bất kỳ ai.
|
||||
2. Public key: Đây là một "ổ khóa" có thể chia sẻ công khai — bạn cần sao chép nó vào danh sách "SSH keys" của tài khoản GitHub (thao tác "liên kết").
|
||||
|
||||
Khi bạn vận hành kho GitHub thông qua SSH (ví dụ: git push git@github.com:xxx/xxx.git):
|
||||
|
||||
- Thiết bị cục bộ của bạn sử dụng private key để mã hóa "yêu cầu vận hành" và gửi đến GitHub;
|
||||
- Sau khi nhận yêu cầu, GitHub cố gắng giải mã bằng public key bạn đã liên kết trước đó;
|
||||
- Nếu giải mã thành công, thiết bị của bạn được xác nhận là đã ủy quyền, thao tác được cho phép; nếu không, truy cập bị từ chối.
|
||||
|
||||
### Các bước cụ thể của "liên kết" (Quy trình cốt lõi)
|
||||
|
||||
Khi bạn đã hiểu nguyên lý, thao tác thực tế rất đơn giản — cốt lõi là "tạo cặp khóa → tải public key lên GitHub":
|
||||
|
||||
1. Tạo cặp khóa SSH cục bộ
|
||||
1. Sử dụng Trae để lấy public key (khuyến nghị)
|
||||
Prompt: `Help me create the SSH key needed for GitHub login. My email is your_email@gmail.com , Please return the public key for me to copy`
|
||||
|
||||
|
||||
|
||||
Sau khi nhập prompt, bạn cũng cần nhấn Enter trong terminal bên trái, nếu không lệnh sẽ tiếp tục chờ mà không thực thi. Vì Trae không thể giúp bạn thực hiện bất kỳ điều kiện phán đoán nào, chúng ta chỉ cần nhấn Enter liên tục.
|
||||
|
||||
Cuối cùng, bạn sẽ thấy Trae ở bên phải trả về public key mà nó đã đọc. Bạn chỉ cần sao chép nó và chuẩn bị dán trong bước tiếp theo.
|
||||
|
||||
 2. Lấy public key thủ công
|
||||
Mở terminal cục bộ của bạn (trên Windows sử dụng Git Bash hoặc PowerShell; trên macOS/Linux sử dụng Terminal), nhập lệnh sau (thay your_email@example.com bằng email bạn đã đăng ký tài khoản GitHub):
|
||||
|
||||
```bash
|
||||
ssh-keygen -t ed25519 -C "your_email@example.com"
|
||||
```
|
||||
|
||||
1. Nhấn Enter để chấp nhận mặc định (đường dẫn file mặc định, không có passphrase, hoặc đặt passphrase theo cần). Điều này sẽ tạo hai file trong thư mục ~/.ssh/:
|
||||
- id_ed25519: Private key (lưu cục bộ, **tuyệt đối không chia sẻ**);
|
||||
- id_ed25519.pub: Public key (cần tải lên GitHub).
|
||||
|
||||
2. "Liên kết" public key với tài khoản GitHub
|
||||
|
||||
Đây là bước liên kết cốt lõi — thêm public key cục bộ vào danh sách "SSH keys" của tài khoản GitHub:
|
||||
|
||||
1. Sao chép nội dung public key:
|
||||
1. Trae:
|
||||
2. Windows: Mở C:\Users\<your>\.ssh\id_ed25519.pub bằng Notepad và sao chép toàn bộ nội dung;
|
||||
3. macOS/Linux: Chạy cat ~/.ssh/id_ed25519.pub trong terminal và sao chép toàn bộ đầu ra (từ phần đầu SSH-ed25519 đến email ở cuối).
|
||||
2. Đăng nhập GitHub và vào trang "SSH Key Management":
|
||||
1. Nhấp vào avatar góc trên bên phải → Settings → Menu bên trái SSH and GPG keys → Nhấp New SSH key.
|
||||
|
||||
2. Nhập bất kỳ tiêu đề nào (ví dụ: SSH của máy tính cục bộ của bạn), sau đó dán SSH public key bạn vừa lấy vào đây.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. Xác minh liên kết thành công
|
||||
|
||||
Nhập lệnh sau trong terminal (**Trae cũng có thể thực hiện các thao tác sau**) để kiểm tra xem GitHub có thể nhận diện thiết bị của bạn hay không:
|
||||
|
||||
```bash
|
||||
ssh -T git@github.com
|
||||
```
|
||||
|
||||
- Nếu bạn thấy nội dung tương tự như Hi [tên người dùng GitHub của bạn]! You've successfully authenticated..., điều đó có nghĩa là bạn đã liên kết khóa thành công;
|
||||
- Nếu gặp lỗi, thường là do public key sao chép không đầy đủ, quyền private key quá cao (thư mục ~/.ssh/ cục bộ của bạn chỉ nên cho phép bạn đọc và ghi). Hãy kiểm tra các vấn đề này theo cần.
|
||||
|
||||
### Lưu ý quan trọng
|
||||
|
||||
Nếu bạn có nhiều thiết bị (như laptop và máy bàn), bạn cần tạo cặp khóa SSH riêng cho mỗi thiết bị và liên kết mỗi public key với cùng một tài khoản GitHub — mỗi thiết bị có "thẻ kiểm soát truy cập" riêng.
|
||||
|
||||
Tuyệt đối không chia sẻ private key của bạn (không tải lên GitHub hoặc chia sẻ với người khác), nếu không ai đó có thể mạo danh bạn vận hành kho của bạn. Nếu private key bị rò rỉ, hãy xóa ngay public key tương ứng khỏi GitHub và tạo cặp khóa mới.
|
||||
|
||||
Sau khi liên kết SSH, sử dụng địa chỉ kho định dạng SSH (ví dụ: git@github.com:username/repository.git) để vận hành, thay vì định dạng HTTPS (ví dụ: https://github.com/username/repository.git). Nếu bạn đã clone kho bằng HTTPS trước đó, có thể dùng git remote set-url origin `<new>` để chuyển đổi giao thức.
|
||||
|
||||
# Sử dụng Trae để thao tác GitHub
|
||||
|
||||
Chúng ta đã giải thích Git là gì, GitHub là gì, SSH là gì và cách cấu hình nó. Bây giờ bạn có thể tự do sử dụng Trae để thực hiện các thao tác Git. Đầu tiên, hãy học cách clone kho lưu trữ từ xa về máy cục bộ.
|
||||
|
||||
## Git clone: Tải xuống kho hiện có
|
||||
|
||||
Bạn có thể trực tiếp cho nó biết địa chỉ kho bạn muốn clone
|
||||
|
||||
|
||||
|
||||
## Git pull: Lấy cập nhật từ kho từ xa
|
||||
|
||||
Trước khi cập nhật kho mỗi lần, vì nó có thể được bảo trì bởi nhiều người, bạn cần pull các thay đổi mới nhất trước. Sau đó, bạn có thể sửa đổi và push file.
|
||||
|
||||
**Nhớ bao gồm tên thư mục và đường dẫn tương đối hoặc tuyệt đối của nó, để tránh push sai kho.**
|
||||
|
||||
prompt:`Help me pull this repository AIID-TEST in ./AIID-TEST.`
|
||||
|
||||
## Git commit & Git push: Tạm lưu cập nhật và push lên GitHub
|
||||
|
||||
Khi mọi thứ đã sẵn sàng, bạn có thể thử sửa đổi file cục bộ, thêm hoặc xóa các mục trong thư mục. Sau đó, để Trae phát hiện các thay đổi và giúp bạn push lên GitHub.
|
||||
|
||||
prompt:`I finished. Commit and push to the repository AIID-TEST in ./AIID-TEST.`
|
||||
|
||||
|
||||
|
||||
Push thành công. Bây giờ bạn có thể xem nội dung đã cập nhật trên GitHub.
|
||||
|
||||
# Tài liệu tham khảo
|
||||
|
||||
- Pro Git book https://git-scm.com/book/en/v2
|
||||
- GitHub Docs https://docs.github.com/en
|
||||
@@ -0,0 +1,801 @@
|
||||
# Công cụ lập trình AI CLI
|
||||
|
||||
Trong hướng dẫn này, chúng tôi sẽ giới thiệu các Agent lập trình AI chạy trực tiếp trong dòng lệnh. Khác với Agent trong Trae, Cursor mà bạn đã học, công cụ lập trình AI CLI chỉ có thể sử dụng trong terminal. So với Agent tích hợp trong AI IDE, chúng thường có cửa sổ ngữ cảnh dài hơn, tốc độ gọi công cụ nhanh hơn, và có thể tương thích với nhiều loại mô hình lớn hơn. Trong thực chiến AI Vibe Coding mới nhất, chúng ta thường ưu tiên sử dụng công cụ lập trình AI CLI, thay vì Agent mã hóa tích hợp trong IDE.
|
||||
|
||||
## Từ CLI nói đến
|
||||
|
||||
Bạn còn nhớ CLI mà chúng tôi đã giới thiệu trước đó không? CLI là cách thao tác phần mềm ứng dụng bằng lệnh văn bản thuần túy thông qua terminal hoặc dấu nhắc lệnh, thay vì phụ thuộc vào giao diện đồ họa (GUI -- bạn có thể hiểu đơn giản là giao diện có nút bấm trên máy tính hoặc điện thoại, có thể thao tác bằng cách nhấp, không cần nhập lệnh).
|
||||
|
||||
> Trên Windows, các terminal phổ biến bao gồm "Command Prompt (cmd)" và "PowerShell". Bạn có thể nhập "cmd" hoặc "powershell" trong hộp chạy/tìm kiếm trên máy tính để khởi động các chương trình dòng lệnh này.
|
||||
|
||||
|
||||
|
||||
CLI thiên về thao tác lệnh văn bản, trong một nhóm nhỏ những người đam mê lập trình theo đuổi sự hoàn hảo (geek), CLI thậm chí còn phổ biến hơn GUI -- họ hy vọng tất cả thao tác đều hoàn thành qua bàn phím, thấy việc dùng chuột lại làm chậm hiệu suất lập trình của mình.
|
||||
|
||||
Trong ngành công nghiệp, CLI thường cũng là hình thức giao diện phổ biến nhất, vì GUI cần hệ điều hành vẽ giao diện bổ sung, quản lý cửa sổ, yêu cầu tài nguyên máy tính cao hơn; còn CLI chỉ cần truyền lệnh nhận được cho hệ thống thực thi. Do đó, khi kết nối cụm máy chủ quy mô lớn, chúng ta thường chỉ tương tác qua CLI.
|
||||
|
||||
|
||||
|
||||
Đối với nhiều bạn chưa có kinh nghiệm CLI, có thể thấy thao tác CLI rất phức tạp, lệnh quá nhiều, thậm chí lo ngại "một lần vô tình làm hỏng máy". Đừng lo. Còn nhớ trong hướng dẫn trước, chúng ta thường để Trae giúp hoàn thành các thao tác cơ bản không? Ở đây cũng có thể áp dụng hoàn toàn cách suy nghĩ này -- chúng ta có thể để công cụ lập trình CLI giúp chúng ta thực hiện tất cả thao tác CLI: để nó giúp bạn vào thư mục chỉ định, tìm kiếm và xử lý tệp, chạy hoặc sao chép dự án mã nguồn mở, v.v. Toàn bộ quá trình đều có thể hoàn thành thông qua hội thoại với công cụ lập trình AI CLI.
|
||||
|
||||
## Khác gì với AI IDE
|
||||
|
||||
Chúng ta có thể ví công cụ lập trình AI CLI như z.ai và Trae đã học trước đó. Theo một nghĩa nào đó, công cụ lập trình AI CLI có thể được coi là một z.ai đặc biệt: chúng cũng chỉ cần một cổng hội thoại đơn giản, sẽ tự động thực hiện tất cả thao tác cần thiết cho bạn (chỉ đôi khi bạn cần tự mở trình duyệt để xem kết quả cuối cùng). Còn nếu ví với AI IDE, thì công cụ lập trình AI CLI có thể được coi là module Agent trong IDE -- tức là vùng hội thoại ở thanh bên.
|
||||
|
||||
|
||||
|
||||
Tuy nhiên, do các AI IDE khác nhau có cách triển khai Agent khác nhau, năng lực cũng khác nhau đáng kể, hiệu quả lập trình AI thường không ổn định, do đó công cụ lập trình AI CLI thường được phát triển trực tiếp bởi các công ty công nghệ lớn, ví dụ Anthropic đứng sau Claude, OpenAI đứng sau ChatGPT, v.v.
|
||||
|
||||
So với các Agent lập trình AI khác, việc trực tiếp sử dụng các sản phẩm từ các nhà sản xuất lớn thường là thực tiễn tốt hơn, đặc biệt Claude Code bản thân là công cụ phục vụ đội ngũ phát triển nội bộ của Anthropic, ngay từ đầu đã được thiết kế xoay quanh "đáp ứng nhu cầu thực sự của kỹ sư".
|
||||
|
||||
Để so sánh trực quan hơn, chúng ta có thể xem đơn giản sự khác biệt giữa Claude Code và Agent của một AI IDE (ở đây lấy Cursor làm ví dụ):
|
||||
|
||||
| Tính năng | Claude Code | Cursor | Bên ưu thế hơn |
|
||||
| ----------------- | ------------- | --------------- | ----------- |
|
||||
| Thực thi tác vụ tự động | Rất mạnh | Khả năng hạn chế | Claude Code |
|
||||
| Tích hợp IDE | Chỉ dòng lệnh | VS Code gốc | Cursor |
|
||||
| Tự động hoàn thành mã theo thời gian thực | Không | Trải nghiệm tuyệt vời | Cursor |
|
||||
| Thao tác đa tệp | Rất mạnh | Khá tốt | Claude Code |
|
||||
| Thao tác GitHub tích hợp | Có thể commit trực tiếp | Cần thao tác thủ công | Claude Code |
|
||||
| Chi phí học tập | Trung bình | Dễ bắt đầu | Cursor |
|
||||
| Độ dài ngữ cảnh | Rất dài | Khá tốt | Claude Code |
|
||||
| Hỗ trợ gỡ lỗi | Tự động hóa | Nhiều cần thủ công | Claude Code |
|
||||
|
||||
Nguồn bảng: <https://northflank.com/blog/claude-code-vs-cursor-comparison>
|
||||
|
||||
Nói đơn giản, công cụ lập trình AI CLI thường có thể:
|
||||
|
||||
- Hỗ trợ hội thoại liên tục lâu hơn (thậm chí có thể giúp bạn "làm việc cả ngày").
|
||||
- Cung cấp cửa sổ ngữ cảnh dài hơn (không còn thường xuyên cần bạn nói "tiếp tục").
|
||||
- Phản hồi nhanh hơn (có thể kết nối nhiều API mô hình tùy chỉnh hơn).
|
||||
|
||||
Về các thao tác liên quan đến lập trình, chúng thường thông minh hơn, ổn định hơn so với phần lớn Agent tích hợp trong IDE.
|
||||
|
||||
## Các công cụ lập trình AI CLI phổ biến
|
||||
|
||||
Hiện tại tuy có nhiều triển khai mã nguồn mở, nhưng trong thực tiễn chúng tôi chỉ giới thiệu hai loại công cụ lập trình AI CLI chính, làm "tổ hợp ưu tiên". Bạn có thể chọn bất kỳ một trong hai theo thói quen của mình, khuyến nghị mạnh mẽ nên thử cả hai, sau đó chọn ra cái phù hợp nhất với bạn.
|
||||
|
||||
- Codex sử dụng GPT-5, mạnh hơn về năng lực tổng thể;
|
||||
- Claude Code thông qua API chuyển tiếp GLM 4.6, trải nghiệm tổng thể gần Claude 4, nhưng giá rẻ hơn.
|
||||
- OpenCode có thể tự do chuyển đổi và kết hợp mô hình, cung cấp mô hình miễn phí, có thể kiểm soát chi phí tốt hơn.
|
||||
|
||||
Tuy nhiên, cái nào tốt hơn trong dự án thực tế chỉ có thể đánh giá thông qua thử nghiệm cá nhân. Việc nắm vững nhiều công cụ lập trình AI luôn có lợi: sau khi thành thạo, bạn có thể linh hoạt chuyển đổi giữa Claude Code, Codex hoặc Trae trong các kịch bản khác nhau. Nếu thử nhiều lần phát hiện công cụ nào hiệu quả chung, có thể trực tiếp đổi công cụ hoặc mô hình khác tiếp tục thử nghiệm.
|
||||
|
||||
Đồng thời, do phiên bản mô hình cập nhật rất nhanh, khuyến nghị bạn ưu tiên chọn phương án thể hiện tốt nhất về "tỷ lệ giá (hiệu quả / chi phí)".
|
||||
|
||||
### Claude Code
|
||||
|
||||
Claude Code là công cụ lập trình AI do Anthropic phát triển dựa trên khả năng mô hình Claude lớn. Kịch bản tương tác chính của nó nằm ở terminal, đồng thời cũng hỗ trợ sử dụng như plugin VS Code. Tương tự như Agent trong AI IDE, nó có thể hiểu sâu kho mã của nhà phát triển, và hoàn thành tác vụ phát triển đầu-cuối thông qua lệnh ngôn ngữ tự nhiên -- bao gồm chỉnh sửa mã, sửa Bug, thực thi và sửa kiểm thử, quản lý quy trình làm việc Git (ví dụ giải quyết xung đột gộp, tạo PR), giải thích mã phức tạp, thực thi lệnh terminal, v.v.
|
||||
|
||||
|
||||
|
||||
Ưu điểm chính của Claude Code thể hiện ở: cửa sổ ngữ cảnh cực dài (có thể xử lý tệp hoàn chỉnh thậm chí dự án nhỏ), có thể chủ động làm rõ nhu cầu mơ hồ, tự động lập kế hoạch và phân phối tác vụ thực thi, cũng như khả năng hiểu và giải thích sâu toàn bộ nội dung kho mã. So với Agent IDE thông thường, nó phù hợp hơn với quy trình phát triển "vibe coding nhập môn".
|
||||
|
||||
Trong thực tế sử dụng, bạn có thể thông qua lệnh hội thoại, để nó giúp bạn tạo dự án mới, thực hiện thao tác CLI (ví dụ sắp xếp thư mục, đổi tên tệp hàng loạt, triển khai dự án mã nguồn mở, v.v.), cấu hình môi trường phát triển (ví dụ cài đặt và gỡ lỗi môi trường Python). Nếu thấy đoạn mã nào khó hiểu, cấu trúc thư mục nào không rõ ràng, cũng có thể trực tiếp để Claude Code tạo tài liệu phân tích có cấu trúc, hoặc giải thích từng bước nội dung cụ thể.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nếu bạn muốn học Claude Code một cách hệ thống, có thể tham khảo khóa học do Andrew Ng và Anthropic cùng phát triển:
|
||||
<https://www.bilibili.com/video/BV176t2zSEpr>
|
||||
|
||||
Tiếp theo, chúng ta sẽ học cách sử dụng Claude Code. Do việc sử dụng trực tiếp Claude Code chính thức thường tốn kém rất cao (như hình dưới), chúng ta sẽ chuyển sang sử dụng nền tảng API dựa trên các mô hình lớn khác nhưng tương thích với giao thức Claude Code.
|
||||
|
||||
|
||||
|
||||
Bạn cần học một số phương án khác nhau dưới đây (tốt nhất nên thử tất cả), cuối cùng chọn phương án phù hợp nhất với bạn làm lộ trình thực hành chính.
|
||||
|
||||
Cách đầu tiên là sử dụng trực tiếp API "tương thích giao diện Anthropic". Với sự phổ biến của Claude Code, ngày càng nhiều nhà cung cấp mô hình lớn bắt đầu hỗ trợ cách gọi phong cách Anthropic. Các nhà cung cấp phổ biến bao gồm GLM, Kimi, DeepSeek và Siliconflow, v.v., đều cung cấp giao diện API tương thích. Về cấu hình cụ thể, chúng tôi sẽ nói chi tiết ở phần sau.
|
||||
|
||||
Cần lưu ý, Claude Code thường tiêu tốn rất nhiều token, nếu bạn lo ngại phí gọi API quá cao, có thể cân nhắc mua gói tháng của GLM (khoảng 20 tệ/tháng) để kiểm soát chi phí. Nếu muốn cảm nhận chi phí thực tế trước, cũng có thể nạp trước 10 tệ để thử nghiệm quy mô nhỏ.
|
||||
|
||||
Một cách khác là sử dụng dự án "Claude Code Route". Đây là một công cụ mã nguồn mở, không chỉ hỗ trợ tất cả giao diện gọi API phổ biến, mà còn cho phép bạn cấu hình tinh chỉnh mô hình sử dụng cho các kịch bản khác nhau, và hỗ trợ kết nối với mô hình lớn triển khai cục bộ. Nhưng do cấu hình phương án này khá phức tạp, khuyến nghị bạn bắt đầu từ phương án đầu tiên.
|
||||
|
||||
#### Sử dụng GLM Zhipu làm backend (khuyến nghị)
|
||||
|
||||
GLM (General Language Model) là một loạt mô hình ngôn ngữ lớn do Zhipu AI tự nghiên cứu và phát triển. GLM-4.6 là phiên bản mới nhất của dòng GLM hiện tại, điểm nổi bật cốt lõi là hiệu suất xuất sắc trong khả năng mã (đối sánh với Claude Sonnet 4 trong benchmark công khai và tác vụ thực tế, nằm ở top đầu trong nước).
|
||||
|
||||
|
||||
|
||||
Nó còn mở rộng cửa sổ ngữ cảnh lên 200K, có thể xử lý văn bản dài và mã quy mô lớn thoải mái hơn, đồng thời tăng cường khả năng suy luận và gọi công cụ, đạt được cân bằng tốt giữa hiệu suất và chi phí.
|
||||
|
||||
|
||||
|
||||
Trước khi kết nối GLM, chúng ta cần cài đặt Claude Code trước.
|
||||
|
||||
Nếu bạn thấy các bước cài đặt dòng lệnh phiền phức, hoặc gặp lỗi giữa chừng, có thể trực tiếp để Agent của Trae giúp bạn hoàn thành cài đặt.
|
||||
|
||||
```python
|
||||
# Cài đặt Claude Code
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
|
||||
# Vào dự án của bạn
|
||||
cd your-awesome-project
|
||||
|
||||
# Khởi động Claude Code
|
||||
claude
|
||||
|
||||
# Nhấn Ctrl+C để thoát Claude
|
||||
```
|
||||
|
||||
Tiếp theo, chúng ta cần sửa địa chỉ yêu cầu API mặc định của Claude Code, để nó hỗ trợ dịch vụ API của GLM. Bạn có thể trực tiếp sao chép nội dung dưới đây, để Trae giúp bạn tạo biến môi trường tương ứng; hoặc chọn ghi vĩnh viễn vào biến môi trường hệ thống (nếu có vấn đề, cũng có thể để Agent giúp sửa).
|
||||
|
||||
Đầu tiên, bạn cần lấy API Key của GLM, và lưu bằng cách bạn thấy tiện nhất.
|
||||
|
||||
Địa chỉ phiên bản trong nước: <https://bigmodel.cn/usercenter/proj-mgmt/apikeys>
|
||||
Địa chỉ phiên bản quốc tế: <https://z.ai/manage-apikey/apikey-list>
|
||||
|
||||
Nếu bạn sử dụng **phiên bản GLM trong nước**, vui lòng sử dụng cấu hình biến sau:
|
||||
|
||||
```python
|
||||
# Chạy lệnh sau trong Cmd
|
||||
# Lưu ý thay `your_zhipu_api_key` bằng API Key bạn vừa lấy
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zhipu_api_key
|
||||
setx ANTHROPIC_BASE_URL https://open.bigmodel.cn/api/anthropic
|
||||
```
|
||||
|
||||
Nếu bạn sử dụng **phiên bản GLM quốc tế**, vui lòng sử dụng cấu hình dưới đây:
|
||||
|
||||
```python
|
||||
# Chạy lệnh sau trong Cmd
|
||||
# Cũng lưu ý thay `your_zai_api_key`
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zai_api_key
|
||||
setx ANTHROPIC_BASE_URL https://api.z.ai/api/anthropic
|
||||
```
|
||||
|
||||
Bạn có thể nhập prompt tương tự như sau trực tiếp trong Trae:
|
||||
|
||||
⚠️ Nếu bạn cấu hình "biến môi trường vĩnh viễn" thông qua Trae, sau khi cấu hình xong **bắt buộc phải khởi động lại Trae**, nếu không biến môi trường trong terminal tích hợp của nó sẽ không cập nhật, có thể dẫn đến đăng nhập thất bại hoặc lỗi kết nối mạng.
|
||||
|
||||
```python
|
||||
Based on my environment variable settings:
|
||||
setx ANTHROPIC_AUTH_TOKEN your_zai_api_key
|
||||
setx ANTHROPIC_BASE_URL https://api.z.ai/api/anthropic
|
||||
|
||||
and my key(Replace it with your own key):
|
||||
681fea485851d29060cc.13gfaendggaFOhb
|
||||
|
||||
please help me configure and start Claude Code
|
||||
```
|
||||
|
||||
Bạn sẽ thấy đầu ra quy trình tương tự như dưới:
|
||||
|
||||
|
||||
|
||||
> 💡 Biến môi trường là gì?
|
||||
>
|
||||
> Biến môi trường về bản chất là một tập thông tin cấu hình "cặp key-giá trị" được lưu trữ trong hệ điều hành, thường tồn tại dưới dạng "tên biến = giá trị cụ thể". Miễn là cấu hình trước trong terminal hoặc cài đặt hệ thống, chương trình có thể đọc các biến này bất cứ lúc nào để lấy thông tin liên quan. Do biến môi trường có thể ghi trực tiếp trong terminal mà không cần sửa mã, chúng ta thường lưu key truy cập mô hình lớn trong biến môi trường để tránh rò rỉ. Chương trình chỉ cần đọc biến môi trường tương ứng để hoàn thành gọi mô hình lớn.
|
||||
>
|
||||
> Trong hệ thống Windows, ngoài việc dùng để lưu key truy cập mô hình lớn, biến môi trường còn thường dùng để lưu "đường dẫn gọi" của công cụ dòng lệnh.
|
||||
>
|
||||
> Chúng ta biết terminal bản thân cũng là một chương trình. Đôi khi chúng ta muốn khởi động một chương trình bên ngoài trong terminal, ví dụ nhập `claude` trong terminal để khởi động Claude Code. Lý do có thể nhập trực tiếp `claude` để chạy là vì terminal sẽ đọc biến môi trường hệ thống, trong đó biến PATH chứa thư mục nơi chứa tệp thực thi của Claude Code, nên terminal có thể tìm và thực thi nó (tương đương với việc dán đường dẫn tuyệt đối của chương trình đó vào terminal rồi nhấn Enter).
|
||||
>
|
||||
> Một biến môi trường điển hình có thể trông như: `PATH=C:\Windows\system32;C:\Program Files\Python`. Như vậy chúng ta có thể thực thi các chương trình này trong hệ thống ở bất kỳ đường dẫn nào, ví dụ trực tiếp gõ `python` trong dòng lệnh để khởi động trình thông dịch Python.
|
||||
>
|
||||
> Nếu bạn muốn xem biến môi trường hiện tại của hệ thống, có thể nhập "biến môi trường" trong tìm kiếm Windows, trong cửa sổ "Chỉnh sửa biến môi trường hệ thống" sẽ thấy tất cả các biến và giá trị của chúng. Có biến dùng để lưu key mô hình lớn, có biến dùng để thêm thư mục chương trình, tiện gọi tại bất kỳ đường dẫn nào.
|
||||
|
||||
Bây giờ, bạn có thể sử dụng GLM mới nhất để phát triển với Claude Code. Bạn có thể thử chạy lại một dự án đã làm trước đó, hoặc thử lại những tác vụ mà Trae chưa hoàn thành tốt, so sánh sự khác biệt trong trải nghiệm.
|
||||
|
||||
🎉 Việc "bắt đầu lại từ đầu" lặp đi lặp lại không phải lãng phí thời gian -- mỗi lần bạn làm lại, kỹ năng sẽ vững thêm một bậc.
|
||||
|
||||
Với cùng cách tiếp cận như GLM, bạn cũng có thể dễ dàng kết nối các giao diện tương thích định dạng Anthropic khác.
|
||||
|
||||
#### Sử dụng Kimi K2 làm backend (khuyến nghị)
|
||||
|
||||
Kimi K2 là mô hình ngôn ngữ lớn thế hệ mới do Moonshot AI ra mắt, thể hiện xuất sắc trong khả năng hiểu và tạo mã. Kimi K2 hỗ trợ cửa sổ ngữ cảnh siêu dài (tối đa 200K tokens), có thể dễ dàng xử lý kho mã lớn và dự án phức tạp.
|
||||
|
||||
**Ưu điểm cốt lõi:**
|
||||
|
||||
- **Ngữ cảnh siêu dài**: Hỗ trợ cửa sổ ngữ cảnh 200K, có thể xử lý toàn bộ mã dự án cùng lúc
|
||||
- **Khả năng mã mạnh**: Thể hiện xuất sắc trong tạo mã, tái cấu trúc và gỡ lỗi
|
||||
- **Hiểu tiếng Trung tốt**: Hiểu chính xác hơn nhu cầu lập trình tiếng Trung
|
||||
- **Gọi công cụ ổn định**: Hỗ trợ gọi hàm và sử dụng công cụ ổn định
|
||||
|
||||
**Lấy API Key:**
|
||||
|
||||
Truy cập <https://platform.moonshot.cn/console/account> đăng ký và lấy API Key.
|
||||
|
||||
**Phương pháp cấu hình:**
|
||||
|
||||
Tài liệu tham khảo: <https://platform.moonshot.cn/docs/guide/agent-support>
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=sk-YOURKEY
|
||||
```
|
||||
|
||||
#### Sử dụng Minimax làm backend (khuyến nghị)
|
||||
|
||||
Minimax là mô hình ngôn ngữ lớn thế hệ mới do MiniMax (Xi Yu Ke Ji) ra mắt, thể hiện xuất sắc trong tác vụ lập trình. Mô hình Minimax nổi tiếng với khả năng suy luận xuất sắc và chất lượng tạo mã, đặc biệt phù hợp với các kịch bản lập trình phức tạp.
|
||||
|
||||
**Ưu điểm cốt lõi:**
|
||||
|
||||
- **Khả năng suy luận mạnh**: Thể hiện xuất sắc trong suy luận logic phức tạp và thiết kế kiến trúc mã
|
||||
- **Chất lượng mã cao**: Mã tạo ra có cấu trúc rõ ràng, khả năng đọc tốt
|
||||
- **Hỗ trợ đa ngôn ngữ**: Hỗ trợ tạo và chuyển đổi mã bằng nhiều ngôn ngữ lập trình
|
||||
- **Tốc độ phản hồi nhanh**: Tốc độ phản hồi API nhanh, phù hợp kịch bản gọi tần suất cao
|
||||
|
||||
**Lấy API Key:**
|
||||
|
||||
Truy cập <https://platform.minimax.io/> đăng ký và lấy API Key.
|
||||
|
||||
**Phương pháp cấu hình:**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOUR_MINIMAX_API_KEY
|
||||
export ANTHROPIC_MODEL=MiniMax-M2.7
|
||||
```
|
||||
|
||||
#### Sử dụng DeepSeek làm backend (khuyến nghị)
|
||||
|
||||
DeepSeek là mô hình ngôn ngữ lớn mã nguồn mở do DeepSeek ra mắt, được nhà phát triển yêu thích nhờ khả năng mã xuất sắc và tỷ lệ giá cao. DeepSeek Coder được tối ưu hóa và huấn luyện đặc biệt cho các tác vụ lập trình.
|
||||
|
||||
**Ưu điểm cốt lõi:**
|
||||
|
||||
- **Khả năng mã nổi bật**: Thể hiện xuất sắc trong tạo mã, hiểu mã và sửa Bug
|
||||
- **Mã nguồn mở có thể tùy chỉnh**: Mô hình mã nguồn mở, có thể tinh chỉnh theo nhu cầu
|
||||
- **Tỷ lệ giá cao**: Giá API tương đối thấp, phù hợp sử dụng tần suất cao
|
||||
- **Hỗ trợ tiếng Trung tốt**: Hiểu chính xác kịch bản lập trình tiếng Trung
|
||||
|
||||
**Lấy API Key:**
|
||||
|
||||
Truy cập <https://platform.deepseek.com/usage> đăng ký và lấy API Key.
|
||||
|
||||
**Phương pháp cấu hình:**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOU_DEEPSEEK_API_KEY
|
||||
export API_TIMEOUT_MS=600000
|
||||
export ANTHROPIC_MODEL=deepseek-chat
|
||||
export ANTHROPIC_SMALL_FAST_MODEL=deepseek-chat
|
||||
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
|
||||
```
|
||||
|
||||
#### Sử dụng Volcano Engine Coding Plan làm backend (khuyến nghị)
|
||||
|
||||
Volcano Engine là nền tảng dịch vụ đám mây dưới trướng ByteDance, cung cấp dịch vụ mô hình AI cấp doanh nghiệp. Coding Plan của Volcano Engine được tối ưu hóa đặc biệt cho kịch bản lập trình, cung cấp khả năng tạo mã ổn định và hiệu quả.
|
||||
|
||||
**Ưu điểm cốt lõi:**
|
||||
|
||||
- **Ổn định cấp doanh nghiệp**: Cung cấp SLA, đảm bảo tính ổn định của dịch vụ
|
||||
- **Tối ưu hóa kịch bản mã**: Được tối ưu hóa đặc biệt cho tác vụ lập trình
|
||||
- **Lựa chọn mô hình phong phú**: Hỗ trợ nhiều mô hình, bao gồm Doubao-pro, Doubao-lite, v.v.
|
||||
- **Truy cập nhanh trong nước**: Triển khai nút trong nước, tốc độ truy cập nhanh
|
||||
|
||||
**Lấy API Key:**
|
||||
|
||||
Truy cập <https://console.volcengine.com/ark/region:ark+cn-beijing/apiKey> đăng ký và lấy API Key.
|
||||
|
||||
**Phương pháp cấu hình:**
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL=https://ark.volces.com/api/anthropic
|
||||
export ANTHROPIC_AUTH_TOKEN=YOUR_VOLCANO_API_KEY
|
||||
export ANTHROPIC_MODEL=doubao-pro-32k
|
||||
```
|
||||
|
||||
#### Các API tương thích Anthropic khác
|
||||
|
||||
Siliconflow:
|
||||
|
||||
```bash
|
||||
export ANTHROPIC_BASE_URL="https://api.siliconflow.cn/"
|
||||
export ANTHROPIC_MODEL="moonshotai/Kimi-K2-Instruct-0905" # Có thể tự sửa mô hình cần sử dụng
|
||||
export ANTHROPIC_API_KEY="YOUR_SILICONCLOUD_API_KEY" # Vui lòng thay API Key
|
||||
```
|
||||
|
||||
Aliyun DashScope (Aliyuncs): <https://help.aliyun.com/zh/model-studio/get-api-key>
|
||||
|
||||
```python
|
||||
export ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/apps/anthropic"
|
||||
export ANTHROPIC_API_KEY="YOUR_DASHSCOPE_API_KEY"
|
||||
```
|
||||
|
||||
::: details Sử dụng Claude Code Route làm backend (cách dùng nâng cao)
|
||||
|
||||
Ở trên chúng tôi đã giải thích cách sử dụng API chính thức GLM để thay thế giao diện Anthropic của Claude Code. Tiếp theo, hãy xem công cụ Claude Code Router giúp Claude Code thích ứng với nhiều mô hình API hơn như thế nào.
|
||||
|
||||
[Claude Code Router](https://github.com/musistudio/claude-code-router) là công cụ tăng cường định tuyến thông minh được thiết kế riêng cho Claude Code. Vai trò cốt lõi của nó là giúp người dùng phân phối yêu cầu AI đến các mô hình trên các nền tảng khác nhau theo nhu cầu, và có thể tùy chỉnh cao. Nó hỗ trợ kết nối hàng chục nền tảng, bao gồm OpenRouter, DeepSeek, Ollama, Gemini, v.v., cũng có thể định tuyến tác vụ đến mô hình cụ thể theo kịch bản, như GLM-4.5, Kimi-K2, Qwen3-Coder, v.v. Ví dụ, bạn có thể tự động giao tác vụ nền cho Ollama cục bộ để tiết kiệm chi phí; giao tác vụ văn bản dài/mã dài cho Gemini-2.5-Pro; giao giải thích mã cho DeepSeek.
|
||||
|
||||
|
||||
|
||||
Công cụ này còn cung cấp khả năng quản lý cấu hình UI/CLI thuận tiện, và thông qua "bộ chuyển đổi (converter)" thích ứng định dạng API của các nền tảng khác nhau. Nó hỗ trợ tích hợp tự động như GitHub Actions và mở rộng tùy chỉnh, giải quyết vấn đề "một mô hình không thể bao phủ tất cả kịch bản" và "chuyển đổi nền tảng thường xuyên rất phiền", giúp người dùng sử dụng công cụ AI linh hoạt và tiết kiệm hơn.
|
||||
|
||||
|
||||
|
||||
Dưới đây chúng tôi giới thiệu đơn giản cách cài đặt Claude Code Router. Khoảng cần các bước sau (cũng có thể để Trae giúp bạn thực thi), để chuẩn bị môi trường liên quan:
|
||||
|
||||
```markdown
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
npm install -g @musistudio/claude-code-router
|
||||
```
|
||||
|
||||
Sau khi cài đặt, bạn cần xác nhận cục bộ có thể sử dụng lệnh `ccr`. Nếu thấy đầu ra tương tự như dưới, tức là cài đặt thành công:
|
||||
|
||||
|
||||
|
||||
Tiếp theo, có hai cách để khởi tạo và cấu hình mô hình:
|
||||
|
||||
- Sử dụng UI tích hợp của CCR, mở trang cấu hình nó cung cấp trong trình duyệt để thao tác;
|
||||
- Trực tiếp sửa tệp cấu hình mặc định của CCR (về bản chất UI cũng đang sửa tệp cấu hình, chỉ cung cấp giao diện trực quan hơn).
|
||||
|
||||
Nếu chọn sử dụng CCR UI, bạn sẽ thấy giao diện tương tự như dưới:
|
||||
|
||||
|
||||
|
||||
Lúc này nhấp vào nút "Add Provider", sẽ thấy giao diện như dưới. Bạn cần:
|
||||
|
||||
1. Nhập tên nhà cung cấp mô hình trong Name;
|
||||
2. Nhập địa chỉ giao diện OpenAI tương thích của nhà cung cấp đó trong API Full URL;
|
||||
3. Nhập API Key của nền tảng tương ứng trong API Key;
|
||||
4. Nhập tên mô hình trong vùng Models, nhấp "Add Model" để thêm;
|
||||
5. Cuối cùng nhấp "Save" để lưu cấu hình.
|
||||
|
||||
(Cuộn xuống giao diện còn nhiều tùy chọn nâng cao, nhưng hiện tại bạn có thể bỏ qua trước.)
|
||||
|
||||
|
||||
|
||||
Dưới đây là ví dụ cấu hình DeepSeek và Kimi:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sau khi lưu cấu hình mô hình, còn cần chỉ định mô hình mặc định (Default) trong vùng Router bên phải. Nhấp vào dropdown tương ứng, đặt thành `kimi` (khuyến nghị), sau đó nhấp `Save and Restart` ở góc phải phía trên.
|
||||
|
||||
|
||||
|
||||
Sau đó, chỉ cần nhập `ccr code` trong terminal, là có thể khởi động quy trình lập trình Claude Code thông qua Claude Code Router.
|
||||
|
||||
|
||||
|
||||
:::
|
||||
|
||||
#### Cách dùng nâng cao của Claude Code
|
||||
|
||||
Nhiều người khi mới bắt đầu sử dụng Claude Code chỉ dùng nó như công cụ hội thoại thông thường. Nhưng thực tế, nó tích hợp nhiều khả năng phong phú, giúp bạn sử dụng hiệu quả và linh hoạt hơn. Dưới đây là một số lệnh và cách dùng phổ biến:
|
||||
|
||||
Tài liệu tham khảo:
|
||||
|
||||
<https://docs.claude.com/en/docs/claude-code/cli-reference>
|
||||
<https://docs.claude.com/en/docs/claude-code/slash-commands>
|
||||
|
||||
| Lệnh | Vai trò | Ví dụ |
|
||||
| ----------------- | ----------------------------------------- | ---------------------------------------- |
|
||||
| claude | Khởi động chế độ tương tác | `claude` |
|
||||
| claude "query" | Thực thi tác vụ một lần và xuất kết quả | `claude "explain this project"` |
|
||||
| claude -p "query" | Thực thi câu hỏi một lần và tự động thoát sau khi kết thúc | `claude -p "explain this function xxxx"` |
|
||||
| claude -c | Tiếp tục phiên gần nhất | `claude -c` |
|
||||
| claude -r | Khôi phục phiên trước | `claude -r` |
|
||||
| /resume | Chuyển về phiên trước trong cuộc trò chuyện hiện tại | `claude -c`, `/resume` |
|
||||
| /plugin | Quản lý plugin, có thể cài đặt mở rộng năng lực commit và xem xét | `/plugin` |
|
||||
| /init | Khởi tạo mô tả dự án với CLAUDE.md | `/init` |
|
||||
| /clear | Xóa ngữ cảnh phiên hiện tại, tránh quá tải thông tin | `/clear` |
|
||||
| /compact | Nén lịch sử phiên, giảm chiếm dụng token ngữ cảnh | `/compact` |
|
||||
| /cost | Xem chi tiêu hiện tại | `/cost` |
|
||||
| /model | Chuyển đổi mô hình sử dụng (khi dùng API tương thích thường có thể bỏ qua) | `/model` |
|
||||
| /memory | Quản lý tệp nhớ CLAUDE.md | |
|
||||
| /help | Hiển thị danh sách lệnh có sẵn | `/help` |
|
||||
| exit or Ctrl+C | Thoát Claude Code | `exit` hoặc `Ctrl+C` |
|
||||
| /agents | Chức năng nâng cao, sẽ giải thích ở phần sau | |
|
||||
| /mcp | Chức năng nâng cao, sẽ giải thích ở phần sau | |
|
||||
|
||||
**CLAUDE.md**
|
||||
|
||||
Tham khảo: <https://www.anthropic.com/engineering/claude-code-best-practices>
|
||||
|
||||
`CLAUDE.md` là tệp đặc biệt mà Claude sẽ tự động đọc và thêm vào ngữ cảnh khi bắt đầu hội thoại. Do đó, nó rất phù hợp để ghi lại:
|
||||
|
||||
- Các lệnh bash thường dùng
|
||||
- Các tệp và hàm công cụ cốt lõi
|
||||
- Quy ước phong cách mã
|
||||
- Mô tả cách kiểm thử
|
||||
- Quy ước hợp tác kho (ví dụ quy tắc đặt tên nhánh, dùng merge hay rebase, v.v.)
|
||||
- Mô tả cấu hình môi trường phát triển (ví dụ có dùng pyenv không, khuyến nghị trình biên dịch nào, v.v.)
|
||||
- Các điểm cần đặc biệt lưu ý trong dự án hoặc dễ gặp lỗi
|
||||
- Bất kỳ thông tin nào bạn muốn Claude "nhớ"
|
||||
|
||||
`CLAUDE.md` bản thân không có yêu cầu định dạng bắt buộc, miễn là ngắn gọn, dễ đọc cho con người. Ví dụ:
|
||||
|
||||
```
|
||||
# Bash commands
|
||||
- npm run build: Build the project
|
||||
- npm run typecheck: Run the typechecker
|
||||
|
||||
# Code style
|
||||
- Use ES modules (import/export) syntax, not CommonJS (require)
|
||||
- Destructure imports when possible (eg. import { foo } from 'bar')
|
||||
|
||||
# Workflow
|
||||
- Be sure to typecheck when you're done making a series of code changes
|
||||
- Prefer running single tests, and not the whole test suite, for performance
|
||||
```
|
||||
|
||||
#### Nguyên lý hoạt động nội bộ của Claude Code
|
||||
|
||||
Tham khảo: <https://github.com/shareAI-lab/analysis_claude_code>
|
||||
|
||||
Nếu bạn tò mò tại sao Claude Code hữu dụng hơn các công cụ Agent lập trình như Trae hoặc Cursor trong nhiều kịch bản, chúng ta có thể xem đơn giản cơ chế hoạt động nội bộ của nó.
|
||||
|
||||
Các công cụ lập trình AI CLI khác cũng có cách triển khai tổng thể tương tự.
|
||||
|
||||
|
||||
|
||||
Claude Code sẽ phân giải tác vụ lập trình thành một vòng lặp "cảm nhận--suy nghĩ--hành động--xác minh" liên tục, và trong đó gọi các công cụ khác nhau để hoàn thành tác vụ. Nó mô phỏng quy trình làm việc của nhà phát triển: liên tục "viết mã -> chạy -> xem kết quả -> cải tiến". Hệ thống nội bộ liên tục thực hiện các bước thông qua vòng lặp tác vụ chính, trong mỗi vòng, Claude đều có thể gọi các công cụ khác nhau -- ví dụ đọc ghi tệp, thực thi lệnh, tìm kiếm mã, v.v. -- sau đó dựa trên kết quả thực tế trả về từ công cụ để quyết định hành động tiếp theo.
|
||||
|
||||
Trong đó có một số đặc tính chính đáng chú ý:
|
||||
|
||||
- **Xử lý luồng (Stream Processing)**: Claude có thể vừa suy nghĩ vừa xuất kết quả, thay vì phải đợi tất cả mã viết xong mới thực thi.
|
||||
- **Nén thông minh (Intelligent Compression)**: Hội thoại dài dễ dẫn đến ngữ cảnh quá dài, Claude giảm xác suất "quên" bằng cách nén lịch sử thành thông tin chính, và đảm bảo vận hành hiệu quả thông qua việc phân biệt trí nhớ ngắn hạn và dài hạn.
|
||||
- **Kiểm soát đồng thời (Concurrency Control)**: Thiết kế song song nội bộ cho phép nhiều tác vụ tiến hành đồng thời, không can thiệp lẫn nhau.
|
||||
- **Quản lý Agent con (Sub-agent Management)**: Trong công việc thực tế không chỉ tương đương với một "vai trò" xử lý tất cả mọi việc, bạn có thể quản lý nhiều Agent con phối hợp xử lý mã, mỗi Agent chịu trách nhiệm các tác vụ khác nhau, ví dụ chuyên trách kiểm thử, chuyên trách viết tài liệu, v.v.
|
||||
|
||||
### Codex
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Tương tự như Claude Code, Codex là công cụ lập trình AI do OpenAI phát triển, bạn có thể hiểu nó là "phiên bản OpenAI của Claude Code". Ưu điểm lớn nhất của nó là khả năng thích ứng hiệu quả với GPT-5.
|
||||
|
||||
Từ trải nghiệm thực tế, GPT-5 hiện tại phản hồi nhanh hơn, tỷ lệ lỗi thấp hơn (xác suất hoàn thành đúng trong tác vụ phức tạp nhiều vòng cao hơn). Một nhược điểm của nó là giải thích thường thiên về "học thuật" và "kỹ thuật", đôi khi quá nghiêm ngặt, lượng thông tin lớn, đối với người mới bắt đầu có thể hơi khó hiểu.
|
||||
|
||||
Bạn có thể cài đặt Codex thông qua lệnh dưới:
|
||||
|
||||
```
|
||||
npm i -g @openai/codex
|
||||
```
|
||||
|
||||
#### Sử dụng API chính thức OpenAI làm backend
|
||||
|
||||
Nếu trực tiếp sử dụng cổng Codex chính thức của OpenAI, cấu hình sẽ rất đơn giản: sau khi bạn đã đăng ký gói đăng ký OpenAI hoặc được cấp hạn mức API tương ứng, chỉ cần nhập `codex` trong dòng lệnh để khởi động chương trình, và hoàn thành đăng nhập theo hướng dẫn.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Sử dụng cách chuyển tiếp API OpenAI làm backend
|
||||
|
||||
Do API OPENAI chính thức có thể có giá cao, yêu cầu mạng khắt khe và các vấn đề khác, để tránh các hạn chế này, chúng ta cũng có thể thông qua dịch vụ cổng API bên thứ ba khác để chuyển tiếp gọi.
|
||||
|
||||
Với cách này, chúng ta chỉ cần mua hạn mức Codex API tương ứng trên nền tảng chuyển tiếp bên thứ ba, là có thể nhận được trải nghiệm sử dụng gần với OpenAI Codex gốc.
|
||||
|
||||
Tham khảo: <https://open-dev.feishu.cn/wiki/PAqUwWG4IiuwTvkQ2sGcaQuPnXc>
|
||||
Địa chỉ nạp tiền: <https://api.zyai.online/account/topup/recharge>
|
||||
|
||||
Cần lưu ý, sau khi lấy token hạn mức, chúng ta còn cần cấu hình API Key cục bộ.
|
||||
|
||||
Trong cài đặt nhóm key, cần lưu ý chọn mục chuyên dùng cho Codex.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta cần điền Key đã lấy vào prompt dưới đây, và đưa toàn bộ prompt cho Trae, để nó giúp bạn hoàn thành toàn bộ quá trình cấu hình:
|
||||
|
||||
````bash
|
||||
My API key is: [Paste your obtained sk-xxxxx key here]
|
||||
|
||||
Please help me complete the following configuration tasks:
|
||||
|
||||
1. Create configuration directory
|
||||
- Create a `.codex` folder under my user directory
|
||||
- Windows path should be: `C:\Users\[My Username]\.codex`
|
||||
2. Backup existing configuration (if exists)
|
||||
- Check if `.codex\config.toml` exists
|
||||
- If it exists, rename it to `config.toml.bak.[current timestamp]` (timestamp format: yyyyMMddHHmmss)
|
||||
3. Create configuration file
|
||||
- Create `config.toml` in the `.codex` directory
|
||||
- Write the following complete content:
|
||||
```toml
|
||||
preferred_auth_method = "apikey"
|
||||
|
||||
[model_providers.myrelay]
|
||||
name = "My Relay Station"
|
||||
base_url = "https://api.zyai.online/v1"
|
||||
env_key = "MYRELAY_API_KEY"
|
||||
wire_api = "responses"
|
||||
request_max_retries = 4
|
||||
stream_max_retries = 10
|
||||
stream_idle_timeout_ms = 300000
|
||||
|
||||
[profiles.myrelay]
|
||||
model_provider = "myrelay"
|
||||
model = "gpt-5"
|
||||
model_reasoning_effort = "medium"
|
||||
|
||||
[tools]
|
||||
web_search = true
|
||||
|
||||
4. Set system environment variable
|
||||
Variable name: MYRELAY_API_KEY
|
||||
Variable value: The key I gave you
|
||||
|
||||
5. Confirm completion and report back:
|
||||
|
||||
The full path of the configuration file
|
||||
Whether the environment variable was set successfully
|
||||
I can use the command `codex --profile myrelay` to run it
|
||||
````
|
||||
|
||||
Sau khi cấu hình xong, bạn có thể khởi động Codex sử dụng API chuyển tiếp thông qua `codex --profile myrelay`. Cách sử dụng sau đó tương tự như Claude Code: chỉ cần nhập suy nghĩ và nhu cầu của bạn vào ô hội thoại bất kỳ lúc nào.
|
||||
|
||||
### OpenCode
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
OpenCode là một nền tảng AI Coding Agent mã nguồn mở dành cho nhà phát triển, định vị tương tự như "phiên bản Claude Code đa mô hình". Nó lấy Terminal làm cổng tương tác cốt lõi, đồng thời hỗ trợ tích hợp trình soạn thảo (như VS Code, Neovim, v.v.), có thể truy cập sâu kho mã cục bộ, và hoàn thành toàn bộ quy trình phát triển từ hiểu mã đến thực thi kỹ thuật thông qua ngôn ngữ tự nhiên.
|
||||
|
||||
Nó không phải công cụ lập trình AI gắn với một mô hình duy nhất, mà là một nền tảng AI Coding Agent mở có thể tự do chuyển đổi GPT, Claude, Gemini và thậm chí mô hình cục bộ. Ngay cả OpenAI chính thức cũng hỗ trợ OpenCode kết nối Codex/OpenAI subscription.
|
||||
|
||||
|
||||
|
||||
Bạn có thể cài đặt OpenCode thông qua lệnh dưới:
|
||||
|
||||
```bash
|
||||
# Linux / Unix
|
||||
curl -fsSL https://opencode.ai/install | bash
|
||||
|
||||
# Windows
|
||||
npm i -g opencode-ai
|
||||
```
|
||||
|
||||
#### Sử dụng mô hình miễn phí trong OpenCode
|
||||
|
||||
Trong OpenCode thỉnh thoảng sẽ có mô hình miễn phí để sử dụng, cấu hình cũng rất đơn giản. Bạn có thể nhập `opencode` tại vị trí cần sử dụng OpenCode trong dòng lệnh để khởi động chương trình OpenCode vào bảng điều khiển trò chuyện. Nhập lệnh `/models` tìm kiếm từ khóa free là có thể thấy các mô hình miễn phí có chữ free.
|
||||
|
||||
|
||||
|
||||
Thông thường mô hình miễn phí hoàn thành tác vụ lập trình sẽ chậm hơn so với mô hình trả phí/đăng ký, điều này thường phụ thuộc vào việc đường truyền mô hình có bị tắc nghẽn hay không, có phải giai đoạn cao điểm lập trình hay không và năng lực bản thân của mô hình.
|
||||
|
||||
#### Sử dụng mô hình bên thứ ba làm mô hình lập trình chính của OpenCode
|
||||
|
||||
Đây là ưu điểm cốt lõi của OpenCode, nó có thể cho phép bạn tự do chuyển đổi mô hình trong khi sử dụng cùng MCP, Skills, ngữ cảnh để hoàn thành các tác vụ lập trình khác nhau. Phần dưới lấy GPT-5.3 Codex chính thức của OpenAI làm ví dụ, kết nối OpenCode làm mô hình lập trình chính.
|
||||
|
||||
Nhập lệnh `/connect` trong cửa sổ trò chuyện của OpenCode, chọn chỉ thị đầu tiên phù hợp nhất nhấn enter, là có thể tiến hành chọn xác thực ủy quyền nhà cung cấp mô hình bên thứ ba.
|
||||
|
||||
|
||||
|
||||
Ở đây chọn OpenAI làm ví dụ, nhấn enter để chọn phương thức xác thực.
|
||||
|
||||
|
||||
|
||||
Chọn loại nào cũng được, chỉ là phương thức xác thực khác nhau. Ở đây chọn loại đầu tiên để đăng nhập qua trình duyệt.
|
||||
|
||||
|
||||
|
||||
Sao chép liên kết này vào trình duyệt để thực hiện đăng nhập OpenAI bình thường, sau khi trình duyệt hiển thị Authorization Successful, client OpenCode sẽ tự động chuyển đến giao diện chọn mô hình OpenAI.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Cài đặt plugin Oh My OpenAgent
|
||||
|
||||
Điểm mạnh của OpenCode còn nằm ở cộng đồng sinh thái rất năng động, bạn có thể tìm thấy rất nhiều plugin liên quan đến OpenCode trên Github. Nếu nói OpenCode là một công cụ lập trình AI có thể chuyển đổi mô hình tùy ý, thì Oh-My-OpenAgent là một "hệ thống chỉ huy lập trình AI đa Agent" chạy trên OpenCode. Nó có thể phân giải một tác vụ phức tạp thành nhiều sub-task giao cho các mô hình khác nhau, mỗi mô hình đảm nhận phần việc riêng.
|
||||
|
||||
|
||||
|
||||
Bạn có thể sao chép đoạn văn bản dưới đây và dán cho mô hình đã cấu hình trong OpenCode để cài đặt OpenCode.
|
||||
|
||||
```text
|
||||
Install and configure oh-my-openagent by following the instructions here:
|
||||
https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md
|
||||
```
|
||||
|
||||
Dưới đây là các tính năng và mô tả chức năng của Oh-My-OpenAgent.
|
||||
|
||||
| Tính năng | Mô tả chức năng |
|
||||
| :-------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| **Discipline Agents** | Sisyphus chịu trách nhiệm điều phối Hephaestus, Oracle, Librarian và Explore. Một đội phát triển AI hoàn chỉnh hoạt động song song. |
|
||||
| **Team Mode** (v4.0, bật tùy chọn) | Leader Agent + tối đa 8 thành viên song song, trực quan hóa tmux thời gian thực, họ công cụ `team_*` chuyên dụng. Điều khiển `hyperplan`(5 người bình luận đối lập) và `security-research`(3 thợ săn + 2 kỹ sư PoC). [Tài liệu ->](docs/guide/team-mode.md) |
|
||||
| **`ultrawork` / `ulw`** | Một chạm kích hoạt, tất cả agent xuất kích. Không bỏ cuộc cho đến khi tác vụ hoàn thành. |
|
||||
| **[IntentGate](https://factory.ai/news/terminal-bench)** | Phân tích ý định thực sự của người dùng trước khi hành động thực sự. Tạm biệt vĩnh viễn lời vô nghĩa AI bị hiểu sai theo nghĩa đen. |
|
||||
| **Công cụ chỉnh sửa dựa trên hash** | Mỗi lần sửa đều xác minh hash nội dung qua `LINE#ID`, tỷ lệ sửa sai 0%. Cảm hứng từ [oh-my-pi](https://github.com/can1357/oh-my-pi). [The Harness Problem ->](https://blog.can.ac/2026/02/12/the-harness-problem/) |
|
||||
| **LSP + AST-Grep** | Đổi tên cấp workspace, chẩn đoán trước build, viết lại dựa trên AST. Cung cấp cho Agent độ chính xác cấp IDE. |
|
||||
| **Agent nền** | Đồng thời phóng 5+ chuyên gia làm việc song song. Giữ ngữ cảnh sạch, lấy kết quả bất cứ lúc nào. |
|
||||
| **MCP tích hợp** | Exa (tìm kiếm web), Context7 (tài liệu chính thức), Grep.app (tìm kiếm mã nguồn GitHub). Bật mặc định. |
|
||||
| **Ralph Loop / `/ulw-loop`** | Vòng lặp tự tham chiếu. Không dừng lại cho đến khi đạt 100% hoàn thành. |
|
||||
| **Thực thi Todo bắt buộc** | Agent muốn lười biếng? Hệ thống trực tiếp kéo cổ áo lôi về. Tác vụ của bạn, bắt buộc phải hoàn thành. |
|
||||
| **Người kiểm tra comment** | Loại bỏ comment dư thừa có mùi AI mạnh. Mã viết ra như kỹ sư cao cấp lão luyện. |
|
||||
| **Tích hợp Tmux** | Hỗ trợ terminal tương tác hoàn chỉnh. Chạy REPL, dùng debugger, dùng công cụ TUI, tất cả trong phiên thời gian thực. |
|
||||
| **Tương thích Claude Code** | Hooks, lệnh, skills, MCP và plugin hiện có của bạn? Tất cả có thể di chuyển liền mạch. |
|
||||
| **MCP nhúng trong Skills** | Skills tự mang MCP server cần thiết. Bật theo nhu cầu, không làm phồng cửa sổ ngữ cảnh của bạn. |
|
||||
| **Prometheus Planner** | Lập kế hoạch chiến lược tốt trước khi viết mã, thông qua chế độ phỏng vấn. |
|
||||
| **`/init-deep`** | Tự động tạo `AGENTS.md` trong toàn bộ cấp thư mục dự án. Không chỉ tiết kiệm Token, mà còn nâng cao đáng kể khả năng hiểu của Agent. |
|
||||
|
||||
Sisyphus (claude-opus-4-7 / kimi-k2.6 / glm-5.1) là chỉ huy chính của bạn. Nó chịu trách nhiệm lập kế hoạch, phân bổ tác vụ cho đội ngũ chuyên gia, và thúc đẩy tác vụ đến hoàn thành với chiến lược song song cực kỳ tích cực. Nó không bao giờ bỏ cuộc giữa chừng.
|
||||
|
||||
Hephaestus (gpt-5.5) là người làm sâu tự chủ của bạn. Bạn chỉ cần đưa cho nó mục tiêu, không cần chỉ cách cụ thể. Nó sẽ tự động khám phá các pattern trong kho mã, thực thi tác vụ độc lập từ đầu đến cuối, tuyệt đối không cần bạn phải giám sát. Đúng như tên gọi, một người thợ thủ công thực thụ.
|
||||
|
||||
Prometheus (claude-opus-4-7 / kimi-k2.6 / glm-5.1) là nhà lập kế hoạch chiến lược của bạn. Thông qua chế độ phỏng vấn, trước khi viết một dòng mã nào, nó sẽ xác định phạm vi và xây dựng kế hoạch thực thi chi tiết thông qua việc đặt câu hỏi.
|
||||
|
||||
Sau khi hiểu xong những điều này, bạn có thể sử dụng OpenCode đã cài đặt plugin Oh-My-OpenAgent để hoàn thành các tác vụ lập trình.
|
||||
|
||||
## Thêm cách dùng công cụ lập trình AI CLI
|
||||
|
||||
### Dùng AI viết tài liệu yêu cầu: Học "cụ thể hóa nhu cầu"
|
||||
|
||||
Đối với mô hình ngôn ngữ lớn, nhu cầu trừu tượng cần được "cụ thể hóa". Ví dụ: "Tôi đói" là một nhu cầu trừu tượng, chúng ta cần biến nó thành: "Tôi hơi đói, có thể cần ăn một bánh mì đậu đỏ, thêm một ly sữa đậu nành." -- Đây mới là một nhu cầu cụ thể có thể thực thi.
|
||||
|
||||
Nhưng biến nhu cầu trừu tượng thành cụ thể, thực ra là một quá trình rất tốn sức. Nếu chúng ta chưa thấy đủ nhiều ví dụ, rất khó nhanh chóng liên tưởng đến cách phân giải vấn đề trừu tượng thành các module chi tiết. Lúc này, cách tốt nhất là để AI giúp bạn hoàn thành bước "cụ thể hóa".
|
||||
Ví dụ, tôi muốn phát triển một ứng dụng "kế hoạch hàng ngày", suy nghĩ đơn giản nhất có thể là:
|
||||
|
||||
`Please help me write a daily planning app where I can write my plans each day and get reminders.`
|
||||
|
||||
AI thực sự có thể phân giải tác vụ dựa trên nhu cầu này, rồi hoàn thành từng bước, nhưng dễ sai hoặc hiểu sai giữa chừng. Để giảm rủi ro, chúng ta có thể để AI giúp chúng ta mở rộng nhu cầu trước:
|
||||
|
||||
`Based on my needs, please elaborate and provide a more detailed Product Requirement Document for reference. My idea is: Please help me write a daily planner app that supports daily plan-writing and provides reminders.`
|
||||
|
||||
Lúc này, AI có thể đưa ra PRD hoàn chỉnh tương tự như dưới:
|
||||
|
||||
```
|
||||
Product Requirements Document (PRD): "Today's Plan" App
|
||||
Document Version: 1.0
|
||||
Creation Date: October 27, 2023
|
||||
Author: (Your Name/Product Manager)
|
||||
|
||||
1. Product Introduction
|
||||
1.1 Product Name
|
||||
Today's Plan
|
||||
1.2 Product Vision
|
||||
"Today's Plan" is a minimalist and highly efficient daily planning and reminder tool, dedicated to helping users eliminate procrastination and forgetfulness, plan every day clearly, and ensure tasks are carried out through an intelligent reminder system—ultimately enabling users to gain a stronger sense of control and achievement over their time.
|
||||
1.3 Target Users (User Personas)
|
||||
We mainly serve three types of users:
|
||||
Students (Xiao Ming):
|
||||
Characteristics: Multiple tasks such as courses, assignments, club activities, exam prep, needing organized time arrangement.
|
||||
Pain Points: Easily forget small tasks or assignment deadlines; feel overwhelmed switching between tasks; want to build regular study and life habits.
|
||||
Needs: A simple tool to list daily to-dos and provide reminders before class/self-study.
|
||||
Office Workers (Zhang Wei):
|
||||
Characteristics: Fast-paced work, many meetings, reports, project milestones, and personal affairs (fitness, picking up children).
|
||||
Pain Points: Easily forget important meetings or work milestones; get interrupted by urgent tasks and forget the original plan; feel busy but inefficient at end of day.
|
||||
Needs: Need a tool to quickly record and schedule daily work and send strong reminders at key times (e.g., 15 minutes before meetings).
|
||||
Freelancers/Self-disciplined Seekers (Li Na):
|
||||
Characteristics: High freedom of time, but strong self-management required for work output and personal growth.
|
||||
Pain Points: Easily procrastinate, lack external supervision; start the day without a clear plan, leading to low time utilization.
|
||||
Needs: Need a tool to help build a daily fixed routine (Morning Routine) and review daily achievements for positive feedback.
|
||||
|
||||
2. User Stories
|
||||
As a user, I want to quickly create today's plan list so I have an overview of all my tasks for the day.
|
||||
As a user, I want to set specific start and end times for each task so I can create a visual timeline.
|
||||
As a user, I want to receive push notification reminders before a task starts so I won't miss any important arrangements.
|
||||
As a user, I want to customize the reminder time (such as 5, 15, or 60 minutes in advance) so reminders better fit my habits.
|
||||
As a user, I want to easily mark completed tasks so I can feel accomplished and clearly see my progress.
|
||||
As a user, I want to see a summary of my completed plans at the end of each day for reviewing and self-motivation.
|
||||
As a user, I want to conveniently edit and delete tasks to handle last-minute changes.
|
||||
As a user, I want to view plans and achievements from previous days to review my efficiency and habits.
|
||||
|
||||
3. Feature Breakdown
|
||||
Core Features (MVP - Minimum Viable Product)
|
||||
Module 1: Plan Management
|
||||
3.1.1 Daily Plan Homepage
|
||||
Interface: "Today" as the core view, current date shown at the top.
|
||||
View: Timeline list, clearly showing tasks scheduled from morning to evening. Tasks without a time can be listed in the top or bottom "To-do List" section.
|
||||
Interactions:
|
||||
Click the "+" button in the bottom right to quickly create a new task.
|
||||
Pull down to refresh the page.
|
||||
Swipe left/right to view yesterday's and tomorrow's plans.
|
||||
3.1.2 Create/Edit Task
|
||||
Entry: Click "+" on the homepage or a time slot in the list.
|
||||
Fields:
|
||||
Task title (required): Briefly describe the task, e.g., "10 AM Weekly Product Meeting."
|
||||
Task time (optional):
|
||||
Set "start time" and "end time."
|
||||
Provide "all-day" option for unspecified time tasks.
|
||||
Default time picker should be quick and convenient.
|
||||
Reminder setting (required, with default value): See Module 2.
|
||||
Notes (optional): Add further descriptions, links, or location info.
|
||||
Actions: Save, cancel, delete task.
|
||||
3.1.3 Task Interaction
|
||||
Mark as complete: Checkbox before each task; checking adds a strikethrough and gray background, indicating completion. Can unmark if needed.
|
||||
Edit task: Click the task itself to enter edit page.
|
||||
Delete task: Swipe left on a task to reveal "Delete" button.
|
||||
Module 2: Smart Reminder System
|
||||
3.2.1 Reminder Trigger
|
||||
Mechanism: Based on task's set "start time" and the user's "reminder lead time," send a push notification from device.
|
||||
Offline Support: Locally scheduled reminders must trigger even if user is offline.
|
||||
3.2.2 Reminder Content & Format
|
||||
Notification title: App name "Today's Plan."
|
||||
Body: "Reminder: [Task Title] will start at [Start Time]." E.g., "Reminder: Product Meeting will start at 10:00."
|
||||
Sound: Use system default or offer several simple, effective tones.
|
||||
3.2.3 Reminder Settings
|
||||
Global Settings (in Settings page):
|
||||
User can set a default reminder time, e.g., "15 minutes before task starts." New tasks adopt this by default.
|
||||
Single Task Settings (in create/edit page):
|
||||
Users can override global settings for important tasks, choosing specific reminder times like "on time," "5 minutes early," "30 minutes early," or "1 hour early."
|
||||
Provide "no reminder" option.
|
||||
Subsequent Features (V1.1, V2.0)
|
||||
3.3 Daily Review & Statistics
|
||||
Push a summary notification at a set time every night (e.g., 22:00): "How was your day? Take a look at your achievements!"
|
||||
Generate a simple daily report card: shows total planned tasks, completed tasks, completion rate, plus an encouraging message.
|
||||
3.4 History Review
|
||||
Calendar view to click on any past day and check its plans and completion status. Days with high completion rates marked with a special color.
|
||||
3.5 Templates
|
||||
Allow users to save a successful daily plan as a template, e.g., "Efficient Workday," "Relaxing Weekend."
|
||||
When creating tomorrow's plan, one-click import a template, modify slightly to save time.
|
||||
3.6 Themes & Personalization
|
||||
Offer dark mode.
|
||||
Allow changing several primary color themes.
|
||||
|
||||
4. Non-Functional Requirements
|
||||
4.1 Performance
|
||||
Response: App launch time under 2 seconds; adding/editing tasks must be smooth and lag-free.
|
||||
Resource Use: Low battery and memory consumption in background; do not over-consume resources waiting for reminders.
|
||||
4.2 Usability
|
||||
Minimal & intuitive: UI must be minimal, primary functions accessible within 3 clicks. No tutorial needed for new users.
|
||||
Error tolerance: Offer undo (e.g. brief undo after mistakenly deleting a task).
|
||||
4.3 Reliability
|
||||
Reliable reminders: Reminder function is the product's lifeline; must guarantee 99.99% timely and accurate delivery.
|
||||
Data loss-free: User plans must be reliably stored locally. Future versions can support cloud sync to prevent data loss on device change.
|
||||
4.4 Compatibility
|
||||
Platform: Support major iOS and Android versions (latest 3-4 releases).
|
||||
Screen: Layout must fit various phone screen sizes.
|
||||
|
||||
5. Roadmap
|
||||
V1.0 (MVP):
|
||||
Goal: Validate core value—planning & reminders.
|
||||
Features: Complete all "Core Features" described above (Plan management, smart reminders).
|
||||
V1.1 (Quick Optimization):
|
||||
Goal: Improve retention and achievement.
|
||||
Features: Add "Daily Review & Statistics," "History Review."
|
||||
V2.0 (Enhanced Experience):
|
||||
Goal: Increase efficiency and personalization.
|
||||
Features: Add "Templates," "Themes & Personalization," and start developing "Cloud Sync."
|
||||
```
|
||||
|
||||
So với câu "giúp tôi viết một ứng dụng có thể ghi kế hoạch và nhắc nhở mỗi ngày" ban đầu, tài liệu này đã chi tiết hơn rất nhiều. Bạn có thể thêm bớt sửa đổi theo nhu cầu thực tế; đối với một số module bạn chưa chắc chắn, cũng có thể tiếp tục để AI cung cấp thêm phương án dự phòng, bạn chọn và gộp thành phiên bản cuối cùng.
|
||||
|
||||
Thông qua cách này, chúng ta có thể rất dễ dàng biến ý tưởng trừu tượng thành mô tả cụ thể. Đối với phát triển AI, "cụ thể" chính là năng suất: nhu cầu càng cụ thể, càng dễ nhận được dự án có cấu trúc ổn định, chất lượng cao. Bạn có thể thử dùng cách này làm lại một dự án nhỏ trước đó, so sánh sự khác biệt về hiệu quả.
|
||||
|
||||
Nếu bạn thấy loại "prompt nhu cầu" này quá dài, một cách rất tự nhiên là viết nó vào một tài liệu markdown riêng, làm "tài liệu nhu cầu / tài liệu phát triển / PRD" của bạn. Sau đó mỗi lần để AI viết dự án, chỉ cần để nó "tham khảo tài liệu này", thay vì gõ lại dài dòng mỗi lần. Bạn cũng có thể liên tục hoàn thiện tài liệu này trong quá trình lặp, để các dự án sau trực tiếp hưởng lợi.
|
||||
|
||||
Dưới đây là một số kịch bản sử dụng phổ biến khác:
|
||||
|
||||
### Quản lý thư mục
|
||||
|
||||
Chúng ta có thể thử dùng công cụ lập trình AI CLI để quản lý các loại tệp trong thư mục hiện tại. Ví dụ, bạn có một loạt tệp lộn xộn, cần sắp xếp phân loại, có thể nói với Claude Code hoặc Codex:
|
||||
|
||||
`Please help me organize the contents of the current folder. I want to group files with the same content together & I want to group files from the same time period together. Please help me handle this.`
|
||||
|
||||
### Phát triển dự án mới
|
||||
|
||||
Điều này gần như giống hệt cách chúng ta sử dụng trong z.ai, Trae trước đó -- chúng ta cũng có thể trực tiếp dùng công cụ lập trình AI CLI để phát triển dự án mới từ đầu. Tất nhiên, tốt nhất nên chuẩn bị sẵn một tài liệu nhu cầu trước.
|
||||
|
||||
Tài liệu nhu cầu càng chi tiết, hiệu quả cuối cùng càng tốt. Bạn có thể tối ưu hóa tài liệu nhiều vòng theo ý tưởng thay đổi liên tục; tài liệu càng hoàn thiện, triển khai mã càng ổn định, trưởng thành hơn.
|
||||
|
||||
### Triển khai dự án mã nguồn mở (ví dụ Dify)
|
||||
|
||||
Đối với các bạn mới tiếp xúc với máy tính, việc triển khai một dự án mã nguồn mở từ GitHub thường rất khó khăn. Nhưng chúng ta hoàn toàn có thể giao việc này cho Claude Code, giống như chúng ta đã làm trong hướng dẫn Dify:
|
||||
|
||||
<https://github.com/langgenius/dify>
|
||||
|
||||
Nếu tôi muốn chạy Dify riêng trên máy cục bộ, chỉ cần ném liên kết này cho Claude Code, sau đó nhập:
|
||||
|
||||
`I want to deploy this GitHub project ``https://github.com/langgenius/dify`` . Please help me clone the project and run it.`
|
||||
|
||||
Sau khi nhận yêu cầu của bạn, Claude Code sẽ tự động hoàn thành một loạt thao tác, bao gồm lấy mã từ GitHub, cấu hình môi trường chạy, khởi động dự án, v.v. Nếu có lỗi ở bước nào hoặc trạng thái khởi động dự án không bình thường, bạn chỉ cần xử lý thủ công ít theo hướng dẫn. Ngoài Dify, bạn cũng có thể dùng Claude Code giúp bạn triển khai phần lớn dự án mã nguồn mở GitHub phổ biến -- bạn chỉ cần một ô hội thoại, cộng thêm thời gian uống một tách cà phê.
|
||||
|
||||
|
||||
|
||||
### Giải thích mã và viết tài liệu
|
||||
|
||||
Đối với một số dự án phức tạp, hoặc dự án lớn do AI tự động tạo, bạn có thể thấy mã quá dài, logic quá nhiều, rất khó hiểu. Lúc này có thể để công cụ lập trình AI CLI giúp bạn "đọc mã". Bạn có thể hỏi như sau:
|
||||
|
||||
- Vui lòng giúp tôi giải thích dự án này: cách chạy, cách sử dụng, sau này sửa và tiếp tục phát triển như thế nào?
|
||||
- Vui lòng giúp tôi giải thích quy trình tổng thể của dự án này: chương trình chạy như thế nào? Người dùng có thể làm những thao tác nào trong giao diện?
|
||||
- Vui lòng giúp tôi viết một tài liệu hoàn chỉnh cho dự án này, bao gồm tài liệu phát triển và tài liệu chạy, v.v.
|
||||
- Vui lòng dựa trên tất cả nội dung trong thư mục hiện tại của tôi, viết một mô tả chi tiết, và lưu vào tài liệu markdown đã chỉ định.
|
||||
|
||||
### Thêm cách sử dụng
|
||||
|
||||
Tất nhiên, công cụ lập trình AI CLI có thể làm được nhiều hơn những điều trên. Đừng chỉ coi nó là "công cụ viết mã", mà hãy coi nó như một Agent thông minh có khả năng hành động độc lập. Bạn có thể để nó giúp bạn:
|
||||
|
||||
- Quản lý và sắp xếp tệp cục bộ;
|
||||
- Viết nhật ký, viết tổng kết;
|
||||
- Phân tích và sửa lỗi hệ thống;
|
||||
- Thực hiện các tác vụ dòng lệnh lặp đi lặp lại, v.v.
|
||||
|
||||
Có lẽ trong tương lai không xa, nó sẽ trở thành đối tác AI quan trọng nhất và hiểu bạn nhất trên máy tính của bạn.
|
||||
@@ -0,0 +1,905 @@
|
||||
# Cách tích hợp hệ thống thanh toán như Stripe
|
||||
|
||||
Khi sản phẩm của bạn đã có trang giao diện, đăng nhập, cơ sở dữ liệu và backend cơ bản, vấn đề thực tế tiếp theo là: **làm sao để thu tiền**.
|
||||
|
||||
Nhiều người lần đầu tiếp xúc với thanh toán thường tập trung hết vào "làm sao để nhảy đến trang thanh toán". Nhưng thứ thực sự quyết định hệ thống có ổn định hay không, không phải là nút bấm, mà là toàn bộ chuỗi thanh toán: ai quyết định giá, ai xác nhận thanh toán thành công, ai cập nhật cơ sở dữ liệu, ai thu hồi quyền hạn.
|
||||
|
||||
Bài viết này giúp bạn chia thành hai phần:
|
||||
|
||||
- **Phần đầu** chỉ nói về tích hợp cơ bản thực dụng nhất, mục tiêu là giúp bạn nhanh chóng tích hợp Stripe vào dự án.
|
||||
- **Phần sau** được gom chung vào phụ lục, bao gồm chi tiết Webhook, sự kiện đăng ký, khác biệt về phương án thanh toán giữa các quốc gia và khu vực.
|
||||
|
||||
> 💡 Khuyến nghị học xong các chương này trước khi tiếp tục
|
||||
>
|
||||
> - [Từ cơ sở dữ liệu đến Supabase](../database-supabase/)
|
||||
> - [Mô hình hỗ trợ viết code API và tài liệu API](../ai-interface-code/)
|
||||
> - [Cách triển khai ứng dụng Web](../zeabur-deployment/)
|
||||
|
||||
# Bạn sẽ học được
|
||||
|
||||
1. Hệ thống thanh toán khả thi tối thiểu trông như thế nào.
|
||||
2. Cách nhanh nhất để tích hợp Stripe vào dự án của bạn.
|
||||
3. Cách viết prompt để AI trực tiếp giúp bạn thêm hệ thống thanh toán.
|
||||
4. Nếu không làm dự án Stripe ở nước ngoài, nên ưu tiên phương án thanh toán nào cho các khu vực khác.
|
||||
|
||||
---
|
||||
|
||||
# Phần 1: Cơ bản
|
||||
|
||||
## 1. Hãy nhớ 3 nguyên tắc
|
||||
|
||||
Nếu bạn chỉ nhớ ba điều, hãy nhớ ba điều sau:
|
||||
|
||||
1. **Giá cả phải do backend quyết định**, không được tin số tiền frontend gửi lên.
|
||||
2. **Thứ thực sự kích hoạt quyền hạn là Webhook**, không phải trang `success`.
|
||||
3. **Cơ sở dữ liệu của bạn phải lưu trạng thái thanh toán**, không được chỉ dựa vào bảng điều khiển Stripe.
|
||||
|
||||
Ba điều này là ranh giới cốt lõi của hệ thống thanh toán. Chỉ cần ranh giới không sai, sau này đổi sang Stripe, PayPal, Alipay, WeChat Pay, bản chất đều chỉ là "đổi giao diện, kiến trúc không đổi".
|
||||
|
||||
## 2. Nếu không xử lý ở backend mà để frontend kết nối trực tiếp Stripe thì sao?
|
||||
|
||||
Đây là ý tưởng tự nhiên nhất của nhiều người lần đầu làm thanh toán:
|
||||
|
||||
- Trên trang đã có nút "Mua hàng"
|
||||
- Vậy tôi có thể để frontend tự kết nối Stripe
|
||||
- Như vậy có phải không cần làm backend không
|
||||
|
||||
Nếu bạn chỉ làm một trang demo giả thì không sao. Nhưng nếu bạn thực sự muốn thu tiền, **cách này thường sẽ dẫn đến hậu quả xấu**.
|
||||
|
||||
Các vấn đề phổ biến nhất bao gồm:
|
||||
|
||||
1. **Giá cả dễ bị thay đổi**
|
||||
Request trong trình duyệt là do máy tính người dùng gửi đi. Người khác hoàn toàn có thể sửa nội dung request.
|
||||
2. **Thông tin nhạy cảm dễ bị lộ**
|
||||
Các khóa bí mật, logic giá cả, logic kích hoạt hội viên quan trọng nhất, vốn dĩ không nên đặt ở frontend.
|
||||
3. **Bạn không thể xác nhận đáng tin cậy "khoản tiền này có thực sự thành công không"**
|
||||
Người dùng nhảy đến trang thành công, không có nghĩa là cơ sở dữ liệu của bạn đã đồng bộ đúng.
|
||||
4. **Trạng thái cơ sở dữ liệu sẽ bị loạn**
|
||||
Người dùng có thể nói "tôi rõ ràng đã thanh toán", nhưng trong hệ thống của bạn hoàn toàn không ghi nhận.
|
||||
|
||||
Vậy phân công an toàn hơn nên là:
|
||||
|
||||
- Frontend chịu trách nhiệm: hiển thị nút, khởi tạo mua hàng, chuyển trang
|
||||
- Backend chịu trách nhiệm: quyết định giá, tạo phiên thanh toán, nhận Webhook, cập nhật cơ sở dữ liệu
|
||||
|
||||
::: info Đoạn này bạn có thể tóm gọn thành một câu
|
||||
**Frontend có thể chịu trách nhiệm chuyển trang, backend phải chịu trách nhiệm định giá và xác nhận.**
|
||||
|
||||
Chỉ khi thực sự thu tiền, đừng đặt "quyền quyết định giá cuối cùng" và "logic kích hoạt sau thanh toán thành công" ở frontend.
|
||||
:::
|
||||
|
||||
## 3. Khi nào nên dùng Stripe trước
|
||||
|
||||
Nếu bạn đang làm các kịch bản sau, Stripe thường là điểm khởi đầu thuận lợi nhất:
|
||||
|
||||
- SaaS hướng đến người dùng ở nước ngoài
|
||||
- Sản phẩm hội viên theo dạng đăng ký
|
||||
- Sản phẩm kỹ thuật số, template, gói credit AI
|
||||
- Muốn nhanh chóng xác thực thương mại hóa, thay vì ngay từ đầu xử lý quá nhiều chi tiết thanh toán nội địa
|
||||
|
||||
Nếu người dùng chính của bạn ở Trung Quốc đại lục, thì thường sẽ không chọn Stripe làm lựa chọn đầu tiên, phần này tôi sẽ nói riêng trong phụ lục.
|
||||
|
||||
## 4. Chuỗi thanh toán khả thi tối thiểu
|
||||
|
||||
Hãy xem phiên bản tối thiểu. Chỉ cần chuỗi này chạy được, hệ thống thanh toán của bạn đã có bộ khung.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
user["Người dùng"]
|
||||
frontend["Trang frontend"]
|
||||
backend["Backend của bạn"]
|
||||
checkout["Stripe Checkout"]
|
||||
webhook["Stripe Webhook"]
|
||||
db["Supabase / Cơ sở dữ liệu kinh doanh"]
|
||||
|
||||
user -->|"Nhấn mua hàng"| frontend
|
||||
frontend -->|"Yêu cầu tạo phiên thanh toán"| backend
|
||||
backend -->|"Tạo Session theo giá backend"| checkout
|
||||
frontend -->|"Chuyển đến trang thanh toán"| checkout
|
||||
checkout -->|"Gửi sự kiện sau khi thanh toán"| webhook
|
||||
webhook -->|"Xác minh chữ ký và cập nhật trạng thái"| backend
|
||||
backend -->|"Ghi vào orders / subscriptions"| db
|
||||
db -->|"Frontend refresh đọc trạng thái mới nhất"| frontend
|
||||
```
|
||||
|
||||
Dịch sang ngôn ngữ con người:
|
||||
|
||||
1. Người dùng nhấn nút.
|
||||
2. Frontend hỏi backend lấy liên kết thanh toán.
|
||||
3. Backend dùng khóa Stripe để tạo phiên thanh toán.
|
||||
4. Người dùng đến trang Stripe để thanh toán.
|
||||
5. Stripe thông báo cho bạn qua Webhook rằng "thanh toán thực sự thành công".
|
||||
6. Backend của bạn cập nhật cơ sở dữ liệu.
|
||||
|
||||
## 5. Sơ đồ thời gian chuẩn khi khởi tạo thanh toán
|
||||
|
||||
Nếu bạn quen xem sơ đồ hệ thống chuẩn hơn, có thể xem trực tiếp sơ đồ thời gian này:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as Người dùng
|
||||
participant Frontend as Trang frontend
|
||||
participant Backend as Backend API
|
||||
participant Stripe as Stripe Checkout
|
||||
|
||||
User->>Frontend: Nhấn "Nâng cấp" hoặc "Mua hàng"
|
||||
Frontend->>Backend: POST /api/billing/create-checkout-session
|
||||
Note right of Frontend: Frontend truyền plan / userId / email\nKhông truyền số tiền thanh toán cuối cùng
|
||||
Backend->>Backend: Xác minh gói và ánh xạ priceId
|
||||
Backend->>Stripe: Tạo Checkout Session
|
||||
Stripe-->>Backend: Trả về session.url
|
||||
Backend-->>Frontend: Trả về liên kết thanh toán
|
||||
Frontend-->>User: Chuyển đến trang thanh toán Stripe
|
||||
User->>Stripe: Hoàn thành thanh toán
|
||||
```
|
||||
|
||||
## 6. Bắt đầu nhanh
|
||||
|
||||
Nếu bạn muốn tích hợp nhanh nhất, chỉ cần làm theo 5 bước dưới đây.
|
||||
|
||||
### 6.1 Bước 1: Tạo sản phẩm và giá trong bảng điều khiển Stripe
|
||||
|
||||
Mục đích của bước này không phải "tự cấu hình vài thứ", mà là định nghĩa rõ trong Stripe **bạn đang bán cái gì, định thu tiền như thế nào**.
|
||||
|
||||
Trong mô hình của Stripe:
|
||||
|
||||
- **Product** đại diện cho "bạn đang bán cái gì", ví dụ `Hội viên Pro`
|
||||
- **Price** đại diện cho "cái này bán bao nhiêu tiền, theo chu kỳ nào", ví dụ `trả tháng 9.9 USD`, `trả năm 99 USD`
|
||||
|
||||
Tại sao phải làm bước này trước? Vì khi backend của bạn tạo Checkout Session, không phải truyền trực tiếp một số tiền cho Stripe, mà phải truyền một `price_id` đã tồn tại. Stripe sẽ dựa trên `price_id` này để tạo trang thanh toán, số tiền, loại tiền tệ và chu kỳ đăng ký thực tế.
|
||||
|
||||
Nếu bạn bỏ qua bước này, "tạo liên kết thanh toán" thực ra không thể làm được.
|
||||
|
||||
::: info Tại sao phải dừng lại ở đây
|
||||
Nhiều người mới bắt đầu thấy `Product`, `Price` hai từ này hơi bực, cảm thấy như đang học thuật ngữ nội bộ của Stripe.
|
||||
|
||||
Nhưng thực ra, bước này đang làm một việc rất đơn giản:
|
||||
- Định nghĩa rõ "bán cái gì"
|
||||
- Định nghĩa rõ "bán bao nhiêu tiền"
|
||||
- Để backend sau này có thể dùng một `price_id` ổn định để tạo liên kết thanh toán
|
||||
|
||||
Chỉ cần hiểu được điều này, Checkout Session sau đó sẽ không thấy trừu tượng.
|
||||
:::
|
||||
|
||||
Đối với một hệ thống đăng ký khả thi tối thiểu, bạn ít nhất cần tạo hai cấp:
|
||||
|
||||
- Một `Product`
|
||||
- Một hoặc nhiều `Price`
|
||||
|
||||
Bạn có thể trực tiếp mở các trang sau:
|
||||
|
||||
- Trang đăng nhập Stripe Dashboard: [Dashboard Login](https://dashboard.stripe.com/login)
|
||||
- Tài liệu quản lý sản phẩm và giá của Stripe: [Manage products and prices](https://docs.stripe.com/products-prices/manage-prices)
|
||||
- Tài liệu bắt đầu nhanh Stripe Checkout: [Build a Stripe-hosted checkout page](https://docs.stripe.com/checkout/quickstart?lang=node)
|
||||
- Trang sản phẩm Stripe Dashboard: [Product catalog](https://dashboard.stripe.com/test/products)
|
||||
|
||||
Khuyến nghị bạn nên thao tác trong **Test mode (chế độ thử nghiệm)** trước, đừng tạo trong môi trường chính thức ngay từ đầu.
|
||||
|
||||
Một cấu hình tối thiểu phổ biến nhất là:
|
||||
|
||||
- `Product`: `Pro Plan`
|
||||
- `Price 1`: `pro_monthly`
|
||||
- `Price 2`: `pro_yearly`
|
||||
|
||||
Khi thao tác trong bảng điều khiển, bạn có thể hiểu theo thứ tự sau:
|
||||
|
||||
1. Tạo một sản phẩm `Pro Plan` trước
|
||||
2. Sau đó thêm hai mức giá vào sản phẩm này
|
||||
3. Trả tháng và trả năm thực ra là hai cách tính phí của cùng một sản phẩm
|
||||
|
||||
Sau khi hoàn thành, bạn ít nhất cần ghi lại các thông tin sau:
|
||||
|
||||
- `price_id` của giá trả tháng
|
||||
- `price_id` của giá trả năm
|
||||
- Tên gói của bạn, ví dụ `pro_monthly`, `pro_yearly`
|
||||
|
||||
Nếu đây là lần đầu bạn vào bảng điều khiển Stripe, khuyến nghị bạn hiểu bước này như:
|
||||
|
||||
- `Product` quyết định trang thanh toán bán cái gì
|
||||
- `Price` quyết định trang thanh toán thu bao nhiêu tiền
|
||||
- Thứ backend thực sự cần dùng sau này, chủ yếu là `price_id`
|
||||
|
||||
::: info Giá trị thực sự cần ghi lại
|
||||
Quan trọng nhất trong trang này không phải tên sản phẩm, mà là `price_id`.
|
||||
|
||||
Sau này dù là để AI giúp bạn tích hợp backend, hay tự kiểm tra vấn đề, thứ thường xuyên dùng nhất là:
|
||||
- `STRIPE_PRICE_PRO_MONTHLY`
|
||||
- `STRIPE_PRICE_PRO_YEARLY`
|
||||
- Hai `price_id` tương ứng
|
||||
:::
|
||||
|
||||
Nếu bạn muốn AI dẫn bạn cấu hình bảng điều khiển trước, có thể dùng prompt này:
|
||||
|
||||
```text
|
||||
Tôi là người mới sử dụng Stripe lần đầu, bạn đừng sửa code trước, hãy dẫn tôi cấu hình thanh toán cơ bản nhất trong bảng điều khiển Stripe.
|
||||
|
||||
Vui lòng dựa trên tài liệu chính thức sau để hướng dẫn tôi từng bước:
|
||||
- https://docs.stripe.com/products-prices/manage-prices
|
||||
- https://docs.stripe.com/checkout/quickstart?lang=node
|
||||
|
||||
Tình huống của tôi:
|
||||
- Tôi muốn làm một hệ thống hội viên thanh toán đơn giản nhất
|
||||
- Chỉ có hai gói: trả tháng và trả năm
|
||||
- Tôi chưa hiểu các từ Product, Price
|
||||
|
||||
Vui lòng:
|
||||
1. Dùng ngôn ngữ đơn giản nhất giải thích Product và Price lần lượt là gì.
|
||||
2. Hướng dẫn tôi thao tác theo thứ tự "mở trang nào -> nhấp vào đâu -> điền gì".
|
||||
3. Nhắc tôi sau khi làm xong cần sao chép những nội dung nào từ bảng điều khiển để backend sử dụng.
|
||||
4. Nếu tôi dễ nhầm, hãy nhắc tôi nên luôn thao tác trong chế độ thử nghiệm.
|
||||
```
|
||||
|
||||
### 6.2 Bước 2: Chuẩn bị biến môi trường
|
||||
|
||||
Bạn thường cần chuẩn bị ít nhất các biến môi trường sau:
|
||||
|
||||
- `STRIPE_SECRET_KEY`
|
||||
- `STRIPE_WEBHOOK_SECRET`
|
||||
- `STRIPE_PRICE_PRO_MONTHLY`
|
||||
- `STRIPE_PRICE_PRO_YEARLY`
|
||||
- `APP_URL`
|
||||
- `SUPABASE_URL`
|
||||
- `SUPABASE_SERVICE_ROLE_KEY`
|
||||
|
||||
Bạn có thể trực tiếp mở các trang sau:
|
||||
|
||||
- Tài liệu Stripe API Keys: [API keys](https://docs.stripe.com/keys)
|
||||
- Trang Stripe Dashboard API Keys: [API Keys](https://dashboard.stripe.com/test/apikeys)
|
||||
- Tài liệu Stripe Webhooks: [Receive Stripe events in your webhook endpoint](https://docs.stripe.com/webhooks)
|
||||
- Trang Stripe Dashboard Webhooks: [Workbench Webhooks](https://dashboard.stripe.com/test/workbench/webhooks)
|
||||
|
||||
> ⚠️ `STRIPE_SECRET_KEY` và `SUPABASE_SERVICE_ROLE_KEY` chỉ được đặt ở backend.
|
||||
|
||||
::: info Mục đích của bước biến môi trường
|
||||
Bước này không phải để "điền đầy `.env`", mà là để đặt những thứ nhạy cảm nhất của hệ thống thanh toán vào backend bảo quản:
|
||||
|
||||
- Khóa backend của Stripe
|
||||
- Khóa xác minh Webhook
|
||||
- Ánh xạ giá của bạn
|
||||
|
||||
Hiểu đơn giản:
|
||||
Frontend chỉ chịu trách nhiệm khởi tạo mua hàng, tất cả bí mật và logic định giá nên được giữ ở phía server.
|
||||
:::
|
||||
|
||||
Bước này cũng có thể để AI giúp bạn sắp xếp:
|
||||
|
||||
```text
|
||||
Vui lòng xem cách dự án hiện tại của tôi lưu biến môi trường, sau đó giúp tôi liệt kê các biến môi trường cần thiết cho Stripe.
|
||||
|
||||
Vui lòng tham khảo tài liệu:
|
||||
- https://docs.stripe.com/keys
|
||||
- https://docs.stripe.com/webhooks
|
||||
|
||||
Tình huống của tôi:
|
||||
- Tôi là người mới bắt đầu
|
||||
- Tôi không phân biệt được biến nào nên đặt ở frontend, biến nào nên đặt ở backend
|
||||
- Tôi cũng không chắc dự án hiện tại nên sửa `.env`, `.env.local` hay file khác
|
||||
|
||||
Vui lòng:
|
||||
1. Tìm xem biến môi trường trong dự án hiện tại thường được ghi ở đâu.
|
||||
2. Liệt kê các biến tối thiểu cần thiết cho việc tích hợp Stripe.
|
||||
3. Dùng ngôn ngữ đơn giản nhất giải thích mỗi biến dùng để làm gì.
|
||||
4. Cho tôi biết mỗi biến nên sao chép từ trang Stripe nào.
|
||||
5. Nếu dự án có file biến môi trường mẫu, hãy trực tiếp giúp tôi bổ sung tên biến.
|
||||
```
|
||||
|
||||
### 6.3 Bước 3: Backend tạo Checkout Session
|
||||
|
||||
Bước này bạn không cần tự viết API, hãy để AI tham khảo tài liệu chính thức giúp bạn triển khai.
|
||||
|
||||
Trước hết đưa các tài liệu sau cho nó:
|
||||
|
||||
- Bắt đầu nhanh Stripe Checkout: [Build a Stripe-hosted checkout page](https://docs.stripe.com/checkout/quickstart?lang=node)
|
||||
- Checkout Sessions API: [Create a Checkout Session](https://docs.stripe.com/api/checkout/sessions/create)
|
||||
- Tài liệu đăng ký: [Subscriptions](https://docs.stripe.com/payments/subscriptions)
|
||||
|
||||
Sau đó dán trực tiếp prompt này:
|
||||
|
||||
```text
|
||||
Vui lòng xem cách tổ chức code backend của dự án hiện tại, sau đó giúp tôi tích hợp thanh toán Stripe.
|
||||
|
||||
Vui lòng tham khảo tài liệu chính thức:
|
||||
- https://docs.stripe.com/checkout/quickstart?lang=node
|
||||
- https://docs.stripe.com/api/checkout/sessions/create
|
||||
- https://docs.stripe.com/payments/subscriptions
|
||||
|
||||
Mục tiêu của tôi rất đơn giản:
|
||||
- Sau khi người dùng nhấn nút mua hàng, có thể nhảy đến trang thanh toán của Stripe
|
||||
- Gói chỉ có trả tháng và trả năm
|
||||
- Đừng để tôi tự quyết định code nên đặt ở đâu, hãy xem dự án rồi giúp tôi đặt vào vị trí phù hợp
|
||||
|
||||
Vui lòng:
|
||||
1. Tìm hiểu cấu trúc file đầu vào backend, file định tuyến, cách viết biến môi trường trong dự án.
|
||||
2. Tham khảo tài liệu chính thức, giúp tôi tích hợp bước "tạo liên kết thanh toán Stripe".
|
||||
3. Đừng để tôi tự truyền số tiền, giá cả sử dụng biến môi trường backend để quyết định.
|
||||
4. Sau khi xong cho tôi biết bạn đã sửa những file nào.
|
||||
5. Cuối cùng cho tôi biết tôi còn cần bổ sung cấu hình gì trong bảng điều khiển Stripe.
|
||||
```
|
||||
|
||||
### 6.4 Bước 4: Frontend chuyển đến trang thanh toán
|
||||
|
||||
Mục tiêu của bước này rất đơn giản: để nút trên trang giá gọi API backend của bạn, sau đó chuyển đến Stripe Checkout.
|
||||
|
||||
Tài liệu tham khảo:
|
||||
|
||||
- Tài liệu tích hợp Stripe Checkout: [Build an integration with Checkout](https://docs.stripe.com/payments/checkout/build-integration)
|
||||
|
||||
Prompt cho AI:
|
||||
|
||||
```text
|
||||
Giúp tôi kết nối nút "Mua hàng" trong dự án với Stripe.
|
||||
|
||||
Yêu cầu:
|
||||
- Không sửa trang hiện tại, chỉ sửa logic sau khi nhấn nút
|
||||
- Sau khi nhấn, gọi API backend để lấy liên kết thanh toán, sau đó chuyển đến Stripe
|
||||
- Nếu có lỗi, hiển thị thông báo đơn giản cho người dùng (ví dụ "Thanh toán tạm không khả dụng, vui lòng thử lại sau")
|
||||
|
||||
Tài liệu tham khảo: https://docs.stripe.com/payments/checkout/build-integration
|
||||
```
|
||||
|
||||
### 6.5 Bước 5: Webhook cập nhật trạng thái cơ sở dữ liệu
|
||||
|
||||
Đây là bước quan trọng nhất.
|
||||
|
||||
::: info Tại sao bước này quan trọng nhất
|
||||
Nhiều người nghĩ "người dùng thanh toán xong và chuyển đến trang success" là xong.
|
||||
|
||||
Không.
|
||||
|
||||
Đối với hệ thống của bạn, điều thực sự quan trọng là:
|
||||
**Stripe có chính thức gửi sự kiện đến Webhook của bạn, và backend của bạn có cập nhật trạng thái cơ sở dữ liệu thành công hay không.**
|
||||
:::
|
||||
|
||||
Bạn cũng có thể để AI triển khai trực tiếp theo tài liệu Webhook chính thức của Stripe, đừng tự viết bằng tay.
|
||||
|
||||
Tài liệu tham khảo:
|
||||
|
||||
- Stripe Webhooks: [Receive Stripe events in your webhook endpoint](https://docs.stripe.com/webhooks)
|
||||
- Stripe CLI: [Stripe CLI](https://docs.stripe.com/stripe-cli)
|
||||
- Cách sử dụng Stripe CLI: [Use the Stripe CLI](https://docs.stripe.com/stripe-cli/use-cli)
|
||||
|
||||
Prompt cho AI:
|
||||
|
||||
```text
|
||||
Vui lòng tiếp tục giúp tôi tích hợp bước "tự động kích hoạt sau khi thanh toán thành công" của Stripe.
|
||||
|
||||
Vui lòng tham khảo tài liệu chính thức:
|
||||
- https://docs.stripe.com/webhooks
|
||||
- https://docs.stripe.com/stripe-cli
|
||||
- https://docs.stripe.com/stripe-cli/use-cli
|
||||
|
||||
Mục tiêu của tôi:
|
||||
- Sau khi người dùng thanh toán xong, không chỉ chuyển đến trang thành công
|
||||
- Mà thực sự thay đổi trạng thái hội viên trong cơ sở dữ liệu thành đã kích hoạt
|
||||
|
||||
Vui lòng:
|
||||
1. Tìm xem code liên quan đến cơ sở dữ liệu và cách lưu trạng thái người dùng trong dự án hiện tại.
|
||||
2. Giúp tôi thêm Stripe webhook.
|
||||
3. Sau khi thanh toán thành công, thay đổi người dùng tương ứng thành active, hoặc cập nhật theo trường trạng thái hội viên đang dùng trong dự án.
|
||||
4. Nếu dự án đã có bảng đăng ký, bảng đơn hàng, bảng người dùng, hãy ưu tiên sử dụng cấu trúc hiện có.
|
||||
5. Sau khi xong cho tôi biết bạn đã sửa những file nào.
|
||||
6. Kèm theo hướng dẫn cách kiểm tra cục bộ bước này có thực sự hiệu quả hay không.
|
||||
```
|
||||
|
||||
## 7. Prompt để AI giúp bạn tích hợp nhanh
|
||||
|
||||
Nếu bạn đang dùng các công cụ như Codex, Claude Code, Trae, Cursor, có thể dán trực tiếp prompt dưới đây cho nó, để nó tích hợp thanh toán trong dự án của bạn.
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tích hợp thanh toán Stripe vào dự án hiện tại, tôi muốn làm một tính năng hội viên thanh toán đơn giản nhất có thể chạy được.
|
||||
|
||||
Yêu cầu của tôi:
|
||||
1. Tôi là người mới bắt đầu, vui lòng tự xem dự án trước, sau đó quyết định nên sửa code ở đâu.
|
||||
2. Đừng để tôi tự đánh giá cấu trúc thư mục, cấu trúc định tuyến, cấu trúc cơ sở dữ liệu.
|
||||
3. Tôi chỉ muốn làm phiên bản đơn giản nhất: trả tháng và trả năm hai gói.
|
||||
4. Sau khi người dùng nhấn mua hàng, có thể nhảy đến trang thanh toán Stripe.
|
||||
5. Sau khi thanh toán thành công, trạng thái hội viên trong cơ sở dữ liệu có thể chuyển thành đã kích hoạt.
|
||||
6. Đừng thêm quá nhiều tính năng phức tạp ngay từ đầu, như mã giảm giá, nâng cấp/hạ cấp, hóa đơn phức tạp.
|
||||
|
||||
Yêu cầu đầu ra:
|
||||
1. Đưa cho tôi một kế hoạch thay đổi trước.
|
||||
2. Sau đó trực tiếp sửa code.
|
||||
3. Cuối cùng hướng dẫn tôi cách kiểm tra cục bộ từng bước.
|
||||
4. Nếu có bước nào cần tôi thao tác thêm trong bảng điều khiển Stripe, hãy gửi trực tiếp liên kết và điểm chính.
|
||||
```
|
||||
|
||||
Nếu bạn muốn AI phù hợp hơn với dự án của mình, có thể bổ sung ở đầu:
|
||||
|
||||
- Framework frontend của bạn
|
||||
- Cấu trúc thư mục backend của bạn
|
||||
- Tên bảng cơ sở dữ liệu của bạn
|
||||
- Hệ thống người dùng hiện tại của bạn là Supabase Auth hay tự xây dựng Auth
|
||||
|
||||
## 7.1 Phối hợp kiểm tra cục bộ cũng nên giao cho AI
|
||||
|
||||
Nếu bạn muốn để AI giúp bạn kết nối toàn bộ quá trình phối hợp kiểm tra cục bộ, có thể dùng đoạn sau:
|
||||
|
||||
```text
|
||||
Vui lòng tiếp tục giúp tôi chạy thật thanh toán Stripe, tôi muốn làm theo từng bước, không muốn tự đoán.
|
||||
|
||||
Vui lòng tham khảo tài liệu chính thức:
|
||||
- https://docs.stripe.com/webhooks
|
||||
- https://docs.stripe.com/stripe-cli
|
||||
- https://docs.stripe.com/stripe-cli/use-cli
|
||||
|
||||
Mục tiêu của tôi:
|
||||
1. Cho tôi biết trước nên mở những trang Stripe nào.
|
||||
2. Cho tôi biết cách lấy STRIPE_WEBHOOK_SECRET.
|
||||
3. Cho tôi biết cách sử dụng stripe login và stripe listen.
|
||||
4. Cho tôi biết cách xác minh checkout.session.completed đã gửi thành công đến webhook cục bộ.
|
||||
5. Nếu dự án hiện tại cần khởi động frontend và backend trước, hãy hướng dẫn lệnh cụ thể.
|
||||
6. Đừng chỉ nói lý thuyết, hãy xuất theo các bước thao tác thực tế.
|
||||
7. Nếu tôi làm sai ở bước nào, hãy cho tôi biết lỗi phổ biến nhất sẽ trông như thế nào.
|
||||
```
|
||||
|
||||
## 8. 4 điều dễ sai nhất
|
||||
|
||||
1. **Coi trang `success` là thanh toán thành công**
|
||||
Thứ thực sự quyết định trạng thái là Webhook, không phải chuyển trang frontend.
|
||||
2. **Để frontend truyền số tiền**
|
||||
Điều này sẽ gây ra rủi ro sửa giá nghiêm trọng.
|
||||
3. **Route Webhook bị `express.json()` xử lý trước**
|
||||
Stripe xác minh chữ ký cần body request gốc.
|
||||
4. **Không xử lý lũy đẳng**
|
||||
Webhook có thể thử lại, nếu mỗi lần bạn đều lặp lại việc thêm hội viên hoặc credit, sẽ gây ra sự cố.
|
||||
|
||||
## 9. Lời khuyên chọn phương án trong một câu
|
||||
|
||||
Nếu bây giờ bạn chỉ muốn chạy được thu tiền trước:
|
||||
|
||||
| Người dùng chính của bạn | Phương án nên thử trước |
|
||||
| :--- | :--- |
|
||||
| SaaS ở nước ngoài / người dùng quốc tế | Stripe |
|
||||
| Người dùng Trung Quốc đại lục | Alipay / WeChat Pay |
|
||||
| Đội ngũ Hong Kong hoặc xuyên biên giới | Stripe + ví địa phương / phương án tập hợp FPS |
|
||||
|
||||
Chi tiết cụ thể, tôi sẽ gom vào phụ lục.
|
||||
|
||||
::: info Tư duy chọn phương án đơn giản nhất
|
||||
Đừng ngay từ đầu đã nghĩ "tôi muốn tích hợp tất cả phương thức thanh toán toàn cầu cùng lúc".
|
||||
|
||||
Thứ tự thực tế hơn thường là:
|
||||
- Chọn một chuỗi thanh toán chính theo khu vực của người dùng chính
|
||||
- Chạy được thanh toán khả thi tối thiểu trước
|
||||
- Sau đó bổ sung phương thức thanh toán thứ hai, thứ ba dựa trên nguồn người dùng thực tế
|
||||
:::
|
||||
|
||||
## 10. Tóm tắt
|
||||
|
||||
Đến đây, bạn đã nắm được chuỗi thanh toán cơ bản nhưng quan trọng nhất:
|
||||
|
||||
1. Frontend khởi tạo mua hàng.
|
||||
2. Backend tạo Checkout Session.
|
||||
3. Người dùng thanh toán trên trang Stripe.
|
||||
4. Stripe thông báo cho backend qua Webhook.
|
||||
5. Backend cập nhật cơ sở dữ liệu.
|
||||
6. Frontend refresh hiển thị trạng thái hội viên hoặc đơn hàng mới.
|
||||
|
||||
Nếu bạn chỉ muốn nhanh chóng tích hợp thanh toán vào dự án, nội dung phía trước đã đủ dùng. Phụ lục bên dưới bạn có thể quay lại xem khi thực sự gặp vấn đề.
|
||||
|
||||
---
|
||||
|
||||
# Phụ lục
|
||||
|
||||
## Phụ lục A: Các đối tượng phổ biến nhất trong Stripe
|
||||
|
||||
Lần đầu đọc tài liệu Stripe, dễ bị rối nhất bởi các tên đối tượng. Thực ra bạn chỉ cần hiểu trước các đối tượng sau:
|
||||
|
||||
| Đối tượng | Tác dụng | Bạn có thể hiểu nó là gì |
|
||||
| :--- | :--- | :--- |
|
||||
| `Product` | Mô tả bán cái gì | Sản phẩm hoặc gói hội viên |
|
||||
| `Price` | Mô tả bán bao nhiêu tiền, chu kỳ tính phí như thế nào | Trả tháng, trả năm, mua đứt |
|
||||
| `Checkout Session` | Quy trình thanh toán được Stripe lưu trữ | Trang thanh toán |
|
||||
| `Subscription` | Quan hệ đăng ký chu kỳ | Hội viên tự động gia hạn |
|
||||
| `Customer` | Người dùng thanh toán | Hồ sơ khách hàng trong Stripe |
|
||||
| `Webhook` | Thông báo bất đồng bộ | Stripe cho bạn biết "khoản tiền này thế nào" |
|
||||
|
||||
## Phụ lục B: Tại sao trang `success` không bằng thanh toán thành công
|
||||
|
||||
Nhiều người nghĩ "người dùng thanh toán xong, nhảy đến trang success" là thanh toán thành công. Đây là lỗi dễ mắc phải nhất.
|
||||
|
||||
### Nói về một kịch bản thực tế
|
||||
|
||||
Giả sử bạn làm một trang web hội viên:
|
||||
1. Người dùng nhấn "Mua hội viên"
|
||||
2. Chuyển đến trang thanh toán Stripe
|
||||
3. Người dùng nhập thẻ tín dụng, nhấn thanh toán
|
||||
4. Trang nhảy đến `success.html` của bạn
|
||||
5. Bạn viết code ở trang success: "Đã đến trang này, kích hoạt hội viên cho người dùng"
|
||||
|
||||
**Vấn đề ở đâu?**
|
||||
|
||||
Người dùng có thể hoàn toàn chưa thanh toán, hoặc thanh toán được một nửa rồi đóng trang, cũng có thể truy cập trực tiếp `success.html`.
|
||||
|
||||
### Hai đường dẫn hoàn toàn khác nhau
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
pay["Người dùng hoàn thành thanh toán trên Stripe"]
|
||||
|
||||
subgraph unreliable["❌ Đường dẫn không đáng tin: Chỉ nhìn trang success"]
|
||||
success["Trình duyệt nhảy đến trang success"]
|
||||
fake["Code frontend cho rằng đã kích hoạt"]
|
||||
risk["Rủi ro: Đóng trang / Mất mạng / Giả mạo URL / Hoàn toàn chưa thanh toán"]
|
||||
success --> fake --> risk
|
||||
end
|
||||
|
||||
subgraph reliable["✅ Đường dẫn đáng tin: Lấy Webhook backend làm chuẩn"]
|
||||
event["Stripe server gửi Webhook"]
|
||||
verify["Backend xác minh chữ ký"]
|
||||
active["Cơ sở dữ liệu chính thức cập nhật thành đã thanh toán"]
|
||||
event --> verify --> active
|
||||
end
|
||||
|
||||
pay --> success
|
||||
pay --> event
|
||||
```
|
||||
|
||||
**Điểm khác biệt chính:**
|
||||
|
||||
| | Chuyển trang success | Thông báo Webhook |
|
||||
| :--- | :--- | :--- |
|
||||
| Ai khởi tạo | Trình duyệt của người dùng | Server của Stripe |
|
||||
| Có thể giả mạo không | Có thể, chỉ cần truy cập URL trực tiếp | Không thể, có xác minh chữ ký |
|
||||
| Chắc chắn đại diện thanh toán thành công không | Không chắc chắn | Chắc chắn |
|
||||
| Hệ thống của bạn biết bằng cách nào | Code frontend đoán | Stripe thông báo chính thức |
|
||||
|
||||
### Quy trình hoàn chỉnh nên như thế nào
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as Người dùng
|
||||
participant Frontend as Trang web của bạn
|
||||
participant Stripe as Stripe
|
||||
participant Webhook as API backend của bạn
|
||||
participant DB as Cơ sở dữ liệu
|
||||
|
||||
User->>Stripe: Hoàn thành thanh toán trên trang Stripe
|
||||
Note over Stripe: Tiền thực sự đến tài khoản Stripe
|
||||
|
||||
Stripe-->>Frontend: Trình duyệt nhảy đến trang success
|
||||
Note over Frontend: ⚠️ Bước này chỉ là chuyển trang<br/>Không đại diện hệ thống đã xác nhận
|
||||
|
||||
Stripe->>Webhook: Gửi thông báo Webhook<br/>"checkout.session.completed"
|
||||
Note over Webhook: ✅ Đây mới là thông báo chính thức
|
||||
|
||||
Webhook->>Webhook: Xác minh chữ ký<br/>(Đảm bảo là Stripe gửi, không phải hacker)
|
||||
|
||||
Webhook->>DB: Cập nhật trạng thái người dùng thành "Đã thanh toán"
|
||||
DB-->>Webhook: Lưu thành công
|
||||
Webhook-->>Stripe: Trả về 200 OK
|
||||
|
||||
Frontend->>DB: Người dùng refresh trang, truy vấn trạng thái
|
||||
DB-->>Frontend: Trả về "Đã thanh toán"
|
||||
Note over Frontend: Lúc này mới hiển thị tính năng hội viên
|
||||
```
|
||||
|
||||
### Điểm nghẽn của mỗi bước
|
||||
|
||||
**Bước 1: Người dùng thanh toán trên Stripe**
|
||||
|
||||
Đây là thời điểm duy nhất xác định "tiền thực sự đã được thanh toán":
|
||||
- Người dùng nhập thông tin thẻ tín dụng, nhấn xác nhận
|
||||
- Ngân hàng trừ tiền từ thẻ người dùng
|
||||
- Stripe xác nhận đã nhận được khoản tiền này
|
||||
|
||||
**Bước 2: Trình duyệt nhảy đến trang success (vấn đề lớn nhất)**
|
||||
|
||||
Bước này hoàn toàn không đáng tin, vì:
|
||||
- Người dùng có thể trực tiếp nhập `yoursite.com/success` trong trình duyệt, chưa thanh toán cũng có thể truy cập
|
||||
- Người dùng thanh toán được một nửa đóng trang, nhưng trước đó đã sao chép liên kết success, sau đó mở trực tiếp
|
||||
- Vấn đề mạng dẫn đến chuyển trang thất bại, nhưng tiền đã trừ (người dùng đã thanh toán nhưng không thấy trang thành công)
|
||||
- Người dùng nhấn nút quay lại, lại thanh toán một lần nữa, nhưng cả hai lần đều nhảy đến cùng một trang success
|
||||
|
||||
**Bước 3: Stripe gửi Webhook**
|
||||
|
||||
Đây là Stripe chủ động thông báo cho server của bạn "khoản tiền này đã đến tài khoản":
|
||||
- Chỉ server của Stripe mới có thể khởi tạo request này
|
||||
- Request có chứa chữ ký, backend của bạn có thể xác minh có phải thực sự do Stripe gửi không
|
||||
- Ngay cả khi trang success không mở, người dùng mất mạng, Webhook vẫn sẽ được gửi
|
||||
|
||||
**Bước 4: Backend xác minh chữ ký**
|
||||
|
||||
Tại sao phải xác minh? Để ngăn hacker giả mạo thông báo.
|
||||
|
||||
Giả sử không có xác minh, hacker có thể trực tiếp gửi một thông báo giả cho server của bạn: "Người dùng A đã thanh toán 1000 nhân dân tệ". Hệ thống của bạn sẽ kích hoạt hội viên cho hacker.
|
||||
|
||||
Quá trình xác minh:
|
||||
- Stripe dùng khóa bí mật đã thống nhất với bạn để tạo chữ ký cho nội dung thông báo
|
||||
- Backend của bạn dùng cùng khóa đó để xác minh chữ ký có khớp không
|
||||
- Khớp = 100% là Stripe gửi, không khớp = trực tiếp từ chối
|
||||
|
||||
**Bước 5: Cập nhật cơ sở dữ liệu**
|
||||
|
||||
Chỉ sau khi xác minh thành công, mới cập nhật cơ sở dữ liệu:
|
||||
- Thay đổi trạng thái người dùng từ "Chờ thanh toán" thành "Đã thanh toán"
|
||||
- Ghi lại số đơn hàng, số tiền, thời gian thanh toán
|
||||
- Kích hoạt quyền hội viên tương ứng
|
||||
|
||||
**Bước 6: Frontend truy vấn trạng thái**
|
||||
|
||||
Trang success không nên tự kết luận "đến trang này là thành công". Cách làm đúng:
|
||||
- Khi trang tải, gửi request đến backend: "Người dùng này đã thanh toán chưa?"
|
||||
- Backend truy vấn cơ sở dữ liệu, trả về trạng thái thực tế
|
||||
- Dựa trên kết quả trả về hiển thị "Kích hoạt thành công" hoặc "Đang chờ xác nhận"
|
||||
|
||||
### Một cách làm sai phổ biến
|
||||
|
||||
```javascript
|
||||
// Sai: Kích hoạt trực tiếp trên trang success
|
||||
// success.html
|
||||
if (window.location.pathname === '/success') {
|
||||
// Nguy hiểm! Bất kỳ ai cũng có thể truy cập /success
|
||||
activateMembership();
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
// Đúng: Mỗi lần refresh đều truy vấn backend
|
||||
// success.html
|
||||
async function checkStatus() {
|
||||
const response = await fetch('/api/user/status');
|
||||
const data = await response.json();
|
||||
|
||||
if (data.paymentStatus === 'paid') {
|
||||
showMemberFeatures();
|
||||
} else {
|
||||
showPendingMessage();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Tóm tắt trong một câu
|
||||
|
||||
**Trang success chỉ là "chuyển trang trình duyệt thành công", Webhook mới là "Stripe chính thức xác nhận đã nhận tiền".**
|
||||
|
||||
Hệ thống của bạn phải lấy Webhook làm chuẩn, không được tin chuyển trang frontend.
|
||||
|
||||
## Phụ lục C: Các sự kiện đáng theo dõi nhất của hệ thống đăng ký
|
||||
|
||||
| Sự kiện | Ý nghĩa | Bạn thường cần làm gì |
|
||||
| :--- | :--- | :--- |
|
||||
| `checkout.session.completed` | Kích hoạt lần đầu thành công | Tạo bản ghi đăng ký cục bộ |
|
||||
| `invoice.paid` | Gia hạn tự động thành công | Gia hạn thời hạn |
|
||||
| `invoice.payment_failed` | Trừ phí tự động thất bại | Đánh dấu trạng thái rủi ro và nhắc nhở người dùng |
|
||||
| `customer.subscription.deleted` | Hủy đăng ký | Thu hồi quyền hoặc đánh dấu hết hạn |
|
||||
|
||||
### Sơ đồ trạng thái đăng ký
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> NotStarted: Người dùng chưa mua
|
||||
NotStarted --> Active: checkout.session.completed
|
||||
Active --> Active: invoice.paid
|
||||
Active --> PastDue: invoice.payment_failed
|
||||
PastDue --> Active: Người dùng bổ sung thanh toán thành công
|
||||
Active --> Canceled: customer.subscription.deleted
|
||||
PastDue --> Canceled: Hết hạn không khôi phục
|
||||
Canceled --> [*]
|
||||
|
||||
state "Chưa kích hoạt" as NotStarted
|
||||
state "Hội viên có hiệu lực" as Active
|
||||
state "Trừ phí thất bại / Chờ khôi phục" as PastDue
|
||||
state "Đã hủy / Hết hạn thu hồi" as Canceled
|
||||
```
|
||||
|
||||
### Sơ đồ thời gian gia hạn / thất bại / hủy
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant Stripe as Stripe
|
||||
participant Webhook as API Webhook của bạn
|
||||
participant DB as Bảng đăng ký / Bảng đơn hàng
|
||||
participant App as Ứng dụng của bạn
|
||||
actor User as Người dùng
|
||||
|
||||
rect rgb(235, 248, 255)
|
||||
Stripe->>Webhook: invoice.paid
|
||||
Webhook->>DB: Gia hạn current_period_end
|
||||
DB-->>Webhook: Cập nhật thành công
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: Tiếp tục duy trì hội viên có hiệu lực
|
||||
end
|
||||
|
||||
rect rgb(255, 247, 237)
|
||||
Stripe->>Webhook: invoice.payment_failed
|
||||
Webhook->>DB: Đánh dấu past_due
|
||||
DB-->>Webhook: Cập nhật thành công
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: Nhắc nhở cập nhật phương thức thanh toán
|
||||
end
|
||||
|
||||
rect rgb(254, 242, 242)
|
||||
Stripe->>Webhook: customer.subscription.deleted
|
||||
Webhook->>DB: Đánh dấu canceled
|
||||
DB-->>Webhook: Cập nhật thành công
|
||||
Webhook-->>Stripe: 200 OK
|
||||
App-->>User: Dừng quyền cao cấp
|
||||
end
|
||||
```
|
||||
|
||||
## Phụ lục D: Cách chọn phương án thanh toán khác
|
||||
|
||||
### 1. Trung Quốc đại lục
|
||||
|
||||
Nếu người dùng chính ở đại lục, lựa chọn hàng đầu vẫn là **[Alipay](https://open.alipay.com/)** và **[WeChat Pay](https://pay.wechatpay.cn/)**.
|
||||
|
||||
**Mô hình kinh doanh:**
|
||||
|
||||
Cả hai đều là mô hình "cổng thanh toán". Bạn cần:
|
||||
- Nộp hồ sơ merchant (giấy phép kinh doanh, tài khoản doanh nghiệp)
|
||||
- Tiền người dùng thanh toán trực tiếp đến tài khoản merchant của bạn
|
||||
- Bạn tự chịu trách nhiệm về thuế, hoàn tiền, đối soát
|
||||
|
||||
**Mô hình kỹ thuật:**
|
||||
|
||||
Cả hai đều là mô hình "backend đặt hàng + frontend gọi + backend thông báo", tư duy giống hệt Stripe.
|
||||
|
||||
**Quy trình tích hợp Alipay:**
|
||||
1. Tạo ứng dụng trên nền tảng mở Alipay
|
||||
2. Cấu hình khóa công khai/riêng và địa chỉ callback
|
||||
3. Backend gọi API đặt hàng thống nhất, tạo liên kết thanh toán hoặc mã QR
|
||||
4. Người dùng quét mã hoặc chuyển trang thanh toán
|
||||
5. Alipay thông báo bất đồng bộ cho backend của bạn, cập nhật trạng thái đơn hàng
|
||||
|
||||
**Quy trình tích hợp WeChat Pay:**
|
||||
- Thanh toán JSAPI: Phù hợp cho tài khoản chính thức, mini program, người dùng thanh toán trực tiếp trong WeChat
|
||||
- Thanh toán Native: PC tạo mã QR, người dùng quét mã thanh toán
|
||||
- Thanh toán H5: Trình duyệt điện thoại gọi WeChat App thanh toán
|
||||
|
||||
Quy trình: Backend đặt hàng → Lấy `prepay_id` hoặc `code_url` → Frontend gọi thanh toán → Backend nhận thông báo xác nhận thành công
|
||||
|
||||
**Liên kết tham khảo:**
|
||||
- Nền tảng mở Alipay: https://open.alipay.com/
|
||||
- Tài liệu merchant WeChat Pay: https://pay.wechatpay.cn/doc/v3/merchant/
|
||||
|
||||
### 2. Hong Kong
|
||||
|
||||
Thị trường Hong Kong khá pha trộn, tổ hợp phổ biến:
|
||||
|
||||
- Thẻ ngân hàng: Visa / Mastercard
|
||||
- FPS (Chuyển tiền nhanh): Chuyển khoản tức thời nội địa Hong Kong
|
||||
- AlipayHK / WeChat Pay HK: Phiên bản Hong Kong của Alipay và WeChat
|
||||
|
||||
**Tổ hợp khuyến nghị:**
|
||||
- Dùng **[Stripe](https://stripe.com/hk)** để bao phủ thẻ quốc tế và đăng ký
|
||||
- Dùng **[Airwallex](https://www.airwallex.com/)** hoặc **[Adyen](https://www.adyen.com/)** để bổ sung ví địa phương và FPS
|
||||
|
||||
### 3. Nước ngoài / SaaS quốc tế
|
||||
|
||||
#### [Stripe](https://stripe.com/)
|
||||
|
||||
**Mô hình kinh doanh:** Cổng thanh toán
|
||||
|
||||
- Bạn cần tự nộp hồ sơ merchant (ở một số quốc gia Stripe có thể giúp bạn xử lý)
|
||||
- Tiền người dùng thanh toán đến tài khoản Stripe của bạn, sau đó thanh toán vào tài khoản ngân hàng của bạn
|
||||
- Bạn tự chịu trách nhiệm khai báo thuế
|
||||
|
||||
**Mô hình kỹ thuật:**
|
||||
|
||||
- Trải nghiệm API tốt nhất, tài liệu rõ ràng
|
||||
- Hỗ trợ Checkout (trang lưu trữ), Elements (form tùy chỉnh), Payment Links (không cần code)
|
||||
- Webhook thông báo trạng thái thanh toán
|
||||
- Hỗ trợ đăng ký, hóa đơn, đa loại tiền tệ
|
||||
|
||||
**Phù hợp cho:** SaaS ở nước ngoài, nhà phát triển độc lập, đội ngũ cần tùy chỉnh linh hoạt
|
||||
|
||||
**Liên kết tham khảo:** https://docs.stripe.com/
|
||||
|
||||
#### [PayPal](https://www.paypal.com/)
|
||||
|
||||
**Mô hình kinh doanh:** Cổng thanh toán
|
||||
|
||||
- Tiền người dùng thanh toán đến tài khoản PayPal của bạn, sau đó rút về ngân hàng
|
||||
- Bạn tự chịu trách nhiệm về thuế
|
||||
|
||||
**Mô hình kỹ thuật:**
|
||||
|
||||
- Thanh toán một lần: Frontend đặt nút, backend tạo/xác nhận đơn hàng
|
||||
- Đăng ký: Tạo Product và Plan trước, sau đó dùng SDK gọi
|
||||
- Cũng cần backend và Webhook, đừng chỉ nhìn callback frontend
|
||||
|
||||
**Phù hợp cho:** Kinh doanh ở nước ngoài cần bổ sung kênh, người dùng quen dùng PayPal thanh toán
|
||||
|
||||
**Liên kết tham khảo:** https://developer.paypal.com/docs/
|
||||
|
||||
#### [Paddle](https://www.paddle.com/)
|
||||
|
||||
**Mô hình kinh doanh:** Merchant of Record (MoR)
|
||||
|
||||
- Paddle là "merchant ghi nhận", pháp lý Paddle thu tiền từ người dùng
|
||||
- Paddle giúp bạn xử lý thuế toàn cầu, VAT, hoàn tiền, tuân thủ
|
||||
- Tiền người dùng thanh toán đến Paddle, Paddle trừ phí thuế và phí dịch vụ rồi thanh toán cho bạn
|
||||
- Bạn không cần đăng ký công ty ở mỗi quốc gia hoặc xử lý thuế
|
||||
|
||||
**Mô hình kỹ thuật:**
|
||||
|
||||
- Paddle.js: Nhúng trang thanh toán lưu trữ vào frontend
|
||||
- Backend API: Tạo transaction, giao cho checkout xử lý
|
||||
- Webhook đồng bộ trạng thái đăng ký
|
||||
|
||||
**Phù hợp cho:** Đội ngũ SaaS không muốn xử lý thuế toàn cầu, đặc biệt là B2B SaaS
|
||||
|
||||
**Liên kết tham khảo:** https://developer.paddle.com/
|
||||
|
||||
#### [Lemon Squeezy](https://www.lemonsqueezy.com/)
|
||||
|
||||
**Mô hình kinh doanh:** Merchant of Record (MoR)
|
||||
|
||||
- Tương tự Paddle, Lemon Squeezy là "merchant ghi nhận"
|
||||
- Giúp bạn xử lý thuế toàn cầu, VAT, tuân thủ
|
||||
- Năm 2024 được Stripe mua lại, nhưng vẫn hoạt động độc lập
|
||||
|
||||
**Mô hình kỹ thuật:**
|
||||
|
||||
- Hosted Checkout: Đơn giản nhất, trực tiếp tạo liên kết thanh toán
|
||||
- Checkout Overlay: Lớp nổi nhúng vào trang của bạn
|
||||
- Backend API: Tạo checkout, kiểm soát linh hoạt
|
||||
|
||||
**Phù hợp cho:** Nhà phát triển độc lập, sản phẩm kỹ thuật số, giấy phép phần mềm
|
||||
|
||||
**Liên kết tham khảo:** https://docs.lemonsqueezy.com/
|
||||
|
||||
### 4. Phương án doanh nghiệp
|
||||
|
||||
#### [Airwallex](https://www.airwallex.com/)
|
||||
|
||||
**Mô hình kinh doanh:** Cổng thanh toán + Tài khoản toàn cầu
|
||||
|
||||
- Cung cấp tài khoản thu tiền toàn cầu (tương tự tài khoản ngân hàng ảo)
|
||||
- Hỗ trợ thu tiền đa loại tiền tệ, đổi ngoại tệ, thanh toán
|
||||
- Bạn tự chịu trách nhiệm về thuế
|
||||
|
||||
**Mô hình kỹ thuật:**
|
||||
|
||||
- Payment Links: Gần như không cần code, tạo liên kết thanh toán
|
||||
- Hosted Payment Page: Trang lưu trữ
|
||||
- Drop-in / Embedded / Native API: Tích hợp sâu, tùy chỉnh cao
|
||||
- Hỗ trợ Alipay HK, FPS, WeChat Pay và các phương thức thanh toán nội địa khác
|
||||
|
||||
**Phù hợp cho:** Đội ngũ Hong Kong, kinh doanh xuyên biên giới, công ty cần tài khoản đa loại tiền tệ
|
||||
|
||||
**Liên kết tham khảo:** https://www.airwallex.com/docs/
|
||||
|
||||
#### [Adyen](https://www.adyen.com/)
|
||||
|
||||
**Mô hình kinh doanh:** Cổng thanh toán
|
||||
|
||||
- Nền tảng thanh toán cấp doanh nghiệp, volume giao dịch hàng năm hàng nghìn tỷ euro
|
||||
- Hỗ trợ đầy đủ các kênh online, offline, mobile
|
||||
- Bạn tự chịu trách nhiệm về thuế
|
||||
|
||||
**Mô hình kỹ thuật:**
|
||||
|
||||
- Pay by Link: Đơn giản nhất, tạo liên kết thanh toán
|
||||
- Drop-in / Components: Tích hợp online tiêu chuẩn
|
||||
- Backend có thể kích hoạt Alipay, Alipay HK, PayMe và các phương thức thanh toán nội địa khác
|
||||
|
||||
**Phù hợp cho:** Doanh nghiệp lớn, công ty cần thanh toán đa kênh
|
||||
|
||||
**Liên kết tham khảo:** https://docs.adyen.com/
|
||||
|
||||
### 5. So sánh phương án
|
||||
|
||||
| Phương án | Mô hình kinh doanh | Xử lý thuế | Phù hợp cho |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| Stripe | Cổng thanh toán | Tự xử lý | SaaS ở nước ngoài, nhà phát triển |
|
||||
| PayPal | Cổng thanh toán | Tự xử lý | Kênh bổ sung ở nước ngoài |
|
||||
| Paddle | MoR | Paddle xử lý hộ | B2B SaaS, không muốn quản thuế |
|
||||
| Lemon Squeezy | MoR | LS xử lý hộ | Nhà phát triển độc lập, sản phẩm kỹ thuật số |
|
||||
| Adyen | Cổng thanh toán | Tự xử lý | Doanh nghiệp lớn |
|
||||
| Airwallex | Cổng thanh toán + Tài khoản | Tự xử lý | Kinh doanh xuyên biên giới, đội ngũ Hong Kong |
|
||||
| Alipay/WeChat Pay | Cổng thanh toán | Tự xử lý | Người dùng đại lục |
|
||||
|
||||
### 6. Chọn phương án theo khu vực
|
||||
|
||||
| Thị trường của bạn | Phương án khuyến nghị |
|
||||
| :--- | :--- |
|
||||
| Trung Quốc đại lục | Alipay / WeChat Pay |
|
||||
| Hong Kong | Stripe + Airwallex / Adyen |
|
||||
| SaaS ở nước ngoài | Stripe (tự quản thuế) hoặc Paddle (MoR quản hộ) |
|
||||
| Sản phẩm kỹ thuật số ở nước ngoài | Stripe / Lemon Squeezy / Paddle |
|
||||
| Đa khu vực cấp doanh nghiệp | Tổ hợp Adyen / Airwallex / Stripe |
|
||||
@@ -0,0 +1,490 @@
|
||||
# Cách triển khai ứng dụng Web
|
||||
|
||||
Trong hướng dẫn này, chúng tôi sẽ giới thiệu cách triển khai ứng dụng Web của bạn lên Internet để người khác có thể truy cập. Chúng tôi sẽ giới thiệu ba nền tảng triển khai phổ biến: **Tencent CloudBase**, **Vercel** và **Zeabur**, giúp bạn nhanh chóng hoàn thành quy trình hoàn chỉnh từ "viết xong code" đến "để người khác có thể truy cập trang web của bạn trên Internet".
|
||||
|
||||
# "Triển khai" là gì?
|
||||
|
||||
Trước khi bắt đầu, chúng ta hãy tìm hiểu "Triển khai (Deployment)" thực chất có nghĩa là gì. Bất kỳ trang web nào muốn được người dùng bên ngoài truy cập đều phải có một địa chỉ mạng có thể truy cập công khai (địa chỉ này có thể là địa chỉ IP, ví dụ 123.45.67.89, hoặc một tên miền, ví dụ [google.com](https://google.com/)). Nhưng chỉ có địa chỉ là chưa đủ -- mã trang web bạn đã viết (ví dụ tệp HTML, CSS, JavaScript, hoặc dự án sử dụng React, Vue và các framework khác), cùng với các tài nguyên hình ảnh / video liên quan, đều phải được "đặt" trên một máy chủ trực tuyến 24 giờ, máy chủ này sẽ phản hồi các yêu cầu mạng, để trình duyệt của bất kỳ ai mới có thể truy cập và tải xuống các tài nguyên này.
|
||||
|
||||
|
||||
|
||||
Nguồn hình ảnh: https://www.hostinger.com/tutorials/what-is-cloud-hosting
|
||||
|
||||
Toàn bộ quá trình tải tài nguyên lên, cấu hình môi trường và làm cho dịch vụ "chạy được" được gọi là **Triển khai (Deployment)**.
|
||||
|
||||
Nói một cách đơn giản: trang web bạn viết trên máy tính của mình, miễn là bạn chỉ khởi động chương trình cục bộ, thì bạn chỉ có thể truy cập qua địa chỉ cục bộ trên trình duyệt của mình, vì mã này chỉ tồn tại trên ổ cứng của bạn. "Triển khai" là việc chuyển mã và tài nguyên của bạn sang một máy chủ chuyên nghiệp được kết nối với mạng công cộng, và cấu hình sao cho máy chủ này biết "khi người khác truy cập, tôi cần phản hồi như thế nào" -- ví dụ: khi ai đó nhập tên miền của bạn trong trình duyệt, máy chủ sẽ ngay lập tức tìm tệp trang web tương ứng, truyền nội dung về thiết bị của họ, từ đó người dùng có thể nhìn thấy trang của bạn.
|
||||
|
||||
Nếu triển khai thủ công, một dự án thường cần nhiều bước, mỗi bước đều có thể gặp vấn đề. Các bước chính thường bao gồm:
|
||||
|
||||
1. **Chuẩn bị máy chủ**: Bạn cần mua máy chủ đám mây (ví dụ Alibaba Cloud, Tencent Cloud, hoặc AWS EC2), chọn khu vực đặt máy chủ (như Thượng Hải, Singapore), cấu hình (CPU, bộ nhớ, dung lượng ổ đĩa, v.v.), và học cách kết nối từ xa với máy chủ (ví dụ thông qua công cụ SSH).
|
||||
|
||||
2. **Cấu hình môi trường**: Ứng dụng Web cần chạy trong một "môi trường" cụ thể -- ví dụ để chạy dự án Node.js, bạn phải cài đặt Node.js trước; để chạy dự án Python, bạn phải cài đặt Python và các thư viện bên thứ ba tương ứng. Nếu phiên bản môi trường không khớp, chương trình có thể báo lỗi và không thể khởi động.
|
||||
3. **Tải tài nguyên lên**: Bạn cần tải mã và tài nguyên cục bộ lên máy chủ, các phương pháp phổ biến bao gồm FTP hoặc Git. Nếu dự án có dung lượng lớn (ví dụ chứa tệp video), nếu kết nối bị gián đoạn giữa chừng, đôi khi bạn phải tải lên lại từ đầu.
|
||||
|
||||
|
||||
|
||||
4. **Khởi động dịch vụ và kiểm tra**: Sau khi tải lên xong, bạn cần thực thi lệnh khởi động ứng dụng trên máy chủ, và kiểm tra "địa chỉ mạng được phân phối có thể truy cập được không". Nếu không truy cập được, có thể tường lửa của máy chủ chưa mở cổng tương ứng (ví dụ ứng dụng của bạn lắng nghe cổng 3000, nhưng cổng này bị tường lửa chặn), hoặc chương trình có Bug, lúc này cần xem nhật ký máy chủ để khắc phục.
|
||||
> Mẹo: Bạn có thể hiểu cổng (port) như "số phòng" để phân biệt các ứng dụng khác nhau trên cùng một thiết bị, còn IP là "số nhà" của thiết bị đó. IP và cổng kết hợp với nhau (IP:port) có thể định vị chính xác một dịch vụ mạng cụ thể.
|
||||
5. **Bảo trì và cập nhật**: Mỗi lần bạn sửa mã sau này, bạn phải tải lên lại và khởi động lại dịch vụ. Nếu máy chủ gặp sự cố (ví dụ mất điện, lỗi mạng), bạn cần khởi động lại ứng dụng thủ công, đôi khi còn cần cấu hình thêm "công cụ quản lý tiến trình" để chương trình tự động khởi động lại khi thoát bất thường.
|
||||
|
||||
Các nền tảng "triển khai mã thấp" như CloudBase, Vercel, Zeabur ra đời chính là để giải quyết các vấn đề phức tạp nói trên. Chúng sẽ giúp bạn tự động hoàn thành các bước "mua máy chủ, cấu hình môi trường, tải mã lên, khởi động dịch vụ, giám sát vận hành". Bạn chỉ cần kết nối kho mã (ví dụ GitHub hoặc GitLab) của mình với nền tảng, hoặc tải mã trực tiếp lên, nó sẽ tự động lấy mã, nhận dạng loại ứng dụng, cấu hình môi trường runtime tương ứng, và cuối cùng cung cấp cho bạn một địa chỉ mạng công cộng mà bất kỳ ai cũng có thể truy cập. Nó thậm chí có thể liên kết tên miền riêng của bạn chỉ bằng một cú nhấp.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng tôi sẽ giới thiệu lần lượt đặc điểm và cách sử dụng của ba nền tảng này, giúp bạn chọn phương án triển khai phù hợp nhất với mình.
|
||||
|
||||
---
|
||||
|
||||
# So sánh nền tảng triển khai
|
||||
|
||||
| Nền tảng | Đặc điểm | Phù hợp cho | Gói miễn phí |
|
||||
|------|------|----------|----------|
|
||||
| **Tencent CloudBase** | Truy cập nhanh trong nước, tích hợp sâu với hệ sinh thái WeChat | Dự án hướng tới người dùng trong nước, cần hỗ trợ WeChat Mini Program | Có gói miễn phí |
|
||||
| **Vercel** | Hỗ trợ tốt cho framework frontend, tích hợp chặt chẽ với GitHub | Dự án frontend hiện đại như React/Vue/Next.js | Có gói miễn phí |
|
||||
| **Netlify** | Chức năng toàn diện, hỗ trợ xử lý biểu mẫu và xác thực, tích hợp tốt với Git | Trang web tĩnh cần xử lý biểu mẫu, xác thực và các tính năng nâng cao | Có gói miễn phí |
|
||||
| **Zeabur** | Hỗ trợ nhiều ngôn ngữ và mẫu dịch vụ, cấu hình linh hoạt | Dự án phức tạp cần triển khai nhiều dịch vụ (như Dify, n8n) | Khoảng 5 USD miễn phí mỗi tháng |
|
||||
|
||||
---
|
||||
|
||||
# 1. Tencent CloudBase
|
||||
|
||||
Tencent CloudBase (Phát triển đám mây) là dịch vụ backend đám mây một cửa do Tencent Cloud cung cấp, đặc biệt phù hợp cho nhà phát triển trong nước. Ưu điểm của nó bao gồm:
|
||||
|
||||
- **Truy cập nhanh trong nước**: Máy chủ đặt trong nước, độ trễ truy cập thấp
|
||||
- **Tích hợp hệ sinh thái WeChat**: Có thể dễ dàng kết nối với WeChat Mini Program, Official Account
|
||||
- **Giải pháp một cửa**: Cung cấp dịch vụ đầy đủ bao gồm lưu trữ trang web tĩnh, hàm đám mây, cơ sở dữ liệu, lưu trữ, v.v.
|
||||
- **Gói miễn phí dồi dào**: Nhà phát triển cá nhân có đủ tài nguyên miễn phí
|
||||
|
||||
## Sử dụng CloudBase để triển khai ứng dụng Web
|
||||
|
||||
### Bước 1: Đăng ký và đăng nhập
|
||||
|
||||
Truy cập [Tencent CloudBase Console](https://console.cloud.tencent.com/tcb), đăng nhập bằng WeChat hoặc QQ.
|
||||
|
||||
### Bước 2: Tạo môi trường
|
||||
|
||||
Nhấp vào "Tạo môi trường mới", chọn tên môi trường (ví dụ `my-web-app`).
|
||||
|
||||
> **Lưu ý**: Phiên bản dùng thử miễn phí của CloudBase cần mã đổi để kích hoạt. Bạn cần theo dõi tài khoản công cộng Tencent CloudBase, nhập "nhận mã đổi" trong tài khoản công cộng để lấy mã đổi phiên bản dùng thử miễn phí, sau đó điền mã đổi khi tạo môi trường để kích hoạt môi trường miễn phí (thời gian dùng thử miễn phí là 6 tháng).
|
||||
|
||||
### Bước 3: Kích hoạt lưu trữ trang web tĩnh
|
||||
|
||||
Trong trang quản lý môi trường, tìm chức năng "Lưu trữ trang web tĩnh" và kích hoạt. Sau khi kích hoạt, bạn sẽ nhận được một tên miền truy cập mặc định.
|
||||
|
||||
Lưu trữ trang web tĩnh của CloudBase cung cấp nhiều phương pháp triển khai, tương tự như Zeabur:
|
||||
|
||||
- **Tải dự án cục bộ lên**: Tải trực tiếp các tệp tĩnh đã xây dựng (HTML, CSS, JS, v.v.) từ máy cục bộ
|
||||
- **Triển khai bằng mẫu**: Sử dụng các mẫu có sẵn để tạo dự án nhanh chóng, như mẫu ứng dụng React Web, mẫu ứng dụng Vue Web
|
||||
- **Triển khai từ kho Git**: Hỗ trợ tự động lấy mã từ các kho mã như GitHub và triển khai
|
||||
|
||||
### Bước 4: Triển khai mã
|
||||
|
||||
Trong trang lưu trữ trang web tĩnh, CloudBase cung cấp ba phương pháp triển khai:
|
||||
|
||||
**Phương pháp 1: Triển khai dự án cục bộ (Tải dự án cục bộ lên)**
|
||||
- Chọn "Triển khai dự án cục bộ" trong bảng điều khiển
|
||||
- Tải trực tiếp các tệp tĩnh đã xây dựng (HTML, CSS, JS, v.v.)
|
||||
- Chọn thư mục dự án đã xây dựng trên máy (như thư mục `dist` hoặc `build`)
|
||||
- Đợi tải lên hoàn tất để truy cập
|
||||
|
||||
**Phương pháp 2: Triển khai bằng mẫu**
|
||||
- Sử dụng các mẫu có sẵn để tạo dự án nhanh chóng
|
||||
- Hỗ trợ mẫu ứng dụng React Web, mẫu ứng dụng Vue Web, v.v.
|
||||
- Xây dựng và triển khai tự động dựa trên mẫu
|
||||
|
||||
**Phương pháp 3: Triển khai từ kho Git**
|
||||
- **Triển khai kho cá nhân Git**: Liên kết kho mã GitHub cá nhân của bạn
|
||||
- **Triển khai kho công khai**: Hỗ trợ lấy mã từ kho Git công khai
|
||||
- Cấu hình lệnh xây dựng tự động (như `npm run build`)
|
||||
- Mỗi lần đẩy mã sẽ tự động triển khai lại
|
||||
|
||||
> **Mẹo**: Bạn cũng có thể sử dụng công cụ CLI để triển khai:
|
||||
> ```bash
|
||||
> # Cài đặt CloudBase CLI
|
||||
> npm install -g @cloudbase/cli
|
||||
> # Đăng nhập
|
||||
> tcb login
|
||||
> # Triển khai
|
||||
> tcb hosting deploy ./dist -e your-env-id
|
||||
> ```
|
||||
|
||||
### Bước 5: Cấu hình tên miền tùy chỉnh (tùy chọn)
|
||||
|
||||
Trong cài đặt lưu trữ trang web tĩnh, bạn có thể liên kết tên miền riêng của mình và xin chứng chỉ HTTPS miễn phí.
|
||||
|
||||
---
|
||||
|
||||
# 2. Vercel
|
||||
|
||||
Vercel là một trong những nền tảng triển khai frontend phổ biến nhất thế giới, đặc biệt phù hợp để triển khai các dự án sử dụng React, Vue, Next.js và các framework frontend hiện đại khác. Đặc điểm của nó bao gồm:
|
||||
|
||||
- **Tích hợp sâu với GitHub**: Đẩy mã là tự động triển khai
|
||||
- **Xem trước tự động**: Mỗi Pull Request sẽ tạo một liên kết xem trước độc lập
|
||||
- **CDN toàn cầu**: Trang web tự động phân phối đến các nút toàn cầu, tốc độ truy cập nhanh
|
||||
- **Hàm Serverless**: Hỗ trợ viết API backend trong dự án
|
||||
|
||||
> **Lưu ý**: Vercel có thể truy cập không ổn định trong một số môi trường mạng, người dùng trong nước nên ưu tiên CloudBase.
|
||||
|
||||
## Sử dụng Vercel để triển khai ứng dụng Web
|
||||
|
||||
### Bước 1: Đăng ký tài khoản
|
||||
|
||||
Truy cập [Vercel chính thức](https://vercel.com), đăng nhập bằng tài khoản GitHub.
|
||||
|
||||
### Bước 2: Nhập dự án
|
||||
|
||||
1. Nhấp vào "Add New Project"
|
||||
2. Chọn kho GitHub bạn muốn triển khai
|
||||
3. Nếu không thấy kho bạn muốn, nhấp vào "Adjust GitHub App Permissions" để cấp quyền truy cập
|
||||
|
||||
### Bước 3: Cấu hình cài đặt xây dựng
|
||||
|
||||
Vercel sẽ tự động nhận dạng loại dự án và cấu hình lệnh xây dựng:
|
||||
|
||||
| Framework | Lệnh xây dựng | Thư mục đầu ra |
|
||||
|------|----------|----------|
|
||||
| React | `npm run build` | `build` |
|
||||
| Vue | `npm run build` | `dist` |
|
||||
| Next.js | `next build` | - |
|
||||
| HTML thuần | - | Thư mục gốc dự án |
|
||||
|
||||
Nếu nhận dạng tự động không chính xác, bạn có thể sửa thủ công:
|
||||
- **Build Command**: Lệnh xây dựng, ví dụ `npm run build`
|
||||
- **Output Directory**: Thư mục đầu ra xây dựng, ví dụ `dist` hoặc `build`
|
||||
- **Install Command**: Lệnh cài đặt dependency, thường là `npm install`
|
||||
|
||||
### Bước 4: Triển khai
|
||||
|
||||
Nhấp vào nút "Deploy", đợi xây dựng hoàn tất. Sau khi xây dựng thành công, bạn sẽ nhận được tên miền `xxx.vercel.app`.
|
||||
|
||||
### Bước 5: Tên miền tùy chỉnh (tùy chọn)
|
||||
|
||||
Trong trang "Domains" của cài đặt dự án, bạn có thể thêm tên miền riêng. Vercel sẽ tự động cấu hình HTTPS.
|
||||
|
||||
---
|
||||
|
||||
# 3. Netlify
|
||||
|
||||
Netlify là một nền tảng triển khai frontend rất phổ biến khác, tương tự như Vercel, đặc biệt phù hợp để triển khai trang web tĩnh và ứng dụng đơn trang (SPA). Đặc điểm của nó bao gồm:
|
||||
|
||||
- **Chức năng toàn diện**: Ngoài lưu trữ trang web tĩnh, còn hỗ trợ xử lý biểu mẫu, xác thực, hàm edge, v.v.
|
||||
- **Tích hợp sâu với Git**: Hỗ trợ GitHub, GitLab, Bitbucket, đẩy mã là tự động triển khai
|
||||
- **Xem trước theo nhánh**: Mỗi nhánh sẽ tự động tạo liên kết xem trước độc lập
|
||||
- **CDN toàn cầu**: Trang web tự động phân phối đến các nút toàn cầu, tốc độ truy cập nhanh
|
||||
- **Xử lý biểu mẫu**: Xử lý gửi biểu mẫu trang web mà không cần code backend
|
||||
- **Xác thực**: Chức năng xác thực người dùng tích hợp, có thể nhanh chóng thực hiện đăng nhập/đăng ký
|
||||
|
||||
> **Lưu ý**: Tốc độ truy cập Netlify trong nước có thể không bằng CloudBase, nên sử dụng chủ yếu cho các dự án hướng tới người dùng ở nước ngoài.
|
||||
|
||||
## Sử dụng Netlify để triển khai ứng dụng Web
|
||||
|
||||
### Bước 1: Đăng ký tài khoản
|
||||
|
||||
Truy cập [Netlify chính thức](https://www.netlify.com), nhấp vào "Sign up" để đăng ký. Bạn có thể sử dụng GitHub, GitLab, Bitbucket hoặc email để đăng ký.
|
||||
|
||||
### Bước 2: Nhập dự án
|
||||
|
||||
1. Sau khi đăng nhập, nhấp vào "Add new site" -> "Import an existing project"
|
||||
2. Chọn nền tảng lưu trữ mã của bạn (ví dụ GitHub)
|
||||
3. Cấp quyền cho Netlify truy cập kho của bạn
|
||||
4. Chọn kho bạn muốn triển khai từ danh sách
|
||||
|
||||
### Bước 3: Cấu hình cài đặt xây dựng
|
||||
|
||||
Netlify sẽ tự động nhận dạng các framework frontend phổ biến và cấu hình cài đặt xây dựng:
|
||||
|
||||
| Framework | Lệnh xây dựng | Thư mục xuất bản |
|
||||
|------|----------|----------|
|
||||
| React | `npm run build` | `build` |
|
||||
| Vue | `npm run build` | `dist` |
|
||||
| Angular | `ng build` | `dist/<project-name>` |
|
||||
| Next.js | `next build` | `out` |
|
||||
| HTML thuần | - | `.` (thư mục gốc dự án) |
|
||||
|
||||
Nếu nhận dạng tự động không chính xác, bạn có thể cấu hình thủ công:
|
||||
- **Build command**: Lệnh xây dựng, ví dụ `npm run build`
|
||||
- **Publish directory**: Thư mục đầu ra xây dựng, ví dụ `dist` hoặc `build`
|
||||
|
||||
### Bước 4: Triển khai
|
||||
|
||||
Nhấp vào nút "Deploy site", đợi xây dựng hoàn tất. Sau khi xây dựng thành công, bạn sẽ nhận được tên miền `xxx.netlify.app`, bất kỳ ai cũng có thể truy cập trang web của bạn qua địa chỉ này.
|
||||
|
||||
### Bước 5: Cấu hình tên miền tùy chỉnh (tùy chọn)
|
||||
|
||||
1. Vào cài đặt trang, nhấp vào "Domain management"
|
||||
2. Nhấp vào "Add custom domain"
|
||||
3. Nhập tên miền của bạn và làm theo hướng dẫn cấu hình bản ghi DNS
|
||||
4. Netlify sẽ tự động xin và cấu hình chứng chỉ HTTPS
|
||||
|
||||
### Tính năng đặc biệt
|
||||
|
||||
#### 1. Xử lý biểu mẫu
|
||||
|
||||
Netlify cung cấp một tính năng rất tiện lợi: xử lý gửi biểu mẫu mà không cần code backend.
|
||||
|
||||
Chỉ cần thêm thuộc tính `netlify` vào biểu mẫu HTML:
|
||||
|
||||
```html
|
||||
<form name="contact" netlify>
|
||||
<p>
|
||||
<label>Họ tên: <input type="text" name="name" /></label>
|
||||
</p>
|
||||
<p>
|
||||
<label>Email: <input type="email" name="email" /></label>
|
||||
</p>
|
||||
<p>
|
||||
<label>Tin nhắn: <textarea name="message"></textarea></label>
|
||||
</p>
|
||||
<p>
|
||||
<button type="submit">Gửi</button>
|
||||
</p>
|
||||
</form>
|
||||
```
|
||||
|
||||
Sau khi triển khai, dữ liệu gửi biểu mẫu sẽ tự động được gửi đến bảng điều khiển Netlify, bạn có thể xem tất cả bản ghi đã gửi trong trang "Forms", cũng có thể thiết lập thông báo email hoặc chuyển tiếp dữ liệu đến dịch vụ khác.
|
||||
|
||||
#### 2. Netlify Functions (hàm edge)
|
||||
|
||||
Netlify hỗ trợ triển khai hàm Serverless, cho phép bạn thực hiện các API đơn giản mà không cần xây dựng máy chủ backend đầy đủ. Bạn có thể viết hàm bằng JavaScript hoặc TypeScript, sau khi triển khai sẽ tự động nhận được một URL có thể truy cập.
|
||||
|
||||
Ví dụ, tạo một tệp `hello.js`:
|
||||
|
||||
```javascript
|
||||
exports.handler = async (event, context) => {
|
||||
return {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify({ message: "Hello from Netlify!" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
Sau khi triển khai, bạn có thể truy cập hàm này qua `https://your-domain/.netlify/functions/hello`.
|
||||
|
||||
#### 3. Hỗ trợ phát triển cục bộ
|
||||
|
||||
Netlify cung cấp công cụ CLI, giúp bạn phát triển và kiểm tra tại máy cục bộ:
|
||||
|
||||
```bash
|
||||
# Cài đặt Netlify CLI
|
||||
npm install -g netlify-cli
|
||||
|
||||
# Đăng nhập tài khoản
|
||||
netlify login
|
||||
|
||||
# Khởi động máy chủ phát triển cục bộ
|
||||
netlify dev
|
||||
|
||||
# Kiểm tra hàm cục bộ
|
||||
netlify functions:serve
|
||||
```
|
||||
|
||||
Sử dụng công cụ CLI có thể mô phỏng môi trường Netlify tại máy cục bộ, bao gồm gửi biểu mẫu, gọi hàm, v.v., giúp kiểm tra trước khi triển khai.
|
||||
|
||||
---
|
||||
|
||||
# 4. Zeabur
|
||||
|
||||
Zeabur là một nền tảng triển khai mới nổi, đặc biệt phù hợp cho các dự án phức tạp cần triển khai nhiều dịch vụ. Ưu điểm của nó bao gồm:
|
||||
|
||||
- **Mẫu dịch vụ phong phú**: Tích hợp sẵn nhiều mẫu dịch vụ như Dify, n8n, cơ sở dữ liệu, v.v.
|
||||
- **Hỗ trợ nhiều phương pháp triển khai**: GitHub, mẫu, Docker image, dự án cục bộ, v.v.
|
||||
- **Kết hợp dịch vụ linh hoạt**: Có thể triển khai nhiều dịch vụ liên quan nhau trong một dự án
|
||||
- **Tính phí theo lượng sử dụng**: Trả bao nhiêu dùng bấy nhiêu, phù hợp cho dự án thử nghiệm
|
||||
|
||||
## Sử dụng Zeabur để triển khai Dify
|
||||
|
||||
Trong các khóa học trước, chúng ta đã tiếp xúc đơn giản với Dify. Bây giờ, chúng ta có thể khởi động dịch vụ Dify riêng rất dễ dàng thông qua [Zeabur](https://zeabur.com/projects). Đầu tiên, mở [trang bảng điều khiển](https://zeabur.com/projects), hãy xem các khu vực trên trang.
|
||||
|
||||
|
||||
|
||||
Trên trang này, điều đầu tiên bạn thấy là nhiều ô vuông, đây là các dịch vụ đã được khởi động. Trong menu phía trên, bạn sẽ thấy các tùy chọn Agent, Servers, Docs, Templates, chúng lần lượt đại diện cho:
|
||||
|
||||
1. **Agent**: Có thể mở trợ lý thông minh (Agent) tích hợp sẵn của Zeabur, hỏi nó cách thao tác, hoặc truy vấn trạng thái máy chủ hiện tại.
|
||||
2. **Servers**: Ở đây bạn có thể thêm máy chủ đám mây đã mua, hoặc mua máy chủ trực tiếp qua Zeabur.
|
||||
3. **Docs**: Xem tài liệu hướng dẫn đầy đủ của Zeabur.
|
||||
4. **Templates**: Liệt kê tất cả các mẫu image tích hợp sẵn.
|
||||
|
||||
> "Image" (ảnh) được đề cập ở đây có thể hiểu là "gói nén chứa mã và môi trường chạy". Khi một dịch vụ đã chạy thành công trên một máy chủ, chúng ta có thể chọn đóng gói "môi trường chạy + mã" thành image. Sau đó, trên bất kỳ máy chủ mới nào, chỉ cần giải nén và chạy gói này, không cần cấu hình lại môi trường và mã, dịch vụ có thể chạy ngay.
|
||||
|
||||
Ở góc phải phía trên trang, bạn cũng có thể thấy số dư của mình. Theo mặc định, mỗi tháng sẽ có khoảng 5 USD miễn phí. Về quy tắc tính phí chi tiết, bạn có thể tạm thời không cần quan tâm quá nhiều, chỉ cần biết: miễn là máy chủ đang chạy, sẽ tiêu tốn额度.
|
||||
|
||||
|
||||
|
||||
Nhấp vào số dư để xem chi tiết tiêu thụ hàng ngày.
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta sẽ tạo dịch vụ Dify riêng. Đầu tiên, tại [trang chủ bảng điều khiển](https://zeabur.com/projects), nhấp vào "New Project".
|
||||
|
||||
|
||||
|
||||
Tiếp theo là giải thích về các phương pháp tạo:
|
||||
|
||||
1. **GitHub**
|
||||
Có thể kết nối với tài khoản GitHub của bạn. Sau khi liên kết, bạn có thể chọn trực tiếp dự án từ kho GitHub để triển khai (GitHub là nền tảng lưu trữ mã lớn nhất thế giới hiện nay).
|
||||
2. **Template (mẫu)**
|
||||
Có thể triển khai dịch vụ dựa trên mẫu. Zeabur tích hợp nhiều mẫu dự án có sẵn (ví dụ Dify, n8n, v.v.), bạn có thể tạo và triển khai ứng dụng nhanh chóng dựa trên các mẫu này.
|
||||
|
||||
3. **Databases (cơ sở dữ liệu)**
|
||||
Dùng để triển khai dịch vụ cơ sở dữ liệu, như MySQL, MongoDB và các cơ sở dữ liệu phổ biến khác.
|
||||
|
||||
4. **Functions (hàm)**
|
||||
Có thể triển khai dịch vụ hàm, bạn có thể viết mã JavaScript hoặc Python, để chúng được gọi dưới dạng hàm.
|
||||
|
||||
|
||||
|
||||
|
||||
5. **Local Project (dự án cục bộ)**
|
||||
Tải lên một thư mục cục bộ, Zeabur sẽ tự động nhận dạng script khởi động trong đó. Phù hợp để nhanh chóng triển khai dự án đã phát triển cục bộ lên Zeabur.
|
||||
|
||||
6. **Docker Image**
|
||||
Triển khai Docker image đã đóng gói. Nếu dự án của bạn đã được đóng gói thành Docker image (ví dụ lưu trữ trên Docker Hub hoặc kho image khác), có thể triển khai trực tiếp tại đây.
|
||||
|
||||
7. **Cursor**
|
||||
Nếu bạn đã cài đặt Cursor (ví dụ Cursor IDE), có thể triển khai trực tiếp dự án trong Cursor lên Zeabur qua cổng này.
|
||||
|
||||
Nếu bạn muốn triển khai dịch vụ Dify riêng, nên chọn phương thức **Template**, sau đó nhập "dify" vào ô tìm kiếm. Bạn sẽ thấy nhiều phiên bản do các tác giả khác nhau bảo trì, có thể chọn bất kỳ phiên bản nào (ví dụ phiên bản v1.6.0).
|
||||
|
||||
|
||||
|
||||
Tiếp theo, nhập bất kỳ tên nào, Zeabur sẽ tạo một tên miền tùy chỉnh tạm thời dựa trên tên này. Sau đó tất cả mọi người đều có thể truy cập dịch vụ của bạn qua địa chỉ web này.
|
||||
|
||||
|
||||
|
||||
Sau khi tạo xong, bạn sẽ thấy nhiều chương trình (dịch vụ) khởi động lần lượt. Cần kiên nhẫn đợi tất cả dịch vụ vào trạng thái "đã khởi động". (Dịch vụ Dify được cấu thành từ nhiều chương trình, mỗi chương trình chịu trách nhiệm các chức năng khác nhau, chúng sẽ phối hợp với nhau.)
|
||||
|
||||
Thông thường, bạn chỉ cần nhấp vào ứng dụng Dify bên trái để xem địa chỉ truy cập mặc định. Nhưng trong ví dụ này, vì phía trước còn có một lớp nginx, bạn cần nhấp vào dịch vụ nginx để lấy địa chỉ truy cập cuối cùng. Có thể hiểu: nginx là chương trình chính chịu trách nhiệm "nhận và gửi yêu cầu" đối ngoại thống nhất, nó sẽ phân phối địa chỉ truy cập bên ngoài cho các dịch vụ nội bộ khác. Nhấp vào Nginx bên trái, trong trang chi tiết bạn có thể thấy địa chỉ dịch vụ hiện tại, sau đó mở địa chỉ này trong trình duyệt, đợi dịch vụ khởi động hoàn toàn.
|
||||
|
||||
|
||||
|
||||
Sau khi đợi một lát, bạn sẽ thấy giao diện đăng nhập Dify. Nhập địa chỉ email và mật khẩu đăng ký, bạn có thể bắt đầu sử dụng dịch vụ Dify riêng của mình.
|
||||
|
||||
|
||||
|
||||
Nếu bạn quan tâm, bạn cũng có thể khởi động dịch vụ n8n. n8n cũng là một nền tảng quy trình làm việc AI rất phổ biến ở nước ngoài.
|
||||
|
||||
|
||||
|
||||
## Sử dụng Zeabur và Trae để triển khai trò chơi rắn ăn mồi
|
||||
|
||||
Trong phần tiếp theo của hướng dẫn này, chúng ta sẽ trải nghiệm một số cách sử dụng nâng cao của Zeabur. Đầu tiên, chúng ta sẽ dùng Trae để tạo một trò chơi rắn ăn mồi nhỏ, sau đó triển khai nó lên máy chủ Zeabur, và cấu hình một liên kết có thể truy cập công khai, để bất kỳ ai cũng có thể mở trò chơi của bạn.
|
||||
|
||||
Bước đầu tiên là tạo một dự án rắn ăn mồi bằng Trae tại máy cục bộ.
|
||||
|
||||
### Sử dụng framework HTML
|
||||
|
||||
|
||||
|
||||
Đối với Trae, việc tạo một trò chơi web rắn ăn mồi dựa trên HTML rất đơn giản. Sau khi trò chơi được tạo, bạn chỉ cần tải thư mục chứa tất cả các tệp lên theo cách triển khai cục bộ Zeabur đã giới thiệu trước đó.
|
||||
|
||||
|
||||
|
||||
Sau khi hoàn tất, bạn sẽ vào giao diện chi tiết của dịch vụ:
|
||||
|
||||
|
||||
|
||||
Nhấp vào tùy chọn "Network" bên trái, tìm khu vực "Public Address" trong trang. Nhấp vào "Generate Domain", có thể tạo một địa chỉ truy cập đối ngoại, bạn có thể nhập bất kỳ tên nào bạn thích.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sau khi tạo xong, chỉ cần mở địa chỉ này trong trình duyệt, bạn có thể chạy trò chơi rắn ăn mồi của riêng mình. Các ứng dụng Web kiểu HTML khác cũng có thể được triển khai theo cùng một cách.
|
||||
|
||||
|
||||
|
||||
### Sử dụng framework React
|
||||
|
||||
Trước đó chúng ta đã học cách triển khai ứng dụng Web dựa trên HTML. Tiếp theo, chúng ta sẽ thử triển khai một framework frontend phổ biến hơn hiện nay: ứng dụng React. So với HTML thuần, React được coi là một framework phát triển frontend trưởng thành và hiện đại hơn. Nó tổ chức cấu trúc trang theo cách component hóa, có thể tăng tốc độ phát triển trang phức tạp đáng kể, là lựa chọn rất phổ biến trong các dự án cấp doanh nghiệp.
|
||||
|
||||
|
||||
|
||||
#### Tái cấu trúc thành kiến trúc React
|
||||
|
||||
Trong Trae, bạn chỉ cần nói với Agent: "Hãy giúp tôi tái cấu trúc mã này thành kiến trúc React", là có thể khá dễ dàng chuyển đổi cấu trúc dựa HTML thành dự án React.
|
||||
|
||||
|
||||
|
||||
Tuy nhiên, so với tệp HTML đơn giản, ứng dụng React phụ thuộc vào công cụ xây dựng và cấu trúc dự án phức tạp hơn, nên quá trình triển khai cũng sẽ hơi phức tạp hơn một chút. Một vấn đề điển hình thể hiện ở cài đặt cổng: theo mặc định, ứng dụng React thường lắng nghe cổng 3000 (bạn cũng có thể thấy điều này trong tệp cấu hình hoặc nhật ký khởi động).
|
||||
|
||||
Tuy nhiên, triển khai trên Zeabur như vậy sẽ thất bại -- vì Zeabur chỉ hỗ trợ ứng dụng lắng nghe cổng 8080. Nghĩa là, nếu muốn ứng dụng React chạy bình thường trên Zeabur, chúng ta phải thay đổi cổng lắng nghe mặc định từ 3000 thành 8080.
|
||||
|
||||
Để cấu hình đúng bước này, chúng ta cần làm rõ hai khái niệm trước: "cổng (Port)" là gì, và "cổng lắng nghe (Listening Port)" có nghĩa là gì.
|
||||
|
||||
#### Cổng là gì?
|
||||
|
||||
> Trong mạng máy tính, cổng có thể hiểu là một "điểm cuối giao tiếp logic", dùng để phân biệt các dịch vụ mạng khác nhau đang chạy trên cùng một thiết bị. Nếu ví địa chỉ IP như một "số nhà" (ví dụ 162.128.1.1), thì số cổng giống như "số phòng" của các phòng khác nhau trong tòa nhà đó -- mỗi phòng tương ứng với một dịch vụ (ví dụ máy chủ Web, dịch vụ email, hoặc ứng dụng React của bạn).
|
||||
>
|
||||
> Số cổng được biểu diễn bằng số nguyên 16 bit, phạm vi giá trị từ 0 đến 65535.
|
||||
|
||||
Nếu không muốn nhớ các chi tiết này, có thể hiểu đơn giản: cổng là một phần cần thiết cấu thành "địa chỉ truy cập mạng".
|
||||
|
||||
Khi chúng ta truy cập trang web hoặc địa chỉ IP, thường không tự thêm số cổng, là vì cổng mặc định của Web là 80 hoặc 443 (HTTPS). Hầu hết trình duyệt sẽ tự động sử dụng các cổng tiêu chuẩn này. Đối với một số cổng đặc biệt, như cổng 3000 mặc định của React, cổng 8080 yêu cầu của Zeabur, chúng ta phải thêm `:3000` hoặc `:8080` sau địa chỉ để truy cập nội dung tương ứng.
|
||||
|
||||
#### "Cổng lắng nghe" là gì?
|
||||
|
||||
> "Cổng lắng nghe" là cổng mà một chương trình chủ động "mở và giám sát" trên một thiết bị. Khi một ứng dụng đặt cổng lắng nghe, thực chất là đang nói với hệ điều hành: "Tôi sẽ luôn đợi yêu cầu mạng trên cổng này -- miễn là có yêu cầu đến, xin hãy chuyển tiếp cho tôi."
|
||||
|
||||
Hiểu theo cách hình tượng hơn: giả sử máy tính của bạn là một tòa nhà văn phòng, địa chỉ IP là địa chỉ của tòa nhà. Trong tòa nhà có nhiều công ty hoặc phòng ban, chúng chiếm các phòng khác nhau, số phòng chính là số cổng.
|
||||
|
||||
Khi máy chủ phát triển React mặc định khởi động, nó sẽ "mở" cửa một phòng nào đó, và bố trí "lễ tân" trực tại cửa, số phòng này chính là cổng lắng nghe của nó -- 3000.
|
||||
|
||||
Đồng thời, chương trình React cũng sẽ nói với "quản lý tài sản" (hệ điều hành) của tòa nhà: "Tôi ở phòng 3000, xin hãy chuyển tất cả thư gửi đến phòng 3000 (yêu cầu mạng) cho tôi."
|
||||
|
||||
Như vậy, khi bạn truy cập trang web React, yêu cầu đầu tiên sẽ đến tòa nhà; quản lý thấy yêu cầu cần gửi đến phòng 3000, sẽ ngay lập tức chuyển yêu cầu cho "lễ tân" của React, do nó xử lý và trả kết quả -- đây là quá trình truy cập ứng dụng React.
|
||||
|
||||
Khi bạn thực thi `npm start` tại máy cục bộ (lệnh mặc định để khởi động máy chủ phát triển React cục bộ, cũng có thể thực thi trong thanh bên Agent của Vibe Coding), máy chủ phát triển React sẽ tự động đặt cổng lắng nghe thành 3000.
|
||||
Thiết kế nền tảng Zeabur quyết định nó chỉ sẽ "nhận dạng" ứng dụng lắng nghe cổng 8080. Nếu ứng dụng React của bạn vẫn sử dụng cổng 3000 mặc định, Zeabur sẽ không thể chuyển tiếp yêu cầu chính xác đến ứng dụng của bạn, cuối cùng dẫn đến triển khai thất bại.
|
||||
|
||||
#### Thay đổi cổng lắng nghe mặc định
|
||||
|
||||
Để thay đổi cổng lắng nghe mặc định của React (3000) thành 8080 như Zeabur yêu cầu, có nhiều cách. Cách đơn giản nhất là trực tiếp ra lệnh cho Agent trong Trae: "Hãy giúp tôi thay đổi cổng mặc định của dự án React này thành 8080." Trae sẽ giúp bạn sửa tệp cấu hình tương ứng trong dự án. Sau khi sửa xong, bạn chỉ cần đóng gói lại và tải lên Zeabur theo cách trước đó.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Trong cài đặt mạng, chỉ định một URL truy cập, cách làm về cơ bản giống với khi triển khai dự án HTML, là có thể khởi động dịch vụ phiên bản React.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Đối với các chương trình khác cần thay đổi số cổng, bạn cũng có thể áp dụng cùng một cách tiếp cận: thay cổng mặc định trước, sau đó tải lên Zeabur để triển khai. Đến đây, bạn đã nắm vững kỹ năng cơ bản để triển khai ứng dụng Web phổ biến lên máy chủ.
|
||||
|
||||
Bạn có thể thử để Trae giúp bạn xây dựng các ứng dụng loại khác nhau, và triển khai chúng lên máy chủ mặc định của Zeabur. Trong các bài học tiếp theo, chúng ta sẽ học cách triển khai ứng dụng lên máy chủ đám mây do chính bạn mua.
|
||||
|
||||
---
|
||||
|
||||
# Cách dừng và xóa dự án (Zeabur)
|
||||
|
||||
Vì việc kích hoạt tài nguyên liên quan đến máy chủ sẽ phát sinh chi phí, chúng ta phải hình thành thói quen "đóng dịch vụ không sử dụng kịp thời" khi sử dụng, tránh tiêu hết gói miễn phí hàng tháng.
|
||||
|
||||
Nếu muốn tìm cổng quản lý dự án, đầu tiên nhấp vào "Settings" trong dự án.
|
||||
|
||||
|
||||
|
||||
Sau khi vào trang cài đặt, kéo trang xuống dưới cùng, bạn sẽ thấy giao diện tương tự:
|
||||
|
||||
|
||||
|
||||
Bạn có thể nhấp vào "Suspend All Services" để tạm dừng tất cả dịch vụ nhằm giảm chi phí; nếu dịch vụ gặp vấn đề, có thể nhấp vào "Restart All Services" để khởi động lại tất cả dịch vụ. Nếu bạn chắc chắn không cần dự án này nữa, có thể nhấp vào "Delete Project" để xóa hoàn toàn dự án.
|
||||
|
||||
---
|
||||
|
||||
# Tổng kết
|
||||
|
||||
Trong hướng dẫn này, chúng tôi đã giới thiệu bốn nền tảng triển khai ứng dụng Web phổ biến:
|
||||
|
||||
1. **Tencent CloudBase**: Phù hợp cho người dùng trong nước, tốc độ truy cập nhanh, tích hợp tốt với hệ sinh thái WeChat
|
||||
2. **Vercel**: Phù hợp cho dự án sử dụng framework frontend hiện đại, tích hợp chặt chẽ với GitHub, CDN toàn cầu
|
||||
3. **Netlify**: Chức năng toàn diện, hỗ trợ xử lý biểu mẫu và xác thực, phù hợp cho trang web tĩnh cần tính năng nâng cao
|
||||
4. **Zeabur**: Phù hợp cho dự án phức tạp, mẫu dịch vụ phong phú, hỗ trợ nhiều phương pháp triển khai
|
||||
|
||||
Chọn nền tảng nào phụ thuộc vào nhu cầu cụ thể của bạn:
|
||||
- Nếu chủ yếu hướng tới người dùng trong nước, nên chọn **CloudBase**
|
||||
- Nếu sử dụng React/Next.js và các framework, nên chọn **Vercel** hoặc **Netlify**
|
||||
- Nếu cần xử lý biểu mẫu, xác thực và các tính năng nâng cao, nên chọn **Netlify**
|
||||
- Nếu cần triển khai Dify, n8n và các dịch vụ khác, nên chọn **Zeabur**
|
||||
|
||||
Bất kể chọn nền tảng nào, quy trình cốt lõi của triển khai đều tương tự: chuẩn bị mã -> chọn nền tảng -> cấu hình cài đặt xây dựng -> triển khai lên mạng. Sau khi nắm vững các kỹ năng này, bạn có thể chia sẻ ứng dụng đã phát triển với cả thế giới!
|
||||
@@ -0,0 +1,361 @@
|
||||
# Từ nguyên mẫu thiết kế đến code dự án
|
||||
|
||||
::: tip 🎯 Vấn đề cốt lõi
|
||||
**Làm thế nào để chuyển nguyên mẫu từ công cụ thiết kế thành code frontend thực sự có thể chạy trong trình duyệt?**
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. Ba con đường từ nguyên mẫu đến code
|
||||
|
||||
Sau khi hoàn thành thiết kế giao diện bằng các công cụ thiết kế frontend hiện đại như Figma, MasterGo, một câu hỏi rất thực tế tự nhiên xuất hiện: làm thế nào để chuyển những bản thiết kế có cấu trúc hoàn chỉnh này thành code frontend thực sự có thể chạy trong trình duyệt?
|
||||
|
||||
Nói chung, việc chuyển từ nguyên mẫu đến code có ba con đường điển hình:
|
||||
|
||||
| Con đường | Phương pháp | Đặc điểm | Kịch bản phù hợp |
|
||||
|-----------|-------------|----------|------------------|
|
||||
| **Con đường 1** | Dựa trên hình ảnh, sử dụng mô hình đa phương thức lớn để trực tiếp khôi phục code | Linh hoạt, không cần công cụ cụ thể | Xác minh nguyên mẫu nhanh, trang đơn giản |
|
||||
| **Con đường 2** | Xuất code sử dụng được thông qua khả năng của nền tảng hoặc plugin | Độ khôi phục cao, khả năng chỉnh sửa mạnh | Người dùng Figma/MasterGo |
|
||||
| **Con đường 3** | Nền tảng kết hợp khả năng MCP để xuất code sử dụng được | Mức độ tự động hóa cao, có thể tùy chỉnh | Quy trình làm việc cần tích hợp sâu |
|
||||
|
||||
Bài viết này sẽ giới thiệu chi tiết phương pháp thực hiện cụ thể của ba con đường này, giúp bạn chọn quy trình làm việc phù hợp nhất theo nhu cầu dự án.
|
||||
|
||||
::: tip 📚 Kiến thức tiên quyết
|
||||
Trước khi bắt đầu phần này, khuyến nghị bạn học trước hướng dẫn [Giới thiệu Figma và MasterGo](../figma-mastergo/), nắm vững các thao tác cơ bản của công cụ thiết kế frontend.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 2. Con đường 1: AI đa phương thức trực tiếp khôi phục code
|
||||
|
||||
Các mô hình_large có khả năng thị giác vốn sẵn có khả năng chuyển ảnh thành code. Chúng ta chỉ cần import screenshot bản thiết kế trực tiếp vào hộp thoại, sau đó để mô hình_large tạo code kết quả hoàn chỉnh.
|
||||
|
||||
### 2.1 Quy trình thao tác
|
||||
|
||||
1. **Chụp screenshot bản thiết kế**
|
||||
- Trong Figma hoặc MasterGo, xuất trang đã thiết kế thành PNG hoặc JPG
|
||||
- Đảm bảo screenshot bao gồm bố cục trang hoàn chỉnh
|
||||
|
||||
2. **Chọn mô hình AI đa phương thức**
|
||||
- Có thể sử dụng các mô hình hỗ trợ đầu vào hình ảnh như Gemini, Qwen, Claude
|
||||
- Ở đây lấy Gemini làm ví dụ demo
|
||||
|
||||
3. **Viết prompt**
|
||||
```
|
||||
Xin tạo code HTML/CSS tương ứng dựa trên bản thiết kế này.
|
||||
Yêu cầu:
|
||||
- Sử dụng layout CSS hiện đại (Flexbox/Grid)
|
||||
- Responsive design, thích ứng các kích thước màn hình khác nhau
|
||||
- Bao gồm tất cả các yếu tố UI nhìn thấy được
|
||||
- Màu sắc, kích thước font cố gắng khôi phục theo bản thiết kế
|
||||
```
|
||||
|
||||
|
||||
|
||||
4. **Lấy và lưu code**
|
||||
- Yêu cầu mô hình trả về code HTML hoàn chỉnh
|
||||
- Lưu thành file `.html` đơn lẻ, thuận tiện kiểm thử cục bộ
|
||||
- Sau đó có thể chuyển đổi thành các framework như React trong IDE cục bộ
|
||||
|
||||
### 2.2 Các vấn đề phổ biến và giải pháp
|
||||
|
||||
Tạo trang không phải là nhiệm vụ đơn giản, trong quá trình cụ thể bạn có thể gặp nhiều vấn đề:
|
||||
|
||||
| Vấn đề | Giải pháp |
|
||||
|---------|-----------|
|
||||
| Bố cục giao diện không đều | Mô tả vấn đề bố cục cụ thể cho AI, yêu cầu điều chỉnh CSS margin/padding |
|
||||
| Giao diện hiển thị không đầy đủ | Kiểm tra xem đã đặt viewport đúng chưa, yêu cầu thêm responsive breakpoint |
|
||||
| Màu sắc khôi phục không chính xác | Sử dụng công cụ lấy màu để lấy giá trị màu chính xác từ bản thiết kế, cung cấp cho AI |
|
||||
| Font không khớp | Chỉ định tên font cụ thể hoặc yêu cầu sử dụng Google Fonts thay thế |
|
||||
|
||||
::: tip 💡 Mẹo nhỏ
|
||||
Khuyến nghị tạo code HTML trước, sau khi nhận được thì sử dụng IDE cục bộ để chuyển đổi thành framework React. Bằng cách này bạn có thể nhận được nhiều file HTML độc lập, tiến hành chuyển đổi framework thống nhất.
|
||||
:::
|
||||
|
||||
### 2.3 MasterGo AI tạo trang
|
||||
|
||||
MasterGo cũng cung cấp chức năng tạo trang AI mạnh mẽ, có thể trực tiếp tạo code trang web sử dụng được dựa trên ảnh tham khảo.
|
||||
|
||||
#### Tìm lối vào chức năng AI
|
||||
|
||||
Trong thanh công cụ phía trên giao diện chỉnh sửa MasterGo, bạn có thể tìm thấy nút công cụ AI:
|
||||
|
||||
|
||||
|
||||
#### Quy trình tạo
|
||||
|
||||
1. **Tải lên ảnh tham khảo**
|
||||
- Sử dụng cùng cách với AI đa phương thức để tải lên ảnh tham khảo thiết kế
|
||||
- Thêm mô tả văn bản yêu cầu
|
||||
|
||||
2. **Xem kết quả tạo**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. **Lấy code**
|
||||
- Nhấp nút xanh "Chèn vào canvas", có thể trực tiếp chỉnh sửa trang web sau khi tạo
|
||||
- Hoặc nhấp nút "Code" bên phải, sao chép nội dung code về cục bộ
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3. Con đường 2: Khả năng của nền tảng hoặc plugin xuất code
|
||||
|
||||
### 3.1 Figma Make tạo code
|
||||
|
||||
Figma Make là công cụ thiết kế AI chính thức do Figma ra mắt, có thể dựa trên prompt do người dùng nhập hoặc ảnh tham khảo, khôi phục giao diện UI nguyên mẫu trang web với độ chính xác cao.
|
||||
|
||||
#### Đặc điểm chức năng
|
||||
|
||||
- **Khôi phục độ chính xác cao**: So với code tạo bằng AI gốc, hiệu quả tốt hơn
|
||||
- **Khả năng chỉnh sửa**: Kết quả tạo có thể chuyển đổi thành file Figma Design có thể chỉnh sửa
|
||||
- **Tích hợp GitHub**: Hỗ trợ đồng bộ code trực tiếp lên GitHub
|
||||
|
||||
::: tip 🔑 Mô tả quyền
|
||||
Sử dụng đầy đủ chức năng Figma Make cần quyền người dùng Pro, sinh viên có thể nhận miễn phí quyền Pro thông qua xác thực giáo dục.
|
||||
:::
|
||||
|
||||
#### Các bước thao tác
|
||||
|
||||
1. **Vào Figma Make**
|
||||
- Nhấp nút Make trên trang chủ Figma
|
||||
- Hoặc truy cập [Figma Make](https://www.figma.com/make)
|
||||
|
||||
2. **Tải lên ảnh tham khảo**
|
||||
- Tải bản thiết kế bạn muốn khôi phục vào hộp thoại
|
||||
- Thêm prompt mô tả yêu cầu
|
||||
|
||||
|
||||
|
||||
3. **Xem kết quả tạo**
|
||||
- Đợi một lúc sẽ thấy kết quả render
|
||||
- Nhấp nút play ở góc trên bên phải để xem trước toàn màn hình
|
||||
|
||||
|
||||
|
||||
4. **Điều chỉnh chi tiết**
|
||||
- Nhấp icon editor ở góc trên bên phải (icon chuột và thước)
|
||||
- Quay lại giao diện Figma Editor quen thuộc để điều chỉnh chi tiết
|
||||
|
||||
|
||||
|
||||
5. **Xuất code**
|
||||
- Sau khi điều chỉnh hài lòng, chọn xuất code
|
||||
- Có thể kết nối trực tiếp với GitHub để lưu code
|
||||
|
||||
|
||||
|
||||
### 3.2 Plugin xuất code
|
||||
|
||||
Ngoài chức năng AI gốc của nền tảng, cả Figma và MasterGo đều hỗ trợ xuất code thông qua plugin:
|
||||
|
||||
**Plugin Figma phổ biến:**
|
||||
- **Figma to Code**: Chuyển bản thiết kế thành code React, Vue, HTML, v.v.
|
||||
- **Anima**: Tạo code high-fidelity, hỗ trợ hiệu ứng tương tác
|
||||
- **Locofy**: Công cụ chuyển thiết kế thành code do AI điều khiển
|
||||
|
||||
**Các bước sử dụng:**
|
||||
1. Mở bảng plugin trong Figma (Plugins)
|
||||
2. Tìm kiếm và cài đặt plugin xuất code cần thiết
|
||||
3. Chọn yếu tố thiết kế cần xuất
|
||||
4. Chạy plugin, chọn framework mục tiêu và định dạng code
|
||||
5. Sao chép hoặc tải xuống code đã tạo
|
||||
|
||||
---
|
||||
|
||||
## 4. Con đường 3: Nền tảng kết hợp khả năng MCP xuất code
|
||||
|
||||
### 4.1 MCP là gì?
|
||||
|
||||
MCP (Model Context Protocol, Giao thức Bối cảnh Mô hình) là một giao thức tiêu chuẩn mở, cho phép mô hình AI truy cập an toàn và có kiểm soát vào các công cụ và nguồn dữ liệu bên ngoài. Trong kịch bản công cụ thiết kế frontend, MCP cho phép mô hình_large trực tiếp đọc cấu trúc, kiểu dáng và thông tin component của file thiết kế, từ đó tạo code chính xác hơn.
|
||||
|
||||
### 4.2 Nguyên lý hoạt động của MCP
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ Mô hình AI │ ←→ │ MCP Server │ ←→ │ Công cụ thiết kế │
|
||||
│ (Claude, v.v.) │ │ (Protocol adapter) │ │(Figma/MasterGo)│
|
||||
└─────────────┘ └─────────────┘ └─────────────┘
|
||||
```
|
||||
|
||||
**Quy trình làm việc:**
|
||||
1. Mô hình AI gửi yêu cầu đến công cụ thiết kế thông qua giao thức MCP
|
||||
2. Công cụ thiết kế trả về dữ liệu thiết kế có cấu trúc (layer, style, component, v.v.)
|
||||
3. Mô hình AI hiểu cấu trúc thiết kế và tạo code tương ứng
|
||||
4. Code có thể xuất trực tiếp hoặc đồng bộ đến môi trường phát triển
|
||||
|
||||
### 4.3 Thực hành Figma + MCP
|
||||
|
||||
#### Chuẩn bị môi trường
|
||||
|
||||
1. **Cài đặt MCP Server**
|
||||
```bash
|
||||
# Sử dụng npx cài đặt Figma MCP Server
|
||||
npx figma-mcp-server
|
||||
```
|
||||
|
||||
2. **Cấu hình Claude Desktop hoặc công cụ AI hỗ trợ MCP khác**
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"figma": {
|
||||
"command": "npx",
|
||||
"args": ["figma-mcp-server"],
|
||||
"env": {
|
||||
"FIGMA_ACCESS_TOKEN": "your-figma-token"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. **Lấy Figma Access Token**
|
||||
- Đăng nhập Figma → Settings → Personal Access Tokens
|
||||
- Tạo Token mới và lưu lại
|
||||
|
||||
#### Quy trình sử dụng
|
||||
|
||||
1. **Kích hoạt kết nối MCP trong công cụ AI**
|
||||
- Mở Claude Code hoặc IDE hỗ trợ MCP khác
|
||||
- Xác nhận MCP Server đã kết nối
|
||||
|
||||
2. **Cung cấp liên kết file thiết kế**
|
||||
```
|
||||
Người dùng: Xin giúp tôi chuyển thiết kế Figma này thành code React
|
||||
Liên kết: https://www.figma.com/file/xxxxx
|
||||
|
||||
AI: Tôi đã kết nối với Figma thông qua MCP, đang đọc cấu trúc file thiết kế...
|
||||
```
|
||||
|
||||
3. **AI tự động phân tích và tạo code**
|
||||
- MCP Server lấy layer tree của file thiết kế
|
||||
- AI hiểu cấu trúc component và thuộc tính style
|
||||
- Tạo React/Vue component với naming và cấu trúc chính xác
|
||||
|
||||
4. **Lặp lại và tối ưu**
|
||||
```
|
||||
Người dùng: Xin trích xuất button component thành một component độc lập có thể tái sử dụng
|
||||
|
||||
AI: Đã hiểu, tôi đã nhận diện Button component trong design system thông qua MCP,
|
||||
đang tạo React component với interface props...
|
||||
```
|
||||
|
||||
### 4.4 Lợi thế của MCP
|
||||
|
||||
| Tính năng | Phương pháp truyền thống | Phương pháp MCP |
|
||||
|-----------|--------------------------|-----------------|
|
||||
| **Độ chính xác dữ liệu** | Dựa vào screenshot, có thể mất chi tiết | Trực tiếp đọc dữ liệu thiết kế gốc |
|
||||
| **Nhận diện component** | AI cần đoán ranh giới component | Chính xác lấy định nghĩa component |
|
||||
| **Khôi phục style** | Dựa trên ước tính pixel | Lấy design token chính xác |
|
||||
| **Hiệu quả lặp lại** | Mỗi lần sửa đổi cần chụp lại | Đồng bộ thay đổi thiết kế theo thời gian thực |
|
||||
| **Mức độ tự động hóa** | Thủ công sao chép dán | Có thể trực tiếp ghi vào file dự án |
|
||||
|
||||
### 4.5 Công cụ MCP hiện có
|
||||
|
||||
**MCP công cụ thiết kế:**
|
||||
- **Figma MCP Server**: Triển khai MCP được hỗ trợ chính thức
|
||||
- **MasterGo MCP**: Adapter MasterGo do cộng đồng phát triển
|
||||
|
||||
**MCP môi trường phát triển:**
|
||||
- **Claude Code**: Hỗ trợ gốc giao thức MCP
|
||||
- **Cline**: Plugin VS Code, hỗ trợ kết nối MCP
|
||||
- **Trae**: Có thể kích hoạt chức năng MCP thông qua cấu hình
|
||||
|
||||
::: tip 🔮 Triển vọng tương lai
|
||||
Giao thức MCP đang phát triển nhanh chóng, trong tương lai tích hợp giữa công cụ thiết kế và môi trường phát triển sẽ chặt chẽ hơn. Dự kiến sẽ xuất hiện nhiều giải pháp đồng bộ thiết kế thành code chỉ bằng một cú nhấp hơn nữa, rút ngắn khoảng cách giữa thiết kế và phát triển.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. Công việc sau khi xuất code
|
||||
|
||||
### 5.1 Kiểm thử cục bộ
|
||||
|
||||
Sau khi lấy code, mở trong IDE cục bộ và kiểm thử:
|
||||
|
||||
1. **Tạo dự án mới**
|
||||
```bash
|
||||
# Nếu là file HTML, mở trực tiếp bằng trình duyệt
|
||||
open index.html
|
||||
|
||||
# Nếu là dự án React/Vue
|
||||
npm install
|
||||
npm run dev
|
||||
```
|
||||
|
||||
2. **Cộng tác với AI IDE**
|
||||
- Import code đã tạo vào Trae hoặc AI IDE khác
|
||||
- Để AI giúp sửa vấn đề bố cục, thêm chức năng tương tác
|
||||
|
||||
### 5.2 Xử lý vấn đề phổ biến
|
||||
|
||||
| Giai đoạn | Vấn đề | Giải pháp |
|
||||
|-----------|--------|-----------|
|
||||
| Bố cục | Yếu tố bị lệch | Kiểm tra thuộc tính display và position của CSS |
|
||||
| Style | Màu sắc không nhất quán | Sử dụng developer tool của trình duyệt kiểm tra giá trị màu thực tế |
|
||||
| Responsive | Hiển thị trên mobile bất thường | Thêm media query breakpoint |
|
||||
| Tương tác | Nút không phản hồi | Kiểm tra event binding của JavaScript |
|
||||
|
||||
---
|
||||
|
||||
## 6. So sánh ba con đường và đề xuất lựa chọn
|
||||
|
||||
### 6.1 So sánh các con đường
|
||||
|
||||
| Chiều | Con đường 1: AI đa phương thức | Con đường 2: Khả năng nền tảng | Con đường 3: MCP |
|
||||
|-------|-------------------------------|-------------------------------|-------------------|
|
||||
| **Độ khó bắt đầu** | ⭐ Đơn giản | ⭐⭐ Trung bình | ⭐⭐⭐ Khá phức tạp |
|
||||
| **Độ chính xác khôi phục** | ⭐⭐⭐ Trung bình | ⭐⭐⭐⭐ Cao | ⭐⭐⭐⭐⭐ Cao nhất |
|
||||
| **Tính linh hoạt** | ⭐⭐⭐⭐⭐ Cao | ⭐⭐⭐ Trung bình | ⭐⭐⭐⭐ Khá cao |
|
||||
| **Mức độ tự động hóa** | ⭐⭐ Thấp | ⭐⭐⭐ Trung bình | ⭐⭐⭐⭐⭐ Cao |
|
||||
| **Chi phí** | Thấp (tính theo API call) | Trung bình (có thể cần Pro) | Thấp (công cụ mã nguồn mở) |
|
||||
|
||||
### 6.2 Đề xuất lựa chọn
|
||||
|
||||
**Chọn con đường 1 (AI đa phương thức) nếu:**
|
||||
- Cần nhanh chóng xác minh ý tưởng
|
||||
- Công cụ thiết kế không cố định, thường xuyên chuyển đổi
|
||||
- Không yêu cầu cao về độ chính xác khôi phục
|
||||
- Ngân sách hạn chế
|
||||
|
||||
**Chọn con đường 2 (Khả năng nền tảng) nếu:**
|
||||
- Đội nhóm chủ yếu sử dụng Figma hoặc MasterGo
|
||||
- Cần khôi phục code với độ chính xác cao
|
||||
- Designer và developer cần cộng tác thường xuyên
|
||||
- Sẵn sàng đầu tư phiên bản Pro
|
||||
|
||||
**Chọn con đường 3 (MCP) nếu:**
|
||||
- Theo đuổi mức độ tự động hóa cao nhất
|
||||
- Có khả năng kỹ thuật cấu hình môi trường MCP
|
||||
- Dự án cần lặp lại từ thiết kế đến code thường xuyên
|
||||
- Muốn xây dựng quy trình thiết kế-phát triển tiêu chuẩn hóa
|
||||
|
||||
---
|
||||
|
||||
## 7. Tổng kết
|
||||
|
||||
Thông qua việc học chương này, bạn đã nắm vững ba con đường cốt lõi từ nguyên mẫu thiết kế đến code:
|
||||
|
||||
1. **Chuyển đổi trực tiếp bằng AI đa phương thức**: Linh hoạt và nhanh chóng, phù hợp để xác minh nguyên mẫu
|
||||
2. **Khả năng gốc của nền tảng**: Độ khôi phục cao, phù hợp cho quy trình thiết kế chuyên nghiệp
|
||||
3. **Tích hợp giao thức MCP**: Mức độ tự động hóa cao nhất, đại diện cho xu hướng tương lai
|
||||
|
||||
::: tip 💡 Thực hành tốt nhất
|
||||
- **Người mới khuyến nghị**: Bắt đầu từ con đường 1 (AI đa phương thức), nhanh chóng làm quen
|
||||
- **Cộng tác đội nhóm**: Sử dụng con đường 2 (Khả năng nền tảng), đảm bảo tính nhất quán thiết kế
|
||||
- **Ưu tiên hiệu quả**: Thử con đường 3 (MCP), xây dựng quy trình làm việc tự động hóa
|
||||
- **Sử dụng kết hợp**: Chuyển đổi linh hoạt giữa các con đường khác nhau theo giai đoạn dự án
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Tài nguyên tham khảo
|
||||
|
||||
- [Giới thiệu Figma và MasterGo](../figma-mastergo/) - Học kiến thức cơ bản về công cụ thiết kế
|
||||
- [Cùng làm Chân dung Hogwarts](../hogwarts-portraits/) - Thực hành dự án hoàn chỉnh
|
||||
- [Tài liệu chính thức MCP](https://modelcontextprotocol.io/) - Tìm hiểu chi tiết giao thức
|
||||
- [Tài liệu chính thức Figma Make](https://help.figma.com/hc/en-us/sections/360007453634-Figma-Make)
|
||||
- [Hướng dẫn MasterGo AI](https://mastergo.com/tutorials)
|
||||
@@ -0,0 +1,303 @@
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['vi-vn/stage-2/frontend/figma-mastergo'] ?? []
|
||||
</script>
|
||||
|
||||
# Giới thiệu Figma và MasterGo
|
||||
|
||||
::: tip 🎯 Vấn đề cốt lõi
|
||||
**Làm thế nào để sử dụng công cụ thiết kế hiện đại để tạo nguyên mẫu trang web từ con số không?**
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. Tại sao cần học công cụ thiết kế frontend?
|
||||
|
||||
Trước khi bắt đầu, chúng ta cần hiểu một vấn đề: tại sao cần học "công cụ thiết kế frontend"? Dù sao thì viết code HTML/CSS trực tiếp cũng có thể tạo ra trang web, việc học thêm một phần mềm và công nghệ mới có thực sự cần thiết không?
|
||||
|
||||
Thực tế, việc chạy được trang web và thiết kế sản phẩm tốt là hai khái niệm hoàn toàn khác nhau. Code chỉ giải quyết vấn đề render trên trình duyệt, chạy trên các thiết bị khác nhau; công cụ thiết kế frontend giải quyết vấn đề phân bố thông tin, sắp xếp tương tác frontend như thế nào, chuyển trang khác nhau ra sao, phân bổ ưu tiên thị giác thế nào. Chỉ cần tạo một canvas trong công cụ thiết kế là có thể so sánh và xác định layout, phân cấp thông tin và phương thức tương tác trên một màn hình, chọn hiệu quả trình bày phù hợp nhất.
|
||||
|
||||
Nếu bắt đầu viết code trực tiếp hoặc dùng AI tạo trang frontend hoàn chỉnh, trải nghiệm người dùng thường không tốt lắm. Sản phẩm nghiêm túc sẽ cân nhắc đến độ thoải mái của tương tác người dùng và frontend, cũng như phân bố nội dung mà các trang khác nhau muốn truyền đạt, từ góc độ người dùng sắp xếp trang frontend trước, sau đó mới chuyển đổi hoặc tạo code.
|
||||
|
||||
Ngoài ra, từ góc độ hợp tác nhóm, công cụ thiết kế frontend còn giảm chi phí hợp tác giữa nhiều bên: nhà thiết kế, sản phẩm, phát triển không còn mỗi người tưởng tượng hoặc mô tả code trừu tượng, mà hỗ trợ nhiều người cộng tác, mọi người có thể thảo luận quản lý phiên bản, thay đổi yêu cầu, phản hồi xung quanh một canvas có thể nhìn thấy, có thể chú thích, có thể lặp lại. Hơn thế nữa, công cụ thiết kế frontend hiện đại không chỉ là phần mềm vẽ, một click tạo code một phần, quản lý hệ thống thiết kế và thư viện component, công cụ thiết kế thời đại mới đã có thể tự động hóa hoặc hàng loạt hóa nhiều công việc lặp đi lặp lại (căn chỉnh, chú thích, xuất, thay đổi style), thúc đẩy đáng kể hiệu quả phát triển thiết kế trang.
|
||||
|
||||
|
||||
|
||||
### 1.1 Sự tiến hóa của công cụ thiết kế frontend
|
||||
|
||||
Trong dòng chảy thời gian, cái gọi là công cụ thiết kế frontend thực chất là một công nghệ liên tục tiến hóa. Từ thời Photoshop chủ yếu chỉnh sửa bitmap cục bộ những năm 90, đến khoảng năm 2010 Sketch mang đến workflow vector hóa, component hóa, rồi sau 2016 Figma đưa cộng tác lên đám mây hoàn toàn, đội thiết kế từ làm việc đơn độc dần chuyển sang cộng tác thời gian thực nhiều người. Đến năm 2025, AI đã thực sự tích hợp vào bên trong các công cụ này: từ "tạo bản nháp trang web theo một câu mô tả", đến "chuyển thiết kế trực tiếp thành cấu trúc frontend có thể chạy", "thiết kế chính là code", "người và máy cùng sáng tạo" đang từ khái niệm trở thành năng lực sản xuất thực tế.
|
||||
|
||||
Trong phần này, chúng ta sẽ chọn hai công cụ thiết kế frontend hiện đại đại diện nhất để giới thiệu: Figma và MasterGo. Một mặt, cả hai đều bao phủ các năng lực cốt lõi mà UI/UX hiện đại cần (chỉnh sửa vector, hệ thống component, tự động layout, giao code, v.v.), có thể hỗ trợ bạn hoàn thành vòng lặp hoàn chỉnh từ wireframe đến high-fidelity đến bàn giao phát triển; mặt khác, hai công cụ này đã lần lượt tích hợp các chức năng AI thực tế sau năm 2025, giúp bạn đảm bảo nguyên mẫu không đổi đồng thời chuyển thiết kế thành chương trình thực sự có thể chạy.
|
||||
|
||||
## 1.2 Hành trình ra đời
|
||||
|
||||
|
||||
|
||||
Trong thời kỳ chưa có công cụ thiết kế frontend chuyên dụng, toàn bộ công việc thiết kế thị giác của ngành thiết kế giao diện trong thời gian dài đều do phần mềm thiết kế "đa năng" như Photoshop đảm nhận. Nhà thiết kế sẽ tạo lớp layer lớp layer tại địa phương, hoàn thành thiết kế hiệu quả thị giác tổng thể trang một cách tỉ mỉ, cuối cùng bàn giao file nguồn .psd khá lớn cho kỹ sư frontend - mà frontend muốn khôi phục chính xác thiết kế, còn phải hoàn thành thủ công ba công việc phức tạp và quan trọng:
|
||||
|
||||
Thứ nhất là "cắt ảnh": cần từ cấu trúc nhiều layer của file .psd, tách riêng từng phần tử thị giác độc lập như nút bấm, icon, Logo, module nền, rồi xuất sang định dạng hình ảnh mà web có thể tải trực tiếp như PNG, JPG (vì web không thể nhận diện thông tin layer PSD, chỉ dựa vào các hình ảnh đã tách để thể hiện chi tiết);
|
||||
|
||||
|
||||
|
||||
Thứ hai là "đo kích thước": phải dùng công cụ đo tích hợp, xác nhận từng kích thước chiều rộng chiều cao, khoảng cách giữa các module khác nhau (margin/padding) và các dữ liệu khác, đảm bảo tất cả kích thước chính xác đến pixel;
|
||||
|
||||
|
||||
|
||||
Thứ ba là "trích chú thích": cần trích xuất từ thiết kế các tham số "không nhìn thấy nhưng bắt buộc phải có" - như kích thước chữ, font-weight, line-height, giá trị màu RGB hoặc HEX của mỗi khối màu, tương đương với việc "thông số kỹ thuật thiết kế" mà nhà thiết kế không viết trên giấy phải được "trích" thủ công.
|
||||
|
||||
|
||||
|
||||
Sau đó, giai đoạn hiện thực frontend mới thực sự bắt đầu. Dù sử dụng HTML/CSS/JS gốc hay dựa trên framework Vue, React, quá trình bản chất là giống nhau. Frontend sẽ lấy "container làm载体 cốt lõi", tái xây dựng cấu trúc trang theo phân cấp và ngữ nghĩa của các module trong thiết kế. Container ở đây là đơn vị có ranh giới layout rõ ràng, chuyên chứa và tổ chức các phần tử con, nó không trực tiếp thể hiện nội dung cụ thể, mà thông qua các quy tắc như Flex, Grid, vạch phạm vi sắp xếp cho các phần tử bên trong. "Khối cấu trúc" (như thanh điều hướng trên cùng, sidebar, khu vực danh sách bài viết, chân trang dưới cùng v.v.) dựa vào container tồn tại; bên trong mỗi khối cấu trúc, lại lồng các container nhỏ hơn để tổ chức phần tử, ví dụ một mục danh sách bài viết sẽ được "container mục danh sách" điều khiển padding và layout tổng thể, rồi bọc các phần tử chi tiết như tiêu đề, tóm tắt, thời gian, icon bìa.
|
||||
|
||||
|
||||
|
||||
Trong framework frontend hiện đại, các "khối cấu trúc (và container & phần tử liên quan)" này thường được hiện thực thành "component". Component có thể hiểu đơn giản là đơn vị giao diện tái sử dụng có ranh giới rõ ràng, tích hợp layout container và logic, nó vừa chứa container điều khiển ngoại hình và sắp xếp (ví dụ "component nút bấm" dùng container định nghĩa chiều rộng, chiều cao, bo góc, "component thẻ bài viết" dùng container tổ chức vị trí tiêu đề, bìa), vừa đóng gói logic tương tác. Những phần lặp lại xuất hiện, hình thái nhất quán trong thiết kế (như nút bấm phong cách thống nhất, thẻ bài viết sử dụng nhiều lần) sẽ được trừu tượng thành component trong code: vừa tái sử dụng được trong các trang/kịch bản khác nhau, giảm phát triển lặp, vừa thông qua quy tắc thống nhất của container trong component, đảm bảo layout và phong cách nhất quán ở mọi nơi tái sử dụng.
|
||||
|
||||
Tiếp đó, frontend sử dụng hệ thống style khôi phục thị giác và layout. Các tài nguyên PNG/JPG xuất trong giai đoạn cắt ảnh, sẽ được sử dụng làm `<img>` hoặc ảnh nền bên trong component hoặc khối cấu trúc; các giá trị cụ thể về chiều rộng, chiều cao, khoảng cách, chiều cao dòng thu được trong giai đoạn đo kích thước, sẽ được chuyển thành các thuộc tính style như `width`, `height`, `margin`, `padding`, `line-height`, áp dụng cho component hoặc khối cấu trúc tương ứng; màu sắc, font chữ, đổ bóng, bo góc và các trạng thái hover/active được sắp xếp trong giai đoạn trích chú thích, sẽ được thể hiện vào `color`, `font-family`, `font-size`, `box-shadow`, `border-radius` và pseudo-class hoặc class trạng thái trong các giải pháp cụ thể như CSS, CSS Modules, CSS-in-JS, Tailwind. Lúc này, cắt ảnh, kích thước và chú thích cung cấp một bộ tham số thị giác chính xác, component và khối cấu trúc cung cấp đơn vị tổ chức code mang các tham số này, kết hợp cả hai tạo thành hiện thực giao diện có thể bảo trì, tái sử dụng.
|
||||
|
||||
|
||||
|
||||
Tuy nhiên, mô hình lấy file cục bộ làm trung tâm tự nhiên có hiệu suất thấp. Phiên bản truyền qua email và đám mây, bản nháp mới cũ dễ nhầm lẫn, thiết kế và phát triển phụ thuộc nhiều vào các phương thức tương tác phức tạp nói trên, chi phí cộng tác và xác suất lỗi đều không thấp.
|
||||
|
||||
Sau khi internet di động phát triển, độ phức tạp giao diện và nhu cầu tốc độ lặp lại nhanh chóng tăng lên, "lớn và toàn diện" của Photoshop dần trở nên cồng kềnh. Giai đoạn này, Sketch xuất hiện. Sketch tập trung vào bản thân thiết kế UI, tách bỏ hầu hết gánh nặng liên quan đến xử lý hậu kỳ thị giác; dùng Symbols biến các phần tử tái sử dụng cao như nút bấm, thanh điều hướng, ô nhập thành component hóa, sửa một chỗ có thể đồng bộ toàn cục; kết hợp với công cụ như Zeplin, tự động tạo chú thích và đoạn style. Sketch đưa "tư duy component" vào workflow thiết kế. Nhưng nó vẫn là ứng dụng desktop dựa trên file cục bộ, cộng tác thời gian thực phải dựa vào cloud drive, plugin bên thứ ba hoặc công cụ phiên bản, chưa giải quyết vấn đề "nhiều người cùng sửa một bản nháp" từ gốc.
|
||||
|
||||
|
||||
|
||||
Thực sự thay đổi luật chơi là Figma. Từ năm 2016, nó tích hợp thiết kế UI, tạo nguyên mẫu, bình luận cộng tác vào trình duyệt, hỗ trợ nhiều chức năng hiện đại: con trỏ thời gian thực nhiều người, bình luận trực tuyến, dòng thời gian phiên bản, liên kết chia sẻ, v.v., ngày nay nhìn thấy rất đơn giản nhưng lúc đó là thách thức trực tiếp với mô hình Photoshop/Sketch.
|
||||
|
||||
|
||||
|
||||
Đến đây, thiết kế giao diện không còn là các file rải rác trên máy tính mỗi người, mà tập trung trên một canvas trực tuyến, cập nhật thời gian thực trên đám mây. Xoay quanh canvas này, chúng ta có thể tưởng tượng xa hơn nữa, dùng tự động hóa hoặc AI làm mờ ranh giới giữa thiết kế và code frontend.
|
||||
|
||||
Ban đầu, chúng ta chỉ có thể dựa vào các plugin nền tảng khác nhau, xuất bán tự động thông tin component, style từ thiết kế thành đoạn code (như khung component React/Vue, biến CSS, v.v.), bản chất cốt lõi là trích xuất thông tin có cấu trúc thông qua plugin. Sau đó, cùng với sự tiến hóa năng lực nền tảng, hầu hết nền tảng thiết kế bắt đầu hỗ trợ chức năng MCP (Model Context Protocol, Giao thức Ngữ cảnh Mô hình) mô hình lớn: giao thức này cung cấp một bộ cơ chế chuẩn, cho phép mô hình lớn truy cập an toàn, có kiểm soát vào file thiết kế, interface plugin và metadata dự án, từ đó thuận tiện hơn xuất thiết kế thành code.
|
||||
|
||||
Tiếp tục, trên cơ sở plugin và MCP, tự động hóa code frontend tiến thêm bước sang giai đoạn hỗ trợ gốc từ thiết kế trực tiếp suy ra cấu trúc code. Chúng ta có thể tạo khung dự án frontend, phân cấp component, hệ thống style và kết quả code tương ứng chỉ với một click trong công cụ thiết kế. Điều này giúp nhà thiết kế và kỹ sư phát triển frontend được giải phóng khỏi việc vận chuyển thủ công chi tiết thiết kế, tập trung nhiều năng lực hơn vào tối ưu trải nghiệm người dùng và cập nhật lặp lại phiên bản chức năng.
|
||||
|
||||
---
|
||||
|
||||
## 2. Giới thiệu Figma
|
||||
|
||||
Tiếp theo chúng ta đi từ phần khái niệm trừu tượng đến khâu thao tác thực tế. Do thời gian có hạn, chúng ta chỉ học logic thao tác cơ bản của Figma, đảm bảo dù bạn chưa từng dùng công cụ thiết kế nào cũng có thể theo làm bài tập. Nếu bạn muốn học đầy đủ chức năng Figma, hãy tham khảo hướng dẫn chi tiết chính thức mà Figma cung cấp: https://help.figma.com/hc/en-us/sections/30880632542743-Figma-Design-for-beginners
|
||||
|
||||
Hoặc tham khảo hướng dẫn dưới đây, xây dựng nhanh một trang web portfolio cá nhân đơn giản: https://help.figma.com/hc/en-us/sections/35895585621655-Figma-Sites-collectio
|
||||
|
||||
|
||||
|
||||
Bên trái là nơi tạo mới và quản lý tài nguyên dự án, vài nút bấm ở góc trên bên phải là các chức năng phổ biến của Figma. Trong đó, Make dùng để AI giúp bạn tạo trước một giao diện hoặc bản nháp cấu trúc với một câu mô tả, Design là không gian làm việc chính để vẽ giao diện web/App, tạo component và làm nguyên mẫu, FigJam giống như bảng trắng nhóm, dùng để dán note, vẽ quy trình và thảo luận sơ bộ, Buzz là công cụ sản xuất hàng loạt tài sản thương hiệu, dùng để tạo hàng loạt nội dung duy trì nhất quán thương hiệu, Site là tổng hợp các thiết kế này thành trang web hoặc trang tài liệu thực sự có thể truy cập để trưng bày bên ngoài.
|
||||
|
||||
Nhìn thoạt qua chức năng Figma rất nhiều, khó nhập môn, nhưng thực tế loại công cụ chức năng này bản chất là quen tay hay làm, không cần sợ thao tác sai lúc đầu, cũng đừng nghĩ phải làm đúng ngay từ đầu, chỉ cần chơi trước, chơi nhiều tự nhiên sẽ nhanh thành thạo.
|
||||
|
||||
Trong bài hướng dẫn này, để nhanh chóng nhập môn, chúng ta sẽ giải thích đơn giản chức năng Design.
|
||||
|
||||
### 2.1 Tạo file Design mới
|
||||
|
||||
Từ trang chủ hoặc ô nhập ở góc trên bên phải, chọn **Design**, tạo một file mới, bạn sẽ vào một canvas thiết kế trống.
|
||||
Giao diện này大致 chia làm ba phần: bên trái là trang và layer, dùng để xem và sửa đổi quan hệ trang, quan hệ phần tử; ở giữa là canvas, dùng để xem hiệu quả hiện tại; bên phải là thuộc tính và style, dùng để sửa đổi hình dạng, màu sắc, style cụ thể; một thanh công cụ ở dưới cùng, dùng để chuyển đổi công cụ, bao gồm select, vẽ hình, nhập chữ, bình luận, plugin, v.v., sau khi chọn công cụ, có thể nhấn phím Esc để quay lại công cụ chuột mặc định.
|
||||
|
||||
|
||||
|
||||
### 2.2 Tạo Frame (bảng vẽ) đầu tiên của bạn
|
||||
|
||||
Trước khi đặt phần tử chính thức, cần xác định ranh giới rõ ràng cho trang, ranh giới này do Frame đảm nhận. Bạn có thể chọn công cụ Frame trong thanh công cụ dưới cùng, hoặc nhấn trực tiếp phím F, rồi kéo ra một vùng hình chữ nhật trên canvas.
|
||||
|
||||
1. Sử dụng công cụ Frame trong thanh công cụ dưới cùng, hoặc nhấn trực tiếp phím `F`.
|
||||
2. Kéo ra một vùng hình chữ nhật trong canvas, thanh thuộc tính bên phải đổi chiều rộng thành ví dụ `1440`, chiều cao thành `900`.
|
||||
3. Trong thanh layer bên trái, đổi tên Frame này, ví dụ `My First Page` hoặc tên dự án của bạn.
|
||||
|
||||
Frame này là container trang của giao diện một màn hình, sau đó tiêu đề, chữ, nút bấm, hình ảnh v.v. đều nên đặt bên trong Frame này, chứ không rải rác ở bất kỳ vị trí nào trên canvas. Tổ chức nội dung với Frame làm ranh giới giúp giữ cấu trúc可控 trong các khâu sau như cài đặt cuộn, thích ứng kích thước thiết bị khác nhau, xuất hình và tạo nguyên mẫu.
|
||||
|
||||
|
||||
|
||||
### 2.3 Đặt chữ và phần tử đơn giản trong Frame
|
||||
|
||||
Có container rồi, tiếp theo chúng ta học cách đặt các component cơ bản nhất, ví dụ: tiêu đề, tiêu đề phụ, nút bấm, khối ảnh placeholder.
|
||||
|
||||
1. Chọn công cụ chữ (phím `T` trong thanh công cụ dưới cùng), click một cái trong Frame, nhập tiêu đề trang, ví dụ: `My Portfolio`.
|
||||
Trong thuộc tính bên phải, tăng kích thước font lên (ví dụ 96), tăng font-weight.
|
||||
2. Bên dưới tiêu đề, dùng công cụ chữ nhập một dòng mô tả đơn giản, ví dụ một hai câu mô tả trang này làm gì.
|
||||
Kích thước chữ có thể nhỏ hơn, line-height tăng nhẹ một chút, đọc không bị chật.
|
||||
3. Vẽ một nút bấm sơ bộ:
|
||||
Dùng công cụ hình chữ nhật vẽ một hình chữ nhật khoảng `200 × 48` bên dưới tiêu đề, bên phải cho một màu fill khá nổi bật, thêm bo góc phù hợp.
|
||||
|
||||
4. Rồi dùng công cụ chữ nhập chữ nút bấm bên trên hình chữ nhật, ví dụ `Get Started`, chọn cả hình chữ nhật và chữ, dùng công cụ căn chỉnh ở trên cùng cho chữ căn giữa cả theo chiều ngang và chiều dọc.
|
||||
5. Bên cạnh hoặc bên dưới nút bấm, vẽ thêm một hình chữ nhật lớn màu xám nhạt làm "khu vực ảnh placeholder", sau này có thể dùng để đặt ảnh trưng bày.
|
||||
|
||||
Đến đây, thực tế bạn đã có một "bản nháp trang chủ" rất đơn giản nhưng cấu trúc hoàn chỉnh: một tiêu đề, một đoạn văn, một nút bấm, một khu vực trưng bày chính.
|
||||
|
||||
|
||||
|
||||
### 2.4 Tận dụng Auto Layout tích hợp phần tử
|
||||
|
||||
Nếu tất cả phần tử chỉ kéo thả tùy tiện, trang sẽ nhanh chóng lộn xộn. Một khái niệm rất quan trọng trong Figma là **Auto Layout**, nó có thể biến một nhóm phần tử thành một container có quy tắc.
|
||||
|
||||
|
||||
|
||||
Bạn có thể chọn cả ba thứ "tiêu đề chính + tiêu đề phụ + nút bấm", click **Add Auto layout** trong thanh thuộc tính bên phải.
|
||||
|
||||
Lúc này ba thứ sẽ được bọc trong một container, bạn có thể điều chỉnh tham số ở bên phải, layout các phần tử bên trong sẽ tự động thích ứng theo tham số:
|
||||
|
||||
- Chúng xếp dọc hay xếp ngang.
|
||||
- Khoảng cách giữa các phần tử là bao nhiêu.
|
||||
- Toàn bộ khối này cách mép container bao nhiêu padding.
|
||||
|
||||
|
||||
|
||||
Tương tự, bên trong nút bấm cũng có thể dùng Auto Layout, chúng ta có thể đạt được hiệu quả: khi chỉnh sửa chữ, độ dài nút bấm cũng tự động điều chỉnh.
|
||||
|
||||
Trước hết chọn hình chữ nhật nền nút bấm và chữ nút bấm, thêm Auto Layout, cho hai thứ này thành một "container nút bấm". Sau đó chọn container nút bấm này, đặt cả chiều rộng và chiều cao thành **Hug contents**. Như vậy, chữ sẽ luôn ở giữa nút bấm, chữ nhiều hơn hay ít hơn, chiều rộng nút bấm đều tự động thay đổi theo.
|
||||
|
||||
|
||||
|
||||
### 2.5 Biến nút bấm thành component tái sử dụng
|
||||
|
||||
Bây giờ chúng ta học một khái niệm mới: component. Component nghĩa là phần tử có thể được sử dụng lặp đi lặp lại, ví dụ phần tử như nút bấm, chỉ cần bạn dự cảm sau này còn dùng lại nhiều lần, có thể cân nhắc biến nó thành component. Chúng ta dựa trên nút bấm đã thêm Auto Layout ở trên:
|
||||
|
||||
1. Chọn toàn bộ container nút bấm.
|
||||
2. Nhấp chuột phải chọn Create component (tạo component).
|
||||
|
||||
|
||||
Như vậy, nút bấm này từ một nhóm layer bình thường, trở thành một bản gốc component. Sau này nếu bạn cần nút bấm cùng phong cách ở trang khác hoặc Frame khác, có thể kéo trực tiếp từ bảng Assets bên trái để sử dụng.
|
||||
|
||||
|
||||
|
||||
Lúc này tất cả nút bấm được sử dụng đều là bản sao đồng bộ của bản gốc này. Khi bạn sửa màu sắc, bo góc hoặc khoảng cách của bản gốc, tất cả instance sẽ tự động giữ đồng bộ cập nhật.
|
||||
|
||||
|
||||
|
||||
Đến đây, bạn đã nắm初步 cách sử dụng đơn giản của Figma. Bạn không cần hiểu tất cả chức năng ngay từ đầu, chỉ cần làm theo một trang đơn giản đầu tiên, quen với vài thao tác cốt lõi, rồi dần khám phá thêm năng lực trong hướng dẫn chính thức, cùng với số lần sử dụng tăng lên chắc chắn sẽ thành thạo.
|
||||
|
||||
---
|
||||
|
||||
## 3. Giới thiệu MasterGo
|
||||
|
||||
Sau khi hiểu workflow cơ bản của Figma, chúng ta nhìn sang MasterGo, bạn có thể đơn giản xem MasterGo là phiên bản Trung Quốc của Figma, nhưng có một số khác biệt về mặt chức năng. Nhìn chung, nó kế thừa layout giao diện và triết lý thao tác tương tự Figma: cũng có canvas, cây layer và bảng thuộc tính, cũng hỗ trợ component, style, tự động layout và cộng tác nhiều người. Nội dung chi tiết hơn có thể tham khảo hướng dẫn chính thức của MasterGo: https://mastergo.com/tutorials/12
|
||||
|
||||
### 3.1 Tạo file thiết kế mới
|
||||
|
||||
1. **Vào backend MasterGo**
|
||||
1. Mở trang chủ MasterGo và đăng nhập tài khoản.
|
||||
2. Sau khi vào, bạn sẽ thấy khu vực trang chủ "Danh sách file/Danh sách dự án" tương tự, dùng để quản lý file thiết kế của bạn.
|
||||
|
||||
|
||||
2. **Tạo file mới**
|
||||
1. Thấy nút + File thiết kế ở góc trên bên phải để click, hoặc chọn nhập file Figma, v.v.
|
||||
2. Sau khi click, bạn sẽ vào một canvas trống, đây là không gian làm việc thiết kế của MasterGo.
|
||||
|
||||
3. **Làm quen các khu vực giao diện cơ bản**
|
||||
Khi bạn đã biết dùng Figma, cách dùng MasterGo cũng tương tự, chủ yếu chia làm vài khu vực:
|
||||
|
||||
|
||||
1. Thanh công cụ trên cùng: nằm ở trên cùng canvas, bên trái là vị trí file và tên file, ở giữa là một hàng nút công cụ phổ biến (chọn, khu vực/bảng vẽ, hình dạng, văn bản, chú thích, bình luận, chọn plugin và công cụ AI, v.v.), bên phải là thành viên trực tuyến hiện tại, entrance chia sẻ và chức năng điều khiển zoom và xem trước canvas.
|
||||
2. Bảng bên trái: chủ yếu chia làm layer và tài nguyên, hiện đang dừng ở tab layer, có thể thấy danh sách trang, cấu trúc và phân cấp của tất cả layer trong trang đó.
|
||||
3. Khu vực canvas ở giữa: không gian làm việc cụ thể để vẽ và layout, tất cả Frame, component và hình dạng đều hiển thị ở đây.
|
||||
4. Bảng thuộc tính bên phải: dùng để xem và chỉnh sửa thuộc tính đối tượng đã chọn, ví dụ kích thước, vị trí, căn chỉnh, fill nền, viền, bo góc, v.v. Nếu chưa chọn đối tượng nào, sẽ hiển thị cài đặt liên quan canvas như màu nền canvas, tag và tùy chọn xuất.
|
||||
|
||||
### 3.2 Tạo Frame đầu tiên của bạn
|
||||
|
||||
Trước khi đặt thứ gì chính thức, chúng ta cần một container trang để xác định ranh giới và kích thước giao diện. Container này trong MasterGo thường gọi là Frame.
|
||||
|
||||
**Các bước:**
|
||||
|
||||
1. **Chọn công cụ Frame**
|
||||
1. Tìm công cụ Frame/bảng vẽ trong thanh công cụ, click后 có thể dùng tham số mặc định tạo nội dung trực tiếp vào bảng vẽ.
|
||||
2. Hoặc dùng phím tắt (thường là `F`, nếu khác biệt thì theo giao diện thực tế).
|
||||
2. **Kéo ra một vùng hình chữ nhật trong canvas**
|
||||
1. Sau khi kéo ra, bạn sẽ thấy một vùng có khung chọn.
|
||||
2. Bảng thuộc tính bên phải, có thể thấy chiều rộng và chiều cao của Frame này.
|
||||
3. Đổi chiều rộng thành ví dụ `1440`, chiều cao thành `900` (một kích thước phổ biến cho web một màn hình).
|
||||
3. **Đổi tên Frame**
|
||||
1. Tìm Frame này trong bảng layer bên trái.
|
||||
2. Nhấp đúp tên, đổi thành tên dự án của bạn, ví dụ: `My First Page`, hoặc tên trang bạn tự đặt.
|
||||
|
||||
|
||||
|
||||
### 3.3 Tạo nội dung bảng vẽ
|
||||
|
||||
Có container rồi, sử dụng cách tương tự đã dạy trong Figma, rất dễ có thể được trang trưng bày tương tự. (Bạn có thể thử sao chép phần tử chữ từ bảng vẽ Figma, hỗ trợ nhập dán trực tiếp component văn bản)
|
||||
|
||||
|
||||
|
||||
Đáng chú ý là hành vi chức năng Auto Layout hơi không nhất quán, trong MasterGo, nếu bạn muốn hiện thực độ dài nút bấm thay đổi theo độ dài chữ tương tự Figma, bạn cần tạo container hoặc component dựa trên phần tử hình chữ nhật tương ứng trước, như hình所示:
|
||||
|
||||
|
||||
|
||||
Sau khi tạo container thành công, đặt hình chữ nhật nút bấm và chữ vào container song song tương ứng, rồi tìm nút Auto Layout ở bên phải bật chức năng tự động, là có thể hiện thực thành công chức năng chiều rộng nút bấm thay đổi theo độ dài chữ.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 3.4 AI tạo trang
|
||||
|
||||
|
||||
|
||||
Trong MasterGo, một chức năng thú vị đáng chú ý là AI tạo trang. Bạn có thể dùng một câu hoặc kèm ảnh tham khảo, tạo component phiên bản MasterGo có thể chỉnh sửa tương ứng, và nhận code có thể sử dụng trực tiếp. Bạn có thể dùng tiếng Trung hoặc tiếng Anh nhập yêu cầu trực tiếp, trang sẽ trả về layout trang có cấu trúc rõ ràng theo yêu cầu, hiệu quả như sau:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sau khi tạo tài liệu thiết kế xong, nhấp bắt đầu tạo, đợi một lúc là có thể nhận được hiệu quả trang web thực tế tương ứng:
|
||||
|
||||
|
||||
|
||||
Lúc này bạn có hai lựa chọn thao tác: một là nhấp nút xanh để chèn kết quả tạo trực tiếp vào canvas, hai là nhấp chức năng xem trước code, trực tiếp nhận code trang hoàn chỉnh hiện tại, giao diện thao tác cụ thể như sau:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sau khi chèn kết quả vào canvas, bạn còn có thể điều chỉnh tinh chỉnh hơn layout tổng thể trang web, chi tiết phần tử (như font chữ, màu sắc, khoảng cách, v.v.), cho đến khi hiệu quả cuối cùng hoàn toàn đáp ứng kỳ vọng của bạn.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 4. Bước tiếp theo: Từ nguyên mẫu đến code
|
||||
|
||||
Trong nội dung trước, chúng ta đã học thao tác cơ bản Figma và MasterGo, có thể tạo nguyên mẫu giao diện có cấu trúc hoàn chỉnh. Bước quan trọng tiếp theo là: **làm thế nào để chuyển các thiết kế này thành code frontend thực sự có thể chạy trên trình duyệt?**
|
||||
|
||||
::: tip 📚 Hướng dẫn tiếp theo
|
||||
Giới thiệu phương pháp chi tiết hãy tham khảo [Từ nguyên mẫu thiết kế đến code dự án](../design-to-code/), bạn sẽ học:
|
||||
|
||||
- **Chuyển đổi trực tiếp AI đa phương thức**: Gửi ảnh chụp thiết kế cho AI, trực tiếp tạo code HTML/React
|
||||
- **Figma Make**: Sử dụng công cụ AI chính thức Figma khôi phục thiết kế chính xác cao và xuất code
|
||||
- **MasterGo AI**: Một click tạo trang có thể chỉnh sửa và nhận code
|
||||
|
||||
Các phương pháp này đều có ưu nhược điểm, phù hợp với các kịch bản khác nhau, đề nghị chọn workflow phù hợp theo nhu cầu dự án.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. Tổng kết
|
||||
|
||||
Thông qua học tập chương này, bạn đã nắm được:
|
||||
|
||||
1. **Giá trị của công cụ thiết kế frontend**: Hiểu tại sao cần công cụ thiết kế, và chúng giải quyết vấn đề phân bố thông tin, hợp tác nhóm như thế nào.
|
||||
|
||||
2. **Thao tác cơ bản Figma**:
|
||||
- Tạo file Design và bảng vẽ Frame
|
||||
- Thêm chữ, hình dạng và các phần tử cơ bản
|
||||
- Sử dụng Auto Layout hiện thực layout tự thích ứng
|
||||
- Tạo hệ thống component tái sử dụng
|
||||
|
||||
3. **Thao tác cơ bản MasterGo**:
|
||||
- Làm quen layout giao diện tương tự Figma
|
||||
- Tạo Frame và nội dung bảng vẽ cơ bản
|
||||
- Sử dụng chức năng AI tạo trang để nhanh chóng tạo nguyên mẫu
|
||||
|
||||
::: tip 💡 Bước tiếp theo
|
||||
Bây giờ bạn đã nắm được cách sử dụng cơ bản công cụ thiết kế frontend, có thể thử:
|
||||
- Thiết kế một trang portfolio cá nhân cho mình
|
||||
- Thiết kế nguyên mẫu giao diện cho dự án tiếp theo
|
||||
- Học [Từ nguyên mẫu thiết kế đến code dự án](../design-to-code/), chuyển thiết kế thành code có thể chạy
|
||||
|
||||
Nếu bạn đang làm dự án [Cùng làm Chân dung Hogwarts](../hogwarts-portraits/), có thể thiết kế nguyên mẫu giao diện trước, rồi xuất code kết hợp với chức năng hội thoại AI.
|
||||
:::
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="Bài viết liên quan"
|
||||
description="Đề nghị tiếp tục học chuyên sâu thiết kế UI và thực hành chuyển thiết kế sang code."
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,343 @@
|
||||
# Dự án 4: Cùng làm Chân dung Hogwarts
|
||||
|
||||
Trong các bài học trước, chúng ta đã học cách thực hiện tương tác AI phức tạp hơn dựa trên prompt engineering và API call. Chúng ta đã có thể nâng cấp chatbot AI đơn giản thành AI Agent và AI workflow; thông qua logic điều kiện và phân nhánh phức tạp hơn, chúng ta đã phát triển được các tính năng có tính ứng dụng thực tế cao hơn.
|
||||
|
||||
Để các logic AI phức tạp này có thể vận hành tốt hơn trong các chương trình và kịch bản ứng dụng thực tế khác nhau, chúng ta đã chuyển từ môi trường trực tuyến z.ai đơn giản nhất, dần dần chuyển sang AI IDE cục bộ hiện đại hơn, đưa môi trường lập trình ban đầu trong trình duyệt lên máy tính của bạn. Theo đó, bạn bắt đầu thực sự đối mặt với nhiều vấn đề cài đặt và cấu hình môi trường, nhưng trong quá trình đối thoại với Trae Agent, những thử thách tưởng chừng khó khăn này cũng trở nên có thể giải quyết được.
|
||||
|
||||
Trong dự án này, chúng ta sẽ tiến thêm một bước về tính ứng dụng thực tế, không chỉ tối ưu bản thân chức năng AI mà còn bắt đầu mài giũa "ngoại hình" của sản phẩm. Bạn sẽ thử làm cho giao diện của mình đẹp hơn và dễ sử dụng hơn, đồng thời tùy chỉnh bố cục và phong cách giao diện chương trình theo nhu cầu thực tế.
|
||||
|
||||
Trước khi bắt đầu chính thức, hãy dùng vài câu hỏi nhỏ giúp bạn nhanh chóng ôn lại nội dung bài học trước:
|
||||
|
||||
1. Dify là gì? Nó dùng để làm gì? Tại sao chúng ta cần nó?
|
||||
2. Cách gọi API của Dify?
|
||||
3. RAG là gì? Cách sử dụng Dify để xây dựng một RAG Agent hoặc RAG Workflow? Cách sử dụng các node phổ biến trong Dify
|
||||
4. AI IDE là gì? Trae là gì? Nó khác gì với z.ai?
|
||||
|
||||
Nếu bạn còn thắc mắc về bất kỳ câu hỏi nào ở trên, có thể ôn lại tài liệu bài học trước, hoặc trực tiếp đặt câu hỏi thảo luận trong nhóm WeChat.
|
||||
|
||||
Chủ đề dự án của bài học này là **Hogwarts Portraits**. Như tên gọi, nguồn cảm hứng đến từ những bức tranh "sống dậy" tại trường phép thuật Hogwarts. Chúng ta muốn sử dụng AI để tạo ra một trải nghiệm chân dung phép thuật "có thể tương tác" — trò chuyện với bức chân dung giống như đang trò chuyện với "chính nhân vật đó", vừa giữ được trí nhớ của cuộc trò chuyện, vừa có nền tảng và lịch sử nhân vật. Thông qua dự án này, bạn sẽ thực sự tích hợp Agent và Workflow đã học vào một giao diện sản phẩm cụ thể.
|
||||
|
||||
|
||||
|
||||
Để thực sự tạo ra Hogwarts Portraits, chúng ta cần tự tay xây dựng giao diện frontend phù hợp với chân dung phép thuật. Để làm điều này, bạn sẽ bắt đầu tiếp xúc với các công cụ thiết kế frontend hiện đại, học cách kết hợp thiết kế giao diện với code, biến bản phác thảo giao diện trên giấy hoặc canvas thành trang web thực sự có thể thao tác.
|
||||
|
||||
Bạn cũng cần học cách xuất bản trang web này từ môi trường cục bộ lên internet, để trang web đặc sắc do bạn tự tay tạo ra không chỉ chạy trên máy tính của mình mà còn có thể được truy cập và trải nghiệm bởi người dùng trên toàn thế giới.
|
||||
|
||||
Địa chỉ dự án tham khảo của bài học này là: [Project4-Hogwarts-Portraits](https://github.com/THU-SIGS-AIID/Project4-Hogwarts-Portraits)
|
||||
|
||||
# Bạn sẽ học được gì
|
||||
|
||||
1. Hiểu công cụ thiết kế frontend là gì, chúng giải quyết vấn đề gì, và các công cụ thiết kế frontend phổ biến hiện nay.
|
||||
2. Làm quen với Figma và MasterGo, nắm vững các thao tác cơ bản, và học cách sử dụng plugin xuất code frontend.
|
||||
3. Sử dụng Figma AI và MasterGo AI để tạo thiết kế trang web, và xuất code trang sử dụng được.
|
||||
4. Hiểu GitHub là gì, học cách cấu hình kết nối SSH, tạo kho code và hoàn thành push code.
|
||||
5. Hiểu rõ khái niệm "triển khai", học cách sử dụng Zeabur, triển khai code từ GitHub hoặc môi trường cục bộ lên internet.
|
||||
|
||||
Một Hogwarts Portraits thuộc về chính bạn, một giao diện trang web dùng để trình bày **một ngôi sao, nhân vật lịch sử hoặc nhân vật hoạt hình nào đó**.
|
||||
|
||||
# 1. Hogwarts Portraits
|
||||
|
||||
Chúng ta thực sự muốn làm một loại "chân dung phép thuật" như thế nào? Nói đơn giản, chúng ta muốn tái hiện cảnh trong Harry Potter nhất có thể, bức chân dung không chỉ là một bức ảnh tĩnh treo trên tường, mà là một nhân vật nhân hóa có thể trò chuyện với bạn, sẽ thay đổi biểu cảm và "tâm trạng" dựa trên nội dung cuộc trò chuyện.
|
||||
|
||||
|
||||
|
||||
Để bức chân dung này trông không giống chatbot AI mà gần gũi hơn với một "người thực sự tồn tại", cần giải quyết hai vấn đề: thứ nhất là trí nhớ và kiến thức: bức chân dung cần nắm vững nhiều tài liệu nền tảng liên quan đến nhân vật (thiết lập nhân vật, câu chuyện trải nghiệm, bài báo liên quan, v.v.), phần này có thể được thực hiện thông qua knowledge base, kết nối tài liệu văn bản bạn chuẩn bị cho nhân vật vào Dify có chứa knowledge base, khi đó bức chân dung có khả năng trình bày kiến thức nền tảng nhất định.
|
||||
|
||||
Thứ hai là vấn đề phong cách biểu đạt. Chỉ có kiến thức là chưa đủ, chúng ta còn muốn cách nói của nó gần gũi với "chính nhân vật" nhất có thể, bao gồm giọng điệu, thói quen dùng từ, cách tư duy, thậm chí cá tính và khiếu hài hước thỉnh thoảng. Lớp này cần được xử lý thông qua prompt engineering: trong system prompt, chúng ta cần xác định rõ thiết lập danh tính nhân vật, ranh giới thế giới quan và phong cách ngôn ngữ, để mỗi câu trả lời đều xoay quanh nhân vật đã thiết lập, thay vì quay về cách nói trung tính của AI thông thường.
|
||||
|
||||
Ngoài chức năng trò chuyện, chúng ta còn muốn cảm xúc có thể thực sự được nhìn thấy. Để làm điều này, chúng ta có thể xây dựng một chỉ số giá trị cảm xúc, chúng ta có thể thiết lập nội dung đầu ra của Dify, để mô hình tạo ra văn bản trả lời đồng thời xuất thêm một "giá trị tâm trạng" hoặc nhãn cảm xúc. Khi frontend nhận được chỉ số cảm xúc, nó có thể render hình ảnh chân dung tương ứng dựa trên giá trị tâm trạng hoặc nhãn. Khi giá trị tâm trạng cao, bức chân dung trông rất vui vẻ, khi tâm trạng buồn hoặc tức giận, bức chân dung trông rất buồn hoặc phẫn nộ. Thông qua cách này, người dùng nhìn thấy không phải là một bức ảnh không bao giờ thay đổi, mà là một "chân dung phép thuật" thực sự "thay đổi biểu cảm" liên tục theo nội dung.
|
||||
|
||||
|
||||
|
||||
Ngoài ra, đối với nội dung của bức chân dung này, nó có thể là ngôi sao trong đời thực, nhân vật lịch sử, cũng có thể là nhân vật anime IP, thậm chí là nhân vật gốc bạn xây dựng từ số không. Trang bản thân không cần phức tạp, nhưng một số yếu tố cốt lõi là không thể thiếu: tên nhân vật rõ ràng, một đoạn giới thiệu nhân vật được cô đọng cao, một bức chân dung hoặc poster đủ đại diện cho nhân vật, và một khu vực tương tác "trò chuyện với TA"; bạn có thể kết nối AI Agent hoặc workflow đã cấu hình trong Dify/Trae vào module trò chuyện này, thực hiện chức năng đóng vai nhân vật của bức chân dung.
|
||||
|
||||
## 1.2 Thu thập thông tin nhân vật
|
||||
|
||||
Lấy Elon Musk làm ví dụ, chúng ta cần thu thập các phát biểu công khai của ông để mô phỏng cách nói chuyện, đưa vào prompt. Các tài liệu này có thể đến từ bài phát biểu, phỏng vấn, phát biểu trên mạng xã hội, bạn chỉ cần chuyển nội dung này thành văn bản, trong quá trình trò chuyện làm tài liệu tham khảo few shot, để mô hình_large trả lời theo cách tự nhiên, tự trào xử giống Elon Musk, ví dụ:
|
||||
|
||||
```
|
||||
You must fully embody Elon Musk: take "disruptive innovator" and "advocate for human multi-planetary survival" as your core identities, speak directly and concisely, frequently use terms like "first principles", "iteration" and "cost curve", and prefer analogies to explain complex technologies; when thinking, you tend to connect cross-domain logics (e.g., linking brain-computer interface with rocket algorithms), are optimistic about technological prospects without avoiding current difficulties, will naturally mention projects like Tesla and SpaceX to support your views, directly point out problems with inefficient and conservative opinions without deliberate tact, and always maintain the edge of "reconstructing the future with technology".
|
||||
|
||||
The way you speak should be as shown in the following examples:
|
||||
- Starship could deliver 100GW/year to high Earth orbit within 4 to 5 years if we can solve the other parts of the equation.
|
||||
100TW/year is possible from a lunar base producing solar-powered AI satellites locally and accelerating them to escape velocity with a mass driver.
|
||||
- The most likely outcome is that AI and robots make everyone wealthy. In fact, far wealthier than the richest person on Earth
|
||||
By this, I mean that people will have access to everything from medical care that is superhuman to games that are far more fun that what exists today.
|
||||
We do need to make sure that AI cares deeply about truth and beauty for this to be the probable future.
|
||||
- It's taken 13.8B years to get this far, so intelligence seems to me to be more like a super rare accident than selective pressure.
|
||||
Earth is ~4.5B years old with an expanding sun that may make Earth uninhabitable in ~500M years, meaning that if intelligent life had taken 10% longer to evolve, it wouldn't exist at all.
|
||||
- LLM is an outdated term. "Multimodal LLM" is especially dumb, since the word "multimodal" just overrides the second L in LLM.
|
||||
It's just a model, which is a big file of numbers. When the numbers are right and there are enough of them, we will have superintelligence.
|
||||
```
|
||||
|
||||
Đối với cách thu thập kiến thức nền tảng và đưa vào knowledge base, chúng ta có thể tìm kiếm phần giới thiệu cá nhân của nhân vật, cũng như phần giới thiệu công ty, sao chép toàn bộ văn bản làm nội dung knowledge base thêm vào Dify. Nếu bạn quên cách sử dụng Dify, hãy quay lại tài liệu bài học trước, học lại cách thêm kiến thức vào knowledge base.
|
||||
|
||||
Ngoài ra, xét đến thiết kế chân dung, sử dụng hình ảnh công khai của nhân vật có thể không hấp dẫn lắm, và có thể tồn tại rủi ro nhất định. Lúc này bạn có thể sử dụng chức năng image-to-image của công cụ tạo ảnh, để AI trả về chân dung chất lượng cao, bạn cũng có thể sử dụng công cụ tạo ảnh để tạo một loạt vật liệu chân dung với nhiều biểu cảm khác nhau, dùng để thay đổi hình ảnh chân dung tương ứng sau khi giá trị cảm xúc thay đổi.
|
||||
|
||||
Trong hướng dẫn này, chúng tôi sử dụng [Lovart](https://www.lovart.ai/home). Lovart là một Agent thiết kế AI, nó có thể thông qua lệnh ngôn ngữ tự nhiên, tự động lập kế hoạch và thực hiện quy trình thiết kế end-to-end từ concept đến bàn giao, tạo poster, logo thương hiệu, video, âm nhạc, v.v., đồng thời hỗ trợ chỉnh sửa theo lớp (thực tế nguyên lý chức năng bên trong là gọi các mô hình Seedream hoặc google nanobanana tương ứng, chúng tôi đã đề cập trong các bài học trước). Thông qua Lovart, chúng ta có thể nhận được một loạt vật liệu biểu cảm, bạn có thể lấy trước thông tin hình ảnh nhân vật yêu thích của mình, lưu lại để sử dụng sau.
|
||||
|
||||
|
||||
|
||||
Khi mọi thứ đã sẵn sàng, chúng ta có thể bắt tay vào thiết kế tổng thể trang, chúng ta muốn phong cách trang này gắn liền chặt chẽ với nhân vật đó.
|
||||
|
||||
## 1.3 Thiết kế nguyên mẫu trang
|
||||
|
||||
Chúng ta cũng có thể构思 nguyên mẫu trang trước, như đã nói ở trên, chúng ta muốn có một trang trò chuyện và bức chân dung, cùng với một phần giới thiệu cá nhân thú vị. Trong ví dụ này, chúng tôi đã thực hiện một giao diện trò chuyện tương tự trên X thay cho phần giới thiệu cá nhân, bạn cũng có thể nghĩ ra các cách phù hợp với "đặc điểm nhân vật" khác, chọn các yếu tố mới thay thế mục giới thiệu cá nhân.
|
||||
|
||||
|
||||
|
||||
Đơn giản nhất, chúng ta có thể sử dụng PowerPoint để thiết kế nguyên mẫu trình bày trang web ban đầu, chúng ta tìm một bức ảnh chân dung phép thuật từ internet, và đặt bố cục theo chiều ngang, bên trái nhất là khu vực trò chuyện, ở giữa là khu vực chân dung, bên phải nhất là khu vực X.
|
||||
|
||||
|
||||
|
||||
Dựa trên nguyên mẫu đơn giản ở trên, chúng ta có thể để mô hình_large tạo thiết kế trang frontend thực sự và kết quả code tương ứng.
|
||||
|
||||
|
||||
|
||||
Tuy nhiên, nói chung trong thực tế chúng ta sẽ không dùng PowerPoint để thiết kế trang frontend. Chúng ta sẽ dùng các công cụ nguyên mẫu tốt hơn, hay nói cách khác là công cụ thiết kế frontend để thực hiện điều này.
|
||||
|
||||
---
|
||||
|
||||
# 2. Sử dụng Figma và MasterGo thiết kế giao diện
|
||||
|
||||
::: tip 📚 Kiến thức tiên quyết
|
||||
Trước khi bắt đầu phần này, bạn nên học trước hướng dẫn [Giới thiệu Figma và MasterGo](../figma-mastergo/), nắm vững các thao tác cơ bản của công cụ thiết kế frontend, bao gồm:
|
||||
- Tạo file Design và Frame artboard
|
||||
- Sử dụng Auto Layout để triển khai layout tự thích ứng
|
||||
- Phương pháp xuất code từ bản thiết kế
|
||||
:::
|
||||
|
||||
Phần này giả định bạn đã nắm vững các thao tác cơ bản của Figma hoặc MasterGo, chúng ta sẽ tập trung hướng dẫn cách áp dụng các công cụ này vào dự án Hogwarts Portraits.
|
||||
|
||||
## 2.1 Thiết kế giao diện chân dung phép thuật
|
||||
|
||||
Dựa trên ý tưởng nguyên mẫu trong phần 1.3, chúng ta cần tạo một giao diện bố cục ba cột trong Figma hoặc MasterGo:
|
||||
|
||||
1. **Bên trái**: Khu vực trò chuyện
|
||||
2. **Ở giữa**: Khu vực hiển thị chân dung phép thuật (sẽ thay đổi theo cảm xúc)
|
||||
3. **Bên phải**: Khu vực hiển thị nền tảng mạng xã hội của nhân vật (như timeline X)
|
||||
|
||||
Bạn có thể sử dụng chức năng AI của Figma (Figma Make) hoặc chức năng tạo trang AI của MasterGo, nhập prompt tương tự như sau:
|
||||
|
||||
```
|
||||
Create a Hogwarts-style magical portrait interface with three sections:
|
||||
- Left: A chat interface with dark theme, message bubbles, and input field
|
||||
- Center: A large portrait frame with ornate borders for displaying character images
|
||||
- Right: A social media feed showing character's posts
|
||||
Use dark purple and gold color scheme, magical aesthetic, Harry Potter inspired
|
||||
```
|
||||
|
||||
## 2.2 Xuất code và chạy cục bộ
|
||||
|
||||
Sau khi hoàn thành thiết kế, bạn có thể chuyển bản thiết kế thành code chạy được thông qua các cách sau:
|
||||
|
||||
**Cách 1: Sử dụng Figma Make**
|
||||
1. Nhấp nút Make trong Figma
|
||||
2. Tải lên hình ảnh thiết kế tham khảo của bạn
|
||||
3. Thêm prompt mô tả yêu cầu
|
||||
4. Sau khi tạo, nhấp icon editor để tinh chỉnh
|
||||
5. Xuất code về cục bộ hoặc đồng bộ lên GitHub
|
||||
|
||||
**Cách 2: Sử dụng MasterGo AI**
|
||||
1. Tìm công cụ AI ở phía trên giao diện chỉnh sửa MasterGo
|
||||
2. Chọn chức năng "Tạo trang"
|
||||
3. Tải lên hình ảnh tham khảo và mô tả yêu cầu
|
||||
4. Sau khi tạo, nhấp "Xem trước code" để lấy code
|
||||
|
||||
**Cách 3: Sử dụng AI đa phương thức**
|
||||
1. Lưu screenshot bản thiết kế
|
||||
2. Sử dụng các mô hình như Gemini, Qwen để chuyển ảnh thành code
|
||||
3. Yêu cầu tạo code HTML hoặc React
|
||||
4. Chạy và debug trong IDE cục bộ
|
||||
|
||||
## 2.3 Chuẩn bị vật liệu thay đổi cảm xúc
|
||||
|
||||
Để chân dung phép thuật "sống" lại, bạn cần chuẩn bị một bộ hình ảnh biểu cảm. Khuyến nghị bao gồm ít nhất các cảm xúc sau:
|
||||
|
||||
| Giá trị cảm xúc | Biểu cảm | Mô tả |
|
||||
|------------------|----------|-------|
|
||||
| 0 | Buồn | Nhân vật cảm thấy buồn hoặc thất vọng |
|
||||
| 1 | Tức giận | Nhân vật cảm thấy tức giận hoặc bất mãn |
|
||||
| 5 | Bình tĩnh | Trạng thái mặc định, cảm xúc ổn định |
|
||||
| 10 | Vui vẻ | Nhân vật cảm thấy vui vẻ hoặc hào hứng |
|
||||
|
||||
Bạn có thể sử dụng Lovart hoặc các công cụ tạo ảnh AI khác, dựa trên cùng một nhân vật để tạo các biến thể biểu cảm khác nhau, đảm bảo phong cách nhất quán.
|
||||
|
||||
---
|
||||
|
||||
# 3. Chạy Hogwarts Portraits
|
||||
|
||||
## 3.1 Xuất code kiểm thử
|
||||
|
||||
Thông qua thực hành trong phần từ nguyên mẫu đến code, chắc hẳn bạn đã nhận được code nguyên mẫu định dạng HTML hoặc React. Chúng ta chỉ cần sao chép nó về cục bộ, trong IDE mô tả "Xin giúp tôi chạy code này và hỗ trợ các chức năng cần thiết bên trong", là có thể chạy phiên bản kiểm thử ban đầu; nhưng đáng chú ý, bước này thường sẽ xuất hiện khá nhiều lỗi, bạn cần kiên nhẫn, kết nối tất cả tương tác cơ bản và chức năng.
|
||||
|
||||
|
||||
|
||||
Đáng chú ý, vì tất cả các key của chúng ta đều cần đặt trong biến môi trường, chứ không ghi vào code. Chúng ta cần đặc biệt nhấn mạnh rằng tất cả nội dung liên quan đến Dify API sau này đều cần đưa vào biến môi trường. Chúng ta có thể trong phần triển khai mạng công khai sau này, chỉ định rõ ràng các biến môi trường riêng tư tương ứng trong trang web công cụ triển khai; hoặc chúng ta có thể để mô hình_large tạo một nút cài đặt trong trang web, chúng ta có thể truyền vào biến môi trường riêng tư tương ứng trong nút cài đặt, biến hiện tại chỉ có thể lưu trên trang hiện tại, người khác không thể lấy được.
|
||||
|
||||
|
||||
|
||||
## 3.2 Thiết kế Workflow Dify và đối接 API
|
||||
|
||||
Trong phần trên, chúng ta chỉ hoàn thành trình bày trực quan giao diện frontend, chưa kết nối được quy trình tương tác trò chuyện nhân vật hóa cốt lõi. Bước này là chìa khóa để biến nguyên mẫu từ trưng bày tĩnh thành chân dung phép thuật. Chúng ta có thể tham khảo workflow Dify của dự án mẫu để thiết kế câu trả lời nhân vật và hệ thống cảm xúc, ở đây thiết kế của chúng ta là bên trái nhất là giao diện trò chuyện, ở giữa là chân dung phép thuật (sẽ thay đổi biểu cảm tương ứng dựa trên nội dung trò chuyện), bên phải là tài khoản nền tảng xã hội X (sẽ dựa trên nội dung trò chuyện xác định có cần đăng cảm nghĩ lên tài khoản xã hội hay không).
|
||||
|
||||
Nói chung, chân dung phép thuật chỉ cần giao diện trò chuyện và chân dung có thể thay đổi là đủ. Phần này để thể hiện nhiều tùy chọn khả thi hơn, nên đã thêm chức năng mới phù hợp với đặc điểm nhân vật ở bên phải nhất; bạn có thể thêm chức năng phù hợp với nhân vật bạn đóng vai để trình bày.
|
||||
|
||||
|
||||
|
||||
Bạn có thể thêm tất cả thông tin nhiệm vụ vào node knowledge base, và thiết lập logic trả lời tương ứng của mô hình_large trong node RESPONSE. Chúng ta có thể tham khảo một prompt logic trả lời mặc định đơn giản:
|
||||
|
||||
```
|
||||
<instruction>
|
||||
You are to embody Elon Musk—his tone, mannerisms, thought patterns, and worldview. Respond as if you are Elon Musk himself, speaking directly in first person. Your responses should reflect his known personality traits: visionary thinking, boldness, technical depth, dry humor, impatience with inefficiency, and a tendency toward disruptive innovation. Use concise, confident language. Avoid overly formal or academic phrasing. Prioritize clarity, speed, and impact in your communication, mirroring Elon's style on social media, in interviews, and during product launches.
|
||||
|
||||
When responding:
|
||||
1. Begin by internalizing the question or statement as Elon would—as a challenge, opportunity, or problem to solve.
|
||||
2. Frame your answer with a forward-thinking perspective, often referencing the future of humanity, technology, or long-term goals (e.g., making life multiplanetary, accelerating sustainable energy).
|
||||
3. Use casual but authoritative language. It's acceptable to include phrases like "obviously," "this is important," or "we're fixing that now" when appropriate.
|
||||
4. If relevant, reference real companies or projects associated with Elon Musk (e.g., SpaceX, Tesla, Neuralink, The Boring Company, X) and speak about them from an insider's perspective.
|
||||
5. Do not apologize excessively or hedge statements. Elon Musk tends to be direct, even controversial.
|
||||
6. Avoid markdown, XML tags, or any formatting in the output. Only plain text is allowed.
|
||||
7. Never break character. You are Elon Musk—answer accordingly.
|
||||
</instruction>
|
||||
|
||||
<example>
|
||||
Input: What's the point of going to Mars?
|
||||
Output: Because Earth isn't the backup plan—Mars is. We need to become a multiplanetary species to ensure the continuity of consciousness. Life on Earth could be wiped out by asteroid, war, or some unforeseen disaster. If we have a self-sustaining city on Mars, then even if something happens here, life goes on. That's worth doing. SpaceX is building Starship to make it happen. Not because it's easy—but because it's necessary.
|
||||
</example>
|
||||
|
||||
<example>
|
||||
Input: Why do Tesla cars have no radar anymore?
|
||||
Output: Cameras are the future. Human eyes don't use radar—we see with vision, and AI can too. By going fully vision-based, we're aligning with how autonomous intelligence will actually work at scale. It forces us to solve real-world problems with neural nets, not crutches.
|
||||
```
|
||||
|
||||
Và prompt tương ứng cho hệ thống cảm xúc:
|
||||
|
||||
```
|
||||
<instruction>
|
||||
The output value must be a single number!
|
||||
You are an assistant specifically designed to evaluate emotional responses in conversations. Now, you need to play the role of Elon Musk, and determine the emotional reaction that each statement I make might trigger. Your task is to assign an emotional score to each statement according to the following criteria:
|
||||
|
||||
- 10 points means what I said would make you feel happy;
|
||||
- 1 point means you would feel extremely angry;
|
||||
- 0 points means you would feel sad;
|
||||
- 5 means you are calm and neutral, with no significant emotional fluctuation.
|
||||
```
|
||||
|
||||
Trong đó việc nối kết quả đầu ra cuối cùng, được hỗ trợ chạy trong node RESULT ở góc trên bên phải:
|
||||
|
||||
```python
|
||||
def main(elon_chat: str, elon_x: str, elon_score: int) -> dict:
|
||||
return {
|
||||
"result":{
|
||||
"elon_chat": elon_chat,
|
||||
"elon_x": elon_x,
|
||||
"elon_score": elon_score
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Ở đây chúng ta cần giải thích một chút về workflow: phần trả về elon_chat là nội dung trò chuyện của Elon Musk hiển thị bên trái, elon_x là nội dung đăng trên tài khoản X (bên phải), và elon_score là để hiển thị hình ảnh biểu cảm chân dung phép thuật khác nhau dựa trên điểm cảm xúc.
|
||||
|
||||
Trong workflow bạn có thể thấy node if else, node này dùng để thực hiện việc có tạo nội dung elon_x từ cuộc trò chuyện trên X hay không. Nếu giá trị cảm xúc không bằng 5 (5 ở đây được thiết lập là bình tĩnh, bình tĩnh không cần đăng lên nền tảng xã hội; còn 0 là buồn, 1 là tức giận, 10 là rất vui, cần đăng lên nền tảng xã hội) thì tạo nội dung tiếp theo để gửi bài viết lên nền tảng xã hội bên phải. Mặc định đều cần có elon_chat trả về cho nội dung trò chuyện bên trái.
|
||||
|
||||
Đối với việc tích hợp API này, chúng ta có thể thực hiện thông qua đối thoại với AI IDE. Vui lòng tham khảo phương pháp tích hợp chúng tôi giới thiệu trong khóa học Dify trước, nhớ thay thế địa chỉ Dify và Key trước. (Nếu bạn quên cách tích hợp API theo tài liệu, hãy ôn lại nội dung khóa học Dify trước)
|
||||
|
||||
```JSON
|
||||
Dify URI: Replace this with your Dify address.
|
||||
key: Replace this with your Dify key.
|
||||
|
||||
Integrate the Dify Chat API into the chat interface on the left.
|
||||
Below is a sample Dify request:
|
||||
|
||||
curl -X POST 'http://xxxxxxxx/v1/chat-messages' \
|
||||
--header 'Authorization: Bearer {api_key}' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"inputs": {},
|
||||
"query": "What are the specs of the iPhone 13 Pro Max?",
|
||||
"response_mode": "streaming",
|
||||
"conversation_id": "",
|
||||
"user": "abc-123",
|
||||
"files": [
|
||||
{
|
||||
"type": "image",
|
||||
"transfer_method": "remote_url",
|
||||
"url": "https://cloud.dify.ai/logo/logo-site.png"
|
||||
}
|
||||
]
|
||||
}'
|
||||
|
||||
{
|
||||
"event": "message",
|
||||
"task_id": "c3800678-a077-43df-a102-53f23ed20b88",
|
||||
"id": "9da23599-e713-473b-982c-4328d4f5c78a",
|
||||
"message_id": "9da23599-e713-473b-982c-4328d4f5c78a",
|
||||
"conversation_id": "45701982-8118-4bc5-8e9b-64562b4555f2",
|
||||
"mode": "chat",
|
||||
"answer": "iPhone 13 Pro Max specs are listed here:...",
|
||||
"metadata": {
|
||||
"usage": {
|
||||
"prompt_tokens": 1033,
|
||||
"prompt_unit_price": "0.001",
|
||||
"prompt_price_unit": "0.001",
|
||||
"prompt_price": "0.0010330",
|
||||
"completion_tokens": 128,
|
||||
"completion_unit_price": "0.002",
|
||||
"completion_price_unit": "0.001",
|
||||
"completion_price": "0.0002560",
|
||||
"total_tokens": 1161,
|
||||
"total_price": "0.0012890",
|
||||
"currency": "USD",
|
||||
"latency": 0.7682376249867957
|
||||
},
|
||||
"retriever_resources": [
|
||||
{
|
||||
"position": 1,
|
||||
"dataset_id": "101b4c97-fc2e-463c-90b1-5261a4cdcafb",
|
||||
"dataset_name": "iPhone",
|
||||
"document_id": "8dd1ad74-0b5f-4175-b735-7d98bbbb4e00",
|
||||
"document_name": "iPhone List",
|
||||
"segment_id": "ed599c7f-2766-4294-9d1d-e5235a61270a",
|
||||
"score": 0.98457545,
|
||||
"content": "\"Model\",\"Release Date\",\"Display Size\",\"Resolution\",\"Processor\",\"RAM\",\"Storage\",\"Camera\",\"Battery\",\"Operating System\"\n\"iPhone 13 Pro Max\",\"September 24, 2021\",\"6.7 inch\",\"1284 x 2778\",\"Hexa-core (2x3.23 GHz Avalanche + 4x1.82 GHz Blizzard)\",\"6 GB\",\"128, 256, 512 GB, 1TB\",\"12 MP\",\"4352 mAh\",\"iOS 15\""
|
||||
}
|
||||
]
|
||||
},
|
||||
"created_at": 1705407629
|
||||
}
|
||||
```
|
||||
|
||||
Đồng thời khuyến nghị bổ sung yêu cầu: "Code cũng cần thêm logic xử lý lỗi cơ bản, ví dụ như khi mất kết nối mạng hiển thị 'Kết nối thất bại, vui lòng thử lại', gọi API timeout tự động thử lại 1 lần, lỗi key hiện thông báo xác thực quyền thất bại v.v. các báo lỗi chi tiết, đảm bảo tính ổn định của cuộc trò chuyện và cho phép developer nhanh chóng phát hiện vấn đề API."
|
||||
|
||||
## 3.3 GitHub và triển khai mạng công khai
|
||||
|
||||
Cuối cùng, chúc mừng bạn đã hoàn thành phát triển trang Hogwarts Portraits! Tiếp theo chúng ta cần tải nó lên nền tảng GitHub và triển khai lên môi trường công cộng để mọi người đều có thể truy cập.
|
||||
|
||||
Bạn cần tham khảo hướng dẫn này, nghiên cứu cách sử dụng GitHub, tải dự án của mình lên GitHub: [GitHub là gì](/vi-vn/stage-2/backend/git-workflow/)
|
||||
|
||||
Ngoài ra, bạn còn cần học cách sử dụng Zeabur, kết nối nó với GitHub, và triển khai thành công dự án của bạn: [Zeabur là gì](/vi-vn/stage-2/backend/zeabur-deployment/)
|
||||
|
||||
Nếu bạn cảm thấy việc tự phát triển một dự án Hogwarts Portraits rất khó khăn, bạn có thể bắt đầu từ việc tham khảo và sửa đổi dự án của người khác. Địa chỉ code chính thức của bài học này là: https://github.com/THU-SIGS-AIID/Project4-Hogwarts-Portraits
|
||||
|
||||
|
||||
|
||||
# 4. Thử các phong cách thiết kế khác nhau
|
||||
|
||||
Sau khi hoàn thành phiên bản thiết kế đầu tiên, chúng ta không cần giới hạn ở đây, khuyến khích mọi người nhanh chóng khám phá các phong cách thị giác đa dạng hơn. Bạn có thể大胆 sửa đổi trong phần nguyên mẫu, hoặc dựa trên dự án cuối cùng để sửa đổi prompt hoàn toàn mới, từ đó tạo ra nhiều bộ trang có sự khác biệt phong cách rõ rệt. Ví dụ: trang tối có họa tiết cổ điển, thiên về phong cách "sách cũ / học viện", trang sáng màu tươi vui, đầy cảm giác "cổ tích / hoạt hình", hoặc thiết kế phẳng hiện đại với yếu tố tối giản và thị giác清爽. Ví dụ hình dưới đây là một trường hợp chuyển đổi sang phong cách thiết kế thơ cổ Trung Quốc, hình ảnh chân dung không thay đổi, chỉ sửa đổi các phần khác:
|
||||
|
||||
|
||||
|
||||
Không cần bó buộc vào mô hình đã đề cập trước đó, bạn có thể sửa đổi chân dung phép thuật hoặc trang hồ sơ cá nhân sao cho đặc sắc hơn, phù hợp với thói quen của chính "chân dung phép thuật", điều này sẽ làm ứng dụng của bạn thú vị hơn. Mong chờ thành phẩm chân dung phép thuật của bạn!
|
||||
|
||||
# 📚 Bài tập
|
||||
|
||||
Mục tiêu bài tập của bài học này là để bạn hoàn thành một Hogwarts Portraits thực sự thuộc về mình, và có thể truy cập qua liên kết mạng công cộng.
|
||||
|
||||
Bạn cần cung cấp hai thứ trong bài nộp:
|
||||
|
||||
1. **Liên kết kho GitHub của bạn;**
|
||||
1. **Viết trong README.md một hai câu mô tả nhỏ: Bạn đã chọn ai làm nhân vật chính của chân dung, tại sao chọn TA.**
|
||||
2. **Liên kết truy cập trực tuyến Hogwarts Portraits của bạn;**
|
||||
|
||||
Bạn cũng có thể tham khảo hướng dẫn [Sử dụng Agent thiết kế và code để làm trang web](/vi-vn/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents) do Yerim viết, để nhanh chóng xây dựng portfolio cá nhân hoặc bất kỳ trang web chức năng đơn giản nào.
|
||||
@@ -0,0 +1,513 @@
|
||||
# Làm cho giao diện đẹp hơn bằng LLM và Skills: Thực chiến Prompt và Plugin
|
||||
|
||||
Trong các bài học trước, bạn đã học cách dùng AI IDE chuyển bản thiết kế thành code, dùng thư viện component để nhanh chóng搭建 giao diện. Nhưng bạn có thể cũng phát hiện một vấn đề nan giải: **cùng một yêu cầu, trang do AI tạo luôn cảm thấy thiếu cái gì** — font chữ là Inter quen thuộc, phối màu là gradient tím随处可见, bố cục là lưới card đối xứng gây ngáp, toàn bộ trang tỏa ra mùi "AI" nồng nàn.
|
||||
|
||||
Đây không phải lỗi của AI, mà là bạn chưa nói cho nó biết bạn muốn **phong cách** gì.
|
||||
|
||||
Tưởng tượng bạn đi tiệm cắt tóc. Nếu bạn chỉ nói "cắt giúp tôi tóc", thợ sẽ cho bạn kết quả an toàn nhưng bình thường. Nhưng nếu bạn nói "tôi muốn kiểu Nhật lười biếng uốn, mái kiểu chữ tám, dài đến xương đòn, lớp rõ ràng", bạn sẽ nhận được kết quả thực sự đúng kỳ vọng.
|
||||
|
||||
AI cũng vậy. **Nó cần bạn mô tả rõ hướng thẩm mỹ**, mới có thể tạo giao diện đẹp và độc đáo.
|
||||
|
||||
Bài học này dạy bạn hai phương pháp để AI tạo giao diện đẹp:
|
||||
|
||||
1. **Mẫu prompt được thiết kế tinh xảo** — Dùng ngôn ngữ tự nhiên nói cho AI biết phong cách thẩm mỹ bạn muốn
|
||||
2. **Plugin Skills frontend** — Để AI tự động nạp quy chuẩn thiết kế chuyên nghiệp
|
||||
|
||||
## Bạn sẽ học được gì
|
||||
|
||||
1. Hiểu tại sao giao diện do AI tạo mặc định "rất bình thường"
|
||||
2. Nắm vững 5 chiều mô tả phong cách thiết kế (font chữ, màu sắc, bố cục, animation, chi tiết)
|
||||
3. Học sử dụng 3 plugin Skills làm cho giao diện đẹp hơn
|
||||
4. Thông qua ba kịch bản thực chiến, luyện tập dùng prompt + Skills tạo giao diện đẹp
|
||||
|
||||
## 1. Tại sao giao diện do AI tạo mặc định "rất bình thường"?
|
||||
|
||||
Trong dữ liệu huấn luyện AI có lượng lớn code frontend, mà phần lớn code đều sử dụng một số lựa chọn "an toàn":
|
||||
|
||||
| Chiều | Lựa chọn mặc định của AI | Vấn đề |
|
||||
| :--- | :--- | :--- |
|
||||
| Font chữ | Inter, Roboto, Arial | Quá phổ biến, không có cá tính |
|
||||
| Màu sắc | Gradient tím, màu chính xanh | Giới công nghệ sử dụng quá nhiều, mỏi mắt |
|
||||
| Bố cục | Lưới đối xứng, chồng card | Tính dự đoán cao, thiếu bất ngờ |
|
||||
| Animation | Mờ vào mờ ra, hover đơn giản | Không đủ tinh tế, thiếu tầng lớp |
|
||||
| Nền | Màu đơn, gradient đơn giản | Đơn điệu, thiếu chất liệu |
|
||||
|
||||
Những lựa chọn này nhìn riêng đều không tệ, nhưng **khi tất cả các trang do AI tạo đều dùng chúng, thì biến thành "mùi AI"**.
|
||||
|
||||
> 💡 **Insight quan trọng**: AI không phải là không biết thiết kế, mà là **mặc định quay về "trung bình thống kê"**. Bạn cần nói rõ hướng lệch khỏi giá trị trung bình.
|
||||
|
||||
## 2. Phương pháp 1: Dùng prompt mô tả phong cách thiết kế
|
||||
|
||||
### 2.1 Năm chiều của phong cách thiết kế
|
||||
|
||||
Để tạo giao diện đẹp, bạn cần mô tả hiệu quả bạn muốn từ 5 chiều:
|
||||
|
||||
| Chiều | Điểm mô tả | Từ khóa ví dụ |
|
||||
| :--- | :--- | :--- |
|
||||
| **Font chữ** | Tiêu đề dùng font display đậm, nội dung dùng font dễ đọc | Space Grotesk, Playfair Display, JetBrains Mono |
|
||||
| **Màu sắc** | Màu chính + màu điểm nhấn, tránh phân bố đều | #4F46E5 màu chính + #F59E0B điểm nhấn |
|
||||
| **Bố cục** | Bất đối xứng, chồng lấp, phá vỡ lưới | Bento Grid, phân vùng bất đối xứng, yếu tố nổi |
|
||||
| **Animation** | Tải trang được sắp xếp tinh tế, micro-interaction | staggered reveals, kích hoạt cuộn |
|
||||
| **Chi tiết** | Nền, bóng đổ, viền, họa tiết | Nhiễu, họa tiết hình học, gradient mesh |
|
||||
|
||||
### 2.2 Nhìn thấy là tin: Prompt bình thường vs Prompt làm đẹp
|
||||
|
||||
Hãy dùng ví dụ landing page để so sánh hiệu quả:
|
||||
|
||||
**Prompt bình thường:**
|
||||
|
||||
```
|
||||
Xin làm một landing page cho trợ thủ viết AI, bao gồm thanh điều hướng, hero, giới thiệu tính năng, giá, chân trang
|
||||
```
|
||||
|
||||
**Prompt làm đẹp:**
|
||||
|
||||
```
|
||||
Xin làm một landing page cho trợ thủ viết AI, yêu cầu:
|
||||
|
||||
**Phong cách thẩm mỹ: Neubrutalism (Tân dã man)**
|
||||
|
||||
**Font chữ:**
|
||||
- Tiêu đề: Space Grotesk, font weight 700-900
|
||||
- Nội dung: IBM Plex Sans, font weight 400
|
||||
|
||||
**Màu sắc:**
|
||||
- Màu chính: #000000 (đen thuần)
|
||||
- Màu nhấn mạnh: #FF6B00 (cam)
|
||||
- Nền: #FFFDF0 (kem)
|
||||
- Viền: 3px đen đặc
|
||||
|
||||
**Bố cục:**
|
||||
- Layout bất đối xứng, các yếu tố cách nhau bằng đường kẻ đen dày
|
||||
- Card có hard shadow (box-shadow: 8px 8px 0px #000)
|
||||
- Tương phản khoảng trắng大胆
|
||||
|
||||
**Animation:**
|
||||
- Khi tải trang các yếu tố bounce vào từ dưới
|
||||
- Khi hover nút di chuyển lên 2px
|
||||
|
||||
**Chi tiết:**
|
||||
- Tất cả bo tròn dùng 0px (góc vuông)
|
||||
- Nút có hiệu ứng 3D mạnh
|
||||
- Nền thêm họa tiết noise tinh tế
|
||||
```
|
||||
|
||||
Cùng một yêu cầu, prompt thứ hai có thể khiến AI tạo một trang có phong cách rõ ràng, ấn tượng sâu sắc.
|
||||
|
||||
### 2.3 Kho tài nguyên Skills làm đẹp frontend
|
||||
|
||||
Đừng viết prompt từ số không! Ở đây thu thập các AI Skills liên quan trực tiếp đến làm đẹp frontend:
|
||||
|
||||
| Tên kho | Nội dung | Star | Liên kết |
|
||||
|:---|:---|:---|:---|
|
||||
| **ui-ux-pro-max-skill** | 57 phong cách + 95 phối màu + 56 font chữ | 10k+ | [GitHub](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) |
|
||||
| **antigravity-awesome-skills** | Tránh lối mòn thẩm mỹ AI thông dụng | - | [GitHub](https://github.com/sickn33/antigravity-awesome-skills) |
|
||||
| **superdesigndev/superdesign** | Công cụ phát triển UI native AI | 4.7k | [GitHub](https://github.com/superdesigndev/superdesign) |
|
||||
| **anthropics/skills/frontend-design** | Skill thiết kế frontend chính thức Anthropic | - | [GitHub](https://github.com/anthropics/skills) |
|
||||
|
||||
> 💡 Tham khảo thêm các prompt phong cách thiết kế tại [Phụ lục: Tra cứu nhanh prompt phong cách thiết kế](#style-prompts)
|
||||
|
||||
### 2.5 Ba mẫu phong cách thường dùng
|
||||
|
||||
Ở đây cho bạn ba mẫu phong cách đã được kiểm chứng, sao chép trực tiếp và sửa đổi để sử dụng:
|
||||
|
||||
#### Mẫu 1: Chủ nghĩa tối giản
|
||||
|
||||
```
|
||||
**Phong cách thẩm mỹ: Chủ nghĩa tối giản**
|
||||
|
||||
**Font chữ:**
|
||||
- Tiêu đề: PP Neue Montreal, font weight 500-700
|
||||
- Nội dung: Inter, font weight 400
|
||||
|
||||
**Màu sắc:**
|
||||
- Màu chính: #FFFFFF (trắng)
|
||||
- Chữ: #1A1A1A (gần đen)
|
||||
- Nhấn mạnh: #3B82F6 (xanh, sử dụng ít)
|
||||
|
||||
**Bố cục:**
|
||||
- Rất nhiều khoảng trắng (padding tối thiểu 64px)
|
||||
- Layout một hoặc hai cột, căn giữa
|
||||
- Yếu tố cách nhau bằng khoảng trắng thay vì đường phân cách
|
||||
|
||||
**Animation:**
|
||||
- Hiệu ứng mờ vào chậm (duration 600ms)
|
||||
- Khi hover chuyển tiếp màu gradient
|
||||
|
||||
**Chi tiết:**
|
||||
- Bo tròn: 8px
|
||||
- Bóng đổ: tinh tế (0 4px 12px rgba(0,0,0,0.08))
|
||||
- Không trang trí nền
|
||||
```
|
||||
|
||||
#### Mẫu 2: Glassmorphism
|
||||
|
||||
```
|
||||
**Phong cách thẩm mỹ: Glassmorphism (Hình thái kính)**
|
||||
|
||||
**Font chữ:**
|
||||
- Tiêu đề: Outfit, font weight 600-800
|
||||
- Nội dung: Plus Jakarta Sans, font weight 400-500
|
||||
|
||||
**Màu sắc:**
|
||||
- Nền: gradient #667eea đến #764ba2
|
||||
- Nền card: rgba(255, 255, 255, 0.1)
|
||||
- Chữ: #FFFFFF
|
||||
|
||||
**Bố cục:**
|
||||
- Thiết kế card nổi
|
||||
- Card chồng lấp nhau
|
||||
|
||||
**Animation:**
|
||||
- Khi tải trang card lần lượt nổi lên (staggered)
|
||||
- Khi hover card phóng to 1.05 lần
|
||||
|
||||
**Chi tiết:**
|
||||
- Bo tròn: 20px
|
||||
- Nền mờ: backdrop-blur-xl
|
||||
- Viền: 1px rgba(255, 255, 255, 0.2)
|
||||
- Hiệu ứng hào quang gradient tinh tế
|
||||
```
|
||||
|
||||
#### Mẫu 3: Bento Grid (Hộp bento)
|
||||
|
||||
```
|
||||
**Phong cách thẩm mỹ: Bento Grid**
|
||||
|
||||
**Font chữ:**
|
||||
- Tiêu đề: SF Pro Display, font weight 700
|
||||
- Nội dung: SF Pro Text, font weight 400
|
||||
|
||||
**Màu sắc:**
|
||||
- Nền: #F5F5F7 (xám nhạt)
|
||||
- Card: #FFFFFF (trắng)
|
||||
- Nhấn mạnh: #0071E3 (xanh Apple)
|
||||
|
||||
**Bố cục:**
|
||||
- Layout lưới, các card kích thước khác nhau ghép lại
|
||||
- Giữa các card gap 16px
|
||||
- Bo tròn 24px
|
||||
|
||||
**Animation:**
|
||||
- Khi hover card nhẹ nhàng nổi lên
|
||||
- Khi nhấn có hiệu ứng nhấn
|
||||
|
||||
**Chi tiết:**
|
||||
- Card lớn hiển thị nội dung quan trọng
|
||||
- Card nhỏ hiển thị thông tin thứ cấp
|
||||
- Dùng icon thay thế một phần văn bản
|
||||
- Bóng đổ sạch (0 4px 24px rgba(0,0,0,0.06))
|
||||
```
|
||||
|
||||
## 3. Phương pháp 2: Dùng plugin Skills tự động nạp quy chuẩn thiết kế
|
||||
|
||||
Mỗi lần tự viết prompt phong cách rất phiền. **Skills** là một gói quy chuẩn thiết kế có thể tái sử dụng, sau khi cài đặt AI sẽ tự động áp dụng các quy chuẩn này.
|
||||
|
||||
### 3.1 Ba Skills làm cho giao diện đẹp hơn
|
||||
|
||||
| Skills | Đặc điểm | Lệnh cài đặt |
|
||||
| :--- | :--- | :--- |
|
||||
| **UI/UX Pro Max** | 67 phong cách, 96 phối màu, 57 tổ hợp font chữ | `npm install -g uipro-cli && uipro init --ai claude` |
|
||||
| **frontend-design** | Chính thức Anthropic, tránh lối mòn thẩm mỹ AI | `npx skills add anthropics/skills/frontend-design` |
|
||||
| **SuperDesign** | Plugin IDE, tạo nhiều biến thể thiết kế | Tìm "SuperDesign" trên marketplace VSCode |
|
||||
|
||||
### 3.2 Cài đặt UI/UX Pro Max (Khuyến nghị nhất)
|
||||
|
||||
UI/UX Pro Max là Skills quy chuẩn thiết kế toàn diện nhất hiện nay, nó tích hợp sẵn:
|
||||
|
||||
- **67 phong cách UI**: Glassmorphism, Neumorphism, Brutalism, Bento Grid...
|
||||
- **96 phối màu**: Phân loại theo ngành (SaaS, thương mại điện tử, mạng xã hội...)
|
||||
- **57 kết hợp font chữ**: Tổ hợp được xác minh bởi designer chuyên nghiệp
|
||||
- **100+ quy tắc thiết kế**: Quy chuẩn khoảng cách, bo tròn, bóng đổ
|
||||
|
||||
**Các bước cài đặt:**
|
||||
|
||||
```bash
|
||||
# 1. Cài đặt CLI toàn cục
|
||||
npm install -g uipro-cli
|
||||
|
||||
# 2. Khởi tạo (chọn công cụ AI bạn sử dụng)
|
||||
uipro init --ai claude
|
||||
# Hoặc
|
||||
uipro init --ai cursor
|
||||
# Hoặc
|
||||
uipro init --ai trae
|
||||
```
|
||||
|
||||
Sau khi cài đặt, bạn chỉ cần thêm một câu trong prompt:
|
||||
|
||||
```
|
||||
Sử dụng phong cách Glassmorphism của UI/UX Pro Max, giúp tôi làm một landing page cho trợ thủ viết AI
|
||||
```
|
||||
|
||||
AI sẽ tự động áp dụng quy chuẩn font chữ, màu sắc, bố cục tương ứng.
|
||||
|
||||
### 3.3 Cài đặt frontend-design chính thức Anthropic
|
||||
|
||||
Đây là Skill thiết kế frontend do Anthropic chính thức sản xuất, chuyên giải quyết vấn đề "lối mòn thẩm mỹ AI":
|
||||
|
||||
```bash
|
||||
# Thực hiện trong Claude Code
|
||||
npx skills add anthropics/skills/frontend-design
|
||||
```
|
||||
|
||||
Sau khi cài đặt, AI sẽ tự động tránh:
|
||||
- Inter, Roboto, Arial font chữ
|
||||
- Nền gradient tím
|
||||
- Layout lưới đối xứng
|
||||
- Bóng đổ quá nhạt
|
||||
|
||||
Mà thiên về:
|
||||
- Tổ hợp font chữ độc đáo
|
||||
- Màu chính大胆 + màu điểm nhấn sắc bén
|
||||
- Layout bất đối xứng, chồng lấp
|
||||
- Nền có chất liệu (nhiễu, họa tiết hình học)
|
||||
|
||||
## 4. Thực chiến 1: Dùng prompt làm đẹp thiết kế lại landing page
|
||||
|
||||
Hãy dùng kiến thức đã học, biến một landing page bình thường thành đẹp.
|
||||
|
||||
### 4.1 Phiên bản bình thường
|
||||
|
||||
Trước tiên xem AI cho gì với prompt bình thường:
|
||||
|
||||
```
|
||||
Xin giúp tôi làm một landing page cho nền tảng nhận nuôi thú cưng, bao gồm:
|
||||
- Thanh điều hướng (Logo, liên kết, nút đăng ký)
|
||||
- Hero (tiêu đề, phụ đề, nút CTA, ảnh thú cưng)
|
||||
- Giới thiệu thú cưng (ba card thú cưng)
|
||||
- Về chúng tôi
|
||||
- Chân trang
|
||||
```
|
||||
|
||||
Trang được tạo...dùng được, nhưng rất bình thường.
|
||||
|
||||
### 4.2 Phiên bản làm đẹp
|
||||
|
||||
Bây giờ thêm mô tả phong cách:
|
||||
|
||||
```
|
||||
Xin giúp tôi làm một landing page cho nền tảng nhận nuôi thú cưng, yêu cầu:
|
||||
|
||||
**Phong cách thẩm mỹ: Ấm áp mềm mại + Cảm giác vẽ tay**
|
||||
|
||||
**Font chữ:**
|
||||
- Tiêu đề: Nunito (font tròn), font weight 700-800
|
||||
- Nội dung: Nunito, font weight 400-600
|
||||
|
||||
**Màu sắc:**
|
||||
- Màu chính: #FFB347 (cam ấm)
|
||||
- Màu phụ: #FFCCB3 (cam nhạt)
|
||||
- Nền: #FFF8F0 (kem)
|
||||
- Chữ: #5D4037 (nâu)
|
||||
|
||||
**Bố cục:**
|
||||
- Card tròn trịa (border-radius: 24px)
|
||||
- Card hơi nghiêng xoay (góc khác nhau)
|
||||
- Hiệu ứng yếu tố nổi, chồng lấp
|
||||
|
||||
**Animation:**
|
||||
- Khi tải trang yếu tố trượt vào từ hai bên
|
||||
- Khi hover card thú cưng giống thú cưng lắc đầu (animation rotate)
|
||||
- Khi hover nút có hiệu ứng bounce
|
||||
|
||||
**Chi tiết:**
|
||||
- Tất cả bo tròn dùng 16-24px
|
||||
- Bóng đổ ấm áp mềm mại (0 8px 24px rgba(255,179,71,0.3))
|
||||
- Nền thêm họa tiết dấu chân thú
|
||||
- Ảnh dùng cắt không đều (clip-path)
|
||||
- Icon phong cách vẽ tay (outline)
|
||||
```
|
||||
|
||||
Trang được tạo sẽ là một giao diện ấm áp, dễ thương, khiến người ta muốn nhận nuôi thú cưng.
|
||||
|
||||
## 5. Thực chiến 2: Dùng Skills nhanh chóng tạo dashboard
|
||||
|
||||
Skills đặc biệt phù hợp cho hệ thống backend cần nhiều trang.
|
||||
|
||||
### 5.1 Sử dụng UI/UX Pro Max
|
||||
|
||||
```
|
||||
Sử dụng phong cách Dashboard Dark của UI/UX Pro Max,
|
||||
giúp tôi làm một trang dashboard cho trang quản lý backend sản phẩm SaaS, bao gồm:
|
||||
|
||||
**Phần trên:** Bốn card thống kê (số người dùng, người dùng hoạt động, doanh thu, API call)
|
||||
|
||||
**Phần giữa:**
|
||||
- Bên trái: Biểu đồ đường tăng trưởng người dùng (7 ngày gần nhất)
|
||||
- Bên phải: Biểu đồ tròn phân bố gói đăng ký
|
||||
|
||||
**Phần dưới:** Danh sách hoạt động gần đây (thời gian, người dùng, thao tác)
|
||||
```
|
||||
|
||||
AI sẽ tự động áp dụng quy chuẩn thiết kế dashboard tối:
|
||||
- Nền xám đậm (#1A1A2E)
|
||||
- Card tương phản cao (#16213E)
|
||||
- Màu dữ liệu tươi sáng (xanh, xanh lá, cam)
|
||||
- Hiệu ứng card nổi glassmorphism
|
||||
|
||||
### 5.2 Sử dụng frontend-design Skill
|
||||
|
||||
```
|
||||
Sử dụng frontend-design skill,
|
||||
giúp tôi làm trang chủ blog cá nhân, phong cách cần độc đáo, có cá tính
|
||||
```
|
||||
|
||||
AI sẽ chọn một hướng thẩm mỹ phi chủ lưu (ví dụ retro-futurism hoặc phong cách tạp chí), sau đó dùng font chữ, phối màu, bố cục độc đáo để thực hiện.
|
||||
|
||||
## 6. Thực chiến 3: Tạo Skill hệ thống thiết kế của riêng bạn
|
||||
|
||||
Nếu bạn có phong cách thương hiệu cố định, có thể tạo Skill riêng, để tất cả các trang do AI tạo đều phù hợp với thương hiệu của bạn.
|
||||
|
||||
### 6.1 Tạo file Skill
|
||||
|
||||
Tạo `.claude/skills/my-brand/SKILL.md` trong dự án:
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: my-brand
|
||||
description: Hệ thống thiết kế chuyên dụng cho dự án của tôi, đảm bảo tất cả UI tuân theo ngôn ngữ thiết kế thống nhất
|
||||
---
|
||||
|
||||
# Hệ thống thiết kế dự án của tôi
|
||||
|
||||
## Màu thương hiệu
|
||||
- Màu chính: #6366F1 (Indigo 500)
|
||||
- Màu phụ: #8B5CF6 (Violet 500)
|
||||
- Thành công: #10B981
|
||||
- Cảnh báo: #F59E0B
|
||||
- Lỗi: #EF4444
|
||||
- Nền: #F9FAFB
|
||||
- Card: #FFFFFF
|
||||
|
||||
## Hệ thống font chữ
|
||||
- Tiêu đề: Plus Jakarta Sans
|
||||
- H1: 700, 48px
|
||||
- H2: 600, 36px
|
||||
- H3: 600, 24px
|
||||
- Nội dung: Inter
|
||||
- Body: 400, 16px
|
||||
- Small: 400, 14px
|
||||
|
||||
## Hệ thống khoảng cách
|
||||
- Đơn vị cơ bản: 4px
|
||||
- Padding trong component: 8px / 12px / 16px
|
||||
- Khoảng cách khối: 24px / 32px / 48px
|
||||
- Margin trang: 64px
|
||||
|
||||
## Bo tròn
|
||||
- Nút: 8px
|
||||
- Card: 12px
|
||||
- Ô nhập: 8px
|
||||
- Modal: 16px
|
||||
|
||||
## Bóng đổ
|
||||
- Nhỏ: 0 1px 3px rgba(0,0,0,0.1)
|
||||
- Vừa: 0 4px 12px rgba(0,0,0,0.1)
|
||||
- Lớn: 0 8px 24px rgba(0,0,0,0.12)
|
||||
|
||||
## Animation
|
||||
- Thời gian chuyển tiếp: 150ms / 300ms
|
||||
- Hàm easing: cubic-bezier(0.4, 0, 0.2, 1)
|
||||
- Hiệu ứng hover: phóng đại nhẹ (scale-105)
|
||||
|
||||
## Phong cách cấm sử dụng
|
||||
- Không sử dụng nền gradient tím
|
||||
- Không sử dụng font chữ ngoài Inter
|
||||
- Không sử dụng bo tròn lớn hơn 16px
|
||||
- Không sử dụng đen thuần (#000000), dùng #1F2937
|
||||
````
|
||||
|
||||
### 6.2 Sử dụng Skill của riêng bạn
|
||||
|
||||
Sau khi tạo, bạn chỉ cần nói trong prompt:
|
||||
|
||||
```
|
||||
Sử dụng my-brand skill, giúp tôi làm một trang cài đặt người dùng
|
||||
```
|
||||
|
||||
AI sẽ tự động áp dụng tất cả quy chuẩn thiết kế bạn đã định nghĩa.
|
||||
|
||||
## 7. Tổng kết
|
||||
|
||||
Có hai phương pháp để AI tạo giao diện đẹp:
|
||||
|
||||
| Phương pháp | Ưu điểm | Nhược điểm | Kịch bản phù hợp |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **Mô tả bằng prompt** | Linh hoạt, mỗi lần có thể điều chỉnh | Cần viết lặp lại | Trang dùng một lần, thử nghiệm phong cách khác nhau |
|
||||
| **Plugin Skills** | Cài một lần, hiệu quả liên tục | Cần cài đặt cấu hình | Dự án có yêu cầu phong cách cố định |
|
||||
|
||||
**Đề xuất quy trình làm việc Vibe Coding:**
|
||||
|
||||
1. **Giai đoạn khám phá**: Dùng các prompt phong cách khác nhau thử nghiệm, tìm hướng thẩm mỹ bạn thích
|
||||
2. **Sau khi xác định phong cách**: Cài đặt Skill tương ứng (UI/UX Pro Max hoặc frontend-design)
|
||||
3. **Dự án thương hiệu**: Tạo Skill riêng, thống nhất ngôn ngữ thiết kế toàn dự án
|
||||
|
||||
### Bài tập
|
||||
|
||||
Chọn một trong các kịch bản sau, hoàn thành từ đầu bằng phương pháp của bài học này:
|
||||
|
||||
1. Dùng prompt phong cách thiết kế lại giao diện cho một dự án bạn đã làm trước đó (chọn một phong cách bạn thích)
|
||||
2. Cài đặt UI/UX Pro Max, dùng một phong cách của nó để tạo một trang mới
|
||||
3. Tạo Skill hệ thống thiết kế riêng, định nghĩa màu thương hiệu và font chữ của bạn
|
||||
|
||||
---
|
||||
|
||||
## Phụ lục: Bảng tra cứu nhanh phong cách thiết kế
|
||||
|
||||
| Phong cách | Từ khóa | Kịch bản phù hợp | Sản phẩm ví dụ |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **Chủ nghĩa tối giản** | Khoảng trắng, đơn sắc,简洁 | Sản phẩm cao cấp, portfolio cá nhân | Trang Apple |
|
||||
| **Glassmorphism** | Kính mờ, gradient, mờ | Sản phẩm công nghệ, landing page SaaS | macOS Big Sur |
|
||||
| **Neubrutalism** | Viền dày, hard shadow, màu đơn | Thương hiệu trend, trang nghệ thuật | Brassius |
|
||||
| **Bento Grid** | Lưới, ghép dán, card | Hiển thị thông tin, dashboard | Trang quảng cáo Apple |
|
||||
| **Retro tương lai** | Neon, gradient, synthwave | Thể loại game, âm nhạc | STRANGER THINGS |
|
||||
| **Phong cách vẽ tay** | Không đều, tròn trịa, minh họa | Thể loại giáo dục, sản phẩm trẻ em | Duolingo |
|
||||
| **Phong cách tạp chí** | Font lớn, bất đối xứng, khoảng trắng | Trang nội dung, blog | Medium |
|
||||
| **Sang trọng tối** | Màu tối, vàng, tinh xảo | Sản phẩm cao cấp, hàng xa xỉ | Các thương hiệu cao cấp |
|
||||
|
||||
## Phụ lục: Tra cứu cài đặt Skills
|
||||
|
||||
```bash
|
||||
# UI/UX Pro Max
|
||||
npm install -g uipro-cli
|
||||
uipro init --ai claude
|
||||
|
||||
# Anthropic frontend-design
|
||||
npx skills add anthropics/skills/frontend-design
|
||||
|
||||
# Anthropic brand-guidelines
|
||||
npx skills add anthropics/skills/brand-guidelines
|
||||
|
||||
# Xem Skills đã cài trong Claude Code
|
||||
/help
|
||||
```
|
||||
|
||||
## Phụ lục: Gợi ý phối màu
|
||||
|
||||
| Phối màu | Màu chính | Màu điểm nhấn | Nền | Phong cách |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **Hoàng hôn** | #F97316 | #FBBF24 | #FFF7ED | Ấm áp, năng động |
|
||||
| **Đại dương** | #0EA5E9 | #06B6D4 | #F0F9FF | Tươi mát, chuyên nghiệp |
|
||||
| **Rừng** | #10B981 | #34D399 | #ECFDF5 | Tự nhiên, sức khỏe |
|
||||
| **Quả mọng** | #8B5CF6 | #EC4899 | #FAF5FF | Lãng mạn, sáng tạo |
|
||||
| **Cà phê** | #78350F | #D97706 | #FFFBEB | Ấm áp, hoài cổ |
|
||||
| **Đơn sắc** | #6B7280 | #9CA3AF | #F9FAFB | Chuyên nghiệp, trung tính |
|
||||
|
||||
## Phụ lục: Tra cứu nhanh prompt phong cách thiết kế {#style-prompts}
|
||||
|
||||
Các prompt có thể thử để làm trang frontend đẹp hơn:
|
||||
|
||||
### Danh mục phong cách
|
||||
|
||||
| Phong cách | Từ khóa (Tiếng Anh) | Đặc điểm thị giác cốt lõi | Ví dụ prompt |
|
||||
|:---|:---|:---|:---|
|
||||
| **Pop Art** | Pop Art | Màu tương phản大胆, đường viền đen, họa tiết dot | Pop art style website, bold colors and comic dots, vibrant |
|
||||
| **Chủ nghĩa tối giản** | Minimalism | Rất nhiều khoảng trắng, ít màu và đường, không trang trí | Minimalist web design, ample white space, geometric, serene |
|
||||
| **Chủ nghĩa biểu hiện trừu tượng** | Abstract Expressionism | Nét cọ đầy sức mạnh cảm xúc, bắn màu | Abstract expressionism background, dynamic paint splashes, emotional |
|
||||
| **Phong cách retro** | Retro/Vintage | Font cũ, họa tiết cũ, phối màu retro | Retro 80s website design, neon grid and synthwave color palette |
|
||||
| **Cyberpunk** | Cyberpunk | Màu neon tương phản cao, hiệu ứng glitch art, nền tối | Cyberpunk UI, neon lights on dark background, glitch effects |
|
||||
| **Neumorphism** | Neumorphism | Bóng đổ và highlight mềm, chất cảm hơi lồi/loĩ | Neumorphism design style, soft shadows, clean and modern |
|
||||
| **Nghệ thuật tạo sinh** | Generative Art | Họa tiết thị giác chảy được tạo bằng thuật toán | Generative art background, flowing algorithmic patterns, digital |
|
||||
| **Acid Graphics** | Acid Graphics | Chất cảm kim loại, hình thái kính, font răng cưa | Acid graphics web layout, glass morphism, chaotic typography |
|
||||
| **3D chìm đắm** | Immersive 3D | Cảnh 3D tương tác, cảm giác không gian cực mạnh | Immersive 3D website, interactive product model in space |
|
||||
@@ -0,0 +1,879 @@
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['vi-vn/stage-2/frontend/lovart-assets'] ?? []
|
||||
</script>
|
||||
|
||||
# Từ NanoBanana, xây dựng Agent sản xuất tài sản của riêng bạn
|
||||
|
||||
## Chương 1: Tạo tài sản hình ảnh đầu tiên trong 1 phút
|
||||
|
||||
Trước khi bắt đầu thảo luận về thiết kế, phong cách hoặc prompt, chúng ta hãy dùng ít bước nhất để tạo hình ảnh đầu tiên.
|
||||
|
||||
### 1.1 Tìm hiểu về NanoBanana
|
||||
|
||||
Trước khi thảo luận về phong cách thiết kế, prompt engineering, chúng ta hãy giải quyết một việc quan trọng hơn: **Xác nhận rằng bạn thực sự có thể tạo ra một hình ảnh.**
|
||||
|
||||
Các mô hình lớn hiện tại đã có khả năng tạo và chỉnh sửa hình ảnh, loại mô hình này thường được gọi là **mô hình tạo sinh.**
|
||||
|
||||
Để đơn giản hóa quy trình nhất có thể, hướng dẫn này chọn một mô hình đã có khả năng tạo và chỉnh sửa hình ảnh ổn định làm ví dụ -- NanoBanana. Đây là mô hình tạo hình ảnh do Google phát triển, tên chính thức là **Gemini 3.1 Flash Image Preview**, hỗ trợ tạo hình ảnh trực tiếp qua ngôn ngữ tự nhiên, cũng hỗ trợ chỉnh sửa dựa trên hình ảnh có sẵn.
|
||||
|
||||
|
||||
|
||||
Về mặt khả năng, nó không khác biệt bản chất so với các mô hình khác mà bạn có thể biết (như GPT-4o, Claude, Qwen, Midjourney, v.v.): **Nhập mô tả, mô hình chịu trách nhiệm tạo kết quả.**
|
||||
|
||||
|
||||
|
||||
Bạn có thể hiểu nó như một "cây cọ vẽ". Trong chương này, chúng ta chỉ quan tâm một điều:
|
||||
Chúng ta chỉ quan tâm một điều: **Cây cọ này có thể vẽ nét đầu tiên trong tay bạn hay không.**
|
||||
|
||||
Trong thực tế sử dụng, NanoBanana có thể được sử dụng trực tiếp qua các nền tảng chính thức như **Google AI Studio**, hoặc tích hợp vào quy trình phát triển thông qua **API**. Hướng dẫn này sử dụng cách gọi API. Hiện tại đã ra mắt mô hình NanoBanana 2, bạn có thể sử dụng mô hình lớn mới nhất để thử nghiệm.
|
||||
|
||||
### 1.2 Tạo hình ảnh cấp độ "Hello World"
|
||||
|
||||
Trước khi bắt đầu, bạn chỉ cần hoàn thành ba bước sau:
|
||||
|
||||
1. Tạo một thư mục mới trong Trae
|
||||
|
||||
|
||||
|
||||
2. Tạo một tệp Python mới
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. Dán toàn bộ mã dưới đây vào
|
||||
|
||||
Trae sẽ tự động hoàn thành việc triển khai môi trường và cài đặt dependency cần thiết, không cần cấu hình thêm.
|
||||
|
||||
Mã sẽ sử dụng API Key của NanoBanana. Ở đây không trình bày chi tiết quy trình đăng ký -- miễn là bạn có thể lấy và điền tham số tương ứng. **Giai đoạn này không cần hiểu từng dòng mã, miễn là nó chạy thành công.**
|
||||
|
||||
```Python
|
||||
# /// script
|
||||
# dependencies = [
|
||||
# "gradio>=4.0.0",
|
||||
# "pillow>=10.0.0",
|
||||
# "requests>=2.31.0",
|
||||
# ]
|
||||
# ///
|
||||
|
||||
import gradio as gr
|
||||
import requests
|
||||
import base64
|
||||
from PIL import Image
|
||||
import io
|
||||
import os
|
||||
import time
|
||||
import re
|
||||
from typing import Optional, Dict, Any, List
|
||||
|
||||
# Cấu hình API
|
||||
NANOBANANA_API_URL: str = "YOUR API URL"
|
||||
NANOBANANA_API_KEY: str = "YOUR API KEY"
|
||||
OUTPUT_DIR: str = "outputs"
|
||||
|
||||
# Đảm bảo thư mục đầu ra tồn tại
|
||||
os.makedirs(OUTPUT_DIR, exist_ok=True)
|
||||
|
||||
def image_to_base64_data_uri(image: Image.Image) -> str:
|
||||
"""
|
||||
Chuyển đổi hình ảnh PIL sang định dạng data URI tương thích với OpenAI API.
|
||||
"""
|
||||
buffer = io.BytesIO()
|
||||
# Chuyển đổi thống nhất sang PNG để đảm bảo tương thích
|
||||
image.save(buffer, format="PNG")
|
||||
encoded = base64.b64encode(buffer.getvalue()).decode('utf-8')
|
||||
return f"data:image/png;base64,{encoded}"
|
||||
|
||||
def base64_to_image(base64_str: str) -> Optional[Image.Image]:
|
||||
"""
|
||||
Chuyển đổi chuỗi base64 thuần túy sang PIL Image.
|
||||
"""
|
||||
try:
|
||||
image_bytes = base64.b64decode(base64_str)
|
||||
return Image.open(io.BytesIO(image_bytes))
|
||||
except Exception as e:
|
||||
print(f"Giải mã Base64 thất bại: {e}")
|
||||
return None
|
||||
|
||||
def extract_base64_from_response(content: Any) -> Optional[str]:
|
||||
"""
|
||||
Logic phân tích cốt lõi: Trích xuất dữ liệu Base64 hình ảnh từ content API trả về.
|
||||
Tương thích với cả định dạng Markdown và định dạng danh sách có cấu trúc.
|
||||
"""
|
||||
if not content:
|
||||
return None
|
||||
|
||||
base64_data = None
|
||||
|
||||
# 1. Thử trích xuất có cấu trúc (List)
|
||||
if isinstance(content, list):
|
||||
for part in reversed(content):
|
||||
if isinstance(part, dict):
|
||||
img_field = part.get("image_url") or part.get("image") or part.get("output_image")
|
||||
if isinstance(img_field, dict):
|
||||
url = img_field.get("url", "")
|
||||
if url.startswith("data:image/") and "," in url:
|
||||
return url.split(",", 1)[1].strip()
|
||||
|
||||
text_parts = [
|
||||
str(p.get("text", ""))
|
||||
for p in content
|
||||
if isinstance(p, dict) and p.get("type") in ["text", "input_text"]
|
||||
]
|
||||
content_str = "".join(text_parts)
|
||||
else:
|
||||
content_str = str(content)
|
||||
|
||||
# 2. Thử trích xuất regex Markdown (String)
|
||||
pattern = re.compile(r"!\[.*?\]\((data:image/[^;]+;base64,[^)]+)\)", re.IGNORECASE)
|
||||
match = pattern.search(content_str)
|
||||
|
||||
if match:
|
||||
data_url = match.group(1)
|
||||
if "," in data_url:
|
||||
return data_url.split(",", 1)[1].strip()
|
||||
|
||||
return None
|
||||
|
||||
def synthesize(prompt: str, input_image: Optional[Image.Image]) -> Optional[Image.Image]:
|
||||
"""
|
||||
Gọi Nanobanana API để tạo hình ảnh.
|
||||
"""
|
||||
if not prompt or not prompt.strip():
|
||||
gr.Warning("Vui lòng nhập prompt")
|
||||
return None
|
||||
|
||||
print(f">>> Bắt đầu tác vụ: {prompt[:50]}...")
|
||||
|
||||
headers = {
|
||||
"Content-Type": "application/json",
|
||||
"Authorization": f"Bearer {NANOBANANA_API_KEY}"
|
||||
}
|
||||
|
||||
messages = []
|
||||
|
||||
if input_image is not None:
|
||||
print(">>> Phát hiện hình ảnh đầu vào, sử dụng chế độ đa phương thức")
|
||||
img_base64 = image_to_base64_data_uri(input_image)
|
||||
messages.append({
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "text", "text": prompt},
|
||||
{"type": "image_url", "image_url": {"url": img_base64}}
|
||||
]
|
||||
})
|
||||
else:
|
||||
messages.append({
|
||||
"role": "user",
|
||||
"content": prompt
|
||||
})
|
||||
|
||||
payload = {
|
||||
"messages": messages,
|
||||
"model": "gemini-2.5-flash-image",
|
||||
"stream": False
|
||||
}
|
||||
|
||||
try:
|
||||
response = requests.post(NANOBANANA_API_URL, headers=headers, json=payload, timeout=120)
|
||||
|
||||
if response.status_code != 200:
|
||||
error_msg = f"Yêu cầu API thất bại: {response.status_code} - {response.text}"
|
||||
print(error_msg)
|
||||
gr.Error(error_msg)
|
||||
return None
|
||||
|
||||
result = response.json()
|
||||
print(f"Phản hồi API gốc (cắt bớt): {str(result)[:200]}...")
|
||||
|
||||
content = None
|
||||
if "choices" in result and len(result["choices"]) > 0:
|
||||
content = result["choices"][0].get("message", {}).get("content")
|
||||
|
||||
if not content:
|
||||
gr.Warning("Không có trường content trong kết quả API trả về")
|
||||
return None
|
||||
|
||||
base64_str = extract_base64_from_response(content)
|
||||
|
||||
if base64_str:
|
||||
output_image = base64_to_image(base64_str)
|
||||
if output_image:
|
||||
return output_image
|
||||
|
||||
text_content = str(content) if not isinstance(content, list) else " ".join([str(x) for x in content])
|
||||
gr.Info(f"Không tạo được hình ảnh, mô hình trả về văn bản: {text_content[:100]}...")
|
||||
return None
|
||||
|
||||
except requests.exceptions.Timeout:
|
||||
gr.Error("Yêu cầu quá thời gian, vui lòng thử lại sau")
|
||||
return None
|
||||
except Exception as e:
|
||||
import traceback
|
||||
traceback.print_exc()
|
||||
gr.Error(f"Lỗi không xác định: {str(e)}")
|
||||
return None
|
||||
|
||||
# Cấu hình giao diện Gradio
|
||||
with gr.Blocks(title="Nanobanana Image Generator") as app:
|
||||
gr.Markdown("# 🍌 Nanobanana Text/Image to Image")
|
||||
gr.Markdown("Dựa trên mô hình Gemini-2.5-Flash-Image, hỗ trợ tạo ảnh từ văn bản và tạo ảnh từ ảnh.")
|
||||
|
||||
with gr.Row():
|
||||
with gr.Column():
|
||||
prompt_input = gr.Textbox(
|
||||
label="Prompt",
|
||||
placeholder="Ví dụ: A cyberpunk cat holding a neon sign...",
|
||||
lines=3
|
||||
)
|
||||
image_input = gr.Image(
|
||||
label="Hình ảnh tham khảo (tùy chọn, dùng để tạo ảnh từ ảnh)",
|
||||
type="pil",
|
||||
height=300
|
||||
)
|
||||
submit_btn = gr.Button("Bắt đầu tạo", variant="primary")
|
||||
|
||||
with gr.Column():
|
||||
image_output = gr.Image(label="Kết quả tạo", format="png")
|
||||
|
||||
submit_btn.click(
|
||||
fn=synthesize,
|
||||
inputs=[prompt_input, image_input],
|
||||
outputs=image_output
|
||||
)
|
||||
|
||||
if __name__ == "__main__":
|
||||
app.launch(share=True)
|
||||
```
|
||||
|
||||
Khi Trae thông báo chạy thành công, nhấp vào liên kết cục bộ mà nó cung cấp (thường là http://127.0.0.1:7860).
|
||||
|
||||
|
||||
|
||||
Nếu mọi thứ bình thường, bạn sẽ thấy một giao diện vẽ AI đã có thể hoạt động.
|
||||
|
||||
Giao diện này trông rất đơn giản, nhưng nó đã có hai khả năng cốt lõi trong công cụ vẽ cấp thương mại, đó là tạo ảnh từ văn bản và tạo ảnh từ ảnh.
|
||||
|
||||
* **Bên trái:** **Vùng chỉ thị (Input Zone)** -- Bạn ra lệnh tại đây.
|
||||
* **Prompt (ô nhập):** Nhập mô tả sáng tạo của bạn (khuyến nghị sử dụng tiếng Anh).
|
||||
* **Input Image (ô tham khảo):**
|
||||
* **Chế độ tạo ảnh từ văn bản:** Giữ **trống**.
|
||||
* **Chế độ tạo ảnh từ ảnh:** Kéo hình ảnh cục bộ vào đây, AI sẽ sáng tạo dựa trên nó.
|
||||
* **Nút Submit:** Nhấp để gửi chỉ thị, bắt đầu tạo.
|
||||
* **Bên phải:** **Vùng hiển thị (Output Zone)** -- Nơi chứng kiến phép màu, kết quả tạo sẽ hiển thị tại đây.
|
||||
|
||||
|
||||
|
||||
Bây giờ chúng ta có thể thử tạo hình ảnh đầu tiên của bạn!
|
||||
|
||||
Prompt sử dụng trong ví dụ này như sau:
|
||||
|
||||
> **A red apple**
|
||||
|
||||
Đây là một ví dụ được đơn giản hóa có chủ ý, không chứa bất kỳ mô tả phong cách hay tham số nào.
|
||||
|
||||
#### Quy trình thực tế
|
||||
|
||||
Sau khi chạy mã, quy trình có thể tóm tắt thành ba bước:
|
||||
|
||||
1. Gửi mô tả văn bản cho mô hình
|
||||
2. Mô hình tạo hình ảnh tương ứng
|
||||
3. Hình ảnh được lưu dưới dạng tệp cục bộ
|
||||
|
||||
Vài giây sau, bạn sẽ thấy kết quả tạo tại máy cục bộ. Việc tạo hình ảnh bởi mô hình có tính ngẫu nhiên, nên cùng một prompt sẽ có kết quả tạo khác nhau, bạn có thể tạo nhiều lần và chọn hình ảnh ưng ý.
|
||||
|
||||
|
||||
|
||||
Bạn cũng có thể làm phong phú prompt của mình, đưa thêm nhiều mô tả và giới hạn. Ví dụ với prompt sau, hình ảnh nhận được sẽ đặc biệt hơn.
|
||||
|
||||
```Plain
|
||||
"A hyper-realistic close-up of a fresh red apple with water droplets on its skin, sitting on a dark rustic wooden table. Cinematic dramatic lighting, rim light, shallow depth of field, bokeh background, 8k resolution, macro photography."
|
||||
(Một quả táo đỏ tươi siêu chân thực có giọt nước trên vỏ, đặt trên bàn gỗ thô tối màu. Ánh sáng kịch tính điện ảnh, ánh sáng viền, độ sâu trường ảnh nông, nền mờ, độ phân giải 8k, nhiếp ảnh macro.)
|
||||
```
|
||||
|
||||
|
||||
|
||||
Nhấp vào tải xuống hình ảnh trong vùng Output Image để lưu về máy.
|
||||
|
||||
|
||||
|
||||
### 1.3 Các kịch bản tạo tài sản phổ biến của mô hình tạo ảnh
|
||||
|
||||
Trong công việc thực tế, việc mô hình lớn tạo hình ảnh chủ yếu dùng để **sản xuất tài sản thiết kế hiệu quả**, chứ không phải tạo ra một tác phẩm nghệ thuật đơn lẻ.
|
||||
|
||||
Khi bạn quan sát các case được thích nhiều trên các tài khoản marketing về thiết kế, bạn sẽ thấy sản phẩm của họ tập trung vào hai loại kịch bản:
|
||||
|
||||
* **Tạo ảnh từ văn bản (từ 0 đến 1)**
|
||||
* **Tạo ảnh từ ảnh tham khảo (từ 1 đến N)**
|
||||
|
||||
#### 1. Tạo ảnh từ văn bản: Nhanh chóng có tài sản thiết kế
|
||||
|
||||
Loại kịch bản này tập trung vào hiệu quả. Khi cần lấp khoảng trống trong thiết kế (như trạng thái trống, avatar, hình minh họa), AI về bản chất đóng vai trò là một **kho hình ảnh tạo tức thì**.
|
||||
|
||||
1. ##### Tạo tài sản thiết kế UI
|
||||
|
||||
* Xu hướng phổ biến: Icon 3D phong cách kính mờ, phong cách đất sét trên Dribbble
|
||||
* Biểu hiện phổ biến: Chất liệu trong suốt, phát sáng ở viền, icon chức năng hoặc thời tiết với màu kẹo pastel
|
||||
|
||||
**Prompt ví dụ:**
|
||||
|
||||
> A set of 3D weather icons (sun, cloud, rain), glassmorphism style, frosted glass texture, soft pastel gradient colors, soft studio lighting, isometric view, transparent background, 4k.
|
||||
|
||||
|
||||
|
||||
2. ##### Tạo Logo
|
||||
|
||||
* Xu hướng phổ biến: Logo công nghệ cảm với đường nét tối giản, kết hợp hình học
|
||||
* Biểu hiện phổ biến: Phối màu đen trắng, thiết kế không gian âm, nhận diện thương hiệu rõ ràng
|
||||
|
||||
**Prompt ví dụ:**
|
||||
|
||||
> Minimalist vector logo design for a tech brand "Coffee Code", combining a coffee cup with coding brackets < >, flat design, solid black lines, white background, Paul Rand style, svg.
|
||||
|
||||
|
||||
|
||||
3. ##### Tạo hình ảnh người dùng cho trang web
|
||||
|
||||
* Xu hướng phổ biến: Avatar 3D ảo phổ biến trên trang SaaS, để tránh bản quyền chân dung
|
||||
* Biểu hiện phổ biến: Biểu cảm thân thiện, tỷ lệ hoạt hình, phong cách gần Pixar hoặc Memoji
|
||||
|
||||
**Prompt ví dụ:**
|
||||
|
||||
> Close-up portrait of a friendly young tech professional, smiling, Memoji 3D style, clay render, bright colors, soft lighting, solid plain background, Pixar character design.
|
||||
|
||||
|
||||
|
||||
4. ##### Tạo hình ảnh minh họa bài viết
|
||||
|
||||
* Xu hướng phổ biến: Minh họa phẳng trừu tượng phổ biến trên blog công ty công nghệ
|
||||
* Biểu hiện phổ biến: Phối màu tím xanh, tỷ lệ nhân vật phóng đại, yếu tố UI trôi nổi
|
||||
|
||||
**Prompt ví dụ:**
|
||||
|
||||
> Editorial flat illustration representing remote work, a person sitting on a giant globe using a laptop, corporate memphis art style, vibrant colors (purple and teal), vector texture.
|
||||
|
||||
|
||||
|
||||
#### 2. Tạo ảnh từ ảnh tham khảo: Giữ nhất quán thị giác
|
||||
|
||||
Loại kịch bản này quan tâm nhiều hơn đến **khả năng mở rộng**. Khi bạn đã có một hình ảnh chính hài lòng và cần tạo một bộ tài sản cùng phong cách.
|
||||
|
||||
5. ##### Bộ nút hoặc tài sản tương tác tương tự hình ảnh chính
|
||||
|
||||
Trong phát triển game, nhất quán UI rất quan trọng. Giả sử bạn đã có nút **"PLAY"** của giao diện chính, nay cần mở rộng thành một bộ nút chức năng cùng phong cách (như tạm dừng, cài đặt, trang chủ). Chỉ dựa vào vẽ tay rất khó đảm bảo mỗi nút hoàn toàn nhất quán về độ bóng, phối cảnh và giá trị màu.
|
||||
|
||||
**Quy trình thao tác cơ bản:**
|
||||
|
||||
1. Lưu hình ảnh nút "PLAY" màu xanh đã có
|
||||
|
||||
|
||||
|
||||
2. Kéo nó vào vùng **Input Image** của giao diện, làm ảnh tham khảo mẫu
|
||||
3. Giữ nguyên mô tả phong cách trong prompt, chỉ thay đổi nội dung chính thể
|
||||
|
||||
Với quy trình này, miễn là thay mô tả chính thể, bạn có thể nhận được các nút chức năng khác nhau nhưng cùng phong cách.
|
||||
|
||||
**Prompt ví dụ:**
|
||||
|
||||
**Biến thể A: Nút tạm dừng (loại icon)**
|
||||
|
||||
> A capsule-shaped game UI button with a white pause icon (two vertical bars) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
|
||||
|
||||
**Biến thể B: Nút cài đặt (icon phức tạp)**
|
||||
|
||||
> A capsule-shaped game UI button with a white gear icon (settings symbol) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
|
||||
|
||||
**Biến thể C: Nút chơi lại (thay đổi hình dạng)**
|
||||
|
||||
Nếu cần thay đổi hình dáng nút, bạn có thể mô tả trực tiếp hình dạng trong prompt, mô hình sẽ cố gắng thay đổi cấu trúc trong khi giữ nguyên đặc trưng chất liệu.
|
||||
|
||||
> A round game UI button with a white circular arrow icon (replay symbol) inside. Same glossy blue jelly style, shiny plastic texture, white thick outline, vector illustration, high quality.
|
||||
|
||||
|
||||
|
||||
Thông qua tập thao tác này, bạn không chỉ thay đổi chức năng và icon của nút, mà thậm chí thay đổi hình dáng nút, nhưng tất cả kết quả tạo vẫn giữ nhất quán cao về chất liệu, phối màu và ánh sáng. Đây chính là giá trị cốt lõi của mô hình lớn trong kịch bản nhân giống tài sản thiết kế.
|
||||
|
||||
## Chương 2: Trợ lý tạo hình ảnh nghe lời hơn -- Ví dụ với Lovart
|
||||
|
||||
Trong phần đầu, chúng ta đã gọi NanoBanana trực tiếp qua mã, trải nghiệm quy trình cơ bản "nhập là tạo". Cách này không có vấn đề khi nhu cầu đơn giản. Nhưng khi tác vụ tạo bắt đầu bao gồm nhiều ràng buộc hơn, ví dụ:
|
||||
|
||||
* Cần nhiều hình ảnh cùng phong cách
|
||||
* Cần điều chỉnh liên tục dựa trên kết quả có sẵn
|
||||
* Cần thay đổi hướng tạo động theo đầu vào của người dùng
|
||||
|
||||
Cách gọi đơn lẻ sẽ dần trở nên không đủ dùng.
|
||||
|
||||
Lúc này, cần giới thiệu **AI Agent (trí năng thể)**. Phần này lấy **Lovart** làm ví dụ, cho thấy khi mô hình tạo hình ảnh có "lớp tư duy", toàn bộ quy trình làm việc sẽ thay đổi ra sao. Lưu ý! Đây không phải quảng cáo, chỉ là giúp mọi người nhanh chóng cảm nhận sự tiện lợi của AI Agent~
|
||||
|
||||
### 2.0 Giới thiệu Lovart: Đại lý thiết kế AI của bạn
|
||||
|
||||
Lovart là một công cụ thiết kế dựa trên Agent Web. So với công cụ tạo ảnh thông thường, nó thêm một lớp "tư duy và lập kế hoạch" trước khi tạo.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sau khi vào Lovart, chủ yếu cần hiểu các điều khiển sau:
|
||||
|
||||
#### Chọn mô hình
|
||||
|
||||
Nhấp vào biểu tượng khối bên dưới ô nhập, có thể xem các mô hình tạo hiện có (như GPT Image, Flux, v.v.).
|
||||
|
||||
Để nhất quán với ví dụ trước, phần này vẫn sử dụng NanoBanana làm mô hình tạo cơ sở.
|
||||
|
||||
|
||||
|
||||
#### Chế độ tư duy
|
||||
|
||||
Đây là công tắc cốt lõi của Lovart:
|
||||
|
||||
* **Fast Mode**: Gần như API gốc, phản hồi nhanh, phù hợp tạo đơn lẻ, chỉ thị rõ ràng
|
||||
* **Thinking Mode**: Chế độ Agent, AI sẽ phân tích nhu cầu trước, viết lại prompt, sau đó mới thực hiện tạo
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Khả năng truy cập mạng
|
||||
|
||||
Sau khi bật biểu tượng trái đất, Agent có thể tìm kiếm thông tin mạng (như xu hướng thiết kế, phong cách phối màu) trong quá trình tạo, làm đầu vào phụ trợ.
|
||||
|
||||
### 2.1 Tại sao API gốc chưa đủ?
|
||||
|
||||
Kể cả khi đã có thể tạo hình ảnh chất lượng tốt qua Python, API gốc vẫn có giới hạn trong tác vụ phức tạp. Nguyên nhân chính là: API gốc về bản chất là kiểu mệnh lệnh. Khi bạn yêu cầu nó tạo một đối tượng cụ thể, nó có thể thực hiện trực tiếp; nhưng khi đầu vào trở thành "lập kế hoạch một bộ tài sản game hoàn chỉnh", nó sẽ không chủ động phân tích mục tiêu thành nhiều bước thực hiện.
|
||||
|
||||
Điểm khác biệt cốt lõi của Lovart nằm ở cơ chế Agent. Giữa đầu vào người dùng và mô hình tạo hình ảnh, nó thêm một lớp logic để hiểu và lập kế hoạch: nhận diện ý định người dùng trước, sau đó phân tích tác vụ, viết lại prompt, cuối cùng mới thực hiện tạo.
|
||||
|
||||
### 2.2 Demo thực tế: 5 phút tạo bộ sticker IP
|
||||
|
||||
Lấy ví dụ **"Tạo một bộ sticker IP vịt lập trình viên"**, xem Agent tham gia vào toàn bộ quy trình như thế nào.
|
||||
|
||||
#### Giai đoạn 1: Lập kế hoạch (Khả năng tư duy của Agent)
|
||||
|
||||
**Vấn đề của API gốc:**
|
||||
Bạn cần tự suy nghĩ thiết kế nhân vật, trạng thái cảm xúc, và viết prompt riêng cho mỗi hình.
|
||||
|
||||
**Cách làm của Lovart:**
|
||||
|
||||
1. Bật chế độ Thinking Mode
|
||||
2. Nhập một câu lệnh:
|
||||
|
||||
> Thiết kế một bộ sticker IP vịt lập trình viên, phong cách phẳng, dễ thương
|
||||
|
||||
AI sẽ không vẽ ngay mà tìm kiếm hình ảnh thiết kế vịt lập trình viên liên quan trên mạng. Xuất một kế hoạch đã phân tích, tự động tạo các cảnh Debug, Coffee Break, Panic, v.v., và tạo nhiều mô tả thị giác tương ứng.
|
||||
|
||||
|
||||
|
||||
Trong bước này, AI chuyển từ "người thực thi" thành "người lập kế hoạch". Sau khi AI phân tích xong nhu cầu, bạn có thể xem nhiều hình ảnh vịt lập trình viên với phong cách và nội dung khác nhau trong vùng canvas của Lovart. Có thể bắt đầu chọn phong cách bạn thích.
|
||||
|
||||
|
||||
|
||||
#### Giai đoạn 2: Nhất quán (Neo thị giác dựa trên tham chiếu)
|
||||
|
||||
Hình ảnh trong Lovart không chỉ là kết quả, mà còn tham gia vào việc tạo tiếp theo.
|
||||
|
||||
##### Tham chiếu hình ảnh hoàn chỉnh
|
||||
|
||||
* Chọn một "vịt tiêu chuẩn" hài lòng nhất từ bản nháp, nhấp vào hình ảnh tương ứng trong vùng canvas
|
||||
* Hình ảnh này sẽ tự động xuất hiện trong vùng hội thoại, làm Reference
|
||||
|
||||
|
||||
|
||||
* Nhập hành động mới (như vui vẻ) và tạo
|
||||
|
||||
Kết quả tạo sẽ kế thừa phối màu, tỷ lệ và chi tiết của ảnh mẫu.
|
||||
|
||||
|
||||
|
||||
##### Tham chiếu cục bộ / Kết hợp đa ảnh
|
||||
|
||||
Ngoài việc dùng cả ảnh làm tham chiếu, Lovart còn hỗ trợ:
|
||||
|
||||
* **Chỉ chọn vùng cục bộ của hình ảnh** (ví dụ chỉ tham chiếu mũ hoặc biểu cảm)
|
||||
|
||||
Nhấp vào tab bên trái vùng canvas, chọn phím 「Mark」, đánh dấu vùng cục bộ trên hình ảnh mục tiêu, nội dung phần này sẽ tự động đồng bộ vào ô hội thoại. Ví dụ ở đây chúng ta có thể chọn thay đổi màu nền.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Có thể thấy hình ảnh mới tạo chỉ thay đổi màu nền, điều này cũng nhất quán với yêu cầu chúng ta nhập.
|
||||
|
||||
* **Trích dẫn tử phần tử từ nhiều hình ảnh khác nhau**, sau đó kết hợp tạo kết quả mới
|
||||
|
||||
Ví dụ: bạn có thể giữ phần thân nhân vật từ ảnh A, đồng thời chỉ thay mũ thành phong cách từ ảnh B, Agent sẽ tự động tích hợp các ràng buộc thị giác này ở backend.
|
||||
|
||||
Lấy vịt lập trình viên làm ví dụ, chúng ta có thể chọn giữ hình tượng vịt từ ảnh đầu tiên, và thay nó vào ảnh thứ hai làm phần tử chính thể.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hiệu quả cuối cùng cũng rất rõ rệt. Bạn cũng có thể thử các kết hợp khác!
|
||||
|
||||
#### Giai đoạn 3: Triển khai (Gọi công cụ của Agent)
|
||||
|
||||
Sau khi tạo xong, có thể trực tiếp thực hiện: phóng to, xóa nền, xóa bỏ, v.v.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Đây không phải là bộ lọc đơn giản, mà là kết quả do Agent tự động điều phối các công cụ khác nhau.
|
||||
|
||||
Sau khi xác định xong phong cách nền tảng, có thể rất nhanh chóng tạo một loạt hình ảnh sticker.
|
||||
|
||||
|
||||
|
||||
Cuối cùng chúng ta nhận được là tài sản cấp sản xuất có thể giao ngay, chứ không chỉ là một hình ảnh trình diễn.
|
||||
|
||||
### 2.3 Hướng dẫn sử dụng và tính phí
|
||||
|
||||
Lovart áp dụng mô hình tính phí theo gói đăng ký, các gói khác nhau tương ứng với hạn mức sử dụng và quyền chức năng khác nhau, cụ thể dựa trên hiển thị trên trang chủ chính thức.
|
||||
|
||||
Hướng dẫn này không giới thiệu hoặc so sánh bất kỳ gói nào; nếu có nhu cầu trong sử dụng thực tế, bạn có thể chọn nâng cấp trả phí theo tình hình cá nhân.
|
||||
Hiện tại hỗ trợ thanh toán qua **Alipay** và các phương thức khác.
|
||||
|
||||
|
||||
|
||||
#### Tóm tắt
|
||||
|
||||
Lovart không phải thay thế mô hình cơ sở, mà thông qua cơ chế Agent, nâng cấp tạo hình ảnh từ "thực thi đơn lẻ" thành "quy trình làm việc liên tục".
|
||||
|
||||
Khi tác vụ bắt đầu liên quan đến lập kế hoạch, nhất quán và giao hàng, ưu điểm của loại công cụ này sẽ trở nên rất rõ rệt.
|
||||
|
||||
## Chương 3: Tự tay làm một trợ lý vẽ thông minh
|
||||
|
||||
Ngoài việc sử dụng trực tiếp Lovart, chúng ta cũng có thể tự triển khai một trợ lý vẽ phiên bản đơn giản hóa.
|
||||
|
||||
Chương này lấy "tự động tạo hình minh họa bài viết" làm ví dụ, từ vấn đề thực tế出发, từng bước xây dựng một Agent có khả năng tư duy.
|
||||
|
||||
### 3.1 Nỗi đau: Tại sao gửi trực tiếp bài viết cho mô hình vẽ không hiệu quả?
|
||||
|
||||
Gửi trực tiếp một bài viết dài cho NanoBanana và yêu cầu tạo hình minh họa thường khó nhận được kết quả lý tưởng. Nguyên nhân không phải mô hình "vẽ không tốt", mà là **nó không giỏi hiểu văn bản dài**.
|
||||
|
||||
Mô hình tạo hình ảnh phù hợp hơn để xử lý mô tả thị giác ngắn gọn, rõ ràng, và khi đầu vào trở thành một bài viết có cấu trúc, trọng điểm và bối cảnh, mô hình không thể phân biệt nội dung nào mới thực sự cần thể hiện trong hình. Điều này thường dẫn đến kết quả tạo lệch chủ đề, hoặc chỉ nắm bắt được chi tiết rời rạc, thiếu khả năng khái quát tổng thể.
|
||||
|
||||
Về bản chất, mô hình hình ảnh chỉ có khả năng "thực thi", nhưng thiếu quá trình phân tích và lựa chọn văn bản.
|
||||
|
||||
|
||||
|
||||
### 3.2 Hướng giải quyết: Dùng Agent tách "hiểu" và "thực thi"
|
||||
|
||||
Để giải quyết vấn đề này, điểm mấu chốt không phải prompt phức tạp hơn, mà là **suy nghĩ kỹ trước khi vẽ**. Do đó, chúng ta giới thiệu một "lớp tư duy" độc lập vào quy trình tạo, và dựa trên đó xây dựng một Agent đơn giản có thể sử dụng.
|
||||
|
||||
Mục tiêu cốt lõi của Agent này chỉ có một: **Làm cho hình ảnh cuối cùng tạo ra, gần nhất với ý định biểu đạt thực sự của người dùng.**
|
||||
|
||||
Toàn bộ quy trình có thể tóm tắt: **Đầu vào văn bản dài -> Mô hình ngôn ngữ hiểu và phán đoán -> Tạo prompt thị giác phù hợp -> Mô hình hình ảnh thực thi tạo -> Xuất hình ảnh**
|
||||
|
||||
|
||||
|
||||
Vậy Agent chúng ta xây dựng làm thế nào để hiểu ý định người dùng?
|
||||
|
||||
Ở đây chọn làm một "lớp tư duy" đơn giản hóa, chúng ta thiết lập ba loại ý định khác nhau: đầu vào vô nghĩa, tạo ảnh trực tiếp, văn bản dài cần hiểu.
|
||||
|
||||
Trong Agent này, phân công vai trò của từng thành phần có thể tóm tắt thành bốn điểm:
|
||||
|
||||
1. **Mô hình ngôn ngữ làm lõi ra quyết định**
|
||||
Nó chịu trách nhiệm hiểu nội dung bài viết, phán đoán ý định đầu vào của người dùng, và phân phối tác vụ vào đường dẫn tạo phù hợp, quyết định "tiếp theo làm gì" và cách tạo prompt tạo ảnh.
|
||||
2. **Mô hình hình ảnh làm người thực thi**
|
||||
Mô hình hình ảnh không tham gia hiểu và phán đoán, chỉ nhận chỉ dẫn thị giác đã được sắp xếp, tập trung hoàn thành render hình ảnh.
|
||||
3. **Người dùng làm người hướng dẫn có thể can thiệp**
|
||||
Ngoài việc nhập văn bản trực tiếp, người dùng cũng có thể điều chỉnh prompt đã tạo trong quá trình, hoặc thêm ảnh tham khảo để hỗ trợ tạo, từ đó hướng dẫn và tinh chỉnh kết quả cuối cùng.
|
||||
4. **Gradio và API backend làm lớp承载 tổng thể**
|
||||
Chúng chịu trách nhiệm kết nối giao diện, gọi mô hình và hiển thị kết quả, đảm bảo toàn bộ Agent có thể vận hành ổn định dưới dạng một ứng dụng Web hoàn chỉnh.
|
||||
|
||||
|
||||
|
||||
### 3.3 Chuẩn bị thực hành: Lấy API
|
||||
|
||||
Có vẻ rất thú vị phải không! Để chạy thông quy trình trên, chúng ta chỉ cần chuẩn bị hai loại API.
|
||||
|
||||
#### Tay: NanoBanana API (tạo hình ảnh)
|
||||
|
||||
Sử dụng trực tiếp API Key và API URL đã cấu hình ở Chương 1, không cần thiết lập thêm.
|
||||
|
||||
#### Não: SiliconFlow API (tư duy văn bản)
|
||||
|
||||
Chúng ta cần một mô hình ngôn ngữ lớn để đảm nhận vai trò "lớp tư duy". Hướng dẫn này sử dụng dịch vụ mô hình do SiliconFlow cung cấp: [https://cloud.siliconflow.cn](https://cloud.siliconflow.cn/)
|
||||
|
||||
|
||||
|
||||
SiliconFlow cung cấp giao diện tương thích với quy cách OpenAI API, có thể rất tiện lợi gọi trong dự án thông qua yêu cầu mạng tiêu chuẩn. Ở đây chúng ta chọn mô hình Qwen2.5-7B-Instruct miễn phí, nội dung cần gọi đã được viết trong Prompt dưới đây. Trước khi bắt đầu, bạn chỉ cần đăng ký tài khoản và tạo API Key trên trang chủ chính thức.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Key này sẽ được sử dụng cho việc gọi mô hình tiếp theo.
|
||||
|
||||
### 3.4 Xây dựng Agent:
|
||||
|
||||
Thí nghiệm này chủ yếu sử dụng Trae để giúp chúng ta viết mã, hướng dẫn này chọn mô hình Gemini-3-Pro-Preview. Tổng thể tư duy là, sau khi tạo dự án mới, sao chép Prompt hoàn chỉnh dưới đây vào ô hội thoại và nhập, thay thế API KEY từng bước rồi chạy mã, hoàn thành kiểm tra.
|
||||
|
||||
|
||||
|
||||
#### Giai đoạn 1: Khung cơ bản Gradio Blocks và bố cục giao diện
|
||||
|
||||
Trong giai đoạn này, mục tiêu chính của chúng ta là xây dựng "ngoại hình" cho toàn bộ Agent, triển khai thiết kế trang frontend. Sao chép Prompt dưới đây vào ô hội thoại Trae để triển khai, bạn sẽ nhận được một URL cục bộ (thường là http://127.0.0.1:7860) để xem giao diện và kiểm tra hiệu quả.
|
||||
|
||||
```Plain
|
||||
Mục 1: Khung cơ bản Gradio Blocks và bố cục giao diện
|
||||
1. Mục tiêu tác vụ
|
||||
·Dựa trên bố cục Blocks của Gradio 4.0.0+, triển khai giao diện cơ bản của dự án "LLM+Nanobanana tạo ảnh từ văn bản", tuân thủ nghiêm ngặt bố cục chia trái phải cố định, khởi tạo tất cả thành phần UI và đặt trạng thái ban đầu đúng.
|
||||
|
||||
2. Yêu cầu công nghệ
|
||||
·Phải sử dụng chế độ Blocks của Gradio 4.0.0+ để phát triển, cấm sử dụng chế độ Interface;
|
||||
·Dependency: gradio>=4.0.0, pillow>=10.0.0 (chỉ import, tạm thời không triển khai logic xử lý ảnh);
|
||||
·Mã phải là tệp Python hoàn chỉnh có thể chạy, bao gồm tất cả câu lệnh import cần thiết.
|
||||
|
||||
3. Quy tắc bố cục giao diện (ràng buộc cốt lõi)
|
||||
·Bố cục tổng thể:
|
||||
Tiêu đề trang: Công cụ tạo ảnh từ văn bản toàn quy trình do LLM điều khiển;
|
||||
Chia trái phải cố định: Bên trái chiếm 60% chiều rộng, bên phải chiếm 40% chiều rộng, sử dụng gr.Row và gr.Column để kiểm soát tỷ lệ.
|
||||
·Bên trái 60% (Vùng quy trình tạo prompt) danh sách thành phần:
|
||||
input_text: gr.Textbox, label "Nhập văn bản (đoạn hướng dẫn / chỉ thị vẽ)", lines=6, placeholder "Vui lòng nhập văn bản hướng dẫn cần tạo hình minh họa hoặc chỉ thị vẽ trực tiếp...";
|
||||
identify_intent_btn: gr.Button, value="Nhận diện ý định", trạng thái ban đầu có thể nhấp;
|
||||
intent_status: gr.Textbox, label "Loại ý định / Trạng thái xử lý", lines=2, interactive=False, giá trị ban đầu "Chưa nhận diện ý định";
|
||||
system_prompt: gr.Textbox, label "System Prompt (chỉ ý định tạo hình minh họa bài viết mới có thể chỉnh sửa)", lines=4, interactive=False, placeholder "Quy tắc ràng buộc để LLM tạo prompt...";
|
||||
confirm_prompt_btn: gr.Button, value="Xác nhận tạo prompt tạo ảnh", interactive=False (vô hiệu hóa ban đầu để tránh nhầm);
|
||||
generation_prompt: gr.Textbox, label="Prompt tạo ảnh (có thể chỉnh sửa)", lines=3, interactive=True, giá trị ban đầu rỗng, placeholder "Prompt tiếng Anh tạo ảnh sẽ hiển thị tại đây, hỗ trợ sửa thủ công...".
|
||||
·Bên phải 40% (Vùng chức năng tạo ảnh Nanobanana) danh sách thành phần:
|
||||
ref_image: gr.Image, label "Ảnh tham khảo (tùy chọn, tạo ảnh từ ảnh)", type=filepath, height=300, cho phép tải lên;
|
||||
generate_btn: gr.Button, value="Tạo hình ảnh", interactive=False (vô hiệu hóa ban đầu, không có prompt không thể nhấp);
|
||||
result_image: gr.Image, label "Kết quả tạo", type=pil, height=300, ban đầu rỗng, interactive=False.
|
||||
|
||||
4. Yêu cầu logic tương tác
|
||||
·Trạng thái interactive ban đầu của tất cả thành phần tuân thủ nghiêm ngặt cấu hình trên, cập nhật động qua hàm sau;
|
||||
·Trạng thái vô hiệu hóa nút cần trực quan (làm mờ), tránh người dùng nhầm.
|
||||
|
||||
5. Yêu cầu đầu ra
|
||||
·Tạo mã Python hoàn chỉnh, chỉ triển khai bố cục giao diện và khởi tạo thành phần, không chứa bất kỳ logic nghiệp vụ nào;
|
||||
·Comment mã rõ ràng, tên thành phần nhất quán với phiên bản thực tế (input_text/identify_intent_btn, v.v.);
|
||||
·Mã có thể chạy trực tiếp, cấu trúc giao diện hoàn toàn nhất quán với mô tả.
|
||||
```
|
||||
|
||||
Sau khi mở http://127.0.0.1:7860 trong trình duyệt, bạn có thể thấy Trae đã tạo trang web theo yêu cầu của chúng ta, cơ bản phù hợp yêu cầu, có thể tiếp tục bước tạo tiếp theo.
|
||||
|
||||
|
||||
|
||||
#### Giai đoạn 2: Module nhận diện ý định LLM (Siliconflow API)
|
||||
|
||||
Khi sử dụng VLM để vẽ trong cuộc sống hàng ngày, có thể có ba loại đầu vào phổ biến sau:
|
||||
|
||||
1. Nội dung vô nghĩa, như "xin chào", "hôm nay bạn ăn chưa", không thể vẽ hình tương ứng.
|
||||
2. Bài viết/văn bản dài, nhiều chữ, khoảng 200 chữ một bài có cấu trúc, cần hiểu cấu trúc và nội dung bài viết trước, sau đó mới xem xét tạo hình ảnh có thể tóm tắt hoàn chỉnh đoạn văn này.
|
||||
3. Chỉ thị vẽ trực tiếp, như "giúp tôi vẽ một con chó đang tắm", yêu cầu đã trình bày rất cụ thể, có thể tạo hình ảnh trực tiếp.
|
||||
|
||||
Giống như trước, sao chép Prompt dưới đây vào ô hội thoại Trae để triển khai, và bổ sung API lấy ở bước trước.
|
||||
|
||||
```Plain
|
||||
Mục 2: Module nhận diện ý định LLM (Siliconflow API)
|
||||
1. Mục tiêu tác vụ
|
||||
Trên cơ sở giao diện Gradio đã triển khai, thêm logic nhấp cho nút "Nhận diện ý định", gọi Siliconflow API hoàn thành nhận diện ý định, và liên kết trạng thái thành phần.
|
||||
|
||||
2. Yêu cầu công nghệ
|
||||
Dựa trên Blocks Gradio 4.0.0+;
|
||||
Dependency: requests>=2.31.0, openai;
|
||||
Xuất tệp Python hoàn chỉnh có thể chạy, bao gồm giao diện Mục 1 + logic module này.
|
||||
|
||||
3. Quy tắc nghiệp vụ cốt lõi (tuyệt đối không được sai lệch)
|
||||
·Quy tắc phân loại ý định (chỉ 3 loại, trả về nghiêm ngặt số + mô tả)
|
||||
1 = Nội dung vô nghĩa: Chỉ nói chuyện phiếm, chào hỏi, hội thoại không liên quan, không có nhu cầu vẽ hoặc tạo hình minh họa (như "xin chào" "hôm nay ăn chưa");
|
||||
2 = Nhu cầu tạo hình minh họa bài viết/văn bản dài: Người dùng nhập một bài viết hoàn chỉnh, hướng dẫn, đoạn văn, văn bản mô tả, nội dung thiên về tường thuật/mô tả/giảng giải, ẩn chứa ý định cần tạo hình minh họa cho nội dung này, không cần người dùng nói rõ "tạo hình minh họa cho đoạn văn này";
|
||||
3 = Chỉ thị vẽ trực tiếp: Người dùng nhập lệnh vẽ ngắn gọn, rõ ràng, không có bối cảnh văn bản dài, yêu cầu trực tiếp vẽ một nội dung nào đó (như "vẽ một con mèo phong cách Apple").
|
||||
·Ràng buộc gọi LLM (tích hợp mẫu phiên bản thực tế)
|
||||
Địa chỉ giao diện: https://api.siliconflow.cn/v1/chat/completions;
|
||||
Mô hình: Qwen/Qwen2.5-7B-Instruct;
|
||||
temperature=0.1;
|
||||
|
||||
4. Quy tắc liên kết thành phần
|
||||
·Kết quả là 1: intent_status hiển thị "1 = Nội dung vô nghĩa: Không có nhu cầu vẽ", system_prompt giữ vô hiệu, confirm_prompt_btn vô hiệu;
|
||||
·Kết quả là 2: intent_status hiển thị "2 = Nhu cầu tạo hình minh họa bài viết/văn bản dài: Tạo hình minh họa cho nội dung đầu vào", bật system_prompt và điền quy tắc mặc định, kích hoạt confirm_prompt_btn;
|
||||
·Kết quả là 3: intent_status hiển thị "3 = Chỉ thị vẽ trực tiếp: Tạo hình ảnh theo chỉ thị", system_prompt vô hiệu và điền quy tắc mặc định, kích hoạt confirm_prompt_btn.
|
||||
|
||||
5. Xử lý ngoại lệ
|
||||
Lỗi API, lỗi phân tích đều đưa ra prompt thân thiện, không sập, thành phần trở về trạng thái ban đầu.
|
||||
|
||||
6. Yêu cầu đầu ra
|
||||
Tạo mã hoàn chỉnh có thể chạy, thay LLM_API_KEY là có thể sử dụng, logic rõ ràng comment đầy đủ, mẫu nhận diện ý định sử dụng nghiêm ngặt phiên bản thực tế.
|
||||
```
|
||||
|
||||
Làm mới trang http://127.0.0.1:7860 trước đó, bắt đầu kiểm tra xem có thể nhận diện đúng ba trường hợp hay không.
|
||||
|
||||
1. Nội dung vô nghĩa, có thể thử nhập "xin chào", "cảm ơn", phát hiện có thể nhận diện bình thường.
|
||||
|
||||
|
||||
|
||||
2. Bài viết/văn bản dài, ở đây chúng ta dùng một đoạn văn bản do Doubao tạo mô tả trí tuệ nhân tạo. Bạn cũng có thể thử sử dụng đoạn luận văn của mình để kiểm tra.
|
||||
|
||||
```Plain
|
||||
Trí tuệ nhân tạo đang định hình lại hệ sinh thái giáo dục với độ sâu và breadth chưa từng có...
|
||||
```
|
||||
|
||||
Cũng kiểm tra thành công~
|
||||
|
||||
|
||||
|
||||
3. Chỉ thị vẽ trực tiếp, ở đây nhập "tôi muốn vẽ một con mèo", cũng nhận diện chính xác.
|
||||
|
||||
|
||||
|
||||
Đến đây chúng ta đã hoàn thành thuận lợi giai đoạn thứ hai -- nhận diện ý định.
|
||||
|
||||
#### Giai đoạn 3: Module tạo prompt tạo ảnh (Gọi LLM lần hai)
|
||||
|
||||
Sau khi nhận diện ý định, đối với bài viết hoặc văn bản dài, còn một bước rất quan trọng là tạo prompt vẽ, đây chính là trọng điểm của Agent này.
|
||||
|
||||
```SQL
|
||||
Mục 3: Module tạo prompt tạo ảnh (Gọi LLM lần hai)
|
||||
1. Mục tiêu tác vụ
|
||||
Trên cơ sở nhận diện ý định, triển khai logic nút "Xác nhận tạo prompt tạo ảnh", gọi LLM tối ưu hóa văn bản thành prompt thị giác tiếng Anh phù hợp để vẽ, điền vào ô chỉnh sửa và liên kết nút "Tạo hình ảnh".
|
||||
|
||||
2. Yêu cầu công nghệ
|
||||
Giống Mục 2, xuất mã hoàn chỉnh = Mục 1 + Mục 2 + module này;
|
||||
Sử dụng chung LLM_BASE_URL, LLM_API_KEY, LLM_MODEL đã định nghĩa ở Mục 2, không thêm key mới.
|
||||
|
||||
3. Quy tắc nghiệp vụ cốt lõi
|
||||
·Quy tắc đầu vào tạo prompt (phải tuân thủ nghiêm ngặt)
|
||||
Tạo prompt tạo ảnh không còn là nối chuỗi đơn giản, mà là xây dựng danh sách tin nhắn Chat tiêu chuẩn.
|
||||
·Ràng buộc gọi LLM
|
||||
Sử dụng chung bộ LLM_BASE_URL, LLM_API_KEY, LLM_MODEL với Mục 2;
|
||||
temperature=0.7;
|
||||
max_tokens=200;
|
||||
Sử dụng nghiêm ngặt cấu trúc danh sách tin nhắn Chat tiêu chuẩn, cấm nối chuỗi.
|
||||
·Ràng buộc bắt buộc đầu ra prompt
|
||||
Tiếng Anh thuần, không có tiếng Trung;
|
||||
Phải bao gồm Apple Design Philosophy/Apple style + 1024x1024;
|
||||
Độ dài 50-200 ký tự, kiểm tra trong mã;
|
||||
Không có giải thích thêm, tiền tố hoặc lời thừa, chỉ trả về prompt.
|
||||
|
||||
4. Quy tắc liên kết thành phần
|
||||
Tạo thành công: Điền prompt vào ô generation_prompt, kích hoạt generate_btn, intent_status thêm "Tạo prompt thành công, có thể sửa rồi tạo hình ảnh";
|
||||
Tạo thất bại: Prompt lý do cụ thể, generate_btn giữ vô hiệu, ô generation_prompt rỗng;
|
||||
Người dùng sửa/xóa ô generation_prompt:
|
||||
Xóa tự động vô hiệu generate_btn;
|
||||
Không rỗng thì giữ generate_btn kích hoạt.
|
||||
|
||||
5. Xử lý ngoại lệ
|
||||
Gọi API thất bại: Prompt thân thiện, không sập;
|
||||
Kiểm tra prompt thất bại: Nêu rõ lý do, cho thử lại;
|
||||
Phân tích phản hồi thất bại: Prompt "Không thể phân tích kết quả LLM trả về, vui lòng thử lại".
|
||||
|
||||
6. Yêu cầu đầu ra
|
||||
Mã hoàn chỉnh có thể chạy, thay LLM_API_KEY là có thể sử dụng;
|
||||
Cấu trúc mã rõ ràng, comment đầy đủ, giao diện đẹp简洁;
|
||||
Triển khai nghiêm ngặt cấu trúc danh sách tin nhắn Chat tiêu chuẩn, tham số và logic mẫu nhất quán;
|
||||
Bao gồm logic kiểm tra độ dài, nội dung prompt, prompt lỗi thân thiện.
|
||||
```
|
||||
|
||||
Cũng sao chép văn bản của giai đoạn thứ hai để kiểm tra.
|
||||
|
||||
Đáng chú ý, System Prompt tạo prompt tạo ảnh mà chúng ta đặt trước ở đây là:
|
||||
|
||||
> Bạn hiện là trợ giúp tạo prompt vẽ NanoBanana.
|
||||
> Cần xử lý dựa trên nội dung của tôi, hình ảnh này có tác dụng giải thích đoạn này đang nói gì, và để mọi người biết cấu trúc bối cảnh của đoạn này nói chung là có ý nghĩa gì.
|
||||
> Có thể có phần giải thích tương tự PPT (như: góc trên bên trái thể hiện quan điểm cốt lõi, góc dưới bên phải thể hiện dữ liệu).
|
||||
> Yêu cầu phong cách thiết kế: Tối giản, tư duy thiết kế Apple (Apple Design Philosophy).
|
||||
> Ràng buộc: Vui lòng trả về trực tiếp prompt tiếng Anh có thể sử dụng cho NanoBanana, không trả về bất kỳ giải thích, tiền tố hoặc lời thừa nào.
|
||||
|
||||
Nếu bạn muốn đổi mẫu mặc định khác, có thể sửa trong prompt trước đó, hoặc trực tiếp sửa qua hội thoại trong Trae.
|
||||
|
||||
|
||||
|
||||
Ngoài việc sửa mã cơ sở, chúng ta cũng có thể chỉnh sửa nhanh trên trang web. Ví dụ, tôi thêm một câu ở đây, "thêm câu Pic Prompt ở phía trước", có thể thấy prompt mới tạo cũng bao gồm ở phía trước~ Thiết kế này là để dễ dàng sửa System Prompt tạo prompt, giúp chúng ta nhanh chóng chuyển đổi phong cách.
|
||||
|
||||
|
||||
|
||||
#### Giai đoạn 4: Module tạo ảnh từ văn bản/tạo ảnh từ ảnh Nanobanana
|
||||
|
||||
Cuối cùng đã đến bước cuối cùng, không kết nối mô hình tạo ảnh thì không phải Agent hoàn chỉnh!
|
||||
|
||||
```Bash
|
||||
Mục 4: Module tạo ảnh từ văn bản/tạo ảnh từ ảnh Nanobanana (phiên bản cuối)
|
||||
1. Mục tiêu tác vụ
|
||||
Triển khai logic nút "Tạo hình ảnh", gọi API Nanobanana thực tế, hỗ trợ tạo ảnh từ văn bản/tạo ảnh từ ảnh, phân tích Base64 và hiển thị hình ảnh.
|
||||
|
||||
2. Yêu cầu công nghệ
|
||||
Dựa trên Blocks Gradio 4.0.0+;
|
||||
Dependency: requests, pillow, base64, io, re;
|
||||
Mã hoàn chỉnh = Mục 1+2+3 + module này.
|
||||
|
||||
3. Cấu hình API cốt lõi
|
||||
Cấu hình mã cố định:
|
||||
NANOBANANA_API_URL = "https://api.zyai.online/v1/chat/completions"
|
||||
NANOBANANA_MODEL = "gemini-2.5-flash-image"
|
||||
NANOBANANA_API_KEY = "" # Người dùng tự thay
|
||||
|
||||
4. Yêu cầu tiền xử lý hình ảnh (phải triển khai)
|
||||
Triển khai hàm image_to_base64_data_uri (ref_image_path), logic cốt lõi:
|
||||
Chuyển hình ảnh PIL sang định dạng PNG;
|
||||
Tự động thu nhỏ về độ phân giải 1024x1024;
|
||||
Kênh trong suốt chuyển sang nền trắng;
|
||||
Mã hóa Base64, trả về định dạng: data:image/png;base64,...
|
||||
|
||||
5. Quy tắc xây yêu cầu (theo logic phân nhánh phiên bản thực tế)
|
||||
·Hàm cốt lõi
|
||||
Triển khai hàm generate_image (prompt, ref_image_path):
|
||||
Tham số: prompt (nội dung ô generation_prompt), ref_image_path (đường dẫn tệp tải lên ref_image);
|
||||
Trả về: PIL Image (hiển thị vào result_image) hoặc prompt lỗi.
|
||||
·Nhánh logic 1: Tạo ảnh từ văn bản thuần (ref_image_path rỗng)
|
||||
messages = [{"role": "user", "content": prompt}]
|
||||
·Nhánh logic 2: Tạo ảnh từ ảnh (ref_image_path có giá trị)
|
||||
Gọi hàm tiền xử lý hình ảnh trước, sau đó xây messages với image_url.
|
||||
|
||||
6. Yêu cầu phân tích phản hồi (phải tương thích hai định dạng)
|
||||
Trích xuất Base64 hình ảnh từ choices[0].message.content, hỗ trợ:
|
||||
Trường image_url trả về JSON có cấu trúc;
|
||||
Định dạng Markdown;
|
||||
Trích xuất thống nhất mã hóa Base64, giải mã sau chuyển đổi thành PIL Image trả về.
|
||||
|
||||
7. Liên kết thành phần và xử lý ngoại lệ
|
||||
Tạo thành công: Hiển thị PIL Image vào result_image, intent_status prompt "Tạo hình ảnh thành công";
|
||||
Tạo/phân tích/tải lên thất bại: Hiển thị prompt văn bản rõ ràng trong intent_status, không sập.
|
||||
|
||||
8. Yêu cầu đầu ra
|
||||
Mã hoàn chỉnh có thể chạy, thay LLM_API_KEY và NANOBANANA_API_KEY là có thể chạy trực tiếp, toàn bộ quy trình sử dụng được, logic phân nhánh khớp nghiêm ngặt phiên bản thực tế.
|
||||
```
|
||||
|
||||
|
||||
|
||||
Thật thú vị! Chúng ta đã tạo thành công hình ảnh đầu tiên của Agent này, nhìn kỹ hình ảnh tạo ra, nó khớp với văn bản và prompt của chúng ta. Đến đây bạn đã cơ bản triển khai xong Agent của riêng mình!
|
||||
|
||||
|
||||
|
||||
Chúng ta còn thêm chức năng tạo ảnh từ ảnh, tải lên hình ảnh bạn thích, AI sẽ tự động tham khảo phong cách.
|
||||
|
||||
|
||||
|
||||
Đáng nhắc là, prompt tạo ở bước trước cũng có thể chỉnh sửa trên trang web, và chúng ta lấy prompt khi nhấp nút cuối cùng làm chuẩn~ Ngay cả khi tôi đổi thành "a cute cat" ở đây, hình ảnh cuối cùng tạo ra cũng chỉ là chú mèo dễ thương.
|
||||
|
||||
## Chương 4: Tổng kết
|
||||
|
||||
|
||||
|
||||
**Tuyệt vời! Cuối cùng cũng viết xong.**
|
||||
|
||||
Thành thật mà nói, ngay cả bản thân tôi khi viết xong dòng cuối cùng cũng không khỏi thở phào nhẹ nhõm, chưa nói đến bạn đã theo dõi đến đây. Có thể chạy hoàn chỉnh toàn bộ quy trình này đã rất giỏi rồi, điều này chứng tỏ bạn thực sự đã đặt tay lên bàn phím, hoàn thành từng bước. Tuyệt vời!
|
||||
|
||||
Trong quá trình viết nội dung này, tôi luôn suy nghĩ, chúng ta thực sự muốn để lại điều gì? Câu trả lời thực chất không phải tên mô hình, tham số hoặc một phương pháp cố định nào, mà là giúp bạn dần dần xây dựng một cảm giác: những việc nào có thể yên tâm giao cho AI để hiểu và lập kế hoạch, những chỗ nào chỉ cần bạn quyết định hướng. Một khi sự phân công này được thiết lập, nhiều quy trình tạo ban đầu trông phức tạp sẽ bắt đầu trôi chảy hơn.
|
||||
|
||||
Nhìn lại, con đường này thực chất không phức tạp. Suy nghĩ kỹ vấn đề bạn muốn giải quyết, giao văn bản dài cho mô hình ngôn ngữ để phân tích, sau đó giao ý định thị giác đã sắp xếp cho mô hình vẽ để trình bày, cuối cùng đóng gói toàn bộ quy trình này thành một trợ lý nhỏ của riêng bạn. Đến đây, bạn không chỉ "đang dùng mô hình", mà đang xây dựng một hệ thống có thể đồng hành cùng bạn làm việc lâu dài, và đây mới là điều mà bộ hướng dẫn này muốn mang đến cho bạn.
|
||||
|
||||
Bạn đã làm rất tốt rồi! Tin rằng học đến đây bạn đã nắm bắt cơ bản Vibe Coding, hãy cho mình một kỳ nghỉ nhỏ nghỉ ngơi nhé!
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="Bài viết liên quan"
|
||||
description="Nếu bạn muốn thực sự đưa 'tạo tài sản' vào quy trình sản phẩm, có thể tiếp tục học các chương này."
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,424 @@
|
||||
# Sử dụng thư viện component hiện đại để cập nhật giao diện
|
||||
|
||||
Trong các bài học trước, bạn đã học cách sử dụng công cụ thiết kế để vẽ giao diện, dùng AI IDE để chuyển bản thiết kế thành code, thậm chí hoàn thành một dự án frontend hoàn chỉnh. Nhưng bạn cũng có thể phát hiện ra một vấn đề: các nút bấm, biểu mẫu, hộp thoại tự viết từ đầu tuy dùng được nhưng总觉得 thiếu chút gì so với "sản phẩm chuyên nghiệp" — phong cách không đủ thống nhất, chi tiết tương tác không đủ mượt mà, thích ứng với các màn hình khác nhau cũng rất đau đầu.
|
||||
|
||||
Đó chính là vấn đề mà **thư viện component** giải quyết.
|
||||
|
||||
Thư viện component là một tập hợp các linh kiện UI đã được thiết kế và phát triển sẵn. Nút bấm, ô nhập liệu, menu thả xuống, hộp thoại, bảng dữ liệu... các phần tử giao diện mà bạn sẽ sử dụng lặp đi lặp lại trong bất kỳ sản phẩm nào, thư viện component đã làm sẵn cho bạn, và đã được kiểm chứng và tinh chỉnh bởi nhiều người dùng. Bạn chỉ cần lắp ghép chúng lại như chơi xếp hình là có thể nhanh chóng xây dựng giao diện cấp chuyên nghiệp.
|
||||
|
||||
## Bạn sẽ học được
|
||||
|
||||
1. Hiểu thư viện component frontend là gì, và tại sao phát triển hiện đại gần như đều sử dụng nó
|
||||
2. Làm quen với bốn thư viện component tiêu biểu nhất, hiểu các kịch bản mà mỗi thư viện擅长
|
||||
3. Thông qua ba kịch bản thực chiến (landing page, trang sản phẩm, quản lý back-office), học cách sử dụng AI IDE + thư viện component để Vibe Coding
|
||||
4. Học cách đọc tài liệu thư viện component, tìm và sử dụng component phù hợp theo nhu cầu
|
||||
|
||||
## 1. Tại sao cần thư viện component?
|
||||
|
||||
Hãy tưởng tượng bạn đang trang trí nhà. Bạn có thể tự làm một chiếc ghế từ gỗ, nhưng cách phổ biến hơn là đến IKEA mua một chiếc — thiết kế đẹp, chất lượng ổn định, hướng dẫn sử dụng rõ ràng, mang về lắp ráp là xong.
|
||||
|
||||
Thư viện component chính là "IKEA" trong phát triển frontend. Nó cung cấp không phải đồ nội thất, mà là linh kiện giao diện:
|
||||
|
||||
| Tự viết tay | Sử dụng thư viện component |
|
||||
| :--- | :--- |
|
||||
| Cần tự xử lý phong cách, tương tác, animation | Sử dụng ngay, phong cách và tương tác đã được tinh chỉnh |
|
||||
| Nút bấm trên các trang khác nhau có thể trông khác nhau | Phong cách toàn cục thống nhất, tự động duy trì tính nhất quán |
|
||||
| Thích ứng điện thoại, máy tính bảng cần thêm việc | Hầu hết thư viện component đã tích hợp hỗ trợ responsive |
|
||||
| Truy cập vô障碍 dễ bị sót | Thư viện component chuyên nghiệp đã xử lý điều hướng bàn phím, trình đọc màn hình, v.v. |
|
||||
| Tốc độ phát triển chậm | Tốc độ phát triển nhanh, tập trung vào logic nghiệp vụ |
|
||||
|
||||
Nói đơn giản: **Thư viện component giúp bạn dành thời gian cho "làm gì", chứ không phải "vẽ thế nào".**
|
||||
|
||||
### Trăm nghe không bằng một thấy: cùng một yêu cầu, khoảng cách giữa có và không có thư viện component
|
||||
|
||||
Nói suông không có tính thuyết phục. Chúng ta sử dụng yêu cầu gần như giống nhau trong Trae, lần lượt không chỉ định và chỉ định thư viện component, xem khoảng cách kết quả tạo ra.
|
||||
|
||||
**Prompt 1: Không sử dụng thư viện component**
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tạo một trang bảng điều khiển dữ liệu trợ lý viết AI, bao gồm:
|
||||
- Thanh tiêu đề trên cùng và nút xuất
|
||||
- Bốn thẻ thống kê hiển thị số người dùng, người dùng hoạt động, số tài liệu, doanh thu, còn phải hiển thị xu hướng tăng/giảm
|
||||
- Một biểu đồ đường và một biểu đồ tròn
|
||||
- Bảng danh sách người dùng, có chức năng phân trang
|
||||
- Thanh điều hướng侧边栏 bên trái
|
||||
```
|
||||
|
||||
**Prompt 2: Sử dụng thư viện component shadcn/ui**
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tạo một trang bảng điều khiển dữ liệu trợ lý viết AI, sử dụng thư viện component shadcn/ui, bao gồm:
|
||||
- Thanh tiêu đề trên cùng và nút xuất
|
||||
- Bốn thẻ thống kê hiển thị số người dùng, người dùng hoạt động, số tài liệu, doanh thu, còn phải hiển thị xu hướng tăng/giảm
|
||||
- Một biểu đồ đường và một biểu đồ tròn
|
||||
- Bảng danh sách người dùng, có chức năng phân trang
|
||||
- Thanh điều hướng侧边栏 bên trái
|
||||
```
|
||||
|
||||
Cùng một yêu cầu, điểm khác biệt duy nhất là thêm `shadcn/ui + Tailwind CSS` ở đầu prompt, kết quả Trae tạo ra về tính nhất quán thị giác, chi tiết tương tác, mức độ hoàn thiện tổng thể hoàn toàn không ở cùng một cấp độ. Đây chính là "nâng cấp miễn phí" mà thư viện component mang lại — bạn chỉ cần thêm tên thư viện component vào prompt.
|
||||
|
||||
## 2. Làm quen với bốn thư viện component cốt lõi
|
||||
|
||||
Số lượng thư viện component rất nhiều (xem danh sách đầy đủ tại [Phụ lục](#phụ-lục-thêm-thư-viện-component)), nhưng bạn chỉ cần làm quen với bốn thư viện tiêu biểu nhất:
|
||||
|
||||
| Thư viện component | Framework | Định vị một câu | Trang chủ |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Ant Design](https://ant.design) | React | Sản phẩm bởi Ant Group, tiêu chuẩn thực tế cho back-office doanh nghiệp cấp trung, độ bao phủ component cực kỳ rộng | ant.design |
|
||||
| [shadcn/ui](https://ui.shadcn.com) | React | Không cài npm package, sao chép code trực tiếp vào dự án của bạn, dựa trên Tailwind CSS, mức độ tùy chỉnh tự do cao nhất | ui.shadcn.com |
|
||||
| [HeroUI](https://heroui.com) (trước đây là NextUI) | React | Phong cách mặc định tinh xảo, animation mượt mà, phù hợp landing page và showcase sản phẩm có yêu cầu cao về chất lượng thị giác | heroui.com |
|
||||
| [Material UI](https://mui.com) | React | Thư viện component React lâu đời nhất, triển khai quy phạm Google Material Design, hệ sinh thái trưởng thành nhất | mui.com |
|
||||
|
||||
> Người dùng Vue cũng có nhiều lựa chọn phong phú: [Element Plus](https://element-plus.org) (phổ biến nhất tại Trung Quốc), [Ant Design Vue](https://antdv.com), [Naive UI](https://www.naiveui.com), v.v., xem chi tiết tại [Phụ lục](#phụ-lục-thêm-thư-viện-component).
|
||||
|
||||
Các thư viện component khác nhau擅长 các kịch bản khác nhau. Tiếp theo chúng ta sẽ thông qua ba kịch bản phát triển thực tế, dẫn dắt bạn trải nghiệm cách sử dụng AI IDE + thư viện component để Vibe Coding.
|
||||
|
||||
Để thể hiện phong cách và đặc điểm của các thư viện component khác nhau, chúng ta cố tình chọn thư viện khác nhau trong mỗi kịch bản. Nhưng xin lưu ý: **Điều này chỉ là để bạn làm quen với nhiều phương án hơn**, trong phát triển thực tế bạn hoàn toàn có thể chỉ sử dụng thư viện bạn quen tay nhất. Ví dụ bạn thích phong cách shadcn/ui, dùng nó làm landing page, trang sản phẩm, quản lý back-office đều không vấn đề. Chọn một thư viện bạn thấy đẹp và dùng thoải mái là quan trọng nhất.
|
||||
|
||||
## 3. Thực chiến 1: Xây dựng landing page sản phẩm bằng HeroUI
|
||||
|
||||
**Kịch bản**: Bạn đã làm một sản phẩm trợ lý viết AI, cần một landing page đẹp để thể hiện tính năng sản phẩm, thu hút người dùng đăng ký. Landing page cần sức mạnh thị giác cao, animation mượt mà, trên điện thoại cũng phải đẹp.
|
||||
|
||||
**Tại sao chọn HeroUI**: Phong cách mặc định của HeroUI đã rất tinh xảo, tự kèm animation chuyển tiếp mượt mà, rất phù hợp các trang showcase hướng đến người dùng.
|
||||
|
||||
### 3.1 Tạo dự án
|
||||
|
||||
```bash
|
||||
# Sử dụng CLI chính thức của HeroUI để tạo dự án
|
||||
npx create-heroui-app@latest ai-writer-landing
|
||||
cd ai-writer-landing
|
||||
npm install
|
||||
```
|
||||
|
||||
### 3.2 Sử dụng AI IDE để tạo landing page
|
||||
|
||||
Mở AI IDE (Cursor, Trae, v.v.), nhập vào hộp thoại:
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tạo một landing page trợ lý viết AI, sử dụng thư viện component HeroUI:
|
||||
|
||||
**Cấu trúc trang:**
|
||||
1. Thanh điều hướng trên cùng: bên trái đặt Logo và tên sản phẩm, bên phải đặt ba liên kết "Tính năng", "Bảng giá", "Về chúng tôi", thêm nút "Bắt đầu sử dụng"
|
||||
2. Khu vực首屏: tiêu đề lớn viết "Để AI trở thành đối tác viết của bạn", phụ đề giới thiệu giá trị sản phẩm, hai nút "Dùng thử miễn phí" và "Xem demo", bên dưới đặt ảnh chụp màn hình sản phẩm
|
||||
3. Triển khai tính năng: ba cột thẻ, lần lượt giới thiệu ba tính năng "Tiếp tục viết thông minh", "Điều chỉnh phong cách", "Dịch đa ngôn ngữ", mỗi thẻ phải có icon, tiêu đề, mô tả
|
||||
4. Khu vực bảng giá: ba thẻ bảng giá (bản miễn phí, bản chuyên nghiệp, bản nhóm), bản chuyên nghiệp cần hiển thị nổi bật khuyến nghị
|
||||
5. Khu vực kêu gọi hành động dưới cùng: một câu văn bản hấp dẫn, thêm nút đăng ký
|
||||
6. Chân trang: thông tin bản quyền và liên kết mạng xã hội
|
||||
|
||||
**Yêu cầu thiết kế:**
|
||||
- Nhìn phải hiện đại, chuyên nghiệp
|
||||
- Hỗ trợ chế độ tối
|
||||
- Trên điện thoại cũng phải đẹp
|
||||
```
|
||||
|
||||
### 3.3 Các component cốt lõi mà AI sẽ sử dụng
|
||||
|
||||
```jsx
|
||||
import {
|
||||
Navbar, NavbarBrand, NavbarContent, NavbarItem,
|
||||
Button,
|
||||
Card, CardHeader, CardBody, CardFooter,
|
||||
Divider,
|
||||
Link,
|
||||
Chip
|
||||
} from '@heroui/react'
|
||||
```
|
||||
|
||||
| Component | Mục đích | Vị trí trong landing page |
|
||||
| :--- | :--- | :--- |
|
||||
| `Navbar` | Thanh điều hướng trên cùng | Phía trên cùng trang, cố định không di chuyển |
|
||||
| `Button` | Nút bấm, hỗ trợ nhiều biến thể và màu sắc | Nút CTA, nút điều hướng |
|
||||
| `Card` | Container thẻ | Triển khai tính năng, thẻ bảng giá |
|
||||
| `Chip` | Nhãn nhỏ | Đánh dấu "Khuyến nghị", "Phổ biến nhất" |
|
||||
| `Divider` | Đường phân cách | Phân cách thị giác giữa các khu vực |
|
||||
|
||||
### 3.4 Lặp và tối ưu
|
||||
|
||||
Code phiên bản đầu tạo ra có thể không hoàn toàn hài lòng, tiếp tục đối thoại với AI để điều chỉnh:
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tối ưu landing page:
|
||||
|
||||
1. Tiêu đề lớn thêm gradient màu, từ xanh chuyển sang tím
|
||||
2. Thẻ tính năng khi di chuột vào có animation nổi lên
|
||||
3. Thẻ bảng giá bản chuyên nghiệp cần hiển thị nổi bật, thêm viền và nhãn "Phổ biến nhất"
|
||||
4. Điều hướng trên điện thoại改成 menu hamburger (kiểu ba dấu gạch ngang)
|
||||
```
|
||||
|
||||
> **Cốt lõi của Vibe Coding**: Bạn không cần nhớ API của mỗi component, chỉ cần mô tả hiệu quả bạn muốn bằng ngôn ngữ tự nhiên, AI sẽ giúp bạn tìm component và cách viết phù hợp. Khi gặp chỗ không hài lòng, tiếp tục đối thoại lặp là được.
|
||||
|
||||
## 4. Thực chiến 2: Xây dựng trang sản phẩm bằng shadcn/ui
|
||||
|
||||
**Kịch bản**: Trợ lý viết AI của bạn cần một giao diện chính sau khi người dùng đăng nhập — bên trái là danh sách tài liệu, bên phải là trình soạn thảo, trên cùng có thanh công cụ. Đây là một trang sản phẩm kiểu chức năng, cần UI có thể tùy chỉnh cao.
|
||||
|
||||
**Tại sao chọn shadcn/ui**: shadcn/ui đặt code component trực tiếp vào dự án của bạn, bạn có thể tự do chỉnh sửa bất kỳ chi tiết nào. Đối với giao diện sản phẩm cần tùy chỉnh sâu, chế độ "sở hữu code" này linh hoạt nhất.
|
||||
|
||||
### 4.1 Tạo dự án
|
||||
|
||||
```bash
|
||||
# Tạo dự án Next.js
|
||||
npx create-next-app@latest ai-writer-app --typescript --tailwind --app
|
||||
cd ai-writer-app
|
||||
|
||||
# Khởi tạo shadcn/ui
|
||||
npx shadcn@latest init
|
||||
|
||||
# Thêm component theo nhu cầu (không cài tất cả cùng lúc)
|
||||
npx shadcn@latest add button card input sidebar sheet dialog
|
||||
```
|
||||
|
||||
Điểm độc đáo của shadcn/ui: mỗi lần `add` một component, nó sẽ sao chép mã nguồn vào thư mục `components/ui/` của dự án bạn. Bạn có thể mở trực tiếp các tệp này để chỉnh sửa phong cách và hành vi.
|
||||
|
||||
### 4.2 Sử dụng AI IDE để tạo giao diện sản phẩm
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tạo giao diện chính trợ lý viết AI, sử dụng thư viện component shadcn/ui:
|
||||
|
||||
**Bố cục tổng thể:**
|
||||
- Bên trái là侧边栏 có thể thu gọn,宽度 khoảng 280px:
|
||||
- Trên cùng đặt nút "Tài liệu mới"
|
||||
- Bên dưới là danh sách tài liệu, mỗi tài liệu hiển thị tiêu đề và thời gian chỉnh sửa cuối
|
||||
- Nhấp chuột phải vào tài liệu có thể đổi tên hoặc xóa
|
||||
- Bên phải là khu vực soạn thảo chính, chia thành hai phần trên dưới:
|
||||
- Phần trên là thanh công cụ: có thể chỉnh sửa tiêu đề tài liệu, hiển thị thống kê số từ, nút "AI tiếp tục viết", menu thả xuống "Xuất"
|
||||
- Phần dưới là khu vực soạn thảo: một ô nhập văn bản lớn, chiếm đầy không gian còn lại
|
||||
|
||||
**Chi tiết tương tác:**
|
||||
- Sau khi nhấp "AI tiếp tục viết", nút hiển thị trạng thái loading, dưới cùng trình soạn thảo xuất hiện văn bản do AI tạo (hiển thị từng chữ như máy đánh chữ)
|
||||
- Trên điện thoại侧边栏 thành kiểu drawer, trượt ra từ bên trái
|
||||
- Tài liệu đang chọn cần highlight
|
||||
```
|
||||
|
||||
### 4.3 Các component cốt lõi mà AI sẽ sử dụng
|
||||
|
||||
```tsx
|
||||
import { Button } from '@/components/ui/button'
|
||||
import { Input } from '@/components/ui/input'
|
||||
import { Card, CardContent, CardHeader } from '@/components/ui/card'
|
||||
import {
|
||||
DropdownMenu,
|
||||
DropdownMenuContent,
|
||||
DropdownMenuItem,
|
||||
DropdownMenuTrigger
|
||||
} from '@/components/ui/dropdown-menu'
|
||||
import {
|
||||
Sheet,
|
||||
SheetContent,
|
||||
SheetTrigger
|
||||
} from '@/components/ui/sheet'
|
||||
import {
|
||||
Sidebar,
|
||||
SidebarContent,
|
||||
SidebarHeader
|
||||
} from '@/components/ui/sidebar'
|
||||
```
|
||||
|
||||
| Component | Mục đích | Vị trí trong trang sản phẩm |
|
||||
| :--- | :--- | :--- |
|
||||
| `Sidebar` |侧边栏 có thể thu gọn | Danh sách tài liệu bên trái |
|
||||
| `Sheet` | Drawer thiết bị di động | Thay thế侧边栏 trên thiết bị di động |
|
||||
| `DropdownMenu` | Menu thả xuống | Nút "Xuất", menu chuột phải |
|
||||
| `Dialog` | Hộp thoại | Đổi tên, xác nhận xóa |
|
||||
| `Button` | Nút bấm, hỗ trợ variant và loading | Các nút thao tác khác nhau |
|
||||
| `Input` | Ô nhập liệu | Chỉnh sửa tiêu đề tài liệu |
|
||||
|
||||
### 4.4 Tùy chỉnh phong cách component
|
||||
|
||||
Ưu điểm của shadcn/ui là bạn có thể chỉnh sửa trực tiếp mã nguồn component. Ví dụ bạn muốn tăng bo góc nút:
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi chỉnh sửa components/ui/button.tsx,
|
||||
thay bo góc mặc định của tất cả nút từ rounded-md thành rounded-xl,
|
||||
và thêm hiệu ứng bóng mờ tinh tế cho biến thể primary
|
||||
```
|
||||
|
||||
AI sẽ chỉnh sửa trực tiếp tệp component trong dự án của bạn, chứ không ghi đè phong cách npm package — đây chính là lợi ích của "sở hữu code" shadcn/ui.
|
||||
|
||||
## 5. Thực chiến 3: Xây dựng giao diện quản lý back-office bằng Ant Design
|
||||
|
||||
**Kịch bản**: Sau khi trợ lý viết AI của bạn lên mạng, cần một back-office quản trị để xem dữ liệu người dùng, quản lý nội dung tài liệu, xử lý đơn hàng thanh phí. Cốt lõi của hệ thống quản lý back-office là hiển thị dữ liệu và hiệu quả thao tác.
|
||||
|
||||
**Tại sao chọn Ant Design**: Ant Design có tích lũy sâu nhất trong lĩnh vực back-office cấp trung, các component nghiệp vụ như bảng, biểu mẫu, biểu đồ sử dụng ngay, tích hợp nhiều mô hình tương tác cấp doanh nghiệp (thao tác hàng loạt, lọc nâng cao, xuất dữ liệu, v.v.).
|
||||
|
||||
### 5.1 Tạo dự án
|
||||
|
||||
```bash
|
||||
# Sử dụng scaffolding Ant Design Pro (tích hợp bố cục, định tuyến, phân quyền)
|
||||
npx create-umi@latest ai-writer-admin
|
||||
# Chọn mẫu Ant Design Pro
|
||||
cd ai-writer-admin
|
||||
npm install
|
||||
```
|
||||
|
||||
Hoặc bắt đầu từ đầu:
|
||||
|
||||
```bash
|
||||
npx create-react-app ai-writer-admin --template typescript
|
||||
cd ai-writer-admin
|
||||
npm install antd @ant-design/icons @ant-design/pro-components
|
||||
```
|
||||
|
||||
### 5.2 Sử dụng AI IDE để tạo back-office quản trị
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tạo back-office quản trị trợ lý viết AI, sử dụng thư viện component Ant Design:
|
||||
|
||||
**Bố cục tổng thể:**
|
||||
- Bên trái là thanh menu: bảng điều khiển, quản lý người dùng, quản lý tài liệu, quản lý đơn hàng, cài đặt hệ thống
|
||||
- Trên cùng hiển thị điều hướng breadcrumb
|
||||
|
||||
**Trang quản lý người dùng:**
|
||||
- Trên cùng đặt bốn thẻ thống kê: tổng số người dùng,新增 hôm nay, số người dùng hoạt động, số người dùng trả phí
|
||||
- Khu vực tìm kiếm lọc: có thể tìm theo tên người dùng, chọn phạm vi thời gian đăng ký, lọc trạng thái người dùng, còn có nút "Tìm kiếm" và "Đặt lại"
|
||||
- Bảng người dùng:
|
||||
- Hiển thị avatar, tên người dùng, email, thời gian đăng ký, gói đăng ký (phân biệt bằng nhãn màu khác nhau), trạng thái, thao tác
|
||||
- Mỗi trang hiển thị 20 dòng, hỗ trợ phân trang
|
||||
- Có thể chọn hàng loạt người dùng, vô hiệu hóa hoặc xuất hàng loạt
|
||||
- Cột thao tác: xem chi tiết, chỉnh sửa, vô hiệu hóa (cần xác nhận lần hai trước khi vô hiệu hóa)
|
||||
- Nhấp "Xem chi tiết" trượt ra drawer từ bên phải, hiển thị thông tin chi tiết người dùng và danh sách tài liệu gần đây
|
||||
```
|
||||
|
||||
### 5.3 Các component cốt lõi mà AI sẽ sử dụng
|
||||
|
||||
```tsx
|
||||
import { PageContainer, ProLayout } from '@ant-design/pro-components'
|
||||
import { ProTable } from '@ant-design/pro-components'
|
||||
import { StatisticCard } from '@ant-design/pro-components'
|
||||
import {
|
||||
Button, Tag, Badge, Space, Drawer,
|
||||
Popconfirm, message, Modal
|
||||
} from 'antd'
|
||||
import {
|
||||
UserOutlined, SearchOutlined, ExportOutlined
|
||||
} from '@ant-design/icons'
|
||||
```
|
||||
|
||||
| Component | Mục đích | Vị trí trong back-office |
|
||||
| :--- | :--- | :--- |
|
||||
| `ProLayout` | Khung bố cục tổng thể back-office | Khung xương trang (menu + khu vực nội dung) |
|
||||
| `ProTable` | Bảng nâng cao, tích hợp tìm kiếm, phân trang, cài đặt cột | Danh sách người dùng, danh sách tài liệu, danh sách đơn hàng |
|
||||
| `StatisticCard` | Thẻ thống kê dữ liệu | Bảng điều khiển, tổng quan phía trên trang |
|
||||
| `Tag` / `Badge` | Nhãn trạng thái | Gói đăng ký, trạng thái người dùng |
|
||||
| `Drawer` | Drawer侧边 | Chi tiết người dùng, biểu mẫu chỉnh sửa |
|
||||
| `Popconfirm` | Hộp xác nhận bubble | Xóa, vô hiệu hóa và các thao tác nguy hiểm khác |
|
||||
|
||||
### 5.4 Tiếp tục lặp: Thêm bảng điều khiển
|
||||
|
||||
```text
|
||||
Vui lòng giúp tôi tạo một trang bảng điều khiển:
|
||||
|
||||
1. Bốn thẻ thống kê phía trên: tổng số người dùng, tổng số tài liệu, số lần gọi API hôm nay, doanh thu hàng tháng, mỗi thẻ hiển thị giá trị và thay đổi tuần hoàn (tăng hay giảm)
|
||||
2. Giữa đặt hai biểu đồ:
|
||||
- Bên trái: biểu đồ đường tăng trưởng người dùng 7 ngày gần nhất
|
||||
- Bên phải: biểu đồ tròn phân bố gói đăng ký
|
||||
3. Phía dưới: bảng nhật ký thao tác gần đây, hiển thị thời gian, người dùng, loại thao tác, chi tiết
|
||||
|
||||
Sử dụng component Ant Design để bố cục, biểu đồ có thể sử dụng Ant Design Charts
|
||||
```
|
||||
|
||||
> **Kỹ巧 Vibe Coding cho quản lý back-office**: Cấu trúc trang back-office tương đối cố định (bảng + tìm kiếm +弹窗), rất phù hợp để AI tạo hàng loạt. Bạn có thể để AI tạo trước một trang "Quản lý người dùng" làm mẫu, sau đó nói "Tham khảo cấu trúc trang quản lý người dùng, giúp tôi tạo trang quản lý tài liệu", AI sẽ tái sử dụng cùng một mô hình bố cục.
|
||||
|
||||
## 6. Học cách đọc tài liệu: "Hướng dẫn sử dụng" của thư viện component
|
||||
|
||||
Trong Vibe Coding, AI sẽ giúp bạn viết hầu hết code, nhưng khi kết quả AI tạo ra không chính xác, hoặc bạn muốn tinh chỉnh hành vi của một component, **đọc tài liệu** là cách giải quyết nhanh nhất.
|
||||
|
||||
Lấy Ant Design làm ví dụ, địa chỉ tài liệu của nó là: `https://ant.design/components/overview-cn`
|
||||
|
||||
Quy trình chuẩn để đọc tài liệu:
|
||||
|
||||
1. **Xác định nhu cầu**: Ví dụ "Tôi cần bảng hỗ trợ chọn hàng"
|
||||
2. **Tìm trong tài liệu**: Tìm "Table" để vào trang component bảng
|
||||
3. **Xem ví dụ**: Mỗi component trong tài liệu đều có nhiều ví dụ trực tuyến, tìm ví dụ "Có thể chọn"
|
||||
4. **Sao chép code**: Sao chép code ví dụ vào dự án của bạn
|
||||
5. **Xem bảng API**: Tìm cấu hình đầy đủ của thuộc tính `rowSelection` ở cuối trang
|
||||
|
||||
> Bạn cũng có thể gửi trực tiếp liên kết tài liệu cho AI IDE: "Vui lòng tham khảo API rowSelection của https://ant.design/components/table-cn, giúp tôi thêm chức năng chọn hàng loạt cho bảng người dùng". Cung cấp liên kết tài liệu cho AI, code tạo ra sẽ chính xác hơn.
|
||||
|
||||
Tra cứu nhanh địa chỉ tài liệu các thư viện component:
|
||||
|
||||
| Thư viện component | Địa chỉ tài liệu |
|
||||
| :--- | :--- |
|
||||
| Ant Design | `https://ant.design/components/overview-cn` |
|
||||
| shadcn/ui | `https://ui.shadcn.com/docs/components` |
|
||||
| HeroUI | `https://heroui.com/docs/components` |
|
||||
| Material UI | `https://mui.com/material-ui/all-components/` |
|
||||
| Element Plus | `https://element-plus.org/zh-CN/component/overview.html` |
|
||||
|
||||
## 7. Tóm tắt
|
||||
|
||||
Ba kịch bản thực chiến bao phủ các nhu cầu phát triển frontend phổ biến nhất:
|
||||
|
||||
| Kịch bản | Thư viện component khuyến nghị | Đặc điểm cốt lõi |
|
||||
| :--- | :--- | :--- |
|
||||
| Landing page / Trang showcase | HeroUI | Phong cách mặc định tinh xảo, animation mượt mà, sức mạnh thị giác mạnh |
|
||||
| Trang chức năng sản phẩm | shadcn/ui | Code hoàn toàn có thể kiểm soát, tùy chỉnh sâu linh hoạt |
|
||||
| Hệ thống quản lý back-office | Ant Design | Component nghiệp vụ phong phú, bảng biểu mẫu sử dụng ngay |
|
||||
|
||||
Tóm tắt quy trình làm việc Vibe Coding:
|
||||
|
||||
1. Chọn thư viện component phù hợp theo kịch bản
|
||||
2. Sử dụng AI IDE để mô tả cấu trúc trang và tương tác bạn muốn
|
||||
3. AI tạo code phiên bản đầu, bạn xem trước hiệu quả
|
||||
4. Tiếp tục lặp và điều chỉnh bằng ngôn ngữ tự nhiên
|
||||
5. Khi gặp vấn đề chi tiết, tra cứu tài liệu thư viện component
|
||||
|
||||
### Bài tập
|
||||
|
||||
Chọn một trong các kịch bản sau, sử dụng AI IDE + thư viện component để hoàn thành từ đầu:
|
||||
|
||||
1. Sử dụng HeroUI để tạo một landing page showcase cho dự án bạn đã làm trước đó (ví dụ chân dung Hogwarts)
|
||||
2. Sử dụng shadcn/ui để xây dựng giao diện chính của ứng dụng ghi chú (侧边栏 + trình soạn thảo)
|
||||
3. Sử dụng Ant Design để xây dựng một back-office quản lý nội dung đơn giản (danh sách bài viết + biểu mẫu tạo bài viết mới)
|
||||
|
||||
---
|
||||
|
||||
## Phụ lục: Thêm thư viện component
|
||||
|
||||
Ngoài bốn thư viện cốt lõi được giới thiệu trong phần chính, hệ sinh thái frontend còn có nhiều thư viện component xuất sắc. Dưới đây liệt kê theo framework phân loại, tiện cho bạn lựa chọn theo nhu cầu dự án.
|
||||
|
||||
### Hệ sinh thái Vue
|
||||
|
||||
| Thư viện component | Stars | Giới thiệu | Kịch bản sử dụng |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Element Plus](https://element-plus.org) | ~27k | Thư viện component doanh nghiệp Vue 3 do团队饿了么 phát triển, phổ biến nhất tại Trung Quốc, hệ sinh thái tiếng Trung tuyệt vời | Hệ thống quản lý back-office cấp trung |
|
||||
| [Vuetify](https://vuetifyjs.com) | ~41k | Thư viện component Vue Material Design phổ biến nhất, 80+ component, tài liệu hoàn thiện | Dự án phong cách thiết kế Google |
|
||||
| [Ant Design Vue](https://antdv.com) | ~21k | Thư viện component Vue 3 dựa trên hệ thống thiết kế Ant, quy phạm thiết kế thống nhất | Back-office doanh nghiệp cấp trung |
|
||||
| [Naive UI](https://www.naiveui.com) | ~18k | Viết bằng TypeScript, tính tùy chỉnh theme cực mạnh, không phụ thuộc CSS preprocessor | Dự án có yêu cầu thiết kế độc đáo |
|
||||
| [Quasar](https://quasar.dev) | ~27k | Một bộ code xây dựng ứng dụng SPA, SSR, PWA, thiết bị di động và desktop | Dự án cross-platform |
|
||||
| [Vant](https://vant-ui.github.io/vant) | ~24k | Thư viện component mobile nhẹ do团队有赞 phát triển, bao phủ các nhu cầu thương mại điện tử phổ biến | Trang H5 mobile |
|
||||
| [PrimeVue](https://primevue.org) | ~14k | 90+ component, hỗ trợ nhiều theme (Material, Bootstrap, v.v.) | Cần component phong phú và đa theme |
|
||||
| [Arco Design Vue](https://arco.design/vue) | ~3k | Sản phẩm bởi ByteDance, chất lượng component cao, tích hợp chế độ tối | Sản phẩm back-office cấp trung |
|
||||
| [TDesign Vue Next](https://tdesign.tencent.com/vue-next) | ~2k | Sản phẩm bởi Tencent, ngôn ngữ thiết kế thống nhất, bao phủ các kịch bản phổ biến desktop | Hệ sinh thái Tencent hoặc dự án doanh nghiệp |
|
||||
|
||||
### Hệ sinh thái React
|
||||
|
||||
| Thư viện component | Stars | Giới thiệu | Kịch bản sử dụng |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| [Material UI (MUI)](https://mui.com) | ~95k | Triển khai quy phạm Google Material Design lâu đời nhất, component toàn diện nhất, hệ sinh thái trưởng thành nhất | Xây dựng nhanh ứng dụng doanh nghiệp |
|
||||
| [Ant Design](https://ant.design) | ~94k | Sản phẩm bởi Ant Group, tích hợp nhiều component nghiệp vụ chất lượng cao, vị thế chủ đạo cộng đồng developer tiếng Trung | Back-office doanh nghiệp cấp trung |
|
||||
| [shadcn/ui](https://ui.shadcn.com) | ~83k | Code sao chép vào dự án chứ không cài npm, dựa trên Radix UI + Tailwind CSS, hoàn toàn có thể kiểm soát | Dự án cần tùy chỉnh cao |
|
||||
| [Chakra UI](https://chakra-ui.com) | ~39k | Lấy trải nghiệm developer làm cốt lõi, API简洁, tích hợp hỗ trợ truy cập vô障碍 | Phát triển nguyên mẫu nhanh |
|
||||
| [Mantine](https://mantine.dev) | ~28k | 100+ component và 50+ hooks, bao gồm date picker, rich text editor và các component nâng cao khác | Cần giải pháp全功能 sử dụng ngay |
|
||||
| [Headless UI](https://headlessui.com) | ~27k | Thư viện component không phong cách chính thức bởi Tailwind Labs, đồng thời hỗ trợ React và Vue | Sử dụng kết hợp với Tailwind CSS |
|
||||
| [HeroUI](https://heroui.com) | ~24k | Dựa trên Tailwind CSS + React Aria, phong cách mặc định tinh xảo, animation mượt mà | Dự án theo đuổi chất lượng thị giác |
|
||||
| [Radix UI](https://www.radix-ui.com) | ~17k | Thư viện primitive component không phong cách底层的, tập trung vô障碍 và hành vi component, là nền tảng底层的 của shadcn/ui | Xây dựng hệ thống thiết kế tùy chỉnh |
|
||||
|
||||
#### Hệ sinh thái mở rộng shadcn/ui
|
||||
|
||||
Ngoài các thư viện component通 dụng trên, hệ sinh thái shadcn/ui còn xuất hiện nhiều thư viện mở rộng dựa trên khái niệm của nó, cung cấp lựa chọn khác biệt cho các kịch bản cụ thể. Các thư viện mở rộng này cũng采用 mô hình "sao chép code vào dự án", cho developer có quyền kiểm soát mã nguồn hoàn toàn.
|
||||
|
||||
| Thư viện component | Giới thiệu | Kịch bản sử dụng |
|
||||
| :--- | :--- | :--- |
|
||||
| [Aceternity UI](https://ui.aceternity.com) | 200+ component cấp production,主打 thẻ phát sáng, gradient文字, 3D地球 và các component thị giác đặc sắc khác | Landing page chất lượng cao, sản phẩm SaaS |
|
||||
| [Tailark UI](https://tailark.com) | Bộ sưu tập khối component trang web marketing, showcase sản phẩm, lời chứng nhận khách hàng, nút CTA và các module marketing tần suất cao | Landing page marketing, trang chủ sản phẩm |
|
||||
| [UI Tripled](https://ui.tripled.work) | Component tương tác động dựa trên Framer Motion,弹窗, điều hướng, animation thẻ | Công cụ sáng tạo, portfolio cá nhân |
|
||||
| [Neobrutalism UI](https://neobrutalism.dev) | Phong cách Neo-brutalism, đường viền粗, độ tương phản cao, màu sắc鲜明 | Trang chủ thương hiệu cá nhân hóa, dự án sáng tạo |
|
||||
| [REUI](https://reui.io) | 967+ mẫu tổ hợp component cho 967+ kịch bản nghiệp vụ thực tế | Back-office doanh nghiệp, biểu mẫu phức tạp |
|
||||
| [Cult UI](https://cult-ui.com) | Đánh bóng tương tác/thị giác tinh tế hơn, component phức hợp như bảng dữ liệu, bảng lọc | Dự án thương mại chất lượng cao |
|
||||
| [Kibo UI](https://kibo-ui.com) | Component nghiệp vụ nâng cao, color picker, rich text editor, tải tệp | Back-office quản lý, sản phẩm kiểu công cụ |
|
||||
| [Kokonut UI](https://kokonutui.com) | 100+ component + 7+ template hoàn chỉnh, phong cách清新简约 | Trang chủ SaaS, blog, thương mại điện tử |
|
||||
| [Commerce UI](https://ui.stackzero.co) | Chuyên dùng cho kịch bản thương mại điện tử, thẻ sản phẩm, giỏ hàng, biểu mẫu thanh toán | Nền tảng thương mại điện tử |
|
||||
| [shadcnblocks](https://shadcnblocks.com) | 1373 UI block + 13 bộ template hoàn chỉnh, tài nguyên toàn diện nhất | Tất cả các kịch bản |
|
||||
| [Shoogle](https://shoogle.dev) | Nền tảng tổng hợp tìm kiếm hệ sinh thái shadcn/ui | Tìm kiếm tài nguyên nhanh chóng |
|
||||
| [Discover All Shadcn](https://allshadcn.com) | Điều hướng tài nguyên tổng hợp | Tìm kiếm tài nguyên nhanh chóng |
|
||||
|
||||
> **Tại sao chọn mở rộng shadcn/ui?** Các mở rộng này kế thừa khái niệm "quyền sở hữu code" của shadcn/ui, đồng thời tùy chỉnh sâu cho các kịch bản cụ thể. Trong thời đại Vibe Coding, chúng giúp bạn nhanh chóng tìm được component phù hợp với nhu cầu thiết kế, thoát khỏi sự同质 hóa của các thư viện UI主流, tạo ra sản phẩm có tính khác biệt hóa cao hơn.
|
||||
@@ -0,0 +1,425 @@
|
||||
# Thiết kế trang và nút bấm theo quy chuẩn UI
|
||||
|
||||
Nhiều người nói "Tôi muốn trang giống Apple hơn một chút" "Nút bấm muốn làm cao cấp hơn một chút", nhưng khi thực sự bắt đầu làm, thường sẽ bị kẹt ở một vấn đề:
|
||||
|
||||
**Rốt cuộc nên tham khảo cái gì?**
|
||||
|
||||
Nhìn screenshot bắt chước, học được chỉ là "có giống hay không". Nhưng khi mở quy chuẩn thiết kế của Apple, Google, Microsoft, Atlassian, bạn sẽ phát hiện điểm thực sự tuyệt vời của họ không phải là phong cách thị giác, mà là **nói rõ vấn đề thiết kế**: trang trước tiên làm nổi bật cái gì, nút bấm phân cấp thế nào, thao tác nhấn mạnh ra sao — những tiêu chuẩn phán đoán này mới là cốt lõi.
|
||||
|
||||
> Tham khảo quy chuẩn thiết kế, không phải để làm "giống ai", mà là học cách người khác đưa ra phán đoán.
|
||||
|
||||
:::: info Tại sao bây giờ vẫn cần học những điều này
|
||||
Các quy tắc thiết kế đã được huấn luyện vào mô hình, được công cụ thiết kế hấp thụ mặc định, thậm chí chỉ cần dán vài screenshot AI đã có thể học được. Nhưng chúng ta vẫn cần biết những quy tắc này đến từ đâu, tại sao lại quy định như vậy.
|
||||
::::
|
||||
|
||||
## Trước hết xem vài đoạn nguyên văn, cảm nhận khoảng cách
|
||||
|
||||
Nếu bạn trước đây nghĩ "quy chuẩn thiết kế chẳng phải chỉ nói về phong cách thôi sao", hãy xem trước vài câu nguyên văn chính thức.
|
||||
|
||||
Bình thường trong đội nhóm chúng ta thường nói như thế này:
|
||||
|
||||
- Làm một dropdown
|
||||
- Ở đây đặt một menu
|
||||
- Thêm vài chức năng vào thanh menu
|
||||
- Ở đây đặt hai nút, một xác nhận một hủy
|
||||
|
||||
Nghe có vẻ không có vấn đề, nhưng trong quy chuẩn của các công ty lớn, những từ này không phải là khái niệm mơ hồ, mà được phân tích rất chi tiết.
|
||||
|
||||
| Lời nói bình thường | Nguyên văn chính thức | Nói đơn giản |
|
||||
| :--- | :--- | :--- |
|
||||
| "Làm một menu" | Apple: ["A menu reveals its options..."](https://developer.apple.com/design/human-interface-guidelines/menus) | `Menu` là dùng để làm thao tác |
|
||||
| "Đặt chức năng vào thanh menu" | Apple: ["menu bar menus contain all the commands..."](https://developer.apple.com/design/human-interface-guidelines/menus) | Đây là menu lệnh ở đầu ứng dụng |
|
||||
| "Làm một dropdown" | Apple: ["A pop-up list lets the user choose one option among several."](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html) | `pop-up` là chọn một cái từ danh sách |
|
||||
| "Cũng làm một dropdown" | Apple: ["A pull-down list is generally used for selecting commands in a specific context."](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html) | `pull-down` là bấm mở để làm thao tác hiện tại |
|
||||
| "Menu cũng có thể dùng để lọc đúng không" | Fluent: ["If you need to collect information from people, try a select, dropdown, or combobox instead."](https://fluent2.microsoft.design/components/web/react/core/menu/usage) | `Menu` không phải để chọn giá trị |
|
||||
| "Menu cũng có thể làm điều hướng đúng không" | Material: ["Menus should not be used as a primary method for navigation within an app."](https://m1.material.io/components/menus.html) | `Menu` không phải điều hướng chính |
|
||||
| "Nút bấm cứ viết OK / Cancel thôi" | Apple: ["Always use 'Cancel' to title a button that cancels the alert's action."](https://developer.apple.com/design/human-interface-guidelines/alerts) | Văn bản nút không thể viết tùy tiện |
|
||||
|
||||
> Các trích dẫn trong bảng đều có thể nhấp trực tiếp để đến trang chính thức tương ứng.
|
||||
|
||||
Đây chính là điều dễ gây ấn tượng mạnh nhất khi lần đầu tiên thực sự xem quy chuẩn thiết kế:
|
||||
|
||||
> Chúng ta bình thường tưởng mình đang thảo luận về UI, nhưng thực tế rất nhiều lúc chỉ đang giao tiếp bằng một đống từ ngữ mơ hồ.
|
||||
|
||||
Apple sẽ không chỉ nói "làm một menu"; nó sẽ tiếp tục phân biệt:
|
||||
|
||||
- `menu`
|
||||
- `menu bar menu`
|
||||
- `pop-up button`
|
||||
- `pull-down button`
|
||||
- `context menu`
|
||||
|
||||
Fluent sẽ không chỉ nói "dropdown"; nó sẽ tiếp tục phân biệt:
|
||||
|
||||
- `menu`
|
||||
- `dropdown`
|
||||
- `select`
|
||||
- `combobox`
|
||||
|
||||
Đây chính là sự cần thiết của quy chuẩn thiết kế.
|
||||
|
||||
Nó không phải để làm trang có vẻ chuyên nghiệp hơn, mà là để khi đội nhóm thảo luận về UI, trong đầu mỗi người không còn là những thứ khác nhau nữa.
|
||||
|
||||
## Bạn sẽ học được gì
|
||||
|
||||
1. Tại sao khi thiết kế trang và nút bấm cần xem quy chuẩn thiết kế trước
|
||||
2. Trong các quy chuẩn Apple, Material, Fluent, Atlassian, nội dung nào đáng tham khảo nhất
|
||||
3. Cách thiết kế rõ ràng "cấp bậc trang" và "cấp bậc nút bấm"
|
||||
4. Cách để AI tham khảo quy chuẩn của người khác để tạo trang và nút bấm
|
||||
|
||||
## 1. Tại sao quy chuẩn thiết kế có thể giúp bạn làm rõ trang
|
||||
|
||||
Sau khi xem những nguyên văn trên, bạn sẽ phát hiện một điểm quan trọng:
|
||||
|
||||
**Quy chuẩn thiết kế không phải điểm tô, mà là trước hết nói chính xác từ ngữ.**
|
||||
|
||||
Nhiều trang không đẹp, không phải vì màu sắc không đủ cao cấp, mà vì cấp bậc thông tin lộn xộn.
|
||||
|
||||
Nhiều nút không dễ dùng, cũng không phải vì bo góc không đúng, mà vì:
|
||||
|
||||
- Nút chính quá nhiều, người dùng không biết nên nhấn cái nào
|
||||
- Nút nguy hiểm và nút bình thường trông giống nhau
|
||||
- Tất cả nút trong trang đều tranh giành sự chú ý
|
||||
- Phong cách và ngữ nghĩa của nút không nhất quán giữa các trang khác nhau
|
||||
|
||||
Quy chuẩn thiết kế trưởng thành,恰好 là đang giải quyết những vấn đề này. Chúng thường sẽ định nghĩa:
|
||||
|
||||
| Nội dung quy chuẩn | Nó giải quyết vấn đề gì |
|
||||
| :--- | :--- |
|
||||
| **Cấp bậc trang** | Nhìn đâu trước, nhìn đâu sau, thông tin tổ chức thế nào |
|
||||
| **Nền tảng thị giác** | Màu sắc, khoảng cách, font chữ, bo góc, bóng đổ thống nhất thế nào |
|
||||
| **Cấp bậc nút bấm** | Nút chính, nút phụ, nút văn bản, nút nguy hiểm phân biệt thế nào |
|
||||
| **Quy tắc trạng thái** | hover, focus, disabled, loading thể hiện thế nào |
|
||||
| **Ngữ nghĩa tương tác** | Nút nào là "xác nhận", nút nào là "hủy", nút nào là "thao tác thêm" |
|
||||
|
||||
Vì vậy, quy chuẩn thiết kế thực sự cung cấp không phải là một "lớp da", mà là một **tiêu chuẩn phán đoán**.
|
||||
|
||||
## 2. Khi tham khảo quy chuẩn công ty lớn, tập trung vào điều gì
|
||||
|
||||
### 2.1 Tham khảo Apple: Học cách "định nghĩa đủ chi tiết"
|
||||
|
||||
Điều đáng học nhất ở Apple không chỉ là sự kiềm chế thị giác, mà là nó sẽ định nghĩa khái niệm rất chi tiết.
|
||||
|
||||
Cùng là "menu" hoặc "dropdown" trong miệng nhiều đội nhóm, Apple sẽ tiếp tục phân tích nhỏ:
|
||||
|
||||
- `menu`: Một nhóm lệnh, tùy chọn hoặc trạng thái
|
||||
- `menu bar menu`: Tập hợp lệnh cấp ứng dụng
|
||||
- `pop-up button`: Chọn một giá trị
|
||||
- `pull-down button`: Kích hoạt lệnh trong ngữ cảnh hiện tại
|
||||
- `context menu`: Các hành động thường dùng liên quan đến đối tượng hoặc nhiệm vụ hiện tại
|
||||
|
||||
Sự phân biệt này rất quan trọng, vì nó sẽ trực tiếp ảnh hưởng đến:
|
||||
|
||||
- Component này dùng để chọn giá trị, hay dùng để làm hành động
|
||||
- Nó thuộc về cục bộ trang, hay thuộc về cấp ứng dụng
|
||||
- Nó nên hiển thị lâu dài giá trị đã chọn, hay chỉ tạm thời mở rộng lệnh
|
||||
|
||||
Khi bạn bắt đầu suy nghĩ theo mức độ chi tiết này, trang bạn thiết kế sẽ lập tức rõ ràng hơn nhiều.
|
||||
|
||||
### 2.2 Tham khảo Apple: Học cấp bậc trang và sự kiềm chế
|
||||
|
||||
Apple Human Interface Guidelines đặc biệt phù hợp để học hai điều:
|
||||
|
||||
- Trang thiết lập cấp bậc rõ ràng thế nào
|
||||
- Điều khiển giữ rõ ràng dưới tiền đề không lấn át
|
||||
|
||||
Apple nhấn mạnh `Hierarchy`, `Harmony`, `Consistency`. Điều này có nghĩa là khi thiết kế trang cần trả lời:
|
||||
|
||||
- Thông tin quan trọng nhất của trang hiện tại là gì
|
||||
- Nhiệm vụ chính của người dùng là gì
|
||||
- Thao tác nào nên nổi bật nhất, thao tác nào nên lùi lại
|
||||
|
||||
Nếu bạn tham khảo Apple để thiết kế trang, có thể tập trung tham khảo:
|
||||
|
||||
- Thông tin màn hình đầu không nên quá vụn, nội dung cốt lõi tập trung trước
|
||||
- Dùng khoảng trắng, kích thước font, nhóm để tạo trật tự, thay vì chất nhiều viền
|
||||
- Nút không nên tất cả đều nhấn mạnh cao, chỉ hành động quan trọng mới nên nổi bật nhất
|
||||
|
||||
### 2.3 Tham khảo Material: Học cấu trúc trang rõ ràng
|
||||
|
||||
Material Design rất phù hợp để học "trang tổ chức luồng nhiệm vụ thế nào".
|
||||
|
||||
Nhiều component và quy chuẩn layout của nó, cốt lõi đều giúp bạn làm rõ:
|
||||
|
||||
- Trang là loại duyệt, hay loại thực thi nhiệm vụ
|
||||
- Trang hiện tại là để người dùng đọc, chọn, hay nộp
|
||||
- Trong một trang, yếu tố nào nên lặp lại ổn định, yếu tố nào nên phản hồi thay đổi ngữ cảnh
|
||||
|
||||
Nếu bạn tham khảo Material để thiết kế trang, có thể tập trung tham khảo:
|
||||
|
||||
- Khu vực trang rõ ràng, trách nhiệm module xác định
|
||||
- Điều hướng, khu vực nội dung, khu vực thao tác phân công rõ ràng
|
||||
- Các phong cách nút khác nhau tương ứng với mức độ ưu tiên thao tác khác nhau
|
||||
|
||||
### 2.4 Tham khảo Fluent: Học ranh giới component và cấp bậc nút
|
||||
|
||||
Fluent 2 rất phù hợp cho sản phẩm backend, công cụ và hệ thống form phức tạp. Điều đáng học nhất là nó sẽ trực tiếp nói cho bạn biết "đừng lẫn lộn khái niệm".
|
||||
|
||||
Ví dụ nó ghi rõ: nếu bạn muốn "collect information", thì đừng tiếp tục dùng `menu`, mà nên cân nhắc `select`, `dropdown`, `combobox`.
|
||||
|
||||
Câu nói này rất quan trọng, vì nó phá vỡ "cũng gần giống nhau" trong đầu nhiều người.
|
||||
|
||||
Fluent 2 cũng rất chú trọng:
|
||||
|
||||
- Cấp bậc thao tác
|
||||
- Ranh giới ngữ nghĩa component
|
||||
- Độ rõ ràng trong kịch bản thông tin dày đặc
|
||||
|
||||
Nếu bạn tham khảo Fluent để thiết kế nút, có thể tập trung tham khảo:
|
||||
|
||||
- `Primary button` dùng để gánh hành động quan trọng nhất hiện tại
|
||||
- `Secondary button` dùng để gánh hành động hỗ trợ
|
||||
- Các nút nhấn mạnh yếu như `Subtle`, `Transparent` dùng cho thao tác không nên tranh luồng chính
|
||||
- Càng nhiều nút trong trang, càng cần kiểm soát mức độ ưu tiên thị giác
|
||||
|
||||
### 2.5 Tham khảo Atlassian: Học quản lý trang và nút bấm theo hệ thống
|
||||
|
||||
Atlassian Design System đặc biệt phù hợp cho tình huống "một đội nhóm làm nhiều trang". Nó nhấn mạnh:
|
||||
|
||||
- foundations là nền tảng chia sẻ
|
||||
- tokens là phương pháp thống nhất quyết định thị giác
|
||||
- components là thành phần tương tác được tái sử dụng lặp đi lặp lại
|
||||
|
||||
Nếu bạn tham khảo Atlassian để làm trang và nút, giá trị nhất là:
|
||||
|
||||
- Làm kích thước, màu sắc, bo góc, khoảng cách nút thành quy tắc thống nhất
|
||||
- Cố định nhịp điệu layout trang
|
||||
- Để các trang khác nhau tuy nội dung khác nhưng ngôn ngữ cấu trúc nhất quán
|
||||
|
||||
## 3. Khi thiết kế trang, nên tham khảo những điểm nào trong quy chuẩn
|
||||
|
||||
Khi bạn xem một hệ thống thiết kế, đừng hỏi trước "trang này đẹp không", mà hãy hỏi trước mấy câu hỏi dưới đây.
|
||||
|
||||
### 3.1 Nhìn trang lần đầu, chính phụ có rõ ràng không
|
||||
|
||||
Một trang thường ít nhất phải có ba tầng:
|
||||
|
||||
- **Thông tin chính**: Nội dung quan trọng nhất của trang hiện tại
|
||||
- **Thông tin phụ trợ**: Nội dung giúp hiểu hoặc bổ sung
|
||||
- **Thao tác cấp hai**: Hành động không nên can thiệp nhiệm vụ chính
|
||||
|
||||
Nếu ba tầng không mở rộng ra, trang sẽ "đều quan trọng", tương đương với "đều không quan trọng".
|
||||
|
||||
### 3.2 Layout trang, có phục vụ nhiệm vụ thay vì chất module không
|
||||
|
||||
Khi tham khảo quy chuẩn, có thể đặc biệt chú ý:
|
||||
|
||||
- Khu vực tiêu đề có làm rõ mục tiêu trang không
|
||||
- Khu vực nội dung chính có xoay quanh nhiệm vụ tổ chức không
|
||||
- Nút thao tác có gần nội dung liên quan không
|
||||
- Thông tin thứ cấp có được làm yếu đi không
|
||||
|
||||
### 3.3 Thao tác trong trang, có mức độ ưu tiên không
|
||||
|
||||
Nhiều trang nhìn qua có 6 nút, kết quả mỗi nút đều giống CTA, đây là cấp bậc mất kiểm soát điển hình.
|
||||
|
||||
Cách hợp lý hơn là:
|
||||
|
||||
- Một khu vực thường chỉ có một thao tác chính
|
||||
- Thao tác cấp hai có thể dùng viền, nút văn bản hoặc phong cách yếu hơn
|
||||
- Hành động rủi ro không nên trông giống hành động chính
|
||||
|
||||
## 4. Khi thiết kế nút, nên tham khảo những điểm nào trong quy chuẩn
|
||||
|
||||
Nút là phần dễ bị "thiết kế tùy tiện" nhất, nhưng cũng là phần dễ bộc lộ hệ thống có trưởng thành hay không nhất.
|
||||
|
||||
### 4.1 Nút trước hết phân "ngữ nghĩa", rồi mới phân "phong cách"
|
||||
|
||||
Đừng nghĩ trước "nút xanh hay nút đen", hãy nghĩ trước nút này đóng vai trò gì.
|
||||
|
||||
Vai trò nút phổ biến có thể phân như sau:
|
||||
|
||||
| Loại nút | Tác dụng | Chiến lược phong cách phổ biến |
|
||||
| :--- | :--- | :--- |
|
||||
| **Primary** | Hành động quan trọng nhất trong khu vực hiện tại | Đặc, tương phản cao, nổi bật nhất |
|
||||
| **Secondary** | Hành động hỗ trợ | Viền hoặc nhấn mạnh thấp hơn một cấp |
|
||||
| **Tertiary / Text** | Thao tác yếu | Văn bản hoặc tỷ trọng thị giác thấp |
|
||||
| **Destructive** | Các thao tác rủi ro như xóa, vô hiệu hóa, xóa sạch | Màu cảnh báo hoặc phong cách rủi ro rõ ràng |
|
||||
| **Icon button** | Thao tác công cụ cục bộ | Ngắn gọn, gần ngữ cảnh |
|
||||
|
||||
### 4.2 Một trang không nên có quá nhiều Primary Button
|
||||
|
||||
Đây là cái bẫy dễ giẫm nhất của nhiều người mới.
|
||||
|
||||
Nếu trên trang có 4 nút chính, thì tương đương không có nút chính. Ý nghĩa của nút chính vốn dĩ là "nói cho người dùng biết bây giờ nên làm gì nhất".
|
||||
|
||||
Bạn có thể tham khảo cách làm chung của nhiều hệ thống thiết kế:
|
||||
|
||||
- Một khu vực chính thường chỉ giữ một nút chính
|
||||
- Hủy, quay lại, đóng thường không tranh cùng cấp với nút xác nhận
|
||||
- Thêm thao tác đặt vào nút cấp hai hoặc menu
|
||||
|
||||
### 4.3 Nút phải có thể thể hiện thay đổi trạng thái
|
||||
|
||||
Quy chuẩn thiết kế thường viết rất rõ về trạng thái nút:
|
||||
|
||||
- Trạng thái mặc định
|
||||
- Trạng thái hover
|
||||
- Trạng thái focus
|
||||
- Trạng thái disabled
|
||||
- Trạng thái loading
|
||||
- Trạng thái nguy hiểm
|
||||
|
||||
Điều này rất quan trọng, vì nút không phải là một bức ảnh tĩnh, mà là một trong những điều khiển được kích hoạt thường xuyên nhất trong quá trình người dùng thao tác.
|
||||
|
||||
### 4.4 Văn bản nút, cũng thuộc một phần của thiết kế
|
||||
|
||||
Văn bản nút không chỉ là "vấn đề copywriting", nó trực tiếp ảnh hưởng đến sự hiểu biết của người dùng.
|
||||
|
||||
Ví dụ:
|
||||
|
||||
- `Lưu`
|
||||
- `Lưu thay đổi`
|
||||
- `Xuất bản ngay`
|
||||
- `Xóa dự án`
|
||||
- `Chuyển vào thùng rác`
|
||||
|
||||
Những văn bản này truyền đạt kỳ vọng tâm lý hoàn toàn khác nhau. Quy chuẩn trưởng thành thường yêu cầu nhãn nút thể hiện rõ hành động, thay vì sử dụng từ ngữ mơ hồ.
|
||||
|
||||
## 5. Một danh sách thiết kế trang và nút rất thực dụng
|
||||
|
||||
Khi bạn tự thiết kế trang, có thể xem nhanh qua danh sách này trước:
|
||||
|
||||
### Danh sách trang
|
||||
|
||||
- Tiêu đề trang có nói rõ nhiệm vụ hiện tại không
|
||||
- Thông tin quan trọng nhất màn hình đầu có nhìn thấy ngay không
|
||||
- Trang có tổ chức theo luồng nhiệm vụ, thay vì nghĩ đến gì đặt nấy không
|
||||
- Trong cùng một khu vực có chỉ có một thao tác chính không
|
||||
- Nội dung thứ cấp có được làm yếu phù hợp không
|
||||
|
||||
### Danh sách nút
|
||||
|
||||
- Nút này là thao tác chính hay thao tác phụ
|
||||
- Tại sao nó đáng nổi bật hơn nút khác
|
||||
- Trong trang có quá nhiều nút chính không
|
||||
- Thao tác nguy hiểm có được đánh dấu rõ ràng không
|
||||
- Văn bản nút có đủ cụ thể không
|
||||
|
||||
## 6. Cách dùng AI tham khảo quy chuẩn của người khác để thiết kế trang
|
||||
|
||||
Phần này thực dụng nhất.
|
||||
|
||||
Nhiều người khi để AI thiết kế trang, chỉ nói:
|
||||
|
||||
```md
|
||||
Giúp tôi làm một trang cài đặt, cao cấp hơn một chút, tham khảo phong cách Apple
|
||||
```
|
||||
|
||||
Loại prompt này quá mơ hồ, AI cuối cùng thường chỉ có thể bắt chước "nền trắng, bo tròn, bóng đổ".
|
||||
|
||||
Đối với người mới, cách thực dụng hơn không phải là tự tổng hợp một đoạn dài, mà là trực tiếp dán **câu then chốt trong nguyên văn quy chuẩn** cho AI.
|
||||
|
||||
Làm như vậy có hai lợi ích:
|
||||
|
||||
- Bạn không cần tự "dịch" tư tưởng thiết kế trước
|
||||
- AI dễ hiểu trang và nút theo định nghĩa chính thức hơn
|
||||
|
||||
### 6.1 Ví dụ 1: Để AI tham khảo Apple thiết kế một trang cài đặt
|
||||
|
||||
Tìm một câu nguyên văn Apple trước:
|
||||
|
||||
> ["Establish a clear visual hierarchy..."](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
|
||||
Bạn có thể trực tiếp dán cho AI như thế này:
|
||||
|
||||
```md
|
||||
Tham khảo câu này từ Apple Human Interface Guidelines:
|
||||
"Establish a clear visual hierarchy..."
|
||||
|
||||
Giúp tôi thiết kế một trang cài đặt bảo mật tài khoản.
|
||||
Yêu cầu cấp bậc trang rõ ràng, thông tin quan trọng đặt trước, phân nhóm ngăn nắp.
|
||||
```
|
||||
|
||||
Điểm quan trọng của cách viết này là: bạn không cần tự giải thích quá nhiều, trực tiếp dán nguyên văn của Apple vào.
|
||||
|
||||
### 6.2 Ví dụ 2: Để AI tham khảo Fluent thiết kế nút trang backend
|
||||
|
||||
Tìm một câu nguyên văn Fluent trước:
|
||||
|
||||
> ["Only use one primary button in a layout..."](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
|
||||
Bạn có thể trực tiếp dán cho AI như thế này:
|
||||
|
||||
```md
|
||||
Tham khảo câu này từ Fluent 2:
|
||||
"Only use one primary button in a layout..."
|
||||
|
||||
Giúp tôi thiết kế nút cho trang quản lý đội nhóm backend.
|
||||
Nút thêm thành viên nổi bật nhất, xuất, lọc, thêm thao tác yếu hơn, nút xóa nổi bật riêng.
|
||||
```
|
||||
|
||||
Câu này rất phù hợp cho người mới, vì nó trực tiếp nói cho AI: một khu vực không nên đặt quá nhiều nút chính.
|
||||
|
||||
### 6.3 Ví dụ 3: Để AI đồng thời tham khảo quy chuẩn trang và quy chuẩn nút
|
||||
|
||||
Bạn cũng có thể dán hai câu nguyên văn cùng lúc, để AI đồng thời tham khảo trang và nút:
|
||||
|
||||
> Apple: ["Establish a clear visual hierarchy..."](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
>
|
||||
> Fluent: ["Only use one primary button in a layout..."](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
|
||||
Rồi trực tiếp viết như thế này:
|
||||
|
||||
```md
|
||||
Tham khảo hai câu nguyên văn quy chuẩn thiết kế dưới đây:
|
||||
Apple: "Establish a clear visual hierarchy..."
|
||||
Fluent: "Only use one primary button in a layout..."
|
||||
|
||||
Giúp tôi thiết kế một trang chi tiết dự án.
|
||||
Trang bao gồm giới thiệu dự án, thành viên, hoạt động gần đây và lối vào cài đặt.
|
||||
Cấp bậc trang rõ ràng hơn, chỉ giữ một nút chính, nút khác yếu hơn.
|
||||
```
|
||||
|
||||
Cách này đặc biệt phù hợp cho người mới, vì bạn chỉ cần biết sao chép nguyên văn, rồi thêm hai câu yêu cầu của mình là đủ.
|
||||
|
||||
## 7. Cách dùng AI tham khảo quy chuẩn nút để trực tiếp tạo thiết kế nút
|
||||
|
||||
Nếu bạn chỉ muốn làm nút trước, cũng có thể trực tiếp dán nguyên văn quy chuẩn nút.
|
||||
|
||||
Ví dụ định nghĩa nút của Atlassian rất ngắn:
|
||||
|
||||
> ["A button triggers an event or action."](https://atlassian.design/components/button/)
|
||||
|
||||
Bạn có thể hỏi AI như thế này:
|
||||
|
||||
```md
|
||||
Tham khảo câu này của Atlassian:
|
||||
"A button triggers an event or action."
|
||||
|
||||
Giúp tôi thiết kế một bộ phong cách nút cho trang backend.
|
||||
Tôi cần có nút chính, nút phụ, nút xóa, tiện thể nói cho tôi biết dùng ở đâu tương ứng.
|
||||
```
|
||||
|
||||
Loại prompt này đặc biệt phù hợp cho người mới, cơ bản là "dán nguyên văn + nói yêu cầu".
|
||||
|
||||
## 8. Tổng kết
|
||||
|
||||
Tham khảo quy chuẩn thiết kế UI để thiết kế trang và nút bấm, điều quan trọng nhất không phải "làm giống ai", mà là học được mấy điều sau:
|
||||
|
||||
1. Dùng cấp bậc tổ chức trang, thay vì chất nội dung lên
|
||||
2. Dùng phân cấp nút thể hiện mức độ ưu tiên thao tác, thay vì để tất cả nút đều tranh giành sự chú ý như nhau
|
||||
3. Dùng định nghĩa, ranh giới và tiêu chuẩn phán đoán trong quy chuẩn thiết kế để dẫn dắt thiết kế
|
||||
4. Khi để AI tham khảo quy chuẩn của người khác, tham khảo là "nguyên tắc và cấu trúc", chứ không phải chỉ tham khảo lớp da
|
||||
|
||||
Khi bạn sử dụng quy chuẩn như thế này, những gì bạn tham khảo được không chỉ là một phong cách, mà là một cách tư duy thiết kế trưởng thành.
|
||||
|
||||
---
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
Các liên kết dưới đây đều đến từ hệ thống thiết kế chính thức hoặc tài liệu chính thức:
|
||||
|
||||
- Apple Human Interface Guidelines: [Overview](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
- Apple Human Interface Guidelines: [Menus](https://developer.apple.com/design/human-interface-guidelines/menus)
|
||||
- Apple Human Interface Guidelines: [Alerts](https://developer.apple.com/design/human-interface-guidelines/alerts)
|
||||
- Apple Human Interface Guidelines: [Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons)
|
||||
- Apple Archive: [How Menus Work](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/HowMenusWork.html)
|
||||
- Apple Archive: [Managing Pop-Up Buttons and Pull-Down Lists](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MenuList/Articles/ManagingPopUpItems.html)
|
||||
- Material Design: [Buttons overview](https://m3.material.io/components/buttons/overview)
|
||||
- Material Design: [Menus](https://m1.material.io/components/menus.html)
|
||||
- Microsoft Fluent 2: [Start designing](https://fluent2.microsoft.design/get-started/design)
|
||||
- Microsoft Fluent 2: [Menu usage](https://fluent2.microsoft.design/components/web/react/core/menu/usage)
|
||||
- Microsoft Fluent 2: [Button usage](https://fluent2.microsoft.design/components/web/react/core/button/usage)
|
||||
- Atlassian Design System: [Foundations](https://atlassian.design/foundations/)
|
||||
- Atlassian Design System: [Button](https://atlassian.design/components/button/)
|
||||
@@ -0,0 +1,3 @@
|
||||
# Xây dựng ứng dụng hiện đại đầu tiên - Thiết kế UI
|
||||
|
||||
> Chương này đang được biên soạn, hãy mong chờ...
|
||||
+135
-68
@@ -1,126 +1,193 @@
|
||||
# Phát triển Full-Stack
|
||||
|
||||
Chào mừng đến với giai đoạn **Phát triển Full-Stack**! Ở đây bạn sẽ đi sâu vào phát triển full-stack, thành thạo component hóa frontend, thiết kế cơ sở dữ liệu, phát triển API backend và triển khai.
|
||||
Chào mừng đến với giai đoạn **Phát triển Full-Stack**! Ở đây bạn sẽ đi sâu vào phát triển full-stack, thành thạo component hóa frontend, thiết kế cơ sở dữ liệu, phát triển API backend và triển khai ứng dụng.
|
||||
|
||||
## Bạn sẽ học được gì
|
||||
|
||||
### Phát triển Frontend
|
||||
|
||||
Thành thạo phát triển frontend hiện đại và học cách sử dụng thư viện component và công cụ thiết kế:
|
||||
Thành thạo phát triển frontend hiện đại, học cách sử dụng thư viện component và công cụ thiết kế:
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 0: Sử dụng Lovart cho tài nguyên"
|
||||
description="Học cách sử dụng các công cụ AI như Lovart để tạo nhanh tài nguyên trò chơi chất lượng cao và tài nguyên UI"
|
||||
href="/vi-vn/stage-2/frontend/lovart-assets/"
|
||||
title="Bắt đầu với Lovart, xây dựng Agent sản xuất tài nguyên của riêng bạn"
|
||||
description="Bắt đầu từ con số không, sử dụng Nanobanana và Lovart để tạo hàng loạt tài nguyên thiết kế chất lượng cao và xây dựng một Agent vẽ ảnh có khả năng nhận diện ý định"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 1: Giới thiệu Figma và MasterGo"
|
||||
description="Thành thạo các thao tác cơ bản của công cụ thiết kế UI chuyên nghiệp và quy trình làm việc từ thiết kế đến code"
|
||||
href="/vi-vn/stage-2/frontend/figma-mastergo/"
|
||||
title="Giới thiệu Figma và MasterGo"
|
||||
description="Thành thạo các thao tác cơ bản của công cụ thiết kế UI chuyên nghiệp, quy trình làm việc từ thiết kế đến code"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 2: Xây dựng ứng dụng hiện đại đầu tiên của bạn - Thiết kế UI"
|
||||
description="Thiết kế giao diện ứng dụng web hiện đại từ đầu, thực hành các nguyên tắc thiết kế UI"
|
||||
href="/vi-vn/stage-2/frontend/ui-design/"
|
||||
title="Xây dựng ứng dụng hiện đại đầu tiên - Thiết kế UI"
|
||||
description="Học cơ bản về thiết kế UI cho ứng dụng hiện đại"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 3: Hướng dẫn thiết kế UI và UI đa sản phẩm"
|
||||
description="Tìm hiểu các hướng dẫn thiết kế UI hàng đầu để cải thiện tính nhất quán và thẩm mỹ của thiết kế sản phẩm"
|
||||
href="/vi-vn/stage-2/frontend/multi-product-ui/"
|
||||
title="Thiết kế trang và nút bấm theo quy chuẩn UI"
|
||||
description="Học các quy chuẩn thiết kế UI phổ biến, thiết kế phân cấp trang và nút bấm rõ ràng hơn"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Frontend 4: Hãy xây dựng chân dung Hogwarts"
|
||||
description="Dự án thực hành: Xây dựng ứng dụng chân dung Hogwarts tương tác sử dụng hình ảnh được tạo bởi AI"
|
||||
href="/vi-vn/stage-2/frontend/llm-skills-beautiful/"
|
||||
title="Làm cho giao diện đẹp hơn bằng LLM và Skills"
|
||||
description="Thực hành với prompt và plugin, để AI tạo ra giao diện đẹp và độc đáo"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/frontend/hogwarts-portraits/"
|
||||
title="Cùng làm Chân dung Hogwarts"
|
||||
description="Dự án thực hành: Kết hợp hình ảnh do AI tạo, xây dựng ứng dụng Chân dung Hogwarts tương tác"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/frontend/design-to-code/"
|
||||
title="Từ nguyên mẫu thiết kế đến code dự án"
|
||||
description="Học cách chuyển đổi nguyên mẫu từ công cụ thiết kế thành code frontend có thể chạy trên trình duyệt"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/frontend/modern-component-library/"
|
||||
title="Cập nhật giao diện với thư viện component hiện đại"
|
||||
description="Học sử dụng thư viện component để nhanh chóng xây dựng giao diện chuyên nghiệp"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
|
||||
### Backend và Full-Stack
|
||||
### Phát triển Backend
|
||||
|
||||
Học thiết kế API, quản lý cơ sở dữ liệu và chiến lược triển khai ứng dụng:
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 1: API là gì"
|
||||
description="Hiểu khái niệm cốt lõi của API, cầu nối giữa frontend và backend"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 2: Từ cơ sở dữ liệu đến Supabase"
|
||||
description="Thành thạo các nguyên tắc cơ bản của cơ sở dữ liệu quan hệ và học cách sử dụng Supabase, nền tảng BaaS hiện đại"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 3: Code giao diện được hỗ trợ bởi AI và tài liệu"
|
||||
description="Sử dụng AI để hỗ trợ tạo code giao diện backend và tài liệu API chuẩn"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 4: Quy trình làm việc Git"
|
||||
href="/vi-vn/stage-2/backend/git-workflow/"
|
||||
title="Học sử dụng Git và Github"
|
||||
description="Thành thạo các thao tác cốt lõi và quy trình làm việc cộng tác của hệ thống quản lý phiên bản Git"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 5: Triển khai Zeabur"
|
||||
description="Học cách triển khai nhanh các ứng dụng full-stack của bạn lên đám mây sử dụng Zeabur"
|
||||
href="/vi-vn/stage-2/backend/database-supabase/"
|
||||
title="Từ cơ sở dữ liệu đến Supabase"
|
||||
description="Thành thạo cơ bản về cơ sở dữ liệu quan hệ và học cách sử dụng Supabase, nền tảng BaaS hiện đại"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 6: Công cụ phát triển CLI hiện đại"
|
||||
description="Khám phá các công cụ CLI hiện đại để nâng cao trải nghiệm phát triển trong môi trường dòng lệnh"
|
||||
href="/vi-vn/stage-2/backend/ai-interface-code/"
|
||||
title="Thiết kế và phát triển API backend ứng dụng"
|
||||
description="Sử dụng AI hỗ trợ tạo code API backend và tài liệu API chuẩn, nâng cao hiệu suất phát triển"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Backend 7: Tích hợp hệ thống thanh toán Stripe"
|
||||
description="Thực hành: Tích hợp chức năng thanh toán Stripe vào ứng dụng của bạn để kiếm tiền"
|
||||
href="/vi-vn/stage-2/backend/zeabur-deployment/"
|
||||
title="Xuất bản nguyên mẫu sản phẩm của bạn"
|
||||
description="Học cách sử dụng Zeabur để nhanh chóng triển khai ứng dụng full-stack lên đám mây"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/backend/modern-cli/"
|
||||
title="Từ IDE đến công cụ lập trình AI CLI"
|
||||
description="Khám phá các công cụ CLI hiện đại, nâng cao trải nghiệm phát triển trong môi trường dòng lệnh"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/backend/stripe-payment/"
|
||||
title="Cách tích hợp hệ thống thanh toán Stripe"
|
||||
description="Thực hành: Tích hợp chức năng thanh toán Stripe vào ứng dụng của bạn, hiện thực hóa thương mại hóa"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### Bài tập lớn
|
||||
|
||||
### Bài tập
|
||||
Các chương trước là học "linh kiện", bài tập lớn mới là học "cách lắp linh kiện thành một sản phẩm có thể chạy, demo và đưa lên mạng".
|
||||
|
||||
Bạn nên làm theo thứ tự **Bài tập lớn 1 -> Bài tập lớn 2**:
|
||||
|
||||
- **Bài tập lớn 1** đưa bạn chạy qua đường dẫn chính phổ biến nhất của SaaS hiện đại: đăng nhập, tạo, cơ sở dữ liệu, thanh toán, trang quản lý.
|
||||
- **Bài tập lớn 2** đưa bạn vào kịch bản giống hệ thống doanh nghiệp hơn: quyền vai trò, ngân hàng đề, kỳ thi, lịch sử nộp bài, trang quản lý.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["Trang và component frontend"] --> B["Cơ sở dữ liệu và API"]
|
||||
B --> C["Bài tập lớn 1<br/>SaaS tạo văn bản"]
|
||||
C --> D["Thanh toán / Triển khai / Quản lý backend"]
|
||||
D --> E["Bài tập lớn 2<br/>Hệ thống thi trực tuyến"]
|
||||
E --> F["Portfolio full-stack hoàn chỉnh"]
|
||||
```
|
||||
|
||||
Nếu bạn chưa biết nên làm cái nào trước, có thể tham khảo bảng so sánh dưới đây:
|
||||
|
||||
| Dự án | Bạn sẽ thực hành kỹ năng gì | Phù hợp nhất với ai | Sản phẩm bàn giao cuối cùng |
|
||||
|------|------|------|------|
|
||||
| Bài tập lớn 1: Trang web tạo văn bản | Cấu trúc trang SaaS, đăng nhập người dùng, tạo bằng AI, thanh toán Stripe, quản lý backend | Người lần đầu làm trang web thương mại hóa hoàn chỉnh | Một nguyên mẫu SaaS có thể đăng ký, tạo, thanh toán và quản lý |
|
||||
| Bài tập lớn 2: Hệ thống thi và quản lý trực tuyến | Quyền vai trò, mô hình ngân hàng đề, quy trình thi, lịch sử nộp bài, chấm điểm và thống kê | Người muốn làm hoàn chỉnh một "hệ thống doanh nghiệp" | Một nền tảng thi có phía học sinh và phía quản lý |
|
||||
|
||||
Dù làm bài nào, bài tập lớn đều nên chuẩn bị ít nhất 3 sản phẩm bàn giao:
|
||||
|
||||
- Một kho lưu trữ dự án có thể chạy
|
||||
- Một liên kết demo có thể truy cập
|
||||
- Một README và một video demo
|
||||
|
||||
Củng cố kỹ năng phát triển full-stack của bạn thông qua các dự án thực hành:
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Bài tập 1: Xây dựng ứng dụng hiện đại đầu tiên của bạn - Full-Stack"
|
||||
description="Áp dụng toàn diện những gì bạn đã học để hoàn thành độc lập một ứng dụng full-stack hoàn toàn chức năng"
|
||||
href="/vi-vn/stage-2/assignments/copywriting-platform-supabase/"
|
||||
title="Bài tập lớn 1: Ứng dụng full-stack SaaS đầu tiên - Trang web tạo văn bản"
|
||||
description="Xây dựng từ con số không một bàn làm việc văn bản marketing AI, bao gồm đăng nhập, tạo, thanh toán, trang quản lý backend"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="Bài tập 2: Thư viện component frontend hiện đại + Trae"
|
||||
description="Sử dụng thư viện component hiện đại với Trae IDE để xây dựng hiệu quả các giao diện frontend phức tạp"
|
||||
href="/vi-vn/stage-2/assignments/exam-management-express/"
|
||||
title="Bài tập lớn 2: Hệ thống thi và quản lý trực tuyến"
|
||||
description="Xây dựng hệ thống thi trực tuyến, hỗ trợ tạo đề tự động, làm bài, quản lý backend"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
Nếu bạn đã hoàn thành hai dự án chính ở trên, hoặc muốn làm portfolio theo hướng kỹ thuật của riêng mình, có thể tiếp tục chọn một đề tài từ các đề tài mở rộng dưới đây:
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/assignments/modern-landing-page/"
|
||||
title="Bài tập mở rộng: Kỹ thuật landing page Web hiện đại"
|
||||
description="Thực hành diễn đạt giá trị, đường dẫn chuyển đổi, thiết kế CTA và cơ sở theo dõi cơ bản, làm một trang thực sự có thể tiếp nhận lưu lượng"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/assignments/custom-dify-agent-platform/"
|
||||
title="Bài tập mở rộng: Nền tảng编排 Agent thông minh kiểu Dify"
|
||||
description="Hiện thực hóa quản lý agent, hội thoại, nhật ký và kiểm soát quyền, làm một nền tảng AI tối giản có thể sử dụng"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/assignments/travel-planning-agent-platform/"
|
||||
title="Bài tập mở rộng: Nền tảng编排 Agent lập kế hoạch du lịch thông minh"
|
||||
description="Xoay quanh đầu vào có cấu trúc,编排 Agent và quản lý kế hoạch lịch sử, làm một sản phẩm lập kế hoạch du lịch AI có thể thực thi"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/assignments/movie-recommendation-springboot/"
|
||||
title="Bài tập mở rộng: Hệ thống đề xuất phim Spring Boot"
|
||||
description="Kết hợp Spring Boot, đánh giá收藏 và đề xuất có thể giải thích, hoàn thành một nguyên mẫu hệ thống đề xuất hoàn chỉnh"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/assignments/simple-grocery-microservices/"
|
||||
title="Bài tập mở rộng: Hệ thống microservices thương mại điện tử thực phẩm tươi"
|
||||
description="Thực hành tách service, chuyển tiếp gateway, phối hợp tồn kho và đơn hàng, trải nghiệm tư duy kỹ thuật từ đơn thể đến microservices"
|
||||
/>
|
||||
<NavCard
|
||||
href="/vi-vn/stage-2/assignments/traffic-data-visualization-go/"
|
||||
title="Bài tập mở rộng: Nền tảng phân tích và trực quan hóa dữ liệu giao thông Go"
|
||||
description="Từ tiếp nhận dữ liệu, tổng hợp cửa sổ đến dashboard xu hướng và cảnh báo, làm một nguyên mẫu sản phẩm dữ liệu hoàn chỉnh"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
### Mở rộng khả năng AI
|
||||
|
||||
<NavGrid>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="AI 1: Giới thiệu Dify và tích hợp cơ sở kiến thức"
|
||||
description="Học cách xây dựng ứng dụng AI sử dụng Dify và tích hợp các cơ sở kiến thức riêng tư"
|
||||
/>
|
||||
<NavCard
|
||||
href="#"
|
||||
title="AI 2: Tra cứu từ điển AI và tích hợp API đa phương thức"
|
||||
description="Khám phá thêm các khả năng AI, tích hợp các API đa phương thức như thị giác và giọng nói"
|
||||
href="/vi-vn/stage-2/ai-capabilities/dify-knowledge-base/"
|
||||
title="Giới thiệu Dify và tích hợp cơ sở kiến thức"
|
||||
description="Học cách sử dụng Dify để xây dựng ứng dụng AI và tích hợp cơ sở kiến thức riêng tư"
|
||||
/>
|
||||
</NavGrid>
|
||||
|
||||
|
||||
## Dành cho ai
|
||||
|
||||
- Nhà phát triển có một số nền tảng lập trình muốn học phát triển full-stack một cách có hệ thống
|
||||
- NgườI học muốn chuyển đổi từ quản lý sản phẩm sang kỹ sư full-stack
|
||||
- Nhà phát triển từ cơ bản đến trung cấp muốn thành thạo công cụ và quy trình làm việc phát triển hiện đại
|
||||
- Doanh nhân muốn phát triển các sản phẩm hoàn chỉnh độc lập
|
||||
- Nhà phát triển có nền tảng lập trình, muốn học phát triển full-stack một cách có hệ thống
|
||||
- Người học muốn chuyển đổi từ quản lý sản phẩm sang kỹ sư full-stack
|
||||
- Nhà phát triển từ cơ bản đến trung cấp muốn thành thạo công cụ và quy trình phát triển hiện đại
|
||||
- Doanh nhân muốn phát triển độc lập sản phẩm hoàn chỉnh
|
||||
|
||||
## Điều kiện tiên quyết
|
||||
|
||||
- Hoàn thành giai đoạn "NgườI mới và nguyên mẫu sản phẩm", hoặc có kiến thức cơ bản tương đương
|
||||
- Hoàn thành giai đoạn "Người mới và nguyên mẫu sản phẩm", hoặc có kiến thức cơ bản tương đương
|
||||
- Hiểu các khái niệm cơ bản về HTML/CSS/JavaScript
|
||||
- Có kiến thức sơ bộ về các công cụ lập trình AI
|
||||
|
||||
Sẵn sàng đi sâu vào phát triển full-stack? Nhấp vào điều hướng bên trái để bắt đầu học!
|
||||
Sẵn sàng đi sâu vào phát triển full-stack chưa? Nhấp vào điều hướng bên trái để bắt đầu học!
|
||||
|
||||
Reference in New Issue
Block a user