Tiếng Việt: Iterating Refining Outputs

23h đêm trước buổi planning, một PM gõ vào ChatGPT: "Viết giúp tôi PRD cho tính năng ví điểm thưởng mới." 30 giây sau, một tài liệu 2 trang xuất hiện — đầy đủ mục "Problem Statement", "User Stories", "Success Metrics", trình bày rất chuyên nghiệp. PM copy nguyên vào Confluence, gắn tag review, đi ngủ. Sáng hôm sau, trong buổi refinement, dev đầu tiên hỏi: "Điểm thưởng có hết hạn không? Có áp dụng cho user đã bị khoá tài khoản không? Tích hợp với ví MoMo hay ZaloPay hiện tại thế nào?" — không câu nào có câu trả lời trong PRD, vì AI viết một bản PRD "chuẩn SaaS Mỹ" hoàn toàn không biết công ty này đang vận hành ở thị trường nào, stack nào, và có những ràng buộc gì.

Đây là sai lầm phổ biến nhất khi PM/BA dùng AI: nhầm lẫn giữa "output nhìn chuyên nghiệp" với "output dùng được". Kỹ năng viết prompt (câu lệnh) tốt chỉ là một nửa câu chuyện. Nửa còn lại — thường bị bỏ qua vì tốn thời gian hơn — là biết cách đọc ra một output tệ, biết cách refine nó qua nhiều lượt hội thoại, biết khi nào nên dừng lại ở một prompt duy nhất và khi nào phải "đấu tay đôi" với AI qua nhiều vòng, và biết cách biến những gì mình học được thành tài sản dùng lại cho lần sau thay vì đánh mất nó ngay sau khi đóng tab chat. Bài này đi sâu vào từng kỹ năng đó.

Nhận Diện Output AI Tệ — Chung Chung, Hời Hợt, Hoặc Lệch Bối Cảnh Kinh Doanh

Output AI tệ hiếm khi trông "sai" ngay từ cái nhìn đầu tiên — nó thường trông rất gọn gàng, đúng format, đủ mục. Vấn đề nằm ở chỗ nó không neo vào bối cảnh thật của công ty bạn. Ba dấu hiệu chẩn đoán quan trọng nhất:

1. Generic (chung chung) — output có thể dán vào bất kỳ công ty nào. Nếu bạn xoá tên sản phẩm, tên công ty ra khỏi bản PRD mà AI viết, và nó vẫn đọc trôi chảy như thể áp dụng được cho bất kỳ app fintech/e-commerce nào khác, đó là dấu hiệu rõ ràng của generic output. Ví dụ kinh điển: PRD ví điểm thưởng ở trên liệt kê "User Story: Là một user, tôi muốn tích điểm khi mua hàng để nhận ưu đãi" — đúng nhưng vô nghĩa, vì nó không nhắc gì đến cơ chế tích điểm hiện tại công ty đang có, không nhắc tới việc công ty đã từng có chương trình loyalty cũ cần migrate dữ liệu, không nhắc gì đến quy định thuế/kế toán khi quy đổi điểm ra tiền tại Việt Nam.

2. Shallow (hời hợt) — đúng cấu trúc nhưng thiếu chiều sâu lập luận. Một bản phân tích đối thủ cạnh tranh (competitive analysis) do AI viết có thể liệt kê rất đẹp bảng so sánh tính năng, nhưng khi bạn hỏi kỹ "tại sao đối thủ X lại chọn hướng này", nó không trả lời được gì ngoài suy đoán chung chung. Ví dụ thực tế: PM yêu cầu AI "phân tích đối thủ trong mảng ví điện tử", AI trả về so sánh với PayPal, Venmo, Cash App — toàn sản phẩm Mỹ, không hề nhắc đến MoMo, ZaloPay, VNPay hay hành vi thanh toán QR code đặc thù của thị trường Việt Nam. Đây không phải AI "sai", mà là AI đang dùng dữ liệu huấn luyện mặc định (chủ yếu tiếng Anh, thị trường Mỹ) khi bạn không cung cấp đủ context về thị trường mục tiêu.

3. Misaligned (lệch) với ràng buộc kinh doanh thật. Đây là dạng nguy hiểm nhất vì nó có thể dẫn đến quyết định sai ở cấp lãnh đạo. Một roadmap do AI vẽ ra có thể đề xuất "Q1: ra mắt 5 tính năng lớn song song" — nghe rất tham vọng, nhưng hoàn toàn bỏ qua việc team hiện tại chỉ có 3 dev backend, đang phải maintain một hệ thống legacy, và 2 người sắp nghỉ phép dài hạn. AI không biết những ràng buộc này trừ khi bạn nói ra, và nếu bạn không kiểm tra kỹ, một roadmap "nhìn hợp lý trên giấy" có thể khiến bạn cam kết sai với ban lãnh đạo.

Điểm chung của cả ba dạng lỗi: chúng không nằm ở "AI viết sai ngữ pháp" hay "AI bịa số liệu" (hallucination — AI tự tạo ra thông tin không có thật) theo nghĩa lộ liễu, mà nằm ở việc AI trả lời đúng câu hỏi bạn hỏi, nhưng câu hỏi bạn hỏi lại thiếu context để có câu trả lời đúng cho công ty bạn.

Quy Trình Chấm Điểm Nhanh Một Output AI Trước Khi Dùng

1. Xoá tên riêng, đọc lại. Xoá tên sản phẩm/công ty/thị trường khỏi output, đọc lại xem nó còn "dán được" vào công ty khác không. Nếu có, output đó chưa đủ cụ thể.
2. Đối chiếu với 3 con số/sự thật bạn biết rõ nhất. Chọn 3 điều bạn chắc chắn 100% về sản phẩm/team/thị trường (ví dụ: quy mô team, đối thủ thực tế, quy định pháp lý địa phương), kiểm tra xem output có nhắc đúng, nhắc sai, hay hoàn toàn bỏ qua.
3. Tìm câu trả lời "an toàn nước đôi". Những câu như "tuỳ vào từng trường hợp cụ thể", "cần cân nhắc thêm nhiều yếu tố" mà không đi kèm khuyến nghị cụ thể là dấu hiệu AI đang né tránh vì thiếu context, không phải vì câu hỏi thực sự mơ hồ.
4. Hỏi ngược "Bạn giả định gì khi viết câu trả lời này?" Đây là câu hỏi đơn giản nhưng cực kỳ hiệu quả — bắt AI lộ ra những giả định ngầm (ví dụ: giả định thị trường Mỹ, giả định team 10 người, giả định không có ràng buộc pháp lý) mà bạn có thể chưa để ý.
5. Kiểm tra tính hành động được (actionability). Một output tốt luôn dẫn tới bước tiếp theo rõ ràng. Nếu đọc xong bạn vẫn không biết mình cần làm gì tiếp, đó là output hời hợt dù hình thức đẹp.

Prompt Tự Chấm Điểm Output — Bắt AI Soi Lại Chính Nó

Đây là output bạn vừa tạo ra ở trên (dán lại toàn bộ nội dung).

Hãy tự đánh giá lại chính output này với vai trò một reviewer khó tính,
theo các tiêu chí sau:

1. Liệt kê những giả định ngầm bạn đã dùng khi tạo ra output này
   (về thị trường, quy mô team, đối thủ, hành vi người dùng, quy định
   pháp lý) mà tôi KHÔNG cung cấp cho bạn.
2. Đánh dấu những phần trong output có thể áp dụng cho BẤT KỲ sản phẩm
   nào khác, không riêng gì sản phẩm của tôi (dấu hiệu generic).
3. Đánh dấu những kết luận/khuyến nghị không có lập luận hoặc bằng
   chứng đi kèm (dấu hiệu shallow).
4. Với mỗi vấn đề tìm được ở trên, đề xuất câu hỏi cụ thể tôi cần trả
   lời để bạn viết lại output chính xác hơn.

Bối cảnh sản phẩm của tôi: [MÔ TẢ NGẮN GỌN SẢN PHẨM, THỊ TRƯỜNG,
QUY MÔ TEAM].

Mẹo: Đừng chỉ tự chấm điểm bằng mắt của chính bạn — dùng chính AI để "soi lại" output của nó với một prompt riêng, tách khỏi cuộc hội thoại tạo ra output ban đầu (mở chat mới hoặc yêu cầu rõ "hãy đóng vai reviewer độc lập"). AI đọc lại chính output của mình khách quan hơn khi được đặt vào vai trò phản biện, thay vì tiếp tục mạch "đồng thuận" của cuộc hội thoại trước đó.

Kỹ Thuật Refine Đa Lượt (Multi-Turn) — Thu Hẹp Phạm Vi, Thách Thức Giả Định, Và Đào Sâu Phân Tích Của AI

Một prompt đơn lẻ, dù viết tốt đến đâu, hiếm khi cho ra kết quả dùng được ngay cho những bài toán PM phức tạp — viết PRD, phân tích chiến lược, đánh giá trade-off roadmap. Giá trị thật nằm ở khả năng dẫn dắt một cuộc hội thoại nhiều lượt (multi-turn), nơi mỗi câu hỏi tiếp theo (follow-up prompt) đẩy AI đi sâu hơn, hẹp hơn, hoặc buộc nó bảo vệ lập luận của chính nó. Có bốn kỹ thuật cốt lõi nên nằm trong phản xạ của mọi PM/BA dùng AI:

Narrowing (thu hẹp phạm vi): Sau khi nhận một output rộng, chung chung, đừng vội bỏ đi — hãy yêu cầu AI thu hẹp lại vào đúng một khía cạnh bạn quan tâm nhất. Ví dụ: nhận bản phân tích đối thủ liệt kê 8 đối thủ, bạn thu hẹp "chỉ phân tích sâu 2 đối thủ có mô hình kinh doanh giống chúng tôi nhất, bỏ qua 6 đối thủ còn lại."

Challenging (thách thức giả định / đóng vai devil's advocate — người phản biện): Chủ động yêu cầu AI tự phản bác lại chính kết luận nó vừa đưa ra. Đây là kỹ thuật ít PM dùng nhất nhưng lại mang lại giá trị cao nhất, vì AI mặc định có xu hướng đồng thuận (sycophancy — thiên hướng chiều theo ý người hỏi) nếu không được yêu cầu rõ ràng phải phản biện.

Steelmanning (bảo vệ luận điểm đối lập ở phiên bản mạnh nhất): Khác với việc chỉ tìm điểm yếu, steelman nghĩa là yêu cầu AI trình bày phiên bản thuyết phục nhất của quan điểm ngược lại — hữu ích khi bạn cần chuẩn bị bảo vệ một quyết định trước ban lãnh đạo hoặc trước một stakeholder hay phản đối.

Asking for evidence/reasoning (yêu cầu bằng chứng và chuỗi lập luận): Thay vì chấp nhận kết luận, yêu cầu AI show chuỗi suy luận dẫn tới kết luận đó, từng bước một — giúp bạn phát hiện lỗ hổng logic nằm ở đâu trong chuỗi, không chỉ nhìn vào kết quả cuối.

Bốn kỹ thuật này không loại trừ nhau — một chuỗi refine hiệu quả thường đi qua cả bốn theo thứ tự: thu hẹp trước, sau đó thách thức, rồi steelman quan điểm đối lập, cuối cùng chốt lại bằng cách yêu cầu bằng chứng cho kết luận cuối cùng.

Quy Trình Dẫn Dắt Một Chuỗi Hội Thoại Refine 4 Vòng

1. Vòng 1 — Nhận output rộng, xác định phần cần đào sâu. Đọc lướt toàn bộ, chọn ra 1-2 điểm quan trọng nhất (thường là điểm ảnh hưởng đến quyết định lớn nhất) để tập trung refine, bỏ qua phần còn lại.
2. Vòng 2 — Thu hẹp và yêu cầu AI bỏ context không liên quan. Ra lệnh rõ ràng: "Bỏ qua phần X, Y đã đề cập ở trên, tập trung hoàn toàn vào Z."
3. Vòng 3 — Đóng vai phản biện, thách thức giả định. Yêu cầu AI tự tìm lỗ hổng trong chính lập luận của nó, hoặc đóng vai một stakeholder cụ thể (CFO, Head of Engineering, khách hàng khó tính) để phản bác.
4. Vòng 4 — Steelman quan điểm đối lập, rồi chốt bằng bằng chứng. Yêu cầu AI trình bày mạnh nhất phía đối lập, sau đó bạn tự cân nhắc, và cuối cùng yêu cầu AI liệt kê rõ chuỗi lập luận + nguồn/giả định cho kết luận cuối cùng để bạn dễ trace ngược khi trình bày lại cho người khác.

Prompt Ví Dụ Cho Từng Kỹ Thuật Refine

[NARROWING — Thu hẹp phạm vi]
Trong bản phân tích đối thủ bạn vừa đưa, hãy bỏ qua tất cả các đối thủ
trừ [Tên đối thủ A] và [Tên đối thủ B] — đây là 2 đối thủ có mô hình
kinh doanh gần giống chúng tôi nhất (subscription B2B, target SME
Việt Nam). Với 2 đối thủ này, đào sâu thêm:
1. Chiến lược pricing cụ thể của họ trong 12 tháng gần nhất.
2. Điểm khác biệt trong onboarding flow so với sản phẩm của tôi
   (mô tả sản phẩm: [MÔ TẢ NGẮN]).
3. Một tính năng họ có mà chúng tôi chưa có, và lý do vì sao nó
   có thể quan trọng hoặc không quan trọng với thị trường Việt Nam.

[CHALLENGING — Đóng vai phản biện]
Hãy tạm quên vai trò "AI hỗ trợ" và đóng vai một CFO khó tính, hoài
nghi với mọi đề xuất tốn tiền. Đọc lại roadmap Q1 bạn vừa đề xuất ở
trên, và đưa ra 5 câu hỏi/phản bác gay gắt nhất mà một CFO thực sự
sẽ hỏi trước khi duyệt ngân sách cho roadmap này — đặc biệt tập trung
vào giả định về nguồn lực team và ROI (return on investment — lợi
tức đầu tư) của từng hạng mục.

[STEELMANNING — Bảo vệ quan điểm đối lập]
Giả sử tôi quyết định KHÔNG làm theo đề xuất ưu tiên tính năng bạn
vừa đưa ra, mà chọn thứ tự ngược lại. Hãy trình bày lập luận thuyết
phục nhất có thể cho phương án ngược lại này, như thể bạn đang cố
thuyết phục tôi rằng đó mới là lựa chọn đúng. Không được nói "đây là
lựa chọn tệ" — hãy tìm lý do thực sự khiến nó hợp lý trong một số
bối cảnh.

[EVIDENCE/REASONING — Yêu cầu chuỗi lập luận]
Với kết luận cuối cùng bạn đưa ra ("nên ưu tiên tính năng X trước
tính năng Y"), hãy trình bày rõ từng bước lập luận dẫn tới kết luận
đó, theo định dạng:
Giả định 1 → Bằng chứng/lý do → Giả định 2 → Bằng chứng/lý do → ...
→ Kết luận.
Với mỗi giả định, chỉ rõ đây là giả định bạn tự đưa ra hay dựa trên
thông tin tôi đã cung cấp trong hội thoại.

Mẹo: Đừng thách thức và steelman trong cùng một prompt — tách riêng hai lượt. Nếu gộp chung, AI có xu hướng trả lời nước đôi, vừa phản biện vừa bênh vực trong cùng một đoạn, khiến bạn khó tách bạch đâu là điểm yếu thật sự cần lưu ý, đâu là lập luận bảo vệ cho phương án gốc.

Khi Nào Dùng Prompt Một Lần (Single-Shot) Và Khi Nào Cần Hội Thoại Nhiều Vòng (Conversational Iteration)

Không phải lúc nào refine nhiều vòng cũng là lựa chọn đúng. Một PM giỏi biết phân biệt lúc nào nên đầu tư 20 phút viết một prompt thật kỹ để lấy kết quả ngay lần đầu (single-shot — một phát ăn ngay), và lúc nào nên chấp nhận một prompt mở đầu sơ sài rồi dành 30-45 phút hội thoại qua lại (conversational iteration — lặp qua hội thoại) để dần làm rõ vấn đề.

Ba yếu tố quyết định nên chọn hướng nào:

Độ rõ ràng của yêu cầu ngay từ đầu. Nếu bạn đã biết chính xác mình cần gì — ví dụ "tóm tắt 5 điểm chính từ 10 câu trả lời phỏng vấn user này theo đúng 3 chủ đề: pain point, mong muốn tính năng, mức độ sẵn sàng trả tiền" — đây là ứng viên hoàn hảo cho single-shot, vì cấu trúc câu trả lời đã rõ, không cần khám phá thêm.

Mức độ rủi ro/tác động của quyết định. Nếu output sẽ được dùng để ra quyết định lớn (roadmap quý, PRD cho tính năng ảnh hưởng doanh thu, thông điệp gửi ban lãnh đạo), luôn đáng đầu tư thời gian iteration dù prompt ban đầu đã khá tốt — chi phí sai sót ở đây cao hơn nhiều chi phí thời gian bỏ ra để refine.

Mức độ mơ hồ của chính vấn đề (không phải của prompt). Có những bài toán PM mà chính bạn cũng chưa hình dung rõ câu trả lời trông như thế nào (ví dụ: "chúng ta có nên pivot sang B2B không?") — với dạng bài toán này, hội thoại nhiều vòng không chỉ giúp AI hiểu bạn hơn, mà còn giúp chính bạn tư duy rõ ràng hơn qua quá trình đặt câu hỏi ngược lại cho AI.

Bảng quyết định nhanh:

Checklist Quyết Định Trước Khi Gõ Prompt

1. Tự hỏi: "Tôi có thể mô tả chính xác định dạng và tiêu chí của câu trả lời tốt ngay bây giờ không?" Nếu có → nghiêng về single-shot, đầu tư viết prompt kỹ ngay từ đầu.
2. Tự hỏi: "Nếu output này sai mà tôi không phát hiện ra, hậu quả lớn cỡ nào?" Rủi ro cao → luôn dành thời gian conversational, kể cả khi prompt đầu đã tốt.
3. Kiểm tra xem đây có phải tác vụ lặp lại (recurring) hay không — nếu có, đầu tư thời gian một lần để viết prompt single-shot thật chuẩn, rồi lưu vào prompt library (xem phần sau) để dùng lại, tránh việc lần nào cũng phải iterate lại từ đầu.
4. Đặt giới hạn thời gian cho hội thoại (ví dụ tối đa 4-5 vòng) — nếu sau 5 vòng vẫn chưa hội tụ về câu trả lời dùng được, nhiều khả năng vấn đề gốc chưa đủ rõ với chính bạn, cần dừng lại suy nghĩ thêm ngoài AI, không phải tiếp tục hỏi AI.

Prompt Ví Dụ — Single-Shot Được Đầu Tư Kỹ (Mọi Ràng Buộc Đưa Ngay Từ Đầu)

Bạn là Product Analyst hỗ trợ tôi tóm tắt kết quả phỏng vấn user.

Bối cảnh: Chúng tôi vừa phỏng vấn 8 user hiện tại của app quản lý chi
tiêu cá nhân, về tính năng "nhắc nhở hoá đơn sắp đến hạn" sắp ra mắt.

Dưới đây là transcript của 8 buổi phỏng vấn (đã ẩn danh):
[PASTE TRANSCRIPT]

Hãy tóm tắt theo đúng cấu trúc sau, không thêm mục khác:
1. Pain point chính (tối đa 5, sắp xếp theo tần suất nhắc tới nhiều
   nhất), mỗi pain point trích 1 câu quote nguyên văn minh hoạ.
2. Mong muốn cụ thể về tính năng (feature request), phân biệt rõ đâu
   là "nice to have" và đâu là "phải có mới dùng".
3. Mức độ sẵn sàng trả thêm phí cho tính năng này (Cao/Trung/Thấp),
   dựa trên ngôn từ họ dùng khi được hỏi trực tiếp.
4. Một bảng: User | Pain point chính | Mức độ ưu tiên tính năng.

Trả lời bằng tiếng Việt, giữ nguyên các thuật ngữ tiếng Anh phổ biến
trong ngành (feature request, nice to have, onboarding, v.v.).

Prompt Ví Dụ — Mở Đầu Hội Thoại Cho Vấn Đề Còn Mơ Hồ

Tôi đang cân nhắc một quyết định chiến lược lớn: liệu có nên pivot
sản phẩm hiện tại (app B2C quản lý chi tiêu cá nhân, 50.000 user)
sang hướng B2B (bán cho doanh nghiệp làm công cụ quản lý phúc lợi
nhân viên) hay không.

Tôi chưa có câu trả lời rõ ràng, và bản thân câu hỏi có thể còn thiếu
góc nhìn. Đừng vội đưa ra khuyến nghị ngay. Hãy bắt đầu bằng cách hỏi
tôi tối đa 5 câu hỏi làm rõ quan trọng nhất mà bạn cần biết trước khi
có thể phân tích nghiêm túc quyết định này (ví dụ về runway tài chính,
lý do B2C không tăng trưởng, năng lực sales hiện tại, v.v.).

Mẹo: Nếu bạn nhận ra mình đang lặp lại một hội thoại "khám phá" (conversational) giống hệt tuần trước cho một loại tác vụ tương tự, đó là tín hiệu rõ ràng: đã đến lúc biến nó thành một prompt single-shot chuẩn hoá, lưu vào thư viện cá nhân — đừng để mỗi lần đều phải dò lại từ đầu.

Xây Dựng Prompt Library Cá Nhân Cho Các Tác Vụ PM Lặp Lại

Phần lớn công việc của một BA/PM/PO xoay quanh một số nhóm tác vụ lặp đi lặp lại: viết PRD, tổng hợp kết quả phỏng vấn user, soạn báo cáo cập nhật cho stakeholder, chạy phân tích đối thủ, viết user story, chuẩn bị tài liệu cho buổi grooming. Nếu mỗi lần làm những việc này bạn đều gõ prompt từ đầu, bạn đang lãng phí chính giá trị lớn nhất của việc dùng AI: khả năng tái sử dụng kinh nghiệm đã được kiểm chứng. Một prompt library (thư viện prompt) cá nhân — hoặc tốt hơn, của cả team — giải quyết đúng vấn đề này.

Một prompt library hiệu quả không phải là một file ghi chú lộn xộn dán đầy prompt cũ, mà cần có cấu trúc tối thiểu:

• Phân loại theo tác vụ (category): PRD Drafting, User Research Synthesis, Stakeholder Update, Competitive Analysis, User Story Writing, Roadmap Planning...
• Ngữ cảnh đi kèm (context block): phần thông tin công ty/sản phẩm cố định (quy mô team, thị trường mục tiêu, đối thủ chính, stack công nghệ) mà bạn copy-paste vào đầu mọi prompt liên quan, tránh phải gõ lại mỗi lần.
• Prompt đã kiểm chứng (battle-tested prompt): chỉ những prompt đã thực sự cho ra kết quả tốt ít nhất 2-3 lần mới nên vào thư viện chính thức — tránh thư viện phình to với những prompt chưa được test kỹ.
• Ghi chú về lần chỉnh sửa gần nhất và lý do (changelog ngắn): giúp bạn (hoặc đồng nghiệp dùng chung) hiểu vì sao prompt được sửa từ phiên bản trước, tránh sửa lại cùng một lỗi đã từng gặp.
• Ví dụ output mẫu (sample output) đính kèm: giúp người dùng sau này biết ngay kỳ vọng chất lượng, không cần chạy thử mới biết prompt có tốt hay không.

Công cụ lưu trữ có thể đơn giản: một trang Notion dùng chung cho cả team PM, một prompt manager chuyên dụng (ví dụ các tiện ích quản lý prompt tích hợp trong trình duyệt), hoặc đơn giản một Google Doc/Confluence page có cấu trúc rõ ràng. Công cụ không quan trọng bằng kỷ luật cập nhật — một thư viện không ai cập nhật sau 2 tháng sẽ chết y như mọi tài liệu "để sau" khác.

Quy Trình Xây Và Duy Trì Prompt Library

1. Bắt đầu từ việc ghi lại, không phải thiết kế trước. Đừng cố ngồi thiết kế cấu trúc thư viện hoàn hảo trước khi có prompt nào — cứ dùng AI như bình thường trong 1-2 tuần, mỗi khi có một prompt cho ra kết quả thực sự tốt, copy nó vào một chỗ tạm ngay lập tức (đừng để "lát nữa lưu" rồi quên).
2. Chuẩn hoá phần context block dùng chung. Viết một đoạn 3-5 câu mô tả công ty/sản phẩm/thị trường của bạn một lần, lưu riêng, và tham chiếu/copy vào đầu các prompt khác — đây là phần tốn công viết lại nhiều nhất nếu không chuẩn hoá.
3. Test lại prompt cũ trước khi đưa vào thư viện chính thức. Một prompt tốt trong tình huống cụ thể chưa chắc tốt khi tổng quát hoá — thử lại prompt đó với một tác vụ tương tự nhưng khác 1-2 chi tiết, xem nó có còn hiệu quả không trước khi coi là "chuẩn".
4. Gắn tag theo tác vụ và theo mức độ tin cậy. Ví dụ tag #prd #dat-cau-hoi-lam-ro #da-test-3-lan, giúp tìm lại nhanh và biết ngay prompt nào đáng tin hơn.
5. Review và dọn dẹp thư viện định kỳ (mỗi tháng hoặc mỗi quý). Xoá hoặc gộp các prompt trùng lặp, cập nhật context block nếu công ty/sản phẩm có thay đổi lớn (ra thị trường mới, đổi định vị sản phẩm), và loại bỏ prompt không còn ai dùng.
6. Chia sẻ ra cả team, không giữ riêng cho mình. Giá trị của prompt library tăng theo cấp số nhân khi cả team PM/BA cùng đóng góp và dùng chung — một prompt viết PRD tốt của một người có thể tiết kiệm hàng giờ cho cả 5 người khác trong team.

Prompt Mẫu — Biến Một Prompt Ad-Hoc Thành Template Dùng Lại Được

Đây là một prompt tôi vừa dùng và cho ra kết quả rất tốt:

[PASTE PROMPT VÀ OUTPUT ĐÃ DÙNG THÀNH CÔNG]

Hãy giúp tôi tổng quát hoá prompt này thành một template có thể dùng
lại cho các tình huống tương tự trong tương lai:
1. Xác định phần nào trong prompt là CỐ ĐỊNH (không đổi giữa các lần
   dùng) và phần nào là BIẾN (cần thay đổi mỗi lần, ví dụ tên tính
   năng, dữ liệu cụ thể).
2. Viết lại thành template, đánh dấu rõ các biến bằng [NGOẶC VUÔNG].
3. Đề xuất tên gọi ngắn gọn cho template này và category nó thuộc về
   (ví dụ: PRD Drafting, Stakeholder Update, Competitive Analysis).
4. Gợi ý 2-3 câu hỏi làm rõ nên hỏi thêm TRƯỚC khi dùng template này,
   để tránh lặp lại lỗi output generic đã gặp trước đây.

[MẪU CONTEXT BLOCK DÙNG CHUNG — copy đầu mọi prompt liên quan đến sản phẩm]

Bối cảnh sản phẩm: [Tên sản phẩm], app [B2B/B2C] trong lĩnh vực
[lĩnh vực], phục vụ [X] người dùng/khách hàng tại thị trường
[Việt Nam / khu vực cụ thể]. Team hiện tại gồm [số lượng] dev,
[số lượng] designer, do 1 PM phụ trách. Đối thủ chính: [tên 2-3
đối thủ thực tế]. Ràng buộc quan trọng: [ví dụ: phải tuân thủ quy
định về dữ liệu tài chính cá nhân, tích hợp với cổng thanh toán
nội địa, ngân sách quý này giới hạn ở mức Y].

Mẹo: Đừng đợi có "prompt hoàn hảo" mới lưu vào thư viện — lưu ngay cả những prompt "khá tốt" kèm ghi chú rõ điểm cần cải thiện. Một thư viện sống, được cập nhật liên tục dù chưa hoàn hảo, có giá trị hơn nhiều so với việc chờ đến khi có phiên bản "chuẩn chỉnh" rồi mới bắt đầu ghi chép — vì lúc đó phần lớn kinh nghiệm quý giá đã bị quên mất.

Những Điểm Chính Cần Nhớ

• Output AI "nhìn đẹp" không đồng nghĩa với "dùng được" — luôn kiểm tra ba dấu hiệu: generic (chung chung, dán được vào công ty khác), shallow (đúng cấu trúc nhưng thiếu lập luận), và misaligned (bỏ qua ràng buộc kinh doanh thật như quy mô team, thị trường, quy định pháp lý).
• Refine đa lượt (multi-turn) hiệu quả nhất khi đi theo trình tự: thu hẹp phạm vi (narrowing) → thách thức giả định (challenging) → bảo vệ quan điểm đối lập (steelmanning) → yêu cầu bằng chứng/lập luận (evidence). Tách riêng từng kỹ thuật vào từng lượt hỏi, đừng gộp chung.
• Chọn single-shot khi yêu cầu đã rõ ràng, rủi ro thấp, và tác vụ lặp lại thường xuyên; chọn conversational iteration khi rủi ro cao, vấn đề còn mơ hồ với chính bạn, hoặc quyết định ảnh hưởng lớn tới sản phẩm/team.
• Xây prompt library cá nhân (hoặc team) là cách biến kinh nghiệm dùng AI từ "học lại mỗi lần" thành tài sản tích luỹ — cấu trúc theo category, kèm context block chuẩn hoá, prompt đã kiểm chứng, và ví dụ output mẫu.
• Kỹ năng lớn nhất không phải là viết prompt hay ngay lần đầu, mà là biết đọc ra khi nào output chưa đủ tốt, và có phản xạ dẫn dắt AI đi sâu hơn thay vì chấp nhận bản nháp đầu tiên.

Mẹo: In checklist "3 dấu hiệu output tệ" (generic/shallow/misaligned) ra và dán cạnh màn hình trong vài tuần đầu luyện tập — đến khi việc soi output trở thành phản xạ tự nhiên mỗi lần nhận kết quả từ AI, bạn sẽ không còn cần nhìn checklist nữa.