Viết prompt cho lập trình

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

Viết prompt kỹ thuật theo cấu trúc năm phần, dùng được cho mọi coding agent.
Chỉ đúng file, mẫu có sẵn và phạm vi để agent không đi lạc.
Biến “xong” thành tiêu chí kiểm chứng cụ thể: test, lệnh build, ảnh chụp màn hình.
Dùng kỹ thuật “AI phỏng vấn ngược” cho tính năng lớn.
Nhận ra và sửa prompt mơ hồ qua bảng trước/sau thực tế.

Vì sao prompt cho lập trình khác prompt thông thường

Khi nhờ AI viết caption Facebook, prompt hơi mơ hồ cũng không sao: bạn đọc kết quả, thích thì dùng, không thích thì bảo viết lại. Sai lệch lộ ra ngay và rẻ.

Với code, sai lệch thường ẩn. Bạn nói “thêm tính năng hủy đơn”, agent làm xong, giao diện có nút hủy, bấm được. Ba tuần sau mới phát hiện: hủy đơn đã đặt cọc không ghi nhận hoàn tiền, nhân viên nào cũng hủy được đơn bếp đang làm, lịch sử trạng thái không lưu. Không phải AI kém; nó đã phải đoán những điều bạn không nói, và đoán theo kiểu phổ biến nhất trên mạng chứ không theo nghiệp vụ của tiệm bánh bạn.

Nhớ lại bài LLM hoạt động thế nào02-01: mô hình chỉ biết những gì có trong ngữ cảnh. Prompt là phần quan trọng nhất của ngữ cảnh đó. Giao việc cho agent giống giao việc cho một nhân viên rất giỏi nhưng mới vào làm hôm nay: họ không biết quy ước tiệm, không biết anh Tuấn cần thấy gì, không biết “xong” nghĩa là gì với bạn.

Cấu trúc prompt năm phần

Phần	Trả lời câu hỏi	Ví dụ ngắn
1. Mục tiêu	Cần đạt điều gì, vì sao?	“Cho phép nhân viên hủy đơn, để đơn hủy không còn hiện ở màn hình bếp.”
2. Bối cảnh	Đang ở đâu, liên quan file/dữ liệu nào?	“Logic trạng thái đơn ở `src/features/orders/status.ts`; bảng `order_status_history` đã có.”
3. Ràng buộc	Không được làm gì, giới hạn ở đâu?	“Chỉ hủy được trước `dang_giao` (`moi`, `da_xac_nhan`, `dang_lam`). Không đổi schema.”
4. Ví dụ hoặc mẫu	Làm theo cách nào đã có?	“Làm tương tự hàm `confirmOrder` trong cùng file.”
5. Tiêu chí hoàn thành	Làm sao biết đã xong và đúng?	“Có unit test cho 3 trường hợp; `npm test` và `npm run typecheck` xanh; dán output.”

Phần 1: Mục tiêu, kèm “vì sao”

Nêu kết quả mong muốn, không chỉ hành động. “Thêm cột zalo_id” là hành động; “Để Hà tìm được khách theo Zalo khi khách nhắn tin không để lại số điện thoại” là mục tiêu. Khi agent biết vì sao, nó đưa ra lựa chọn phụ hợp lý hơn: có thể đề xuất thêm ô tìm kiếm, có thể hỏi lại khi gặp tình huống không rõ.

Hình chữ ký Trước / sau

Prompt mơ hồ
Prompt tốt
Mục tiêu
Bối cảnh
Ràng buộc
Ví dụ hoặc mẫu
Tiêu chí hoàn thành

Phần 2: Bối cảnh, chỉ đúng chỗ

Agent có thể tự tìm file, nhưng mỗi lần tìm là tốn ngữ cảnh và có thể tìm nhầm. Hãy chỉ:

File hoặc thư mục liên quan: “trong src/features/customers/“.
Dữ liệu liên quan: tên bảng, tên cột (dùng đúng tên như customers.phone, orders.delivery_at).
Tài liệu liên quan: “spec ở docs/specs/tao-don-hang.md“.
Tình trạng hiện tại: “trang đang hiện lỗi X”, “test Y đang đỏ”.

Phần 3: Ràng buộc, rào trước những lối tắt nguy hiểm

