# Cách thiết lập Spec Kit trong Claude Code năm 2026: Đặc tả thay cho câu lệnh > Cách thiết lập GitHub Spec Kit trong Claude Code: 4 giai đoạn—Specify, Plan, Tasks, Implement. Đây là phương pháp thay thế cho vibe coding tùy hứng. Source: https://ailoot.ai/blog/vi/spec-kit-claude-code-spec-driven-development/ Canonical: https://ailoot.ai/blog/vi/spec-kit-claude-code-spec-driven-development/ Language: vi Publisher: Ailoot (https://ailoot.ai/) Translation: guide-219 Revision: sha256-15f0e56ff9b1216efa2efc567f4148b9fd2ecde44aaf0c695a16f7181d252941
Điểm chính Spec Kit là công cụ của GitHub cho phép bạn viết đặc tả nhiệm vụ bằng ngôn ngữ tự nhiên, sau đó Claude Code lập kế hoạch, chia nhỏ thành các nhiệm vụ và viết mã. Đây không phải lý thuyết: công cụ đạt 107.000 sao GitHub trong 8 tháng, AWS dùng phương pháp này để xây dựng một dự án khám phá thuốc trong 3 tuần thay vì vài tháng. Hướng dẫn này trình bày cách cài đặt, các mẫu, 4 giai đoạn của quy trình cùng bước kiểm tra cuối, và cách kết nối với CLAUDE.md của bạn.
[Tài liệu Ailoot](https://ailoot.ai/docs/) — tài liệu tham khảo về cách sử dụng dịch vụ.
## Vibe coding đã ra sao vào tháng 5 năm 2026?
Điểm chính Sau 8 tháng, GitHub Spec Kit thu hút 107.000 sao, và AWS công bố nghiên cứu điển hình cho biết tiết kiệm hơn 80 giờ khi làm một tính năng. Xu hướng của tuần trong tháng 5: đặc tả thay thế cho ứng biến.
Một năm sau, vào ngày 4 tháng 2 năm 2026, ông đăng một chuỗi bài nhìn lại: Trong bài nói chuyện tại Sequoia Ascent 2026, ông diễn đạt chính xác hơn nữa: “Vibe coding nâng mức sàn—mức độ mọi người có thể làm được trong lĩnh vực phần mềm. Agentic engineering giữ nguyên mức trần—tiêu chuẩn chất lượng của hoạt động phát triển chuyên nghiệp.” Trên cùng sân khấu, ông nói một câu đi vào từ vựng của ngành: “Bạn không được phép tạo ra lỗ hổng vì vibe coding. Bạn vẫn chịu trách nhiệm về phần mềm của mình như trước đây.” Hai việc diễn ra song song. Tháng 9 năm 2025, GitHub phát hành công cụ [Spec Kit](https://github.com/github/spec-kit)—công cụ này thu hút 107.000 sao trong 8 tháng. Tháng 2 năm 2026, AWS công bố [nghiên cứu điển hình chi tiết về khám phá thuốc](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/), cho biết “95% logic nghiệp vụ được tạo từ đặc tả, tiết kiệm hơn 80 giờ.” Đến cuối tháng 5 năm 2026, trong không gian thông tin tiếng Anh đã hình thành sự đồng thuận: vibe coding như một phương pháp làm việc là cấp độ dành cho người mới bắt đầu. Tiếp theo là Spec-Driven Development. Hướng dẫn này giải thích cách cài đặt và áp dụng phương pháp đó. ## Spec Kit và Spec-Driven Development là gì?
Điểm chính Spec-Driven Development (SDD) đảo ngược cách tiếp cận thông thường với tác tử AI. Trước đây, mã là nguồn sự thật còn đặc tả chỉ là giấy tờ đi kèm. Giờ đây, đặc tả là nguồn sự thật, còn mã trở thành bước cuối cùng—phần triển khai của nó. Spec Kit là công cụ CLI của GitHub, biến 4 giai đoạn (Specify, Plan, Tasks, Implement) và bước kiểm tra Converge cuối cùng thành các lệnh sẵn dùng trong Claude Code, Cursor, Copilot và hơn 30 tác tử khác.
Ý tưởng cốt lõi của phương pháp được tóm gọn trong một câu từ tài liệu chính thức của GitHub:

Spec-Driven Development thay đổi thứ bậc: đặc tả không phục vụ mã—mã phục vụ đặc tả. Đặc tả trở thành tạo phẩm chính, còn mã là cách thể hiện nó bằng một ngôn ngữ và framework cụ thể.

— Tài liệu GitHub Spec Kit, https://github.com/github/spec-kit/blob/main/spec-driven.md
Trên thực tế, quy trình gồm 4 giai đoạn (Spec Kit bổ sung thêm một giai đoạn nữa, giai đoạn số không—constitution, được mô tả bên dưới): 1. **Specify** - viết đặc tả về điều bạn muốn bằng ngôn ngữ tự nhiên. CẦN làm gì và TẠI SAO. Không phải LÀM THẾ NÀO. 2. **Plan** - tác tử tiếp nhận đặc tả và lập kế hoạch kỹ thuật: dùng công nghệ nào, kiến trúc ra sao và gồm những thành phần nào. 3. **Tasks** - tác tử chia kế hoạch thành các nhiệm vụ cụ thể, có thể kiểm chứng và có quan hệ phụ thuộc. 4. **Implement** - tác tử (hoặc các tác tử con) thực hiện từng nhiệm vụ và viết mã. Sau Implement, phiên bản Spec Kit hiện tại có bước xác minh mang tên **Converge**: tác tử đối chiếu mã hoàn thành với đặc tả, kế hoạch và các nhiệm vụ, rồi bổ sung những gì còn thiếu vào `tasks.md`. Lặp lại Implement và Converge cho đến khi Converge trả lời “Converged.” Mỗi giai đoạn là một tệp markdown riêng trong repo. Mỗi giai đoạn là một lệnh slash riêng trong Claude Code: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement`, còn bước kiểm tra là `/speckit-converge`. Tài liệu Spec Kit ghi các lệnh tương tự với dấu chấm (`/speckit.specify`), nhưng trong Claude Code, Spec Kit cài chúng dưới dạng skills và gọi bằng dấu gạch nối. Nếu có vấn đề ở bất kỳ bước nào, hãy sửa tệp markdown rồi chạy lại giai đoạn tiếp theo. Spec Kit là một cách triển khai cụ thể của SDD. Đến tháng 5 năm 2026, công cụ đã có hơn 30 tích hợp với các tác tử AI khác nhau. Trong cùng một repo, Spec Kit hoạt động như nhau với Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose và hơn mười tác tử khác. | Giai đoạn Spec Kit | Lệnh slash | Tạo phẩm trong repo | |----|----|----| | Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` | | Specify | `/speckit-specify` | `specs/###-feature/spec.md` | | Clarify (không bắt buộc) | `/speckit-clarify` | chỉnh sửa trong `spec.md` | | Plan | `/speckit-plan` | `specs/###-feature/plan.md` | | Checklist (không bắt buộc) | `/speckit-checklist` | danh sách kiểm tra chất lượng yêu cầu | | Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` | | Analyze (không bắt buộc) | `/speckit-analyze` | báo cáo về spec, plan và tasks | | Implement | `/speckit-implement` | mã trong dự án | | Converge | `/speckit-converge` | kết luận “Converged” hoặc nhiệm vụ mới trong `tasks.md` | Vậy sau một lượt chạy, repo của bạn không chỉ có mã mà còn có đặc tả, kế hoạch và nhiệm vụ của mã đó. Một tháng sau, bạn có thể quay lại dự án, đọc `spec.md` và hiểu việc gì đã được làm cũng như lý do. Đây không còn là “vibe coding quên mất mã tồn tại”—đó là bộ nhớ làm việc của dự án. ## Vì sao người làm vibe coding không viết mã vẫn cần đến phương pháp này?
Điểm chính Nỗi đau chính của người làm vibe coding là tính khó đoán. Hôm nay tác tử tạo cho bạn một tính năng hoạt động trong 20 phút; ngày mai, với nhiệm vụ tương tự, nó lại tạo ra một mớ mã rối. Spec Kit loại bỏ nguồn gốc của sự khó đoán này—một nhiệm vụ diễn đạt mơ hồ. Khi viết đặc tả theo mẫu, tác tử làm việc nhất quán vì có một nguồn sự thật rõ ràng. Ngoài ra, bạn có một tạo phẩm lâu dài trong repo để quay lại sau một tháng.
Spec Kit chính thức hóa việc lập kế hoạch qua các bước riêng với 4 lệnh slash. Logic: tách “suy nghĩ thấu đáo” khỏi “triển khai” để chúng diễn ra trong những cửa sổ ngữ cảnh khác nhau. Mỗi giai đoạn có một ngữ cảnh sạch, chưa bị giai đoạn trước làm lộn xộn. Ba lợi ích cụ thể cho người làm vibe coding: - **Tính dự đoán.** Khi bạn bảo tác tử “tạo biểu mẫu đăng ký có xác nhận qua email”, nó tự đoán 10 chi tiết—và đoán sai ba chi tiết so với điều bạn hình dung. Khi có `spec.md` với User Stories, Acceptance Scenarios và dấu `[NEEDS CLARIFICATION]` ở mọi điểm chưa chắc chắn, sẽ không còn gì để đoán. - **Bộ nhớ dự án.** Một tháng sau, bạn sẽ không nhớ mình đã trao đổi gì với tác tử trong chat. Nhưng `spec.md`, `plan.md` và `tasks.md` nằm trong repo, trong thư mục `specs/###-feature/` cùng với mã. Chúng cho bạn biết không chỉ việc gì đã làm, mà còn vì sao. - **Khả năng mở rộng.** Với tính năng liên quan đến 1-2 tệp, khác biệt hầu như không đáng kể. Với tính năng liên quan đến 20 tệp và 5 thực thể dữ liệu, khác biệt nằm giữa “viết lại tất cả sau 4 giờ” và “mọi thứ đã vào nhánh chính sau 4 giờ.” AWS Kiro đã chứng minh khả năng tự động hóa 95% logic nghiệp vụ từ đặc tả trong dự án TargetID. Ảo tưởng lớn nhất của vibe coding là ban đầu nó có vẻ nhanh hơn. Nửa giờ là có nguyên mẫu. Nhưng đến mốc một tuần, nguyên mẫu bị hỏng và vứt bỏ nó còn dễ hơn. Spec-Driven Development mất thêm một chút thời gian lúc đầu (một giờ thay vì nửa giờ), nhưng một tuần sau bạn vẫn làm việc trong cùng repo. ## Cách cài đặt Spec Kit trong Claude Code (4 bước)
Điểm chính Spec Kit được cài đặt thông qua uv, trình quản lý gói Python của Astral. Bản thân lệnh chỉ dài một dòng. Sau khi cài đặt, hãy vào repo, chạy `specify init` với cờ `--integration claude` (hoặc chọn Claude Code trong danh sách tác tử), bạn sẽ có cấu trúc sẵn dùng với mẫu constitution, spec, plan và tasks, cùng một bộ lệnh `/speckit-*` ngay trong Claude Code. Cài đặt mất 5 phút nếu uv đã được cài, và 10 phút nếu cần cài từ đầu.
**Bước 1. Cài uv.** Bạn chỉ cần làm việc này một lần; uv sẽ ở lại trên hệ thống. ```bash # macOS / Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" ``` Kiểm tra uv đã được cài đặt: ```bash uv --version ``` **Bước 2. Cài Spec Kit.** Một lệnh: ```bash uv tool install specify-cli --from git+https://github.com/github/spec-kit.git ``` Kiểm tra: ```bash specify --version ``` **Bước 3. Khởi tạo repo.** Đi đến thư mục dự án (hoặc tạo thư mục mới) và chạy: ```bash specify init --here --integration claude ``` Cờ `--integration claude` chọn trực tiếp Claude Code. Nếu không dùng cờ này, Spec Kit sẽ yêu cầu bạn chọn một tác tử trong danh sách tương tác, và có thể hỏi thêm loại script (với macOS và Linux, hãy để là `sh`). Nếu thư mục không trống, Spec Kit sẽ cảnh báo rằng nó sẽ gộp các tệp của mình với tệp hiện có: trước tiên hãy commit công việc, rồi chạy lại lệnh với cờ `--force`. Sau đó, các thành phần sau sẽ xuất hiện trong repo: ``` .specify/ memory/ constitution.md # quy tắc dự án, được điền bằng /speckit-constitution scripts/ templates/ spec-template.md plan-template.md tasks-template.md .claude/ skills/ speckit-constitution/SKILL.md speckit-specify/SKILL.md speckit-clarify/SKILL.md speckit-plan/SKILL.md speckit-checklist/SKILL.md speckit-tasks/SKILL.md speckit-analyze/SKILL.md speckit-implement/SKILL.md speckit-converge/SKILL.md speckit-taskstoissues/SKILL.md ``` **Bước 4. Mở Claude Code và kiểm tra các lệnh slash.** Chạy lệnh này trong cùng thư mục: ```bash claude ``` Trong phiên làm việc, nhập `/speckit`—các lệnh `speckit-*` sẽ xuất hiện trong gợi ý. Nếu không thấy, hãy khởi động lại Claude Code để chương trình đọc lại `.claude/skills/`. Nếu đã có `CLAUDE.md` ở thư mục gốc dự án, Spec Kit sẽ giữ nguyên tệp đó—nó hoạt động song song với tệp này trong `.specify/memory/constitution.md`. Spec Kit cũng hoạt động mà không cần Claude Code (công cụ hỗ trợ hơn 30 tác tử), nhưng hướng dẫn này tập trung cụ thể vào việc thiết lập với Claude. Nếu muốn cài đặt ngay hai công cụ, hãy xem các hướng dẫn riêng về [thiết lập CLAUDE.md](https://ailoot.ai/blog/vi/claude-md-template/) và [Plan Mode trong Claude Code](https://ailoot.ai/blog/vi/claude-code-plan-mode/). Spec Kit là khối nền tảng đầu tiên trong “hợp đồng lao động của tác tử”. Cấu hình hoàn chỉnh gồm cả ba thành phần: bản sao AI (phương pháp của bạn dưới dạng Skills và tác tử con), Second Brain (cấu trúc `business/` mà tác tử quay lại mỗi lần), và kỹ thuật ngữ cảnh (Spec Kit, Plan Mode, /compact). Đây là ba trụ cột mà nếu thiếu, AI sẽ ảo giác. ## Cách viết đặc tả đầu tiên (Specify)
Điểm chính Spec Kit yêu cầu bạn mô tả tính năng theo cách tự do, sau đó mở rộng mô tả đó thành tệp `spec.md` theo mẫu: User Stories với mức ưu tiên P1/P2/P3, Acceptance Scenarios theo định dạng Given/When/Then, Functional Requirements (FR-001, FR-002, v.v.) và Success Criteria với kết quả có thể đo lường. Ở những chỗ tác tử chưa chắc chắn, nó chèn dấu `[NEEDS CLARIFICATION: ...]`—bạn cần trả lời các điểm này trước khi chuyển sang Plan.
Trong Claude Code, nhập: ``` /speckit-specify ``` Sau đó tác tử sẽ yêu cầu mô tả tính năng. Ở bước này, hãy dùng ngôn ngữ thông thường, không dùng thuật ngữ kỹ thuật: ``` Tôi muốn có biểu mẫu đăng ký trong ứng dụng. Người dùng nhập email và mật khẩu, nhận email xác nhận, rồi sau khi xác nhận được đưa đến bảng điều khiển. Xác nhận hết hạn sau 48 giờ. Nếu email vẫn chưa xác nhận, xóa tài khoản trong 5 phút sau hạn đó; không bao giờ xóa tài khoản đã xác nhận. ``` Ví dụ minh họa đã làm rõ dung sai xóa 5 phút sau hạn 48 giờ. Với sản phẩm thật, xác nhận dung sai trước Plan; hạn chính xác 48 giờ cần thiết kế và test cưỡng chế yêu cầu mạnh hơn. Tác nhân tạo `specs/001-registration/spec.md`; mở ra sẽ thấy cấu trúc như sau: ```markdown # Đặc tả tính năng: Đăng ký người dùng **Feature Branch**: `001-registration` **Created**: 2026-05-31 **Status**: Draft **Input**: User Description: "Tôi muốn có biểu mẫu đăng ký..." ## User Scenarios & Testing *(bắt buộc)* ### Câu chuyện người dùng chính Là người dùng mới, tôi muốn đăng ký tài khoản bằng xác nhận email, để có thể truy cập bảng điều khiển với danh tính đã xác minh. ### Kịch bản chấp nhận 1. **Given** tôi đang ở trang đăng ký, **When** tôi gửi email và mật khẩu hợp lệ, **Then** tôi nhận được email xác nhận trong vòng 1 phút. 2. **Given** tôi đã nhấp vào liên kết xác nhận trong vòng 48 giờ, **When** tôi đến bảng điều khiển, **Then** tôi thấy email của mình được xác nhận trong hồ sơ. 3. **Given** tôi chưa xác nhận tại hạn 48 giờ, **When** cleanup chạy trong 5 phút tiếp theo, **Then** tài khoản bị xóa và email được giải phóng đăng ký lại. 4. **Given** tài khoản vừa dưới 48 giờ hoặc đã xác nhận, **When** cleanup chạy, **Then** tài khoản không bị xóa. ## Requirements *(bắt buộc)* ### Yêu cầu chức năng - **FR-001**: Hệ thống PHẢI chấp nhận đăng ký qua [CẦN LÀM RÕ: chỉ email/mật khẩu, hay cả SSO/OAuth?] - **FR-002**: Hệ thống PHẢI gửi email xác nhận trong vòng 60 giây - **FR-003**: Xác nhận PHẢI hết hạn tại 48 giờ; hệ thống PHẢI xóa tài khoản vẫn chưa xác nhận chậm nhất 5 phút sau hạn đó và KHÔNG ĐƯỢC xóa tài khoản đã xác nhận - **FR-004**: Hệ thống PHẢI ghi nhật ký mọi lần thử đăng ký trong [CẦN LÀM RÕ: lưu nhật ký trong bao lâu - 30 ngày, 90 ngày, hay mãi mãi?] ### Thực thể chính - User: email, password_hash, email_verified_at, created_at, deleted_at - ConfirmationToken: token, user_id, expires_at, used_at ## Tiêu chí thành công *(bắt buộc)* - **SC-001**: 95% email xác nhận được gửi trong vòng 60 giây (p95) - **SC-002**: 0 trường hợp vô tình xóa tài khoản đã xác nhận - **SC-004**: Không xóa trước 48 giờ; mọi tài khoản đủ điều kiện còn chưa xác nhận bị xóa khi tuổi không quá 48 giờ 5 phút dưới tải đã thử - **SC-003**: Tỷ lệ hoàn tất đăng ký > 60% (từ lúc mở biểu mẫu đến bảng điều khiển) ``` Hãy chú ý đến các dấu `[NEEDS CLARIFICATION: ...]`. Spec Kit cố ý chèn chúng ở bất cứ đâu mà tác tử không nhận được câu trả lời rõ ràng từ văn bản của bạn. Trước khi chuyển sang giai đoạn Plan, bạn phải trả lời chúng thủ công trong `spec.md` hoặc chạy `/speckit-clarify`; tác tử sẽ lần lượt hỏi bạn về các điểm chưa rõ trong cuộc hội thoại. Trong Spec Kit, lệnh tích hợp `/speckit-clarify` thay cho câu nói “hãy hỏi tôi”. Hiệu quả giống nhau: bạn không chuyển sang Plan cho đến khi không còn dấu `[NEEDS CLARIFICATION]` nào trong `spec.md`. Không nên có công nghệ trong `spec.md`. Không đề cập React, Postgres, Prisma hay Redis. Đặc tả mô tả cách hệ thống hoạt động từ góc độ người dùng và doanh nghiệp. Ngăn xếp công nghệ sẽ được chọn ở giai đoạn tiếp theo. ## Claude làm gì trong giai đoạn Plan?
Điểm chính Lệnh `/speckit-plan` nhận đặc tả hoàn chỉnh và tạo kế hoạch kỹ thuật: dùng công nghệ nào, kiến trúc ra sao, gồm những mô-đun, thực thể dữ liệu và hợp đồng API nào. Kế hoạch được ghi vào `specs/###-feature/plan.md`, hợp đồng được xuất ra thư mục `contracts/` riêng, còn mô hình dữ liệu nằm trong `data-model.md`. Ở bước này, Claude đã biết ngăn xếp công nghệ của bạn từ CLAUDE.md và constitution, vì vậy kế hoạch phù hợp với dự án hiện có thay vì đề xuất “viết lại tất cả bằng Rust”.
Khi `spec.md` đã sẵn sàng, chạy: ``` /speckit-plan ``` Bạn có thể đưa gợi ý công nghệ trực tiếp vào lệnh: ``` /speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email ``` Claude đọc ba nguồn: `spec.md`, `CLAUDE.md` (hoặc `memory/constitution.md`) và mã hiện có trong repo. Đầu ra là `plan.md` với cấu trúc đại khái như sau: ```markdown # Kế hoạch triển khai: Đăng ký người dùng ## Bối cảnh kỹ thuật - Framework: Next.js 14 App Router - Cơ sở dữ liệu: PostgreSQL qua Prisma - Email: Resend (một kênh gửi duy nhất) - Xác thực dữ liệu: lược đồ Zod trong thư viện dùng chung - Xác thực: NextAuth.js với nhà cung cấp thông tin đăng nhập ## Quyết định kiến trúc ### 1. Lưu trữ token Token được lưu trong DB (bảng ConfirmationToken), không phải trong JWT. Lý do: cần thu hồi phía máy chủ khi đăng ký lại bằng email. ### 2. Gửi email Gửi bất đồng bộ qua cron `/api/cron/send-confirmation`, chạy ngay sau khi đăng ký. Resend xử lý việc thử lại. ### 3. Cron tự động xóa Chạy `/api/cron/cleanup-unconfirmed` mỗi phút. Chỉ xóa hàng có created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL. Ví dụ đã làm rõ cho phép trễ tối đa 5 phút. Kiểm độ trễ scheduler và thời gian hoàn tất theo ngưỡng; lỡ ngưỡng là lỗi, không phải cleanup hằng ngày thành công. ## Mô hình dữ liệu Xem data-model.md ## Hợp đồng API Xem contracts/ - POST /api/auth/register - POST /api/auth/confirm - GET /api/auth/resend-confirmation ## Các giai đoạn triển khai 1. Di trú cơ sở dữ liệu (lược đồ Prisma + tệp di trú) 2. Các tuyến API (3 endpoint) 3. Giao diện người dùng: biểu mẫu đăng ký + trang xác nhận thành công 4. Cron job (gửi + dọn dẹp) 5. Mẫu email 6. Kiểm thử tích hợp ``` `data-model.md` sẽ mô tả các thực thể và mối quan hệ giữa chúng. `contracts/` sẽ chứa các bản phác thảo hợp đồng API (dưới dạng OpenAPI YAML hoặc kiểu dữ liệu yêu cầu/phản hồi TypeScript). Đây không phải mã—mà là ý định Claude sẽ chuyển thành các tuyến thực tế sau này. Ưu điểm chính của giai đoạn Plan là ngữ cảnh sạch. Claude không cố ghi nhớ đồng thời cả đặc tả lẫn phần triển khai. Trước hết, Claude suy nghĩ thấu đáo, ghi quyết định vào tệp, rồi mới chuyển sang giai đoạn tiếp theo. Tiếp theo là lệnh không bắt buộc `/speckit-analyze`. Lệnh này chạy sau giai đoạn Tasks và trước Implement: nó rà soát bộ `spec.md + plan.md + tasks.md` để tìm mâu thuẫn, đồng thời kiểm tra xem kế hoạch và nhiệm vụ đã bao phủ mọi yêu cầu trong đặc tả hay chưa. Lệnh không chỉnh sửa tệp; nó chỉ tạo báo cáo. Về cơ bản, đây là bước kiểm tra sơ bộ chính thức trước khi triển khai. ## Cách chia công việc thành nhiệm vụ (Tasks)
Điểm chính Lệnh `/speckit-tasks` chia kế hoạch thành các nhiệm vụ cụ thể. Mỗi nhiệm vụ có các quan hệ phụ thuộc, ước tính và dấu cho biết “có thể chạy song song” hay “phải chạy tuần tự”. Đầu ra là `tasks.md`, nơi nhiệm vụ dùng định dạng checklist `[ ] T-001: ...`. Sau đó, bạn có thể giao các nhiệm vụ này cho `/speckit-implement` triển khai hoặc chuyển thành GitHub Issues bằng `/speckit-taskstoissues`—rồi phân công cho nhóm hoặc nhiều phiên Claude Code chạy song song.
Khi đã có `spec.md` và `plan.md`, chạy: ``` /speckit-tasks ``` Claude mở rộng kế hoạch thành `tasks.md`: ```markdown # Nhiệm vụ: Đăng ký người dùng ## Giai đoạn 1: Cơ sở dữ liệu (không phụ thuộc) - [ ] T-001: Thêm mô hình User vào prisma/schema.prisma (an toàn khi chạy song song) - [ ] T-002: Thêm mô hình ConfirmationToken vào prisma/schema.prisma (sau T-001) - [ ] T-003: Tạo migration `add-user-registration` (sau T-002) ## Giai đoạn 2: Hợp đồng API (không phụ thuộc) - [ ] T-004: Tạo lược đồ Zod trong shared/validation/auth.ts - [ ] T-005: Định nghĩa kiểu TypeScript trong shared/types/auth.ts (sau T-004) ## Giai đoạn 3: Tuyến (phụ thuộc Giai đoạn 1+2) - [ ] T-006: Triển khai POST /api/auth/register - [ ] T-007: Triển khai POST /api/auth/confirm - [ ] T-008: Triển khai GET /api/auth/resend-confirmation ## Giai đoạn 4: Giao diện (chạy song song với Giai đoạn 3) - [ ] T-009: Tạo trang /register với biểu mẫu - [ ] T-010: Tạo trang /register/confirm/[token] - [ ] T-011: Tạo trang /register/success ## Giai đoạn 5: Cron + tích hợp (phụ thuộc Giai đoạn 3+4) - [ ] T-012: Cron /api/cron/send-confirmation - [ ] T-013: Cron /api/cron/cleanup-unconfirmed - [ ] T-014: Mẫu email registration-confirmation.tsx - [ ] T-015: Kiểm thử tích hợp (Playwright), gồm cleanup ngay trước 48h, đúng 48h, xóa trước 48h 5m, lỗi job trễ và bảo vệ tài khoản đã xác nhận ## Ghi chú - T-001, T-004, T-009-T-011 an toàn khi chạy song song (các tệp khác nhau) - T-002 xung đột với T-001 (cùng tệp: schema.prisma) - chạy tuần tự - T-006 cần T-003 (đã áp dụng migration) và T-005 (các kiểu dữ liệu) ``` Hãy chú ý các dấu `parallel-safe` và `after T-NNN`. Đây là đồ thị phụ thuộc cho phép bạn chạy nhiều giai đoạn song song về sau. Toàn bộ cách Spec Kit tăng tốc dựa trên cơ chế này: một số nhiệm vụ có thể giao cho năm phiên Claude Code khác nhau cùng lúc, trong khi những nhiệm vụ khác phải chạy tuần tự nghiêm ngặt. Spec Kit tự động thực hiện việc này chỉ bằng một lệnh, ngay khi cài đặt xong. Lệnh không bắt buộc `/speckit-taskstoissues` nhận `tasks.md` và tạo GitHub Issues từ danh sách, mỗi issue có liên kết quay lại `spec.md`. Cách này hữu ích nếu bạn làm việc theo nhóm hoặc muốn theo dõi tiến độ qua GitHub Projects. ## Cách triển khai bằng tác tử con (Implement)
Điểm chính Giai đoạn cuối `/speckit-implement` bắt đầu triển khai. Claude xử lý `tasks.md` từ trên xuống, đánh dấu `[x]` khi hoàn thành từng nhiệm vụ. Bạn có thể chạy nhiều phiên Claude Code song song—mỗi phiên phụ trách một giai đoạn. Trong mỗi phiên, Claude khởi chạy các tác tử con cho những loại công việc khác nhau: một tác tử rà soát mã, một tác tử kiểm tra và một tác tử viết tài liệu README. Đây là “1000 tác tử con chạy song song” mà Anthropic đã viết về khi phát hành Opus 4.8—trong Spec Kit, đó chỉ đơn giản là một cách làm việc, không phải sản phẩm riêng.
``` /speckit-implement ``` Claude bắt đầu với nhiệm vụ đầu tiên trong `tasks.md`. Mỗi nhiệm vụ trải qua một chu trình ngắn: đọc các tệp liên quan, viết diff, chạy kiểm thử, đánh dấu `[x]`. Tác tử con sẽ tự động được gọi khi cần: một tác tử riêng để rà soát mã, một tác tử để chạy linter và một tác tử để kiểm tra hồi quy. Và riêng về quy tắc: Trong Spec Kit, chu trình này được chính thức hóa. Bạn có `spec.md` làm nguồn sự thật, `plan.md` cho các quyết định kỹ thuật và `tasks.md` làm checklist. Nếu Claude đi chệch hướng ở bất kỳ bước nào, bạn quay lại đặc tả và nói: “Điều đó không khớp với FR-003; hãy làm lại.” Không cần những câu lệnh dài kiểu “hãy nhớ những gì chúng ta đã thảo luận...” — toàn bộ lịch sử nằm trong các tệp. Nếu đã kết nối [Dynamic Workflows trong Opus 4.8](https://ailoot.ai/blog/vi/claude-code-dynamic-workflows/), bạn có thể đưa Spec Kit vào chế độ tự động hóa hoàn toàn: một lệnh `/speckit-implement` để Claude song song hóa công việc, tổng hợp kết quả và kiểm tra chúng. Giới hạn là 1000 tác tử con cùng lúc. Với hầu hết tính năng, 10-30 tác tử là đủ. Khi mọi ô `[x]` đã được đánh dấu và bước kiểm tra ở phần tiếp theo trả về “Converged”, bạn rà soát PR (hoặc một loạt PR nếu có nhiều nhiệm vụ) rồi gộp nó. Các tạo phẩm—`spec.md`, `plan.md`, `tasks.md`—vẫn nằm trong repo làm tài liệu của tính năng. Một năm sau, bạn sẽ không phải đảo ngược kỹ thuật để suy ra logic từ mã. ## Cách kiểm tra xem tác tử có bỏ sót điều gì không (Converge)
Điểm chính Sau Implement, phiên bản Spec Kit hiện tại có bước kiểm tra tên là `/speckit-converge`. Tác tử đối chiếu mã hoàn chỉnh với `spec.md`, `plan.md` và `tasks.md`. Nếu mọi thứ khớp, nó trả lời “Converged” và không đụng đến các tệp. Nếu phát hiện thiếu sót, nó thêm chúng thành nhiệm vụ mới ở cuối `tasks.md`. Sau đó, bạn chạy lại `/speckit-implement`, rồi chạy lại `/speckit-converge` cho đến khi nhận được “Converged.”
``` /speckit-converge ``` Đầu tiên, tác tử tóm tắt những gì đã tìm thấy, kèm mức độ nghiêm trọng, rồi đưa ra một trong hai kết quả. “Converged” nghĩa là không có gì bị bỏ sót, `tasks.md` không thay đổi dù chỉ một byte và bạn có thể chuyển sang bước rà soát. “Tasks appended” nghĩa là phát hiện thiếu sót, chúng đã được thêm vào mục Convergence trong `tasks.md`, và tác tử cho biết có bao nhiêu mục. Converge không chỉnh sửa hay xóa mã; thao tác ghi duy nhất của nó là thêm nhiệm vụ mới vào `tasks.md`. Vì vậy, bạn có thể chạy lệnh này mà không phải lo lắng, nhưng chỉ sau khi `/speckit-implement` đã xử lý xong `tasks.md` hiện tại. Mỗi lượt tiếp theo sẽ tìm thấy ít thiếu sót hơn. ## Spec Kit khác CLAUDE.md và Plan Mode như thế nào?
Điểm chính Đây là câu hỏi thường gặp khi so sánh những công cụ này. Câu trả lời ngắn gọn: CLAUDE.md là “hợp đồng lao động” của tác tử, một nguồn sự thật duy nhất cho toàn bộ dự án. Plan Mode là bước lập kế hoạch một lần trước một yêu cầu cụ thể. Spec Kit là toàn bộ vòng đời của một tính năng: từ mô tả đến triển khai, với các tạo phẩm trong repo. Chúng không thay thế nhau; chúng kết hợp thành một hệ thống ba lớp: ngữ cảnh toàn cục (CLAUDE.md) → ngữ cảnh dự án (constitution của Spec Kit) → ngữ cảnh tính năng (spec.md + plan.md + tasks.md).
So sánh chúng theo 5 đặc điểm: | Đặc điểm | CLAUDE.md | Plan Mode | Spec Kit | |----|----|----|----| | Thời điểm chạy | Mỗi phiên | Theo yêu cầu (Shift+Tab hoặc /plan) | Bằng lệnh slash /speckit-\* | | Thời hạn | Toàn bộ dự án | Một phiên | Một tính năng | | Vị trí | Thư mục gốc repo | Trong ngữ cảnh Claude | `specs/###-feature/*` | | Nội dung lưu trữ | Ngăn xếp, quy tắc, bảng thuật ngữ | Kế hoạch hiện tại + quan sát | spec + plan + tasks + contracts | | Mẫu | Tự do (quy tắc repo) | Không có | Markdown có cấu trúc | | Vai trò phù hợp nhất | Quy tắc dự án và ngăn xếp công nghệ | Kiểm tra lại trước thay đổi lớn | Vòng đời tính năng đầy đủ: từ WHAT đến CODE | Theo thuật ngữ Spec Kit, đây là `.specify/memory/constitution.md`. Khi khởi tạo, Spec Kit có thể dùng CLAUDE.md hiện có làm nền tảng cho constitution hoặc tạo một tệp riêng bên cạnh. Thường tôi giữ CLAUDE.md làm “hợp đồng” toàn cục (ngăn xếp, bảng thuật ngữ, quy trình triển khai), còn dùng constitution của Spec Kit cho các quy tắc riêng của tính năng—ví dụ: “mọi biểu mẫu đều được xác thực qua Zod; không kiểm tra thủ công.” Mối liên hệ với Plan Mode đơn giản hơn. Plan Mode là chế độ nhanh “lập kế hoạch trước khi viết mã” trong một phiên duy nhất. Chế độ này phù hợp với thay đổi nhỏ (sửa lỗi, tái cấu trúc một hàm). Với tính năng lớn, Plan Mode không đáp ứng tốt vì cửa sổ ngữ cảnh của một phiên quá nhỏ cho kế hoạch dài 3000 dòng—như tôi giải thích trực tiếp trong buổi trực tiếp: Spec Kit là công cụ kỹ thuật ngữ cảnh cụ thể. Nó chuyển “tấm khăn trải bàn kiến trúc” từ cuộc trò chuyện vào các tệp. Spec.md nằm trong repo và mỗi phiên Claude mới lại đọc nó—bạn không phải nhắc lại. Cấu hình cho một dự án lớn: 1. **CLAUDE.md** - ngăn xếp, bảng thuật ngữ, những điều không được làm. Tệp nằm ở thư mục gốc. 2. **.specify/memory/constitution.md** cho Spec Kit—các quy tắc riêng cho quy trình này. 3. **specs/001-feature-A/spec.md, plan.md, tasks.md** - tính năng đầu tiên. 4. **specs/002-feature-B/spec.md, plan.md, tasks.md** - tính năng thứ hai. 5. Với công việc hằng ngày, dùng `/speckit-implement` (cho nhiệm vụ đã sẵn sàng) hoặc `/plan` (kiểm tra nhanh trước khi thay đổi). ## Những trường hợp thực tế nào đang hoạt động hiệu quả?
Điểm chính Phương pháp Spec Kit và SDD đã tạo ra kết quả đo lường được tại các công ty lớn. AWS trong dự án khám phá thuốc: 95% logic nghiệp vụ được tạo từ đặc tả, tiết kiệm hơn 80 giờ cho một tính năng. Rackspace Technology: 52 tuần công việc được rút xuống còn 3 tuần, hiệu suất tăng hơn 90%. Bản thân Spec Kit thu hút 107.000 sao GitHub trong 8 tháng.
Các trường hợp cụ thể: - **AWS Kiro - tác tử khám phá thuốc.** Trong [bài đăng trên blog AWS Industries](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) đề ngày 18 tháng 2 năm 2026, nhóm mô tả dự án TargetID. Ba nhà phát triển, ba tuần, một tác tử khám phá thuốc. Số liệu trong bài viết: Kiro tạo ra hơn 95% mã logic nghiệp vụ, tiết kiệm hơn 80 giờ phát triển. Ngoài ra: “Tài liệu README do Kiro viết giúp tiết kiệm ước tính 8 giờ” và “giảm 40% số chu trình lặp lại giữa prompt và sửa lỗi.” - **Rackspace Technology.** Trong cùng bài blog AWS, Rackspace cho biết: “hoàn thành 52 tuần công việc ước tính chỉ trong 3 tuần”, “hiệu suất tăng 90%”. Đây không còn là tính năng nhỏ—mà là toàn bộ dự án doanh nghiệp. - **Mức tăng trưởng của GitHub Spec Kit.** Tốc độ tăng trưởng này là dấu hiệu rõ ràng cho thấy phương pháp đang chiếm thêm thị phần. Với người đọc, điều này có nghĩa phương pháp không chỉ là lý thuyết: các nhóm nghiêm túc đã đưa nó vào sản xuất. ## Khi nào Spec Kit KHÔNG phù hợp?
Điểm chính Spec Kit không phù hợp trong mọi trường hợp. Có ba nhóm ngoại lệ rõ ràng: chỉnh sửa nhỏ (sửa lỗi, đổi tên biến), thử nghiệm và nguyên mẫu (khi chính việc chưa biết mình muốn gì là mục đích của vibe coding), và mã cũ có trạng thái phức tạp (khi đặc tả trở nên lỗi thời nhanh hơn thời gian bạn viết xong). Có những phê bình nghiêm túc về các trường hợp này. Nên biết các lập luận để không lãng phí thời gian viết đặc tả khi nó không giúp ích.
**Không phù hợp #1 - chỉnh sửa nhỏ.** Nếu nhiệm vụ là “đổi tên một biến”, “sửa lỗi chính tả trong nội dung” hoặc “thêm nhật ký”, trải qua Specify → Plan → Tasks sẽ lâu hơn chính thao tác chỉnh sửa. Với chỉnh sửa nhỏ, Plan Mode hoặc một câu lệnh trực tiếp trong Claude Code sẽ nhanh hơn. **Không phù hợp #2 - thử nghiệm trực tiếp.** Khi bạn chưa biết mình muốn gì và cần “khám phá” giao diện hoặc nhanh chóng lắp một nguyên mẫu để xem “có ổn không”, thì đặc tả chẳng có ích gì. Giá trị nằm chính ở việc bạn đang ứng biến. Ở cấp độ “chơi với một ý tưởng”, chính vibe mới hiệu quả chứ không phải đặc tả. **Không phù hợp #3 - mã cũ có trạng thái phức tạp.** Một phản biện mạnh: “Thực tế thay đổi nhanh hơn đặc tả.” Ví dụ về tính phí thuê bao: nhóm mô tả chu kỳ tính phí và quy tắc thuế, rồi một tuần sau bộ phận Tài chính yêu cầu VAT châu Âu—đặc tả đã lỗi thời trước khi phát hành. Khi logic nghiệp vụ thay đổi nhanh, việc duy trì đặc tả trở thành gánh nặng. Một rủi ro khác là cảm giác kiểm soát giả tạo: cấu trúc rất thanh nhã nhưng tác tử thường bỏ qua chỉ dẫn hoặc ngược lại, làm theo mẫu quá máy móc. Kết quả là mã đúng về cấu trúc nhưng không phù hợp với repo cụ thể của bạn—đặc tả không đảm bảo tác tử hiểu nó theo đúng ý bạn. Tháng 4 năm 2026, các nhà phân tích ngành cảnh báo về mô hình thác nước: viết một đặc tả lớn trước khi viết mã là con đường từng khiến ngành thất bại, từ thời các tài liệu yêu cầu dài 200 trang. Kể từ đó, các kỹ sư luôn thận trọng với cách tiếp cận này, và sự thận trọng ấy là có cơ sở. **Nên làm gì.** Tôi đề xuất một quy tắc đơn giản: so sánh độ lớn tính năng với thời gian cần để viết đặc tả. Nếu tính năng mất dưới 2 giờ để triển khai, đừng viết đặc tả—Plan Mode nhanh hơn. Nếu tính năng mất một tuần, nhất định hãy dùng Spec Kit; thời gian tiết kiệm được sẽ bù gấp năm lần cho một giờ viết đặc tả. Trong khoảng từ 2 giờ đến một tuần, hãy tự cân nhắc, dù cá nhân tôi vẫn viết đặc tả cho cả tính năng nửa ngày vì tạo phẩm trong repo đáng giá hơn 30 phút tiết kiệm được. ## Tiếp theo: tích hợp Spec Kit vào dự án như thế nào?
Điểm chính Bước đầu tiên dễ nhất là thử Spec Kit với một tính năng nhỏ mới, không phải toàn bộ dự án hiện có. Cài đặt công cụ, khởi tạo trong repo, chạy `/speckit-specify` cho một tính năng và xem các tạo phẩm. Sau một hoặc hai tuần, bạn sẽ có cảm nhận khi nào nên chuyển sang dùng công cụ và khi nào nên tiếp tục với câu lệnh nhanh. Phương pháp hoàn chỉnh kết hợp CLAUDE.md + Spec Kit + Skills + tác tử con.
Kế hoạch cụ thể cho 7 ngày tiếp theo: - **Ngày 1.** Cài uv và Spec Kit (5-10 phút). Kiểm tra các lệnh `/speckit-*` đã xuất hiện trong Claude Code chưa. Đừng thử áp dụng chúng cho dự án hiện có—hãy bắt đầu với dự án mới. - **Ngày 2.** Chọn một tính năng thực tế bạn định xây dựng. Chạy `/speckit-specify` với mô tả tự do. Mở `spec.md`, đọc và trả lời mọi dấu `[NEEDS CLARIFICATION]`. Đừng vội chuyển sang Plan. - **Ngày 3.** Chạy `/speckit-plan` cùng gợi ý về ngăn xếp công nghệ. Đọc `plan.md`, đặc biệt là phần Architecture Decisions. Nếu có gì không phù hợp, hãy sửa thủ công. - **Ngày 4-5.** Chạy `/speckit-tasks`, sau đó `/speckit-analyze` để kiểm tra lại bộ spec, plan và tasks, rồi chạy `/speckit-implement`. Theo dõi cách Claude đánh dấu `[x]` trong `tasks.md`. Có thể Claude sẽ mắc kẹt ở đâu đó—điều đó bình thường. Quay lại `spec.md`, làm rõ yêu cầu rồi chạy lại `/speckit-implement` với một nhiệm vụ cụ thể. Khi đã hoàn thành các nhiệm vụ, chạy `/speckit-converge` rồi lặp lại chuỗi Implement và Converge đến khi nhận được câu trả lời “Converged.” - **Ngày 6-7.** Rà soát PR (hoặc loạt PR). Gộp chúng. Đọc `spec.md` và `plan.md`—đó là tài liệu về tính năng của bạn cho năm tới. Bạn cũng có thể đọc song song các tài liệu sau: - [Cách thiết lập CLAUDE.md năm 2026](https://ailoot.ai/blog/vi/claude-md-template/) - nền tảng cho constitution của Spec Kit. - [Plan Mode trong Claude Code](https://ailoot.ai/blog/vi/claude-code-plan-mode/) - lựa chọn nhanh cho nhiệm vụ nhỏ. - [Kỹ thuật ngữ cảnh năm 2026](https://ailoot.ai/blog/vi/context-engineering/) - vì sao Spec Kit hoạt động. - [Skills, Subagents, MCP hay Plugins](https://ailoot.ai/blog/vi/skills-subagents-mcp-plugins-claude-code/) - những gì cần thêm vào Spec Kit cho quy trình của bạn. - [Dynamic Workflows trong Claude Code](https://ailoot.ai/blog/vi/claude-code-dynamic-workflows/) - cách khởi chạy nhiều tác tử con cùng lúc trong giai đoạn Implement.
### Nguồn tham khảo - [GitHub Spec Kit - kho mã nguồn](https://github.com/github/spec-kit) - [GitHub Spec Kit - tài liệu chính thức](https://github.github.com/spec-kit/) - [Spec-Driven Development - văn bản phương pháp chính thức](https://github.com/github/spec-kit/blob/main/spec-driven.md) - [Mẫu spec - GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) - [Blog AWS Industries - Từ đặc tả đến sản xuất: tác tử khám phá thuốc Kiro trong 3 tuần (ngày 18 tháng 2 năm 2026)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) - [Tài liệu Claude Code - Tác tử con](https://code.claude.com/docs/en/sub-agents) - [Tài liệu Claude Code - Skills](https://code.claude.com/docs/en/skills) - [Tài liệu Claude Code - Commands](https://code.claude.com/docs/en/commands)
Quy trình ngữ cảnh hoàn chỉnh: bản sao AI + Second Brain + Context Engineering. Xem thêm tài liệu trên [Ailoot](https://ailoot.ai/). ## Câu hỏi thường gặp ### Vì sao cleanup hằng ngày không đủ yêu cầu xóa sau 48 giờ? Tài khoản tới hạn ngay sau lượt ngày có thể chờ gần thêm một ngày. Làm rõ độ trễ chấp nhận trong spec, chọn lịch phù hợp và thử ngưỡng 48 giờ lẫn độ trễ tối đa. ### Làm gì khi plan.md mâu thuẫn spec.md? Quay lại yêu cầu, giải quyết trước triển khai. Cập nhật spec, plan, task và kiểm tra chấp nhận cùng nhau, dùng Analyze và kiểm tra triển khai để xác minh cùng hành vi đã thống nhất. ## Ailoot · Công ty và danh mục dự án của công ty Ailoot dựa trên kinh nghiệm vận hành tích lũy, cơ sở khách hàng lớn, dịch vụ ổn định và việc kiểm soát KPI liên tục. Công ty và danh mục dự án của công ty: hàng triệu khách hàng; doanh số hàng tỷ mỗi tháng. Ailoot áp dụng kinh nghiệm vận hành này để cung cấp quyền truy cập API vào các tính năng AI trong sản phẩm của khách hàng, tác tử, ứng dụng và quy trình tự động hóa.