UX‑guidelines từ OpenAI: khi nào nên hiển thị App và cách không “chiếm quyền” cuộc trò chuyện

1. Chat‑first: ChatGPT — trước hết là chat, sau đó mới là ứng dụng

Trong 6 mô‑đun đầu tiên, chúng ta đã tìm hiểu mọi khía cạnh của ứng dụng: từ UI và MCP đến gỡ lỗi và triển khai. Giờ chúng ta sẽ đi qua mọi mặt ấy một lần nữa, nhưng sâu hơn. Bạn không nghĩ mọi thứ sẽ đơn giản thế đâu, đúng không?

Bắt đầu từ UX, cụ thể là các UI requirements và UX‑guidelines chính thức. Bạn muốn ứng dụng của mình vượt qua review, phải không? Tuyệt, vậy hãy bắt đầu với điều thú vị nhất: cú “chuyển khung” cần có cho một frontend dev đã quen với SPA/Next.js: ChatGPT — về cốt lõi là giao diện đối thoại, còn App — chỉ là vị khách trong cuộc đối thoại đó. Không phải ngược lại.

OpenAI trong các guideline phát biểu như sau: ứng dụng mở rộng những gì người dùng có thể làm, mà không làm gãy dòng hội thoại. Widget không phải là thẻ trình duyệt mới, mà là phần chèn gọn gàng vào chat, đem lại cấu trúc khi văn bản thuần đã trở nên nặng nề.

Dễ nhớ nhất là phân chia vai trò.

Vai trò của GPT và App

Bên trong ChatGPT có hai “nhân vật”:

GPT vẫn là người dẫn chuyện chính. GPT giải thích bằng lời điều sắp diễn ra, lý do đề xuất App, ý nghĩa các nút, và tóm tắt kết quả widget. Còn App tập trung vào phần trực quan và hành động: chọn tùy chọn, thiết lập bộ lọc, đi qua các bước của trình hướng dẫn.

Một quy tắc rất quan trọng, đáng để lặp lại như một câu thần chú: mọi quyết định quan trọng phải được nói rõ trong câu trả lời văn bản của GPT, ngay cả khi người dùng thao tác trong UI. Người dùng không bắt buộc phải đọc mọi dòng trong widget — các hệ quả then chốt (ví dụ “chúng tôi đã đặt hàng” hoặc “bạn đã chọn các tham số này”) phải được nói ra trong chat.

2. Khi nào App thực sự cần thiết: tiêu chí hiển thị

Về mặt kỹ thuật, bạn có thể gọi widget sau mỗi tin nhắn. Nhưng về mặt UX — đó như thể mở một hộp thoại toàn màn hình sau mỗi ký tự gõ trong input. Có thể chạy — đúng. Sống chung thoải mái — không.

OpenAI và Apps SDK đề xuất một nguyên tắc đơn giản: App phù hợp khi nó giúp suy nghĩ dễ hơn so với chỉ văn bản.

Các yêu cầu có cấu trúc và kịch bản lặp lại

App phát huy tốt khi yêu cầu của người dùng đã gợi ý sẵn về cấu trúc:

• “Gợi ý 5 món quà cho đồng nghiệp trong tầm $50.”
• “So sánh ba gói cước này.”
• “Lên lịch trình 3 ngày ở Tokyo.”
• “Hiển thị danh sách việc cần làm trong tuần và giúp sắp xếp ưu tiên.”

Trong các trường hợp này có những thực thể rõ ràng (quà tặng, gói cước, ngày trong lịch trình, nhiệm vụ) cần thao tác, và các bước: chọn, lọc, so sánh, xác nhận. Ở đây, UI với thẻ, checkbox, bộ lọc là hợp lý, thậm chí “cứu cánh”.

Ví dụ cho GiftGenius

Hãy lấy nhân vật quen thuộc GiftGenius. Một yêu cầu điển hình:

Cần chọn quà cho 10 khách dự đám cưới, với ngân sách và sở thích khác nhau.

Bằng văn bản thuần, GPT có thể liệt kê 10 danh sách riêng, nhưng đọc sẽ rất mệt. Dễ chịu hơn nhiều khi:

• hiển thị bảng khách, ngân sách và sở thích,
• cho phép lọc “rẻ hơn/đắt hơn”,
• hiển thị bộ thẻ cho từng khách.

