Một yêu cầu sai có thể sinh ra hàng nghìn dòng code đúng

Có một chuyện hơi ngược đời trong ngành phần mềm.

Một lập trình viên có thể viết code rất đúng.

QA có thể kiểm thử rất kỹ.

Database có thể chạy rất nhanh.

Hệ thống có thể chịu được hàng triệu request.

Nhưng sản phẩm cuối cùng vẫn sai.

Không phải vì chương trình có bug.

Mà vì ngay từ đầu, cả đội đã hiểu sai thứ cần xây.

Giống như một đội thợ nhận được bản vẽ xây nhà.

Bản vẽ ghi phòng ngủ rộng 20 mét vuông, nhưng người chủ thật ra muốn 12 mét vuông và dành phần còn lại làm nhà vệ sinh.

Thợ xây không biết chuyện đó.

Họ đo rất chuẩn.

Trộn xi măng rất đều.

Xây tường thẳng tắp.

Lát gạch đẹp long lanh.

Ba tháng sau, chủ nhà bước vào và hỏi:

Nhà vệ sinh đâu?

Người thợ mở bản vẽ ra.

Không có.

Tất cả mọi người đều làm đúng.

Chỉ có căn nhà là sai.

Phần mềm cũng vậy.

Một yêu cầu sai không chỉ tạo ra một lỗi.

Nó được nhân bản thành:

• hàng nghìn dòng code,
• hàng trăm test case,
• vài chục bảng dữ liệu,
• một đống dashboard,
• tài liệu hướng dẫn sử dụng,
• quy trình vận hành,
• và đôi khi là cả một hệ thống rất lớn đang chạy đúng một điều không ai thực sự cần.

Đó là lý do mình khá tâm đắc khi đọc bài viết “Lessons from Building a First-Pass AI PRD Reviewer at Uber”.

Uber không cố xây một AI Product Manager biết quyết định thay con người.

Họ làm một việc nghe khiêm tốn hơn rất nhiều:

Cho AI đọc bản PRD đầu tiên, trước khi những người đắt giá nhất trong phòng phải đọc nó.

Nhưng đôi khi, chính những việc khiêm tốn như vậy mới tạo ra giá trị thật.

PRD là gì, nói theo cách lúa nhất có thể?

PRD là viết tắt của Product Requirement Document.

Dịch ra là tài liệu yêu cầu sản phẩm.

Nghe hơi học thuật.

Nói đơn giản hơn, PRD là tờ giấy trả lời câu hỏi:

Chúng ta sắp xây cái gì, xây cho ai, vì sao phải xây và làm sao biết nó có ích?

Trước khi một đội kỹ thuật viết code cho tính năng hủy đơn hàng, PRD có thể phải mô tả:

• Khách hàng nào được hủy?
• Được hủy ở trạng thái nào?
• Hủy rồi có hoàn tiền không?
• Phí giao hàng xử lý ra sao?
• Voucher có trả lại không?
• Nhà bán hàng có bị trừ điểm không?
• Nhân viên chăm sóc khách hàng có can thiệp được không?
• Làm sao đo được tính năng này có hiệu quả?

PRD giống như tờ giấy gọi món trong quán ăn.

Khách ghi:

Cho một tô phở.

Bếp nhận được đúng bốn chữ đó.

Nhưng phở bò hay phở gà?

Có hành không?

Có giá không?

Ăn tại bàn hay mang về?

Khách có dị ứng đậu phộng không?

Một câu “cho một tô phở” nghe rất rõ trong đầu người viết.

Nhưng với người phải nấu, nó lại là một cánh đồng sương mù.

Vấn đề của PRD hiếm khi nằm ở câu chữ khó hiểu.

Vấn đề nằm ở những thứ người viết tưởng rằng ai cũng biết nên không viết ra.

Mười người đọc, mười bộ não khác nhau

Giả sử trong PRD có một dòng:

Khi khách hàng hủy đơn, hệ thống sẽ tự động hoàn tiền.

Product Manager đọc câu đó và nghĩ:

Hoàn lại số tiền khách đã thanh toán.

Kế toán đọc và nghĩ:

Phải trừ phí giao hàng.

Lập trình viên đọc và nghĩ:

Chỉ xử lý với giao dịch đã thanh toán thành công.

QA đọc và hỏi:

Nếu cổng thanh toán báo thành công nhưng ngân hàng chưa đối soát thì sao?

Bộ phận vận hành lại nghĩ:

Nếu tài xế đã lấy hàng thì ai chịu chi phí?

Chăm sóc khách hàng hỏi thêm:

Khách dùng một nửa voucher, một nửa tiền mặt thì hoàn kiểu gì?

Không ai cố tình làm khó ai.

