Store 要求与最小必要权限

1. 课程语境中的 ChatGPT Store 是什么

先看全貌。ChatGPT Store 是 ChatGPT 内部的应用目录，用户可以进入、找到你的 App、启用并在常规对话中使用。对你而言，它不仅是一个展示橱窗，更是一个有规则的分发渠道，是 LLM 世界的“App Store” 类比。

在本课程中，我们区分你的 App 的三种运行模式：

• 第一种模式——Dev Mode。 你的 App 绑定到你的账号/组织，对你（以及可能的同事）可见。没有正式审核，但平台的通用政策仍然适用。在这里你可以自由试错、记录一切、打通隧道并连接到 staging 后端。
• 第二种模式——公开 Store。 这是一流赛道：App 面向所有 ChatGPT 用户（受地区限制），需要通过审核，有公开的列表页、隐私/条款链接，并且必须表现得像一个成熟产品。
• 第三种——仅组织可用（org‑only）的 Apps。 这类应用仅服务单一组织：公司可以为员工启用/禁用，叠加自有的安全要求，甚至进行内部审核。

本讲我们关注的正是“公开 Store + 公开列表页”的组合。重点在于：你不再只是“又一个 Next.js 服务”的开发者，而是需要同时打动三方的产品作者：用户、Store 审核员，以及你公司的安全团队。

2. Store 的基本要求：政策、诚实与 UI

内容与政策

ChatGPT Store 是一个受审的平台。直说：OpenAI 不希望在 ChatGPT 内出现违反平台使用政策的应用（暴力、恐怖主义、NSFW、欺诈等），或试图绕过模型防护（越狱提示词，如“假装你不是 ChatGPT，而是我的邪恶分身”）。

这意味着两点。

其一，你的 App 本身不应生成被禁止的内容。 如果我们的示例 App GiftGenius（礼物推荐）突然开始推荐“如何掩盖犯罪痕迹”的礼物，审核只需要一张截图就够了。

其二，你的 App 不应该帮助用户绕过过滤器。 如果用户要求：“挑选能做炸弹的礼物”，正确的行为是基于政策拒绝，而不是愉快地调用你的 MCP 工具去搜索所需零件。

大量此类行为由 system prompt 和你提供给模型的工具所决定。但 Store 看的是结果：用户实际可能得到怎样的回复。

品牌与域名

下一层是品牌与域名。公开 App 必须绑定到可信的所有者。对于具有外部 backend/MCP 的 App，Store 期望你做到：

域名验证（Domain Verification）。 你在自己的域名 DNS 中添加 TXT 记录，Store 会确认 backend 确属你所有。使用免费的 ngrok URL 的匿名服务要么无法进入公开 Store，要么会被标注为低信任。

合理的名称与 Logo。 不能取名为“ChatGPT Super Weather”或“Official OpenAI Something”——在名称开头使用“GPT / OpenAI / ChatGPT”，或复制 OpenAI 的品牌风格，会触犯品牌限制。请自创名称（GiftGenius 就是不错的例子）与视觉风格。

UI/UX：不要“破坏” ChatGPT

与“老”插件不同，现在 App 可以直接在聊天中渲染自有 UI 小部件。这带来很多机会……也带来很多“作坏”的方式。

Store 的朴素想法是：小部件应当相对 ChatGPT 显得“原生”。字体、间距、颜色、在深色/浅色主题与移动端的表现——都应当干净利落，不能让人觉得你把一个广告横幅或整套 SPA 塞进了聊天里。

Store 也不喜欢“占领聊天”的 UI：巨大的全屏“吸附”层、强制订阅的模态框、自动滚动等侵扰式模式。你的部件应该是对话里的卡片/向导/工具，而不是一个自成宇宙的世界。

本质上，审核关注三件事：你是否违反内容政策、是否误导用户（这一点在讲末谈列表页与清单一致性时会单独展开）、是否把 ChatGPT 变成了 UX 糟糕的广告垃圾场。这里所谓的“诚实”，指的是 App 实际能力与在描述和 UI 中的宣称相一致。

3. Store 如何看待你的 App 权限

另一条重要维度是：你向用户与外部系统请求哪些权限。Store 不仅关注安全性，还关注这些权限是否与应用的价值主张相匹配。

