Phát Triển Dựa Trên Đặc Tả (SDD): Giải Pháp Cho Mã AI Chuẩn Sản Xuất Không Còn "Vibe Coding"

Phát Triển Dựa Trên Đặc Tả (SDD): Giải Pháp Cho Mã AI Chuẩn Sản Xuất Không Còn "Vibe Coding"

AI ngày càng được ứng dụng rộng rãi trong hỗ trợ viết mã, tuy nhiên phương pháp "vibe coding" – tức là nhập lệnh tự nhiên cho AI và áp dụng ngay lập tức – chỉ phù hợp cho các prototype nhỏ. Với dự án thực tế quy mô lớn, nhiều file và công nghệ phức tạp, phương pháp này dẫn đến việc AI sinh ra mã không đồng nhất, có lỗi bảo mật và phá vỡ cấu trúc dự án.

Phát triển Dựa Trên Đặc Tả (Specification-Driven Development – SDD) là một quy trình rõ ràng gồm 4 giai đoạn (đặc tả yêu cầu, thiết kế, phân chia tác vụ, triển khai theo TDD) nhằm cung cấp đủ bối cảnh và giới hạn cho AI. Nhờ vậy, mã sinh ra có thể chạy ổn định trên môi trường sản xuất, giảm 60-80% lỗi phát sinh so với kiểu phát triển theo cảm tính.

Tại sao "Vibe Coding" lại thất bại?

"Vibe coding" hoạt động tốt trên những dự án mới, đơn giản nhưng lại không thích hợp với nền tảng mã phức tạp sản xuất thực tế vì 4 lý do chính:

• Bỏng rụi bối cảnh (Context Collapse): AI mỗi lần chạy không nhớ được đặc thù dự án như quy ước đặt tên, cấu trúc dữ liệu hay các lớp tùy chỉnh, dẫn đến tạo ra mã theo mẫu chung không phù hợp, gây ra lệch pha về kiến trúc.

• Thiên vị đường mòn (Happy Path Bias): AI thường sinh mã xử lý các tình huống lý tưởng, bỏ qua các lỗi như timeout mạng, điều kiện tranh chấp, lỗi validate đầu vào hay giới hạn tần suất API, dễ gây lỗi bảo mật.

• Thiếu sở hữu (Ownership Void): Người phát triển không hiểu sâu về mã do AI viết, dẫn đến khó khăn khi sửa lỗi hay mở rộng, đặc biệt trong các sự cố khẩn cấp.

• Nợ kỹ thuật tích tụ (Compounding Technical Debt): Mỗi lần AI viết mã theo kiểu riêng không thống nhất, kích thích việc nợ kỹ thuật gia tăng theo cấp số nhân, gây hỗn loạn cho hệ thống.

Quy trình 4 giai đoạn của SDD

Thay vì "gõ prompt — xuất code", SDD đề xuất vòng lặp 4 bước, mỗi bước sinh ra tài liệu tham chiếu rõ ràng giúp AI có đủ bối cảnh:

Giai đoạn 1: YÊU CẦU → requirements.md  
Giai đoạn 2: THIẾT KẾ → design.md  
Giai đoạn 3: PHÂN CÔNG → tasks.md  
Giai đoạn 4: TRIỂN KHAI → mã nguồn + bài kiểm tra
                          ↓
                     Phản hồi và lặp lại

Giai đoạn 1: Đặc Tả Yêu Cầu

Trước khi bắt đầu viết code, AI được yêu cầu tổng hợp các user story, tính năng ngoại lệ, yêu cầu bảo mật, điểm tích hợp với hệ thống hiện tại, đồng thời liệt kê rõ ràng giới hạn (cái gì sẽ không làm). Tài liệu requirements.md trở thành "nguồn chân lý" nhất quán cho cả đội.

Giai đoạn 2: Thiết Kế Kiến Trúc

AI chuyển đặc tả thành những quyết định kỹ thuật cụ thể như thay đổi schema cơ sở dữ liệu, API endpoint, kiến trúc tầng dịch vụ và chiến lược xử lý lỗi. Và lúc này vẫn chưa viết code, chỉ thiết kế để đảm bảo đồng bộ và hợp lý, tránh sửa lỗi tốn kém về sau.

Giai đoạn 3: Phân Tác Vụ

Công việc thiết kế được chia nhỏ ra các bước (task) có thứ tự phụ thuộc, mỗi task vừa đủ để AI có thể hoàn thành trong một phiên làm việc ngắn. Đồng thời mô tả luôn yêu cầu kiểm thử cho từng task giúp kiểm soát chất lượng.

Giai đoạn 4: Triển Khai Theo Từng Task Và TDD

AI nhận từng task cụ thể có đầy đủ bối cảnh và bắt đầu viết mã theo yêu cầu, song song viết test trước (Test-Driven Development). AI tự chạy test, phát hiện lỗi sẽ tự động sửa, giảm thiểu tối đa lỗi sai trước khi mã được con người xem lại.

Cấu trúc tệp Spec (CLAUDE.md, AGENTS.md, Quy tắc thư mục)

Các tài liệu này đóng vai trò "bản tóm tắt" quy mô dự án cho AI, chứa thông tin về công nghệ, quy chuẩn code, cách xử lý lỗi, quy tắc kiến trúc… giúp AI mỗi lần làm việc đều có đầy đủ ngữ cảnh để sinh mã chuẩn mực.

Mỗi thư mục cũng có thể có .rules riêng để quy định những quy tắc cụ thể theo domaine (tầng dịch vụ, API...), giữ sự thống nhất xuyên suốt dự án.