Ràng buộc chặn những hướng đi bạn không muốn: “không cài thư viện mới”, “không sửa schema database”, “chỉ sửa trong thư mục này”, “không đổi hành vi của API hiện có”, “tiền là số nguyên VNĐ”. Đây cũng là nơi nêu ngoài phạm vi: “chưa cần xử lý hoàn tiền, sẽ làm ở task sau”.

Phần 4: Ví dụ hoặc mẫu có sẵn

Câu mạnh nhất trong một prompt lập trình thường là: “Làm theo cách của file X.” Nếu dự án đã có trang danh sách khách hàng, khi làm trang danh sách sản phẩm hãy bảo agent bắt chước nó. Kết quả nhất quán, ít bất ngờ, dễ review. Với logic, ví dụ đầu vào và đầu ra cụ thể còn rõ hơn cả trăm chữ mô tả.

Phần 5: Tiêu chí hoàn thành có thể kiểm chứng

Như bài Từ chatbot đến coding agent02-02 đã chỉ ra, agent dừng khi nó nghĩ đã xong. Tiêu chí hoàn thành biến “nghĩ” thành “chứng minh”. Chi tiết ở mục ngay dưới.

Bàn thử

Dán prompt → đánh dấu đủ/thiếu 5 phần (có ‘để…’, có đường dẫn file/bảng, có ràng buộc ‘không…’, có ‘làm theo…’, có lệnh hoặc ca kiểm thử) và nhắc che SĐT, khóa trước khi gửi

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.

Chỉ ra file, mẫu có sẵn và phạm vi

Ba câu hỏi trước khi gửi

Agent có biết bắt đầu từ đâu không? Nếu chính bạn không biết file nào liên quan, hãy giao một bước “khám phá” trước: “Tìm xem logic tính tiền đơn nằm ở đâu, chưa sửa gì, báo lại cho mình.”
Agent có biết làm theo kiểu nào không? Chỉ một mẫu có sẵn, hoặc nêu quy ước.
Agent có biết dừng ở đâu không? Nêu rõ phạm vi để nó không “tiện tay” sửa thêm mười file khác.

Cho agent dữ liệu thật thay vì mô tả

Thông báo lỗi: dán nguyên văn, đừng tóm tắt “nó báo lỗi gì đó về kiểu”.
Ảnh chụp màn hình: hầu hết agent hiện nay đọc được ảnh. Một ảnh chụp giao diện bị vỡ hoặc bản thiết kế mong muốn rõ hơn ba đoạn mô tả.
Dữ liệu mẫu: vài dòng đơn hàng thật (đã che thông tin cá nhân) giúp agent hiểu dữ liệu thực tế trông thế nào.
Đường dẫn tài liệu: với thư viện mới, chỉ trang tài liệu chính thức để bù cho ngày cắt kiến thức.

Tiêu chí kiểm chứng: test, ảnh chụp, lệnh build

Các loại tiêu chí

Loại tiêu chí	Dùng khi	Câu mẫu trong prompt
Ca kiểm thử cụ thể	Logic, tính toán, chuyển trạng thái	“Viết test cho: đơn 350.000đ + ship 30.000đ = 380.000đ; cọc lớn hơn tổng thì báo lỗi.”
Lệnh phải xanh	Mọi thay đổi code	“Chạy `npm run typecheck`, `npm run lint`, `npm test`; dán output.”
Build thành công	Thay đổi cấu hình, thư viện	“Chạy `npm run build` và xác nhận thành công.”
Ảnh chụp màn hình	Giao diện	“Mở `/orders/new` ở local, chụp màn hình ở khổ điện thoại, so với ảnh thiết kế đính kèm.”
Tái hiện lỗi	Sửa bug	“Viết test tái hiện lỗi trước (phải đỏ), sửa xong test phải xanh.”
Hành vi không đổi	Refactor	“Toàn bộ test hiện có vẫn xanh; không đổi chữ ký hàm công khai.”

Ví dụ: từ tiêu chí trong prompt đến test

Prompt nói: “Hàm calcOrderTotal nhận tiền hàng, phí giao, tiền cọc; trả về tổng và số còn phải thu. Ca kiểm thử: (1) 350.000 + 30.000, cọc 100.000 thì tổng 380.000, còn thu 280.000; (2) cọc bằng tổng thì còn thu 0; (3) cọc lớn hơn tổng thì ném lỗi.” Agent sẽ viết được test gần như nguyên văn:

