客户AI应用的构建集成清单

构建者集成清单可防止客户AI应用程序在所有权模糊、不清楚使用单位以及账单意外的情况下上线。对于开发机构来说，这是将交付的AI功能在交接后转化为可衡量成果的预上线通行证。

重要的界限很简单：客户应用程序是在ShareAI之外构建、托管和控制的。ShareAI是一个市场和API层，可以路由AI推理流量、处理客户支付的使用费用、应用构建者的利润或附加费，并根据生成的收入支持每月的构建者支付。

在上线之前、在定价讨论变得模糊之前、以及在支持团队接手他们无法解释的AI工作流程之前，请使用此清单。

构建者集成清单：上线前需要确认的事项

目标不是将每个机构项目转变为相同的定价模型。目标是使AI流量可追踪、可计费、可解释，并与客户成果保持一致。

1. 确认客户应用边界

从记录ShareAI在客户设置中做什么和不做什么开始。ShareAI不是应用构建器、CMS、托管平台或工作流构建器。代理或客户仍然拥有应用程序、用户体验、数据模型、权限和业务逻辑。

ShareAI位于AI功能之后。应用程序通过ShareAI发送选定的推理流量，这些流量可以成为使用计费和构建者收益的基础。这一区别帮助客户理解为什么集成不会取代代理的产品工作。

• 确认构建者： 负责AI流量的代理、应用所有者、维护者或产品团队。
• 确认客户： 支付路由使用费用的用户、客户、工作空间或最终客户。
• 确认应用表面： 聊天机器人、门户网站、CRM工作流程、CMS插件、支持自动化、商业功能或内部工具。
• 确认交接负责人： 负责处理客户关于定价、使用、支持和功能行为的问题。

2. 选择客户理解的使用单位

AI成本通常以技术单位开始，例如输入令牌、输出令牌、模型调用和缓存上下文。这些细节很重要。OpenAI的 API定价 是一个模型选择和使用类型如何影响成本的例子。

客户通常需要一个面向业务的单位。支持负责人可能理解解决的工单数量。法律运营团队可能理解审阅的文件数量。商业团队可能理解生成的产品描述或创建的评论摘要。

选择一个将AI消费与客户价值连接的单位。然后将该单位映射回底层的ShareAI路由推理使用。

• 支持自动化：AI回答、工单摘要、问题解决或升级处理。
• 文档工作流程：处理的文档、总结的部分、提取的实体或生成的草稿。
• CRM自动化：合格的潜在客户、总结的笔记、起草的跟进或丰富的记录。
• CMS和商业：产品描述、内容重写、搜索查询、评论摘要或推荐。
• 内部工具：部门请求、报告生成、工作区使用或员工助手运行。

3. 映射ShareAI路由路径

在启动之前，决定哪些生产AI调用应该通过ShareAI路由，哪些应该留在非货币化路径之外。并非每个请求都需要相同的模型、利润或面向客户的处理方式。

技术交接应明确用户操作、AI请求、模型或模型类别、回退预期以及报告所需的使用记录。团队可以使用 ShareAI文档 和 API参考 作为实施的起点。

• 触发： 什么用户或系统操作会创建AI请求？
• 路由： 哪些请求在生产环境中通过ShareAI处理？
• 模型选择： 哪些模型选项符合功能需求、延迟需求和成本配置？
• 回退： 如果某条路由不可用或过慢，应该发生什么？
• 日志记录： 应保留哪些请求ID、租户ID、客户端ID或工作区标签以供支持？

4. 在客户使用之前确定构建者的利润率

最清晰的定价对话发生在第一张发票之前。构建者的利润率应与客户应用的价值挂钩，而不是作为随机加价呈现。如果AI工作流程节省时间、减少支持票据、处理文档或筛选潜在客户，那么定价逻辑应该容易辩护。

资金流动应以简单语言记录下来：客户应用将选定的AI推理流量路由到ShareAI，构建者配置利润率或附加费，客户为路由使用向ShareAI付款，ShareAI根据生成的收入每月向构建者付款。

这是基于使用的经常性收入潜力，而不是保证收入。如果客户不使用AI功能，就没有使用量可供货币化。

5. 为报告和支持标记使用情况

使用标签是许多客户AI启动变得混乱的地方。支持票据、聊天机器人对话和后台工作流程可能都会调用模型，但它们不应该在后续无法分离。

至少，决定您的应用程序如何保留足够的上下文以用于操作和客户报告。保持标签易于业务理解，因为账户经理和客户利益相关者可能会在工程团队完成后使用它们。

• 客户或租户ID。
• 工作空间、部门或终端客户标签。
• 功能名称，例如支持摘要、潜在客户资格或文档审查。
• 使用单位，例如对话、运行、票据、文档或工作流程。
• 请求时间戳和内部请求ID。
• 面向客户的状态，例如已完成、失败、重试或升级。

