最近重度使用opencode，做任务时，明明任务已经执行完了，但新开一个 Session 后，Atlas 又把之前的任务重新执行一遍。

原因分析

OpenCode 用 boulder.json 文件来跟踪任务进度，文件位置在 ~/.sisyphus/boulder.json。

{
  "active_plan": "/root/.sisyphus/plans/rsshub-installation.md",
  "completed_at": "2026-02-12T14:40:00.000Z",
  "final_status": "COMPLETED",
  "session_ids": ["ses_xxx", "ses_xxx"],
  "plan_name": "rsshub-installation"
}

问题出在两个方面：

1. boulder.json 指向错误的计划

• 虽然 n8n-docker-install.md 计划中所有任务都标记为 - [x] 完成
• 但 boulder.json 的 active_plan 指向了另一个已完成的计划 rsshub-installation
• 新 Session 找不到正确的计划

2. Session 连续性丢失

• 多个 Session ID 记录在 boulder 中
• 新 Session 不知道任务是否真的完成
• 每次都从头开始

解决方案

方案 1：清理 boulder 状态（新 Session 前执行）

# 删除 boulder.json（清除所有状态）
rm ~/.sisyphus/boulder.json

或者手动重置：

cat > ~/.sisyphus/boulder.json << 'EOF'
{
  "active_plan": "/root/.sisyphus/plans/正确的计划名.md",
  "final_status": "COMPLETED"
}
EOF

方案 2：在计划末尾明确标记结束

在 .md 计划文件末尾添加：

---

## 计划状态

**状态**: ✅ 已完成
**完成时间**: 2026-02-12
**验证方式**: 所有任务标记为 - [x]

**注意**: 此计划已完全执行，无需再次执行。

预防措施

1. 每次新 Session 前检查 boulder 状态

cat ~/.sisyphus/boulder.json

1. 明确告诉 Atlas 跳过已完成的任务

2. 不要手动修改 - [ ] 标记

文件位置参考

• Boulder 状态文件：~/.sisyphus/boulder.json
• 计划文件目录：~/.sisyphus/plans/
• 学习记录目录：~/.sisyphus/notepads/

总结

这是一个 OpenCode 的状态管理边界问题：

解决方案：删除 boulder.json 或手动重置状态即可。

快速修复

新开 Session 遇到任务被重复执行时，运行：

rm ~/.sisyphus/boulder.json

然后重新开始即可。

之前用 Feedly 订阅 RSS，但很多技术博客没有原生 RSS，而且被墙的网站也无法访问。于是决定自建一个 RSS 阅读器。

为什么选择 Miniflux

• 开源免费：MIT 许可证
• 轻量级：Go 语言开发，资源占用少
• 自托管：数据完全掌控在自己手中
• 支持 Fever API：可以搭配各种第三方客户端使用

环境要求

• Docker 已安装
• 已有 PostgreSQL 或使用内置数据库

安装步骤

1. 创建目录结构

mkdir -p /root/docker/miniflux
cd /root/docker/miniflux
mkdir -p data pgsql_data

2. 配置 docker-compose

version: '2.4'

services:
  miniflux:
    image: miniflux/miniflux:latest
    container_name: miniflux
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:changeme@miniflux-db/miniflux?sslmode=disable
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=changeme
      - LISTEN_ADDR=:8082
    volumes:
      - ./data:/var/lib/miniflux

  db:
    image: postgres:16
    container_name: miniflux-db
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=changeme
      - POSTGRES_DB=miniflux
    volumes:
      - ./pgsql_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      timeout: 5s
      retries: 5

3. 启动服务

docker-compose up -d

4. 验证状态

# 检查容器状态
docker ps | grep miniflux

# 测试 Web 访问
curl -s -o /dev/null -w "%{http_code}" http://localhost:8082
# 应返回 200

导入订阅源

我整理了一份可访问的技术博客订阅列表：

技术巨头

国内技术团队

中文独立博客

导入命令

# 批量导入 RSS 源
while read url; do
  curl -s -X POST \
    -u admin:changeme \
    -H "Content-Type: application/json" \
    -d "{\"feed_url\":\"$url\"}" \
    http://localhost:8082/v1/feeds
