1. 项目概述：一个为长篇创作而生的智能体系统

如果你尝试过用大模型写小说，尤其是写一部几万字甚至几十万字的长篇，大概率会遇到几个让人头疼的问题：写着写着主角名字变了、前面埋的伏笔后面忘了、世界观设定前后矛盾、或者写到第十章时，模型已经完全记不住第一章发生了什么。这些问题的根源，在于大多数基于对话的AI写作工具，本质上是一个“无状态的聊天窗口”，它没有为长篇、结构化的内容创作提供持久化、可管理的上下文支持。

WenShape（文枢）正是为了解决这些问题而生的。它不是一个简单的“AI写作助手”，而是一个 深度上下文感知的智能体创作系统 。它的核心设计理念，是把写一本小说这件事，从一个黑盒式的“一次性生成”，拆解成一个由多个智能体（Agents）协同、数据持久化存储、流程清晰可见的工程项目。我把它理解为一个为创作者打造的“集成开发环境”（IDE），只不过你编写的不是代码，而是故事。

这个项目最吸引我的地方在于它的“工程化”思维。它不满足于让模型“自由发挥”，而是通过一套严谨的架构——包括 编排器（Orchestrator）、智能体（Agents）、上下文引擎（Context Engine）和存储层（Storage） ——来组织整个创作流程。你的所有创作资产，如分卷结构、人物卡、世界观设定、章节摘要、关键事实，都被结构化为YAML、Markdown、JSONL等纯文本文件。这意味着你的整个项目可以用Git进行版本管理，可以长期维护，甚至可以像代码一样进行协作和迭代。

简单来说，文枢适合两类人：一是严肃的、希望利用AI辅助完成中长篇创作的作者，二是对AI应用架构、智能体编排和RAG（检索增强生成）技术在实际场景中落地感兴趣的技术开发者。它提供了一个绝佳的、功能完整的样板，展示了如何将前沿的AI能力与传统的、以文件为核心的创作流程深度融合。

2. 核心架构与设计哲学拆解

2.1 为什么是“智能体系统”而非“聊天机器人”？

这是理解文枢价值的关键。传统的AI写作工具，其交互模式是线性的、回合制的：你输入指令，模型返回文本。这种模式对于短篇或灵感迸发是有效的，但对于需要长期维护一致性的长篇创作，则力不从心。因为模型没有“记忆”能力，每次对话都是独立的，你需要不断地在提示词中重复人物设定、故事背景，效率低下且容易出错。

文枢采用了“智能体”（Agent）范式。在这里，智能体不是指一个无所不能的超级AI，而是指一系列具有特定职责的“功能模块”。例如：

• Writer Agent（写手智能体） ：负责根据指令和上下文生成新的章节草稿。
• Editor Agent（编辑智能体） ：负责对生成的草稿进行润色、审查逻辑一致性。
• Archivist Agent（档案员智能体） ：负责从生成的文本中提取关键事实（Fact），并存入知识库。

这些智能体由一个 Orchestrator（编排器） 统一调度。当你点击“生成下一章”时，编排器会启动一个工作流：它首先调用上下文引擎，检索与当前章节最相关的人物、世界观设定和过往事实；然后，它将检索到的上下文、你的指令以及预设的提示词模板打包，发送给Writer Agent；Writer Agent生成草稿后，编排器可能再调用Editor Agent进行润色；最后，Archivist Agent会扫描新生成的文本，提取出“A人物在B地点做了C事”这类结构化事实，存入事实库，供未来章节检索使用。

这种设计带来了几个根本性优势：

1. 职责分离 ：每个环节专注做好一件事，代码更清晰，也更容易针对单个环节进行优化或替换模型。
2. 流程可控 ：整个创作流程变得透明、可调试。你可以看到是哪个环节的输入输出导致了问题。
3. 状态持久化 ：所有中间产物和最终数据都保存在文件系统中，而非易失的对话内存里。

2.2 存储层设计：一切皆文件，拥抱版本控制

