TL;DR

Prompting là kỹ năng có leverage cao nhất trong toàn bộ vibe coding stack. Công cụ hầu như không quan trọng nếu prompt của bạn mơ hồ. Một công cụ tầm trung với prompt xuất sắc sẽ vượt trội hơn công cụ xuất sắc với prompt mờ nhạt - mọi lần.

Tháng 3 bao gồm: cấu trúc prompt 4 phần, PRP Framework (kế hoạch trước khi prompt), llms.txt, Cursor Rules + CLAUDE.md, Spec-Driven Development, và 18 thực hành mà mọi expert vibe coder đều dùng.

Cấu trúc Prompt 4 phần

Sự khác biệt giữa prompt của người mới và người chuyên nghiệp hầu như hoàn toàn là về cấu trúc. Người mới nói: "Add a login page." Chuyên gia nói: "Create a login page in app/login/page.tsx using the existing Supabase auth client in lib/supabase.ts. Use the same form styling as app/signup/page.tsx. Include email/password fields, a submit button, and error handling for invalid credentials. Do not modify any other files."

Một cái tạo ra component hoạt động. Cái còn lại tạo ra thứ gì đó có thể hoạt động, có thể phá vỡ các file khác, và có thể đưa ra các pattern không nhất quán với phần còn lại của codebase.

Cấu trúc prompt 4 phần:

  • Goal - Chính xác thì điều này nên làm gì?

  • Context - Files nào liên quan? Những gì đã tồn tại?

  • Constraints - Những gì KHÔNG nên thay đổi? Pattern nào nên tuân theo?

  • Output format - Kết quả hoàn chỉnh trông như thế nào?

Tài nguyên:

PRP Framework - Lên kế hoạch trước khi Prompt

Nguyên nhân phổ biến nhất của doom loops là nhảy thẳng vào feature development mà không có kế hoạch nào. AI viết code, nó phá vỡ thứ gì đó, bạn yêu cầu sửa, nó phá vỡ thứ khác, và bạn xoáy vào vòng lặp.

Cách sửa rất đơn giản: viết kế hoạch trước khi viết bất kỳ dòng prompt nào cho code.

PRP Framework (Product Requirements Prompt): Trước khi mở công cụ vibe coding, trả lời 3 câu hỏi này trong một tài liệu:

  1. Điều này dành cho ai? (Target user, mức độ quen thuộc kỹ thuật của họ)

  2. Điều này giải quyết vấn đề gì? (Giá trị cốt lõi, trong một câu)

  3. Thành công trông như thế nào? (Tiêu chí cụ thể, có thể test được)

Sau đó đưa tài liệu của bạn cho Claude hoặc ChatGPT và yêu cầu nó expand thành Product Requirements Document (PRD) đầy đủ. PRD đó trở thành opening prompt của bạn trong Cursor hoặc Claude Code.

Thói quen một mình này tách biệt những người ship với những người doom-loop.

llms.txt - Tiêu chuẩn cho tài liệu AI-readable

Một trong những kỹ thuật ít được sử dụng nhất trong vibe coding là llms.txt - file markdown plain-text đặt ở root của bất kỳ library, framework, hoặc project nào, cung cấp cho AI tools chính xác context cần thiết để làm việc với nó đúng cách.

Vấn đề nó giải quyết: hầu hết tài liệu thư viện được viết cho con người và được tối ưu hóa cho browser. AI models gặp khó khăn với HTML, trang docs JavaScript-heavy, và navigation menus. llms.txt loại bỏ tất cả những thứ đó và cung cấp cho model một reference có cấu trúc rõ ràng, tập trung vào API phù hợp với context window.

Nơi các file llms.txt tồn tại: llmstxt.org - tiêu chuẩn chính thức, liệt kê tất cả các thư viện và framework đã publish llms.txt.

Ví dụ: https://docs.supabase.com/llms.txt - paste URL vào Claude Code, Cursor, hoặc ChatGPT và nói: "Read this first, then help me build with this library."

Cursor Rules và CLAUDE.md - Hướng dẫn vĩnh cửu cho AI

Cursor Rules và CLAUDE.md files là thực hành ít được sử dụng nhất và có ROI cao nhất trong vibe coding. Đây là các file instruction liên tục mà AI đọc vào đầu mỗi session. Chúng định nghĩa project, conventions, tech stack, và những gì AI không nên làm.

Setup Cursor hiện tại (2026): Cursor dùng thư mục .cursor/rules/ với các file .mdc riêng lẻ. Có 4 chế độ kích hoạt:

  • Always Apply - được load trong mọi conversation

  • Auto Attached (globs) - kích hoạt khi các file pattern phù hợp được tham chiếu

  • Agent Requested - AI quyết định khi nào áp dụng dựa trên mô tả task

  • Manual (@rule-name) - chỉ được load khi bạn tham chiếu rõ ràng trong prompt

