企业官网建设流程全解析

1. 先搞清楚：opencode 到底是什么，凭什么值得折腾

我最早注意到 opencode 是在一次技术社区的讨论里，有人把它和 Claude Code、Codex 放在一起对比，说它是“终端里的开源编码助手”。实际用了一段时间后，我越来越觉得这个定位只说对了一半——它确实运行在终端里，但它能做的事远不止“帮你补全代码”或“照着提示词改文件”，更像是一个长在项目里的 AI 协作者，能读代码库、能跑命令、能改文件、能调浏览器，甚至能自己安排一系列步骤去完成一个跨文件的开发任务。

很多人第一次听说 opencode 时会下意识问：这不就是又一个 AI 编程工具吗？和 Copilot、Cursor 有什么区别？我的答案是：区别在于工作方式。Copilot 类工具解决的是“你写代码时给你提词”，而 opencode 解决的是“你给一个目标，它自己拆解并执行”。举个例子，我可以直接对它说“帮我把这个项目里所有 TODO 注释整理成一份清单，并且按优先级排序”，它会自己去翻目录、读文件、检索关键词，最后生成一份 Markdown 报告放到指定位置。这个过程里我不需要告诉它读哪些文件、用什么命令，它自己就能规划路径。

更让我愿意持续使用的点是它的开源属性。作为一个可以本地化部署、完全掌控配置的终端 Agent，它对开发者来说没有“黑盒焦虑”——模型可以换、配置可以改、行为可以调。相比某些闭源工具的固定工作流，opencode 的自由度高出一个量级。对于需要频繁处理多语言项目、跨模块重构、自动化测试脚本的开发者来说，这几乎是一个“瑞士军刀”式的存在。

这篇文章我会从安装到实战，完整记录我折腾 opencode 的整个过程。内容包括：怎么把它跑起来、怎么配置模型、怎么用 Skills 和 Memory 增强它的能力、怎么让它在真实项目里干活、怎么在 VSCode 和 JetBrains 里用插件配合它，以及我踩过的各种坑和排查经验。不管你是第一天听说 opencode，还是已经装过但没玩明白，这篇都能给你点实际帮助。

2. 安装与基础接入：从命令行跑通第一个任务

2.1 跨平台安装：Windows、macOS、Linux 一条龙

opencode 的安装方式非常“现代 CLI 工具”风格，官方提供了多种渠道，我用下来最顺手的是通过包管理器直接装。macOS 用户可以用 Homebrew，命令是brew install opencode；Linux 用户可以用curl -fsSL https://opencode.ai/install | bash这条官方脚本；Windows 用户则可以直接用scoop install opencode，或者打开 PowerShell 执行官方安装脚本。

我第一次安装时用的是 Windows 机器，当时直接开了个 PowerShell 窗口跑安装脚本，过程很顺，装完敲opencode --version能看到版本号。这里要特意提醒 Windows 用户：如果你之前没装过 scoop 或者没有配置过用户级 PATH，装完可能会遇到opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称这个报错。这不是 opencode 本身的问题，而是可执行文件没有加入 PATH。解决办法很简单，在 PowerShell 里执行一条命令，把 opencode 的安装目录（一般是%USERPROFILE%\.opencode\bin）追加到当前用户 PATH 里，然后重开一个终端窗口就正常了。如果你用 Go 语言生态比较熟，go install github.com/sst/opencode@latest也能装，这种方式适合本来就习惯用 Go 工具链的开发者。

2.2 配置模型接入：别被一堆参数吓到

opencode 本身不内置模型，它更像一个“模型路由器”，需要你自己配置后端模型服务。第一次运行opencode时，它会引导你完成基础配置，你可以选择交互式输入 API Key，也可以手动改配置文件。配置文件的默认路径在~/.config/opencode/opencode.json（macOS/Linux）或%USERPROFILE%\.config\opencode\opencode.json（Windows），里面是一个 JSON 结构。

第一次配置时我踩了个小坑：我以为只要把 API Key 填进去就能用，结果跑第一个任务时报了错误，提示模型不存在或服务不可用。后来翻了文档才明白，opencode 支持多种模型服务商，需要在配置里指定 provider，然后在 provider 下面写 model 名称和 API Key。举个例子，如果你要用 OpenAI 兼容的接口，配置大致长这样：