文枢的存储策略是其“可维护性”的基石。它没有使用数据库，而是将一切创作元素存储为纯文本文件。这种选择看似复古，实则非常高明。

让我们看看项目目录下一个典型的创作项目（ data/your_novel/ ）里有什么：

your_novel/
├── cards/
│   ├── characters/          # 人物卡，每个角色一个YAML文件
│   │   └── protagonist.yaml
│   └── world/              # 世界观卡，每个设定一个YAML文件
│       └── magic_system.yaml
├── volumes/                # 分卷定义
│   └── volume_1.yaml
├── summaries/              # 章节摘要
│   └── chapter_1_summary.yaml
├── drafts/                 # 章节草稿
│   └── chapter_1/
│       ├── draft_001.md    # 迭代草稿
│       └── final.md        # 最终定稿
├── canon/                  # 事实库
│   └── facts.jsonl         # 按行存储的事实条目
└── config.yaml             # 项目级配置

这种设计的精妙之处在于：

• 可读性与可编辑性 ：你可以直接用文本编辑器打开任何YAML或Markdown文件进行查看和修改，无需通过特定界面。
• 完美的版本控制 ：你可以用Git来管理整个项目文件夹。每一次人物设定的修改、每一版章节的迭代，都可以通过 git diff 清晰地看到变化，甚至可以回滚到任何一个历史版本。这对于需要反复修改的长篇创作来说是革命性的。
• 数据主权与迁移自由 ：你的作品完全掌握在自己手中，是一堆标准格式的文件。你可以随时将这些文件导入到任何其他兼容的系统，或者用脚本进行批量处理，没有任何锁定风险。
• 结构清晰 ：通过目录结构，项目的一级要素（人物、世界、章节、事实）被物理分隔开，强迫创作者进行结构化思考，避免了所有信息混杂在一个“聊天记录”里的混乱。

实操心得 ：刚开始你可能会觉得直接编辑YAML文件有点麻烦，不如在UI里点选直观。但一旦你习惯了用VS Code或任何你喜欢的编辑器同时打开人物卡和正在创作的章节，那种“一切尽在掌控”的感觉是无与伦比的。特别是当需要批量修改所有角色年龄，或者查找某个地名在所有章节中的出现情况时，几个简单的命令行工具（如 grep , sed ）或编辑器全局搜索就能搞定，效率远超在图形界面中手动操作。

2.3 上下文引擎：RAG在创作场景下的深度定制

RAG（检索增强生成）是解决大模型“遗忘”问题的关键技术。但通用的RAG方案（如简单的向量数据库检索）在小说创作场景下往往表现不佳。文枢的上下文引擎（ context_engine ）对此做了大量深度定制，是其“深度上下文感知”能力的核心。

它管理着多种类型的上下文源：

1. 事实库（Facts） ：从已创作文本中提取的结构化事实（谁，在何时何地，做了什么）。
2. 摘要（Summaries） ：章节摘要和分卷摘要，提供高层叙事脉络。
3. 卡片（Cards） ：人物卡、世界观卡、文风卡，提供静态设定。
4. 章节绑定（Chapter Binding） ：某些事实或设定可能只与特定章节强相关。

其检索逻辑远非简单的“语义相似度搜索”，而是融合了多种策略：

• BM25关键词检索 ：快速找到包含特定实体（如人名、地名）的条目。
• 实体增强 ：识别查询中的实体，并主动去查找与这些实体相关的事实和设定。
• 章节距离衰减（Chapter Distance Decay） ：这是文枢的一个关键创新。它认为，在小说中，距离当前创作章节越近的事件和事实，对当前生成的影响应该越大。例如，在写第15章时，第14章发生的事比第5章发生的事更重要。引擎会基于章节索引的差值，对检索到的事实进行权重衰减。这样既保证了近期上下文的强相关性，又不会完全丢弃远期的、但可能非常重要的核心设定（如世界观基石）。
• 预算与排序（Budgeting & Ranking） ：大模型的上下文窗口是有限的（如128K）。上下文引擎需要像一个精明的管家，从海量的潜在上下文中，挑选出最相关、最核心的一批，组合成一个不超过“预算”（Token数）的上下文包，送给模型。这涉及到复杂的排序和裁剪算法。

