Hướng dẫn xung quanh UX: thông báo App, từ chối App và cách ứng xử trong hội thoại

1. Tại sao cần quản lý UX bằng hướng dẫn

Từ góc nhìn của ChatGPT, App của bạn chỉ là các công cụ và widget bổ sung. Nhưng với người dùng, đó là một giao diện riêng biệt đột ngột xuất hiện giữa cuộc trò chuyện. Nếu không kiểm soát hành vi của mô hình, bạn có thể nhận hai kịch bản cực đoan.

Ở một phía, GPT bỏ qua App và cố gắng “giải quyết mọi thứ bằng lời”. Người dùng nhờ chọn quà, nhưng thay vì khởi chạy GiftGenius, mô hình đưa ra một bài viết dài với các khuyến nghị “từ bản thân”. Đôi khi cũng ổn, nhưng bạn đâu viết App để nó phủ bụi trên kệ.

Ở phía còn lại, GPT lại lạm dụng App. Chỉ cần ai hỏi kiểu “Dịch vụ của bạn làm được gì?” là nó khởi chạy widget, render một biểu mẫu khó hiểu, người dùng hoảng và đóng tất cả. Nhìn từ góc độ UX, điều này rất phiền.

Vì thế logic rất đơn giản: cần cố định rõ hành vi, giống như bạn cố định schema JSON của công cụ hay props của component React. System‑prompt (và các hướng dẫn đi kèm) ở đây là “giao thức UX” của bạn. Trong đó, bạn mô tả khi nào và cách trợ lý:

• thông báo việc khởi chạy App;
• chủ động không khởi chạy App mà trả lời bằng văn bản;
• hành xử sau khi widget đã hiển thị kết quả;
• tôn trọng yêu cầu của người dùng “không dùng ứng dụng”.

Tất cả điều này không phải về marketing hay phong cách trò chuyện. Nó thực sự ảnh hưởng đến tần suất App của bạn được gọi và mức độ thoải mái của người dùng.

Tiếp theo từng bước: trợ lý nên thông báo khởi chạy App ra sao, trường hợp nào tốt hơn là không đề xuất widget, hành xử thế nào sau khi ứng dụng hoàn thành, cách tôn trọng yêu cầu rõ ràng về định dạng hội thoại và cách gói gọn tất cả quy tắc này vào system‑prompt.

2. Thông báo App: model nên “báo trước” về widget như thế nào

Khi ChatGPT quyết định sử dụng App, giao diện sẽ thay đổi: trong chat xuất hiện thẻ widget, đôi khi ở dạng toàn màn hình, có nút và các thành phần UI khác. Nếu trợ lý chỉ hiển thị widget mà không giải thích, người dùng có thể không hiểu chuyện gì vừa xảy ra và khối đó từ đâu ra.

Vì vậy, phép lịch sự là trước hết giải thích bằng văn bản điều sắp diễn ra, rồi mới khởi chạy App. Điều này giống như trình duyệt hỏi: “Mở cửa sổ mới?” hay ứng dụng di động cảnh báo: “Chúng tôi sắp xin quyền truy cập camera”.

Các kiểu thông báo

Có thể tạm chia thành ba phong cách thông báo.

Thứ nhất — đề nghị nhẹ nhàng. Trợ lý nói kiểu: “Tôi có thể mở ứng dụng GiftGenius để chọn quà theo tham số của bạn. Có mở không?” và chờ trả lời “có/không”. Cách này hiệu quả khi người dùng mới làm quen với dịch vụ hoặc nhạy cảm với việc thay đổi giao diện.

Thứ hai — khuyến nghị dứt khoát. Nếu App là giao diện chính của sản phẩm, bạn có thể viết: “Tôi sẽ khởi chạy ứng dụng GiftGenius và hiển thị vài lựa chọn quà dưới dạng thẻ.” Trợ lý vẫn có thể chấp nhận từ chối, nhưng mặc định hành động quyết đoán hơn.

Thứ ba — thông báo trung lập. Ở đây trợ lý chỉ nói: “Đang khởi chạy ứng dụng GiftGenius để chọn quà…”, không giải thích dài. Phong cách này phù hợp khi người dùng đã thấy App của bạn nhiều lần và mong đợi nó xuất hiện.

