Phát triển theo đặc tả: mỗi yêu cầu đi qua cổng kiểm soát cứng và truy vết được tới đúng code và test hiện thực nó — không thể đi tắt, không mất dấu.
Phần lớn công cụ AI lập trình được chào bán dựa trên việc chúng tạo ra được bao nhiêu. Đây là ba điều thực sự thay đổi — với đội kỹ sư của bạn, với các chỉ số bàn giao bạn vốn đã theo dõi, và với những dự án bạn có thể nhận.
Kỹ sư và chuyên viên phân tích nghiệp vụ của bạn có mô tả được yêu cầu đủ chính xác — theo định dạng EARS, với tiêu chí nghiệm thu kiểm thử được — để code do AI sinh ra vượt qua cổng phê duyệt ngay lần đầu? Mức độ sử dụng không đồng nghĩa với năng lực: số license, số lần prompt của mỗi lập trình viên hay số dòng code AI viết ra đều không nói lên chất lượng đầu ra.
Những con số ban lãnh đạo kỹ thuật vốn đã nắm: tỷ lệ làm lại, thời gian hoàn thành mỗi thay đổi, tỷ lệ lỗi lọt ra ngoài, và chi phí sửa lỗi theo giai đoạn phát hiện. Một lỗi bắt được ở pha đặc tả tốn kém chỉ bằng một phần rất nhỏ so với chính lỗi đó khi phát hiện trên production. Nếu đóng góp của AI cần một dashboard riêng mới nhìn thấy được, thì thực chất nó chưa nhìn thấy được.
Truy vết hai chiều và nhật ký quyết định chống sửa đổi cho phép khách hàng thuộc ngành chịu quản lý chặt chấp nhận code do AI sinh ra — điều trước đây họ buộc phải từ chối — trong các môi trường tuân thủ APRA CPS 234, ISO 42001 và IRAP. Đó là một hạng mục dịch vụ bàn giao có kiểm soát hoàn toàn mới, có thể định giá và bán, chứ không phải phiên bản nhanh hơn của dịch vụ bạn vẫn đang làm.
Cấp độ 1 và 2 cho bạn biết quy trình đang vận hành tốt. Cấp độ 3 là lý do vì sao nó đáng để xây dựng.
Hãy hình dung SDD là quy trình kỹ thuật chuẩn của một đội ngũ dày dạn, được "đóng hộp" và nối thẳng vào AI. Thay vì hy vọng AI làm đúng, ta dựng các chốt kiểm bắt buộc — như dây chuyền lắp ráp có trạm QA ở mỗi công đoạn.
Trước khi viết dòng code nào, AI phải làm rõ yêu cầu thành spec có cấu trúc. Bạn duyệt "làm gì" trước khi tốn công cho "làm thế nào".
Mỗi pha chỉ được đi tiếp khi đạt chuẩn do máy kiểm tra. Trượt là dừng và báo cáo trung thực, tuyệt đối không có chuyện "bỏ qua cho nhanh".
Từ một yêu cầu truy ra đúng đoạn code và bài test hiện thực nó, và ngược lại. Không còn tính năng "mồ côi" hay yêu cầu bị bỏ quên.
Một nền chuẩn, cộng lớp công nghệ của bạn (.NET, Django, Rails, Next.js, ứng dụng LLM…) và lớp nghiệp vụ (tài chính, ERP, thương mại điện tử, SaaS). Đúng ngữ cảnh ngay từ đầu.
AI ra quyết định trong giới hạn cho phép, theo chuỗi heuristic rõ ràng. Mọi lựa chọn đều được ghi lại để bạn soát xét sau, không phải "tin mù quáng".
Mỗi quyết định tự động được niêm phong bằng chuỗi hash; sửa đổi về sau đều bị phát hiện. Bằng chứng kỹ thuật, không phải lời hứa.
Một tính năng đi qua 7 pha, giữa mỗi pha là một cổng kiểm soát cứng do máy chấm. Con người đặt ý định và phán đoán ở đầu pha, SDD + AI thực thi phần nặng, còn cổng chặn lỗi trước khi công việc đi tiếp.
Làm rõ yêu cầu thành spec có cấu trúc, kèm tiêu chí nghiệm thu.
Chốt kiến trúc, NFR và ADR; cổng kiểm tra đồ thị module không vòng.
Phân rã 100% yêu cầu thành task, kiểm DAG phụ thuộc, chia milestone.
Viết test trước rồi mới viết code; task nhỏ, truy vết về từng yêu cầu.
Chạy toàn bộ test, soát truy vết và tiêu chí nghiệm thu.
Ba vòng review độc lập, mở rộng dần phạm vi; AI không tự chấm bài mình.
Tổng kết trung thực: đạt gì, trượt gì, quyết định nào đã ghi vào nhật ký.
Khi một cổng FAIL (hết lượt tự sửa), pipeline nhảy thẳng tới pha 7 REPORT với báo cáo trung thực. Quy trình không bao giờ dừng im lặng, cũng không giả vờ đã xong.
| Pha | PO / BA | Sol. Architect | Tech Lead | Developer | QA / SDET | DevOps | Team Lead |
|---|---|---|---|---|---|---|---|
| Specify | A | C | C | I | C | I | I |
| Plan | C | A | R | C | C | C | I |
| Tasks | C | C | A | R | C | I | I |
| Implement | I | C | C | A | C | C | I |
| Verify | I | C | C | R | A | C | I |
| Review | C | C | A | C | R | I | I |
| Report | I | I | C | I | C | I | A |
R = thực hiện · A = chịu trách nhiệm cuối (đúng một người mỗi pha) · C = được tham vấn · I = được thông báo. SDD / AI luôn là bên thực thi dưới người chịu trách nhiệm.
SDD không phải đường một chiều mà là vòng lặp khép kín: khám phá → đặc tả → xây dưới kiểm soát (từ spec sang task, rồi implement sang report, mỗi pha có cổng kiểm) → phát hành → vận hành & học (theo dõi trên bảng KPI chỉ-đọc) → chu kỳ kế tiếp.
Phản hồi từ vận hành quay về spec qua kênh thay đổi yêu cầu; spec sống cùng codebase nên chu kỳ sau không phải "vibe-code" lại từ đầu.
Cùng một AI, hai kết cục khác nhau. Bên trái là cách hầu hết đội đang dùng AI hôm nay; bên phải là cùng công việc đó nhưng chạy dưới kỷ luật SDD.
Niềm tin ở đây không đến từ lời hứa mà từ cấu trúc: sáu bảo đảm dưới đây là hệ quả trực tiếp của cách SDD vận hành, mỗi bảo đảm bám vào một trụ cột đã nêu ở trên.
Mỗi pha chỉ qua khi đạt chuẩn do máy chấm; trượt là dừng, không có ngoại lệ "bỏ qua cho nhanh".
Quyền tự chủ của AI bị giới hạn và ghi lại; việc chấm do cổng và reviewer độc lập đảm nhiệm — reviewer chạy chỉ-đọc ở phạm vi task và milestone, và fresh-context ở vòng dự án.
Review đi từ hẹp ra rộng qua nhiều vòng — mỗi vòng là một cổng, không phải một lần liếc qua.
Duyệt "làm gì" ở pha spec trước khi tốn công cho "làm thế nào", rồi mới soát chất lượng hiện thực.
Mọi yêu cầu trong phạm vi phải nối được tới code và test hiện thực nó; kiểm tra tự động chặn "done" cho tới khi nối đủ.
Kết quả gate được ghi thẳng vào nhật ký phát hiện can thiệp — sửa về sau là vỡ chuỗi băm và trình kiểm tra báo ngay. Không tô hồng, không giấu lỗi.
Vài con số rút thẳng từ chính dự án này — bản thân trang web cũng dựng qua SDD, nên đây là bằng chứng chứ không phải khẩu hiệu.
yêu cầu chức năng (FR) được đặc tả
yêu cầu phi chức năng (NFR)
pha có cổng kiểm soát cứng
vòng review độc lập mỗi thay đổi
SDD giải một nỗi lo khác nhau cho mỗi vai trò. Nếu bạn nhận ra mình ở một trong bốn nhóm dưới đây, phần còn lại của trang sẽ nói đúng điều bạn quan tâm.
Tận dụng tốc độ của AI nhưng vẫn giữ quyền kiểm soát, tính dự đoán được và một chuẩn chất lượng đồng nhất cho cả đội.
Cần nhật ký quyết định phát hiện can thiệp (chuỗi băm) và độ phủ truy vết yêu cầu → test để chứng minh tuân thủ khi bị soát.
Duyệt "hệ thống sẽ làm gì" bằng ngôn ngữ nghiệp vụ ngay ở pha spec, minh bạch ở mọi điểm kiểm soát.
Ít phải làm lại, ít hiểu sai yêu cầu, giao hàng nhanh hơn vì drift bị bắt ngay ở commit bằng script thay vì tới lúc khách nghiệm thu.
Để lại thông tin, chúng tôi sẽ liên hệ để tư vấn cách áp dụng SDD cho đội của bạn.