Bài 6 — Thiết kế "Trợ lý PO" cá nhân: vai trò, công cụ, ranh giới

Vấn đề

Đến giờ bạn có nhiều prompt và vài tự động hóa rời rạc. Nhưng một "trợ lý PO" thực thụ cần được thiết kế như một vai trò: nó là ai, được làm gì, KHÔNG được làm gì, dùng công cụ nào, và khi nào phải hỏi bạn. Thiết kế rõ ranh giới chính là điều tách một agent hữu ích khỏi một agent nguy hiểm.

Bốn thành phần của một agent PO tốt

• Persona (vai trò): "Trợ lý cho PO, ưu tiên rõ ràng và ngắn gọn, luôn đánh dấu giả định, tiếng Việt."
• Tools (công cụ): đọc/ghi Jira project X, đọc lịch, đọc tài liệu sản phẩm — liệt kê rõ, không hơn.
• Guardrails (ranh giới): không đổi ưu tiên, không đóng ticket release, luôn dry-run khi ghi, không đụng dữ liệu khách hàng thật.
• Escalation (khi nào hỏi người): khi thiếu thông tin, khi hành động rủi ro cao, khi phát hiện mâu thuẫn.

Prompt mẫu: bản "hiến pháp" cho trợ lý PO (system prompt)

Bạn là "Trợ lý PO" cho Product Owner của <sản phẩm>.
NHIỆM VỤ: hỗ trợ viết/chuẩn hóa story, chuẩn bị refinement, giữ backlog sạch, tóm tắt tiến độ.
NGUYÊN TẮC:
Luôn viết tiếng Việt, ngắn gọn, có cấu trúc.
Đánh dấu [Giả định] cho mọi thông tin không được cung cấp rõ.
Không bịa số liệu, mã ticket, hay quy tắc nghiệp vụ.

ĐƯỢC PHÉP: đọc backlog project PROJ; đề xuất thay đổi; tạo bản nháp story.
KHÔNG ĐƯỢC: đổi thứ tự ưu tiên backlog; đóng/xóa ticket; sửa ticket có label "release";
           dùng hay hiển thị dữ liệu khách hàng thật.
KHI GHI VÀO JIRA: luôn in bản tóm tắt để tôi xác nhận trước (dry-run).
KHI THIẾU THÔNG TIN: dừng lại và hỏi, không tự suy diễn.

Prompt mẫu: gọi trợ lý cho một việc cụ thể

[Dùng hiến pháp Trợ lý PO ở trên]
Việc hôm nay: chuẩn bị cho refinement chiều nay. Quét PROJ, liệt kê story chưa sẵn sàng,
soạn agenda 45 phút, và nêu 3 rủi ro lớn nhất cần chốt. Nhắc tôi nếu thiếu thông tin.

Các bước thiết kế trợ lý của bạn

• Viết persona 2-3 câu phản ánh phong cách làm việc bạn muốn.
• Liệt kê danh sách công cụ tối thiểu agent cần (nguyên tắc quyền tối thiểu).
• Viết guardrails: 5-7 điều "KHÔNG được làm" rõ ràng.
• Định nghĩa các tình huống escalation (khi nào phải hỏi bạn).
• Gộp thành 1 "hiến pháp" tái dùng cho mọi phiên làm việc.
• Chạy thử với vài việc thật, chỉnh guardrails khi agent vượt ranh giới.

Template: Thẻ thiết kế Trợ lý PO

TÊN TRỢ LÝ: __________
PERSONA (2-3 câu): __________
ĐƯỢC PHÉP LÀM:
  - __________
KHÔNG ĐƯỢC LÀM (guardrails):
  - __________
CÔNG CỤ ĐƯỢC CẤP (tối thiểu):
  - __________
BẮT BUỘC HỎI NGƯỜI KHI:
  - Thiếu thông tin quan trọng
  - Hành động không hoàn tác được
  - Đụng dữ liệu nhạy cảm
ĐỊNH DẠNG OUTPUT MẶC ĐỊNH: __________

Sai lầm thường gặp

• Persona mơ hồ, guardrails yếu: Nếu không viết rõ "KHÔNG được làm", agent sẽ tự quyết những việc vượt quyền. Ranh giới càng cụ thể càng an toàn.
• Cấp công cụ theo kiểu "cho chắc": Cấp quyền ghi mọi project "phòng khi cần" là sai. Chỉ cấp đúng thứ dùng đến.
• Ảo giác vẫn xảy ra dù có hiến pháp: Ràng buộc [Giả định] giảm chứ không xóa được ảo giác. Vẫn phải kiểm chứng output quan trọng.
• Rò rỉ dữ liệu qua cấu hình: Đừng nhúng token, thông tin khách hàng, hay link tài liệu mật vào system prompt dùng chung. Tách bí mật ra khỏi cấu hình.
• Phụ thuộc quá mức: Một hiến pháp tốt khiến agent đáng tin đến mức bạn ngừng kiểm tra. Định kỳ tự làm tay một tác vụ để giữ kỹ năng và cảm nhận.

Chốt bài

Bạn đã thiết kế một Trợ lý PO có persona, công cụ, ranh giới và cơ chế escalation rõ ràng. Bài 7 sẽ đưa trợ lý này vào các tình huống thực tế trong một sprint điển hình.