import { describe, it, expect } from "vitest";
import { calcOrderTotal } from "@/features/orders/calc-order-total";

describe("calcOrderTotal", () => {
  // Tiền lưu dạng số nguyên VNĐ, không dùng số thực
  it("tính tổng và số còn phải thu", () => {
    expect(calcOrderTotal({ subtotal: 350_000, shippingFee: 30_000, deposit: 100_000 }))
      .toEqual({ total: 380_000, remaining: 280_000 });
  });

  it("cọc bằng tổng thì không còn phải thu", () => {
    expect(calcOrderTotal({ subtotal: 350_000, shippingFee: 30_000, deposit: 380_000 }).remaining)
      .toBe(0);
  });

  it("cọc lớn hơn tổng thì báo lỗi", () => {
    expect(() => calcOrderTotal({ subtotal: 350_000, shippingFee: 0, deposit: 400_000 }))
      .toThrow();
  });
});

Bạn không cần tự viết test này. Nhưng nhờ bạn đã nêu ca kiểm thử bằng lời, bạn đọc được test và biết nó kiểm tra đúng điều mình muốn. Đó là cách người không chuyên vẫn kiểm soát được chất lượng.

Đòi bằng chứng ở cuối prompt

Thêm một câu chuẩn vào cuối mọi prompt giao việc: “Khi xong, liệt kê file đã sửa, lệnh đã chạy và output; nếu có gì chưa làm được hoặc chưa chắc, nói rõ.” Câu cuối quan trọng: nó cho phép agent thừa nhận giới hạn thay vì tô vẽ kết quả.

Để AI phỏng vấn ngược bạn

Khi nào dùng

Với tính năng lớn (màn hình bếp, quy trình đặt cọc, phân quyền theo chi nhánh), thường chính bạn chưa nghĩ hết các trường hợp. Viết prompt dài cỡ nào cũng sẽ sót. Lúc này, hãy đảo vai: để AI hỏi, bạn trả lời. AI rất giỏi liệt kê những câu hỏi mà người làm phần mềm lâu năm sẽ hỏi: trường hợp biên, xung đột, quyền hạn, dữ liệu cũ.

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

Có

Không

Rồi, chỉ chưa rõ code

Chưa

Có việc cần giao

Mô tả được trong một câu và biết rõ ‘xong’ là gì?

Prompt trực tiếp, kèm tiêu chí kiểm chứng

Bạn đã rõ yêu cầu nghiệp vụ chưa?

Yêu cầu agent khám phá và lập kế hoạch trước

Để AI phỏng vấn ngược bạn

AI viết spec vào docs/specs/

Bạn đọc, sửa spec

Mở phiên mới sạch, giao thực thi theo spec

Bạn duyệt kế hoạch

Agent thực thi, tự kiểm chứng

Hình 1 Sơ đồ luồng

Đọc sơ đồ dạng chữ

Có việc cần giao → Mô tả được trong một câu và biết rõ ‘xong’ là gì?
Mô tả được trong một câu và biết rõ ‘xong’ là gì? → Prompt trực tiếp, kèm tiêu chí kiểm chứng (Có)
Mô tả được trong một câu và biết rõ ‘xong’ là gì? → Bạn đã rõ yêu cầu nghiệp vụ chưa? (Không)
Bạn đã rõ yêu cầu nghiệp vụ chưa? → Yêu cầu agent khám phá và lập kế hoạch trước (Rồi, chỉ chưa rõ code)
Bạn đã rõ yêu cầu nghiệp vụ chưa? → Để AI phỏng vấn ngược bạn (Chưa)
Để AI phỏng vấn ngược bạn → AI viết spec vào docs/specs/
AI viết spec vào docs/specs/ → Bạn đọc, sửa spec
Bạn đọc, sửa spec → Mở phiên mới sạch, giao thực thi theo spec
Yêu cầu agent khám phá và lập kế hoạch trước → Bạn duyệt kế hoạch
Bạn duyệt kế hoạch → Agent thực thi, tự kiểm chứng
Mở phiên mới sạch, giao thực thi theo spec → Agent thực thi, tự kiểm chứng
Prompt trực tiếp, kèm tiêu chí kiểm chứng → Agent thực thi, tự kiểm chứng