Ở đây App gần như bắt buộc: quá nhiều thực thể và tham số để chỉ giữ bằng văn bản.

Trái lại với điều này:

Tặng gì cho anh trai với 5000 ₽?

Đây là câu hỏi nhỏ, một bước. GPT có thể trả lời bằng văn bản với 3–5 ý tưởng, và chỉ khi người dùng yêu cầu “hiển thị tùy chọn để tôi lọc theo sở thích và độ tuổi”, lúc đó mới chuyển mượt sang App.

Heuristic nhỏ

Hữu ích khi ghi nhớ bảng đơn giản:

Chi tiết về inline và fullscreen sẽ bàn ở các bài sau, nhưng đã thấy rõ: App là công cụ cho các tác vụ có cấu trúc, nhiều bước, chứ không phải cho mọi câu “mình buồn quá, làm gì bây giờ?”.

3. Khi App gây cản trở: chế độ “trò chuyện” và suy tư

Ta đã xem các trường hợp App thực sự đơn giản hóa cuộc sống và giúp cấu trúc hội thoại. Nhưng cũng có mặt trái: có những tình huống mọi UI đều chỉ làm vướng.

Bàn quá nhiều về “hãy vẽ UI” thường tạo phản xạ: “ồ, người dùng vừa hỏi gì đó — đến lúc khởi chạy widget”. Đây là lúc bạn có thể bị trừ điểm UX khi review trên Store.

Có một lớp yêu cầu mà App thường có hại hơn lợi:

1. Người dùng ở chế độ “trò chuyện”. Đó là những suy tư triết học, câu hỏi cá nhân, băn khoăn nghề nghiệp, trò chuyện mang tính trị liệu. Trong những kịch bản này, người dùng kỳ vọng cuộc nói chuyện bằng văn bản, các câu hỏi làm rõ, đôi khi là sự đồng cảm. Chèn thẻ và bộ lọc ở đây sẽ bị cảm nhận như banner quảng cáo.
2. Câu hỏi giới thiệu về dịch vụ. Nếu ai đó viết “Hãy kể GiftGenius làm được gì?”, họ muốn một cái nhìn tổng quan chứ không phải UI ngay lập tức. Ở đây GPT nên giải thích ngắn gọn trước về mục đích của App, có thể đưa ví dụ về yêu cầu, rồi mới nhẹ nhàng đề nghị thử widget.
3. Câu hỏi lý thuyết chung. “Chọn quà cho người hướng nội như thế nào?” hoặc “Hệ thống tích điểm trong cửa hàng hoạt động ra sao?” — đây là kịch bản học hỏi, không phải giao dịch. GPT có thể đưa câu trả lời bằng văn bản tốt, và cuối cùng thêm nhẹ nhàng: “Nếu muốn, tôi có thể mở GiftGenius và gợi ý vài lựa chọn cụ thể.”

Ở bất cứ nơi nào UI không mang lại giá trị mới mà chỉ lặp lại văn bản, tốt hơn nên tiếp tục ở trong chat. Đó là tôn trọng ý định của người dùng — điều mà các chuyên gia UX luôn nhấn mạnh.

4. Cách đề xuất App: auto‑launch so với “chuyển giao khiêm tốn”

Ngay cả khi bạn chắc chắn App phù hợp, câu hỏi “khởi chạy thế nào” vẫn còn. Cách thô: widget bất ngờ mở fullscreen không báo trước. Cách chuẩn: GPT trước hết giải thích bằng lời điều sắp diễn ra và hỏi ý kiến hoặc ít nhất là thông báo.

Trong tài liệu UX của ChatGPT Apps có hai pattern: auto‑launch và suggestion (humble handoff).

Auto‑launch: khi người dùng yêu cầu rõ ràng

Auto‑launch phù hợp khi người dùng đưa ra ý định rõ ràng:

Mở GiftGenius.
Mở phần cài đặt của GiftGenius.
Hiển thị giỏ quà của tôi trong GiftGenius.

Quy tắc ở đây rất đơn giản:

1. GPT viết ngắn gọn kiểu “Đang mở GiftGenius…”
2. Mô hình ngay lập tức gọi công cụ / widget.

Cuộc hội thoại có thể trông như sau:

Người dùng: Mở GiftGenius, tôi muốn chọn quà cho bạn.
GPT: Đang mở trợ lý GiftGenius để chọn quà.
[Widget GiftGenius xuất hiện ở inline hoặc fullscreen]

Tự động khởi chạy không cần hỏi thêm là hợp lý, vì chính người dùng đã yêu cầu “mở”.

Suggestion (humble handoff): khi ý định chưa rõ ràng

Trong nhiều trường hợp, người dùng thậm chí không biết về ứng dụng của bạn. Họ viết:

Cần nghĩ gì đó cho đồng nghiệp nhân dịp sinh nhật, ngân sách nhỏ.

Pattern đúng là:

1. GPT phân tích yêu cầu và hiểu rằng App có thể giúp.
2. GPT đặt 1–2 câu hỏi làm rõ hoặc đề xuất App bằng lời.
3. Chỉ sau khi có đồng ý hoặc gợi ý rõ ràng — mới khởi chạy widget.

Ví dụ:

Người dùng: Cần nghĩ gì đó cho đồng nghiệp nhân dịp sinh nhật, ngân sách nhỏ.
GPT: Tôi có thể tự gợi ý ý tưởng hoặc mở ứng dụng GiftGenius, nơi chúng ta sẽ lọc theo ngân sách và sở thích. Bạn muốn chỉ nhận lời khuyên hay thử ứng dụng?
Người dùng: Dùng ứng dụng đi.
GPT: Đang mở GiftGenius để gợi ý các lựa chọn quà.
[Widget xuất hiện]

Cách này nhấn mạnh rằng: chủ động vẫn là ở người dùng, còn App — là một tùy chọn, không phải banner bị áp đặt. Điều này phù hợp với nguyên tắc “Respect user’s intent” trong UX‑guidelines.

Ví dụ nhỏ “bộ phân loại ý định” bằng TypeScript

Giả sử ở phía backend của bạn đã có phân loại sơ bộ yêu cầu người dùng (không nhầm với chính GPT, đây là logic phụ trợ):

// Kiểu ý định của người dùng (đơn giản hoá)
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Trigger cho App mà chúng ta muốn sử dụng
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "mở GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // yêu cầu không rõ ràng
  return 'avoid';                                // trò chuyện bình thường, không App
}

Logic này tự nó không gọi widget — nó chỉ là cách hệ thống hóa cách tiếp cận UX của bạn. Sau đó, bạn chuyển các quy tắc này vào system‑prompt và mô tả App, để mô hình hành xử nhất quán.

5. Cách không “chiếm quyền” cuộc trò chuyện: những pattern tốt và xấu

Trong tài liệu và các bài viết về UX‑design cho ChatGPT Apps, OpenAI nêu rất rõ điều không nên làm: đừng “đánh cắp” cuộc trò chuyện. Nghĩa là đừng biến chat thành kênh quảng bá cho giao diện của bạn.

Anti‑pattern

Đau nhất — “widget bất ngờ”. Khi người dùng đang trò chuyện sâu và bất chợt toàn bộ màn hình bị chiếm bởi ứng dụng fullscreen mà họ không hề yêu cầu. Ngữ cảnh biến mất, cảm giác kiểm soát cũng vậy.

Lỗi phổ biến khác — dùng App như quảng cáo. Ví dụ, người dùng hỏi câu lý thuyết, còn mô hình đáp: “Trước hết tôi sẽ mở siêu widget của chúng tôi, trong đó có mọi thứ” và hiển thị UI mà một nửa là nội dung marketing. Guidelines chính thức gọi đó là “poor use cases”.

Anti‑pattern thứ ba — chuyển qua lại không cần thiết giữa UI và văn bản. Nếu sau mỗi lần làm rõ nhỏ đều mở và đóng App, cuộc trò chuyện sẽ như đèn nhấp nháy. Người dùng, nhất là trên di động, sẽ nhanh mệt mỏi.

Thực hành tốt

Trong mọi kịch bản nơi bạn mở App, hãy cố bám ba quy tắc đơn giản.

Thứ nhất, hãy báo trước. Hãy để GPT nói rõ là sẽ mở ứng dụng và để làm gì. Ví dụ: “Bây giờ tôi sẽ mở trợ lý GiftGenius để hiển thị các lựa chọn dạng thẻ”. Chỉ 1–2 câu, nhưng thay đổi hoàn toàn cảm nhận khi chuyển trạng thái.

