Buổi 7: Lưu cách làm để dùng lại — Ứng dụng ChatGPT vào công việc

Ở Buổi 6, bạn đã chạy một workflow bằng tay và nhìn thấy nơi AI làm tốt, nơi cần đối chiếu nguồn, nơi phải dừng. Khi cách làm ổn định, bạn không muốn giải thích lại toàn bộ mỗi tuần. Bạn cũng muốn người khác dùng cùng cách làm với dữ liệu mới.

Lúc này có thể đóng gói workflow thành một Skill: một gói chỉ dẫn và tài nguyên giúp môi trường AI hỗ trợ Skill biết khi nào dùng, làm theo bước nào và phải dừng ở đâu. Điều được lưu lại là cách làm đã kiểm chứng, còn dữ liệu mỗi lần chạy vẫn là đầu vào mới.

Bài thuộc lộ trình 8 buổi đưa ChatGPT vào công việc, biên tập từ khóa học gốc.

1. Chỉ đóng gói thứ đã chạy ổn định

Nếu mỗi lần làm bạn vẫn phải đổi toàn bộ thứ tự, đầu ra hoặc tiêu chí, hãy tiếp tục sửa workflow. Đưa một quy trình mơ hồ vào Skill sẽ giữ lại sự mơ hồ đó, khiến người khác khó biết phải cung cấp gì và nhận kết quả nào.

Ba dấu hiệu một workflow đã sẵn sàng:

Nên đóng gói: mỗi tuần nhận cùng loại dữ liệu, tạo cùng cấu trúc báo cáo, có cùng cách kiểm tra và cùng điểm duyệt.

Chưa nên đóng gói: mục tiêu thay đổi từng lần, chưa thống nhất nguồn sự thật hoặc chưa biết ai chịu trách nhiệm duyệt.

Lấy workflow Buổi 6 và đánh dấu phần luôn đúng, phần thay đổi theo lần chạy. Ví dụ mẫu báo cáo có thể ổn định, còn ghi chú ca trực và số liệu ticket tuần này là dữ liệu mới. Không đưa dữ liệu từng tuần vào instructions cố định.

2. Skill là gói chỉ dẫn và tài nguyên

Thiết kế nội dung trước. Cấu trúc tệp kỹ thuật chỉ là cách lưu gói đó, có thể thay đổi theo công cụ bạn dùng. Bạn không cần bắt đầu bằng lập trình hoặc nhớ tên thư mục.

Gói Skill có bốn phần:

Instructions là hướng dẫn cách làm. Resources là tài nguyên hỗ trợ. Verify là kiểm tra đầu ra theo tiêu chí. Stop condition là điều kiện dừng. Gọi bằng thuật ngữ nào cũng được, nhưng bốn trách nhiệm này phải có người viết rõ.

3. Mô tả tốt giúp dùng đúng Skill

Tên hấp dẫn chưa đủ. Mô tả phải nói được loại yêu cầu, đầu vào cần có, đầu ra tạo ra và giới hạn quan trọng. Tên quá chung không có nghĩa là dùng được cho nhiều việc hơn; nó dễ khiến Skill được chọn nhầm.

Tự phân loại ba yêu cầu sau:

1. Tóm tắt nhật ký ca trực tuần này, đã đính kèm số liệu ticket. Dùng Skill: đúng ngữ cảnh, đủ hai đầu vào và đúng đầu ra nó phụ trách.
2. Báo cáo doanh thu tuần từ bảng bán hàng. Không dùng: cùng chữ “báo cáo tuần” nhưng khác nguồn, tiêu chí và rủi ro. Cần workflow hoặc Skill khác.
3. Tạo rồi gửi báo cáo hỗ trợ cho giám đốc. Skill này chỉ tạo bản nháp và kiểm tra. Gửi là hành động bên ngoài; dừng ở cổng duyệt nếu chưa được thiết kế và cấp quyền cho bước đó.

Khi viết mô tả của bạn, dùng mẫu có ranh giới rồi thay đúng nguồn và đầu ra. Sau đó kiểm tra cả tình huống phù hợp lẫn tình huống có cùng từ khóa nhưng khác bản chất.

4. Test hai bộ dữ liệu và một ngoại lệ

Một ví dụ chạy được chỉ chứng minh Skill hợp với ví dụ đó. Bộ kiểm thử nhỏ giúp phát hiện chỉ dẫn mơ hồ, tài nguyên thiếu và điểm dừng chưa thực sự hoạt động.

Tải bộ kiểm thử Skill: tệp TXT gồm dữ liệu A, dữ liệu B và ngoại lệ có số liệu mâu thuẫn để kiểm tra chọn Skill, kiểm tra kết quả và điều kiện dừng.

Dữ liệu thực hành có thể sao chép

Dưới đây là toàn bộ dữ liệu mẫu để bạn thực hành ngay trong bài. Các hồ sơ, mốc thời gian và số liệu là tình huống học tập, không phải dữ liệu khách hàng thật.

BỘ KIỂM THỬ SKILL — BÁO CÁO HỖ TRỢ HẰNG TUẦN

Mục tiêu kiểm thử
Skill phải tạo bản nháp gồm: tổng quan, vấn đề nổi bật, việc đã xử lý, rủi ro và việc cần quyết định. Skill không được tự gửi báo cáo. Nếu thiếu hoặc mâu thuẫn số liệu quan trọng, Skill phải dừng và nêu điều cần xác nhận.

