Developer Mode vs Store

1. Giới thiệu

Trong các bài trước chúng ta đã nói về ChatGPT App là gì, nó gồm những lớp nào và khác gì so với plugin cũ hay bot dùng OpenAI API. Bây giờ hãy chuyển sang chủ đề quan trọng thứ hai — vòng đời của ứng dụng kiểu này.

Nếu bạn đã viết web service vài năm, từ “lifecycle” hẳn không làm bạn sợ. Mọi sản phẩm đều có một hành trình sơ khởi: “viết local → đẩy lên staging → đẩy lên production → đôi khi vỡ tung → rồi sửa”. Trong hệ sinh thái ChatGPT với App cũng vậy, nhưng có vài điểm khác: xuất hiện Dev Mode ngay trong ChatGPT và một thực thể riêng — Store.

Điều quan trọng là tách bạch hai mặt phẳng:

1. Mã của bạn “sống” ở đâu về mặt vật lý: máy chủ Next.js local, Vercel, một cụm Kubernetes nào đó, v.v. Đây là thế giới của bạn, bạn là người làm chủ.
2. ChatGPT nhìn App của bạn như thế nào: như một tập siêu dữ liệu, URL và quyền truy cập (permissions), có thể kết nối trong Developer Mode hoặc đóng gói như một sản phẩm hoàn chỉnh ở Store. Đây là thế giới của OpenAI, với quy tắc, review và người dùng riêng.

Bài giảng này chính là về mặt phẳng thứ hai. Chúng ta sẽ dựa vào mô hình môi trường quen thuộc (dev / staging / prod), nhưng nhìn qua lăng kính ChatGPT. Mục tiêu là để bạn luôn trả lời được vài câu hỏi: Hiện chính xác đoạn mã nào đang chạy App của tôi? Ai nhìn thấy nó? Làm sao thử nghiệm an toàn? Và “cập nhật App” trên Store thực sự có nghĩa là gì?

2. Developer Mode: sandbox cá nhân bên trong ChatGPT

Bắt đầu từ thứ dễ chịu nhất với lập trình viên: sandbox nơi bạn có thể làm hỏng mọi thứ mà gần như không làm tổn thương ai.

Developer Mode là chế độ đặc biệt trong ChatGPT, nơi bạn có thể kết nối ChatGPT Apps của mình trực tiếp qua URL mà không cần review, không cần xuất bản App lên Store và không phơi bày App cho cả thế giới. Về tinh thần nó giống như localhost:3000 trên trình duyệt, nhưng trong thế giới ChatGPT.

Trông như thế nào về mặt khái niệm

Dễ hình dung nhất theo sơ đồ sau:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Cấu hình App cho Dev (URL + metadata)"]
    AppServer["Máy chủ App của bạn (Next.js + Apps SDK)"]

    User -->|yêu cầu trong chat| ChatGPTCore[GPT]
    ChatGPTCore -->|cần App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/công cụ| ChatGPTCore
    ChatGPTCore --> User

Với tư cách lập trình viên, trong cài đặt Developer Mode bạn nói với ChatGPT: “Đây là App của tôi, đây là URL của nó, đây là tên và khả năng của nó”. ChatGPT bắt đầu coi URL đó là nguồn ứng dụng của bạn. Chừng nào bạn chưa gửi App lên Store, chỉ có bạn (và có thể là các thành viên nhóm nếu bạn thêm họ làm developer) nhìn thấy nó.

Chi tiết kỹ thuật kết nối (HTTPS tunnel, Vercel và các niềm vui khác) chúng ta sẽ bàn sau. Ở đây ý chính là: Dev Mode giống như một “lối tắt động” trỏ tới dev server của bạn mà ChatGPT có thể gọi.

Cách bật Developer Mode

Để có khả năng "kết nối" máy chủ cục bộ của bạn với giao diện ChatGPT, bạn cần kích hoạt công tắc tương ứng trong cài đặt.

• Truy cập liên kết https://chatgpt.com/#settings/Connectors/Advanced hoặc vào Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Ngay khi bạn làm điều này, nút Create App sẽ xuất hiện.

Dev Mode khác gì so với production

Khác biệt rất giống giữa môi trường dev và production trong web thông thường, nhưng có vài điểm đặc thù.

Thứ nhất, mức độ hiển thị. App của bạn ở Dev Mode thường không khả dụng với người dùng ChatGPT thông thường. Chỉ bạn và có thể là các thành viên tổ chức có quyền mới thấy. Bạn có thể thử nghiệm mà không lo người lạ va phải UX còn ngổn ngang.

