Bạn đã bao giờ thấy trong quá trình phát triển Vibe Coding, mã do AI tạo ra đầy rẫy các lỗ hổng logic, khiến bạn nghi ngờ nhân sinh khi sửa nó chưa?
Trong phát triển truyền thống, Spec là công lý. Nhưng khi cộng tác với AI, chúng ta giống “đạo diễn” hơn.
Để khiến diễn viên AI tài năng nhưng đôi khi “điên rồ” đó diễn một vở kịch hay, bạn cần hai công cụ mạnh mẽ: EARS (Logic kịch bản) và BDD (Ảnh tĩnh chấp nhận).
EARS: Biến yêu cầu thành “Khối logic”
Bạn chắc chắn đã gặp kiểu PM này, viết yêu cầu như: “Hệ thống cần dễ sử dụng hơn”, “Tốc độ xử lý cần nhanh”. Đây là thảm họa khi viết mã.
EARS (Easy Approach to Requirements Syntax) nói một cách đơn giản là chuyển đổi những “tính từ mơ hồ” này thành “mệnh lệnh chính xác”.
EARS giống như Prompt Engineering hàng đầu, buộc bạn phải nói bằng logic đóng. 5 mẫu câu chính cho phép bạn “khóa” ranh giới yêu cầu bất cứ lúc nào:
| Loại | Mô tả |
|---|---|
| Ubiquitous (Phổ biến) | Hệ thống phải... (Như hơi thở, phải tuân theo mọi lúc). |
| Event-driven (Hướng sự kiện) | Khi [sự kiện xảy ra], hệ thống phải.... |
| Unwanted Behavior (Hành vi không mong muốn) | Nếu [điều xấu xảy ra], hệ thống phải... (Đây là linh hồn của Xử lý lỗi). |
| State-driven (Hướng trạng thái) | Khi [ở trạng thái cụ thể], hệ thống phải.... |
| Optional Feature (Tính năng tùy chọn) | Nơi [tính năng được bao gồm], hệ thống phải.... |
EARS giúp bạn thiết lập các quy tắc nghiêm ngặt
Khiến AI không thể “nói nhảm với vẻ mặt nghiêm túc” về mặt logic.
BDD: Biến kiểm thử thành “Kịch bản phim”
Nếu EARS là một hợp đồng nghiêm ngặt, thì BDD (Behavior Driven Development) là một “câu chuyện có da có thịt”. Nó không kiểm tra a == b, nó kiểm tra “người dùng cảm thấy điều gì đã xảy ra”.
Cú pháp được sử dụng bởi BDD được gọi là Gherkin (Dưa chuột muối, phải giòn và sảng khoái!), và bộ ba cốt lõi như sau:
| Cú pháp | Mô tả |
|---|---|
| 🎬 Given (Bối cảnh) | Thiết lập cảnh trước khi quay (ví dụ: Có 100 đô la trong túi). |
| ⚡ When (Hành động) | Khoảnh khắc đạo diễn hô Action (ví dụ: Đã gọi món mực siêu cay). |
| ✅ Then (Kết quả) | Kết thúc khán giả nhìn thấy (ví dụ: Nhận được mực thơm lừng, ví giảm 60 đô la). |
Thông qua phương pháp “kể chuyện” này, ngay cả những người không phải kỹ sư cũng có thể giao tiếp với chúng ta, và AI cũng có thể hiểu ý định thực sự của bạn qua những “ví dụ thực tế” này.
Sự khác biệt giữa EARS vs BDD là gì?
Hai thứ này thực hiện nhiệm vụ riêng của chúng, và việc kết hợp chúng thực sự là “vô địch”.
| Tính năng | EARS (Cú pháp yêu cầu) | BDD (Hướng hành vi) |
|---|---|---|
| Tinh thần cốt lõi | Định nghĩa chính xác (Loại bỏ sự mơ hồ) | Đồng thuận & Xác minh (Kể chuyện) |
| Giống như viết… | Điều khoản pháp lý | Kịch bản phim |
| Khán giả chính | PM, Kiến trúc sư, Người tạo quy tắc | Kỹ sư, QA, Trợ lý AI |
| Giải quyết nỗi đau | “Cái bạn làm không phải là cái tôi nghĩ!” | “Logic đúng, nhưng không dùng được!” |
Nói đơn giản: EARS giúp bạn thiết lập quy tắc, BDD giúp bạn xác minh kết quả.
Ứng dụng nâng cao EARS: Vibe Coding trong thực tế
Chúng tôi nhồi trực tiếp các quy tắc EARS và kịch bản BDD vào Prompt để AI phát triển.
Bạn có thể thử đưa ra hướng dẫn như thế này khi phát triển “Trừ tiền ví điện tử”:
# Nhiệm vụ: Hãy giúp tôi triển khai API trừ tiền
## Logic EARS (Vui lòng tuân thủ nghiêm ngặt):
- [Event-driven]: Khi nhận được yêu cầu, phải xác minh số dư.
- [Unwanted]: Nếu số dư không đủ, trả về mã lỗi 400 'INSUFFICIENT_FUNDS'.
- [State-driven]: Khi ví ở trạng thái 'Frozen', từ chối tất cả các khoản trừ.
## Kịch bản chấp nhận BDD (Để kiểm thử Jest):
Scenario: Trừ tiền thất bại do không đủ số dư
Given Số dư người dùng là 50 đô la
When Nhận yêu cầu trừ 100 đô la
Then API nên trả về HTTP 400
And Mã lỗi nên là 'INSUFFICIENT_FUNDS'
Thử ném cái này cho AI, và Code được tạo ra sẽ không lệch quá xa mục tiêu!
Kết luận
Cho dù trong phát triển hàng ngày hay Vibe Coding, EARS và BDD là những tạo tác để nâng cao hiệu quả.
EARS giúp bạn thiết lập các quy tắc nghiêm ngặt, BDD giúp bạn xác nhận kết quả diễn xuất.