OpenCode

20260903 OpenCode 和 KiloCode 的主要区别是什么？为什么我会选择 KiloCode？ 最近 OpenCode 和 KiloCode 经常被放在一起讨论：一个让我在终端里专注完成任务，一个把多个 Agent、隔离工作区和代码审查组织进 IDE。很多朋友真正想问的其实不是“谁更强”，而是“我现在的工作方式，应该把哪一个放在手边”。这篇文章记录我最近一次切换工具的原因，也把我认为最影响选择的差异讲清楚。蓝色高亮表示工具事实，绿色高亮表示我的判断，红色高亮表示容易踩的坑，黄色高亮表示可以直接尝试的做法。文中的产品信息按 2026 年 9 月 3 日查阅到的官方文档整理，后续可能随版本变化。 先说我的结论：如果你主要在终端里工作，喜欢自己控制会话、目录和模型，OpenCode 依然是一把很顺手的工具；如果你经常同时推进多个任务，希望在 VS Code 或 JetBrains 里集中看状态、diff 和工作区，KiloCode 更贴合我的习惯。更准确地说，Kilo CLI 是 OpenCode 的 fork；Kilo 的 IDE 插件和 Agent Manager 则是 Kilo 另行组织的产品层。所以它们不是两个完全无关的竞品，也不是同一个产品换了两个皮肤。 我为什么又换了一次？上一篇文章里，我写过自己怎样把 OpenCode 接进日常开发，那些经验现在仍然有效：终端里可以跑命令，配合 LSP（语言服务协议）理解代码，也可以通过 MCP（模型上下文协议）接入外部工具，项目规则则写进 AGENTS.md。后来我的任务从“一个人在终端里重构 Go 服务”，变成了同时推进重构、补测试、写文档、审 PR 和修 bug，还要在 VS Code 与 JetBrains 之间来回切换。OpenCode 的多 session 能力并不弱，只是我需要自己安排目录、创建 git worktree（并行分支工作区），再盯住每个会话的进度。KiloCode 的 Agent Manager 把这部分协调工作做成了看板：每个 Agent 可以在独立 worktree 里运行，我只需要负责拆任务和合并结果。 ...

