OpenCode 项目上下文实战：AGENTS.md 与 Skills 让 AI 读懂你的代码库

一条 /init 命令，AI 就能完整掌握你的项目语境。这并非魔法，而是靠 AGENTS.md 体系实现。

通用 AI 不知道你们团队的工作约定、代码风格、目录结构——AGENTS.md 就是你为 AI 编写的「项目操作手册」，Skills 则是提供「专项技能包」。两者结合，把 OpenCode 从「通用助手」升级为「项目专家」。

核心思路：为什么必须使用 AGENTS.md

通用 AI 的真正短板

想象你刚招募了一位技术很强但对项目零了解的开发者。他产出的代码功能也许没问题，但大概率会出现：

• 变量命名风格随意，与 camelCase / snake_case 不符
• 无视 packages/core/ 是共享逻辑区的约束
• 部署前忘记执行 pnpm lint
• Git 提交信息与团队规范冲突

OpenCode 同样面临这个问题。 默认状态下它只是能力出众的 AI 编程助手——技术扎实，却对你的项目上下文一无所知。

AGENTS.md 就是项目的「上下文说明书」

AGENTS.md 是面向整个项目的 AI 配置文件，可以这样类比：

.editorconfig  →  指导编辑器如何格式化代码  
.gitignore     →  告知 Git 忽略哪些文件  
AGENTS.md      →  让 AI 懂得项目的运行规则

类比：.editorconfig 供编辑器阅读，AGENTS.md 供 AI 理解。两者均为项目级配置，理应纳入 Git 版本控制。

AGENTS.md 如何改变 AI 的行为

OpenCode 启动时，会把 AGENTS.md 的内容作为系统提示（System Prompt）的一部分注入每次对话。也就是说，无论你给 AI 分配何种任务，它都会自动遵循这里面定义的各项规则。

AGENTS.md 深度解析

/init 命令：一键生成项目说明书

OpenCode 内置了 /init 命令，可自动分析项目并生成 AGENTS.md：

你：/init  

OpenCode：  
🔍 扫描项目结构...  
📦 检验到 Go 项目，基于 Gin 框架  
📁 解析目录组织...  
📝 分析编码规范...  
✅ AGENTS.md 已生成

/init 的执行流程如下：

/init 命令

扫描项目文件 → 识别技术栈 → 分析目录结构 → 提取代码规范 → 生成 AGENTS.md

注意：如果项目中已存在 AGENTS.md，/init 会在现有内容基础上补充而非覆盖，这样能保护你手工编写的自定义配置。

AGENTS.md 的推荐模块设计

一份高质量的 AGENTS.md 应覆盖下面这些模块：

AGENTS.md

项目概况

编码规范

项目结构

特殊约定

构建与测试

已知问题

项目做什么、用哪些技术栈

命名、格式化、架构风格

目录组织逻辑说明

环境变量、部署流程

常用命令

坑与注意事项

模块 1：项目概况

让 AI 先明白这个项目的目标和用到的技术栈。

## 项目概况

这是一个基于 Go 开发的用户认证微服务。
- 语言：Go 1.22
- 框架：Gin v1.9
- 数据库：PostgreSQL 15 + GORM
- 缓存：Redis 7
- 认证方式：JWT（RS256 算法）

模块 2：编码规范

定义团队实际遵循的编程准则。

## 编码规范

- 变量和函数采用驼峰命名法（camelCase）
- 结构体和接口使用 PascalCase
- 错误必须显式处理，禁用 panic
- 所有公开函数需要 godoc 注释
- 单个函数长度不超过 80 行
- import 分组顺序：标准库 / 第三方库 / 项目内部包，各组之间用空行分隔

模块 3：项目结构说明

为 AI 标明目录组织的职责划分。

## 项目结构

- `cmd/server/` - 程序入口
- `internal/handler/` - HTTP 请求处理器
- `internal/service/` - 业务逻辑层
- `internal/repository/` - 数据访问层
- `internal/model/` - 数据模型
- `pkg/auth/` - 认证相关的可复用包
- `config/` - 配置文件
- `migrations/` - 数据库迁移脚本

模块 4：特殊约定

记录项目特有的环境配置、全局变量、部署流程等。

## 特殊约定

- 环境变量统一由 `.env` 文件管理，严禁硬编码
- 数据库迁移采用 golang-migrate，文件命名格式：`000001_create_users_table.up.sql`
- API 响应格式固定为 `{"code": 0, "message": "", "data": {}}`
- 分页参数统一用 `page` 和 `pageSize`，默认 pageSize=20
- 部署通过 Docker + GitHub Actions，主分支为 main