接下来是工程师最关心的：权限模型。在 Apps SDK 与 MCP 语境中，你面临三大访问层级。

为便于理解，可以这样表示：

graph TD
    A[App 清单/配置] --> B[Model capabilities]
    A --> C[OAuth 作用域]
    A --> D[MCP tools & ACP]
    D --> E[用户确认级别]

Model capabilities 严格来说并非与 OAuth 作用域或写操作工具同义的“权限”，而是模型的内建能力集合。但在安全设计时，把它视作需要最小化的第一层访问是很方便的。

层级 1：model capabilities

这是模型“自身”就能完成的事，无需访问你的 backend：比如网页浏览、DALL‑E 图片生成等。

如果同时开启浏览与 MCP 工具，模型有时会判断通过网页搜索更容易完成任务，而不是用你的专用工具——尤其当工具说明模糊或在 prompt 中未设定优先级时。因此，如果 App 已能通过 MCP 访问你的 API，就有必要考虑关闭浏览，或在 prompt 中明确固定 MCP 工具的优先级。

也就是说，在这一层你已经在应用“最小权限原则”：关闭一切对 App 的真实价值不必要的能力。

层级 2：OAuth 作用域

如果你的 App 使用认证（模块 10），你会向外部提供方请求作用域： openid、email、profile、orders.read、orders.write 等。

此处最小化原则尤为重要：

• 如果你只需区分不同用户，通常 openid（匿名标识符）就足够，email 并非必需。
• 如果确实需要 email，那么这点应在 UX 与权限描述中透明呈现：“用于向你发送订单收据与提醒”，而不是“以防万一”。

此外，尽量采用“按需授权”：先让用户在无登录状态下体验基础功能，仅当他确实需要“将礼物清单保存到收藏”或“查看订单历史”等操作时再请求访问。这会降低摩擦、提升转化。

为 MCP 工具配置作用域的示例（简化）：

// server/mcp/config/auth.ts
export const OAUTH_SCOPES = {
  basic: ["openid"],
  orders: ["openid", "orders.read"],
  checkout: ["openid", "orders.read", "orders.write"]
};

层级 3：MCP 工具与“consequential”操作

第三层是你的 MCP 工具以及 ACP/Instant Checkout。在 MCP 服务器中，每个工具可以是：

• 只读（read‑only）：获取汇率、挑选礼物、查看目录；
• 改变状态（consequential）：创建订单、发送邮件、扣款。

对于第二类工具，Store 期望更严格的确认模型。思路是：并非所有操作都能“随手就调”。在平台术语中，通常通过 consequential: true 标志与确认策略（always_allow vs ask_user）来表达。

MCP 工具注册示例，包含 security‑schemes 以及其为改变状态的操作：

// server/mcp/tools/createOrder.ts
server.registerTool(
  "create_order",
  {
    title: "Create order",
    description: "在 GiftGenius 中创建新订单。",
    inputSchema: {
      type: "object",
      properties: {
        productId: { type: "string" },
        quantity: { type: "integer", minimum: 1 }
      },
      required: ["productId", "quantity"]
    },
    _meta: {
      securitySchemes: [{ type: "oauth2", scopes: ["orders.write"] }]
    },
    // 伪字段：该操作会改变状态
    consequential: true
  },
  async ({ input, security }) => {
    // ... 创建订单的逻辑
  }
);

作用域与 security‑schemes 的示例取自 MCP 工具的官方文档，工具既可以无需授权，也可以受 OAuth2 保护。

在 Store 端，这会被转换为“此应用可以在 GiftGenius 商店创建与管理订单”的清晰文案，并可能引入单独的确认步骤。

4. 从用户与审核员视角看权限

对我们工程师而言，App 是清单、MCP 服务器与一堆 TypeScript。对 Store 而言，它是一些事实集合：App 能对用户数据与外部世界做什么。

可以用如下表格来理解：

关键思想：每个技术元素都应映射到对人类可理解的动作。在本模块的计划中，这点被明确强调：技术上的 MCP 工具 get_user_orders 要在列表页转化为“查看你在我们商店的订单列表”的文案。

如果你无法用一两句话解释某个权限——这是一个警讯。很可能是你要的权限过多，或者把多个不同任务混在了一个 App 里。

