从Vim到Llama：我在创业公司搞AI辅助编码的血泪史

上周五晚上十点半，我还在工位上对着终端发呆，屏幕上是第17次Fine-tuning失败的报错。窗外国贸的霓虹灯都快熄了，地铁末班车也快没了——这已经是这个月第三次因为模型跑挂而错过末班。但说真的，当我看到OpenCode最终在我们内部系统里跑出第一个靠谱的代码补全时，那种“成了！”的爽感，比喝十杯冰美式还提神。

我是谁？一个坐标北京、通勤一小时、键盘上F和J键磨得发亮的Vim党全栈开发。在这家三十来人的创业公司，我的title是“高级工程师”，实际干的活儿包括：写前端、调后端、修K8s、怼产品经理、帮测试搭环境，以及最近被CTO点名“搞点AI提效”。行吧，谁让咱是“啥都会一点”的人设呢。

为什么我们要搞AI编码？

事情起源于去年底的一次复盘会。产品迭代越来越快，前端要同时维护React和Vue两套老系统，后端微服务拆得七零八落，而新来的实习生连Git rebase都搞不定。CTO拍桌子：“能不能搞个智能助手，让新人少问点‘这个API怎么调’这种问题？”

一开始我想到的是GitHub Copilot。但一查价格，好家伙，团队人均$10/月，算下来一年小几万——对我们这种抠门创业公司来说，简直是奢侈。而且Copilot不能私有化部署，公司核心业务代码怎么可能喂给微软的云端模型？

于是，我们把目光投向了开源方案：Llama系列大模型 + 自研微调（Fine-tuning） + 内部代码库训练。目标很明确：打造一个叫 OpenCode 的内部AI编程助手，只懂我们自己的代码风格、API规范和业务逻辑。

选型：Llama2还是CodeLlama？

市面上能用的开源代码大模型不多，主要就两个选择：

• Llama2：Meta的基础语言模型，需要自己加代码预训练
• CodeLlama：Meta官方基于Llama2专门针对代码优化的版本，支持Python、Java、C++等，甚至还有13B参数的版本

我本来想省事直接用Llama2，结果第一次跑测试时，它居然把axios.post写成了axois.post——拼写错误就算了，更离谱的是它生成的SQL语句里出现了SELECT * FROM users WHERE id = "admin"，这要是上线了不得被安全团队追着砍？

果断切到CodeLlama。虽然它对JavaScript/TypeScript的支持不如Python那么强，但至少知道useEffect要配[]，也知道async/await不能乱用。关键是我们能拿到它的完整checkpoint，本地跑起来也不用求人。

Fine-tuning：不是你想训，想训就能训

真正的坑，是从Fine-tuning开始的。

我们的内部代码库大概有80万行，涵盖React、Vue2、Node.js、Go、Python。我用tree-sitter做了语法树解析，只保留函数定义、API调用、组件结构等“有用”片段，最后清洗出约12万条高质量样本。

但问题来了：显存不够。

公司那台“高性能训练服务器”其实是CTO从二手市场淘来的GTX 3090，24G显存。CodeLlama-7B光加载模型就要20G，根本没法开batch size > 1。我试过QLoRA（量化低秩适配），结果精度掉得厉害，生成的代码经常缺return或者漏闭包。

后来灵机一动：分阶段训练。

1. 先用所有语言混合数据做一轮通用微调，让模型记住我们的命名规范（比如API接口必须以/api/v1/开头）
2. 再分语言单独微调：前端组用React/Vue样本，后端组用Node/Go样本
3. 最后用真实PR（Pull Request）中的diff作为强化学习信号，告诉模型“这样改是对的”

训练脚本长这样（简化版）：

# 使用Hugging Face Transformers + PEFT 做QLoRA微调
python finetune.py \
  --model_name meta-llama/CodeLlama-7b-hf \
  --dataset_path ./data/cleaned_code.jsonl \
  --output_dir ./models/opencode-v1 \
  --per_device_train_batch_size 2 \
  --gradient_accumulation_steps 8 \
  --bf16 \
  --use_peft \
  --lora_r 64 \
  --lora_alpha 128 \
  --lora_dropout 0.1

注：--bf16是救命稻草，没它连7B都跑不动；--gradient_accumulation_steps 8相当于虚拟batch size=16，不然梯度太抖。

集成到Vim：让老派程序员也用上AI

作为骨灰级Vim用户，我坚决反对让团队换VS Code。所以OpenCode的客户端必须支持Vim！

我用coc.nvim插件框架写了个自定义provider，通过gRPC调用本地模型服务。配置如下：

// coc-settings.json
{
  "opencode.enable": true,
  "opencode.grpcEndpoint": "localhost:50051",
  "opencode.triggerCharacters": [".", "(", "/"]
}

现在，当我敲api.的时候，Vim会自动弹出我们内部的API方法列表；写const user = 时，它会根据上下文建议await getUserById(id)。最关键的是——所有推理都在本地完成，不用联网，不怕泄密，延迟也就300ms左右（比等npm install快多了）。

效果：真香，但别指望它替代你

上线一个月后，我们做了个粗略统计：

指标	训练前	训练后（OpenCode v1）
新人PR平均review轮数	3.2	2.1
重复性问题咨询量（Slack）	45次/周	18次/周
代码生成采纳率	-	63%

最让我惊喜的是，它居然学会了我们团队的“黑话”。比如我们有个内部工具叫dragonfly，用于日志追踪，普通模型根本不知道这是啥，但OpenCode能正确生成：

import { dragonfly } from '@internal/utils';
dragonfly.trace('user-login', { userId, ip });

当然，它也不是万能的。上周它试图用eval()来动态执行用户输入的过滤条件，被我当场毙掉。还有一次，它在React组件里写了this.setState，差点把实习生带沟里——我们早就用Hooks了好吗！

给想尝试的兄弟几点建议

1. 别一上来就搞7B/13B：如果你只有消费级显卡，先试试CodeLlama-7B-Q4_K_M（量化版），用llama.cpp跑，CPU也能推
2. 数据质量 > 数据量：宁可1万条干净代码，不要10万条屎山
3. Fine-tuning不是终点：一定要结合RAG（检索增强生成），把当前文件的上下文喂给模型
4. 别信“开箱即用”：所有开源模型都需要针对你的业务做适配，否则就是玩具

最后

现在，OpenCode已经成了我们团队的“第31号成员”。它不会抢我饭碗，但确实让我少写了好多样板代码。昨天实习生问我：“哥，这AI是不是你写的？”我笑了笑：“不，它是被deadline和CTO逼出来的。”

通勤路上，我还在想下一步：能不能让它自动写单元测试？或者根据Jira ticket生成骨架代码？不过在那之前，我得先搞定今晚的模型蒸馏——毕竟，明天又是新的一天，新的bug，新的需求，和新的可能。

（完）

P.S. 如果你也在用Vim搞AI，欢迎来GitHub找我互关。别问，问就是.vimrc比命还长。