So Sánh Các Công Cụ Phát Triển AI: spec-kit, OpenSpec, superpowers và BMAD
Phân tích kiến trúc bốn công cụ phát triển hướng đặc tả (spec-driven): quy trình vận hành, chi phí thủ tục, tình huống lỗi và tiêu chí lựa chọn phù hợp.
Viết code không còn là điểm nghẽn chính trong quy trình phần mềm. Dữ liệu telemetry của Faros AI trên 10.000 lập trình viên cho thấy: họ merge nhiều hơn 98% pull request và hoàn thành nhiều hơn 21% tác vụ, nhưng thời gian review code lại tăng 91%. Trong thử nghiệm ngẫu nhiên của METR trên 16 lập trình viên mã nguồn mở giàu kinh nghiệm xử lý các issue thật trong chính repo của họ, nhóm dùng AI làm chậm hơn 19%, dù họ ước tính bản thân làm nhanh hơn 20%. Đồng thời, khảo sát năm 2025 của Stack Overflow chỉ ra 46% lập trình viên chủ động nghi ngờ độ chính xác của code AI sinh ra.
Khi việc sinh code trở nên rẻ, yêu cầu không được quản lý khiến khối lượng review chồng chất. Như đã phân tích trong bài viết về chuyển đổi từ vibe coding sang Agentic Engineering, hệ thống production đòi hỏi lớp đặc tả có cấu trúc để neo các AI coding agent hàng đầu năm 2026 vào ý định đã được con người xác nhận.
Bốn bộ công cụ mã nguồn mở tiêu biểu đã xuất hiện để giải quyết bài toán này: spec-kit, OpenSpec, superpowers và BMAD. Dù cùng dùng định dạng Markdown, triết lý thiết kế, chi phí vận hành và mục tiêu thực thi của chúng khác biệt rõ rệt.
Bảng so sánh bốn bộ công cụ
Trước khi đi sâu vào từng giải pháp, hãy đối chiếu cách bốn công cụ phân chia trách nhiệm trên toàn bộ quy trình phát triển:
| Tiêu chí | spec-kit | OpenSpec | superpowers | BMAD Method |
|---|---|---|---|---|
| Đơn vị duy trì | GitHub | Fission-AI | Jesse Vincent (Prime Radiant) | BMad Code |
| Cơ chế cốt lõi | Pipeline tài liệu theo từng giai đoạn | Thư mục delta thay đổi | Kỹ năng markdown bắt buộc | Mô phỏng nhóm agile đa vai trò |
| Mô hình spec | Bộ spec đơn khối theo tính năng | Đặc tả năng lực hệ thống | Không có (kỷ luật luồng việc) | Bộ tài liệu PRD và ADR |
| Tầng thực thi | Công cụ agent bên ngoài | Hệ thống slash-command cho agent (/opsx) |
Terminal hook và git worktree | Prompt theo từng vai trò agent |
| Đầu ra chính | specs/NNN-feature/ |
openspec/changes/<name>/ |
Bảng chống ngụy biện trong kỹ năng | _bmad-output/ |
| Quy mô phù hợp | Dự án greenfield quy mô doanh nghiệp | Codebase brownfield hiện có | Tính năng từ vừa đến lớn | Sản phẩm hoàn chỉnh nhiều epic |
1. spec-kit: Pipeline tài liệu theo từng giai đoạn
Do GitHub phát triển, spec-kit vận hành trên nguyên tắc: code phục vụ bản đặc tả, bản đặc tả không chạy theo code. Công cụ này xoay quanh quy trình lõi sáu bước, đi kèm các bước tùy chọn như clarify, checklist và analyze:
/speckit-constitution -> specify -> plan -> tasks -> implement -> convergeQuy trình bắt đầu bằng việc thiết lập bộ quy ước nền tảng (constitution), cố định các nguyên tắc kiến trúc bắt buộc. Với mỗi tính năng, spec-kit tự động tạo nhánh git riêng và thư mục riêng tại specs/NNN-feature/.
Các thành phần chính gồm:
spec.md: User story, tiêu chí nghiệm thu và edge cases. Bản mẫu cấm đưa chi tiết triển khai vào spec, bắt buộc gắn thẻ[NEEDS CLARIFICATION]khi yêu cầu còn mơ hồ.plan.md: Thiết kế kiến trúc kỹ thuật, data model và contracts.tasks.md: Danh sách đầu việc theo trình tự triển khai.converge: Vòng lặp luân phiên sinh code và kiểm chứng đến khi công cụ báo trạng thái hội tụ.
Ưu điểm và sự đánh đổi
Thế mạnh lớn nhất của spec-kit là khả năng truy vết và kiểm toán (auditability). Trong các doanh nghiệp lớn hoặc đội ngũ kỹ thuật phân tán quy mô lớn, lưu trữ hồ sơ giải thích lý do từng hàm được tạo ra sẽ ngăn ngừa phân rã kiến trúc.
Nhược điểm là gánh nặng thủ tục. Trong thử nghiệm của Scott Logic khi dựng lại tính năng CRUD circuits trên ứng dụng KartLog, spec-kit tốn 57 phút chạy agent qua hai lần lặp (33,5 và 23,5 phút), sinh 4.800 dòng markdown (2.577 và 2.262 dòng) và cần 5,5 giờ review (3,5 và 2 giờ; riêng bước plan chiếm 2.067 dòng). Ngược lại, prompt trực tiếp chỉ mất 8 phút chạy agent và 24 phút kiểm tra (15 phút review code và 9 phút chạy test, sửa lỗi). Với tính năng nhỏ, spec-kit tạo ra lượng tài liệu dư thừa lớn.
2. OpenSpec: Bản đặc tả sống và cơ chế delta
Được Fission-AI xây dựng, OpenSpec tiếp cận bài toán đặc tả theo hướng lặp từng bước (iterative), tối ưu cho codebase có sẵn (brownfield). Thay vì tạo tài liệu tách biệt cho từng ticket, OpenSpec lưu trữ năng lực hệ thống trong thư mục trung tâm openspec/specs/.
Luồng làm việc tuân theo vòng đời opsx tinh gọn:
/opsx:explore -> propose -> apply -> archiveKhi bắt đầu tính năng, OpenSpec tạo thư mục riêng tại openspec/changes/<feature>/ gồm proposal.md và đặc tả delta:
# Change: Add Dark Mode Toggle
## MODIFIED Requirements
- The Settings screen SHALL expose a persistent theme toggle.
- WHEN a user selects dark mode, the client SHALL write the preference to the user profile schema.Sau khi code được duyệt, lệnh archive gộp các delta này vào file năng lực lâu dài. Chính OpenSpec cũng được phát triển bằng cách này với hơn 35 file năng lực.
Ưu điểm và sự đánh đổi
OpenSpec phù hợp với brownfield vì đội ngũ không cần dừng dự án để viết lại tài liệu từ đầu. Lập trình viên chỉ cần mô tả phần delta bị ảnh hưởng bởi pull request hiện tại.
Dù OpenSpec có lệnh xác thực (openspec validate) và kiểm tra (/opsx:verify), đặc tả của nó vẫn là văn bản markdown mô tả. Khác với test suite, công cụ không tự động chạy code ứng dụng để khẳng định việc hiện thực khớp với từng điều khoản. Telemetry cũng được bật mặc định và cần tắt thủ công.
3. superpowers: Kỷ luật thực thi và bắt buộc TDD
Khác với spec-kit hay OpenSpec, superpowers không định nghĩa schema file đặc tả mới. Do Jesse Vincent tại Prime Radiant phát triển, superpowers là execution harness dành riêng cho terminal coding agent như Claude Code.
Triết lý của superpowers là biến chỉ dẫn thành bắt buộc: dùng session hook ép agent gọi kỹ năng markdown theo chuẩn qua bảy bước:
- Động não tương tác (interactive brainstorming): Agent phải hỏi ba đến năm câu làm rõ trước khi đề xuất giải pháp.
- Cô lập git worktree: Mọi thay đổi diễn ra trên worktree riêng nhằm bảo vệ nhánh chính.
- Phân rã đầu việc nhỏ: Chia nhỏ kế hoạch sao cho mỗi đầu việc chỉ nên mất hai đến năm phút.
- Điều phối bằng subagent: Khởi chạy subagent mới cho từng đầu việc nhỏ, tránh quá tải context window.
- Bắt buộc quy trình TDD: Agent phải viết test thất bại trước, xoá mọi code ứng dụng đã viết trước khi có test fail.
- Hai lớp kiểm duyệt: Một lượt kiểm tra mức tuân thủ spec và lượt độc lập thứ hai đánh giá chất lượng code.
- Kết thúc nhánh gọn gàng: Squash commit và hợp nhất thay đổi từ worktree.
Ưu điểm và sự đánh đổi
Superpowers đem lại độ tin cậy thực thi cao nhất trong bốn công cụ nhờ ép buộc viết test trước và cô lập subagent.
Hạn chế là chi phí token đáng kể. Trong issue #832, một cộng tác viên đề xuất cắt giảm 69% dung lượng qua 14 file kỹ năng (từ 3.150 dòng xuống 977 dòng). Phía maintainer từ chối và đóng đề xuất, bảo vệ các bảng chống ngụy biện (rationalization tables) là cần thiết để ngăn agent lách quy tắc. Dù vậy, chạy vòng lặp subagent TDD cho chỉnh sửa UI nhỏ vẫn tốn kém token.
4. BMAD Method: Mô phỏng nhóm agile đa vai trò
BMAD Method cấu trúc vòng đời phần mềm bằng cách mô phỏng phòng ban kỹ thuật với các vai trò chuyên biệt. Trong kiến trúc bản v6 ổn định, BMAD điều phối:
- Product Manager (John) và Analyst (Mary): Định hình bản tóm tắt sản phẩm và tài liệu PRD.
- Kiến Trúc Sư Hệ Thống (Winston): Soạn thảo quyết định kiến trúc ADR và ranh giới giao diện, hợp đồng kỹ thuật.
- Scrum Master (Bob): Phân rã epic thành user story kèm tiêu chí nghiệm thu.
- Lập Trình Viên (Amelia) và QA (Quinn): Hiện thực hóa code và vận hành cổng kiểm thử.
Thư mục _bmad-output/ lưu PRD và ADR. Kết hợp ADR với domain glossary giúp các agent chạy song song thống nhất cách đặt tên và schema.
Ưu điểm và sự đánh đổi
BMAD hiệu quả ở sản phẩm greenfield khi tầm nhìn sản phẩm và kiến trúc kỹ thuật cần định hình cùng lúc, tránh các quyết định mâu thuẫn giữa các agent. Về việc khi nào các persona agent riêng biệt thật sự đáng dùng, xem bài agent profile cần ranh giới chứ không cần chức danh.
Tuy nhiên, BMAD có thủ tục nặng. Trong issue #2003 do chính agent BMAD thực hiện, kiến trúc sư ảo chỉ ra nghịch lý: phương pháp hướng đến người không chuyên, nhưng đánh giá chất lượng vẫn đòi hỏi đọc hiểu diff phức tạp. BMAD cung cấp Quick Flow bỏ qua kiến trúc cho tác vụ nhỏ, thừa nhận rằng mô phỏng agile đầy đủ là không thực tế với bảo trì thường ngày.
Khung phối hợp và lựa chọn thực tế
Bốn công cụ này không loại trừ nhau và có thể xếp lớp theo tầng:
Quy tắc lựa chọn dựa trên độ trưởng thành dự án và quy mô công việc:
- Sửa lỗi nhỏ và bảo trì thường xuyên: Bỏ qua cả bốn công cụ. Prompt trực tiếp kèm test tự động trong CI là con đường ít ma sát nhất.
- Thêm tính năng trên codebase hiện có (brownfield): Chọn OpenSpec. Mô hình delta mô tả tính năng mới mà không cần viết lại code cũ trước.
- Module mới cho hệ thống lớn (greenfield): Chọn spec-kit. Đầu tư ban đầu vào bộ quy ước kiến trúc, hợp đồng và hội tụ giúp chống trôi kiến trúc về dài hạn.
- Tác vụ phức tạp trên terminal agent: Chọn superpowers. Đặt superpowers lên trên bản spec để đảm bảo kỷ luật TDD nghiêm ngặt và worktree riêng.
- Xây dựng sản phẩm hoàn chỉnh từ đầu: Chọn BMAD. Dùng vòng lặp các vai trò để thiết lập PRD, ADR và bảng phân chia công việc trước khi code.
