Spec Kit của GitHub - phát triển phần mềm chất lượng cao nhanh hơn

• Phát triển theo đặc tả (Spec-Driven Development): một cách tiếp cận nhằm nâng đặc tả (Spec) từ vai trò công cụ hỗ trợ trong phát triển truyền thống thành đặc tả có thể thực thi, để trực tiếp tạo ra phần triển khai đang hoạt động từ đặc tả
  • Chuyển đổi thói quen lấy code làm trung tâm sang nhấn mạnh phát triển lấy ý định làm trung tâm, trong đó định nghĩa cái gì và tại sao trước, rồi mới cụ thể hóa như thế nào
  • Ý tưởng cốt lõi là tạo ra các đầu ra nhất quán thông qua đặc tả, đồng thời tự động hóa công việc lặp lại để giúp lập trình viên tập trung vào vấn đề của sản phẩm
• Spec Kit là bộ công cụ giúp chuyển đặc tả thành đầu ra có thể thực thi để tự động hóa việc triển khai theo cách này
• Sau khi cài đặt, dùng /specify để mô tả cái gì/tại sao, /plan để khai báo stack/kiến trúc, và /tasks để tạo đơn vị công việc
• Mục tiêu là giúp tổ chức thoát khỏi việc viết mã dùng chung không tạo khác biệt để tập trung vào kịch bản sản phẩm, như một framework thử nghiệm nhằm nâng cả chất lượng lẫn tốc độ thông qua phương pháp phát triển theo đặc tả

Triết lý cốt lõi: Core philosophy

• Tư duy đặc tả trước tiên với phát triển lấy ý định làm trung tâm, đặt cái gì lên trước và cụ thể hóa như thế nào sau
• Viết các đặc tả phong phú có guardrail và nguyên tắc tổ chức, đồng thời đi qua quá trình tinh chỉnh nhiều giai đoạn thay vì tạo code một lần là xong
• Hướng đến cách tận dụng khả năng diễn giải của mô hình AI tiên tiến để chủ động chuyển đặc tả thành kết quả có thể thực thi

Quy trình phát triển theo đặc tả với Spec Kit

• Spec Kit đặt đặc tả vào trung tâm của quy trình kỹ thuật để dẫn dắt triển khai, checklist và phân rã công việc, còn lập trình viên chủ yếu đóng vai trò chỉ đạo
  • Tác tử lập trình đảm nhiệm phần lớn công việc viết
• Quy trình gồm 4 giai đoạn, mỗi giai đoạn có checkpoint rõ ràng và không chuyển sang bước tiếp theo cho đến khi công việc hiện tại được xác minh đầy đủ
• Giai đoạn Specify: khi cung cấp mô tả cấp cao, tác tử lập trình sẽ tạo đặc tả chi tiết, tập trung vào hành trình người dùng, trải nghiệm và chỉ số thành công thay vì stack công nghệ
  • Lập bản đồ người dùng là ai, đang giải quyết vấn đề gì, cách tương tác và các kết quả quan trọng
  • Đây là một artifact sống tiếp tục phát triển theo hiểu biết ngày càng nhiều về người dùng
• Giai đoạn Plan: khi cung cấp stack, kiến trúc và các ràng buộc mong muốn, tác tử lập trình sẽ tạo kế hoạch kỹ thuật toàn diện
  • Bao gồm công nghệ tiêu chuẩn của công ty, tích hợp hệ thống legacy, tuân thủ quy định, mục tiêu hiệu năng, v.v.
  • Có thể yêu cầu nhiều biến thể kế hoạch để so sánh; nếu cung cấp tài liệu nội bộ thì các pattern kiến trúc có thể được tích hợp trực tiếp
• Giai đoạn Tasks: dựa trên đặc tả và kế hoạch, tác tử lập trình phân rã công việc thành các phần nhỏ có thể review
  • Mỗi công việc có thể được triển khai và kiểm thử độc lập, được thiết kế để AI có thể xác minh và theo dõi
  • Ví dụ, thay vì "xây dựng xác thực" thì sẽ cụ thể như "tạo endpoint đăng ký người dùng có kiểm tra định dạng email"
• Giai đoạn Implement: tác tử lập trình xử lý từng công việc một hoặc song song, còn lập trình viên review các thay đổi tập trung
  • Đặc tả cho biết cần xây gì, kế hoạch cho biết xây như thế nào, và tác vụ cho biết cần làm những gì
