# 网文专项模块模板

这份文件不是给用户看的教程，而是给后续新增模块时用的统一骨架。

目标只有一个：

`任何专项模块都必须让模型先判断问题、再匹配素材、再做局部计划、最后写作。`

## 一、建议目录结构

```text
references/modules/<module_name>/
├── README.md
├── tutorial.md
├── runtime.md
├── good_examples.md
├── bad_examples.md
├── source_index.md
└── sources/
    ├── raw/
    └── raw_html/   # 可选，用于网页备份
```

## 二、每个文件分别负责什么

### README.md

负责回答四件事：

- 这个模块到底解决什么问题
- 什么时候该调用它
- 建议按什么顺序读
- 这个目录里的文件分别干什么

要求：

- 先写适用场景，再写阅读顺序
- 明确“这不是泛理论，而是执行入口”
- 把模块目标写成一组可识别的问题信号

### tutorial.md

负责把收集来的教程重组为一套统一框架。

建议包含：

- 统一定义
- 底层原则
- 新手常用法
- 进阶方法库
- 网文适配原则

要求：

- 不平铺罗列原教程
- 不只写方法名，要解释每种方法解决什么问题
- 优先把原资料整理成可执行判断框架

### runtime.md

这是模块最关键的文件，负责告诉模型“实际怎么跑”。

至少要包括：

- 什么时候必须调用本模块
- 先按什么分层
- 再按什么分类
- 正反例怎么匹配
- 动笔前先写什么局部计划
- 如果任务是诊断、改写、创作，各自怎么处理
- 写完后怎么自查

要求：

- 先诊断，再选方法
- 不要让模型一上来就润色句子
- 要给出明确的执行顺序，而不是理论总述

### good_examples.md

负责提供可迁移的正例，不是摘抄集锦。

建议：

- 至少准备 `15-20` 个例子
- 按“问题簇”或“方法簇”分组
- 每条例子都写“该学什么”
- 开头给一份快速索引

要求：

- 强调结构，不强调句面
- 优先收录能直接迁移到网文写作的例子

### bad_examples.md

负责提供高频错误识别样本。

建议：

- 至少准备 `15-20` 个例子
- 按“错误簇”分组
- 每条例子都写“断在哪里”
- 对关键错误簇补一句“这类通常该补什么”

要求：

- 反例要短、典型、好识别
- 目的是帮助模型避错，不是做抽象批评

### source_index.md

负责记录原始资料的整理结果。

建议包含：

- 哪些 `raw` 文件是主参考
- 哪些互相重复
- 哪些只是补充
- 哪些噪音较大

要求：

- 明确写出“这一轮模块重组主要依赖了哪些资料”
- 保留原件，不要把原件清洗掉后只留摘要

### sources/raw/

这里存用户手工收集或后续补进来的教程原件。

要求：

- 保留原始命名或建立稳定编号
- 尽量不要覆盖原件
- 如果后续重组教程，要在 `source_index.md` 里说明依据

## 三、模块运行契约

任何专项模块都应该遵守这 6 条：

1. 先判断是不是该调用模块，不要滥调。
2. 先判断问题层级，不要直接套技巧名。
3. 必须匹配正例和反例，不能只靠抽象建议。
4. 动笔前必须有一版局部计划，哪怕很短。
5. 允许快切，但不能剪断因果、状态和关系。
6. 最后写出来的内容必须能直接落回正文，而不是停留在点评层。

## 四、模块命名和组织建议

- 模块名尽量用清晰的环节名，比如 `transition`、`plot_logic`、`character_consistency`
- 正例和反例尽量用稳定 ID，方便在运行规则里引用
- 分组优先按“问题诊断”组织，不优先按修辞名词组织
- 如果模块同时有教程和例库，运行规则里要明确告诉模型先看哪组再看哪组

## 五、判断一个模块是否合格

只要能同时满足下面几条，这个模块就算合格：

- 模型能明确知道什么时候该调用它
- 模型能先判问题，不会一上来就润色
- 模型能快速选到近似正例和反例
- 模型能在写正文前先搭一个局部结构桥
- 模块里的内容能直接服务实际写作，而不是停在理论讲解