长篇创作的难点并不只是生成某一段文字，而是让世界观、人物关系、大纲、章节正文与后续复盘等持续积累的信息在更新后仍能被准确调用。若这些信息散落在文档、笔记和聊天记录中，后续创作很容易出现设定遗漏、上下文断裂或改稿难以回溯的问题。
方案概览
织叙工作台将书架、世界设定、角色、组织、关系、大纲、章节和剧情复盘放入同一套 Web 工作台。作者可以先建立作品与设定，再进入章节写作与分析流程，使创作对象从非结构化文本延伸为可管理的数据集合。
项目采用 MIT 开源许可证发布，支持商业化使用，并允许在遵守许可证条款的前提下进行修改、分发与二次开发。
织叙工作台适合将 AI 放在既有创作流程中，而非将模型输出直接视为最终内容。世界观、人物卡和大纲先形成可编辑的上下文，章节创作、续写和分析则在这些结构化信息基础上展开。
系统架构
前端采用 React、TypeScript、Vite、Ant Design 与 Zustand，负责书架、设定维护、章节编辑和分析界面的交互状态。后端采用 FastAPI、PostgreSQL、SQLAlchemy 与 Alembic，承载业务接口、持久化模型和数据库迁移。
这种前后端分层使织叙工作台能够将创作内容、项目属性和系统配置分开处理。作品正文与设定资料进入数据库管理，界面状态留在前端协作层，模型调用参数则通过系统设置统一维护。对于需要在个人创作和小型团队协作之间切换的场景，这种边界有助于减少配置和内容数据的混杂。
关键实现
织叙工作台将长篇内容拆分为世界设定、角色、组织、职业、关系、大纲和章节等实体。关系图谱、亲密度、势力信息与角色档案构成可持续维护的设定网络；章节编辑则结合标题、视角、目标字数和写作风格等字段，承接正文创作过程。
AI 接入采用 OpenAI 兼容接口，模型、温度和生成参数由系统设置统一配置。这样可以把模型调用从页面逻辑中抽离，使章节创作、剧情分析和提示词模板复用同一套服务配置。提示词工坊与系统模板管理进一步把常见创作指令沉淀为可复用组件。
在较长作品中，织叙工作台可选用 Chroma 与 SentenceTransformers 建立向量记忆。该能力用于从既有设定、章节与资料中检索相关内容，再将其组织进当前任务的上下文。向量记忆的作用是辅助信息回查，不替代作者对设定和正文的最终判断。
部署与安全
织叙工作台支持 Docker Compose 部署，也支持前后端分开启动。容器化方式适合同时管理应用、数据库与依赖服务；本地开发可分别启动 FastAPI 服务和 Vite 前端，以便进行功能修改与接口调试。
部署时应将数据库密码、模型接口凭据和本地管理员账号放入环境变量管理，并设置强随机的会话密钥。生产环境应启用 HTTPS，并结合安全 Cookie 配置限制会话传输范围。邮件注册与 SMTP 属于可选能力，应按实际运营需求启用。
向量记忆首次使用时可能需要加载嵌入模型。部署环境可通过持久化缓存目录保留模型文件，避免重复加载；在离线或受限网络环境中，也应预先规划模型获取和缓存策略。织叙工作台在调用外部模型服务时会发送当前任务所需的上下文，因此模型服务选择、访问凭据和数据处理边界应纳入部署决策。
结语
织叙工作台的核心价值在于把长篇创作中的设定管理、正文生产和内容复盘组织为连续流程。对于需要维护复杂人物关系、章节结构和伏笔状态的项目，结构化数据与可选向量检索能够提供更稳定的上下文基础；对于需要私有化部署的团队，前后端分层和容器化方式也保留了较清晰的运行边界。
