在县城用VSCode接入OpenAI：一个小镇做题家的实战手记

上个月底，我正窝在杭州余杭区某个老小区的出租屋里，一边啃着外婆送来的梅干菜烧肉，一边被产品经理凌晨三点发来的微信消息轰炸：“老板说咱们后台管理页面能不能加个‘智能问答’功能？用户问问题能自动回答那种。”

我盯着屏幕上还没跑完的单元测试，叹了口气——这不就是想套个大模型壳子嘛。但转念一想，最近面试刷题时总看到“熟悉LLM API调用”这种JD要求，再加上隔壁阿里网易的朋友都在聊AI工程化，与其被推着走，不如主动搞起来。于是打开VSCode（插件栏里Prettier、ESLint、GitHub Copilot、Rainbow Brackets挤得满满当当），新建了个openai-demo文件夹，准备从零接入OpenAI API。

这篇文章，就记录下我这个“县城远程打工人”如何在资源有限、网络不稳定、文档看不懂的情况下，把OpenAI API稳稳地塞进项目里。顺便聊聊怎么用它辅助解决那些让人头秃的面试题挑战，以及为什么我现在写代码离不开Cursor。

---

为啥非要用OpenAI？因为老板要“快”

我们团队做的是一个面向中小企业的SaaS工具，用户经常在工单里问：“怎么导出报表？”“为什么我的数据没同步？”以前这些都靠客服手动回复，效率低还容易漏。老板的想法很朴素：“让AI替我们回，省人。”

一开始我想自己微调个小模型，结果一看显存——本地只有16G内存的MacBook Air，连Hugging Face上最轻量的Llama-3-8B都跑不动。租云GPU？预算卡得死死的，财务说“除非ROI能算清楚”。最后只能退而求其次：用现成的API。

OpenAI成了最优解。理由很简单：

• 文档相对友好（虽然偶尔抽风）
• 支持流式输出（用户体验好）
• 有gpt-4o-mini这种便宜又够用的模型
• 国内访问虽慢，但加个代理+重试机制还能忍

而且说实话，在县城远程办公最大的优势就是时间灵活。我不用挤地铁，不用参加9点晨会，晚上十点到凌晨两点是我coding的黄金时段。这时候网络也相对稳定，调试API不容易被干扰。

---

第一步：注册、开Key、配环境 —— 别被第一步劝退

很多人卡在第一步：怎么拿到API Key？

去 platform.openai.com 注册账号（需要绑信用卡，但新用户送$5额度，够玩一阵子了）。登录后点右上角头像 → View API keys → Create new secret key。复制下来，立刻存到.env文件里：

OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

千万别提交到Git！我之前手滑把Key push上去，GitHub秒发邮件警告，吓得我立马revoke重开。血泪教训啊兄弟们。

然后装官方SDK：

npm install openai

或者如果你像我一样喜欢TypeScript（毕竟在阿里系氛围里待久了，TS是基操），直接：

import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

这时候你可能会遇到两个坑：

1. 国内访问超时：解决方案是配代理。我在VSCode里用REST Client插件测试时，加了Proxy-Authorization头；正式代码里则用axios拦截器统一处理。
2. 模型权限不足：比如你想用gpt-4o，但账号没开权限。这时候要么升级组织，要么换gpt-4o-mini（性价比之王，每百万token只要0.15美元）。

---

实战：给后台系统加上“AI客服”

我们的需求很简单：用户输入一个问题，AI返回结构化答案。但实际做起来才发现，光是prompt设计就能写篇论文。

最初我写的prompt是这样的：

你是我们的客服助手，请回答用户的问题。

结果AI经常胡说八道，比如告诉用户“点击设置里的蓝色按钮”——可我们界面根本没有蓝色按钮！后来才明白：必须给AI划定边界。

改进后的system prompt：

你是一个名为“智服助手”的AI客服，仅回答与[产品名称]相关的操作问题。
- 如果问题超出范围，回复：“抱歉，我只能回答关于[产品名称]的使用问题。”
- 禁止编造不存在的功能或按钮。
- 所有回答必须基于官方帮助文档（见下方上下文）。
- 回答简洁，不超过3句话。

然后把用户问题和相关文档片段一起喂进去。这里用了RAG（Retrieval-Augmented Generation）思路：先从知识库检索相关段落，再拼进prompt。

关键代码如下：

async function answerQuestion(userQuery: string) {
  // 1. 从知识库检索相关文档（简化版：硬编码几条）
  const relevantDocs = searchKnowledgeBase(userQuery);
  
  // 2. 构建messages
  const messages = [
    {
      role: "system",
      content: `你是一个名为“智服助手”的AI客服……（如上所述）\n\n【帮助文档】\n${relevantDocs.join("\n")}`
    },
    {
      role: "user",
      content: userQuery
    }
  ];

  // 3. 调用API
  const response = await openai.chat.completions.create({
    model: "gpt-4o-mini",
    messages,
    temperature: 0.3, // 降低随机性，避免胡说
    max_tokens: 300,
  });

  return response.choices[0].message.content;
}

上线后效果不错，准确率从最初的60%提升到85%以上。最爽的是，再也不用半夜回“怎么重置密码”这种重复问题了！

---

面试题挑战？让AI当你的模拟面试官