• Ở mỗi giai đoạn, lập trình viên thực hiện vai trò xác minh: suy ngẫm và tinh chỉnh, kiểm tra xem đặc tả có nắm đúng ý định không, kế hoạch có phản ánh đúng ràng buộc thực tế không, và có thiếu sót hay edge case nào không

Cách dùng Spec Kit trong workflow agentic

• Spec Kit hoạt động với các tác tử lập trình như GitHub Copilot, Claude Code, Gemini CLI, sử dụng một chuỗi lệnh đơn giản để chỉ đạo tác tử và tạo artifact
  • Cách này biến prompt mơ hồ thành ý định rõ ràng để thực thi đáng tin cậy
• Sau khi khởi tạo dự án, cung cấp prompt cấp cao bằng lệnh /specify thì tác tử lập trình sẽ tạo đặc tả hoàn chỉnh, tập trung vào "cái gì" và "tại sao" của dự án
• Với lệnh /plan, khi cung cấp định hướng kỹ thuật cấp cao, tác tử lập trình sẽ tạo kế hoạch chi tiết tôn trọng kiến trúc và ràng buộc
• Với lệnh /tasks, đặc tả và kế hoạch được phân rã thành danh sách công việc có thể thực thi, để tác tử lập trình dựa vào đó triển khai yêu cầu của dự án

Các giai đoạn phát triển: Development phases

• 0-to-1 (greenfield): hỗ trợ luồng tạo đặc tả → lập kế hoạch → tạo ứng dụng sẵn sàng cho production dựa trên yêu cầu cấp cao
• Khám phá sáng tạo: nhấn mạnh quy trình thử nghiệm nhiều stack/kiến trúc và pattern UX bằng triển khai song song
• Cải tiến dần (brownfield): phát triển tiến hóa lặp lại việc thêm tính năng, hiện đại hóa legacy, và điều chỉnh quy trình

3 kịch bản mà cách tiếp cận này hoạt động tốt

• Greenfield (zero-to-one): khi bắt đầu một dự án mới, thay vì code ngay thì tạo đặc tả và kế hoạch trước để đảm bảo AI xây đúng ý định, đồng thời cho ra kết quả tùy biến thay vì giải pháp chung chung dựa trên pattern phổ biến
• Công việc tính năng trên hệ thống hiện có (N-to-N+1): khi thêm tính năng vào codebase phức tạp, đặc tả giúp làm rõ cách tính năng mới tương tác với hệ thống hiện tại, còn kế hoạch mã hóa các ràng buộc kiến trúc để tạo ra code có cảm giác như phần gốc của hệ thống
  • Điều này giúp phát triển liên tục nhanh hơn và an toàn hơn, dù có thể cần các kỹ thuật context engineering nâng cao
• Hiện đại hóa legacy: khi xây lại hệ thống legacy mà ý định ban đầu đã bị thất lạc, quy trình Spec Kit giúp ghi lại logic nghiệp vụ cốt lõi vào đặc tả hiện đại và lập kế hoạch cho kiến trúc mới để AI tái xây dựng mà không mang theo technical debt

Prerequisites

• Cần Linux/macOS hoặc WSL2 trên Windows
• Chọn một tác tử AI trong Claude Code, GitHub Copilot, Gemini CLI, Cursor

[edunga1]

Làm tôi nhớ đến Copilot Workspace.

[cocofather]

Có vẻ như đây sẽ là nền tảng cho lập trình AI dựa trên ngôn ngữ tự nhiên.

[tested]

Ưu điểm của Spec Kit của GitHub là có thể dùng ngay cả trong GitHub Copilot.
Vì do GitHub tạo ra nên có lẽ là điều hiển nhiên? nhưng trước giờ nhiều công cụ khác lại dựa trên Claude.

[skageektp]

Làm tôi nhớ đến Kiro IDE.

[kandk]

Thú vị đấy. Nghe cũng có lý.

[xguru]

Liên kết giới thiệu chi tiết về SDD ở giữa bài khá hay. Dưới đây là bản tôi thử tóm tắt bằng AI.

Phát triển hướng đặc tả (Specification-Driven Development, SDD)

Đảo ngược quyền lực

