Mẫu ghi chú phát hành

Mẫu ghi chú phát hành này trình bày 11 mục mà một đội ngũ phát hành cần để cho người dùng biết điều gì đã thay đổi. Sao chép toàn bộ cấu trúc mà không cần đăng ký, hoặc tải về dưới dạng PDF.

Mẫu ghi chú phát hành (sẵn sàng sao chép và dán)

Khối bên dưới là toàn bộ mẫu, có thể sao chép ngay lập tức, không cần đăng ký hay nhập email. Nó dán nguyên vẹn vào Word, Google Docs, Confluence, Notion hoặc một tệp Markdown, và bản PDF cũng giữ đủ 11 mục nếu bạn muốn in ra. Thay thế các gợi ý trong dấu ngoặc vuông, sau đó xóa những mục mà bản phát hành này không liên quan.

[Tên sản phẩm] Ghi chú phát hành
Phiên bản: [x.y.z]
Ngày phát hành: [YYYY-MM-DD]
Nền tảng / môi trường: [web, iOS, Android, API, staging]

Tóm tắt thay đổi (Mục đích)
[Một hoặc hai câu: bản phát hành này giải quyết điều gì và ảnh hưởng đến ai]

Tính năng mới
- [Người dùng giờ đây có thể làm gì, không phải tên tính năng nội bộ]

Cải tiến và nâng cấp (Cải thiện hiệu năng)
- [Điều gì đã tồn tại từ trước, và điều gì tốt hơn từ góc nhìn người dùng]

Sửa lỗi
- Đã sửa: [người dùng đã gặp gì trước đây, và điều gì xảy ra bây giờ]

Thay đổi phá vỡ và các bước di chuyển
- [Điều gì ngừng hoạt động], nên [bạn phải thay đổi gì, và trước thời hạn nào]

Vấn đề đã biết và giải pháp tạm thời (Vấn đề đang tồn tại)
- [Vấn đề chưa xử lý] · [nền tảng bị ảnh hưởng] · [giải pháp tạm thời] · [thời hạn khắc phục]

Các bước nâng cấp hoặc cài đặt (Bước nâng cấp / Ghi chú cài đặt)
1. [Người đọc phải làm gì để lên phiên bản mới]

Tính năng ngừng hỗ trợ
- [Tính năng, tích hợp hoặc API] sẽ ngừng hỗ trợ vào [ngày]. [Cần chuyển sang gì]

Ghi chú bảo mật
- [Thay đổi liên quan đến bảo mật, nêu ra mà không mô tả lỗ hổng]

Nơi nhận trợ giúp và gửi phản hồi
- Tài liệu: [liên kết] · Hỗ trợ: [email hoặc kênh] · Phản hồi: [liên kết]

Những gì có trong một mẫu ghi chú phát hành

Một mẫu ghi chú phát hành có mười một mục, mỗi mục có một nhiệm vụ riêng. Hãy viết từng mục cho đúng người sẽ đọc nó: nhà phát triển và khách hàng cần những thông tin khác nhau.

Cách sử dụng mẫu ghi chú phát hành

1. Sao chép mẫu vào nơi bản phát hành của bạn đã tồn tại. Nó dán nguyên vẹn vào Jira, Confluence, Notion, GitHub hoặc Azure DevOps, để ghi chú nằm ngay cạnh phần công việc thay vì lạc trong một tài liệu riêng lẻ.
2. Điền dòng tiêu đề trước tiên. Tên sản phẩm, số phiên bản, ngày phát hành và nền tảng, để bất kỳ ai đọc đến ghi chú cũng biết ngay bản build nào đang được mô tả trước khi đọc thêm một chữ nào.
3. Thu thập nhật ký phát hành rồi sắp xếp theo những gì người dùng nhìn thấy. Chia mỗi thay đổi thành tính năng mới, cải tiến, sửa lỗi và bất kỳ điều gì gây gián đoạn, rồi bỏ những mục mà người dùng không nhìn thấy.
4. Viết mỗi mục theo khả năng mang lại, không phải theo cách triển khai. "Đã triển khai xử lý theo lô" trở thành "Bạn giờ đây có thể xuất tập dữ liệu lớn mà không lo tiến trình bị hết thời gian chờ", câu này trả lời ngay câu hỏi của người đọc rằng bản phát hành này có ảnh hưởng đến họ hay không.
5. Thêm ảnh chụp màn hình hoặc một GIF ngắn ở bất kỳ đâu giao diện thay đổi. Nếu một mục cần đến ba đoạn văn để giải thích, có lẽ nó cần một GIF mười lăm giây thay vì thế.
6. Xóa những mục mà bản phát hành này không liên quan và giữ nguyên thứ tự phần còn lại. Một bản vá sẽ bỏ mục tính năng mới và các bước nâng cấp, và người dùng không nên phải học lại cấu trúc ở mỗi lần phát hành.
7. Giao bản nháp cho một người phụ trách được chỉ định, rồi xuất bản. Nếu không có một người chịu trách nhiệm rõ ràng cho việc phê duyệt, ghi chú sẽ ra muộn hoặc bị phát hành hai lần.