{ "$schema": "https://opencode.ai/config.json", "provider": { "openai": { "api_key": "你的密钥", "model": "gpt-4o" } } }

如果你只想快速试一把，也可以在终端里直接用环境变量指定密钥，opencode 会自动读取常见环境变量名称，这一点对习惯用 dotenv 管理密钥的人很友好。我自己的习惯是：不动配置文件，在 shell 的 profile 里设置好环境变量，这样换项目不用反复改配置。

2.3 首次启动：跑一个最简单的对话任务

配置完成之后，直接在项目目录下执行opencode，它会进入一个类似 REPL 的交互界面。你可以直接打字提问，比如问它“这个项目的依赖管理文件是哪个”，它会先扫描目录结构再回答，而不是凭空猜测。我第一次跑的时候，它识别出这是一个 Python 项目，准确说出了 requirements.txt 的位置，还顺带解释了哪些依赖是核心依赖。这个“先看再答”的习惯给我留下不错的印象，说明它不是那种只会背知识库的聊天机器人，而是真的会结合当前代码上下文。

如果你觉得交互式界面不够脚本化，opencode 也支持非交互模式，比如opencode run "你的指令"这条命令可以直接执行单次任务并输出结果。这个模式在 CI/CD 流水线里特别有用，你可以把 opencode 当成一个自动化的代码审查机器人或者文档生成工具来调。我后来写一个自动化脚本时就是这样用的：让 opencode 读一堆日志文件，然后输出错误分类报告，全程不需要人工介入。

3. 模型选择与模式配置：找到最顺手的组合

3.1 CLI 模式与“opencode go”模式到底有什么区别

很多人在搜索 opencode 时会看到opencode go这个说法，我刚开始也一头雾水，以为是某个子命令。实际用下来才明白，它指的是通过 Go 工具链安装的版本，也就是go install那个渠道，而不是说 opencode 分了“CLI 版”和“Go 版”两个产品线。用 Go 安装的好处是二进制文件会和你的 Go 环境放在一起，升级管理更统一，适合本来就用 Go 做开发的场景。

不过在功能层面，opencode 确实有两种运行思路：一种是“对话驱动”，就是你一直在交互界面里和它来回沟通，像一个结对编程的搭档；另一种是“任务驱动”，通过opencode run执行一次性任务，适合明确的、不需要多轮沟通的指令。我自己的使用习惯是：探索性工作用交互模式，比如让它分析项目结构、解释一段复杂逻辑；重复性工作用任务模式，比如生成测试文件、格式化代码、整理错误日志。两种模式配合起来，效率会高出不少。

3.2 选模型时我在想什么：能力、速度与成本的三角权衡

opencode 支持很多模型，选择本质上是能力、速度、成本三者之间的平衡。如果你只是让它写点简单的脚本、正则表达式、Shell 命令，中等规模的模型完全够用，响应速度快，也不会烧太多 token。但如果你要处理跨文件的复杂重构、理解大型代码库的业务逻辑，就需要更强的模型，这类模型往往更贵、更慢。

我自己在项目里会同时配置好几个模型，然后在不同场景下切换着用。比如日常问答用轻量模型，写复杂算法或重构模块时切换到更强的模型。opencode 的配置支持多模型并存，在交互界面里可以随时切换当前模型。这个设计对我来说非常实用。一个经常被忽略的点是“上下文长度”——有些模型虽然很聪明，但上下文窗口小，处理大型代码库时容易“忘事”；有些模型上下文很长但推理能力一般。选型时要结合你项目的实际体量，不能只看榜单分数。

3.3 遇到“模型在当前地区不可用”怎么办

看到这个热词被频繁搜索，我觉得有必要专门说一句。我自己在配置一个模型服务时也遇到过类似提示，内容大致是this model is not available in your country。这个问题的本质是模型服务商按区域授权，某些地区访问特定模型会被拒绝。这不是 opencode 本身的问题，也不是你的配置写错了。

遇到这种情况，最直接的调整思路是换成配置里可用的模型，或者向你的模型服务商确认该区域是否支持。如果你有多个服务商的账号，可以切到其他服务商提供的模型。我不太建议在这种问题上花太多时间折腾，因为模型服务商的政策随时可能调整，与其和“地理限制”较劲，不如准备好两三个备选模型。opencode 的配置灵活性在这里就体现出来了——你可以在配置里同时写好多个模型，一个不行就换另一个，运行过程中的切换成本几乎为零。