Thứ hai, giải thích cần làm gì trong UI. Không phải ai cũng quen với giao diện mới. GPT có thể thêm: “Bên dưới bạn sẽ thấy các thẻ quà, có thể chuyển trang và nhấn “Chi tiết hơn” ở bất kỳ lựa chọn nào.” Nếu widget có yếu tố lạ (ví dụ “Hiển thị thêm N” hoặc bộ lọc không chuẩn), nên nói rõ bằng lời.

Thứ ba, tóm tắt kết quả bằng văn bản. Sau khi App làm gì đó (chọn, tính toán, gửi), GPT nên nói ngắn gọn: “Tôi đã chọn 3 lựa chọn quà. Hai lựa chọn đầu trong ngân sách đến $50, lựa chọn thứ ba hơi cao hơn nhưng giao nhanh. Bạn muốn thu hẹp tiếp không?” Điều này đặc biệt quan trọng trên di động và khi dùng giọng nói: người dùng có thể không nhìn UI, nhưng sẽ nghe phần tóm tắt.

6. Vai trò của system‑prompt và mô tả App trong điều phối UX

Trước đây bạn đã thấy cách system‑prompt xác định “tính cách” của App và cách mô hình dùng công cụ. Giờ hãy bổ sung các quy tắc UX vào đó: khi nào đề xuất App, cách thông báo, khi nào nên tránh.

Nên ghi gì trong system‑prompt

Với GiftGenius, system‑prompt có thể có phần “Đối thoại và UX”. Tài liệu và bài viết khuyên nên mô tả có cấu trúc, thành các quy tắc riêng.

Ví dụ đoạn trích (pseudo‑code, nhưng rất sát thực tế):

### Đối thoại và UX

1. Nếu người dùng đưa ra điều kiện chọn quà (cho ai, ngân sách, dịp),
   trước hết hãy đặt 1–2 câu hỏi làm rõ bằng văn bản.
2. Sau khi làm rõ, đề nghị mở App GiftGenius:
   "Tôi có thể mở trợ lý GiftGenius để hiển thị các lựa chọn quà. Mở nhé?"
3. Nếu người dùng yêu cầu rõ ràng "mở GiftGenius" hoặc "hiển thị danh sách quà",
   hãy trả lời "Đang mở GiftGenius..." và gọi App ngay, không hỏi thêm.
4. Nếu người dùng hỏi lý thuyết hoặc lời khuyên chung (ví dụ "chọn quà thế nào"),
   hãy trả lời bằng văn bản và không mở App cho đến khi họ tự yêu cầu.
5. Nếu người dùng nói "đừng mở ứng dụng" hoặc "chỉ trả lời bằng văn bản",
   về sau đừng đề nghị App trong cuộc hội thoại này nữa.
6. Sau khi App hoàn tất, luôn tóm tắt kết quả bằng văn bản (ngắn gọn).

Ở đây cô đọng mọi nguyên tắc UX: chat‑first, tôn trọng việc từ chối của người dùng, khác biệt giữa auto‑launch và suggest, và bắt buộc có phần tóm tắt bằng văn bản.

Hỗ trợ bản thân bằng các config TypeScript

Trong dự án thực tế, tiện nhất là lưu một phần quy tắc này ở dạng cấu trúc (để khỏi phải đi tìm đoạn text trong prompt bằng tay). Ví dụ, có thể tạo một config đơn giản:

// Kiểu giả định cho config UX‑trigger của App
type AppUxRule = {
  intent: 'gift_selection' | 'theory' | 'open_app';
  trigger: 'auto' | 'suggest' | 'avoid';
  askConfirmation?: boolean;
};

export const giftGeniusUxRules: AppUxRule[] = [
  { intent: 'open_app', trigger: 'auto' },
  { intent: 'gift_selection', trigger: 'suggest', askConfirmation: true },
  { intent: 'theory', trigger: 'avoid' },
];

Bản thân mô hình không đọc config này — nó dành cho bạn, các lập trình viên, để gom thỏa thuận product/design vào một nơi rồi chuyển gọn sang system‑prompt, mô tả App và tài liệu.