模块 5：构建与测试命令

清晰告诉 AI 如何构建、测试、部署你的项目。

## 构建与测试

```bash
# 启动项目
go run cmd/server/main.go

# 执行全部测试
go test ./...

# 运行特定包测试
go test ./internal/service/...

# 构建二进制文件
go build -o bin/server cmd/server/main.go

# 数据库迁移
migrate -path migrations -database "postgres://..." up

模块 6：已知问题和注意事项

记录项目中曾经遇到的「坑」，帮助 AI 主动规避风险。

## 已知问题和注意事项

- Redis 连接池不能超过 50，否则会触发服务端限制
- 用户表的 email 字段设置了唯一约束，更新操作要格外注意
- `internal/service/user.go` 中的 `CreateUser` 方法目前仍有缓存一致性问题，暂通过 TTL 缓解
- 不得修改 `pkg/auth/jwt.go` 中的签名算法，已有线上用户依赖 RS256

最佳实践：什么该写、什么不该写

核心原则：AGENTS.md 只应记录项目特有的信息。AI 已掌握通用知识，无需重复灌输。

实战案例展示

示例一：Go 项目 AGENTS.md

# User Service

用户管理微服务，负责注册、登录和权限管理。

## Tech Stack

- Go 1.22 + Gin v1.9
- PostgreSQL 15 + GORM v2
- Redis 7 (session cache)
- gRPC (跨服务通信)
- Docker + Kubernetes

## Project Structure

- `cmd/` - 入口 (server, worker, migration)
- `internal/handler/` - HTTP handlers
- `internal/service/` - Business logic
- `internal/repository/` - Data access layer
- `internal/model/` - Database models
- `pkg/` - 共享包
- `api/proto/` - gRPC proto 定义
- `deploy/` - Kubernetes manifests

## Code Standards

- 遵循 Effective Go 指南
- 变量 camelCase，导出名称 PascalCase
- 错误处理：必须检查，生产环境禁用 panic
- 所有导出函数都需要 godoc 注释
- 函数保持 80 行以内

## Commands

```bash
go run cmd/server/main.go      # 启动服务
go test ./...                   # 运行全部测试
go test -race ./...             # 竞态检测测试
docker compose up -d            # 启动依赖服务
make build                      # 构建二进制文件

Important Notes

• Proto 文件构建前必须先执行：make proto
• 数据库采用软删除 (gorm.DeletedAt)
• 速率限制由网关层处理，此服务不关心
• JWT token 有效期：access=15min, refresh=7d

示例二：Java / Spring Boot 项目 AGENTS.md

# Order Management System

订单管理系统后端，涵盖订单创建、支付和发货全流程。

## Tech Stack

- Java 17 + Spring Boot 3.2
- Gradle (Kotlin DSL)
- MySQL 8.0 + MyBatis Plus
- Redis (分布式锁)
- RabbitMQ (异步消息)
- Spring Security + JWT

## Project Structure

- `src/main/java/com/example/oms/`
  - `controller/` - REST API 控制器
  - `service/` - 业务逻辑层
  - `mapper/` - MyBatis 数据访问
  - `entity/` - 数据库实体
  - `dto/` - 数据传输对象
  - `config/` - Spring 配置
  - `common/` - 公用工具和常量
  - `exception/` - 全局异常处理
- `src/main/resources/`
  - `mapper/` - MyBatis XML 映射
  - `db/migration/` - Flyway 迁移脚本

## Code Standards

- 遵循《阿里巴巴 Java 开发手册》
- 用 Lombok 减少样板代码
- 优先使用 Java Stream API 处理集合
- Controller 只处理请求/响应，无业务逻辑
- Service 层承载所有业务逻辑
- 数据库操作添加 `@Transactional`
- 所有 API 响应统一用 `Result<T>` 包裹

## Naming Conventions

- 数据库表：`t_order`, `t_order_item`, `t_payment`
- REST 端点：`/api/v1/orders`, `/api/v1/orders/{id}`
- DTO 命名：`OrderCreateDTO`, `OrderQueryDTO`

## Commands