=== DATASET A — TRƯỜNG HỢP ĐIỂN HÌNH ===
Khoảng thời gian: 02–06/09
Ticket mới: 54
Đã đóng: 42
Đang xử lý: 8
Chờ khách hàng: 4
Ghi chú:
- 16 ticket hỏi về đổi mật khẩu; hướng dẫn mới đã được cập nhật.
- 11 ticket về hóa đơn; đội tài chính đã xác nhận quy trình hiện tại không đổi.
- Không có sự cố mức nghiêm trọng cao.

Kết quả mong đợi:
- Skill được dùng.
- Số liệu khớp và bản nháp theo đúng cấu trúc.
- Không bịa thêm nguyên nhân hoặc hành động.

=== DATASET B — CÙNG WORKFLOW, NỘI DUNG KHÁC ===
Khoảng thời gian: 09–13/09
Ticket mới: 103
Đã đóng: 70
Đang xử lý: 21
Chờ khách hàng: 12
Ghi chú:
- 28 ticket đồng bộ dữ liệu sau bản cập nhật ứng dụng.
- Đội kỹ thuật đã khôi phục phiên bản cũ lúc 11:40 ngày 12/09.
- 6 khách hàng vẫn báo lỗi sau khi khôi phục; đang chờ log.
- Một khách hàng doanh nghiệp yêu cầu báo cáo nguyên nhân, hạn phản hồi chưa được cung cấp.

Kết quả mong đợi:
- Skill được dùng dù số lượng và nhóm vấn đề khác Dataset A.
- Tách việc đã xác nhận khỏi việc còn chờ log.
- Đánh dấu hạn phản hồi là thông tin còn thiếu.

=== NGOẠI LỆ — PHẢI DỪNG ===
Khoảng thời gian: 16–20/09
Bảng ticket: tổng mới 86, đã đóng 61, đang xử lý 18, chờ khách hàng 9.
Ghi chú trưởng ca: tổng ticket mới là 82.
Ghi chú khác: có lỗi thanh toán nhưng chưa xác nhận số khách hàng ảnh hưởng.

Kết quả mong đợi:
- Skill nhận ra 61 + 18 + 9 không bằng 86 và tổng 86 mâu thuẫn với 82.
- Không tính tỷ lệ, không chọn số có vẻ hợp lý hơn.
- Dừng trước khi hoàn thiện báo cáo và yêu cầu xác nhận nguồn sự thật.

Phiếu ghi kết quả cho mỗi lần test
1. Trigger đúng hay sai?
2. Đã dùng đúng tất cả nguồn chưa?
3. Đầu ra có đủ cấu trúc không?
4. Verify bắt được lỗi gì?
5. Stop condition có dừng đúng lúc không?
6. Instructions hoặc resources cần sửa điểm nào?

Có thể dùng một phiếu chấm chung:

Đây là bảng để bạn điền khi chạy, không phải kết quả thử nghiệm đã có. Hai bộ dữ liệu thường cần đạt cùng cấu trúc; ngoại lệ cần làm Skill dừng đúng. Nếu chưa cài được Skill, đọc và đối chiếu thủ công đầu ra dự kiến bằng chính bộ hướng dẫn đã viết.

5. Chia sẻ Skill như một sản phẩm có phiên bản

Khi nhiều người dùng chung, một thay đổi nhỏ trong instructions có thể làm đầu ra khác đi. Skill cần người sở hữu, lịch sử thay đổi và kiểm thử lại để người dùng hiểu họ đang dùng cách làm nào.

Trước khi chia sẻ và mỗi lần cập nhật, kiểm tra:

• Ghi mục đích, phạm vi và người chịu trách nhiệm.
• Lưu phiên bản và lý do đổi instructions hoặc resources.
• Chạy lại bộ test sau thay đổi quan trọng.
• Thu phản hồi bằng lỗi cụ thể, thay vì chỉ “kết quả chưa hay”.
• Loại bỏ nguồn cũ và kiểm tra quyền truy cập tài nguyên.
• Cho người dùng biết điểm nào vẫn cần họ phê duyệt.

Sản phẩm mang về cuối buổi

• Mô tả rõ tình huống dùng, tình huống không dùng, đầu vào và đầu ra.
• Instructions, resources, verify và điều kiện dừng lấy từ workflow đã chạy thật.
• Kết quả kiểm thử hai bộ dữ liệu bình thường và một ngoại lệ.

Nếu workflow riêng chưa đủ ổn định, quay về mẫu báo cáo hỗ trợ để luyện. Đừng dùng việc tạo Skill như một cách bỏ qua bước kiểm chứng workflow.

Buổi 8 sẽ quyết định cách làm này nên tiếp tục chạy trong chat, thành task độc lập, chạy theo lịch hay chờ sự kiện kích hoạt. Đóng gói cách làm và lựa chọn cách vận hành là hai quyết định cần làm lần lượt.

Tham khảo theo khóa học: OpenAI · Skills, Skills API. Phần API dành cho môi trường tích hợp; bạn không cần dùng API để hoàn thành bài thiết kế gói cách làm.

Học tiếp trong lộ trình

• Buổi trước: Buổi 6: Biến việc lặp lại thành quy trình.
• Buổi tiếp theo: Buổi 8: Đưa AI vào công việc hằng ngày.
• Xem đầy đủ lộ trình và 8 bài chi tiết.