Bản đồ công trìnhTờ này lắp: Coding agent, Màn hình bếp
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Một buổi tối năm 2026 ở tiệm bánh
Chín giờ tối, sau khi đóng cửa chi nhánh Phú Nhuận, chị Lan mở máy tính. Chị gõ vào ô chat của một coding agent: “Thêm cột ghi chú dị ứng vào form tạo đơn, hiển thị nổi bật ở màn hình bếp.” Agent đọc mã nguồn, tìm ra file form, file màn hình bếp, file định nghĩa bảng dữ liệu, đề xuất kế hoạch bốn bước, chờ chị duyệt, rồi bắt tay vào làm. Mười lăm phút sau, nó báo: đã thêm cột, đã viết migration, đã chạy bộ test, tất cả đều xanh, kèm ảnh chụp màn hình bếp với dòng chữ đỏ “Dị ứng: hạt óc chó”.
Mười năm trước, việc này cần một lập trình viên biết ít nhất ba thứ: ngôn ngữ lập trình, framework giao diện và cơ sở dữ liệu. Chị Lan thì chưa từng học lập trình một ngày nào. Vậy chị có đang “lập trình” không? Câu trả lời ngắn: có, nhưng theo một nghĩa rất khác. Và chính sự khác biệt đó là chủ đề của bài này.
Điều đáng chú ý trong câu chuyện trên không phải là tốc độ. Điều đáng chú ý là chị Lan biết hỏi đúng (ghi chú dị ứng phải nổi bật ở bếp, vì đó là nơi sai sót gây hậu quả), biết duyệt kế hoạch (chị để ý agent định lưu ghi chú dị ứng ở bảng orders thay vì customers, và chị đồng ý vì dị ứng có thể khác nhau theo người nhận bánh), và biết đòi bằng chứng (test xanh, ảnh chụp). Ba kỹ năng đó không phải cú pháp, mà là hiểu biết về phần mềm.
Ba thời kỳ của nghề lập trình
Để hiểu mình đang đứng ở đâu, hãy nhìn lại chặng đường. Các mốc thời gian dưới đây chỉ mang tính tương đối, vì mỗi đội ngũ chuyển giao giữa các thời kỳ ở những thời điểm khác nhau.
- Thời kỳ 1: Viết code thủ công
- Thời kỳ 2: AI gợi ý code
- Thời kỳ 3: Agent tự thực thi
- Con người: đặc tả + duyệt + kiểm chứng
Xem sơ đồ gốc (Hình 1)
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Thời kỳ 1 Viết code thủ công → Thời kỳ 2 AI gợi ý code
- Thời kỳ 2 AI gợi ý code → Thời kỳ 3 Agent tự thực thi
- Thời kỳ 1 Viết code thủ công → Con người: nghĩ + gõ + kiểm tra
- Thời kỳ 2 AI gợi ý code → Con người: nghĩ + chọn gợi ý + kiểm tra
- Thời kỳ 3 Agent tự thực thi → Con người: đặc tả + duyệt + kiểm chứng
Thời kỳ 1: Viết code thủ công
Trong nhiều thập kỷ, muốn làm phần mềm bạn phải học một ngôn ngữ lập trình như học ngoại ngữ: từ vựng (cú pháp), ngữ pháp (cấu trúc chương trình), thành ngữ (các mẫu thiết kế quen dùng). Một lập trình viên mới thường mất vài tháng tới vài năm mới tự tin làm được một ứng dụng web hoàn chỉnh. Khi gặp lỗi, họ đọc tài liệu, tìm trên diễn đàn hỏi đáp, thử từng giả thuyết.
Ở thời kỳ này, rào cản lớn nhất là kỹ năng gõ ra code chạy được. Người có ý tưởng hay nhưng không biết code (như chị Lan) phải thuê người, và thường mất kiểm soát vì không hiểu người được thuê đang làm gì.
Thời kỳ 2: AI gợi ý code
Khoảng đầu những năm 2020, các công cụ tự động hoàn thành code bằng AI xuất hiện trong trình soạn thảo: bạn gõ tên hàm, AI đoán phần thân hàm. Sau đó là làn sóng chatbot: bạn mô tả vấn đề, chatbot trả về một đoạn code, bạn sao chép và dán vào dự án.
Đây là bước nhảy lớn, nhưng con người vẫn “lái”: bạn quyết định đặt code ở file nào, ghép nối thế nào, chạy thử ra sao. AI giống một người nhắc bài giỏi, còn bạn vẫn là người làm bài. Người không biết code vẫn gặp khó, vì họ không biết dán đoạn code đó vào đâu, và khi nó lỗi thì không biết vì sao.
Thời kỳ 3: Agent tự thực thi
Từ khoảng giữa thập niên, coding agent (tác tử lập trình) trở nên phổ biến: các công cụ như Claude Code, Cursor, GitHub Copilot ở chế độ agent, OpenAI Codex, Gemini CLI… Agent không chỉ đưa gợi ý, mà tự làm theo vòng lặp: đọc mã nguồn, lập kế hoạch, sửa nhiều file, chạy lệnh, đọc kết quả, sửa tiếp cho tới khi đạt mục tiêu. Bạn sẽ hiểu kỹ vòng lặp này ở bài Từ chatbot đến coding agent02-02.
Ở thời kỳ này, con người chuyển từ vai “thợ” sang vai người chỉ đạo và người nghiệm thu. Bạn mô tả mục tiêu, duyệt kế hoạch, cung cấp bối cảnh, và kiểm chứng kết quả.
| Khía cạnh | Thời kỳ 1: Thủ công | Thời kỳ 2: AI gợi ý | Thời kỳ 3: Agent |
|---|---|---|---|
| Ai gõ code | Con người | Con người + AI gợi ý từng đoạn | Chủ yếu là agent |
| Đơn vị làm việc | Từng dòng, từng hàm | Từng đoạn, từng file | Cả tính năng, nhiều file |
| Rào cản chính | Cú pháp, kỹ thuật | Ghép nối, gỡ lỗi | Đặc tả, kiểm chứng, kiến trúc |
| Kỹ năng quan trọng nhất | Viết code | Viết code + đặt câu hỏi | Diễn đạt, phân rã, đánh giá |
| Rủi ro điển hình | Chậm, đắt | Dán code không hiểu | Code nhiều, nhanh, sai mà trông đúng |
Nút thắt đã dịch chuyển, không biến mất
Hãy nghĩ về một xưởng bánh. Khi có máy đánh trứng công nghiệp, người thợ không cần đánh tay nữa. Nhưng xưởng không vì thế mà tự làm ra bánh ngon. Người ta vẫn cần biết công thức, biết bột nở chưa, biết bánh chín chưa, biết khách đặt gì. Máy càng nhanh, sai công thức càng tạo ra nhiều bánh hỏng hơn.
Phần mềm cũng vậy. Khi chi phí viết code giảm mạnh, nút thắt chuyển sang ba chỗ:
- Biết mình muốn gì. Một yêu cầu mơ hồ như “làm app quản lý đơn” buộc AI phải đoán hàng chục điều bạn chưa nói: đơn có những trạng thái nào, ai được hủy đơn, tiền cọc tính thế nào. Mỗi lần đoán sai là một lần làm lại.
- Biết kết quả đúng hay sai. AI viết code rất tự tin, kể cả khi sai. Nếu bạn không có cách kiểm chứng (test, kịch bản thử, tiêu chí nghiệm thu), “trông có vẻ xong” trở thành tín hiệu duy nhất, và đó là tín hiệu tồi.
- Giữ hệ thống mạch lạc khi nó lớn lên. Viết một màn hình thì dễ. Giữ cho 50 màn hình, 20 bảng dữ liệu, 5 tích hợp bên ngoài vẫn nhất quán, an toàn và sửa được sau một năm mới là phần khó. AI viết nhanh nên cũng làm hệ thống rối nhanh hơn nếu không ai giữ kiến trúc.
Vì sao “biết code” không còn là rào cản, nhưng “hiểu phần mềm” vẫn bắt buộc
Hãy xem một ví dụ cụ thể. Chị Lan muốn mỗi đơn hàng có mã dạng BM-YYMMDD-XXX, ví dụ BM-261012-007 là đơn thứ 7 ngày 12/10/2026. Chị nhờ AI viết hàm tạo mã. AI trả về:
// Phiên bản đầu tiên: chạy tốt khi chị Lan thử lúc 3 giờ chiều
function taoMaDon(soThuTu: number): string {
// toISOString() trả về thời gian theo UTC, ví dụ "2026-10-12T08:00:00.000Z"
const yymmdd = new Date().toISOString().slice(2, 10).replaceAll("-", "");
return `BM-${yymmdd}-${String(soThuTu).padStart(3, "0")}`;
}Code ngắn, gọn, chạy được, chị thử và thấy ra đúng BM-261012-001. Nhưng có một lỗi ẩn: toISOString() dùng giờ UTC, trong khi Việt Nam ở múi giờ UTC+7. Một đơn được Hà tạo lúc 6 giờ 30 sáng ngày 12/10 theo giờ Việt Nam thì theo UTC vẫn là 23 giờ 30 ngày 11/10. Kết quả: mã đơn mang ngày hôm trước, báo cáo theo ngày lệch, và đơn sáng sớm ngày lễ bị “lạc” sang ngày cũ.
Phiên bản đúng hơn:
// Lấy ngày theo giờ Việt Nam, không phụ thuộc múi giờ của máy chủ
function taoMaDon(soThuTu: number, thoiDiem: Date = new Date()): string {
const parts = new Intl.DateTimeFormat("en-GB", {
timeZone: "Asia/Ho_Chi_Minh",
year: "2-digit",
month: "2-digit",
day: "2-digit",
}).formatToParts(thoiDiem);
const lay = (loai: string) => parts.find((p) => p.type === loai)?.value ?? "";
return `BM-${lay("year")}${lay("month")}${lay("day")}-${String(soThuTu).padStart(3, "0")}`;
}Và vẫn còn một câu hỏi mà không đoạn code nào tự trả lời: số thứ tự lấy từ đâu? Nếu Hà và nhân viên tiệm Thảo Điền cùng tạo đơn trong cùng một giây, hai đơn có thể nhận cùng số 007. Câu trả lời đúng nằm ở thiết kế dữ liệu: cột orders.code phải có ràng buộc UNIQUE trong database, và việc cấp số phải an toàn khi nhiều người làm cùng lúc. Bạn sẽ học điều này ở bài Cơ sở dữ liệu04-03.
Bài học ở đây: chị Lan không cần tự viết được đoạn code thứ hai. Nhưng chị cần biết để hỏi: “Ngày trong mã đơn tính theo giờ nào? Hai người tạo đơn cùng lúc thì sao?” Đó là hiểu biết về phần mềm, không phải cú pháp. Và AI sẽ trả lời rất tốt nếu được hỏi đúng.
“Hiểu phần mềm” gồm những gì?
Bạn không cần hiểu mọi thứ. Nhưng có một bộ hiểu biết tối thiểu để không bị “mù” khi làm việc với AI:
- Phần mềm gồm dữ liệu, logic và giao diện, và quy tắc nghiệp vụ là trái tim của nó (xem Phần mềm thực chất là gì01-01).
- Web vận hành thế nào: trình duyệt, máy chủ, database nói chuyện với nhau ra sao, và vì sao không được tin dữ liệu từ trình duyệt.
- AI vận hành thế nào: vì sao nó tự tin nói sai, vì sao nó “quên” khi cuộc trò chuyện quá dài.
- Cách kiểm chứng: test, kịch bản thử, tiêu chí nghiệm thu.
- Rủi ro: bảo mật, dữ liệu cá nhân khách hàng, chi phí, khả năng quay lui khi hỏng.
Toàn bộ chuỗi bài được thiết kế để bạn có đúng bộ hiểu biết này, theo thứ tự từ nền tảng tới nâng cao.
Kỹ năng nào mất giá, kỹ năng nào tăng giá
Khi một công việc trở nên rẻ, giá trị dịch chuyển sang những công việc bổ trợ cho nó. Bảng dưới đây là nhận định định tính của chuỗi bài, dựa trên cách các đội ngũ làm phần mềm đang thay đổi quy trình.
| Mất giá (AI làm tốt, rẻ) | Tăng giá (AI cần con người) |
|---|---|
| Nhớ cú pháp, tên hàm, tham số | Hiểu vấn đề nghiệp vụ và người dùng |
| Gõ nhanh code lặp lại (form, bảng, CRUD) | Viết đặc tả rõ ràng, có tiêu chí chấp nhận |
| Dịch code từ ngôn ngữ này sang ngôn ngữ khác | Thiết kế mô hình dữ liệu và kiến trúc |
| Tra cứu cách dùng một thư viện phổ biến | Đọc, review và đánh giá code |
| Viết tài liệu mô tả code đã có | Thiết kế cách kiểm chứng (test, nghiệm thu) |
| Sửa lỗi cú pháp, lỗi kiểu dữ liệu đơn giản | Bảo mật, quyền riêng tư, quản trị rủi ro |
| Dựng khung dự án mẫu | Quản lý ngữ cảnh và chỉ đạo agent |
| Ra quyết định đánh đổi (nhanh hay chắc, mua hay xây) | |
| Vận hành, xử lý sự cố, giao tiếp với người dùng |
Hai lưu ý quan trọng khi đọc bảng này:
- “Mất giá” không có nghĩa là “vô dụng”. Đọc code vẫn cần, vì bạn phải review. Bạn không cần viết thành thạo, nhưng cần đọc được ở mức cơ bản; bài Đọc hiểu code cơ bản01-04 dành riêng cho việc này.
- Cột “tăng giá” phần lớn là kỹ năng của người làm sản phẩm, người quản lý và người kiểm định, những kỹ năng mà chủ doanh nghiệp và marketer thường đã có nền tảng. Chị Lan làm marketer mười năm: chị giỏi hiểu khách hàng, viết brief, đo lường. Đó là lợi thế lớn khi bước vào nghề phần mềm thời AI.
Chân dung “kỹ sư AI” mà chuỗi bài hướng tới
“Kỹ sư AI” trong chuỗi bài này không phải là nhà nghiên cứu trí tuệ nhân tạo. Đó là người làm phần mềm bài bản với AI làm đội thi công. Họ có tám thói quen tư duy, tương ứng với tám tinh thần xuyên suốt của chuỗi bài:
| Thói quen | Biểu hiện cụ thể | Học sâu ở |
|---|---|---|
| Hiểu trước, nhờ AI sau | Mô tả được điều mình muốn, nhận ra khi AI làm sai | Module 01, 02 |
| Đặc tả là nguồn sự thật | Viết rõ “cái gì” và “vì sao” trước khi để AI lo “làm thế nào” | Module 03, 06 |
| Kiểm chứng mọi thứ | Đòi bằng chứng: test, build, ảnh chụp; không tin “trông có vẻ xong” | Module 08 |
| Bước nhỏ, commit thường xuyên | Mỗi thay đổi nhỏ, có điểm lưu để quay lui | Module 06, 07 |
| Ngữ cảnh là tài nguyên quý | Biết đưa gì cho agent, giữ phiên làm việc sạch | Module 02 |
| Bảo mật là trách nhiệm của mình | Không giao phó an toàn dữ liệu khách cho AI | Module 09 |
| Công nghệ đơn giản, phổ biến | Chọn công cụ “nhàm chán”, dễ tuyển người, AI quen thuộc | Module 04 |
| Phần mềm là sinh vật sống | Ra mắt mới là bắt đầu; lên kế hoạch vận hành, bảo trì | Module 10, 11 |
Một kỹ sư AI giỏi không phải là người gõ prompt nhanh nhất. Đó là người mà khi agent báo “đã xong”, họ biết chính xác cần kiểm tra ba điều gì trước khi tin. Bài Vai trò mới của bạn00-04 sẽ cụ thể hóa chân dung này thành năm năng lực có thể rèn luyện và tự đánh giá.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261013-001
13.10.2026
- Chị LanChủ chuỗi
- Anh TuấnBếp trung tâm
- HàBán hàng online
Trước khi bắt đầu chuỗi bài, chị Lan làm một bài kiểm kê nhỏ: liệt kê những việc liên quan tới phần mềm mà chị muốn làm trong năm tới, rồi phân loại xem việc nào AI có thể làm phần lớn, việc nào chị bắt buộc phải tự hiểu và quyết định.
| Việc chị Lan muốn làm | AI làm phần lớn | Chị Lan phải tự hiểu và quyết định |
|---|---|---|
| Form tạo đơn hàng | Viết giao diện, validate dữ liệu | Form cần những trường gì, trường nào bắt buộc |
Mã đơn BM-YYMMDD-XXX |
Viết hàm tạo mã | Ngày theo giờ Việt Nam, mã không được trùng |
| Màn hình bếp | Dựng giao diện danh sách | Anh Tuấn cần thấy gì trước, sắp xếp theo giờ nhận |
| Phân quyền nhân viên | Viết chính sách truy cập | Ai được xem doanh thu, ai được hủy đơn |
| Thanh toán VietQR | Tích hợp theo tài liệu | Đối soát tiền cọc thế nào, xử lý khi chuyển thiếu |
| Lưu thông tin khách | Viết bảng, viết truy vấn | Lưu những gì, xin đồng ý ra sao, ai được xem |
Chị nhận ra một điều thú vị: cột bên phải toàn là những câu hỏi về doanh nghiệp của chính chị, không phải về công nghệ. Không AI nào biết anh Tuấn muốn sắp xếp bánh theo giờ nhận hay theo chi nhánh. Không AI nào được quyền quyết định Hà có được xem doanh thu toàn chuỗi không.
Chị viết vào nhật ký học tập dòng đầu tiên: “AI là đội thi công. Mình là chủ đầu tư kiêm giám sát. Mình không cần biết xây tường, nhưng phải biết đọc bản vẽ và biết tường nào chịu lực.”
Prompt mẫu
Prompt dưới đây giúp bạn dùng AI để tự kiểm kê như chị Lan đã làm, áp dụng cho doanh nghiệp hoặc ý tưởng của riêng bạn.
Điền ô trống rồi sao chép
Tôi là [vai trò của bạn, ví dụ: chủ một chuỗi 3 tiệm bánh], chưa biết lập trình.
Tôi muốn dùng AI coding agent để xây phần mềm [mô tả ngắn, ví dụ: quản lý đơn hàng].
Hãy giúp tôi lập một bảng gồm 3 cột:
1. Các việc cần làm để có phần mềm này (khoảng 8–12 việc).
2. Phần nào AI có thể làm phần lớn.
3. Phần nào tôi BẮT BUỘC phải tự hiểu, tự quyết định hoặc tự kiểm tra, và vì sao.
Yêu cầu:
- Không dùng thuật ngữ kỹ thuật mà không giải thích.
- Với mỗi mục ở cột 3, gợi ý một câu hỏi tôi nên tự trả lời trước khi giao việc cho AI.
- Cuối cùng, liệt kê 3 rủi ro lớn nhất nếu tôi để AI tự quyết mọi thứ.Prompt thứ hai giúp bạn luyện thói quen “biết để hỏi” khi nhận code từ AI:
Điền ô trống rồi sao chép
Đây là một đoạn code AI vừa viết cho tôi: [dán code].
Tôi không biết lập trình. Hãy:
1. Giải thích đoạn code này làm gì bằng ngôn ngữ đời thường, không quá 5 câu.
2. Liệt kê các tình huống thực tế mà đoạn code này có thể cho kết quả sai
(ví dụ: múi giờ, hai người thao tác cùng lúc, dữ liệu trống, số âm).
3. Với mỗi tình huống, cho tôi một câu hỏi để kiểm tra lại với người viết code.
Đừng sửa code, chỉ phân tích.Sai lầm thường gặp
-
Sự cố 01
Nghĩ rằng AI viết code được thì không cần học gì nữa.
Triệu chứngĐây là cách nhanh nhất để có một ứng dụng chạy được demo nhưng sụp đổ khi dùng thật.
Cách tránhcoi AI là đội thi công và đầu tư thời gian học “đọc bản vẽ”, tức là các kiến thức nền ở module 01–04.
-
Sự cố 02
Nghĩ rằng phải học lập trình bài bản như sinh viên CNTT mới dùng được AI.
Triệu chứngNgược lại với sai lầm trên, nhiều người nản vì tưởng phải học cú pháp hàng năm.
Cách tránhtập trung vào đọc hiểu và tư duy hệ thống; cú pháp để AI lo, bạn học dần khi cần.
-
Sự cố 03
Đánh giá AI qua lần thử đầu tiên.
Triệu chứngThấy AI làm đúng một lần thì tin tuyệt đối, hoặc thấy sai một lần thì bỏ hẳn.
Cách tránhđánh giá AI như đánh giá một nhân viên mới, qua nhiều việc, với tiêu chí rõ ràng và cơ chế kiểm tra.
-
Sự cố 04
Đo năng suất bằng số dòng code hay tốc độ.
Triệu chứngAI có thể sinh ra hàng nghìn dòng code trong một giờ, nhưng code nhiều không có nghĩa là giá trị nhiều.
Cách tránhđo bằng vấn đề nghiệp vụ được giải quyết (ví dụ: thời gian đối soát cuối ngày giảm từ 2 giờ xuống 15 phút), xem bài Đo lường thành công03-08.
-
Sự cố 05
Giao cả trách nhiệm cùng với công việc.
Triệu chứng“AI viết mà, chắc đúng.”
Cách tránhghi nhớ rằng bạn ký tên dưới mọi thay đổi được đưa tới người dùng thật; mọi thay đổi đều cần ít nhất một bước kiểm chứng do bạn chủ động.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Kiểm kê công việc
Dùng prompt mẫu thứ nhất cho doanh nghiệp hoặc ý tưởng của bạn. Đọc kỹ cột “tôi phải tự quyết định” và đánh dấu những mục bạn chưa trả lời được.
Kết quả mong đợi
một bảng 8–12 dòng; bạn nhận ra ít nhất 3 câu hỏi về nghiệp vụ mà trước đây bạn nghĩ “để lập trình viên lo”.
-
Bài 2
Cơ bản
Săn lỗi “trông đúng”
Nhờ một chatbot AI viết hàm tính tiền cọc 50% cho một đơn bánh, làm tròn tới nghìn đồng. Sau đó dùng prompt mẫu thứ hai để hỏi về các tình huống có thể sai.
Kết quả mong đợi
bạn tìm được ít nhất 2 câu hỏi nghiệp vụ mà đoạn code chưa trả lời, ví dụ “làm tròn lên hay xuống?”, “đơn có phí giao hàng thì cọc tính trên tổng nào?”.
-
Bài 3
Nâng cao
Bản đồ kỹ năng cá nhân
Lấy bảng “mất giá / tăng giá” ở trên, tự chấm điểm bản thân từ 0 đến 3 cho từng kỹ năng ở cột “tăng giá”. Chọn hai kỹ năng điểm thấp nhất làm mục tiêu cho ba tháng tới.
Kết quả mong đợi
một đoạn ngắn trong nhật ký học tập, ghi rõ hai mục tiêu và module tương ứng trong chuỗi bài.
Thuật ngữ trong bài
- Coding agent (tác tử lập trình)
- Công cụ AI có thể tự đọc mã nguồn, sửa file, chạy lệnh và lặp lại tới khi đạt mục tiêu
- Autocomplete (tự hoàn thành)
- AI đoán và gợi ý đoạn code tiếp theo khi bạn đang gõ
- Cú pháp (syntax)
- Quy tắc viết của một ngôn ngữ lập trình
- Đặc tả (spec)
- Tài liệu mô tả rõ phần mềm cần làm gì, cho ai, tiêu chí đúng sai
- Kiểm chứng (verification)
- Chứng minh kết quả đúng bằng test, kịch bản thử, bằng chứng cụ thể
- UTC
- Giờ phối hợp quốc tế; giờ Việt Nam là UTC+7
- Ràng buộc UNIQUE
- Quy tắc trong database đảm bảo một giá trị không bị trùng
- Trường hợp biên (edge case)
- Tình huống ít gặp nhưng dễ làm phần mềm sai
- Kỹ sư AI
- Trong chuỗi bài: người làm phần mềm bài bản, chỉ đạo AI và chịu trách nhiệm kết quả
Đọc thêm
- Báo cáo và nghiên cứu của DORA về hiệu quả phát triển phần mềm, bao gồm vai trò của AI.
- Từ chatbot đến coding agent02-02: giải phẫu vòng lặp agent.
- Mô hình ngôn ngữ lớn hoạt động thế nào02-01: vì sao AI tự tin nói sai.
- Phần mềm thực chất là gì01-01: nền tảng để “hiểu phần mềm”.
Nghiệm thu tờ 00-01
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
