OpenAI API 使用实战：从面试题挑战到上线的那些坑
去年双11前两周，我坐在上海公司附近那间不到30平的出租屋里，一边啃着便利店饭团，一边刷 LeetCode。没错，我又在准备跳槽了——做了6年 iOS 开发，Swift 从 beta 一路陪我熬到 5.x，Xcode 升级过无数次，连 Apple Silicon 都换过两台 Mac，但最近总觉得职业发展有点卡壳。
就在那时候，团队突然接到一个需求：给 App 加个“智能客服助手”，能理解用户问题并推荐解决方案。产品经理拍着胸脯说：“不就是调个 AI 接口嘛，三天搞定！” 我差点把键盘砸他脸上——但转念一想，这不正好是个机会？既能学点新东西，又能加到简历里，说不定还能应对下一场“AI 相关算法题”的面试题挑战。
于是，我撸起袖子，打开了 VSCode（对，我早就不用 Xcode 写脚本和后端逻辑了，插件装得比头发还多），开始研究 OpenAI API。
为啥选 OpenAI API？
其实我们内部也讨论过自己训模型。但现实很骨感：公司没 GPU 集群，运维一听“分布式训练”就摇头，测试同学连 Postman 都不太会用……最后老板一句话拍板：“先用现成的，快速验证。”
OpenAI 的优势很明显：
- 开箱即用：几行代码就能调用 GPT 级别的语言模型
- 按量付费：对我们这种小团队非常友好
- 文档完善：比某些国产大模型的 PDF 式文档强一百倍
不过，安全意识必须拉满。毕竟这玩意儿要处理用户输入，万一有人塞个 rm -rf / 进去（虽然模型不会执行），或者诱导它输出敏感信息，那就真成 P0 事故了。
所以第一步不是写代码，而是读文档里的 安全最佳实践。比如：
- 永远不要把 API Key 写死在前端或客户端代码里（iOS App 里硬编码等于送人头）
- 用户输入要做过滤和长度限制
- 输出内容要经过审核层（哪怕只是简单关键词过滤）
实战：从零接入 OpenAI API
我们的架构很简单：iOS 客户端 → 公司后端服务 → OpenAI API。这样既能控制调用频率，又能做日志和监控。
第一步：申请 Key 并配置后端
在 platform.openai.com 上注册账号，创建 API Key。我习惯用 .env 文件管理密钥：
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxx
然后用 Node.js（别问，我们后端是全栈 JS，老板说“统一技术栈”）写了个中间层：
import OpenAI from "openai";
const openai = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
});
export async function askAI(userQuery) {
// 安全校验：过滤特殊字符、限制长度
if (userQuery.length > 200) throw new Error("输入太长啦");
const cleanQuery = userQuery.replace(/[<>]/g, "");
try {
const response = await openai.chat.completions.create({
model: "gpt-3.5-turbo",
messages: [
{ role: "system", content: "你是一个App内的客服助手，请用简短中文回答。" },
{ role: "user", content: cleanQuery }
],
max_tokens: 150,
temperature: 0.3, // 降低随机性，避免胡说八道
});
return response.choices[0].message.content.trim();
} catch (err) {
console.error("OpenAI 调用失败:", err);
throw new Error("服务暂时不可用，请稍后再试");
}
}
注意几个关键参数：
| 参数 | 值 | 说明 |
|---|---|---|
model |
gpt-3.5-turbo |
性价比高，响应快；没上 gpt-4 是因为贵 |
temperature |
0.3 |
数值越低越确定，客服场景不需要创意 |
max_tokens |
150 |
控制输出长度，避免返回一大段废话 |
第二步：iOS 端集成
用 URLSession 发个 POST 请求就行，没啥特别的。但为了防止被逆向提取接口地址，我加了简单的签名机制（虽然防君子不防小人）：
func fetchAIResponse(query: String, completion: @escaping (String?) -> Void) {
guard let url = URL(string: "https://api.mycompany.com/ai/ask") else { return }
var request = URLRequest(url: url)
request.httpMethod = "POST"
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
let body = ["query": query]
request.httpBody = try? JSONSerialization.data(withJSONObject: body)
URLSession.shared.dataTask(with: request) { data, _, error in
// ...解析响应
}.resume()
}
踩过的坑：别笑，都是血泪
API Key 泄露
第一次部署时，我把 Key 提交到了 Git。还好用的是私有仓库，而且立刻 revoke 了。从此养成了.gitignore+.env的习惯。Token 超限
用户输了一篇《滕王阁序》，直接爆了 token 上限。后来加了前端字数限制 + 后端二次校验。模型“胡说八道”
有次测试问“怎么退款？”，它回：“请联系客服电话 400-xxx-xxxx”。问题是——我们根本没有这个电话！赶紧加了 system prompt 限定知识范围，并加了关键词黑名单。费用失控
上线第一天，有人写脚本疯狂调用，账单飙到 $200。赶紧加了 Redis 计数器，每人每天限 10 次。
和“面试题挑战”居然能联动？
有意思的是，这段经历居然帮我在一次面试中逆袭了。
面试官问：“如果让你设计一个 AI 助手，怎么保证安全性和可控性？”
我直接掏出手机，打开我们 App 的客服页面，说：“这是我们上周上线的功能，后端做了输入清洗、输出审核、调用限流，还加了人工兜底开关。” 然后顺手画了架构图。
他眼睛一亮：“你还考虑了 fallback 机制？”
我说：“当然，AI 不可靠的时候，自动转人工——毕竟我们不是在造 AGI，是在做产品。”
最后 HR 说，我“既有工程落地能力，又有安全意识”，offer 到手。
工具链 & 心得
现在我的 VSCode 里装了这些插件辅助开发：
- REST Client：直接在
.http文件里调试 OpenAI 接口 - dotenv：高亮 .env 文件
- Code Spell Checker：避免 prompt 里拼错单词（真的会影响效果！）
至于算法？说实话，这次没涉及训练，但Prompt Engineering 本身就是一种算法思维。比如：
- 用 Few-shot prompting 提供示例
- 通过 temperature 和 top_p 调控输出分布
- 用 chain-of-thought 让模型“分步思考”
这些技巧，在 LeetCode 上可学不到，但在实际业务中决定成败。
最后一点真心话
作为老 iOS 开发，我一度觉得 AI 离我很远。但这次项目让我意识到：工具在进化，开发者也要进化。你不需要成为算法工程师，但得知道怎么安全、高效地用好这些能力。
而且，现在的求职市场，但凡 JD 里写了“了解大模型”、“有 AI 项目经验”，薪资都能往上跳一跳。我不是鼓吹盲目追风口，但把新技术落到真实场景里，永远是程序员最硬的底气。
所以下次再看到“三天搞定 AI 功能”的需求，别急着骂 PM。或许，这就是你跳出舒适区、拿下下一个 offer 的契机。
对了，我现在已经搬到离公司更近的房子了——省下的通勤时间，刚好用来研究 fine-tuning。谁让咱们程序员，永远在折腾的路上呢？
评论 0