Luồng người dùng: cách GPT đề xuất App và gọi các chức năng của nó

1. Giới thiệu

Hãy tưởng tượng bạn đang viết một web service bình thường. Mọi thứ khá đơn giản: bạn có URL /search, người dùng nhấn nút, bạn gọi controller searchController. Trong thế giới ChatGPT Apps, người dùng không thấy /search. Họ viết bằng ngôn ngữ tự nhiên:

“Gợi ý quà cho anh trai game thủ, tối đa $50”

Và sau đó:

• mô hình quyết định: “Ồ, đây là về quà tặng, mình có GiftGenius, cái này làm được”;
• GPT tự “nhấn nút” — gọi các công cụ (tools) của App của bạn;
• đôi khi còn đề xuất với người dùng: “Bạn có muốn mở GiftGenius để mình hiển thị các lựa chọn không?”.

Điểm then chốt: người dùng bày tỏ ý định, còn mô hình là bên “nhấn nút”. Nếu không hiểu luồng này, rất dễ:

• viết các công cụ với tên vô nghĩa (run_func, doStuff),
• tạo ra App mà không bao giờ được mô hình đề xuất hoặc bị gọi sai ngữ cảnh,
• xây widget kiểu “nhảy ra từ bụi” làm hỏng cuộc đối thoại.

Vì vậy trong bài này, ta sẽ xây dựng mô hình tư duy: GPT biết về App của bạn bằng cách nào và trong những điểm nào của cuộc hội thoại nó “lồng” App vào.

Insight: ứng dụng — là một plugin cho ChatGPT

Khác với các ứng dụng trên điện thoại hay mini‑app trong WeChat, ứng dụng trong ChatGPT được tổ chức theo cách khác.

ChatGPT tự quyết định khi nào khởi chạy ứng dụng của bạn và gọi chức năng nào của nó. Ứng dụng trong ChatGPT có thể can thiệp (dù có giới hạn) vào logic của chat. Mục tiêu và điểm mạnh của chúng — là mở rộng khả năng chính của ChatGPT.

Nếu ChatGPT có thể giải quyết hoàn hảo vấn đề của người dùng — nó không cần gọi ứng dụng của bạn. Nếu ChatGPT hoàn toàn không thể giải quyết — người dùng cũng sẽ không hỏi về việc đó. Tình huống lý tưởng là khi ChatGPT chỉ có thể đáp ứng một phần yêu cầu của người dùng. Nghĩa là có nhu cầu, có nhiều yêu cầu, nhưng kết quả chưa đủ tốt.

Chính lúc đó ChatGPT gọi ứng dụng của bạn và hai bên cùng làm người dùng hài lòng. Người dùng hạnh phúc hơn, còn bạn — giàu hơn.

2. Cách khởi chạy ChatGPT App từ góc nhìn người dùng

Người dùng không có nút “gọi MCP‑server và call_tool”, nhưng họ có ô nhập văn bản và (đôi khi) menu ứng dụng. Với họ có hai sơ đồ khởi chạy cơ bản: tường minh và ngầm định.

Khởi chạy tường minh (explicit)

Đây là kịch bản khi người dùng chủ ý chọn App của bạn.

Các trường hợp điển hình:

• họ tìm App trong Store của ChatGPT và nhấn “Mở”;
• họ chọn App trong launcher (ví dụ qua nút + ở ô nhập văn bản (Composer));
• họ bắt đầu thông điệp bằng tên ứng dụng: “GiftGenius, hãy gợi ý quà…” — gọi là named mention. Nếu tên App đứng ở đầu prompt, ChatGPT sẽ tự động đưa App của bạn vào ngữ cảnh trả lời.

Trong chế độ tường minh, ngay từ đầu mô hình đã biết: người dùng đến đây để làm việc với App này. Vì vậy:

• GPT gọi tools của bạn thường xuyên và chủ động hơn;
• UI‑widget của App có thể xuất hiện ngay trong câu trả lời đầu tiên;
• GPT ít khi “phớt lờ” App và tự trả lời hơn.

Ví dụ “ruột”: người dùng mở trực tiếp GiftGenius vì muốn “nghịch” việc chọn quà. Họ nhấn vào App trong danh sách, GPT hiển thị lời chào kiểu:

“Xin chào! Mình là GiftGenius, sẽ giúp bạn chọn quà. Hãy cho biết người nhận là ai và ngân sách khoảng bao nhiêu?”

Và sau đó chủ động dùng công cụ của bạn để tìm kiếm.

