Narcooo/inkos

如果你已经厌倦每次只把一章的需求丢进聊天框，想让世界观、角色和修订记录留在同一个项目里，InkOS 值得认真试一次。但它不是轻量工具：从 1.x 迁移和配置 LLM 服务本身就需要投入，更适合先做小规模验证。

解决什么问题

连载作者写下一章时，最怕和前文的人物决定、伏笔和时间线对不上。手工做法是翻旧稿、在每个提示里重复设定，再单独要求审稿和修改。InkOS 把这些步骤搬进工作区：用创作简报建书，生成世界观、角色和卷纲，再把写作、审稿、修订和状态结算拆成独立记录的动作。你得到的是一份草稿加上规划与审稿材料，而不是一串对话记录。

有什么不同

InkOS 把写作、审稿、修订和状态结算做成同一个 Harness 上可单独调用、可追溯的行动，并把上下文分成 protected 和 compressible 两层，目的是让长篇越写越稳。写下一章前，剧情多线推演能生成 2 到 5 条彼此隔离的未来分支，方便横向比较节拍、人物决定和风险；但采用分支只保存候选计划文件，不会改动正文、大纲或正史 项目说明。短篇、封面、互动世界和翻译都从同一个 Studio/CLI 入口进入，重动作执行前需要确认。

代价是配置负担。你要自己选择服务商和模型，而且系统会校验模型与服务是否匹配，避免请求悄悄发错地方。以 SKILL.md 形式加入的 Skill 只提供说明和静态参考资料，不会获得执行权限，也不能绕过确认闸门。这个设计合理，但意味着它是一个需要配置的创作系统，而不是打开就能聊的写作应用。

谁值得试

适合：写连载中文小说、剧本或分支互动故事，希望规划、审稿和修订在长项目里可追溯、可回看的人。如果你习惯在动笔前比较几种结构选项，分支推演模式尤其对路。不适合：只想做一次性写作提示的人，或者期待开箱即用网页应用的非技术用户。README 提供了网页版入口可以先体验，但文档描述的工作流仍以本地 CLI/Studio 为主 网页版。

另外一条路径会改变适用人群：InkOS 已发布为 OpenClaw Skill，兼容该接口的 Agent 可以直接调用，Claude Code 或 OpenClaw 用户可以通过共享的 inkos interact 入口使用，不必先学 CLI ClawHub 页面。

使用条件与边界

npm 安装路径要求 Node.js 22.16 或更高版本 npm 包。每次生成都会消耗你配置的 LLM 服务；README 示例里提到 DeepSeek 模型和付费封面图服务，因此 API 成本和可用性属于布置的一部分，不是事后才考虑的问题。本地模型只能通过兼容 OpenAI、Anthropic 或自定义端点接入，配置时测试协议和流式能力；缺少结构化输出或流中断会明确报错，而不是把残缺文本当成功。

从 1.x 升级是单独的一件事：先运行迁移清单做干跑，再执行导入，原始目录和旧清单会备份；没有运行时状态的项目会以草稿进入，需要重建状态后才能继续生产。许可证是 AGPL-3.0，如果你打算围绕代码提供服务，需要先看清这一条 许可证。

HotRepo 点评

HotRepo 有记录的日期只有 2026-10-26 登上每日趋势榜时 10,832 星、当天 +107 星；没有可比的日榜历史，无法判断热度在升还是在退。这个快照只能说明项目存在且获得过一次曝光，不能当作成熟度证据。真要投入长篇之前，最值得确认的是 README 没有回答的一点：protected/compressible 上下文分层在你的书长度下是否够用；文档对长篇一致性的承诺，目前只有机制说明，没有对应的效果说明。