```bash
./gradlew bootRun                # 启动应用
./gradlew test                   # 运行测试
./gradlew clean build -x test    # 跳过测试构建
./gradlew flywayMigrate          # 执行数据库迁移
docker compose up -d             # 启动依赖服务

Important Notes

• Flyway 迁移版本规则：V{version}__{description}.sql
• 订单状态转换必须遵从状态机规则
• 支付回调采用幂等设计
• 库存扣减使用分布式锁 (Redis + Redisson)

示例三：前端项目 AGENTS.md

# Dashboard Web App

数据可视化后台管理系统，基于 React 和 TypeScript。

## Tech Stack

- React 18 + TypeScript 5
- Vite 5 (构建工具)
- TanStack Router (路由)
- TanStack Query (数据请求)
- TailwindCSS 3 (样式)
- shadcn/ui (组件库)
- Vitest + Playwright (测试)

## Project Structure

- `src/components/` - 可复用组件
  - `ui/` - shadcn/ui 基础组件
  - `forms/` - 表单组件
  - `charts/` - 图表封装
- `src/features/` - 功能模块
- `src/hooks/` - 自定义 Hooks
- `src/lib/` - 工具函数
- `src/routes/` - 路由定义（文件式路由）
- `src/types/` - TypeScript 类型定义
- `src/mocks/` - MSW 模拟处理器

## Code Standards

- 启用 TypeScript 严格模式
- 纯函数组件，禁用 class 组件
- 组件使用 `const` + 箭头函数
- 样式与组件同文件（Tailwind 类）
- 自定义 Hook 处理可复用的有状态逻辑
- 导入使用 `@/` 路径别名

## Component Conventions

- 组件文件：PascalCase（如 `UserList.tsx`）
- Hook 文件：camelCase，以 `use` 前缀开头（如 `useAuth.ts`）
- 单组件单文件
- 默认导出组件
- Props 接口命名：`ComponentNameProps`

## Commands

```bash
pnpm dev              # 启动开发服务器
pnpm build            # 生产构建
pnpm test             # 运行单元测试
pnpm test:e2e         # 端到端测试
pnpm lint             # ESLint 检查
pnpm storybook        # 启动 Storybook

Important Notes

• API 根地址由环境变量 VITE_API_URL 设定
• 所有 API 调用统一经过 src/lib/api-client.ts
• 认证 token 存储在 httpOnly cookie 中（禁用 localStorage）
• 所有服务端状态使用 React Query，避免用本地 state 管理 API 数据

Skills 系统：赋予 AI 专项能力

Skills 是什么

如果说 AGENTS.md 是「项目操作手册」，那 Skills（技能） 就是具体的「操作流程卡」。

Skills 是预定义的可复用指令模块，AI 会在需要的时刻按需加载。它们与 AGENTS.md 「始终存在」的方式不同，采用按需发现、按需加载的机制。

graph LR
    A["AGENTS.md"] -->|"始终加载"| B["AI 上下文"]
    C["Skills"] -->|"按需加载"| B

    A -.->|"项目知识<br/>编码规范"| B
    C -.->|"专项技能<br/>操作流程"| B

    style A fill:#4F46E5,color:#fff
    style C fill:#059669,color:#fff
    style B fill:#D97706,color:#fff

Skill 的文件结构

每个 Skill 都是 .opencode/skills/ 目录下的一个独立文件夹，内含一个 SKILL.md 文件：

.opencode/
└── skills/
    ├── git-release/
    │   └── SKILL.md        # Git 发版技能
    ├── pr-review/
    │   └── SKILL.md        # PR 审查技能
    └── db-migration/
        └── SKILL.md        # 数据库迁移技能

Skill 存放路径的数量越丰富越好，OpenCode 会按以下顺序搜索：

命名规则：Skill 名称（文件夹名）只能包含小写字母、数字和单个连字符，长度 1-64 字符，例如 git-release、pr-review。

SKILL.md 的 Frontmatter

每个 SKILL.md 必须以 YAML frontmatter 开头：

---
name: git-release
description: Create consistent releases and changelogs
license: MIT
compatibility: opencode
metadata:
  audience: maintainers
  workflow: github
---

## What I do

- 从已合并的 PR 中提取发布说明
- 推荐版本号变更
- 提供可直接复制的 `gh release create` 命令

## When to use me

当你要准备一次标记发行版时使用。如果目标版本策略不清晰，我会主动询问。

Frontmatter 字段说明：

Skill 的发现与加载机制

核心顺序如下：

1. 启动时：OpenCode 只扫描技能列表（名称 + 描述），不载入完整内容。
2. 按需加载：只有当 AI 认为需要某技能时，才会通过 skill 工具加载其完整正文。
3. 智能选择：AI 根据 description 字段自动匹配最适合的技能。

