一问题引入：为什么还要折腾本地 AI 编码？
这支视频解决的是一个很具体的问题：如果你已经习惯了 Claude Code、Copilot 或 ChatGPT 帮你写代码，能不能把一部分日常编码任务搬回自己的电脑上完成？作者的答案不是“本地模型全面替代云端模型”，而是用 Ollama 运行本地 LLM，再用 OpenCode 接进编辑器和终端，把组件生成、代码解释、轻量 API 路由这类高频任务先本地化。
视频的场景放在 Windows 笔记本上，硬件是带 Nvidia RTX 5060 laptop GPU 的 ASUS TUF A14。这个硬件信息重要，因为作者不是在服务器或工作站上演示，而是在一台学生和开发者都可能使用的移动设备上证明：本地模型只要选型合理，已经能进入日常开发链路。
这节课最值得带走的判断是：本地 AI 不一定替代最强云端模型，但它可以接管大量重复、低风险、上下文不敏感的开发任务，从而节省 token、降低等待时间，也让敏感代码少离开本机。
二核心概念：Ollama、OpenCode 和本地模型各管什么？
Ollama 是本地模型运行层。你可以把它理解成“模型服务”：它负责下载模型、启动模型、在本机暴露接口，并让 GPU 或 CPU 参与推理。视频里作者先安装 Ollama，再拉取 Qwen3 8B，这一步相当于把推理能力装到机器里。
OpenCode 是编码智能体层。它更接近 Claude Code 的使用体验：在项目目录里启动，对文件、命令、任务计划和代码生成有一定操作能力。它本身不是模型，而是把模型接到开发工作流里的壳。
Qwen3 8B 是具体的本地模型选择。作者提到自己机器有约 8GB VRAM，因此选择 8B 参数级别，这是视频里最实用的决策点：本地 AI 的第一步不是追最大模型，而是选一个能稳定塞进显存、速度能接受、支持代码和工具调用的模型。
| 层级 | 在工作流里的角色 | 视频中的对应操作 | 判断重点 |
|---|---|---|---|
| Ollama | 本地模型服务 | 安装、查看版本、拉取并运行 Qwen3 | 是否能稳定启动，GPU 是否参与推理 |
| Qwen3 8B | 实际推理模型 | ollama run qwen3:8b | 显存、速度、上下文窗口和代码能力是否匹配任务 |
| OpenCode | 项目级编码代理 | 在 VS Code 项目目录里启动并执行任务 | 能否识别本地模型、能否安全修改项目文件 |
| VS Code / Next.js | 开发与验证环境 | 生成任务表组件、启动本地 dev server | 产物是否能运行，而不只是生成文本 |
三实操步骤：把本地模型接进编码工作流
1. 安装并验证 Ollama
作者从搜索 Ollama 开始，下载 Windows 安装包，然后在终端运行版本检查。这里的关键不是命令本身，而是验证路径：先确认 Ollama 服务存在，再进入模型选择。很多本地 AI 教程失败，都是因为把模型、客户端和编辑器插件混在一起排错。
ollama --version如果版本命令能返回结果，说明本地服务层已经就绪。之后再从 Ollama 模型库选择适合自己机器的模型。视频中作者推荐 Qwen3，并说明 8B 版本对约 8GB VRAM 的笔记本更现实。
2. 拉取并测试 Qwen3 8B
第二步是拉取模型并直接对话测试。作者输入问候后，通过系统监控看到 GPU 使用率升高，说明推理没有只落在 CPU 上。这个小测试很朴素，但很有用：本地 AI 编码要稳定，首先要确认模型真的在本机跑，而且资源路径符合预期。
ollama pull qwen3:8b
ollama run qwen3:8b这里还隐含一个工程建议：先用小问题验证本地推理，再把它接入会修改文件的编码代理。直接让新环境改项目，排错范围会变大。
3. 安装 OpenCode 并选择本地模型
视频把 OpenCode 当作 Claude Code 的本地替代入口。安装后，作者在项目目录里启动 OpenCode，并通过模型选择确认它能看到 Ollama 侧的 Qwen3。中间出现了一次配置字段写错的问题：应该配置 models 而不是单数 model。这也是本节课最真实的部分：本地智能体不是一键魔法，配置名、模型 ID、上下文限制都会影响能否跑起来。
4. 写 OpenCode 配置
配置文件的核心是告诉 OpenCode：模型来自 Ollama，服务地址是 localhost:11434，模型名映射到 Qwen3 8B，并打开 tool call。作者还把上下文窗口从默认约 8K 提到 16K，输出上限设为 4096，以便它能处理稍长的项目任务。
{
"$schema": "https://opencode.ai/config.json",
"model": "ollama/qwen3:8b-16k",
"provider": {
"ollama": {
"name": "Ollama Local",
"baseURL": "http://localhost:11434/v1",
"npm": "@ai-sdk/openai"
}
},
"models": {
"qwen3:8b-16k": {
"name": "Qwen3 8B",
"toolCall": true,
"options": {
"context": 16384,
"num_predict": 4096
}
}
}
}不同版本的 OpenCode 配置 schema 可能会变化，所以这段配置更适合作为结构参考：provider、base URL、模型映射、tool call、上下文限制是必须检查的几个点。
5. 用真实任务验证：生成 Next.js 任务表
环境跑通后，作者没有停留在“你好”对话，而是让 OpenCode 创建一个 Next.js app，再生成一个可复用的 React data table 组件，要求 TypeScript、排序和分页，并能展示任务列表。这个验证方式比问模型概念题更可靠，因为它要求模型规划文件结构、生成组件、启动项目并在浏览器中查看效果。
随后作者继续加码：让本地 AI 添加 Next.js API route，接受 POST 请求、用 Zod 校验 body，并返回错误处理。这个阶段能看出本地模型的边界：它可以补齐路由和表单，也能让 demo 跑起来，但细节上出现了样式颜色等小 bug，需要人类开发者检查和修正。
四决策矩阵：哪些任务适合本地 AI？
本地模型的价值不在于“每件事都比云端更强”，而在于它把一部分任务变成了低成本、低延迟、可离线的工作流。下面这张表可以作为选择依据。
| 任务类型 | 适合程度 | 优点 | 主要风险 | 建议 |
|---|---|---|---|---|
| 解释已有代码、学习自定义 Hook | 高 | 上下文短、风险低、反馈快 | 解释可能不精确 | 适合本地优先，关键点再人工核对 |
| 生成普通 React 组件或表格 UI | 中高 | 可以快速起草结构和状态逻辑 | 样式、可访问性和边界状态容易漏 | 让它生成初稿，人类负责验收 |
| 添加简单 API route 和 Zod 校验 | 中 | 模板化强，能节省重复劳动 | 错误处理、状态同步可能不完整 | 必须运行测试或手动请求验证 |
| 跨仓库重构、复杂多 Agent 设计 | 低到中 | 可以做局部探索 | 推理深度和长上下文稳定性不如前沿云模型 | 用 Claude / GPT 等强模型主导，本地模型做辅助 |
| 敏感代码摘要、离线学习、课堂实验 | 高 | 数据留在本机，成本可控 | 模型能力受硬件限制 | 适合作为默认入口 |
五关键观点：本地 AI 是“省 token 的副驾驶”，不是万能替身
视频后半段很坦诚：作者展示了成功生成任务管理器，也展示了生成过程中出现的小瑕疵。他没有把本地模型包装成能完全替代 Sonnet、GPT 或 Claude Code 的方案，而是强调任务分层。日常组件、解释代码、课堂 notebook、轻量 CRUD，可以交给本地模型；真正复杂的多智能体、长链路规划、困难推理，仍然要用更强的云端模型。
本地 AI 可以替代很多日常使用 ChatGPT 和 Claude 的场景，并节省大量 token 和费用；但在真正复杂的多 Agent 工作和高难推理上，Claude 这类前沿模型仍然领先。
这句话对工程实践很重要。团队如果想引入本地编码模型，不应该先问“它能不能完全替代云端模型”，而应该先列任务清单：哪些任务低风险、重复多、验证快、上下文短？把这些迁到本地，收益会更稳定。