在结构中写作
在 Markdown 编辑器中写正文，同时维护字段、层级、关系和可追溯的项目事实。
结构化写作不等于先填完所有字段。正确的节奏是：先确定当前内容类型和目标，再写正文；只把长期需要维护的事实写入字段和关系。
创建文档
从左侧选择目标栏目，然后新建文档。若栏目包含多个子类型，先选择符合当前内容的子类型。不同子类型可能拥有不同字段、正文结构和质量规则。
新建文档时建议先确定：
- 标题和内容目标。
- 内容类型与子类型。
- 父级或上级结构。
- 当前任务真正需要确认的少量字段。
一次完整的结构化创作流程
以“写一篇正文章节”为例，推荐按下面的顺序完成一次工作：
- 从栏目进入：先进入“章节”或模板对应的正文类型，不要从空白文件开始猜结构。
- 选择子类型：确认这是普通章节、开篇章节还是其他子类型；子类型决定字段和检查规则。
- 确认上下文：补齐父级、顺序、关联人物或主题等少量关键字段，缺少证据的字段留空并标记待确认。
- 先写正文：按正文结构完成段落，不要把章节内容拆成一堆字段；引用已有内容时使用
[[文档名]]。 - 让 AI 做一次受限协作：明确依据、允许修改的范围和验收标准，先让它检查或提出方案，再决定是否应用修改。
- 检查并交付：保存后查看类型视图、图谱和质量检查结果；确认关系、状态和版本都能被下一次工作复用。
这条流程适用于小说章节、研究报告、课程小节、内容稿件等不同模板；变化的是类型和规则，不变的是“类型先于正文、证据先于结论”。
查看高清截图 ↗三种常用协作方式
| 方式 | 适合什么时候 | 推荐说法 |
|---|---|---|
| 先检查 | 你怀疑存在冲突，但不想改原文 | “只检查当前章节与相关设定的冲突，列出依据和风险，不要修改。” |
| 提出方案 | 你知道目标，但还没决定怎么改 | “基于当前类型规则提出两种修改方案，说明会影响哪些字段和文档。” |
| 确认后修改 | 方案明确，准备交付 | “按方案二修改正文，保留字段和关系不变，完成后列出修改文件。” |
编辑正文
Plova 使用 Markdown 作为主要内容格式，支持常见 GFM、表格、代码块、数学公式和 Mermaid。编辑器负责长文正文，信息字段区负责结构化事实。
正文适合承载论证、叙事、说明和完整段落。字段适合承载状态、顺序、关系、时间和需要筛选的事实。不要在正文和字段中重复维护同一事实。
使用 Wiki 链接
输入 [[ 可以连接项目内已有内容。Wiki 链接适合在自然语言中引用人物、设定、章节、论点或资料。
如果某项关系需要被筛选、校验或进入图谱规则，使用正式关系字段；如果只是正文中自然提及，可以使用 Wiki 链接。两者都可能进入内容图谱，但约束强度不同。
保存与未保存状态
编辑标签会显示未保存状态。切换项目结构、关闭标签或退出项目前先保存修改。关闭多个未保存文档时，应用会要求统一确认。
被删除的 Markdown 文档会进入项目回收站时，可以从回收站查看原路径和内容；仍建议用 Git 保存正式版本历史。
从结构调用 AI
让 AI 修改正文时，给出具体目标、允许变更的范围和验收标准。例如：
检查当前章节与“港区停电规则”是否冲突。只提出修改方案，不要直接改角色动机；引用相关设定和前一章的状态变化。
AI 创建结构化文档时会参考当前内容类型、子类型、项目说明和相关内容。遇到无法从项目证据确认的事实时，应先向你确认，而不是补写看似合理的答案。
查看高清截图 ↗完成一篇内容前
- 标题、父级和关键关系是否正确。
- 必填事实是否有项目证据。
- 正文中的引用是否能回到资料或源文件。
- 结构诊断是否出现断链、孤立节点或字段提醒。
- 交付前质量规则是否已经检查。
- 需要长期保留的决定是否已写回项目，而不是只停留在对话中。
创建或保存失败时
- 新建文档失败时，先确认标题、父级、必填信息字段和目标目录是否有效。
- 保存被质量规则阻止时，按提示补齐依据或结构；不要通过外部编辑器绕过规则后继续生成。
- Wiki 链接无法匹配时，打开目标文档核对标题和路径，避免把同名内容误连。
- 关闭前仍显示未保存状态时，停止切换项目，先复制尚未落盘的正文并再次保存。