Điều quan trọng là tất cả biến thể này có thể và nên được “đóng gói” vào system‑prompt. Model sẽ không bịa ra câu UX từ số 0 nếu bạn đã đưa cho nó khung sườn.

Ví dụ code nhỏ: phần về thông báo trong system‑prompt

Hãy tưởng tượng trong template Next.js của bạn có file appDefinition.ts, nơi bạn đặt system‑prompt cho App:

// app/appDefinition.ts
export const systemPrompt = `
# Vai trò
Bạn là ChatGPT App GiftGenius, hỗ trợ chọn quà tặng.

# Đối thoại và UX — Thông báo ứng dụng
Nếu bạn quyết định khởi chạy widget GiftGenius,
trước hết hãy giải thích bằng một đến hai câu,
rằng sắp mở một ứng dụng với bộ sưu tập quà tặng
và nó sẽ giúp gì cho người dùng.
`;

Đây chưa phải hợp đồng hoàn chỉnh, nhưng chỉ một đoạn nhỏ thế này cũng đã tăng mạnh tính dự đoán trong hành vi.

Khi nào việc thông báo đặc biệt quan trọng

UI của bạn càng phức tạp, việc báo trước càng quan trọng. Nếu widget chỉ hiển thị ba thẻ quà tặng — đó là thay đổi ngữ cảnh tương đối nhẹ. Còn nếu bạn mở một wizard nhiều bước với bộ lọc, ngân sách, danh mục, v.v., người dùng cần hiểu vì sao cuộc trò chuyện bỗng biến thành “ứng dụng web nhỏ trong chat”.

Các hướng dẫn UX chính thức cũng nhấn mạnh rằng trợ lý phải liên kết rõ ràng văn bản và UI, chứ không nên lặng lẽ gắn widget vào câu trả lời.

3. Khi nào chủ động không đề xuất App

Lỗi thường gặp ở giai đoạn đầu phát triển App là hiệu ứng “có búa thì cái gì cũng là đinh”. Vì có GiftGenius đẹp đẽ, model bắt đầu kéo nó vào mọi cuộc trò chuyện. Người dùng hỏi: “Ứng dụng của bạn làm được gì?”, còn ChatGPT đã: “Đang khởi chạy GiftGenius…”, trong khi người ta chỉ cần hai dòng giải thích.

Để tránh điều này, trong system‑prompt cần mô tả các tình huống nên không đề xuất App. Dưới đây là vài kịch bản điển hình.

• Thứ nhất, câu hỏi làm quen. Nếu ai đó viết kiểu “GiftGenius làm gì?” hoặc “Các bạn hoạt động thế nào?”, hướng dẫn cần yêu cầu trước hết đưa một giải thích ngắn bằng văn bản, không mở UI. Widget chỉ làm xao nhãng ở đây.
• Thứ hai, yêu cầu quá chung chung hoặc mơ hồ. Người dùng viết “Kể về quà tặng cho dịp Năm mới” — đây thiên về câu hỏi mang tính phổ quát hơn là chọn lựa cụ thể. Trợ lý có thể giải thích ngắn các nguyên tắc chung, đặt câu hỏi làm rõ, và chỉ khi có tham số cụ thể (ngân sách, người nhận, danh mục) mới đề xuất App.
• Thứ ba, yêu cầu ngoài phạm vi App. Nếu ai đó nói: “Hãy giúp viết CV”, còn App của bạn dành cho quà tặng, hành vi đúng là trả lời như ChatGPT thông thường và không khởi chạy gì cả. Đôi khi có thể nhắc khéo App dùng để làm gì, nhưng không nên áp đặt khi nó rõ ràng không liên quan.
• Thứ tư, từ chối UI một cách rõ ràng. Nếu người dùng viết: “Đừng mở bất kỳ ứng dụng nào, chỉ giải thích bằng văn bản”, model bắt buộc phải tuân theo, ngay cả khi thấy đây là kịch bản hoàn hảo cho App.

Bảng: loại yêu cầu và hành vi của trợ lý

Bổ sung quy tắc từ chối App vào system‑prompt

Tiếp tục với systemPrompt đó, thêm khối về khi nào không khởi chạy App:

export const systemPrompt = `
# Vai trò
Bạn là ChatGPT App GiftGenius, hỗ trợ chọn quà tặng.

# Khi KHÔNG khởi chạy widget
Nếu người dùng chỉ hỏi về khả năng của dịch vụ,
hoặc đặt câu hỏi lý thuyết chung về quà tặng,
trước hết hãy trả lời bằng văn bản và không mở ứng dụng.

Nếu yêu cầu không liên quan đến việc chọn quà,
hãy trả lời như ChatGPT thông thường và không đề xuất GiftGenius.

Nếu người dùng yêu cầu rõ ràng không dùng ứng dụng,
hãy tôn trọng điều đó và chỉ trao đổi trong chat.
`;

Văn bản như vậy chuyển thành các quyết định cụ thể của model trong những tình huống ranh giới, nơi nếu không nó có thể “kéo chăn” về phía UI. Chúng ta đã cố định khi nào App không cần thiết. Giờ quan trọng là mô tả vế còn lại: làm gì khi widget đã chạy xong và người dùng thấy kết quả.

4. Hành vi sau khi sử dụng App: follow‑up và kết thúc kịch bản

Trong module về widget, bạn đã thấy cách các thông điệp follow‑up giúp tiếp tục đối thoại sau khi UI hoàn thành. Widget hiển thị các thẻ, và bên dưới trợ lý viết kiểu: “Tôi đã tìm được các lựa chọn quà cho đồng nghiệp trong ngân sách đến $50. Bạn có muốn tôi hiển thị rẻ hơn hay đổi danh mục?” và đề xuất các nút cho hành động phổ biến.

Giờ nhiệm vụ của chúng ta là cố định hành vi này trong hướng dẫn, thay vì trông chờ vào “trực giác” của model.

Trợ lý nên làm gì sau widget

Trong kịch bản lý tưởng sẽ có vài bước.

• Trước hết trợ lý tóm tắt ngắn gọn kết quả App bằng lời. Dù widget có hiển thị mười thẻ, vẫn hữu ích khi viết: “Tôi đã chọn 4 phương án quà cho đồng nghiệp trong ngân sách đến $50. Trong đó có cốc in theo yêu cầu, cây để bàn, bộ cà phê ngon và sổ tay phong cách.”
• Sau đó đưa ra các bước tiếp theo. Ở đây các câu follow‑up soạn sẵn sẽ hữu ích: “Bạn muốn xem các lựa chọn rẻ hơn không?”, “Cần thu hẹp theo sở thích chứ?”, “Chỉ hiển thị những món có sẵn tại khu vực của bạn?” Chính các câu này bạn có thể dùng trong sendFollowUpMessage của widget, đồng thời khuyến nghị model trong system‑prompt.
• Cuối cùng, nếu người dùng rõ ràng kết thúc kịch bản (“Cảm ơn, thế là đủ”), trợ lý “đóng” chủ đề một cách nhẹ nhàng: xác nhận nhiệm vụ đã xong và đề nghị hỗ trợ việc khác.

Lưu đồ: câu hỏi → widget → follow‑up

Để trực quan, có thể hình dung hành vi của trợ lý như một máy trạng thái đơn giản.

flowchart TD
    U[Người dùng đặt nhiệm vụ] --> G[GPT quyết định: có khởi chạy App không?]
    G -->|Có| A[Thông báo việc khởi chạy App]
    A --> W[Widget GiftGenius đề xuất phương án]
    W --> S[Trợ lý tóm tắt kết quả]
    S --> F[Trợ lý đề xuất các lựa chọn follow‑up]
    F -->|Người dùng chọn hành động| G
    G -->|Không, không khởi chạy App| T[Câu trả lời dạng văn bản, không UI]
    F -->|"Người dùng nói \"Cảm ơn\""| E[Trợ lý kết thúc kịch bản và đề nghị hỗ trợ khác]

Dòng chảy như vậy chúng ta thực chất đang mô tả bằng lời trong system‑prompt.

Ví dụ code: follow‑up từ widget

Về phía UI bạn đã biết cách gửi thông điệp follow‑up. Để đầy đủ, đây là ví dụ đơn giản về một component mà sau khi bấm nút sẽ yêu cầu model “mở rộng ngân sách”:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Hiển thị các lựa chọn với ngân sách lớn hơn một chút"
        );
    };

    return <button onClick={onClick}>Tôi muốn các lựa chọn đắt hơn</button>;
}

