Spec trước, code sau (spec-first)
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".
Spec-first · TDD bắt buộc · Truy vết hai chiều
AI viết code nhanh, SDD bảo đảm code đúng và chứng minh được.
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.
Spec-first
Đặc tả có cấu trúc trước khi code
TDD bắt buộc
Viết test trước, rồi mới viết code
Truy vết hai chiều
Spec ↔ code ↔ test, cả hai hướng
Phát hiện can thiệp
Nhật ký quyết định niêm phong chuỗi băm
Ý tưởng cốt lõi
SDD là gì?
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.
Cổng kiểm soát cứng giữa các pha
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".
Truy vết hai chiều
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.
Ghép theo tech và ngành
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.
Tự chủ có kiểm soát
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".
Nhật ký kiểm toán phát hiện can thiệp
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.
#a4c
→
#1b7
→
#e2f
→
#9d0
Pipeline
Quy trình 7 pha — một vòng khép kín
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.
1
PO / BA
Specify
Làm rõ yêu cầu thành spec có cấu trúc, kèm tiêu chí nghiệm thu.
2
Solution Architect
Plan
Chốt kiến trúc, NFR và ADR; cổng kiểm tra đồ thị module không vòng.
3
Tech Lead
Tasks
Phân rã 100% yêu cầu thành task, kiểm DAG phụ thuộc, chia milestone.
4
Developer
Implement
Viết test trước rồi mới viết code; task nhỏ, truy vết về từng yêu cầu.
5
QA / SDET
Verify
Chạy toàn bộ test, soát truy vết và tiêu chí nghiệm thu.
6
QA + Tech Lead
Review
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.
7
Team Lead
Report
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.
Vai trò ở mỗi pha (RACI)
| 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 (SPECIFY→TASKS qua /autopilot, IMPLEMENT→REPORT qua /pipeline) → phát hành → vận hành & học (theo dõi trên bảng KPI chỉ-đọc /sdd-metrics) → chu kỳ kế tiếp.
Phản hồi từ vận hành quay về spec qua kênh /delta; 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
Vấn đề ↔ Giải pháp
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.
AI code theo cảm tính
AI code dưới kỷ luật SDD
Drift khỏi ý định
Code âm thầm trôi khỏi yêu cầu ban đầu; đến lúc nghiệm thu mới lộ ra đã lệch.
Cổng kiểm soát cứng chấm từng pha, bắt drift ngay tại chỗ trước khi đi tiếp.
Tự chấm điểm
AI tự đánh giá kết quả của chính mình — vừa đá bóng vừa thổi còi.
Reviewer độc lập cùng cổng do máy chấm; AI không bao giờ tự phê duyệt việc của nó.
Thiếu truy vết
Không rõ đoạn code nào hiện thực yêu cầu nào, tính năng "mồ côi" lọt lưới.
Truy vết hai chiều spec ↔ code ↔ test: mỗi yêu cầu nối đúng tới code và bài test.
Quyết định tản mát
Lựa chọn kỹ thuật nằm rải rác, sửa lại về sau không ai hay biết.
Nhật ký niêm phong bằng chuỗi hash; mọi chỉnh sửa về sau đều bị phát hiện.
Cấu trúc, không phải lời hứa
Vì sao tin tưởng được
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.
Không thể đi tắt
↳ Trụ cột · Cổng kiểm soát cứng giữa các phaMỗ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".
verify-*.pyAI không tự chấm điểm mình
↳ Trụ cột · Tự chủ có kiểm soátQuyền tự chủ của AI bị giới hạn và ghi lại; việc chấm do cổng và reviewer đảm nhiệm — reviewer chạy chỉ-đọc ở phạm vi task và milestone, và fresh-context ở vòng dự án.
spec-compliance-reviewerBa vòng review mở rộng phạm vi
↳ Trụ cột · Cổng kiểm soát cứng giữa các phaReview đ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.
task_lenses = 3Review cả nghiệp vụ lẫn chất lượng code
↳ Trụ cột · Spec trước, code sauDuyệ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.
spec-compliance → code-quality-reviewerBắt buộc truy vết
↳ Trụ cột · Truy vết hai chiềuMọi yêu cầu trong phạm vi phải nối được tới code và test hiện thực nó; một script chặn "done" cho tới khi nối đủ.
verify-traceability.py --auto-detectBáo cáo trung thực
↳ Trụ cột · Nhật ký kiểm toán phát hiện can thiệpKế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.
tasks/DECISIONS/ verify-decisions.py
Bằng chứng, không phải khẩu hiệu
Kỷ luật đo được, không phải lời hứa
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.
27
yêu cầu chức năng (FR) được đặc tả
specs/FUNCTIONAL.md
29
yêu cầu phi chức năng (NFR)
specs/NON_FUNCTIONAL.md
7
pha có cổng kiểm soát cứng
SPECIFY → REPORT
3
vòng review độc lập mỗi thay đổi
reviewer không tự duyệt việc của mình
Mỗi vai trò, một nỗi lo
Kiểm soát + tốc độ
Bằng chứng kiểm toán
Duyệt bằng nghiệp vụ
Ít làm lại, giao nhanh
Đối tượng phù hợp
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.
CTO & Engineering Lead
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.
Đội Tuân thủ & Kiểm toán
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.
Founder không chuyên kỹ thuậ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.
Đội phát triển sản phẩm
Í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.
Đăng ký tư vấn
Để 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.