Vibe code như nào cho đúng? Quy trình thực chiến từ một dự án thật
Mục lục
Mục lục
Tối qua ngồi lướt mạng, thấy một bạn đăng bài khoe “3 ngày build xong SaaS bằng AI”.
Tôi bấm vào xem. Code lộn xộn, không có kiến trúc, hardcode tùm lum, UI thì copy y chang template. Bạn ấy gọi đó là Vibe code.
NHƯNG? Vibe code thật sự là gì?
Là bạn ngồi gõ prompt rồi AI phun ra code, rồi bạn copy paste vào dự án, rồi cầu nguyện nó chạy?
Không. Cái đó gọi là cầu may.
Vibe code đúng nghĩa là bạn vẫn phải hiểu mình đang làm gì, chỉ là bạn dùng AI để tăng tốc quá trình đó lên gấp nhiều lần. Bạn vẫn cần suy nghĩ, vẫn cần phân tích, vẫn cần review. AI chỉ là phụ giúp.
Tôi vừa hoàn thành t5edu.site bằng Vibe code. Từ lúc bắt đầu tới MVP mất khoảng 1.5 ngày. Không phải vì AI quá giỏi, mà vì tôi có một quy trình rõ ràng.
Bài viết này là toàn bộ quy trình đó.
Công cụ tôi dùng
IDE
Antigravity. Không phải vì nó miễn phí, mà vì nó cho phép dùng nhiều model khác nhau trong cùng một workspace.
Tài khoản thì tôi dùng Google Pro, xoay vòng 10 account. Nghe hơi xàm nhưng quota nó giới hạn, phải xoay thôi.
Model nào làm gì
Đây là phần quan trọng. Không phải model nào cũng làm tốt mọi thứ.
Gemini 3.1 PRO (High) dùng cho brainstorm, lên plan, research. Nói chung là tất cả những gì KHÔNG PHẢI CODE. Model này nghĩ rất tốt, phân tích rất sâu, nhưng code thì lúc được lúc không.
Claude Opus 4.6 (Thinking) dùng cho coding. Nhận plan từ Gemini, rồi code theo plan đó. Model này code chuẩn chỉnh hơn hẳn, hiểu context tốt, ít bịa hàm.
Tách riêng vai trò như vậy là bài học xương máu. Trước tôi dùng một model cho tất cả, kết quả là plan thì sơ sài, code thì lú, debug thì vòng vòng.
Kit command
Tôi dùng Antigravity Kit (Github) để tạo ra các command tự động hóa workflow.
3 command chính:
-
/brainstorm: Cung cấp context cho cuộc hội thoại, detect issue, chọn issue để lên plan xử lý. Chạy bằng Gemini. -
/plan: Tạo plan code chi tiết, chỉnh sửa cho đúng hướng. Cũng chạy bằng Gemini. -
/create [FILE_PLAN]: Code theo plan, tự test, tự detect issue, tự fix hoặc báo lại. Chạy bằng Claude Opus.
Nghe đơn giản nhưng đây là xương sống của toàn bộ quy trình. Thiếu một trong ba cái này, mọi thứ sẽ loạn.
Plugin hỗ trợ design
Taste: Bộ skill giúp AI sáng tạo theme, layout mà không bị cái vibe “AI tạo ra” quá rõ ràng.
ui-ux-pro-max: Dùng python để generate bảng màu, requirement phù hợp với vibe dự án.
Quy trình Vibe code cho dự án mới
Đây mới là phần chính. Đọc kỹ, vì sai ở bước nào thì bước sau sẽ lệch hết.
Bước 1: Draft “linh hồn” dự án
Trước khi gõ bất kỳ dòng code nào, bạn phải trả lời được một loạt câu hỏi.
Techstack gì? Framework nào? Database nào? Đăng nhập bằng gì, đăng nhập xong thì user đi đâu? Dự án là tool, LMS, CRM hay SaaS? Có bao nhiêu màn hình, mỗi màn hình làm gì? Giao diện ưu tiên mobile hay desktop? Có trang admin không, admin có những gì?
Và quan trọng nhất, phải tách rõ 3 thứ:
Tính năng nào là ĐẶC BIỆT NHẤT? Tính năng nào là TÍNH NĂNG CHÍNH? Tính năng nào CẦN LÀM TRƯỚC?
Ba thứ này khác nhau hoàn toàn.
Viết hết ra thành một file soul.md. Nhờ AI format lại cho dễ đọc, nhưng bắt buộc giữ nguyên 100% nội dung, không thêm không bớt.
Bước 2: Phân tích MVP
Đây là chỗ nhiều người sai nhất.
Tính năng đặc biệt nhất CHƯA CHẮC là tính năng chính. Tính năng chính CHƯA CHẮC là thứ cần làm đầu tiên.
Ví dụ thực tế từ t5edu.site: Tính năng đặc biệt nhất là tự động thanh toán. Nhưng đó không phải tính năng chính. Tính năng chính là tạo khóa học, bài học, bài tập, làm bài và admin chấm điểm. Còn tính năng cần làm đầu tiên? Đăng nhập, render giao diện, viết API cho CRUD khóa học. Vì không có data khóa học thì mấy cái kia đều vô nghĩa.
Tính năng làm đầu tiên phải là tính năng cung cấp data cho các tính năng đặc biệt và tính năng chính.
Từ đó, liệt kê ra toàn bộ các bước cần làm theo thứ tự. Ví dụ:
- Làm tính năng đăng nhập Google
- Làm API CRUD khóa học
- Làm giao diện CRUD, filter khóa học
- Làm API CRUD bài học, bài tập
- Làm giao diện CRUD bài học, bài tập
Viết thành file MVP.md.
Bước 3: Khởi tạo base dự án
-
Dùng CLI tạo dự án theo framework đã chọn. Copy
soul.mdvàoREADME.md, copyMVP.mdvào dự án. -
Khởi tạo Kit:
npx @vudovn/ag-kit init
- Nhờ AI tạo
AGENTS.md, file này là “bộ não” của AI trong dự án. Chuyển sang model Claude Sonet 4.6 rồi chạy prompt này:
/brainstorm @README.md @MVP.md
Dựa vào README của dự án, khởi tạo AGENTS.md gồm
- Context
- Techstack
- Architecture Rules
+ Layered Architecture
+ ORM Specifics
+ OAuth Specifics
+ UI liblary Specifics
+ Store Global Frontend Specifics
- Directory Structure
- Database Models
+ Enum
+ Models...
+ Conventions Models
- Business Logic Summary
- Environment Variables
- MVP Scope
IMPORTANT RULE: Luôn luôn UPDATE STATUS vào TODO.md ngay sau khi làm xong
- Chuyển sang Claude Opus 4.6 để tạo
TODO.mdchi tiết:
Dựa vào @README.md @MVP.md @AGENTS.md
Khởi tạo TODO.md CHI TIẾT với format Task TODO List:
- Init dự án
- MVP
- Next Feature,...
- Tìm và tạo ENV, điền các key, install các package cần thiết.
Bước 4: Khởi tạo DESIGN.md
Đây là phần nhiều người bỏ qua. Nhưng nếu không có design system rõ ràng, AI sẽ tự chế UI theo kiểu của nó, mỗi lần mỗi khác.
- Chuyển sang Gemini, cho AI phân tích thương hiệu:
/brainstorm
@AGENTS.md
@README.md
Đọc và phân tích thương hiệu, tóm tắt 1 câu mô tả đầy đủ dự án
- Vẫn Gemini, dùng plugin ui-ux-pro-max để generate theme:
/ui-ux-pro-max @README.md @AGENTS.md
- Clone Taste về:
git clone https://github.com/Leonxlnx/taste-skill.git .agent/.shared/taste
rm -rf .agent/.shared/taste/.git
- Vẫn Gemini, tạo
DESIGN.md. Phần prompt dưới đây nhớ custom lại cho phù hợp dự án của bạn:
Create DESIGN.md cho dự án này với framework design: @taste
Toàn bộ component custom mà dùng chung thì cần được tách thành components
Toàn bộ data theme, css, style dùng chung cũng phải tách ra ở globals.css, types, store, hooks
DESIGN.md place ở root để phân tích và đặc tả chi tiết toàn bộ về design
Đừng dùng y nguyên cái AI generate ra. Nhớ custom lại.
Bước 5: Setup base trước khi code
-
Đọc lại toàn bộ TODO, README, AGENTS, DESIGN. Sửa lại cho chuẩn chỉnh.
-
Tạo một conversation chat mới hoàn toàn. Đừng dùng lại conversation cũ vì context sẽ bị nhiễu.
-
Chuyển sang Gemini, brainstorm trước:
/brainstorm @README.md @MVP.md @TODO.md @DESIGN.md
Phân tích dự án, tìm hiểu các tính năng, phân tích base dự án bao gồm những gì
- Vẫn Gemini, lên plan:
/plan @AGENTS Dựa vào brainstorm, create plan chi tiết để setup base dự án
- Chuyển sang Claude Opus 4.6, code:
/create @docs/PATH_TO_PLAN_SETUP_BASE
UPDATE @TODO.md sau khi làm xong
Nếu có kiến thức mới, UPDATE vào @AGENTS.md
- Review toàn bộ.
Tôi nhấn mạnh lại: AI SETUP BASE RẤT DỞ. Bắt buộc phải review cực kỳ kỹ. Nếu không, fail dự án 100%. Đây không phải nói quá, đây là kinh nghiệm thực tế.
Bước 6: Vòng lặp chính
Sau khi base ổn, mỗi tính năng mới đều chạy theo một vòng lặp:
-
Đọc, sửa lại TODO, README, AGENTS, DESIGN cho chuẩn.
-
Tạo conversation chat mới.
-
Chuyển sang Gemini, brainstorm tính năng:
/brainstorm @README.md @MVP.md @TODO.md @DESIGN.md
Phân tích tính năng [VIẾT TÍNH NĂNG CẦN LÀM VÀO ĐÂY]
- Vẫn Gemini, lên plan:
/plan @AGENTS Dựa vào brainstorm, create plan chi tiết để [VIẾT TÍNH NĂNG CẦN LÀM VÀO ĐÂY]
- Chuyển sang Claude Opus 4.6, code:
/create @docs/PATH_TO_CODE
UPDATE @TODO.md sau khi làm xong
Nếu có kiến thức mới, UPDATE vào @AGENTS.md
-
Test toàn bộ flow bằng tay, check code, sửa những đoạn AI lú.
-
Xong hết TODO thì quay lại check, thêm TODO mới rồi mới làm tiếp.
Không được làm tính năng nào không có trong TODO. Nghe cứng nhắc nhưng đây là cách duy nhất để kiểm soát được dự án khi dùng AI code.
Lưu ý kẻo toang
Sau mấy dự án Vibe code, tôi đúc kết được 5 điều mà nếu bỏ qua thì sẽ khổ:
1. AI không handle được 100% lỗi. Bạn phải tự debug, tìm ra root cause, mô tả chi tiết issue cho AI. Đừng chỉ paste log rồi nói “sửa đi”. AI cần biết lỗi ở đâu, tại sao, ảnh hưởng gì.
2. Lỗi UI phải mô tả cực kỳ chi tiết. AI bây giờ test frontend vẫn kém. Muốn AI sửa đúng thì phải nói rõ: element nào, ở đâu, đang hiển thị sao, muốn hiển thị sao.
3. Context window là tài nguyên quý. Mỗi lần nạp AGENTS, TODO, README rồi chat, thinking, debug liên tục thì tốn context rất nhanh. Biết tiết kiệm context thì dùng AI hiệu quả hơn nhiều.
4. Luôn check code khi AI tạo hoặc gọi hàm. AI có thể quên vị trí hàm cũ rồi hardcode hoặc khởi tạo function mới. Cái này debug sau thì muốn khóc.
5. Luôn reference file code, tên function, service, component khi giao việc cho AI. Giúp AI code chuẩn hơn, dùng đúng hàm đã có thay vì tự bịa ra cái mới.
Vibe code cho dự án đã có
Ngoài 5 điều trên, dự án đã có thì thêm vài thứ nữa.
Nếu chưa dùng ag-kit thì khởi tạo. Brainstorm phải chi tiết hơn, và bắt buộc chính bạn phải hiểu source code. Nếu bạn không hiểu code hiện tại thì AI cũng không thể giúp bạn code đúng.
Plan phải viết chi tiết hơn nữa. Reference đầy đủ. Review cực kỹ.
Mỗi lần xong một đợt code, check lại code conventions, check lại tính năng và vùng ảnh hưởng.
Và điều quan trọng nhất: chính bạn cũng phải hiểu cách setup, chạy dự án, code được và hiểu được những phần cần code. AI chỉ phụ giúp. Bộ não lớn nhất vẫn là của con người.
Kết bài
AI không thay thế được tư duy. Nó thay thế được thời gian gõ phím.
Người biết Vibe code đúng cách không phải người chỉ gõ prompt, mà là người hiểu dự án sâu nhất.
Chúc các bạn tìm được quy trình phù hợp với mình, build được những sản phẩm mà mình tự hào, và luôn nhớ rằng mỗi dự án hoàn thành đều là một bước tiến trên hành trình phát triển sự nghiệp.
Hẹn gặp lại ở bài viết sau.