Mỗi người chỉ đang đứng ở một cửa sổ khác nhau và nhìn vào cùng một căn phòng.

PRD được sinh ra để kéo những góc nhìn đó về gần nhau.

Nhưng nghịch lý nằm ở chỗ: để biết PRD đang thiếu gì, người viết thường phải biết trước tất cả những gì mình chưa biết.

Mà con người không làm được chuyện đó.

Chúng ta không thể nhớ lại một tài liệu mình chưa từng đọc.

Không thể phát hiện một thí nghiệm đã được đội khác thực hiện ba năm trước nếu chưa từng nghe về nó.

Không thể nhìn thấy một phụ thuộc nằm ngoài hệ thống mình đang phụ trách nếu chẳng ai nhắc tới.

Theo Uber, chính những khoảng trống như giả định thiếu bằng chứng, ảnh hưởng tới hệ thống lân cận, tác động bậc hai, vấn đề chính sách và các thử nghiệm cũ thường chỉ xuất hiện khi PRD đã đi vào vòng review chính thức. Khi đó, cuộc họp đáng lẽ dùng để ra quyết định lại phải quay về làm công việc điều tra căn bản. (Uber)

Cuộc họp review không nên là nơi mọi người đi tìm giấy tờ thất lạc

Hãy tưởng tượng một cuộc họp có mười người.

Có Product Lead.

Có Engineering Lead.

Có Designer.

Có Data Scientist.

Có Legal.

Có Operations.

Có Finance.

Mỗi người ngồi đó một giờ.

Nếu trong giờ đầu tiên, cả nhóm phải hỏi:

Số liệu này lấy từ đâu?

Đội nào từng thử việc này rồi?

Metric này định nghĩa thế nào?

Thay đổi này có ảnh hưởng tới hệ thống thanh toán không?

Tại sao chọn con số 20%?

Thì cuộc họp chưa thực sự review sản phẩm.

Mọi người chỉ đang cùng nhau đi tìm những mảnh giấy bị rơi dưới gầm bàn.

Đây là một sự lãng phí khá đắt.

Không chỉ vì tiền lương của những người trong phòng.

Mà vì khả năng phán đoán của con người là tài nguyên có giới hạn.

Một Product Lead chỉ có một số giờ nhất định trong ngày.

Một chuyên gia pháp lý không thể đọc mọi bản nháp từ dòng đầu tiên.

Một kiến trúc sư hệ thống không nên dành nửa cuộc họp để hỏi lại những câu hoàn toàn có thể được phát hiện từ hôm qua.

Điều Uber muốn làm không phải thay đổi quy trình phê duyệt.

Họ muốn nâng chất lượng của thứ được đưa vào quy trình đó.

Câu hỏi của họ khá đơn giản:

Nếu mỗi Product Manager đều có một người review vòng đầu thật nhanh, có đủ ngữ cảnh và không biết mệt thì sao?

Từ câu hỏi đó, Uber xây dựng PRD Evaluator, một hệ thống AI đứng trước vòng review chính thức, đọc bản nháp, tìm thêm tài liệu liên quan và trả về một bản đánh giá có cấu trúc. (Uber)

AI ở đây không phải ông sếp, mà là đứa trẻ sáu tuổi rất hay hỏi

Nhiều người nghe đến AI review PRD sẽ hình dung một chiếc máy chấm điểm.

PRD được 85 điểm.

Được duyệt.

PRD kia được 42 điểm.

Viết lại.

Theo mình, hình dung như vậy hơi nguy hiểm.

Sản phẩm không phải bài kiểm tra trắc nghiệm.

Không có đáp án A, B, C, D được in sẵn ở cuối sách.

Một AI review PRD tốt nên giống một đứa trẻ sáu tuổi.

Bạn nói:

Bố đi làm.

Nó hỏi:

Bố đi bằng gì?

Bạn trả lời:

Xe máy.

Nó hỏi tiếp:

Nếu xe hết xăng thì sao?

Bạn nói:

Bố đổ xăng.

Nó lại hỏi:

Nếu cây xăng đóng cửa thì sao?

Người lớn thường khó chịu với kiểu hỏi này.

Nhưng chính những câu hỏi nghe rất ngớ ngẩn lại bóc ra những giả định đang nằm im trong đầu chúng ta.

AI không nhất thiết hiểu doanh nghiệp sâu hơn Product Manager.

Nó chỉ có ba ưu điểm rất thực dụng:

• đọc nhanh,
• không ngại hỏi,
• và không mệt khi phải kiểm tra cùng một loại thiếu sót lần thứ một nghìn.

Con người thường bỏ qua điều quen thuộc.

Máy thì không có khái niệm “chắc ai cũng biết rồi”.

Điều Uber xây không phải một công cụ sửa văn

