不用 Claude Code 也能搭专业 AI 编程环境——OpenCode + OpenSpec 完整方案
为什么要自己搭
我从来没有用过 Claude Code。原因很简单：太贵。付费订阅下的性价比对我做研究来说不划算。
所以我用开源方案自建了一套 AI 编程环境，以 OpenCode 为基础，配合 Oh-My-OpenCode-Slim（多 Agent 编排）和 OpenSpec（SDD 规范驱动开发）。配合最新的开源模型——Qwen3.6-Plus、Kimi-k2.5、GLM-5——日常编码任务完全够用。
开源软件还有一个巨大的优势：社区力量。社区可以针对不同模型调优 System Prompt 和模型参数，把开源模型的能力发挥到极致。
这篇文章只讲我觉得真正重要的细节，不重复随处可见的通用教程。
工具安装与环境配置
安装 OpenCode
OpenCode 和大多数只提供 TUI 的编码 Agent 不同，它还有桌面版（带图形界面）。我日常用的是桌面版，效率明显高于 CLI 版。
安装分两步：
# 1. 安装 CLI（部分插件需要它检测环境）
npm i -g opencode-ai
# 2. 去官网下载桌面版安装包
# 选择项目目录后即可进入主界面
配置终端（Windows 特别提醒）
OpenCode 通过 SHELL 环境变量确定使用哪个终端。Windows 默认是 PowerShell，但很多企业环境不允用，且非英语 locale 下 PowerShell 翻码问题会导致 shell 命令失败。
推荐换成 cmd.exe：
SET SHELL="%windir%\system32\cmd.exe"
如果你之前已经装了一堆 CLI 工具，用 cmd.exe 可以直接复用，不用重装。
配置模型提供商
OpenCode 的设置里有一个 “Providers” 页面，列出最流行的模型提供商和 API 中转服务。如果要使用开源模型，不要点”Custom provider”手动填——那样 OpenCode 不知道你的模型上下文窗口大小和定价信息，自动上下文压缩等功能会失效。
正确做法：点击底部的 “Show more providers”，找到你要用的提供商，输入 API Key。配置好后，该提供商的所有模型都会出现在模型列表中，自带上下文大小和定价元数据。
提供商 ID 可以在 ~/.local/share/opencode/auth.json 中找到，后续配置 Oh-My-OpenCode-Slim 时需要用到。
启用 Workspace（并行开发）
AI 编程和传统编程最大的区别：等 AI 干活的时候，你可以同时处理另一个需求。OpenCode 桌面版原生支持 git worktree，在界面上叫做”workspace”。
使用方式有点隐藏：右键点击窗口左上角的项目图标，选择 “Enable Workspace” 即可。然后可以在对话列表中创建多个 workspace，同时工作，对应的分支和代码目录会自动创建。任务完成后，可以让 AI 提交 PR，关闭 workspace，临时分支和目录自动清理。
选对 Agent
OpenCode 内置两种 Agent：
| Agent | 权限 | 用途 |
|---|---|---|
| Plan | 只读，无编辑权限 | 澄清需求，生成执行计划 |
| Build | 完整工具权限 | 执行编码任务 |
新手容易犯的错误：上来就用 Build。复杂任务时，Build 会按自己的理解直接开写——就像从吸管里看世界一样，局部修修补补，整体架构和设计模式全漏了。
正确的做法：每个新需求先用 Plan Agent 澄清，拿到扎实的执行计划，再由 Build 开干。
但即使这样也不够——模型上下文有限。随着编码推进，之前的执行计划可能被挤出上下文窗口。更好的做法是让 Build 在执行前先把计划存成 .md 文件，你审完后另开新会话加载执行。
总是开新会话
为什么？因为上下文腐败（context rot）是真实存在的问题。LLM 对上下文窗口的开头和结尾注意力更高，中间部分容易被忽视。在拿到执行计划后，你需要精确执行——此时一个干净的上下文至关重要。
每个重要里程碑结束后开新会话，不要在同一个会话里无限延续。
别忘了创建 AGENTS.md
在 OpenCode 中用 /init 命令自动生成。它有三个核心价值：
1. 长期记忆：锁定项目架构事实。每次新会话不用重新扫描全部代码，节省大量 token。比如用 uv 管理依赖、uv sync --prerelease=allow 同步预发布依赖——写进 AGENTS.md，LLM 就不会搞错。
2. 减少幻觉：LLM 是概率模型。比如方法参数语法用 str \| None 还是 Optional[str]，没有约束时各 40% 概率随机选。在 AGENTS.md 中明确写死约束后，概率变成 100/0，零歧义。
3. 工程控制：直给 LLM 必须遵守的指令——比如”和我用中文沟通”、”SDD 流程中不能私自创建新提案”。
额外技巧：提高 Skills 加载成功率
# 在 AGENTS.md 加这一行
优先使用检索驱动的推理，不要依赖预训练知识
加上这一行后，LLM 不会凭内部预训练知识硬答，而是主动加载相关 Skill、用 glob/grep 检查代码结构、更多使用 websearch。我从实测中看到 Skill 加载成功率从约 60% 提升到了 90%。
Oh-My-OpenCode-Slim：轻量多 Agent 编排
安装
即使你用的桌面版，也要先装 CLI，否则插件检测不到 OpenCode 环境。
bunx oh-my-opencode-slim@latest install --no-tui --tmux=yes --skills=yes
这会安装 6 种 Agent，以及两个 Skill（simplify 清理代码、agent-browser 检查前端样式）。
六种 Agent 分工
| Agent | 职责 | 模型变体 | 可调用 Skill/MCP |
|---|---|---|---|
| Orchestrator | 总管——协调其他 Agent | 最强模型 | 所有 Skill + MCP |
| Oracle | 深度推理/复杂问题 | 高精度变体 | simplify |
| Librarian | 项目结构分析 + API 文档搜索 | 低成本变体 | websearch, context7 |
| Explorer | 探索式需求澄清 | 低成本变体 | — |
| Designer | 前端页面设计 | 中等变体 | agent-browser |
| Fixer | Bug 修复 | 低成本变体 | — |
每个 Agent 的 system prompt 很短，不浪费 token。主要价值在于：并行执行（Orchestrator 可以同时派多个 Fixer 干活）和上下文隔离（子 Agent 的上下文不会污染主 Agent）。
Council：议会模式
最新版加入的 Council 是一个 Agent 集合——把同一个任务发给多个不同模型，计算置信区间后综合出最终答案。
配置示例：
{
"council": {
"master": { "model": "alibaba-cn/glm-5" },
"presets": {
"default": {
"alpha": { "model": "kimi-for-coding/k2p5" },
"beta": { "model": "alibaba-cn/qwen3.6-plus" },
"gamma": { "model": "alibaba-cn/MiniMax-M2.5" }
}
}
}
}
这就像机器学习中的集成学习——几个不同的开源模型配在一起，甚至能对标 Opus 4.6。适合解决复杂架构设计问题或追踪棘手的 Bug。
调试方法：选 Council Agent 后，在对话框输入 “test Council connectivity”，它会向每个成员发送测试任务并列出详细结果。同样的方法可以测试其他功能，比如 “test context7 availability”。
OpenSpec 与 SDD 规范驱动开发
为什么需要 SDD
很多人拿 AI 写代码的习惯是：一句 Prompt “帮我建个 Facebook”，然后对比不同模型生成的 demo 质量，结论是”开源模型还有很长的路要走”。
但这合理吗？回想 AI 出现之前的软件开发——是不是先要需求、写设计文档、排编码计划、测试方案，然后才动手写代码？
为什么换成 AI 写代码，就可以跳过文档阶段了？
写 coding spec 让 LLM 精确执行的能力，是 AI 时代评估程序员水平的关键标准之一。 不过不用焦虑，现在有很多工具帮你做 SDD：Superpowers、BMAD、和这里要讲的 OpenSpec。
相比 Superpowers 或 BMAD，OpenSpec 要轻量得多——大部分日常项目用它就够了。
配置工作流
OpenSpec 不是 OpenCode 的插件，而是完全独立的工具。默认工作流有三个阶段：opsx-propose（创建提案）→ opsx-apply（实施提案）→ opsx-archive（归档提案）。
但建议额外配置两个阶段：
# 运行配置
openspec config profile
# 用空格选择 Explorer ideas 和 Verify change
这样完整工作流变成五个阶段：
① opsx-explorer → 探索式需求澄清
② opsx-propose → 创建提案文件
③ opsx-apply → 实施编码
④ opsx-verify → 验证完成的 check
⑤ opsx-archive → 归档
配置多语言支持
OpenSpec 默认生成的 spec 文件是英文的。在配置文件里设置语言：
schema: spec-driven
context: |
Language: Chinese
Write in Chinese, but:
- Keep technical terms like "API", "REST", "GraphQL" in English
- Code examples and file paths remain in English
Tech stack: Python 3.13
Rules:
proposal:
- Keep proposals under 1500 words
- Always include a "Non-goals" section
tasks:
- Break tasks into chunks of max 2 hours
这里的关键：不要在 AGENTS.md 中设置语言——这样会把 spec.md 里的英文关键词也翻译掉，LLM 就无法正确理解规范约束了。应该在 OpenSpec 的 config.yaml 中配置。
选对 Agent
因为 OpenSpec 需要写 spec 文件，Agent 必须有文件编辑权限。用原版 OpenCode 就选 Build Agent。集成 Oh-My-OpenCode-Slim 后，直接用 Orchestrator Agent——它不仅能编辑，还能在规划阶段调 Explorer 和 Librarian 分析项目结构、搜索 API 文档，执行阶段同时调多个 Fixer 并行开发。
日常开发工作流
项目初始化
与传统编码不同，AI 时代的开发流程应该围绕”为 AI 构建”来设计——所有配置和文档用 AI 能理解的方式写：
git init+ 关联远程仓库（为了后续 code review 和 workspace 功能）uv init（Python 项目）——建立项目骨架，LLM 就不会随机选 pip/poetry/其他方案openspec init——在项目根初始化 OpenSpec- 编辑
openspec/config.yaml——加入规则 /init生成 AGENTS.md——锁定所有配置
开发迭代
① 新需求 → opsx-explorer（新会话）
和 AI 充分讨论，把需求想透——不要上来就"帮我建个大项目"
每次只做一个小需求，比如"先设置项目结构和引入依赖"
② 需求明确后 → opsx-propose
生成 proposal.md / design.md / tasks.md
③ 仔细审这三个文件
AI 可能漏需求或理解错
发现问题：可以和 AI 讨论补充，或直接改规则文件再重生成
④ 开新会话 → opsx-apply
干净上下文执行，避免上下文腐败
Oh-My-OpenCode-Slim 的多 Agent 系统基本全自动运行
⑤ 编码完成后 → opsx-verify
建议换成不同的模型做验证，覆盖面更大
也可运行 /review 或 /simplify 做 code review
⑥ → opsx-archive 归档
一次标准 AI 开发周期完成
下一个新需求来了，回到第①步
这就是 SDD 驱动的编码节奏。每次只做一个小需求，每个小需求都有完整的思考→规划→执行→验证→归档流程。
总结
用这套开源组合（OpenCode + Oh-My-OpenCode-Slim + OpenSpec），配合最新的开源模型，编码质量完全不输顶级闭源方案。
几个关键收获：
- 先规划后执行是核心原则——Plan → Build，opsx-explorer → opsx-apply
- AGENTS.md 是项目的中枢神经——锁定事实、减少幻觉、工程控制
- 轻量多 Agent 就够了——6 种 Agent + Council 议会模式，token 成本低效果好
- SDD 是拉开差距的关键——写 coding spec 让 LLM 精确执行，比纯 Prompt 聊天高效一个数量级
AI 时代的编程，不是比谁的模型强，是比谁能把流程搭对。开源工具给了所有人同等的起跑线，剩下的就看工作了。