done < feeds.txt

使用效果

部署完成后，成功导入 10 个订阅源，包括：

• 技术巨头官方博客（Kubernetes、AWS、Azure、Red Hat）
• 国内一线技术团队博客（美团、有赞）
• 优质中文独立博客（阮一峰、云风、酷壳等）

Web 界面访问地址：http://你的服务器IP:8082

初始账户：admin / changeme，建议首次登录后立即修改密码。

数据备份

数据目录说明：

/root/docker/miniflux/
├── docker-compose.yml    # 配置文件
├── data/                 # Miniflux 应用数据
└── pgsql_data/          # PostgreSQL 数据库文件

定期备份 pgsql_data 目录即可完整保存所有订阅数据和文章缓存。

参考资料

• Miniflux 官方文档
• RSSHub 官方文档
• Kubernetes 官方博客

背景

在 WireGuard 虚拟网络环境下，我尝试 SSH 连接远程主机时，TCP 连接可以建立，但会话随即卡死。

使用 ssh -v 开启详细调试模式，发现日志停滞在密钥交换（Key Exchange）的最后一步：

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
...
debug1: kex: algorithm: curve25519-sha256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY  <-- 卡死在此处，随后超时

分析

MTU 黑洞 (MTU Black Hole)。

SSH 在密钥交换（KEX）阶段会发送较大的数据包。WireGuard 协议本身会增加头部开销（Overhead）。当 [SSH Payload + TCP/IP Headers + WireGuard Overhead] 的总长度超过物理链路路径上的最小 MTU（通常受限于 PPPoE 拨号或中间路由策略）时，数据包会被静默丢弃。

由于中间链路可能禁用了 ICMP，导致发送端无法收到 “Fragmentation Needed” 通知，从而造成连接“假死”。

解决方案

WireGuard 官方推荐将 MTU 设置为保守值 1280 以适配绝大多数网络环境。

最近在macOS上安装应用程序时，是否遇到过“已损坏，无法打开”的提示。经过一番搜索，这是macOS的安全机制在作祟。

一、问题背景

macOS包含一套名为“Gatekeeper”的安全系统，它会检查应用程序是否来自已知开发者，并确保软件未被篡改。当您从非App Store来源下载应用时，系统可能会阻止其运行，并显示“已损坏”的警告。

二、解决方案

1. 允许“任何来源”的应用程序运行

打开“终端”应用程序（可以在“应用程序”>“实用工具”中找到），输入以下命令并按回车：

sudo spctl --master-disable

根据提示输入您的管理员密码。然后打开“系统偏好设置”>“安全性与隐私”>“通用”，您会看到“允许从以下位置下载的应用程序”选项，现在可以选择“任何来源”了：

步骤2：移除应用的安全隔离属性

再次打开“终端”，输入以下命令（注意命令末尾有一个空格）：

sudo xattr -dr com.apple.quarantine 

不按回车，而是打开“访达”，找到无法打开的应用程序，将其拖拽到终端窗口中。此时终端会自动填充应用程序的完整路径，然后按回车执行命令并输入管理员密码。大概是这个样子

；

sudo xattr -dr com.apple.quarantine /Applications/MyApp.app

步骤3：双击打开应用程序

完成前两个步骤后，您现在可以正常双击打开应用程序了。

安全注意事项

1. 谨慎使用“任何来源”选项：这会降低系统的安全性，建议在使用完应用程序后通过以下命令恢复设置：

   sudo spctl --master-enable
   

2. 只从可信来源下载应用：即使解决了“已损坏”问题，也要确保应用程序来源可靠

为什么这个方法有效？

macOS使用com.apple.quarantine属性标记从互联网下载的文件，这个属性会告诉Gatekeeper在首次打开时检查应用程序。移除这个属性或完全禁用Gatekeeper可以绕过这些检查。

结论

这个3步方案适用于大多数从非官方渠道下载的macOS应用程序。

最近opencode很火，我也在 macOS/Linux 上装了。这篇文章记录一下安装和使用过程。

官方说明

OpenCode is an open source agent that helps you write code in your terminal, IDE, or desktop.

