Google Connected Apps：先选好产品动作，再谈分发增长

Google 于 10 月 28 日推出 Connected Apps Platform 预览，为开发者把应用能力接入 Search 和 Gemini 提供了统一路径。对小团队来说，机会在于让用户在已经发起求助的地方，直接完成一件有用的事。真正昂贵的误判，是把新的接入渠道当成确定的获客渠道。

官方发布介绍了云端 MCP、Android AppFunctions，以及通过 Connected Console 注册、测试和提交应用的流程。开发者与市场的开放仍分阶段进行，自己的账号、目标地区是否可用，还需要另行确认。看到发布消息，可以开始研究用户需求；据此承诺上线时间或预测流量，证据还不够。

我们的判断是：先选定一个完整、具体的用户任务，再决定开放哪些工具。明确用户最终要完成什么、应用可以改变什么，以及什么证据才算完成，然后再把集成纳入路线图。

本文面向已有服务的非技术创始人、AI 应用构建者和小型产品团队，提供一个虚构的课程改期场景、一份可复用的试点任务书，以及衡量分发价值的方法。本文依据公开文档撰写，没有运行集成。下面的测试与决策条件都是建议，不是 Google、YBuild 或客户的实测结果。

1. 先理解这个新入口与现有产品的关系

Connected App 可以理解为：让用户在另一款产品里调用你服务的部分能力。承载对话的平台负责理解请求、选择可用动作，但正确的账号数据、业务规则和执行结果，仍由你的服务负责。它像是产品多开了一扇门，而用户进门时说话的方式变了。 MCP 即 Model Context Protocol，规定客户端如何发现和调用工具、访问相关资源。工具是一个定义明确的操作，例如查询已有预约。平台入口指 Search、Gemini 等发生交互的产品。完成结果才是用户真正得到的东西，可能需要多次工具调用，也可能需要跳回原应用。这几个概念不能混在一起统计。

Google 的平台概览介绍了账号连接，以及远程 MCP 和通过 AppFunctions 实现的 Android MCP 两条路径。不过，能开放的操作，不等于都适合对话。产品里最有价值的部分，也许需要并排比较、多人协作或精细编辑，继续留在原应用中反而更好。

以独立教师的课程管理应用为例。“我下一节课是什么时候？”可以从已有账号数据中得到明确答案；“有没有别的时间？”需要查询可约时段和用户偏好；“把下个月的课都挪一下”则会改变一组承诺。口头表达都很简短，背后的产品责任与客服负担却差别很大。

第一步应列出用户的问题，而不是后端函数。用户打开应用前要找什么资料，在应用里做什么决定，离开之后还需要什么？沿着这个过程梳理，才看得出对话入口是否真正减少了中断。如果只是复制一个本来就很容易找到的按钮，后续维护可能得不偿失。

用 AI builder 开发时，也应交付清晰的任务过程：输入是什么、输出怎样才有用、失败后怎么办。只说“接一下 Google”，等于让构建工具替你决定产品范围，结果通常是把最容易连接的接口都暴露出去。

2. 选择离开原界面后仍有价值的用户任务

好的候选任务，既有清楚的需求，也依赖你的应用独有的数据或服务。用户应该能解释：为什么这里需要用到你的产品？如果只是任何助手都能生成的通用建议，就很难让人愿意连接账号、保留授权，并再次回来使用。

对课程管理应用，首个任务可以是：查看下一节课、了解允许更换的时段、准备改期方案。它可能需要多个能力，却仍围绕一件完整的事。范围先不扩展到管理全部日历、付款和对外沟通。

可以先回答三个问题：用户本来就会在对话中提出这个需求吗？不引用你产品的界面布局，能否描述最终结果？服务能否依据现有规则稳定提供信息或执行动作？任何一项答不清楚，都应先访谈用户，再谈集成。

Google 的 MCP 开发指南把远程服务器作为跨平台基础能力的推荐路径，AppFunctions 则适合更深入地使用 Android 设备和应用上下文。指南也介绍了点名调用应用的方式。这些信息帮助选择接入方案，并不能证明某个入口一定有需求。