实战：打造自己的 Skill

示例一：Git 发版技能

创建 .opencode/skills/git-release/SKILL.md：

---
name: git-release
description: 根据已合并 PR 创建一致的发布和变更日志
metadata:
  audience: maintainers
  workflow: github
---

## What I do

- 分析自上次标签以来的所有合并 PR
- 按类型（feat/fix/breaking）分组编写发布说明
- 基于语义化版本推荐下一版本号
- 生成可复制粘贴的 `gh release create` 命令

## Steps

1.  执行 `git log <last-tag>..HEAD --oneline` 找出合并内容
2.  将变更分为功能、修复、破坏性更新
3.  依据变更类型建议版本升级（major/minor/patch）
4.  按 Keep a Changelog 格式生成发布说明
5.  提供 `gh release create` 命令

## Rules

- 创建前必须取得确认
- 发布说明中需包含 PR 编号和参与者
- 破坏性变更必须突出标记

实际效果：

你：帮我准备 v2.3.0 的发布

OpenCode：
🔧 加载技能：git-release
📋 分析自 v2.2.0 以来的变更...

## Release v2.3.0

### Features
- 添加用户导出 CSV (#142 由 @alice 提交)
- 支持深色模式切换 (#145 由 @bob 提交)

### Bug Fixes
- 修复移动端分页溢出问题 (#143)

### Command
gh release create v2.3.0 --title "v2.3.0" --notes "..."

示例二：数据库迁移技能

创建 .opencode/skills/db-migration/SKILL.md：

---
name: db-migration
description: 以安全命名和验证方式管理数据库迁移
metadata:
  category: database
---

## What I do

- 生成命名规范的迁移文件
- 审核迁移 SQL 的安全性（防止数据丢失）
- 创建回滚脚本
- 校验迁移顺序

## Migration Naming Convention

- 格式：`V{version}__{description}.sql`
- 版本号必须顺序递增
- 描述用 snake_case
- 示例：`V005__add_user_phone_column.sql`

## Safety Rules

- 绝对不要在没有备份的情况下使用 DROP COLUMN
- 任何迁移都必须提供回滚脚本
- 数据迁移采用分批处理（每批最大 1000 行）
- 建议前先在本地数据库测试

## Steps for New Migration

1.  确定下一个版本号
2.  编写 UP 迁移 SQL
3.  编写 DOWN（回滚）SQL
4.  对复杂操作添加注释说明
5.  提议本地测试命令

示例三：代码审查技能

创建 .opencode/skills/pr-review/SKILL.md：

---
name: pr-review
description: 关注安全性、性能和可维护性的结构化代码审查
metadata:
  category: review
---

## What I do

- 用结构化检查表审查代码变更
- 重点覆盖安全、性能和可维护性
- 提供附带代码示例的可执行建议
- 生成审查总结

## Review Checklist

### Security
- [ ] 输入验证和净化
- [ ] SQL 注入防御
- [ ] 认证与授权检查
- [ ] 敏感数据暴露

### Performance
- [ ] N+1 查询检测
- [ ] 不必要的前端重渲染
- [ ] 缺失索引
- [ ] 内存泄漏

### Maintainability
- [ ] 函数长度（< 50 行）
- [ ] 合理的错误处理
- [ ] 有意义的命名
- [ ] 足够的测试覆盖

## Output Format

### Summary
整体简要评估

### Critical Issues
合并前必须修复的问题

### Suggestions
锦上添花的改进建议

### Positive Notes
值得肯定的优秀实践

Skill 权限控制

在 opencode.json 中可以控制 AI 能访问哪些技能：

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "skill": {
      "*": "allow",
      "internal-*": "deny",
      "experimental-*": "ask"
    }
  }
}

AGENTS.md 与 opencode.json：分工明确

定位差异

opencode.json — 工具自身的配置

模型选择

API 密钥

权限设置

MCP 服务器

插件管理

AGENTS.md — AI 的知识输入

项目概况

编码规范

目录结构

特殊约定

构建命令

对比详表

何时用 AGENTS.md

• 定义项目的编码规范和风格指南
• 说明目录结构和模块职责
• 记录构建、测试、部署相关命令
• 列出已知技术债务和需要注意的点
• 描述团队的 Git 提交规范
• 确定 API 约定与数据格式

何时用 opencode.json

• 配置使用哪个大语言模型
• 管理 API 密钥和提供商
• 设定文件编辑及 bash 命令的权限
• 配置 MCP 服务器连接
• 加载插件和自定义命令
• 配置主题与快捷键

两者如何协同工作

一个典型项目的组合配置：

my-project/
├── AGENTS.md              # 项目知识（提交 Git）
├── opencode.json          # 工具配置（提交 Git，密钥用环境变量）
├── .opencode/
│   ├── agents/            # 自定义代理
│   ├── commands/          # 自定义命令
│   └── skills/            # 自定义技能
└── .env                   # 环境变量（不提交 Git）

opencode.json 也支持通过 instructions 字段引用额外规则文件，与 AGENTS.md 合并生效：

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-5",
  "instructions": [
    "CONTRIBUTING.md",
    "docs/coding-standards.md",
    ".cursor/rules/*.md"
  ]
}