6. 计划限制、安全性和故障处理

一个生产AI功能需要的不仅仅是一个成功的演示。决定在使用量激增、用户发送意外输入、模型输出需要审查或下游工作流程失败时会发生什么。

对于安全规划， OWASP LLM和生成式AI应用程序的十大安全问题 是团队应该审查的问题的有用外部参考，包括提示注入和不安全工具行为。不要将其转化为不支持的合规语言。将其视为一个实用的审查步骤。

• 为异常高的使用量设置使用警报。
• 定义当客户达到包含的使用级别时会发生什么。
• 为失败或延迟的AI请求记录文档后备行为。
• 决定哪些输出需要用户确认后才能影响客户端系统。
• 确保敏感提示、日志和保留期与客户自身的政策保持一致。

7. 准备客户交接

客户交接应使AI功能对非工程师易于理解。一个好的交接说明了功能的作用、跟踪的使用单位、付款方式、Builder利润的含义以及谁在上线后审查使用情况。

这对代理机构尤其重要。代理机构可能构建了第一个版本，但客户将每天使用该功能。清晰的交接说明减少了混淆，并使持续价值更容易维护。

• 功能负责人和支持联系人。
• 使用单位和可计费操作示例。
• 包含的使用量、付费使用量或补充政策（如适用）。
• 客户可以查看使用情况或请求报告的地方。
• 已知限制、后备行为和升级路径。
• 哪些更改需要定价或实施审查。

简单的启动检查清单

在客户AI应用上线之前，确保以下每项都有负责人。

• 客户应用明确由ShareAI之外的人员拥有和运营。
• Builder角色已记录。
• AI功能具有面向业务的使用单元。
• ShareAI路由的请求已识别。
• 模型、路由和回退行为已记录。
• Builder的利润或附加费已批准。
• 客户支付流程以面向客户的语言进行解释。
• 使用标签已定义，用于报告和支持。
• 限制、警报和失败行为已定义。
• 客户交接包括定价、使用和支持说明。

如需更多面向实施的文章，请浏览 开发者 类别，然后打开 构建者控制台 当您准备连接应用流量并配置使用利润时。

常见问题

什么是Builder集成清单？

Builder集成清单是一个预发布审查，用于团队通过ShareAI从现有应用路由AI使用。它涵盖了所有权、使用单元、路由、利润、客户支付、报告和交接。

ShareAI是否用于构建客户端应用程序？

不，客户端应用程序是在 ShareAI 之外构建和控制的。ShareAI 提供 AI 市场、API、路由、使用、计费、附加费和支付层，用于选定的推理流量。

谁应该使用此检查表？

它对开发机构、AI 自动化机构、SaaS 团队、插件开发者、聊天机器人团队以及已经拥有带有 AI 使用的应用程序的内部软件团队有用。

在 ShareAI 路由上线之前应该定义什么？

在生产使用开始之前，定义 AI 功能、使用单位、请求路由、模型选择、回退行为、客户支付流程、Builder 利润、报告标签和支持负责人。

机构应该如何选择使用单位？

机构应该选择客户认可的单位，例如解决的工单、处理的文档、代理运行、支持对话、生成的报告或合格的潜在客户。单位应将 AI 成本与业务价值联系起来。

Builder 使用的客户支付如何运作？

应用程序通过 ShareAI 路由选定的 AI 推理流量。客户为路由的使用向 ShareAI 支付费用，Builder 可以根据配置的利润或附加费获得每月支付。

Builder支付与Provider奖励有何区别？

Builder 的支付来自于从 Builder 应用程序路由的 AI 流量，包括配置的利润或附加费。提供者奖励是独立的，与向 ShareAI 网络贡献合格的计算能力相关。

每个 AI 功能都应该通过 ShareAI 路由吗？

不一定。路由那些使用有价值、可变且值得跟踪的功能。一些仅限管理员、测试或非计费请求可能根据产品设计留在非货币化路径之外。

应该如何向客户说明基于使用的 AI 定价？

使用简单语言。解释计费操作、为什么高使用量成本更高、包含了什么（如果有）、付费使用如何运作以及使用报告将在上线后如何审查。

此检查表是否适用于自托管或客户控制的部署？

是的，当部署通过ShareAI发送选定的AI推理流量时。注意隐私和合规语言：ShareAI可以被描述为流量和计费层，而不是全面的合规保证。

启动后应该监控什么？

监控使用量、失败请求、异常繁重的用户、模型选择、客户问题、利润假设，以及使用单位是否仍然反映客户收到的价值。

清单完成后下一步是什么？

打开Builder控制台，连接相关应用流量，配置使用利润，并确保面向客户的定价和支持说明与实施的路线保持一致。