核心用法
story-import 是一款面向小说创作者的逆向工程工具，核心功能是将用户已有的小说文本（无论是半成品还是完本）自动解析为标准化的项目目录结构，使其能够无缝接入 story-long-write（长篇日更）或 story-short-write（短篇写作）的后续创作流程。
使用流程分为四个阶段：
Phase 1：确认导入源 — 用户需提供小说文件路径或直接粘贴文本，系统自动识别章节结构、总字数、篇幅类型（长篇/短篇），并询问用户是要构建"可续写的完整写作工程"还是仅需"拆文库分析"。同时检测项目基础设施是否已部署（story-setup），未部署时提示用户选择先部署或降级为串行处理。
Phase 2：深度分析 — 根据判定的篇幅类型，自动调用对应的拆解管道：长篇调用 story-long-analyze 的完整 Stage 0-6 管道，短篇调用 story-short-analyze 的 Stage 2-6 管道。产物输出到 拆文库/{书名}/，包含原文备份、章节拆解、角色分析、剧情结构、情绪模块、文风分析等全套结构化资产。
Phase 3：结构迁移 — 将拆文库分析结果迁移为可续写的项目工程结构：
- 长篇：生成
{书名}/ 目录，包含 设定/（世界观、角色、势力）、大纲/（卷级大纲、卷纲、细纲）、正文/（标准化章节文件）、追踪/（伏笔、时间线、角色状态、上下文）、对标/（结构化资产同步） - 短篇：生成
{短篇标题}/ 目录，包含 正文.md（单文件全文）、设定.md（核心框架+对标摘要）、小节大纲.md（轻量蓝图）、对标/{书名}/（可选引用视图）
Phase 4：项目激活 — 执行质量检查清单，输出导入完成报告和待补充项清单，设置 .active-book 指针，确认项目可被对应写作 skill 识别。
关键设计
- 复用不重复：深度分析完全复用现有拆解管道，不维护独立方法论
- 拆文库即资产：
拆文库/ 是写作工程的一部分（喂给 对标/），非一次性中间产物 - 篇幅自动分流：根据结构信号、字数、用户声明自动判定长篇/短篇，决定后续路径
- 渐进式激活：大型作品（>200章）支持增量导入策略，首期导入前50章+全书概要
显著优点
1. 零门槛续写：让作者从现有素材出发，而非从零开始搭建项目结构，大幅降低续写门槛
2. 工程化标准：将非结构化的文本转化为标准化的写作工程，统一角色、设定、大纲、追踪等资产的管理格式
3. 智能分析复用：深度复用成熟的 story-long-analyze/story-short-analyze 拆解管道，自动输出剧情节奏、情绪模块、文风特征等专业分析资产
4. 双轨兼容：同时支持长篇（分章节管理）和短篇（单文件全文）两种创作模式，自动识别并分流
5. 对标资产沉淀：拆文库产物同步到项目 对标/ 目录，为后续日更循环提供文风模仿、结构参考、节奏对照的可复用资产
6. 状态追踪继承：自动生成 追踪/角色状态.md 等文件，让续写时的"状态筛选"有数据可依，避免角色设定崩塌
7. 开源可信：MIT-0 许可证，代码完全开源，无黑箱操作
潜在缺点与局限性
1. 依赖前置技能：深度分析依赖 story-long-analyze/story-short-analyze 的存在和可用性，若这些技能未安装或版本不兼容，导入流程将中断
2. 基础设施要求：完整功能（特别是长篇的并行 chapter-extractor agent）需要预先运行 /story-setup 部署基础设施，否则降级为串行处理，速度显著变慢
3. Agent 兼容性复杂度：需要处理 Claude/OpenCode/Codex 三种 Agent 运行时的兼容差异，包括 .claude/agents/ → .opencode/agents/ → .codex/agents/ 的查找顺序，以及 custom-agent registry 的可用性检测
4. 版本号不一致：当前 SKILL.md 声明 1.0.0，与 _meta.json 的 1.0.8 存在版本号漂移，可能引发用户困惑
5. 输入验证有限：对用户提供的文件路径缺乏严格的规范化处理和敏感目录拦截（如 /etc, ~/.ssh 等），存在潜在的意外操作风险
6. 旧拆文库兼容负担：需要同时处理 v12 新契约拆文库（必须含 剧情/节奏.md 和 剧情/情绪模块.md）和 pre-v12 旧拆文库的兼容性，增加了维护复杂度
7. 残稿处理被动：对于最后一章为残稿的情况，仅记录用户决定（"基于残章续写"或"先补完再导入"），不替用户做选择，需要用户自行判断
适合的目标群体
- 已有存稿的作者：写了几十万字但未规范管理的"烂尾"或"半成品"小说持有者
- 多平台迁移作者：需要将其他平台/编辑器中的小说迁移到 Claude Code / OpenCode / Codex 写作工作流的创作者
- 续写需求者：停笔一段时间后希望恢复创作，需要快速重建项目记忆和角色状态追踪
- 对标学习者：希望将自己的完本作品拆解为结构化资产，作为下一本书的对标参考
- 工作室/团队：需要将历史项目统一导入标准化工程，便于协作续写或改编
使用风险
1. 误触发风险：触发词包括"/story-import""导入小说""反向解析""导入""把我的书导进来"等，日常对话中可能误触发（如"我想导入一些参考资料"）
2. 项目覆盖风险：若目标目录已存在同名项目，迁移阶段可能覆盖现有文件（特别是 对标/{书名}/ 的文风文件）
3. 分类错误风险：篇幅类型判定（长篇/短篇）依赖自动检测，极端情况下可能误判（如超长单章短篇被误判为长篇），导致后续流程不匹配
4. Agent 不可用降级：若 chapter-extractor agent 未部署或运行时返回 unknown agent_type，长篇逐章摘要降级为串行处理，对于 500+ 章作品处理时间可能从分钟级延长到小时级
5. 依赖项缺失阻塞：v12 新契约拆文库缺失 剧情/节奏.md 或 剧情/情绪模块.md 时，导入流程会主动停下并要求修复，而非静默跳过，这可能打断用户 workflow
6. 存储空间消耗：大型作品（>100万字）的拆文库产物可能占用大量存储（章节拆解、角色分析、情绪模块等多文件重复存储原文摘要）
7. 状态同步延迟：追踪/角色状态.md 等文件基于拆文库产物反推，若后续手动修改拆文库但未重新导入，项目状态与拆文库可能产生分歧
整体而言，story-import 是一款设计严谨、工程化程度高的专业写作工具，适合有明确续写需求的网文作者，但需要注意前置依赖的完整性和版本一致性。