7. Ví dụ: GPT thông báo về GiftGenius mà không “giành” cuộc trò chuyện

Kết nối tất cả với ứng dụng của chúng ta. Giả sử người dùng lần đầu viết vào chat:

Tôi đang tìm quà cho đồng nghiệp, khoảng 3000 ₽, anh ấy thích board game.

Câu trả lời tốt của mô hình (với system‑prompt đã định) có thể như sau:

Tôi hiểu! Hãy làm rõ vài chi tiết rồi chọn ý tưởng nhé.

Cho tôi biết anh ấy khoảng bao nhiêu tuổi và đây là món quà mang tính xã giao hay từ một người bạn thân?

(Sau khi bạn trả lời, tôi có thể mở trợ lý GiftGenius, nơi chúng ta xem các lựa chọn dưới dạng thẻ.)

Sau khi làm rõ, GPT viết:

Tuyệt, tôi đã có đủ thông tin.

Bây giờ tôi sẽ mở ứng dụng GiftGenius — trong đó tôi sẽ hiển thị cho bạn vài lựa chọn quà dạng thẻ, bạn có thể xem chi tiết và thu hẹp theo ngân sách và loại trò chơi.

Và chỉ sau đó — khởi chạy App. Không có “bất ngờ” nào, mọi thứ đều được giải thích bằng lời.

React‑component nhỏ “giới thiệu App” bên trong widget

Về mặt code, widget thường chỉ render khi được gọi. Nhưng bạn có thể đưa triết lý “không giành lấy” ngữ cảnh vào UI của nó, ngay cả khi nó đã được mở.

Ví dụ, màn hình đầu tiên của GiftGenius có thể rất đơn giản:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Chọn quà với GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Tôi sẽ hiển thị vài lựa chọn dưới dạng thẻ. Bạn có thể
        chọn những gì bạn thích, còn ChatGPT sẽ giải thích ưu và nhược điểm.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        Bất cứ lúc nào bạn cũng có thể quay lại chat bình thường để tiếp tục trao đổi.
      </p>
    </section>
  );
}

Component này không làm gì “mạnh” về kỹ thuật, nhưng từ góc nhìn UX nó quan trọng: nó nhắc rằng chat vẫn ở đó, và vai trò của GPT vẫn là trung tâm.

Sau đó, chính từ màn hình intro này bạn sẽ chuyển tới thẻ quà, trình hướng dẫn, v.v., nhưng đó là chủ đề của các bài giảng tiếp theo.

8. Thực hành và bài tập

Ở trên, chúng ta đã gom một bộ nguyên tắc — chat‑first, tôn trọng ý định người dùng, phân biệt giữa auto‑launch và đề xuất App. Để khắc sâu cách “khi nào và như thế nào hiển thị App”, hữu ích khi cân nhắc các yêu cầu thực tế và phân định rõ nơi App cần, và nơi không. Bài tập về nhà có thể làm hai bài nhỏ.

Trước tiên, lấy GiftGenius và nghĩ ra 5–7 yêu cầu người dùng. Với mỗi yêu cầu, hãy tự trả lời một cách thành thật:

• có nên đề xuất mở App ngay không;
• chỉ nên nhắc đến App như một tùy chọn thôi;
• hay tốt hơn là không liên hệ câu trả lời với App chút nào.

Ví dụ:

1. “Quà cho vợ dịp kỷ niệm, ngân sách đến $1000” — có lẽ nên bắt đầu bằng vài câu hỏi làm rõ rồi đề nghị mở App.
2. “Gói quà sao cho độc đáo?” — câu hỏi lý thuyết, có thể không cần App.
3. “Mở GiftGenius, tôi muốn chọn quà cho cả team” — auto‑launch trực tiếp.

Bài tập thứ hai — viết đoạn văn ngắn để thông báo mở App. Hãy thử 1–2 câu ngắn mà GPT sẽ dùng để giải thích với người dùng việc chuyển sang App. So sánh các tông giọng: trang trọng hơn (“Đang mở ứng dụng GiftGenius…”) và thân thiện hơn (“Hãy thử trợ lý GiftGenius — như vậy sẽ dễ so sánh lựa chọn hơn”).

Như vậy, bạn sẽ học cách tư duy không chỉ như lập trình viên, mà còn như tác giả của cuộc đối thoại.

