Webnovel Writer 未来如何跑在 Gemini CLI 和 Codex 上多宿主适配 Spec 完整解读【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writerWebnovel Writer是一套基于 Claude Code 的长篇网文 AI 创作插件专治 AI 写到几百章后的「遗忘」和「幻觉」。它最新的多宿主适配 Spec 给出了一个答案不重写业务逻辑而是让 Gemini CLI、Codex 等宿主通过轻量 adapter 消费同一套写作能力。这篇文章带你读完这份 Spec 的核心设计 为什么要做多宿主适配目前 Webnovel Writer 是 Claude Code 插件8 个/webnovel-*命令、4 个 Agent、hooks 守卫、Python 运行时全都挂在 Claude Code 的插件形态上。但真正干活的是底层的 Python runtime 和 Story System——它们本身并不依赖 Claude Code。这就引出一个问题同一套写作能力为什么只能在一个宿主上使用多宿主适配的目标一句话概括以现有 Python runtime 和 Story System 为唯一业务核心向多个宿主生成轻量 adapter 的长篇写作插件。当前基线这套系统现在长什么样Spec 先盘点了 v6.1.0 的真实基线见 multi-agent-adaptation-spec-2026-06-05.md组成现状多宿主适配中的地位8 个 Skillinit / plan / write / review / query / learn / dashboard / doctor全部保留write是最高优先级主流程4 个 Agentcontext / reviewer / data / deconstruction引入webnovel-前缀规范名旧名保留兼容hooks会话开始报短状态 危险写入兜底阻断保持现状其他宿主可选Runtime CLI统一入口 scripts/webnovel.py所有宿主共享绝不复制hooks 是轻量守卫而非业务流程会话开始时运行短状态检查拦截对.story-system/commits/、state.json等关键文件的直接写入配置见 hooks/hooks.json。已有两类验证能力——包校验器 validate_plugin_package.py 和行为 evalfast.json 覆盖 8 个 Skill 的行为契约——多宿主适配是扩展它们而不是另造一套检查。三大设计原则不破坏、不复制、不猜测1. Runtime 是唯一业务真源所有能修改项目事实的动作必须走同一条链路Skill / 宿主命令 ↓ webnovel.py统一 CLI ↓ data_modules业务逻辑 ↓ .story-system commit事实入账 ↓ projection 只读视图state / index / summary / memory任何宿主 adapter 都不允许直接写.story-system/commits/或.webnovel/*视图文件。这是防止「换个宿主就出现另一套状态」的根本手段。2. Claude Code 是第一支持宿主.claude-plugin/plugin.json位置不变skills/、agents/、hooks/结构不动${CLAUDE_PLUGIN_ROOT}变量继续用。现有用户的安装和使用体验保持零变化。3. Adapter 要薄每个宿主的 adapter 只负责 6 件事manifest 元数据、工具名映射、Agent 配置转换、命令暴露方式、hook 能力降级、smoke 测试启动。它不负责改写写作流程、解释 Story System、校验章节产物、执行投影、维护项目状态。业务逻辑永远只有一份。Gemini CLI 和 Codex 将如何接入Spec 规划了adapters/目录结构adapters/ ├── registry.json # 宿主注册表tier / 能力 / smoke 命令 ├── claude/ ├── codex/ ├── gemini/ ├── cursor/ ├── opencode/ └── copilot/三个关键机制值得注意 support.md不相信手写能力矩阵外部宿主的能力变化很快「Codex 现在支持什么」不能靠口头事实。每个宿主 adapter 必须带一份support.md记录官方文档核验日期、支持/不支持的能力、以及本项目采用的降级策略。⚙️ 生成器 drift check新增的generate_host_artifacts.py从 Skill / Agent / hook 源文件生成各宿主的 manifest 和 agent 配置--check模式可检测生成产物是否与源文件漂移。 降级模式不支持就不假装支持如果宿主不支持 subagent就进入 compatibility mode主 agent 按同一份任务书和产物 schema 执行并明确声明「未调用 subagent」仍然必须通过write-gate和行为 eval 校验。不允许声称调用了不存在的能力。无论哪个宿主统一的状态入口都是三个命令project-status机器可读短状态doctor安装后第一检查回答「目录全不全、DB 好不好、RAG 配没配」write-gate写前 / 提交前 / 提交后三道关卡七步迁移路线图从 Phase 0 到 Phase 6Spec 采用渐进迁移避免一次性大改破坏现有用户阶段目标关键动作Phase 0锁定现状文档与主干对齐列出 8 Skill / hooks / 状态命令Phase 1注册表落地新增adapters/registry.json和各宿主support.mdPhase 2Agent 规范名webnovel-*前缀 旧名兼容映射Phase 3Skill 瘦身跨宿主工具映射下沉到 referencesPhase 4生成器上线generate_host_artifacts.py CI drift checkPhase 5跨宿主验收每个宿主 discover / status / doctor smoke至少一个非 Claude 宿主跑通webnovel-write兼容模式Phase 6发布治理README 与 release note 明确每个宿主的支持等级对普通用户意味着什么如果你是 Claude Code 用户什么都不用改。这条路线的第一原则就是不破坏现有体验。如果你在等 Gemini CLI / Codex 版最终形态不是「再装一个看起来差不多的插件」而是同一套命令语义init / plan / write / review / doctor在不同宿主里的表达。支持到什么程度会写进 release note不会让你猜。如果你是维护者关注点从「某个宿主能不能用」变成了可验证的问题——support.md有没有核验日期、smoke 命令能不能跑、drift check 过不过。总结这份多宿主适配 Spec 的精髓不是「再写一套插件」而是四件事保住基线v6.1.0 的 runtime 是地基不动 Story System 主链一级宿主Claude Code 继续作为第一支持宿主稳定演进薄 adapter用注册表 生成器把同一套能力暴露给 Gemini CLI、Codex 等新宿主可验证doctor、project-status、write-gate、projection log 和行为 eval 共同证明「它真的能用」。这样扩展新宿主时项目不会被重新打散用户也不会迷路在多个「看起来相似、实际语义不同」的入口里。想读完整设计可以直接看原文docs/architecture/multi-agent-adaptation-spec-2026-06-05.md更多文档入口见 docs/README.md。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考