长篇专项

长篇专项

此技能是写作系统的伏笔管理层，负责伏笔的放置登记与跨章节情节回忆。长篇与短篇作品均可使用。

核心定位

• 伏笔生命周期管理：从伏笔放置 → 登记存档 → 回收提醒 → 状态更新，全链路追踪，每条伏笔在 项目信息.json 中以单行字符串形式持久化
• 情节回溯：当用户提及前文章节事件时，自动读取该章原文全文，按查询焦点定向提取并生成结构化摘要
• 被动触发：不主动扫描全文、不主动建议设伏笔、不评判伏笔质量。仅在用户提示词命中触发条件时执行
• 共享数据源：与 Core / NSFW 共用 项目信息.json，伏笔数据独占 foreshadowing 字段，写入时绝不覆盖其他技能字段

关联文件

文件定位优先级：

1. 当前工作目录 → 大纲/ + 正文/（分卷多文件时加查 正文/卷{N}/）
2. 当前工作目录 → outline/ + body/（English 路径；分卷时加查 body/vol{N}/）
3. Glob 模糊匹配（如 正文/第X章*、正文/卷*/第X章*）
4. 以上均未找到 → 提示用户确认路径

触发条件

伏笔管理触发

A. 正文标注类（→ 步骤 A）：

用户消息中出现以下任一表述：

• "这是一个伏笔"、"这是伏笔"、"此处为伏笔"、"此处埋伏笔"
• "埋伏笔"、"设伏笔"、"放置伏笔"、"在此埋一个伏笔"
• "伏笔："、"【伏笔】"、"[伏笔]"、"（伏笔）"
• 正文段落后附带伏笔说明（如"——此处的玉佩会在后面出现"）

B. 大纲规划类（→ 步骤 B）：

• 用户编辑剧情大纲时写入 "伏笔"、"铺垫"、"预热" 关键词
• 大纲中出现 "此处埋伏笔"、"为后续XX做铺垫"、"为XX章埋伏笔"
• 章节规划中标注某项为伏笔/铺垫/前兆/暗示

C. 回收确认类（→ 步骤 C）：

• "回收伏笔"、"填坑"、"回收XX伏笔"
• "这个伏笔该回收了"、"之前的伏笔可以收了"
• "XX伏笔在这一章回收"

D. 查看清单类（→ 步骤 D）：

• "查看伏笔"、"伏笔列表"、"还有哪些坑没填"
• "梳理一下伏笔"、"看看埋了多少伏笔"、"伏笔进度"

F. 人物伏笔预登记（→ 步骤 A0）：

由创建人物技能在角色填写「隐藏设定」字段后自动调度（联动定义见 templates/character.schema.json 的 fields[].integration）。用户通常不直接触发。

情节回忆触发（→ 步骤 E）

用户消息中出现以下表述时调用：

• "之前第X章里……"、"在第X章中……"、"回顾第X章的事件"
• "之前XX发生了什么"、"XX事件是在哪一章"、"第X章发生了什么"
• "前文中XX和XX的关系"、"回顾一下XX的情节"、"重温XX章节"
• 任何要求回顾/重温/查询前文章节内容的表述

加载策略（规格数据）

• data/foreshadowing-spec.json 为机器规格（条目格式/扫描关键词/阈值/提取正反例）：首次调度本技能时完整读取一次（同会话仅此一次），读取后按工作记忆执行，后续调度不重复读取
• 仅当规格数据变更（版本升级）或新会话首次调度时重新读取

执行模式

伏笔管理与情节回忆均为被动触发。 无需计划模式，命中触发条件后直接按对应步骤执行。

与其他 body 技能的关系：

• 与 Core 的关系：Core 负责正文润色写入，Long 负责伏笔登记。用户在同一章中写完正文（经 Core）后标注伏笔 → Long 读取已写入的章文件提取伏笔
• 与 NSFW 的关系：无直接调度关系，与 NSFW 共享 项目信息.json，各自维护独立字段（NSFW 维护 nsfw_*，Long 维护 foreshadowing）

步骤 A0：人物伏笔预登记（由创建人物技能调度）

当创建人物技能写入含「隐藏设定」字段的角色条目后自动调度（联动定义见 templates/character.schema.json 的 fields[].integration）。以角色隐藏设定为来源，将人物秘密/身世类信息登记进伏笔体系。

A0.1 — 读取隐藏设定

从刚写入的角色条目中提取「隐藏设定」字段内容（字段非空才执行本步骤）。

A0.2 — 生成数据行

按 A4 相同格式生成：{第N章}_{≤50字摘要}_{待回收}

• 放置章节：当前创作章节（无法确定时用 第1章）
• 摘要：隐藏设定的一句话概括（≤50 字，强制含"施动人/物 + 核心秘密 + 线索对象"），不评价、不展开推测

