企业官网建设流程全解析

1. 先把 opencode 放进 AI 编码工具的坐标里

最近半年，经常有朋友问我：你现在写代码用的哪个 AI 工具？我说主力是 opencode，十个人里有八个会反问一句：opencode 是什么？这很正常，大家最熟悉的还是 GitHub Copilot、Cursor 这类带界面的工具，或者最近讨论度很高的 Codex、Claude Code。opencode 走的是另一条路线：它是一个命令行里的 AI 编程代理，本身不自带模型，却能把各种模型、技能、LSP、Playwright 这些能力像积木一样拼在一起用。这个定位让它在"哪家大厂出品"这个问题上显得很特殊——它不属于任何单一模型厂商，更像是一个社区驱动的开源基础设施，所以才有那么多人在搜索"opencode是哪家公司的"。

我第一次接触 opencode 是在一个中型全栈项目上。项目里同时涉及 TypeScript 前端、Python 后端、还有一堆历史遗留的脚本。GitHub Copilot 能帮我补全代码，但遇到"这个接口为什么报错""这个老模块到底被谁引用了"这种跨文件、跨语言的问题，它就比较吃力。Codex 和 Claude Code 我也试过，很强，但它们跟各自的模型生态绑得比较深，我想换模型、想接入自己的检查脚本时，总感觉被框架限制住了。opencode 给我的第一印象是"可组合性"——它不试图替你做所有事，而是把读取代码、执行命令、调用工具这些能力开放给你，让你按项目需要自由装配。

如果你之前没接触过这类工具，可以把它理解成一个"会使用电脑的程序员助手"：它能读文件、能跑命令、能看错误日志，也能调用语言服务器和浏览器自动化工具。你可以让它"帮我修一下这个 bug""给这个函数补测试""看看为什么 CI 挂了"，它会自己规划步骤、执行操作、把结果反馈回来。它和 ChatGPT 那种"你贴代码我改代码"的交互方式有本质区别：opencode 直接长在你的项目里，有真实的文件系统访问权限，也有执行命令的能力。

这篇文章不是官方文档的翻译，而是我从零开始把 opencode 装进工作流后的一些实操记录，包括安装时踩过的坑、配置模型时的选择逻辑、让 Agent 看懂老项目的办法，以及几个高频报错的排查链路。不管你是第一次听说它，还是已经装上但还没跑通，应该都能从里面找到点有用的东西。

2. 安装落地：从命令行到编辑器插件的完整部署

opencode 的安装本身并不复杂，但"装到一半感觉没装上"的人特别多。我先说结论：不管用哪种方式安装，装完第一件事一定是打开一个新终端，执行opencode --version，能输出版本号才算真正落地。这一步能过滤掉后面一半的问题。

2.1 多平台安装方式与版本选择

官方推荐的方式是直接用安装脚本或者包管理器。以我实际用过的几种环境为例：

• macOS 上我用 Homebrew 安装，一条命令搞定，后续升级也方便。
• Linux 上我习惯从 Release 页面下载预编译二进制，放到/usr/local/bin下；当然用官方安装脚本也可以，原理都是一样的，下载二进制并添加到 PATH。
• Windows 上可以用 Scoop 或 winget 这类包管理器，也可以直接下载 exe 文件手动安装。

这里有一个容易忽略的点：如果你以前用 npm 全局安装过其他 CLI 工具，那npm i -g opencode也是一种可选方式，但 npm 全局目录有没有进 PATH，在不同系统上表现差异很大，后面会细说。我更推荐优先用系统包管理器或官方二进制，原因只有一个——少一层依赖，少一个坑。

版本选择上我的建议是：不要追最新版，但也别用太老的版本。opencode 迭代速度很快，配置格式和命令参数有调整，搜索结果里经常看到"2.0 之后配置方式变了"这类讨论。遇到旧教程里的配置不生效，先看一眼官方仓库的 Release Notes，确认自己用的版本对应的配置写法是什么。

2.2 Windows 报错"无法将 opencode 项识别为 cmdlet、函数、脚本文件或可运行程序的名"的修复思路

这个报错在 Windows 用户里出现频率极高，我身边至少有三个人栽在这里。先别急着怪工具，这个报错的意思是：PowerShell 在当前的所有 PATH 目录里都找不到opencode这个可执行文件。就这么简单，无外乎三种情况：没装成功、装到了 PATH 之外、PATH 更新后终端没重开。

