Xây dựng hệ thống quản lý tác vụ với Claude Code
Sau vài tháng làm việc với Claude Code trong một ứng dụng web phức tạp, tôi nhận ra mình thường xuyên lặp lại cùng một quy trình: đọc các issue trên Linear, phân rã chúng thành các phần có thể triển khai, rồi cẩn thận phối hợp các thay đổi trên API, ứng dụng web và các tác vụ nền.
Quy trình thủ công này tiêu tốn rất nhiều thời gian – thời gian mà tôi muốn dành cho các quyết định kiến trúc và giải các vấn đề thú vị. Vì vậy, tôi đã xây dựng một quy trình gồm hai lệnh đơn giản để xử lý phần việc hệ thống, nhường chỗ cho tôi tập trung vào các khía cạnh cần đến tư duy con người.
Thách thức: Mã nguồn thực tế thường rất lộn xộn
Khi làm việc với một ứng dụng có quy mô đáng kể, bạn sẽ phải đối mặt với:
- Hơn 50 file có liên kết chặt chẽ giữa các service
- Các mẫu kiến trúc cần đảm bảo tính nhất quán
- Quy trình chạy nền (chúng tôi dùng Temporal.io)
- Các thay đổi về API và lược đồ cơ sở dữ liệu
- Yêu cầu kiểm thử trên nhiều thành phần khác nhau
- Tích hợp với Linear, GitHub và quy trình triển khai
Khoảng cách giữa “đây là một issue trên Linear” và “đây là tính năng đã hoạt động” đòi hỏi rất nhiều công việc có tính hệ thống – quan trọng nhưng không sáng tạo.
Giải pháp: Hai lệnh tuỳ chỉnh
Tôi đã xây dựng hai lệnh hoạt động song song với nhau:
breakdown-linear-issue
– Phân rã tác vụ
Lệnh này đọc một issue trên Linear và tạo ra kế hoạch triển khai. Nó tự động hóa giai đoạn phân tích mà tôi thường làm thủ công:
- Phân tích mô tả issue và tiêu chí chấp nhận
- Ánh xạ yêu cầu vào cấu trúc mã nguồn hiện tại
- Xác định các file và dịch vụ cần thay đổi
- Tạo chuỗi các tác vụ có thể triển khai
- Ghi chú yêu cầu kiểm thử và các rủi ro có thể phát sinh
Kết quả là một file Markdown chứa các tác vụ cụ thể có thể được thực hiện độc lập.
process-task
– Thực thi
Lệnh này nhận một file tác vụ và thực hiện:
- Đọc đặc tả nhiệm vụ
- Phân tích trạng thái hiện tại của các file liên quan
- Thực hiện thay đổi theo đúng mẫu thiết kế của nhóm
- Chạy test và sửa các lỗi cơ bản
- Tạo commit với thông điệp mô tả rõ ràng
Ý tưởng cốt lõi: tách biệt giữa lập kế hoạch và thực thi.
Việc lập kế hoạch cần cái nhìn tổng thể, còn thực thi hiệu quả hơn khi tập trung vào từng phần riêng biệt.
Ví dụ thực tế: Thêm tính năng thông báo qua email
Hãy cùng xem tính năng tôi đã triển khai tháng trước.
Issue trên Linear: “Người dùng nên nhận email thông báo khi một số điều kiện được thỏa mãn, với tần suất khác nhau tùy theo cấp độ đăng ký.”
Bước 1: Phân tích chiến lược
/breakdown-linear-issue DEV-123
Lệnh này phân tích codebase và phát hiện rằng đây không chỉ đơn thuần là “thêm chức năng gửi email” mà liên quan đến:
- Thay đổi lược đồ database (ngưỡng thông báo, tùy chọn người dùng)
- Điều chỉnh workflow Temporal (tác vụ nền)
- Thêm endpoint API để quản lý thông báo
- Tích hợp với hệ thống mẫu email
- Xác thực theo cấp độ đăng ký
- Giới hạn tốc độ theo loại người dùng
- Thêm UI trên frontend để cấu hình thông báo
- Kiểm thử toàn diện trên mọi thành phần
Nó tạo ra 8 tác vụ riêng biệt với thứ tự phụ thuộc rõ ràng và phạm vi ước lượng.
Bước 2: Thực thi hệ thống
/process-task implement-notification-database-schema
/process-task implement-notification-workflow-system
/process-task implement-notification-api-endpoints
# ... và tiếp tục các task còn lại
Mỗi lệnh thực hiện phần việc của mình mà vẫn nhận thức được toàn bộ hệ thống.
Khi tạo API, nó tự động dùng middleware xác thực, mẫu kiểm tra dữ liệu, và chuẩn xử lý lỗi hiện có của chúng tôi.
Tại sao cách này hiệu quả?
1. Hiểu biết kiến trúc
Các lệnh này nắm rõ stack và quy ước của nhóm:
- Fastify + Prisma + Temporal.io
- Tích hợp với Auth0
- Lớp trừu tượng dịch vụ
- Yêu cầu test (>50% coverage API, >90% service)
2. Giữ ngữ cảnh
Không như AI hội thoại dễ quên bối cảnh, các lệnh này:
- Nhớ phần đã được triển khai
- Biết các thay đổi đang diễn ra
- Hiểu tính năng nằm ở đâu trong roadmap tổng thể
- Tuân thủ yêu cầu chất lượng mã nguồn cụ thể của nhóm
3. Kỷ luật trong thực thi
Quy trình 2 bước giúp tránh sai lầm phổ biến: nhảy vào code mà chưa hiểu đầy đủ vấn đề.
Bước phân tích buộc tôi phải cân nhắc toàn bộ phạm vi trước khi bắt đầu.
Quy trình tổng thể
Chu trình phát triển điển hình của tôi:
- Linear issue được tạo (từ PM hoặc phản hồi người dùng)
- Phân tích chiến lược:
breakdown-linear-issue
để hiểu toàn cảnh - Xem lại & điều chỉnh: tôi rà lại, thay đổi ưu tiên, chia nhỏ nếu cần
- Thực thi có hệ thống: dùng
process-task
cho từng tác vụ con - Kiểm thử tích hợp: chạy bộ test E2E
- Code review: tạo PR với đầy đủ ngữ cảnh
🔑 Tôi không thay thế tư duy kỹ sư, tôi hệ thống hóa cách thực thi tư duy đó.
Kỹ thuật triển khai (cho kỹ sư)
Các lệnh này hoạt động thông qua tích hợp MCP (Model Context Protocol) của Claude Code:
- API Linear: đọc issue, cập nhật trạng thái
- API GitHub: quản lý branch, PR, phân tích code
- Bộ nhớ ngữ cảnh: duy trì hiểu biết xuyên suốt các lần gọi lệnh
Chúng không chỉ là script — mà là các workflow AI hiểu codebase cụ thể và thích ứng theo yêu cầu.
Hiệu quả ra sao?
1. Chất lượng phân rã tác vụ (breakdown-linear-issue
)
Tôi theo dõi:
- So sánh giữa kế hoạch ban đầu và triển khai thực tế
- Liệu có bỏ sót thành phần lớn nào không
- Ước lượng có chính xác không
Tỷ lệ thành công:
~95% đủ chính xác để triển khai trực tiếp
~5% còn lại thường do:
- Các edge case lộ ra khi triển khai
- Phụ thuộc vào hệ thống khác không rõ ràng trong issue
Thường thất bại ở:
- Phức tạp frontend (responsive phức tạp)
- Quyền truy cập/ủy quyền bị bỏ sót
Làm tốt ở:
- Thay đổi database
- Cấu trúc endpoint API
- Phạm vi test
2. Chất lượng thực thi (process-task
)
Tôi theo dõi:
- Mức độ code tạo ra được dùng trực tiếp
- Tỷ lệ pass test
- Phản hồi từ code review
Tỷ lệ thành công lần đầu: ~85%
Sửa nhỏ (import thiếu, test chưa đúng): ~10%
Cần viết lại đáng kể: ~5%
Lần chạy thứ hai (qua Gemini review): đạt ~95% thành công
Làm tốt ở:
- Tuân thủ mẫu sẵn có (auth, validation, error)
- Viết test phù hợp và đầy đủ
- Giữ sự nhất quán giữa các component
Gặp khó ở:
- UI/UX không được mô tả rõ trong task
Đo lường tác động
Tôi bắt đầu theo dõi từ tháng đầu tiên:
1. Tốc độ phát triển
Trước:
- ~1.5 tính năng/tuần (đơn giản)
- 1 tính năng/2 tuần (phức tạp)
Sau:
- ~2 tính năng/tuần (đơn giản)
- 1.2 tính năng/tuần (phức tạp)
→ Tăng mạnh với tính năng tầm trung
2. Vòng review code
- Trước: trung bình 2.3 vòng
- Sau: 1.7 vòng
→ Ít comment kiểu “quên cập nhật test” hơn
3. Lỗi sản phẩm
- Không thay đổi rõ rệt về tỷ lệ bug
- Nhưng bug thường do logic nghiệp vụ, không phải do tích hợp
Nhìn nhận thực tế
Hệ thống này không phải phép màu. Nó giống như một lập trình viên junior cực kỳ tỉ mỉ:
- Không bao giờ mệt khi làm checklist
- Nhớ chính xác mọi quy ước trong code
- Đôi khi “không thấy rừng vì mải nhìn cây”
- Cần chỉ dẫn rõ ràng để làm việc hiệu quả
Giá trị lớn nhất: Sự nhất quán và kỹ lưỡng — chứ không phải sự sáng tạo.
Bức tranh lớn hơn
Không phải AI thay thế lập trình viên, mà là nâng tầm vấn đề chúng ta giải quyết.
Từ:
- "Cấu trúc endpoint API này sao cho đúng?"
- "Những file nào cần sửa?"
- "Mình có cập nhật test chưa nhỉ?"
Đến:
- "Trải nghiệm người dùng nào là hợp lý nhất?"
- "Tính năng này nằm ở đâu trong chiến lược sản phẩm?"
- "Kiến trúc nào bền vững nhất về lâu dài?"
Bắt đầu xây workflow riêng
Nếu bạn muốn xây dựng hệ thống tương tự:
- Xác định điểm đau – quyết định nào lặp đi lặp lại? bạn hay quên điều gì?
- Chuẩn hóa mẫu code – tài liệu hóa quyết định kiến trúc, chuẩn code, yêu cầu test
- Xây dần từng bước – bắt đầu với các lệnh đơn giản, mở rộng khi bạn học thêm
- Đo lường tác động – theo dõi tốc độ, tỷ lệ bug, chỉ số nhất quán
Mục tiêu không phải là hệ thống AI hoành tráng — mà là một công cụ khiến bạn trở thành kỹ sư hiệu quả hơn.
Kết luận
Claude Code không phải là phép màu.
Nhưng nếu bạn đầu tư thời gian dạy nó các mẫu code cụ thể và xây dựng các workflow có hệ thống, nó trở nên cực kỳ mạnh mẽ.
Các lệnh tôi xây dựng không chỉ là công cụ tăng năng suất — chúng là cách để mã hóa và mở rộng các thực hành tốt nhất trong kỹ thuật phần mềm.
Chúng giúp tôi làm việc có hệ thống hơn, kỹ lưỡng hơn, và nhất quán hơn.
All rights reserved