注意事项 ：理解上下文引擎的工作原理，对于调试生成内容的质量至关重要。如果你发现模型忽略了某个重要设定，不要只去修改提示词。首先应该去检查对应的“卡片”是否被正确创建和存储，然后可以尝试在创作时，通过界面手动将相关卡片“钉选”（Pin）到当前会话，强制将其加入上下文。这相当于给了上下文引擎一个明确的指令。

3. 核心功能模块深度实操指南

3.1 从零开始构建你的第一部小说项目

让我们抛开概念，直接上手。假设我们要创作一部奇幻小说《星穹旅人》。

第一步：项目初始化与基础配置

1. 启动文枢（通过 start.bat 或Release包），在项目列表页点击“新建项目”。
2. 输入项目名称 Starway_Traveler ，系统会自动在 data 目录下创建同名文件夹及基础结构。
3. 关键步骤：配置模型 。点击设置图标，进入“模型配置”。这里我强烈建议初学者先从 DeepSeek 或 Qwen（通义千问） 的官方API开始。它们性价比高，且对中文创作支持良好。在配置页填入你的API Key，并选择最新型号（如 deepseek-chat 或 qwen-max ）。文枢的多供应商适配做得很好，切换模型通常无需修改代码，只需在界面选择。

第二步：搭建世界观与人物——卡片系统的使用 在开始写第一个字之前，先填充“卡片”。这是保证故事一致性的“宪法”。

• 创建世界观卡 ：进入“卡片”->“世界观”，点击新建。文件将保存在 data/Starway_Traveler/cards/world/ 下。
  • 名称 ： 星穹魔法体系
  • 描述 ：不要只写“这是一个魔法世界”。采用 description-first 原则，进行 结构化描述 ：

    description: |
      本世界的魔法能量称为“星尘”，源于远古星辰的碎片。施法者通过精神力共鸣引导星尘，形成法术。
      核心规则：
      1.  等价交换：法术强度与消耗的精神力成正比，过度使用会导致灵魂疲劳。
      2.  元素亲和：个体通常对一种星尘元素（火、水、风、土、光、暗）有天然亲和，学习非亲和元素法术事倍功半。
      3.  法术回路：复杂法术需预先用星尘在体内构筑“回路”，瞬发高阶法术极为罕见。
      重要地点：
      - 星陨平原：最大的露天星尘矿脉，也是魔法战争古战场。
      - 静默圣殿：禁止使用魔法的中立城市。
    

  • 实操技巧 ：描述字段支持Markdown，善用列表、加粗来组织信息，使其对模型更友好。文枢会读取这个YAML文件，并将其描述文本作为核心上下文注入。
• 创建人物卡 ：进入“卡片”->“人物”，创建主角。
  • 名称 ： 里昂
  • 描述 ：同样，进行 清单式描述 ：

    description: |
      外貌：黑发，碧眼，左脸颊有一道细小的疤痕。身材修长，常穿着灰色旅行者斗篷。
      性格：冷静务实，因过往经历对权威抱有怀疑，但内心深处坚守承诺。有轻微的幽闭恐惧症。
      背景：前帝国星尘勘探员，因在一次事故中发现被隐瞒的真相而遭追杀，从此流浪。
      能力：对“风”元素星尘有杰出亲和力，擅长移动和感知类法术。不会任何攻击性火系法术。
      重要关系：追寻失踪的导师“艾尔文”；与情报商人“薇拉”保持互利合作。
      口头禅：“代价总是要付的，只是早晚问题。”
    

  • 关键点 ：人物卡中的“背景”、“能力”、“关系”是模型生成时的重要锚点。尽量具体、避免模糊。“冷静”不如“在危机中会先观察3秒再行动”来得有效。