Một bản PRD có thể được viết rất đẹp.

Câu chữ mượt mà.

Heading ngay ngắn.

Không sai chính tả.

Đọc vào thấy tràn đầy niềm tin.

Nhưng vẫn có thể hoàn toàn chưa sẵn sàng để triển khai.

Ví dụ:

Tính năng mới dự kiến giúp tăng tỷ lệ chuyển đổi đáng kể.

Câu này nghe rất chuyên nghiệp.

Nhưng “đáng kể” là bao nhiêu?

Tăng từ 2% lên 2,1% hay từ 2% lên 4%?

Dữ liệu nào cho thấy người dùng đang gặp vấn đề?

Nếu tỷ lệ chuyển đổi tăng nhưng số đơn bị hủy cũng tăng thì sao?

Có nhóm khách hàng nào bị ảnh hưởng xấu không?

Đó là lý do Uber không muốn tạo ra một công cụ chỉ thưởng cho văn bản trau chuốt. PRD Evaluator của họ tập trung vào ngữ cảnh, logic quyết định, phạm vi, metric, rủi ro và mức độ sẵn sàng, thay vì chỉ nhìn xem tài liệu có được viết “hay” hay không. (Uber)

Đây là điểm đầu tiên mình rất tâm đắc.

AI review tài liệu không nên hỏi “bài này viết có hay không?”, mà phải hỏi “dựa vào đâu chúng ta tin đây là việc nên làm?”

Hai câu hỏi nghe gần giống nhau.

Nhưng một câu tạo ra văn bản đẹp.

Câu còn lại có thể cứu cả dự án.

Bước một: Đừng chỉ đọc tờ giấy, hãy đi lục cả tủ hồ sơ

Nếu chỉ đưa một bản PRD cho LLM rồi yêu cầu:

Review giúp tôi.

Kết quả thường sẽ khá chung chung.

AI sẽ nói:

• Cần làm rõ mục tiêu.
• Nên bổ sung rủi ro.
• Cần xác định KPI.
• Nên cân nhắc các trường hợp biên.

Nghe không sai.

Nhưng cũng không giúp được bao nhiêu.

Nó giống như bác sĩ nhìn bệnh nhân từ bên kia đường rồi nói:

Bạn nên ăn uống lành mạnh và ngủ đủ giấc.

Lời khuyên đúng với gần như mọi người.

Vì vậy cũng gần như vô dụng.

Theo mô tả của Uber, PRD Evaluator không chỉ đọc bản PRD. Nó dùng tài liệu đó làm điểm bắt đầu, sau đó tập hợp thêm các tài liệu được liên kết, slide, ghi chú cuộc họp, thí nghiệm trước đây, tài liệu từ các bộ phận khác và những kiến thức nội bộ đã được chuẩn bị sẵn như nguyên tắc cốt lõi, định nghĩa metric và các “jobs to be done”. (Uber)

Nói theo cách dễ hiểu hơn:

AI không chỉ đọc tờ đơn xin xây nhà.

Nó còn đi tìm:

• bản đồ khu đất,
• quy định xây dựng,
• bản thiết kế cũ,
• biên bản họp với hàng xóm,
• hồ sơ căn nhà từng bị nứt,
• và cuốn sổ ghi rằng khu vực này cứ tháng Chín là ngập.

Đây mới là nơi phần lớn giá trị được tạo ra.

Model có thể là bộ não biết nói.

Nhưng kho tài liệu, quyền truy cập và khả năng tìm đúng ngữ cảnh mới là đôi mắt.

Một bộ não thông minh mà bị bịt mắt thì vẫn có thể nói rất trôi chảy về thứ nó không nhìn thấy.

Context quan trọng không kém model

Đây cũng là một trong những bài học Uber rút ra: chất lượng ngôn ngữ chưa đủ, vì những tín hiệu quan trọng thường nằm ngoài chính bản PRD. Khi có thêm ngữ cảnh, hệ thống có thể phát hiện một tập điểm mù hoàn toàn khác so với khi chỉ đọc tài liệu đơn lẻ. (Uber)

Theo mình, đây là chỗ nhiều dự án AI doanh nghiệp đi sai.

Mọi người dành rất nhiều thời gian tranh luận:

• Dùng model 70B hay 200B?
• Temperature bao nhiêu?
• Prompt dài mấy nghìn token?
• Dùng agent hay workflow?
• Model nào reasoning tốt hơn?

Trong khi dữ liệu đưa vào chỉ có đúng một file Word.

Nó giống như mua một đầu bếp cực giỏi, đưa cho anh ta nửa củ hành, một gói mì và yêu cầu nấu tiệc cưới cho ba trăm người.

Đầu bếp không phải vấn đề.

Tủ lạnh mới là vấn đề.