4. 核心功能实战：Skills、Memory、LSP 与项目接管

4.1 Skills：让 opencode 学会你的项目专属技能

Skills 是 opencode 非常亮眼的一个能力，它允许你给 Agent 定义一组“技能”或“操作规范”，让它在特定场景下调用。打个比方，默认的 opencode 像一个实习生，基础能力在线但不懂你项目的特殊规矩；配置了 Skills 之后，它就像接受过岗前培训的老员工，知道代码规范、知道提交信息格式、知道怎么跑测试。

我实际玩了一下 Skills 的配置逻辑。opencode 会把 Skills 放在项目目录或全局配置目录下，每个 Skill 是一个包含描述和指令的文件夹，你可以写自然语言说明这个 Skill 是干什么的、应该在什么场景下触发、具体执行步骤是什么。比如我可以定义一个“代码审查”Skill，让它收到审查请求时，先检查代码风格、再查是否有硬编码、最后生成审查报告。它执行时会严格按这个顺序来，而不是自由发挥。

我试过让 opencode 通过一个自定义 Skill 去整理项目的 README 文档，效果比我预想的好。它在执行时会主动读取 README 现有内容，对比项目实际结构，列出不一致的地方，再生成修改建议。这个过程中我能观察到它是一步步按照我设定的规则来的，而不是一股脑输出一大段文本。

4.2 Memory：让 Agent 记住你的偏好和历史决策

Memory 功能解决的是“上次说过的这次又忘”的痛点。用对话式 AI 工具久了都会遇到一个烦心事：每次新开会话，它都不记得上次讨论的结论。opencode 的 Memory 机制会把一些关键信息持久化保存，后续会话可以自动加载。

实际操作中，你可以通过对话直接告诉它“记住我倾向于使用类型注解”，它会把这条信息写入记忆文件。下次会话再聊相关话题时，它给出的代码就会自动带上类型注解。对我来说最有用的场景是跨会话维护项目约定，比如每个模块必须写测试、错误处理统一用某种风格、变量命名遵循什么规范，这些约定口头说过一次就好，不用每次重复讲。

不过 Memory 也不是灵丹妙药，它需要你有意识地“喂”信息。如果你什么都不告诉它，它当然记不住任何偏好。这就像带新人，你希望对方记住什么，最好明确说出来，而不是指望他通过察言观色自己总结。我自己会在项目开始时做一次“项目约定注入”，把编码规范、目录结构约定、常用命令一次性告诉 opencode，后面干活会顺滑很多。

4.3 LSP 集成：不只是读代码，而是真正“理解”代码

opencode 支持接入 LSP（Language Server Protocol），这意味着它不只是在文本层面读代码，而是能获得语法分析、类型信息、引用关系这些编译级别的理解。我一开始不理解这个功能的意义，直到我让它重构一个 Java 方法时才意识到 LSP 的重要性：它能准确找到所有调用点，而不是靠正则匹配碰运气。

配置 LSP 需要对项目使用的语言做额外设置。opencode 支持多个 LSP server，比如 TypeScript 项目可以用 typescript-language-server，Python 项目可以用 pyright 或 pylsp。配置文件里指定语言的 LSP 工具后，opencode 会自动启动对应的 language server 来分析项目。当然，这要求你本地已经装好了对应的 LSP 服务，opencode 只负责调用，并不会替你安装。

对开发者来说，LSP 集成带来的最大价值是“跨文件重构”和“精确定位”能力。比如你提一个需求“把 utils.ts 里的 formatDate 函数移到 date.ts 里，并且更新所有引用”，没有 LSP 的 Agent 要么靠猜，要么只能改一部分引用导致编译错误；而有 LSP 支持的 opencode 能精确分析调用链，把活干完且不出错。这个功能对那些涉及多文件联动的重构任务帮助极大，也是我后来在 Java 项目里敢放手让它改代码的原因。

4.4 接手项目：给它一个陌生代码库，看它怎么“读”

“接手开发项目”是 opencode 一个非常实用的场景。你刚拿到一个别人写的项目，代码量巨大、文档缺失、逻辑混乱，但你需要在最短时间内了解它并开始修改。我自己做过一个实验：把一个我完全没看过的开源项目丢给 opencode，让它告诉我这个项目是干什么的、核心模块有哪些、入口在哪里、主要依赖是什么。