第三步：规划故事结构——卷与章节管理 在“写作”主界面，左侧是卷章树状图。

1. 新建卷 ：点击“添加卷”，命名为“第一卷：星尘之遗”。卷的信息（标题、简介）会保存在 volumes/volume_1.yaml 。
2. 新建章节 ：在卷下“添加章节”，命名为“第一章：静默城的来信”。文枢会自动创建对应的目录 drafts/chapter_1/ 和摘要文件 summaries/chapter_1_summary.yaml 。
3. 顺序管理 ：你可以通过拖拽调整章节顺序，这个 order_index 会被持久化，确保无论你如何浏览，故事的时间线视图都是稳定的。

至此，你的项目骨架已经搭建完毕。这相当于为你的AI创作伙伴准备了一份详尽的项目需求文档和设计稿。

3.2 核心创作循环：生成、精修与知识提取

现在进入实际的写作环节。打开“第一章：静默城的来信”。

1. 生成草稿 ：

   • 在编辑器的指令输入框，写下你的章节指令。 指令的质量直接决定输出的下限 。不要只写“写第一章”，试试这样：

     “以里昂为主视角，描写他在静默城的一家地下酒馆‘漏壶’中，收到一封匿名信的场景。信的内容暗示其导师艾尔文曾在星陨平原出现。要求：1. 突出静默城‘禁止魔法’的特殊氛围与里昂作为外来者的谨慎。2. 展现里昂利用风元素星尘进行细微感知（如监听远处对话、感知信上残留能量）的小动作。3. 对话简洁，带有悬疑感。字数约1500字。”

   • 点击“生成”。后台的Orchestrator开始工作：它收集本章节指令、里昂的人物卡、星穹魔法世界观卡，并从事实库（目前为空）检索相关信息，组合成提示词，调用你配置的模型（如DeepSeek）生成文本。
   • 生成的内容会以草稿（ draft_001.md ）形式保存，并显示在编辑器中。

2. 编辑与迭代 ：

   • 第一遍生成很少能完美符合预期。你可以直接在人机界面编辑文本，也可以利用 Editor Agent 。
   • 选中一段你觉得对话生硬或描写不足的文字，在侧边栏点击“编辑”功能，输入指令：“将这段对话改得更自然，增加一些酒馆的环境音效描写。” Editor Agent会结合上下文对选中部分进行重写。
   • 重要心得 ：将AI视为一个才华横溢但需要明确指引的协作作者。你的指令越具体、越具有场景感，它的表现就越好。迭代是常态，一次生成+2-3次针对性编辑，通常能得到不错的结果。

3. 归档事实——让故事“记住” ：

   • 当你对当前章节的草稿满意后，点击“归档”或“完成本章”。这时， Archivist Agent 会启动。
   • 它会自动扫描本章节的最终文本（ final.md ），提取关键事实。例如，它可能会提取出：
     • 事实：里昂在静默城的“漏壶”酒馆。
     • 事实：里昂收到一封关于艾尔文在星陨平原的匿名信。
     • 事实：信纸材质特殊，带有微弱的土元素星尘残留。
   • 这些事实将以JSONL格式存入 canon/facts.jsonl 。每个事实条目都会 自动绑定到本章节 。这意味着，当你未来创作第五章时，上下文引擎会知道“里昂在静默城收信”这个事实发生在第一章，并根据章节距离衰减计算其相关性权重。

这个“生成 -> 编辑 -> 归档”的循环，是文枢核心的创作工作流。它确保了故事在推进的同时，其细节也被不断沉淀为结构化的知识，供后续创作检索使用，有效对抗了模型的“遗忘症”。

3.3 同人创作快速启动：从零到一构建设定

文枢的“同人创作”功能是一个被低估的利器。它解决了一个痛点：当你想要基于一个已有的IP（如一部小说、动漫、游戏）进行二次创作时，手动构建其复杂的世界观和人物群像极其耗时。