• Đảo ngược luồng mà trước đây code là trung tâm còn PRD·tài liệu thiết kế chỉ đóng vai trò phụ trợ: đặc tả là bản gốc, còn code là biểu hiện được triển khai bằng ngôn ngữ·framework cụ thể
  • Đưa ra nhận định rằng khoảng cách thường trực giữa đặc tả và triển khai rất khó được xóa bỏ chỉ bằng cách bổ sung tài liệu hay siết chặt quy trình
  • Nếu đặc tả có thể thực thi và kế hoạch triển khai tạo ra code thì khoảng cách đó biến mất, chỉ còn sự chuyển đổi
• AI giúp có thể diễn giải đặc tả phức tạp và lập kế hoạch triển khai, nhưng tạo sinh không có cấu trúc sẽ gây hỗn loạn, vì vậy SDD đảm bảo chất lượng bằng cấu trúc chính xác và guardrail
• Bảo trì là hành vi tiến hóa đặc tả; ý đồ phát triển được biểu đạt bằng ngôn ngữ tự nhiên·tài sản thiết kế·nguyên tắc cốt lõi, còn code giữ vai trò chặng cuối
• Debug ưu tiên sửa đặc tả·kế hoạch triển khai hơn là sửa code sai; refactoring được định nghĩa lại là tái cấu trúc sự rõ ràng

Quy trình làm việc SDD trong thực tế

• Mài giũa ý tưởng thành PRD thông qua tương tác hội thoại với AI, và AI sẽ cụ thể hóa câu hỏi·edge case·tiêu chí chấp nhận
  • Chuyển yêu cầu·thiết kế thành hoạt động liên tục, hỗ trợ làm việc đặc tả theo nhánh ở cấp độ nhóm cùng review·versioning
• Research agent khám phá khả năng tương thích thư viện, hiệu năng, bảo mật và ràng buộc tổ chức (chuẩn DB·xác thực·chính sách triển khai), rồi tự động phản ánh vào đặc tả
• Từ PRD tạo ra kế hoạch triển khai, ánh xạ có thể truy vết giữa yêu cầu và quyết định kỹ thuật, đồng thời AI liên tục kiểm chứng mâu thuẫn·mơ hồ·thiếu sót
• Khi đặc tả·kế hoạch đã đủ ổn định thì bắt đầu sinh code, nhưng ban đầu sẽ dùng tạo sinh mang tính thăm dò để kiểm chứng tính khả thi
  • Khái niệm miền được chuyển thành data model, user story thành API endpoint, kịch bản chấp nhận thành test
• Metric·incident ở giai đoạn vận hành sẽ cập nhật lại đặc tả để phản ánh vào lần tái tạo tiếp theo; nút thắt hiệu năng được nâng thành yêu cầu phi chức năng, lỗ hổng bảo mật thành ràng buộc toàn cục

Vì sao SDD quan trọng lúc này

• Ngưỡng năng lực AI: giờ đã có thể tạo code hoạt động một cách đáng tin cậy từ đặc tả ngôn ngữ tự nhiên, đồng thời tự động hóa phần cơ học của việc dịch triển khai để hỗ trợ khám phá·khuếch đại sáng tạo
• Độ phức tạp bùng nổ: với nhiều dịch vụ·framework·dependency, việc duy trì sự nhất quán giữa ý đồ và triển khai ngày càng khó, nên cần căn chỉnh theo đặc tả của SDD
• Thay đổi tăng tốc: trong bối cảnh pivot thường xuyên, SDD xử lý thay đổi bằng tái tạo có hệ thống thay vì lan truyền thủ công qua tài liệu-thiết kế-code
  • Ví dụ, nó cho phép mô phỏng what-if và triển khai song song để mang lại độ linh hoạt trong ra quyết định

Các nguyên tắc cốt lõi

• Đặc tả = ngôn ngữ chung: đặc tả là sản phẩm hạng nhất, code là biểu hiện của stack cụ thể, và bảo trì là hành vi tiến hóa đặc tả
• Đặc tả có thể thực thi: tạo ra hệ thống vận hành được từ đặc tả ở mức chính xác·đầy đủ·không mơ hồ
• Tinh chỉnh liên tục: thực hiện kiểm chứng tính nhất quán thường trực chứ không phải cổng kiểm duyệt một lần
• Ngữ cảnh dựa trên nghiên cứu: liên tục thu thập hiệu năng·bảo mật·ràng buộc tổ chức để đưa vào đặc tả
• Phản hồi hai chiều: thực tế vận hành trở thành đầu vào cập nhật đặc tả
• Phân nhánh để khám phá: hỗ trợ tạo nhiều cách triển khai từ cùng một đặc tả theo các mục tiêu tối ưu như hiệu năng·khả năng bảo trì·UX·chi phí