Mẫu ghi chú phát hành: một ví dụ đã điền đầy đủ

Đây là cùng một mẫu, được điền cho một sản phẩm điều phối hư cấu đang phát hành một bản cập nhật tính năng.

• Fieldpost 4.2.0 · Ngày phát hành: 12 tháng 3, 2026 · Nền tảng: Web và iOS
• Tóm tắt thay đổi: Việc xuất dữ liệu giờ đây hoàn tất trên các tài khoản lớn, giá tại Canada đã chính xác, và các quản trị viên tự lưu trữ có một bước di chuyển cần thực hiện.
• Tính năng mới
• Xuất dữ liệu theo lịch. Bạn giờ đây có thể đặt một báo cáo chạy vào mỗi thứ Hai và gửi thẳng đến hộp thư của bạn.
• Cập nhật trạng thái hàng loạt. Chọn tối đa 500 công việc và thay đổi trạng thái của chúng trong một lần thao tác.
• Cải tiến và nâng cấp
• Bảng điều phối nhanh hơn. Bảng tải trong khoảng hai giây trên các tài khoản có 10.000 công việc đang mở, giảm từ chín giây.
• Sửa lỗi
• Đã sửa: việc xuất dữ liệu trên 50.000 dòng bị hết thời gian chờ và trả về tệp rỗng.
• Đã sửa: giá hiển thị bằng USD đối với các tài khoản tại Canada.
• Thay đổi phá vỡ và các bước di chuyển
• Phiên bản 4.2.0 gỡ bỏ endpoint /exports v1. Trỏ các tích hợp của bạn sang /v2/exports, endpoint này trả về một job ID. Các bản cài đặt tự lưu trữ chạy fieldpost migrate --v2-exports trước khi khởi động phiên bản 4.2.0.
• Vấn đề đã biết và giải pháp tạm thời
• Trên iOS, các lần xuất dữ liệu đặt lịch cho Chủ nhật lại chạy vào thứ Hai. Hãy dùng ứng dụng web cho đến khi phiên bản 4.2.1 phát hành vào ngày 26 tháng 3.
• Các bước nâng cấp hoặc cài đặt
• Các tài khoản trên cloud đã ở phiên bản 4.2.0. Người dùng iOS cập nhật từ App Store trước ngày 31 tháng 3.
• Tính năng ngừng hỗ trợ
• Fieldpost ngừng hỗ trợ định dạng báo cáo chỉ dùng CSV vào ngày 1 tháng 9, 2026. Hãy chuyển các báo cáo đã lưu sang XLSX.
• Ghi chú bảo mật
• Token phiên làm việc giờ đây hết hạn sau 12 giờ, và quản trị viên có thể kết thúc phiên làm việc của người dùng khác.
• Nơi nhận trợ giúp và gửi phản hồi
• Tài liệu: docs.fieldpost.example · Hỗ trợ: support@fieldpost.example · Phản hồi: tab Feedback trong ứng dụng.

Các biến thể của mẫu ghi chú phát hành

Năm biến thể dưới đây nằm trên hai trục: ai đọc ghi chú, và bản phát hành thuộc loại nào. Mỗi biến thể giữ nguyên dòng tiêu đề và tóm tắt thay đổi, sau đó thêm, bỏ hoặc viết lại chín mục còn lại. Phần chênh lệch mới là phần hữu ích, vì quyết định nên bỏ gì cho một bản phát hành nhỏ là điều mà hầu hết các đội thường làm sai.

Mẫu ghi chú phát hành cho bản phát hành lớn

Biến thể này chạy đủ cả 11 mục. Mỗi tính năng mới có một đoạn văn kèm ảnh chụp màn hình hoặc GIF, bạn nêu rõ từng bước di chuyển thay vì chỉ dẫn liên kết, và bạn viết tóm tắt thay đổi sao cho đứng độc lập được, vì đây chính là dòng mà đồng nghiệp sẽ dán vào Slack và trích lại với bạn.