Khởi chạy ngầm định (implicit / suggested)

Một kịch bản khác hẳn: người dùng hoàn toàn không nghĩ về App. Họ chỉ gõ trong cuộc chat thông thường:

“Gợi ý quà sinh nhật cho mẹ, bà thích làm vườn, ngân sách đến $100”

GPT phân tích yêu cầu và nhận thấy rằng:

• trong hệ sinh thái có App GiftGenius, tools của nó được mô tả là “Use this when the user wants to get gift recommendations”;
• nhiệm vụ và ràng buộc (quà tặng, ngân sách, sở thích) khớp rất tốt với App này.

Khi đó mô hình có thể “nhẹ nhàng xen vào” với đề nghị:

“Mình có thể dùng ứng dụng GiftGenius để chọn ra các phương án quà tặng cụ thể và hiển thị dưới dạng thẻ. Bạn có muốn mở không?”

Nếu người dùng đồng ý — GPT sẽ gọi công cụ phù hợp của App và có thể render widget của bạn.

Quan trọng là bạn không hề viết if (prompt.includes("quà")) openApp(). Mô hình đưa ra quyết định tự thân, dựa trên:

• văn bản yêu cầu và lịch sử hội thoại;
• metadata của các công cụ (tên, mô tả, schema tham số);
• trạng thái kết nối của người dùng với App (đã đăng nhập hay chưa), có phải người dùng doanh nghiệp hay không.

Bạn không can thiệp thuật toán, mà ảnh hưởng bằng cách “mô tả” App và tools để mô hình hiểu.

Lai: khi GPT hỏi làm rõ rồi mới đề xuất App

Đôi khi người dùng viết điều gì đó rất chung chung:

“Cần nghĩ gì đó tặng đồng nghiệp, mình chưa có ý tưởng gì cả”

Mô hình hiểu GiftGenius có thể giúp, nhưng thông tin quá mơ hồ. Mẫu phổ biến:

1. GPT đặt 1–2 câu hỏi làm rõ qua văn bản.
2. Sau đó đề xuất khởi chạy App: “Mình có công cụ chọn quà. Có muốn mình mở nó và hiển thị các phương án không?”.

Đây là UX tốt: người dùng không cảm thấy bị “ép chuyển sang ứng dụng khác”.

3. Discovery: GPT tìm thấy App của bạn như thế nào

Giờ hãy xem mọi thứ trông ra sao từ phía mô hình.

Trong tài liệu Apps SDK, điều này gọi là Discovery — mọi cách mà người dùng và mô hình biết đến App của bạn. Đó có thể là yêu cầu tự nhiên trong chat, danh mục ứng dụng (catalog), và các “điểm vào” đặc biệt như launcher.

Mô hình biết App của bạn tồn tại từ đâu

Khi đăng ký, ChatGPT khởi chạy App của bạn và nó (qua MCP) tự giới thiệu: liệt kê các công cụ khả dụng cùng schema của chúng — tên, mô tả, JSON‑schema của tham số đầu vào. Thông tin về ứng dụng sẽ cần điền khi đăng ký, còn thông tin về công cụ ChatGPT sẽ tự lấy qua MCP‑method list_tools.

Mô hình không thấy mã nguồn của bạn, nó chỉ có quyền truy cập:

• tên công cụ (name);
• mô tả (description);
• chữ ký đầu vào (inputSchema).

Chính những thứ này trở thành “API dành cho mô hình”. Nếu bạn đặt tên công cụ là run_func với mô tả “Executes the function”, mô hình sẽ không hiểu khi nào cần gọi. Nếu bạn đặt là suggest_gifts với mô tả “Use this when the user wants gift ideas based on recipient, occasion and budget” — mọi thứ trở nên rõ ràng.

Named mention và in‑conversation discovery

Spec chính thức của Apps SDK nêu hai cơ chế then chốt:

• Named mention — khi người dùng bắt đầu thông điệp bằng tên App của bạn. Trường hợp này App gần như chắc chắn sẽ được nâng lên và sử dụng trong câu trả lời.
• In‑conversation discovery — khi người dùng chỉ viết yêu cầu, còn mô hình quyết định có nên kết nối App hay không. Khi đó sẽ xét đến:
  • ngữ cảnh cuộc trò chuyện (lịch sử tin nhắn, kết quả các tool trước đó, sở thích người dùng);
  • các đề cập thương hiệu rõ ràng trong văn bản;
  • metadata của tools — tên, mô tả, tài liệu tham số;
  • trạng thái “link” — người dùng đã liên kết với App chưa (đã đăng nhập, đã cấp các quyền cần thiết hay chưa).