它做了一件事让我印象很深：先通过目录结构和包名推断整体分层，然后读配置文件了解依赖和构建方式，再找到入口文件追踪主流程，最后按模块梳理核心逻辑。整个过程它没有让我补一句说明，全靠自己读出来的。最终给出的项目概览虽然不能替代人肉通读，但已经能帮我省掉半天到一天的熟悉时间。

当然，opencode 并不能保证“读完就懂每一个细节”。它更擅长把握整体结构和主流程，对于某些复杂的业务逻辑，它也可能理解偏差。我的建议是：用它做第一轮项目扫描和框架梳理，然后再针对你关心的模块深入提问，这样效率最高。

5. 让 Agent 替你跑前端：Playwright 集成实战

5.1 为什么要在 opencode 里集成 Playwright

日常开发里最让人头疼的重复劳动之一就是前端测试。特别是修一个 bug 之后，你需要确认页面交互没有被破坏，这种“回归验证”既无聊又耗时。opencode 提供了和 Playwright 结合的方案，让它能真正打开浏览器、模拟用户操作、检查页面表现，然后根据结果调整代码。

这个功能对我的价值很大，因为很多前端 bug 光看代码是看不出来的，必须“跑一遍”才能看到真实表现。opencode 集成 Playwright 后，我只需要用自然语言描述问题场景，比如“打开登录页，输入错误密码，看看会不会弹出错误提示”，它自己会写 Playwright 脚本、启动浏览器、执行操作、捕获结果，然后对照预期判断是否符合。整个过程像是有一个测试工程师在帮你干活，而你只需要描述“你希望看到什么”。

5.2 配置流程：从安装浏览器到第一个自动化任务

要在 opencode 里用 Playwright，你需要先确保环境里已经安装了 Node.js 和 Playwright 相关的浏览器内核。opencode 本身不负责安装这些依赖，它只是调用你机器上已有的 Playwright 环境。我第一次用时卡在这一步：opencode 能生成脚本，但执行时提示找不到浏览器，后来我手动跑了一遍npx playwright install chromium才解决。

配置好之后，给 opencode 的下一个任务就可以涉及浏览器操作了。比如你可以直接输入“打开本项目的首页，截图登录按钮的样式，帮我检查是否符合设计稿”，它会调用 Playwright 启动一个有头或无头浏览器，访问本地开发服务器，然后执行截图。如果页面还没启动开发服务器，它还知道先帮你跑起来。我第一次看到它自己启动 Vite 开发服务器、等端口就绪、再打开浏览器时，确实有种“这工具真懂事”的感觉。

5.3 实测：用自然语言指挥它修一个前端 bug

我专门做了一个实测来验证这套流程的可用性。我在一个 React 项目里故意留下一个 bug：点击按钮后本应显示一个提示信息，但控制台报了 TypeError，提示某个属性为 undefined。我把这个现象用自然语言告诉 opencode：“点击提交按钮时控制台报错，提示某个值未定义，帮我定位问题并修复。”

opencode 的流程是这样的：先读相关组件代码，定位按钮的事件处理函数；再顺着报错信息查找可能为 undefined 的值；然后用 Playwright 打开页面复现问题，确认报错确实存在；接着修改代码；最后重新跑一遍测试验证修复生效。整个过程我基本插不上手，只能在旁边看它执行。最后不仅 bug 修好了，它还写了一个简单的回归测试脚本，防止以后再次出现类似问题。

这个实测让我确信，opencode 和 Playwright 的组合已经不只是“玩具级”的自动化，而是能真正进入日常开发流程的实用组合。当然，它也有局限：复杂交互、动态渲染、权限校验等场景偶尔会失败，需要你手动介入调整。但作为“第一轮测试执行器”，它的效率和覆盖率已经足够让人满意。

6. 从终端到 IDE：VSCode 与 JetBrains 插件实战

6.1 VSCode 插件：在编辑器里直接召唤 Agent

虽然 opencode 在终端里已经很好用，但很多开发者还是习惯在编辑器里工作。opencode 官方提供了 VSCode 插件，装好之后可以在编辑器里直接和 Agent 对话。这个插件和终端版并不是两套独立的东西，而是共享同一套配置和会话状态的——你在编辑器里发起的对话，本质上还是在调 opencode 后端，只是交互入口变了。

