开发者社区针对本地 LLM 编码场景的实际表现展开讨论，焦点集中在工具调用能力、prompt 缓存命中率与 OS/Docker 环境下的可用性。多数反馈认为，Qwen 27B、Gemma 4 31B 等本地 LLM 在长会话编码任务中仍难替代云端 Claude Code 与 Kimi。
本地 LLM 编码核心短板：Token 累积与缓存失效
用户在 Reddit 本地 LLM 编码体验讨论帖中指出，执行 Docker 化 GitHub 仓库等任务时，本地模型会读入 docker build 的全量输出，会话 token 累积至250K后发生崩溃，prompt 缓存频繁失效导致长时间停顿。该用户对比云模型结论是：本地 LLM 在自动化与文本任务上仍有价值，但在编码场景生产力损失高于切换云端模型成本。评论区多数反馈支持类似观点，认为对本地编码能力的期待不切实际。
RTX 5090 + Qwen3.6 + TurboQuant 配置经验
部分开发者分享了RTX 5090 + Qwen3.6 35B/27B + TurboQuant 量化的本地配置，采用–temperature 0.6、–top-p 0.95参数，配合 OpenCode TUI 与 oh-my-opencode harness。该配置自述在编码场景表现优于 Anti-Gravity 与 Codex。Unsloth 团队发布的Claude Code 配置优化指南则针对推理加速与缓存命中率低问题提供参数建议，可作为参考起点。
Harness 选型对本地编码体验的影响
讨论中反复出现的核心观点是：相同模型在不同 harness 下表现差异显著。Hermes 等 harness 在长时运行进程处理上各有取舍，社区共识倾向于在具体任务上分别测试 harness，而非锁定单一框架。Harness 设计被视为本地编码智能体后续优化的关键方向。
本地 LLM 编码体验争议反映出当前开源模型在工具调用与长会话稳定性上的系统性短板。短期内，云端 Claude Code 与 Kimi 仍将主导认真编码场景；本地模型则在隐私敏感、离线开发与小规模辅助任务中保持价值。