Tiếng Việt: Iterating and refining AI outputs

Prompt đầu tiên của bạn hiếm khi là prompt cuối cùng. Điều phân biệt một QA engineer dùng AI hiệu quả với một người chỉ "hỏi rồi copy" chính là khả năng nhận ra output chưa đạt, và biết đúng cách để sửa nó — nhanh, có chủ đích, không phải thử lại từ đầu mỗi lần. Bài này tập trung vào kỹ năng refinement (tinh chỉnh) — thứ quyết định 80% giá trị thực tế bạn lấy được từ AI trong công việc QA hàng ngày.

Làm sao nhận ra một AI output kém — mơ hồ, thiếu sót, hay lạc đề?

Trước khi sửa được, bạn phải nhận diện được vấn đề. Nhiều QA engineer mới dùng AI có xu hướng chấp nhận output miễn là nó "trông có cấu trúc" — bảng biểu đẹp, đánh số rõ ràng — mà không soi vào nội dung thực chất. Đây là lỗi tốn kém nhất khi làm agentic testing.

Ba kiểu thất bại thường gặp

1. Vague (mơ hồ): Output đi đúng hướng nhưng generic, không đặc thù cho hệ thống của bạn. Ví dụ test case "Verify user can login successfully" — đúng nhưng vô dụng, vì thiếu data cụ thể, thiếu môi trường, thiếu expected response schema. Bạn đọc xong không biết execute thế nào.

2. Incomplete (thiếu sót): Output bỏ sót nhóm case quan trọng — thường là negative case, boundary value, concurrency, i18n/locale, hoặc case liên quan đến phân quyền. AI có xu hướng thiên về happy path nếu bạn không ép nó nghĩ tới case xấu.

3. Off-target (lạc đề): Output trả lời sai câu hỏi, hoặc dựa trên giả định sai về hệ thống — dạng hallucination (bịa đặt) nguy hiểm nhất vì nó "nghe rất hợp lý". Ví dụ AI giả định API dùng REST truyền thống trong khi hệ thống thực tế dùng GraphQL, rồi generate cả bộ test case theo REST convention hoàn toàn sai bản chất.

Checklist đánh giá output thực tế

Trước khi chấp nhận bất kỳ output nào, chạy nhanh qua checklist này (tôi dán checklist này ngay cạnh màn hình khi review):

• Specificity: Có data cụ thể (giá trị input, expected output cụ thể) hay chỉ mô tả chung?
• Traceability: Mỗi test case/finding có map được về đúng requirement hoặc acceptance criteria nào không?
• Testability: Bước thực hiện đủ rõ để một người khác (hoặc automation) chạy được ngay, không cần đoán?
• Coverage: Có negative case, boundary case, permission case không, hay chỉ toàn happy path?
• Consistency với hệ thống thật: Có field, endpoint, hay flow nào bị "bịa" không khớp với spec/code thật không?
• Actionability: Format output có sẵn sàng dùng ngay (import vào tool, paste vào ticket) hay cần format lại thủ công?

Nếu output fail từ 2 tiêu chí trở lên, đừng sửa tay từng chỗ — quay lại refine bằng kỹ thuật ở phần dưới, vì fail nhiều tiêu chí thường có nghĩa là context đầu vào thiếu, không phải chỉ do output "chưa may".

Rèn khả năng đánh giá (calibrate judgment) theo thời gian

Khả năng "nhìn là biết output có vấn đề" không đến ngay — nó được rèn qua việc bạn chủ động ghi nhận sai lầm lặp lại của AI trong domain của mình. Gợi ý thực tế: giữ một file ngắn tên "ai-blind-spots.md", mỗi khi bạn phát hiện AI sai một kiểu nào đó (ví dụ "luôn quên test pagination edge case", hoặc "hay nhầm response code 409 với 400"), ghi một dòng vào đó. Sau vài tuần, bạn sẽ thấy pattern rõ ràng theo domain/model bạn dùng, và có thể đưa thẳng các điểm này vào system prompt hoặc checklist review để chặn lỗi lặp lại từ gốc.

