故事编辑、美术与出版流程

调研日期：2026-10-31。状态：制作流程与架构提案，尚未制作新故事页面或配图。 总计划见 docs/plan/story-rebuild-plan.md；来源/作品/版本与工作台字段见 docs/plan/story-review-tooling.md。

1. 从候选到成品，每一步留下什么

E1–E4 的文字可以完全先于美术完成；没有图的短篇也可以成为完整成品。AI 负责把材料组织到能判断的程度，不能用“模型觉得作者想表达……”代替与作者确认。

2. 编辑阅读与作者沟通

2.1 每部作品的编辑档案

档案分成读者可见部分和内部部分，导出与界面都要保持边界。

不把点赞、字数或模型“文学性分数”当推荐等级。选编讨论采用具体理由：文本是否成熟、题材是否有代表性、能否独立读完、连载是否可追、制作资源是否匹配。短而完整的作品可以比很长的作品更适合首发。

2.2 和作者聊什么

第一轮不发长问卷，也不要求每人写一篇“中心思想”。给作者看一份能修改的现成理解，再问少量关键问题：

1. 我们准备采用的版本和章节顺序是否正确？公开署名用什么？账号与笔名是否可以公开关联？
2. 这段简介有没有误解或剧透？我们理解的冲突/主题里，哪些接近你的想法，哪些应删？
3. 可以做哪些整理：标点、段落、标题、章分隔、删改、节选？是否需要逐次签收？
4. 是否包含转载、翻译、同人、共同创作或 AI 生成/辅助？公开时希望怎样准确说明？
5. 是否同意故事区面向访客展示并被索引？后续深入 AI 编辑、AI 配图、分享图和所需裁切的范围是什么？哪些人物/场面不要具象化？

后续仅补与该作品有关的问题，例如长篇缺章、角色外貌、历史服饰、不能提前揭示的身份。不主动索取真实姓名和联系方式；沟通内容由站长人工发出，本计划不授权工具自动联系作者。

初审的数据处理范围应在小批试验前，由站长依据现有社区约定、投稿许可和所选服务确认；明确限制离站的内容只在本地处理或暂缓。不机械要求先联系全部 214 个账号才可整理候选，也不把后续作者访谈当作追认此前处理的方式。作者沟通主要确认这部作品新增的公开、编辑和美术用途；超出原有范围的深入处理先确认再开展。

2.3 授权记录怎么拆

这是编辑用途的确认清单，不冒充法律结论。每项都保存适用作品/版本、范围、确认人、日期与私有凭据引用；不只放一个 authorized: true。

• 故事区原文展示范围：站内、仅链接、公开可列举/可索引。
• 编辑权限：格式整理、错字修订、节选、实质改写分别确认。
• 摘要、节选、封面/分享图与站内推荐的使用范围。
• AI 文本分析和 AI 图像制作分别确认；不把一项默认包含另一项。
• 文字 AI 使用与图片 AI 使用分别标明，不能因为配图由 AI 生成就给整部小说贴“AI 小说”。
• 原文、图片或字体是否允许进入公开 Git 仓库；网上能读不自动表示允许再分发源文件。
• 署名、共同作者、原作者/译者/改编者、修改后重新签收与撤回方式。

转载/翻译涉及的第三方许可尚不清楚时留在内部候选；站长与投稿者的同意不能替代原权利人的许可。作者暂不回复就跳过新增用途，不为凑首发数量推断默认同意。

2.4 文本定稿的纪律

保留来源原文，编辑稿生成独立修订。空格、段落、标点建议与删句、换词、改情节分别展示；AI 不自动重写成统一“优美文风”。对话语气、方言、非常规标点可能是创作选择，疑问交作者处理。

定稿锁定后再生成稳定段落 ID。设计引用段落或章节 ID，而不是“第 5,000 个字符附近”；改稿导致 ID/内容失配时，图片位置、引用、摘要和章纲要标过期。允许签收无图版后只补装饰素材，但若图片改变人物解读或透露情节，仍需补签收。

3. 选编层级与首页

把作品分层是编辑资源分配，不是公开价值排名：