instructions 中引用的所有文件都会和 AGENTS.md 一同注入 AI 上下文。因此可以复用已有的团队规范文档，无需重复维护。

团队共享最佳实践

1. 将 AGENTS.md 纳入版本控制

# 将 AGENTS.md 纳入版本管理
git add AGENTS.md
git commit -m "docs: 为 AI 项目上下文添加 AGENTS.md"

# 敏感信息绝不应写入 AGENTS.md
# 使用 .env + opencode.json 的 {env:XXX} 管理密钥

2. 分层配置满足个性化需求

OpenCode 支持多层配置，每一层对应不同作用域：

团队公共规范

个人偏好

项目级 AGENTS.md（Git 共享）

AI 上下文

全局 AGENTS.md（~/.config/opencode/）

instructions 引用（opencode.json）

Skills（.opencode/skills/）

3. 全局 AGENTS.md 示例

~/.config/opencode/AGENTS.md——属于你个人的 AI 偏好：

# Personal Preferences

- 永远使用简体中文回复
- 解释要简洁，避免啰嗦
- 生成代码时附带简短的中文注释
- 尽量采用函数式编程风格

4. 跨项目共享规范

若团队有多个项目需要共享相同的规范，有两种方式：

方式 A：远程 URL 指令

{
  "instructions": [
    "https://raw.githubusercontent.com/my-org/shared-rules/main/java-standards.md",
    "https://raw.githubusercontent.com/my-org/shared-rules/main/git-conventions.md"
  ]
}

方式 B：Git 子模块或符号链接

# 将共享规范作为 Git 子模块引入
git submodule add https://github.com/my-org/shared-rules.git shared-rules

# 在 opencode.json 中引用
# "instructions": ["shared-rules/java-standards.md"]

进阶技巧

技巧一：在 AGENTS.md 中引用外部规则文件

OpenCode 不会自动解析 AGENTS.md 内的文件引用，但你可以用明确指令教 AI 按需读取外部文件：

# Project Rules

## External File Loading

CRITICAL：当你遇到文件引用（例如 @rules/general.md）时，请用 Read 工具按需加载。

Instructions:
- 不预加载所有引用
- 加载后将其视为强制指令
- 必要时递归跟随引用

## Development Guidelines

TypeScript 代码风格：@docs/typescript-guidelines.md
API 设计模式：@docs/api-standards.md
测试策略：@test/testing-guidelines.md

推荐使用 opencode.json 的 instructions 字段来替代这种方式，因为 instructions 由框架自动处理，更加可靠。

技巧二：针对不同代理定制行为

结合代理系统和 AGENTS.md，可以让不同代理呈现不同的行为倾向。在 AGENTS.md 中使用条件指令：

# Project Rules

## General

- 提交前所有代码必须通过 lint
- 使用 TypeScript 严格模式

## For Build Agent

- 创建新文件时，同步添加对应的测试文件
- 每次代码变更后执行 `pnpm lint --fix`

## For Plan Agent

- 为每个任务评估复杂度（S/M/L）
- 在建议实施顺序前先列出依赖项

技巧三：从 Claude Code 无缝迁移

如果你从 Claude Code 迁移到 OpenCode，可以无需立即改动原有配置：

Claude Code 配置

OpenCode 兼容处理

CLAUDE.md → AGENTS.md

~/.claude/CLAUDE.md → 全局 AGENTS.md

~/.claude/skills/ → Skills

OpenCode 会自动识别：

• 项目目录中缺少 AGENTS.md 时，会回退读取 CLAUDE.md
• 全局缺少 ~/.config/opencode/AGENTS.md 时，会回退读取 ~/.claude/CLAUDE.md
• 同样兼容 ~/.claude/skills/ 下的技能文件