我建议按这个顺序排查：

1. 输入Get-Command opencode，如果没有任何返回，说明确实不在 PATH 里。
2. 检查安装目录。如果是通过安装脚本装的，默认可能在%USERPROFILE%\.opencode\bin或者%LOCALAPPDATA%\Programs\opencode；如果是 npm 装的，先执行npm config get prefix，把返回的目录记下来。
3. 手动把该目录加入系统 PATH。可以打开"系统属性 > 环境变量"，在 Path 变量里新增一行；也可以用setx PATH "$env:PATH;C:\具体目录"这种命令。注意setx有长度限制，路径特别长的时候建议还是在界面里操作。
4. 关掉当前终端，重新开一个 PowerShell，再执行opencode --version验证。

这个报错还有个变体：你明明已经装了，目录也加进 PATH 了，但Get-Command opencode仍然找不到。这时候大概率是 PATH 更新没有被当前会话加载。PowerShell 不会自动感知系统 PATH 变更，新开的终端窗口才会读取。如果新窗口还不行，检查一下是不是同时存在用户级 PATH 和系统级 PATH，你的安装目录加错层级了。

还有一个很隐蔽的问题：有些安装脚本在 Windows 上需要管理员权限才能把二进制复制到受保护目录。如果安装过程中看到 UAC 弹窗就直接取消了，那安装结果可能是不完整的。这时候重新以管理员身份运行一次安装脚本就好。

2.3 IDE 插件：VSCode 和 JetBrains IDEA 里的接入体验

命令行用顺手之后，你大概率还是想在 IDE 里用，毕竟看代码、看 diff 还是在编辑器里方便。opencode 有对应的 VSCode 插件和 JetBrains IDEA 插件，整体思路是一样的：插件负责提供交互界面，真正干活的核心还是终端里的那个 CLI。

VSCode 插件装好之后，第一件事是在设置里确认 opencode 可执行文件的路径要不要手动指定。一般情况下插件会自动识别 PATH 里的opencode，但如果出现"插件启动了但没有任何反应"，多半是 IDE 的 PATH 环境和终端不一致。macOS 上经常有这个问题，从 Dock 启动的 IDE 不会加载 shell 的配置文件，导致找不到命令。解决办法是在 IDE 的配置文件里手动写死 opencode 的绝对路径。

JetBrains IDEA 插件的体验类似，但它和 VSCode 有个区别：IDEA 的虚拟终端和系统终端 PATH 是基本一致的，所以问题会少一些。不过 IDEA 插件在处理大段代码 diff 时的流畅度和 VSCode 相比还差一点，我个人的习惯是：日常小改动直接在插件里操作，遇到需要跑测试、批量改文件的大任务，切到终端里跑 CLI，两种方式各干各的活。

3. 核心配置与模型接入：跑通第一个真实任务

装好只是开始，真正让 opencode 发挥威力的是配置。很多人拿到手就跑opencode，然后发现它问你登录或者填 API Key，这时候才反应过来：原来它自己不生产模型，只是模型的搬运工。

3.1 配置文件位置与修改原则

opencode 的配置分两层：用户级配置和项目级配置。用户级配置的位置在不同系统上不一样，Linux 常见路径是~/.config/opencode/opencode.json，macOS 是~/Library/Application Support/opencode/opencode.json，Windows 则在%APPDATA%\opencode\下。项目级配置一般放在项目根目录的opencode.json或者.opencode/目录里，后者还会存放 skills 这类项目专属文件。

这个设计逻辑跟 Git 很像：用户级配置保存你的个人习惯和默认模型，项目级配置跟着仓库走，团队共享。我建议把 API Key 这类敏感信息放在环境变量里，而不是写进配置文件。配置文件里只写模型名称和调用参数，这样就算整个文件不小心被公开，泄露的也只是配置而不是密钥。

修改 JSON 配置时有一个教训：不要用 Windows 记事本直接编辑，因为保存出来的文件可能是带 BOM 的 UTF-8，某些解析器会因此报错。还有一次我把一个中文字符写成了中文引号，结果整个配置无法解析，排查了很久才发现是标点符号的问题。现在我的习惯是改完配置后用opencode doctor或者直接跑一条简单命令验证一下，能正常响应就说明格式没问题。

3.2 模型选择：官方模型、免费模型、本地模型怎么配