• Giữ lại: đủ cả 11 mục.
• Mở rộng: tính năng mới, thay đổi phá vỡ và các bước di chuyển, các bước nâng cấp.
• Lưu ý: tóm tắt phải có nghĩa dù không đi kèm mục nào khác.

Mẫu ghi chú phát hành cho bản vá hoặc hotfix

Bốn mục làm phần lớn công việc: dòng tiêu đề, tóm tắt, sửa lỗi, và vấn đề đã biết nếu còn tồn tại. Mở đầu bằng bản sửa, sau đó là ai bị ảnh hưởng, rồi đến việc người đọc có phải làm gì hay không. Một ghi chú hotfix mở đầu bằng số phiên bản và giấu bản sửa ở đoạn thứ ba làm mất hết ý nghĩa của việc phát hành nhanh.

• Bỏ: tính năng mới, cải tiến, tính năng ngừng hỗ trợ, các bước nâng cấp.
• Giữ lại: dòng tiêu đề, tóm tắt, sửa lỗi, vấn đề đã biết.
• Lưu ý: nêu rõ ràng khi không cần hành động gì.

Mẫu ghi chú phát hành nội bộ hoặc kỹ thuật

Bạn viết biến thể này cho đội ngũ vận hành hệ thống, nên phần khung lợi ích biến mất và phần cơ chế xuất hiện. Nêu tên các dịch vụ bị ảnh hưởng, cấu hình đã thay đổi, và bất kỳ điều gì đồng nghiệp có thể gặp phải lúc 2 giờ sáng.

• Thêm: thay đổi mã nguồn, thay đổi API và cơ sở dữ liệu, ghi chú về môi trường và cấu hình.
• Bỏ: cách trình bày lợi ích hướng đến người dùng.
• Giữ lại: thay đổi phá vỡ, vấn đề đã biết, các bước nâng cấp, những mục này mang trọng lượng lớn hơn trong biến thể này so với các biến thể khác.

Mẫu ghi chú phát hành cho App Store trên di động

Các cửa hàng ứng dụng giới hạn số ký tự, nên toàn bộ ghi chú được nén lại thành một dòng phiên bản và một danh sách "có gì mới" ngắn gọn. Viết ba đến năm gạch đầu dòng, mỗi dòng nêu một điều người dùng giờ đây có thể làm, sắp xếp theo mức độ họ quan tâm nhất.

• Giữ lại: dòng tiêu đề, danh sách tính năng mới đã rút gọn, một dòng cho các bản sửa đáng chú ý.
• Bỏ: vấn đề đã biết, tính năng ngừng hỗ trợ, ghi chú bảo mật, các bước di chuyển.
• Lưu ý: bất kỳ điều gì bị cắt khỏi danh sách trên cửa hàng vẫn nên có mặt trong ghi chú đầy đủ mà bạn tự lưu trữ.

Mẫu ghi chú phát hành cho API

Bạn viết biến thể này cho một nhà phát triển đang tích hợp với sản phẩm của bạn, chứ không phải cho người dùng cuối. Mỗi mục nêu tên endpoint hoặc tham số mà nó tác động đến, và mỗi tính năng ngừng hỗ trợ đi kèm một ngày kết thúc mà người đọc có thể ghi vào lịch.

• Thêm: thay đổi endpoint, thay đổi tham số, một ví dụ di chuyển kèm request và response.
• Mở rộng: tính năng ngừng hỗ trợ, kèm ngày kết thúc, và thay đổi phá vỡ.
• Bỏ: ảnh chụp màn hình và GIF, những thứ mà một nhà phát triển đọc không cần đến.

Một bản vá bảo mật dùng bất kỳ biến thể nào phù hợp với bản phát hành, kèm theo một quy tắc bổ sung: giữ ghi chú bảo mật khách quan và không mô tả bản thân lỗ hổng.

Khi nào nên dùng mẫu ghi chú phát hành

Hãy dùng mẫu này cho bất kỳ bản phát hành nào mà người dùng có thể nhìn thấy hoặc phải hành động theo. Ba tình huống phổ biến nhất là ra mắt tính năng, sửa lỗi hoặc hotfix, và một bản build nội bộ. Các bản vá bảo mật, bản phát hành API và cập nhật trên cửa hàng ứng dụng đều dùng cùng cấu trúc với các mục khác nhau được sử dụng.