其工作流设计得非常理性，分为四步： 搜索 -> 预览 -> 抓取 -> 提案 。

实操演示：基于《哈利·波特》创作同人

1. 搜索 ：在同人功能界面，选择数据源（如“萌娘百科”或“Wikipedia”），输入“哈利·波特”。你会得到一个词条列表。
2. 预览 ：点击“哈利·波特”词条，文枢会调用 crawler_service 尝试抓取页面正文，并 在右侧预览窗格中显示清洗后的文本 。这一步非常关键，你可以确认抓取的内容是否准确、完整，避免了垃圾数据直接污染你的项目。
3. 抓取与解析 ：确认无误后，点击“抓取”。服务端会深度解析页面，识别出关键信息块（如角色列表、世界观设定、故事梗概等）。
4. 生成提案 ：抓取完成后，点击“生成提案”。系统会将解析后的结构化信息，送入一个专门的智能体。这个智能体会分析这些信息，并 自动生成一系列“人物卡”和“世界观卡”的提案 。
   • 例如，它可能会生成“哈利·波特”、“赫敏·格兰杰”、“霍格沃茨魔法学校”、“魔法部”等卡片提案。
   • 每个提案都包含了从百科中提取的关键描述。你可以在一个审核界面里， 逐一查看、编辑这些提案 ，决定是“采纳”、“修改后采纳”还是“丢弃”。
5. 导入项目 ：选择你需要的卡片，点击导入。这些卡片就会作为正式的YAML文件，存入你当前项目的 cards/ 目录下。

避坑指南 ：自动抓取和提案生成虽然强大，但绝非完美。百科文本可能包含剧透、矛盾信息或粉丝二次设定。务必在“提案审核”环节进行人工核查和修正。例如，自动生成的“斯内普”人物卡描述可能过于简单，你需要手动补充其双面间谍的复杂性格和关键事件。这个功能的价值在于 极大地降低了信息搜集和初步结构化的成本 ，而非完全替代你的创作判断。

3.4 模型网关：灵活接入AI大脑

文枢的 llm_gateway 设计体现了良好的架构抽象。它让你可以无缝切换不同的“大脑”，而无需改动任何创作逻辑。

配置详解 ： 在“设置”->“模型配置”中，你可以添加多个供应商。

• 官方供应商 ：如OpenAI、Anthropic、DeepSeek、Google Gemini等。你只需要提供API Key和选择模型名称（如 gpt-4-turbo-preview 、 claude-3-sonnet-20240229 ）。
• 自定义/第三方网关 ：这是高级用法。如果你使用像 OpenAI-Forward 、 LiteLLM 这样的代理网关，或者公司的内部AI平台，只要它提供了与OpenAI API兼容的接口，你就可以选择“自定义（OpenAI兼容）”类型。
  • API Base URL ：填写你的网关地址，如 https://your-gateway.com/v1 。
  • API Key ：填写网关所需的认证密钥（如果有）。
  • 模型名称 ：填写网关后端实际对应的模型名，这个名称会作为 model 参数传递给网关。

成本与性能调优心得 ：

• 分层使用 ：可以将“写作”任务分配给能力强的昂贵模型（如GPT-4），而将“提取事实”、“生成摘要”这类结构化任务分配给更便宜、速度更快的模型（如DeepSeek或GPT-3.5-Turbo）。文枢目前版本的路由配置尚不支持如此精细的策略，但你可以通过克隆项目，修改 llm_gateway 中的路由逻辑来实现，这是其架构带来的可能性。
• 上下文长度 ：在配置模型时，注意设置正确的“最大上下文长度”。如果设置得比模型实际能力小，会浪费；如果设置得太大，在构造长上下文时可能导致不必要的令牌消耗或API错误。对于大多数创作场景，设置成模型最大长度的80%左右是安全的（例如，对于128K模型，设置为100000）。
• 失败重试与降级 ：在生产环境中，可以在 llm_gateway 的调用层添加重试机制和备选模型降级策略，以提高系统的鲁棒性。文枢的基础框架为此留出了扩展空间。