Một hệ thống review PRD thực tế cần kết nối được với nơi kiến thức đang nằm:

• kho tài liệu nội bộ,
• hệ thống quản lý dự án,
• dashboard dữ liệu,
• tài liệu thiết kế kỹ thuật,
• biên bản họp,
• kết quả A/B testing,
• chính sách pháp lý,
• và cả những quyết định cũ đã bị chôn dưới mười tầng thư mục.

Trong trường hợp này, RAG không phải một từ khóa để trang trí slide.

Nó là công việc đi lục lại trí nhớ của cả tổ chức.

Bước hai: Không thể dùng cùng một kính lúp để soi mọi PRD

Không phải thay đổi nào cũng nguy hiểm như nhau.

Đổi màu một nút bấm không giống thay đổi cách tính giá.

Thêm bộ lọc tìm kiếm không giống thay đổi chính sách hủy đơn.

Chuyển một công cụ nội bộ sang giao diện mới không giống mở một mô hình kinh doanh hoàn toàn mới.

Nếu mọi PRD đều bị review bằng cùng một mức độ, hệ thống sẽ rơi vào một trong hai trạng thái.

Hoặc quá lỏng.

Cái gì cũng “trông ổn”.

Hoặc quá gắt.

Đổi một dấu phẩy cũng bị hỏi về chiến lược ba năm.

Uber giải quyết vấn đề này bằng cách phân loại đề xuất rồi điều chỉnh độ sâu review. Những thay đổi nhỏ như UX parity hoặc discoverability có thể được xem nhẹ hơn; thay đổi workflow hay migration cần mức vừa phải; tính năng hoàn toàn mới cần review đầy đủ; còn các thay đổi liên quan tới chính sách, giá hoặc marketplace cần thêm sự soi xét chuyên biệt. (Uber)

Nói cách khác, trước khi khám bệnh, AI phải biết bệnh nhân đang bị xước tay hay chuẩn bị mổ tim.

Cả hai đều cần bác sĩ.

Nhưng không cần cùng một phòng phẫu thuật.

Bước ba: Một PRD tốt phải đứng được trên nhiều chân

Một chiếc bàn bốn chân chỉ cần thiếu một chân là đã bắt đầu rung.

PRD cũng vậy.

Tài liệu có thể mô tả tính năng rất rõ nhưng không chứng minh được vấn đề có thật.

Có thể nêu vấn đề rất hay nhưng không định nghĩa thành công.

Có thể có metric nhưng quên guardrail.

Có thể mang lại lợi ích cho nhóm người dùng này nhưng gây thiệt hại cho nhóm khác.

Uber đánh giá mức độ sẵn sàng của PRD theo nhiều chiều, trong đó có:

• Cơ hội và giả thuyết: vấn đề có thật không, thành công đã được định nghĩa đủ rõ chưa?
• Phạm vi sản phẩm: đề xuất có dễ hiểu, đúng phạm vi và đủ thông tin để quyết định không?
• Trải nghiệm và ảnh hưởng tới người dùng: tính năng có hoạt động hợp lý với các nhóm người dùng, khu vực và trường hợp biên khác nhau không?
• Metric và độ chặt chẽ của dữ liệu: có baseline, mục tiêu, guardrail và phương pháp kiểm chứng đáng tin cậy không? (Uber)

Phần này nghe có vẻ nhiều thuật ngữ.

Ta thử lúa hóa bằng một ví dụ.

Giả sử một chuỗi bán lẻ muốn làm tính năng:

Tự động gửi voucher cho khách hàng lâu ngày chưa mua hàng.

Một PRD sơ sài có thể ghi:

Hệ thống gửi voucher 100.000 đồng cho khách không phát sinh đơn hàng trong 90 ngày nhằm tăng tỷ lệ quay lại.

Đọc rất hợp lý.

Nhưng AI reviewer nên hỏi:

Vấn đề có thật không?

Khách không quay lại vì thiếu voucher, hay vì họ vừa mua một chiếc tủ lạnh và ba năm nữa mới cần mua tiếp?

Phạm vi là gì?

Áp dụng cho tất cả ngành hàng hay chỉ hàng tiêu dùng nhanh?

Ai bị ảnh hưởng?

Khách vừa khiếu nại có nhận voucher không?

Khách đã yêu cầu không nhận quảng cáo thì sao?

Thành công là gì?

Tăng số đơn hàng, tăng doanh thu hay tăng lợi nhuận?

Nếu khách dùng voucher 100.000 đồng để mua món hàng lợi nhuận 20.000 đồng thì hệ thống đang tăng doanh thu hay đang phát tiền?

Guardrail là gì?

Có giới hạn ngân sách không?

Có ngăn một người tạo nhiều tài khoản không?

