简介WordTree是一款专为中文作家打造的跨平台小说创作集成开发环境面向需要构建复杂人物关系与宏大世界观的网文作者、出版作者以及写作工具研究者。这一压缩包共包含432个文件整体大小约31.45MB文件构成以Java与Kotlin编写的源码为主体同时辅以SVG、PNG格式的界面图标、CSS样式、JSON配置以及可直接运行的exe与jar程序包和gradle跨平台构建脚本兼顾源码阅读与实际使用。目前已有六十人学习下载。功能方面覆盖人物关系图谱、世界观地图构建、富文本素材管理、智能文本提示、任务进度追踪、写作数据统计和插件扩展系统读者可以借此了解完整写作平台的模块划分、数据存储思路与插件机制设计也可以作为个人二次开发的脚手架适合中文小说创作者、写作工具爱好者以及有Java或Kotlin基础的程序员参考学习。 很早以前我就意识到一件事写长篇小说的难度有一半不在“写”而在“记”。几十号人物、四五个势力、横跨几十年的时间线写到第三卷的时候读者可能记得住情节我却经常想不起来某个配角上一次出场戴的是什么颜色的玉佩。市面上的写作软件要么是纯文本编辑器要么是逻辑简单的目录树人物卡、时间线、世界设定全是各管各的。所以我动手做了 WordTree——一款跨平台小说创作IDE今天把整个项目的核心设计、踩坑经历和实操流程一次讲清楚。它解决的核心问题不是“让你写得更快”而是“在你写长之后依然不会乱”。如果你正在写长篇网文、实体小说或者只是手头堆着大量设定资料这篇文章应该能帮你理解这类工具到底应该怎么设计以及如何真正用起来。1. 为什么做 WordTree长篇写作的真实痛点1.1 传统写作工具的短板传统工具分两类。一类是 Word 或 WPS 这种通用文档另一类是笔记软件。Word 的优势是排版和批注但它的信息组织方式是线性的适合论文不太适合小说。小说有“人物”“地点”“事件”“物品”这些实体它们之间的关系是一张网线性文档很难承载。笔记软件虽然有了标签和双向链接但标签体系用久了会失控双链也是手动维护写到中后期光整理链接就够你喝一壶。更麻烦的是写作过程本身是有状态的。我今天写的是第 37 章这章需要用到 3 个伏笔、6 个出场人物其中 2 个人说了违心话一个地点首次出现。这些上下文信息如果在写作时不能一眼看到就得来回翻设定集思路很容易断。我见过很多作者用一堆表格来管理人物表、地点表、事件表各一个最后表格之间对不上号连“这个人到底是哪一派的”都要翻半天。1.2 什么样的人适合用 WordTree我在设计时的定位是面向“以角色和世界驱动”的长篇作者尤其是中文语境下的网文作者、轻小说作者和实体书作者。如果你写的是短篇三五千字一个场景那不需要这么重的工具一个记事本足够了。但如果你有三卷以上的计划主要角色超过十人或者世界观里有明确的势力、地点和年代设定那 WordTree 的价值就会显现出来。这里多说一句我也刻意避开了一部分用户不喜欢在写作前做任何规划的人。WordTree 不是要强迫你先写大纲它的默认界面只有一个写作区和素材侧栏你用不用人物图谱、世界观地图完全自主。工具可以做得很重但使用路径应该保持轻量。这个取舍很重要后面讲界面设计时还会再提。2. 技术选型与整体架构2.1 跨平台框架选择Electron 与 Tauri 之间标题里写了“跨平台”所以我最开始就在 Electron 和 Tauri 之间纠结。Electron 生态成熟Node.js 插件多团队上手快。Tauri 体积小、内存占用低客户端由 Rust 编写但生态相对年轻。对一个写作工具来说内存占用非常关键——写作时旁边还要开查资料窗口一个动辄吃 500MB 内存的编辑器会让很多用户直接放弃。实测下来Electron 的冷启动在 3 秒左右Tauri 可以做到 1 秒内。但 Tauri 的坑在于 WebView 的跨平台差异Windows 上的 WebView2 和 macOS 的 WKWebView 在富文本渲染上表现不一致。最终我选择了 Electron 做主力构建原因不是性能而是富文本编辑器和拖拽图谱的兼容性这两个是 WordTree 的核心容不得半点偏差。这个选择也提醒我在技术选型里快的不一定是对的稳定兼容才是写作工具的第一诉求。2.2 本地优先的数据存储方案WordTree 的核心原则是“本地优先”。所有章节正文以 Markdown 文件存储人物卡、地点卡、关系数据以 JSON 文件存储素材库的富文本内容则保存在 SQLite 里。为什么不用云端数据库因为写作数据是最不应该被平台绑定的资产。用户今天用 WordTree三年后完全可以手动把 Markdown 文件导入别的工具不带一点心理负担。但纯文件模式也有问题。人物关系图谱需要频繁读取 JSON、并做全图计算文件越多效率越低。所以我在本地启动一个轻量索引层启动时扫描项目目录建立内存索引关系图只操作内存数据改动落盘时采用原子写入先写临时文件再替换防止写一半断电导致文件损坏。这个方案比数据库简单又能保证大部分操作都在毫秒级完成。2.3 插件扩展系统的边界划分插件系统是 WordTree 架构里最让我纠结的部分。标题里写了“插件扩展系统”说明它不只是附加功能而是核心卖点。但插件能做什么不能做什么必须划清边界。我的做法是把能力分成三类第一类编辑器增强。比如统计字数、替换选中文本、插入模板、自定义快捷键这些通过编辑器的扩展 API 暴露。第二类内容分析。比如读取当前章节、查询人物卡、生成数据报表这类插件只能读不能改核心数据防止插件把关系图谱的数据搞坏。第三类外部服务。比如把章节导出为 Epub、同步到某个网盘、调用本地模型做续写建议这类必须显式声明网络权限安装时就要用户确认。这个边界划分避免了插件系统的常见灾难——一个不靠谱的插件把整个项目的数据结构改乱了。我宁可插件能力弱一点也要保证核心数据安全。插件运行在独立的沙箱脚本环境里不能直接访问文件系统只能通过 WordTree 暴露的 API 操作。3. 核心功能拆解与实现思路3.1 人物关系图谱从文档到可视化最能体现 WordTree 特色的是人物关系图谱。实现上它不要求用户画图而是从人物卡中自动提取关系。每个人物卡里有一个“关系”字段填的是“张川师父人物标签城府深”图谱模块读取所有人物卡后以人物为节点、以关系为边进行力导向布局。这里的难点是布局算法。小说早期人物少没问题写到后期几十个人物时力导向图节点会互相重叠。我加了两个处理第一是分类分区按人物的阵营比如门派、家族分区域着色同阵营节点在地图上互相靠近第二是关系强度权重关系描述里带“师徒”“父子”“仇敌”等关键词时边的长度会自动调整关系越强距离越近。这样生成的图谱虽然不完美但比手工画快得多而且人物卡更新后图谱自动更新永远同步。注意人物关系图谱的价值不是“好看”而是“一眼看出谁和谁不该同场出现”。我写悬疑时经常用它排查逻辑漏洞比如某个角色在第三章就已经死了结果第十章又出现图谱一查就露馅。3.2 世界观地图构建世界观地图分两层一层是地理信息一层是时间线。地理信息不是要求用户上传高分地图图片而是提供一组可自由排布的“地点卡”。每张地点卡可以设置坐标、归属势力、气候、相关事件图谱视图里会把地点按势力着色。这样做的好处是假设你写到一个城市侧栏会立刻显示这个城市的所有历史事件和相关人物不需要再翻设定集。时间线则是按事件日期排列的序列。写奇幻或科幻时时间线尤其重要因为日历可能是虚构的。WordTree 允许自定义纪元和月份名称事件可以挂在自定义日期上并在写作区通过悬浮面板快速查看。我见过最夸张的用法是一个作者把整本小说每个角色的年龄按虚构历做了自动计算每次提到“他今年三十岁”之前先用 WordTree 确认一下那个时间点角色到底多大。3.3 富文本素材库与双向引用素材库是富文本管理的核心场景。网文作者经常需要收集灵感和素材比如怪物图鉴、武器设定、国家科技水平。这些内容往往不是纯文字会有表格、图片、加粗标题。所以我直接把素材编辑器做成了富文本编辑器而不是 Markdown这样用户可以直接粘贴网页截图调整表格标注重点。同时素材库支持“双向引用”。也就是说在一张地点卡里引用某件宝物时会形成一个链接打开宝物卡时也能看到“被哪些地点、人物引用过”。这个功能的意义在于写作时你不一定会主动想起某个老设定但双向链接能顺着写作路径把相关素材浮上来。我在写第二卷时就是靠这个功能捞出了一卷里埋的伏笔避免了三卷前后的细节冲突。3.4 智能文本提示与写作数据统计“智能文本提示”我一开始想做得很玄比如续写建议但试下来发现现有本地模型续写质量不稳定而调用云端大模型又涉及联网和隐私。最后我选了一条务实的路基于当前章节内容的实时上下文提示。比如你写到了“他推开门”工具会从素材库中检索与当前位置、当前人物相关的形容词、环境细节、之前出现过的物品减少“推开门”之后卡壳的概率。写作数据统计则是反向给作者反馈。它能统计每日字数、连续写作天数、各章节耗时还能分析高频词、重复词。重复词分析是我用得最多的中文写作容易不自觉地重复“然后”“可是”统计面板会把前二十个高频词列出来我每隔几章就扫一眼把多余的删掉。这类数据不需要复杂算法SQLite 里存着每次输入的日志聚合查询就能出结果。4. 实操从新建项目到写完一章4.1 新建项目与目录结构实操部分拿一个具体案例走一遍。打开 WordTree点击“新建项目”输入项目名称“雾城谜案”选择默认模板。创建后项目目录自动生成雾城谜案/ ├── novel/ # 章节文件Markdown │ └── 第一卷/ │ └── 001_雨夜来客.md ├── characters/ # 人物卡JSON ├── locations/ # 地点卡JSON ├── events/ # 事件/时间线JSON ├── assets/ # 素材库富文本 ├── stats/ # 统计数据 └── project.json # 项目配置这个结构是公开的用户可以直接用文件管理器查看。很多作者第一次看到后会说“原来数据都在这”这也是我想达到的效果让用户对自己的数据有掌控感。4.2 建人物卡并生成关系图接下来我创建三个初始人物林远侦探、苏晴记者、周海警长。每个人物卡里填上“关系”字段比如林远的卡片里写“苏晴伙伴经常一起查案”苏晴的卡片里写“周海线人消息灵通”。保存后进入“关系图谱”页面点“重新生成”三个人物就自动出现在画布上连线是“伙伴”和“线人”。如果后面新增一个人物“陈默”并在他的卡里备注“林远敌手”图谱会自动多出一条边不需要手动编辑任何画布信息。这是 WordTree 关系图谱最核心的使用习惯维护数据而不是维护图片。4.3 写作区实战侧栏引用与实时提示写第一章时我在写作区输入“林远站在”四个字侧栏立刻出现提示人物卡里林远的身份描述、与他相关的伙伴苏晴、他常用的动作词列表。接着我打开苏晴的人物卡点击“新建事件”按钮直接在卡里记录“第一场苏晴在咖啡馆递上线索”这一幕在时间线上自动生成。写完一章后统计面板显示我实际用了 2 小时总字数约 2200重复词组里“然后”出现了 7 次我手动删到 2 次。整个流程走下来最明显的感觉是查找资料的动作变少了因为素材和设定永远停在手边。5. 踩坑记录与排查清单5.1 关系图谱布局混乱最常见的问题是人物多了以后图谱挤成一团。排查思路是三个一查人物卡数量是否超过 80二查是否所有人物都填了阵营字段三查是否存在孤立节点。我常用的优化方式是给重要角色设置“固定位置”次要角色交给自动布局。实测下来固定 20% 的核心角色剩余让算法自动排图谱可阅读性提升最明显。5.2 富文本渲染差异标题里写“富文本”实际项目里最容易出兼容性问题的是表格和图片粘贴。我在 Windows 上从浏览器复制带格式文本进素材库偶尔会带进一堆内联样式导致界面错乱。后来做了粘贴清洗统一转为内联样式白名单过滤掉多余的字体和颜色再落库。如果你是从网页复制资料建议先用“无格式粘贴”再手动加粗也顺手规避了这个问题。5.3 插件 API 兼容性插件系统上线后我发现有用户反馈插件在 Windows 上正常、macOS 上报错。排查下来是 API 里我用到了跨平台不一致的路径拼接方式。后来插件 API 统一封装了路径读写接口禁止插件直接用原生路径字符串拼文件位置问题基本消失。这也是前面说“插件只能走受限 API”这个设计带来的回报——虽然限制了能力但大幅降低了兼容性问题的排查成本。5.4 数据备份与恢复建议虽然 WordTree 本地优先但本地数据也有风险。我给出的建议是项目目录本身就是备份单元直接用 Git 管理最靠谱。每个章节是一个 Markdown 文件每次保存后提交一次这样不仅可以回滚还能看到每天的写作量变化。JSON 人物卡也可以纳入版本管理。问题处理方式字数统计与平台不一致统计口径可在设置里切换默认不统计标点和空白关系图谱空白检查人物卡 JSON 是否符合 schema用内置“数据体检”修复素材库图片显示异常图片默认复制到项目 assets 目录避免引用外部绝对路径插件冲突插件列表可单独禁用先用二分法禁用一半排查6. 给想写插件的人最小可用示例6.1 插件目录结构插件系统带的最小示例插件就是放在plugins/目录下的一个文件夹plugins/my-word-count/ ├── manifest.json # 插件声明 └── index.js # 主逻辑manifest.json 里声明插件名称、入口文件、所需权限。index.js 里通过WordTreeAPI操作编辑器。以下是一个统计当前章节关键词密度的示例// manifest.json { name: keyword-density, version: 1.0.0, entry: index.js, permissions: [editor:read, editor:insert] }// index.js const { editor, ui } WordTreeAPI; function computeDensity(keyword) { const text editor.getCurrentChapter(); const count text.split(keyword).length - 1; const total text.replace(/\s/g, ).length; return { count, density: (count * 100 / total).toFixed(2) % }; } ui.addCommand(关键词密度, () { const keyword ui.prompt(输入要统计的关键词); if (!keyword) return; const result computeDensity(keyword); ui.notify(「${keyword}」出现 ${result.count} 次密度 ${result.density}); });6.2 插件的安装与调试开发时插件目录可以软链到项目目录保存后点“重载插件”即可生效。发布时WordTree 支持把整个文件夹打包成.wtplugin文件用户双击即可安装。这个流程是我用了三个月才稳定下来的最初插件直接在全局环境运行一崩就崩整个应用后来改成沙箱脚本才开始敢让用户跨平台自由分享插件。写完《雾城谜案》第一卷之后复盘时我最大的体会是这类工具真正的价值不在某个炫酷的图谱而在“设定与正文保持同频”。我用人物卡维护了一次关系后面每次写对手戏侧栏都能把关系相关的事件调出来这省掉的不是搜资料的时间而是从写作状态里跳出来再回去的切换成本。如果你现在正被“写到后期设定打架”困扰建议别急着换软件先把你手头的小说人物和地点整理成卡片哪怕用文件夹加文本文件都行。结构清晰了写起来自然就顺了。本文还有配套的精品资源点击获取 WordTree：跨平台小说创作IDE，让长篇写作不再混乱
简介WordTree是一款专为中文作家打造的跨平台小说创作集成开发环境面向需要构建复杂人物关系与宏大世界观的网文作者、出版作者以及写作工具研究者。这一压缩包共包含432个文件整体大小约31.45MB文件构成以Java与Kotlin编写的源码为主体同时辅以SVG、PNG格式的界面图标、CSS样式、JSON配置以及可直接运行的exe与jar程序包和gradle跨平台构建脚本兼顾源码阅读与实际使用。目前已有六十人学习下载。功能方面覆盖人物关系图谱、世界观地图构建、富文本素材管理、智能文本提示、任务进度追踪、写作数据统计和插件扩展系统读者可以借此了解完整写作平台的模块划分、数据存储思路与插件机制设计也可以作为个人二次开发的脚手架适合中文小说创作者、写作工具爱好者以及有Java或Kotlin基础的程序员参考学习。 很早以前我就意识到一件事写长篇小说的难度有一半不在“写”而在“记”。几十号人物、四五个势力、横跨几十年的时间线写到第三卷的时候读者可能记得住情节我却经常想不起来某个配角上一次出场戴的是什么颜色的玉佩。市面上的写作软件要么是纯文本编辑器要么是逻辑简单的目录树人物卡、时间线、世界设定全是各管各的。所以我动手做了 WordTree——一款跨平台小说创作IDE今天把整个项目的核心设计、踩坑经历和实操流程一次讲清楚。它解决的核心问题不是“让你写得更快”而是“在你写长之后依然不会乱”。如果你正在写长篇网文、实体小说或者只是手头堆着大量设定资料这篇文章应该能帮你理解这类工具到底应该怎么设计以及如何真正用起来。1. 为什么做 WordTree长篇写作的真实痛点1.1 传统写作工具的短板传统工具分两类。一类是 Word 或 WPS 这种通用文档另一类是笔记软件。Word 的优势是排版和批注但它的信息组织方式是线性的适合论文不太适合小说。小说有“人物”“地点”“事件”“物品”这些实体它们之间的关系是一张网线性文档很难承载。笔记软件虽然有了标签和双向链接但标签体系用久了会失控双链也是手动维护写到中后期光整理链接就够你喝一壶。更麻烦的是写作过程本身是有状态的。我今天写的是第 37 章这章需要用到 3 个伏笔、6 个出场人物其中 2 个人说了违心话一个地点首次出现。这些上下文信息如果在写作时不能一眼看到就得来回翻设定集思路很容易断。我见过很多作者用一堆表格来管理人物表、地点表、事件表各一个最后表格之间对不上号连“这个人到底是哪一派的”都要翻半天。1.2 什么样的人适合用 WordTree我在设计时的定位是面向“以角色和世界驱动”的长篇作者尤其是中文语境下的网文作者、轻小说作者和实体书作者。如果你写的是短篇三五千字一个场景那不需要这么重的工具一个记事本足够了。但如果你有三卷以上的计划主要角色超过十人或者世界观里有明确的势力、地点和年代设定那 WordTree 的价值就会显现出来。这里多说一句我也刻意避开了一部分用户不喜欢在写作前做任何规划的人。WordTree 不是要强迫你先写大纲它的默认界面只有一个写作区和素材侧栏你用不用人物图谱、世界观地图完全自主。工具可以做得很重但使用路径应该保持轻量。这个取舍很重要后面讲界面设计时还会再提。2. 技术选型与整体架构2.1 跨平台框架选择Electron 与 Tauri 之间标题里写了“跨平台”所以我最开始就在 Electron 和 Tauri 之间纠结。Electron 生态成熟Node.js 插件多团队上手快。Tauri 体积小、内存占用低客户端由 Rust 编写但生态相对年轻。对一个写作工具来说内存占用非常关键——写作时旁边还要开查资料窗口一个动辄吃 500MB 内存的编辑器会让很多用户直接放弃。实测下来Electron 的冷启动在 3 秒左右Tauri 可以做到 1 秒内。但 Tauri 的坑在于 WebView 的跨平台差异Windows 上的 WebView2 和 macOS 的 WKWebView 在富文本渲染上表现不一致。最终我选择了 Electron 做主力构建原因不是性能而是富文本编辑器和拖拽图谱的兼容性这两个是 WordTree 的核心容不得半点偏差。这个选择也提醒我在技术选型里快的不一定是对的稳定兼容才是写作工具的第一诉求。2.2 本地优先的数据存储方案WordTree 的核心原则是“本地优先”。所有章节正文以 Markdown 文件存储人物卡、地点卡、关系数据以 JSON 文件存储素材库的富文本内容则保存在 SQLite 里。为什么不用云端数据库因为写作数据是最不应该被平台绑定的资产。用户今天用 WordTree三年后完全可以手动把 Markdown 文件导入别的工具不带一点心理负担。但纯文件模式也有问题。人物关系图谱需要频繁读取 JSON、并做全图计算文件越多效率越低。所以我在本地启动一个轻量索引层启动时扫描项目目录建立内存索引关系图只操作内存数据改动落盘时采用原子写入先写临时文件再替换防止写一半断电导致文件损坏。这个方案比数据库简单又能保证大部分操作都在毫秒级完成。2.3 插件扩展系统的边界划分插件系统是 WordTree 架构里最让我纠结的部分。标题里写了“插件扩展系统”说明它不只是附加功能而是核心卖点。但插件能做什么不能做什么必须划清边界。我的做法是把能力分成三类第一类编辑器增强。比如统计字数、替换选中文本、插入模板、自定义快捷键这些通过编辑器的扩展 API 暴露。第二类内容分析。比如读取当前章节、查询人物卡、生成数据报表这类插件只能读不能改核心数据防止插件把关系图谱的数据搞坏。第三类外部服务。比如把章节导出为 Epub、同步到某个网盘、调用本地模型做续写建议这类必须显式声明网络权限安装时就要用户确认。这个边界划分避免了插件系统的常见灾难——一个不靠谱的插件把整个项目的数据结构改乱了。我宁可插件能力弱一点也要保证核心数据安全。插件运行在独立的沙箱脚本环境里不能直接访问文件系统只能通过 WordTree 暴露的 API 操作。3. 核心功能拆解与实现思路3.1 人物关系图谱从文档到可视化最能体现 WordTree 特色的是人物关系图谱。实现上它不要求用户画图而是从人物卡中自动提取关系。每个人物卡里有一个“关系”字段填的是“张川师父人物标签城府深”图谱模块读取所有人物卡后以人物为节点、以关系为边进行力导向布局。这里的难点是布局算法。小说早期人物少没问题写到后期几十个人物时力导向图节点会互相重叠。我加了两个处理第一是分类分区按人物的阵营比如门派、家族分区域着色同阵营节点在地图上互相靠近第二是关系强度权重关系描述里带“师徒”“父子”“仇敌”等关键词时边的长度会自动调整关系越强距离越近。这样生成的图谱虽然不完美但比手工画快得多而且人物卡更新后图谱自动更新永远同步。注意人物关系图谱的价值不是“好看”而是“一眼看出谁和谁不该同场出现”。我写悬疑时经常用它排查逻辑漏洞比如某个角色在第三章就已经死了结果第十章又出现图谱一查就露馅。3.2 世界观地图构建世界观地图分两层一层是地理信息一层是时间线。地理信息不是要求用户上传高分地图图片而是提供一组可自由排布的“地点卡”。每张地点卡可以设置坐标、归属势力、气候、相关事件图谱视图里会把地点按势力着色。这样做的好处是假设你写到一个城市侧栏会立刻显示这个城市的所有历史事件和相关人物不需要再翻设定集。时间线则是按事件日期排列的序列。写奇幻或科幻时时间线尤其重要因为日历可能是虚构的。WordTree 允许自定义纪元和月份名称事件可以挂在自定义日期上并在写作区通过悬浮面板快速查看。我见过最夸张的用法是一个作者把整本小说每个角色的年龄按虚构历做了自动计算每次提到“他今年三十岁”之前先用 WordTree 确认一下那个时间点角色到底多大。3.3 富文本素材库与双向引用素材库是富文本管理的核心场景。网文作者经常需要收集灵感和素材比如怪物图鉴、武器设定、国家科技水平。这些内容往往不是纯文字会有表格、图片、加粗标题。所以我直接把素材编辑器做成了富文本编辑器而不是 Markdown这样用户可以直接粘贴网页截图调整表格标注重点。同时素材库支持“双向引用”。也就是说在一张地点卡里引用某件宝物时会形成一个链接打开宝物卡时也能看到“被哪些地点、人物引用过”。这个功能的意义在于写作时你不一定会主动想起某个老设定但双向链接能顺着写作路径把相关素材浮上来。我在写第二卷时就是靠这个功能捞出了一卷里埋的伏笔避免了三卷前后的细节冲突。3.4 智能文本提示与写作数据统计“智能文本提示”我一开始想做得很玄比如续写建议但试下来发现现有本地模型续写质量不稳定而调用云端大模型又涉及联网和隐私。最后我选了一条务实的路基于当前章节内容的实时上下文提示。比如你写到了“他推开门”工具会从素材库中检索与当前位置、当前人物相关的形容词、环境细节、之前出现过的物品减少“推开门”之后卡壳的概率。写作数据统计则是反向给作者反馈。它能统计每日字数、连续写作天数、各章节耗时还能分析高频词、重复词。重复词分析是我用得最多的中文写作容易不自觉地重复“然后”“可是”统计面板会把前二十个高频词列出来我每隔几章就扫一眼把多余的删掉。这类数据不需要复杂算法SQLite 里存着每次输入的日志聚合查询就能出结果。4. 实操从新建项目到写完一章4.1 新建项目与目录结构实操部分拿一个具体案例走一遍。打开 WordTree点击“新建项目”输入项目名称“雾城谜案”选择默认模板。创建后项目目录自动生成雾城谜案/ ├── novel/ # 章节文件Markdown │ └── 第一卷/ │ └── 001_雨夜来客.md ├── characters/ # 人物卡JSON ├── locations/ # 地点卡JSON ├── events/ # 事件/时间线JSON ├── assets/ # 素材库富文本 ├── stats/ # 统计数据 └── project.json # 项目配置这个结构是公开的用户可以直接用文件管理器查看。很多作者第一次看到后会说“原来数据都在这”这也是我想达到的效果让用户对自己的数据有掌控感。4.2 建人物卡并生成关系图接下来我创建三个初始人物林远侦探、苏晴记者、周海警长。每个人物卡里填上“关系”字段比如林远的卡片里写“苏晴伙伴经常一起查案”苏晴的卡片里写“周海线人消息灵通”。保存后进入“关系图谱”页面点“重新生成”三个人物就自动出现在画布上连线是“伙伴”和“线人”。如果后面新增一个人物“陈默”并在他的卡里备注“林远敌手”图谱会自动多出一条边不需要手动编辑任何画布信息。这是 WordTree 关系图谱最核心的使用习惯维护数据而不是维护图片。4.3 写作区实战侧栏引用与实时提示写第一章时我在写作区输入“林远站在”四个字侧栏立刻出现提示人物卡里林远的身份描述、与他相关的伙伴苏晴、他常用的动作词列表。接着我打开苏晴的人物卡点击“新建事件”按钮直接在卡里记录“第一场苏晴在咖啡馆递上线索”这一幕在时间线上自动生成。写完一章后统计面板显示我实际用了 2 小时总字数约 2200重复词组里“然后”出现了 7 次我手动删到 2 次。整个流程走下来最明显的感觉是查找资料的动作变少了因为素材和设定永远停在手边。5. 踩坑记录与排查清单5.1 关系图谱布局混乱最常见的问题是人物多了以后图谱挤成一团。排查思路是三个一查人物卡数量是否超过 80二查是否所有人物都填了阵营字段三查是否存在孤立节点。我常用的优化方式是给重要角色设置“固定位置”次要角色交给自动布局。实测下来固定 20% 的核心角色剩余让算法自动排图谱可阅读性提升最明显。5.2 富文本渲染差异标题里写“富文本”实际项目里最容易出兼容性问题的是表格和图片粘贴。我在 Windows 上从浏览器复制带格式文本进素材库偶尔会带进一堆内联样式导致界面错乱。后来做了粘贴清洗统一转为内联样式白名单过滤掉多余的字体和颜色再落库。如果你是从网页复制资料建议先用“无格式粘贴”再手动加粗也顺手规避了这个问题。5.3 插件 API 兼容性插件系统上线后我发现有用户反馈插件在 Windows 上正常、macOS 上报错。排查下来是 API 里我用到了跨平台不一致的路径拼接方式。后来插件 API 统一封装了路径读写接口禁止插件直接用原生路径字符串拼文件位置问题基本消失。这也是前面说“插件只能走受限 API”这个设计带来的回报——虽然限制了能力但大幅降低了兼容性问题的排查成本。5.4 数据备份与恢复建议虽然 WordTree 本地优先但本地数据也有风险。我给出的建议是项目目录本身就是备份单元直接用 Git 管理最靠谱。每个章节是一个 Markdown 文件每次保存后提交一次这样不仅可以回滚还能看到每天的写作量变化。JSON 人物卡也可以纳入版本管理。问题处理方式字数统计与平台不一致统计口径可在设置里切换默认不统计标点和空白关系图谱空白检查人物卡 JSON 是否符合 schema用内置“数据体检”修复素材库图片显示异常图片默认复制到项目 assets 目录避免引用外部绝对路径插件冲突插件列表可单独禁用先用二分法禁用一半排查6. 给想写插件的人最小可用示例6.1 插件目录结构插件系统带的最小示例插件就是放在plugins/目录下的一个文件夹plugins/my-word-count/ ├── manifest.json # 插件声明 └── index.js # 主逻辑manifest.json 里声明插件名称、入口文件、所需权限。index.js 里通过WordTreeAPI操作编辑器。以下是一个统计当前章节关键词密度的示例// manifest.json { name: keyword-density, version: 1.0.0, entry: index.js, permissions: [editor:read, editor:insert] }// index.js const { editor, ui } WordTreeAPI; function computeDensity(keyword) { const text editor.getCurrentChapter(); const count text.split(keyword).length - 1; const total text.replace(/\s/g, ).length; return { count, density: (count * 100 / total).toFixed(2) % }; } ui.addCommand(关键词密度, () { const keyword ui.prompt(输入要统计的关键词); if (!keyword) return; const result computeDensity(keyword); ui.notify(「${keyword}」出现 ${result.count} 次密度 ${result.density}); });6.2 插件的安装与调试开发时插件目录可以软链到项目目录保存后点“重载插件”即可生效。发布时WordTree 支持把整个文件夹打包成.wtplugin文件用户双击即可安装。这个流程是我用了三个月才稳定下来的最初插件直接在全局环境运行一崩就崩整个应用后来改成沙箱脚本才开始敢让用户跨平台自由分享插件。写完《雾城谜案》第一卷之后复盘时我最大的体会是这类工具真正的价值不在某个炫酷的图谱而在“设定与正文保持同频”。我用人物卡维护了一次关系后面每次写对手戏侧栏都能把关系相关的事件调出来这省掉的不是搜资料的时间而是从写作状态里跳出来再回去的切换成本。如果你现在正被“写到后期设定打架”困扰建议别急着换软件先把你手头的小说人物和地点整理成卡片哪怕用文件夹加文本文件都行。结构清晰了写起来自然就顺了。本文还有配套的精品资源点击获取