首先，感谢你愿意为 NovelForge 做贡献 ❤️
无论是修复一个小问题，还是推进一个大功能，我们都非常欢迎。为了让协作更顺畅、评审更高效，请优先遵循下面的约定。
适用于：
- 小范围功能增强
- Bug 修复
- 文案与交互优化
- 小型重构（不改变核心架构）
提交 PR 时请务必包含：
- 改动说明：一句话说明这次改了什么、解决了什么问题。
- 文件级说明：列出本次改动的主要文件，并说明每个文件的改动目的。
- 验证方式：你如何验证改动有效（如手动步骤、关键日志、测试结果）。
建议格式（可直接复制到 PR 描述）：
## 改动概述
-
## 文件改动说明
- `path/to/fileA`：
- `path/to/fileB`：
## 验证
- 如果你计划贡献的是较大功能（例如涉及架构调整、核心流程改造、跨前后端的大改动），请先提一个 Issue，与作者/维护者讨论后再开发。
Issue 建议包含：
- 背景与问题
- 目标与边界（做什么 / 不做什么）
- 方案草图（关键设计点）
- 对现有行为的影响
这样可以避免返工，也能帮助你更快获得有效反馈。
为便于和普通问题反馈区分，建议使用以下中文标题格式：
- 大功能方案讨论（推荐）：
【方案讨论】【模块】一句话目标 - 认领规划功能（推荐）：
【功能认领】【模块】准备实现的功能 - 小问题修复（可选）：
【问题修复】【模块】问题摘要
示例：
【方案讨论】【工作流】增加并行分支错误恢复策略【功能认领】【Agent】实现工作流 Agent 的批量示例模板【问题修复】【编辑器】修复章节正文自动保存冲突
说明：
【方案讨论】用于先讨论方案，再进入开发；【功能认领】用于“我准备做这个”，减少重复开发；- 功能完成且 PR 被合并后，请关闭对应 Issue。
开发时请遵守项目工程规则：
rules/novelforge-engineering-rule.md
核心要求可以概括为：
- 设计清晰，避免耦合和硬编码
- 代码整洁，优先可维护性
- 变更有校验闭环，不做“看起来能跑”的脆弱实现
- 尽量保持“小步提交、聚焦改动”，避免一个 PR 混入过多无关改动。
- 不要顺手重写无关模块（除非已在 Issue 中达成一致）。
- 优先补充或更新必要文档，确保后续维护者能快速理解你的改动。
如果你不确定某个设计是否合适，欢迎先开 Issue 或在 PR 中明确写出你的取舍与疑问。
再次感谢你的贡献！