如果现在需要一个多小时才能完成的工作流程，在 Experience Cloud 中只需点击一下就能变成一个可控且可重复的流程，会怎样？本指南将展示 Adobe App Builder 如何将手动操作转化为可扩展的自动化流程，并详细介绍从概念到发布企业应用程序的完整步骤。
不久前，我帮助一家大型金融科技公司优化了他们的 Adobe Target 工作流程。他们的团队每次配置展示次数限制逻辑都需要花费近 45 分钟 — 这是一场涉及设置、受众、规则和验证的细致操作。看着这一切发生，我一直在想，一定有更好的方法。如果这一切能在数分钟内完成，甚至只需点击一下呢？
这直接引领我走进了 Adobe App Builder 的世界。
在大型企业环境中，团队通常依靠工具、脚本和内部经验来完成日常工作。虽然没有什么真正“出问题”，但总感觉步骤比应有的多。App Builder 提供了一条不同的路径：不是绕过平台，而是将工作流程构建到平台中。
一个自定义界面。在 Adobe Experience Cloud 内部。由您的逻辑、您的 API 和您的自动化驱动。
这正是我构建的 — 一个轻量级内部应用程序，可自动处理整个展示次数限制设置。曾经需要数十次手动操作的任务，现在变成了一个直接嵌入 Adobe UI 的整洁仪表板。
在本文中，我将分享 App Builder 的工作原理、为何它对企业团队如此有价值，并介绍启动和运行自己的应用程序所需的命令和配置。无论您是要自动化特定工作流程，还是要构建完整的内部产品，本指南都应能为您提供一个坚实的起点。
什么是 Adobe App Builder？
Adobe App Builder 是一个完备的应用程序和运行时框架，用于构建在 Adobe 基础架构上运行的自定义云原生应用程序。它允许开发者扩展 Adobe Experience Cloud、Adobe Experience Platform 和其他 Adobe 产品的功能。借助 App Builder，团队可以创建 Adobe 与第三方系统之间的自定义集成，以简化操作并提高工作流程效率。
App Builder 提供了多个模板，可作为不同类型集成的起点。在本文中，我将重点介绍 excshell 扩展，它使您的应用程序能够直接在 Adobe Experience Cloud shell 中运行。
每个应用程序都：
-
通过 Adobe IMS 进行身份验证
-
使用 Adobe I/O Runtime 进行无服务器部署
-
与您的组织的 Adobe Experience Cloud 环境集成
-
通过统一的 Developer Console 和项目工作区模型进行管理
简而言之：它是您的 Adobe Experience Cloud 自定义扩展框架。
咨询视角
作为一名咨询师，我经常遇到想要实现以下目标的企业团队：
-
简化内部营销或内容审核工作流程
-
提供对复杂 Target 或 AEM 配置的可控可见性
-
自动化重复的 API 任务，如活动同步或受众创建
App Builder 优雅地解决了这些问题。它结合了安全运行时操作、基于 Spectrum 的 UI 组件和受控访问控制，无需管理基础架构或凭据即可实现快速开发。
真实案例概述
我的一个客户在 Adobe Target 中面临复杂的活动设置，涉及多个技术步骤且耗时较长。我提议构建一个应用程序，将复杂的 45 分钟设置过程简化为点击一下按钮。这个应用程序将与 Adobe Target Admin API 集成，以管理活动、产品建议和受众。主要功能：
-
可搜索、可排序的 Target 活动列表
-
可持久保存用户选择的Workspace 筛选条件
-
详情模态框（含针对每次体验的操作）
-
一键式产品建议更新（注入元数据）
-
可配置值的可选受众创建
-
采用 Spectrum 样式的 UI (Spectrum CSS)，呈现原生的 Adobe 外观
快速入门（新环境）
1) 先决条件
-
Adobe Developer Console 访问权限（涉及 App Builder 的项目）
-
Node.js 18+ 及 npm
-
Adobe I/O CLI：npm install -g @adobe/aio-cli
-
登录 Adobe 账户：aio login
2) 初始化
若从头开始：
3) 配置 app.config.yaml
app.config.yaml 文件定义了您的应用程序如何与 Adobe Experience Cloud 集成。它告知 App Builder 您正在构建何种类型的扩展，前端文件位于何处，以及哪些后端操作应在 Adobe I/O Runtime 中运行。
从宏观层面讲，您需要指定：
-
扩展类型 — 在此情况下，为 Experience Cloud Shell 扩展 (dx/excshell/1)，它允许应用程序直接显示在 Adobe Experience Cloud 界面中。
-
前端实现 — 指向您的主要 HTML 入口点（例如，index.html）的引用，以及应用程序的名称、描述和图标等元数据。
-
Web 资源文件夹 — 通常是一个包含 Spectrum 样式前端的 web-src 目录。
-
运行时操作 — 一组部署到 Adobe 无服务器基础架构的 Node.js 函数（例如，“getTargetActivities”、“updateOffer”等）。每个操作包含以下详细信息：
-
JavaScript 函数文件的路径
-
是否可通过网络访问
-
Node.js 运行时版本
-
任何注释（如需要 Adobe 身份验证）
-
简而言之，此配置将您的用户界面与后端逻辑连接起来，并在部署后使应用程序可在 Experience Cloud 中被发现。
4) 本地开发
应用程序在 http://localhost:9080提供服务，支持实时重新加载和 IMS 身份验证（在 Experience Cloud shell 中启动时）。
5) 部署到 Workspace
根据需要切换工作区（例如，预发布环境、生产环境）：
6) 发布到目录（生产环境）
经过 Exchange 审核后，应用程序将出现在您组织的 App Builder 目录中。
操作（无服务器 API）
本应用程序中使用的示例（Node.js，@adobe/aio-sdk + node-fetch）：
-
getTargetActivities — 列出组织/租户的 Target 活动
-
getActivity — 获取特定活动的详细信息 (/target/activities/{type}/{id})
-
getOffer — 读取 JSON 产品建议 (/target/offers/json/{offerId})
-
updateOffer — 更新产品建议 (PUT /target/offers/content/{offerId})
-
createAudience — 使用规则逻辑创建 Target 受众
每个操作均从缓存的 状态 存储中获取 IMS 访问令牌（由 getAccessToken 操作填充），并使用 Authorization: Bearer <token> 和 X-Api-Key: <clientId> 标头调用 Adobe Target API。
前端 (Spectrum UI)
UI 采用纯 HTML/JS，使用 Spectrum CSS：
-
带清除按钮的搜索输入框
-
Workspace 选择器（简洁选择器）
-
带状态标签和格式化时间戳的表格
-
带有 更新产品建” 和可选 创建受众 控件的模态对话框
UI 将所选 Workspace 存储在 localStorage 中，以便您的筛选条件在不同会话间保持有效。
命令参考
命令
描述
最佳实践与注意事项
-
在 Experience Cloud shell 内运行时，使用 runtime.done()（通过 @adobe/exc-app 运行时），以避免 shell 超时 UI（适用于 SPA 设置）。
-
避免长时间运行的操作；应快速返回，并在需要时进行流式传输或轮询。
-
为保持 shell 一致性，优先使用简洁的 Spectrum 组件。
-
将身份验证逻辑保留在操作中；前端调用您的操作，而不是直接调用 Adobe API。
-
将用户过滤器（例如工作区）保存在 localStorage 中，以提供更好的用户体验。
-
对于 Exchange 发布，请确保提供正确的元数据（名称、图标），并在 app.config.yaml 中包含扩展块。