Spec-Driven Development (SDD) & BDD trong Kỷ nguyên Agent
Chuyển dịch điểm nghẽn sang khâu đặc tả, tài liệu Decision-complete, chuyển hóa quyết định sản phẩm thành kịch bản Gherkin BDD và phân loại vòng đời chỉ dẫn.
Tốc độ đẩy điểm nghẽn sang các khâu phía sau
Bốn ngày đầu đã xây dựng các thành phần của một sản phẩm agent: kết quả mong muốn của người dùng có ranh giới rõ ràng, tool có thể tương tác với nhau, skill tái sử dụng được, cơ chế kiểm soát an toàn và bằng chứng đánh giá. Ngày 5 sẽ kết nối chúng thành một quyết định sẵn sàng cho môi trường production.
Quy trình phát triển với agent có thể tạo ra phần triển khai nhanh hơn khả năng review, kiểm thử và tích hợp của team. Khi mục tiêu vẫn mơ hồ, tốc độ này dễ tạo ra ảo giác rằng công việc đang tiến triển. Một nghìn dòng code nghe có vẻ hợp lý sẽ không có giá trị nếu chỉ làm dài thêm danh sách code cần kiểm thử hoặc kéo sản phẩm lệch khỏi nhu cầu thực sự của người dùng.
Vì thế, điểm nghẽn dịch chuyển từ khâu viết code sang làm rõ sản phẩm và kiểm thử hệ thống. PM và engineer dành nhiều thời gian hơn để xác định hành vi, review bằng chứng, quản trị ranh giới và quyết định điều gì đủ an toàn để phát hành. Agent xử lý nhiều chi tiết triển khai hơn, nhưng con người vẫn chịu trách nhiệm về bản thiết kế và bản phát hành.
Spec-Driven Development (SDD) - Phát triển dựa trên bản đặc tả là mô hình vận hành cho sự chuyển dịch này: xem mục tiêu và hành vi đã được review là nguồn sự thật cốt lõi, còn code triển khai có thể thay thế khi không còn khớp với bản thiết kế.
Vì vậy, “vibe coding” không thể đồng nghĩa với “đưa cảm tính vào production”. Có thể bắt đầu thử nghiệm từ một mục tiêu còn thô, nhưng công việc production cần một nguồn sự thật mà người khác, agent khác và hệ thống đánh giá đều kiểm tra được.
Hãy dùng xuyên suốt Ngày 5 một ví dụ: sales-research agent đọc bằng chứng tài khoản đã được phê duyệt, soạn bản briefing và đề xuất cập nhật CRM. Trong đợt pilot đầu tiên, agent không được ghi vào CRM hoặc gửi email ra bên ngoài. Nhu cầu người dùng là có thật-nghiên cứu chậm và bằng chứng rời rạc-nhưng rủi ro cũng hiện hữu: dữ liệu tài khoản lỗi thời hoặc người nhận do agent bịa ra có thể biến một bản nháp tưởng như hợp lý thành sự cố nghiêm trọng với bên ngoài. Chúng ta sẽ đưa workflow này đi từ bản đặc tả qua tích hợp, review, kiểm soát an toàn, đánh giá, phát hành và hoàn tác.
Luồng reviewable từ spec tới release
Mỗi transition bổ sung evidence trước khi sản phẩm nhận thêm authority.
Reviewed source of truth
User outcome, boundary, contract, policy, owner và rollback trigger
Normal, boundary, ambiguous và unsafe behavior có thể quan sát
Commit-bound delivery
Runtime decision
Threshold vẫn đạt
Tiếp tục monitor approved cohort mà không mở rộng authority.
Rollback trigger được kích hoạt
Disable write tool, revoke credential, giữ trace và quay về read hoặc draft-only mode.
Failure trở thành BDD và eval case mới. Review spec trước khi bắt đầu small batch tiếp theo.
Bản đặc tả là hợp đồng chung
Bản đặc tả là kim chỉ nam kiến trúc cho workflow. Nó nêu rõ cần xây gì, vì sao điều đó quan trọng, những trạng thái nào tồn tại, hệ thống nào liên quan và team sẽ biết kết quả đúng bằng cách nào. Hãy lưu bản đặc tả theo từng tác vụ cùng dự án để có thể review và quản lý phiên bản cùng phần triển khai.
SDD giữ bản thiết kế đi trước code được sinh ra
SDD là một vòng lặp, không phải việc viết một tài liệu thật dài. Trước hết, team xác định kết quả mong muốn của người dùng và các ranh giới. Tiếp đó, giải quyết các quyết định về sản phẩm và kiến trúc trước khi sinh code. Sau đó, chuyển các hành vi trọng yếu thành ví dụ và bằng chứng nghiệm thu. Agent triển khai một gói nhỏ có thể review dựa trên phiên bản đặc tả ấy; test và eval đối chiếu kết quả với bản thiết kế. Khi quá trình triển khai làm lộ một quy tắc chưa được quyết định, team cập nhật và review đặc tả trước khi tiếp tục. Code có thể sinh lại; một quyết định sản phẩm chưa được review thì không.
Với sales-research agent, bản đặc tả ban đầu nêu rõ nguồn tài khoản nào là nguồn chuẩn, điều gì khiến một nhận định có căn cứ, khi nào dữ liệu bị coi là lỗi thời, trường CRM nào chỉ được lập bản nháp, đồng thời xác định email và thao tác ghi trực tiếp vào CRM nằm ngoài phạm vi. Nhờ đó agent triển khai không tự đặt ra quy tắc về độ mới của dữ liệu hoặc hiểu “chuẩn bị tiếp cận” thành “gửi email tiếp cận”.
Một bản đặc tả sản phẩm agent tốt bao gồm:
- Vấn đề người dùng, người dùng mục tiêu và nhu cầu thực sự cần giải quyết.
- Các kịch bản được hỗ trợ và không được hỗ trợ.
- Nguồn dữ liệu, độ mới và yêu cầu về bằng chứng.
- Các hợp đồng tool, phân quyền và thay đổi trạng thái.
- Hành trình người dùng, trạng thái, sự phê duyệt và các trạng thái khôi phục.
- Kỳ vọng về chức năng, giao diện, hành vi và khả năng tiếp cận.
- Trường hợp đánh giá, chỉ số guardrail và ngưỡng phát hành.
- Kế hoạch triển khai, chủ sở hữu, xử lý sự cố và kế hoạch hoàn tác.
Dùng Markdown dạng văn xuôi cho mục tiêu và các đánh đổi. Dùng bảng có cấu trúc hoặc YAML cho schema, phân quyền và cấu hình khi cấu trúc lồng nhau quan trọng. Định dạng chỉ đứng sau độ rõ ràng. Một tài liệu dài, lặp ý và chôn vùi tiêu chí nghiệm thu có thể gây vấn đề ngữ cảnh y như một system prompt khổng lồ.