Tích hợp TDD cùng AI: Chu trình Đỏ - Xanh - Tinh chỉnh

TDD là công cụ lý tưởng cho AI vì nó cung cấp định nghĩa khách quan cho "đúng", thay vì con người phải đọc từng dòng code do AI viết để kiểm tra. Quy trình gồm:

• Bước 1: Con người viết test mô tả hành vi mong muốn (thường bằng code test tự động)

• Bước 2: AI viết code để test qua được, lặp lại nếu thất bại

• Bước 3: Con người đánh giá đầu ra, tập trung vào kết quả chứ không đọc toàn bộ code

Những lỗi phổ biến AI mắc và cách SDD ngăn ngừa

Mô hình lỗi	Nguyên nhân gốc	Cách SDD khắc phục
Bỏng rụi bối cảnh	AI không biết quy chuẩn	Tệp CLAUDE.md với quy chuẩn kiến trúc, code
Thiên vị đường mòn	Thiếu mã xử lý lỗi	Viết test chi tiết tình huống lỗi đầu tiên
Mở rộng ngoài tầm kiểm soát	AI phát sinh tính năng ngoài yêu cầu	Phân chia task với giới hạn rõ ràng
Lệch kiến trúc	AI dùng mẫu riêng	Thiết kế kiến trúc và quy tắc thư mục
Regresion (Lỗi tái phát)	Mã mới phá vỡ mã cũ	TDD phát hiện sớm lỗi
Lỗ hổng bảo mật	AI bỏ qua kịch bản an ninh	Yêu cầu bảo mật rõ ràng + test bảo mật
Thiếu sở hữu	Dev ko hiểu mã AI viết	Đánh giá thiết kế trước viết code
Nợ kỹ thuật tăng	Mã không đồng nhất	CLAUDE.md và luật thư mục duy trì đồng nhất

Quy trình sản xuất chuẩn từ yêu cầu tới tích hợp

1. Tóm tắt tính năng: Mô tả ngắn gọn chức năng cần phát triển.

2. Phân tích yêu cầu AI hỗ trợ: AI tạo requirements.md chi tiết.

3. Thiết kế kiến trúc AI hỗ trợ: AI tạo design.md, được review bởi con người.

4. Review thiết kế: Con người duyệt kỹ trước khi code.

5. Phân công công việc AI hỗ trợ: AI lập tasks.md.

6. Triển khai lặp từng task: Viết test rồi viết code, chạy test.

7. Kiểm thử tích hợp và lint: Đảm bảo toàn bộ hệ thống vận hành ổn định.

Mở rộng quy trình cho nhóm và đo lường hiệu quả

• Lưu trữ toàn bộ tài liệu spec trong repository, đồng bộ với code.

• Dùng checklist PR bắt buộc tham chiếu các tài liệu spec và test.

• Theo dõi các chỉ số như số lỗi AI tạo ra mỗi sprint, thời gian debug, thời gian review PR, tốc độ hoàn thiện tính năng và tỷ lệ bắt lỗi bảo mật.

Sau khi áp dụng SDD, các nhóm thấy giảm mạnh lỗi phát sinh, rút ngắn thời gian sửa lỗi và review, tăng tốc độ bàn giao tính năng thực tế.

Giải đáp những thắc mắc thường gặp

• "SDD là thêm giấy tờ rườm rà?" Không, SDD tận dụng AI sinh tài liệu, con người chỉ cần review, tiết kiệm hàng giờ debugging dài dòng.

• "Dự án nhỏ liệu có cần?" Nếu codebase nhỏ, bạn có thể dùng vibe coding. Tuy nhiên khi số file vượt 10-20, SDD là cần thiết để tránh hỗn loạn.

• "Viết test làm chậm phát triển?" Viết test mất vài phút, nhưng tổng thể giúp tăng tốc vì AI code đúng ngay từ đầu, giảm thời gian sửa.

• "Tôi chỉ cần prompt tốt hơn?" Prompt chỉ hữu ích trong phiên làm việc. Spec files giúp duy trì kiến thức liên tục, phù hợp mọi AI, mọi người trong team.

Mô hình trưởng thành trong áp dụng SDD

• Giai đoạn 1 - Phản ứng: Dùng AI với prompt rời rạc, không lưu bối cảnh, sửa lỗi thủ công nhiều.

• Giai đoạn 2 - Có cấu trúc: Xây spec files, vòng 4 giai đoạn và TDD, luật thư mục.

• Giai đoạn 3 - Toàn diện: Duy trì kho spec, AI tự động cập nhật spec, theo dõi metric, onboarding dễ dàng qua spec, nhiều công cụ AI tuân thủ spec thống nhất.

---

AI coding là một công cụ đầy sức mạnh nhưng cũng tiềm ẩn sai sót khi thiếu quy trình phù hợp. Vibe coding là cách tận dụng AI thiếu kỷ luật, còn SDD là phương pháp giúp biến AI thành trợ thủ đắc lực, đảm bảo sản phẩm không chỉ nhanh mà còn ổn định đáng tin cậy.

Hãy coi AI như một kỹ sư junior đầy tài năng. Đào tạo họ bằng đặc tả rõ ràng, thiết kế kỹ càng, test chặt chẽ và phân công cụ thể là cách để tăng gấp bội hiệu quả phát triển phần mềm trong thời đại mới.

---

Bài viết gốc đăng trên Pockit Blog, tham khảo thêm công cụ hỗ trợ lập trình tại Pockit.tools.