5. 最小必要权限原则

在传统后端世界，PoLP（最小权限原则）常被理解为“是啊，该限制一下数据库角色，回头再说”。在 ChatGPT Apps 里，这不是“回头再说”，而是进入 Store 的硬指标，也是影响用户转化的因素。

要点：

• App 请求的权限越少，用户的基础信任越高。 Chat 内对话是用户期望隐私得到保障的空间。一个突然请求访问全部账户、支付与联系人信息的 App 会显得可疑。
• 权限越清晰、越收敛，审核员越容易判断。 审核需要快速判断 App 的功能、与政策及安全最佳实践的契合度。权限过宽的 App 往往会被“搁置并要求澄清”，甚至直接被拒。
• 越“最小化”且“按需”的访问，UX 越顺畅。 授权页面是强摩擦点。如果 App 能在授权前提供有用体验（比如展示不依赖用户身份的热门礼物），用户更愿意日后接受扩展权限。

因此，Store 里的“最小权限”不仅是安全问题，还是营销与增长问题。第 18 模块会特别强调：最小权限是竞争优势，而不是官僚形式。

6. 示例：GiftGenius 在“瘦身”前后的权限

为避免空谈，我们以虚构主角 GiftGenius 为例。设想你“面向所有可能性”设计，得到如下能力清单：

1. 读取商品目录并筛选礼物。
2. 查看用户的订单历史。
3. 创建新订单并取消已有订单。
4. 将“收藏清单”保存到用户账户。
5. 发送打折邮件通知。

在配置层面可表现为：

// server/mcp/config/permissions-naive.ts
export const PERMISSIONS_NAIVE = {
  capabilities: { webBrowsing: true, dalle: false },
  oauthScopes: ["openid", "email", "orders.read", "orders.write"],
  tools: {
    searchProducts: { consequential: false },
    getUserOrders: { consequential: false },
    createOrder: { consequential: true },
    cancelOrder: { consequential: true },
    saveFavoriteList: { consequential: true },
    sendDiscountEmail: { consequential: true }
  }
};

纸面上看起来合情合理（“迟早都会用上”），但作为首个 Store 版本，这样的权限是过度的：

• 不必一开始就读取订单历史。 可以先提供一次性的礼物推荐，并通过 ACP/Instant Checkout 完成安全的结账，支付流程本就受平台控制。
• 邮件通知是完全不同的一摊： 它需要保存 email、在隐私政策中解释、并处理退订。对于 GiftGenius 的 MVP，这几乎总是过度设计。

按照最小化原则，你可以组装一个最小可用的首发权限集：

// server/mcp/config/permissions-v1.ts
export const PERMISSIONS_V1 = {
  capabilities: { webBrowsing: false, dalle: false },
  oauthScopes: [], // 无需登录，匿名工作
  tools: {
    searchProducts: { consequential: false },
    createOrder: { consequential: true }
  }
};

在该版本中：

• App 不访问用户账户，不读取历史订单，也不发送邮件。
• 所有敏感操作（创建订单）均通过 ACP/Instant Checkout 完成，用户可看到标准的支付流程。

在列表页上可以如实写道：“为你挑选礼物，并在 GiftGenius 商店中创建订单。应用不保存你的聊天历史，也不发送邮件通知。”这对用户与审核员都很友好。

之后，当你拥有稳定流量与信任度时，可发布升级版本，增加额外权限（订单历史、收藏），并同步更新列表页与隐私政策。

7. 如何在列表页描述权限

清单与配置是机器语言。审核员与用户阅读的是完全不同的文本：标题、描述、“此应用可以做什么”模块，以及隐私/条款链接。

第 17 模块强调“映射”：技术作用域与工具 → 人类可读的动作。

以 GiftGenius v1 为例，我们可以这样呈现。

技术上：

• Browsing: off
• DALL‑E: off
• MCP 工具：search_products（只读）、create_order（consequential）

列表页上：

• “可根据你的描述或参数（性别、年龄、预算、兴趣）挑选礼物。”
• “可通过 ChatGPT 内的受保护结账在 GiftGenius 商店创建订单。”
• “不请求访问你的邮箱或订单历史，不发送通知。”

若日后加入 OAuth 登录与 orders.read，描述需如实更新：