Lập trình viên chỉ ảnh hưởng gián tiếp: qua metadata chất lượng và các UX pattern, chứ không phải qua if/else trong code.

Catalog và launcher

Ngoài cách qua hội thoại, còn có Store bên trong ChatGPT và launcher trong composer. Qua đó người dùng có thể chọn App một cách tường minh, giống như trong cửa hàng ứng dụng.

Với chúng ta, điều này quan trọng về mặt khái niệm: khi thiết kế luồng của GiftGenius, cần nhớ rằng:

• có người sẽ vào qua catalog và lập tức ở “bên trong” App;
• có người chẳng bao giờ duyệt catalog và chỉ thấy App như đề xuất trong hội thoại.

Tất cả những điều này — là về discovery của chính App: các thời điểm mà mô hình quyết định có nên “nâng” ứng dụng của bạn lên và đề xuất nó cho người dùng trong cuộc trò chuyện hiện tại hay không.

4. Giải phẫu vòng tương tác: từ câu chữ đến widget

Đến lúc gom các tầng trong bài trước — từ ChatGPT UI và widget đến Apps SDK và MCP‑server — vào một chu trình logic dễ hiểu.

Sơ đồ cấp cao

Về mặt quy trình, vòng lặp trông như sau:

sequenceDiagram
    participant U as Người dùng
    participant G as ChatGPT (mô hình)
    participant A as App / MCP-server

    U->>G: Yêu cầu văn bản
    G->>G: Phân tích yêu cầu + chọn tools
    G->>A: Gọi công cụ (call_tool)
    A-->>G: Phản hồi (dữ liệu / structuredContent)
    G->>U: Câu trả lời văn bản + (tuỳ chọn) widget của App

Nói theo ngôn ngữ đời thường:

1. Người dùng viết một tin nhắn trong ChatGPT.
2. Mô hình phân tích yêu cầu và ngữ cảnh hiện tại, rồi quyết định:
   • tự trả lời,
   • hay gọi một hoặc vài công cụ.
3. Nếu chọn công cụ của App bạn, ChatGPT tạo một yêu cầu có cấu trúc (call_tool) và gửi đến MCP‑server.
4. Backend (hoặc MCP‑server) của bạn thực thi hành động: truy vấn CSDL, API bên ngoài, ACP, v.v., và tạo kết quả.
5. Kết quả được trả về dưới dạng dữ liệu có cấu trúc (và có thể là JSON cho widget).
6. Mô hình dùng các dữ liệu này để:
   • sinh ra văn bản dễ hiểu với người dùng,
   • khi cần — vẽ widget của App ngay trong câu trả lời.

Mọi lập kế hoạch nhiều bước — “khi nào gọi cái gì”, “có hỏi làm rõ không”, “có thực hiện thêm lần gọi nào nữa không” — đều nằm ở phía mô hình AI. Apps SDK và MCP chỉ cung cấp hợp đồng thống nhất cho các công cụ.

Ta viết code ở đâu trong quy trình này

Trong vòng lặp này có ba điểm bạn thực sự viết TypeScript/code:

1. Cấu hình App và công cụ — mô tả tools (tên, mô tả, schema) và metadata của App (tên, biểu tượng, danh mục). Trong dự án của bạn, rất có thể là một file kiểu openai/app-config.ts.
2. MCP‑server / backend — xử lý call_tool: truy vấn CSDL, lọc sản phẩm, có thể gọi các API khác, v.v.
3. Widget (UI) — component React trong ứng dụng Next.js, được render trong chat và đọc kết quả của công cụ qua window.openai hoặc các hook của Apps SDK.

Mọi thứ còn lại — là việc của mô hình và nền tảng.

5. GiftGenius trong thực tế: hai kịch bản luồng người dùng

Chuyển sang các kịch bản cụ thể hơn để bạn có thể “nhìn thấy” luồng này.

Kịch bản 1: người dùng mở GiftGenius một cách tường minh

Kịch bản:

1. Người dùng trong ChatGPT mở catalog App và tìm GiftGenius.
2. Nhấn “Mở”.
3. ChatGPT khởi động hội thoại trong ngữ cảnh của GiftGenius.

Đối thoại ví dụ như sau:

Người dùng:

Mở GiftGenius từ catalog.
Và viết: “Chào! Mình muốn chọn quà cho bạn”

GPT:

“Tuyệt, mình sẽ giúp bạn chọn quà. Hãy cho biết người nhận là ai, ngân sách bao nhiêu và dịp gì nhé?”

Ở bước này GPT có thể gọi ngay công cụ đầu tiên, ví dụ start_gift_session, để khởi tạo phiên ở backend của bạn (tạo giỏ tạm, sinh sessionId, v.v.).

Code phía MCP‑server của bạn có thể trông như sau (chỉ là phác thảo):

// Ví dụ giả future-TS: mô tả công cụ GiftGenius
const suggestGiftsTool = {
  name: "suggest_gifts",
  description: "Use this when the user wants gift ideas by recipient, occasion, and budget",
  inputSchema: {
    type: "object",
    properties: {
      recipient: { type: "string" },
      occasion: { type: "string" },
      budgetUsd: { type: "number" },
    },
    required: ["recipient", "occasion", "budgetUsd"],
  },
};
    

Chi tiết cấu hình trong MCP/Apps SDK ta sẽ bàn ở module riêng; hiện giờ ý chính là: qua mô tả này, mô hình hiểu công cụ phù hợp với các yêu cầu “chọn quà”.

Sau khi người dùng trả lời, GPT gọi suggest_gifts, nhận về một mảng phương án từ bạn, rồi:

• tóm tắt bằng văn bản;
• nhúng widget GiftGenius, nơi có thể lướt và lọc các thẻ quà tặng.

Kịch bản 2: người dùng yêu cầu “chọn quà” trong chat thông thường

Giờ một phương án khác: người dùng không hề biết đến GiftGenius.

Họ viết trong chat thường:

“Cần quà cho anh trai, anh ấy mê board game, tối đa $50”

Bên trong ChatGPT sẽ diễn ra đại khái như sau:

1. Mô hình phân tích yêu cầu và danh sách công cụ khả dụng.
2. Thấy công cụ suggest_gifts với mô tả phù hợp.
3. Hiểu rằng App GiftGenius sinh ra cho những tác vụ như thế này.
4. Kiểm tra xem người dùng đã cài ứng dụng này chưa, đã đăng nhập, đã cấp những permissions nào.

Hành vi tiếp theo có thể khác nhau:

• nếu yêu cầu đủ cụ thể, GPT có thể im lặng gọi suggest_gifts và trả về kết quả kèm widget;
• nếu thiếu thông tin (ví dụ chưa nêu dịp hay độ tuổi), GPT có thể hỏi làm rõ trước, rồi mới đề xuất App.

Sự linh hoạt này — là điều khiến Apps khác với UI “cứng”: mô hình tự chọn khi nào dùng công cụ, khi nào trò chuyện.

6. Semantic routing: “LLM như một điều phối viên”

Ở cấp độ discovery, mô hình quyết định có nên kết nối App của bạn với yêu cầu hiện tại hay không. Nhưng sau đó, khi App đã được “nâng” và các công cụ của nó đã được biết trong phiên hiện tại, cấp độ thứ hai bật lên — semantic routing bên trong các tools đó: xử lý lượt nói tiếp theo bằng công cụ nào.

Trong backend web cổ điển, route được chọn theo URL: /checkout — nghĩa là gọi checkout‑controller. Trong ChatGPT Apps không có routing theo URL, nhưng có semantic routing: mô hình so khớp ý nghĩa yêu cầu với mô tả công cụ của bạn.

Đơn giản hoá, quy trình như sau:

1. Khi bắt đầu phiên, ChatGPT nhận danh sách tools: tên, mô tả, schema.
2. Các dữ liệu này được nhúng vào system instructions của mô hình.
3. Khi người dùng viết yêu cầu, mô hình so sánh ý nghĩa yêu cầu với mô tả công cụ: đâu là “chọn quà”, đâu là “tìm khách sạn”, đâu là “vẽ biểu đồ”.
4. Nếu tìm thấy sự trùng khớp tốt — nó tạo lời gọi có cấu trúc đến công cụ phù hợp.

Từ đây rút ra kết luận thực tiễn quan trọng:

• mô tả công cụ — chính là API của bạn dành cho mô hình; hãy đọc lại điều này. Và thêm lần nữa.
• Nếu bạn viết “does stuff”, mô hình thực sự không hiểu khi nào cần gọi nó.

Tài liệu và best practices về discovery nhấn mạnh: hãy coi metadata như công việc copywriting sản phẩm. Chính chúng quyết định trong những cuộc trò chuyện nào mô hình sẽ nhớ đến App của bạn.

