Bản đồ công trìnhTờ này lắp: Coding agent
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
AI là bộ khuếch đại
Báo cáo DORA 2025 về phát triển phần mềm có hỗ trợ AI đưa ra một thông điệp đáng nhớ: AI là bộ khuếch đại. Nó phóng to điểm mạnh sẵn có của một tổ chức, và phóng to cả điểm yếu. Đội có quy trình tốt (lô nhỏ, quản lý phiên bản chặt, tập trung vào người dùng) thu được nhiều lợi ích; đội lộn xộn thì lộn xộn nhanh hơn.
Với một doanh nghiệp nhỏ như Bánh Mộc, điều này có nghĩa: AI không thay được việc bạn hiểu nghiệp vụ, đặt ra quy trình và kiểm chứng kết quả. Nó làm cho những việc đó đáng giá hơn bao giờ hết. Bài này giúp bạn nhìn thẳng vào giới hạn của AI để dùng nó đúng chỗ.
Các kiểu lỗi đặc trưng của code do AI viết
Mỗi “nhân viên” có kiểu sai riêng. Nhân viên mới hay quên quy trình; nhân viên lâu năm hay chủ quan. AI cũng có những kiểu sai lặp đi lặp lại, xuất phát trực tiếp từ cách nó hoạt động mà bạn đã học ở bài LLM hoạt động thế nào02-01.
| Kiểu lỗi | Biểu hiện | Dấu hiệu nhận biết | Phòng ngừa |
|---|---|---|---|
| Bịa thư viện, bịa API | Import gói không tồn tại, gọi hàm không có | Cài gói lỗi, type check báo lỗi, gói lạ ít lượt tải | TypeScript nghiêm ngặt, kiểm tra gói trước khi cài, cấm thêm thư viện khi chưa hỏi |
| Sửa triệu chứng | Bọc try/catch nuốt lỗi, ép kiểu as any, sửa test cho qua, tắt quy tắc lint |
Diff có any, @ts-ignore, test bị xóa hoặc đổi kỳ vọng |
Dặn “sửa nguyên nhân gốc”, review diff tìm các dấu hiệu này, hook/CI chặn |
| Phình code | Thêm lớp trừu tượng không cần, viết hàm mới trùng hàm có sẵn, xử lý cả những trường hợp không thể xảy ra | Diff dài bất thường so với yêu cầu; nhiều hàm na ná nhau | Chỉ mẫu có sẵn, giới hạn phạm vi, yêu cầu “thay đổi nhỏ nhất đủ để đạt mục tiêu” |
| Sửa ngoài phạm vi | “Tiện tay” đổi tên, định dạng lại, sửa file không liên quan | Diff chạm nhiều file không nằm trong yêu cầu | Nêu rõ phạm vi, PR nhỏ, review danh sách file thay đổi |
| Test giả | Test kiểm tra mock thay vì hành vi; test luôn đúng | Test không bao giờ đỏ dù bạn cố tình làm hỏng code | Nêu ca kiểm thử bằng lời; thử làm hỏng code xem test có đỏ không |
| Bảo mật lỏng | Thiếu kiểm tra quyền ở server, tin dữ liệu từ client, lộ khóa | Logic quyền chỉ ở giao diện; khóa bí mật trong code phía trình duyệt | Quy ước trong AGENTS.md, review bảo mật riêng, test phân quyền |
| Sai ở trường hợp biên | Múi giờ, làm tròn tiền, hai người thao tác cùng lúc, dữ liệu rỗng | Chạy đúng với dữ liệu “đẹp”, sai với dữ liệu thật | Liệt kê trường hợp biên trong spec và test |
| Tuyên bố xong khi chưa xong | “Đã sửa và kiểm tra” nhưng không có bằng chứng | Báo cáo chung chung, không có output lệnh | Luôn đòi bằng chứng: lệnh, output, ảnh chụp |
Ví dụ: sửa triệu chứng và sửa nguyên nhân
Dashboard của Mộc OMS thỉnh thoảng bị lỗi trắng trang. Chị Lan nhờ agent sửa, và lần đầu nhận được bản “sửa” này:
// ❌ Sửa triệu chứng: nuốt lỗi, trả về 0 để trang không trắng
export async function countTodayOrders(branchId: string) {
try {
return await queryTodayOrderCount(branchId);
} catch {
return 0; // Trang không còn lỗi, nhưng dashboard báo "0 đơn" sai sự thật
}
}
Trang hết trắng, nhưng giờ dashboard có thể báo “0 đơn” trong khi bếp đang ngập việc, và không ai biết có lỗi. Đây là kiểu sửa nguy hiểm nhất: giấu lỗi đi. Khi được yêu cầu tìm nguyên nhân gốc, agent phát hiện lỗi xảy ra khi branchId rỗng (người dùng owner không thuộc chi nhánh nào):
// ✅ Sửa nguyên nhân: xử lý rõ ràng trường hợp owner xem tất cả chi nhánh
export async function countTodayOrders(branchId: string | null) {
// owner không gắn chi nhánh: đếm toàn chuỗi; lỗi khác vẫn được ném ra để Sentry ghi nhận
return branchId === null
? queryTodayOrderCountAllBranches()
: queryTodayOrderCount(branchId);
}
Việc nên và không nên giao cho AI
Hai câu hỏi phân loại
Với mỗi việc, hỏi hai câu:
- Sai thì hậu quả lớn đến đâu? Đổi màu nút sai: sửa trong một phút. Tính tiền cọc sai: mất tiền, mất lòng khách. Phân quyền sai: lộ dữ liệu toàn bộ khách hàng.
- Kiểm chứng kết quả dễ đến đâu? Có test tự động bắt được không? Nhìn ảnh chụp là biết không? Hay phải có chuyên môn sâu mới nhận ra?
- Sai thì hậu quả lớn?
- Kiểm chứng dễ?
- Giao thoải mái, nghiệm thu bằng kết quả
- Giao có giám sát chặt: kế hoạch duyệt trước, review kỹ diff
- Bạn giữ quyết định; AI chỉ phân tích, đề xuất; cân nhắc chuyên gia
Xem sơ đồ gốc (Hình 1)
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Một việc cần làm → Sai thì hậu quả lớn?
- Sai thì hậu quả lớn? → Kiểm chứng dễ? (Nhỏ, dễ sửa)
- Kiểm chứng dễ? → Giao thoải mái, nghiệm thu bằng kết quả (Dễ)
- Kiểm chứng dễ? → Giao, nhưng thêm test hoặc ảnh chụp trước khi nhận (Khó)
- Sai thì hậu quả lớn? → Kiểm chứng dễ? (Lớn: tiền, dữ liệu, bảo mật)
- Kiểm chứng dễ? → Giao có giám sát chặt: kế hoạch duyệt trước, review kỹ diff (Dễ, có test tốt)
- Kiểm chứng dễ? → Bạn giữ quyết định; AI chỉ phân tích, đề xuất; cân nhắc chuyên gia (Khó)
Bảng phân loại cho dự án như Bánh Mộc
| Giao thoải mái | Giao có giám sát chặt | Bạn giữ quyết định (AI hỗ trợ) |
|---|---|---|
| Giao diện theo design system có sẵn | Logic tính tiền, tiền cọc, phí giao | Phạm vi MVP, ưu tiên tính năng |
| Viết test cho logic đã có spec rõ | Phân quyền, chính sách RLS | Chọn kiến trúc, chọn nhà cung cấp |
| Sửa lỗi có thông báo lỗi rõ và test tái hiện | Migration database có dữ liệu thật | Đánh đổi chi phí – rủi ro – thời gian |
| Script một lần (nhập dữ liệu mẫu, đổi định dạng) | Tích hợp thanh toán, webhook | Diễn giải quy định pháp lý (dữ liệu cá nhân, hóa đơn) |
| Viết tài liệu, README, giải thích code | Xử lý dữ liệu cá nhân khách hàng | Quy trình làm việc với nhân viên |
| Tìm hiểu codebase, lập bản đồ | Cập nhật thư viện lớn | Thao tác trên môi trường production |
Một số việc AI làm kém hơn hẳn mức trung bình, cần đặc biệt lưu ý:
- Hiểu ngữ cảnh tổ chức chưa được ghi lại: AI không biết anh Tuấn ghét màn hình nhiều chữ, không biết Hà hay nhập đơn trên điện thoại khi đang trực tin nhắn. Phải nói cho nó.
- Thông tin mới sau ngày cắt kiến thức: quy định mới, phiên bản thư viện mới, thay đổi đơn vị hành chính.
- Quyết định có đánh đổi kinh doanh: AI liệt kê ưu nhược rất tốt, nhưng chọn bên nào là việc của người chịu trách nhiệm.
- Hệ thống rất lớn, nhiều phần liên kết chằng chịt: càng nhiều thứ cần giữ trong đầu cùng lúc, càng dễ vượt quá ngữ cảnh.
Chi phí: thuê bao, token và cách ước tính
Ba mô hình tính tiền
Tại thời điểm viết (2026), chi phí công cụ AI coding thường theo một trong ba mô hình (hoặc kết hợp). Giá cụ thể thay đổi thường xuyên, hãy xem trang giá chính thức của từng nhà cung cấp.
| Mô hình | Cách tính | Ưu điểm | Nhược điểm | Hợp với |
|---|---|---|---|---|
| Thuê bao | Phí cố định theo tháng, kèm hạn mức sử dụng | Dễ dự toán, không lo hóa đơn bất ngờ | Có thể chạm hạn mức giữa chừng; trả kể cả khi ít dùng | Cá nhân, đội nhỏ dùng hằng ngày |
| Theo token qua API | Trả theo số token vào và ra, giá khác nhau theo mô hình | Trả đúng mức dùng; dùng được trong CI, script | Khó dự toán, phiên dài có thể tốn bất ngờ | Tự động hóa, bot review, dùng không đều |
| Tín dụng (credit) | Mua gói điểm, mỗi thao tác trừ điểm | Đơn giản với người mới | Khó quy đổi ra công việc; vòng sửa đi sửa lại tiêu hết điểm | App builder, thử nghiệm |
Vì sao phiên agent dài tốn kém
Nhớ lại: mô hình đọc lại toàn bộ ngữ cảnh ở mỗi lượt. Một phiên agent gồm nhiều lượt (đọc file, chạy lệnh, sửa, chạy lại), mỗi lượt gửi lại cả ngữ cảnh đang có. Ngữ cảnh lại lớn dần theo thời gian. Kết quả: tổng token vào của một phiên tăng nhanh hơn nhiều so với độ dài phiên.
Ví dụ minh họa với số giả định (không phải số đo thật): ngữ cảnh lượt đầu khoảng 15 nghìn token (hướng dẫn hệ thống, AGENTS.md, prompt), mỗi lượt thêm khoảng 3 nghìn token (file đọc, output lệnh).
| Số lượt trong phiên | Ngữ cảnh ở lượt cuối (xấp xỉ) | Tổng token vào cả phiên (xấp xỉ) |
|---|---|---|
| 10 lượt | 42 nghìn | 285 nghìn |
| 30 lượt | 102 nghìn | khoảng 1,8 triệu |
| 60 lượt | 192 nghìn | khoảng 6,2 triệu |
Phiên dài gấp 6 lần nhưng tổng token vào gấp hơn 20 lần. Đây là lý do kinh tế đằng sau lời khuyên ở bài Context engineering02-05: phiên ngắn, tập trung, làm mới khi chuyển việc.
Nhiều nhà cung cấp có bộ nhớ đệm prompt (prompt caching): phần ngữ cảnh lặp lại giữa các lượt được tính giá thấp hơn đáng kể. Các agent thường tự tận dụng điều này, nên chi phí thực tế thấp hơn phép tính thô ở trên; nhưng xu hướng “phiên dài tốn hơn nhiều” vẫn đúng.
Công thức ước tính
Với mô hình trả theo token, chi phí một phiên xấp xỉ:
Điền ô trống rồi sao chép
Chi phí phiên ≈ (token vào không đệm × giá vào)
+ (token vào được đệm × giá vào có đệm)
+ (token ra × giá ra)
Bạn không cần tính tay. Hầu hết công cụ hiển thị mức dùng token hoặc chi phí theo phiên, và bảng điều khiển API có báo cáo theo ngày. Một hàm nhỏ giúp bạn ngoại suy từ số đo thật, với giá là tham số bạn tự điền từ trang giá chính thức:
// Ước tính chi phí AI hằng tháng từ số đo thực tế của một tuần chạy thử
type UsageSample = {
sessionsPerWeek: number; // số phiên đã chạy trong tuần thử
avgInputTokens: number; // token vào trung bình mỗi phiên (đọc từ công cụ)
avgOutputTokens: number; // token ra trung bình mỗi phiên
};
type Pricing = {
inputPerMillion: number; // giá cho 1 triệu token vào (lấy từ trang giá chính thức)
outputPerMillion: number; // giá cho 1 triệu token ra
};
export function estimateMonthlyCost(u: UsageSample, p: Pricing, peakFactor = 1.5) {
const weekly =
(u.sessionsPerWeek * u.avgInputTokens * p.inputPerMillion +
u.sessionsPerWeek * u.avgOutputTokens * p.outputPerMillion) / 1_000_000;
// Một tháng khoảng 4,3 tuần; nhân hệ số dự phòng cho giai đoạn làm nhiều
return weekly * 4.3 * peakFactor;
}
Lập ngân sách cho dự án nhỏ: đo – ngoại suy – đặt hạn mức
- Liệt kê nhu cầu: ai dùng AI vào việc gì? Ví dụ: chị Lan code hằng ngày; sau này có thêm Khoa code part-time ở giai đoạn mở rộng; một bot review PR tự động; sau này là tính năng AI trong sản phẩm (tính riêng, xem bài Chọn model, tối ưu chi phí12-05).
- Chọn mô hình tính tiền cho từng nhu cầu: người dùng hằng ngày thường hợp thuê bao; tự động hóa trong CI thường dùng API theo token.
- Chạy thử một đến hai tuần, ghi lại mức dùng thực tế từ công cụ.
- Ngoại suy ra tháng, nhân hệ số dự phòng cho giai đoạn làm nhiều (sắp ra mắt, sửa lỗi gấp).
- Đặt hạn mức và cảnh báo trên bảng điều khiển của nhà cung cấp API: hạn mức chi tiêu tháng, cảnh báo khi đạt một tỷ lệ nhất định.
- Xem lại hằng tháng: so thực tế với dự toán, tìm phiên bất thường.
Mẫu bảng ngân sách (điền số của bạn):
| Hạng mục | Mô hình tính tiền | Số người / số lần | Đơn giá (từ trang chính thức) | Dự toán tháng | Hạn mức cứng |
|---|---|---|---|---|---|
| Công cụ code cho chị Lan | Thuê bao | 1 người | [điền] | [điền] | Theo gói |
| Công cụ code cho Khoa | Thuê bao | 1 người | [điền] | [điền] | Theo gói |
| Bot review PR trong CI | API theo token | [số PR/tháng] | [điền] | [đo – ngoại suy] | [điền] |
| Dự phòng thử công cụ mới | Tín dụng hoặc gói dùng thử | — | [điền] | [điền] | [điền] |
Chi phí ẩn đáng kể hơn hóa đơn
Hóa đơn AI thường không phải khoản lớn nhất. Các chi phí ẩn:
- Thời gian review và kiểm chứng của bạn: đây là nút thắt thật. Code sinh nhanh hơn tốc độ bạn đọc là dấu hiệu phải chia nhỏ việc và tăng test tự động.
- Nợ kỹ thuật từ code phình, không nhất quán: trả lãi về sau (bài Nợ kỹ thuật và refactor11-04).
- Sự cố do lỗi lọt qua: một ngày dashboard sai trong mùa Trung thu đắt hơn cả năm tiền thuê bao.
Cách giữ chi phí hợp lý
- Phiên ngắn, một việc một phiên, lọc output lệnh, chỉ bật MCP cần thiết.
- Chọn mô hình theo việc: mô hình mạnh cho lập kế hoạch và việc khó; mô hình nhanh, rẻ hơn cho việc vặt, nếu công cụ cho phép chọn.
- Tránh vòng sửa đi sửa lại: sau hai lần chỉnh không được, làm lại phiên với prompt tốt hơn.
- Mỗi dự án, mỗi mục đích một khóa API riêng, có hạn mức, để biết tiền đi đâu và khoanh vùng khi bị lộ.
Nhập ngữ cảnh lượt đầu, token thêm mỗi lượt, số lượt, giá vào/ra (tự điền từ trang giá chính thức) → tổng token vào cả phiên và chi phí; tái hiện bảng 10/30/60 lượt (285 nghìn → 6,2 triệu) và ngoại suy tháng ×4,3 ×1,5
Bàn thử cần bật JavaScript.
Kết quả chỉ để tham khảo, không thay cho việc bạn tự duyệt.
Phụ thuộc nhà cung cấp và kế hoạch dự phòng
Những gì có thể xảy ra
| Rủi ro | Ví dụ | Mức ảnh hưởng nếu không chuẩn bị |
|---|---|---|
| Dịch vụ gián đoạn | Nhà cung cấp sự cố vài giờ | Ngừng làm việc đúng hôm cần sửa lỗi gấp |
| Thay đổi giá, hạn mức | Gói thuê bao đổi điều khoản | Ngân sách vỡ, phải chuyển gấp |
| Mô hình ngừng hỗ trợ hoặc đổi hành vi | Phiên bản cũ bị khai tử, bản mới làm khác | Quy trình đang chạy tốt bỗng kém đi |
| Thay đổi chính sách, khu vực | Tính năng không còn khả dụng ở một số nơi | Mất công cụ chính |
| Tài khoản gặp vấn đề | Thanh toán lỗi, tài khoản bị khóa | Mất quyền truy cập đột ngột |
Kế hoạch dự phòng bốn lớp
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Lớp 1: Tài sản mang đi được (code trong Git, tài liệu Markdown, AGENTS.md, test, CI) → Lớp 2: Công cụ thứ hai đã thử trên việc thật
- Lớp 2: Công cụ thứ hai đã thử trên việc thật → Lớp 3: Tài khoản thuộc doanh nghiệp, nhiều người có quyền quản trị
- Lớp 3: Tài khoản thuộc doanh nghiệp, nhiều người có quyền quản trị → Lớp 4: Làm được việc khẩn cấp không cần AI (đọc hiểu code, quy trình rollback, người hỗ trợ)
- Tài sản mang đi được. Như bài Bản đồ công cụ AI coding02-03: mọi thứ quan trọng nằm trong repo của bạn, theo chuẩn mở.
- Công cụ thứ hai đã thử. Không phải “biết là có”, mà đã từng làm một việc thật với nó trong dự án này.
- Tài khoản thuộc về doanh nghiệp. Đăng ký bằng email công ty, thanh toán bằng phương thức của công ty, ít nhất hai người có quyền quản trị. Đừng để mọi thứ nằm trong tài khoản cá nhân của một freelancer.
- Năng lực tối thiểu khi không có AI. Bạn (hoặc một người hỗ trợ đã thỏa thuận trước) đọc được code để làm việc khẩn cấp: quay lui bản phát hành, tắt một tính năng bằng feature flag, khôi phục backup. Đây là lý do module 1 dạy bạn đọc hiểu code cơ bản.
Với tính năng AI trong sản phẩm (module 12), dự phòng còn gồm: tách lớp gọi mô hình khỏi logic nghiệp vụ để đổi nhà cung cấp dễ, có bộ evals để đo chất lượng khi đổi mô hình, và có đường xử lý thủ công khi AI không khả dụng.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261013-022
13.10.2026
- Chị LanChủ chuỗi
- HàBán hàng online

