Mất 9 ngày để ra mắt bkamp.ai cùng Claude Code, và tôi đã đóng gói bí quyết đó thành plugin bkit.

(bkit.ai)

2 điểm bởi agentkay 26 ngày trước | Chưa có bình luận nào. | Chia sẻ qua WhatsApp

bkit — Dùng Claude Code “đúng cách” bằng Context Engineering

Vào tháng 12 năm 2025, tôi đã ra mắt một dịch vụ tên là bkamp.ai.

11 microservice
Cổng thông tin dựa trên Next.js
AWS EKS + GitOps (ArgoCD)
Hạ tầng Terraform

Và tôi đã đưa toàn bộ hệ thống này lên production chỉ trong 9 ngày.

Chỉ có một mình tôi là developer,
AI được sử dụng là Claude Code.

Bài viết này không phải câu chuyện về việc “làm thật nhanh”

Nhiều trường hợp phát triển với AI thường được mô tả như sau:

“Làm xong bằng AI trong N ngày”
“Chỉ cần viết prompt tốt là được”

Nhưng điều tôi thực sự cảm nhận sau 9 ngày phát triển lại hoàn toàn khác.

AI đúng là viết code rất tốt.
Nhưng AI không quyết định phải viết cái gì.

Thứ quyết định điều đó cuối cùng vẫn là:

Thiết kế
Quy tắc
Đơn vị công việc
Cách kiểm chứng

Tôi định nghĩa điều này là Context Engineering.

Context Engineering là gì

Nói ngắn gọn:

Không phải viết prompt cho hay
mà là thiết kế chính môi trường làm việc của AI

Ví dụ:

Tạo tài liệu thiết kế trước
Chia đơn vị công việc dựa trên tài liệu
Tạo quy tắc để kiểm chứng kết quả
Tạo một chu trình có thể lặp lại

Tức là,

AI không còn là “người viết”
mà trở thành engine render theo context đã được xác định

Cách đã thực sự áp dụng ở bkamp

1. Day 0 — Tạo quy tắc trước khi viết code

Commit đầu tiên không có code nào cả.

Thay vào đó, tôi tạo ra những thứ sau:

.claude/CLAUDE.md (khoảng 150 dòng)
Tài liệu yêu cầu
Tài liệu chiến lược

Trong đó định nghĩa các nội dung sau:

Chu trình PDCA (Plan → Do → Check → Act)
Mọi kết quả đều do con người kiểm chứng
Lập kế hoạch bằng tiếng Hàn, code bằng tiếng Anh, commit bằng tiếng Hàn
Đơn vị công việc và cách triển khai

Chính khoảng 100 dòng quy tắc này đã quyết định toàn bộ quá trình phát triển về sau.

2. Đơn vị công việc không phải là “tính năng” mà là “tài liệu”

Thông thường người ta yêu cầu như thế này:

“Hãy tạo tính năng chat”

Nhưng trên thực tế, tôi làm việc như sau:

“Hãy triển khai mục 3.2 của tài liệu 7”

Sự khác biệt này là cực kỳ lớn.

Từ góc nhìn của AI:

Tính năng → cần diễn giải (bất định)
Tài liệu → triển khai nguyên trạng (mang tính xác định)

Kết quả là:

Độ biến động của đầu ra gần như biến mất

3. Mỗi ngày = một chu trình PDCA

Việc phát triển diễn ra theo cách này:

Plan (thiết kế)
Do (triển khai)
Check (phân tích gap)
Act (chỉnh sửa)

Và chu trình này được lặp lại theo đơn vị từng ngày.

Ưu điểm của cách làm này là:

Context luôn được giữ ở trạng thái mới nhất
Phạm vi công việc rõ ràng
AI hiểu rõ “lúc này cần làm gì”

4. Tạo checkpoint và mạnh dạn làm lại từ đầu

Đến ngày thứ 4, tôi đã tái cấu trúc toàn bộ frontend.

Nhưng trước đó có một việc nhất định phải làm:

Tạo checkpoint có thể rollback

Nhờ vậy:

Kể cả thất bại vẫn an toàn
→ có thể mạnh dạn thay đổi cấu trúc lớn

5. Chỉ gắn hạ tầng vào một lần ở giai đoạn cuối

Trong một ngày của ngày thứ 8, tôi đã gắn cùng lúc:

Terraform
Kubernetes
CI/CD
ArgoCD

Lý do điều này khả thi rất đơn giản:

Vì trước đó toàn bộ cấu trúc đã được căn chỉnh xong

Mẫu hình cốt lõi rút ra từ đây

Mẫu hình được lặp lại trong 9 ngày đó như sau:

Định nghĩa quy tắc trước
Tạo thiết kế trước
Làm việc dựa trên tài liệu
Lặp lại theo chu trình PDCA
Tạo checkpoint
Giải quyết mọi điểm không khớp trong tài liệu
Code là bước cuối cùng

Nhưng có thể duy trì cách này mãi không?

Đây là lúc vấn đề xuất hiện.

Cách làm này rất mạnh, nhưng:

Nó quá vất vả nếu con người phải liên tục duy trì

Phải luôn nhớ các quy tắc
Phải liên tục đồng bộ tài liệu
Phải tuân thủ PDCA mỗi lần

Vì vậy tôi đã tạo ra bkit.

bkit là gì

bkit là plugin cho Claude Code.

Nhưng nó không chỉ là một công cụ đơn thuần.

Đây là hệ thống hóa nguyên vẹn cách làm việc đã được dùng ở bkamp

Khái niệm quan trọng nhất: PDCA = state machine

bkit triển khai PDCA như sau:

Trạng thái: plan, design, do, check, act, v.v.
Chuyển trạng thái: quy tắc di chuyển giữa các trạng thái
Guard: kiểm tra điều kiện

Ví dụ:

Mức độ khớp giữa thiết kế và triển khai từ 90% trở lên → đạt
Nếu không → tự động chạy vòng lặp chỉnh sửa

Tức là,

“Review → chỉnh sửa” được lặp lại tự động

Cấu trúc biến Context Engineering thành hệ thống

bkit gồm các thành phần sau:

Skills (tri thức miền)
Agents (hành vi dựa trên vai trò)
PDCA state machine
Hệ thống tiêm context
Quality Gate (kiểm chứng)
Audit Log (ghi nhận)
Feedback Loop (lặp tự động)

Tóm gọn trong một câu:

Không phải là dùng AI
mà là xây dựng hệ thống nơi AI làm việc

Kết quả

Kết quả thu được với cách làm này như sau:

Tương thích liên tục với 79 phiên bản Claude Code
Hơn 4.000 bài test, 0 lỗi
Hơn 200 quy tắc kiểm chứng CI
Docs và Code đồng bộ hoàn toàn

Kết luận

Đây không phải câu chuyện AI trở nên thông minh hơn.

Đây là câu chuyện về việc công việc của con người được đẩy lên phía trước

Thiết kế trước
Quy tắc trước
Kiểm chứng trước

Sau đó:

AI thực thi
Hệ thống kiểm chứng
Con người phê duyệt

TL;DR

Chỉ dựa vào prompt thì có giới hạn
Context Engineering mới là cốt lõi
AI không phải người viết mà là bộ render
Workflow quan trọng hơn model

Liên kết

bkit: https://github.com/popup-studio-ai/bkit-claude-code
Trường hợp thực tế: https://bkamp.ai

Nếu bạn có ý kiến hoặc phản hồi về cách làm này, tôi rất hoan nghênh.