Hướng Dẫn Toàn Diện Cho Người Mới Bắt Đầu Về Khung GSD (Get Shit Done) Cho Claude Code

Nếu bạn đã và đang sử dụng Claude Code, chắc hẳn bạn đã từng gặp phải “bức tường” quen thuộc: mọi thứ ban đầu diễn ra suôn sẻ, Claude viết mã hoàn hảo, nhưng rồi đột nhiên, khi ngữ cảnh đạt khoảng 50%, chất lượng bắt đầu suy giảm. Mã trở nên cẩu thả, các yêu cầu bị bỏ qua, và Claude bắt đầu “súc tích hơn” (thực chất là cắt giảm các chi tiết quan trọng). Hiện tượng này được gọi là suy giảm ngữ cảnh (context rot), và đó là lý do hàng đầu khiến việc lập trình bằng AI đôi khi bị đánh giá thấp.

Khung GSD (Get Shit Done) ra đời để giải quyết triệt để vấn đề này. Bài viết này sẽ cung cấp một hướng dẫn chi tiết, giúp bạn nắm bắt mọi khía cạnh của GSD để tối ưu hóa quy trình phát triển phần mềm với Claude Code.

GSD Là Gì Và Tại Sao Nó Lại Quan Trọng?

GSD là một hệ thống phát triển hướng đặc tả (spec-driven development) và meta-prompting mã nguồn mở, nhẹ, được xây dựng dành riêng cho Claude Code. Được tạo ra bởi Lex Christopherson (còn được biết đến với biệt danh glittercowboy), GSD đã nhanh chóng trở nên phổ biến với hơn 31.000 lượt gắn sao trên GitHub và được tin dùng bởi các kỹ sư tại Amazon, Google, Shopify và Webflow.

Cốt lõi của GSD là một mục tiêu duy nhất: duy trì chất lượng hoạt động đỉnh cao của Claude Code trong suốt dự án của bạn, bất kể quy mô hay độ phức tạp. GSD thực hiện điều này bằng cách chia dự án thành các nhiệm vụ nhỏ, được định nghĩa rõ ràng. Mỗi nhiệm vụ sẽ được thực thi trong một cửa sổ ngữ cảnh 200K token tươi mới bởi các tác nhân phụ chuyên biệt. Phiên làm việc chính của bạn được giữ gọn nhẹ, chỉ sử dụng 30-40% ngữ cảnh, trong khi các công việc nặng nhọc được xử lý trong các môi trường biệt lập, nguyên vẹn.

“Đó không phải là phép thuật. Đó chỉ là kỹ thuật ngữ cảnh cực kỳ tốt được gói gọn trong một quy trình làm việc không làm cản trở bạn.”

— Lex Christopherson, Người sáng tạo GSD

Tầm Quan Trọng Của GSD: Trước Và Sau

Thực tế của Claude Code khi không có một khung làm việc hỗ trợ:

GSD đảm bảo mỗi nhiệm vụ đều chạy trong “vùng ngọt” 0-30% ngữ cảnh. Luôn luôn như vậy.

Không Có GSD:

• Bắt đầu một dự án trong Claude Code.
• 3-4 nhiệm vụ đầu tiên diễn ra tuyệt vời.
• Ngữ cảnh đầy dần.
• Chất lượng suy giảm âm thầm.
• Bạn phải khởi động lại phiên làm việc, mất ngữ cảnh, lặp lại.
• Mã không nhất quán tích tụ.

Với GSD:

• Xác định dự án của bạn một lần.
• GSD tạo ra một lộ trình với các giai đoạn.
• Mỗi nhiệm vụ chạy trong một ngữ cảnh tác nhân phụ tươi mới.
• Chất lượng duy trì nhất quán từ nhiệm vụ 1 đến nhiệm vụ 100.
• Lịch sử git sạch sẽ với các commit nguyên tử.
• Mọi thứ được ghi lại và có thể truy vết.

Cài Đặt Khung GSD Chỉ Trong Vài Phút

Bắt đầu với GSD cực kỳ đơn giản. Chỉ cần một lệnh duy nhất:

npx get-shit-done-cc@latest

Trình cài đặt sẽ hỏi bạn hai điều:

1. Môi trường Runtime: Chọn Claude Code (hoặc OpenCode, Gemini CLI, Codex, Copilot, Antigravity nếu bạn sử dụng).
2. Vị trí: Toàn cục (Global – cho tất cả các dự án) hoặc Cục bộ (Local – chỉ cho dự án hiện tại).

