经验

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 条是"日常真正省时间"的核心姿势，全部按顺序展开，每一条都尽量具体到"打开哪个文件、敲哪条命令、看哪个输出"。我会刻意把"我踩过的坑"嵌在技巧后面写，而不是单独列一节，这样读起来不会割裂。 ...