4. 开发、部署与高级定制指南

4.1 本地开发环境搭建与代码导读

如果你想深入了解或贡献代码，需要搭建本地开发环境。

环境准备：

# 1. 克隆仓库
git clone https://github.com/unitagain/WenShape.git
cd WenShape

# 2. 确保已安装 Python 3.10+ 和 Node.js 18+
python --version
node --version

# 3. 启动开发环境（Windows）
start.bat
# 或在根目录执行
python start.py

start.py 脚本会检查环境，安装Python和Node.js的依赖包（ requirements.txt 和 package.json ），并同时启动前端开发服务器（通常 localhost:5173 ）和后端FastAPI服务器（通常 localhost:8000 ）。

代码结构深入： 遵循项目推荐的阅读顺序至关重要：

1. 从前端入口开始 ( frontend/src/pages/WritingSession.jsx )：这是用户的主工作台。从这里你可以看到所有UI组件如何组装，以及用户操作（点击生成、编辑、保存）触发了哪些事件和API调用。
2. 追踪到后端路由 ( backend/app/routers/session.py )：查看FastAPI如何接收前端请求。例如， /api/write 端点对应生成请求， /api/analyze/facts 对应事实提取。
3. 深入核心编排器 ( backend/app/orchestrator/orchestrator.py )：这里是业务逻辑的中枢。它定义了“写作”、“编辑”、“分析”等主要用例的完整流程。看它如何初始化上下文、调用不同的智能体、处理异常。
4. 剖析智能体 ( backend/app/agents/ )：每个智能体都是一个相对独立的类。 WriterAgent 负责生成文本，它的 run 方法接收 context （编排器提供的）和 instruction ，组装最终提示词并调用LLM。 EditorAgent 和 ArchivistAgent 同理。这是理解“能力如何被封装”的关键。
5. 解密上下文与检索 ( backend/app/context_engine/ 和 backend/app/services/ )： context_engine/selector.py 包含了复杂的检索排序逻辑。 services/evidence_service.py 负责从事实库、摘要中构建证据链。这是系统智能的“记忆”部分。
6. 理解数据持久化 ( backend/app/storage/ )：最后看数据如何落地。 yaml_storage.py 、 markdown_storage.py 、 jsonl_storage.py 分别处理不同类型文件的读写。了解这里的逻辑，有助于你自定义数据格式或添加新的存储后端。

4.2 构建独立发布包（Windows）

文枢提供了 build_release.py 脚本，可以将整个应用打包成一个独立的Windows可执行文件，这对于分享给不熟悉技术的创作者朋友非常有用。

构建步骤：

1. 确保你的开发环境运行正常。
2. 在项目根目录执行：

   python build_release.py
   

3. 脚本会自动完成以下工作：
   • 打包前端React应用（ npm run build ），生成静态文件。
   • 使用 PyInstaller 将后端Python代码、前端静态文件、以及必要的配置文件（ config.yaml , .env 模板）和空数据目录，一起打包进一个单一的 WenShape.exe 。
   • 最终发布包位于 dist/WenShape/ 目录下。

发布包内容解析：

WenShape/
├── WenShape.exe          # 主程序
├── config.yaml          # 默认配置文件
├── .env.example         # 环境变量示例
├── data/                # 空数据目录，首次运行后用户项目将在此创建
└── ... (其他运行时依赖库)

用户只需双击 WenShape.exe ，程序就会自动启动后端服务器并打开默认浏览器指向本地页面。所有依赖（Python解释器、Node环境）都已内嵌，真正做到开箱即用。

4.3 常见问题排查与性能调优

在实际使用和开发中，你可能会遇到以下问题：

问题1：生成速度慢，或经常超时。