如果需要关闭 Claude Code 兼容模式，可设置以下环境变量：

# 完全禁止 .claude 支持
export OPENCODE_DISABLE_CLAUDE_CODE=1

# 仅忽略 ~/.claude/CLAUDE.md
export OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=1

# 仅忽略 .claude/skills
export OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1

技巧四：动态更新 AGENTS.md

每当项目发生重大调整（如引入新框架、调整目录结构），务必同步更新 AGENTS.md：

# 方法 1：再次运行 /init，在现有内容上补充
/init

# 方法 2：手动编辑 AGENTS.md
# 只修改变动部分，保持其他内容不变

建议：将 AGENTS.md 的检查项纳入代码审查流程。当项目结构或规范发生变化时，对应的 PR 应同时更新 AGENTS.md。

常见问题（FAQ）

Q1：AGENTS.md 和 CLAUDE.md 到底有什么区别？

AGENTS.md 是 OpenCode 的原生格式，而 CLAUDE.md 来自 Claude Code。OpenCode 会优先使用 AGENTS.md，仅在缺失时才回退到 CLAUDE.md。想获得最佳兼容性，建议直接使用 AGENTS.md。

Q2：AGENTS.md 内容太长会影响性能吗？

会的。AGENTS.md 的内容会作为系统提示的一部分注入每次对话，过长会占用宝贵的上下文窗口。建议控制在 500 行以内，聚焦项目特有信息。详细规范可交由 instructions 字段按需加载。

Q3：能在 monorepo 的子目录中放置 AGENTS.md 吗？

可以。OpenCode 会从当前目录向上遍历至 Git 根目录，沿途加载所有遇到的 AGENTS.md。因此你可以在 packages/api/AGENTS.md 中定义 API 模块特有规范，而根目录的 AGENTS.md 负责全局规则。

Q4：Skill 和自定义命令有什么区别？

Q5：怎样验证 AGENTS.md 已生效？

在 OpenCode 中直接询问：

你：我们项目的代码规范是什么？

OpenCode：
根据项目配置：
- 使用 Go 1.22 + Gin 框架
- 变量采用 camelCase 命名
- 公开函数必须带有 godoc 注释
...

如果 AI 能够准确复述你定义的规范，就说明 AGENTS.md 已经成功加载。

Q6：多个规则文件之间会产生冲突吗？

OpenCode 按优先级加载规则文件，后面的会覆盖前面的：

1. 本地 AGENTS.md（从项目根向上遍历加载）
2. 全局 ~/.config/opencode/AGENTS.md
3. Claude Code 兼容的 ~/.claude/CLAUDE.md

同类别内，AGENTS.md 优先级高于 CLAUDE.md。instructions 字段中的文件会和 AGENTS.md 合并生效。

总结

项目 AI 理解能力 = AGENTS.md（持续在线的项目知识） + Skills（按需调用的操作技能）

通过本篇文章，你已经掌握了：

• ✅ 通用 AI 为何需要 AGENTS.md——它天然不了解团队的内部约定
• ✅ AGENTS.md 的推荐结构与最佳实践——什么该写、什么不必写
• ✅ 三种项目类型（Go / Java / 前端）的实战示例
• ✅ Skills 系统的工作原理——发现机制、frontmatter、按需加载
• ✅ AGENTS.md 与 opencode.json 的分工——各自负责什么
• ✅ 团队共享及跨项目协作的配置策略
• ✅ 从 Claude Code 无缝迁移的兼容方案

欢迎继续关注本系列的后续内容：

延伸阅读

• OpenCode 官方文档 - 规则[1]
• OpenCode 官方文档 - 代理技能[2]
• OpenCode 官方文档 - 代理[3]
• OpenCode 官方文档 - 配置[4]
• OpenCode GitHub 仓库[5]

现已介绍的工具链：OpenCode 规则文件与技能系统。若想进一步了解自定义命令或代理定制，请留意后续更新。如果你觉得本系列对你有帮助，欢迎分享给更多同事。

引用链接

[1] OpenCode 官方文档 - 规则: https://opencode.ai/docs/zh-cn/rules/ [2] OpenCode 官方文档 - 代理技能: https://opencode.ai/docs/zh-cn/skills/ [3] OpenCode 官方文档 - 代理: https://opencode.ai/docs/zh-cn/agents/ [4] OpenCode 官方文档 - 配置: https://opencode.ai/docs/zh-cn/config/ [5] OpenCode GitHub 仓库: https://github.com/opencode-ai/opencode