• 主推：当前最能代表故事区的一部完整制作，封面、介绍、阅读路径都成熟。
• 精选：已完成编辑和样式，有明确推荐理由；数量少而稳定。
• 作品目录：经确认可收录，但不要求每部都具备重美术。
• 旧版入口：兼容尚未重做的既有内容，标明状态，不伪装成已精编作品。
• AI 创作/转载等独立集合：是否设立由选编政策决定，标签准确，不能藏到目录深处才说明。

建议首页首屏出现具体作品封面、作者、短介绍和阅读入口，后接 3–6 部精选、类型入口与完整目录。标题和标签只承担必要信息，不用泛泛的抒情口号制造“文学氛围”。避免大横幅占完手机首屏但看不见任何作品。

短篇默认点进就读；长篇先有作品页和目录，可“开始阅读”或按本地记录“继续阅读”；互动作品明显标为互动，不显示误导性的纯文本阅读时长。

4. 美术与排版如何按作品做

4.1 共用阅读器，定制内容表达

共用基础：页面外壳、目录、进度、章节导航、字体/主题偏好、焦点、图片载入、错误与纯文字模式。每部作品定制：封面、局部配色、字体组合、章首、分隔、插画布局、留白节奏和少数专用组件。

实现依照 docs/frontend-styles.md §3/§4/§7.2/§7.5。原创插画与阅读内容可以有专属视觉，公共顶栏、按钮、焦点和明暗主题仍使用站点规范；不为一本小说修改全站按钮样式。

建议先做三种可复用版式，再允许少数特殊作品扩展：

同一部作品的章节通常共享一套视觉语言。逐章不同可以服务结构，但不能变成每页都要重新学习的操作方式。

4.2 试点的视觉假设

以下只是基于少量抽读的可讨论方向，不是作者已确认意图，也不是已经完成的设计：

• 《燃料》：先比较留白、对话节奏和少量红色物象的方案；不把关键解释直接画进封面，不靠灾难场景夸大题意。
• 《阿提亚的四季童话》：楔子中的山地、雾和海岸可作为环境方向；先确认世界设定，再定地貌、服饰与人物。不能仅因书名就自动做春夏秋冬四张通用插画。
• Connizarro 的短篇：可讨论物件、空缺与概念性构图；不同短篇先分别读完，再决定是否共用合集视觉。
• Cattca：先跑通分支与结局，再选择舞台感；图片不能覆盖可选项或把未走到的分支结局提前展示。

4.3 一张图为什么出现在这里

先画无素材线框，把每张图的任务说清楚：建立环境、表现意象、承接章间停顿、提示新的时间/空间，或作为纯装饰。没有任务就不出图。

每条素材需求至少包含：关联作品/章节/段落、叙事功能、能公开到哪一步、画面不可出现什么、是否具象人物、横竖比例、手机裁切焦点、文字留空位置、替代文本意图。

图不固定按“每 800 字一张”插入。对话中途、悬念揭晓前、同一连续行动中通常不打断；首图不能把读者整屏挡在正文外。正文不烧进图片，题字由 HTML/CSS 排版；纯文字模式保留完整正文、章序和必要说明。

4.4 从简报到最终图的制作步骤

1. 视觉参考与来源检查：优先作者自有、站长自有与可用的公开授权资料。参考图不自动进入最终出版包；记录许可与适用范围。
2. 建立基准：需要重复人物时先确认形象表、服饰、地点与色彩；不明确的形象可以用背影、局部或环境表达，避免替作者过早定型。
3. 小样对比：围绕一个任务先做 2–3 个方向，选定构图再做高清图；不一口气给整部长篇生成数十张。
4. 局部修改：对获选图修构图、物件、服饰或留白；保留生成版本、参考与修改记录，减少反复重抽导致角色漂移。
5. 内容验收：人物、数量、道具、时代、空间关系、文字伪影、面部/手部与剧透逐项看；跨章重复角色并排比较。生成模型不能保证自动一致。
6. 导出：保留高质量母版，生成桌面/手机裁切和 WebP/AVIF 等交付尺寸，检查暗底/浅底、透明边缘与图片压缩。
7. 落版复看：图放进实际段落再评估，不以单张“好看”代替排版通过。作者/站长确认后标为获准素材。

图像工具支持从描述生成及对已有图进行编辑，适合上述渐进流程；具体工具/模型在制作时选择，不把当前能力写成永久承诺。OpenAI 图像生成与编辑