如果课程服务原本就在云端运行，远程访问账号信息可能更合适；如果产品价值取决于 Android 本地应用状态，就值得研究 AppFunctions。先让实施者用用户听得懂的话解释“到底需要哪些上下文”，再选方案。已有 MCP 服务器可以降低部分成本，却不是用户采用的理由。

同时写出明确的排除范围。例如，试点不自动批量移动已付款课程，不联系教师，不修改取消政策。这样既能让承诺更容易理解，也能避免每次演示受到好评就顺势扩容。用户也会知道，哪些任务仍应回到原应用处理。

范围聚焦，并不等于注册时只写一项能力。控制台前置要求规定，除了类别默认能力，还需要至少三项高价值能力。一个完整任务可以包含多个真正有用的能力；不要为了填表硬凑不相关功能。如果找不到足够扎实的能力，可能说明产品还不适合进入这个渠道。

3. 把获得接入、通过审核、发布和被用户发现分开

渠道试验需要一份外部依赖清单。否则，团队可能忙了几周准备发布活动，最后才发现目标用户还无法使用。每个依赖都应有负责人、证据和受影响的决策，不要在所有项目后面都填“Google 已宣布”。

官方注册与发布指南区分了预览测试、审核、批准和发布。批准后进入可发布状态，还需要单独执行发布动作。配置中也包含产品、国家或地区及语言。应记录自己应用的真实状态，不要统称为“已经集成”。

规划时至少保留四个独立判断：团队能进入开发流程；指定测试者能调用应用；所选版本已审核并发布；目标用户能在选定入口完成任务。前一步的证据不能自动证明后一步。即使应用已经可用，用户是否能发现它、是否愿意采用，仍是另一件事。

假设创始人承诺下周一就能从 Search 改期课程。在 Gemini 测试账号中演示成功，不能证明这个承诺成立；只看到审核通过截图，也无法证明产品、地区配置符合目标。销售话术应该跟随实际观察到的可用范围，并说明尚存的开放限制。

Connected Console 概览把测试者管理、对外资料、版本和发布放在统一流程中。团队可以据此维护上线记录，但仍须另留一份用户价值证据。完成管理流程，与证明用户得到帮助，回答的是不同问题。

尚未获得接入时，也可以继续做需求研究：展示明确标注为概念的方案，让用户描述自己的任务，再与当前做法比较。不要让人以为概念图就是已开放的 Google 功能。如果关键依赖仍不可用，而剩余研究也不会改变决策，就应暂停付费实施工作。

4. 把课程改期场景写到足以暴露失败

下面是虚构试点，不是客户案例。某课程服务有跨时区学生，且部分课程临近开始时不能改期。创始人想验证：对话入口能否降低安排改期的成本，同时不增加误订。

目标结果是：学生选中符合规则的替代时段，并准确理解课程究竟改了没有。先使用隔离的合成账号和虚构课程数据：一个账号有普通待上课程，一个临近改期截止时间，另一个没有可换时段。把这些初始状态写下来，评审者才分得清是模型理解错了，还是后端返回错了。

示例请求是：“能把我下一节课改到明天晚上吗？”执行前，需要确定是哪节课、采用哪个时区，以及政策是否允许。不能遇到歧义就默默选择第一条匹配记录。一次必要的澄清，即便还没触发工具动作，也可能是正确进展。

原型应明确区分：查询可用时段、准备改期方案、正式提交改期。方案里应显示原课程、替代日期与时间，以及相关条件。如果试点尚不支持提交，就直接说明，并提供能继续处理的原应用入口。建议不能被表述成已确认的预约。

故意加入会挑战承诺的情况：展示后的时段被别人约走；有两节课都符合“下一节”；授权过期；用户等了一会儿又重复请求。要求团队展示课程系统中最后的记录，不要只接受助手说“已完成”的最后一句话。

评审同时记录两件事：系统实际发生了什么，学生认为发生了什么。服务虽然正确拒绝了改期，但对话听起来像成功，仍是产品失败。相反，准确说明没有可换时段，也可以是有用结果。应在看精美演示之前确定这些标准，避免事后替模糊结果找理由。

