故事区重做计划

调研日期：2026-10-31。状态：方案完成，工具、内容重编与新版页面均未实施。

这次重做要交付两样东西：一个能持续发现、整理作品的编辑流程，以及一个值得放在网站首个入口的故事区。只有小说列表，页面仍会停留在旧状态；只有漂亮页面，新投稿仍会继续积压。

建议采用 人工策展的首页 + 按作品定制的版本 + 共用的阅读基础设施。页面结构、章节顺序、配图位置和推荐顺序由编辑确认；正文保持可追溯的独立内容文件。先做出 3 个完整的作品样板，再逐批扩大。不把“整理完全部历史文章”设为新版上线的前置条件。

1. 怎么读这份计划

本文给出建议默认值，方便下一次直接开工。标为“待决定”的产品取舍在遇到相应作品时解决，不阻塞只读盘点、人工复审原型和旧内容映射。

2. 调研后应当先做的判断

2.1 真正的规模与难点

本地快照中有 6,196 条博客记录，其中未软删除 4,909 条，来自 214 个作者账号，正文原始字符合计 27,091,994。未删除文章中，“文学&艺术”栏目只有 548 条，不能用它代替全站筛选。

文章原始长度中位数是 113 字符，但 207 条超过 30,000 字符，这部分占全部正文字符约 83.7%。因此要同时处理大量极短内容和少量超长内容。标题、栏目和开头只能用来安排阅读顺序，不能据此永久排除小说。

旧故事区有 8 个顶层合集，包含 265 个 Markdown 文件与 7 个 Cattca 文件。其中 Life 精选集占 231 个 Markdown 文件。这些是文件数，不是独立作品数；长篇、合集、单章和完整短篇现在混在同一层概念里。

还有两件事比页面风格更早影响方案：

• 未删除博客中有 4,907 条为 internal，只有 link、public 各 1 条。站长能读到，不代表可以把全文、摘要、标题或引用资源放到公开故事页。
• 旧故事与博客不是一对一关系。去除文件头和空白后，只有 8 个 Markdown 文件能与现存博客正文完全匹配。其余不能据此说“没有来源”：可能有合章、编辑、改稿、私下投稿或本地快照差异。

以上仅是 2026-10-31 本地快照统计与抽查，没有调用模型给全量文章分类，也没有核对生产数据库。 详细调研报告保留在本地 reports/，不随仓库发布。正式导入前须以只读一致快照重新盘点： 未删除口径为 ignore IS NULL OR ignore = 0，字符数为原始正文长度；故事与博客的去头、去空白 完全匹配只提供候选映射，不替代来源与作者确认。

2.2 “写死”应当写死什么

“定制页面”不等于“完全静态导出”。根布局现在读取登录用户，不能因为写了 generateStaticParams 就承诺整页成为静态 HTML。第一阶段目标是确定的已审定版本、读取时不扫候选库、不调用 AI。预渲染和缓存单独验证，见 docs/plan/story-editorial-design.md §6。

2.3 AI 与人分别决定什么

AI 做全文覆盖、内容类型建议、章序候选、证据摘录、摘要初稿、访谈问题、视觉方向和页面实现。站长决定选登、作者归属、来源与 AI 使用情况、推荐层级、公开范围；作者确认署名、定稿、改编尺度、配图与其意图是否一致。

AI 生成、AI 辅助、转载、原创、是否值得推荐是不同维度。 模型文风判断不能成为公开标记。Life 的小说按站长已提供的情况登记为待逐篇核对的已知线索，不把 Life 账号所有博客自动判成 AI 小说，也不把别的作者自动判成人类原创。

3. 最终产品的范围

3.1 读者看到的故事区

1. 故事首页：一部主推、数部精选、明确的长篇/短篇/互动入口，以及完整作品目录。首屏直接展示具体作品与作者，减少从“小说集 1/2/3”逐层点进去的距离。
2. 作品首页：封面、署名、无剧透简介、篇幅和连载状态；长篇有显式章序、开始/继续阅读入口；短篇可直接进入正文。
3. 阅读页：稳定正文行宽、章节导航、目录、阅读位置、图片与文字有目的地组合；可切到纯文字阅读。
4. 专题或作者集合：内容足够时再做，首发只需最小作者介绍和作品关联。
5. 旧版兼容：没有重做的内容仍有可理解的去处；已迁移旧 URL 指向对应新版本，不能整批跳故事首页。

3.2 编辑端形成的长期资产

