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
LLM là gì: chiếc bàn phím gợi ý chữ phiên bản khổng lồ
Bạn đã quen với bàn phím điện thoại gợi ý chữ tiếp theo: gõ “Chúc mừng sinh” thì nó gợi ý “nhật”. Bàn phím đó học từ những gì bạn hay gõ. Mô hình ngôn ngữ lớn (Large Language Model, viết tắt LLM) về bản chất làm cùng một việc, nhưng ở quy mô lớn hơn rất nhiều lần: nó học từ một lượng khổng lồ sách, bài viết, tài liệu kỹ thuật và mã nguồn công khai.
Qua quá trình học đó, mô hình không “chép” lại từng câu mà nắm được các quy luật: câu tiếng Việt thường được cấu tạo ra sao, một hàm TypeScript thường trông thế nào, sau câu “lỗi này do thiếu biến môi trường” thường là lời khuyên gì. Khi bạn hỏi, mô hình dùng những quy luật đó để viết tiếp câu trả lời có khả năng cao nhất.
Sau giai đoạn học “đọc mọi thứ” (tiền huấn luyện, pretraining), mô hình còn được tinh chỉnh để biết làm theo hướng dẫn và cư xử như một trợ lý.
Vòng lặp tạo câu trả lời
Mỗi câu trả lời được tạo ra theo một vòng lặp lặp đi lặp lại rất nhanh:
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Bạn gửi câu hỏi → Cắt thành token
- Cắt thành token → Mô hình tính xác suất cho token tiếp theo
- Mô hình tính xác suất cho token tiếp theo → Chọn một token
- Chọn một token → Nối token vào văn bản
- Nối token vào văn bản → Đã đủ câu trả lời?
- Đã đủ câu trả lời? → Mô hình tính xác suất cho token tiếp theo (Chưa)
- Đã đủ câu trả lời? → Hiển thị câu trả lời (Rồi)
Điểm then chốt: mô hình viết từng mảnh một, mỗi mảnh dựa trên toàn bộ những gì đứng trước nó (câu hỏi của bạn cộng phần nó đã viết). Nó không lập sẵn toàn bộ câu trả lời trong đầu rồi mới viết ra như con người. Đó là lý do khi bạn yêu cầu “hãy lập kế hoạch trước rồi mới viết code”, chất lượng thường tốt hơn: phần kế hoạch đã viết trở thành nền để các token sau dựa vào.
Token: đơn vị đo mọi thứ
Token là gì
Mô hình không đọc theo chữ cái hay theo từ như chúng ta, mà theo token (mảnh văn bản). Một token có thể là một từ ngắn, một phần của từ dài, một dấu câu, hoặc một khoảng trắng kèm vài ký tự. Ví dụ, câu “Bánh kem dâu size 20cm” có thể bị cắt thành chừng mười mảnh; cách cắt cụ thể phụ thuộc bộ tách token (tokenizer) của từng mô hình.
Code cũng là token. Một dòng const total = subtotal + shippingFee; bị cắt thành các mảnh như const, total, =, subtotal… Một file code dài vài trăm dòng có thể tốn vài nghìn token.
Vì sao token quan trọng với bạn
Token là “đơn vị tiền tệ” của thế giới LLM:
- Chi phí tính theo token: số token bạn gửi vào (input) và số token mô hình viết ra (output). Bài Giới hạn, rủi ro và chi phí khi làm việc với AI02-08 sẽ hướng dẫn cách ước tính.
- Giới hạn bộ nhớ tính theo token: mô hình chỉ xử lý được một số token nhất định trong một lần.
- Tốc độ phụ thuộc token: câu trả lời càng dài, chờ càng lâu.
Cửa sổ ngữ cảnh: chiếc bàn làm việc có kích thước cố định
Hình dung
Hãy tưởng tượng mô hình là một nhân viên rất giỏi nhưng mất trí nhớ sau mỗi cuộc gặp. Mỗi lần bạn hỏi, mọi thứ nó cần biết phải được bày lên một chiếc bàn làm việc: câu hỏi của bạn, lịch sử trò chuyện trước đó, nội dung file bạn đưa, hướng dẫn hệ thống. Chiếc bàn đó gọi là cửa sổ ngữ cảnh (context window). Thứ gì không nằm trên bàn, nó không biết.
Bàn có kích thước cố định, đo bằng token. Tại thời điểm viết (2026), các mô hình phổ biến có cửa sổ ngữ cảnh từ khoảng vài trăm nghìn đến cỡ một triệu token tùy dòng và gói dịch vụ; con số thay đổi liên tục nên hãy kiểm tra trang chính thức của nhà cung cấp.
Ba sự thật dễ bị hiểu lầm
- Mô hình không nhớ giữa các phiên. Cảm giác “nó nhớ cuộc trò chuyện” đến từ việc ứng dụng gửi lại toàn bộ lịch sử lên bàn ở mỗi lượt. Mở cuộc trò chuyện mới là bàn trống trơn.
- Bàn đầy thì phải dọn. Khi lịch sử quá dài, công cụ sẽ cắt bớt hoặc tóm tắt phần cũ. Thông tin quan trọng bạn nói từ đầu có thể bị rơi mất.
- Bàn càng bừa, làm việc càng kém. Nhồi nhiều thứ không liên quan khiến mô hình khó tập trung vào điều quan trọng. Bài Context engineering02-05 sẽ đi sâu vào chuyện này.
Dự đoán xác suất và tính không tất định
Mô hình chọn chữ như thế nào
Ở mỗi bước, mô hình không biết “câu trả lời đúng” mà tính ra một bảng xác suất cho mọi token có thể đứng tiếp. Giả sử câu đang viết là “Trạng thái đơn hàng chuyển sang”, bảng xác suất có thể trông như sau (số liệu minh họa):
- đã xác nhận
- đang làm
- hoàn tất
- đã hủy
- các lựa chọn khác
- Nhiệt độ
| Token tiếp theo | Xác suất (minh họa) |
|---|---|
| “đã xác nhận” | 38% |
| “đang làm” | 22% |
| “hoàn tất” | 17% |
| “đã hủy” | 9% |
| các lựa chọn khác | 14% |
Mô hình sẽ chọn một token theo bảng này. Nếu luôn chọn token có xác suất cao nhất, câu trả lời sẽ ổn định nhưng dễ đơn điệu. Nếu cho phép chọn cả những token xác suất thấp hơn, câu trả lời đa dạng, sáng tạo hơn nhưng dễ “lạc đề”.
Nhiệt độ (temperature)
Nhiệt độ là núm vặn điều chỉnh mức “liều lĩnh” khi chọn token. Nhiệt độ thấp: gần như luôn chọn lựa chọn an toàn nhất, phù hợp với code và trích xuất dữ liệu. Nhiệt độ cao: chọn táo bạo hơn, phù hợp viết slogan, nghĩ tên sản phẩm. Khi dùng coding agent, bạn thường không chỉnh núm này; nhà cung cấp đã đặt sẵn. Khi tự xây tính năng AI trong sản phẩm ở module 12, bạn sẽ gặp lại nó.
Không tất định: cùng câu hỏi, khác câu trả lời
Vì có yếu tố chọn ngẫu nhiên theo xác suất, cùng một prompt chạy hai lần có thể cho hai đoạn code khác nhau. Một lần agent viết hàm tính tiền dùng vòng lặp, lần khác dùng reduce. Một lần nó nhớ xử lý đơn rỗng, lần khác quên.
Hệ quả thực tế cho người làm phần mềm:
- Không thể kiểm chứng bằng cách “hỏi lại xem nó có nói giống không”. Hai câu trả lời giống nhau vẫn có thể cùng sai.
- Kiểm chứng phải dựa trên thứ tất định: test tự động, trình biên dịch, kết quả chạy thật. Một bài test chạy 100 lần cho cùng kết quả; AI thì không.
- Kết quả tốt một lần không đảm bảo lần sau. Quy trình (spec, test, review) mới là thứ tạo ra chất lượng ổn định, không phải “trúng prompt hay”.
Ảo giác: khi AI tự tin nói sai
Vì sao ảo giác xảy ra
Ảo giác (hallucination) là khi mô hình tạo ra thông tin nghe rất thuyết phục nhưng sai hoặc không tồn tại. Nguyên nhân nằm ngay trong cách nó hoạt động: mô hình được tối ưu để viết tiếp văn bản hợp lý, và trong phần lớn văn bản nó đã học, người viết trả lời một cách tự tin. Khi gặp điều nó không chắc, xác suất cao nhất thường vẫn là một câu trả lời tự tin, chứ không phải “tôi không biết”.
Hãy hình dung một nhân viên mới rất muốn làm hài lòng sếp: được hỏi về một quy trình chưa từng thấy, thay vì thừa nhận không biết, cậu ấy ghép từ những gì nghe “na ná” và trình bày rất trôi chảy.
Ảo giác trong lập trình trông như thế nào
Trong code, ảo giác đặc biệt nguy hiểm vì nó trông giống hệt code thật. Các dạng thường gặp:
| Dạng ảo giác | Ví dụ minh họa | Cách lộ ra |
|---|---|---|
| Thư viện không tồn tại | import { toVND } from "vn-money-utils" (tên do bài viết đặt ra để minh họa) |
Cài gói báo không tìm thấy, hoặc tệ hơn: có kẻ xấu đã đăng ký đúng tên đó |
| Hàm/phương thức bịa | db.orders.findByPhone(phone) trong Drizzle |
Trình kiểm tra kiểu (type checker) báo lỗi “không tồn tại” |
| Tùy chọn cấu hình bịa | Thêm khóa cấu hình nghe hợp lý nhưng framework không hỗ trợ | Cấu hình bị bỏ qua âm thầm, tính năng không chạy |
| Trộn phiên bản | Dùng cách viết của phiên bản cũ trong dự án dùng phiên bản mới | Cảnh báo deprecated, lỗi khi build |
| Bịa nguồn | “Theo tài liệu chính thức, hàm này tự động mã hóa dữ liệu” | Mở tài liệu thật thì không có câu đó |
Ví dụ cụ thể với stack của Bánh Mộc. Bạn nhờ AI viết hàm tìm khách hàng theo số điện thoại, nó trả về:
// ❌ Ảo giác: Drizzle ORM KHÔNG có phương thức findByPhone tự sinh như thế này
import { db } from "@/db";
export async function findCustomer(phone: string) {
return db.orders.findByPhone(phone); // sai cả bảng lẫn phương thức
}Code này đọc lên rất “thuận mắt”, nhưng sai hai chỗ: tìm khách hàng lại truy vấn bảng orders, và phương thức findByPhone không tồn tại. Phiên bản đúng theo cách Drizzle hoạt động:
// ✅ Đúng: dùng select + where với hàm so sánh eq của Drizzle
import { eq } from "drizzle-orm";
import { db } from "@/db";
import { customers } from "@/db/schema";
export async function findCustomerByPhone(phone: string) {
const rows = await db
.select()
.from(customers)
.where(eq(customers.phone, phone)) // phone là cột UNIQUE
.limit(1);
return rows[0] ?? null; // không tìm thấy thì trả về null
}Tương tự, khi cần định dạng tiền VNĐ, AI có thể gợi ý cài một gói lạ, trong khi JavaScript đã có sẵn công cụ chuẩn:
// Không cần thư viện ngoài: Intl là API có sẵn trong JavaScript
const formatVND = (amount: number) =>
new Intl.NumberFormat("vi-VN", { style: "currency", currency: "VND" }).format(amount);
formatVND(350000); // "350.000 ₫"Cách phát hiện ảo giác
Bạn không cần thuộc mọi thư viện để phát hiện ảo giác. Bạn cần những người gác cổng không biết nói dối:
- Trình kiểm tra kiểu và trình biên dịch. TypeScript sẽ báo ngay khi gọi một hàm không tồn tại. Đây là một lý do lớn để chuỗi bài chọn TypeScript thay vì JavaScript thuần.
- Chạy thật. Chạy lệnh build, chạy test, mở trình duyệt xem. Code bịa thường gãy ngay lần chạy đầu.
- Kiểm tra gói trước khi cài. Tra tên gói trên trang npm, xem số lượt tải, ngày cập nhật, kho mã nguồn. Có thể dùng lệnh
npm view ten-goiđể xem thông tin gói trước khi cài. - Đối chiếu tài liệu chính thức. Khi AI nói “tài liệu viết rằng…”, yêu cầu nó trích nguồn, rồi tự mở trang đó.
Điều thú vị: coding agent (bài tiếp theo) ít bị ảo giác hơn chatbot trong nhiều tình huống, vì nó có thể tự đọc code thật trong dự án và tự chạy lệnh kiểm tra. Khi agent chạy type check và thấy lỗi, nó tự sửa trước khi bạn kịp nhìn thấy. Đó là sức mạnh của việc cho AI công cụ kiểm chứng.
Kiến thức có ngày cắt (knowledge cutoff)
Mô hình “đóng băng” ở một thời điểm
Mô hình học từ dữ liệu được thu thập tới một ngày nhất định, gọi là ngày cắt kiến thức (knowledge cutoff). Sau ngày đó, thế giới vẫn chạy: thư viện ra phiên bản mới, API đổi tên, tính năng bị khai tử. Mô hình không biết những thay đổi đó trừ khi bạn hoặc công cụ đưa thông tin mới vào ngữ cảnh.
Thêm một điểm tinh tế: kể cả trước ngày cắt, phiên bản mới nhất của một thư viện thường có ít ví dụ trên mạng hơn phiên bản cũ đã tồn tại nhiều năm. Vì vậy mô hình có xu hướng “quen tay” với cách viết cũ.
Ví dụ quen thuộc trong hệ sinh thái web
- Next.js có hai cách tổ chức: Pages Router (cũ) và App Router (mới hơn, chuỗi bài dùng cách này). AI đôi khi trộn hàm đặc trưng của Pages Router như
getServerSidePropsvào dự án App Router, nơi nó không còn tác dụng. - Tailwind CSS từ phiên bản 4 chuyển nhiều cấu hình từ file JavaScript sang khai báo trong CSS. Mô hình quen phiên bản cũ có thể tạo file cấu hình kiểu cũ.
- Thư viện bạn mới cài hôm qua có thể ra đời sau ngày cắt của mô hình; nó sẽ đoán cách dùng dựa trên những thư viện “na ná”.
Cách bù đắp
- Khai báo phiên bản rõ ràng trong file hướng dẫn của dự án (bài AGENTS.md, rules và skills02-06), ví dụ “Next.js App Router, Tailwind v4, Drizzle ORM”.
- Đưa tài liệu vào ngữ cảnh: dán đoạn tài liệu liên quan, hoặc cho agent đọc trang tài liệu chính thức nếu nó có công cụ duyệt web.
- Cho agent đọc code thật: trong dự án có sẵn, agent có thể đọc
package.jsonđể biết phiên bản và bắt chước cách viết đã có trong codebase. - Ưu tiên công nghệ phổ biến, ổn định. Công nghệ “nhàm chán” có nhiều dữ liệu huấn luyện, AI viết tốt hơn hẳn. Bài Chọn tech stack04-06 sẽ phân tích kỹ.
Hệ quả thực tế: từ hiểu biết đến thói quen
Gom tất cả lại, mỗi đặc tính của LLM dẫn tới một thói quen làm việc cụ thể:
| Đặc tính của LLM | Hệ quả | Thói quen của bạn |
|---|---|---|
| Đoán token tiếp theo, không tra cứu sự thật | Trôi chảy nhưng có thể sai | Kiểm chứng bằng test, build, chạy thật |
| Cửa sổ ngữ cảnh có hạn, không nhớ giữa phiên | Quên điều đã nói, chất lượng giảm khi đầy | Ghi quyết định vào file, mở phiên mới cho việc mới |
| Không tất định | Mỗi lần chạy khác nhau | Dựa vào quy trình, không dựa vào “may mắn” |
| Ảo giác | Bịa thư viện, hàm, nguồn | Kiểm tra gói, dùng TypeScript, đối chiếu tài liệu |
| Ngày cắt kiến thức | Dùng cách viết cũ | Khai báo phiên bản, đưa tài liệu mới vào ngữ cảnh |
| Viết từng mảnh dựa trên phần trước | Lập kế hoạch trước cho kết quả tốt hơn | Yêu cầu kế hoạch trước khi code |
Bạn không cần biết mô hình có bao nhiêu tham số; bạn cần biết nó yếu ở đâu để thiết kế quy trình bù vào.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261012-015
12.10.2026
- Chị LanChủ chuỗi
- HàBán hàng online
Chị Lan nhớ lại lần đầu “vibe” một app đặt bánh. Chị hỏi một chatbot: “Viết giúp chị đoạn code tạo mã QR chuyển khoản cho đơn hàng”. Chatbot trả lời ngay, kèm lệnh cài một gói có tên nghe rất chuyên nghiệp. Chị chạy lệnh, máy báo không tìm thấy gói. Chị hỏi lại, chatbot xin lỗi và đưa một tên gói khác, cũng không tồn tại. Lần thứ ba thì cài được một gói có thật, nhưng nhìn kỹ thì gói đó chỉ có vài lượt tải, đăng lên vài tuần trước, không có kho mã nguồn. Hồi đó chị không biết, cứ thế dùng.
Sau khi học bài này, chị Lan đặt ra ba quy tắc cho dự án Mộc OMS và ghi vào sổ tay:
- Không cài thư viện mới nếu chưa kiểm tra. Mỗi khi AI đề xuất thêm gói, chị yêu cầu nó giải thích vì sao không dùng được thứ có sẵn, và tự xem thông tin gói trên trang npm.
- TypeScript ở chế độ nghiêm ngặt và lệnh type check phải xanh. Bất kỳ hàm bịa nào cũng bị bắt trước khi tới tay Hà và nhân viên tiệm.
- Ghi rõ phiên bản công nghệ vào file hướng dẫn cho agent, để AI không trộn Next.js cũ với mới.
Một tình huống khác: Hà hỏi AI “Khách hàng có số điện thoại 0909… đặt bao nhiêu đơn tháng trước?”. Chatbot đưa ra con số 7 rất tự tin, trong khi nó không hề có dữ liệu đơn hàng của Bánh Mộc. Chị Lan giải thích cho Hà: AI chỉ biết những gì nằm trong ngữ cảnh; nếu chưa đưa dữ liệu vào thì mọi con số nó nói về tiệm mình đều là bịa. Bài học này sẽ quay lại ở module 12, khi Bánh Mộc xây trợ lý AI truy vấn được dữ liệu đơn hàng.
Prompt mẫu
Prompt yêu cầu AI tự khai báo mức độ chắc chắn khi đề xuất thư viện:
Điền ô trống rồi sao chép
Mình cần định dạng số tiền VNĐ trong dự án Next.js + TypeScript.
Trước khi đề xuất cài thư viện mới, hãy:
1. Cho biết có cách nào dùng API có sẵn của JavaScript/TypeScript không.
2. Nếu vẫn cần thư viện, nêu tên gói chính xác, đường dẫn trang npm và kho mã nguồn,
và nói rõ nếu bạn KHÔNG chắc gói đó tồn tại hoặc còn được bảo trì.
3. Không tự chạy lệnh cài đặt; chờ mình xác nhận.Prompt chống trộn phiên bản:
Điền ô trống rồi sao chép
Dự án dùng Next.js App Router (không dùng Pages Router), Tailwind CSS v4, Drizzle ORM.
Hãy đọc package.json để xác nhận phiên bản trước khi viết code.
Nếu cách viết bạn định dùng có thể thuộc phiên bản cũ, hãy cảnh báo và đề xuất cách
kiểm tra trong tài liệu chính thức.Prompt kiểm tra ngược một đoạn code nghi ngờ:
Điền ô trống rồi sao chép
Trong đoạn code dưới đây, liệt kê mọi hàm, phương thức, gói được import.
Với mỗi mục, cho biết: nó thuộc thư viện nào, bạn chắc chắn nó tồn tại không (chắc / không chắc),
và cách mình tự kiểm chứng (lệnh nào, trang tài liệu nào).
[dán đoạn code]Sai lầm thường gặp
-
Sự cố 01
Coi câu trả lời trôi chảy là câu trả lời đúng.
Triệu chứngVăn phong tự tin là đặc tính của mô hình, không phải tín hiệu độ chính xác.
Cách tránhMặc định mọi câu trả lời là “bản nháp cần kiểm chứng” cho tới khi có test, build hoặc tài liệu chính thức xác nhận.
-
Sự cố 02
Cài ngay mọi thư viện AI gợi ý.
Triệu chứngĐây là cửa ngõ cho cả lỗi lẫn mã độc.
Cách tránhKiểm tra tên gói, lượt tải, kho mã nguồn; ưu tiên API có sẵn và thư viện đã có trong dự án.
-
Sự cố 03
Nghĩ rằng AI “nhớ” cuộc trò chuyện hôm qua.
Triệu chứngMở phiên mới là bàn trống; dặn dò hôm qua đã mất.
Cách tránhGhi quy ước, quyết định vào file trong dự án (file hướng dẫn, spec) để lần nào cũng nạp lại được.
-
Sự cố 04
Hỏi AI về dữ liệu riêng của doanh nghiệp mà không đưa dữ liệu vào.
Triệu chứngMô hình sẽ bịa con số nghe hợp lý.
Cách tránhChỉ hỏi về dữ liệu bạn đã cung cấp trong ngữ cảnh, hoặc dùng công cụ cho phép AI truy vấn dữ liệu thật.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Săn ảo giác
Hỏi một chatbot bất kỳ: “Viết hàm TypeScript dùng Drizzle ORM để lấy 10 đơn hàng mới nhất của một khách hàng theo số điện thoại”. Đọc kết quả và liệt kê mọi gói, hàm được dùng. Tra tài liệu chính thức của Drizzle để đánh dấu cái nào có thật.
Kết quả mong đợi
Một danh sách có đánh dấu “có thật / không chắc / bịa”. Nhiều khả năng bạn thấy phần lớn đúng, nhưng có thể có một vài chi tiết sai như tên hàm hoặc cách nối bảng.
-
Bài 2
Cơ bản
Thử tính không tất định
Gửi cùng một prompt “Viết hàm tính tổng tiền đơn bánh gồm tiền hàng, phí giao, trừ tiền cọc” ba lần trong ba phiên mới. So sánh ba kết quả: cách đặt tên, cách xử lý tiền cọc lớn hơn tổng, cách xử lý số âm.
Kết quả mong đợi
Ba phiên bản khác nhau ít nhiều; ít nhất một phiên bản bỏ sót một trường hợp biên. Từ đó bạn thấy vì sao cần tiêu chí kiểm chứng rõ trong prompt (bài 02-04).
-
Bài 3
Nâng cao
Thử ngày cắt kiến thức
Chọn một thư viện bạn biết vừa ra phiên bản lớn gần đây. Hỏi AI cách cấu hình nó mà không nói phiên bản, sau đó hỏi lại kèm đoạn tài liệu mới nhất bạn dán vào.
Kết quả mong đợi
Lần đầu có thể ra cách viết cũ; lần hai bám đúng tài liệu bạn cung cấp. Ghi lại nhận xét: ngữ cảnh bạn đưa vào thay đổi kết quả mạnh đến mức nào.
Thuật ngữ trong bài
- LLM (Large Language Model)
- Mô hình ngôn ngữ lớn, học từ lượng văn bản khổng lồ để tạo văn bản và code
- Token
- Mảnh văn bản nhỏ mà mô hình đọc và viết; đơn vị tính chi phí và giới hạn
- Cửa sổ ngữ cảnh (context window)
- Lượng token tối đa mô hình “nhìn thấy” trong một lần xử lý
- Nhiệt độ (temperature)
- Núm điều chỉnh độ ngẫu nhiên khi chọn token tiếp theo
- Không tất định (non-deterministic)
- Cùng đầu vào có thể cho kết quả khác nhau
- Ảo giác (hallucination)
- Thông tin sai hoặc bịa nhưng được trình bày tự tin
- Ngày cắt kiến thức (knowledge cutoff)
- Thời điểm dữ liệu huấn luyện dừng lại
- Tiền huấn luyện (pretraining)
- Giai đoạn mô hình học từ dữ liệu lớn trước khi được tinh chỉnh
- Type checker
- Công cụ kiểm tra kiểu dữ liệu, bắt lỗi gọi hàm không tồn tại trước khi chạy
- Slopsquatting
- Kẻ xấu đăng ký tên gói mà AI hay bịa để phát tán mã độc
Đọc thêm
- Tài liệu Next.js (App Router) để đối chiếu cách viết đúng: https://nextjs.org/docs
- MDN về
Intl.NumberFormatvà JavaScript chuẩn: https://developer.mozilla.org - Tài liệu coding agent của các nhà cung cấp, ví dụ: https://code.claude.com/docs
- Bài liên quan: Vibe coding và kỹ sư AI00-02, An toàn chuỗi cung ứng phần mềm09-05, Context engineering02-05
Nghiệm thu tờ 02-01
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
