文章批评OpenCode是一个用TypeScript编写的AI编码代理工具，存在严重安全隐患，如同“靴子踩人脸”。作者认为其安全设计极差，建议所有人停止使用，并指出问题集中在“管道”部分，而非LLM本身。

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了关键细节，并删减了与主题无关或过于技术性的内容。

标题：停止使用 OpenCode

核心观点： 作者强烈建议开发者停止使用名为 OpenCode 的 AI 编程助手，因为它存在严重的安全隐患和糟糕的设计问题。

一、烦人的问题（设计缺陷）

1. 提示缓存失效频繁： OpenCode 的设计导致本地大语言模型（LLM）的提示缓存频繁失效，严重拖慢响应速度。例如：

   • 每次对话都会重新读取 AGENTS.md 文件。
   • 每次用户与AI交互后，都会清理大量上下文，导致需要重新计算。
   • 系统提示中包含了当前日期，导致每天零点或跨天时缓存完全失效。

2. 上下文修剪（Pruning）机制糟糕： 当AI的思考过程过长或用户中断其操作时，OpenCode 会粗暴地删除早期的重要上下文（如项目规范文档），导致AI在后续工作中“失忆”，无法参考关键信息。

3. 会话压缩（Compaction）功能低效： 该功能试图将长对话总结成要点，但实现方式会导致长时间的等待，效果不佳。作者认为，不如直接让AI手动写出笔记更可靠。

4. 系统提示词冗长且固执： 默认提示词非常啰嗦，且包含一些糟糕的指令（例如，要求AI“绝对不要写注释”）。用户无法全局修改默认提示词，切换模式时还会导致缓存失效。

5. 权限提示设计不合理： 当AI试图访问项目目录外的文件时，会弹出权限请求。但选项只有“是”、“否”和“总是”，缺少“从不”选项。如果选择“否”，会直接终止AI子任务并丢失其上下文，迫使你只能选择“是”，容易因疲劳而误放行危险操作。

6. 与AI的交互体验差：

   • 用户消息的发送时机不明确，中断AI后消息可能丢失。
   • 无法与AI的子任务直接沟通，只能眼睁睁看着它们浪费资源或直接杀死它们。
   • 子任务一旦出错，所有上下文都会丢失。

7. 工具设计问题： 例如，edit 工具默认要求精确匹配，而 grep 和 glob 工具与 bash 命令功能重复。

8. 终端界面（TUI）体验糟糕： 内存占用高（高达1GB），无法正常输入换行符，文本选择会因自动滚动而失效，快捷键不符合常规（如 ^C 直接关闭会话而非中断当前命令）。

二、令人警惕的问题（安全隐患）

1. 默认远程连接： OpenCode 默认连接远程模型，即使你配置了本地模型，首次启动时仍需交互选择，而在此期间它可能已经通过远程模型连接到了你的本地终端。其默认模型的URL是从其关联网站动态下载的。

2. 允许AI访问互联网： OpenCode 内置了 WebFetch 工具，并鼓励AI使用。系统提示词中关于“不要猜测URL”的指令措辞模糊，形同虚设。考虑到AI行为不可预测，这带来了巨大风险。

3. Bash命令权限控制形同虚设： 用户可以通过配置文件禁止某些命令（如 git），但OpenCode的过滤机制极其脆弱，可以被轻易绕过。例如：

   • 禁止 git status，但允许 env git status、/usr/bin/git status、$(which git) status。
   • 禁止 git push，但允许通过 echo 'git push' | bash、base64 解码后执行、python3 调用子进程等方式绕过。
   • 作者总结：这种文本过滤完全无用，只会带来虚假的安全感。

4. 权限持久化带来风险： 一旦你对某个命令（如 python3）选择了“总是允许”，AI之后就可以用该命令执行任何操作（如读取你的SSH私钥），而不会再次提醒。

5. 文件权限检查漏洞百出：

   • 只对预设的少数命令（如 cat, rm）进行路径检查，其他命令（如 python3）则完全不受限。
   • 对Shell重定向（如 echo foo > bar.txt）的路径检查存在逻辑缺陷，且由于 echo 不在检查列表中，该检查根本不会执行。