opencode 支持接入多种模型服务，配置核心就两个信息：模型名称和服务的 API 端点。模型名称通常要写成"提供商/模型名"的格式，比如用 Anthropic 的 Claude 就写anthropic/claude-sonnet，用 OpenAI 就写openai/gpt-4o，用本地 Ollama 就写ollama/llama3.1这类。

很多人喜欢折腾免费模型。我的建议是：免费模型适合拿来跑通流程、验证配置，不适合真正拿来做开发主力。一来免费模型的速率限制通常很低，二来上下文窗口往往比付费版本小，代码任务对上下文长度的需求比想象中大。如果你只是想试试 opencode 好不好用，可以先接一个免费模型跑两天，确认工作流顺手之后再决定要不要上更强的模型。

本地模型是另一个选择。用 Ollama 跑一个 7B 或 13B 的模型，配置到 opencode 里，好处是完全不依赖外部服务，代码隐私性最好。坏处也很明显：代码生成质量和推理速度跟云端大模型差距很大，尤其在处理复杂重构任务时，能明显感觉到"智力不够用"。

网上常说的"go 套餐""go 订阅"这类服务，本质上是把某个模型服务以订阅形式打包，给客户端提供一个兼容端点。配置逻辑跟官方服务一样，无非是 base URL 和 API Key 换一下而已。但我在实际使用中的体会是：选这类服务一定要关注服务方的资质和稳定性，不要只看价格。有些服务商为了控制成本会偷偷降级模型，或者在高负载时大量限流，看起来便宜，实际用起来全是泪。我的做法是长期备两套配置，一套官方直连用于关键任务，另一套作为备用，切换通过环境变量完成，而不是反复改配置文件。

3.3 Skills 机制：让 Agent 学会你团队的规范

Skills 是 opencode 里比较有特色的能力，通俗点说，就是给 Agent 一份"操作手册"。你可以把团队的业务规范、代码风格、常用命令、检查步骤写成一个 skill，Agent 在执行相关任务时会主动读取并遵守。

一个 skill 本质上是项目.opencode/skills/下的一个目录，里面包含一个说明文件和一些可选脚本。比如我给自己写了一个"代码审查"skill，它会提示 Agent 按顺序检查：接口变更有没有同步更新文档、错误处理有没有遗漏、新增依赖有没有加到锁文件里。这样每次让 opencode 做 code review 时，它输出的结果就不是泛泛而谈的"看起来不错"，而是按我的规范逐条检查过的清单。

写 skill 的诀窍是：不要写太多模棱两可的描述。比如"注意代码质量"这种话等于没说，Skill 的指令越具体，Agent 的执行效果越好。我一般会按照"触发时机、执行步骤、输出格式"三段式来写，跟给新人写 onboarding 文档一样。花一个小时写好一个 skill，后面每次调用都是省下来的时间。

3.4 接上 LSP，让 Agent 真正看懂代码

LSP（Language Server Protocol）本来是给编辑器提供代码补全、跳转、诊断用的，opencode 也可以接它，让 Agent 获得更精确的代码语义信息。没接 LSP 的时候，Agent 看代码有点像人用文本编辑器读代码——能看到字面内容，但不知道符号在哪里定义、这个函数有哪些调用方。接了 LSP 之后，它就能像在 IDE 里一样获得符号表、诊断信息和定义跳转，对复杂项目的理解能力会断崖式提升。

配置方式是在 opencode 配置文件的lsp字段里注册对应语言的 server。比如 TypeScript 项目要装typescript-language-server，Python 项目要装pyright或basedpyright：

{ "lsp": { "typescript": { "command": ["typescript-language-server", "--stdio"] } } }

配置好之后，让 opencode 找函数定义或者分析报错时，它会优先通过 LSP 获取信息，而不是把整个文件内容一股脑塞进上下文。这不仅提升了准确性，也大幅减少了 token 消耗。我的实测感受是有 LSP 和没有 LSP，在处理第三方库类型问题时的差距特别明显，前者能直接给出类型签名，后者只能靠猜。

3.5 老项目接手：让 opencode 快速建立全局认知

接手一个陌生项目的时候，最容易犯的错误是一上来就让 Agent 改 bug。它连项目怎么启动、代码怎么组织、有没有特殊的构建流程都不知道，改出来的东西大概率是空中楼阁。我更推荐先让 Agent 做一次全局梳理。