Các cách tiếp cận triển khai

• Việc áp dụng hiện nay cốt lõi là kết hợp công cụ sẵn có và duy trì kỷ luật, có thể triển khai bằng các thành phần sau
  • AI assistant để lặp lại quá trình tinh chỉnh đặc tả
  • Research agent để thu thập ngữ cảnh kỹ thuật
  • Công cụ sinh code để chuyển đổi đặc tả → triển khai
  • Quản lý phiên bản phù hợp với workflow đặc tả trước
  • Kiểm tra dựa trên phân tích tính nhất quán bằng AI cho tài liệu đặc tả
• Nguyên tắc chung là coi đặc tả là nguồn chân lý duy nhất, còn code là đầu ra mà đặc tả yêu cầu

Tinh gọn SDD bằng command

• /specify: chuyển mô tả tính năng thành đặc tả có cấu trúc, đồng thời tự động hóa đánh số tự động, tạo nhánh, và cấu trúc thư mục dựa trên template
• /plan: tạo chuỗi gồm phân tích đặc tả → rà soát tuân thủ hiến pháp → dịch kỹ thuật → tài liệu hóa data model·API contract·test scenario → xác minh quickstart
• /tasks: đọc plan.md và các thiết kế liên quan để tạo danh sách tác vụ có thể thực thi, đồng thời đánh dấu tác vụ có thể song song và nhóm song song an toàn
• Ví dụ: tính năng chat
  • Đưa ra ví dụ về luồng rút ngắn khoảng ~12 giờ làm tài liệu theo cách truyền thống xuống còn khoảng 15 phút thiết lập nhờ tự động hóa đặc tả·kế hoạch·tác vụ
  • Các đầu ra gồm đặc tả, kế hoạch triển khai và cơ sở lý giải, API contract·data model, kịch bản quickstart, tasks.md đều được quản lý phiên bản trên nhánh

Sức mạnh của tự động hóa có cấu trúc

• Ngăn thiếu sót: template bao quát cả yêu cầu phi chức năng·xử lý lỗi
• Khả năng truy vết quyết định: mọi lựa chọn kỹ thuật đều được gắn với yêu cầu cụ thể
• Tài liệu sống: vì đặc tả tạo ra code, nên việc duy trì đồng bộ trở nên dễ dàng
• Lặp nhanh: khi yêu cầu thay đổi, có thể phản ứng trong đơn vị phút·giờ bằng tái tạo kế hoạch

Chất lượng dựa trên template

• Ngăn chi tiết triển khai xâm nhập quá sớm: duy trì mức trừu tượng bằng quy tắc tập trung vào WHAT/WHY, loại bỏ HOW
• Buộc đánh dấu điểm chưa chắc chắn: marker [NEEDS CLARIFICATION] giúp cấm phỏng đoán và thúc đẩy câu hỏi tường minh
• Tự rà soát theo checklist: triển khai quality gate bằng cách kiểm tra độ đầy đủ·độ rõ ràng·tiêu chí chấp nhận đo lường được
• Cổng hiến pháp: áp dụng kiểm tra ở giai đoạn trước (-1) như cổng đơn giản hóa (≤3 project), cổng chống trừu tượng hóa quá mức (dùng trực tiếp framework), cổng ưu tiên tích hợp (hợp đồng·contract test đi trước)
• Quản lý chi tiết theo lớp: phần code·chi tiết quá mức được tách vào implementation-details/ để giữ khả năng đọc
• Ưu tiên test: đảm bảo khả năng kiểm chứng bằng quy tắc tạo file·ưu tiên test theo thứ tự contract → integration → E2E → unit
• Kiềm chế giả định·tính năng suy đoán: tăng cường quản lý phạm vi bằng việc cấm tính năng suy đoán và nêu rõ điều kiện tiên quyết theo từng giai đoạn

Nền tảng hiến pháp