A0.3 — 写入项目信息.json

按 A5 相同流程（三种情况 + 数据完整性约束 + 经成品输出校验落盘）写入 foreshadowing 数组。条目格式与正文伏笔完全一致——隐藏设定的可追溯性由角色文件的「隐藏设定」字段保证。

A0.4 — 确认输出

向用户输出登记确认（格式同 A6），注明来源为人物设定。

步骤 A：伏笔登记（正文标注）

当用户在正文中标注"这是一个伏笔"或类似提示词时执行。

A1 — 确定当前章节

从用户上下文或当前已打开的文件路径中提取章节号与章节名。

定位顺序：

正文/第XX章 XX.md（分卷多文件时：正文/卷{N}/第XX章 XX.md）  →  body/ChXX XX.md  →  Glob "第X章*"  →  询问用户

提取到的章号记为 {N}（纯数字），章名记为 {T}（如"初入江湖"）。

歧义处理：用户同时打开多章文件时，以最近修改或用户正在编辑的章节为准。无法确定时询问。

A2 — 读取伏笔所在原文

定位用户标注"这是一个伏笔"的位置，读取该位置前后各 5 个段落的原文（约 500-1500 字）。

读取策略：

• 如伏笔标注在用户消息中、正文已写入文件 → 读取章文件中对应位置的原文
• 如伏笔标注紧跟在用户提供的正文后、正文尚未写入文件 → 直接从用户消息中提取正文段落
• 如用户标注时附加了说明（"这是一个伏笔——后面他会用到这把钥匙"）→ 将说明一并纳入上下文

不纳入伏笔上下文的内容：

• 伏笔标注的后 2 段之后的环境过渡描写（与伏笔内容无直接因果关联）
• 纯功能性章节标记（如"第X章 完"）

A3 — 提取关键意思

通读 A2 获取的原文 + 用户附加说明，提炼为一句话关键意思。

提取规则（强制）：

正反例对照（3 组：原文情境/错误提取/正确提取）见 data/foreshadowing-spec.json → extraction_examples。

如用户附带了预期回收方向（如"→ 后续战斗中激活"），在关键意思末尾以 → 附加，不计入 50 字限制。

A4 — 生成数据行

按固定模板生成一行字符串：

{第N章}_{一句话关键意思}_{待回收 / 第M章}

字段分隔符：_（下划线，半角）

字段规则：

• 第一字段：第N章（仅章号，不含章名 {T}）
• 第二字段：A3 提取的关键意思（不含 → 回收方向，回收方向独立作为预期提示）
• 第三字段：待回收（未指定回收章）或 第M章（已指定/已知回收章号）

产出示例：

第3章_后山发现发光符文石触碰后手心留印记_待回收
第5章_偷听到管家提及下月初三西城码头_第12章
第1章_师傅临别交付旧锦囊嘱咐走投无路时打开_待回收

A5 — 写入项目信息.json

定位文件：大纲/项目信息.json（优先）或 outline/project-info.json。

分三种情况组装数据，统一经成品输出校验落盘（不自行 Write）：

情况 1：文件存在且已有 foreshadowing 字段

1. Read 读取 项目信息.json 全文
2. 解析 JSON，定位 foreshadowing 数组
3. 在数组末尾追加 A4 生成的字符串
4. 组装完整 JSON → 调度 成品输出校验（type: "json", expected_schema: "项目信息", file_path）→ 由校验技能执行 JSON 模式校验后落盘

情况 2：文件存在但无 foreshadowing 字段

1. Read 读取 项目信息.json 全文
2. 在已有字段最下方（} 之前）插入 "foreshadowing" 数组，写入 A4 数据
3. 组装完整 JSON → 调度 成品输出校验 → 校验后落盘

情况 3：文件不存在

1. 组装最小合法 JSON 结构 → 调度 成品输出校验（type: "json", expected_schema: "项目信息", file_path）→ 校验后落盘

数据完整性约束（与 templates/project-info.schema.json 中 foreshadowing.x_dynamic 约束一致——字段规则以 schema 文件为准）：

• 绝不修改 foreshadowing 以外的任何字段
• 绝不重新排列已有字段的顺序
• foreshadowing 数组内条目按放置时间顺序排列（新条目追加在末尾）
• 条目格式必须匹配 {第N章}_{≤50字关键意思}_{待回收|第M章}（schema pattern），且必须插入在 last_updated 字段之前

A6 — 向用户确认

写入完成后输出：

🔖 伏笔已登记 — 第{N}章「{T}」
{第N章}_{关键意思}_{待回收或第M章}

如用户附带了预期回收方向，追加一行：

📎 预期回收方向：{用户说明的回收方向}

步骤 B：伏笔预登记（大纲规划）

当用户在剧情大纲中写入伏笔计划时执行。

B1 — 读取剧情大纲