我的实际体验是：VSCode 插件的最大优势是可以一边看代码一边和 Agent 对话，它的回答可以直接插入到当前文件中，不需要来回切换窗口。比如我让 Agent 帮我重写一个函数，它给出的代码可以通过“应用更改”按钮直接落到编辑器里，我 review 完再保存。这个流程比在终端里复制粘贴要顺畅得多。

如果你熟悉 VSCode 的命令面板（Ctrl+Shift+P），装好插件后可以直接输入 opencode 相关命令来启动会话、切换模型、查看历史记录。我个人觉得这个插件适合“轻量修改 + 快速问答”的场景，而终端版更适合“大任务、长时间运行”的项目级操作。两者互补，建议都装上。

6.2 JetBrains 系插件：IDEA、PyCharm 等一个思路

JetBrains 用户同样有官方插件可以用，装好后在 IntelliJ IDEA、PyCharm、GoLand 等系列 IDE 里都能直接触发 opencode。插件的使用方式和 VSCode 版类似，都是从右侧或底部的工具窗口打开对话面板。对于我这种用 IDEA 写 Java 的人来说，这个插件最大的价值是和 IDE 自身的代码分析能力配合——Agent 给的建议，我能立刻在 IDE 里看到语法高亮、类型检查和运行结果。

和 VSCode 插件一样，JetBrains 插件也支持把 Agent 的修改直接应用到代码中。但有一点要注意：如果你的项目用了复杂的构建工具（比如 Maven 或 Gradle），opencode 在分析代码时不一定能自动识别所有依赖关系，有时需要你提供一些上下文。我一般会把mvn dependency:tree的输出的关键部分复制给它，或者直接让它先跑一遍构建命令，这样它的分析会更准确。

6.3 说说 IDE 插件和终端模式的取舍

用了一段时间 IDE 插件和终端模式之后，我觉得两者并不是替代关系，而是各司其职。终端模式更适合批量任务、脚本化操作和 CI/CD 集成，而且它的交互界面信息密度更高，适合长任务观察；IDE 插件则更适合日常开发中的“贴身辅助”，你看代码时随手问一句、让它改个函数、写个测试，全程不脱离编码上下文。

如果你之前一直只用终端模式，我建议你装一下 IDE 插件试试。它和学习成本很低——装好之后你不需要任何额外的配置，之前的模型配置、Skills、Memory 全部自动生效。换句话说，你之前的“调教”在 IDE 里也能继承，这种感觉还是挺爽的。

7. 常见问题排查实录与避坑技巧

7.1 热词里高频出现的报错，一个个说清楚

很多人搜 opencode 的相关问题，核心就那几个高频报错。我在折腾过程中也基本全遇到了一遍，这里按出现频率排序，逐个分析根因和解决方案。

第一个高频问题是opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这个报错 90% 的情况是 PATH 没配好。安装后 shell 没有重开，或者安装目录没加入 PATH，都会导致系统找不到可执行文件。解决办法：确认安装目录路径，手动加到环境变量里，重开终端。如果是用 Go 安装的，检查$GOPATH/bin是否在 PATH 中。

第二个高频问题是unexpected server error. check server logs。这个报错通常不是 opencode 自身的问题，而是后端模型服务返回了异常。可能的原因包括：API Key 无效、模型名称拼写错误、服务商端临时故障、请求参数不被模型服务接受。我的经验是：先检查配置里的 provider 和 model 字段是否正确，再确认 API Key 有足够额度，最后看网络是否能正常访问模型服务。如果都正常，大概率是服务商临时故障，等一会儿再试即可。

第三个高频问题是this model is not available in your country。这个在前面已经详细说过，根因是模型服务商的区域授权限制。建议换一个在当前区域可用的模型，或者使用其他模型服务商的接入方式。opencode 的多模型配置能力在这里很关键，平时多配一个备选模型，关键时刻能救命。

7.2 Skills 不生效的排查思路

