Biến quy trình thành bộ prompt dùng chung cho đội content: framework, Skills và quản lý phiên bản
Cách đóng gói những việc làm đi làm lại thành prompt framework cho cả đội: cấu trúc 9 phần, ba ví dụ từ sản xuất nội dung, một framework mẫu hoàn chỉnh, đóng gói thành Skills, GPTs, Gems, kiểm thử và quản lý phiên bản.
Trong bài này
- 13 phút đọc
- 12 phần
- 4 mẫu sao chép được
- 6 bảng tra cứu
Mục lục
- Khi nào một quy trình đáng được đóng gói
- Chín phần của một prompt framework
- Ba ví dụ thực tế từ sản xuất nội dung
- Một framework viết trọn vẹn: caption theo giọng thương hiệu
- Đóng gói: Skills, GPTs, Gems hay thư viện tài liệu
- Kiểm thử framework trước khi giao cho đội
- Quản lý phiên bản
- Triển khai cho cả đội
- Đo hiệu quả của framework
- Câu hỏi thường gặp
- Những lỗi hay gặp
- Kết luận
Trong một đội làm nội dung, mỗi người dùng AI một kiểu. Người này có bộ prompt rất tốt cho ảnh sản phẩm, lưu trong ghi chú cá nhân. Người kia viết prompt video từ đầu mỗi lần. Người mới vào thì hỏi “anh chị prompt thế nào?” và nhận về một đoạn chat bị cắt ngang. Kết quả là chất lượng phụ thuộc vào ai làm, và kinh nghiệm của đội nằm rải rác trong đầu từng người.
Bài này trình bày cách biến những quy trình làm đi làm lại thành bộ prompt chuẩn (prompt framework) dùng chung cho cả đội, và đóng gói chúng thành công cụ như Skills của Claude, GPTs của ChatGPT hay Gems của Gemini. Bài có cấu trúc chín phần của một framework, ba ví dụ thực tế từ sản xuất nội dung, cách kiểm thử, quản lý phiên bản và triển khai cho đội.
Khi nào một quy trình đáng được đóng gói#
Không phải prompt nào cũng cần thành framework. Đóng gói tốn công, và framework tồi còn tệ hơn không có. Một quy trình đáng đóng gói khi thoả ít nhất ba trong năm điều kiện:
- Lặp lại thường xuyên: ít nhất hằng tuần, hoặc nhiều người cùng làm.
- Có tiêu chuẩn đầu ra rõ ràng: bạn mô tả được thế nào là “đạt”.
- Có nhiều bước cố định: đọc đầu vào, phân tích, tạo nhiều phần đầu ra theo thứ tự.
- Có lỗi lặp lại: những lỗi mà người làm lâu năm biết tránh, người mới hay mắc.
- Có kiến thức chuyên môn: thuật ngữ, quy tắc, giới hạn công cụ mà không phải ai cũng nhớ.
Ví dụ trong sản xuất nội dung: viết prompt video quảng cáo 15 giây từ link sản phẩm, đổi nền ảnh sản phẩm mà giữ nguyên sản phẩm, biến KV tĩnh thành motion ad, viết caption theo giọng thương hiệu. Những việc này làm hằng ngày, có tiêu chuẩn rõ và có lỗi kinh điển.
Chín phần của một prompt framework#
| Phần | Trả lời câu hỏi | Ghi chú |
|---|---|---|
| 1. Mục đích | Framework này làm gì, cho ai | Một hai câu, đặt đầu tiên |
| 2. Khi nào dùng, khi nào không | Tình huống phù hợp và không phù hợp | Giúp người dùng và AI chọn đúng framework |
| 3. Đầu vào | Cần những gì, bắt buộc hay tuỳ chọn | Thiếu đầu vào bắt buộc thì hỏi lại, không tự bịa |
| 4. Quy trình từng bước | Làm theo thứ tự nào | Đánh số, mỗi bước một việc |
| 5. Kiến thức nền | Thuật ngữ, giới hạn công cụ, quy tắc ngành | Có thể tách ra file tham khảo riêng |
| 6. Định dạng đầu ra | Kết quả trình bày thế nào | Có khuôn mẫu cụ thể, người nhận copy dùng ngay |
| 7. Ràng buộc | Những điều không được làm | Viết thành danh sách rõ ràng |
| 8. Ví dụ | Một ví dụ tốt, một ví dụ xấu, kèm lý do | Phần hiệu quả nhất để AI hiểu đúng ý |
| 9. Tự kiểm tra | Trước khi trả kết quả, kiểm tra những gì | Danh sách ngắn, AI tự rà lại |
Phần 2 và phần 8 thường bị bỏ qua nhưng lại quan trọng nhất. Phần 2 ngăn framework bị dùng sai chỗ. Phần 8 cho AI thấy chất lượng mong muốn bằng ví dụ thay vì tính từ: “viết hay”, “chuyên nghiệp” không có nghĩa cụ thể, còn một ví dụ tốt kèm ví dụ xấu thì rất cụ thể.
Ba ví dụ thực tế từ sản xuất nội dung#
Ví dụ 1: Video affiliate 15 giây từ link sản phẩm
| Phần | Nội dung chính |
|---|---|
| Mục đích | Từ một link trang sản phẩm, tạo bộ prompt cho video dọc 15 giây gồm 3 cảnh × 5 giây |
| Đầu vào | Link sản phẩm (bắt buộc), nền tảng đăng, góc tiếp cận ưu tiên (tuỳ chọn) |
| Quy trình | Đọc trang, trích bản brief 7 trường; chia 3 cảnh theo vai trò hook, trình diễn, kêu gọi; viết prompt khung đầu, khung cuối, chuyển động cho từng cảnh |
| Kiến thức nền | Vùng an toàn khung dọc, giới hạn đầu vào của mô hình video, ngôn ngữ máy quay |
| Ràng buộc | Không bịa số đã bán, khuyến mãi; không vẽ chữ, giá vào ảnh; mô tả sản phẩm giống hệt nhau ở mọi prompt |
Ví dụ 2: Đổi nền ảnh sản phẩm, giữ nguyên sản phẩm
| Phần | Nội dung chính |
|---|---|
| Mục đích | Tạo prompt thay bối cảnh cho ảnh sản phẩm chụp thật, nâng lên chuẩn studio |
| Quy trình | Phân tích ảnh gốc: hướng sáng, góc chụp, chất liệu; viết khối “giữ nguyên tuyệt đối”; viết các biến thể bối cảnh |
| Ràng buộc | Không đổi màu, logo, chữ in, hình dáng sản phẩm; không thêm chữ lên nền |
| Tự kiểm tra | Hướng sáng bối cảnh khớp ảnh gốc chưa; khối giữ nguyên có đủ logo, chữ, góc chụp, bàn tay chưa |
Ví dụ 3: KV tĩnh thành motion ad
| Phần | Nội dung chính |
|---|---|
| Mục đích | Từ cặp ảnh KV khung đầu và khung cuối, viết prompt video cho motion ad |
| Quy trình | So sánh hai khung, xếp vào một trong ba kiểu: dựng dần, chuyển KV sang KV, không khí; chọn chuyển động theo kiểu; viết prompt |
| Kiến thức nền | Mô hình video có thể làm sai chữ và giá, nên chữ đặt ở hậu kỳ |
| Định dạng đầu ra | Prompt tiếng Anh để dán thẳng, kèm giải thích tiếng Việt cho người duyệt |
Để ý điểm chung: cả ba framework đều mã hoá kinh nghiệm thành ràng buộc. “Không vẽ giá vào video” là bài học mà ai làm motion ad lâu năm cũng biết. Đưa nó vào framework, người mới không phải trả giá để học lại.
Một framework viết trọn vẹn: caption theo giọng thương hiệu#
Để thấy chín phần ghép lại thành một framework hoàn chỉnh, đây là ví dụ cho việc viết caption mạng xã hội. Bạn có thể sao chép, thay phần giọng thương hiệu và ví dụ bằng của mình:
# Framework: Caption mạng xã hội theo giọng thương hiệu (v1.0)
## 1. Mục đích
Viết caption cho bài đăng mạng xã hội của [Thương hiệu], đúng giọng, đúng một thông điệp, không vi phạm Luật Quảng cáo.
## 2. Khi nào dùng / không dùng
Dùng: bài đăng sản phẩm, bài chia sẻ mẹo, bài kể chuyện trên Facebook, Instagram, TikTok, Zalo OA.
Không dùng: thông cáo báo chí, nội dung khủng hoảng, nội dung y tế, tài chính cần duyệt pháp lý riêng.
## 3. Đầu vào
Bắt buộc: người đọc, mục tiêu, một thông điệp, nền tảng.
Tuỳ chọn: chi tiết thật (số liệu, phản hồi khách, tình huống), kiểu hook mong muốn.
Thiếu đầu vào bắt buộc: hỏi lại, không tự đoán.
## 4. Quy trình
1. Xác nhận lại một thông điệp chính bằng một câu.
2. Viết 5 phiên bản, mỗi bản một kiểu hook khác nhau.
3. Mỗi bản: hook, thân bài theo một cấu trúc, một hành động cụ thể.
4. Tự kiểm tra theo mục 9, sửa trước khi trả kết quả.
## 5. Kiến thức nền
- 8 kiểu hook: tình huống quen thuộc, con số, nói ngược, thừa nhận điểm yếu, trước và sau,
câu nói của khách, hướng dẫn nhanh, đặt cược nhỏ.
- 3 cấu trúc thân bài: nỗi đau và giải pháp, câu chuyện ngắn, mẹo kèm sản phẩm.
- Độ dài gợi ý theo nền tảng: [điền theo thương hiệu].
## 6. Định dạng đầu ra
Mỗi phiên bản: caption hoàn chỉnh, sau đó một dòng "Hook: [kiểu] Cấu trúc: [kiểu]".
## 7. Ràng buộc
- Không dùng "nhất", "duy nhất", "tốt nhất", "số một" khi không có bằng chứng.
- Không thêm số liệu, khuyến mãi, phản hồi khách không có trong đầu vào.
- Tối đa 2 emoji, 2 đến 4 hashtag.
- Không mở đầu bằng "Bạn có biết".
## 8. Ví dụ
Tốt: [dán caption đã chạy tốt] — vì: tình huống cụ thể, chi tiết thật, một hành động.
Xấu: [dán caption chung chung] — vì: câu hỏi sáo rỗng, ba lợi ích chung chung, "tốt nhất".
## 9. Tự kiểm tra
- Thay tên thương hiệu khác vào, caption có còn đúng không? Nếu còn: chưa đủ cụ thể.
- Mọi con số có trong đầu vào không?
- Có từ nào trong danh sách cấm không?Câu kiểm tra đầu tiên ở mục 9, “thay tên thương hiệu khác vào có còn đúng không”, là một mẹo nhỏ nhưng rất hiệu quả để AI tự phát hiện caption chung chung.
Đóng gói: Skills, GPTs, Gems hay thư viện tài liệu#
| Cách đóng gói | Cách hoạt động | Hợp với |
|---|---|---|
| Skills (Claude) | Một thư mục chứa file SKILL.md và các file tham khảo. Claude đọc phần mô tả để tự quyết định khi nào dùng skill. | Đội dùng Claude, framework nhiều bước, nhiều file tham khảo |
| GPTs (ChatGPT) | Trợ lý tuỳ chỉnh có hướng dẫn cố định và file kiến thức đính kèm | Đội dùng ChatGPT, mỗi framework thành một trợ lý riêng |
| Gems (Gemini) | Trợ lý tuỳ chỉnh với hướng dẫn cố định | Đội dùng hệ sinh thái Google |
| Thư viện tài liệu | Mỗi framework là một tài liệu, người dùng copy dán vào công cụ bất kỳ | Đội dùng nhiều công cụ AI khác nhau, cần linh hoạt |
Công cụ nào cũng được, miễn là cả đội dùng cùng một nơi và cùng một phiên bản. Một framework tốt viết theo chín phần ở trên có thể chuyển giữa các công cụ mà không cần viết lại nhiều.
Ví dụ cấu trúc một Skill
kv-motion-ads/
├── SKILL.md # hướng dẫn chính
└── references/
├── motion-types.md # mô tả 3 kiểu chuyển động
├── prompt-templates.md # mẫu prompt cho từng kiểu
└── text-safety.md # quy tắc chống méo chữ, sai giáPhần đầu file SKILL.md có tên và mô tả. Mô tả là thứ quyết định skill có được dùng đúng lúc hay không, nên hãy viết nó như một câu trả lời cho câu hỏi “khi nào dùng?”, kèm những cách người dùng hay diễn đạt yêu cầu:
---
name: kv-motion-ads
description: Phân tích cặp ảnh KV khung đầu và khung cuối, viết prompt video để biến KV tĩnh
thành motion ad. Dùng khi người dùng đưa 1-2 ảnh KV và nhắc tới "KV động", "motion ad",
"biến KV tĩnh thành động", "start frame end frame", kể cả khi chỉ gửi ảnh.
---
# KV tĩnh thành motion ad
## Quy trình
1. So sánh khung đầu và khung cuối, liệt kê những gì thay đổi.
2. Xếp vào một trong ba kiểu chuyển động (xem references/motion-types.md).
3. Viết prompt theo mẫu tương ứng (xem references/prompt-templates.md).
4. Tự kiểm tra theo references/text-safety.md trước khi trả kết quả.
## Ràng buộc
- Không để mô hình video tạo hay chỉnh chữ, số, giá, logo.
- Máy quay đứng yên ở giây cuối để khung kết trùng KV gốc.Tách kiến thức dài ra file tham khảo giúp file chính ngắn gọn. AI chỉ đọc file tham khảo khi cần, và người bảo trì sửa từng phần mà không đụng tới cả framework.
Kiểm thử framework trước khi giao cho đội#
Một framework chưa kiểm thử là một giả thuyết. Cách kiểm thử đơn giản nhất:
- Chuẩn bị bộ đầu vào thử nghiệm: 5 đến 10 trường hợp, gồm trường hợp điển hình, trường hợp khó và trường hợp thiếu thông tin.
- Viết tiêu chí chấm: 4 đến 6 tiêu chí đạt hoặc không đạt, ví dụ “mô tả sản phẩm giống hệt nhau ở mọi prompt”, “không có số liệu không có trong đầu vào”.
- Chạy và chấm: chạy mỗi trường hợp, chấm theo tiêu chí. Ghi lại lỗi theo nhóm.
- Sửa framework theo lỗi: mỗi nhóm lỗi thường cần thêm một ràng buộc, một bước kiểm tra hoặc một ví dụ.
- Chạy lại toàn bộ bộ thử nghiệm sau mỗi lần sửa, để chắc rằng sửa lỗi này không sinh lỗi khác.
Trường hợp thiếu thông tin rất quan trọng. Một framework tốt phải biết hỏi lại hoặc ghi rõ “[giả định]” khi thiếu dữ liệu, thay vì tự bịa cho đủ.
Ví dụ bộ tiêu chí cho framework video affiliate
| Tiêu chí | Cách kiểm tra |
|---|---|
| Đủ 3 cảnh, mỗi cảnh đủ 3 prompt | Đếm |
| Cụm mô tả sản phẩm giống hệt nhau ở mọi prompt ảnh | So sánh từng chữ |
| Cảnh 1 có hook trong 3 giây đầu | Đọc mốc thời gian cảnh 1 |
| Không có số liệu, khuyến mãi không có trên trang sản phẩm | Đối chiếu với trang gốc |
| Không yêu cầu mô hình vẽ chữ, giá | Tìm các yêu cầu về chữ trong prompt |
| Có ghi chú vùng an toàn khung dọc | Tìm trong prompt ảnh |
Quản lý phiên bản#
Framework sẽ thay đổi: công cụ AI ra phiên bản mới, đội phát hiện lỗi mới, khách hàng đổi yêu cầu. Không có quản lý phiên bản, mỗi người dùng một bản khác nhau và không ai biết bản nào mới nhất.
- Một nơi lưu duy nhất: một thư mục dùng chung, một kho Git, hoặc một tài liệu chính. Không có bản “riêng” trong máy cá nhân.
- Số phiên bản và nhật ký thay đổi: mỗi lần sửa ghi ngày, ai sửa, sửa gì, vì sao.
- Một người phụ trách mỗi framework: người duyệt thay đổi và trả lời câu hỏi.
- Thông báo khi có thay đổi lớn, kèm ví dụ trước và sau.
## Nhật ký thay đổi
v1.3 (2026-11-08, An): thêm ràng buộc không vẽ giá vào video sau 2 lỗi sai giá ở chiến dịch tháng 10.
v1.2 (2026-10-15, Minh): thêm kiểu chuyển động "chuyển KV sang KV".
v1.1 (2026-09-30, An): tách quy tắc chống méo chữ ra file tham khảo riêng.Triển khai cho cả đội#
- Bắt đầu với hai, ba framework cho những việc làm nhiều nhất, đừng cố đóng gói mọi thứ cùng lúc.
- Buổi hướng dẫn ngắn cho mỗi framework: khi nào dùng, đầu vào cần gì, một ví dụ trọn vẹn.
- Kênh phản hồi: mỗi khi framework cho kết quả sai, người dùng gửi lại đầu vào và kết quả. Đây là nguồn trường hợp thử nghiệm tốt nhất.
- Xem lại định kỳ: mỗi tháng một lần, xem framework nào được dùng nhiều, framework nào bị bỏ, lỗi nào lặp lại.
Một dấu hiệu framework đang hoạt động tốt: người mới vào đội cho ra kết quả gần với người làm lâu năm ngay trong tuần đầu.
Đo hiệu quả của framework#
Framework là một khoản đầu tư, nên cần biết nó có hoàn vốn không. Ba chỉ số dễ đo:
- Thời gian từ đầu vào đến kết quả dùng được, trước và sau khi có framework.
- Số lần phải sửa hoặc làm lại trước khi kết quả được duyệt.
- Độ đồng đều giữa các thành viên: kết quả của người mới so với người làm lâu năm.
Không cần đo phức tạp. Một bảng tính ghi lại mỗi lần dùng framework, thời gian và số lần sửa, sau một tháng đã đủ để thấy framework nào đáng đầu tư thêm, framework nào nên bỏ.
Câu hỏi thường gặp#
Framework có làm mất tính sáng tạo không?
Framework tốt cố định phần lặp lại và phần dễ sai: định dạng, ràng buộc, quy trình kiểm tra. Phần sáng tạo, như ý tưởng, góc tiếp cận, chi tiết câu chuyện, vẫn đến từ đầu vào của người dùng. Người làm nội dung có nhiều thời gian hơn cho sáng tạo vì không phải viết lại những thứ lặp lại.
Ai trong đội nên viết framework?
Người làm việc đó giỏi nhất, phối hợp với một người có kỹ năng viết prompt. Người giỏi chuyên môn biết lỗi nào hay gặp và thế nào là đạt. Người viết prompt biết cách diễn đạt để AI làm theo ổn định.
Framework viết bằng tiếng Việt hay tiếng Anh?
Phần hướng dẫn có thể viết bằng tiếng Việt cho cả đội dễ đọc và sửa. Riêng các mẫu prompt đưa vào công cụ tạo ảnh, video nên giữ tiếng Anh, vì các mô hình này hiểu thuật ngữ tiếng Anh ổn định hơn.
Những lỗi hay gặp#
- Framework quá dài, quá chung. Một framework “làm mọi thứ về video” sẽ làm không tốt việc nào. Mỗi framework một việc.
- Toàn tính từ, không có ví dụ. “Viết sáng tạo, chuyên nghiệp, hấp dẫn” không giúp được gì. Một ví dụ tốt và một ví dụ xấu giúp nhiều hơn.
- Mô tả “khi nào dùng” mơ hồ, khiến framework không được dùng đúng lúc, hoặc bị dùng sai chỗ.
- Không có bước xử lý khi thiếu thông tin, dẫn tới AI tự bịa cho đủ đầu ra.
- Không kiểm thử lại sau khi sửa. Sửa một lỗi, sinh hai lỗi mới mà không ai biết.
- Không có người phụ trách. Framework cũ dần, đội quay lại tự viết prompt.
Kết luận#
Prompt framework là cách biến kinh nghiệm của những người giỏi nhất trong đội thành công cụ cho cả đội. Chọn những việc lặp lại nhiều nhất, viết theo chín phần với ràng buộc và ví dụ cụ thể, kiểm thử bằng một bộ trường hợp thật, rồi quản lý phiên bản như quản lý một sản phẩm. Công cụ đóng gói (Skills, GPTs, Gems hay thư viện tài liệu) chỉ là chỗ chứa. Giá trị nằm ở nội dung bên trong và ở việc cả đội cùng dùng, cùng cải tiến.