• 每条来源的版本、AI 建议和人工结论。
• 每部作品、每一章与多条来源之间的映射。
• 作者署名档案、授权范围和待核对事项。
• 经确认的编辑档案：摘要、主题解释、章纲、敏感情节与配图边界。
• 素材台账、设计简报、定稿出版包和可回滚发布记录。

这些资产可以导出，不能只留在一次聊天里。工具失效或模型更换时，人工结论与成品仍然能继续使用。

3.3 首版暂不建设

全功能投稿 CMS、自动文学评分榜、自动发消息给作者、全站自动查重爬虫、全量自动生图、每部作品一个完全不同的阅读器、推荐算法、音频朗读、电子书导出。它们都不是首版完成所必需。

4. 两条工作线与共同的发布关口

内容工具线负责发现和整理；样板出版线负责尽早完成可读成品。两条线可以交错推进，不必等批处理跑完整库。

只读快照 ─→ 小样本人工标注 ─→ AI 初审与复审 ─→ 持续候选池
    │                                │
    └→ 旧故事与已知作者试点 ────────────┘
                      ↓
           作品/章节建档 → 作者确认 → 编辑定稿
                      ↓
             视觉简报 → 配图 → 页面样板
                      ↓
             出版包校验 → 预览签收 → 分批上线

任何来源都必须经过同一套定稿与发布检查。旧故事“已经展示过”不能代替新用途授权，AI 初审“通过”也不能代替人工选登。

5. 分阶段实施

工期按一位开发者配合站长估算，表示有效工作日，不含等待作者回复，也不是承诺排期。每阶段完成一个可验收的小闭环，随后再扩大。

M1 就要能独立使用，不能先造完全部 AI 调度器才允许人工读文章。M3 与 P1/P2 不互相等待。预算紧时先交付 M0、M1 和一个完整短篇样板。

5.1 下一轮开发的具体顺序

1. 建立最小字段和持久化存储，写只读盘点/导入器；默认无网络。
2. 做“左侧待办、右侧原文和结论”的工作台，支持保存、筛选、撤回、导出。
3. 导入旧故事并人工关联 Audrey、Connizarro、Efforia 的少量已知作品，验证一章多来源与一来源多章。
4. 用真实样本制作标注集，再接可替换的 AI 初审适配器；先跑 20 条检查，再跑评测集。
5. 同时选一篇有明确授权的短篇，完成编辑档案、定稿、无图版和一张图的出版演练。
6. 评测通过后扩大批次，并把短篇样板扩展为长篇和互动样板。
7. 最后替换故事首页和旧路由入口，逐部增加成品。

工具字段、队列与任务拆解见 docs/plan/story-review-tooling.md；作品制作步骤与交接模板见 docs/plan/story-editorial-design.md。

6. 首批试点怎么选

首发完成度优先于作者名额或作品数量。长篇无须等完结才能入选，但必须清楚标“连载”，不能把暂缺章节包装成完结作品。

7. 人力、费用和质量如何收住

7.1 不把人工从“读 5,000 篇”换成“审 5,000 张表”

工作台默认按作品候选与不确定项组织。已知重复内容可共享 AI 分析，但保留每次投稿的来源与作者；疑似同一连载可整组查看，批量动作必须预览影响范围。

假设初审后有 400 条候选、每条快速复审 2 分钟，就是约 13.3 小时；若是 1,000 条则是约 33.3 小时。400 和 1,000 都是容量情景，不是本次识别出的小说数。 长篇完整阅读、作者沟通和定稿另外计时。先记录 30 条真实操作耗时，再制定每周可承受的处理量。

建议每周两个 45 分钟的复审时段，每月集中制作 1–3 部作品；站长只对需要判断的节点做决定，AI 和工具负责资料整合与重复劳动。

7.2 先测费用，再下全量任务

不以中文字符直接折算账单。小批试验记录实际输入、输出、分段重叠、重试和更强模型升级的 token；按任务层分别外推全量费用。分类用较经济模型，疑难项升级，详细编辑分析只对入选作品做，生图只在简报通过后开始。

每批显示预计费用、预算上限、已用金额和未完成量；预算到线停止创建新请求，已返回的结果照常归档。可用异步 Batch 降低非实时任务成本，但模型、端点、保留策略与价格在实施时重新核对。OpenAI Batch 官方文档

7.3 判断是否做成

8. 待决定的事项与建议默认值

9. 本次交付边界

本次只提交调研与计划，以及文档索引登记。没有修改文章、写入业务数据库、调用付费 AI 批量分析、生图、联系作者或部署。

后续实施时，现行故事指南仍以 docs/guide/story-module.md 为准；新行为通过验收后再更新指南和架构说明，不能把本计划提前当成已交付功能。