webnovel-writer 多宿主与多智能体适配以 Runtime 为唯一业务核心的薄 Adapter 演进设计【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer本文基于 docs/architecture/multi-agent-adaptation-spec-2026-06-05.md 展开完整解读 webnovel-writer 从「Claude Code 单宿主插件」演进为「可验证、可生成、可降级的多宿主写作插件」的规格设计包括当前 v6.1.0 运行时基线的完整盘点8 个 Skill、4 个 Agent、统一 Runtime CLI、hooks 与两类验证能力、以scripts/webnovel.py为唯一业务真源的目标架构、adapter registry 与生成器的设计、逐 Phase 的迁移计划与验收清单。读完后你将掌握一套把同一套写作能力暴露给 Codex、Cursor、Gemini CLI、OpenCode、GitHub Copilot CLI 等多个宿主、且能力声明可被 smoke 测试验证的工程方法。需要说明的适用前提该 spec 以master分支 v6.1.0 为基线撰写当前仓库的 plugin.json 版本已演进到 6.2.1但 spec 描述的插件结构、hooks、Runtime CLI 与验证体系在当前主干上仍然成立下文会指出关键差异。1. 背景为什么需要多宿主适配以及基线修正spec 的出发点很明确webnovel-writer 不应该永远被 Claude Code 的表达方式绑定。它已经具备完整的写作运行时、Story System、RAG、Dashboard、Agent 分工和发布校验具备向多个宿主适配的条件。但 spec 同时指出先前 PR #110 的原始 spec 使用了过期基线存在四处失真只列出 7 个 Skill漏掉/webnovel-doctor把 hooks 描述为「当前未形成 bootstrap」而当前主干已经有 hooks.json、session_start.py 和 guard_runtime_write.py没有把project-status、doctor、write-gate、projections retry/replay、.webnovel/projection_log.jsonl纳入最终形态新增文档放在docs/superpowers/specs/但superpowers已归档到docs/archive/superpowers/活跃架构 spec 应进入docs/architecture/。因此该 spec 以当前运行时为基线重新定义多宿主适配方案。这一点也体现在当前仓库的 docs/README.md 文档索引中该 spec 与plugin-runtime-hardening-spec等并列收录在架构分区下。2. 当前真实基线8 个 Skill、4 个 Agent、统一 Runtime 与 hooks2.1 Claude Code 插件结构当前插件根为webnovel-writer/目录符合官方plugin-dev对 Claude Code 插件结构的要求webnovel-writer/ ├── .claude-plugin/ │ └── plugin.json ├── agents/ │ ├── context-agent.md │ ├──>{ id: skill_write_contract, type: skill_contract, skill: webnovel-write, required: [ write-gate --chapter {chapter_num} --stage prewrite, write-gate --chapter {chapter_num} --stage precommit, write-gate --chapter {chapter_num} --stage postcommit, projections retry --chapter {chapter_num} ], ordered: [ [write-gate --chapter {chapter_num} --stage precommit, chapter-commit], [chapter-commit, write-gate --chapter {chapter_num} --stage postcommit] ] }也就是说「先 precommit、再 commit、后 postcommit」的硬顺序不是自然语言约定而是被 run_behavior_evals.py 执行的机器可检契约。2.3 当前 4 个 Agent 及目标规范名当前文件当前职责目标规范名context-agent.md写前上下文与任务书组装webnovel-context-agentreviewer.md多维审查与 blocking issue 输出webnovel-reviewerdata-agent.md提取 commit artifacts不直接写 projectionwebnovel-data-agentdeconstruction-agent.md拆解参考书和结构学习webnovel-deconstruction-agent从源码结构看四个 agent 的 frontmatter 均包含name、description、tools如Read, Grep, Bash、model: inherit和color字段与官方插件 agent 格式一致。spec 明确要求当前文件名不能直接删除或重命名因为现有 Skill 文案和用户习惯可能仍引用旧名目标规范名必须通过兼容迁移引入详见第 9 节。2.4 当前 Runtime CLI所有确定性动作统一从 scripts/webnovel.py 进入。该脚本本身极薄把scripts/目录加入sys.path后转发到data_modules.webnovel这样在项目级或用户级~/.claude安装时都能被调用。多宿主适配必须复用这些 runtime 命令不为每个宿主重写一套业务逻辑。spec 列出的关键命令命令作用preflight快速环境与项目根检查project-status机器可读短状态、phase、下一步doctor阶段感知项目体检与修复建议write-gate写前、提交前、提交后三个自然边界校验story-systemStory System 合同与运行时数据chapter-commit章节事实提交驱动 projectionprojections retry/replay基于已有 commit 补跑或重放投影status旧宏观创作健康报告保持原语义对照 data_modules/webnovel.py 中的 argparse 定义这些子命令全部真实存在且每个子命令都是转发到独立的业务模块cmd_project_status、cmd_doctor、cmd_write_gate、cmd_projections、cmd_status等projections下还有retry与replay两个 action。当前版本还额外包含 spec 基线之后加入的user-report、run-ledger、run-log、use等子命令进一步印证了「Runtime 是唯一业务真源」这一原则的落地方式。2.5 当前 Hook当前已经存在 Claude Code 插件级 hooks且 hooks.json 使用官方要求的 wrapper 格式——外层包含description与hooks两个键SessionStartmatcher*运行 session_start.py给新会话提供短状态PreToolUsematcherWrite|Edit|MultiEdit与Bash运行 guard_runtime_write.py对直接写危险路径做兜底阻断。从源码看session_start.py只调用project-status --format summary输出被裁剪到最多 8 行 / 1000 字符4 秒超时任何异常都静默返回 0——保证 hook 永远不会拖慢或破坏会话启动。guard_runtime_write.py则维护一份受保护路径清单PROTECTED_SUFFIXES ( .story-system/commits/, .webnovel/index.db, .webnovel/vectors.db, .webnovel/memory_scratchpad.json, .webnovel/projection_log.jsonl, )当检测到 Bash 命令绕过 runtime 直写这些文件且命令中不含webnovel.pychapter-commit/projections retry/projections replay等合法标记时hook 向 stderr 输出{hookSpecificOutput: {permissionDecision: deny}, ...}并以退出码 2 拒绝操作。源码注释还特别说明.webnovel/state.json被有意排除在保护清单之外因为审计修复经常需要它无法表达的批量修改且state.json自身有备份 重建路径issue #113。spec 对此的定性是hook 是轻量守卫不是业务状态机。它只做状态提示和危险写入兜底不允许自动写 commit、自动改正文/设定、自动安装依赖、启动长驻服务或写入章节流程状态。2.6 当前验证能力当前已有两类基础验证validate_plugin_package.py按官方plugin-dev思路检查 manifest、Skill / Agent frontmatter、hooks wrapper、README 版本、路径可移植性。从源码看它带 schema 版本webnovel-plugin-package-validator/v1并用正则LOCAL_ABSOLUTE_RE检测生成物中是否混入本机绝对路径/Users/...、/home/...、盘符路径与 spec 后续 drift check「生成产物是否含本机绝对路径」的检查项一脉相承run_behavior_evals.py evals/fixtures/behavior/fast.json检查 8 个 Skill 的关键行为契约、Agent 边界、commit/projection 顺序、Dashboard 只读语义。spec 的结论是多宿主适配必须扩展这两类验证而不是新造一套互不相干的检查。3. 目标与非目标3.1 一句话目标把 Webnovel Writer 从「Claude Code 单宿主插件」升级为以现有 Python runtime 和 Story System 为唯一业务核心向多个宿主生成轻量 adapter 的长篇写作插件。具体目标六条保留 Claude Code 现有安装、Skill、Agent、hook 和 CLI 体验让 Codex、Cursor、Gemini CLI、OpenCode、GitHub Copilot CLI 等宿主可以通过 adapter 消费同一套写作能力所有宿主都复用scripts/webnovel.py和data_modules不复制 Story System、commit、projection、doctor、gate 逻辑每个宿主的支持状态必须可验证有 manifest 校验、smoke 测试和行为 eval当宿主不支持 subagent 或 hook 时有明确降级模式不假装已经调用了不存在的能力所有新增插件组件继续符合官方plugin-dev的结构、frontmatter、hooks、路径和验证要求。3.2 非目标spec 明确不做这些事防止适配工作演变成重写不重写 Story System 主链不拆掉现有 8 个 Skill不改变webnovel.py status的旧健康报告语义不把doctor、project-status、write-gate、projection_log重新设计成另一套平行系统不把 hooks 变成隐藏业务流程不自动启动 Docker、Dashboard、RAG 服务或外部依赖不把docs/superpowers/重新作为活跃文档区活跃架构 spec 进入docs/architecture/不承诺未经官方文档和本地验证的外部宿主能力。4. 设计原则4.1 Runtime 是唯一业务真源Skill、Agent、hook、adapter 都只是入口或调度层。真正能修改项目事实的动作必须进入 runtimeSkill / host command ↓ webnovel.py ↓ data_modules ↓ .story-system commit ↓ projection read-models任何宿主 adapter 都不能直接写.story-system/commits/或.webnovel/*read-model。这条原则在当前实现中有两层证据支撑一是 guard_runtime_write.py 对直写受保护路径做兜底阻断二是行为 eval 锁定chapter-commit只能经由webnovel.py的合法命令链发生。4.2 Claude Code 是第一支持宿主Claude Code 当前体验必须保持稳定.claude-plugin/plugin.json保持官方位置skills/、agents/、hooks/保持插件根层级Claude hooks 继续使用${CLAUDE_PLUGIN_ROOT}符合官方plugin-dev/webnovel-*Skill 名称继续有效。4.3 Adapter 尽量薄各宿主 adapter 只负责六件事manifest / metadatatool name mappingagent frontmatter 转换command 暴露方式hook 能力降级smoke/eval 启动方式。adapter 不负责改写写作流程、解释 Story System、校验 chapter artifacts、执行 projection、自己维护项目状态。4.4 不相信手写矩阵外部宿主能力变化很快spec 不把「某宿主现在支持什么」写成不可验证的口头事实。每个宿主 adapter 必须有自己的support.md或等价记录包含官方文档链接、核验日期、支持的 manifest 字段、支持的 skill / command / agent / hook / MCP 能力、不支持能力的降级规则、本仓库对应的 smoke 测试命令。adapters/registry.json中的supports数组不能手写猜测必须由该宿主的support.md和 smoke test 支撑。4.5 UTF-8 First所有新增脚本和 adapter 生成器必须显式 UTF-8Python 文件头保留# -*- coding: utf-8 -*-文本读写使用encodingutf-8Windows 子进程优先使用python -X utf8不依赖系统默认 GBK 编码。当前仓库已整体遵循这一点hooks.json 中两条 hook 命令均为python -X utf8 ...webnovel.py 入口还调用enable_windows_utf8_stdio()处理 Windows 中文路径场景。4.6 渐进迁移多宿主适配必须逐步引入不能一次性重命名 Agent 或大改 Skill先锁定现状和验证再补 adapter 目录与生成器再迁移 Agent 规范名和 Skill 文案最后接入跨宿主 smoke/eval。5. 目标架构adapters 目录、生成器与事实源划分5.1 目标结构webnovel-writer/ ├── .claude-plugin/ │ └── plugin.json ├── skills/ │ ├── webnovel-init/ │ ├── webnovel-plan/ │ ├── webnovel-write/ │ ├── webnovel-review/ │ ├── webnovel-query/ │ ├── webnovel-learn/ │ ├── webnovel-dashboard/ │ ├── webnovel-doctor/ │ └── using-webnovel-writer/ # 可选跨宿主使用说明与工具映射 ├── agents/ │ ├── context-agent.md # 旧名兼容 │ ├── reviewer.md # 旧名兼容 │ ├──>是否事实源是否提交Claude 插件 manifest.claude-plugin/plugin.json是是Skill 源文件skills/*/SKILL.md是是Agent 源文件agents/*.md是是Claude hook 源文件hooks/hooks.json、hooks/*.py是是Runtimescripts/、data_modules/是是Adapter 模板adapters/host/是是生成器scripts/generate_host_artifacts.py是是非 Claude 生成包dist/host/webnovel-writer/否否小型宿主 manifest 快照.codex-plugin/plugin.json等视宿主而定需 drift check这张表是多宿主工程的核心纪律业务事实只存在于「事实源」一侧生成物一侧可以随时销毁重建一致性由--check保证。6. 环境变量与路径策略6.1 Claude Code 路径保持不变Claude Code 插件组件里继续使用${CLAUDE_PLUGIN_ROOT}这是官方plugin-dev推荐方式不能为了跨宿主把 Claude hook 或 Claude Skill 里的路径粗暴替换掉。6.2 Runtime 可增加兼容解析Python runtime 可以支持更通用的插件根解析顺序显式 CLI 参数WEBNOVEL_PLUGIN_ROOTCLAUDE_PLUGIN_ROOT当前脚本路径向上推导。但这属于 runtime 兼容层不代表 Claude 插件文档主变量要改名。从现有源码看hooks 已经采用了「环境变量优先、脚本位置兜底」的类似策略session_start.py 中CLAUDE_PLUGIN_ROOT缺失时回退到Path(__file__).resolve().parents[1]说明这条解析顺序在当前实现中已有雏形。6.3 Skill 文案中的路径写法Claude Code Skill 里的可执行示例继续用python -X utf8 ${CLAUDE_PLUGIN_ROOT}/scripts/webnovel.py ...跨宿主说明放到using-webnovel-writer或skills/*/references/host-tools.md不要把所有宿主变量塞进每个 Skill 主体。7. Skill 适配规范7.1 保留当前 8 个业务 Skill第 2.2 节列出的 8 个 Skill 一个不少。每个 Skill 的四条要求frontmatter、主体精简、references 下沉、确定性校验交给 runtime已在第 2.2 节展开此处不重复。7.2 新增可选总入口 Skill可以新增skills/using-webnovel-writer/SKILL.md用途给非 Claude 宿主提供统一使用说明解释当前宿主下的工具名映射引导先运行project-status必要时运行doctor说明不支持 subagent/hook 的降级模式。限制同样明确不替代 8 个业务 Skill、不复制每个 Skill 的完整流程、不承载题材知识和 Story System schema。7.3 写章 Skill 的硬要求webnovel-write对应 skills/webnovel-write/SKILL.md是多宿主适配的核心验收对象。任何宿主的写章流程都必须保留写前调用write-gate --stage prewrite提交前调用write-gate --stage precommit提交事实只能走chapter-commit提交后调用write-gate --stage postcommitprojection 失败时提示projections retry --chapter N不能直接手写 read-model。这六条与 fast.json 中skill_write_contract的required/ordered断言完全对应——也就是说spec 的「硬要求」不是新增负担而是把已经在行为 eval 里机器化的契约在多宿主维度上重新声明一遍。8. Agent 适配规范8.1 规范名与旧名兼容目标规范名使用webnovel-前缀旧名规范名context-agentwebnovel-context-agentreviewerwebnovel-reviewerdata-agentwebnovel-data-agentdeconstruction-agentwebnovel-deconstruction-agent迁移方式分四步先在文档和 adapter registry 中声明映射再让生成器为不同宿主输出规范名最后逐步修改 Skill 正文使用规范名旧名至少保留一个小版本周期避免破坏现有调用。8.2 Agent 边界所有宿主都必须遵守现有边界context-agent只负责写前上下文和任务书reviewer只负责审查和 blocking 输出data-agent只产出 commit artifacts不直接写 projectiondeconstruction-agent只负责参考拆解和经验沉淀。这与四个 agent 源文件的 frontmatterdescription逐字对应例如>hooks/hooks.json hooks/session_start.py hooks/guard_runtime_write.py必须继续满足官方plugin-dev要求hooks/hooks.json使用 wrapper 格式外层包含description与hooks当前 hooks.json 即是该格式command hook 使用${CLAUDE_PLUGIN_ROOT}hook 脚本只做轻量、确定性、可快速退出的检查两个脚本均设置了 5 秒超时且异常路径一律静默放行。9.2 其他宿主 hook 可选其他宿主是否支持 hook由对应 adapter 的support.md和 smoke test 决定。若宿主不支持 hook不影响核心写作流程通过project-status/doctor/write-gate显式命令补足不能让某个关键能力只存在于 hook 中。9.3 hook 禁止做的事hook 不允许自动写 commit、自动改正文、自动改设定、自动安装依赖、自动启动长驻服务、写入章节流程状态。当前 guard_runtime_write.py 的实现也印证了这一约束——它只读取 stdin 的工具调用 payload、判定路径或命令是否命中保护规则命中则 deny全程无任何写入副作用。10. Doctor 与统一状态入口10.1 所有宿主共享同一状态入口多宿主适配必须统一使用python -X utf8 PLUGIN_ROOT/scripts/webnovel.py --project-root PROJECT_ROOT project-status --format summary当短状态显示异常时再运行python -X utf8 PLUGIN_ROOT/scripts/webnovel.py --project-root PROJECT_ROOT doctor --format text10.2 不新增第二套 statusstatus继续保留宏观创作健康报告语义转发到 status_reporter.py短状态只用project-status深度体检只用doctor。三个入口的分工在 data_modules/webnovel.py 中都有对应实现且互不替代。10.3 doctor 的跨宿主价值doctor是多宿主适配的安装后第一检查入口必须能回答项目根是否解析正确当前 phase 是什么当前 phase 应该有哪些文件目录、JSON、SQLite 是否完整RAG 配置是否存在Python 依赖是否安装Dashboard 产物是否存在projection 是否失败缺失项怎么修。11. Adapter 设计registry、宿主目录与生成器11.1 Adapter registry新增adapters/registry.json建议结构{ schema_version: webnovel-host-adapter-registry/v1, hosts: { claude: { tier: primary, source: .claude-plugin/plugin.json, supports: [skills, agents, hooks], smoke: python -X utf8 scripts/validate_plugin_package.py --format json }, codex: { tier: adapter, source: adapters/codex/, supports: [], smoke: } } }supports不能手写猜测必须由该宿主support.md和 smoke test 支撑。11.2 每个宿主目录每个宿主 adapter 至少包含adapters/host/ ├── support.md # 官方文档核验记录 ├── manifest.template.* # 需要时才有 ├── tool-mapping.md # 工具名与降级规则 ├── agent-mapping.json # 规范 agent 名与宿主表达 └── smoke.md # 本地验证命令11.3 生成器新增生成器scripts/generate_host_artifacts.py用法python -X utf8 scripts/generate_host_artifacts.py --target all python -X utf8 scripts/generate_host_artifacts.py --target codex python -X utf8 scripts/generate_host_artifacts.py --check生成器负责读取 adapter registry、读取 Skill / Agent / hook 源文件、生成宿主 manifest、生成宿主 agent 配置、生成宿主 command / skill 入口、生成 drift manifest。生成器不负责修改业务源文件、联网下载依赖、改写 Story System schema、运行写作流程。--check模式的语义是「只对比不写入」CI 用它判断已提交的生成产物是否与当前业务源一致失败时说明哪个源文件变化导致 drift、应该重新运行哪个生成命令、哪些生成文件需要提交。12. 验证与 CI12.1 Package validator 扩展当前 validate_plugin_package.py 继续作为基础它已经能检查 manifest、frontmatter、hooks wrapper、README 版本与本机绝对路径泄漏后续扩展检查adapters/registry.jsonschema每个 adapter 是否有support.md每个 adapter 是否声明 smoke 命令生成产物是否含本机绝对路径复用现有LOCAL_ABSOLUTE_RE思路小型提交 manifest 是否与生成器输出一致docs/README.md是否索引活跃 spec。12.2 Behavior eval 扩展当前 fast eval 已覆盖 8 个 Skill见 fast.json。后续增加每个宿主至少一个 install / discover smoke每个宿主至少一个project-statussmokewebnovel-doctor在每个宿主都有可执行说明webnovel-write在至少一个非 Claude 宿主完成兼容模式验收无 subagent 宿主不得声称调用 subagent。12.3 Drift check如果提交了任何生成 manifest 或 generated adapter 文件CI 必须运行python -X utf8 scripts/generate_host_artifacts.py --check失败时说明哪个源文件变化导致 drift应该重新运行哪个生成命令哪些生成文件需要提交。12.4 外部能力核验每次实现某个宿主 adapter 前必须重新核验官方文档核验结果写入adapters/host/support.md至少包含核验日期、官方链接、支持能力、不支持能力、本仓库采用的降级策略。13. 迁移计划Phase 0 到 Phase 6Phase 0锁定现状目标让 spec 和当前主干一致。改动新增本 spec 到docs/architecture/更新 docs/README.md 索引不新增docs/superpowers/活跃目录。验收文档列出 8 个 Skill文档列出当前 hooks文档列出 doctor、project-status、write-gate、projections、projection_loggit diff --check通过。Phase 1Adapter 研究记录与注册表目标先验证外部宿主能力不写大规模生成器。改动新增adapters/README.md、adapters/registry.json为每个目标宿主新增support.md只记录官方文档核验结果和本项目降级策略。影响不影响现有 Claude Code 用户不影响 runtime。Phase 2Agent 规范名与兼容映射目标引入webnovel-*规范 Agent 名但不破坏旧名。改动新增agents/aliases.json或等价映射更新 adapter registry 使用规范名更新 behavior eval确保旧名与规范名不会互相漂移。影响Claude Code 现有 Skill 仍可调用旧名后续宿主生成优先使用规范名。Phase 3Skill 瘦身与宿主工具映射目标减少 Skill 主体中的 Claude-only 工具表达。改动新增skills/using-webnovel-writer/把跨宿主工具映射放到 references保留 Claude Code 示例中的${CLAUDE_PLUGIN_ROOT}不把每个宿主的完整说明复制进 8 个业务 Skill。影响Skill 更短更容易被不同宿主消费当前 Claude Code 命令不变。Phase 4生成器与 drift check目标让非 Claude adapter 可生成、可检查。改动新增scripts/generate_host_artifacts.py生成dist/host/webnovel-writer/扩展validate_plugin_package.py检查 adapterCI 增加 drift check。影响新增开发工具不改变用户项目数据生成文件默认不提交。Phase 5跨宿主 smoke 与行为 eval目标证明「能发现、能体检、能执行核心流程或明确降级」。改动扩展run_behavior_evals.py每个宿主至少有 discover / project-status / doctor smoke至少一个非 Claude 宿主完成webnovel-write兼容模式验收。影响发布前检查时间增加但适配声明更可信。Phase 6发布文档与版本治理目标用户知道哪个宿主支持到什么程度。改动README 增加多宿主支持表docs/guides/commands.md增加非 Claude 使用口径docs/operations/plugin-release.md增加 adapter 发布检查release note 明确每个宿主支持等级。影响避免用户误以为所有宿主都已完整支持降低 issue 中的环境误解。14. 风险与控制风险影响控制外部宿主能力描述过期spec 很快失真每个 adapter 用support.md记录官方核验日期和链接为每个宿主复制业务流程逻辑漂移adapter 只调webnovel.py不复制 runtime重命名 Agent 破坏旧流程现有用户调用失败旧名兼容一个小版本周期以上hook 被误当业务流程隐藏副作用hook 只做状态提示和危险写入兜底Skill 主体继续膨胀token 消耗高详细内容下沉 references确定性动作下沉 scripts生成产物漂移发布包和源不一致generate_host_artifacts.py --checkWindows 中文路径失败用户无法运行所有新增 Python I/O 使用 UTF-8命令用python -X utf815. 验收清单最终完成时必须满足Claude Code 原安装流程不破坏8 个现有 Skill 仍可发现/webnovel-doctor保留并进入多宿主自检路径当前 hooks 保持 plugin-dev wrapper 格式project-status、doctor、write-gate、projections都是跨宿主共享 runtime 入口status仍保留旧宏观健康报告语义Agent 规范名有webnovel-前缀旧名有兼容映射每个 adapter 都有support.md包含官方文档核验日期和链接每个 adapter 都有 smoke 命令或明确阻断原因生成器可生成非 Claude 宿主产物drift check 能发现生成产物不一致package validator 覆盖 adapter registry、support.md 和 manifest 漂移behavior eval 覆盖 8 个 Skill 和至少一个非 Claude 兼容写作流程README 和 release note 明确每个宿主的支持等级。16. 小结这次多宿主适配的核心不是「再写一套插件」而是保住当前已经做好的 runtime 基线spec 撰写时为 v6.1.0当前 plugin.json 为 6.2.1两者共享同一套结构把 Claude Code 作为第一宿主继续维护用 adapter 和生成器把同一套能力暴露给其他宿主用 doctor、project-status、write-gate、projection log 和 eval 证明它真的能用。对开发者而言这套设计的可复用价值在于它给出了一组清晰的工程判据业务能力集中在唯一 runtime 中宿主差异收敛到「薄 adapter 可验证的 support 记录 生成器 drift check」——能力声明必须能被 smoke test 推翻或证实降级必须显式声明而不是靠文档里的手写矩阵自我保证。后续扩展宿主时项目不会被重新打散用户也不会在多个看起来相似、实际语义不同的入口里迷路。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
webnovel-writer 多宿主与多智能体适配以 Runtime 为唯一业务核心的薄 Adapter 演进设计【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer本文基于 docs/architecture/multi-agent-adaptation-spec-2026-06-05.md 展开完整解读 webnovel-writer 从「Claude Code 单宿主插件」演进为「可验证、可生成、可降级的多宿主写作插件」的规格设计包括当前 v6.1.0 运行时基线的完整盘点8 个 Skill、4 个 Agent、统一 Runtime CLI、hooks 与两类验证能力、以scripts/webnovel.py为唯一业务真源的目标架构、adapter registry 与生成器的设计、逐 Phase 的迁移计划与验收清单。读完后你将掌握一套把同一套写作能力暴露给 Codex、Cursor、Gemini CLI、OpenCode、GitHub Copilot CLI 等多个宿主、且能力声明可被 smoke 测试验证的工程方法。需要说明的适用前提该 spec 以master分支 v6.1.0 为基线撰写当前仓库的 plugin.json 版本已演进到 6.2.1但 spec 描述的插件结构、hooks、Runtime CLI 与验证体系在当前主干上仍然成立下文会指出关键差异。1. 背景为什么需要多宿主适配以及基线修正spec 的出发点很明确webnovel-writer 不应该永远被 Claude Code 的表达方式绑定。它已经具备完整的写作运行时、Story System、RAG、Dashboard、Agent 分工和发布校验具备向多个宿主适配的条件。但 spec 同时指出先前 PR #110 的原始 spec 使用了过期基线存在四处失真只列出 7 个 Skill漏掉/webnovel-doctor把 hooks 描述为「当前未形成 bootstrap」而当前主干已经有 hooks.json、session_start.py 和 guard_runtime_write.py没有把project-status、doctor、write-gate、projections retry/replay、.webnovel/projection_log.jsonl纳入最终形态新增文档放在docs/superpowers/specs/但superpowers已归档到docs/archive/superpowers/活跃架构 spec 应进入docs/architecture/。因此该 spec 以当前运行时为基线重新定义多宿主适配方案。这一点也体现在当前仓库的 docs/README.md 文档索引中该 spec 与plugin-runtime-hardening-spec等并列收录在架构分区下。2. 当前真实基线8 个 Skill、4 个 Agent、统一 Runtime 与 hooks2.1 Claude Code 插件结构当前插件根为webnovel-writer/目录符合官方plugin-dev对 Claude Code 插件结构的要求webnovel-writer/ ├── .claude-plugin/ │ └── plugin.json ├── agents/ │ ├── context-agent.md │ ├──>{ id: skill_write_contract, type: skill_contract, skill: webnovel-write, required: [ write-gate --chapter {chapter_num} --stage prewrite, write-gate --chapter {chapter_num} --stage precommit, write-gate --chapter {chapter_num} --stage postcommit, projections retry --chapter {chapter_num} ], ordered: [ [write-gate --chapter {chapter_num} --stage precommit, chapter-commit], [chapter-commit, write-gate --chapter {chapter_num} --stage postcommit] ] }也就是说「先 precommit、再 commit、后 postcommit」的硬顺序不是自然语言约定而是被 run_behavior_evals.py 执行的机器可检契约。2.3 当前 4 个 Agent 及目标规范名当前文件当前职责目标规范名context-agent.md写前上下文与任务书组装webnovel-context-agentreviewer.md多维审查与 blocking issue 输出webnovel-reviewerdata-agent.md提取 commit artifacts不直接写 projectionwebnovel-data-agentdeconstruction-agent.md拆解参考书和结构学习webnovel-deconstruction-agent从源码结构看四个 agent 的 frontmatter 均包含name、description、tools如Read, Grep, Bash、model: inherit和color字段与官方插件 agent 格式一致。spec 明确要求当前文件名不能直接删除或重命名因为现有 Skill 文案和用户习惯可能仍引用旧名目标规范名必须通过兼容迁移引入详见第 9 节。2.4 当前 Runtime CLI所有确定性动作统一从 scripts/webnovel.py 进入。该脚本本身极薄把scripts/目录加入sys.path后转发到data_modules.webnovel这样在项目级或用户级~/.claude安装时都能被调用。多宿主适配必须复用这些 runtime 命令不为每个宿主重写一套业务逻辑。spec 列出的关键命令命令作用preflight快速环境与项目根检查project-status机器可读短状态、phase、下一步doctor阶段感知项目体检与修复建议write-gate写前、提交前、提交后三个自然边界校验story-systemStory System 合同与运行时数据chapter-commit章节事实提交驱动 projectionprojections retry/replay基于已有 commit 补跑或重放投影status旧宏观创作健康报告保持原语义对照 data_modules/webnovel.py 中的 argparse 定义这些子命令全部真实存在且每个子命令都是转发到独立的业务模块cmd_project_status、cmd_doctor、cmd_write_gate、cmd_projections、cmd_status等projections下还有retry与replay两个 action。当前版本还额外包含 spec 基线之后加入的user-report、run-ledger、run-log、use等子命令进一步印证了「Runtime 是唯一业务真源」这一原则的落地方式。2.5 当前 Hook当前已经存在 Claude Code 插件级 hooks且 hooks.json 使用官方要求的 wrapper 格式——外层包含description与hooks两个键SessionStartmatcher*运行 session_start.py给新会话提供短状态PreToolUsematcherWrite|Edit|MultiEdit与Bash运行 guard_runtime_write.py对直接写危险路径做兜底阻断。从源码看session_start.py只调用project-status --format summary输出被裁剪到最多 8 行 / 1000 字符4 秒超时任何异常都静默返回 0——保证 hook 永远不会拖慢或破坏会话启动。guard_runtime_write.py则维护一份受保护路径清单PROTECTED_SUFFIXES ( .story-system/commits/, .webnovel/index.db, .webnovel/vectors.db, .webnovel/memory_scratchpad.json, .webnovel/projection_log.jsonl, )当检测到 Bash 命令绕过 runtime 直写这些文件且命令中不含webnovel.pychapter-commit/projections retry/projections replay等合法标记时hook 向 stderr 输出{hookSpecificOutput: {permissionDecision: deny}, ...}并以退出码 2 拒绝操作。源码注释还特别说明.webnovel/state.json被有意排除在保护清单之外因为审计修复经常需要它无法表达的批量修改且state.json自身有备份 重建路径issue #113。spec 对此的定性是hook 是轻量守卫不是业务状态机。它只做状态提示和危险写入兜底不允许自动写 commit、自动改正文/设定、自动安装依赖、启动长驻服务或写入章节流程状态。2.6 当前验证能力当前已有两类基础验证validate_plugin_package.py按官方plugin-dev思路检查 manifest、Skill / Agent frontmatter、hooks wrapper、README 版本、路径可移植性。从源码看它带 schema 版本webnovel-plugin-package-validator/v1并用正则LOCAL_ABSOLUTE_RE检测生成物中是否混入本机绝对路径/Users/...、/home/...、盘符路径与 spec 后续 drift check「生成产物是否含本机绝对路径」的检查项一脉相承run_behavior_evals.py evals/fixtures/behavior/fast.json检查 8 个 Skill 的关键行为契约、Agent 边界、commit/projection 顺序、Dashboard 只读语义。spec 的结论是多宿主适配必须扩展这两类验证而不是新造一套互不相干的检查。3. 目标与非目标3.1 一句话目标把 Webnovel Writer 从「Claude Code 单宿主插件」升级为以现有 Python runtime 和 Story System 为唯一业务核心向多个宿主生成轻量 adapter 的长篇写作插件。具体目标六条保留 Claude Code 现有安装、Skill、Agent、hook 和 CLI 体验让 Codex、Cursor、Gemini CLI、OpenCode、GitHub Copilot CLI 等宿主可以通过 adapter 消费同一套写作能力所有宿主都复用scripts/webnovel.py和data_modules不复制 Story System、commit、projection、doctor、gate 逻辑每个宿主的支持状态必须可验证有 manifest 校验、smoke 测试和行为 eval当宿主不支持 subagent 或 hook 时有明确降级模式不假装已经调用了不存在的能力所有新增插件组件继续符合官方plugin-dev的结构、frontmatter、hooks、路径和验证要求。3.2 非目标spec 明确不做这些事防止适配工作演变成重写不重写 Story System 主链不拆掉现有 8 个 Skill不改变webnovel.py status的旧健康报告语义不把doctor、project-status、write-gate、projection_log重新设计成另一套平行系统不把 hooks 变成隐藏业务流程不自动启动 Docker、Dashboard、RAG 服务或外部依赖不把docs/superpowers/重新作为活跃文档区活跃架构 spec 进入docs/architecture/不承诺未经官方文档和本地验证的外部宿主能力。4. 设计原则4.1 Runtime 是唯一业务真源Skill、Agent、hook、adapter 都只是入口或调度层。真正能修改项目事实的动作必须进入 runtimeSkill / host command ↓ webnovel.py ↓ data_modules ↓ .story-system commit ↓ projection read-models任何宿主 adapter 都不能直接写.story-system/commits/或.webnovel/*read-model。这条原则在当前实现中有两层证据支撑一是 guard_runtime_write.py 对直写受保护路径做兜底阻断二是行为 eval 锁定chapter-commit只能经由webnovel.py的合法命令链发生。4.2 Claude Code 是第一支持宿主Claude Code 当前体验必须保持稳定.claude-plugin/plugin.json保持官方位置skills/、agents/、hooks/保持插件根层级Claude hooks 继续使用${CLAUDE_PLUGIN_ROOT}符合官方plugin-dev/webnovel-*Skill 名称继续有效。4.3 Adapter 尽量薄各宿主 adapter 只负责六件事manifest / metadatatool name mappingagent frontmatter 转换command 暴露方式hook 能力降级smoke/eval 启动方式。adapter 不负责改写写作流程、解释 Story System、校验 chapter artifacts、执行 projection、自己维护项目状态。4.4 不相信手写矩阵外部宿主能力变化很快spec 不把「某宿主现在支持什么」写成不可验证的口头事实。每个宿主 adapter 必须有自己的support.md或等价记录包含官方文档链接、核验日期、支持的 manifest 字段、支持的 skill / command / agent / hook / MCP 能力、不支持能力的降级规则、本仓库对应的 smoke 测试命令。adapters/registry.json中的supports数组不能手写猜测必须由该宿主的support.md和 smoke test 支撑。4.5 UTF-8 First所有新增脚本和 adapter 生成器必须显式 UTF-8Python 文件头保留# -*- coding: utf-8 -*-文本读写使用encodingutf-8Windows 子进程优先使用python -X utf8不依赖系统默认 GBK 编码。当前仓库已整体遵循这一点hooks.json 中两条 hook 命令均为python -X utf8 ...webnovel.py 入口还调用enable_windows_utf8_stdio()处理 Windows 中文路径场景。4.6 渐进迁移多宿主适配必须逐步引入不能一次性重命名 Agent 或大改 Skill先锁定现状和验证再补 adapter 目录与生成器再迁移 Agent 规范名和 Skill 文案最后接入跨宿主 smoke/eval。5. 目标架构adapters 目录、生成器与事实源划分5.1 目标结构webnovel-writer/ ├── .claude-plugin/ │ └── plugin.json ├── skills/ │ ├── webnovel-init/ │ ├── webnovel-plan/ │ ├── webnovel-write/ │ ├── webnovel-review/ │ ├── webnovel-query/ │ ├── webnovel-learn/ │ ├── webnovel-dashboard/ │ ├── webnovel-doctor/ │ └── using-webnovel-writer/ # 可选跨宿主使用说明与工具映射 ├── agents/ │ ├── context-agent.md # 旧名兼容 │ ├── reviewer.md # 旧名兼容 │ ├──>是否事实源是否提交Claude 插件 manifest.claude-plugin/plugin.json是是Skill 源文件skills/*/SKILL.md是是Agent 源文件agents/*.md是是Claude hook 源文件hooks/hooks.json、hooks/*.py是是Runtimescripts/、data_modules/是是Adapter 模板adapters/host/是是生成器scripts/generate_host_artifacts.py是是非 Claude 生成包dist/host/webnovel-writer/否否小型宿主 manifest 快照.codex-plugin/plugin.json等视宿主而定需 drift check这张表是多宿主工程的核心纪律业务事实只存在于「事实源」一侧生成物一侧可以随时销毁重建一致性由--check保证。6. 环境变量与路径策略6.1 Claude Code 路径保持不变Claude Code 插件组件里继续使用${CLAUDE_PLUGIN_ROOT}这是官方plugin-dev推荐方式不能为了跨宿主把 Claude hook 或 Claude Skill 里的路径粗暴替换掉。6.2 Runtime 可增加兼容解析Python runtime 可以支持更通用的插件根解析顺序显式 CLI 参数WEBNOVEL_PLUGIN_ROOTCLAUDE_PLUGIN_ROOT当前脚本路径向上推导。但这属于 runtime 兼容层不代表 Claude 插件文档主变量要改名。从现有源码看hooks 已经采用了「环境变量优先、脚本位置兜底」的类似策略session_start.py 中CLAUDE_PLUGIN_ROOT缺失时回退到Path(__file__).resolve().parents[1]说明这条解析顺序在当前实现中已有雏形。6.3 Skill 文案中的路径写法Claude Code Skill 里的可执行示例继续用python -X utf8 ${CLAUDE_PLUGIN_ROOT}/scripts/webnovel.py ...跨宿主说明放到using-webnovel-writer或skills/*/references/host-tools.md不要把所有宿主变量塞进每个 Skill 主体。7. Skill 适配规范7.1 保留当前 8 个业务 Skill第 2.2 节列出的 8 个 Skill 一个不少。每个 Skill 的四条要求frontmatter、主体精简、references 下沉、确定性校验交给 runtime已在第 2.2 节展开此处不重复。7.2 新增可选总入口 Skill可以新增skills/using-webnovel-writer/SKILL.md用途给非 Claude 宿主提供统一使用说明解释当前宿主下的工具名映射引导先运行project-status必要时运行doctor说明不支持 subagent/hook 的降级模式。限制同样明确不替代 8 个业务 Skill、不复制每个 Skill 的完整流程、不承载题材知识和 Story System schema。7.3 写章 Skill 的硬要求webnovel-write对应 skills/webnovel-write/SKILL.md是多宿主适配的核心验收对象。任何宿主的写章流程都必须保留写前调用write-gate --stage prewrite提交前调用write-gate --stage precommit提交事实只能走chapter-commit提交后调用write-gate --stage postcommitprojection 失败时提示projections retry --chapter N不能直接手写 read-model。这六条与 fast.json 中skill_write_contract的required/ordered断言完全对应——也就是说spec 的「硬要求」不是新增负担而是把已经在行为 eval 里机器化的契约在多宿主维度上重新声明一遍。8. Agent 适配规范8.1 规范名与旧名兼容目标规范名使用webnovel-前缀旧名规范名context-agentwebnovel-context-agentreviewerwebnovel-reviewerdata-agentwebnovel-data-agentdeconstruction-agentwebnovel-deconstruction-agent迁移方式分四步先在文档和 adapter registry 中声明映射再让生成器为不同宿主输出规范名最后逐步修改 Skill 正文使用规范名旧名至少保留一个小版本周期避免破坏现有调用。8.2 Agent 边界所有宿主都必须遵守现有边界context-agent只负责写前上下文和任务书reviewer只负责审查和 blocking 输出data-agent只产出 commit artifacts不直接写 projectiondeconstruction-agent只负责参考拆解和经验沉淀。这与四个 agent 源文件的 frontmatterdescription逐字对应例如>hooks/hooks.json hooks/session_start.py hooks/guard_runtime_write.py必须继续满足官方plugin-dev要求hooks/hooks.json使用 wrapper 格式外层包含description与hooks当前 hooks.json 即是该格式command hook 使用${CLAUDE_PLUGIN_ROOT}hook 脚本只做轻量、确定性、可快速退出的检查两个脚本均设置了 5 秒超时且异常路径一律静默放行。9.2 其他宿主 hook 可选其他宿主是否支持 hook由对应 adapter 的support.md和 smoke test 决定。若宿主不支持 hook不影响核心写作流程通过project-status/doctor/write-gate显式命令补足不能让某个关键能力只存在于 hook 中。9.3 hook 禁止做的事hook 不允许自动写 commit、自动改正文、自动改设定、自动安装依赖、自动启动长驻服务、写入章节流程状态。当前 guard_runtime_write.py 的实现也印证了这一约束——它只读取 stdin 的工具调用 payload、判定路径或命令是否命中保护规则命中则 deny全程无任何写入副作用。10. Doctor 与统一状态入口10.1 所有宿主共享同一状态入口多宿主适配必须统一使用python -X utf8 PLUGIN_ROOT/scripts/webnovel.py --project-root PROJECT_ROOT project-status --format summary当短状态显示异常时再运行python -X utf8 PLUGIN_ROOT/scripts/webnovel.py --project-root PROJECT_ROOT doctor --format text10.2 不新增第二套 statusstatus继续保留宏观创作健康报告语义转发到 status_reporter.py短状态只用project-status深度体检只用doctor。三个入口的分工在 data_modules/webnovel.py 中都有对应实现且互不替代。10.3 doctor 的跨宿主价值doctor是多宿主适配的安装后第一检查入口必须能回答项目根是否解析正确当前 phase 是什么当前 phase 应该有哪些文件目录、JSON、SQLite 是否完整RAG 配置是否存在Python 依赖是否安装Dashboard 产物是否存在projection 是否失败缺失项怎么修。11. Adapter 设计registry、宿主目录与生成器11.1 Adapter registry新增adapters/registry.json建议结构{ schema_version: webnovel-host-adapter-registry/v1, hosts: { claude: { tier: primary, source: .claude-plugin/plugin.json, supports: [skills, agents, hooks], smoke: python -X utf8 scripts/validate_plugin_package.py --format json }, codex: { tier: adapter, source: adapters/codex/, supports: [], smoke: } } }supports不能手写猜测必须由该宿主support.md和 smoke test 支撑。11.2 每个宿主目录每个宿主 adapter 至少包含adapters/host/ ├── support.md # 官方文档核验记录 ├── manifest.template.* # 需要时才有 ├── tool-mapping.md # 工具名与降级规则 ├── agent-mapping.json # 规范 agent 名与宿主表达 └── smoke.md # 本地验证命令11.3 生成器新增生成器scripts/generate_host_artifacts.py用法python -X utf8 scripts/generate_host_artifacts.py --target all python -X utf8 scripts/generate_host_artifacts.py --target codex python -X utf8 scripts/generate_host_artifacts.py --check生成器负责读取 adapter registry、读取 Skill / Agent / hook 源文件、生成宿主 manifest、生成宿主 agent 配置、生成宿主 command / skill 入口、生成 drift manifest。生成器不负责修改业务源文件、联网下载依赖、改写 Story System schema、运行写作流程。--check模式的语义是「只对比不写入」CI 用它判断已提交的生成产物是否与当前业务源一致失败时说明哪个源文件变化导致 drift、应该重新运行哪个生成命令、哪些生成文件需要提交。12. 验证与 CI12.1 Package validator 扩展当前 validate_plugin_package.py 继续作为基础它已经能检查 manifest、frontmatter、hooks wrapper、README 版本与本机绝对路径泄漏后续扩展检查adapters/registry.jsonschema每个 adapter 是否有support.md每个 adapter 是否声明 smoke 命令生成产物是否含本机绝对路径复用现有LOCAL_ABSOLUTE_RE思路小型提交 manifest 是否与生成器输出一致docs/README.md是否索引活跃 spec。12.2 Behavior eval 扩展当前 fast eval 已覆盖 8 个 Skill见 fast.json。后续增加每个宿主至少一个 install / discover smoke每个宿主至少一个project-statussmokewebnovel-doctor在每个宿主都有可执行说明webnovel-write在至少一个非 Claude 宿主完成兼容模式验收无 subagent 宿主不得声称调用 subagent。12.3 Drift check如果提交了任何生成 manifest 或 generated adapter 文件CI 必须运行python -X utf8 scripts/generate_host_artifacts.py --check失败时说明哪个源文件变化导致 drift应该重新运行哪个生成命令哪些生成文件需要提交。12.4 外部能力核验每次实现某个宿主 adapter 前必须重新核验官方文档核验结果写入adapters/host/support.md至少包含核验日期、官方链接、支持能力、不支持能力、本仓库采用的降级策略。13. 迁移计划Phase 0 到 Phase 6Phase 0锁定现状目标让 spec 和当前主干一致。改动新增本 spec 到docs/architecture/更新 docs/README.md 索引不新增docs/superpowers/活跃目录。验收文档列出 8 个 Skill文档列出当前 hooks文档列出 doctor、project-status、write-gate、projections、projection_loggit diff --check通过。Phase 1Adapter 研究记录与注册表目标先验证外部宿主能力不写大规模生成器。改动新增adapters/README.md、adapters/registry.json为每个目标宿主新增support.md只记录官方文档核验结果和本项目降级策略。影响不影响现有 Claude Code 用户不影响 runtime。Phase 2Agent 规范名与兼容映射目标引入webnovel-*规范 Agent 名但不破坏旧名。改动新增agents/aliases.json或等价映射更新 adapter registry 使用规范名更新 behavior eval确保旧名与规范名不会互相漂移。影响Claude Code 现有 Skill 仍可调用旧名后续宿主生成优先使用规范名。Phase 3Skill 瘦身与宿主工具映射目标减少 Skill 主体中的 Claude-only 工具表达。改动新增skills/using-webnovel-writer/把跨宿主工具映射放到 references保留 Claude Code 示例中的${CLAUDE_PLUGIN_ROOT}不把每个宿主的完整说明复制进 8 个业务 Skill。影响Skill 更短更容易被不同宿主消费当前 Claude Code 命令不变。Phase 4生成器与 drift check目标让非 Claude adapter 可生成、可检查。改动新增scripts/generate_host_artifacts.py生成dist/host/webnovel-writer/扩展validate_plugin_package.py检查 adapterCI 增加 drift check。影响新增开发工具不改变用户项目数据生成文件默认不提交。Phase 5跨宿主 smoke 与行为 eval目标证明「能发现、能体检、能执行核心流程或明确降级」。改动扩展run_behavior_evals.py每个宿主至少有 discover / project-status / doctor smoke至少一个非 Claude 宿主完成webnovel-write兼容模式验收。影响发布前检查时间增加但适配声明更可信。Phase 6发布文档与版本治理目标用户知道哪个宿主支持到什么程度。改动README 增加多宿主支持表docs/guides/commands.md增加非 Claude 使用口径docs/operations/plugin-release.md增加 adapter 发布检查release note 明确每个宿主支持等级。影响避免用户误以为所有宿主都已完整支持降低 issue 中的环境误解。14. 风险与控制风险影响控制外部宿主能力描述过期spec 很快失真每个 adapter 用support.md记录官方核验日期和链接为每个宿主复制业务流程逻辑漂移adapter 只调webnovel.py不复制 runtime重命名 Agent 破坏旧流程现有用户调用失败旧名兼容一个小版本周期以上hook 被误当业务流程隐藏副作用hook 只做状态提示和危险写入兜底Skill 主体继续膨胀token 消耗高详细内容下沉 references确定性动作下沉 scripts生成产物漂移发布包和源不一致generate_host_artifacts.py --checkWindows 中文路径失败用户无法运行所有新增 Python I/O 使用 UTF-8命令用python -X utf815. 验收清单最终完成时必须满足Claude Code 原安装流程不破坏8 个现有 Skill 仍可发现/webnovel-doctor保留并进入多宿主自检路径当前 hooks 保持 plugin-dev wrapper 格式project-status、doctor、write-gate、projections都是跨宿主共享 runtime 入口status仍保留旧宏观健康报告语义Agent 规范名有webnovel-前缀旧名有兼容映射每个 adapter 都有support.md包含官方文档核验日期和链接每个 adapter 都有 smoke 命令或明确阻断原因生成器可生成非 Claude 宿主产物drift check 能发现生成产物不一致package validator 覆盖 adapter registry、support.md 和 manifest 漂移behavior eval 覆盖 8 个 Skill 和至少一个非 Claude 兼容写作流程README 和 release note 明确每个宿主的支持等级。16. 小结这次多宿主适配的核心不是「再写一套插件」而是保住当前已经做好的 runtime 基线spec 撰写时为 v6.1.0当前 plugin.json 为 6.2.1两者共享同一套结构把 Claude Code 作为第一宿主继续维护用 adapter 和生成器把同一套能力暴露给其他宿主用 doctor、project-status、write-gate、projection log 和 eval 证明它真的能用。对开发者而言这套设计的可复用价值在于它给出了一组清晰的工程判据业务能力集中在唯一 runtime 中宿主差异收敛到「薄 adapter 可验证的 support 记录 生成器 drift check」——能力声明必须能被 smoke test 推翻或证实降级必须显式声明而不是靠文档里的手写矩阵自我保证。后续扩展宿主时项目不会被重新打散用户也不会在多个看起来相似、实际语义不同的入口里迷路。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
