Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 8 — Quy trình thực chiến: vận hành coding agent trên dự án thật

Đã đọc 0/9 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Ghép mọi thứ lại

Bảy bài trước cho bạn từng kỹ thuật. Bài này ghép chúng thành một quy trình vận hành áp dụng được cho một tính năng thật, từ đầu đến khi merge, cùng các tình huống khó thường gặp.

Quy trình chuẩn cho một tính năng

  • Chuẩn bị context bền: đảm bảo CLAUDE.md cập nhật (stack, quy ước, lệnh, định nghĩa xong).
  • Phân rã tác vụ: chia tính năng thành 3-6 bước nhỏ, mỗi bước một thay đổi mạch lạc.
  • Nạp context đúng: với mỗi bước, grep + đọc file liên quan + test liên quan; bỏ file thừa.
  • Prompt theo TCREV: mục tiêu, ràng buộc (gồm điều cấm), ví dụ mẫu, tiêu chí nghiệm thu.
  • Chạy feedback loop: agent viết → test/lint → sửa theo lỗi thật → xanh.
  • Chống ảo giác: yêu cầu xác nhận API tồn tại, dán output test, không tin lời suông.
  • Review diff: đọc git diff, kiểm tra phạm vi đúng, không refactor lan man.
  • Nén context giữa các bước: phiên dài thì tóm tắt tiến độ ra PROGRESS.md, mở phiên mới.

Ví dụ đầu-cuối

Tính năng: "Cho phép user đặt lại mật khẩu qua email."

Bước 1: model + migration token reset (đọc models/user.py, migrations/)
Bước 2: service tạo & xác thực token (mẫu: services/auth.py)
Bước 3: gửi email (dùng EmailClient, mẫu send_welcome_email)
Bước 4: route POST /password/reset (@rate_limit, @validate)
Bước 5: test end-to-end

Mỗi bước: nạp đúng file, prompt TCREV, chạy pytest phạm vi hẹp, review diff. Không làm cả 5 bước trong một prompt khổng lồ.

Xử lý tình huống khó

  • Agent đi lạc, refactor lung tung: dừng, thu hẹp phạm vi ("chỉ sửa file X"), thêm ràng buộc phủ định.
  • Agent lặp sửa-fail: đặt trần 3 vòng; nếu vẫn fail, tự đọc lỗi, thu hẹp bài toán, cho thêm context.
  • Context đầy, agent "lú": tóm tắt ra file, mở phiên mới sạch.
  • Agent bịa API: buộc grep xác nhận tồn tại; đưa định nghĩa thật vào context.
  • Thay đổi rủi ro cao (migration, xóa dữ liệu): yêu cầu agent trình bày kế hoạch + rollback trước khi chạy; bạn duyệt tay.

Khung vận hành PLAN-CONTEXT-ACT-VERIFY

PLAN    : chia nhỏ, xác định định nghĩa xong
CONTEXT : nạp đúng code + quy ước, bỏ nhiễu
ACT     : prompt TCREV, agent thực thi
VERIFY  : test/lint + review diff + chống ảo giác
(lặp lại cho từng bước nhỏ)

Checklist trước khi merge

  • [ ] Mỗi bước có test và đã pass (thấy output)
  • [ ] Diff đúng phạm vi, không thay đổi ngoài ý muốn
  • [ ] Tuân thủ quy ước trong CLAUDE.md
  • [ ] Không có API/thư viện bịa
  • [ ] Không có secret bị hard-code
  • [ ] Thay đổi rủi ro đã được người duyệt

Ánh xạ 7 kỹ thuật vào một bước

Để thấy mọi thứ khớp nhau, hãy soi bước 4 ("route POST /password/reset") của ví dụ trên qua lăng kính cả khóa học:

  • Bài 1 (signal/noise): chỉ nạp route mẫu + service reset, bỏ file không liên quan.
  • Bài 2 (context window): nếu phiên đã dài, tóm tắt trước khi làm bước này.
  • Bài 3 (CLAUDE.md): quy ước @rate_limit, layer route→service được nạp sẵn.
  • Bài 4 (retrieval): đọc route POST /login làm mẫu phong cách.
  • Bài 5 (prompt TCREV): mục tiêu + ràng buộc "không đổi API cũ" + tiêu chí test.
  • Bài 6 (chống ảo giác): buộc xác nhận service reset thật sự có hàm cần gọi.
  • Bài 7 (feedback loop): chạy pytest phạm vi route, sửa theo lỗi thật.
Một bước nhỏ mà dùng cả bảy kỹ thuật — đó là dấu hiệu bạn đã vận hành đúng. Khi thành thạo, các bước này chạy gần như phản xạ.

Sai lầm thường gặp

  • Làm cả tính năng trong một prompt — khó review, lỗi chồng lỗi. Chia nhỏ.
  • Bỏ review diff vì "test đã pass" — test có thể thiếu; mắt người vẫn cần cho phạm vi và ý đồ.
  • Không cập nhật CLAUDE.md khi quy ước đổi — agent lặp lại lỗi cũ ở dự án lâu dài.
  • Để agent tự chạy lệnh phá hủy — luôn gate migration/deploy/xóa dữ liệu.
  • Tin context window lớn nên không dọn — phiên dài vẫn cần nén để giữ tín hiệu.
  • Dùng lẻ tẻ vài kỹ thuật — sức mạnh đến từ việc ghép cả bảy vào từng bước nhỏ.

Kết

Context Engineering cho coding agent là một kỹ năng vận hành: thiết kế thông tin (bền + tức thời), khử nhiễu, ràng buộc rõ, và luôn verify bằng công cụ. Nắm quy trình PLAN-CONTEXT-ACT-VERIFY, bạn biến coding agent từ "trợ lý hay bịa" thành "kỹ sư tự kiểm chứng" làm được việc thật trên dự án thật.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi