Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao nhiệm vụ viết spec cho một tính năng mới: "Trợ lý AI gợi ý sản phẩm trong giỏ hàng". Bạn ngồi xuống, mở template PRD quen thuộc của công ty, điền vào các mục Problem, Goal, User Stories, Acceptance Criteria — y hệt như mọi tính năng bạn từng làm. Bạn gửi đi, đội kỹ thuật gật đầu, và ba tuần sau bạn nhận về một thứ... gần đúng. Đôi khi nó gợi ý chuẩn xác đến kinh ngạc. Đôi khi nó gợi ý dầu gội cho người vừa mua... thức ăn cho mèo. Và khi bạn hỏi "tại sao nó làm vậy?", cả phòng im lặng, bởi vì spec của bạn chưa bao giờ định nghĩa "đúng" nghĩa là gì khi đầu ra không phải lúc nào cũng giống nhau.
Đây chính là cú sốc đầu tiên mà mọi PM gặp khi chuyển từ viết spec cho tính năng truyền thống sang tính năng AI. Spec truyền thống được xây trên một giả định ngầm: cùng một đầu vào sẽ cho ra cùng một đầu ra. Nhấn nút "Thanh toán" với giỏ hàng 500.000đ thì luôn ra hóa đơn 500.000đ. Nhưng tính năng AI hoạt động theo xác suất (probabilistic), không theo quy tắc cứng (deterministic). Cùng một câu hỏi, model có thể trả lời hơi khác nhau mỗi lần. Đầu ra đi kèm một mức độ tin cậy (confidence) chứ không phải một sự thật tuyệt đối. Và quan trọng nhất: model có thể sai một cách rất thuyết phục.
Bài học này tập trung hẹp vào cách viết spec cho tính năng AI — tức là khi sản phẩm bạn xây dựng có AI bên trong, phục vụ người dùng cuối. Đây không phải bài về dùng AI để viết PRD (đó là Bài 11), cũng không phải về đạo đức của sản phẩm AI (Bài 52). Ở đây, chúng ta học cách mô tả một hệ thống không xác định sao cho đội kỹ thuật, designer và chính bạn ba tháng sau vẫn hiểu rõ thế nào là thành công.
Khái niệm cốt lõi
Vì sao PRD chuẩn không đủ
PRD truyền thống mô tả hành vi: "Khi người dùng làm X, hệ thống làm Y." Mô hình này gãy đổ với AI vì ba lý do.
Thứ nhất, đầu ra là xác suất, không phải quy tắc. Bạn không thể liệt kê hết mọi đầu vào và đầu ra tương ứng. Thay vào đó, bạn phải mô tả phân phối hành vi mong muốn: model nên đúng bao nhiêu phần trăm thời gian, và khi nó sai thì sai theo kiểu chấp nhận được hay không.
Thứ hai, có khái niệm độ tin cậy (confidence). Một model có thể trả về kết quả kèm điểm tự tin. Spec của bạn phải quy định: ở ngưỡng tự tin nào thì hiển thị thẳng cho user, ngưỡng nào thì hiển thị kèm cảnh báo, ngưỡng nào thì im lặng không hiển thị gì. Ranh giới này chính là phần "thịt" của một AI spec tốt.
Thứ ba, luôn tồn tại trường hợp model sai (failure modes). Trong tính năng truyền thống, lỗi là ngoại lệ cần fix. Trong tính năng AI, "lỗi" là một phần bản chất — câu hỏi không phải "làm sao để không bao giờ sai" mà là "khi sai thì chuyện gì xảy ra với người dùng, và làm sao để hậu quả nhẹ nhất".
Bảy thành phần một AI spec cần có thêm
So với PRD chuẩn, một spec cho tính năng AI cần bổ sung các phần sau:
- Định nghĩa "đúng" (Quality bar): Thế nào là một câu trả lời tốt? Cho ví dụ cụ thể về đầu ra đạt và không đạt. Đây là phần quan trọng nhất và hay bị bỏ sót nhất.
- Confidence và hành vi theo ngưỡng: Quy định rõ hệ thống làm gì ở mỗi mức độ tin cậy. Ví dụ: trên 0.8 thì tự động áp dụng, 0.5–0.8 thì gợi ý cho user xác nhận, dưới 0.5 thì không hiển thị.
- Failure modes và fallback: Liệt kê các kiểu sai (hallucination — bịa thông tin; off-topic; trả lời rỗng; nội dung nhạy cảm) và phương án dự phòng cho từng kiểu. Luôn phải có một "đường lui an toàn" khi AI không dùng được.
- Human-in-the-loop: Quyết định nào AI được tự làm, quyết định nào bắt buộc có người duyệt. Càng rủi ro cao (tiền bạc, pháp lý, sức khỏe) thì càng cần con người.
- Guardrails và phạm vi: AI được phép nói/làm gì và tuyệt đối không được làm gì. Ví dụ: chatbot ngân hàng không được đưa lời khuyên đầu tư cụ thể.
- Dữ liệu và prompt context: AI dựa trên nguồn dữ liệu nào, được cấp thông tin gì trong ngữ cảnh. Điều này ảnh hưởng trực tiếp đến chất lượng và bảo mật.
- Cách đo lường và cải tiến: Metric đánh giá chất lượng (không chỉ uptime mà cả độ chính xác, tỉ lệ user chấp nhận gợi ý), và quy trình thu thập phản hồi để cải thiện theo thời gian.
Acceptance criteria kiểu mới
Trong spec truyền thống bạn viết: "Hệ thống phải hiển thị tổng tiền chính xác." Một câu, kiểm tra được, hoặc đúng hoặc sai. Với AI, acceptance criteria phải mang tính thống kê và có ví dụ minh họa. Ví dụ tốt: "Trên một bộ test gồm 100 câu hỏi tiêu chuẩn, ít nhất 85% câu trả lời được đánh giá là 'hữu ích và chính xác' bởi 2 reviewer độc lập; không có câu nào đưa thông tin sai về giá hoặc chính sách hoàn tiền." Lưu ý hai điều: có ngưỡng phần trăm, và có một lằn ranh đỏ tuyệt đối (không bao giờ sai về giá) bên cạnh ngưỡng mềm.
Tình huống thực tế
Tình huống 1: Chatbot CSKH của một sàn TMĐT Việt Nam
Một sàn thương mại điện tử cỡ vừa tại TP.HCM (giả định tên Chợ Sỉ) muốn ra mắt chatbot AI trả lời câu hỏi khách hàng về đơn hàng và chính sách. PM ban đầu viết spec kiểu cũ: "Chatbot trả lời câu hỏi của khách về tình trạng đơn hàng, đổi trả, và vận chuyển." Đội kỹ thuật build xong, demo rất ấn tượng. Nhưng khi chạy thật, chatbot bắt đầu bịa chính sách hoàn tiền — có lần nói khách được hoàn tiền trong 30 ngày trong khi chính sách thật là 7 ngày. Một khách chụp màn hình đăng lên Facebook, gây khủng hoảng nhỏ.
Vấn đề: spec không hề định nghĩa "đúng", không có failure mode cho hallucination, và không phân biệt câu hỏi nào AI được tự trả lời với câu hỏi nào cần dữ liệu chính xác tuyệt đối.
PM viết lại spec với ba bổ sung. Một, phân tầng câu hỏi: câu hỏi về chính sách (hoàn tiền, bảo hành) bắt buộc trả lời bằng cách trích nguyên văn từ tài liệu chính sách (retrieval), không cho model tự diễn giải. Hai, ngưỡng confidence: nếu hệ thống không tìm được tài liệu liên quan với độ khớp trên 0.7, chatbot trả lời "Mình chưa chắc về điều này, để mình chuyển bạn tới nhân viên nhé" thay vì đoán. Ba, lằn ranh đỏ: tuyệt đối không đưa con số (ngày, %, tiền) nào không có trong tài liệu nguồn. Kết quả sau một tháng: tỉ lệ khiếu nại do thông tin sai giảm từ 12 ca/tuần xuống còn 1.
Bài học: Với thông tin có thể gây hậu quả pháp lý hay tài chính, đừng để model "sáng tạo". Spec phải buộc nó trích dẫn nguồn và biết nói "tôi không biết".
Tình huống 2: Tính năng gợi ý nội dung của một startup edtech
Một startup edtech (giả định tên HọcNhanh) xây tính năng AI gợi ý "bài học tiếp theo nên học" dựa trên lịch sử của học viên. PM viết acceptance criteria: "Gợi ý phải liên quan đến trình độ học viên." Đội kỹ thuật hỏi lại: "Liên quan" là sao? Đo bằng gì? Cuối cùng mỗi người hiểu một kiểu, và lúc nghiệm thu thì cãi nhau vì không ai có tiêu chí chung.
PM sửa bằng cách xây một bộ đánh giá bằng ví dụ (golden set): chọn 50 hồ sơ học viên mẫu, và với mỗi hồ sơ, một chuyên gia giáo dục viết sẵn 2-3 bài học "đáng lẽ phải gợi ý". Acceptance criteria thành: "Với 50 hồ sơ mẫu, ít nhất 80% trường hợp gợi ý của AI trùng với danh sách chuyên gia, hoặc được chuyên gia chấm là hợp lý dù khác lựa chọn." Thêm vào đó là quy định confidence: nếu học viên mới chỉ học dưới 3 bài (dữ liệu quá ít), không gợi ý cá nhân hóa mà hiển thị lộ trình mặc định.
Bài học: "Liên quan", "tốt", "phù hợp" là những từ vô nghĩa trong AI spec nếu không kèm ví dụ cụ thể và cách đo. Golden set biến một mục tiêu mơ hồ thành một bài kiểm tra có thể chấm điểm.
Tình huống 3: Tóm tắt phản hồi khách hàng tại một ngân hàng số
Một ngân hàng số ở Đông Nam Á muốn dùng AI tóm tắt hàng nghìn phản hồi của khách mỗi tuần thành báo cáo cho ban lãnh đạo. Đây là tính năng nội bộ, rủi ro thấp hơn, nhưng PM thông minh vẫn viết spec cẩn thận vì biết lãnh đạo sẽ ra quyết định dựa trên báo cáo này.
Phần quan trọng nhất trong spec của cô là human-in-the-loop và minh bạch nguồn. AI tạo bản tóm tắt nháp, nhưng mỗi luận điểm phải kèm số lượng phản hồi gốc và link tới mẫu ("Có 47 khách phàn nàn về thời gian chờ — xem ví dụ"). Một nhân viên phân tích duyệt lại trước khi gửi lãnh đạo. Spec cũng định nghĩa failure mode tinh tế: nếu AI "phóng đại" một chủ đề nhỏ thành xu hướng lớn, con người phải bắt được — nên báo cáo bắt buộc hiển thị tần suất, không cho phép kết luận định tính kiểu "nhiều khách không hài lòng" mà không có con số.
Bài học: Ngay cả tính năng nội bộ rủi ro thấp cũng cần human-in-the-loop khi đầu ra dùng để ra quyết định. Yêu cầu AI luôn "chỉ ra bằng chứng" là một guardrail chống hallucination cực kỳ hiệu quả.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng khi viết spec cho bất kỳ tính năng AI nào.
Bước 1 — Bắt đầu bằng định nghĩa "đúng". Trước cả khi viết user story, hãy viết 5-10 cặp ví dụ: đầu vào này thì đầu ra tốt trông như thế nào, và đầu ra tệ trông như thế nào. Đây là phần khó nhất nên làm đầu tiên. Nếu bạn không tự viết được ví dụ "tốt", nghĩa là chính bạn cũng chưa hiểu tính năng.
Bước 2 — Phân loại mức độ rủi ro. Hỏi: nếu AI sai ở chỗ này, hậu quả tệ nhất là gì? Khó chịu nhẹ (gợi ý sai sản phẩm) hay nghiêm trọng (báo sai số dư tài khoản)? Mức rủi ro quyết định bạn cần bao nhiêu guardrail và human-in-the-loop.
Bước 3 — Định nghĩa hành vi theo confidence. Vẽ một bảng đơn giản: ở mỗi khoảng độ tin cậy, hệ thống làm gì. Luôn có một nhánh "khi không đủ tự tin" — và nhánh đó phải an toàn (im lặng, hỏi lại, hoặc chuyển cho người).
Bước 4 — Liệt kê failure modes và fallback. Với mỗi kiểu sai có thể xảy ra (bịa thông tin, lạc đề, trả lời rỗng, nội dung không phù hợp), viết rõ: hệ thống phát hiện thế nào, và làm gì để giảm thiệt hại.
Bước 5 — Quyết định ranh giới con người và máy. Ghi rõ AI được tự quyết gì, cái gì bắt buộc người duyệt. Đặc biệt với hành động không thể hoàn tác (gửi email, hoàn tiền, xóa dữ liệu).
Bước 6 — Viết acceptance criteria thống kê. Kết hợp ngưỡng phần trăm (đo trên golden set) với lằn ranh đỏ tuyệt đối. Chỉ rõ ai chấm, chấm bằng tiêu chí gì.
Bước 7 — Định nghĩa cách đo và cải tiến sau khi ra mắt. Metric chất lượng, cơ chế thu phản hồi (nút thumbs up/down, ghi log câu trả lời bị từ chối), và nhịp review định kỳ. AI feature không "xong" khi ship — nó cần được theo dõi liên tục.
Lỗi thường gặp & mẹo
Lỗi 1: Mô tả tính năng AI như tính năng tất định. Viết "hệ thống sẽ gợi ý đúng sản phẩm" mà không nói "đúng" là gì và đúng bao nhiêu phần trăm. Mẹo: mỗi khi viết một từ định tính (tốt, đúng, liên quan), tự hỏi "đo cái này bằng gì?" và "cho tôi xem một ví dụ".
Lỗi 2: Quên failure mode hallucination. Nhiều PM giả định AI "thường đúng" nên bỏ qua chuyện nó sai. Mẹo: luôn coi hallucination là chắc chắn xảy ra, và thiết kế trải nghiệm sao cho khi nó xảy ra, người dùng không bị hại. Bài 16 về phát hiện hallucination sẽ giúp bạn hiểu sâu hơn cơ chế này.
Lỗi 3: Không có đường lui an toàn. Khi AI không chắc, hệ thống vẫn cố trả lời bừa. Mẹo: "im lặng còn hơn sai" với các tình huống rủi ro cao. Một câu "mình chưa chắc, để mình kết nối bạn với nhân viên" gần như luôn là fallback tốt.
Lỗi 4: Đặt ngưỡng confidence tùy hứng. Viết "ngưỡng 0.8" mà không hề biết 0.8 nghĩa là gì trong thực tế. Mẹo: đừng chốt con số trong spec đầu tiên; viết "ngưỡng X sẽ được hiệu chỉnh qua thử nghiệm" và làm việc với đội data để tìm con số đúng dựa trên dữ liệu thật.
Lỗi 5: Không định nghĩa quyền tự quyết của AI. Để mơ hồ về việc AI được tự làm gì dẫn đến những hành động không mong muốn. Mẹo: mặc định là human-in-the-loop cho mọi hành động không thể hoàn tác, rồi nới lỏng dần khi đã tin tưởng.
Mẹo vàng: Hãy đính kèm một "bộ ví dụ sống" (golden set) vào spec như một phụ lục. Nó vừa là acceptance criteria, vừa là tài liệu căn chỉnh giữa PM, kỹ thuật và data, vừa là bộ test hồi quy khi bạn đổi model sau này (rất hữu ích — xem thêm Bài 12 về chọn model).
Bài tập thực hành
Chọn một tính năng AI giả định: "Trợ lý AI soạn email trả lời khách hàng trong CRM cho một công ty bảo hiểm Việt Nam." Nhân viên gõ ý chính, AI soạn email hoàn chỉnh để nhân viên gửi.
- Định nghĩa "đúng": Viết 3 cặp ví dụ (ý chính đầu vào → email tốt vs email tệ). Email tệ ở đây có thể là gì? (Gợi ý: hứa hẹn điều khoản bảo hiểm không có thật.)
- Bảng confidence: Thiết kế hành vi cho 3 mức độ tin cậy. Khi nào AI tự soạn xong cho nhân viên chỉnh, khi nào chỉ gợi ý dàn ý, khi nào từ chối?
- Failure modes: Liệt kê ít nhất 4 kiểu sai có thể xảy ra và fallback cho từng kiểu. Chú ý kiểu sai nguy hiểm nhất: bịa ra cam kết bảo hiểm.
- Acceptance criteria: Viết một tiêu chí nghiệm thu có cả ngưỡng phần trăm lẫn lằn ranh đỏ tuyệt đối.
- Human-in-the-loop: Quyết định email có được gửi tự động không, hay luôn cần nhân viên bấm gửi? Bảo vệ lựa chọn của bạn bằng lập luận về rủi ro.
Tóm tắt
Spec cho tính năng AI khác về bản chất so với spec truyền thống vì AI hoạt động theo xác suất, đi kèm độ tin cậy, và chắc chắn sẽ sai ở một tỉ lệ nào đó. PRD chuẩn — vốn giả định đầu vào cố định cho ra đầu ra cố định — không đủ để mô tả một hệ thống như vậy.
Một AI spec tốt bổ sung bảy thành phần: định nghĩa "đúng" bằng ví dụ cụ thể, hành vi theo ngưỡng confidence, các failure mode kèm fallback, ranh giới human-in-the-loop, guardrails, nguồn dữ liệu, và cách đo lường liên tục. Acceptance criteria phải mang tính thống kê (ngưỡng phần trăm) đồng thời có lằn ranh đỏ tuyệt đối cho những điều không bao giờ được phép sai.
Ba tình huống — chatbot sàn TMĐT bịa chính sách, tính năng gợi ý edtech mơ hồ tiêu chí, và tóm tắt phản hồi ngân hàng — đều cho thấy cùng một bài học: nếu bạn không định nghĩa rõ "đúng" là gì và "khi sai thì sao", đội kỹ thuật sẽ tự định nghĩa thay bạn, và thường không theo ý bạn. Hãy bắt đầu mỗi AI spec bằng việc viết ví dụ về đầu ra tốt và xấu, luôn thiết kế đường lui an toàn, và đính kèm một golden set làm thước đo chung. Đó là sự khác biệt giữa một tính năng AI "trông ấn tượng lúc demo" và một tính năng "đáng tin khi chạy thật".