研究用例

识别并优先考虑 Apps SDK 用例。

为什么要从用例开始

每个成功的 Apps SDK 应用都始于对用户试图完成的任务的清晰理解。ChatGPT 中的发现是由模型驱动的:当你的工具元数据、描述和过去的使用情况与用户的提示词和记忆相符时,助手会选择你的应用。只有在你已经映射了模型应该识别的任务和你可以交付的结果时,这才有效。

使用此页面来捕获你的假设,通过提示词对其进行压力测试,并在定义工具或构建 component 之前与团队就范围达成一致。

收集输入

从定性和定量研究开始:

• 用户访谈和支持请求 – 捕获用户今天依赖的待完成工作、术语和数据源。
• 提示词采样 – 列出应该路由到你的应用的直接请求(例如,"显示我的 Jira 看板")和间接意图("发布前我被什么阻碍了?")。
• 系统约束 – 注意任何合规要求、离线数据或速率限制,这些将在稍后影响工具设计。

记录用户角色、他们求助于 ChatGPT 时所处的上下文,以及每个场景中成功的定义(用一句话概括)。

定义评估提示词

当你有一个黄金集合来进行迭代时,决策边界调整会更容易。对于每个用例:

1. 至少编写五个直接提示词,明确引用你的数据、产品名称或你期望用户会说的动词。
2. 起草五个间接提示词,其中用户陈述目标但不提及工具("我需要保持我们的发布任务井然有序")。
3. 添加负面提示词,这些提示词不应该触发你的应用,以便你可以衡量精确度。

稍后在优化元数据中使用这些提示词,在不过度拟合单个请求的情况下提升召回率和精确度。

确定最小可爱功能的范围

对于每个用例,决定:

• 哪些信息必须 inline 可见才能回答问题或让用户采取行动。
• 哪些操作需要写入权限,以及它们是否应该在开发者模式下通过确认来限制。
• 哪些状态需要持久化在多轮对话之间——例如,过滤器、选定的行或草稿内容。

根据用户影响和实施工作量对用例进行排名。常见的模式是先发布一个具有高置信度 component 的 P0 场景,然后在发现数据确认参与度后扩展到 P1 场景。

将用例转化为工具

一旦场景在范围内,起草工具契约:

• 输入:模型可以安全提供的参数。保持它们明确,当集合受限时使用枚举,并记录默认值。
• 输出:你将返回的结构化内容。添加模型可以推理的字段(ID、时间戳、状态),以及你的 UI 渲染的内容。
• Component 意图:你是否需要只读查看器、编辑器或多轮工作区。这会影响稍后的 component 规划和存储模型。

在投入实施之前,与利益相关者(特别是法律或合规团队)审查这些草稿。许多集成在发布到生产环境之前需要 PII 审查或数据处理协议。

为迭代做好准备

即使有扎实的规划,也要期待在首次内部测试后修改提示词和元数据。在你的时间表中为以下内容留出时间:

• 每周轮换黄金提示词集并记录工具选择准确性。
• 从 ChatGPT 开发者模式中的早期测试人员那里收集定性反馈。
• 捕获分析数据(工具调用、component 交互),以便你可以衡量采用情况。

一旦应用上线,这些研究成果将成为你的路线图、变更日志和成功指标的支柱。