企业官网建设流程全解析

简介：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 人物卡也可以纳入版本管理。

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文件，用户双击即可安装。这个流程是我用了三个月才稳定下来的：最初插件直接在全局环境运行，一崩就崩整个应用，后来改成沙箱脚本，才开始敢让用户跨平台自由分享插件。

写完《雾城谜案》第一卷之后，复盘时我最大的体会是：这类工具真正的价值不在某个炫酷的图谱，而在“设定与正文保持同频”。我用人物卡维护了一次关系，后面每次写对手戏，侧栏都能把关系相关的事件调出来，这省掉的不是搜资料的时间，而是从写作状态里跳出来再回去的切换成本。如果你现在正被“写到后期设定打架”困扰，建议别急着换软件，先把你手头的小说人物和地点整理成卡片，哪怕用文件夹加文本文件都行。结构清晰了，写起来自然就顺了。

本文还有配套的精品资源，点击获取