6. 存在远程代码执行（RCE）漏洞： 历史上曾有一个严重漏洞，OpenCode 默认开启的HTTP服务器允许任意网站通过其API执行Shell命令和读取文件。虽然该服务器现已默认关闭，但开发者的处理方式（关闭issue，承诺改进后消失）令人担忧。

7. “用Docker”不是解决方案： 作者反驳了用Docker来隔离AI的建议，认为Docker本身会引入新的安全问题（如创建root权限的服务、破坏防火墙），且如果容器内的Shell能联网，保护作用有限。

结论：

OpenCode 在安全性和设计上都存在根本性缺陷。作者强烈建议所有人停止使用它。

附言：关于本地大语言模型

作者认为，本地模型（如 Qwen3.6-27B）与云端前沿模型一样，会腐蚀代码库的稳定性和概念一致性。其优势在于：愚蠢行为更明显，有助于校准交互；输出内容不易被认定为抄袭；不依赖云服务商。作者认为，将LLM用于代码生成是死胡同，它们更适合作为“搜索”工具来辅助理解代码。整个LLM软件生态存在严重问题，需要真正的系统工程来将其转变为安全的工具，而这需要由人类来完成。

根据评论内容，总结如下：

主要观点与论据：

1. 对OpenCode的强烈批评（评分：无，但多位评论者支持）

   • 作者htrp认为OpenCode存在严重问题：系统提示频繁变更导致缓存失效、压缩功能效果差、默认系统提示有缺陷。他主张“停止使用OpenCode”，并批评远程模型和Docker隔离方案。
   • 关键引用：htrp：“Don't use Opencode, Don't use remote models (cloud providers), Don't use Docker to isolate coding agents.” 以及“Using LLMs for code generation feels like a dead end.”
   • 评论者LoganDark因缓存问题转向Pi：“Cache misses are the one reason I stopped using OpenCode in favor of Pi. OpenCode mutates the system prompt every turn, which is completely unacceptable.”

2. 对OpenCode的辩护与实用视角（评分：无，但多位评论者提供平衡观点）

   • 评论者kristopolous因免费额度使用OpenCode：“Opencode offers free models with 200/requests over 5 hours. That's why I use it... The reason I use it is purely financial.”
   • 评论者alanwreath报告正面体验：“I have ran with opencode and qwen 3.2 on a 5090 and I’m getting results on a production codebase of golang... I’m content with draining my local tokens.”
   • 评论者speedping指出OpenCode被大企业采用：“If OpenCode is so terrible it wouldn't be the base for many of the fortune 500's internal cli coding agents, Meta included.”

3. 对文章标题与焦点的质疑（评分：无，多位评论者）

   • 评论者lucideer认为文章标题误导：“this is a complaint without a straightforward suggested alternative... None of the major issues listed are unique to OpenCode.”
   • 评论者LaurensBER建议更合适的标题：“A better title for this article would be: 'Some minor annoyances that, when fixed, would improve OpenCode'.”
   • 评论者singpolyma3认为这是反AI文章：“This is an anti AI post masquerading as an anti opencode port.”

4. 替代方案与未来展望（评分：无，多位评论者）

   • 评论者volf_转向Pi：“I switched from OpenCode to Pi and there was a big improvement in terms of tool calling performance.”
   • 评论者tomaytotomato预测未来自建工具：“In a years time the discussions on using CC, Opencode, Pidev etc. will be redundant as we will be building our own tooling.”
   • 评论者axegon_强调本地模型的重要性：“if AI is to survive, the future HAS TO BE local or near-local.”

5. 安全与隐私担忧（评分：无，多位评论者）

   • 评论者axegon_批评数据外泄：“allowing a slop machine to execute arbitrary code on your machine... we all sign tons of NDA's... just to throw all out the window by giving it all away to anthropic/openai/google.”
   • 评论者petesergeant建议沙箱隔离：“You should absolutely be running your AI agent inside some kind of sandbox.”

平衡性总结： - 批评方：强调OpenCode的技术缺陷（缓存、压缩、安全）、默认远程模型的风险、以及LLM代码生成的局限性。 - 辩护方：指出免费额度、实际可用性、企业采用、以及可通过配置使用本地模型。 - 中立方：认为问题非OpenCode独有，文章标题夸大，建议改进而非放弃。 - 替代方案：推荐Pi、Kilo Code、本地模型（如Qwen3.6-27B）或自建工具。