Ghi chú phát hành, nhật ký thay đổi và ghi chú bản vá trả lời những câu hỏi khác nhau. Ghi chú phát hành là theo từng lần phát hành và dễ đọc với con người, viết cho đối tượng chịu ảnh hưởng bởi thay đổi. Nhật ký thay đổi là bản ghi đầy đủ theo trình tự thời gian, hướng đến nhà phát triển và tồn tại lâu dài. Ghi chú bản vá là bản ghi chú phát hành ngắn gọn cho một lần phát hành chỉ để sửa lỗi. Hãy xuất bản ghi chú phát hành khi ai đó bên ngoài đội ngũ phải hành động theo, và duy trì nhật ký thay đổi chạy ngầm bên dưới.

Quyền sở hữu vận hành theo kiểu bàn giao. Đội kỹ thuật cung cấp nhật ký phát hành, một PM hoặc PMM chuyển chúng thành các mục hướng đến người dùng, và một người được chỉ định ký duyệt trước khi ghi chú được phát hành.

Bỏ qua tài liệu trống: ghi hình lại thay vì viết

Điền vào một mẫu trống là bước mà hầu hết các đội trì hoãn cho đến khi bản phát hành đã ra mắt. Cách khác là ghi lại đoạn hướng dẫn bạn vốn định trình bày và để nó trở thành ghi chú.

Hinto AI nhận bất kỳ nguồn video nào, một video Loom, một cuộc gọi Zoom, một video YouTube hay một tệp MP4 cục bộ, và ghi lại màn hình của bạn từ ứng dụng web hoặc tiện ích mở rộng Chrome. Tính năng nhận diện hành động bằng AI của nó xác định các thay đổi trạng thái giao diện và các cú nhấp nút, trích xuất ảnh chụp màn hình và các bước bằng văn bản. Những bước đó trở thành các mục tính năng mới, cải tiến và sửa lỗi, còn công cụ tạo GIF đảm nhận các phần mà giao diện đã thay đổi. Hinto cung cấp sẵn một mẫu dự án "What's New" được xây dựng cho ghi chú phát hành từ các bản demo sản phẩm.

Từ đó bạn chỉnh sửa thay vì viết từ đầu: bôi đen một đoạn và yêu cầu AI viết lại, sau đó lưu trữ kết quả trên một URL công khai với tên miền tùy chỉnh, hoặc đồng bộ nó sang Notion, Confluence, GitHub hoặc GitLab.

Câu hỏi thường gặp về mẫu ghi chú phát hành

Ghi chú phát hành nên chứa những gì?

Mười một mục: một dòng tiêu đề; một tóm tắt thay đổi; tính năng mới; cải tiến; sửa lỗi; thay đổi phá vỡ và các bước di chuyển; vấn đề đã biết; các bước nâng cấp; tính năng ngừng hỗ trợ; ghi chú bảo mật; và nơi nhận trợ giúp. Tóm tắt là dòng mà người lướt đọc và các tác nhân AI trích dẫn.

Làm thế nào để viết ghi chú phát hành tốt?

Hãy mở đầu bằng điều người đọc giờ đây có thể làm, và bỏ phần triển khai kỹ thuật ra ngoài. "Đã triển khai xử lý theo lô" trở thành "Bạn giờ đây có thể xuất tập dữ liệu lớn mà không lo tiến trình bị hết thời gian chờ." Hãy in đậm tên tính năng, dùng các nhãn Mới, Cải tiến và Đã sửa, và giữ mỗi mục trong hai đến ba câu.

Ai thường là người viết ghi chú phát hành?

Một quản lý sản phẩm hoặc quản lý marketing sản phẩm, dựa trên những gì đội kỹ thuật bàn giao. Đội kỹ thuật cung cấp nhật ký phát hành, PM hoặc PMM chuyển chúng thành các mục hướng đến người dùng, và một người phụ trách được chỉ định ký duyệt trước khi ghi chú được phát hành.

Sự khác biệt giữa ghi chú bản vá và ghi chú phát hành là gì?

Ghi chú bản vá là bản rút gọn cho một lần phát hành chỉ để sửa lỗi. Chúng bỏ tính năng mới, cải tiến, tính năng ngừng hỗ trợ và các bước nâng cấp, và mở đầu bằng bản sửa, ai bị ảnh hưởng, và người đọc có phải hành động gì hay không. Ghi chú phát hành mang cấu trúc đầy đủ cho một bản phát hành tính năng.

Ghi chú phát hành trong Jira là gì?

Đó vẫn là cùng một tài liệu, chỉ được dán vào một nơi cụ thể. Người tìm kiếm hỏi về Jira, Confluence, GitHub, Notion hay Azure DevOps thực ra muốn chính ghi chú phát hành, vậy nên hãy sao chép mẫu ở trên vào bất kỳ nơi nào đội của bạn đang đọc. Hinto xuất bản sang Notion, Confluence, GitHub và GitLab.