Đối với người mới bắt đầu, tôi khuyên dùng cấu hình Claude Code + Global.

Xác Minh Cài Đặt

Mở Claude Code và chạy lệnh sau để xác minh cài đặt:

/gsd:help

Nếu bạn thấy menu trợ giúp, vậy là mọi thứ đã sẵn sàng!

Chế Độ Bỏ Qua Quyền (Recommended)

GSD tạo ra nhiều tác nhân chạy lệnh. Việc bị nhắc phê duyệt mọi lệnh git commit và date sẽ làm mất đi mục đích của nó. Bạn nên sử dụng chế độ bỏ qua quyền hoặc cấu hình quyền cụ thể:

claude --dangerously-skip-permissions

Hoặc, thêm các quyền chi tiết vào tệp .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(date:*)",
      "Bash(echo:*)",
      "Bash(cat:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)"
    ]
  }
}

Quy Trình Làm Việc Của GSD: Từng Bước Chi Tiết

GSD tuân thủ một chu trình 6 bước có kỷ luật. Hãy hình dung nó như một vòng đời phát triển phần mềm thu nhỏ, nhưng không có sự phức tạp của các quy trình doanh nghiệp:

New Project -> Discuss Phase -> Plan Phase -> Execute Phase -> Verify Work -> Complete Milestone

Hãy cùng đi sâu vào từng bước:

Bước 1: Khởi Tạo Dự Án Của Bạn

/gsd:new-project

Đây là nơi mọi thứ bắt đầu. GSD sẽ:

1. Phỏng vấn bạn: Hỏi các câu hỏi cho đến khi nó hiểu đầy đủ dự án của bạn (mục tiêu, hạn chế, ưu tiên công nghệ, các trường hợp ngoại lệ).
2. Nghiên cứu: Khởi tạo các tác nhân song song để điều tra lĩnh vực (thư viện, thực tiễn tốt nhất, cạm bẫy).
3. Trích xuất yêu cầu: Phân tách những gì thuộc về phiên bản v1, v2 và ngoài phạm vi.
4. Tạo lộ trình: Ánh xạ các yêu cầu vào các giai đoạn có thể thực thi.

Bạn phê duyệt lộ trình, và bạn đã sẵn sàng xây dựng.

Các tệp được tạo:

• PROJECT.md – Tầm nhìn dự án của bạn (luôn được tải để tham khảo ngữ cảnh).
• REQUIREMENTS.md – Các yêu cầu đã được xác định phạm vi với khả năng truy vết theo giai đoạn.
• ROADMAP.md – Các giai đoạn được ánh xạ tới các yêu cầu.
• STATE.md – Tài liệu trạng thái sống động cho các quyết định và vấn đề.
• .planning/research/ – Các phát hiện nghiên cứu.

Mẹo chuyên nghiệp: Hãy chuẩn bị một mô tả chi tiết. Bạn càng cụ thể ngay từ đầu, GSD càng ít cần hỏi thêm các câu hỏi tiếp theo. Bao gồm mục tiêu, người dùng mục tiêu, tính năng cốt lõi, hạn chế và ưu tiên ngăn xếp công nghệ.

Bước 2: Thảo Luận Giai Đoạn

/gsd:discuss-phase 1

Đây là bước mà hầu hết người mới bắt đầu thường bỏ qua – đừng làm vậy. Đây là nơi bạn định hình việc triển khai.

Lộ trình của bạn chỉ có một hoặc hai câu cho mỗi giai đoạn. Điều đó không đủ ngữ cảnh để xây dựng thứ bạn hình dung. GSD phân tích giai đoạn và xác định các khu vực “xám”:

• Các tính năng trực quan? – Bố cục, mật độ, tương tác, trạng thái rỗng.
• API/CLI? – Định dạng phản hồi, xử lý lỗi, cờ.
• Hệ thống nội dung? – Cấu trúc, giọng điệu, chiều sâu.

Đối với mỗi khu vực “xám”, GSD đặt ra các câu hỏi có mục tiêu. Câu trả lời của bạn sẽ được đưa vào CONTEXT.md, sau đó trực tiếp cung cấp thông tin cho việc lập kế hoạch và thực thi.

Tại sao điều này quan trọng: Nếu không có bước này, Claude sẽ đưa ra các giả định. Với bước này, Claude sẽ xây dựng chính xác những gì bạn hình dung.

“Lập kế hoạch hai lần. Prompt một lần.” — Mauvis Ledford

Bước 3: Lập Kế Hoạch Giai Đoạn

/gsd:plan-phase 1

GSD hiện tại sẽ:

1. Nghiên cứu: Cách triển khai giai đoạn này (dựa trên CONTEXT.md của bạn).
2. Lập kế hoạch: Tạo 2-3 kế hoạch nhiệm vụ nguyên tử trong cấu trúc XML.
3. Xác minh: Kiểm tra các kế hoạch so với các yêu cầu, lặp lại cho đến khi chúng vượt qua.

Mỗi kế hoạch đủ nhỏ để thực thi trong một cửa sổ ngữ cảnh tươi mới. Đây là bí quyết – không có nhiệm vụ nào bị suy giảm ngữ cảnh.

Dưới đây là ví dụ về một kế hoạch nguyên tử:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Hướng dẫn chính xác. Không cần đoán. Xác minh được tích hợp sẵn.

Bước 4: Thực Thi Giai Đoạn

/gsd:execute-phase 1

Đây là lúc bạn ngồi lại và xem GSD hoạt động. Nó sẽ:

1. Nhóm các kế hoạch thành các làn sóng: Các nhiệm vụ độc lập chạy song song, các nhiệm vụ phụ thuộc chờ đợi.
2. Khởi tạo các tác nhân phụ tươi mới: Mỗi tác nhân nhận 200K token chỉ để triển khai.
3. Commit theo từng nhiệm vụ: Mỗi nhiệm vụ hoàn thành có commit git nguyên tử riêng.
4. Xác minh theo mục tiêu: Kiểm tra mã nguồn cung cấp đúng những gì giai đoạn đã hứa.

WAVE 1 (song song)          WAVE 2 (song song)          WAVE 3
  +-----------+ +-----------+  +-----------+ +-----------+  +-----------+
  | User      | | Product   |  | Orders    | | Cart      |  | Checkout  |
  | Model     | | Model     |  | API       | | API       |  | UI        |
  +-----------+ +-----------+  +-----------+ +-----------+  +-----------+
       |            |               ^            ^               ^
       +------------+---------------+------------+               |
           Dependencies flow forward through waves

Bạn có thể rời đi, quay lại với công việc đã hoàn thành cùng với lịch sử git sạch sẽ.

Bước 5: Xác Minh Công Việc Của Bạn

/gsd:verify-work 1

Các bài kiểm tra tự động kiểm tra xem mã có biên dịch và vượt qua không. Nhưng liệu tính năng này có hoạt động đúng như bạn mong đợi? GSD sẽ:

1. Trích xuất các sản phẩm có thể kiểm thử: Những gì bạn có thể làm được bây giờ.
2. Dẫn dắt bạn qua từng sản phẩm: “Bạn có thể đăng nhập bằng email không?” Có/Không.
3. Chẩn đoán lỗi: Khởi tạo các tác nhân gỡ lỗi để tìm ra nguyên nhân gốc rễ.
4. Tạo kế hoạch sửa lỗi: Sẵn sàng để thực thi lại.

Nếu mọi thứ đều vượt qua, hãy tiếp tục. Nếu có gì đó bị hỏng, hãy chạy lại /gsd:execute-phase.

Bước 6: Lặp Lại Và Hoàn Thành

/gsd:discuss-phase 2
/gsd:plan-phase 2
/gsd:execute-phase 2
/gsd:verify-work 2
...
/gsd:complete-milestone

Lặp lại qua tất cả các giai đoạn. Khi hoàn thành, /gsd:complete-milestone sẽ lưu trữ mọi thứ và gắn thẻ phát hành. Bạn muốn xây dựng thêm? /gsd:new-milestone sẽ bắt đầu phiên bản tiếp theo.

Chế Độ Nhanh (Quick Mode): Cho Các Nhiệm Vụ Nhỏ Hơn

Không phải mọi thứ đều cần quy trình làm việc đầy đủ. Đối với các tác vụ đặc biệt:

/gsd:quick
> What do you want to do? "Add dark mode toggle to settings"

Chế độ nhanh cung cấp cho bạn các đảm bảo của GSD (commit nguyên tử, theo dõi trạng thái) mà không cần nghiên cứu và lập kế hoạch toàn diện. Bạn có thể thêm các cờ để có công việc kỹ lưỡng hơn:

• --discuss – Thu thập sở thích của bạn trước.
• --research – Nghiên cứu các phương pháp tiếp cận trước khi lập kế hoạch.
• --full – Thêm kiểm tra kế hoạch và xác minh sau thực thi.

Các cờ có thể kết hợp: /gsd:quick --discuss --research --full mang đến trải nghiệm đầy đủ trong một gói nhẹ hơn.