5. 把账号连接当作用户体验的一部分

授权不只是藏在集成后台的配置。它是用户判断“这点方便是否值得开放数据”的时刻。创始人应该能用解释产品价值时同样自然的语言，说明连接会做什么。

Google 的 OAuth 实施指南推荐 OAuth 2.1 配合 PKCE，并把权限范围收敛到完成目标任务所需的程度。OAuth 支持委托授权：用户允许客户端在约定范围内访问服务。但它本身不会决定，某节课是否符合业务上的改期条件。

课程试点可以先写一段访问说明：连接需要读取相关课程和允许更换的时段；若支持正式改期，应在任务流程中有明确的用户决定。再由工程人员检查，这段说明是否符合实际权限和服务器行为。不能请求宽泛权限，却用很窄的文案让人误解。

准备两个课程数据故意不同的合成账号。连接其中一个时，不能读取或改变另一个的课程；切换账号后，再完整走一遍。之后撤销连接，检查系统能否明确引导重新授权，而不是编造账号答案。这些是建议采用的验收测试，并非本文已经审计 Google 授权机制。

同意连接，也需要有容易理解的退出方式。告诉用户在哪里断开，以及断开后产品会停止做什么。与此同时，另行解释你的服务已经保存的记录如何处理。断开第三方连接和删除课程账号，是两种不同意图，混在一起容易引发客服问题。

审查环境只使用隔离的合成数据。若演示依赖创始人真实的学生账号，失败就不容易重现，也不便安全地分享。即使评审者第一次接触产品、不了解隐藏的账号状态，也应该能看懂试点并判断结果。

6. 验收真实任务完成，也认可诚实的拒绝

工具返回只是中间事件。学生关心的是课程，而不是 JSON。因此，验收必须同时看服务记录、对话内容和用户理解。只看其中任何一个，都不足以证明完整任务成功。

Gemini Developer Mode 测试指南介绍了事件日志、工具结构、授权诊断，以及日期、时间和语言模拟。这些功能有助于解释交互为何失败，却不能替代检查真实预约记录，也不能替代让用户复述结果。

每个用例运行前先写预期。对不允许的临近开课改期，成功应是没有违规改变，并准确解释可行的下一步；对过期凭证，成功可能是暂停并要求重新连接；对允许的改期，必须是正确课程只改变一次，且学生理解新的安排。

测试应包含意图相同但表述不同的请求、必须澄清的歧义，以及超出宣传范围的任务。如果计划支持不同语言或时区，就在相应环境中重复日期敏感用例。创始人在自己时区里用英文说通了一次，不能据此承诺双语上线。

请求失败时，先分类再改提示词。Google 的注册故障排查指南分别列出了端点连通、传输、OAuth 发现、域名验证和工具同步问题。连接断了，不能当作用户不喜欢功能的证据；把连接修好，也不能证明任务有价值。

每个合成用例保留足够的复现材料：账号初始数据、用户请求、发布配置、相关工具结果、最终课程状态和评审说明。以后进入真实用户试点，也要控制留存的个人信息。证据的用途是定位错误，不应顺手形成第二套失控的客户数据库。

7. 直接复用这份创始人试点任务书

下面是一份建议采用的工作表。让 builder 动手前，先用自己产品的事实填好。“负责人”指对证据交付负责的人，不一定是亲自执行所有操作的人。空白格能把演示容易掩盖的未决问题暴露出来。

在任务书后再附一份用例台账。每行包含初始状态、请求、预期结果、实际结果、用户理解和证据链接。模型下次给出不同回答时，团队仍有具体材料可讨论，而不是靠印象争论。

提前约定暂停条件。一个合理的建议是：只要有用例改错账号，或在未获得预期授权时把方案变成正式承诺，就暂停。如果用户反复误解课程是否已改，也应先修改流程。这是本文建议的产品决策规则，不是 Google 公布的审核标准。

修正问题与扩大范围要分开。日期显示不清楚，与因为测试者问到发票就新增付款，是两类工作。后者会改变权限、失败方式和用户预期，应返回任务书重新评估，不能当成给 builder 补一句提示词就能完成的小改动。