• Áp dụng hiến pháp phát triển với các nguyên tắc bất biến trong memory/constitution.md để giữ mọi triển khai nhất quán·đơn giản·chất lượng cao
  • Article I: Library-First — mọi tính năng bắt đầu như một thư viện độc lập để đảm bảo tính mô-đun
  • Article II: CLI Mandate — mọi thư viện phải cung cấp giao diện CLI hỗ trợ văn bản vào/ra·JSON để đảm bảo khả năng quan sát và dễ kiểm thử
  • Article III: Test-First — cấm triển khai trước khi test được phê duyệt và xác nhận thất bại (red), áp dụng nguyên tắc định nghĩa hành vi trước
  • Articles VII & VIII: Đơn giản hóa·chống trừu tượng hóa quá mức — tối thiểu số lượng project và tin cậy trực tiếp vào framework để kiềm chế over-engineering
  • Article IX: Test ưu tiên tích hợp — ưu tiên test gần với môi trường thực, đồng thời buộc contract test đi trước triển khai
• Dùng cổng Phase -1 của template để biến việc tuân thủ hiến pháp thành checklist, còn ngoại lệ sẽ ghi cơ sở nêu rõ trong Complexity Tracking
• Thông qua quy trình sửa đổi, cách áp dụng các nguyên tắc có thể tiến hóa nhưng triết lý cốt lõi vẫn được giữ nguyên

Sự chuyển đổi

• Mục tiêu không phải thay thế lập trình viên mà là tự động hóa bản dịch mang tính cơ học để khuếch đại năng lực con người và duy trì tính nhất quán giữa ý đồ và triển khai
• SDD thực hành chuyển đổi liên tục bằng cách để đặc tả tạo ra code, từ đó đặc tả·nghiên cứu·code cùng tiến hóa trong vòng phản hồi chặt chẽ

[amoplan]

Bạn đã dùng AI nào để tóm tắt vậy?

[xguru]

Tôi dùng GPT-5, và sử dụng một prompt khá dài do chính tôi sắp xếp để phục vụ việc tóm tắt.

[heycalmdown]

Tôi rất đồng cảm với ý tưởng này nên cuối tuần đã thử nghiệm một chút với một dự án mới, nhưng kết quả lại không tốt như kỳ vọng. Có vẻ nó vẫn cần được cải thiện nhiều. Trước hết, luồng hoạt động đại khái, như đã được giới thiệu nhiều lần, là như sau: Soạn hiến pháp → soạn spec → soạn task → triển khai

Vấn đề là

• file constitution.md là hướng dẫn cốt lõi về “sẽ phát triển như thế nào”, nhưng không chứa “ứng dụng này cuối cùng sẽ trở thành gì”
• spec.md là tài liệu mô tả một tính năng
• không có tài liệu master về “ứng dụng này là gì”
• đọc các cuộc thảo luận đang diễn ra trên GitHub thì có vẻ quan điểm là chain of specs rốt cuộc sẽ trở thành source of truth. Nghe vẫn hơi khó hiểu, nhưng cũng có thể tạm chấp nhận được.
• thông qua các lệnh /specify và /tasaks, rất nhiều tài liệu được tạo ra như là đầu ra (đúng thứ tôi muốn), nhưng có lẽ vì vậy mà context bị tiêu tốn rất nhanh (tôi đang dùng Claude Code)
• một khi bắt đầu đi vào triển khai thì lại tạm rời xa Spec Kit, và cuối cùng vẫn hoàn thiện phần triển khai bằng cách trò chuyện với Claude Code như bình thường
• khi dùng hết context rồi compaction hoặc bắt đầu session mới thì nó quên mất sự tồn tại của các tài liệu do Spec Kit tạo ra
• khi làm các công việc được định nghĩa trong tasks.md, đôi lúc lại ghi đè những gì đã làm tốt trước đó, hoặc trong quá trình sửa bug lại tạo thêm tính năng mới, nên ngày càng xa rời tasks.md. Tôi không hiểu ý nghĩa của việc lưu giữ vĩnh viễn tasks.md.

Trước mắt, kết luận tôi rút ra là như sau

• dù kết quả đầu ra có khác với ý tưởng ban đầu thì trước hết vẫn nên hoàn tất spec, rồi tạo spec mới để chỉnh sửa dần dần
• spec ban đầu chắc chắn sẽ phình to, nên có lẽ tốt hơn là đừng giải thích gì về chức năng của ứng dụng mà chỉ tạo boilerplate thôi
• khi làm ở mức PoC thì có lẽ tốt hơn là không nên dùng Spec Kit