我的 OpenCode 使用心得：基于当前配置把博客写作做成稳定闭环
内容提要
作者将OpenCode配置为“少而稳”的写作助手，通过固定路径配置插件和技能，将写作流程固化到SKILL.md中，实现选题、生成、校验、落盘的稳定闭环。文章强调可追溯、可验证、可复现，推荐先聚焦高频任务，并验证配置有效性，最终提升写作效率与稳定性。
延伸解读
配置“少而稳”的核心逻辑
作者强调将OpenCode配置为“少而稳”，即先聚焦高频任务（如写博客），而不是一次性铺开多个技能。这种策略有助于减少配置复杂度，避免因技能过多导致行为不一致。通过将写作流程固化到SKILL.md中，作者将个人习惯转化为可执行规则，从而提升可复现性。这提示读者，在引入AI工具时，应优先解决最频繁、最痛的点，而非追求功能全面。
固定路径与验证机制的价值
作者在固定路径（如.opencode/package.json和.opencode/skills/）下管理配置，并在每次写作前运行检查命令，以排除环境漂移。这种做法确保了配置的可追溯性和可验证性，减少了“为什么这次效果不一样”的问题。对于依赖AI工具的用户，建立类似的配置检查和预期输出机制，有助于稳定产出质量，并降低后期维护成本。
能力扩展与行为规范的分离
作者将OpenCode的插件体系（扩展能力）与Skills（复用行为）分开，认为这能让配置更清晰，问题定位更快。插件负责提供功能，而技能负责定义写作规范。这种分离设计有助于用户理解不同组件的职责，并在遇到问题时快速定位是能力缺失还是规则不完善。对于希望深度定制AI工具的用户，这种架构思路值得借鉴。
方法的边界与适用条件
作者明确指出，这套方法并不自动保证观点正确，仍需事实核对；且产出质量依赖SKILL.md的质量。这意味着，将AI工具工程化并不能替代内容审核和知识积累。读者在采用类似方法时，应意识到工具只是辅助，核心仍在于人的判断和输入。同时，技能文件需要持续维护和优化，才能保持长期有效。
Q&A
如何将 OpenCode 配置为稳定的写作助手？
作者建议将配置最小化，并把写作流程固化到 SKILL.md 中。具体做法是：在 .opencode/package.json 中管理插件依赖，在 .opencode/skills/<name>/SKILL.md 中定义技能，然后通过固定路径和预期输出确保流程可复现。
OpenCode 的插件和技能有什么区别？
插件体系负责扩展能力，如本地插件目录、npm 插件和事件钩子；技能（Skills）负责复用行为，按需加载 SKILL.md 中的规则。作者认为将两者分开可以让配置更清晰，问题定位更快。
OpenCode 的 GitHub 仓库有多少 stars？
根据文章抓取日期（2026-02-25），anomalyco/opencode 仓库显示约 110k stars。
使用 OpenCode 写博客有哪些最佳实践？
作者推荐：1. 先把高频任务写成一个 skill；2. 在固定路径配置依赖和技能；3. 给关键命令提供预期输出；4. 为技术点补充来源（官方文档和 GitHub）；5. 每轮写作前运行配置检查命令。
OpenCode 写作闭环的收益和边界是什么？
收益：写作风格稳定、返工减少、复盘成本低。边界：不自动保证观点正确，需要事实核对；依赖技能质量，SKILL.md 写得空会影响产出。
如何验证 OpenCode 配置是否有效？
作者通过运行检查命令（如 cat .opencode/package.json 和 find .opencode/skills/write-blog）来确认配置完整，并参考官方文档和 GitHub 社区活跃度来验证。