8. 衡量有用的分发，不编造归因

发布说明称，正式集成可以追踪流量、延迟和错误率。这些运营信号有用，但并不能证明新增客户、留存收入或获客盈利。商业价值需要另一套定义。

课程应用可以按可观察事件记录：用户获得邀请或访问机会、连接账号、发起真实任务、正确完成、之后又为同类任务回来。有些曝光事件可能看不到，就标为未知。不要把第一次观察到工具调用，假定成每个用户旅程的起点。

分母尤其重要。在已连接账号里统计完成率，与在所有受邀用户里统计，是不同问题。一次改期内部重复调用工具，不是多个成功用户。失败后跳回应用才完成的任务，应按最终用户结果归类，同时保留这次中断带来的成本。

找相似任务，对比对话路径与现有应用路径。观察耗时、澄清、错误理解和人工协助。小规模试点更适合报告具体案例及反复出现的问题，不宜声称精确的转化提升。如果同一批人体验两种路径，条件允许时调整顺序，并注明先做一遍会给第二次带来学习优势。

账号连接也许主要服务老用户。只要确实让常见任务更容易，这也可能值得投入；但在获得获客证据前，应称为服务便利性。调用量突然增加，也可能只是好奇或重复尝试。先检查最终记录和后续使用，再判断分发效果。

成本同样要持续记录：端点运营、授权客服、审核准备、回归检查，以及员工接手失败的时间。用自己的实现和试点观察估算。任何公开发布都无法替你的产品确定客服负担，也不能保证平台曝光覆盖这些成本。

9. 决定现在做什么，哪些事继续等待

如果已有明确的用户任务，服务本身能执行必要规则，而且目标测试路径确实可用，就可以做有限试点。首批交付应小到创始人能够逐一检查结果；有证据证明新入口改善真实任务之后，再考虑扩大。

如果服务执行正确，但用户误解结果、觉得权限索取过多，或新流程反而增加了解释成本，就先修改。更清楚的方案展示、更好的返回应用路径，或更窄的能力范围，可能比换模型、增加工具更有效。

如果接入资格、目标用户可用范围，或必需的平台行为还未验证，就等待。维护带日期的依赖记录，继续做能改变范围判断的研究。不要按假定的发布时间招人，也不要承诺团队尚未测试的地区和语言。

如果价值完全依赖无法观察的广泛推荐流量，产品本身还不能可靠完成动作，或者需要的敏感上下文与收益不相称，就应停止。涉及复杂专业判断、账号隔离未解决，或关键动作必须多人审批的产品，不适合匆忙做对话上线。

维护责任也要提前确定。后端变化如何针对当前已发布工具约定做回归？授权问题由谁负责？服务中断时，用户如何回原应用继续？工具描述固定下来，不代表背后的服务行为也固定了。保留可恢复的旧实现，或其他有文档的恢复路径，并用合成数据演练。

本文不配图，因为任务书和改期场景已经能直接解释方法。虚构一张 Google 界面，反而容易让人以为我们已经测试过产品。今天真正有用的交付，是一个聚焦的用户任务、一份填好的试点表，以及是否值得投入工程资源的明确决定。

参考资料

1. Google：在同一处构建和管理 Connected Apps：10 月 28 日发布、分阶段开放。
2. Connected Apps Platform 概览：集成路径及账号关联服务。
3. Connected Apps MCP 开发指南：集成范围与实施流程。
4. Connected Console 前置要求：账号、端点和应用资料要求。
5. 注册、测试和发布：预览、审核、目标范围与发布。
6. Connected Console 概览：管理集成资料与版本。
7. OAuth 2.1 实施指南：委托授权与权限范围。
8. 在 Gemini Apps Developer Mode 中测试：诊断与环境模拟。
9. 注册故障排查：连接与配置故障分类。

资料核验日期为 2026 年 10 月 29 日。以上均为平台一手材料，不是用户结果的独立验证，也不保证任何具体账号已获得接入。本文未注册、提交或测试应用。