Tài nguyên:

Spec-Driven Development - Bước tiến hóa chuyên nghiệp

Spec-Driven Development (SDD) là điều xảy ra khi vibe coding gặp các dự án thực và cần scale. Được JetBrains đặt tên chính thức trong khóa học DeepLearning.AI năm 2026, đây là kỷ luật định nghĩa hệ thống nên làm gì trước khi để bất kỳ agent nào viết code - thông qua các tài liệu đặc tả có cấu trúc được lưu trực tiếp trong repository.

Vibe coding gặp phải giới hạn vào khoảng tháng thứ 3 của một dự án. Model bắt đầu tạo ra code mâu thuẫn với các quyết định trước đó. Context tích lũy. Các pattern xung đột xuất hiện. Doom loop đến. SDD ngăn điều này bằng cách làm cho spec - không phải prompt - là source of truth.

Workflow SDD:

  1. Viết specification - trước khi có bất kỳ code nào, mô tả chính xác hành vi của hệ thống: inputs, outputs, edge cases, và constraints.

  2. Tạo requirements - đưa spec cho AI agent và yêu cầu tạo requirements document. Review và phê duyệt.

  3. Tạo design document - AI chuyển đổi requirements được phê duyệt thành kế hoạch kỹ thuật. Bạn review trước khi viết bất kỳ dòng code nào.

  4. Implement - AI viết code theo spec, không phải từ prompt mơ hồ.

  5. Tạo và chạy tests - vì spec định nghĩa inputs, outputs và edge cases rõ ràng, các test case tự tạo ra từ spec.

Tài nguyên:

18 thực hành của expert Vibe Coder

Những thực hành này đến trực tiếp từ cộng đồng r/ClaudeAI và r/PromptEngineering, được xác minh theo kinh nghiệm thực tế 2025-2026:

  1. Bắt đầu với vision chi tiết - viết đầy đủ trước khi mở bất kỳ công cụ nào

  2. Dùng Git và branch tự do - tạo branch mới cho mọi feature experiment

  3. Duy trì instructions folder - thư mục /docs hoặc /instructions với markdown files mô tả architecture

  4. Chia features thành phases - không bao giờ yêu cầu toàn bộ feature một lần; chia thành 3-5 prompts

  5. Mở chat mới khi context quá dài - conversation dài làm giảm chất lượng output

  6. Tham chiếu file cụ thể trong mọi prompt - nói với AI chính xác files nào cần nhìn

  7. Không áp đảo với context - chỉ đề cập những file liên quan nhất

  8. Tham chiếu components hiện có - khi yêu cầu component mới, link đến component hiện có làm style reference

  9. Dùng Gemini 3.5 Pro làm secondary reviewer - copy code được tạo ra và paste vào Gemini để kiểm tra security vulnerabilities

  10. Luôn validate và sanitize server-side - không bao giờ tin tưởng dữ liệu client-submitted

  11. Giữ secrets server-side - dùng environment variables, không bao giờ đặt API keys trong frontend code

  12. Xử lý errors rõ ràng - copy error messages từ console và paste cho AI

  13. Nếu fix thất bại 3 lần, xem lại prompt - không hỏi cùng một prompt hỏng 4 lần

  14. Yêu cầu AI thêm logs khi debug

  15. Rõ ràng về scope - thêm "Do not change anything I didn't ask for" vào mọi prompt

  16. Duy trì file "Common AI Mistakes" - ghi lại errors mà AI lặp lại

  17. Yêu cầu kế hoạch, không phải code - luôn lấy kế hoạch trước, phê duyệt, rồi mới implement

  18. Yêu cầu giải thích về code không quen - không chấp nhận code bạn hoàn toàn không thể đọc

Milestone tháng 3

Cuối tháng này, bạn nên có thể: viết prompt có cấu trúc tạo ra output nhất quán ngay lần đầu, dùng PRP framework để lên kế hoạch bất kỳ app nào trước khi build, setup Cursor Rules và CLAUDE.md cho mọi dự án, áp dụng 18 thực hành expert một cách tự nhiên, và duy trì file "Common AI Mistakes" đang hoạt động.

Kết

Tháng 3 là tháng chuyển đổi từ người dùng công cụ thành người làm chủ công cụ. Những kỹ năng ở đây - prompting có cấu trúc, lập kế hoạch trước khi implement, và spec-driven development - sẽ theo bạn suốt sự nghiệp.

Phần tiếp theo (P4) bao gồm tháng 4: xây dựng dự án thật, từ ý tưởng đến URL live, với các bài học về bảo mật và testing thực tế.