Mẹo: Đừng review output AI với tư duy "tìm lỗi đúng/sai" — review với tư duy "tìm chỗ AI đang tự tin nhưng thực ra đang đoán". Dấu hiệu nhận biết: output dùng ngôn ngữ chắc chắn ("hệ thống sẽ...", "luôn luôn...") cho một hành vi mà bạn biết trong spec không hề nói rõ — đó chính là hallucination nguỵ trang dưới vẻ tự tin.

Những kỹ thuật refinement nào giúp AI tạo ra QA output tốt hơn?

Một khi đã xác định được vấn đề, bước tiếp theo là chọn đúng "công cụ sửa" — mỗi loại vấn đề cần một kỹ thuật refine khác nhau. Sửa sai kỹ thuật (ví dụ dùng scope extension cho lỗi định dạng) chỉ tốn thêm turn mà không giải quyết gốc vấn đề.

Kỹ thuật 1: Targeted Correction (sửa lỗi có chủ đích)

Dùng khi output có 1-2 điểm sai cụ thể, phần còn lại ổn — bạn chỉ ra chính xác điểm sai và yêu cầu sửa, giữ nguyên phần đúng. Tránh yêu cầu "generate lại từ đầu" vì dễ mất luôn những phần đã tốt.

Test case TC-04 sai — hệ thống trả 409 Conflict khi trùng email,
không phải 400 Bad Request như bạn viết. Sửa lại đúng TC-04,
giữ nguyên toàn bộ các test case khác không đổi.

Kỹ thuật 2: Scope Extension (mở rộng phạm vi)

Dùng khi output đúng nhưng thiếu coverage — bạn giữ nguyên phần đã có, yêu cầu AI bổ sung thêm case theo một chiều cụ thể (không nói mơ hồ "thêm test case nữa đi", vì AI sẽ lặp lại case tương tự).

Bộ test case trên đã ổn cho single-user flow. Bổ sung thêm
test case cho trường hợp 2 device cùng gửi request update
đồng thời (concurrent) lên cùng 1 order — mô tả rõ race condition
cần kiểm tra và expected outcome khi có conflict.

Kỹ thuật 3: Depth Drilling (khoan sâu chi tiết)

Dùng khi một item trong output đúng hướng nhưng còn hời hợt — bạn yêu cầu AI đào sâu riêng item đó thành nhiều sub-case chi tiết hơn, thay vì để nguyên một dòng chung chung.

Với TC-07 (upload file đính kèm), hãy phân tích chi tiết hơn:
liệt kê boundary case về file size (0 byte, đúng limit, vượt limit 1 byte),
format hợp lệ/không hợp lệ, và encoding tên file có ký tự đặc biệt/unicode.

Kỹ thuật 4: Format Transformation (chuyển đổi định dạng)

Dùng khi nội dung đã đúng nhưng format chưa dùng được ngay — chuyển đổi list thành Gherkin/BDD, chuyển bảng test case thành CSV để import TestRail, hay chuyển bug analysis thành format sẵn sàng paste vào Jira.

Chuyển toàn bộ bộ test case trên từ dạng bảng markdown sang
Gherkin (Feature/Scenario/Given-When-Then), giữ nguyên nội dung,
chỉ đổi cấu trúc trình bày.

Kỹ thuật 5: Adversarial Review (phản biện)

Dùng khi bạn nghi ngờ output "trông ổn nhưng có gì đó thiếu" mà không chỉ ra được cụ thể — yêu cầu AI (hoặc đổi hẳn persona) tự phản biện lại chính output vừa tạo.

Đóng vai một senior QA reviewer khắt khe, chưa từng thấy bộ
test case này trước đó. Chỉ ra 5 điểm yếu nhất trong bộ test case
trên — về coverage, về giả định sai, hoặc về case dễ bị miss trong review thực tế.

Chọn đúng kỹ thuật refinement

Bảng quyết định nhanh để bạn không mất thời gian chọn sai công cụ:

Mẹo: Kết hợp Adversarial Review với việc đổi hẳn persona so với prompt gốc (ví dụ từ "test writer" sang "security auditor" hoặc "khách hàng khó tính nhất của bạn"). Đổi góc nhìn hoàn toàn khác thường lộ ra góc mù mà chính prompt ban đầu — do cùng một khung tư duy — không bao giờ tự nhìn thấy.

Khi nào nên dùng multi-turn conversation, khi nào dùng single-shot prompt cho công việc QA?

