作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/260225170548/
相关话题：https://www.cnsre.cn/tags/opencode/
版权声明: 如需转载，请联系作者授权

我最近一段时间把 OpenCode 当成主力写作助手在用。最大的变化不是“写得更快”，而是“写作流程更稳”：选题、生成、校验、落盘这几步可以连续跑通，不再靠临场发挥。

这篇文章按我当前仓库里的真实配置来写，重点是个人心得，不是泛泛入门。

1. 问题背景：为什么我要把 OpenCode 配置成“少而稳”

我之前用 AI 工具写技术博客，常见问题有三个：

• 输出看起来完整，但可复现性差；
• 文章结构每次不同，后期维护很累；
• 对话越长越容易跑偏，最后返工。

所以我的思路是：先把 OpenCode 配置压到最小，再把写作流程固化到 SKILL.md，把“个人习惯”变成“可执行规则”。

2. 安装与配置：我当前仓库里的真实状态

根据官方插件文档，OpenCode 支持在配置目录使用 package.json 管理插件依赖，并在启动时通过 Bun 安装依赖。

1
2
3
4
5
6
7
8
9

// 文件路径: .opencode/package.json
// 来源: 本地仓库配置
// 版本: 2026-02-25

{
  "dependencies": {
    "@opencode-ai/plugin": "1.2.13"
  }
}

根据官方 Skills 文档，技能文件放在 .opencode/skills/<name>/SKILL.md 可被自动发现。我在项目里落地的技能元数据如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 文件路径: .opencode/skills/write-blog/skill.json
// 来源: 本地仓库配置
// 版本: write-blog v2.0.0

{
  "name": "write-blog",
  "version": "2.0.0",
  "description": "Generate technical blog posts for SRE/Kubernetes/DevOps topics",
  "type": "skill",
  "entry": "SKILL.md",
  "category": "writing",
  "tags": ["blog", "technical", "sre", "devops"],
  "author": "Wenlong",
  "license": "MIT"
}

我现在的重点不是多装插件，而是先把一个高频场景（写博客）跑顺。这个策略对我非常有效。

3. 代码示例：我的写作闭环是怎么落地的

我在 write-blog skill 里固定了一个原则：

每个信息点都可追溯、可验证、可复现

基于这个原则，我每次写文都按同一套路执行：

1. 先确认当前仓库配置是否完整；
2. 再根据技能模板生成文章结构；
3. 最后做命令验证和来源补全。

下面是我实际在本仓库执行的检查命令。

1
2
3
4
5
6
7

# 文件路径: 项目根目录
# 来源: 本地仓库验证命令
# 版本: 2026-02-25

cat .opencode/package.json
cat .opencode/skills/write-blog/skill.json
find .opencode/skills/write-blog -maxdepth 2 -type f | sort

预期输出:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "dependencies": {
    "@opencode-ai/plugin": "1.2.13"
  }
}
{
  "name": "write-blog",
  "version": "2.0.0",
  ...
}
.opencode/skills/write-blog/SKILL.md
.opencode/skills/write-blog/references/writing-style.md
.opencode/skills/write-blog/skill.json
.opencode/skills/write-blog/write-blog.skill

这个动作很简单，但能避免 80% 的“为什么这次效果不一样”问题。

4. 验证测试：我怎么判断这套配置确实有效

4.1 官方能力验证

根据官方文档，OpenCode 的插件能力和技能能力在我当前方案里分别承担不同职责：

• 插件体系负责“扩展能力”（本地插件目录、npm 插件、事件钩子）；
• Skills 负责“复用行为”（按需加载 SKILL.md 规则）。

我的实际体会是：把“能力扩展”和“写作规范”分开，配置会更清楚，问题定位也更快。

4.2 社区活跃度验证

根据 GitHub 仓库页面（抓取日期：2026-02-25），anomalyco/opencode 已显示约 110k stars。这个规模说明生态和实践样本都比较丰富，踩坑时更容易找到可参考案例。

5. 最佳实践：我个人最推荐的 5 条

1. 先把高频任务写成一个 skill，不要一上来铺太多技能。
2. 在具体路径配置：依赖放 .opencode/package.json，技能放 .opencode/skills/<name>/SKILL.md。
3. 文章里每个关键命令都给“预期输出”，不要只贴命令。
4. 每个技术点都补来源，至少官方文档 + GitHub 两类。
5. 每轮写作前先跑一次配置检查命令，先排除环境漂移。

6. 我的真实收益和边界

收益

• 写作风格稳定了，文章结构一致；
• 返工变少，发布节奏可控；
• 后续复盘成本低，因为来源和验证都在文内。

边界

• 这套方法并不会自动保证“观点正确”，还是要做事实核对；
• 依赖技能质量，如果 SKILL.md 写得空，会直接影响产出质量。

7. 总结

我现在对 OpenCode 的定位是：它不是只会“聊天”，而是可以被工程化的写作执行器。

对我来说，真正关键的是三件事：

• 在固定路径配置；
• 用 skill 固化流程；
• 用命令和来源做验证。

只要这三步稳住，OpenCode 在博客写作场景里就能长期稳定产出。

参考资料

本文验证的信息来源：

1. 官方文档

   • OpenCode Plugins 文档
   • OpenCode Agent Skills 文档
   • OpenCode Ecosystem 文档

2. GitHub 源码与仓库

   • anomalyco/opencode

3. 本地配置（本文核心依据）

   • .opencode/package.json
   • .opencode/skills/write-blog/SKILL.md
   • .opencode/skills/write-blog/skill.json
   • .opencode/skills/write-blog/references/writing-style.md

4. 社区资源

   • opencode.cafe

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/260225170548/
相关话题：https://www.cnsre.cn/tags/opencode/
版权声明: 如需转载，请联系作者授权