我的操作习惯是这样的：先把项目 README、package.json、Makefile、docker-compose.yml 这些入口文件让 opencode 读一遍，然后让它总结这个项目的架构、启动方式、测试命令。接下来让它跑一次构建或测试，把报错输出交给它分析，这些报错往往能暴露项目和标准流程之间的偏差。最后，再让它基于刚才的理解，用一两百字复述一遍它认为的"项目地图"。

这一步看似多余，实际价值很大。Agent 能不能用，很大程度上取决于它对项目的理解准不准。如果复述出来明显不对，说明你的上下文给得还不够，这时候可以再补充目录结构说明或者架构文档。等它把项目讲明白了，再让它动手改代码，效率和准确率都会高很多。我现在接手任何新项目，都会把"让 opencode 先讲给我听"当作第一步，而不是让它直接开干。

4. 常见报错的排错链路：从终端到模型返回

用 opencode 的过程中，报错是常态，关键在于怎么快速定位问题。这一节我把几个高频报错的排查链路完整写出来，有些是我自己踩过的坑，有些是帮别人排查时总结出来的。

4.1 Linux/macOS 下"command not found"的同类问题

Windows 有 cmdlet 报错，Linux 和 macOS 也有对应的"command not found"，但原因往往不太一样。最常见的情况是：安装时用的 shell 是 zsh，但配置文件写到了.bashrc，导致新终端里找不到命令；或者安装目录没加到 PATH，只对当前会话有效，重启终端就失效。

排查方法很简单，先执行which opencode，如果有返回路径但执行依然失败，检查一下文件是否有执行权限，用ls -l看权限位，没有x就chmod +x一下。如果which完全没有输出，就要确认安装位置，然后把它加到对应 shell 的配置文件里。我自己的习惯是把这类工具的路径统一软链到/usr/local/bin下，一劳永逸，省得每个 shell 配置里都维护一遍 PATH。

还有一种隐蔽情况：系统里同时存在多个版本，which返回的路径和你以为的安装路径不是一个。之前我遇到过opencode --version显示旧版本，但配置文件里全是新需求的情况，查了很久才发现是 PATH 里前面某个目录下有个同名旧二进制。遇到工具行为不正常时，先确认你实际调用的到底是哪个文件。

4.2 unexpected server error 与它的真实含义

在终端里跑 opencode 时，如果看到unexpected server error. check server logs，很多人第一反应是重试，但重试往往没有用。这个报错的信息量其实很低，它只告诉你服务端返回了非预期错误，但没有说具体是什么。真正的排查入口在日志里。

我一般是分四步排查：

1. 用opencode --debug或者设置DEBUG=1重新跑一次，让信条输出更完整的请求日志。
2. 从日志里找到实际请求的端点地址，确认是不是你预期的模型服务。如果配置了代理或自定义 base URL，这里很容易发现请求发错了地方。
3. 用 curl 手动构造一个简单请求发到同一个端点，看能不能拿到正常响应。这一步能帮你区分问题在 opencode 本身还是模型服务端。
4. 检查模型名称。很多"unexpected server error"其实是模型名不对，服务端不知道你要调哪个模型，干脆返回了一个笼统的错误。

还有个容易忽略的点：升级 opencode 之后，旧配置里的某些字段可能已经不被识别，也会触发类似错误。这时候回看一下 Release Notes，通常能找到线索。

4.3 this model is not available in your country 的处理原则

这个报错在新手群里出现的频率越来越高。字面意思是：当前模型在你的区域不可用。它通常是模型服务方根据请求来源区域做的合规限制，而不是你本地配置出了问题。

遇到这个报错，我的原则很简单：不要想着绕，而是换个思维，选一个在当前环境里合法可用的替代方案。市面上有些教程会建议修改请求出口区域，这种做法既不合法也不稳定，而且容易导致 API Key 被封禁，得不偿失。正确做法是先查看你使用的服务商官方文档里支持哪些区域，然后在支持列表范围内选一个能力接近的模型。如果确实需要某个特定模型，可以考虑自部署开源模型，配合 Ollama 或 vLLM 接入 opencode，虽然效果可能有差距，但至少可控、合规、稳定。

从长期来看，"被区域限制卡住"的趋势会越来越多，这是模型服务商在合规压力下的必然选择。与其花时间研究怎么绕过，不如建立一套"多模型可切换"的配置习惯，备选方案能随时顶上，工作流才不会断。