Bảng Tổng Hợp Lệnh GSD Thiết Yếu

Dưới đây là một danh sách các lệnh GSD quan trọng mà bạn cần biết:

Cấu Hình: Hồ Sơ Mô Hình (Model Profiles)

GSD cho phép bạn kiểm soát mô hình Claude nào mà mỗi tác nhân sử dụng. Điều này rất quan trọng để quản lý chi phí:

Bạn có thể thay đổi hồ sơ bằng lệnh:

/gsd:set-profile budget

Những Sai Lầm Thường Gặp (Và Cách Khắc Phục)

Dựa trên hàng trăm báo cáo của người dùng trên Reddit, Hacker News và Twitter, đây là những sai lầm mà mọi người mới bắt đầu đều mắc phải:

1. Sử Dụng GSD Cho Các Nhiệm Vụ Nhỏ

Quy trình làm việc đầy đủ của GSD tạo ra nhiều tác nhân. Đối với việc thay đổi màu sắc hoặc sửa lỗi chính tả, điều đó là quá mức cần thiết.

Khắc phục: Sử dụng /gsd:quick cho các tác vụ nhỏ, hoặc chỉ cần trực tiếp nhắc Claude.

2. Bỏ Qua Giai Đoạn Thảo Luận

/gsd:discuss-phase tồn tại vì Claude đưa ra các giả định khi bạn không chỉ định sở thích. Bỏ qua nó có nghĩa là bạn sẽ phải lặp lại nhiều hơn sau này.

Khắc phục: Dành 5-10 phút trong giai đoạn thảo luận. Nó sẽ tiết kiệm hàng giờ tranh luận sau đó.

3. Không Ánh Xạ Codebase Hiện Có

Bắt đầu GSD trên một dự án hiện có mà không có ngữ cảnh sẽ dẫn đến xung đột với các mẫu hiện có.

Khắc phục: Luôn chạy /gsd:map-codebase trước cho các dự án brownfield (dự án hiện có).

4. Phớt Lờ Chi Phí Token

GSD sử dụng nhiều token. Nhiều người dùng báo cáo đã nhanh chóng đốt hết giới hạn của gói Pro (20$/tháng). Một người dùng báo cáo tỷ lệ chi phí chung là 4:1 – cứ 1 token viết mã thì có 4 token dùng cho điều phối.

Khắc phục: Gói Max (100-200$/tháng) được khuyến nghị mạnh mẽ cho việc sử dụng GSD thường xuyên. Sử dụng hồ sơ mô hình budget cho các giai đoạn ít quan trọng hơn.

5. Mô Tả Dự Án Mơ Hồ

Thông tin đầu vào mơ hồ tại /gsd:new-project sẽ kích hoạt quá nhiều câu hỏi tiếp theo và nghiên cứu không tập trung.

Khắc phục: Chuẩn bị một mô tả chi tiết trước khi bắt đầu. Bao gồm: mục tiêu, người dùng mục tiêu, tính năng cốt lõi, hạn chế và ưu tiên ngăn xếp công nghệ.

6. Không Xóa Ngữ Cảnh Giữa Các Giai Đoạn

Để ngữ cảnh tích lũy qua các giai đoạn làm mất đi mục đích của GSD.

Khắc phục: Sử dụng lệnh clear giữa các giai đoạn chính để giữ cho phiên làm việc của bạn gọn nhẹ.

GSD So Với Các Framework Khác

Không gian phát triển hướng đặc tả đã bùng nổ. Dưới đây là cách GSD so sánh với các framework khác:

Điểm mạnh của GSD: Bạn là một nhà phát triển solo hoặc một nhóm nhỏ đang xây dựng một cái gì đó không hề tầm thường, và bạn muốn chất lượng nhất quán mà không cần các thủ tục phức tạp của doanh nghiệp.

Như một người dùng Hacker News đã nói:

“Tôi thích sự tập trung vào việc xác định những gì cần làm và các tiêu chí hoàn thành. Đây là những thực hành tuyệt vời dù có AI hay không.”

Kết Quả Thực Tế Từ Người Dùng GSD

Dưới đây là những gì người dùng thực tế đang báo cáo về GSD:

• Mauvis Ledford (LinkedIn): Dành 8 giờ thử nghiệm GSD, rút ngắn 2-3 ngày làm việc xuống còn khoảng 1 ngày.
• Steve Adams (Hacker News): Đã ủy quyền thành công việc tái cấu trúc Effect pipeline, phân tích lỗi DuckDB và kiểm tra bộ kiểm thử.
• Max Buckley (LinkedIn): Hoàn thành một dự án nghiên cứu kéo dài 6 tháng (so sánh GLiNER, Mistral 7B và Claude Haiku cho NER) chỉ trong vài ngày.
• Esteban Torres (Blog): GSD tạo ra mã chức năng chính xác ngay lần thực thi đầu tiên cho giao diện người dùng BlogWatcher, chỉ yêu cầu các chỉnh sửa nhỏ về phong cách.

Tuy nhiên, không phải ai cũng yêu thích nó. Một số người dùng thấy nó “quá chậm, quá chi tiết” đối với quy trình làm việc của họ, và những người khác báo cáo rằng chi phí chung không mang lại lợi ích cho các dự án đơn giản. Hãy biết trường hợp sử dụng của bạn.

Khi Nào Nên Dùng GSD Và Khi Nào Nên Bỏ Qua

Nên Sử Dụng GSD Khi:

• Xây dựng một ứng dụng đa trang hoặc tính năng phức tạp.
• Làm việc trên một dự án kéo dài nhiều phiên làm việc.
• Bạn cần chất lượng nhất quán trên hàng tá nhiệm vụ.
• Tái cấu trúc các codebase lớn hiện có.
• Bạn muốn lịch sử git sạch sẽ, có thể truy vết.

Nên Bỏ Qua GSD Khi:

• Sửa lỗi nhanh hoặc thay đổi chỉ một dòng.
• Tạo prototype/khám phá ban đầu.
• Bạn có ngân sách token eo hẹp (gói Pro).
• Nhiệm vụ đủ đơn giản chỉ cần một prompt duy nhất.

Mẹo Tối Ưu Quy Trình Làm Việc Với GSD

Sau khi nghiên cứu rộng rãi và nói chuyện với những người dùng GSD chuyên nghiệp, đây là những thủ thuật năng suất nổi bật:

1. Sử dụng các worktree git riêng biệt cho các tác vụ nhanh trong khi vẫn duy trì nhánh chính của bạn.
2. Kiểm tra các tính năng không chắc chắn với /gsd:quick --research trước khi cam kết với lộ trình của bạn.
3. Thiết kế token trước, components thứ hai, màn hình thứ ba – ngăn ngừa việc phải thiết kế lại cascade.
4. Ghi lại các ý tưởng lẻ tẻ với /gsd:add-todo thay vì làm chệch hướng giai đoạn hiện tại của bạn.
5. Sử dụng /gsd:stats để theo dõi tiến độ dự án và các chỉ số git của bạn.
6. Đối với các dự án brownfield, luôn chạy /gsd:map-codebase trước – điều này ngăn Claude “đối đầu” với các mẫu hiện có của bạn.

Tìm Kiếm Hỗ Trợ

Bạn có thể tìm kiếm sự giúp đỡ và cộng đồng GSD qua các kênh sau:

• Tài liệu chính thức: Tài liệu Mintlify của GSD rất tuyệt vời và chi tiết.
• Discord: Chạy /gsd:join-discord để tham gia cộng đồng (rất tích cực và hữu ích).
• Cộng đồng X: Hơn 1.200 thành viên chia sẻ mẹo và quy trình làm việc.
• GitHub Issues: Báo cáo lỗi và yêu cầu tính năng trên GitHub.

Lời Kết

GSD không làm cho Claude Code thông minh hơn, mà nó làm cho Claude Code đáng tin cậy hơn. Bằng cách giải quyết vấn đề suy giảm ngữ cảnh thông qua kỹ thuật ngữ cảnh có kỷ luật, mỗi nhiệm vụ đều nhận được toàn bộ sức mạnh của cửa sổ ngữ cảnh 200K của Claude.

Đường cong học tập là tối thiểu – cài đặt chỉ với một lệnh, tuân theo quy trình 6 bước, và để GSD xử lý sự phức tạp phía sau hậu trường. Người tạo ra GSD đã nói rất đúng:

“Sự phức tạp nằm ở hệ thống, không phải ở quy trình làm việc của bạn.”

Nếu bạn nghiêm túc trong việc xây dựng với AI, GSD xứng đáng là một khoản đầu tư. Không phải vì nó là phép thuật, mà vì nó là kỷ luật kỹ thuật được áp dụng cho các quy trình làm việc AI. Và trong một thế giới đầy hỗn loạn của việc “lập trình theo cảm hứng”, kỷ luật chính là siêu năng lực.

Bây giờ, hãy bắt tay vào “Get Shit Done”.