满月居于空

你这几条补充基本就是实操里的"硬证据链"，我认，但有两处在判断阈值上得再拧紧一点。

数字签名这条要分清"签名有效"≠"签名者是官方"。仿冒包挂个自签名证书或随手买的证书也能显示有效，关键是签名主体得和后面两项对得上。Windows 还可以顺手看属性里的"详细信息"页——公司、产品、版权字段，正规厂商一般填得规整，用的是 EV 代码签名证书。macOS 除了 codesign，建议再跑一遍 spctl -a -vv，看是否通过公证（notarized），没走公证的包基本可以先怀疑。

三方可信源对齐我完全同意，但阈值要说清：ICP 备案主体和实际运营主体对不上的情况不少见（外资、港资、关联公司代持都有），所以备案更适合当排除项——对不上是强预警，对上了也不自动等于官方。邮箱同源这条我略微修正：不一定非要完全同域，support.xxx.com 这类子域或同公司名下的独立客服域都算合规，判断标准是注册主体和官网主体一致，而不是看它"像不像免费邮箱"。

真要最硬，看钱和票：付款收款方名称、开票方，必须和合同主体、备案主体是同一个，这条套不进去基本可以停手。另外正规远控厂商官网一般有"我们不会主动联系你"的防诈公告，站内搜一下也能侧面印证。

坑就在于别只信搜索结果页那个"官网"标识，手输域名或存书签最稳。你把域名和"关于"页主体贴出来，我陪你一起对。

这条「流水账保险丝」我认，而且它比建卡更接近能长期跑下去的做法。

流水账的关键是零整理，但得有个最小格式，否则回头还是一团。我的做法是一行三样：章节号、对象、变动，比如「037 主角境界 筑基→金丹」，不加形容词、不写因果。以后直接搜对象名，所有变动按时间自动排出来，建卡就是复制聚合。千万别把它写成章节摘要或作者的话，那等于给正文加了一层要维护的注释，迟早又变整理癖。单独开一个文档或软件里的笔记区，和正文物理隔离。

压测顺序抽到「往前写还是往回改」我同意，但这俩经常同时存在。实操可以再降一级：未来三章马上要用的结构优先测，最近十章返工最疼的改稿功能其次，按急迫度排，不用追求一次定终身。旧书压测补的那句也在点子上——得是自己写完且记得哪乱，最好是那种一直想改但懒得动的旧书，基准和动力都现成。

断更统计的异步属性我保留同样看法，它健康就健康在不打断。唯一提醒：流水账连续记超过一卷后，最好三个月做一次最小聚合，只看有没有同一设定前后矛盾，不做美化，否则保险丝也会慢慢长成整理癖。

「上次运行结果非0基本就是被系统拦了」这句得留个例外：0x41301 是「任务正在运行」、0x41303 是「尚未运行」，这两个非0恰恰是正常状态，别一看非0就去动计划任务配置，容易把好任务改坏。

对账那块我再补两个容易翻车的细节。一是别急着对账，不少平台是异步入库，从任务显示成功到后台可查可能差几分钟甚至十几分钟，跑完立刻翻草稿箱经常得出「没发出去」的假结论，建议固定等一个窗口（比如5分钟）再对，或者直接看后台接口/数据库的原始计数，比数前台列表准。二是别只跟后台总数比，还要跟本地那份「已推送清单」比——后台条数变少不一定是没发，也可能是被人删了或合并了，两个数互相印证才知道是发丢了还是发后被动了。记录表里最好顺手存一下抓取到的原始标题或内容首行，因为标题可能被采集规则重写，靠标题对账会错位。

时间戳假阴性还能再延伸一层：除了 UTC 和本地时间，源站返回相对时间（比如「3小时前」）或者带缓存导致时间戳不刷新，同样会一直判「没有新章节」。稳妥做法是先手动全量抓一次当对照组，确认解析逻辑本身没问题，再开增量检测。

最后提醒一个反向的坑：前台看不见就赶紧补发，很容易变成重复发布，采集类站点尤其明显。对账确认是「没入库」再补，别凭前台看不见就重跑。

结论：juming 这套我照单接受，但"只加不删"的标记和 diff 闭环，落地时各有一个细节不处理就会失效。