Cách làm

Nêu mục tiêu ở mức cao và bối cảnh chính.
Yêu cầu AI hỏi bạn từng nhóm vài câu một, ưu tiên những điểm khó, những trường hợp bạn có thể chưa nghĩ tới; không hỏi những điều nó tự tìm được trong code.
Trả lời. Nếu không biết, nói “chưa biết, đề xuất giúp mình phương án và ưu nhược”.
Khi đủ, yêu cầu AI viết thành file spec trong repo.
Đọc kỹ spec, sửa. Rồi mở phiên mới để thực thi, vì phiên phỏng vấn đã đầy những trao đổi qua lại không còn cần thiết (lý do chi tiết ở bài Context engineering02-05).

Cách viết spec đầy đủ được trình bày ở bài Viết PRD và spec03-06; quy trình spec-driven ở bài Spec-driven development06-04.

Bảng prompt trước/sau

Dưới đây là các cặp prompt thực tế trong dự án Bánh Mộc. Cột “Vì sao tốt hơn” chỉ ra phỏng đoán nào đã được loại bỏ.

#	Prompt mơ hồ	Prompt tốt	Vì sao tốt hơn
1	“Thêm chức năng tìm khách hàng.”	“Trên trang `/customers`, thêm ô tìm theo số điện thoại (cột `customers.phone`). Chấp nhận nhập có hoặc không có số 0 đầu, có khoảng trắng. Làm theo cách ô tìm kiếm ở trang `/orders`. Viết test cho hàm chuẩn hóa số điện thoại với 4 ca: `0909 123 456`, `909123456`, `+84909123456`, chuỗi rỗng. Chạy `npm test`.”	Rõ vị trí, cột dữ liệu, quy tắc nhập liệu kiểu Việt Nam, mẫu để theo, ca kiểm thử
2	“Đơn hàng bị lỗi, sửa đi.”	“Khi tạo đơn giao lúc 23:30 tối, trang chi tiết hiển thị ngày hôm sau. Nghi ngờ lỗi múi giờ khi lưu `orders.delivery_at` (timestamptz). Hãy viết test tái hiện trước (phải đỏ), tìm nguyên nhân gốc, sửa để hiển thị đúng giờ Asia/Ho_Chi_Minh. Không đổi kiểu cột. Dán output test trước và sau khi sửa.”	Có triệu chứng cụ thể, vị trí khả nghi, định nghĩa “đã sửa”, cấm lối tắt
3	“Viết hàm tạo mã đơn.”	“Viết hàm tạo mã đơn dạng `BM-YYMMDD-XXX` (ví dụ `BM-261012-007`), XXX là số thứ tự trong ngày theo giờ Việt Nam, bắt đầu từ 001. Hai đơn tạo cùng lúc không được trùng mã (cột `orders.code` UNIQUE). Đề xuất cách đảm bảo không trùng trước khi code, chờ mình duyệt.”	Định dạng chính xác, múi giờ, rủi ro trùng lặp khi tạo đồng thời, yêu cầu kế hoạch trước
4	“Làm đẹp dashboard.”	“Trang `/dashboard` cần hiển thị số đơn hôm nay theo trạng thái (`moi`, `da_xac_nhan`, `dang_lam`, `dang_giao`, `hoan_tat`, `da_huy`) và theo chi nhánh. Dùng component Card có sẵn của shadcn/ui như trang `/orders`. Ưu tiên đọc tốt trên điện thoại. Xong thì chụp màn hình khổ điện thoại và máy tính.”	“Đẹp” được thay bằng nội dung cụ thể, hệ thống thiết kế có sẵn, thiết bị mục tiêu, bằng chứng bằng ảnh
5	“Build lỗi.”	“`npm run build` lỗi với thông báo: [dán nguyên văn]. Tìm và sửa nguyên nhân gốc. Không thêm `any`, không tắt kiểm tra, không sửa test cho qua. Chạy lại build và dán kết quả, kèm một câu giải thích nguyên nhân.”	Có dữ liệu thật, cấm che triệu chứng, yêu cầu xác minh
6	“Viết test cho phần đơn hàng.”	“Viết unit test cho hàm chuyển trạng thái đơn trong `src/features/orders/status.ts`. Bao phủ: mọi chuyển hợp lệ theo chuỗi `moi → da_xac_nhan → dang_lam → dang_giao → hoan_tat`; không được nhảy cóc; chỉ hủy được từ `moi`, `da_xac_nhan` hoặc `dang_lam`; không chuyển tiếp từ `hoan_tat` hay `da_huy`. Không mock chính hàm đang test.”	Nêu hành vi cần kiểm, trường hợp biên của nghiệp vụ, chặn kiểu test giả
7	“Thêm chức năng in phiếu cho bếp.”	“Mình muốn bếp in phiếu bánh kem. Trước khi làm gì, hãy phỏng vấn mình về: thông tin cần trên phiếu, khổ giấy, khi nào in, ai in, xử lý đơn sửa sau khi đã in. Hỏi từng nhóm 3–4 câu. Xong thì viết spec vào `docs/specs/in-phieu-bep.md`.”	Thừa nhận yêu cầu chưa rõ, dùng phỏng vấn ngược thay vì để AI đoán