除了业务需求，我还发现OpenAI特别适合练面试题挑战。

比如上周我在刷LeetCode，遇到一道“设计Twitter”的系统设计题，完全懵圈。于是打开VSCode终端，用Node.js写了个小脚本：

const question = "请模拟一场系统设计面试，题目是：设计一个类似Twitter的短消息服务。逐步提问，并在我回答后给出反馈。";

const completion = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: question }],
  stream: true,
});

// 流式输出，边问边答
for await (const chunk of completion) {
  process.stdout.write(chunk.choices[0]?.delta?.content || "");
}

结果AI真的像面试官一样，先问我“QPS预估多少？”“怎么存推文？”“如何实现关注流？”，等我口头回答后，它还能指出漏洞：“你没考虑冷启动问题”、“缓存策略太简单”。

这比看面经强多了！关键是——它不会judge你。不像有些面试官一脸“这都不会？”的表情，AI永远耐心。

后来我把这个脚本封装成CLI工具，名字就叫interview-coach，现在每天晚饭后练20分钟，感觉系统设计能力肉眼可见地提升。

---

Cursor：我的VSCode外挂，真香！

说到这儿必须提Cursor。这玩意儿简直是小镇做题家的救命稻草。

简单说，Cursor就是基于VSCode深度魔改的AI IDE。它不仅能像Copilot一样补全代码，还能：

• 理解整个项目上下文（Copilot只能看当前文件）
• 根据自然语言指令生成函数（比如“写个防抖函数”）
• 解释复杂代码逻辑
• 自动写单元测试

举个真实例子：上周五晚上，我需要对接一个第三方支付回调接口，文档又臭又长。我直接在Cursor里选中那段混乱的示例代码，按Cmd+K，输入：“请用TypeScript重写这段代码，添加类型注解，并处理所有可能的错误情况。”

不到10秒，它给我生成了带Zod校验、try-catch包裹、日志记录的完整实现。我当时惊了——这比我手动写快三倍，而且更健壮。

更重要的是，Cursor能调用OpenAI API。你在编辑器里就能直接和模型对话，不用切窗口。比如遇到报错Error: connect ECONNREFUSED 127.0.0.1:8080，选中错误信息，问：“这是什么问题？怎么解决？”，它会结合你的项目结构给出建议。

对于远程办公的我来说，没有同事随时请教，Cursor就成了最靠谱的“虚拟队友”。

---

性能优化：别让AI拖垮你的服务

接入API后，性能成了新痛点。第一次压测，QPS超过20就大量超时。原因很明显：每次请求都要等OpenAI响应（平均800ms），而我们的Node.js服务是单线程的，很容易阻塞。

几个优化手段：

1. 缓存高频问题

用Redis缓存常见问题的答案。比如“如何修改邮箱？”这种，一天被问几百次，没必要每次都调API。

const cached = await redis.get(`qa:${userQuery}`);
if (cached) return JSON.parse(cached);

const answer = await callOpenAI(userQuery);
await redis.setex(`qa:${userQuery}`, 3600, JSON.stringify(answer)); // 缓存1小时

2. 请求合并（Debounce + Queue）

用户快速连续提问时，把请求攒起来，批量发送。不过要注意OpenAI的rate limit（gpt-4o-mini是每分钟3万token）。

3. 降级策略

当API不可用时，返回预设的兜底话术，而不是直接500。我们在Nginx层加了fallback：

location /api/ai {
  proxy_pass https://api.openai.com;
  proxy_intercept_errors on;
  error_page 502 503 504 = @fallback;
}

location @fallback {
  return 200 '{"answer":"小助手暂时休息，请稍后再试~"}';
}

4. 模型选型

别盲目上gpt-4o。对于简单问答，gpt-4o-mini延迟更低、成本更低。我们做了AB测试：

模型	平均延迟	成本（每千次调用）	准确率
gpt-4o	1.2s	$3.00	92%
gpt-4o-mini	0.6s	$0.30	85%
gpt-3.5-turbo	0.5s	$0.15	78%

最终选择gpt-4o-mini——性价比碾压。

---

写在最后：小镇做题家也能玩转AI

其实我一直觉得，“县城远程办公”不是劣势。没有大厂内卷，反而让我有更多时间沉下心来学东西。每天下班后，泡杯龙井，打开VSCode，折腾点新玩意儿，这种节奏刚刚好。

OpenAI API的接入过程，让我深刻体会到：AI不是取代程序员，而是把我们从重复劳动中解放出来。那些机械的CRUD、文档查询、基础debug，完全可以交给模型。而我们，该去思考更高维的问题——架构设计、产品体验、技术选型。

下次面试被问“你怎么看待AI对开发的影响？”，我会说：“它让我从‘码农’变成了‘AI指挥官’。”

对了，如果你也在刷面试题挑战，不妨试试用OpenAI当陪练；如果你还在纯手敲代码，强烈建议装个Cursor。这两个组合拳下来，效率至少翻倍。

最后放个彩蛋：我在GitHub开源了这个AI客服的简化版实现，搜 town-coder/openai-quickstart 就能找到。欢迎star，也欢迎提issue吐槽——毕竟，谁还不是个在县城里仰望硅谷的做题家呢？

（完）