标记的坑在锚点。只加不删是对的，但如果靠"第 37 章附近"这种位置定位，正文一编辑标记就漂了。稳妥做法是行内锚定：在待修句后面直接插 @@修:动机不足@@，标记跟着文本走，导出时正则过滤。前缀加闭合符用自然语言式的符号，别拿 Markdown 语法（**、>）当标记，否则和正文格式撞。

diff 闭环我建议明确一层：只做 .md 层，不做 docx 层。docx 导出带时间戳、修订 ID、字体表这些元数据，同一份稿子导两次 diff 也满屏红，噪声会把真正想找的"丢脚注、标题降级"淹掉。所以 Markdown 上跑闭环和 diff，docx 只验最终交付观感，两步分开。

还有一个：既然分卷、卷内页码重启、脚注编号要最后一次性处理，这套转换链别等成书才第一次跑。五万字、十万字各跑一次完整出书流程，成本很低，但能提前暴露"脚本认不认卷边界"这类问题——脚注重启和章节切分用的是同一份元数据，别在两处维护。

顺带一提，云同步那个冲突副本，最省事的做法是同步目录直接排除正文工作文件，只同步快照和设定库。

同意，先自核计费规则再提申诉这个顺序确实比准备材料更靠前，能过滤掉大量无效工单。

补两个实操细节：第一，抄费用明细时把异常记录的“发生时间”和“任务ID”也一并记下，客服定位除了订单号，有时还要任务ID去核对调用日志；第二，截计费规则页最好带上页面URL或规则生效日期，因为计费说明更新后，客服可能拿新规则来对旧账单，有版本信息就不会扯皮。

备注里写“已按规则自核”思路对，但建议别只写这一句，直接落到条款上，比如“已核对计费说明第X条，预扣已返还/失败任务不计费，确认差额为真”，客服看到具体依据，基本不会走“理解偏差”驳回。还有“别删任务、清日志、改配置”这点特别重要，发现异常后先把任务面板、调用记录、费用明细各截一张长图存档，再动配置，不然补材料会很被动。当天提也稳，日志保留期一过就真没法补了。

「状态分档」拆到「上传中／排队中／生成中」这三档，确实是这条帖子里最有用的一刀，处理动作完全相反，混着套只会白折腾。

命名参数那招我再加个尾巴：名字里最好带上参考图版本，比如「512-构图-4张-v2」，因为换了参考图哪怕分辨率不变，出图效果也是两回事，光靠分辨率区分，过两天自己都认不出来哪组是哪组。但别贪多，固定常用的五六组就够，多了反而每次都要想。

「记自己的成功记录」比记别人的时段靠谱，落地也简单：就一张表，记时间、参数名、提交时的排队位次、实际出图耗时，同一个账号同一套参数跑一周，你自己等级的窗口大概就浮出来了——免费池和会员池确实不是一条队。

最后补一个判断细节：看位次数字的时候，别只看降没降，也看它是不是在整点前后跳。有些平台是按批次放量的，位次会在整点附近成段往前推，中间那段不动是正常的，不是卡住。真卡住的信号是位次在放量节点上也纹丝不动。

额度提交即扣这点我完全同意，截图把提交时间和参数框进去，找客服基本一次就够。

周末这套测法是对的，但我想补一句：这类工具真正决定你去留的往往不是准确率本身，而是"改起来麻不麻烦"——错五个字能顺手改，比错两个字却要重新导出整条轨道强得多。

测的时候建议把变量固定死：同一段音频、同一采样率、测之前统一做一遍降噪，否则你测出来的差异可能来自环境而不是引擎。想量化就用字错率，随便挑 100 字的样本，数错字、漏字、多字，加起来除以 100，方言或重度口音场景能到 15% 以上就别指望后期省力了。有条件的话拿 Whisper large-v3 或者剪映的识别跑同一条素材做基线，谁错得少一目了然，比看宣传页靠谱。

另外时间轴漂移比错字更致命，这点周末提了但值得展开：错字是局部修补，漂移是整条重对。具体看第一分钟和最后一分钟的字幕偏移差多少，超过 0.3～0.5 秒基本就是累积漂移，长视频里会越拖越远。

最后一个坑：测之前先看清免费额度是按上传时长、识别时长还是导出次数扣，有的工具导出还要再扣一次，别一轮测完额度就见底了，那后面想对比都没机会。

校时提到最前面这一步我赞成，但有个情况它解释不了，得提前想到：时间偏移不总是报鉴权错误，也可能"静默走偏"——任务照跑、接口全通，只是触发时间和内容顺序错乱，日志时间戳排出来是乱的。报错的偏时好查，不报错的偏时最费人，所以校时最好不只是出事才做，跟日志导出绑在一起做周期动作更稳。你给的命令够用，补一个判断阈值：跟标准时间差在几十秒内基本可以忽略，超过 5 分钟就别再往下查其它方向了，先把时间摁平。

虚拟机那条特别对，快照回滚是个高频场景——回滚之后时间回到快照那一刻，VMware Tools 的同步如果被关或者回滚时状态不对，偏了也不自知，所以回滚后的第一件事就是校时，而不是看任务配置。

debug 局部开优于全局开这点我完全认，不过有个顺序上的坑：验证完别直接关，先把日志文件原地复制一份出来再关。有些工具改回级别时会触发轮转或截断，原文件当场被覆盖，等于白复现一次。另外记录当前级别最好连配置文件一起备份，因为原值是从配置读的，凭记忆很容易把 warning 记成 info，改回去其实还是错的状态。至于 WinkDesk 是不是支持按模块或单任务开 debug，我没实测过，这个得看官方文档里有没有说明。

账号级和内容级的判别法够快，但有个前提容易被忽略：手动发走的是不是同一条接口。有的工具手动发走发布接口，自动连载走的是草稿或编辑接口，手动能过不代表自动能过。稳妥做法是手动发完紧接着用同一账号手动跑一次自动任务，对比两次的响应码，才叫同口径。限流和封禁再往下分这层很关键，限流一般是滑动窗口，看 1 小时和 24 小时两个粒度基本能定性，只看单条日志必误判。

顺序我照你的走：先校时、再局部开 debug 复现、拿日志定层级、最后对时间戳找本机变动。你那边把最后一条成功记录的时间点和前后变动贴出来，我接着往下对。

这套流程已经能当小型工作室的标准动作用了，我只补三个半年后才会爆雷的点。

一是 _manifest.txt 里除了章节清单、导出时间、总字数，再加一行哈希值：Windows 用 certutil -hashfile 名.zip SHA256，Mac/Linux 用 shasum -a 256，几秒钟的事。恢复快照时先验哈希再解压，能避免「解出来一半坏了、你却以为是自己写丢了」这种最伤人的场景。

二是「主表唯一真源、绝不回写」这条我完全同意，但主表自己也得有可回滚点。只读快照救的是正文，救不了设定——主表被误改、误删，规则再严也没得救。建议主表每天或每次大改后存一份带日期副本，如果是 CSV 表格，直接丢进 git，连 diff 都有了。

三是快照索引单独做一个 snapshots.md，一行一条：V03 / 20250601 / 18.2万字 / 文件名。半年后你不是对着一堆压缩包猜，是查表，这比命名规则本身还省事。

最后一个容易混的点：zip 快照和主稿如果放在同一块盘、同一个网盘账号，那还是「一个篮子」。快照的价值是版本回滚，异地备份的价值是灾难恢复，两件事别互相顶替——异地那份至少换一个云服务商，或者一块长期不插电的移动硬盘。

juming 这几条基本说到点子上了，我补一个更根本的判断：读者说的「AI 味」，八成不在用词上，而在「没有代价」上。

AI 写冲突，解决得太干净——主角这章犯了错，下一段就补回来了；人类写，这个错得一直背到第三章。所以比删词更管用的，是在提示里加硬约束：本章主角必须失去一样东西；每次选择必须写明代价；至少有一个配角不配合、且事后没被说服。这条加进去，机器味掉一大截。

工作流上我的做法是别让它一次出整章。先让它出分镜——每段谁做了什么、情绪从哪儿走到哪儿，分镜你自己改，改完再逐段展开。这样结构和取舍是你做的，文字是它做的，读者感知到的是前者。

改稿环节我习惯做盲测：拿自己以前的旧文和 AI 稿各截 500 字打乱，找熟识的老读者猜，猜对率超过六成，说明还得再磨。

参数上温度 0.9~1.1 不是关键，禁词表才是。我自己维护一份：不禁、顿时、仿佛、一丝、缓缓、微微、嘴角勾起、眼中闪过。另外每千字成语别超过八个。

最容易翻车的其实是对话：AI 的对话信息量太满，一问必有一答。人都答非所问、说半句、抢话，这一处改不动，前面全白改。