Bài 3 — Sinh release notes theo đối tượng: khách hàng, Sales/CS, lãnh đạo, nội bộ

Cùng một release, bốn câu chuyện

Một thay đổi "Thêm SSO qua Google" phải được kể khác nhau:

• Khách hàng: "Đăng nhập nhanh và an toàn bằng tài khoản Google."
• Sales/CS: "Đã hỗ trợ SSO Google — dùng để chốt các deal enterprise yêu cầu bảo mật."
• Lãnh đạo: "SSO mở khóa phân khúc enterprise; giảm rào cản onboarding."
• Nội bộ: "OAuth2 Google provider, ảnh hưởng luồng auth, cần cập nhật docs tích hợp."

Kỹ năng cốt lõi của bài này: dùng một đầu vào JSON sạch (từ Bài 2) và sinh nhiều bản theo đối tượng, giữ nhất quán về sự thật nhưng khác nhau về góc nhìn và giọng.

Nguyên tắc "một sự thật, nhiều lăng kính"

Mọi bản đều phải bắt nguồn từ cùng danh sách ticket đã kiểm chứng. Nếu bản cho lãnh đạo nói "tăng 30% chuyển đổi" mà ticket không có số đó → đó là ảo giác. Hãy ràng buộc AI: chỉ được diễn giải, không được thêm số liệu mới.

Ví dụ cụ thể + Prompt mẫu

Bạn là biên tập release notes đa đối tượng cho sản phẩm SaaS tiếng Việt.
ĐẦU VÀO (JSON đã kiểm chứng, KHÔNG được thêm thông tin ngoài danh sách này):
[
  {"key":"PROJ-812","type":"feature","summary":"Đăng nhập SSO qua Google"},
  {"key":"PROJ-799","type":"improvement","summary":"Trang báo cáo tải từ 8s xuống 1.5s"},
  {"key":"PROJ-830","type":"bugfix","summary":"Sửa nội dung tooltip sai trên dashboard"}
]
Hãy tạo 4 phiên bản release notes:
1. KHÁCH HÀNG: giọng thân thiện, nhấn lợi ích, không thuật ngữ. Có tiêu đề hấp dẫn.
2. SALES/CS: gạch đầu dòng, mỗi mục kèm "dùng để bán/hỗ trợ thế nào".
3. LÃNH ĐẠO: tối đa 4 dòng, nhấn tác động kinh doanh & rủi ro. KHÔNG bịa số liệu.
4. NỘI BỘ: chi tiết kỹ thuật, đánh dấu breaking change nếu có.
RÀNG BUỘC: mọi câu phải truy nguyên được về một key ở trên. Nếu không đủ dữ kiện
để nói điều gì, ghi "[cần xác nhận]" thay vì suy đoán.

Câu ràng buộc cuối cùng biến AI từ "người kể chuyện tự do" thành "biên tập viên có kỷ luật".

Các bước làm (numbered)

• Nạp JSON sạch từ Bài 2 làm đầu vào duy nhất.
• Khai báo rõ 4 đối tượng và tiêu chí mỗi bản (giọng, độ dài, điều nhấn).
• Thêm ràng buộc truy nguyên: mọi câu gắn với một key, cấm thêm số liệu mới.
• Sinh đồng thời 4 bản trong một lượt để giữ nhất quán.
• Đối chiếu bản khách hàng với ticket gốc — kiểm từng lợi ích có thật không.
• Rà bản lãnh đạo — chắc chắn không có con số bịa ("nhanh 5 lần" phải suy ra từ 8s→1.5s).
• Đánh dấu breaking change ở bản nội bộ và nhân đôi cảnh báo nếu có.
• Lưu 4 bản vào template để phân phối ở Bài 5–6.

Template: Khung release notes theo đối tượng (tái dùng)

## [Tên bản phát hành] — [Ngày]
### Dành cho KHÁCH HÀNG
✨ Mới: <lợi ích>
⚡ Tốt hơn: <cải tiến>
🔧 Đã sửa: <lỗi ảnh hưởng người dùng>

### Dành cho SALES/CS
- <mục> — Điểm bán/hỗ trợ: <cách dùng>

### Dành cho LÃNH ĐẠO (≤4 dòng)
- Tác động: <kinh doanh>
- Rủi ro/theo dõi: <nếu có>

### Dành cho NỘI BỘ
- <mục kỹ thuật> [breaking? có/không]

(Lưu ý theo quy tắc thương hiệu: ở giao diện sản phẩm chính thức nên thay emoji bằng icon; emoji ở đây chỉ là ký hiệu nội bộ khi soạn nháp.)

Sai lầm thường gặp

• Sinh riêng lẻ từng bản: dễ lệch sự thật giữa các bản. Sinh cùng lúc để nhất quán.
• AI phóng đại lợi ích (ảo giác): "tính năng đột phá", "nhanh nhất thị trường" — cấm tính từ không có căn cứ trong ticket.
• Bản lãnh đạo bịa số ROI: rất nguy hiểm vì lãnh đạo có thể trích dẫn ra ngoài. Bắt buộc "[cần xác nhận]".
• Rò rỉ qua bản nội bộ: đừng nhét tên khách hàng cụ thể hay chi tiết hạ tầng nhạy cảm vào bản có thể bị forward.
• Phụ thuộc quá mức: bản khách hàng là bộ mặt công ty — luôn có người đọc lại trước khi phát hành, đừng để agent tự gửi.

Điều rút ra

Một sự thật, nhiều lăng kính. Với JSON sạch + ràng buộc truy nguyên + cấm bịa số, bạn sinh được 4 bản chỉ trong một lượt và giữ được độ chính xác mà chính bạn chịu trách nhiệm.