AI viết code nhanh, SDD bảo đảm code đúng và chứng minh được

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.

• 📋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".

• 🚦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 (dotnet, 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.

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. 1

   SPECIFY

   PO/BA

   Làm rõ yêu cầu thành spec có cấu trúc, kèm tiêu chí nghiệm thu.

2. Cổng kiểm soát cứng

   2

   PLAN

   Solution Architect

   Chốt kiến trúc, NFR và ADR; cổng kiểm tra đồ thị module không vòng.

3. Cổng kiểm soát cứng

   3

   TASKS

   Tech Lead

   Phân rã 100% yêu cầu thành task, kiểm DAG phụ thuộc, chia milestone.

4. Cổng kiểm soát cứng

   4

   IMPLEMENT

   Developer

   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. Cổng kiểm soát cứng

   5

   VERIFY

   QA/SDET

   Chạy toàn bộ test, soát truy vết và tiêu chí nghiệm thu.

6. Cổng kiểm soát cứng

   6

   REVIEW

   QA + Tech Lead

   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. Cổng kiểm soát cứng

   7

   REPORT

   Team Lead

   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ò theo từng pha (RACI)

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.

Vòng đời sản phẩm dưới SDD

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.

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.

• Drift khỏi ý định

  Phía vấn đề · AI code theo cảm tí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.

  Phía giải pháp · AI code dưới kỷ luật SDD

  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

  Phía vấn đề · AI code theo cảm tính

  AI tự đánh giá kết quả của chính mình — vừa đá bóng vừa thổi còi.

  Phía giải pháp · AI code dưới kỷ luật SDD

  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

  Phía vấn đề · AI code theo cảm tính

  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.

  Phía giải pháp · AI code dưới kỷ luật SDD

  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

  Phía vấn đề · AI code theo cảm tính

  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.

  Phía giải pháp · AI code dưới kỷ luật SDD

  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.

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

  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".

  ↳ Trụ cột: Cổng kiểm soát cứng giữa các pha

  cổng máy chấm: verify-*.py

• AI không tự chấm điểm mình

  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 đảm nhiệm — reviewer chạy chỉ-đọc ở phạm vi task và milestone, và fresh-context ở vòng dự án.

  ↳ Trụ cột: Tự chủ có kiểm soát

  spec-compliance-reviewer (agent độc lập)

• Ba vòng review mở rộng phạm vi

  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.

  ↳ Trụ cột: Cổng kiểm soát cứng giữa các pha

  task_lenses = 3 (mặc định SDD)

• Review cả nghiệp vụ lẫn chất lượng code

  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.

  ↳ Trụ cột: Spec trước, code sau (spec-first)

  spec-compliance → code-quality-reviewer

• Bắt buộc truy vết

  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ó; một script chặn "done" cho tới khi nối đủ.

  ↳ Trụ cột: Truy vết hai chiều

  verify-traceability.py --auto-detect

• Báo cáo trung thực

  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.

  ↳ Trụ cột: Nhật ký kiểm toán phát hiện can thiệp

  tasks/DECISIONS/ hash-chain + verify-decisions.py

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ả

  đếm trong specs/FUNCTIONAL.md

• 29

  yêu cầu phi chức năng (NFR)

  đếm trong 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

Đố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

  Kiểm soát + tốc độ

  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

  Bằng chứng 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 bằng nghiệp vụ

  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 làm lại, giao nhanh

  Í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.