4.5 素材台账与提示模板

台账保存素材 ID、母版哈希、来源类型（作者/自绘/AI/第三方）、许可或制作记录、模型与日期、所用参考、获准用途、修改版本、裁切焦点、alt、对应段落和签收状态。提示词和私有参考留工作台，公开页只显示必要的图片来源说明。

以下模板交给图像工具前，要先填写，不能把全章原文和作者私信直接粘入提示：

作品/章节：<稳定ID与已获准的最少上下文>
图片用途：<封面/环境/意象/章节分隔>
正文锚点：<段落ID>
必须符合的事实：<地点、人物、服饰、季节、道具>
视觉方式：<媒介、色彩、光线、材质、构图>
已确认参考：<可用的本地素材或形象表>
不得出现：<剧透、未确认人物外貌、错误时代元素>
交付：<比例、画幅、手机焦点、留空区域；正文与标题不入图>
一致性：<关联的获准人物/场景图>

自制且有公开权利的素材可按仓库约定入库；第三方素材只有明确允许再分发才可入库。未确认素材与预览图放私有目录，不先放进 public/ 再靠隐藏页面保护。

5. 版式数据与出版包

5.1 建议的分层

可评审代码
  共用 StoryShell / Reader / 受控图文块
  作品专用组件与样式（仅确实需要时）
  公开 metadata 的字段契约、校验器与路由规则

私有编辑数据：instance/story-workbench/
  来源快照、人工记录、作者确认、摘要草稿、原图与设计简报

审定发布数据：instance/story-published/
  releases/<releaseId>/manifest.json
  releases/<releaseId>/works/<workId>/...
  current.json                 ← 当前完整版本指针
  withdrawals.json             ← 独立、不能被回滚复活的撤回清单

这里的路径与结构是提案。默认从已确认出版包提供正文，不从博客实时拼装，也不扫描工作台生成公开页。未来若某作品明确允许公开仓库再分发，可以将该作品定稿与素材纳入代码评审；不能将此作为全部作品的默认前提。

5.2 正文与图文布局分开

正文是经确认的章节修订；布局引用段落 ID，允许有限的块类型：章首、正常段落、场景分隔、插图、图文并列、引用摘句、作者说明、互动播放器。新块先实现/测试，再进入白名单。

示意（不是可直接运行的最终格式）：

{
  "workId": "work-example",
  "editionId": "edition-01",
  "textRevision": "text-03",
  "layoutVariant": "prose",
  "blocks": [
    {"type": "text", "paragraphIds": ["p-001", "p-002"]},
    {"type": "figure", "assetId": "art-01", "after": "p-002"},
    {"type": "text", "paragraphIds": ["p-003", "p-004"]}
  ]
}

编译校验正文每段恰好出现一次且顺序不变，除非存在作者确认的节选/重排许可；引文块引用的重复段落另标角色，不计作正文重复。不得因为 JSX 复制或图文交错漏掉一句。

模型只生成布局建议，不能生成发布时执行的任意 JS、MDX 或原始 HTML。导入博客/AI 内容使用安全 AST/净化管线；旧故事 stripScripts 的可信假设不能直接继承。人工审核的定制 React 代码单独走代码评审，不让模型输出的数据获得代码执行权限。

5.3 出版包的完整性校验

• 作品、章节、章序、段落、素材 ID 唯一；不允许路径穿越、重复 slug、别名循环或目录/作品冲突。
• 锁定原文修订和图像哈希，所有引用指向包内存在且获准的内容。
• 公开 metadata 只有确认过的标题、署名、无剧透简介和公开标签，不包含内部梗概/凭据/来源账号关联。
• 纯文字版本的规范化正文与定稿一致；图文版段落覆盖一致。
• 发布资格、展示范围、索引范围、必要许可、签收与无未决阻塞全部满足。
• 不将内部博客引用、私有图片路径、作者私信或工作台数据打进客户端 JS、source map、RSC、分享图和 sitemap。

6. 页面实现与阅读验收

6.1 路由与渲染

建议给新作品预留显式命名空间，例如 /story/works/<slug> 与 /story/works/<slug>/<chapter>。实际采用前先确认旧路径无冲突。路由由审定清单映射到稳定 ID，标题改名不改变作品 ID，slug 改名保留别名。