Có loại trừ nhân viên nội bộ không?

Một câu “gửi voucher để kéo khách quay lại” nghe rất đơn giản.

Nhưng phía sau nó là một đoàn tàu chở theo tiền, dữ liệu, chính sách và hành vi con người.

PRD tốt không cần dự đoán mọi thứ.

Nhưng ít nhất phải nhìn thấy đoàn tàu đang chạy tới.

Bước bốn: Đừng đưa một bức tường bình luận, hãy chỉ vào viên gạch cần sửa trước

Có một kiểu feedback nghe rất sang nhưng gần như không dùng được:

Cần làm rõ hơn chiến lược.

Hãy suy nghĩ sâu hơn về rủi ro.

Metric chưa đủ thuyết phục.

Cần xem xét tác động dài hạn.

Người viết đọc xong sẽ gật đầu.

Sau đó không biết phải sửa dòng nào.

Uber cho rằng lựa chọn thiết kế quan trọng nhất của PRD Evaluator không phải là chấm điểm, mà là biến phản biện thành hành động có thể thực hiện. Hệ thống trả về đánh giá mức độ sẵn sàng, điểm theo từng nhóm tiêu chí, một chỉ dẫn “bắt đầu từ đây”, các khoảng trống cụ thể, đề xuất nội dung thay thế, bằng chứng liên quan và danh sách hành động được chia thành yêu cầu quan trọng và phần tối ưu thêm. (Uber)

Đây là điểm thứ hai mình rất thích.

Một lời phê bình tốt không chỉ nói căn nhà đang dột. Nó phải chỉ đúng viên ngói nào cần thay trước cơn mưa.

Ví dụ, thay vì viết:

Phần metric chưa rõ.

AI có thể nói:

PRD hiện đặt mục tiêu “tăng tỷ lệ hoàn tất đơn hàng” nhưng chưa nêu baseline hiện tại, mức tăng kỳ vọng và guardrail cho tỷ lệ hủy. Hãy bổ sung ba thông tin này trước khi review.

Thậm chí nó có thể đề xuất đoạn viết:

Hiện tỷ lệ hoàn tất đơn hàng của nhóm A là 72%. Phiên bản đầu tiên đặt mục tiêu tăng lên 75% trong bốn tuần, đồng thời không làm tỷ lệ hủy sau thanh toán tăng quá 0,2 điểm phần trăm.

Đoạn này chưa chắc đúng.

Con người vẫn phải xác nhận con số.

Nhưng ít nhất người viết biết mình đang thiếu gì và phải sửa ở đâu.

Framework quan trọng hơn một lời nhận xét thông minh

Một trong những bài học Uber công bố là framework tốt hơn generic critique.

Nhận xét rộng và chung chung hiếm khi giúp đội sản phẩm tiến nhanh hơn. Giá trị thật đến từ một khung đánh giá gắn với tiêu chí ra quyết định và những kiểu thất bại đã biết. (Uber)

Theo mình, đây là nguyên tắc cực kỳ quan trọng khi xây bất kỳ hệ thống AI reviewer nào.

Không chỉ PRD.

Mà cả:

• review code,
• review thiết kế hệ thống,
• review hợp đồng,
• review tài liệu bảo mật,
• review kiến trúc dữ liệu,
• review kế hoạch marketing.

Nếu chỉ prompt:

Hãy đóng vai chuyên gia hàng đầu và review thật kỹ tài liệu này.

AI sẽ tạo ra một màn trình diễn rất mượt.

Nhưng kết quả có thể thay đổi theo từng lần chạy.

Lúc nói nhiều về metric.

Lúc nói nhiều về UX.

Lúc lại bị cuốn vào câu chữ.

Framework giống như danh sách kiểm tra trước khi máy bay cất cánh.

Phi công có thể rất giỏi.

Đã bay hai mươi năm.

Nhưng vẫn phải kiểm tra nhiên liệu, cánh tà, động cơ, liên lạc và áp suất.

Không phải vì phi công ngu.

Mà vì những hệ thống quan trọng không nên phụ thuộc hoàn toàn vào trí nhớ và tâm trạng của con người.

AI cũng vậy.

Model càng thông minh, chúng ta càng cần một khung rõ ràng để sự thông minh đó không chạy lung tung như con bò vừa thoát chuồng.

AI phải biết nói: “Tôi không đủ bằng chứng”

Một AI được huấn luyện để luôn giúp đỡ thường có xu hướng cố trả lời.

Ngay cả khi thông tin thiếu.

Đây là đặc tính khá nguy hiểm đối với một công cụ đánh giá.

Nếu PRD không có baseline, AI không nên tự tưởng tượng baseline.

Nếu tài liệu không nói tới chính sách hoàn tiền, AI không được tự suy ra chính sách.