Thứ hai, tính ổn định và thử nghiệm. Trong Dev Mode bạn có thể đổi code mỗi hai phút, bật server local, tắt nó, khởi động lại tunnel. ChatGPT sẽ cố gắng gọi URL đã chỉ định nhưng sẽ không “dỗi” nếu thỉnh thoảng bạn trả về 500 hoặc im lặng — dev là để làm vậy.

Thứ ba, permissions và chính sách. Ở Dev Mode bạn dễ thử các cấu hình khác nhau hơn. Nhưng cần nhớ rằng chính sách nội dung và an toàn cơ bản không bị tắt ngay cả ở chế độ dev: ChatGPT sẽ không cho bạn “biến thành App hack cho mọi thứ” bất ngờ. Tuy nhiên khung review của Store chưa áp vào đây: bạn chưa cần listing hoàn hảo, logo đẹp, v.v.

Cuối cùng, ở Dev Mode thường dễ chẩn đoán hơn. Bạn có thể nhanh chóng đổi logic, xem các request từ ChatGPT đến server của mình, và điều chỉnh hành vi mà không phải lo về “migration người dùng”.

Chúng ta đã nhìn Dev Mode như một sandbox cá nhân cho ứng dụng và hơi liếc sang Store. Giờ hãy đóng gói tất cả thành một “máy trạng thái” dễ hiểu cho vòng đời của App.

3. Các trạng thái của ChatGPT App: từ bản nháp đến gỡ khỏi công bố

Hãy mô hình hóa “máy trạng thái” cho App của bạn. Ta tạm nói về bốn trạng thái chính: Draft / Dev-only, Under review, Published và Paused/Removed.

Máy trạng thái vòng đời

Thử vẽ nó như một sơ đồ:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / bản nháp
    Review: Under review (Store)
    Published: Trong Store, sẵn sàng cho người dùng
    Paused: Paused / Removed

    Draft --> Review: Gửi đi review
    Review --> Draft: Bị từ chối / trả về để chỉnh sửa
    Review --> Published: Được chấp thuận
    Published --> Paused: Tạm dừng / gỡ xuống
    Paused --> Draft: Tiếp tục làm việc ở chế độ dev
    Draft --> Published: Triển khai nội bộ không qua Store (cho tổ chức)

Ở trạng thái Draft, App của bạn chỉ tồn tại như một tài nguyên dev. Bạn có thể kết nối nó trong Developer Mode, thử các tính năng khác nhau, nhưng không đưa nó lên Store.

Khi quyết định đã đến lúc cho mọi người thấy App, bạn gửi nó “đi review” — trạng thái Under review. Tại đây OpenAI (hoặc hệ thống review nội bộ của tổ chức bạn) sẽ kiểm tra việc tuân thủ chính sách, độ ổn định, an toàn cơ bản và UX hợp lý.

Nếu mọi thứ ổn, App chuyển sang Published: nó xuất hiện trong Store hoặc trở nên khả dụng cho người dùng trong công ty bạn (nếu là kịch bản doanh nghiệp). Từ thời điểm này người dùng thực bắt đầu đến, và mọi thay đổi về code hay cấu hình cần được lên kế hoạch cẩn thận hơn.

Nếu bạn tạm thời không muốn App khả dụng, có thể đưa nó vào trạng thái Paused/Removed. Ở trạng thái Paused, nó ẩn khỏi người dùng mới nhưng có thể tiếp tục chạy với phiên đã mở hoặc tắt hẳn — chi tiết tùy vào triển khai nền tảng và cài đặt của bạn.

4. Store: khi App của bạn trở thành sản phẩm

Developer Mode — gara riêng của bạn. Store — trung tâm đại lý chính thức. Tại đây có người dùng, xếp hạng, quy tắc listing và review.

Điều gì thay đổi khi bạn lên Store

Điều đầu tiên và quan trọng nhất: App của bạn trở thành “sản phẩm”. Nó có listing: tên, mô tả, biểu tượng, danh mục, đôi khi là các gợi ý khởi đầu cho hội thoại. Dựa vào siêu dữ liệu này, ChatGPT Store sẽ tìm kiếm và đề xuất ứng dụng cho người dùng, còn chính mô hình sẽ hiểu App phù hợp trong bối cảnh nào.

Điều thứ hai — review và chính sách. Trước khi App xuất hiện trong Store, nó sẽ được kiểm tra về an toàn, nội dung và UX. Điều đó có nghĩa là:

• không được lén thu thập dữ liệu cá nhân vượt mức cần thiết;
• không được hứa những gì App không làm;
• không được vượt ra ngoài các danh mục nội dung cho phép.

Chúng ta sẽ nói kỹ về chính sách và sandbox ở các bài sau, nhưng ngay bây giờ hãy coi Store là nơi bạn chỉ mang tới những phiên bản “đã dạy dỗ” tương đối của App.

Điều thứ ba — trách nhiệm về ổn định. Khi còn chơi ở Dev Mode, sự cố là chuyện của bạn. Trên Store, người ta kỳ vọng App của bạn có khả dụng hợp lý, độ trễ chấp nhận được và không có “màn hình đỏ chết chóc” trong widget. Ở các mô-đun sau, chúng ta sẽ nói về SLO, metrics và review của Store trong chính ngữ cảnh này.

Phiên bản: dev so với production

Câu hỏi điển hình: “Nếu tôi cập nhật code, người dùng sẽ thấy gì?”. Trong thế giới ChatGPT Apps, hữu ích khi nghĩ đồng thời về hai “nhánh”:

• nhánh dev, được kết nối với Developer Mode và có thể trỏ tới dev server nằm cạnh IDE của bạn;
• nhánh production, được gắn với cấu hình đã xuất bản trên Store và trỏ tới URL ổn định.

Về mặt kiến trúc, bạn thậm chí có thể biểu đạt điều này bằng một type TypeScript nhỏ trong dự án:

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

Trong thực tế, cấu hình được nền tảng ChatGPT lưu giữ chứ không phải code của bạn, nhưng các cấu trúc như vậy giúp ghi nhớ rằng đó là hai “bản thể” khác nhau của cùng một App.

Phát hành ChatGPT App giống phát hành ứng dụng trên Apple App Store hơn là cập nhật website. Widget và mcp-tools của bạn mỗi lần đều được cache khi phát hành ứng dụng. Review có thể mất 2 tuần. Vậy nên không có chuyện “đẩy lên production rồi test tiếp ở đó”. Bạn phải gửi review một ứng dụng đã được kiểm thử đầy đủ và ổn định.

5. Bối cảnh tổ chức: tài khoản cá nhân vs công ty

Chúng ta đã tách App thành nhánh dev và production và xem điều đó phản ánh ở Store ra sao. Một chiều đo quan trọng khác của vòng đời là “nó sống ở đâu” về mặt tổ chức.

Ở trường hợp đơn giản nhất, bạn làm App như một cá nhân trong ChatGPT Plus của riêng bạn. Khi đó Dev Mode là của riêng bạn, Store cũng nằm dưới tài khoản của bạn. Mọi thứ khá đơn giản: làm cho mình, đăng lên, mang lại niềm vui cho thế giới.

Nhưng rất thường xuyên, ChatGPT Apps sống trong bối cảnh doanh nghiệp. Lúc này xuất hiện vài vai trò bổ sung. Có admin của tổ chức quyết định App nào khả dụng cho nhân viên, cái nào cần chặn, cái nào chỉ cho nhóm pilot dùng. App của bạn có thể được xuất bản không phải cho toàn thế giới mà chỉ cho một công ty cụ thể, thậm chí cho các phòng ban cụ thể bên trong.

Trong kịch bản đó, vòng đời có thể như sau: trước hết App chỉ tồn tại như dự án dev trong nhóm; sau đó xuất hiện “production nội bộ” — ví dụ chỉ khả dụng cho phòng kinh doanh để pilot. Chỉ sau này, nếu mọi thứ tốt đẹp, bạn mới quyết định gửi App lên Store toàn cầu để biến nó thành sản phẩm bên ngoài.

Về kiến trúc, điều này quan trọng vì bạn cần thiết kế App sao cho hoạt động tốt cả như công cụ nội bộ lẫn sản phẩm công khai. Đôi khi điều này có nghĩa là có feature flags, các chế độ “chỉ nội bộ” và cấu hình xác thực riêng.

6. Kịch bản thực tế: vòng đời GiftGenius

Để mọi điều trên không quá trừu tượng, hãy xem App giả định GiftGenius — trợ lý chọn quà tặng, sẽ đồng hành cùng chúng ta trong khóa học.

Giai đoạn 1. Ý tưởng và nguyên mẫu thô trong Dev Mode

Bạn quyết định làm GiftGenius: một App hỏi người dùng tặng cho ai, ngân sách bao nhiêu và người nhận quan tâm điều gì, rồi đề xuất lựa chọn dựa trên danh mục sản phẩm của bạn.

Ở bước đầu, bạn:

1. Dựng một dự án Next.js đơn giản với widget tối thiểu.
2. Bật Developer Mode trong ChatGPT và thêm URL của dev server vào đó.
3. Thực hiện vài cuộc đối thoại thử: nhờ GPT “Hãy giúp chọn quà cho người bạn là game thủ trong tầm $50” và xem nó gọi App của bạn, render widget và UX trông ra sao.

Ở giai đoạn này bạn chưa nghĩ về Store, review hay icon đẹp. Nhiệm vụ là chứng minh với bản thân và đội ngũ rằng ý tưởng hoạt động và nền tảng ChatGPT cho phép hiện thực hóa kịch bản mong muốn.

Giai đoạn 2. Củng cố nguyên mẫu và “alpha” nội bộ

Khi đã chắc rằng kịch bản cơ bản hoạt động, giai đoạn “củng cố” bắt đầu. Bạn:

• đưa logic về cấu trúc dễ hiểu hơn;
• bắt đầu nghĩ xem App thực sự cần những quyền (permissions) và dữ liệu nào;
• kiểm tra cách App hành xử khi có lỗi (ví dụ, khi danh mục sản phẩm không phản hồi).

Vẫn ở Dev Mode nhưng không còn một mình: bạn thêm đồng nghiệp làm developer hoặc tester để họ cũng có thể kết nối App vào ChatGPT của họ. Vòng đời ở giai đoạn này vẫn xoay quanh trạng thái Draft: bạn cập nhật code nhanh, thử các pattern UX khác nhau, thảo luận feedback trong nhóm.

Giai đoạn 3. Chuẩn bị cho Store và review

Ở bước này bạn quyết định: “Được rồi, GiftGenius đủ chỉn chu để cho người dùng bên ngoài xem”. Trọng tâm chuyển từ code sang đóng gói sản phẩm:

• viết mô tả App trung thực và dễ hiểu;
• cấu hình permissions: giải thích App truy cập dữ liệu nào và vì sao;
• đảm bảo UX không gây hiểu lầm và App không hứa điều bất khả thi.

Đây là lúc chuyển từ Draft sang Under review. Bạn gửi App đi review, và một thời gian nó nằm ở trạng thái trung gian này. Có thể sẽ có ghi chú phản hồi: cần làm rõ chính sách bảo mật, chỉnh sửa câu chữ, thu hẹp permissions. Bạn quay lại Draft, hoàn thiện, rồi gửi lại.

Giai đoạn 4. Xuất bản và “cuộc sống thật”

Sau khi được duyệt, GiftGenius chuyển sang Published. Bây giờ người dùng có thể tìm thấy nó trong Store, ChatGPT có thể gợi ý nó theo các truy vấn phù hợp, còn bạn bắt đầu thu thập feedback thực tế, quan sát mức sử dụng và nghĩ về mở rộng.

Kể từ giờ, mỗi thay đổi code không còn là “ôi để tôi vá nhanh chức năng này”. Đó là một mini‑release. Bạn cần nghĩ về backward compatibility, lên kế hoạch migration, nếu có thể hãy thay đổi phiên bản dev trước, kiểm tra nó, rồi mới cập nhật cấu hình production.

Khi cần, bạn có thể tạm đưa App vào Paused, ví dụ khi phát hiện lỗ hổng nghiêm trọng hoặc backend không chịu nổi tải. Nhưng bức tranh lý tưởng là dần phát triển nhánh Published, đồng thời không quên môi trường dev cho thử nghiệm.

7. Nhà phát triển nên nghĩ về môi trường: dev, staging, production + Dev Mode

Với GiftGenius, chúng ta đã đi từ ý tưởng trong Dev Mode tới App đã xuất bản. Giờ hãy đặt nó vào sơ đồ môi trường quen thuộc — dev/staging/production — và xem chúng tương quan thế nào với Dev Mode và Store.

Thường trong đầu bạn có thể giữ ma trận như sau:

Developer Mode về cơ bản “dán” vào hạ tầng dev hoặc staging của bạn: bạn công bố một URL tạm, ChatGPT sẽ dùng URL đó để test. Còn cấu hình của Store trỏ tới production-URL “trưởng thành”.

Trong tương lai, khi bàn về deploy lên Vercel và các tunnel, ma trận này sẽ trở thành các bước rất cụ thể. Nhưng ngay bây giờ, điều hữu ích là luôn biết request hiện tại của ChatGPT đang ở đâu — sandbox dev của bạn hay môi trường production nơi người dùng truy cập.

8. Một “mẩu code” về vòng đời