Read 读取剧情大纲文件，按以下优先级定位：

• 先读 大纲/项目信息.json → volumes 判断分卷状态
• 分卷多文件模式 → 大纲/剧情/剧情大纲-卷{N}.md（按目标章所属卷号定位）
• 不分卷/单文件 → 大纲/剧情/剧情大纲.md（优先）或 outline/plot/plot-outline.md

如大纲文件不存在 → 提示用户先创建剧情大纲，中止此步骤。

B2 — 扫描伏笔标注

在大纲全文搜索以下关键词（不区分全半角，关键词表与命中判定见 data/foreshadowing-spec.json → scan_keywords）：

找到后，读取该关键词所在段落的完整内容（该段落从标题或空行分隔的起止范围内）。

B3 — 逐条提取

对每条命中的伏笔标注，提取三个字段：

1. 计划放置章节：大纲中标注的章号（如"第5章"）。如大纲未明确章号，从上下文推断（该伏笔标注属于哪个阶段/分卷）
2. 核心内容：用一句话概括（同 A3 ≤50 字规则）
3. 计划回收章节：大纲中如已写明"第X章回收"则提取，否则填 待回收

按 A4 模板逐条生成数据行。

B4 — 写入

逐条追加到 项目信息.json 的 foreshadowing 数组（同 A5 写入逻辑）。

B5 — 汇总告知

🔖 从剧情大纲中预登记 {K} 条伏笔：

第X章_{核心内容}_待回收
第Y章_{核心内容}_第Z章
…

💡 提示：这些伏笔目前为"预登记"状态，在正文实际写入对应章节后可更新为正式放置。

步骤 C：伏笔回收

当用户表示要回收伏笔时执行。

C1 — 读取伏笔列表

Read 读取 项目信息.json，提取 foreshadowing 数组。

如 foreshadowing 为空或不存在 → 提示"当前无已登记的伏笔"，中止。

C2 — 匹配目标伏笔

根据用户描述的关键词（如"发光石头"、"码头交易"、"锦囊"）在 foreshadowing 数组各条目中做子串匹配。

匹配优先级：

1. 第二字段（关键意思）精确包含用户关键词 → 置信度最高
2. 第二字段语义模糊匹配 → 置信度中等
3. 第一字段（放置章节）与用户提及的章节号一致 → 辅助筛选

匹配结果处理：

多匹配消歧输出：

找到 {K} 条匹配的伏笔：

1. 第3章_后山发现发光符文石触碰后手心留印记_待回收
2. 第7章_洞穴壁画出现相同符文图案_待回收
3. 第10章_拍卖行出现一枚符文石残片_待回收

请指定要回收哪一条？（输入数字序号）

C3 — 更新状态

将匹配条目的第三个字段 _待回收 替换为 _第{N}章（当前章号）：

修改前：第3章_后山发现发光符文石触碰后手心留印记_待回收
修改后：第3章_后山发现发光符文石触碰后手心留印记_第12章

组装更新后的完整 JSON → 调度 成品输出校验（type: "json", expected_schema: "项目信息", file_path）→ 校验后落盘。

回收时额外操作：如用户当前正在写的章节正文中涉及该伏笔的回收情节，在写回前向用户确认该章是否为正确的回收点——防止用户说"回收伏笔"但实际上该章只是部分回收（伏笔仍需保持待回收状态）。

C4 — 确认

✅ 伏笔已回收 — 第 {K} 条
第3章_后山发现发光符文石触碰后手心留印记_第12章

如回收后该章同时回收了多条伏笔，触发 C5。

C5 — 回收密度提醒

回收后检测当前章已回收的伏笔数（阈值与输出文案见 data/foreshadowing-spec.json → thresholds.recycle_density）：

• 同章回收 2 条 → 口头提示
• 同章回收 ≥ 3 条 → 警告

步骤 D：伏笔清单

当用户要求查看伏笔时执行。

D1 — 读取

Read 读取 项目信息.json，提取 foreshadowing 数组。

如数组为空或不存在 → 输出"📭 当前无已登记的伏笔。"

D2 — 分类统计

解析每条数据的第三个字段（_ 分隔后的最后一段）：

• 待回收 → 归入「未回收」组
• 其他章号（匹配 第X章）→ 归入「已回收」组

统计两组数量，计算：

• 总伏笔数 = 未回收数 + 已回收数
• 回收率 = 已回收数 / 总伏笔数 × 100%

D3 — 输出清单

🔖 全书伏笔清单（总计 {T} 条 / 已回收 {M} 条 / 回收率 {R}%）

▎ 未回收（{N} 条）

第3章_后山发现发光符文石触碰后手心留印记_待回收
第5章_偷听到管家提及下月初三西城码头_待回收
第8章_神秘人留下半块玉佩后消失_待回收
…