Nếu không tìm thấy thí nghiệm cũ, nó không nên viết như thể thí nghiệm đó chưa từng tồn tại.

Uber nhận thấy các ranh giới cứng giúp đầu ra trung thực hơn. Việc định nghĩa một nhóm khoảng trống quan trọng giúp hệ thống tránh đánh giá PRD là sẵn sàng khi những nền móng căn bản vẫn còn thiếu. (Uber)

Có thể hình dung thế này.

Một bác bảo vệ tốt không phải người lúc nào cũng mở cửa.

Mà là người biết lúc nào phải nói:

Tôi chưa thấy giấy tờ. Anh vui lòng quay lại bổ sung.

Một AI reviewer cũng cần quyền từ chối kết luận.

Ví dụ:

Chưa thể đánh giá mức độ sẵn sàng vì PRD thiếu baseline của metric chính và chưa có bằng chứng cho giả thuyết nhu cầu người dùng.

Câu này ít hào nhoáng hơn một bài phân tích dài hai trang.

Nhưng đáng tin hơn rất nhiều.

Nếu cái gì cũng quan trọng thì chẳng có gì quan trọng

AI rất giỏi tìm lỗi.

Đưa một tài liệu đủ dài cho nó, nó có thể tạo ra năm mươi đề xuất.

Vấn đề là Product Manager chỉ có hai giờ để sửa.

Nếu hệ thống đánh dấu cả năm mươi mục đều “Critical”, nó không còn là reviewer.

Nó trở thành một người đứng bên cạnh chiếc nhà đang cháy và hét:

Mọi chỗ đều nóng!

Uber xem việc ưu tiên là một phần của chính sản phẩm. Một công cụ review đánh dấu mọi thứ đều quan trọng sẽ không giúp ích nhiều; giá trị nằm ở việc chỉ ra điều gì phải sửa trước. (Uber)

Theo mình, một đầu ra tốt nên chia rất rõ:

Phải sửa trước khi review

• Chưa có bằng chứng cho giả thuyết chính.
• Metric thành công chưa có baseline.
• Thay đổi tác động đến hệ thống thanh toán nhưng chưa có đại diện Finance tham gia.
• Chưa có guardrail cho nhóm khách hàng dễ bị ảnh hưởng.

Nên cải thiện

• Bổ sung sơ đồ user flow.
• Viết rõ phạm vi phiên bản đầu tiên.
• Thêm giải thích cho một số thuật ngữ.
• Liên kết tài liệu thử nghiệm cũ.

Hai nhóm này khác nhau như “nhà chưa có móng” và “màu rèm cửa chưa đẹp”.

Không nên trộn chung.

AI không thay người review cuối cùng

Uber nói rất rõ rằng PRD Evaluator không nhằm đưa ra quyết định phê duyệt cuối cùng hay thay thế chuyên gia lĩnh vực. Công cụ có giá trị nhất khi nó làm tài liệu mạnh hơn trước khi tài liệu tới tay con người. (Uber)

Đây có lẽ là phần quan trọng nhất của cả câu chuyện.

AI không ngồi ghế chủ tọa.

Nó đứng ở ngoài cửa.

Nó kiểm tra xem người bước vào đã mang đủ giấy tờ chưa.

Quyết định có xây tính năng hay không vẫn cần:

• hiểu biết về khách hàng,
• chiến lược của doanh nghiệp,
• khẩu vị rủi ro,
• trách nhiệm pháp lý,
• kinh nghiệm vận hành,
• và đôi khi là trực giác của những người đã ăn ngủ với sản phẩm nhiều năm.

Những thứ này không phải lúc nào cũng nằm trong tài liệu.

Có những quyết định đúng nhưng dữ liệu chưa đủ.

Có những quyết định nhìn rất đẹp trên dashboard nhưng đi ngược giá trị của doanh nghiệp.

Có những rủi ro nhỏ về xác suất nhưng quá lớn về hậu quả nên không thể giao hoàn toàn cho máy.

AI có thể làm sáng căn phòng.

Nhưng con người vẫn phải quyết định sẽ đi về hướng nào.

Nếu tự xây một AI PRD Reviewer, mình sẽ bắt đầu như thế nào?

Không cần bắt đầu bằng một hệ thống agent phức tạp có mười hai con AI chạy vòng quanh.

Phiên bản đầu tiên có thể rất đơn giản.

 1PRD
 2 │
 3 ▼
 4Thu thập tài liệu liên quan
 5 │
 6 ▼
 7Phân loại loại thay đổi và mức rủi ro
 8 │
 9 ▼
10Đánh giá theo framework cố định
11 │
12 ▼
13Trích dẫn bằng chứng
14 │
15 ▼
16Ưu tiên vấn đề cần sửa
17 │
18 ▼
19Tạo scorecard