Bây giờ chúng ta sẽ thêm vào system‑prompt đoạn văn bản hướng dẫn model xử lý các thông điệp follow‑up như vậy.

// tiếp theo systemPrompt
const followUps = `
# Hành vi sau khi khởi chạy ứng dụng
Sau khi widget hiển thị danh sách quà,
hãy mô tả ngắn gọn kết quả bằng văn bản.

Sau đó đề xuất 1–3 bước tiếp theo rõ ràng
(ví dụ: hiển thị rẻ hơn, thay đổi ngân sách, đổi danh mục).
Nếu widget gửi thông điệp follow‑up,
hãy dùng nó như gợi ý cho bước kế tiếp.
`;

Về mặt kỹ thuật đây chỉ là một chuỗi. Còn về UX — nó là nền tảng cho một kịch bản có thể dự đoán.

5. Tôn trọng ý định của người dùng

Những gì chúng ta bàn ở trên là kỳ vọng sản phẩm của bạn về hành vi của App. Hướng dẫn UX sẽ hoạt động kém nếu model không “lắng nghe” người dùng. Ngay cả App được thiết kế hoàn hảo cũng phải nhường bước nếu người dùng rõ ràng yêu cầu không đổi định dạng tương tác.

Có một vài tình huống điển hình.

• Nếu người dùng nói thẳng rằng không muốn khởi chạy ứng dụng (“Không UI, hãy giải thích bằng văn bản xem tôi nên mua gì”), trợ lý cần coi đó là ràng buộc cứng và không tìm cách lách. Có thể lịch sự nói: “Ok, tôi sẽ chỉ trả lời bằng văn bản”, và sau đó thực sự giữ lời.
• Nếu người dùng lo thứ gì đó sẽ tự động chạy, hãy giúp họ có cảm giác kiểm soát. Ví dụ: “Tôi có thể mở ứng dụng chọn quà, nhưng nếu bạn thích, chúng ta có thể thảo luận ngay trong chat. Bạn thấy tiện cách nào hơn?” Ở đây bạn đưa ra lựa chọn rõ ràng.
• Nếu người dùng viết “Tôi đang dùng điện thoại, đừng mở biểu mẫu phức tạp” — đó cũng là một phần ngữ cảnh. Trợ lý cần chấp nhận và, chẳng hạn, chỉ đưa một danh sách ý tưởng ngắn kèm câu hỏi làm rõ.

Nhúng sự tôn trọng vào hợp đồng

Tất cả có thể gói gọn trong system‑prompt:

export const respectBlock = `
# Ưu tiên ý định của người dùng
Luôn tính đến các yêu cầu rõ ràng của người dùng
về định dạng trao đổi.

Nếu họ yêu cầu không khởi chạy ứng dụng hay widget,
đừng đề xuất và đừng khởi chạy GiftGenius,
dù điều đó có thể giúp giải quyết nhiệm vụ.
Thay vào đó, hãy hỗ trợ bằng văn bản.
`;

Như vậy bạn cố định rõ “ai là người quyết định” trong cuộc đối thoại. Và bật mí: đó không phải là niềm tự hào về UI đẹp của bạn, mà là con người ở phía bên kia màn hình.

6. Cách trình bày hướng dẫn UX trong system‑prompt và tài liệu

Chúng ta đã liệt kê khá nhiều quy tắc hành vi — từ thông báo App đến thông điệp follow‑up và tôn trọng định dạng hội thoại. Giờ không chỉ quan trọng nói gì với model, mà còn trình bày thế nào trong system‑prompt và tài liệu.

System‑prompt trong App thực tế sẽ phình to rất nhanh. Nếu viết như một đoạn văn liền mạch, sau một tuần chẳng ai tìm được gì. Hãy coi nó như đặc tả kỹ thuật hay README: cần cấu trúc hoá.

Thực hành tốt — chia prompt thành các phần logic có tiêu đề. Ví dụ: “Vai trò và phạm vi trách nhiệm”, “Khi dùng App”, “Khi không dùng App”, “Đối thoại và UX”, “Bảo mật và giới hạn”. Trong mỗi phần, viết câu ngắn, rõ ràng, một nghĩa.

