作者:Robert Kimani
人工智能工具(如GitHub Copilot和ChatGPT)的兴起引发了人们对于AI如何协助开发者生成和使用API SDK(软件开发工具包)的兴趣。凭借其能够简化重复性编码任务的潜力,AI为增强API工作流程提供了令人兴奋的机会。然而,这种新方法也带来了显著的挑战,包括可靠性、安全性和非确定性等问题。
在本文中,我们将深入探讨AI可以在SDK生成过程中扮演的辅助角色,审视诸如幻觉等常见陷阱,并探索AI如何补充传统的代码生成方法以提供平衡和高效的开发体验。
API是现代软件应用程序的基石,使不同的系统能够相互通信。SDK通过提供预打包的库和工具来简化API的使用,从而帮助开发者。传统上,SDK生成是一个手动且耗时的过程。然而,最近人工智能的进步为自动化SDK创建开辟了新的可能性。
AI在SDK生成中的一个关键优势是它能够处理枯燥重复的任务。通过解析OpenAPI规范或API文档,AI可以自动化创建构建SDK所需的各种模型、服务及其他组件。这减少了手动劳动,使开发人员能够专注于更复杂和创新性的任务。
例如,像这样的平台APIMatic正在试验使用AI来改善开发者的体验,通过训练AI与传统的代码生成工具协同工作。在这个混合模型中,AI可以动态地回答开发者的问题并探索API文档,而确定性的代码生成器则负责可靠地创建静态API访问代码。
下面的C#代码演示了如何与Spotify API为了创建一个新的播放列表,获取一位艺术家的热门歌曲并使用Spotify Web API SDK将这些歌曲添加到新创建的播放列表中。这是APIMatic的API副驾根据查询“如何创建一个新播放列表并添加泰勒·斯威夫特最流行的10首歌?”生成的。
这段代码处理整个工作流:
此文件包含双向Unicode文本,可能会与下方显示的内容有不同的解释或编译方式。为了查看,请在可以显示隐藏Unicode字符的编辑器中打开文件。了解双向Unicode字符的相关信息
使用SpotifyWebAPI.标准; | |
使用中SpotifyWebAPI.标准.身份验证; | |
使用SpotifyWebAPI.标准.控制器; | |
使用SpotifyWebAPI.标准.异常; | |
使用SpotifyWebAPI.标准.HTTP.响应; | |
使用中SpotifyWebAPI.标准.模型; | |
使用系统; | |
使用系统.收藏夹.通用; | |
使用系统.多线程.任务; | |
命名空间 测试控制台项目 | |
{ | |
公共的 类 程序 | |
{ | |
公共的 静态的 异步任务主菜单() | |
{ | |
使用OAuth凭证初始化Spotify客户端 | |
SpotifyWebApiClient 客户 = 新的SpotifyWebAPIClient.建造者() | |
.授权码认证( | |
新的授权码认证模型.建造者( | |
"OAuth客户端ID", //您的客户端ID | |
"OAuth客户端密钥", //您的客户端密钥 | |
"OAuth重定向URI" // 你的重定向URI | |
) | |
.OAuthScope权限范围( | |
新的 列表<OAuthScopeEnum> | |
{ | |
OAuthScopeEnum.播放列表修改私有化, | |
OAuthScopeEnum.播放列表修改公开权限, | |
}) | |
.构建()) | |
.环境( SpotifyWebAPI.标准.环境.生产) | |
.构建(); | |
尝试 | |
{ | |
将用户重定向以进行OAuth授权并获取令牌 | |
字符串 授权URL = 等待客户端.授权码认证.构建授权URL(); | |
字符串 授权码 = "待办:替换代码"; // 用获取到的授权码替换 | |
OAuth令牌 令牌 =客户端.授权码认证.获取令牌(授权码); | |
使用OAuth令牌重建客户端 | |
客户端 =客户端.ToBuilder() | |
.授权码认证( | |
客户端.授权码认证模型.ToBuilder() | |
.OAuth令牌(令牌) | |
.构建()) | |
.构建(); | |
} | |
抓住 (异常 e) | |
{ | |
控制台.写入行(e.消息); | |
} | |
创建一个新的播放列表 | |
播放列表控制器 播放列表控制器playlistController(注意首字母小写是常见的编码实践) =客户端.播放列表控制器; | |
字符串 用户ID = "斯梅坚(地名,可能需要根据具体语境确定准确译名)"; // 用你的Spotify用户ID替换 | |
用户播放列表请求 身体 = 新的用户播放列表请求 | |
{ | |
名称 = "泰勒·斯威夫特 top 10", | |
MPublic = false, | |
描述 = "泰勒·斯威夫特最受欢迎的十首歌曲", | |
}; | |
API响应<播放列表对象> 创建播放列表的结果 = null; | |
尝试 | |
{ | |
创建播放列表的结果 = 等待播放列表控制器.创建播放列表异步方法(用户ID,身体); | |
} | |
捕捉 (API异常 e) | |
{ | |
控制台.写入行(e.消息); | |
} | |
获取泰勒·斯威夫特的热门歌曲 | |
艺术家控制器 艺术家控制器 =客户端.艺术家控制器; | |
字符串 艺术家ID = "06HL4z0CvFAxyc27GXpf02"; 泰勒斯威夫特的Spotify艺术家ID | |
字符串 市场 = "美国"; | |
ApiResponse<ManyTracks> 热门歌曲结果 = null; | |
尝试 | |
{ | |
热门歌曲结果 = 等待艺术家控制器.获取艺术家热门歌曲异步方法(艺术家ID,市场); | |
} | |
抓住 (API异常 e) | |
{ | |
控制台.写入行(e.消息); | |
} | |
// 将热门歌曲添加到新播放列表中 | |
如果 (创建播放列表的结果 != null && 热门歌曲结果 != null) | |
{ | |
字符串 播放列表ID =创建播放列表的结果.数据.ID; | |
列表<字符串> trackURIs = 新的 列表<字符串>(); | |
foreach (var轨道在top Tracks 结果.数据.轨道) | |
{ | |
trackUris.添加(追踪.URI); | |
} | |
字符串 URIs = 字符串.加入(",",trackURIs); | |
尝试 | |
{ | |
ApiResponse<播放列表快照ID> 添加轨道结果 = 等待播放列表控制器.添加轨道到播放列表异步方法( | |
playlistId, | |
null, | |
uris | |
); | |
} | |
捕捉 (API异常 e) | |
{ | |
控制台.写入行(e.消息); | |
} | |
} | |
} | |
} | |
} |
以下是代码分解。
代码首先通过设置OAuth 2.0授权码流程来访问Spotify的API。它定义了OAuth客户端ID、客户端密钥和重定向URI,并请求管理播放列表所需的权限范围:
播放列表修改私有化
修改私人文档播放列表。注意,这里的“播放列表”可能是特定上下文中的术语,如果指的是更为通用的概念如音乐播放列表,则应译为“私人播放列表”。若此处特指文档或媒体库中的播放列表功能,请根据实际情况调整翻译。原文如果没有特殊含义直接翻译即可:“修改私人文档播放列表。”播放列表修改公开
修改公共播放列表。客户端在用户同意后通过将用户重定向到Spotify授权页面来获取OAuth令牌。然后使用该令牌来认证API调用。
授权后,一个播放列表控制器
被实例化以与播放列表进行交互。使用创建了一个名为“Taylor Swift Top 10”的播放列表。创建播放列表异步方法
带有隐私和描述参数的方法。
The 艺术家控制器
用于获取泰勒·斯威夫特的热门歌曲获取艺术家热门歌曲异步
指定艺术家的Spotify ID(06HL4z0CvFAxyc27GXpf02)和市场(US)。结果是包含它们URI(唯一Spotify轨道标识符)的热门歌曲列表。
然后代码将这些热门歌曲添加到新创建的播放列表中使用添加轨道到播放列表异步方法
它使用发送一组轨道 URI 到播放列表中播放列表ID
从播放列表创建响应中获得。
try-catch
用于捕获API调用过程中异常的代码块(例如,如果授权失败或无法创建播放列表)。授权码认证
该模型用于安全访问,在用户明确同意后允许应用程序修改用户的播放列表。此设置允许用户创建动态播放列表,个性化音乐体验,并将Spotify无缝集成到应用程序中。
通过利用API助手,这一系列复杂的API交互被简化为一个结构化且可执行的格式。该助手确保自动处理正确的端点、认证过程和API参数,使开发人员更容易实现诸如播放列表创建和歌曲管理等复杂功能,而无需手动编写每个细节。
虽然这听起来很有前景,但基于AI的SDK生成远不是一个完整的解决方案。尽管它有诸多优势,但仍有许多关键性的挑战亟待解决。
非确定性指的是AI模型对于相同的输入无法一致地生成相同输出的能力。这在SDK生成中尤为成问题,因为一致性至关重要。如果一个由AI助手生成的SDK每次都有细微差别,将来可能会导致严重的集成问题。开发者需要信任生成的代码是稳定和可靠的——这是目前AI技术的一个不足之处。
一个相关的问题是“幻觉”,即AI生成的代码在语法上正确,但与底层逻辑或API文档不符。例如,AI可能会误解一个API端点,或者创建看似功能正常但实际上完全无法使用的函数。
这可能导致令人沮丧的调试 session,在这些 session 中,开发人员必须筛选出由故障人工智能生成的代码行以纠正幻觉或不一致性。
大型语言模型(如GPT-4)在严格的令牌限制内运行。这些限制规定了单次运行中可以处理的输入量(例如,API文档或OpenAPI规范)和输出量(例如,SDK代码)。对于更大或更复杂的API而言,这成为一个重要的瓶颈。由于SDK生成通常需要处理大量代码库,目前AI的令牌限制使其无法一次性生成完整的SDK。
AI模型是在大量现有代码上进行训练的,这些代码既包括安全示例也包括不安全示例。这使得它们容易生成易受常见安全威胁(如SQL注入、跨站脚本(XSS)或路径遍历攻击)影响的代码。例如,一个看似无害的由AI生成的功能可能会有隐藏的安全漏洞,比如允许未经授权的文件访问,如果未经适当审查的话。
现代API的复杂性往往涉及管理认证、速率限制和敏感数据,所有这些都需要安全处理。仅仅依赖AI生成此类代码而不进行人工监督可能会导致严重的安全漏洞。因此,每一段由AI生成的代码都必须经过人类开发者的仔细审查和测试。
另一个与AI生成的SDK相关的挑战是,大型语言模型在管理长时间交互中的状态和上下文时存在困难。SDK生成通常涉及多个步骤,在这些步骤中,对先前状态的记忆至关重要,例如链式API调用或跟踪认证状态。如果没有有效的记忆机制,AI可能会生成无法正确管理这些交互的代码,从而导致工作流中断。
鉴于上述限制,人工智能目前尚不具备取代传统SDK生成方法的条件。然而,结合人工智能和确定性工具优势的混合方法提供了一个有前景的解决方案。虽然像APIMatic这样的确定性代码生成器能够确保可靠且可重复的结果,但人工智能可以增强灵活性并帮助处理更动态的任务。
随着AI的不断进化,它在SDK生成中的作用预计将会增长,尽管仍存在一些挑战。目前,将AI与传统的代码生成方法相结合提供了一种平衡的方法,可以提高开发人员的生产力而不牺牲可靠性和安全性。然而,一个重要的未来发展方向是集成以工作流为导向的规范,如阿拉佐到API设计和消费。
Arazzo 是在开放API倡议(OAI)下开发的一种工作流规范,它允许开发者超越基本端点描述,捕捉完整的API交互序列,包括状态转换和依赖关系。通过结合人工智能驱动的工具与像 Arazzo 这样的规范,开发者可以更有效地描述和自动化复杂的 API 工作流程。
本规范可以通过帮助管理需要上下文感知和状态管理的多步骤工作流,从而极大地促进AI在SDK生成中的应用。例如,涉及多个认证步骤、支付网关或用户驱动的工作流程的API可以通过Arazzo更好地表示。这种抽象级别可以帮助AI工具更准确地理解API调用的流程,并生成更准确、可靠的SDK代码。
此外,Arazzo的可扩展性允许开发人员在其工作流程中定义自定义业务逻辑,从而在确定性代码生成和人工智能辅助之间创建更全面的集成。这意味着,在AI继续处理动态查询解析和初始代码搭建的同时,像Arazzo这样的工具可以指导生成更为复杂、有状态的API工作流。
随着令牌限制的扩大和AI系统在保持上下文和记忆能力上的提升,未来的发展可能会使AI更高效地处理更大的代码库和多步骤工作流程。借助增强的规范如Arazzo,AI生成的SDK的准确性和适用性将得到提高,为更加无缝且可靠的开发体验铺平道路。
总之,未来人工智能在SDK生成中的发展将很可能涉及更深层次地与像Arazzo这样的工作流驱动规范集成,增强AI处理复杂API交互和有状态操作的能力,同时仍然依赖传统方法进行静态代码生成和安全管理。
人工智能正成为开发人员越来越有价值的工具,特别是在探索API和自动化重复性任务方面。然而,在非确定性、幻觉、安全风险以及处理大型代码库的能力不足等方面仍然存在重大挑战。
虽然人工智能可以增强SDK开发过程,但它尚未准备好完全取代传统方法。今天最有效的做法是采用混合模型,利用人工智能的动态能力,并依靠传统的代码生成器来确保可靠性。
youtube.com/theneewstack
科技发展迅速,不要错过每一集。订阅我们的YouTube频道以观看我们所有的播客、访谈、演示等内容。