• 自动识别编程语言。
• 多个对话同时进行。
• 分享编程过程。
• 支持各种AI模型。
• 什么编辑器，都能用OpenCode。

安装

最简单的方式是使用Homebrew：

brew install anomalyco/tap/opencode

Linux下：

curl -fsSL https://opencode.ai/install | bash

启动OpenCode并配置模型：

cd ~/Workspace  # 进入你的工作目录
opencode        # 启动OpenCode

在TUI界面中，输入 /connect 配置模型提供商：

• 新手推荐: OpenCode Zen（经过验证的模型）
• 进阶选择: Claude Sonnet 4.5（编程能力强）

首次使用，运行 /init 让OpenCode分析你的项目结构。

安装好之后让 opencode 帮忙安装 oh my opencode：

请安装ohmyopencode：bunx oh-my-opencode install

基础操作

掌握这几个核心命令就能开始使用：

/help          # 查看所有命令
@文件名         # 引用文件内容
!命令           # 执行shell命令
/undo          # 撤销操作
/redo          # 重做操作
Tab键          # 切换Plan/Build模式
Esc            # 退出、打断当前操作

初上手

先拿我的blog项目进行练手：

请分析我这个blog项目的结构和功能，然后告诉我可以用OpenCode做什么改进?

其他类似的上手问答工作都可以试试：

1. 请问你会做些什么
2. 检查macOS版本
3. 显示内存使用情况
4. 列出Homebrew安装的包
5. 检查磁盘空间

oh my opencode

模型配置说明

• Sisyphus (西西弗斯): 默认的 Orchestrator (协调者)。他是“全能管家”，负责拆解任务、维护 TODO 列表，脏活累活他先接，搞不定再摇人。
• Atlas (阿特拉斯): Executor (执行者)。专注于执行 Prometheus 制定好的计划，或者处理具体的实施工作，不负责高层决策。
• Hephaestus (赫淮斯托斯): The Craftsman (工匠)。这是一个“深度编码”模式 (类似 Deep Mode)，不依赖 Fallback 链，专注于一次性写出高质量、经过深思熟虑的代码。
• Prometheus (普罗米修斯): Planner (规划者)。只动口不动手，负责生成架构文档和实施计划，绝对不写具体代码。

OpenCode 云端模型：

在输入框输入 /models 即可切换models

添加本地 Ollama 模型

OpenCode 原生支持连接本地 Ollama 实例，无需 API Key。

安装 Ollama

# 启动服务（后台运行）
ollama serve

# 拉取代码专用模型
ollama pull qwen3-coder-next:q4_K_M

⚠️ 重要提示：截至 2026.2.4 macOS 正式版 Ollama不支持 qwen3-coder-next 等最新模型。 请从 GitHub 下载最新的 RC 版本：

1. 访问 https://github.com/ollama/ollama/releases
2. 下载 macOS RC 版本的 dmg 文件（不是 tar.gz！）
3. 打开 dmg 文件，将 Ollama 拖到应用程序文件夹
4. 启动 Ollama（Launchbar 或 Spotlight 搜索 “Ollama”）

先在 OpenCode 中配置 Ollama

vi ~/.config/opencode/opencode.json

{
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama(local)",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen3-coder-next:q4_K_M": {
          "name": "qwen3-coder-next:q4_K_M"
        }
      }
    }
  }
}

再在 Oh My OpenCode 中使用 Ollama

vi ~/.config/opencode/oh-my-opencode.json

{
  "agents": {
    "hephaestus": {
      "model": "ollama/qwen3-coder-next:q4_K_M"
    },
    "oracle": {
      "model": "ollama/qwen3-coder-next:q4_K_M"
    },
    "prometheus": {
      "model": "ollama/qwen3-coder-next:q4_K_M"
    },
    "sisyphus": {
      "model": "ollama/qwen3-coder-next:q4_K_M"
    }
  },
  "categories": {
    "visual-engineering": {
      "model": "opencode/minimax-m2.1-free"
    },
    "ultrabrain": {
      "model": "opencode/minimax-m2.1-free"
    },
    "quick": {
      "model": "opencode/minimax-m2.1-free"
    }
  }
}

