Cách thiết lập Spec Kit trong Claude Code năm 2026: Đặc tả thay cho câu lệnh

Vibe coding đã ra sao vào tháng 5 năm 2026?#

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—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, 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ì?#

Ý 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:

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.

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?#

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)#

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.

# 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:

uv --version

Bước 2. Cài Spec Kit. Một lệnh:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Kiểm tra:

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:

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:

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 và Plan Mode trong Claude Code.

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)#

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:

# Đặ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?#

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:

# 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)#

Khi đã có spec.md và plan.md, chạy:

/speckit-tasks

Claude mở rộng kế hoạch thành tasks.md:

# 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)#

/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, 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)#

/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?#

So sánh chúng theo 5 đặc điểm:

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ả?#

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 đề 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?#

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?#

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 - nền tảng cho constitution của Spec Kit.
• Plan Mode trong Claude Code - lựa chọn nhanh cho nhiệm vụ nhỏ.
• Kỹ thuật ngữ cảnh năm 2026 - vì sao Spec Kit hoạt động.
• Skills, Subagents, MCP hay Plugins - những gì cần thêm vào Spec Kit cho quy trình của bạn.
• Dynamic Workflows trong Claude Code - cách khởi chạy nhiều tác tử con cùng lúc trong giai đoạn Implement.

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.