OpenCode 使用技巧：开源 AI 编程代理怎么用更顺手

OpenCode 的吸引力很直接：

1	开源、多模型、跑在终端里，还能接不同 LLM Provider。

它不像某些封闭工具那样只绑定一个模型。

你可以接 Claude、GPT、Gemini，也可以接其他 provider，甚至围绕自己的环境做更细的配置。

这让 OpenCode 特别适合两类人：

想掌控工具链的开发者
想在不同模型之间切换成本和效果的人

但 OpenCode 也不是装上就自动变强。

要用得顺，关键是把它当成一个可配置的本地编程代理，而不是一个普通问答窗口。

一、安装之后，先初始化项目

OpenCode 官方推荐的安装方式很简单：

1	curl -fsSL https://opencode.ai/install \| bash

也可以用 npm：

1	npm install -g opencode-ai

安装完成后，进入项目目录：

1 2	cd /path/to/project opencode

第一次进入项目，我建议先运行：

/init

这个动作会让 OpenCode 分析项目，并生成 AGENTS.md。

这一步很重要。

因为 AI 编程代理最怕对项目一无所知。AGENTS.md 就像项目说明书，它能告诉 OpenCode 目录结构、代码习惯、常用命令和注意事项。

如果你希望 OpenCode 在团队里长期使用，应该把 AGENTS.md 提交到 Git。

二、把 AGENTS.md 写成“操作手册”，不要写成散文

AGENTS.md 不需要很长。

它应该像给新同事的项目速览：

项目是什么
主要目录在哪里
如何启动
如何构建
如何测试
文章/组件/API 分别放在哪里
哪些文件不要改
提交前要检查什么

比如一个 Hexo 博客项目，可以写：

This is a Hexo blog.
Posts live in source/_posts.
Each post must include front matter.
Use pnpm build to generate the site.
Do not edit generated public/ files.

这比写一大段“请保持代码优雅”更有效。

AI 不怕规则，怕的是规则模糊。

三、用 Plan 模式处理复杂任务

OpenCode 有 Plan / Build 的工作方式。

复杂任务先切到 Plan 模式，让它只分析和制定方案，不要直接改文件。

你可以这样说：

请先分析这个需求，不要修改文件。

目标：
给文章页增加上一篇/下一篇导航。

请输出：
1. 需要改哪些文件
2. 数据从哪里拿
3. 页面结构怎么变
4. 构建验证命令是什么

等计划合理，再切回 Build 模式执行。

这个习惯非常适合这些场景：

跨多个文件的功能
不熟悉的老项目
数据结构不确定
前端页面大改
后端接口和数据库一起改

直接 Build 当然更快。

但复杂任务里，先 Plan 往往更省时间。

四、提示词要像给初级开发分配任务

OpenCode 文档里有一个说法我很赞同：给它足够上下文，就像你在和团队里的初级开发沟通。

也就是说，不要只说结果，要说背景、约束和参考。

比如不要写：

加一个删除功能。

更好的写法是：

请给 note 增加软删除功能：
1. 删除时不要物理删除记录
2. 在数据库里新增 deletedAt 字段
3. 列表默认不显示已删除记录
4. 新增最近删除页面
5. 最近删除页面支持恢复和永久删除
6. 参考 @packages/functions/src/notes.ts 的现有风格

OpenCode 支持用 @ 搜索和引用文件。

这点很好用。

当你知道参考实现在哪里时，直接把文件喂给它，比让它全仓库乱找更稳。

五、用多模型思路，而不是迷信一个模型

OpenCode 的一个特点是可以接很多模型和 provider。

这意味着你可以按任务类型选择模型，而不是所有事情都用同一个。

我一般会这样分：

复杂重构：用推理能力更强的模型
大量文档：用长文本和表达能力强的模型
小修小补：用速度快、成本低的模型
前端设计：用更擅长视觉和结构表达的模型
代码审查：换一个不同模型做第二意见

这不是玄学。

不同模型确实有不同手感。

OpenCode 的价值就在于，你不必把整个工作流押在一个 provider 上。

六、不要忽略 LSP 和编辑器体验

OpenCode 的定位不是只会聊天的终端工具。

它强调能在终端、IDE、桌面环境里工作，并且支持 LSP 相关能力。

这对代码修改很关键。

因为真实项目里，很多判断不只来自文本：

类型是否匹配
函数是否存在
引用是否正确
import 是否可解析
重命名是否影响其他文件

如果你的项目本身就有良好的 TypeScript、Rust、Go、Python 工具链，OpenCode 会更容易借助这些信号完成任务。

所以不要只配置模型。

也要把项目自己的开发工具链整理好。

七、用 /undo 给试错留后路

OpenCode 支持撤销变更。

如果它改偏了，可以使用：

/undo

这比你手动一个文件一个文件回滚轻松很多。

但我仍然建议搭配 Git 使用：

1 2	git status git diff

在让 OpenCode 做大改之前，最好保证当前工作区是干净的，或者至少知道已有改动是什么。

/undo 解决的是会话内的撤销。

Git 解决的是项目级别的安全网。

两者一起用，心里会踏实很多。

八、分享会话适合团队排查问题

OpenCode 支持分享会话。

这在团队协作里很实用。

比如你让 OpenCode 分析了一个复杂 bug，它找到了调用链、关键文件和可能原因。你可以把会话分享给同事，让对方看到完整推理过程。

这比只发一句：

可能是缓存问题。

要有用得多。

分享会话尤其适合：

复杂 bug 排查
架构方案讨论
代码迁移记录
新人学习项目
PR 前解释改动背景

注意一点：分享之前确认里面没有密钥、内部地址、客户数据和敏感日志。

九、一个 OpenCode 常用提示模板

我会这样写：

请先阅读相关文件并给出计划，不要立即修改。

目标：
xxx

上下文：
参考 @path/to/example.ts 的实现方式。

约束：
1. 保持现有代码风格
2. 不引入新依赖
3. 不修改无关模块
4. 完成后运行 pnpm build

输出：
1. 修改计划
2. 风险点
3. 验证方式

如果计划没问题，再说：

按这个计划执行。

这个模板适合大多数项目。

它不会让 OpenCode 一上来就猛冲，也不会把任务说得太虚。

十、结语

OpenCode 的优势不是“又多了一个 AI 编程工具”。

它真正有价值的地方在于：

1	开源、可配置、多模型、本地工作流友好。

如果你喜欢掌控自己的开发环境，OpenCode 很值得试。

但要用好它，仍然离不开基本功：

写清楚需求，初始化项目规则，先计划再执行，给验证命令，用 Git 兜底，按任务选择模型。

工具越开放，越考验使用者的工作流设计能力。

当你把这些基础打好，OpenCode 就不只是一个终端里的 AI 聊天窗口，而是一个可以融进日常开发节奏的开源编程代理。