我的常用命令

删除所有 Task

如果需要清除所有 Sisyphus 任务，运行以下命令：

# 查看 Sisyphus 状态
ls ~/.sisyphus/

# 删除 boulder.json（清除任务状态）
rm ~/.sisyphus/boulder.json

# 删除所有计划文件
rm ~/.sisyphus/plans/*.md

# 删除 notepads
rm -rf ~/.sisyphus/notepads/*

/handoff

长对话会产生：

• 大量已完成的思考过程
• 过时的中间草稿
• 历史决策和当前需求混杂
• 上下文膨胀影响响应质量

使用 /handoff 命令可以 创建当前工作上下文的精简摘要，用于下一会话， 这会生成一个包含以下内容的摘要：

• 当前项目状态
• 未完成的工作
• 关键决策和上下文
• 建议的下一会话起点

常用命令速查

🔥 高频使用（日常必用）

基础操作

• opencode - 启动 TUI 界面
• opencode . - 启动当前目录的 TUI
• @filename - 引用文件（模糊搜索当前目录）
• @packages/functions/src/index.ts - 精确引用文件路径
• !ls -la - 执行 shell 命令，结果加入对话
• !npm run build - 运行构建命令

必备 Slash 命令

• /help - 显示帮助信息
• /init - 初始化项目/创建 AGENTS.md
• /undo - 撤销上一步修改
• /redo - 重做操作
• /share - 分享当前会话
• /models - 切换/查看可用模型
• /connect - 配置 API keys

智能体切换

• Tab - 切换 Build/Plan 模式

⚡ 中频使用（项目开发常用）

CLI 命令

• opencode -c / opencode --continue - 继续上次会话
• opencode -s session_id - 继续指定会话
• opencode run "message" - 非交互式运行
• opencode serve - 启动 headless HTTP 服务器
• opencode web - 打开 Web 界面
• opencode agent [command] - 管理智能体

内置工具

• read - 读取文件内容
• write - 创建/覆盖文件
• edit - 编辑文件
• grep - 搜索文件内容
• glob - 按模式查找文件
• bash - 执行 shell 命令
• ast_grep_search - AST 模式搜索
• ast_grep_replace - AST 模式替换
• lsp_symbols - 获取符号列表
• lsp_diagnostics - 获取诊断信息
• lsp_rename - 重命名符号

模式切换

• build - 默认模式（全工具权限）
• plan - 规划模式（只读，禁止文件操作）

🔧 低频使用（高级功能）

Oh My OpenCode 专用

11个专业智能体

• @sisyphus - 默认编排器（复杂任务）
• @hephaestus - 自主深度工作者
• @atlas - 主编排钩子
• @prometheus - 规划智能体
• @metis - 计划分析验证
• @momus - 工作计划审查
• @oracle - 战略顾问
• @librarian - 多仓库研究
• @explore - 快速上下文搜索

高级命令

• ulw / ultrawork - 超work模式（复杂任务自动理解上下文）
• /refactor - 智能重构
• /start-work - 从 Prometheus 计划开始执行
• /cancel-ralph - 取消 Ralph 循环
• /stop-continuation - 停止所有延续机制
• /handoff - 创建上下文摘要

32+ 生命周期钩子

• pre-exec, post-exec, pre-task, post-task
• on-error, on-success, on-timeout
• background-compaction, context-compaction
• 等等…

MCP 管理

• opencode mcp add [server] - 添加 MCP 服务器
• opencode mcp remove [server] - 移除 MCP 服务器
• opencode mcp list - 列出已安装的 MCP

自定义命令

• /custom-command - 自定义命令（放在 .opencode/commands/ 目录）

服务器/开发

• opencode attach - 附加到运行中的服务器
• opencode --fork - 继续时fork会话
• opencode --model provider/model - 指定模型
• opencode --agent agent_name - 指定智能体

最近重置了 Mac 系统，需要重新配置 Ruby 和 Jekyll 环境来运行我的静态博客。相比于直接使用系统 Ruby，这次选择了更优雅的 rbenv 进行版本管理。整个过程遇到不少“坑”，特此记录以备忘，希望这篇记录也能帮你绕开这些坑。

核心思路：为何使用 rbenv？

rbenv 将 Ruby 环境和所有 Gem 安装在你的用户目录下，实现完全的隔离管理，是当前 Ruby 社区推荐的最佳实践。

第一步：安装和基础配置

# 1. 通过 Homebrew 安装 rbenv 和 ruby-build（用来编译安装 Ruby）
brew install rbenv ruby-build

# 2. 初始化 rbenv，并按照提示把下面这行加到 ~/.zshrc 里
rbenv init
echo 'eval "$(rbenv init - zsh)"' >> ~/.zshrc
source ~/.zshrc # 让配置生效

# 3. 安装一个稳定的 Ruby 版本（这里选了 3.4.4，因为我系统显示最新的就是3.4.4）
rbenv install --list-all
rbenv install 3.4.4
rbenv global 3.4.4 # 设为默认版本
rbenv rehash # 重要：重建命令链接

# 4. 验证一下，确保 ruby 和 gem 命令指向的是 rbenv 安装的版本
which ruby # 应该显示 ~/.rbenv/shims/ruby
which gem  # 应该显示 ~/.rbenv/shims/gem
ruby -v    # 应该显示 3.4.4

# 5. 现在可以安全安装 Jekyll 了
gem install jekyll

第二步：在博客项目中启动，问题接踵而至

本以为万事大吉，在博客目录下输入 jekyll s，结果错误连环出现。

第一个坑：项目依赖 vs 全局安装

直接报错，说项目 Gemfile 里锁定的 Jekyll 版本（4.3.2）和我刚全局安装的版本（4.4.1）对不上。

解决：在项目目录下，让 Bundler 根据 Gemfile 重新安装所有依赖。

bundle install

第二个坑：架构冲突，编译失败

运行 bundle install 时，在编译 nokogiri 时卡住了，报错提示在找 x86_64 的库，但我的是 ARM 芯片（Apple Silicon）。

ld: warning: ignoring file '/opt/homebrew/Cellar/xz/5.8.1/lib/liblzma.dylib': found architecture 'arm64', required architecture 'x86_64'

原因：我的机器上好像混用了两个 Homebrew（Intel 和 ARM 版）。默认的 brew 命令指向了 Intel 版本。

解决：

1. 先检查当前 brew 路径：which brew。我的是 /usr/local/bin/brew（Intel版）。
2. 切换回 ARM 版的 Homebrew：

   eval $(/opt/homebrew/bin/brew shellenv)
   

3. 之后再重新 bundle install，编译就通过了。

第三个坑：public_suffix 版本激活冲突

再次尝试 jekyll s，又出现新错误：全局的 public_suffix (7.0.2) 和项目需要的 (5.0.4) 冲突。

解决：改用 bundle exec 命令，严格使用项目 Gemfile.lock 里锁定的版本。

bundle exec jekyll s

第四个坑：Ruby 3.4 的“惊喜”——标准库缺失

以为终于行了，结果连续报错：

• cannot load such file -- csv
• cannot load such file -- base64
• cannot load such file -- bigdecimal

原因：Ruby 3.4 开始，像 csv、base64、bigdecimal、zlib、openssl 这些以前默认就有的标准库，现在需要单独作为 gem 安装了。而我的博客用的 Jekyll 版本比较旧，还依赖它们。

解决：在项目目录下，把这些缺失的库一次性补上。

bundle add csv base64 webrick bigdecimal zlib openssl

最后，终于跑起来了！

完成以上所有步骤后，再次运行：

bundle exec jekyll s

熟悉的启动信息终于出现了，浏览器打开 http://localhost:4000，博客本地预览恢复正常。

几点心得

1. rbenv 不错：虽然一开始配置多点步骤，但彻底告别了权限混乱，值。
2. bundle exec 是护身符：在项目目录下运行任何 gem 相关的命令，都习惯性加上它，能避免很多奇怪的版本冲突。
3. 注意 Homebrew 架构：尤其是换过芯片的 Mac，确保用的是对应版本的 brew，能省去很多编译麻烦。
4. Ruby 3.4+ 的用户：如果跑老项目，记得缺啥标准库就用 bundle add 装啥，csv、base64、bigdecimal、zlib、openssl 这几个是常客。

最近在使用 Jekyll 开发博客时，遇到了一个典型问题：Gemfile 和 Gemfile.lock 文件 在本地和生产环境需要不同的配置。

• 🖥️ 本地环境：需要特定版本的 jekyll 插件
• ☁️ 云端环境：需要兼容老版本的依赖

解决方案：git update-index --assume-unchanged

Git 提供了一个优雅的解决方案：assume-unchanged 标志。

什么是 assume-unchanged？

assume-unchanged 是 Git 的一个内部标志，它告诉 Git：

“假设这个文件没有变化，不要检查它的修改状态，也不要让我提交它。”

如何使用？

# 从暂存区移除Gemfile文件
git restore --staged ../Gemfile ../Gemfile.lock

# 告诉 Git 忽略特定文件的本地修改
git update-index --assume-unchanged Gemfile
git update-index --assume-unchanged Gemfile.lock

# 查看哪些文件被标记为 assume-unchanged
git ls-files -v | grep '^h'

# 提交其他文件
git commit -m "更新博客文章，忽略Gemfile本地修改"

# 查看状态确认
git status


# 需要更新配置文件时
# 先恢复跟踪（撤销忽略）
git update-index --no-assume-unchanged Gemfile
git update-index --no-assume-unchanged Gemfile.lock

# 修改并提交
git add Gemfile
git commit -m "更新Gemfile依赖"

# 重新标记为忽略
git update-index --assume-unchanged Gemfile
git update-index --assume-unchanged Gemfile.lock

与 .gitignore 的区别

很多人会混淆 assume-unchanged 和 .gitignore，它们有本质区别：

与 skip-worktree 的区别

Git 还有一个类似的标志：skip-worktree。

# skip-worktree 的用法
git update-index --skip-worktree Gemfile

# 查看区别
git ls-files -v | grep '^S'  # skip-worktree 文件
git ls-files -v | grep '^h'  # assume-unchanged 文件

主要区别：

• assume-unchanged：性能优化，告诉Git文件不太可能改变
• skip-worktree：功能标志，明确表示”不要更新我的工作树”

对于配置文件管理，skip-worktree 是更安全的选择，因为它能防止 Git 的各种操作覆盖你的本地文件。

注意事项和陷阱

1. 分支切换问题： 当你在标记了 assume-unchanged 的分支之间切换时，如果文件有冲突，Git 可能会报错。

2. 团队协作：

   # 假设团队成员更新了仓库中的 Gemfile
   git pull
   # 由于本地文件被标记，更新可能不会应用到你的工作副本
   

3. 忘记恢复：

   # 创建一个脚本帮助管理
   cat > git-ignored-files.sh << 'EOF'
   #!/bin/bash
   echo "当前被忽略的文件:"
   git ls-files -v | grep -E "^[hs]"
   EOF
   chmod +x git-ignored-files.sh
   

更好的替代方案

对于配置文件管理，还有更健壮的方案：

1. 使用模板文件：

   # 仓库中保存模板
   _config.example.yml
   Gemfile.example
      
   # 本地复制并重命名
   cp _config.example.yml _config.yml
   cp Gemfile.example Gemfile
   

2. 环境变量：

   # _config.yml
   url: <%= ENV['JEKYLL_SITE_URL'] || 'http://localhost:4000' %>
   

3. 多环境配置：

   # 使用不同的配置文件
   jekyll build --config _config.yml,_config.local.yml
   

总结

git update-index --assume-unchanged 是一个强大的工具，特别适合管理那些需要在版本控制中保留，但又不想提交本地修改的文件。

最后，如果你经常忘记哪些文件被标记了，可以在 .gitconfig 中添加别名：

[alias]
    ignored = !git ls-files -v | grep \"^[hs]\"
    hide = update-index --assume-unchanged
    unhide = update-index --no-assume-unchanged

然后使用更简洁的命令：

git ignored      # 查看被忽略的文件
git hide Gemfile # 隐藏文件
git unhide Gemfile # 取消隐藏