Tổng Hợp: Ráp Một AI-Native Flow Hoàn Chỉnh Qua 8 Bước Checklist
Ráp 9 lesson trước thành checklist 8 bước duy nhất, chạy thử trên LeaseReader để thấy các quyết định ràng buộc lẫn nhau theo đúng thứ tự.
Tổng Hợp: Ráp Một AI-Native Flow Hoàn Chỉnh Qua 8 Bước Checklist
Chín lesson vừa qua tách riêng từng quyết định - confidence, latency, error state, human-in-loop, steerability, explainability, onboarding, prototyping. Trong một sản phẩm thật, chúng không đứng riêng lẻ: chọn một cái sẽ kéo theo ràng buộc cho những cái khác. Lesson cuối này không dạy khái niệm mới - nó là checklist ráp lại thành một quy trình thiết kế, và một ví dụ chạy hết checklist đó trên một flow hoàn chỉnh.
1. Checklist 8 bước - áp cho bất kỳ AI feature nào, theo đúng thứ tự đã học
- Xác định trục nào của output sẽ biến thiên (Lesson 27) - hình dạng, thời gian, hay độ chắc chắn? Trục nào không biến thiên thì bỏ qua, không cần thiết kế thừa.
- Input mở tới đâu, và discoverability xử lý ra sao (Lesson 28) - nếu input vẫn là form cứng thì bỏ qua bước này.
- Ngưỡng confidence và hành vi tương ứng (Lesson 29) - bao nhiêu tầng, mỗi tầng làm gì khác nhau.
- Latency dự kiến và kỹ thuật che/giảm chờ (Lesson 30) - nếu tác vụ luôn nhanh (dưới 1-2s) thì spinner tĩnh là đủ.
- 3 loại failure xử lý ra sao (Lesson 31), và human-in-the-loop ở điểm dừng nào theo Cost of Failure (Lesson 32) - hai bước này luôn đi cùng nhau vì fallback plan chính là nơi con người bước vào.
- Steerability cần tới đâu, explainability cần tới đâu (Lesson 33, 34) - tỉ lệ theo độ phức tạp output và Cost of Failure, không mặc định bật hết.
- Onboarding tại điểm tương tác (Lesson 35) - nếu bước 2 mở input tự do, bước này bắt buộc phải có.
- Chọn kỹ thuật prototype đúng câu hỏi cần trả lời trước khi build thật (Lesson 36).
Thứ tự này không tùy ý - bước 1-2 định hình loại vấn đề sản phẩm sẽ gặp, bước 3-6 là phản ứng với vấn đề đó, bước 7 là dạy user sống chung với thiết kế đã chọn, bước 8 là cách test rẻ trước khi commit build.
Checklist 8 Bước: Ráp Một AI-Native Flow Hoàn Chỉnh
Thứ tự không tùy ý - bước 1-2 định hình vấn đề, bước 3-6 là phản ứng, bước 7 dạy user, bước 8 test rẻ.
2. Ví dụ chạy hết checklist: LeaseReader (đã dùng ở Lesson 29)
Công cụ AI trả lời câu hỏi về hợp đồng thuê nhà, giờ ráp đầy đủ:
| Bước | Quyết định cho LeaseReader |
|---|---|
| 1. Trục biến thiên | Chủ yếu confidence (câu trả lời có thể rõ ràng hoặc mơ hồ tùy hợp đồng), độ dài ít biến thiên (luôn 1-3 câu) |
| 2. Input | Vẫn mở (câu hỏi tự do), nhưng phạm vi hẹp (chỉ hỏi về hợp đồng) nên discoverability nhẹ |
| 3. Confidence | 3 tầng như đã thiết kế ở Lesson 29 |
| 4. Latency | Tác vụ nhanh (dưới 3s vì chỉ tra cứu, không suy luận nhiều bước) → skeleton state là đủ, không cần streaming |
| 5+6. Failure & HITL | Cost of Failure trung bình (hiểu sai điều khoản thuê nhà có thể gây tranh chấp thật) → mức (b) execute + easy undo: trả lời ngay nhưng luôn kèm nút "Xem đoạn gốc" để tự verify, không chặn review từng câu |
| 7. Steerability/explainability | Explainability dạng (a) citation là bắt buộc (trỏ đúng đoạn hợp đồng); steerability không cần vì output ngắn, không có gì để "chỉnh riêng từng phần" |
| 8. Onboarding | 3 chip câu hỏi mẫu ("Tôi có được nuôi thú cưng không?", "Ai chịu phí sửa chữa?"...) ngay dưới ô input |
| 9. Prototype | Bắt đầu bằng (b) mock response - cố định vài cặp câu hỏi/trả lời mẫu để test riêng UI 3 tầng confidence, trước khi nối RAG thật vào |
3. Các quyết định ràng buộc lẫn nhau - lý do checklist phải chạy đúng thứ tự
Nhìn bảng trên sẽ thấy các quyết định ràng buộc lẫn nhau: vì latency thấp (bước 4) nên không cần streaming; vì Cost of Failure trung bình chứ không cao (bước 5) nên không cần review-before-execute; vì output ngắn (bước 1) nên bỏ hẳn steerability. Đây chính là lý do checklist phải chạy theo thứ tự - chạy bước 6 (steerability) trước khi biết bước 1 (output có nhiều phần hay không) sẽ dẫn tới thiết kế thừa.
Bài tập cuối module: Chọn 1 trong các case đã dùng xuyên suốt module - HireFlow, InvoiceBot, ShiftPlanner, PitchCraft, hoặc BudgetAdvisor - và chạy hết 8 bước checklist trên thành một bảng giống LeaseReader ở trên. Đầu ra là bản thiết kế đủ chi tiết để chuyển thẳng cho engineer/designer dựng prototype - đúng tinh thần "kết thúc module = demo chạy được".