▎ 已回收（{M} 条）

第1章_师傅临别交付旧锦囊嘱咐走投无路时打开_第8章
第2章_酒馆角落的斗笠人始终未开口_第6章
…

D4 — 状态诊断

清单输出后，诊断以下异常情况（诊断条件与输出文案见 data/foreshadowing-spec.json → thresholds.diagnosis，共 5 项）：

步骤 E：关键情节回忆

当用户提及前文章节事件时执行。

E1 — 解析章节号

从用户消息中抓取章节定位信息：

章节号无法确认时 → 将候选章节列出，请用户确认。

E2 — 定位并读取章节文件

按以下优先级查找：

正文/第X章 {章名}.md（分卷多文件：正文/卷{N}/第X章 {章名}.md）  →  body/ChX {章名}.md  →  Glob "正文/第X章*"  →  询问用户

找到后，Read 全文读取该章。

如查询涉及多章（如"回顾第3到第7章"），逐章读取。单次最多读取 5 章——超过时提示用户缩小范围。

E3 — 按查询焦点定向提取

根据用户查询焦点，从原文中提取对应段落：

提取原则：

• 提取原文段落，不做改写
• 每段提取内容前标注其在原文中的大致位置（如"中段"、"结尾前"）

E4 — 输出情节摘要

📖 第X章「{章名}」情节回顾

【查询焦点】
{用户问什么——直接引用用户原文或概括}

【场景】
{地点} / {时间} / 出场人物：{人物列表}

【相关情节】
{从原文提取的 2-5 句话摘要，直接回答用户问题。
使用原文中的关键细节，不概括为空洞的"主角完成了某事"}

【人物状态】
{查询涉及的人物在本章中的行为、情绪、位置变化}

【伏笔关联】（如 `项目信息.json` 中有登记）
第X章_{伏笔内容}_待回收
或：第X章_{伏笔内容}_第Y章 ✅ 已回收

E5 — 多章关联查询

当用户跨章查询（如"第3到7章之间XX的变化"）：

1. 按 E2 逐章读取第 3→7 章
2. 每章按 E3 提取与 XX 相关段落（仅提取相关段落，不读全文无关部分）
3. 按时间线呈现：

📖 XX 线索回溯（第3章 → 第7章）

第3章「{章名}」
  → {一句话说明 XX 在本章中的状态/事件}

第4章「{章名}」
  → {一句话}

…

第7章「{章名}」
  → {一句话}

【演变总结】
{2-3 句话概括 XX 在各章之间的变化趋势}

数据格式速查

foreshadowing 数组条目

条目格式（三字段定义/分隔符/插入位置/排序规则）见 data/foreshadowing-spec.json → entry_format：

{第N章}_{一句话关键意思}_{待回收 或 第M章}

• 分隔符：_（半角下划线）
• 第一字段：放置章节（如 第3章）
• 第二字段：≤50 字一句关键意思，不评价、不展开
• 第三字段：待回收（未回收）或 第M章（已回收）

项目信息.json 存储位置

{
  "book_name": "XX",
  "content_rating": "一般向",
  "nsfw_output_level": "限制级",
  "nsfw_tier_range": { "global": "N3-N4", "chapters": {} },
  "foreshadowing": [
    "第3章_后山发现发光符文石触碰后手心留印记_待回收",
    "第5章_偷听到管家提及下月初三西城码头_第12章"
  ],
  "last_updated": "2026-06-13"
}

foreshadowing 数组插入在已有字段之后、last_updated 之前，作为一个独立 JSON 段落存在。

注意事项

• 不覆盖原则：写入 项目信息.json 时，仅操作 foreshadowing 数组。content_rating、nsfw_output_level、nsfw_character_tone、nsfw_tier_range、last_updated 等字段绝不触碰
• 顺序保持：foreshadowing 数组内条目按放置时间排序（先放置在前），回收不改变条目位置——仅修改第三个字段内容
• 文件查找链：章节文件优先查 正文/（分卷多文件时加查 正文/卷{N}/），其次 body/（分卷时加查 body/vol{N}/），再次 Glob（正文/第X章*、正文/卷*/第X章*），都找不到时提示用户确认——不要直接报"文件不存在"
• 关键意思字数：超过 50 字时删减形容词和修饰从句，保留"谁 + 干了什么 + 涉及什么线索"。宁可偏短不可偏长
• 被动触发边界：此技能不主动建议"这里该加个伏笔"、不评判伏笔质量好坏、不自动扫描全文章节查找未登记的伏笔。所有操作由用户提示词触发
• 回收确认：用户说"回收XX伏笔"时，必须确认该章正文中确实写了回收情节再做状态更新——防止口头说回收但正文未写
• 短篇兼容：短篇作品同样可用，伏笔数量少时清单更简洁，不因"长篇"二字限制调用