Áp dụng vào dự án Bánh Mộc

Nhật ký công trình · Bánh Mộc

BM-261013-018

13.10.2026

Chị LanChủ chuỗi
HàBán hàng online

Chị Lan và Hà cùng trả lời các câu hỏi agent phỏng vấn ngược trước khi viết spec

Tuần đầu làm MVP, chị Lan gửi agent một câu: “Làm trang tạo đơn hàng.” Agent làm ra một form khá đẹp, có tên khách, số điện thoại, sản phẩm, số lượng. Nhưng không có ô chữ viết trên bánh, không có giờ nhận, không chọn chi nhánh, không có tiền cọc. Tiền lưu dạng số thực. Mã đơn là chuỗi ngẫu nhiên dài ngoằng. Chị mất cả buổi để chỉnh qua lại, càng chỉnh càng rối.

Chị dừng lại, mở phiên mới và làm khác đi. Lần này chị bắt đầu bằng phỏng vấn ngược: “Mình cần màn hình tạo đơn cho tiệm bánh. Hãy hỏi mình những điều cần biết trước khi thiết kế.” Agent hỏi những câu chị chưa từng nghĩ: “Một đơn có thể có nhiều bánh kem với chữ khác nhau không?”, “Khách quen gọi điện, nhân viên có cần tìm nhanh theo số điện thoại không?”, “Đơn đặt cọc qua chuyển khoản, ai xác nhận đã nhận tiền?”, “Nếu khách đổi giờ nhận sau khi bếp đã bắt đầu làm thì sao?”. Chị gọi Hà vào cùng trả lời.

Kết quả là file docs/specs/tao-don-hang.md dài hai trang. Chị mở phiên mới, giao: “Thực thi spec docs/specs/tao-don-hang.md, phần 1: lưu đơn và mã đơn. Lập kế hoạch trước, chờ mình duyệt.” Lần này kết quả đúng ngay từ đầu tới 80–90%, phần còn lại là chi tiết nhỏ.

Chị Lan rút ra công thức riêng dán cạnh màn hình: “Muốn gì, ở đâu, đừng làm gì, giống cái nào, sao biết xong.“

Prompt mẫu

Khung prompt năm phần dùng lại được:

Giao việc cho agent

Mục tiêu: [kết quả mong muốn] để [lý do nghiệp vụ].
Bối cảnh: liên quan [file/thư mục], [bảng/cột], spec ở [đường dẫn nếu có].
Ràng buộc: [không cài thư viện mới / không đổi schema / chỉ sửa trong ...]. Ngoài phạm vi: [...].
Mẫu: làm theo cách [file/hàm có sẵn].
Hoàn thành khi: [ca kiểm thử cụ thể]; chạy [lệnh] và dán output.
Liệt kê file đã sửa. Nếu có gì chưa chắc hoặc chưa làm được, nói rõ.

Phỏng vấn ngược cho tính năng lớn:

Giao việc cho agent

