Mở đầu — vì sao bài này quan trọng
Trong các bài trước, bạn đã làm quen với việc tạo một Custom GPT đơn giản: đặt tên, viết vài dòng mô tả, dán một đoạn hướng dẫn ngắn, thế là có một "trợ lý" chạy được. Nó hoạt động, nhưng thường ở mức "đủ dùng cho demo" chứ chưa phải thứ bạn dám đặt vào quy trình làm việc hằng ngày của cả team.
Bài này là bước nhảy từ "biết tạo" sang "tạo ra thứ dùng được thật". Một Custom GPT được xây dựng bài bản có thể thay thế cho hàng chục lần bạn phải copy-paste lại cùng một prompt dài, đảm bảo cả team viết PRD theo đúng template công ty, hay biến tài liệu nội bộ 200 trang thành một chuyên gia trả lời ngay trong 5 giây. Với một PM — người luôn thiếu thời gian và phải lặp đi lặp lại nhiều loại công việc giống nhau — đây là một trong những đòn bẩy năng suất rõ ràng nhất.
Điều quan trọng cần phân biệt ngay: bài này KHÔNG dạy bạn prompt engineering nói chung (đã có ở Bài 6 và Bài 10), cũng không so sánh Custom GPT với Claude Projects (Bài 13). Ở đây ta đào sâu riêng vào nghệ thuật và kỹ thuật xây dựng một Custom GPT chuyên nghiệp: cấu trúc Instructions, dùng Knowledge files, bật/tắt Capabilities đúng chỗ, gắn Actions để gọi API, và đóng gói thành một sản phẩm nội bộ đáng tin cậy.
Khái niệm cốt lõi
Một Custom GPT thực chất là gói gồm bốn lớp cấu hình chồng lên mô hình nền (GPT của OpenAI). Hiểu rõ vai trò từng lớp là chìa khóa để xây cho chắc.
1. Instructions — bộ não điều khiển hành vi
Đây là phần quan trọng nhất, quyết định 80% chất lượng. Khác với một prompt thông thường mà bạn gõ một lần, Instructions được áp dụng cho MỌI cuộc hội thoại với GPT đó. Vì vậy nó cần được viết như một "bản đặc tả hành vi", không phải một câu hỏi.
Một cấu trúc Instructions chuyên nghiệp nên có các khối rõ ràng:
- Role + Context (Vai trò + bối cảnh): Bạn là ai, làm cho ai, trong ngữ cảnh nào. Ví dụ: "Bạn là trợ lý viết PRD cho team Product của một công ty fintech tại Việt Nam, tuân theo template nội bộ và quy định bảo mật dữ liệu khách hàng."
- Goal (Mục tiêu): GPT này tồn tại để làm gì, output cuối cùng nên trông như thế nào.
- Workflow / Steps (Quy trình): Các bước GPT phải đi qua. Đây là phần khiến GPT "có kỷ luật" thay vì trả lời tùy hứng. Ví dụ: "Bước 1: hỏi đủ 5 thông tin bắt buộc trước khi viết. Bước 2: đề xuất outline. Bước 3: chỉ viết full khi user xác nhận."
- Constraints (Ràng buộc): Những điều KHÔNG được làm. Ví dụ: "Không bịa số liệu thị trường. Nếu thiếu dữ liệu, ghi rõ [CẦN BỔ SUNG]."
- Format (Định dạng output): Markdown, bảng, độ dài, ngôn ngữ.
2. Knowledge — bộ nhớ dài hạn
Bạn có thể tải lên tối đa 20 file (mỗi file tối đa 512 MB, nhưng phần text được index có giới hạn). Đây là cách bạn "nhồi" kiến thức riêng vào GPT: template PRD công ty, brand guideline, tài liệu sản phẩm, FAQ nội bộ. Khi user hỏi, GPT sẽ tra cứu (retrieval) trong các file này thay vì bịa.
Lưu ý quan trọng: Knowledge hoạt động theo cơ chế tìm kiếm đoạn liên quan, không phải đọc toàn bộ file mỗi lần. Vì vậy file nên được đặt tên rõ ràng, chia mục mạch lạc, có tiêu đề. File lộn xộn sẽ khiến retrieval kém chính xác.
3. Capabilities — công cụ tích hợp sẵn
Ba công tắc: Web Browsing (tìm web), DALL·E (tạo ảnh), Code Interpreter / Data Analysis (chạy code, đọc Excel/CSV). Nguyên tắc: chỉ bật cái bạn thực sự cần. Một GPT viết PRD mà bật Web Browsing có thể tự đi tra cứu lung tung và đưa thông tin sai vào tài liệu. Ngược lại, một GPT phân tích dữ liệu mà quên bật Data Analysis thì vô dụng.
4. Actions — cánh tay nối ra hệ thống ngoài
Đây là phần "nâng cao" thật sự. Actions cho phép GPT gọi API bên ngoài qua một schema OpenAPI. Ví dụ: GPT có thể truy vấn Jira lấy danh sách ticket, đọc số liệu từ một endpoint analytics nội bộ, hay tạo trang trong Notion. Đây là thứ biến Custom GPT từ "công cụ trò chuyện" thành "tác nhân có thể hành động" — dù với PM, đa số nhu cầu dừng ở ba lớp đầu.
Tình huống thực tế
Ví dụ 1 — Tiki và "PRD Assistant" chuẩn hóa cho 15 PM
Giả định một team Product khoảng 15 người ở một sàn TMĐT lớn như Tiki. Vấn đề kinh điển: mỗi PM viết PRD một kiểu, người thì thiếu phần success metrics, người thì quên edge case, khiến team engineering liên tục phải hỏi lại, mỗi feature chậm trung bình 2-3 ngày chỉ vì làm rõ yêu cầu.
Trưởng nhóm Product quyết định xây một Custom GPT tên "Tiki PRD Assistant". Trong Instructions, họ nhúng quy trình bắt buộc: GPT phải hỏi đủ 6 thông tin (problem, target user, success metric, scope, non-goals, dependencies) trước khi viết một dòng nào. Phần Knowledge gồm 3 file: template PRD chính thức, một PRD mẫu đạt chuẩn, và checklist review. Họ tắt Web Browsing để tránh GPT tự bịa số liệu thị trường.
Kết quả sau 1 tháng: tỷ lệ PRD bị engineering trả về để làm rõ giảm rõ rệt vì mọi tài liệu đều có cùng cấu trúc và không thiếu mục bắt buộc. Bài học: giá trị lớn nhất của Custom GPT trong team không phải "viết hay hơn" mà là "chuẩn hóa và ép kỷ luật quy trình". Phần Workflow trong Instructions chính là nơi tạo ra giá trị đó.
Ví dụ 2 — Một startup SaaS tại Singapore và "Voice of Customer" GPT
Một startup SaaS B2B quy mô vừa ở Singapore nhận khoảng 400-500 phản hồi khách hàng mỗi tháng từ nhiều kênh: support ticket, khảo sát NPS, review trên G2. PM phụ trách phải tổng hợp thủ công, mất gần 1 ngày mỗi tháng và rất dễ bỏ sót.
Họ xây Custom GPT "VoC Synthesizer". Knowledge chứa file định nghĩa các theme phân loại sẵn (pricing, onboarding, performance, feature gap...) và bảng phân loại mức độ ưu tiên. Instructions yêu cầu GPT: phân loại từng phản hồi vào theme, đánh giá sentiment, gắn cờ những phản hồi nhắc đến churn risk, và xuất ra bảng tóm tắt kèm 3 insight nổi bật nhất. Họ bật Data Analysis để GPT có thể đọc trực tiếp file CSV export từ hệ thống.
PM giờ chỉ cần kéo file CSV vào, 2 phút sau có bản tổng hợp có cấu trúc. Bài học: khi công việc lặp lại + có dữ liệu đầu vào dạng file + cần output theo khung cố định, Custom GPT (kết hợp Data Analysis) thắng xa việc gõ prompt thủ công mỗi lần. Lưu ý đây là dữ liệu khách hàng nên cần cân nhắc kỹ về quyền riêng tư (xem thêm Bài 37 về guardrails).
Ví dụ 3 — Bài học thất bại: GPT "biết tuốt" của một PM solo
Một PM làm việc độc lập tại một công ty edtech ở TP.HCM hào hứng tạo một Custom GPT "tất cả trong một": vừa viết PRD, vừa phân tích đối thủ, vừa soạn email, vừa brainstorm tính năng. Instructions dài hơn 2000 từ, Knowledge nhồi 18 file đủ thể loại.
Kết quả: GPT trả lời chung chung, hay lẫn lộn ngữ cảnh, lúc viết PRD thì lại chèn cả phân tích đối thủ không liên quan. Retrieval kém vì file quá tạp. Sau 2 tuần, anh bỏ dùng.
Bài học: một Custom GPT tốt nên làm MỘT việc thật giỏi, không phải mười việc tàm tạm. Nguyên tắc "một GPT, một job" gần như luôn đúng. Thay vì một GPT khổng lồ, anh nên tách thành 3-4 GPT chuyên biệt, mỗi cái có Instructions gọn và Knowledge sạch.
Hướng dẫn từng bước
Đây là quy trình xây một Custom GPT chuyên nghiệp, áp dụng được ngay.
Bước 1 — Xác định một job duy nhất. Viết ra một câu: "GPT này giúp [ai] làm [việc gì cụ thể] để đạt [kết quả gì]." Nếu bạn không viết được trong một câu, nghĩa là phạm vi đang quá rộng — hãy thu hẹp.
Bước 2 — Soạn Instructions theo khung 5 khối. Mở Notepad trước, viết theo cấu trúc Role + Context → Goal → Workflow → Constraints → Format. Một mẫu khởi đầu:
# ROLE & CONTEXT
Bạn là [vai trò], hỗ trợ [đối tượng] tại [bối cảnh công ty/ngành].
# GOAL
Mục tiêu: [kết quả cuối cùng GPT phải tạo ra].
# WORKFLOW
1. Trước tiên, hỏi đủ các thông tin: [liệt kê].
2. Đề xuất outline và chờ user xác nhận.
3. Sau khi xác nhận, tạo output đầy đủ.
# CONSTRAINTS
- Không bịa số liệu. Thiếu dữ liệu thì ghi [CẦN BỔ SUNG].
- Luôn trả lời bằng tiếng Việt.
- Bám sát template trong Knowledge.
# OUTPUT FORMAT
- Markdown, có heading rõ ràng.
- Kèm bảng khi phù hợp.
Bước 3 — Chuẩn bị và tải Knowledge files. Dọn sạch tài liệu trước khi tải: đặt tên file rõ ràng (vd template-prd-v3.md), chia mục, bỏ phần thừa. Ưu tiên file text/Markdown hơn PDF scan. Tải tối đa những gì thực sự liên quan đến job duy nhất ở Bước 1.
Bước 4 — Bật/tắt Capabilities có chủ đích. Hỏi với mỗi công tắc: "Job này có cần không?" Viết tài liệu → thường tắt Web Browsing. Phân tích dữ liệu → bật Data Analysis. Tạo mockup nhanh → bật DALL·E. Mặc định nên tắt những gì không cần.
Bước 5 — Viết Conversation Starters. Đặt 3-4 câu gợi ý bấm-là-chạy, vừa hướng dẫn user vừa "khóa" họ vào đúng luồng. Ví dụ: "Bắt đầu viết PRD cho tính năng mới", "Review PRD đã có theo checklist".
Bước 6 — Test bằng các ca thực tế và ca biên. Đừng chỉ test câu dễ. Hãy thử: input thiếu thông tin (GPT có hỏi lại không?), input ngoài phạm vi (GPT có từ chối lịch sự không?), input bằng tiếng Việt lẫn tiếng Anh. Mỗi lần phát hiện lỗi, quay lại sửa Instructions — đây là vòng lặp quan trọng nhất.
Bước 7 — (Nâng cao) Gắn Actions nếu cần. Nếu GPT cần lấy/ghi dữ liệu hệ thống ngoài, vào mục Actions, dán OpenAPI schema, cấu hình authentication. Bắt đầu với một action read-only đơn giản trước khi làm những thao tác ghi.
Bước 8 — Đóng gói và chia sẻ. Đặt tên gợi nhớ, mô tả ngắn gọn rõ chức năng, chọn phạm vi chia sẻ (chỉ mình bạn / link / trong workspace của team). Kèm một dòng hướng dẫn dùng cho đồng nghiệp.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi quá nhiều việc vào một GPT. Như Ví dụ 3, "một GPT làm tất cả" gần như luôn thất bại. Mẹo: một GPT, một job.
Lỗi 2 — Instructions viết như prompt một lần. Nhiều người dán nguyên một câu hỏi vào ô Instructions. Hãy viết như đặc tả hành vi lặp lại, dùng cấu trúc 5 khối và ngôi "Bạn là...".
Lỗi 3 — Quên phần Constraints. Không có ràng buộc, GPT sẽ bịa số liệu, trả lời lan man, hoặc làm việc ngoài phạm vi. Constraints quan trọng ngang Workflow.
Lỗi 4 — Tải Knowledge file lộn xộn. PDF scan, file thiếu cấu trúc, đặt tên kiểu final_v2_real.docx khiến retrieval kém. Mẹo: file sạch, có tiêu đề, đặt tên có ý nghĩa.
Lỗi 5 — Không test ca biên. GPT chạy ngon với câu mẫu nhưng vỡ trận khi user nhập thiếu thông tin. Luôn test input thiếu, input sai, input ngoài phạm vi.
Lỗi 6 — Tin tưởng tuyệt đối vào output. Custom GPT vẫn có thể hallucinate, đặc biệt khi câu hỏi vượt ngoài Knowledge. Luôn giữ một bước người kiểm tra với output quan trọng (xem Bài 16 về phát hiện hallucination).
Mẹo vàng: dùng chính ChatGPT để giúp bạn viết Instructions. Mô tả job, nhờ nó soạn bản nháp Instructions theo khung 5 khối, rồi bạn tinh chỉnh. Đây là cách rút ngắn thời gian xây dựng đáng kể.
Mẹo về versioning: Custom GPT không có lịch sử phiên bản. Hãy lưu nội dung Instructions vào một file riêng (Google Doc/Notion) mỗi khi sửa lớn, để có thể quay lại nếu bản mới tệ hơn.
Bài tập thực hành
- Chọn một job lặp lại trong công việc PM của bạn (vd: viết user story, tóm tắt meeting note, soạn release note). Viết một câu mô tả job duy nhất theo mẫu ở Bước 1.
- Soạn Instructions hoàn chỉnh theo khung 5 khối (Role+Context, Goal, Workflow, Constraints, Format) cho job đó. Tối thiểu có 1 ràng buộc chống bịa số liệu.
- Chuẩn bị 1-2 Knowledge file sạch (template hoặc tài liệu mẫu liên quan), đặt tên rõ ràng, tải lên.
- Tạo GPT thật trên ChatGPT, viết 3 Conversation Starters, và bật/tắt Capabilities có chủ đích — ghi lại lý do cho mỗi công tắc.
- Chạy 3 ca test: một input đầy đủ, một input thiếu thông tin, một input ngoài phạm vi. Ghi lại GPT phản ứng thế nào và sửa Instructions ít nhất một lần dựa trên kết quả.
- (Nâng cao) Viết ra một kịch bản trong đó GPT của bạn sẽ cần một Action (gọi API ngoài). Mô tả endpoint cần gọi và dữ liệu trả về — chưa cần cấu hình thật, chỉ thiết kế.
Tóm tắt
- Một Custom GPT chuyên nghiệp gồm bốn lớp: Instructions (quan trọng nhất), Knowledge, Capabilities, và Actions (nâng cao).
- Instructions nên viết theo khung 5 khối: Role+Context → Goal → Workflow → Constraints → Format. Đây là nơi tạo ra giá trị chuẩn hóa và kỷ luật quy trình.
- Nguyên tắc bất biến: một GPT, một job. GPT "biết tuốt" gần như luôn thất bại.
- Knowledge chỉ mạnh khi file sạch, có cấu trúc, đặt tên rõ. Capabilities chỉ bật cái thực sự cần.
- Vòng lặp test ca biên → sửa Instructions là phần quyết định một GPT dùng được hay không.
- Với PM, giá trị lớn nhất không phải "AI viết hay hơn" mà là biến công việc lặp lại thành một quy trình một-chạm, nhất quán cho cả team — đồng thời luôn giữ một bước người kiểm tra output quan trọng.