第一阶段沿用当前动态根布局和登录态顶栏，服务端只读取已发布版本的正文/布局，正文可预编译并按版本缓存。不为追求 SSG 给整个故事区强设 force-static，也不关闭站点登录功能。

Next.js 15 的 generateStaticParams 可以枚举构建期路径，但完整静态化要审视根布局等动态依赖。若以后确实需要 CDN 静态正文，可以在验证读者身份与撤回语义后另设计静态内容层；不在首轮重构根布局和整站部署方式。Next.js 15 路由枚举说明

6.2 阅读与性能基线

以下为初始验收目标，样板实测后调整并记证据；不是当前页面已有的成绩。

• 正文优先使用现有阅读字体栈；可试约 18px、1.9–2 行高与约 28–38 个汉字行宽，尊重用户字号/缩放。桌面大图可超出正文列，文字仍保持稳定行宽。
• 手机先单列，图文并列自然变为按语义顺序排列；不依赖 CSS 重排改变朗读顺序，不把文字压在复杂图像上。
• 标题、目录、章导航与首段在首屏容易找到；没有下一章时不显示假的可点击按钮；←/→ 不抢输入框、可编辑区域和互动播放器的键盘。
• 阅读位置用 workId/chapterId/textRevision/paragraphId 存本地，版本变更时安全回退到最近有效位置；第一阶段不另建账号同步服务。
• 无 JS 时普通故事正文、目录和章节链接可读；互动故事提示需要脚本，不能伪装成可交互。纯文字模式关闭非必要装饰，不删必要叙事说明。
• 必要图片给不剧透的替代文本，纯装饰用 alt=""；正文仍是可选择、可复制的语义 HTML。W3C WAI 图片用途与替代文本
• 图片带尺寸与响应式源，首屏主图合理优先，后续图片延迟加载；不默认下载所有章的图或为简单阅读引入重动画库。
• 暂定手机首屏图片合计目标约 500KB 内，章节新增 JS 压缩后约 50KB 内、普通阅读器不重复拉大库。超预算记录原因；互动引擎另计基线。
• 以受控移动网络实测 LCP ≤2.5s、CLS ≤0.1 为目标，条件和视口随记录保存；JS 交互用实际设备试验，后续有流量再看真实用户数据。不能把本地开发模式测试当线上指标。

6.3 最小验收矩阵

开发按仓库纪律按风险跑适用验证（相关测试、必要时 typecheck），全量按根指引的触发条件执行；页面改动另做真实预览/目标 e2e。探针可复用 scripts/probe-page.mjs，不反复手写浏览器启动脚本。快照测试不收真实未授权文本。

7. 迁移、发布、撤回与回滚

7.1 先列全旧地址，再替换入口

盘点全部旧合集与故事 URL，包括中文、空格、多层目录、Cattca 和直接访问的旧文件。为每条记录选择明确去处：对应新章节、作品目录、保留旧版、或经人工决定的撤回页。

• 一对一迁移可永久重定向；一旧文件拆多章时跳到能解释关系的作品/阅读入口，必要时保留旧版并提供章目录，不能随意只指第一章。
• 同标题不同作者不合并；新路径使用 ID 关联，标题和笔名只是展示字段。
• 旧内容未审完时保留既有允许范围的兼容入口；已发现授权/可见性问题的内容由站长决定暂停。目录隐藏不能替代所有读口的发布检查。
• 清单必须区分合集与作品；“小说集 1/2/3”的旧入口能到相应作品集合，而不是全部跳故事首页。

7.2 搜索、分享与来源链接

sitemap、故事目录、站内推荐、metadata、OG 图与正文都由同一份已发布且可列举清单生成。仅链接作品可直接读但不列举/索引，站内作品仍校验读者；公开首页不能暗中列出其标题和封面。

作品首页通常 self-canonical。章节若与一个已公开可索引博客实质相同，首轮可 canonical 到该博客；若故事版已被确认为独立正式版本，则在发布清单明确其规范地址。不能 canonical 到访客看不到的站内博客，也不自动修改原博客的 visibility/canonical。

原博客链接只在读者有权访问且编辑决定展示时提供；不复制原评论、点赞与鱼干数字。JSON-LD 使用 src/lib/json-ld.ts 的既有安全出口，机器时间遵守项目时间约定；标题/简介由公共字段白名单序列化。

