Bản đồ công trìnhTờ này lắp: Coding agent, Kiểm thử
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Bạn là sếp, agent là nhân viên giỏi nhưng mới vào
Chị Lan có kinh nghiệm tuyển và đào tạo khoảng 25 nhân viên. Chị biết rõ một người thợ bánh giỏi từ tiệm khác chuyển sang vẫn cần thời gian: họ biết làm bánh, nhưng chưa biết công thức riêng của Bánh Mộc, chưa biết khách quen thích gì, chưa biết quy tắc “bánh kem chữ phải chụp ảnh gửi khách duyệt trước khi giao”.
Coding agent giống hệt như vậy, chỉ cực đoan hơn ở vài điểm:
| Đặc điểm của agent | Giống nhân viên mới ở chỗ | Khác ở chỗ | Hệ quả với cách bạn quản lý |
|---|---|---|---|
| Rất giỏi kỹ thuật | Biết nghề | Biết nhiều ngôn ngữ, framework hơn hầu hết mọi người | Đừng dạy nó cú pháp; hãy dạy nó về doanh nghiệp của bạn |
| Không biết bối cảnh | Chưa hiểu doanh nghiệp | Hoàn toàn không biết gì ngoài những gì bạn đưa vào | Phải cung cấp bối cảnh rõ ràng mỗi lần |
| Hay quên | Cần thời gian nhớ quy trình | Mỗi phiên mới gần như bắt đầu lại từ đầu | Viết “sổ tay nhân viên” (AGENTS.md) để nó đọc mỗi phiên |
| Luôn tự tin | Nhân viên mới hay ngại hỏi | Hiếm khi nói “tôi không chắc”, dễ nói “đã xong” | Đòi bằng chứng, không tin lời khẳng định |
| Làm đúng chữ | Hiểu theo nghĩa đen | Lấp chỗ trống bằng phỏng đoán thay vì hỏi lại | Viết yêu cầu rõ, cho phép và khuyến khích nó hỏi |
| Có thể đi đường tắt | Muốn hoàn thành nhanh | Có thể sửa test cho qua, tắt cảnh báo, viết cứng kết quả | Kiểm tra cách làm, không chỉ kết quả |
| Rất nhanh, không mệt | Không có | Làm trong vài phút việc của vài ngày | Khả năng review của bạn trở thành nút thắt |
Mô hình này giải thích hầu hết các thực hành tốt bạn sẽ học trong chuỗi bài. Viết spec là “giao việc rõ ràng”. AGENTS.md là “sổ tay nhân viên”. Chia nhỏ công việc là “không giao cả dự án cho người mới”. Review và test là “nghiệm thu”. Chế độ phê duyệt lệnh là “chưa cho ký séc”.
Ba chiếc mũ bạn phải đội
Khi agent đảm nhận phần lớn việc viết code, những vai trò còn lại trong một đội phần mềm truyền thống dồn về phía bạn. Có ba vai quan trọng nhất.
Chiếc mũ thứ nhất: Quản lý sản phẩm
Người quản lý sản phẩm (product manager) trả lời câu hỏi: làm gì, cho ai, vì sao, và theo thứ tự nào. Họ hiểu vấn đề của người dùng, quyết định phạm vi, nói “không” với những tính năng chưa cần, và đo xem sản phẩm có tạo ra giá trị không.
Với chị Lan, chiếc mũ này quen thuộc nhất, vì mười năm làm marketer chị đã quen hỏi “khách hàng cần gì, và vì sao?”. Trong Mộc OMS, chiếc mũ này quyết định: MVP có màn hình bếp nhưng chưa có trợ lý AI nhận đơn; ưu tiên giảm sai chữ trên bánh trước khi làm báo cáo đẹp.
Chiếc mũ thứ hai: Kiến trúc sư
Kiến trúc sư phần mềm (software architect) giữ cấu trúc tổng thể của hệ thống: dữ liệu được tổ chức thế nào, các phần nói chuyện với nhau ra sao, công nghệ nào được dùng, quyết định nào khó đảo ngược. Họ đảm bảo hệ thống lớn lên mà không rối.
Đây là chiếc mũ người mới hay bỏ quên nhất, và cũng là chiếc mũ mà thiếu nó thì AI gây hại nhiều nhất. Nếu không ai giữ kiến trúc, mỗi phiên agent sẽ tự đưa ra quyết định riêng, và sau vài tháng, hệ thống có năm cách làm cùng một việc. Bạn không cần là kiến trúc sư chuyên nghiệp, nhưng cần đủ hiểu để ra những quyết định nền tảng và ghi chúng lại (xem Kiến trúc phần mềm là gì04-01).
Chiếc mũ thứ ba: Kiểm định viên
Kiểm định viên (người nghiệm thu, QA) trả lời: cái được làm ra có đúng không, có an toàn không, có dùng được không? Họ không tin lời “đã xong”; họ kiểm tra bằng kịch bản, bằng test, bằng mắt người dùng thật.
Với agent làm việc rất nhanh, chiếc mũ này được dùng nhiều nhất trong ngày. Mỗi lần agent báo xong là một lần bạn đội mũ kiểm định viên.
| Chiếc mũ | Câu hỏi chính | Sản phẩm đầu ra | Học sâu ở |
|---|---|---|---|
| Quản lý sản phẩm | Làm gì, cho ai, vì sao, khi nào? | Tuyên bố vấn đề, PRD, backlog ưu tiên, chỉ số thành công | Module 03, 07, 11 |
| Kiến trúc sư | Hệ thống được tổ chức thế nào để bền và dễ thay đổi? | ERD, thiết kế API, ADR, AGENTS.md, ma trận quyền | Module 04, 05, 09, 13 |
| Kiểm định viên | Kết quả có đúng, an toàn, dùng được không? | Tiêu chí chấp nhận, bộ test, kết quả review, quyết định go/no-go | Module 06, 08, 09 |
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Ghi chú (B): Mũ quản lý sản phẩm
- Bạn → Coding agent: Spec: làm gì, vì sao, tiêu chí chấp nhận
- Ghi chú (B): Mũ kiến trúc sư
- Coding agent → Bạn: Đề xuất kế hoạch, file sẽ sửa
- Bạn → Coding agent: Duyệt hoặc chỉnh kế hoạch
- Coding agent → Coding agent: Viết code, chạy test, tự sửa
- Coding agent → Bạn: Báo cáo kèm bằng chứng (test, ảnh chụp)
- Ghi chú (B): Mũ kiểm định viên
- Bạn → Bạn: Đọc diff, thử kịch bản, rà rủi ro
- Bạn → Coding agent: Yêu cầu sửa hoặc chấp nhận
- Ghi chú (B): Bạn quyết định merge và phát hành
Năm năng lực cốt lõi
Ba chiếc mũ cần năm năng lực. Đây là những năng lực bền vững: công cụ AI thay đổi mỗi quý, nhưng năm năng lực này vẫn giữ giá trị.
1. Diễn đạt: nói rõ điều mình muốn
Là gì: khả năng mô tả mục tiêu, bối cảnh, ràng buộc và tiêu chí thành công một cách rõ ràng, đủ để một người (hay một agent) không biết gì về doanh nghiệp của bạn vẫn làm đúng.
Yếu trông như thế nào: “Làm cho trang đơn hàng đẹp hơn.” Mạnh trông như thế nào: “Trên màn hình danh sách đơn, đơn có giờ nhận trong 2 giờ tới phải hiện nổi bật màu cam, sắp lên đầu; nhân viên tiệm cần nhận ra chúng trong 3 giây khi nhìn lướt trên điện thoại.”
Cách rèn: viết spec, viết user story với tiêu chí chấp nhận, đọc lại prompt của mình và hỏi “nếu là người lạ, mình có hiểu không?”. Xem Viết prompt cho lập trình02-04 và User story và tiêu chí chấp nhận03-05.
2. Phân rã: chia việc lớn thành việc nhỏ
Là gì: khả năng chia một mục tiêu lớn (“quản lý đơn hàng”) thành những phần nhỏ, độc lập, mỗi phần làm và kiểm chứng được trong một phiên làm việc.
Yếu trông như thế nào: giao “làm toàn bộ quản lý khách hàng” trong một prompt, nhận về hàng nghìn dòng code không ai review nổi. Mạnh trông như thế nào: chia thành “tìm khách theo số điện thoại”, “tạo khách mới khi chưa có”, “xem lịch sử mua”, mỗi phần có test riêng, làm lần lượt.
Cách rèn: luyện kỹ thuật lát cắt dọc, viết danh sách task. Xem Chia nhỏ công việc06-05.
3. Đánh giá: nhận ra cái tốt và cái tệ
Là gì: khả năng nhìn vào một kế hoạch, một thiết kế, một đoạn code và nhận ra dấu hiệu bất thường: quá phức tạp, sai hướng, thiếu trường hợp, không nhất quán với phần còn lại.
Yếu trông như thế nào: chấp nhận mọi kế hoạch agent đề xuất vì “nghe có vẻ chuyên nghiệp”. Mạnh trông như thế nào: “Kế hoạch này thêm một thư viện quản lý trạng thái mới, trong khi dự án đã có cách làm khác. Vì sao cần thêm?”
Cách rèn: đọc diff mỗi ngày, hỏi agent giải thích, học các dấu hiệu cảnh báo. Xem Đọc và review code do AI viết06-06.
4. Kiểm chứng: chứng minh nó đúng
Là gì: khả năng thiết kế cách để biết chắc kết quả đúng: test tự động, kịch bản thử, ảnh chụp so sánh, dữ liệu mẫu có trường hợp biên. Khác với “đánh giá” (nhìn và nhận xét), kiểm chứng là chạy và chứng minh.
Yếu trông như thế nào: bấm thử một đơn bình thường thấy chạy là chấp nhận. Mạnh trông như thế nào: có sẵn danh sách kịch bản: đơn có cọc, đơn hủy sau khi cọc, đơn giao lúc 6 giờ sáng, hai nhân viên sửa cùng một đơn, khách không có số điện thoại.
Cách rèn: viết tiêu chí chấp nhận trước, học các tầng kiểm thử, luyện săn trường hợp biên. Xem module Kiểm thử và chất lượng08-01.
5. Quản trị rủi ro: biết cái gì có thể hỏng và hỏng nặng cỡ nào
Là gì: khả năng nhận ra thay đổi nào nguy hiểm (chạm tới tiền, dữ liệu khách, quyền truy cập, database production), áp dụng mức thận trọng tương ứng, và luôn có đường lui.
Yếu trông như thế nào: để agent chạy migration thẳng trên database thật vào chiều 30 Tết. Mạnh trông như thế nào: “Thay đổi này đụng tới bảng payments. Phải sao lưu trước, thử trên staging, phát hành giờ thấp điểm, chuẩn bị sẵn cách quay lui.”
Cách rèn: học bảo mật cơ bản, học triển khai an toàn, tập trả lời câu hỏi “nếu cái này sai thì điều tệ nhất là gì?”. Xem module Bảo mật và dữ liệu09-01.
Trách nhiệm không thể giao cho AI
Có những việc agent làm được về mặt kỹ thuật, nhưng bạn không được giao, vì trách nhiệm gắn với nó thuộc về con người và doanh nghiệp. Bảng dưới đây chia công việc thành ba vùng.
| Vùng | Ví dụ trong Mộc OMS | Nguyên tắc |
|---|---|---|
| ✅ Giao thoải mái | Viết component giao diện, viết test theo tiêu chí có sẵn, giải thích code, tìm lỗi chính tả, viết tài liệu nháp | Agent làm, bạn kiểm tra nhanh |
| Giao có giám sát chặt | Logic tính tiền, cọc, trạng thái đơn; phân quyền; migration database; tích hợp thanh toán; thêm thư viện mới | Agent làm theo spec, bạn duyệt kế hoạch, đọc kỹ diff, đòi test |
| ❌ Không bao giờ giao | Quyết định phạm vi và ưu tiên; quyết định thu thập dữ liệu khách nào; quyền truy cập database production và khóa bí mật thật; bấm nút phát hành; trả lời khách khi có sự cố; quyết định chi tiền | Con người quyết định và chịu trách nhiệm |
Vì sao những việc ở dòng cuối không thể giao?
- Quyết định phạm vi và ưu tiên phụ thuộc vào chiến lược kinh doanh, ngân sách, con người, những thứ agent không biết và không chịu hậu quả.
- Dữ liệu cá nhân khách hàng chịu sự điều chỉnh của pháp luật Việt Nam về bảo vệ dữ liệu cá nhân. Doanh nghiệp là bên chịu trách nhiệm pháp lý, không phải công cụ.
- Quyền truy cập production và khóa bí mật thật: một agent có thể bị lừa bởi nội dung độc hại (prompt injection) hoặc chỉ vô tình chạy nhầm lệnh. Hậu quả có thể là mất dữ liệu không khôi phục được.
- Quyết định phát hành: bạn là người ký tên dưới mỗi thay đổi tới tay người dùng.
- Giao tiếp khi có sự cố: khách hàng và nhân viên cần nghe từ con người có trách nhiệm.
Tự đánh giá năng lực hiện tại
Dưới đây là bảng tự đánh giá gồm 15 câu, ba câu cho mỗi năng lực. Chấm mỗi câu theo thang: 0 = chưa bao giờ / không biết; 1 = thỉnh thoảng / biết sơ; 2 = thường xuyên / làm được; 3 = luôn luôn / có thể hướng dẫn người khác.
- Diễn đạt
- Phân rã
- Đánh giá
- Kiểm chứng
- Quản trị rủi ro
| Năng lực | Câu hỏi tự đánh giá |
|---|---|
| Diễn đạt | 1. Tôi viết được mô tả yêu cầu mà người lạ đọc hiểu đúng ngay lần đầu. |
| 2. Khi giao việc, tôi nêu rõ thế nào là “xong” (tiêu chí chấp nhận). | |
| 3. Tôi nói rõ những gì không nằm trong phạm vi. | |
| Phân rã | 4. Tôi chia được một dự án thành các phần làm được trong một tới hai ngày. |
| 5. Tôi biết phần nào phải làm trước, phần nào phụ thuộc phần nào. | |
| 6. Mỗi phần tôi chia ra đều kiểm tra được độc lập. | |
| Đánh giá | 7. Tôi nhận ra khi một đề xuất phức tạp hơn mức cần thiết. |
| 8. Tôi đọc được một bản so sánh trước/sau (diff) và hiểu đại ý thay đổi. | |
| 9. Tôi hay hỏi “vì sao làm cách này?” thay vì chấp nhận ngay. | |
| Kiểm chứng | 10. Trước khi nghiệm thu, tôi đã có sẵn danh sách tình huống cần thử. |
| 11. Tôi nghĩ tới trường hợp biên (dữ liệu trống, số âm, thao tác cùng lúc). | |
| 12. Tôi đòi bằng chứng cụ thể thay vì tin lời “đã xong”. | |
| Quản trị rủi ro | 13. Tôi phân biệt được thay đổi rủi ro thấp và rủi ro cao. |
| 14. Trước thay đổi lớn, tôi luôn có cách quay lại trạng thái cũ. | |
| 15. Tôi biết dữ liệu nào là nhạy cảm và ai được phép xem. |
Cách đọc kết quả (tổng tối đa 45 điểm, mỗi năng lực tối đa 9 điểm):
- 0–15 điểm: bạn đang ở điểm xuất phát, hoàn toàn bình thường với người mới. Đọc tuần tự chuỗi bài, đặc biệt module 01–03.
- 16–30 điểm: bạn có nền tảng từ công việc hiện tại (thường là diễn đạt và quản trị rủi ro ở người làm kinh doanh). Tập trung vào năng lực có điểm thấp nhất.
- 31–45 điểm: bạn đã có tư duy của người làm sản phẩm hoặc quản lý dự án. Chuỗi bài sẽ giúp bạn chuyển tư duy đó sang kỹ thuật cụ thể.
Quan trọng hơn tổng điểm là năng lực nào thấp nhất. Một chuỗi chỉ chắc bằng mắt xích yếu nhất: diễn đạt giỏi mà kiểm chứng kém vẫn sẽ chấp nhận code sai.
Chấm 15 câu (0–3) → tổng /45, điểm từng năng lực /9, chỉ ra năng lực thấp nhất kèm bài nên đọc; lưu trên trình duyệt để chấm lại sau module 06 và 14
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.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261012-004
12.10.2026
- Chị LanChủ chuỗi
Chị Lan tự chấm bảng 15 câu và được 19 điểm:
| Năng lực | Điểm | Nhận xét của chị Lan |
|---|---|---|
| Diễn đạt | 6/9 | Viết brief cho agency quảng cáo mười năm, quen nói rõ mục tiêu. Hay quên nói “không làm gì”. |
| Phân rã | 3/9 | Hay muốn làm hết một lần. App vibe là ví dụ. |
| Đánh giá | 2/9 | Chưa đọc được code. Hay tin đề xuất nghe chuyên nghiệp. |
| Kiểm chứng | 2/9 | Trước giờ chỉ bấm thử. Chưa nghĩ tới trường hợp biên. |
| Quản trị rủi ro | 6/9 | Quen quản lý tiền, ca làm, hàng tồn. Nhưng chưa biết rủi ro kỹ thuật. |
Chị rút ra hai ưu tiên: rèn kiểm chứng và phân rã trước, vì đó là hai điểm yếu đã làm app vibe sụp đổ.
Chị cũng phân vai cho đội nhỏ của mình, dựa trên ba chiếc mũ:
- Chị Lan: đội cả ba mũ ở mức tổng thể; quyết định cuối cùng về phạm vi, kiến trúc, phát hành.
- Hà: kiểm định viên cho luồng nhận đơn và chăm sóc khách. Hà là người dùng nhiều nhất, nên Hà viết kịch bản thử “nhận đơn qua Zalo lúc cao điểm”.
- Anh Tuấn: kiểm định viên cho màn hình bếp. Không ai biết rõ hơn anh thế nào là “đọc được trong 3 giây khi tay đang dính kem”.
- Coding agent: đội thi công, làm việc theo spec, có quyền hạn giới hạn, không bao giờ được chạm vào dữ liệu thật.
Phân vai này giúp chị không phải một mình làm kiểm định viên cho mọi thứ, đồng thời đưa người dùng thật vào quy trình ngay từ đầu.
Prompt mẫu
Prompt dưới đây biến AI thành người phỏng vấn giúp bạn tự đánh giá năm năng lực sâu hơn bảng chấm điểm:
Điền ô trống rồi sao chép
Hãy đóng vai một trưởng nhóm kỹ thuật giàu kinh nghiệm đang đánh giá một người mới
sẽ chỉ đạo coding agent. Tôi là [vai trò hiện tại, ví dụ: chủ tiệm bánh, từng làm marketing].
Hãy hỏi tôi lần lượt từng câu (mỗi lần MỘT câu, chờ tôi trả lời rồi mới hỏi tiếp),
tổng cộng 10 câu, phủ 5 năng lực: diễn đạt, phân rã, đánh giá, kiểm chứng, quản trị rủi ro.
Dùng tình huống cụ thể trong bối cảnh [lĩnh vực của tôi], không hỏi lý thuyết.
Sau câu cuối, cho tôi:
- Điểm từ 0–3 cho mỗi năng lực, kèm lý do dựa trên câu trả lời của tôi.
- Hai năng lực nên ưu tiên rèn, và một bài tập cụ thể cho mỗi năng lực.Prompt thứ hai giúp bạn tập “giao việc như sếp”, dùng trước khi đưa yêu cầu cho agent:
Điền ô trống rồi sao chép
Đây là yêu cầu tôi định giao cho coding agent: [dán yêu cầu].
Hãy đóng vai một lập trình viên giỏi nhưng mới vào công ty, không biết gì về doanh nghiệp.
Liệt kê mọi câu hỏi bạn cần hỏi lại trước khi bắt tay vào làm, chia theo nhóm:
mục tiêu, người dùng, dữ liệu, trường hợp biên, phạm vi, cách nghiệm thu.
Đừng viết code.Sai lầm thường gặp
-
Sự cố 01
Quản lý agent như một công cụ, không như một nhân viên.
Triệu chứngBấm nút và chờ kết quả, không cung cấp bối cảnh, không kiểm tra.
Cách tránháp dụng mọi thứ bạn biết về quản lý nhân viên mới: giao việc rõ, sổ tay, việc nhỏ trước, kiểm tra kết quả, quyền hạn tăng dần.
-
Sự cố 02
Chỉ đội một chiếc mũ.
Triệu chứngNgười làm kinh doanh thường chỉ đội mũ quản lý sản phẩm, bỏ quên kiến trúc và kiểm định.
Cách tránhmỗi khi giao việc, tự hỏi ba câu: “Làm gì, vì sao?” (sản phẩm), “Nó ảnh hưởng tới cấu trúc chung thế nào?” (kiến trúc), “Mình sẽ kiểm tra bằng cách nào?” (kiểm định).
-
Sự cố 03
Tin vào sự tự tin của agent.
Triệu chứngAgent nói “đã kiểm tra kỹ, mọi thứ hoạt động” không có nghĩa là đúng.
Cách tránhchỉ chấp nhận bằng chứng: output của lệnh test, ảnh chụp, các bước tái hiện được.
-
Sự cố 04
Giao quyền quá sớm.
Triệu chứngCho agent chạy mọi lệnh không cần hỏi, truy cập database thật, vì “nó làm tốt mấy lần rồi”.
Cách tránhquyền hạn theo nguyên tắc tối thiểu; production và khóa thật luôn nằm ngoài tầm với của agent. Xem Bảo mật khi dùng agent09-07.
-
Sự cố 05
Tự làm kiểm định viên cho mọi thứ.
Triệu chứngBạn không phải là người dùng tốt nhất của mọi màn hình.
Cách tránhđưa người dùng thật (nhân viên, khách quen) vào vai kiểm định viên cho phần họ dùng nhiều nhất.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Chấm điểm và lập kế hoạch
Chấm bảng 15 câu. Với hai năng lực thấp nhất, ghi ra bài trong chuỗi sẽ giúp bạn rèn chúng (dùng các liên kết trong bài).
Kết quả mong đợi
một ghi chú ngắn trong nhật ký học tập với điểm số và hai mục tiêu có đường dẫn bài cụ thể.
-
Bài 2
Cơ bản
Bảng ba vùng cho dự án của bạn
Lập bảng “giao thoải mái / giao có giám sát / không bao giờ giao” cho dự án bạn định làm, mỗi vùng ít nhất ba ví dụ cụ thể.
Kết quả mong đợi
vùng “không bao giờ giao” có ít nhất một mục về dữ liệu khách hàng và một mục về quyền truy cập môi trường thật.
-
Bài 3
Nâng cao
Luyện diễn đạt với người phỏng vấn ngược
Lấy một yêu cầu thực tế bạn định làm. Dùng prompt mẫu thứ hai để AI liệt kê câu hỏi. Viết lại yêu cầu sao cho trả lời được ít nhất 80% các câu hỏi đó.
Kết quả mong đợi
bản yêu cầu thứ hai dài hơn bản đầu khoảng ba tới năm lần, có phần “không làm” và phần “cách nghiệm thu”.
Thuật ngữ trong bài
- Product manager (quản lý sản phẩm)
- Người quyết định làm gì, cho ai, vì sao, theo thứ tự nào
- Software architect (kiến trúc sư phần mềm)
- Người giữ cấu trúc tổng thể và các quyết định khó đảo ngược
- QA (đảm bảo chất lượng) / kiểm định viên
- Người kiểm tra và nghiệm thu kết quả
- AGENTS.md
- File hướng dẫn mà nhiều coding agent đọc đầu mỗi phiên, như “sổ tay nhân viên”
- Tiêu chí chấp nhận (acceptance criteria)
- Điều kiện cụ thể để coi một việc là hoàn thành đúng
- Prompt injection
- Kỹ thuật chèn chỉ dẫn độc hại vào nội dung mà AI đọc, khiến nó làm điều không mong muốn
- Production
- Môi trường thật, nơi người dùng thật đang dùng
- Nguyên tắc đặc quyền tối thiểu
- Chỉ cấp đúng quyền cần thiết cho công việc, không hơn
Đọc thêm
- AGENTS.md: định dạng mở cho file hướng dẫn coding agent.
- AGENTS.md, rules và skills02-06: cách viết “sổ tay nhân viên” cho agent.
- Từ chatbot đến coding agent02-02: quyền hạn và chế độ phê duyệt.
- Khi nào cần kỹ sư chuyên nghiệp13-07: giới hạn của việc tự làm với AI.
Nghiệm thu tờ 00-04
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
