Làm việc với Reasoning Model và khoá chặt Output Format
Mô tả Definition of Done cho Reasoning Model thế hệ mới thay vì ép step-by-step, và khoá chặt cấu trúc Output để triệt tiêu biến thiên định dạng.
Làm việc với Reasoning Model và khoá chặt Output Format
Sau khi đã định hình ngữ cảnh và cấu trúc ở các bài trước, bài này tập trung vào tầng kiểm soát thực thi: cách làm việc với các thế hệ Reasoning Model, và kỹ thuật khoá chặt cấu trúc Output để triệt tiêu biến thiên.
Ví dụ xuyên suốt bài: Product Manager của FreelanceFlow cần dùng AI để ước lượng độ phức tạp tính năng cho Sprint Planning, và để soạn thảo bản báo cáo Weekly Update định kỳ gửi cho CPO/CEO.
Mô hình cũ: Ép step-by-step
Mô hình chuẩn: Định nghĩa DoD + khoá format
1. Mô tả định nghĩa hoàn thành thay vì ép buộc chuỗi suy luận từng bước
Sự xuất hiện của các mô hình suy luận chuyên sâu (Reasoning Models như OpenAI o-series, Gemini Thinking, Claude Extended Thinking, DeepSeek R1) đòi hỏi PM phải thay đổi thói quen viết prompt. Các mô hình này được huấn luyện để tự sinh chuỗi suy luận nội tại (internal chain-of-thought) trước khi đưa ra câu trả lời cuối cùng.
Sai lầm nghiêm trọng nhất là việc máy móc chèn thêm câu lệnh "Hãy suy nghĩ từng bước một: Bước 1 làm X, Bước 2 làm Y..." cho các tác vụ phân tích. Hành vi này:
- Làm gián đoạn chiến lược suy luận tối ưu tự nhiên của mô hình.
- Làm phình to độ dài output không cần thiết, tăng latency và chi phí token.
- Có thể khiến mô hình sa vào các bước suy luận thừa thãi thay vì tập trung giải quyết bài toán cốt lõi.
Quy tắc tối ưu: Thay vì chỉ đạo cách suy luận, hãy tập trung mô tả chính xác Định nghĩa Hoàn thành (Definition of Done - DoD) của câu trả lời. Hãy để mô hình tự quyết định độ sâu suy luận cần thiết.
Ví dụ đối chiếu: Ước tính effort kỹ thuật tính năng "Tự động phân bổ hoá đơn vào danh mục chi phí" cho FreelanceFlow:
- Cách tiếp cận sai (Ép buộc quy trình): "Hãy suy nghĩ từng bước thật kỹ: Bước 1 phân tích các API ngân hàng cần gọi, Bước 2 liệt kê các rủi ro bảo mật, Bước 3 ước tính số story points cho backend, Bước 4 ước tính cho mobile app..."
- Cách tiếp cận đúng (Mô tả DoD): "Ước tính nỗ lực kỹ thuật (số ngày công kỹ sư) để xây dựng tính năng phân bổ hoá đơn tự động, xét trong bối cảnh hệ thống hiện tại đang sử dụng microservices Node.js và PostgreSQL. Đầu ra yêu cầu: 1 con số ước lượng tổng, phân rã theo 3 rủi ro kỹ thuật lớn nhất và 1 phương án giảm thiểu."
Ngoại lệ: Chỉ yêu cầu xuất tường minh từng bước tính toán khi chính các bước đó là sản phẩm bàn giao cần audit (ví dụ: giải trình công thức tính thuế hoặc đối chiếu dòng tiền phục vụ kiểm toán tài chính).
Làm chủ Output, giải thích ràng buộc và làm việc với Reasoning Model
So sánh giữa việc ép buộc từng bước suy nghĩ (Forced CoT) vs. thiết lập Tiêu chuẩn Hoàn thành (DoD).
## Tiêu chuẩn nghiệm thu (Definition of Done):
1. Báo cáo tài chính phải cân bằng: Tổng thu - Tổng chi = Số dư cuối kỳ.
2. Phân loại thuế TNCN theo biểu luỹ tiến 5 bậc hiện hành.
3. Cảnh báo đỏ nếu khoản phải thu quá hạn > 30 ngày.
-> Mô hình tự do phân nhánh logic để thoả mãn toàn bộ tiêu chí.
Khám phá không gian trạng thái: Model thử nghiệm nhiều hướng giải, tự backtracking khi phát hiện vi phạm DoD.
Hiệu quả sử dụng Token: 100% token suy luận tập trung vào việc thoả mãn ràng buộc sản phẩm.
Bài tập 3.1: Một PM viết prompt sau để phân tích feedback người dùng:
"Hãy suy nghĩ từng bước: Bước 1 đọc toàn bộ 30 phản hồi, Bước 2 phân loại tích cực/tiêu cực, Bước 3 đếm số lượng mỗi nhóm, Bước 4 tìm các từ khoá phổ biến nhất, Bước 5 viết kết luận."
Hãy viết lại prompt trên theo nguyên tắc Reasoning-Friendly: loại bỏ việc ép buộc quy trình, thay bằng bản mô tả định nghĩa hoàn thành rõ ràng về cấu trúc và chất lượng insight.
2. Khoá chặt cấu trúc đầu ra để triệt tiêu biến thiên định dạng
Mô hình ngôn ngữ có xu hướng tạo ra định dạng ngẫu nhiên nếu không được chỉ định cụ thể. Cùng một câu hỏi "Hãy tóm tắt cuộc họp", lần chạy thứ nhất có thể trả về một đoạn văn xuôi dài 500 từ, lần thứ hai trả về 3 gạch đầu dòng, lần thứ ba lại tạo một bảng biểu.
Việc khoá chặt Output Format giúp loại bỏ hoàn toàn một trục biến thiên (Variance Axis), cho phép mô hình dành toàn bộ năng lực Attention vào việc tinh chỉnh chất lượng nội dung.
Ví dụ: Soạn thảo Weekly Update gửi Leadership của FreelanceFlow:
## Output format
Bắt buộc trình bày theo đúng 3 khối Markdown sau:
### 1. Highlight Tuần (Tối đa 3 gạch đầu dòng, mỗi dòng kèm 1 metric định lượng)
### 2. Blocker & Rủi Ro (Tên rủi ro - Mức độ ảnh hưởng P1/P2 - Phương án xử lý)
### 3. Ưu Tiên Tuần Tới (Đúng 2 mục tiêu có thể nghiệm thu)Lợi ích kép: Định dạng rõ ràng không chỉ giúp AI trả lời chuẩn xác mà còn buộc chính PM phải tư duy tường minh về nhu cầu thông tin thực sự của các bên liên quan trước khi gửi prompt.
Bài tập 3.2: Viết đặc tả Output Format chuẩn xác cho prompt tóm tắt cuộc phỏng vấn người dùng sâu (User In-depth Interview) dài 45 phút của FreelanceFlow, sao cho bản tóm tắt có thể dán trực tiếp vào Notion database của team Design và Engineering mà không cần biên tập lại.