手头有一篇草稿，关于 Gentoo 上跑容器的，三十来行，写了个开头就丢在那了。最近想把它完善到能发布的程度，正好试试 opencode——第一次用，之前只是听说过。

第一轮：清理和修补

我把仓库地址丢给它，它自己 clone 下来，然后我告诉它这有个分支，文章在里边。

它读了文件，然后跟我说发现几个问题：URL 里有跟踪参数、有处笔误、原标题和内容不太对。我扫了一眼，确认，让它逐条改掉。opencode 各自搜了一下文件，逐条处理完，最后给出来四个备选标题。

这个环节大概五分钟，放在以前我自己打开编辑器改，差不多也是这个时间。差别在于我不需要离开终端去翻文件找位置。

第二轮：扩展内容

“加个 Docker 安装步骤”，我说。

它先跑去查本机的 Docker 是怎么装的——USE 标志、内核配置、daemon.json，全看了一遍，然后写了一整段。

“btrfs 那部分展开说一下”、”GPU 支持也要展开”。它又去查了一轮，补上了 LVM 存储布局、nvidia-container-toolkit 配置。

这个过程有意思的地方是，我只需要说”展开什么”，不用告诉它”怎么写”。它自己决定篇幅和详略，不合适再说。几个来回下来，文章从 30 行到了 170 行。

意外的环节：验证

文章写得差不多了，我跟 opencode 说：你去联网核实一下这些配置有没有问题。

我本来没想过做这个事。写技术文章最怕的就是贴了一堆配置，结果有错。它去查了 Gentoo 的官方 ebuild、NVIDIA 的文档、Docker 的存储驱动说明。

还真发现了东西：registry 的 REGISTRY_PROXY_TTL 在 registry:2 里用不了，必须用 registry:3。这个差异我在本机配置时都没注意到，因为本机用的就是 registry:3。它查了 GitHub issue 之后确认了版本兼容性。

这步是整轮协作里我觉得最值的地方。

发布

git push 之后 GitHub Actions 跑了构建，报错了。让 opencode 看了一下日志，是 Sass 版本和 Ruby 不兼容，跟文章内容无关。重试一次，过了。

几点感受

整个过程下来，最大的感觉是”可以更专注于想说什么，不用太纠结怎么写”。

以前写技术文章，花在查文档验证配置上的时间，不比动笔少。现在这部分可以交给工具去做——不是完全托管，但至少能快速定位问题。

当然，文章的走向、观点的取舍还是得自己来。opencode 不会说”这段写得不好，重来”，它等着你给指令。这一点跟 Copilot 做代码补全是一个道理：工具负责执行，方向由人把握。

至于这文章本身——也是用 opencode 写的，包括你现在读到的这一段。

本文由 opencode 辅助撰写

更正：初版写完后，作者发现三处事实偏差——自己是第一次使用 opencode 而非有使用经验；第一轮的三项问题由 opencode 主动发现而非作者提出；验证环节由作者要求而非 opencode 提议。这也反映出 AI 辅助写作的一个短板：生成的内容读起来通顺，但事实细节可能偏离真实情况。作者如果不仔细核对，这些错误自己很难发现。