Nhiều QA engineer mặc định dùng multi-turn (hỏi đáp nhiều lượt) cho mọi việc vì "cảm giác tự nhiên hơn" — nhưng single-shot (một lượt, một prompt đầy đủ) thường cho kết quả nhất quán hơn và dễ tái sử dụng thành template. Biết khi nào dùng cái nào là kỹ năng tiết kiệm rất nhiều thời gian.

Single-shot prompt: khi nào là lựa chọn đúng

Dùng single-shot khi task được định nghĩa rõ ràng (bounded), toàn bộ context cần thiết đã có sẵn ngay từ đầu, và bạn kỳ vọng có thể đưa ra output đạt yêu cầu ngay hoặc chỉ cần refine nhẹ. Ví dụ: generate test case từ một ticket đã có acceptance criteria đầy đủ, convert format, hay tóm tắt một diff cụ thể. Ưu điểm: nhanh, không có rủi ro "trôi" theo hội thoại dài, và dễ lưu thành prompt template để tái dùng nguyên vẹn cho task tương tự sau này.

Multi-turn conversation: khi nào tạo giá trị

Dùng multi-turn khi task có tính thăm dò (exploratory), mơ hồ ngay từ đầu, hoặc cần nhiều vòng điều chỉnh nhỏ dựa trên phản hồi liên tục — ví dụ root cause analysis (RCA) một bug phức tạp mà bạn cần đào sâu dần theo từng giả thuyết, hoặc buổi "brainstorm" test strategy cho một feature mới mà bạn chưa hình dung rõ scope. Giá trị lớn nhất: context tích luỹ dần trong conversation, bạn không phải giải thích lại từ đầu mỗi lượt, và có thể "bẻ hướng" từng bước nhỏ khi thấy AI đi lệch.

Một framework để lựa chọn

Tự hỏi 3 câu trước khi bắt đầu:

1. Task này có bounded (ranh giới rõ, biết khi nào "xong") không? → Có: nghiêng về single-shot.
2. Toàn bộ context cần thiết đã có sẵn chưa, hay bạn cần "khám phá" thêm trong lúc làm? → Cần khám phá thêm: nghiêng về multi-turn.
3. Bạn dự đoán cần bao nhiêu vòng sửa? Nếu >5 vòng sửa nhỏ liên tiếp là bình thường với task này → multi-turn tự nhiên hơn; nếu chỉ 1-2 vòng refine → single-shot + refine đủ dùng.

Quản lý context trong multi-turn hiệu quả

Multi-turn có một rủi ro âm thầm: model có thể vẫn "bám" vào một giả định sai bạn đã sửa ở turn trước, đặc biệt khi hội thoại dài. Tôi từng gặp trường hợp sửa một giả định ở turn 3, nhưng đến turn 9 AI vẫn quay lại dùng giả định cũ đó khi tổng hợp kết quả cuối — vì tín hiệu sửa ở giữa bị "chìm" trong toàn bộ lịch sử hội thoại.

Cách quản lý:

• Định kỳ tóm tắt lại những gì đã thống nhất, dán thành một đoạn "state hiện tại" ngay trong hội thoại, thay vì tin model tự tổng hợp đúng.
• Nếu hội thoại vượt quá khoảng 8-10 lượt mà vẫn chưa ra kết quả cuối, đừng cố nói tiếp — đó là dấu hiệu nên dừng, tóm tắt toàn bộ ngữ cảnh đã chốt thành một prompt single-shot mới, sạch, và mở hội thoại mới với prompt đó.
• Đánh dấu rõ "đây là câu trả lời cuối cùng, dùng để tổng hợp" ở message chốt, tránh model lẫn giữa các phiên bản trả lời nháp trước đó.

Mẹo: Khi bạn sửa một giả định quan trọng giữa hội thoại dài, đừng chỉ nói "không, sai rồi" — nhắc lại rõ giả định đúng bằng câu khẳng định đầy đủ (ví dụ "Xác nhận lại: hệ thống dùng JWT với thời hạn 15 phút, KHÔNG phải session cookie như bạn giả định ở trên"). Việc này giúp model "ghi đè" đúng thông tin cũ trong context, giảm khả năng nó quay lại giả định sai ở các turn sau.

Làm sao xây dựng một prompt library cá nhân cho các task QA lặp lại?