• 排查思路 ：
  1. 检查模型供应商 ：如果你使用的是海外供应商（如OpenAI、Anthropic），网络延迟可能是主因。考虑切换到国内可高速访问的模型，如DeepSeek、通义千问。
  2. 检查上下文长度 ：在文枢的设置中，或查看 backend/app/context_engine/budget.py ，确认每次请求发送的上下文Token数是否过大。过长的上下文会显著增加模型响应时间。可以尝试调低“最大上下文Token”限制。
  3. 查看日志 ：启动时添加 --log-level DEBUG 参数，或查看控制台输出的日志。观察时间消耗在哪个环节：是检索上下文慢，还是LLM API调用慢？
• 优化建议 ：
  • 对于摘要、事实提取等对创造力要求不高的任务，使用更小、更快的模型。
  • 优化卡片和事实的描述，使其更加精炼，减少无关Token。
  • 考虑对事实库进行 嵌入向量化 并建立向量索引（文枢当前主要用BM25和规则检索，未来可扩展），可以加速相似性检索。

问题2：生成的内容偏离设定（“幻觉”或忽略卡片）。

• 排查思路 ：
  1. 确认卡片已加载 ：在写作界面，检查侧边栏的“当前上下文”区域，确认你期望的人物卡、世界观卡是否被正确“激活”或“钉选”到当前章节。
  2. 检查事实检索 ：系统是否提取了相关事实？可以在 data/your_novel/canon/facts.jsonl 中手动查看，或尝试在界面进行“事实查询”。
  3. 分析提示词 ：这是最关键的步骤。在 backend/app/prompt_templates/ 目录下，找到对应的提示词模板文件（如 writer_system_prompt.j2 ）。Jinja2模板定义了最终发给模型的指令。检查模板中引用卡片和事实的部分（如 {{ character_descriptions }} ）是否被正确替换。你可以在日志中搜索“Final prompt”来查看实际发送的完整提示词。
• 优化建议 ：
  • 强化卡片描述 ：在人物卡的 description 中，将核心、不可违背的设定放在最前面，并使用强调语气，例如：“ 核心设定：XXX绝对不可能YYY。 ”
  • 使用“钉选”功能 ：对于本章节至关重要的卡片，手动将其钉选，确保它100%被包含在上下文中。
  • 修改提示词模板 ：如果你有编程能力，可以微调提示词模板。例如，在Writer的指令部分增加：“你必须严格遵循以下人物设定和世界观，不得自行添加或修改任何核心设定：”。

问题3：前后端连接失败，或静态资源加载404。

• 排查思路 ：
  1. 端口冲突 ：默认前端在5173端口，后端在8000端口。检查是否有其他程序占用了这些端口。可以在 start.py 或配置文件中修改。
  2. CORS问题 ：如果前端能打开但无法调用API，浏览器控制台（F12）会报CORS错误。确保后端FastAPI应用正确配置了CORS中间件（通常已在 backend/app/main.py 中配置）。
  3. 发布包路径问题 ：在打包后的EXE环境中，文件路径是相对的。确保 config.yaml 中的资源路径配置正确，或者使用 sys._MEIPASS （PyInstaller运行时临时目录）来定位资源。

问题4：我想接入新的LLM供应商。

• 操作路径 ：
  1. 在 backend/app/llm_gateway/providers/ 目录下，参考现有文件（如 openai_provider.py ），创建一个新的Provider类。这个类需要实现统一的接口，主要是 async def generate_completion(...) 方法。
  2. 在 backend/app/llm_gateway/factory.py 中，将你的新Provider注册到 PROVIDER_MAP 字典中。
  3. 在前端 frontend/src/lib/constants.js 或相关配置模型中，添加新供应商的显示名称和标识符。
  4. 在前端配置页面添加对应的UI选项。这需要修改React组件，相对复杂一些，但遵循现有模式（如 ModelConfigCard 组件）即可。

文枢的架构清晰地分离了模型调用逻辑和业务逻辑，使得扩展新模型供应商成为一个相对模块化的任务。