Sau hai tháng xây MVP, chị Lan ngồi xuống tổng kết với tư cách chủ doanh nghiệp, không chỉ là người học.
Về lỗi đặc trưng. Chị lập danh sách những lần phải sửa lại sau khi agent báo xong: lần agent nuốt lỗi dashboard bằng catch trả về 0; lần agent viết ba hàm định dạng tiền khác nhau ở ba thư mục; lần test “tạo đơn” luôn xanh vì chỉ kiểm tra hàm giả. Từ đó chị thêm vào quy trình: một bước review riêng tìm “dấu vân tay” sửa triệu chứng, và thói quen cố tình làm hỏng code xem test có đỏ không.
Về phân việc. Chị dán bảng ba cột lên tường. Hà được phép tự nhờ agent làm các việc ở cột trái (sửa chữ trên giao diện, thêm bộ lọc). Mọi việc liên quan tiền cọc, phân quyền, migration đều phải có kế hoạch được chị duyệt; riêng phần phân quyền và bảo mật, chị dự trù thuê một người rà soát độc lập trước khi ra mắt. Quyết định “có cho khách tự đặt bánh online không” là của chị.
Về chi phí. Chị dùng thuê bao cho bản thân. Sau này khi có thêm người cùng code, mỗi người dùng thuê bao riêng do công ty trả. Bot review PR trong CI dùng một khóa API riêng có hạn mức tháng và cảnh báo qua email. Tuần đầu chạy thử, chị ghi lại số PR và mức token trung bình mỗi lần review, ngoại suy ra tháng, nhân hệ số 1,5 cho giai đoạn trước Trung thu. Chị cũng nhận ra khoản đắt nhất không phải hóa đơn AI, mà là những buổi tối chị phải tự kiểm tra thủ công vì thiếu test.
Về dự phòng. Repo banhmoc-oms thuộc tổ chức GitHub của công ty, không thuộc tài khoản cá nhân của ai. AGENTS.md, spec, test nằm trong repo. Chị đã thử một công cụ thứ hai trên việc thêm bộ lọc theo kênh bán; mất khoảng một giờ làm quen, quy trình vẫn chạy. Trong sổ vận hành có mục “Khi công cụ AI không dùng được”: cách quay lui bản phát hành, và những việc chị tự làm tay được trong lúc chờ.
Chị Lan kết luận với Hà: “AI giống một đội thợ rất nhanh. Mình phải biết họ hay sai chỗ nào, việc gì giao được, tốn bao nhiêu, và nếu mai họ nghỉ thì tiệm vẫn chạy.”
Prompt mẫu
Tự rà soát diff tìm dấu hiệu sửa triệu chứng và phình code:
Điền ô trống rồi sao chép
Rà soát toàn bộ thay đổi so với nhánh main. Liệt kê:
1. Mọi catch rỗng hoặc trả giá trị mặc định, as any, @ts-ignore, eslint-disable, test bị xóa hoặc đổi kỳ vọng.
2. Hàm mới có chức năng trùng với hàm đã có trong src/lib hoặc src/features.
3. File bị sửa nằm ngoài phạm vi yêu cầu: [mô tả phạm vi].
Với mỗi mục: vị trí, lý do đáng ngờ, đề xuất. Không sửa gì.
Yêu cầu thay đổi tối thiểu:
Điền ô trống rồi sao chép
Thực hiện [yêu cầu] với thay đổi NHỎ NHẤT đủ để đạt mục tiêu.
Dùng lại hàm và component có sẵn; không tạo lớp trừu tượng mới; không định dạng lại hay đổi tên ở file khác.
Nếu bạn thấy cần thay đổi lớn hơn, dừng lại và giải thích lý do trước.
Phân tích một quyết định có đánh đổi (bạn giữ quyền quyết định):
Điền ô trống rồi sao chép
Mình đang cân nhắc [quyết định, ví dụ: cho khách tự đặt bánh kem trên website hay chỉ nhận qua Zalo].
Hãy liệt kê 2–3 phương án, với mỗi phương án: lợi ích, rủi ro, chi phí xây và vận hành, điều cần biết thêm.
Không đưa ra khuyến nghị cuối cùng; mình sẽ quyết định.
Sai lầm thường gặp
-
Sự cố 01
Chấp nhận “đã sửa” mà không xem cách sửa.
Triệu chứngSửa triệu chứng làm lỗi biến mất khỏi màn hình nhưng vẫn còn trong hệ thống.
Cách tránhReview diff tìm dấu vân tay sửa triệu chứng; yêu cầu giải thích nguyên nhân gốc.
-
Sự cố 02
Giao việc rủi ro cao mà không có kiểm chứng.
Triệu chứngLogic tiền, phân quyền, migration sai thì thiệt hại thật.
Cách tránhKế hoạch duyệt trước, test bắt buộc, review kỹ; việc quá khó kiểm chứng thì bạn giữ quyết định hoặc nhờ chuyên gia.
-
Sự cố 03
Không đặt hạn mức chi tiêu API.
Triệu chứngMột script lặp vô hạn hoặc khóa bị lộ có thể tạo hóa đơn lớn.
Cách tránhHạn mức tháng, cảnh báo, khóa riêng cho từng mục đích.
-
Sự cố 04
Ước tính chi phí bằng cảm tính.
Triệu chứngPhiên agent dài tốn hơn trực giác rất nhiều.
Cách tránhĐo một đến hai tuần, ngoại suy, nhân hệ số dự phòng, xem lại hằng tháng.
-
Sự cố 05
Chỉ tính hóa đơn AI, quên chi phí ẩn.
Triệu chứngThời gian review, nợ kỹ thuật, sự cố mới là khoản lớn.
Cách tránhĐầu tư vào test, spec, PR nhỏ để giảm thời gian kiểm chứng thủ công.
-
Sự cố 06
Mọi thứ nằm trong tài khoản cá nhân của một người.
Triệu chứngNgười đó nghỉ hoặc tài khoản gặp sự cố là doanh nghiệp mất quyền truy cập.
Cách tránhTài khoản thuộc doanh nghiệp, ít nhất hai quản trị viên, tài sản trong repo của công ty.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Săn dấu vân tay
Lấy một thay đổi gần đây do AI viết trong dự án của bạn (hoặc nhờ agent sửa một lỗi giả định trong dự án mẫu). Dùng prompt rà soát trong bài, đối chiếu với bảng kiểu lỗi đặc trưng.
Kết quả mong đợi
Danh sách các điểm đáng ngờ, mỗi điểm được bạn kết luận “chấp nhận được vì…” hoặc “cần sửa vì…”.
-
Bài 2
Cơ bản
Phân loại backlog
Viết 12 việc cần làm cho Mộc OMS (hoặc dự án của bạn), xếp vào ba cột giao thoải mái, giám sát chặt, tự quyết định, kèm một câu lý do theo hai tiêu chí hậu quả và khả năng kiểm chứng.
Kết quả mong đợi
Bảng ba cột; các việc về tiền, quyền, dữ liệu cá nhân không nằm ở cột trái.
-
Bài 3
Nâng cao
Ngân sách thật
Trong một tuần, ghi lại số phiên và mức token (hoặc mức dùng mà công cụ hiển thị) của bạn. Tra đơn giá trên trang chính thức, dùng công thức trong bài để ngoại suy chi phí tháng, so với giá thuê bao của cùng nhà cung cấp.
Kết quả mong đợi
Một bảng ngân sách điền đủ số, kèm kết luận nên dùng thuê bao hay trả theo token cho nhu cầu của bạn, và hạn mức cần đặt.
Thuật ngữ trong bài
- Sửa triệu chứng
- Làm lỗi biến mất khỏi bề mặt mà không xử lý nguyên nhân
- Phình code (code bloat)
- Code dài và phức tạp hơn mức cần thiết
- Over-engineering
- Thiết kế quá mức, giải quyết những vấn đề chưa tồn tại
- Thuê bao (subscription)
- Trả phí cố định theo kỳ, kèm hạn mức sử dụng
- Token vào / token ra
- Số token gửi cho mô hình / số token mô hình sinh ra
- Bộ nhớ đệm prompt (prompt caching)
- Tính giá thấp hơn cho phần ngữ cảnh lặp lại giữa các lượt
- Hạn mức chi tiêu
- Giới hạn số tiền tối đa được dùng trong một kỳ
- Feature flag
- Công tắc bật/tắt tính năng mà không cần phát hành lại
- DORA
- Chương trình nghiên cứu về hiệu quả phát triển và vận hành phần mềm
Đọc thêm
- Nghiên cứu DORA về phát triển phần mềm có hỗ trợ AI: https://dora.dev
- Danh sách lỗ hổng bảo mật web phổ biến: https://owasp.org/www-project-top-ten/
- Tài liệu về theo dõi mức dùng và chi phí của agent: https://code.claude.com/docs
- Bài liên quan: Rủi ro bảo mật đặc trưng của code AI09-01, Chi phí hạ tầng10-07, Chất lượng của chính bộ test08-09, Khi nào cần kỹ sư chuyên nghiệp13-07
Nghiệm thu tờ 02-08
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.

