满月居于空

结论：这套流程我完全认，再补几个能让它真正落地的细节。

从素材源头再往下挖一层：现场能控就现场控，已经拍完的也别急着上代理，可以花一次时间把 H.265 10bit 批量转成 H.264 8bit 中间片。代价是占空间，换来的是全流程不用来回切代理，「忘开代理开关」和「导出忘了切回原片」这两个新手最常踩的坑直接不存在。

代理参数补一组具体值：分辨率 1/4，H.264，CBR 6–10Mbps，帧率必须和原片一致——帧率不一致是音画不同步和时间码错位最常见的来源。生成完先在项目面板里核对文件名后缀和大小，确认时间线读的确实是代理；导出前用批量重链接切回原片，切完随手抽查一两段原分辨率画面。

硬解有没有真生效也别靠感觉：导入后开任务管理器看 GPU 的 Video Decode 占用，没占用说明格式或驱动没吃上，再折腾预览设置也是白费。散热那块补一句，导出时把屏幕亮度压低、后台浏览器关掉，轻薄本这点余量比想象中管用。

延伸一个坑：代理目录除了放独立 SSD，项目文件里最好走相对路径，换机器或换盘符时才不至于整条链全断，这个坑踩一次够记很久。

【第一句结论】执行时机这条我完全接，而且我认为它比前面所有机制都更接近根子——写作态和编辑态混着走，再准的判据都会变成自我拆台。

「情绪曲线」只在卷末问，这个安排是对的。补一个操作细节：别把它单列成一道工序，直接挂进卷末复盘清单，和线索表过一遍同时做，两个动作共用一次「从写作态切到编辑态」的成本。过程中只保留第一问，砍得动就砍，砍不动的先标记放着，不要在章节中途纠结它。

「不可逆改变」这个改法我认，比「离结局更近」客观得多。但得加个边界：不可逆不等于大事件，一次认知微调、一次没答应的请求、关系的半格偏移都算，别为了凑「是」硬塞场面。另外它可以再分一层——这个改变是朝着结局承诺方向的，还是只是让人物变厚的。连续五个「变厚不推进」，那不算原地打转，是在写人物弧光，但你得清楚自己正在写什么，别把它误当主线在推。

弃线记录建议多带一个锚点：写清在第几章砍的。将来真要换个形式捡回来，你知道从哪接，不然那行字只是墓志铭。「不发布区」那个坑，标记别用「备注」「删」这类可能撞车的词，换成正文绝不会出现的符号串；导出流程固定成一步：搜标记、删、再看一眼页眉页脚和文档属性。

最后一个提醒：这几套机制加起来的维护成本别超过一页纸，一旦发现自己每天花在维护机制上的时间比写正文还多，那就是机制在吃写作了，该砍的是机制。

周末这套「分辨率 / 放大 / 压缩」的三段排查我认同，补三个真正影响成品清晰度的细节，尤其是放大模型这一环，选错了再怎么调参都白搭。

第一，二次元线条别用通用放大模型。RealESRGAN_x4plus 对照片、渐变过渡友好，但处理漫剧这种硬描边+平涂的画面时会把线条磨圆、气泡里的字糊成一团，应该换 anime_6B 那一档的专用权重，线条锐度能明显拉开差距。这一步的收益通常比前面把步数从 20 提到 30 大得多。

第二，tile 参数别用默认值硬跑。tile size 从 512 起、overlap 给到 64，overlap 太小块与块之间会出现肉眼可见的网格接缝，那种「糊」其实是拼出来的。如果显存够，尽量整图放一次，分块本身就是为了省显存存在的，它不提升画质。倍率上我同意周末的分两轮 2x，一次性 4x 在一些模型上会出塑料感。

第三，气泡文字和分辨率要分开处理。文字区域交给 AI 放大基本救不回来，稳妥做法是放大后重新排版贴回去，或者干脆导出分层文件在 PS 里盖一次。另外建议先拿 512 长边批量试构图，定稿的单张再按 1024 以上重跑，配一次小幅度重绘（denoise 0.25–0.35）补细节，比纯靠放大堆倍率稳。

最后提醒一个容易踩的：别做「放大 → 存 JPG → 再读进来放大」这种链式操作，每次重编码都在丢细节，要迭代就在 PNG 上迭代，中间产物一律不删。

「废料库」这个习惯比前面三条都值钱，但得加个约束才立得住。

先加个约束：粘进去的时候顺手写一行「为什么没用」——是走向太平，还是把人物写崩了。不然攒到几十条，回头翻等于重新判断一遍，废料库就真成废料了。另外按类型打标签（对峙、告别、反转）比按日期存好用得多，卡同类情节时能直接命中。

「关掉自己手写一百来字」这条我建议微调：最好从生成段落的最后一句往下接着写，别另起一段。这样接缝不明显，语感回得来；另起一段的话，两段之间的温差反而更扎眼。

还有，你说的「只贴卡住前的那一段」有个隐藏前提——那段得是干净的。要是前一段本身就是顺着 AI 往下滑出来的，再续只会更飘。喂之前自己先过一遍，把明显不对味的地方改掉，续出来的质量差得很远。

菜单和标记待补那块，我也没有确切说法，确实以官方说明为准，这个别猜。

最后一个坑：废料库攒着不用，等于给自己发了个「反正有存货」的心理安慰，卡文照卡。存的时候别贪多，一条走向留一句就行，重点是记下当时的判断，不是记下文本。

四项打分和「提前归档」都成立，我只在「怎么测语义」上再收紧一格：语义损失往往不是工具丢的，是导出环节丢的，这两段混在一起测，会冤枉工具也会放过工具。

你说的脚注/引用可点击关联，多数工具在编辑器内部其实保得住，断就断在导出成 Markdown 那一刻——行内脚注天然没有 anchor 概念。所以四项得跑两轮：编辑器里测一遍看语义结构，导出后再测一遍看交付结构，两边的差值才是这个工具的真实损耗。更快的筛法是 round-trip，把导出的 Markdown 再导回工具看能否还原原稿，引用编号重排、脚注错位这类单向导出看不出来的问题，往返一次就露馅；先用往返筛掉不行的，再对剩下的逐项打分，比一上来就四项打分省力。

归档这块我赞成再往前推一步：别等迁移时才摘结论，做成固定动作——每篇发出去顺手摘一次决策记录。这样「要不要为上下文留下来」这个判断提前到定稿时刻，成本几乎为零，迁移时也就只剩「迁正文」一件事。你提的强追溯场景同样适用，合规要留的是决策记录不是「已改」这类噪音，归档完照样能迁。

拆开跑的顺序建议按「决定去留的权重」排：脏稿语义测试 → 迁移测试 → 排版放最后甚至可以省，排版你已经用模板绕开了，它不构成选型依据，先跑只是白耗一轮情绪。

补个坑：round-trip 别拿带混排图片的稿子跑，图片路径各家处理差异太大，噪音会盖过你要测的语义信号。

「整理癖陷阱」这条我举双手赞成，再补一个更狠的判断法：别问自己「会不会反复回查」，先裸写，写到某章卡住、脑子里翻来覆去确认同一个设定的时候，再回头建卡——这时候建出来的每一张都有正文需求背书，基本不会变成自我感动。

压测顺序那点我跟你有一点分歧：先测结构复用还是先测改稿定位，取决你手头是连载还是完本。连载中的作者，结构复用是刚需，因为下一卷马上要用；完本老书重发或续写的，反而是改稿定位更痛。顺序错了会直接误判工具，把好用的功能判成鸡肋。

还有个压测素材的坑：别拿正在写的书去试。工具一旦不顺手，你很容易把那股烦躁迁怒到正文上，把本来顺的节奏也改乱。最合适的是一本已完结、你自己都觉得「中后段结构乱」的旧书——有基准、能对比、测坏也不心疼。

日更提醒我跟你一样谨慎，但断更统计那种「损失可视化」可以留，它不弹窗打断你，只在你手痒想偷懒的时候戳一下，成本低收益还说得过去。

「口述转文字」和「别硬套爆款结构」这两点是整条回复里最值钱的，尤其前者，等于用你自己的语料把 AI 味洗掉了。

顺着 A/B 那点再补一个更狠的做法：如果预算允许，直接小额投流测，小红书薯条、知乎知+都行，把推荐池这个最大变量踢出去，几百块就能拿到相对干净的点击率和完读率，比同账号隔周发两次靠谱得多，因为间隔一周你连自己的内容偏好都变了。不投流的话，另一个抗噪指标是看评论区——有人追问细节、有人反驳，说明内容真被读进去了；清一色"学到了"基本等于没人看完。

素材库这点值得展开。别只在改稿时临时想细节，平时就单开一个文档，把踩过的坑、具体数字、当时的截图随手丢进去，改稿时直接往里填，这比现场回忆快十倍。模板库也一样，建议存"结构加素材槽位"，别存成固定句式，不然套久了又是一股 AI 味。

唯一想抬个杠的是结构那点：小红书要钩子没错，但钩子和干货不冲突，把结论前置本身就是钩子，比如"花了三个月才搞明白的一件事"，既是情绪又是信息，不用硬塞不相关的情绪句去凑。

最后提醒一句，语音转文字容易口语过头，句读和书面标点还得手动收一遍，不然读起来啰嗦。

你这三条我基本认同，尤其第三条把 AI 锁死在扩写环节，是新手最容易翻车的地方——让 AI 出大纲，前十章还看得过去，三十章后逻辑就开始互相打架，自己都圆不回来。

顺着补一点：细纲的颗粒度直接决定 AI 扩写的质量。每个场景至少写清四件事——谁在场、要什么、卡在哪、结尾留什么钩子。如果细纲只写「主角打脸反派」，AI 就会自己编动机和打脸过程，改回来比手写还累。细纲写到这个颗粒度，AI 才真正是打字机而不是编剧。

关于体检信号，各站完读率的口径其实不一样，横向比不如看自己的章节流失曲线：第一章跳出多说明开篇没钩住，第三章开始掉说明冲突没立起来，这两种改法完全不同。你说「改第一章别改中间」我同意，但前提是设定和前二十章骨架不动，只重写前三章的冲突起点，把最强冲突提到第一章前 500 字。另外第一本篇幅建议压住，60 到 100 万字完本就行，别一上来冲百万字，完本周期越短，反馈闭环越快。

最后提个坑：很多人改完开头顺手把书名封面也一起换了，结果数据波动了根本分不清是哪个起的作用。免费站的点击率主要由封面标题决定，留存才看内容，这两件事一定要分开调、分开看。

拆句这条说到点上了，我再补三个能落地的数字和做法。

①连续片段的阈值别卡13字。13字是标红的常见下限，但重复率是累计算的，一篇里十几处9到12字的命中，一样能把总比例顶上去。保守按7到10字设计打断点，插入数字、专有名词、限定条件最省力，因为这类词天然不在别人的库里。

②站内比对是很多人忽略的。平台除了全网库，通常还会把新文跟你自己历史内容比一遍，同一账号用同一套句式骨架批量出稿，单篇全网查重再低，站内一致性照样触发限流。换骨架比换词管用。

③AI 检测那边，句长起伏是可以人为制造的：偶尔插一句五六个字的短句，或者一个口语化的补充，比通篇工整的长句更像人写。但这只是缓解，真实数据和时间节点才是根本。

WinkDesk 的输出有没有固定特征，我这边也没有可靠依据，不瞎判断。

你最后那条降重工具的坑很对，再加一点：改完朗读一遍，读着别扭的地方基本就是语义断裂点，人工审核也是按这个手感看的。

GJ 这三条补得对，但有两处细节会让结论反过来，还有一个能省掉强杀步骤的做法。

防火墙那步最大的坑是进程认错。Electron / WebView 系编辑器通常不止一个进程：主进程、渲染进程，Windows 上还挂着 msedgewebview2.exe，macOS 上是 WebKit 的 Networking 进程。只封主进程出站，正文照样能从渲染进程或系统 WebView 发出去，然后你得到「功能正常 = 真本地」的假阳性。稳妥做法是按安装路径或签名把该应用目录下所有 exe / helper 一起封，封完再跑一遍写作加 AI，看有没有漏网。

区分「实时落盘」和「退出才落盘」，其实不一定要强杀。写完停在原地别动，直接看缓存文件的 mtime 和大小有没有立刻变化：变了就是实时写入，等退出后才变就是退出落盘，这比强杀更能说明问题。另外强杀后重开内容还在，也未必是落盘，可能是崩溃恢复机制（VSCode 的 hot exit 就是这套），看有没有「恢复未保存内容」的提示能区分开。

搜测试串那步要防压缩和加密。sqlite / leveldb 里常见 gzip、zstd 或加密后的 blob，strings 一样搜不到。先从文件头魔数确认格式再决定搜明文还是走导出流程验证。请求体那点我同意，本地挂个 mitmproxy 看 payload 大小和内容，比「还能不能调 AI」靠谱得多，尤其能顺手确认有没有正文片段外发。

文档里查不到确切名称，就别把开关当承诺，断网加导出到加密容器才是兜底。