外包仔的AI辅助开发求生指南

刚下班，躺在我成都出租屋的沙发上，窗外飘进来火锅味。突然想写篇文章记录一下这几个月的工作状态——一个大专计算机应届生，靠自学前端苟进了外包公司，现在天天跟AI搭伙写代码。

说实话，我现在写代码已经离不开ChatGPT和Claude了，重度到断网就想请假。但这几个月踩的坑让我明白一件事：AI生成的代码，你敢直接复制粘贴上生产，它就敢让你半夜被报警电话叫醒。

Vibe Coding不是玄学，是保命技能

Vibe Coding这词是Andrej Karpathy提出来的，意思是“跟着感觉写代码”，让AI干活，你负责描述需求和审查结果。我一开始觉得这就是终极摸鱼状态，结果第一个星期就翻车了。

上个月给内部管理系统加数据导出功能，我用Claude生成了Node.js的CSV导出代码，本地和测试环境都没问题。上线第三天，运维大哥在群里@我：“你那个导出接口，有人导了8万条数据，服务器内存飙到95%了。”打开代码一看，AI的逻辑是把所有数据查出来放内存里拼字符串，完全没有流式处理的概念。8万条数据，不爆才怪。

这就是最大的坑：AI给你的代码在“能用”层面通常没问题，但在“用得好”层面，它完全不管。 它不会告诉你数据量大时会挂，不会提醒你加限流，不会考虑并发。这些事，还是得你自己想。

后来我学乖了。每次拿到AI代码，先问自己三个问题：数据量翻10倍会怎样？有没有资源泄漏风险？错误处理够不够健壮？想清楚了才敢往正式环境丢。

Function Calling的暗坑

Function Calling是我最近真正用上的功能。场景很简单：客服系统需要让大模型能查询订单状态、修改配送地址。对接公司内部LLM平台，支持OpenAI格式。我照着文档写了工具函数定义：

const tools = [
  {
    type: "function",
    function: {
      name: "query_order_status",
      description: "查询用户订单的当前状态",
      parameters: {
        type: "object",
        properties: {
          order_id: {
            type: "string",
            description: "订单编号"
          }
        },
        required: ["order_id"]
      }
    }
  }
];

联调时发现，模型返回的参数里order_id有时是undefined。查日志才明白：用户说“帮我看看上次那个订单到哪了”，模型识别到要调函数，但没提取到订单号，就直接返回空参数。

Function Calling的陷阱在于：模型不是编译器，它不会严格遵循参数定义。 required字段并不能保证参数一定有值。所以调用工具函数前，必须自己做参数校验：

const args = JSON.parse(functionCall.arguments);
if (!args.order_id) {
  return { error: "请提供订单编号" };
}
if (!/^[A-Z0-9]+$/.test(args.order_id)) {
  return { error: "订单编号格式不正确" };
}

还有个成本问题。Function Calling每次都要把工具定义和结果塞进上下文，对话轮次多了，token消耗蹭蹭涨。我们组有个接口，测试期间一天烧了80多块钱的token。后来加了缓存策略和意图识别前置判断，成本才降下来。

写在最后

作为一个靠自学入行的外包仔，我没什么资格给技术建议。但踩过的坑是真实的：AI能让你跑得更快，但方向得自己把握，刹车得自己踩。现在每次用AI生成代码，我都会想起那个差点搞挂服务器的周三下午。那种后背发凉的感觉，比任何代码审查都管用。安全第一，别让AI替你背锅——它背不动，最后挨骂的还是你。

写于成都出租屋，窗外还在飘火锅味。