1. Xây một framework trước khi chọn model

Hãy ngồi với Product Lead, Engineering, QA, Data, Legal và Operations.

Hỏi họ:

Khi review PRD, anh chị thường tìm điều gì?

Những thiếu sót nào từng gây rework lớn?

Điều gì bắt buộc phải có trước khi tài liệu được đưa vào checkpoint?

Sau đó biến câu trả lời thành rubric.

Ví dụ:

• Problem definition
• Evidence
• Scope
• User segments
• Edge cases
• Metrics
• Guardrails
• Dependencies
• Operational impact
• Legal and policy risk
• Rollout plan
• Rollback plan

Nếu chưa có framework mà đã chọn model, hệ thống sẽ nói rất nhiều nhưng không ai biết nó đang nói theo tiêu chuẩn nào.

2. Kết nối đúng nguồn dữ liệu

AI cần tìm được:

• PRD liên quan,
• tài liệu cũ,
• dashboard metric,
• kết quả thử nghiệm,
• biên bản quyết định,
• dependency map,
• chính sách và quy trình.

Nhưng cần giữ nguyên quyền truy cập.

Một Product Manager không có quyền xem tài liệu lương thì AI của họ cũng không được phép lục vào đó chỉ vì “có thể liên quan”.

Đừng biến AI thành bác bảo vệ được phát chìa khóa tổng của cả tòa nhà.

3. Bắt buộc trích dẫn bằng chứng

Mỗi nhận xét quan trọng nên trả lời được:

Anh dựa vào đâu để nói vậy?

Nếu AI nói:

Một thử nghiệm tương tự trước đây không hiệu quả.

Nó phải dẫn tới tài liệu hoặc dashboard cụ thể.

Nếu không có bằng chứng, nó phải ghi rõ đây là câu hỏi cần kiểm chứng, không phải một sự thật.

4. Giới hạn số vấn đề quan trọng

Ví dụ chỉ cho phép tối đa:

• 3 critical gaps,
• 5 important improvements,
• và một danh sách nhỏ các chỉnh sửa không bắt buộc.

Giới hạn này buộc AI phải lựa chọn.

Mà lựa chọn mới tạo ra giá trị.

5. Ghi nhận phản hồi của người dùng

Product Manager cần có thể đánh dấu:

• Nhận xét hữu ích
• Không liên quan
• Sai ngữ cảnh
• Đã có trong tài liệu
• Cần thêm bằng chứng

Sau một thời gian, chính những phản hồi này sẽ giúp cải thiện framework, retrieval và prompt tốt hơn nhiều so với việc chỉ đổi sang model lớn hơn.

Đo thành công bằng chất lượng cuộc họp, không phải số lượng comment

Đây là điểm thứ ba mình tâm đắc từ bài viết của Uber.

Họ nhận thấy dấu hiệu mạnh nhất cho thấy công cụ hoạt động không phải là AI tạo ra nhiều nhận xét hơn, mà là những cuộc thảo luận review sau đó trở nên sắc bén và nhanh hơn. (Uber)

Điều này thay đổi hoàn toàn cách đo sản phẩm.

Một AI PRD Reviewer không nên khoe:

Tháng này chúng tôi tạo ra 18.000 comment.

Số comment nhiều có thể chỉ chứng minh AI nói nhiều.

Những metric có ý nghĩa hơn có thể là:

• Tỷ lệ critical gap được phát hiện trước checkpoint
• Thời gian từ bản nháp đầu tiên tới bản review-ready
• Số vòng sửa PRD
• Thời gian cuộc họp dành cho việc tìm ngữ cảnh
• Tỷ lệ nhận xét được PM đánh giá là hữu ích
• Tỷ lệ bằng chứng được trích dẫn chính xác
• Số dependency quan trọng được phát hiện sớm
• Mức giảm rework sau khi engineering bắt đầu

Mục tiêu cuối cùng không phải tạo ra một AI có vẻ thông minh.

Mục tiêu là làm cho con người đưa ra quyết định tốt hơn.

Những điều AI vẫn có thể làm rất tệ

Một bài về AI sẽ không đầy đủ nếu chỉ kể phần đẹp.

AI PRD Reviewer có thể gặp khá nhiều vấn đề.

Tìm nhầm tài liệu

Hai dự án có tên gần giống nhau.

AI lấy kết quả của dự án A để phản biện dự án B.

Một câu trả lời trông rất thuyết phục nhưng đặt trên nền đất sai.

Tin tài liệu cũ hơn tài liệu mới

Một chính sách ba năm trước có thể đã hết hiệu lực.