7.3 发布步骤

1. 冻结本批：选择少量作品与明确版本，所有签收对内容/布局/素材哈希有效。文本或关键素材修改后签收失效。
2. 重查来源与资格：比对最近来源状态、软删、可见性与许可变更；生产上发布时也要核对实际来源，不把旧本地快照当当前事实。
3. 生成候选出版包：在 staging 目录构建、校验，检查 URL 映射、素材、段落覆盖、公共字段和构建产物；原版继续服务。
4. 私有预览：owner 鉴权覆盖 HTML、RSC、接口和图像；noindex 与 private/no-store 只是补充，不能代替鉴权。预览素材不进公开 public/。
5. 签收实际页面：站长/作者按约定范围查看最终版，不只签收文字或单张插画。形成可评审变更摘要。
6. 切换版本：出版包完整落盘后原子切换当前指针，读口一次请求固定同一 release，避免目录、正文与图像各读到一版。
7. 发布后核对：匿名入口、主推/目录、旧链接、图片、章序、canonical 与 sitemap；保存检查结果和前一可用版本。

这是一套将来实施的产品发布流程，不包含本机私有服务器地址或部署命令。实际代码发布遵守仓库已有操作约定，本次不执行。

7.4 公开版本也要能撤回

“正文固定下来”不能变成“撤稿只能改代码再部署”。保留独立的运行时撤回清单，由正文、metadata、OG、资产与列表读口共同校验；状态先停用，随后移除推荐/索引、处理缓存和相关文件。

当来源转为站内/删除、作者撤回或发现来源问题时，默认暂停对应公开版本并进入复核。若有独立且仍有效的故事版许可，由站长明确决定恢复，不能依据旧博客权限自动继续公开。

回滚只更换成品版本，不回滚撤回清单或复审历史，防止旧版本复活已撤作品。故障演练应包含切回前一版，以及切回后撤回仍有效。已经公开或进入公开 Git 的副本无法保证从外部缓存/克隆中追回，因此在入库前单独确认再分发范围，并为公共资产选择有界缓存策略。

8. 给 Codex 的逐部制作交接单

每次交接一部作品或一批明确的页面，不给“把这些小说做漂亮”这种无法验收的任务。下列材料都保存在工作台，可导出为一个包：

任务范围：<作品ID、版本ID、需要制作的页>
定稿：<章节修订与哈希；不可改动的正文边界>
事实与署名：<获准公开的字段>
读者文案：<获准无剧透简介、连载说明、来源/AI标签>
设计简报：<已选择方向、参考、线框、基础版式>
布局：<段落顺序、图片锚点、移动端顺序>
素材：<获准资产ID、尺寸、裁切焦点、alt与来源>
交互：<开始/继续、目录、章导航；互动播放器要求>
限制：<禁止剧透/人物定型/额外改写；未获准素材>
兼容：<旧URL、canonical、原博客链接规则>
验收：<手机/桌面、明暗主题、纯文字、权限、性能目标>
发布：<仅私有预览，或本批已有明确发布授权>

Codex 可以在这份材料上实现页面、补必要组件、调整排版、给出实际截图，并按明确问题迭代；新增情节解读、正文改写或新配图用途回到编辑环节确认。这样重复制作的成本逐渐下降，作品也不会因为每次对话换了一批上下文而失去一致性。

9. 上线后的持续节奏

• 每周：导入新增/变更来源；AI 初审和人工复审形成少量明确下一步，不要求每周都上新。
• 每月：选择 1–3 部可完成的作品，检查作者回复、定稿与素材卡点，更新首页主推。
• 每次新章：复用已确认作者档案与视觉语言，只对新章和受影响摘要/素材复审，不重复审整部长篇。
• 每次改稿：展示版本差异，决定是否更新故事版；发布后阅读位置安全迁移，必要时写简短修订说明。
• 阶段回顾：看一部作品从候选到出版花多久、卡在哪、初审漏了什么、图像返工为什么发生；不只看新增多少张漂亮封面。

这套流程最终要让站长花时间做选编与作者交流，让 AI 和代码承担重复阅读、材料整合、版式实现与可验证的制作劳动。