Sẽ mở trong thẻ mới
PDL AIAI Worker — trợ lý AI trực 24/7: trả lời khách, xử lý yêu cầu, báo cáo tự động

Kỹ sư phần mềm thời AITờ 02-08 / 112

Giới hạn, rủi ro và chi phí khi làm việc với AI

Đồng hồ chi tiêu sắp chạm vạch giới hạn, hóa đơn dài và hộp đồ nghề dự phòng, ví cho giới hạn và chi phí AI
Tờ
02-08 / 112
Hạng mục
M02 · Hiểu AI và agent coding
Cấp độ
Trung cấp
Thời gian đọc
21 phút
Giai đoạn công trình
0 · Khám phá
Cập nhật
Bản đồ công trìnhTờ này lắp: Coding agent
Bản đồ công trình Mộc OMSBài này: Coding agent. Đã học: Khách hàng, Kênh bán, Sheet & sổ tay. Chưa tới: PRD & spec, Repo & CI, Kiểm thử, Hosting & tên miền, Giám sát lỗi, Giao diện app, API, Database, Dashboard, báo cáo, Trợ lý AI nhận đơn, Màn hình bếp, Đăng nhập, vai trò, Thanh toán VietQR, Thông báo khách, Nhiều tiệm (MộcOS), Kế toán, hoá đơn.Thi công & hạ tầngDòng đơn hàngNghiệp vụ & dịch vụMở rộng MộcOSPRD & specspecCoding agentagentRepo & CIrepo-ciKiểm thửtestsHosting & tên miềnhostingGiám sát lỗimonitoringKhách hàngcustomerKênh bánchannelsGiao diện appapp-uiAPIapiDatabasedatabaseDashboard, báo cáoreportsSheet & sổ taysheetTrợ lý AI nhận đơnai-assistantMàn hình bếpkitchenĐăng nhập, vai tròauthThanh toán VietQRpaymentsThông báo kháchnotificationsNhiều tiệm (MộcOS)tenantsKế toán, hoá đơnintegrations0 Khám phá1 MVP2 Ra mắt3 Thêm AI4 Mở rộng
Bản đồ công trình Mộc OMSBài này: Coding agent. Đã học: Khách hàng, Kênh bán, Sheet & sổ tay. Chưa tới: PRD & spec, Repo & CI, Kiểm thử, Hosting & tên miền, Giám sát lỗi, Giao diện app, API, Database, Dashboard, báo cáo, Trợ lý AI nhận đơn, Màn hình bếp, Đăng nhập, vai trò, Thanh toán VietQR, Thông báo khách, Nhiều tiệm (MộcOS), Kế toán, hoá đơn.Dòng đơn hàngKhách hàngKênh bánGiao diệnAPIDatabaseBáo cáoNghiệp vụ & dịch vụSheet, sổ tayTrợ lý AIMàn hình bếpĐăng nhậpThanh toánThông báoThi công & hạ tầngPRD & specCoding agentRepo & CIKiểm thửHostingGiám sátMở rộng MộcOSNhiều tiệmKế toán0 Khám phá1234

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:

TS
// ❌ 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):

TS
// ✅ 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:

  1. 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.
  2. 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?
Hình chữ ký Ma trận
  1. Sai thì hậu quả lớn?
  2. Kiểm chứng dễ?
  3. Giao thoải mái, nghiệm thu bằng kết quả
  4. Giao có giám sát chặt: kế hoạch duyệt trước, review kỹ diff
  5. 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ơ đồ

Nhỏ, dễ sửa

Dễ

Khó

Lớn: tiền, dữ liệu, bảo mật

Dễ, có test tốt

Khó

Một việc cần làm

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, nhưng thêm test hoặc ảnh chụp trước khi nhận

Kiểm chứng dễ?

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

Hình 1 Sơ đồ luồng
Đọc sơ đồ dạng chữ
  1. Một việc cần làm → Sai thì hậu quả lớn?
  2. Sai thì hậu quả lớn? → Kiểm chứng dễ? (Nhỏ, dễ sửa)
  3. Kiểm chứng dễ? → Giao thoải mái, nghiệm thu bằng kết quả (Dễ)
  4. Kiểm chứng dễ? → Giao, nhưng thêm test hoặc ảnh chụp trước khi nhận (Khó)
  5. Sai thì hậu quả lớn? → Kiểm chứng dễ? (Lớn: tiền, dữ liệu, bảo mật)
  6. 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)
  7. 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ỉ:

Phiên agent

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:

TS
// Ướ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

  1. 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).
  2. 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.
  3. Chạy thử một đến hai tuần, ghi lại mức dùng thực tế từ công cụ.
  4. 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).
  5. Đặ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.
  6. 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ộ.
