Tạo biên bản họp và giao việc vào Jira bằng AI
Thiết kế workflow biến transcript cuộc họp thành biên bản ngắn gọn, danh sách việc có cấu trúc và bản nháp Jira. Mọi ticket chỉ được tạo sau khi người có thẩm quyền kiểm tra, xác nhận.
Một cuộc họp kết thúc, file ghi âm hoặc transcript được lưu lại. Nhưng câu hỏi quan trọng nhất — ai làm gì, khi nào xong? — thường bị lẫn trong tranh luận, cập nhật trạng thái và các đề xuất chưa chốt.
Nếu đưa nguyên phần tóm tắt đó vào Jira, đội rất dễ có ticket sai người phụ trách, sai hạn hoặc thậm chí ghi nhận một ý kiến chưa thành quyết định.
Cách an toàn hơn là xây workflow theo chuỗi:
Transcript → AI lập biên bản và trích xuất việc → người duyệt xác nhận → tạo Jira issue
Trong luồng này, AI không quyết định thay cuộc họp. Vai trò của AI là chuẩn hóa thông tin đã được nói rõ, đồng thời chỉ ra những phần còn thiếu để con người xác nhận.
Biên bản không phải bản chép lời
Biên bản họp là bản ghi bằng văn bản về một cuộc họp. Nội dung có thể gồm người tham dự, các vấn đề được xem xét, phản hồi và quyết định liên quan.
Theo tài liệu tham khảo về minutes, mục đích chính của biên bản là ghi lại điều đã được làm hoặc được quyết định, không phải ghi lại từng câu từng người nói. Vì vậy, biên bản thường nên ngắn gọn và tập trung vào kết quả của cuộc họp.
Khi đưa AI vào workflow, đừng chỉ yêu cầu “tóm tắt cuộc họp”. Hãy yêu cầu mô hình phân tách rõ:
Quyết định: điều đã được chốt.
Việc cần làm: hành động cụ thể phát sinh từ cuộc họp.
Người phụ trách: chỉ ghi khi được nêu rõ.
Hạn chót: chỉ ghi khi có mốc thời gian rõ ràng.
Điểm cần xác nhận: việc có vẻ cần làm nhưng chưa có chủ sở hữu, hạn hoặc mô tả đủ cụ thể.
> Thiếu thông tin cũng là một kết quả hợp lệ. Đừng để AI tự suy đoán người phụ trách hay hạn chót chỉ để làm đầy dữ liệu.
Kiến trúc workflow: từ transcript đến bản nháp Jira
Bạn có thể triển khai luồng này bằng n8n, Make, Zapier, Power Automate, Apps Script hoặc code riêng. Công cụ khác nhau, nhưng nguyên tắc xử lý nên giống nhau.
Bước 1: Nhận transcript hoặc file cuộc họp
Workflow có thể bắt đầu khi:
File ghi âm mới được đưa vào thư mục họp.
Một biểu mẫu nội bộ có transcript đính kèm.
Một tin nhắn chứa transcript được gửi vào kênh vận hành.
Nhân sự chủ động chạy workflow sau cuộc họp.
Tài liệu về biên bản cho biết cuộc họp có thể được ghi âm hoặc ghi hình, sau đó biên bản được chuẩn bị sau. Tuy nhiên, tài liệu tham khảo không mô tả bước chuyển audio thành transcript.
Vì vậy, nếu đầu vào là file ghi âm, hãy xem bước chuyển giọng nói thành văn bản là một dịch vụ riêng trong stack của bạn. Nên lưu file gốc, transcript và mã cuộc họp để có dữ liệu đối chiếu khi cần kiểm tra.
Ví dụ dữ liệu đầu vào:
json
{
"meetingid": "<meetingid>",
"meetingtitle": "<meetingtitle>",
"meetingdate": "<meetingdate>",
"participants": ["<name1>", "<name2>"],
"transcript": "<transcripttext>",
"jiraprojectkey": "<projectkey>"
}
Nếu transcript bị thiếu, rỗng hoặc lỗi nặng, hãy đưa cuộc họp vào hàng chờ xử lý thay vì tiếp tục trích xuất công việc.
Bước 2: Dùng AI lập biên bản và trích xuất việc dưới dạng JSON
Đầu ra có cấu trúc giúp các node phía sau kiểm tra dữ liệu, hiển thị để duyệt và tạo Jira issue có kiểm soát.
Prompt nên yêu cầu AI chỉ dùng thông tin có căn cứ trong transcript:
text
Bạn là trợ lý lập biên bản cuộc họp.
Dựa CHỈ trên transcript bên dưới, hãy:
Tóm tắt các quyết định đã được chốt.
Trích xuất các việc cần làm rõ ràng.
Với mỗi việc, ghi người phụ trách và hạn chót chỉ khi được nói rõ.
Không biến ý kiến, câu hỏi hoặc đề xuất chưa chốt thành quyết định.
Không suy đoán người phụ trách hoặc hạn chót.
Đưa các việc thiếu thông tin vào needsreview.
Thông tin cuộc họp:
Tiêu đề: <meetingtitle>
Ngày: <meetingdate>
Người tham dự dự kiến: <participants>
Transcript:
<transcripttext>
Trả về JSON hợp lệ theo đúng cấu trúc:
{
"minutessummary": "<tóm tắt ngắn>",
"decisions": [
{
"decision": "<nội dung đã chốt>",
"evidence": "<đoạn hoặc ý trong transcript làm căn cứ>"
}
],
"actionitems": [
{
"summary": "<việc cần làm>",
"description": "<bối cảnh và kết quả mong đợi nếu được nêu>",
"assigneename": "<tên hoặc null>",
"duedate": "<hạn chót hoặc null>",
"evidence": "<căn cứ từ transcript>"
}
],
"needsreview": [
{
"item": "<nội dung cần xác nhận>",
"reason": "<thiếu người phụ trách, hạn chót hoặc chưa đủ rõ>"
}
]
}
Cách này biến AI thành bước trích xuất có ràng buộc. Với nhu cầu lập biên bản và tạo ticket, một workflow cố định thường dễ kiểm soát hơn việc để AI tự chọn hành động.
Ví dụ: giữ lại phần chưa chắc chắn
Giả sử transcript có nội dung:
> “Nhóm thống nhất cập nhật tài liệu triển khai. Lan sẽ rà lại phần hướng dẫn. Còn phần kiểm thử, cần xử lý trước đợt phát hành.”
AI không nên tự gán việc kiểm thử cho Lan. Một kết quả phù hợp hơn là:
json
{
"minutessummary": "Nhóm thống nhất cập nhật tài liệu triển khai và cần xử lý phần kiểm thử trước đợt phát hành.",
"decisions": [
{
"decision": "Cập nhật tài liệu triển khai.",
"evidence": "Nhóm thống nhất cập nhật tài liệu triển khai."
}
],
"actionitems": [
{
"summary": "Rà lại phần hướng dẫn trong tài liệu triển khai",
"description": null,
"assigneename": "Lan",
"duedate": null,
"evidence": "Lan sẽ rà lại phần hướng dẫn."
}
],
"needsreview": [
{
"item": "Xử lý phần kiểm thử trước đợt phát hành",
"reason": "Chưa nêu rõ người phụ trách và hạn chót cụ thể."
}
]
}
Các mục trong needsreview nên được đưa vào bước xác nhận, thay vì tạo Jira issue ngay.
Bước 3: Kiểm tra dữ liệu trước khi tạo Jira issue
Trước node Jira hoặc HTTP request, hãy thêm các điều kiện kiểm tra:
summary không rỗng.
Mỗi action item có căn cứ trong evidence.
Người phụ trách, nếu có, khớp với danh sách người dùng mà tổ chức cho phép gán việc.
Hạn chót, nếu có, tuân theo quy ước dữ liệu của workflow.
Action item chưa được tạo từ cùng một cuộc họp hoặc cùng một lần duyệt.
Tài liệu Jira Cloud REST API v3 liệt kê endpoint tạo issue:
text
POST /rest/api/3/issue
Jira cũng cung cấp các endpoint lấy metadata phục vụ việc tạo issue, gồm:
text
GET /rest/api/3/issue/createmeta
GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes
GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}
Bạn có thể dùng metadata để kiểm tra project, issue type và các trường liên quan trước khi gửi yêu cầu tạo issue.
Điểm quan trọng: node tạo Jira chỉ nên nhận dữ liệu đã được kiểm tra và phê duyệt, không nên nhận trực tiếp toàn bộ JSON vừa do AI trả về.
Bước 4: Đặt bước duyệt trước khi ghi vào Jira
Tạo issue là hành động làm thay đổi hệ thống làm việc của đội. Vì vậy, trước khi gọi API, hãy hiển thị cho người duyệt:
Tóm tắt cuộc họp.
Danh sách quyết định.
Các ticket dự kiến tạo.
Người phụ trách và hạn chót, nếu có.
Căn cứ trích từ transcript.
Các mục AI đánh dấu cần làm rõ.
Người duyệt có thể sửa, bỏ qua hoặc chấp nhận từng mục. Chỉ những mục đã được chấp nhận mới đi đến bước:
text
POST /rest/api/3/issue
Nếu sau này workflow cần tra cứu thêm ticket liên quan, tài liệu dự án hoặc quy tắc phân loại nội bộ, bạn có thể bổ sung bước AI tra cứu. Dù vậy, hành động tạo hoặc chỉnh sửa issue vẫn nên có giới hạn và cơ chế phê duyệt phù hợp.
Xử lý lỗi, tạo lại và lưu vết
Demo tạo được ticket chưa đủ để workflow vận hành ổn định. Hãy chuẩn bị các nhánh xử lý cơ bản:
JSON không hợp lệ: kiểm tra trước khi parse; nếu lỗi, yêu cầu AI trả lại đúng cấu trúc hoặc chuyển sang xử lý thủ công.
Lỗi khi gọi Jira: lưu trạng thái theo từng action item để biết mục nào đã tạo thành công.
Retry: chỉ thử lại các mục chưa tạo thành công, tránh tạo issue lặp.
Timeout hoặc gián đoạn: lưu meetingid, dữ liệu đã duyệt và phản hồi từ Jira để có thể tiếp tục đúng bước.
Lưu vết: ghi nhận ai đã duyệt, duyệt lúc nào, AI trích xuất gì và Jira phản hồi gì.
Dữ liệu nội bộ: chỉ đưa vào bước AI phần nội dung cần thiết và kiểm soát quyền truy cập transcript.
Thông tin xác thực: không đặt trực tiếp trong prompt, code node hoặc bảng tính dùng chung.
Checklist trước khi bật workflow
[ ] Có transcript hoặc nguồn đối chiếu cho từng biên bản.
[ ] Prompt yêu cầu đầu ra JSON và cấm suy đoán.
[ ] Có nhánh needsreview cho việc thiếu người phụ trách hoặc hạn chót.
[ ] Có kiểm tra dữ liệu trước khi tạo Jira issue.
[ ] Có bước phê duyệt của con người.
[ ] Có cơ chế tránh tạo trùng và theo dõi trạng thái lỗi.
[ ] Có lưu vết cho việc AI trích xuất, người dùng duyệt và Jira tạo issue.
[ ] Transcript và thông tin xác thực được kiểm soát theo quyền truy cập phù hợp.
Workflow tốt không phải là workflow tạo ra nhiều ticket nhất. Đó là workflow giúp đội nhìn rõ điều đã chốt, phát hiện điều còn mơ hồ và chỉ biến những cam kết đã được xác nhận thành công việc trong Jira.