前端也能玩转AI？OpenAI API接入实战手记
上周五晚上十点，办公室只剩我一个人。窗外下着小雨，咖啡凉了，VSCode里还开着三个没合上的 diff。产品下午突然甩过来一个需求：“能不能在婚礼邀请函H5里加个智能文案生成？用户输入‘浪漫海边’，就自动生成一段适合的请柬文字。”
我翻了个白眼——这不就是想用AI偷懒嘛！但转念一想，反正婚期快到了，自己正好也要写请柬，不如趁机把 OpenAI API 接一下，工作生活两头忙，能省一点是一点。
我是某大厂前端组的程序媛，在这个组干了快两年，日常除了和产品经理“斗智斗勇”，就是折腾各种架构设计和代码质量。最近组里推“AI赋能业务”，领导说谁先跑通 AI 能力谁就能优先调休——这不，我立马心动了。
为什么前端要关心 OpenAI API？
很多人觉得 AI 是算法同学的事，前端只负责调接口、展示结果。但现实是：用户体验的闭环，往往卡在前端这一环。比如：
- 用户输入“温馨家庭聚会”，AI 返回了一段“末日废土风”文案；
- 请求超时没处理，页面卡死，用户以为崩了；
- 没做流式响应，用户等了10秒才看到结果，直接关掉页面。
这些都不是模型的问题，而是前端交互设计和错误处理没到位。所以，与其等后端同学“封装好”，不如自己动手，丰衣足食。
快速接入：从零到跑通只需三步
OpenAI 的 API 其实非常友好，官方文档清晰，连我这种非算法出身的都能看懂。核心就三件事：
- 申请 API Key
- 选对模型（别乱用 GPT-4）
- 写个优雅的请求封装
第一步：拿到钥匙
去 platform.openai.com 注册，创建一个 secret key。注意：千万别把 key 提交到 Git！ 我们组有个实习生上周不小心把 key 传到 GitHub，被运维半夜拉起来删库，惨不忍睹。
建议用 .env.local 管理：
VITE_OPENAI_API_KEY=sk-xxxxxx
然后在代码里用 import.meta.env.VITE_OPENAI_API_KEY 读取（Vite 项目）。
第二步：选模型，别被“GPT-4”迷惑
很多人一上来就用 gpt-4，结果发现又贵又慢。其实对于文案生成这种任务，gpt-3.5-turbo 完全够用，价格只有 1/10。
| 模型 | 输入价格（每 1M tokens） | 输出价格（每 1M tokens） | 响应速度 | 适合场景 |
|---|---|---|---|---|
| gpt-3.5-turbo | $0.50 | $1.50 | ⚡️ 快 | 聊天、文案、简单推理 |
| gpt-4 | $30.00 | $60.00 | 🐢 慢 | 复杂逻辑、代码生成、高精度 |
我们这个“婚礼请柬生成”属于轻量级文本生成，果断选 gpt-3.5-turbo。
第三步：写个靠谱的请求函数
别直接在组件里 fetch！封装一层，加上 loading、error、retry 机制。
// api/openai.ts
export const generateWeddingText = async (prompt: string): Promise<string> => {
const response = await fetch('https://api.openai.com/v1/chat/completions', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${import.meta.env.VITE_OPENAI_API_KEY}`,
},
body: JSON.stringify({
model: 'gpt-3.5-turbo',
messages: [
{ role: 'system', content: '你是一个专业的婚礼文案策划师，请根据用户提供的关键词生成一段温馨、简洁、有仪式感的婚礼邀请函正文。' },
{ role: 'user', content: prompt }
],
temperature: 0.7, // 控制创意度，0.7 适中
max_tokens: 150, // 别让 AI 啰嗦
})
});
if (!response.ok) {
throw new Error(`OpenAI API error: ${response.status} ${response.statusText}`);
}
const data = await response.json();
return data.choices[0].message.content.trim();
};
关键点：
- system prompt 很重要！它决定了 AI 的“人设”。我试过不加，结果它给我写了一段“恭喜你成功逃离单身牢笼”……
temperature=0.7：太高会胡说八道，太低又死板。max_tokens限制输出长度，避免返回 500 字的小作文。
前端体验优化：让用户感觉“丝滑”
光跑通不算完，用户体验才是前端的主战场。
1. 加 loading 和骨架屏
用户点击“生成”后，立刻显示 loading 动画。别让用户以为没反应！
const [loading, setLoading] = useState(false);
const [result, setResult] = useState('');
const handleGenerate = async () => {
setLoading(true);
try {
const text = await generateWeddingText(inputKeyword);
setResult(text);
} catch (err) {
toast.error('生成失败，请重试～');
} finally {
setLoading(false);
}
};
2. 错误处理要友好
OpenAI 限流很严格，免费账号每分钟只能发几次请求。一旦超限，会返回 429 Too Many Requests。这时候别直接报错，可以：
- 自动重试（带退避）
- 提示“稍后再试”
- 本地缓存上次成功结果
3. 流式响应（可选进阶）
如果用 gpt-3.5-turbo 的流式接口（stream: true），可以实现“打字机”效果，用户看着文字一个个蹦出来，体验超棒。不过实现起来要处理 SSE（Server-Sent Events），对前端有点挑战。我暂时没上，等婚假回来再搞。
算法思维：Prompt 决定上限
虽然我不是算法工程师，但接了 AI 接口后深刻体会到：前端写的 prompt，其实也是一种“算法”。
比如最初我只传 用户输入：浪漫海边，AI 返回：
“在金色的沙滩上，海浪轻拍，你们的爱情如潮水般永恒……”
听起来还行，但太泛了。后来我加了约束：
“请生成一段 80 字左右的婚礼邀请函正文，包含‘海边’、‘夕阳’、‘誓言’三个关键词，语气温馨庄重，不要用比喻。”
结果变成：
“诚邀您于夕阳西下的海边，见证我们许下永恒的誓言。期待与您共度这温馨而庄重的时刻。”
精准多了！ 这让我意识到：AI 的输出质量，70% 取决于 prompt 设计。前端不仅要会调接口，还得懂点“提示工程”（Prompt Engineering）。
踩过的坑 & 血泪教训
CORS 问题：OpenAI API 不支持浏览器直接跨域！必须通过后端代理，或者用 Vite 的 proxy（开发环境）：
// vite.config.ts server: { proxy: { '/api/openai': { target: 'https://api.openai.com', changeOrigin: true, rewrite: (path) => path.replace(/^\/api\/openai/, '/v1') } } }生产环境一定要走后端，否则 key 会暴露。
token 计算陷阱：中文字符 token 消耗比英文高。一个“爱”字 ≈ 2 tokens。测试时记得用真实中文数据压测。
别信“万能 prompt”：网上很多通用 prompt 在实际业务中水土不服。一定要结合场景反复调优。
效果如何？值不值得搞？
上线三天，婚礼 H5 的“AI 生成”功能使用率高达 68%。用户反馈：“比我自己写的强多了！” 产品还特意在周会上表扬我，说这是“技术驱动业务”的典范（虽然我知道他只是想蹭 AI 热点）。
对我个人来说，最大的收获是：前端不再只是“切图仔”，而是能直接参与 AI 产品设计的关键角色。下次跳槽，简历上又能多写一行“主导 AI 能力前端落地”了（笑）。
最后的小建议
如果你也在备婚、赶项目、被 deadline 追着跑，不妨试试把 OpenAI API 接进来。别怕算法，前端离 AI 没那么远。一行 system prompt，可能就省下你写三天文案的时间。
对了，我的婚礼请柬最终用了 AI 生成的版本，老公说比他写的“吃了没”高级多了。这波，稳了 💍
（完）
评论 0