4.4 模型返回慢与超时的调优经验

模型返回慢是最影响使用体验的问题，但很多慢跟"工具"没关系，是上下文太多导致的。你让 Agent 读了一个巨大的文件，或者把整个项目的目录树都塞进去，模型光消化这些内容就要花很久，首字返回自然慢。

我的调优经验有几点：

• 能用 LSP 拿准确信息的，就不要把整个文件丢给模型。
• 能用grep或rg缩小范围的，就不要让 Agent 自己反复读文件。
• 大文件可以先让 Agent 只读关键片段，而不是一次性全文载入。
• 检查是否有历史会话的上下文一直在累积。opencode 的多轮对话里，前面几轮的内容都会保留，如果你开了个很长很长的会话，后面每轮都会越来越慢。该开新会话的时候就开新会话，不要觉得浪费。

网络层面的因素也会有影响，但大多数情况下，先自查上下文规模比排查网络更高效。

5. 用 Playwright 给 Agent 一双眼睛：前端 bug 的复现与修复闭环

opencode 在分析后端问题时很有优势，读日志、查堆栈、追数据流都算它的强项。但前端 bug 是另一回事——很多问题只有在浏览器里真实操作一下才会暴露，比如"点击某个按钮后页面白屏""某个组件在特定分辨率下错位"。这些问题如果只给 Agent 代码，它很难准确复现。Playwright 在这里就是 Agent 的眼睛。

5.1 为什么前端 bug 不能只靠看代码

我见过太多这样的情况：让 opencode 修一个"页面点按钮没反应"的 bug，它从代码里找出一个看起来可疑的事件绑定，改完之后你手动一测，问题还在，甚至可能改出新问题。原因很简单，前端 bug 的根因经常不在你一眼看到的那几行代码里，可能是某个接口返回了意外格式的数据，可能是某个 CSS 类名冲突，也可能是浏览器兼容性问题。这些问题在静态代码里很难发现，必须结合实际运行时的控制台报错和网络请求来定位。

Playwright 能帮我们做一件很关键的事：把"复现 bug"这一步自动化。你只需要写一小段脚本，让浏览器自动打开页面、模拟点击、收集控制台错误和网络请求，这些信息就是 Agent 调试时最需要的证据。与其让模型凭空猜测，不如直接告诉它："我复现了一次，控制台报了这个错，是这行代码导致的。"定位准确率会大幅提升。

5.2 一个最小可复现脚本的编写思路

写 Playwright 脚本不需要很复杂，核心目标是"跑一遍打开页面、触发操作、收集输出"的流程。下面是一个很典型的模板：

import { chromium } from 'playwright'; const browser = await chromium.launch(); const page = await browser.newPage(); const consoleErrors = []; page.on('console', (msg) => { if (msg.type() === 'error') consoleErrors.push(msg.text()); }); page.on('pageerror', (err) => consoleErrors.push(err.message)); await page.goto('http://localhost:5173'); await page.click('button.start'); await page.waitForTimeout(2000); console.log('=== console errors ==='); consoleErrors.forEach((err) => console.log(err)); await browser.screenshot({ path: 'screenshot.png', fullPage: true }); await browser.close();

这段脚本做的事情是：打开本地开发服务器地址，点击一个按钮，等两秒，然后输出所有的控制台错误，同时截一张全屏截图。对于"按钮点击后页面异常"这类问题，这个脚本基本够用了。你可以根据实际情况调整选择器、交互步骤和等待时间，甚至可以加上网络请求监听，把某个接口的返回状态码和响应体也打印出来。

写脚本的时候有几个容易踩的坑：一是 Playwright 的包名容易拼错，好多人写成了playwrig，第二就是等待逻辑不要用固定延迟来代替条件等待，如果页面加载很慢，固定等两秒可能不够。更好的做法是用page.waitForSelector或者page.waitForResponse去等待某个元素或某个接口出现。

5.3 把 Playwright 输出喂给 opencode 的工作流

脚本跑通之后，接下来就是把它和 opencode 串起来。最简单的方式是：手动运行脚本，然后把控制台输出和截图路径告诉 opencode，让它基于这些信息分析问题。再进阶一点，可以把整个流程封装成一个 skill，让 opencode 在遇到前端 bug 时自动执行 Playwright 脚本、读取输出结果，相当于给它配了一个"浏览器操作工具"。