Skill 配置好却不生效，这个问题也挺让人抓狂的。我遇到过两次，最后都解决了。第一次是因为我把 Skill 文件夹放错了位置，opencode 只会在特定目录下扫描 Skills，放错了自然加载不到。查一下官方文档确认路径即可。第二次是 Skill 的描述太模糊，导致触发条件不匹配。opencode 判断何时调用 Skill，主要靠描述信息和用户请求的语义匹配，如果你的描述写得过于宽泛或过于具体，都可能降低匹配准确率。我后来把描述改得“像搜索关键词”一样精准，命中率明显提升。

7.3 Playwright 相关：连不上浏览器、脚本超时这些坑

Playwright 集成虽然好用，但坑也不少。最常见的是“找不到浏览器”的报错，多半原因是没执行过npx playwright install，或者安装的浏览器内核版本和 Playwright 依赖的版本不匹配。固定做法是：首次配置时完整执行一次浏览器内核安装命令，以后升级 Node 依赖后如果报错，重跑一遍即可。

另一个常见问题是“脚本超时”。opencode 生成的 Playwright 脚本默认可能设置了严格的超时时间，而某些页面加载慢或存在慢接口时，脚本会在超时后失败。你可以适当调大超时参数，或者在给 opencode 的指令里明确“等待时间可以长一些”。还有一个隐蔽问题：如果你本地开发服务器没有启动，Playwright 访问不到页面也会超时。记住，opencode 有时候会忽略启动开发服务器这一步，你需要提前手动把服务跑起来。

7.4 配置文件的“另类”技巧：直接改 JSON 比交互配置更快

opencode 的配置文件是一个 JSON 文件，很多人倾向于在首次启动时通过交互菜单设置。但实际用下来，我发现直接编辑 JSON 文件效率更高，尤其当你需要配置多个模型、多个 provider、自定义参数时。交互式界面适合新手快速上手，老手建议直接上手改文件。

配置文件里有很多可选字段，比如模型温度、上下文长度、是否禁用某类工具等等。我建议你养成“先备份再修改”的习惯，改之前复制一份原文件。因为某些字段如果你不熟悉，改坏了会导致 opencode 起不来，这时备份文件就是你的后悔药。另外，不同版本的 opencode 配置文件格式可能会有调整，升级后如果发现配置失效，去官方文档看下 schema 变更说明，别自己想当然去补字段。

8. 从入门到舒服使用：我的一些个人经验和扩展想法

到这里，opencode 的主要功能和使用方法已经全部过了一遍。最后再分享几个我自己的“舒服使用”经验，这些不是官方文档里会写的东西，但对你实际用起来的体验影响很大。

第一个经验：给 opencode 配置一个“项目启动提示”。每次进新项目时，先花五分钟把项目背景、技术栈、请求入口、构建命令这些东西告诉它，这五分钟的投资能让你后续的每次提问都更精准。就像带新同事，第一天给他讲清楚团队规范，后面合作才顺畅。

第二个经验：善用opencode run做定时任务。我写了一个简单的脚本，每天下班前会自动跑一遍 opencode，让我今天的代码检查一遍 TODO、输出变更摘要、生成明日计划。这个习惯让我对项目状态的掌控感强了很多，而且完全不需要手动执行任何命令。

第三个经验：配置一个“代码解释器”Skill。当你拿到一段别人写的复杂逻辑时，让 opencode 按照“整体作用、关键逻辑、潜在问题、优化建议”四个维度去解读。用了几次之后，你会发现自己读代码的速度也提高了——因为它的解读框架会潜移默化地影响你的思维方式。

第四个经验是：不要怕给它“大任务”。很多人用 AI 工具时习惯把任务拆得非常碎，生怕它干不了。opencode 这种 Agent 式工具的定位恰恰相反，它更适合那种“你去把这个模块测试补一下”“帮我重构这块逻辑”“分析一下性能瓶颈”级别的大任务。你给它足够的信息和信任，它往往能给你超出预期的结果。当然，过程中你可能需要检查它的步骤、纠正方向，但整体体验比事无巨细地下指令要爽得多。

最后说句实在话：opencode 仍然是一个快速迭代中的工具，版本更新频繁，部分功能文档不够完善，偶尔也会遇到一些莫名其妙的问题。但它的核心思路——开源、可配置、Agent 式协作——代表了 AI 编程工具一个很有前景的方向。如果你想找一个能真正替你干活、而不是只给你提建议的 AI 搭档，它值得你花点时间好好调教一番。