Còn tốt hơn nữa — đưa system‑prompt ra file riêng cạnh code, thay vì nhét nó vào literal chuỗi giữa component. Như vậy sẽ dễ review, so sánh thay đổi và thảo luận với product hay pháp lý.

Ví dụ tổ chức system‑prompt trong code

Một cách là lưu các phần của prompt vào các chuỗi riêng và ghép lại:

// app/prompt/role.ts
export const roleSection = `
# Vai trò
Bạn là ChatGPT App GiftGenius.
Bạn giúp người dùng chọn quà theo nhiệm vụ và ngân sách.
`;

// app/prompt/ux.ts
export const uxSection = `
# Đối thoại và UX
Trước khi khởi chạy widget GiftGenius
hãy giải thích ngắn gọn rằng sắp mở ứng dụng với các thẻ quà tặng.
Đừng khởi chạy ứng dụng cho các câu hỏi chung hay lý thuyết,
trừ khi người dùng yêu cầu rõ việc chọn quà.
Sau khi widget hoàn thành, hãy tóm tắt kết quả bằng văn bản
và đề xuất 1–3 bước tiếp theo.
`;

// app/appDefinition.ts
import { roleSection } from "./prompt/role";
import { uxSection } from "./prompt/ux";

export const systemPrompt = `
${roleSection}
${uxSection}
`;

Cách chia nhỏ này giúp bạn nghĩ về hướng dẫn như các module riêng: phần UX, bảo mật, làm việc với công cụ, v.v. Điều này đặc biệt hữu ích khi bạn bổ sung tính năng mới và cần thống nhất hành vi giữa nhiều nhóm.

Ngoài ra, tài liệu về App (README nội bộ, Confluence, Notion) cũng nên đồng bộ với các phần này. Ở đó bạn có thể mô tả bằng ngôn ngữ đời thường vì sao lại thông báo App như vậy và vì sao không khởi chạy cho các yêu cầu thử. Ghi rõ các câu follow‑up nên như thế nào. Nhờ vậy, người mới vào đội sẽ không tìm cách “sửa” prompt khi chưa hiểu bạn đã làm gì.

7. Thực hành: viết lại phần UX cho GiftGenius của chúng ta

Hãy gộp tất cả vào một ví dụ system‑prompt tương đối đầy đủ. Giả sử trước đây chúng ta có system‑prompt rất sơ sài:

export const systemPrompt = `
Bạn là ứng dụng GiftGenius.
Hãy chọn quà cho người dùng.
`;

Văn bản như vậy không nói gì về khi nào khởi chạy App, cách thông báo và làm gì sau widget. Hãy thêm hướng dẫn UX từng bước.

Đầu tiên, xác định rõ phạm vi trách nhiệm và định dạng làm việc:

const role = `
# Vai trò
Bạn là ChatGPT App GiftGenius.
Nhiệm vụ của bạn là giúp người dùng chọn 3–7 món quà phù hợp
theo ngân sách, người nhận và dịp.
Bạn có thể dùng widget GiftGenius để chọn trực quan.
`;

Sau đó mô tả cách thông báo khởi chạy:

const announce = `
# Thông báo ứng dụng
Nếu thấy widget GiftGenius sẽ giúp tốt hơn,
trước hết hãy giải thích trong một đến hai câu
rằng sắp mở ứng dụng với các thẻ quà tặng
và người dùng có thể xem và lọc chúng.
Chỉ sau đó mới khởi chạy ứng dụng.
`;

Thêm quy tắc khi không khởi chạy App:

const noApp = `
# Khi không dùng ứng dụng
Nếu người dùng chỉ hỏi về khả năng của dịch vụ
hoặc muốn thông tin lý thuyết chung về quà tặng,
hãy trả lời bằng văn bản và không khởi chạy GiftGenius.

Nếu yêu cầu không liên quan đến quà tặng (ví dụ, về CV hay code),
hãy trả lời như ChatGPT thông thường và không đề xuất ứng dụng.

Nếu người dùng yêu cầu không dùng ứng dụng,
coi đó là ràng buộc bắt buộc.
`;

Và kết thúc bằng hành vi sau khi dùng widget:

