我被本地AI坑了三天的血泪史

做技术这行，最憋屈的事就是看着一个标榜"智能"的系统，因为一些低级问题原地趴窝。最近我就遇到了这么一档子事——在折腾本地 AI 编程工具。

这事儿最近挺火的。原因很简单：开源模型越来越能打，大家也越来越在意数据隐私。自己跑模型写代码，听起来挺美。

我决定测试一下：让一个完全跑在本地机器上的编程 agent 写个游戏出来。不是那种糊弄人的 Demo，得是真的能玩的——有状态管理、有渲染逻辑、有输入处理那种。

结果嘛，折腾半天最后还真写出来了。但整个过程暴露了一堆问题，AI 工具链现在处理得真不怎么样。

配置看着没问题，实际全是坑

先说说我用的这套组合：

• 一个跟 provider 无关的编程 agent 命令行工具
• Ollama，在本地跑 OpenAI 兼容 API
• Qwen3.8 27B，跑在本地

32G 统一内存带 17G 的模型，绑绑有余，还支持工具调用和推理。这配置不算差了。

开头挺顺利。十五分钟，完整的 HTML 结构搞定，快两百行 NES 风格的 CSS，什么斜面边框、复古配色都有。

更绝的是，agent 写到一半自己发现问题了：它写了个文件，读回来一看，发现实际内容和想写的不对，直接修复了——没等我说。这种"自主纠错"的行为，确实有点东西。

然后它开始写游戏逻辑文件，然后，就卡住了。

噩梦般的循环

接下来发生的事情，但凡折腾过 AI 工具的应该都认识：

连着十三次，每次都写到一半直接断掉。流式输出直接消失，没报错、没解释、没任何有用的东西。

最气人的不是失败本身，而是看着 agent 的推理过程。它每次重试都从零开始推导设计思路，导致每次出来的方案都不一样——记分规则不同、实现方式不同。等于说它花了一小时思考，然后啥也没留下。

我第一反应是内存不够。关掉几个浏览器标签，内存多出来几个 G，情况稍微好一点。我以为找到原因了。

但这个结论是错的。

翻日志才发现真相

回去看服务端日志，真相完全不同。十三次失败里，一次内存溢出都没有。系统空闲内存一直在 21 到 27G 之间晃悠，模型本身才占 17G。内存压根不是问题。

真正的原因是配置对不上，而且这种对不上不会有任何提示。

agent 的配置说自己有 32,768 个 token 的上下文窗口。但 Ollama 重启后实际只给了 8,192。agent 根本不知道这事儿。它以为有 32k 的余量，兴冲冲地规划一个八百行的文件要一口气写完。结果写到 8k 的墙那里，直接被掐断了，连个错误提示都没有。

还有一个更隐蔽的问题藏在启动日志里：Ollama 开了 context shifting 功能，意思是一旦不够了就滑动窗口，丢掉旧 token 给新的腾地方。但这个模型架构不支持这功能，所以被静默禁用了。原本应该是软限制，结果变成了硬墙。

本地跑模型，你得懂运维

这次经历让我想明白一件事。本地跑 AI 开发工具，热情归热情，但有个关键问题容易被忽略——

你不是在单纯写代码，你在运维基础设施。

而基础设施就得有基础设施的样子：诊断思维、配置管理、对运行时参数的敏感度，一样都不能少。

上下文窗口不是那种"设一下就拉倒"的抽象参数。它是实打实的运行参数，会和你的工具链产生各种意想不到的交互。当 agent 配置的上下文和服务器实际能力对不上的时候，你不会收到警告，只会得到静默失败——看着像模型不够聪明，实际上是配置出了岔子。

给想尝试本地 AI 编程的朋友几个实在的建议：

• 配置要校验。agent 说什么、服务器实际给什么，必须对得上。
• 看日志。不只是盯着 agent 的输出，服务端日志才是宝藏。
• 搞清楚模型实际支持什么。别看工具想给你什么，看模型能接住什么。

游戏最后还是跑起来了

Tetris 勉强跑起来了。耗时四个半小时，分了两天，代码干净，分了三个文件，功能正常。

但真正有用的教训不是"成功了"，而是搞清楚"为什么会失败"。

有时候最贵的问题，跟智能一点关系都没有。