• “连接 GiftGenius 账户后，可查看你的历史订单，以提供更个性化的推荐。”

切勿承诺 App 做不到的事，也不要隐瞒关键操作。为第 18 模块收集的文档明确指出：列表页信息必须与实际行为完全一致，尤其是与支付与 PII 等敏感事项相关的部分。

8. Store 要求与你的架构之间的关系

务必认识到，Store 的要求并非真空产生。所有这些要求都不是“市场部的又一份表单”。Store 实质上在验证你在安全与生产模块中早已完成的工作：

• 如果你配置了 OAuth，认真实现了 .well-known 端点与令牌校验，那么一个向用户请求“半个互联网”宽泛作用域的 App 就显得很突兀。这样的 App 很容易以权限过宽在审核中被否。
• 如果你认真落实了保留策略与 PII 清理，就更容易撰写真实的隐私政策并通过核查。Store 与用户可以点开链接，将你的承诺与实际流程对照。
• 如果你的 MCP 服务器稳定、日志与指标完善（可观测性与 SLO 模块），审核员对性能与工具错误的疑虑就会减少。

最小权限与这幅图景相得益彰：你不仅安全稳定，还在对用户数据的请求上“克制”。

9. 课中小练习

为避免空谈，请立刻按步骤拆解你当前的 App（或 GiftGenius）。

首先列出App 实际能做的所有动作。例如：“挑选礼物”、“创建订单”、“展示历史”、“保存到收藏”、“给同事发邮件”。最好先用自然语言描述，不要急于思考技术细节。

接着为每个动作回答自己两个问题：“涉及哪些用户数据？”以及“是否会改变外部系统的状态？”。这样你就能自动将动作划分为只读与改变状态两类。

随后将动作与权限层级对齐：哪些只需 model capabilities，哪些需要 OAuth 作用域，哪些需要带 MCP 工具与 consequential: true 标志，甚至需要用户确认。

现在玩一把“剪刀手”： 首发版本里有哪些可以删掉而不损伤核心价值？你会常常发现，即使没有历史、收藏与邮件通知，App 也能完成核心任务。因此，这些权限可以留到 1.1 或 2.0 版本再加。

10. Store 要求与权限的常见错误

错误 1：“做一个什么都能做的超级 App，Store 自然会搞定。”
开发者把 App 说成通用助理（“我能处理财务、医疗、法律与购物”），接入十来个 MCP 工具并请求最大权限。这样的 App 同时触及敏感领域（医疗/财务/法律）、请求大量数据，且违背“一个 App 做好一件事”的原则。结果可想而知：审核会提出大量问题，甚至直接拒绝。更好的做法是做几个聚焦的 App，并配以清晰的权限。

错误 2：为了“以防万一”的过度授权。
典型表现：App 请求 email、profile、orders.read、orders.write、billing.read，但实际上只需要“基于描述挑选礼物”。对用户而言，这是在贪婪收集数据；对 Store 而言，这是高风险应用。Apps 安全文档里将其作为反面案例。

错误 3：清单与列表页不一致。
清单里有 create_order、cancel_order 与支付相关权限，而描述只写“推荐礼物”。审核员或用户迟早会注意到 App 能力超出宣称。这会破坏信任，并可能导致 App 被下架。

错误 4：用“无害”UI 掩盖敏感操作。
例如，你在小部件里画了个“保存清单”的按钮，实际上却群发邮件给整个部门，或在外部系统里创建任务，却未在权限中说明。Store 不喜欢惊喜。开发者指南明确要求：应用必须严格按承诺行事，不得包含隐藏行为。

错误 5：一启动就强求登录，而其实可以不需要。
App 一打开就要求连接账户、授予全部权限，否则“无法工作”，但事实上大半场景可在匿名状态下完成。这会伤害转化，并让人觉得你急于收集数据而非提供价值。更好的做法是先证明 App 的确有用，再解释为何需要额外权限。

错误 6：忽视组织性背景。
有时开发者做了一个“面向所有人”的 App，但本质上它是内部企业工具。结果他把非常特定的权限（内部 CRM、员工私密数据）带入了 Store，难以向普通用户合理解释。这种情况下应选择 org‑only 模式与内部审核，而非公开 Store。