9. Lỗi thường gặp trong UX “khi nào hiển thị App”

Lỗi №1: Hiển thị App chỉ vì bất kỳ từ khóa liên quan nào.
Một cực đoan thường thấy: nếu App về quà tặng, bất kỳ từ “quà” nào trong hội thoại lập tức kích hoạt widget. Người dùng hỏi “làm sao để không lúng túng khi tặng quà cho sếp”, nhưng thay vì lời khuyên sống động lại nhận UI với thẻ. Điều này bị cảm nhận như quảng cáo và bỏ qua ý định thực sự của người dùng, đi ngược với UX‑guidelines chính thức và nguyên tắc “Respect user’s intent”.

Lỗi №2: Fullscreen không báo trước.
“Widget bất ngờ” đột ngột chiếm toàn màn hình — cách chắc chắn để làm hỏng trải nghiệm. Đặc biệt tệ ở giữa cuộc trò chuyện dài khi người dùng không trông đợi chuyển gấp từ văn bản sang UI. Theo guideline của OpenAI, đây là thực hành tồi; luôn cần thông báo chuyển trạng thái và nếu có thể, hỏi ý kiến.

Lỗi №3: Dùng UI thay cho câu trả lời.
Đôi khi tác giả App nghĩ: “Z cần gì trả lời bằng văn bản, chúng ta có UI đẹp rồi!” Kết quả là GPT hầu như không nói gì, mọi “câu trả lời” nằm trong widget. Người dùng, đặc biệt ở chế độ thoại hoặc di động, có thể bỏ lỡ chi tiết quan trọng. Cách đúng — UI bổ sung câu trả lời, không thay thế nó: App hiển thị chi tiết và tùy chọn, GPT giải thích ý nghĩa.

Lỗi №4: Bỏ qua việc người dùng từ chối App.
Nếu người dùng nói rõ “đừng mở ứng dụng” hoặc “chỉ trả lời bằng văn bản”, App cần coi đó là quy tắc cứng cho đến hết cuộc trò chuyện. Cứ hai tin nhắn lại đề nghị App — giống pop‑up “hãy đánh giá dịch vụ của chúng tôi” phiền toái. Điều này làm xấu UX và có thể ảnh hưởng đến review trên Store. Trong system‑prompt cần cài rõ sự tôn trọng đối với việc từ chối.

Lỗi №5: Không phân biệt auto‑launch và “đề xuất”.
Khi lập trình viên không phân biệt ý định rõ ràng và không rõ ràng, hoặc là không bao giờ khởi chạy App ngay cả khi người dùng yêu cầu trực tiếp, hoặc là luôn mở, kể cả khi người dùng chỉ buột miệng “có thể một lúc nào đó tôi thử App của bạn”. Từ đó sinh ra auto‑open “chỉ vì nghe giống từ”. Việc chuẩn hóa trigger (auto / suggest / avoid) và logic được suy nghĩ kỹ trong system‑prompt sẽ giúp tránh rối rắm này.

Lỗi №6: Hoàn toàn thiếu quy tắc UX trong system‑prompt.
Đôi khi mọi quyết định UX chỉ “ở trong đầu team”, còn system‑prompt thì chỉ dừng ở “Bạn là trợ lý GiftGenius, hãy giúp về quà tặng”. Kết quả là mô hình khi thì đề nghị App, khi lại quên, khi lại mở sai thời điểm. Các quy tắc UX được ghi chép, có cấu trúc trong system‑prompt và tài liệu — cũng quan trọng như JSON‑schema của công cụ.

Lỗi №7: “Gắn UX sau này”.
Cách tiếp cận thường gặp — trước hết “làm cho chạy đã”, rồi sẽ nghĩ về UX sau. Với ChatGPT Apps, điều này dẫn tới việc bạn đã ràng buộc với một số pattern gọi công cụ, và về sau thay đổi system‑prompt và hành vi GPT trở nên khó hơn. Tốt hơn là đặt sẵn các guideline UX cơ bản ngay từ đầu: chat‑first, tôn trọng việc từ chối, tiêu chí hiển thị App rõ ràng và không có “widget bất ngờ”. Khi đó các phần phát triển tiếp theo (pattern inline, fullscreen, voice) sẽ dựa trên nền tảng vững chắc.