OpenCode，别急着上手，分享我的自用经验 最近一段时间 OpenCode 的话题度很高，公众号和推上每隔几天就有人晒"一天配置、终身起飞"。我也凑过几次热闹，但说实话，真正把它当成日常开发工具并接入 AI 用，是在吃了几次亏、调过几次规则之后才稳定下来的。这一篇不是官方文档的搬运，也不是"hello world 教程"，我会先讲我为什么把 OpenCode 作为日常开发工具并接入 AI 用，列 8 条最容易踩的注意事项——尤其是"装上第一天别急着写规则"。如果你正在评估 OpenCode、或者已经装上却不知道从哪一步开始，这篇可能比"快速上手"那一份更值得花十分钟读完。蓝色高亮表示工具或事实，绿色高亮表示我的使用判断，红色高亮表示容易踩的坑，黄色高亮表示可以直接抄走的最小可用集。、 先把"为什么用"想清楚：换模型不被绑架、过程可观察、本地运行——这三条都满足了，再谈下一步。 从最小可用集开始：一份简短 AGENTS.md + 一个稳定 Provider + 一个默认 build 角色 + 启用的 LSP。够用就好。 复杂任务先 plan 再 build：跨文件的改动，先看 diff 再下手，能避免一整轮返工。 规则要可验证、规则要文件化：机器能判的才叫规则，读不懂的只是愿望。 审查用只读 agent：把"看"和"改"分开，是让 AI 报告客观的前提。 接入 MCP 时按"只读 → 受限可写 → 状态变更"分步放权：每一步都先想清楚"最危险的事是什么"。 不要让关键检查静默失败：可见、可追溯、有人负责，三条缺一不可。 把 AI 当草稿作者，把自己当责任编辑：最终交付的责任，不能下放给工具。 一、把 OpenCode 放进工作流之前，我给自己提过三个问题：它能不能让我换模型不被绑架？它能不能把每一步操作摊在我眼前？它能不能在我自己的机器上跑，而不是把代码交给一个远端托管？ OpenCode 在这三个问题上都给出了让我愿意留下来的答案，这也是我后来把它接入 AI 用作日常开发工具的真正原因。我把这三个答案按顺序写下来，因为它们不只是在"功能上"成立，更是OpenCode 与同类工具最明显的差异点： 开源、可审计、不绑定单一供应商：OpenCode 的客户端代码是公开的，关键行为可以在源码里核对；Provider（也就是模型供应商）走的是开放协议，我可以在同一个配置里同时挂上 OpenAI、Anthropic、本地 Ollama、自建代理，换模型不需要重写工作流，更不需要换一份订阅。对我来说这意味着两件事：第一，今天贵/限流的模型，明天可以被另一个模型接住；第二，今天数据合规的顾虑，明天可以通过本地模型或者自建网关绕过。这条不是装饰，它直接决定了我愿不愿意把生产代码交给它。 把"工具调用 + 文件编辑 + 命令执行"收进一个 TUI：比起网页聊天窗口，OpenCode 的好处是上下文连续。一次会话里，它可以直接读写我的文件、跑我的命令、调用我的 LSP，并把每一步的结果作为下一步输入。传统聊天窗口要靠我在不同窗口之间复制粘贴，OpenCode 把这些步骤变成了同一个会话里的多轮工具调用。对我而言这比"模型写得多聪明"更重要：我能在同一个界面里看见它读了什么、改了什么、跑过哪些命令、回滚时还能回到哪一步。信任不是靠宣传词建立的，是靠"可观察"建立的。 配置即文档，规则可以在 review 里被讨论：OpenCode 的绝大部分约定都放在纯文本文件里：项目根的 AGENTS.md 写规则，commands/*.md 写命令模板，agents/*.md 写角色，skills/*.md 写沉淀下来的做事方法。最常见的错误是把 AGENTS.md 当成无所不包的"价值观大全"，其实它的价值恰恰相反——把"我想要的工作方式"显式写下来，让工具按文件读，而不是每次新会话都让我重新解释一遍。规则在哪一步生效、谁负责什么，可以被同事直接读到，也可以在 review 里被讨论。这就是我把 OpenCode 当成"开发工具并接入 AI 用"的核心原因——AI 第一次成为工作流的一部分，而不是一个聊天侧栏。 二、装上 OpenCode 之后，先别急着让它"做项目"。我会先定一个最小可用集，把"模型 + 规则 + 角色 + 编辑器反馈"四件事按顺序配齐，再开始干正事。顺序不能乱，因为规则没写好之前，模型越强越容易跑偏。下面这 8 条技巧，前 4 条是"装好就能用"的最小集，后 4 条是"日常真正省时间"的核心姿势，全部按顺序展开，每一条都尽量具体到"打开哪个文件、敲哪条命令、看哪个输出"。我会刻意把"我踩过的坑"嵌在技巧后面写，而不是单独列一节，这样读起来不会割裂。 ...

AI 写的代码，为什么总像“差不多对”？我用 opencode 把 commit 前审查做成三道门 我用opencode做代码审查，注重agents.md的质量，聚焦多轮核心BUG输出质量，减少MR被驳回的风险 审查阶段不要使用可写 agent。 可写 agent 看到问题后很容易顺手修复，修复后的代码又变成新的审查对象。我要的是报告，不是未经确认的工作树变化。 AGENTS.md 不是越长越好。 我见过把抽象价值观、编码风格和所有历史事故都塞进去的规则文件，最后 AI 什么都读到了一点，却没有一条真正执行到位。规则应当短、具体、可验证。 不要只统计 AI 提了多少条意见。 我更看重高价值意见的比例、误报率、漏报案例和处理耗时。意见越多不等于审查越好。 我最近在 Go 项目里遇到过一个很典型的例子：我让 AI 把一个用 sync.Mutex 保护的缓存改成 sync.RWMutex，因为读请求远多于写请求。代码能编译，go test -race 也通过了，我正准备提交时又看了一遍 diff，才发现 AI 在 RLock() 之后没有为所有提前返回的分支补上 RUnlock()。原代码用 defer Unlock() 做了一次兜底，锁的种类变了，兜底结构却没有一起变。 这个问题不是函数体“完全写错”，而是局部正确、整体破坏。测试没有触发那个错误分支，竞态检测自然也抓不到。类似的情况我见过很多：错误被 _ 接住、context 半路丢失、goroutine 没有退出条件、异常路径没有补齐、依赖被悄悄换成团队没人维护的库。AI 生成代码的速度越快，diff 的影响半径就越容易被低估。 我现在把 commit 前的审查拆成三道门：机器门负责确定性检查，AI 自审负责挑出候选风险，人工 review 负责业务判断和最终签字。这篇文章记录我在 Go 项目里实践这套流程的方式，也会说明 opencode 适合放在哪一层、哪些事情仍然不能交给它。 蓝色 表示工具或事实，绿色 表示我的实践判断，红色 表示容易踩的坑，黄色 表示可以直接改写到自己项目里的模板。 一、先把 commit 当成一次小型发布 以前我把 git commit 当作保存进度，后来几次线上问题让我改了看法：commit 是把一组行为变化交给团队和环境的发布动作。即使还没有上线，它也已经影响了后续 review、合并、回滚和事故追踪。 ...

我的编程套餐尝试：对大多数个人开发者，OpenCode Go 套餐值得试 尤其是像我这种经常折腾 Docker、后端服务、AI 工具、UI 页面、脚本排错的人，$5 首月 / $10 每月的价格很有性价比。 OpenCode 官方说明：Go 是低成本订阅，首月 $5，之后 $10/月，可用于 OpenCode 或其他 agent，并支持充值兜底；它包含 GLM、Kimi、Qwen、DeepSeek、MiniMax、MiMo 等开放模型。(开源代码) 为什么值得 1. 价格低，但额度不算小 官方文档写得比较清楚：Go 套餐不是简单按"请求次数"限制，而是按等价用量限制： 限制周期 用量额度 5 小时 $12 usage 每周 $30 usage 每月 $60 usage 实际请求次数取决于你选的模型。比如官方估算，DeepSeek V4 Flash 每月可到 158,150 次请求，Qwen3.7 Plus 每月约 21,600 次，GLM-5.2 每月约 4,300 次。(开源代码) 这对日常 coding、改 bug、解释报错、生成脚本、写 Dockerfile、分析日志，已经非常够用。 2. 很适合作为"日常编码副驾驶" Go 套餐的定位不是替代最强闭源模型，而是提供稳定、便宜、可大量使用的开放 coding 模型。官方也说它主要解决的是开放模型访问不稳定、不同 provider 质量不一致的问题，OpenCode 会筛选和 benchmark 适合 coding agent 的模型组合。(开源代码) ...