我实际用下来比较顺畅的工作流是这样的：

1. 在.opencode/skills/reproduce-frontend/下建一个 skill，说明文件里写清楚"当用户报告前端页面异常时，先运行node scripts/reproduce.mjs收集控制台错误，再根据错误信息定位代码"。
2. Skill 里附带一个可参数化的 Playwright 脚本，用户提供页面 URL 和要触发的操作就行。
3. Agent 分析脚本输出时，会同时参考控制台错误、截图和项目源码，通常能很快定位到具体是哪个组件、哪一行代码出的问题。

有一次遇到一个白屏问题，排查了很久都没头绪，最后用 Playwright 跑了一遍，发现控制台报的是某个接口返回的字段是 undefined，代码里直接访问了它的属性，导致渲染中断。这个错误在静态代码里其实很难一眼看出来，但结合运行时报错就非常清晰。Agent 拿到这个信息后，很快就给出了修复方案。这个案例让我彻底意识到：给 Agent 配上运行时反馈，效果是几何级数提升的。

6. 不同 Agent 怎么选：我最终留在 opencode 的理由

很多人在搜"codex、claude code、pi 哪个 agent 好用"，说明这个领域已经不是一家独大了。我在这几个工具之间反复切换过，最后留在 opencode，不是说它每一项都最强，而是它在"可定制性"这个维度上正好戳中了我的需求。

6.1 对比维度与实测感受

我按自己比较看重的几个维度整理了一张对比表，纯属个人感受，仅供参考：

在纯代码能力上，Codex 和 Claude Code 的官方模型体验确实很顶，尤其在大规模重构和长上下文理解上，开箱即用就能达到不错的效果。但我要换模型、要自定义操作流程时，Codex 给我的感觉是"铁路警察，各管一段"，Claude Code 的 hooks 机制比 Codex 灵活一些，但整体架构仍然是以 Claude 为中心的。

opencode 的思路更像是"Agent 的底座"：模型只是其中一个组件，你可以换，可以去调整它的工作方式，可以做任何上层封装。它不会替你做决定，但给你足够的控制权。对于我这种喜欢把工具链按自己习惯组装的人来说，这种自由度比模型本身的强弱更重要。

6.2 我的选择逻辑

如果你问我"哪个 agent 最好用"，我的答案是：先看你用哪个模型。如果你已经重度使用 OpenAI 或 Anthropic 的模型，且工作流相对固定，直接用官方工具是最省心的。官方工具和自家模型之间的适配深度，是第三方工具很难追上的，尤其在一些细节处理上，比如工具调用的 token 效率、上下文压缩策略。

但如果你和我一样，想在不同的模型之间切换，或者需要在 Agent 的工作流里插入自己的脚本和检查逻辑，那 opencode 这种开放式架构会更合适。它不是和 Codex、Claude Code 正面竞争的关系，更像是给那些想做"人生不止一种模型"的人准备的自由空间。

还有一点是成本考量。官方工具通常只能用官方渠道的模型定价，而 opencode 可以按任务类型选择不同价位的模型：简单任务用便宜模型，复杂任务用顶配模型。这种"灵活调度"长期下来能省不少钱，这也是我坚持用它的原因之一。

6.3 踩坑之后的一点实在体会

最后分享一个我踩过最深、也最值得说的坑：刚开始用 opencode 时，我总想着把一个大任务一次性丢给它，让它自己拆解、自己执行、自己交付。结果是它在某个环节理解偏差，后面越走越偏，等我发现时已经浪费了很长时间和很多 token。

后来我总结出一个原则：大任务切成小任务，每个小任务给足上下文、限定明确范围。就像带新人一样，你不可能第一天就让实习生负责整个项目，而是先让他做一个小模块，确认他理解到位了，再逐步扩大范围。Agent 也是一样的道理，它跑得越快，前提是方向越准确。现在我做任何稍微复杂一点的改动，都会先让 opencode 给出一个简短的实施计划，我看一眼方向对不对，再让它继续往下做。这一步多花两分钟，但能避免后面半小时的返工。

如果你刚接触 opencode，我建议你先在一个练习项目上跑一周，用它做一些常规的 bug 修复和小功能开发，等摸清了配置和 skills 的脾气，再用到正式项目上。这个工具的上手曲线比那些开箱即用的官方 agent 要陡一些，但一旦搭建出适合你自己的工作流，回报会远超那点学习成本。