Nếu chỉ search theo độ tương đồng mà không quan tâm thời gian và trạng thái tài liệu, AI sẽ đào xác một quyết định cũ lên rồi bắt cả nhóm tranh luận lại.

Chấm điểm giả chính xác

PRD được 7,6/10 nghe rất khoa học.

Nhưng 7,6 khác 7,4 ở đâu?

Nếu không giải thích được, con số đó chỉ là lớp sơn toán học phủ lên một nhận định chủ quan.

Khuyến khích viết để qua bài

Khi mọi người biết AI dùng một rubric cố định, họ có thể học cách viết đủ từ khóa để được điểm cao mà không thực sự suy nghĩ sâu.

Giống học sinh học thuộc văn mẫu.

Bài rất tròn trịa.

Nhưng không có ý tưởng.

Làm mọi PRD trở nên giống nhau

Nếu quá phụ thuộc vào replacement text, tài liệu của cả tổ chức có thể dần mang cùng một giọng máy móc.

Rõ ràng hơn.

Nhưng vô hồn hơn.

Vì vậy AI nên giúp người viết nhìn thấy khoảng trống, chứ không nên chiếm luôn cây bút.

Điều mình tâm đắc nhất: AI nên đứng ở nơi có chi phí sai lầm còn thấp

Chúng ta thường thích đưa AI vào phần hào nhoáng nhất.

Cho AI tự ra quyết định.

Tự phê duyệt.

Tự chạy chiến dịch.

Tự gửi hàng nghìn email.

Tự sửa production.

Nhưng có lẽ vị trí phù hợp nhất của AI trong giai đoạn đầu lại nằm sớm hơn rất nhiều.

Trước khi quyết định được ký.

Trước khi code được viết.

Trước khi ngân sách được tiêu.

Trước khi một giả định mơ hồ được đúc thành bê tông.

Ở giai đoạn PRD, sai lầm vẫn còn mềm.

Nó chỉ là vài dòng chữ.

Có thể sửa trong mười phút.

Khi nó đi qua thiết kế, engineering, QA, vận hành và phát hành, sai lầm đó bắt đầu cứng lại.

Nó trở thành database schema.

API contract.

Mobile app.

Quy trình cửa hàng.

Hợp đồng đối tác.

Thói quen người dùng.

Lúc đó, muốn sửa một câu đã hiểu sai, chúng ta phải kéo ngược cả một đoàn tàu.

Đây là lý do mình cho rằng AI reviewer là một ứng dụng rất thực tế.

Không phải vì AI giỏi hơn con người.

Mà vì nó được đặt đúng chỗ.

Nơi một câu hỏi ngớ ngẩn hôm nay có thể ngăn hàng tháng rework vào ngày mai.

Tổng kết

Bài học lớn nhất mình rút ra không phải là cách Uber dùng LLM để chấm PRD.

Mà là cách họ đặt AI vào quy trình.

AI không thay Product Manager.

Không thay Product Lead.

Không thay Engineering.

Không thay người phê duyệt cuối cùng.

Nó chỉ làm một việc rất cơ bản:

Đọc trước, tìm lại ngữ cảnh, soi những khoảng trống và hỏi các câu cần được hỏi sớm hơn.

Nghe thì có vẻ đơn giản.

Nhưng phần mềm hiếm khi thất bại vì thiếu thêm một mô hình thật lớn.

Nó thường thất bại vì một giả định nhỏ không ai hỏi lại.

Một metric không ai định nghĩa.

Một dependency không ai nhớ tới.

Một trường hợp biên bị xem là “chắc không xảy ra đâu”.

Một yêu cầu sai được chuyền từ người này sang người khác, rồi được hàng trăm con người rất giỏi biến thành một hệ thống hoàn chỉnh.

Đó là nghịch lý đáng sợ nhất.

Code có thể đúng.

Test có thể xanh.

Server có thể khỏe.

Dashboard có thể đẹp.

Nhưng nếu câu hỏi ban đầu sai, toàn bộ cỗ máy chỉ đang chạy thật nhanh về phía không ai muốn tới.

Vì vậy, có lẽ tương lai gần của AI trong phát triển sản phẩm không phải là một ông sếp máy móc ngồi phê duyệt mọi thứ.

Nó giống một người phản biện đầu tiên hơn.

Một người không biết mệt.

Không ngại lục lại tủ hồ sơ.

Không xấu hổ khi hỏi những câu tưởng như ngớ ngẩn.

Và quan trọng nhất, nó hỏi khi sai lầm vẫn còn là một dòng chữ có thể xóa đi, chưa kịp biến thành hàng nghìn dòng code được viết hoàn toàn đúng.

Tham khảo

• Uber Engineering – Lessons from Building a First-Pass AI PRD Reviewer at Uber, Lakshmi Ashok, ngày 12/05/2026. (Uber)