为什么开始

两年前我在用 AI 写网文。GPT 能写出不错的段落，但写到 50 章它就忘了主角为什么复仇。每开一个新对话，要把设定、前文、角色关系重新喂一遍，token 烧得心疼。

伏笔更惨。第 12 章埋的吊坠，到第 47 章该回收了，我自己都忘了，AI 更不可能记得。写完一章还得手动提醒它"更新角色状态""检查弧线进度"。

试过市面上的工具——要么是 SaaS，数据上云不放心；要么只是 prompt 模板的封装，没有真正的状态管理。

于是决定自己做一个。核心思路很简单：不是给 AI 一个更好的 prompt，而是给 AI 一套它能自己查询和维护的结构化记忆。

这个项目叫 Goink。

技术选型

选型没有花哨的：

• Go + Wails v2：桌面应用，单文件分发，启动快。不需要 Electron 的资源开销
• React 19 + TypeScript：前端生态成熟，Monaco Editor 和 G6 图可视化都有现成集成
• SQLite：结构化记忆的存储，ACID 保障，零配置
• ONNX Runtime：本地语义搜索的推理引擎，不需要 GPU
• Git：内置版本控制，每个小说是独立仓库

没有用任何云服务。所有数据在本地——这是做长篇写作工具的前提，作者不会接受把几十万字的稿子放云端。

核心设计：六维结构化记忆

这不是一个 chatbot 套壳。Goink 给 AI 提供了六个维度的结构化数据，AI 在对话中自主查询和维护：

1. 角色关系：有向图。A 对 B 和 B 对 A 是两条独立记录，关系变化时旧记录保留，可以回顾演变过程
2. 伏笔追踪：每条伏笔有目标章节和重要度。写新章节时自动注入近处伏笔的完整详情和远处伏笔的压缩索引
3. 故事弧线：有序节点链，写完一章自动推进。一个故事通常 3-5 条并行弧线
4. 地点图谱：层级包含 + 空间连通，不是扁平列表
5. 读者认知：已知/悬念/误解三态，控制信息释放节奏，防止"不小心暴露关键信息"
6. 创作偏好：全局 + 每本小说双层，写到第 37 章依然生效

这些数据存在 SQLite 里，跨对话永久保留。AI 不是靠对话窗口的上下文"记住"这些，是靠查数据库。

31 个工具：AI 的手和眼

给 LLM 提供了 31 个 Function Calling 工具，覆盖写作全流程——读文件、写文件、语义搜索、角色 CRUD、伏笔管理、弧线推进、地点查询、读者认知设置、创作偏好、章节管理、子 Agent 调度、web 搜索。

核心是一个 ReAct 循环：LLM 拿到上下文后，自主决定调用哪个工具、传什么参数、下一步做什么。不是 pipeline 式的"大纲 Agent → 正文 Agent → 润色 Agent"——那种设计信息在每一步都在丢失。Goink 的 Agent 在一个连续上下文里完成所有操作。

用户: 写第37章

Agent 内部:
  → 查角色状态 → 搜前文线索 → 查伏笔 → 读上一章 → 写正文 → 更新角色 → 推进弧线 → 自检

还有子 Agent 系统：审稿 Agent 做四维检查（角色一致性/情节逻辑/伏笔管理/读者认知），记忆 Agent 做多维度检索。Sub-agent 的工具调用对主 Agent 不可见，只有最终报告回传，不污染主写作上下文。

本地语义搜索：几十万字里找一句话

这是开发过程中花时间最多的一块。

写到第 50 章，主角见到一个吊坠，AI 需要确认"这个吊坠第一次出现是第几章"。调 search_story_memory("吊坠的来历")，1 秒返回最相关段落——不是关键词匹配，是按语义搜索。

技术栈：BGE-small-zh-v1.5 int8 量化，ONNX Runtime 本地 CPU 推理，sqlite-vec 做向量索引。中文感知分句（在句号感叹号处切分），420 token 窗口，50 重叠。混合搜索三路并发：实体名模糊 + 正文精确 + 语义搜索。

最麻烦的是增量索引——写完章节后台自动刷新，但要去重合并 500ms 内的重复任务，否则连点几次保存会触发多次索引重建。

整套引擎不需要网络、不需要 GPU。一个安装包，打开就用。

Diff 审批：AI 不会直接改你的稿

默认 AI 不会直接修改正文。每次编辑生成 Diff，Monaco Editor 展示对比，用户批准后写入。写入前还会重读文件比对——如果审批期间文件被其他程序改了，拒绝写入，防止覆盖手动修改。

也有自动模式，AI 连续多轮自由写作，适合信任 AI 发挥的场景。

Git 内置：每次对话自动提交

每个小说是独立 git 仓库。每次对话自动 commit，commit message 包含 session ID 和模型名。支持按 turn 粒度回退——DB 元数据 + git revert 同步原子操作。

"AI 写了一堆东西，我想回到三天前的版本"——这个场景在实际使用中比想象中频繁。

Skill 系统：Markdown 文件即方法论

12 个内置写作技能（场景节拍、对白潜台词、节奏控制、悬念钩子等），/技能名 一键加载。自定义 Skill 只需创建 Markdown 文件放到 ~/.goink/skills/，系统热加载。三层覆盖：小说级 > 用户级 > 内置级。

后来又做了技能市场——社区仓库 sigpanic/goink-skills，App 内浏览、搜索、一键安装。你写的好套路，别人一键就能用。

一些数字

• 安装包 < 60MB，零外部依赖
• 31 个 Function Calling 工具
• 7 个内置 LLM Provider 模板（DeepSeek/GLM/MiniMax/MiMo/Kimi/Qwen/豆包）
• 12 个内置写作技能 + 社区技能市场
• 6 套可视化面板（角色关系图/地点图谱/弧线泳道图等）
• AGPL v3 开源

开发过程中的一些感受

最难的不是技术，是产品决策。 比如"AI 应该自动维护记忆还是等用户提醒"——一开始做成自动的，后来发现用户需要控制感，又加了审批流程。再比如"伏笔应该怎么注入"——全量注入会淹没上下文，最终做成近处完整 + 远处索引的两级方案。

Go + Wails 是个好组合。 单文件分发，启动快，内存占用低。唯一痛点是 CGO——ONNX Runtime 和 sqlite-vec 都需要 cgo，交叉编译比较麻烦。

本地优先是个正确的选择。 写作工具的用户对隐私敏感，数据在本地是个硬需求。虽然开发成本比 SaaS 高（要处理本地文件、本地索引、本地推理），但产品定位更清晰。

项目信息

• GitHub：github.com/sigpanic/goink
• 技能市场：github.com/sigpanic/goink-skills
• 协议：AGPL v3
• 平台：Windows / macOS / Linux
• 安装包：< 60MB，零依赖

如果你也在用 AI 写长文，被"写到后面忘了前面"折磨过，欢迎试试。