Bạn có một ý tưởng phần mềm nhưng chưa biết khách hàng có thật sự cần không? Nếu bắt đầu ngay bằng một dự án lớn, bạn có thể mất nhiều tuần trước khi nhận ra giả thuyết ban đầu chưa đúng.
Quy trình vibe coding tốt giúp bạn đi từ câu hỏi kinh doanh đến prototype có thể bấm thử trong phạm vi nhỏ. Mục tiêu không phải tạo một sản phẩm hoàn chỉnh bằng vài câu lệnh, mà là tạo đủ bằng chứng để quyết định nên giữ, sửa hay bỏ ý tưởng.
Tóm tắt nhanh
- Bước 1: viết giả thuyết kinh doanh có thể kiểm tra.
- Bước 2: chọn một user flow nhỏ và xác định người dùng.
- Bước 3: tạo dữ liệu mẫu cùng các trường hợp lỗi.
- Bước 4: viết brief có input, output, ràng buộc và acceptance criteria.
- Bước 5: dựng prototype trong môi trường cô lập.
- Bước 6: test theo kịch bản và ghi feedback có cấu trúc.
- Bước 7: quyết định build tiếp, thu nhỏ, chuyển giao hoặc dừng.
Quy trình vibe coding là gì?
Quy trình vibe coding là chuỗi bước biến một vấn đề kinh doanh thành prototype có phạm vi, dữ liệu, tiêu chí kiểm tra và decision gate rõ ràng. AI hỗ trợ tạo code, nhưng con người vẫn giữ quyền chọn vấn đề và đánh giá kết quả.
Không có quy trình, bạn rất dễ rơi vào vòng lặp “thêm một tính năng nữa”. Prototype phình to, prompt dài dần, lỗi khó truy ra và team không biết khi nào nên dừng.
Trong bài này, mình dùng ví dụ một dashboard ưu tiên lead. Bạn có thể thay bằng landing page, tool nội bộ, script báo cáo hoặc automation nhỏ; cấu trúc 7 bước vẫn giữ nguyên.
Bước 1: Viết giả thuyết kinh doanh
Hãy bắt đầu bằng điều bạn muốn học, không phải danh sách tính năng bạn muốn xây. Một giả thuyết tốt nói rõ ai gặp vấn đề gì, giải pháp thay đổi hành vi nào và bạn sẽ quan sát tín hiệu nào.
Ví dụ yếu: “Tạo một CRM mini cho đội sales”. Câu này quá rộng, khiến AI và team phải đoán cả user, dữ liệu, quy trình và tiêu chí thành công.
Ví dụ tốt hơn: “Nếu sales có bảng ưu tiên lead dựa trên ngân sách, nguồn và thời gian gửi form, họ sẽ chọn đúng nhóm cần gọi trước trong buổi sáng”. Câu này có thể kiểm tra bằng dữ liệu mẫu và một buổi dùng thử.
Bạn có thể dùng mẫu:
- Người dùng: ai sẽ dùng prototype?
- Nỗi đau: bước nào đang chậm, lặp hoặc dễ sai?
- Giả thuyết: thay đổi nào có thể cải thiện workflow?
- Tín hiệu: bạn sẽ quan sát hành vi hoặc kết quả nào?
- Giới hạn: điều gì chưa cần làm trong vòng thử nghiệm?
Bước 2: Chọn một user flow nhỏ
Prototype đầu tiên chỉ nên giải quyết một luồng chính từ input đến output. Đừng cố dựng toàn bộ sản phẩm, tài khoản, thông báo, báo cáo và phân quyền trong cùng một vòng lặp.
Với dashboard lead, flow đầu tiên có thể là: tải CSV mẫu → xem danh sách → lọc theo nguồn → mở lý do ưu tiên. Những việc như đồng bộ CRM, gửi email tự động và phân quyền có thể để backlog.
Hãy viết flow thành các bước mà người dùng thực sự làm. Nếu một bước không giúp trả lời giả thuyết, tạm thời bỏ nó. Cách này giúp prompt ngắn hơn và giúp bạn phát hiện sớm phần nào cần người có chuyên môn kỹ thuật.
Bước 3: Chuẩn bị dữ liệu mẫu
Dữ liệu mẫu phải đủ giống tình huống thật để test logic, nhưng không chứa thông tin nhạy cảm. Đây là bước nhiều người bỏ qua vì muốn thấy giao diện nhanh, nhưng dữ liệu kém sẽ tạo cảm giác prototype tốt hơn thực tế.
Với bảng lead, bạn có thể chuẩn bị các cột: tên công ty giả, nguồn lead, quy mô, ngân sách giả, ngày gửi form, trạng thái và ghi chú. Hãy cố ý thêm dòng thiếu ngân sách, trùng email, ngày sai định dạng và nguồn không xác định.
Không paste API key, thông tin khách hàng, dữ liệu tài chính hoặc nội dung bí mật vào công cụ AI. Hướng dẫn OWASP GenAI Data Security Risks & Mitigations 2026 xem việc kiểm soát dữ liệu, quyền truy cập và traceability là phần quan trọng của quản trị GenAI [1].
Trong file dữ liệu mẫu, bạn nên ghi rõ:
- Trường nào bắt buộc?
- Giá trị hợp lệ là gì?
- Thiếu dữ liệu thì báo lỗi hay bỏ qua?
- Dòng trùng được xử lý thế nào?
- Ai được xem hoặc tải file?
Bước 4: Viết brief cho AI
Brief tốt giúp AI hiểu mục tiêu, ràng buộc và cách bạn đánh giá kết quả. Đừng chỉ viết “hãy làm một dashboard đẹp”; hãy mô tả người dùng, input, output và trạng thái lỗi.
Mục tiêu: tạo prototype dashboard ưu tiên lead. Người dùng: sales manager. Input: CSV mẫu gồm company, source, budget, submitted_at, status. Logic: ưu tiên lead có budget cao hơn, nguồn rõ và ngày gửi gần hơn. Output: bảng lead, điểm ưu tiên và lý do giải thích được. Ràng buộc: chỉ dùng dữ liệu mẫu, không gọi API thật, không lưu secret. Lỗi cần xử lý: thiếu cột, sai kiểu ngày, dòng trùng và file rỗng. Acceptance criteria: import được file mẫu, báo lỗi rõ, điểm số nhất quán và có thể reset dữ liệu. Ngoài phạm vi: login, đồng bộ CRM, email tự động và payment.
Acceptance criteria là điều kiện để stakeholder chấp nhận sản phẩm hoặc user story hoàn tất, theo tài liệu Cucumber cập nhật tháng 7/2026 [2]. Việc viết tiêu chí trước khi prompt giúp bạn kiểm tra output bằng hành vi cụ thể thay vì cảm giác “trông có vẻ đúng”.
Bước 5: Dựng prototype trong môi trường cô lập
Hãy dựng prototype bằng dữ liệu mẫu trong môi trường cục bộ hoặc staging, tách khỏi database và tài khoản production. Môi trường cô lập cho phép bạn thử sai, reset và xóa bản nháp mà không gây hậu quả cho hoạt động thật.
Ở vòng đầu, hãy yêu cầu AI tạo ít phần nhất có thể: một màn hình, một luồng chính và một bộ dữ liệu cố định. Sau mỗi thay đổi, chạy lại một test nhỏ và ghi nhận điều gì đã thay đổi.
Không nên kết nối ngay payment, CRM hoặc email thật. Nếu cần mô phỏng tích hợp, hãy tạo mock response hoặc file mẫu. Khi prototype đã chứng minh được giá trị, developer mới đánh giá kiến trúc, secret management, phân quyền, logging và kế hoạch deploy.
Bài GitHub Actions CI/CD cho website có thể dùng làm tài liệu nối tiếp khi bạn chuyển từ prototype sang staging có kiểm thử và rollback.
Bước 6: Test và lấy feedback có cấu trúc
Test prototype bằng kịch bản thực tế, gồm cả dữ liệu đúng, dữ liệu sai và thao tác ngoài dự kiến. Một người tạo prototype tự bấm thử thường bỏ sót những lỗi người dùng mới gặp.
- Tải một file hợp lệ và kiểm tra output.
- Tải file thiếu cột bắt buộc.
- Tải file rỗng hoặc có dòng trùng.
- Nhập giá trị sai kiểu và ký tự đặc biệt.
- Reset hoặc tải lại trang giữa chừng.
- Nhờ một người chưa xem brief hoàn thành flow.
Ghi feedback theo ba cột: quan sát, ảnh hưởng và hành động. Ví dụ: “Người dùng không hiểu điểm 82 nghĩa là gì” → “không tin bảng ưu tiên” → “hiển thị lý do và thêm ngưỡng giải thích”. Đừng biến mọi ý kiến thành một feature ngay lập tức.
Nghiên cứu về code review trong thời đại AI lưu ý rằng code được tạo nhanh hơn sẽ làm tăng khối lượng cần xác minh; review nên tập trung vào requirement, logic và rủi ro chứ không chỉ formatting [3]. Điều này cũng đúng khi bạn test prototype: hãy kiểm tra nó có trả lời đúng câu hỏi ban đầu không.
Bước 7: Ra quyết định build tiếp
Vòng prototype phải kết thúc bằng quyết định: dừng, thu nhỏ, lặp lại hoặc chuyển sang build có kiểm soát. Nếu chỉ tiếp tục thêm code, bạn chưa thật sự kiểm chứng ý tưởng.
| Tín hiệu | Quyết định | Việc tiếp theo |
|---|---|---|
| Người dùng không hoàn thành flow | Dừng hoặc đổi giả thuyết | Phỏng vấn lại và xác định pain point |
| Flow có giá trị nhưng quá rộng | Thu nhỏ | Giữ một user và một output |
| Prototype trả lời được câu hỏi | Lặp một vòng có mục tiêu | Sửa lỗi ảnh hưởng trực tiếp đến quyết định |
| Cần dữ liệu thật hoặc tích hợp | Chuyển giao kỹ thuật | Review security, architecture, test và ownership |
| Sản phẩm ảnh hưởng tiền hoặc quyền | Không tự đưa production | Lập quality gate và kế hoạch vận hành |
Một nghiên cứu enterprise tháng 7/2026 ghi nhận throughput AI có thể tăng mạnh, nhưng merge rate và revert rate không tự chứng minh business value [4]. Vì vậy, metric của prototype nên là tốc độ học và chất lượng quyết định, không phải số file hoặc số pull request.
Nếu prototype được giữ lại, hãy đóng gói nó thành brief bàn giao: mục tiêu, user flow, dữ liệu, acceptance criteria, feedback, rủi ro, phần ngoài phạm vi và quyết định đã chốt. Đây là tài liệu có giá trị hơn một thư mục code mà không ai hiểu.
Bạn đang đọc bài viết thuộc chuyên mục Lập trình của VietnamTutor. Nếu muốn chọn use case phù hợp trước khi bắt đầu, hãy đọc bài vibe coding cho doanh nghiệp.
Hãy bắt đầu với một workflow nhỏ trong tuần này: một file dữ liệu mẫu, một user flow và một tiêu chí pass rõ. Đừng lo nếu prototype đầu tiên bị bỏ; biết sớm một ý tưởng không đáng build cũng là một kết quả tốt.
Nguồn tham khảo
- OWASP GenAI Data Security Risks & Mitigations 2026
- Cucumber: User Story và Acceptance Criteria, 03/07/2026
- arXiv 2605.17548: Rethinking Code Review in the Age of AI
- arXiv 2607.01904: AI Writes Faster Than Humans Can Review
- WeWeb: Enterprise Requirements for Vibe Coding, 30/06/2026
Các câu hỏi thường gặp
Quy trình vibe coding gồm mấy bước?
Quy trình trong bài gồm 7 bước: viết giả thuyết, chọn user flow, chuẩn bị dữ liệu mẫu, viết brief, dựng prototype cô lập, test lấy feedback và ra quyết định build tiếp.
Bước nào quan trọng nhất khi vibe coding?
Không có một bước duy nhất, nhưng giả thuyết, phạm vi và acceptance criteria quyết định prototype có trả lời được câu hỏi kinh doanh hay không.
Có nên đưa dữ liệu thật vào prototype không?
Không nên ở vòng đầu. Hãy dùng dữ liệu giả hoặc đã ẩn danh, chạy trong môi trường cô lập và chỉ kết nối dữ liệu thật sau khi có review bảo mật và quyền truy cập.
Acceptance criteria dùng để làm gì?
Acceptance criteria mô tả điều kiện để stakeholder chấp nhận output. Nó giúp bạn test prototype bằng hành vi cụ thể thay vì đánh giá theo cảm giác giao diện đẹp hay code nhiều.
Khi nào nên dừng prototype?
Nên dừng khi người dùng không hoàn thành flow, giả thuyết không còn đúng, chi phí mở rộng vượt lợi ích hoặc prototype không tạo thêm thông tin để ra quyết định.
