作为一名程序员，我以前一直觉得，"完成一个大型项目"这件事，本质上是两种能力的叠加：
- 硬技能：你会不会写代码、会不会用工具；
- 软能力：你能不能把大问题拆成小问题，然后持续推进。
前两年 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 化带来的变化是：把"玄学式创作"变成"工程式推进"——
| 阶段 | 核心关注点 |
|---|---|
| 选题阶段 | 不是"我喜欢"，而是"它是否有卖点、有受众、有平台适配" |
| 大纲阶段 | "剧情结构能不能支撑长跑"，而不是"开头够不够炸" |
| 写作阶段 | 节奏与爽点排布，而不是某一段辞藻 |
| 审查阶段 | 一致性校验与修复机制，而不是事后读者骂了才回头找 bug |
说人话就是：把"写作"当成一个可以迭代的系统，而不是一次性灵感发挥。
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，也欢迎反馈问题。