Mình muốn xây [tính năng] cho Mộc OMS. Bối cảnh: [2–3 câu].
Đừng viết code. Hãy phỏng vấn mình để làm rõ yêu cầu: hỏi từng nhóm 3–4 câu,
ưu tiên trường hợp biên, quyền hạn, dữ liệu, điều có thể xung đột với quy trình hiện tại.
Không hỏi những gì bạn tự tìm được trong code.
Khi đủ thông tin, viết spec vào docs/specs/[ten-tinh-nang].md gồm: mục tiêu, người dùng,
luồng chính, trường hợp biên, ngoài phạm vi, cách kiểm chứng.

Báo lỗi đúng cách:

Giao việc cho agent

Triệu chứng: [điều đang xảy ra], mong đợi: [điều lẽ ra phải xảy ra].
Cách tái hiện: [các bước]. Thông báo lỗi: [dán nguyên văn].
Nghi ngờ ở: [file/khu vực nếu biết].
Hãy viết test tái hiện trước, tìm nguyên nhân gốc, sửa, chạy lại test. Không che triệu chứng.

Sai lầm thường gặp

Sự cố 01

Mô tả hành động thay vì mục tiêu.

Triệu chứng

“Thêm cột X” mà không nói để làm gì, agent không thể đưa lựa chọn phụ hợp lý.

Cách tránh

Luôn kèm “để…”. Một câu lý do giúp agent tự quyết định đúng ở những chỗ bạn không nói.
Sự cố 02

Không có định nghĩa “xong”.

Triệu chứng

Agent dừng ở chỗ code trông ổn; bạn thành người kiểm tra.

Cách tránh

Kết thúc prompt bằng ca kiểm thử, lệnh phải xanh, bằng chứng cần dán.
Sự cố 03

Tóm tắt lỗi thay vì dán nguyên văn.

Triệu chứng

“Nó báo lỗi gì đó về null” làm mất thông tin quý nhất.

Cách tránh

Dán nguyên văn thông báo lỗi, stack trace, ảnh chụp màn hình.
Sự cố 04

Sửa đi sửa lại trong cùng một phiên rối.

Triệu chứng

Sau vài lần chỉnh, ngữ cảnh đầy những hướng đi sai, agent càng lúc càng lạc.

Cách tránh

Nếu đã chỉnh hơn hai lần cho cùng một vấn đề, mở phiên mới với prompt đã rút kinh nghiệm.
Sự cố 05

Giao việc lớn bằng một câu.

Triệu chứng

“Làm module thanh toán” buộc AI đoán hàng chục quyết định.

Cách tránh

Phỏng vấn ngược, viết spec, chia nhỏ rồi mới giao từng phần.

Checklist

Prompt nêu mục tiêu kèm lý do nghiệp vụ.
Đã chỉ file, thư mục, bảng, cột liên quan bằng đúng tên.
Đã nêu ràng buộc và phần ngoài phạm vi.
Đã chỉ một mẫu có sẵn để agent làm theo (nếu có).
Có tiêu chí hoàn thành kiểm chứng được: ca kiểm thử, lệnh, ảnh chụp.
Yêu cầu agent liệt kê file đã sửa và nói rõ điều chưa chắc.
Đã che dữ liệu cá nhân và khóa bí mật trước khi dán.
Với việc lớn chưa rõ, đã để AI phỏng vấn ngược và viết spec trước.

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

Bài 1

Cơ bản

Viết lại prompt mơ hồ

Viết lại ba prompt sau theo cấu trúc năm phần trong bối cảnh Bánh Mộc: “Thêm danh mục sản phẩm”, “Sửa lỗi đăng nhập”, “Làm báo cáo doanh thu”.

Kết quả mong đợi

Mỗi prompt mới có mục tiêu kèm lý do, ít nhất một file hoặc bảng cụ thể, một ràng buộc, và tiêu chí hoàn thành có lệnh hoặc ca kiểm thử.
Bài 2

Cơ bản

Viết ca kiểm thử bằng lời

Cho hàm “tính phí giao hàng” của Bánh Mộc (giao tận nơi 30.000đ, miễn phí cho đơn từ 500.000đ; khách tự lấy không tính phí), viết 5 ca kiểm thử bằng lời gồm đầu vào và đầu ra mong đợi, trong đó ít nhất 2 ca là trường hợp biên.

Kết quả mong đợi

Danh sách 5 ca rõ ràng mà một người khác (hoặc agent) có thể chuyển thẳng thành test.
Bài 3

Nâng cao

