Bài 2 — Chuẩn hóa nguồn dữ liệu: từ ticket lộn xộn thành đầu vào sạch cho AI

Vì sao bước này quyết định chất lượng

Có một nguyên tắc: rác vào, rác ra. Nếu bạn ném cho AI một mớ ticket thiếu mô tả, viết tắt, lẫn cả việc nội bộ, thì release notes sinh ra sẽ sai và bạn phải sửa nhiều hơn cả tự viết. 80% chất lượng release notes đến từ chất lượng đầu vào. Bài này dạy bạn cách lấy và làm sạch nguồn một cách có hệ thống để các bài sau tự động hóa được.

Ba nguồn phổ biến và cách lấy

• Jira / Linear: lọc theo sprint = current AND status = Done, export CSV các cột: Key, Type, Summary, Description, Labels, Components.
• GitHub / GitLab PR: lấy các PR đã merge vào nhánh release, dùng tiêu đề PR + nhãn (label) feature/bugfix.
• Changelog thủ công: nếu team ghi tay, chuẩn hóa mỗi dòng theo một mẫu cố định.

Ví dụ cụ thể: làm sạch một export

Export thô thường trông như:

PROJ-812,Story,Add SSO login via Google,,auth;sprint-14
PROJ-777,Task,Refactor payment module,,tech-debt
PROJ-799,Bug,Fix slow report page,report loads >8s now ~1.5s,perf

PROJ-777 là nợ kỹ thuật nội bộ — người dùng không thấy. Bạn cần AI tự lọc những mục này thay vì tự tay xóa.

Prompt mẫu: chuẩn hóa và lọc

Bạn là trợ lý chuẩn hóa dữ liệu release cho Product Owner.
Đầu vào là CSV export ticket (cột: Key, Type, Summary, Description, Labels).
Hãy:
1. Loại các mục KHÔNG ảnh hưởng người dùng cuối: refactor, tech-debt,
   CI/CD, test, chore, cập nhật thư viện nội bộ. Ghi rõ đã loại mục nào và lý do.
2. Với các mục còn lại, chuẩn hóa thành JSON:
   { "key", "type": "feature|improvement|bugfix", "raw_summary",
     "user_impact": "cao|trung bình|thấp" }
3. Nếu Description trống, đánh dấu "cần bổ sung" thay vì tự bịa nội dung.
CSV:
<dán CSV ở đây>

Lưu ý câu số 3: yêu cầu AI báo thiếu thay vì tự chế — đây là lá chắn chống ảo giác quan trọng nhất ở bước đầu vào.

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

• Đặt bộ lọc cố định trong Jira/Linear và lưu thành filter tái dùng.
• Export CSV chỉ các cột cần thiết (đừng export cả assignee, comment nội bộ).
• Ẩn danh dữ liệu nhạy cảm: thay tên khách hàng, ID hợp đồng bằng placeholder.
• Chạy prompt chuẩn hóa để lọc mục nội bộ và ra JSON sạch.
• Rà lại danh sách bị loại — đảm bảo AI không loại nhầm một tính năng thật.
• Bổ sung mô tả thiếu: với mục AI đánh dấu "cần bổ sung", hỏi dev một câu ngắn.
• Lưu JSON sạch làm đầu vào cho bước sinh release notes (Bài 3).

Template: Định nghĩa "Done for Release Notes" (checklist tái dùng)

Một ticket sẵn sàng đưa vào release notes khi:

• [ ] Có Type rõ ràng (feature / improvement / bugfix).
• [ ] Summary mô tả cái gì thay đổi, không chỉ tên module.
• [ ] Có nhãn phân loại người-dùng-thấy hay nội-bộ.
• [ ] Không chứa dữ liệu nhạy cảm (tên KH, số liệu doanh thu, secret).
• [ ] Nếu là breaking change → có nhãn breaking để cảnh báo riêng.

Dán checklist này vào Definition of Done của team để nguồn sạch từ gốc — giảm việc làm sạch thủ công mỗi sprint.

Sai lầm thường gặp

• Export cả comment và trường nội bộ: dễ vô tình đưa thông tin nhạy cảm (tên khách hàng phàn nàn, ước lượng doanh thu) vào công cụ AI công cộng — nguy cơ rò rỉ dữ liệu.
• Để AI tự bịa mô tả cho ticket trống: nó sẽ ảo giác một tính năng nghe hợp lý nhưng không tồn tại. Luôn dùng cơ chế "cần bổ sung".
• Lọc quá tay: đôi khi một "cải tiến hiệu năng" là điểm bán hàng lớn với khách. Đừng để AL loại hết bugfix; hãy rà lại danh sách bị loại.
• Chuẩn hóa một lần rồi thôi: nguồn thay đổi theo team. Xem lại prompt lọc mỗi quý.
• Phụ thuộc quá mức vào phân loại của AI: phân loại type sai sẽ kéo theo giọng văn sai ở bước sau. Kiểm mẫu 10% trước khi tin toàn bộ.

Điều rút ra

Đầu vào sạch = release notes tốt. Hãy chuẩn hóa nguồn thành JSON có cấu trúc, để AI lọc và gắn nhãn thay vì bạn làm tay, và luôn giữ cơ chế "báo thiếu" để chặn ảo giác ngay từ cửa ngõ.