const afterWidget = `
# Hành vi sau widget
Sau khi widget hiển thị các lựa chọn quà,
hãy mô tả ngắn gọn kết quả bằng lời.
Đề xuất cho người dùng 1–3 bước tiếp theo
(ví dụ: thay đổi ngân sách, lọc theo sở thích,
chỉ hiển thị các lựa chọn rẻ hơn).

Nếu widget đã gửi thông điệp follow‑up,
hãy dùng nó như tín hiệu chính cho bước tiếp theo.
`;

System‑prompt cuối cùng có thể như sau:

export const systemPrompt = `
${role}
${announce}
${noApp}
${afterWidget}
`;

Đến đây nó đã giống một đặc tả hành vi hơn là “điều ước”. Ở các module sau, bạn sẽ bổ sung hợp đồng này với hướng dẫn về bảo mật, ảo giác, thương mại và nhiều niềm vui khác của cuộc sống “trưởng thành” của App, nhưng phần UX đã là nền tảng.

8. Những lỗi thường gặp khi thiết lập hướng dẫn UX

Lỗi 1: “App luôn tốt hơn văn bản”.
Đôi khi các nhà phát triển quá tự hào về widget của mình đến mức yêu cầu model gọi nó ở mọi cơ hội. Kết quả là người dùng nhận App cả ở nơi họ chỉ muốn hỏi “đây là cái gì vậy?”. Model trở nên áp đặt, và mọi người bắt đầu phớt lờ ứng dụng. Cách đúng là viết rõ các kịch bản khi App không cần thiết, và tôn trọng các trường hợp đó.

Lỗi 2: thiếu thông báo rõ ràng trước khi khởi chạy App.
Nếu trợ lý im lặng khởi chạy widget, người dùng sẽ không hiểu khối UI từ đâu ra và phải làm gì với nó. Hướng dẫn của OpenAI và kinh nghiệm thực tế cho thấy: một hai câu “bây giờ tôi sẽ mở ứng dụng làm X” cải thiện UX rõ rệt và giảm bối rối.

Lỗi 3: đề xuất App quá hung hăng nhiều lần.
Có trường hợp App sau mỗi câu trả lời lại đề nghị mở widget: “Bạn có muốn mở lại ứng dụng không? Còn bây giờ? Còn tiếp theo?” Điều này nhanh chóng thành spam. Tốt hơn là cố định trong hướng dẫn rằng sau lần dùng đầu tiên của App cần nhìn vào ngữ cảnh: chỉ đề xuất lại nếu người dùng rõ ràng thay đổi tham số nhiệm vụ hoặc tự yêu cầu “hiển thị thêm”.

Lỗi 4: phớt lờ việc người dùng từ chối dùng ứng dụng.
Những câu như “làm ơn đừng dùng ứng dụng” hay “tôi dùng điện thoại, không tiện làm với form” phải được coi là ràng buộc cứng. Nếu model vẫn áp đặt App, người dùng sẽ mất niềm tin vào cả trợ lý lẫn sản phẩm. Trong system‑prompt, việc này có thể cố định chỉ với vài câu, nhưng nhiều người lại quên làm.

Lỗi 5: thiếu phần tóm tắt và thông điệp follow‑up sau widget.
Đôi khi widget hiển thị lựa chọn đàng hoàng, nhưng trợ lý sau đó lại im lặng. Người dùng thấy UI mà không hiểu làm gì tiếp. Không có văn bản, không có câu hỏi, không có nút cho hành động phổ biến. Kịch bản như vậy trông dang dở và làm đứt mạch hội thoại. Hãy luôn ghi trong hướng dẫn rằng sau widget phải có phần tóm tắt ngắn và 1–3 bước tiếp theo rõ ràng.

Lỗi 6: trộn lẫn UX sản phẩm và “phong cách chung của ChatGPT” trong một đoạn.
Đôi khi system‑prompt biến thành một bài văn dài: “Hãy thân thiện, dùng emoji, thỉnh thoảng đùa nếu phù hợp. À, và có thể, đôi lúc hãy khởi chạy App.” Trong văn bản như vậy rất khó nhận ra quy tắc UX thực sự. Tốt hơn là tách thành các mục riêng với tiêu đề rõ: “Vai trò”, “Đối thoại và UX”, “Khi dùng App”, “Khi không dùng App”. Điều này giúp cả model lẫn những người sẽ làm việc với prompt sau bạn.