Bàn thử

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ơ đồ

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 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ợ)

Vuốt ngang để xem hết sơ đồ

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 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ợ)

Hình 2 Sơ đồ luồng
Đọc sơ đồ dạng chữ
  1. 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
  2. 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ị
  3. 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ợ)
  1. 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ở.
  2. 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.
  3. 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.
  4. 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
Chị Lan dán bảng ba cột phân loại việc giao cho AI, Hà đứng đọc

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:

Giao việc cho agent

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:

Giao việc cho agent

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):

Giao việc cho agent

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

  1. Sự cố 01

    Chấp nhận “đã sửa” mà không xem cách sửa.

    Triệu chứng

    Sử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ánh

    Review 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.

  2. Sự cố 02

    Giao việc rủi ro cao mà không có kiểm chứng.

    Triệu chứng

    Logic tiền, phân quyền, migration sai thì thiệt hại thật.

    Cách tránh

    Kế 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.

  3. Sự cố 03

    Không đặt hạn mức chi tiêu API.

    Triệu chứng

    Mộ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ánh

    Hạn mức tháng, cảnh báo, khóa riêng cho từng mục đích.

  4. Sự cố 04

    Ước tính chi phí bằng cảm tính.

    Triệu chứng

    Phiê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.

  5. Sự cố 05

    Chỉ tính hóa đơn AI, quên chi phí ẩn.

    Triệu chứng

    Thờ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.

  6. 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ứng

    Ngườ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ánh

    Tà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

Phiếu nghiệm thu

Bài tập thực hành

  1. 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ì…”.

  2. 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.

  3. 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ệ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.

Tác giả
Phú Digital
Đội ngũ PDL Digital — triển khai website, giải pháp AI và digital marketing cho doanh nghiệp.
Tư vấn 1:1

Muốn dựng phần mềm riêng cho doanh nghiệp của bạn?

Kỹ sư PDL cùng bạn chọn bước đầu tiên phù hợp — phản hồi trong giờ làm việc (T2–T7, 8h–18h).

<script src="https://cdn.jsdelivr.net/npm/page-flip/dist/js/page-flip.browser.js"></script>

<div id="container-flipbook" style="display:flex; justify-content:center;">
    <div id="my-flipbook">
       <div class="page"> <img src="https://pdl.vn/wp-content/uploads/2025/05/AI-Google-Search.jpg" /> </div>
       <div class="page"> <img src="https://pdl.vn/wp-content/uploads/2025/05/wearable-tech-advertising.jpg" /> </div>
       <div class="page"> <img src="https://pdl.vn/wp-content/uploads/2025/05/multimodal-embeddings-digital-marketing.jpg" /> </div>
    </div>
</div>
#my-flipbook {
    box-shadow: 0 0 20px rgba(0,0,0,0.2);
    margin: 20px auto;
    background-color: #f0f0f0;
}

.page {
    background-color: white;
    overflow: hidden;
}

.page img {
    width: 100%;
    height: 100%;
    object-fit: cover; /* Giúp ảnh vừa vặn trang sách */
}
// Đảm bảo thư viện đã sẵn sàng
function initFlipbook() {
    const el = document.getElementById("my-flipbook");
    if (!el || !window.St) return; // Nếu chưa thấy thư viện St thì thoát

    const pageFlip = new St.PageFlip(el, {
        width: 550,
        height: 733,
        size: "stretch",
        minWidth: 315,
        maxWidth: 1000,
        minHeight: 420,
        maxHeight: 1350,
        showCover: true,
        maxShadowOpacity: 0.5,
    });

    pageFlip.loadFromHTML(document.querySelectorAll(".page"));
}

// Chạy khởi tạo
if (document.readyState === 'complete') {
    initFlipbook();
} else {
    window.addEventListener('load', initFlipbook);
}
PDL · Tư vấn 1:1

Nhận tư vấn
miễn phí

Để lại thông tin, chuyên viên PDL sẽ liên hệ để hiểu nhu cầu và đề xuất giải pháp phù hợp ngân sách của bạn.

  • Phân tích nhanh hiện trạng website, quảng cáo, kênh bán hàng
  • Đề xuất lộ trình & báo giá minh bạch, rõ từng hạng mục
  • Không ràng buộc: nghe tư vấn xong mới quyết định
Giờ làm việc T2–T7 · 08:00–18:00

Chỉ mất khoảng 30 giây

Bạn cần tư vấn về

🔒 Thông tin được bảo mật, chỉ dùng để PDL liên hệ tư vấn.