当创作被 Skill 化：我用 AI 写了一部 320 章的长篇网文

作为一名程序员，我以前一直觉得，"完成一个大型项目"这件事，本质上是两种能力的叠加：

• 硬技能：你会不会写代码、会不会用工具；
• 软能力：你能不能把大问题拆成小问题，然后持续推进。

前两年 AI 出来了（尤其是去年），硬技能这边突然被"外挂"了一把：写代码这件事，居然真的可以被 AI 提效。今年初，我又看到在一些规划和约束下（skill），AI 能更好地完成整个工作。我第一次被这种范式击中，是看到 superpowers 这套面向 Coding 的 skills：把"写需求、写模块、写测试、查 bug、做重构"拆成一组可以被反复调用的技能模块，整个开发流程像装了乐高接口一样。

然后我就开始想着做点啥有意思的事——既然大型项目的 Coding 可以用 skill 辅助完成，那另一种"更长、更磨人、更需要拆解与推进"的工作：写一部长篇小说，能不能也用 skill 体系来做？

其实在此之前，我已经做过一次无 skill 的写作尝试了，遇到了很多问题，具体见《我用AI写了部小说，这里是整个过程》，我把其中的问题解决方案和一些经验总结提炼，于是就有了 Sumeru-须弥写作 这套 skill。

1）sumeru 是什么：一套面向小说创作的 Skill 集合

一句话概括：sumeru 是一套把小说创作流程"模块化 + 可编排化"的 AI skills。

可以在任何 AI 工具中使用，无论是 Claude Code、OpenCode…… 这些编程类 Agent，还是 OpenClaw、Hermes…… 这些通用 Agent 里都可以正常使用，安装方法：

npx skills add xindoo/sumeru #建议项目级安装

它不是"给你一个 Prompt，让你自己反复试到天亮"的那种工具；我的目标更像是：

• 你给一个题材和创意方向；
• 它能按流程带你走完：选题 → 大纲 → 章节写作 → 逻辑审查 → 润色 → 完稿导出；
• 中间数据能沉淀，支持断点续传；
• 批量任务可以并行（尤其是写章节这种体力活）。

在 Sumeru 里我把它拆成了 7 个模块（worldbuilder / topic / outline / write / review / polish / finalize），每个模块都对应一个明确的产出和边界。

这种结构有一个好处：你不是在"跟模型聊天"，而是在"驱动一个生产线"。

当然，生产线不一定每次都产出精品，但它至少能稳定把你从"卡住"推到"有东西"产出。

2）为什么我觉得"小说更需要 Skill 化"

首先我还没看到类似的 skill，其次我觉得写长篇小说，其实和写复杂项目很像：

你永远不缺灵感，你缺的是"把灵感落地为可持续推进的结构"； 你写 1 章靠爆发，写 100 章靠系统，写 300 章靠流程； 中途最容易崩的是一致性：设定、时间线、人设、伏笔回收。

所以我更相信：长篇创作的关键不是"写得多好"，而是"能不能稳定地往前走"。而稳定往前走，靠的并不一定是天赋，也可能是一套可复用的拆解方式。

Skill 化带来的变化是：把"玄学式创作"变成"工程式推进"——

说人话就是：把"写作"当成一个可以迭代的系统，而不是一次性灵感发挥。

3）它到底表现怎么样：我用五一做了一次"极限压测"

做工具最怕的一件事是：写得很嗨，上线没人用；或者只在"十分钟 Demo"里好用，一到长链路就露馅。

所以五一我干了一件有点"闲得慌"的事情：用 sumeru 跑了一次长链路创作。

结果是：我用它生成了一部长篇小说 《古物记》，一共 320 章，100w+ 字。

如果你想直接看效果（也欢迎挑刺），可以去这个站点阅读：opennovel.zxs.io

这里我不吹"质量吊打人类"，因为那不真实。更诚实的说法是：

• 它能把"从 0 到 1"这段最难的启动成本压得很低：选题、大纲、细纲、章节生产都能跑通；
• 它能把"从 1 到 300"这段最磨人的重复劳动变得可执行：并行写作 + 数据沉淀 + 审查修复；
• 它也确实会暴露问题：比如部分章节会出现节奏松散、人物行为偶尔不够自然、细节重复等——这些更像是"批量生产"的副作用。

但对我来说，这次压测最关键的验证是：

skill 化的流程，确实能把"长篇创作"从不可控变成可控。

你可以把它理解为：写作不再是"我今天状态好不好"，而是"我今天想推进哪一个环节"。

4）我在设计 sumeru 时刻意坚持的几条原则

原则 A：每个 Skill 的边界要清晰

我不希望出现那种"一个万能指令包办一切"的模式。万能指令看起来爽，但复用性很差，也很难定位问题。

例如：

• review 只做逻辑与一致性审查、轻量修复、输出修复计划；
• polish 专注文笔与节奏优化；
• finalize 做合规检查与导出适配。

边界清晰，才能让你知道：哪里出了问题，该调哪一块。

原则 B：中间数据必须持久化

写长篇最痛的一件事是：你一旦中断，就很难无痛恢复。

所以 sumeru 把中间数据统一放在 .sumeru/ 目录，让每一步都可复用、可回滚、可续跑。

原则 C：并行化只做"体力活"，不要做"核心决策"

并行写章节很合适，但世界观底层设定、主线节奏这种核心决策，不适合"多 Agent 投票"。

所以我的策略是：

• worldbuilder / outline 把核心约束定下来；
• write / review / polish 这些更偏执行与检查的环节，再去并行。

总结

做 sumeru 的过程中，我最强烈的感受是：

AI 的价值不仅仅是替你写几段文字，而是通过流程和约束，帮你去完成一个复杂的项目。就像 Coding 里，真正拉开差距的不是"会不会写一行代码"，而是"能不能把系统做出来并跑起来"。写小说也是一样。

我不敢说 sumeru 已经成熟到可以让所有人"躺着当大神"，但至少它让我验证了一件事：

当创作被 skill 化之后，完成一部长篇这件事，会变得更像工程，而不是玄学。

《古物记》小说我已经放在 opennovel.zxs.io 了，欢迎你去看、去喷。Sumeru 也已经在 GitHub 开源：https://github.com/xindoo/sumeru，也欢迎反馈问题。