7. Các pattern hội thoại xoay quanh App

Bây giờ xem các UX pattern điển hình xuất hiện khi GPT tương tác với App trong cùng một cuộc trò chuyện. Điều này quan trọng để bạn không xây App “trong chân không”, thiếu hiểu biết về vai trò phần GPT.

Tất cả các hướng dẫn thực hành về Apps SDK đều nêu một vài pattern đặc trưng:

“Trình hướng dẫn” (The Wizard)

GPT dẫn dắt người dùng từng bước, thường xuyên dựa vào App.

Với GiftGenius ví dụ:

1. GPT: “Hãy cho biết người nhận quà là ai?”
2. Người dùng: “Anh trai, 25 tuổi, thích board game.”
3. GPT: “Ngân sách bao nhiêu?”
4. Người dùng: “Tối đa $50.”
5. GPT gọi suggest_gifts, hiển thị kết quả trong widget và viết: “Mình đã chọn vài phương án, bạn hãy xem trong danh sách bên dưới.”

Trong pattern này, App và widget của nó — như một lớp trực quan phủ lên cuộc hội thoại nhiều bước. Người dùng chủ yếu gõ văn bản, còn widget giúp trực quan hoá việc lựa chọn.

“Widget thích ứng” (The Adaptive Widget)

Văn bản vẫn là kênh chính, còn App được kết nối có chọn lọc cho các nhiệm vụ đặc biệt: vẽ biểu đồ, hiển thị bảng, vẽ thẻ sản phẩm.

Ví dụ:

• Người dùng: “So sánh ba phương án quà: board game, sách, trải nghiệm.”
• GPT trước hết giải thích ưu nhược điểm bằng văn bản.
• Sau đó gọi công cụ trả về danh sách sản phẩm có cấu trúc và render một bảng nhỏ hoặc các thẻ.

Ở đây App — như phần bổ trợ trực quan, không phải “chế độ mặc định”.

“Tác nhân vô hình” (Invisible Agent)

App thậm chí có thể không hiển thị UI. Nó chạy “dưới nắp capo” như nguồn dữ liệu:

• bạn triển khai MCP‑tool tìm quà trong CSDL của mình;
• GPT gọi nó, nhận danh sách và tự tóm tắt kết quả bằng văn bản, không có bất kỳ widget nào.

Điều này giống “plugin‑không‑UI” cổ điển: người dùng chỉ thấy GPT biết giá và hàng hoá cập nhật.

Pattern này hữu ích cho tool‑first App, nơi UI không quá quan trọng.

8. Luồng ảnh hưởng đến thiết kế App như thế nào

Hiểu luồng quan trọng không chỉ về triết lý, mà còn cho các quyết định rất thực tế: mở những công cụ nào, mô tả ra sao, khi nào hiển thị widget và khi nào nên trả lời bằng văn bản.

Nguyên tắc “chat‑first”

Ý tưởng cốt lõi của hệ sinh thái: chat — là kênh tương tác chính, còn các thành phần UI — là phụ trợ.

Điều đó có nghĩa:

• đừng cố “nhét cả một website” vào một widget;
• widget nên giúp ở nơi chat bất tiện: chọn từ danh sách, lọc, so sánh, biểu mẫu phức tạp.

Với GiftGenius, điều này là:

• chọn danh sách quà và cho người dùng “bấm” vào các thẻ;
• trực quan hoá bộ lọc (giá, danh mục, tồn kho);
• hỗ trợ làm đơn hàng (checkout) qua vài bước rõ ràng.

Còn việc viết dài dòng “cách chọn quà cho cô gái hướng nội” trong widget — không phải ý hay, đó là việc của chat.

Khi nào khởi chạy App, khi nào không

Hệ quả khác: đừng biến App thành “kẻ chiếm đóng cuộc trò chuyện”.

Pattern tệ:

• người dùng đang thảo luận nghiêm túc;
• App khởi chạy và mở một widget fullscreen khổng lồ không báo trước;
• người dùng bối rối: “chat của tôi đâu rồi?”.

Tốt hơn:

• ban đầu thảo luận bằng văn bản, hỏi vài điều làm rõ;
• sau đó nhẹ nhàng đề nghị mở App nếu điều đó thực sự cải thiện UX (so sánh, cấu hình, checkout).

Ảnh hưởng đến bộ công cụ

Vì mô hình chọn công cụ dựa trên mô tả, mỗi công cụ cần:

• giải quyết một nhiệm vụ dễ hiểu;
• được mô tả rõ theo phong cách “Use this when…”;
• có tham số tự nhiên phát sinh từ các câu hỏi GPT sẽ hỏi người dùng.

Với GiftGenius, thay vì một do_everything khổng lồ, hợp lý hơn là có:

• suggest_gifts — chọn danh sách phương án;
• get_gift_details — chi tiết theo một ID;
• create_order — tạo đơn hàng.

Ta sẽ bàn kỹ hơn về thiết kế công cụ ở module 4, nhưng ý chung đã quan trọng ngay lúc này: luồng hội thoại quyết định những công cụ nào thực sự cần.

9. Ví dụ mini: mô tả tools ảnh hưởng luồng như thế nào (phác thảo TypeScript)

Một đoạn nhỏ tưởng tượng trong openai/app-config.ts, để nối lý thuyết với code. Đừng xem đây là cú pháp SDK chính xác (ta sẽ bàn ở module tiếp theo) — hiện giờ ý quan trọng là tên và mô tả.

// Đoạn cấu hình giả định cho GiftGenius (mã trong tương lai)
const tools = [
  {
    name: "suggest_gifts",
    description: "Use this when the user wants gift ideas based on recipient, occasion, and budget.",
    inputSchema: {/* ... */},
  },
  {
    name: "get_gift_details",
    description: "Use this when the user asks for more information about a specific gift from a previous list.",
    inputSchema: {/* ... */},
  },
];

Nếu bạn thay suggest_gifts bằng run_func và mô tả thành “Main function”, GPT sẽ:

• khó hiểu hơn với những yêu cầu nào nên gọi công cụ này;
• có thể ít đề xuất App của bạn hơn trong in‑conversation discovery;
• khó liên kết các follow‑up của người dùng với danh sách quà đã hiển thị.

Ngược lại, tên và mô tả tốt sẽ tăng khả năng App của bạn “xuất hiện đúng lúc”.

10. Lỗi thường gặp khi thiết kế luồng người dùng

Lỗi số 1: Kỳ vọng kiểm soát hoàn toàn — “tôi tự quyết khi nào khởi chạy App”.
Đôi khi lập trình viên nghĩ theo mô hình “tôi sẽ bắt mọi yêu cầu về quà và nối App của mình vào”. Trong thế giới ChatGPT Apps không phải vậy: mô hình đưa ra quyết định. Nó cân nhắc mô tả công cụ, ngữ cảnh hội thoại, trạng thái quyền (permissions) và mức độ người dùng hài lòng khi gọi đúng App của bạn.

Lỗi số 2: Tên và mô tả công cụ vô nghĩa.
Các công cụ mang tên run, main, tool1 và mô tả “Calls the main function” tạo ra “cơn bão hoàn hảo”: mô hình không hiểu khi nào cần gọi, in‑conversation discovery gần như không hoạt động, và App của bạn trở nên “vô hình”. Mô tả theo phong cách “Use this when the user wants…” và một cái tên rõ ràng — quan trọng hơn bạn tưởng.

Lỗi số 3: Cố nhồi “mọi thứ trên đời” vào một App.
Nếu App của bạn vừa “chọn quà, đặt khách sạn, tính thuế, lại còn hiển thị mèo”, mô hình sẽ không thể route yêu cầu ổn định. Khuyến nghị chính thức và hướng dẫn thực hành nhấn mạnh nguyên tắc “one clear job per tool/App”: tốt hơn là vài ứng dụng chuyên biệt thay vì một “siêu đơn khối”.

Lỗi số 4: Tự động khởi chạy UI nặng một cách hung hãn.
Lập trình viên phấn khích với widget fullscreen đẹp đẽ và muốn hiển thị “mọi lúc mọi nơi”. Kết quả là người dùng thấy chat “bị hỏng” và biến thành một web app kỳ lạ. Tốt hơn nhiều nếu GPT trò chuyện trước, hỏi làm rõ, rồi mới đề nghị mở App và giải thích lý do.

Lỗi số 5: Bỏ qua vai trò GPT như một lớp UX.
Bạn có thể thiết kế App như một SPA thông thường: làm mọi thứ trong widget, còn ChatGPT “im lặng đừng can thiệp”. Nhưng sẽ không hiệu quả. ChatGPT có thể không hiển thị widget của bạn, hoặc hiển thị widget mới cho mỗi lần gọi tool. Muốn sản phẩm thành công — hãy thích ứng với nền tảng, đừng mong nền tảng thích ứng với bạn.