Thử phỏng vấn ngược

Chọn một tính năng bạn chưa nghĩ kỹ (ví dụ “chương trình khách hàng thân thiết” của Bánh Mộc). Dùng prompt phỏng vấn ngược trong bài, trả lời đến khi AI viết xong spec.

Kết quả mong đợi

Một file spec, kèm danh sách ít nhất 3 câu hỏi mà AI đặt ra và bạn chưa từng nghĩ tới trước đó.

Thuật ngữ trong bài

Prompt: Lời giao việc hoặc câu hỏi gửi cho mô hình
Tiêu chí hoàn thành: Điều kiện kiểm chứng được để coi một việc là xong
Ca kiểm thử (test case): Một bộ đầu vào và kết quả mong đợi cụ thể
Phỏng vấn ngược: Để AI đặt câu hỏi làm rõ yêu cầu trước khi làm
Spec: Bản đặc tả tính năng: cái gì, vì sao, phạm vi, cách kiểm chứng
Ngoài phạm vi (out of scope): Những gì cố ý không làm trong lần này
Stack trace: Danh sách các lời gọi hàm dẫn tới lỗi, giúp khoanh vùng
Refactor: Sắp xếp lại code mà không đổi hành vi

Đọc thêm

Hướng dẫn thực hành tốt khi giao việc cho agent: https://code.claude.com/docs
Tài liệu Vitest để đọc hiểu test: https://vitest.dev
Bài liên quan: Viết PRD và spec03-06, User story và tiêu chí chấp nhận03-05, Debug cùng AI06-07, Thư viện prompt và template14-02

Nghiệm thu tờ 02-04

Đọ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.

Viết prompt cho lập trình: rõ ràng, có bối cảnh, có tiêu chí kiểm chứng

Bạn sẽ học được gì

Vì sao prompt cho lập trình khác prompt thông thường

Cấu trúc prompt năm phần

Phần 1: Mục tiêu, kèm “vì sao”

Phần 2: Bối cảnh, chỉ đúng chỗ

Phần 3: Ràng buộc, rào trước những lối tắt nguy hiểm

Phần 4: Ví dụ hoặc mẫu có sẵn

Phần 5: Tiêu chí hoàn thành có thể kiểm chứng

Chỉ ra file, mẫu có sẵn và phạm vi

Ba câu hỏi trước khi gửi

Cho agent dữ liệu thật thay vì mô tả

Tiêu chí kiểm chứng: test, ảnh chụp, lệnh build

Các loại tiêu chí

Ví dụ: từ tiêu chí trong prompt đến test

Đòi bằng chứng ở cuối prompt

Để AI phỏng vấn ngược bạn

Khi nào dùng

Cách làm

Bảng prompt trước/sau

Áp dụng vào dự án Bánh Mộc

Prompt mẫu

Sai lầm thường gặp

Mô tả hành động thay vì mục tiêu.

Không có định nghĩa “xong”.

Tóm tắt lỗi thay vì dán nguyên văn.

Sửa đi sửa lại trong cùng một phiên rối.

Giao việc lớn bằng một câu.

Checklist

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

Viết lại prompt mơ hồ

Viết ca kiểm thử bằng lời

Thử phỏng vấn ngược

Thuật ngữ trong bài

Đọc thêm

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

Phần 1: Mục tiêu, kèm “vì sao”

Phần 2: Bối cảnh, chỉ đúng chỗ

Phần 3: Ràng buộc, rào trước những lối tắt nguy hiểm

Phần 4: Ví dụ hoặc mẫu có sẵn

Phần 5: Tiêu chí hoàn thành có thể kiểm chứng

Ba câu hỏi trước khi gửi

Cho agent dữ liệu thật thay vì mô tả

Các loại tiêu chí

Ví dụ: từ tiêu chí trong prompt đến test

Đòi bằng chứng ở cuối prompt

Khi nào dùng

Cách làm

Mô tả hành động thay vì mục tiêu.

Không có định nghĩa “xong”.

Tóm tắt lỗi thay vì dán nguyên văn.

Sửa đi sửa lại trong cùng một phiên rối.

Giao việc lớn bằng một câu.

Viết lại prompt mơ hồ

Viết ca kiểm thử bằng lời

Thử phỏng vấn ngược

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

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

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