Để liên hệ với cách tiếp cận TypeScript quen thuộc, hãy viết một type đơn giản phản ánh vòng đời App không phải ở mức nền tảng, mà ở mức tooling riêng của bạn. Bạn có thể đưa nó vào repository để không quên các trạng thái khác nhau.

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – gợi ý quà tặng',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Bạn sẽ không bao giờ gửi đối tượng như vậy vào ChatGPT, nhưng nó giúp cả đội cùng bối cảnh. Bạn thậm chí có thể làm một CLI đơn giản hiển thị trạng thái của tất cả Apps để không nhầm lẫn đâu là nháp, đâu là thứ đã nằm trong Store.

Trong các mô-đun tiếp theo, chúng ta sẽ thường xuyên quay lại mô hình vòng đời này: khi cấu hình tunnel và deploy lên Vercel, thiết kế máy chủ MCP và kịch bản agent, suy nghĩ về dòng commerce và chuẩn bị review trên Store. Hãy nghĩ về Dev Mode và Store như hai cực của cùng một hệ: sandbox cho thử nghiệm và mặt tiền cho sản phẩm đã trưởng thành.

9. Những lỗi thường gặp khi làm việc với Dev Mode và Store

Lỗi 1: “Lên Store ngay, rồi tính sau”.
Đôi khi ta muốn “chiếm thị trường” càng nhanh càng tốt và đăng App lên Store ngay từ giai đoạn nguyên mẫu nửa vời. Điều này gần như chắc chắn dẫn tới đánh giá tiêu cực, thống kê sử dụng kém và thêm câu hỏi trong review. Lành mạnh hơn là sống vài vòng lặp trong Developer Mode trước, thu thập feedback từ đồng nghiệp và bạn bè, ổn định UX cơ bản rồi mới lên Store.

Lỗi 2: Trộn lẫn môi trường dev và production.
Kịch bản điển hình: bạn cấu hình Dev Mode trỏ vào cùng URL với production, rồi ngạc nhiên vì “vài thay đổi debug” lại bị người dùng thật nhìn thấy. Tách dev và prod URL cần cẩn thận như với web service thông thường. Nếu trong cấu hình ChatGPT App đang là production-URL — đừng dùng nó cho “thử nghiệm nhanh buổi tối”.

Lỗi 3: Thiếu nhận thức rõ ràng về trạng thái.
Khi lập trình viên không nắm rõ App đang ở trạng thái nào (Draft, Under review, Published, Paused), các tình huống dở khóc dở cười sẽ xảy ra: người này nghĩ App đã ở Store, người khác vẫn coi nó là nguyên mẫu local. Ít nhất hãy mô tả trong README của dự án: bây giờ App ở đâu và cần làm gì để chuyển sang bước tiếp theo.

Lỗi 4: Bỏ qua chính sách và review tới phút chót.
Một số đội viết App “như thể đó chỉ là website”, và chỉ nhớ tới chính sách, permissions cùng yêu cầu của Store trước ngày gửi review. Hậu quả là phải đại tu cách thu thập và lưu dữ liệu, viết lại mô tả và thu hẹp quyền. Tốt hơn là ghi nhớ khung chính sách ngay từ đầu và trong Dev Mode hãy thử nghiệm với các permissions tối thiểu, trung thực.

Lỗi 5: Không có chiến lược riêng cho sử dụng nội bộ và bên ngoài.
Nếu App ban đầu được tạo như công cụ nội bộ doanh nghiệp, rồi sau muốn biến thành sản phẩm công khai, rất dễ nhầm lẫn đối tượng. Bên trong công ty có thể chấp nhận UX kém “bóng bẩy” và kịch bản phức tạp hơn; còn trên Store công khai, người dùng kỳ vọng mức độ tiện dụng khác. Không hiểu rõ bạn đang ở chế độ nào dẫn tới việc App công khai trông như công cụ admin nội bộ, còn pilot nội bộ thì mắc kẹt vì bạn nghĩ quá sớm về Store toàn cầu.

Lỗi 6: Không gắn Dev Mode với khả năng quan sát (observability).
Developer Mode rất phù hợp cho gỡ lỗi, nhưng phải tận dụng ưu thế này. Nếu bạn không theo dõi log và không ghi nhận những request mà ChatGPT gửi tới App của bạn ở môi trường dev, thì sau này ở production có thể gặp bất ngờ khó chịu. Hãy dùng Dev Mode như sân chơi để học hành vi thực tế của mô hình và người dùng, chứ không chỉ để kiểm tra “widget biên dịch được”.