Nếu bạn viết lại một prompt tương tự từ đầu mỗi lần cần test API mới hay phân tích bug mới, bạn đang lãng phí chính lợi thế lớn nhất của AI: tính lặp lại. Một prompt library (thư viện prompt) cá nhân, được tinh chỉnh dần qua thời gian, chính là "công cụ" giá trị nhất bạn xây được trong suốt module context engineering này.

Một prompt library gồm những gì

Không phải mọi prompt đều đáng lưu — chỉ lưu những gì bạn thực sự dùng lại nhiều lần. Với QA, các nhóm task phổ biến nhất đáng có template riêng: test plan generation, test case generation (theo từng loại: API/UI/mobile), bug report analysis/root cause analysis, regression scoping, exploratory testing charter, sinh test data, và review coverage của PR trước khi ký duyệt QA.

Cấu trúc thư viện

Mỗi template trong thư viện nên có đủ 5 phần: Tên, Mục đích, Khi nào dùng, Nội dung template (có placeholder), và một ví dụ đã điền sẵn để tham khảo nhanh. Dưới đây là một worked example thực tế bạn có thể copy làm khung mẫu:

Template: API Test Case Generation

ROLE: Bạn là senior QA engineer chuyên về API testing.

CONTEXT CẦN CUNG CẤP:
- Endpoint: {{METHOD}} {{PATH}}
- OpenAPI schema liên quan: {{paste schema}}
- Business rule không có trong schema: {{mô tả free text}}

NHIỆM VỤ:
Generate test case covering:
1. Happy path cho từng tổ hợp field required.
2. Thiếu/sai field required (case trả 400).
3. Boundary value cho field numeric/string length.
4. Case auth failure (401/403).
5. Idempotency nếu method là POST/PUT.
6. Rate-limit/concurrency edge case nếu áp dụng.

OUTPUT FORMAT: Bảng markdown — ID | Title | Precondition | Steps | Expected Result | Priority

Lưu template này dưới file riêng (ví dụ templates/api-test-case-generation.md) kèm ví dụ đã điền cho ít nhất 1 endpoint thực tế bạn từng dùng — ví dụ điền sẵn giúp bạn (hoặc đồng nghiệp) hiểu ngay cách dùng mà không cần đoán.

Xây dựng thư viện dần theo thời gian

Đừng cố ngồi thiết kế toàn bộ thư viện trong một buổi. Cách hiệu quả hơn: mỗi lần bạn viết một prompt từ đầu và nó cho kết quả tốt, lưu ngay lại thành template thô. Mỗi lần bạn dùng lại template cũ và phải sửa gì đó để nó chạy đúng cho case mới, cập nhật luôn template — đừng chỉ sửa cho lần dùng đó rồi bỏ đi. Bắt đầu với 3 task bạn làm thường xuyên nhất, thư viện sẽ tự lớn dần một cách tự nhiên theo nhu cầu thật.

Metadata cho template giúp tiết kiệm thời gian

Một template không có metadata rất dễ trở thành "nợ" theo thời gian — bạn không biết nó còn đúng không, ai viết, dùng cho hệ thống nào. Metadata tối thiểu nên có: tag khu vực chức năng (feature area), model đã test template này (vì hành vi có thể khác giữa các model), ngày cập nhật cuối, và một ghi chú ngắn về tỉ lệ thành công/gotcha đã gặp khi dùng.

Team Library so với Personal Library

Personal library là nơi bạn thử nghiệm tự do, không cần review, có thể sai và sửa nhanh không ảnh hưởng ai. Khi một template đã được bạn dùng thành công nhiều lần và ổn định, đó là lúc "promote" nó lên team library — nhưng team library cần chuẩn cao hơn: có review qua PR, version control (nên nằm trong repo, không phải Notion cá nhân), và có chủ sở hữu rõ ràng để tránh tình trạng nhiều bản template trùng lặp, xung đột nhau giữa các thành viên.

Mẹo: Lưu prompt library ngay trong repo dự án (ví dụ thư mục docs/qa-prompts/) thay vì trong note app cá nhân. Lưu trong repo giúp nó version cùng code, được review qua PR như bất kỳ thay đổi nào khác, và không biến mất khi bạn đổi công cụ ghi chú hay đổi máy làm việc.