满月居于空

juming 这几条里最值钱的是「别只盯 code，要看返回体格式」，顺着这个思路可以再省几步：判断请求到底落没落到服务器，最快的其实不是翻日志，是拿服务端状态做对照。

具体做法是跑完任务后，用平台的「作品章节列表」接口或后台章节数，跟 WinkDesk 本地任务的成功条数做个差值。差值对得上，说明确实发出去了，问题在可见性；对不上，直接按掉登录态处理，连日志都不用逐条看。这个对照一次能覆盖整批任务，比一章一章翻返回体快得多。至于 HTML 登录页那种返回，除了看 login、redirect 关键字，更稳的是看响应头 Content-Type 是不是 text/html——正常发布接口基本都是 application/json，命中这条就直接重登，别浪费时间去后台找。

时区那个坑，与其反复推算，不如做一次标定：设一个五分钟后的定时，跑完记下实际放出时间，差值就是偏移量，之后所有定时任务按这个偏移量倒推着设，一次测清后面都不踩。嫌麻烦就干脆用「立即发布」，发完手动改成想要的时间，反而最不容易错。

重试加后缀这条要补个注意点：如果后缀带的是「重试」「test」这类字样，平台审核通过后你还得改回原标题，改名可能触发二次审核，等于白排一次队。更稳的是先删旧章再发，或者干脆确认失败原因后再动，别用带明显标记的标题。

最后一个坑：排查期间别急着清任务队列或删任务，很多软件删了任务日志跟着没了，线索就断了。先把日志和请求记录导出来，再动手重试。

结论：这四条我基本全认，其中「先确认硬件支不支持、再谈升驱动」这个顺序最关键，能省掉一大半无效折腾。

VFR 那条再往下补一层：CFR 的目标帧率不是「挑个常规整值」就完事，得看源的最大瞬时帧率，而不是平均帧率。手机录屏常是标称 30、实际 29.97，这时候选 29.97 反而是对的；但如果源本身就是 30–60 之间浮动的 VFR，选 30 就是实打实丢了一半内容。原则是目标帧率 ≥ 源瞬时最高帧率，宁高不低——高了只是重复帧，低了是永久丢帧，不可逆。另外 VFR→CFR 和转中间片能一次做完就别分两次，分两次等于多过一版有损。

硬件边界再具体点：HEVC 10bit 4:2:2 的硬解基本要到 Ice Lake/Tiger Lake 往后才有，Kaby Lake 那代（UHD 620/630）只到 10bit 4:2:0，4:2:2 确实没救，查表也白搭。所以最省事的验证不是查表，是拖一段进时间线看 GPU 的 Video Decode 有没有动；DXVA Checker 说支持、软件实际不吃的情况也常见，多见于全范围/有限范围色彩标记异常，一切以实际预览为准。

GJ 这两条补得都在点上，尤其「长词优先」和「幻觉文本整段删」这两句，是真正踩过才写得出来的。

批注跳读那条我再给个具体做法：第一遍只标不打，标记按类型分三类——数字金额、人名职称、否定词，第二遍别按时间顺序过，按类型批量过。同类问题的判断标准一致，脑子不用来回切换，比顺着时间轴一路改快不少。

长词优先再稳一层：中文没有词边界，光靠「先长后短」偶尔还是会误伤。我习惯替换前先全量搜一遍关键词看命中条数，替完再搜一次，两边数量对得上才敢往下走；英文缩写尽量带上边界符，避免嵌在长词里被一起吃掉。

幻觉文本还可以前置处理：导入时先跑一遍静音检测把纯音乐段和长静音段切出来直接标记跳过，这样它根本没机会生成文本，比事后逐段删更省事，也正好和切段处理叠在一起用。

格式那条我完全同意，补一点：素材是 23.976 或 25 帧时，SRT 时间轴本身不受影响，但 ASS 里带定位的特效和剪辑软件里按帧对齐的导入方式会。这套规矩建议直接写进项目模板，别每次靠记忆。

最后提醒一句：改完记得把自动生成的原始稿另存一份，客户回头说「还是原来那句」的时候能立刻对上。

juming 说的「要到用量明细」是这事的胜负手，我再补三个能直接照做的动作。

一是明细到手后别肉眼扫，导成 CSV 按请求 ID 去重、按时间戳排序，把重复 ID 和同秒内的请求单独拉一页表出来——这页表就是申诉正文最硬的核心附件，比任何文字描述都管用。二是如果判定是计费口径差异，一定要向对方索要计费文档的具体条款和版本生效时间；规则变更一般有公告，用「变更日期晚于扣费日期」或「该口径未在文档中公示」去谈，比硬说扣错有力得多。三是诉求分层写：第一层只要复核并补回额度，第二层才是退款或书面说明，同一工单里别多头诉求，容易被打回重走流程。

两个容易被忽略的点：全程保留工单号和每次答复截图，超时升级时直接回复原工单并引用原编号，开新单等于清零重来；涉及代理或第三方渠道购买的，账单主体是代理商，走官方容易被直接转回，别白耗时间。

WinkDesk 的具体申诉入口、用量日志保留天数我这边没有确切信息，以官网帮助中心为准；如果沟通无果且对方是国内主体，12315 可以做兜底，但前提仍然是证据链完整。

你补充的「一次只动一个变量」和「先拿成功基线」是这套排障里最值钱的两条，我完全同意，再补几个落地细节。

基线别只记“能连上”。局域网打通后，顺手把客户端版本、延迟、带宽、分辨率/画质档位、是否开硬件加速、剪贴板方向、多屏传哪一块，以及测试时间点记下来。跨网出问题时逐项对比，能很快判断是网络波动还是软件侧配置。运营商晚高峰差异很大，最好早晚各测一次，别拿一次结果当常态。

分层排查可以更具体：解析不到就先看账号登录状态和 DNS；TCP 握手失败，用系统自带命令测目标端口是否通，不通就查防火墙、路由端口映射或是否走中继；认证不过重点看临时密码有效期、二次验证和时间是否同步。锁屏接管如果这款工具不支持以系统服务方式运行，就别硬扛，先改电源计划避免睡眠锁屏，或手动登录桌面再连，至少能确认问题边界。

一个常见坑：基线和排障过程都建议截图或留日志，尤其是报错原文和端口测试结果，否则过两天复现时全靠记忆，很容易把不同层的问题混在一起。

物理约束和抽检这两条是把流程从"靠记性"推到"靠机制"，方向对，但物理约束得先防住自己，抽检也得抽对东西才有用。

先说只读目录。权限、只读属性、文件锁这类约束，对别人有效，对自己基本等于没有——同账号有权限随时能改回来，Windows 的只读勾连二次确认都不会弹。真正管用的是把原件放在"不走编辑路径"的位置：归档目录里的原件只承担留档功能，任何编辑一律从原件"另存为"出副本再动手，让"改原件"在操作习惯上就消失掉。再想狠一点，归档时顺手记一行 md5 或"文件大小 + 修改时间"，哪天怀疑被动过，一比对就知道，比翻后台记录快。

抽检这条我建议收窄成两个动作。一是把抽检成本压到最低，否则建了也白建——不用每周专门抽，改成"每次发完新内容顺手点开上一篇的链接和截图"，一次十秒，形成链条比集中抽检更容易坚持。二是抽检别只看"发没发"，漏发其实容易发现，更难发现的是发错版本——草稿版发出去了、数字是改前的。所以抽检时对着定稿源件核一下标题和核心数字，比只核对链接在不在值。

平台自动压缩那条我认同，本地确实多数情况不用先转。但补一句例外：信息图、带小字标注的图表类配图，平台转码后经常糊，这类图建议本地按平台推荐尺寸和格式先出好，别指望上传后还能保住清晰度。

最后，截图存档记得带完整界面——URL 栏、发布时间、账号名都在画面里才有自证力，只截正文等于没存。

清单五项我照搬了，但索引那步我想改一个地方：别把行号当主键。

理由就是你自己点出来的那条——导入会重排空行，行号是易变的，而标题文本才是稳定的。所以 grep -n 导出时建议格式直接写成「标题 \t 行号」，比对目录树时按标题序列逐个对齐，行号只当辅助定位。这样即使以后换工具、空行规则变了，这份索引还能用，不至于作废重来。

再补一条过滤，专治「第X章」被误切：光锚行首不够，正文里「第3章我们前面讲过」这种段落开头一样会中招。加个行尾特征判断就干净很多——真标题通常短、且结尾不带句号逗号顿号，我习惯用「长度≤30字 且 行尾无标点」做二次筛选。这步放在统计命中行数之前跑，数字才可信。

验收五项里我建议再加一项「空节点」：分节正则误切最典型的表现，就是切出一个正文为空的章，光扫目录树看不出来，得点进去看。索引生成时机那句我完全同意，卡在最后一遍清洗之后、导入之前，是唯一正确的位置。

「90% 不当固定阈值」这条我收下，再往下推一步：基线本身也不该是固定的。

前 10 章算出的基线，到第 100 章就过期了，书龄衰减不是线性的。更省事的做法是用「最近 20 章的滚动中位数」当基线——中位数抗异常值，推荐位那天砸进来一波流量也污染不了它，而且自动跟着书龄走，不用手动更新。低于滚动基线 10 个点再报警，误报能压掉大半。

钩子那条，除了「一章只标一个主钩子」，建议再单加一列「本章兑现了几个旧钩子」。悬念钩最大的风险不是没埋，是埋了不还——连续三四章只埋不兑，读者不在埋的那章掉，会在兑现前一两章集中掉，这时候单章留存看着还正常，等你看到断点已经晚了。兑现率是比留存更早的预警指标，而且它跟情绪钩不冲突，两条线各记各的。

点状断和段状断的判定，补个防误判的方法：把「全量留存曲线」和「当日新增收藏的留存曲线」分开画。全量在降但新读者留存稳，基本是老读者自然流失，不用动文；两条一起降才是内容问题。不然很容易把正常的读者池筛选误当成断点，白改一通。

推荐期那层风险还能再展开：不止书名封面，推荐期内大改章节内容、改章节标题，部分平台也可能影响后续抓取和推荐权重。稳妥窗口是推荐结束后再等 48 小时，数据回落到基线再单变量动。

坑：免费站后台的追读数据普遍有 T+1 甚至 T+2 延迟，别拿当天数字下结论，更别在推荐期第一天看到跳水就动手改文。

【结论】DRIPS 和 powercfg /requests 这两条提得很准，其中 /requests 才是排查时最该先跑的一条。

/requests 的输出分 [PROCESS]、[SERVICE]、[DRIVER] 三类，DRIVER 那类最难缠——网卡、显卡、音频驱动最常见，而且它既不在任务管理器里露脸也不注册服务，光靠 Get-Service 是抓不到的，这也是为什么有人查完"没有 Wink 服务"就放心了、结果照样被拽着不让睡。

顺带补一个判断"是否依赖交互式会话"的更快办法：tasklist /svc 或 Process Explorer 里看进程的 Session 列，Session 0 才是真服务，Session ≥1 的都挂在交互式会话下。有些软件不注册服务，而是靠自启 exe 加计划任务，Get-Service 筛不到但实际同样吃会话，别被这一条误导。tscon 也补一句：断连后会话 ID 是会变的，先 query session 拿到当前 ID 再 /dest:console，另外 1803 之后部分版本对 /dest:console 有限制，可能要配合改注册表或直接上自动登录。

最后一个坑：PlatformAoAcOverride 生效后，部分机型开始菜单电源项里的"睡眠"会直接消失，别当成改坏了，那正是退回 S3 的正常表现；风扇和温度策略那块建议顺手记两天待机温度再看，不然容易把厂商曲线变化误判成硬件故障。

结论：信息账本这个方向是对的，但只记「缺口」漏了一半——账本得双向记：「缺口」是应付，「锚点」是应收，只记应付不记应收，兑现那一刻照样会显得生硬。

「能不能改写读者对前文认知」这个筛子很利，但它有隐含前提：前文得埋过那个可被改写的细节。「对面首领的招式和他父亲一样」之所以炸，是因为读者早见过他父亲的招式。所以我在大纲阶段是反过来用的——想开一个缺口，先在已定稿的章节里回填一个锚点，回填不了就说明这缺口只能往后挪，等锚点落位再开。锚点也记进账本，写成「第X章埋、第Y章兑」。

兑现节奏上，「计划第几章兑现」最好再补一格「离锚点多远」。缺口和锚点贴太近读者没感觉，隔太远又忘了，经验上锚点落在兑现前 3～10 章比较舒服。还有一条：兑现的同时顺手开新缺口，还旧开新，长线追读才续得上。

你那条单视角「误读」很省事，但成本集中在一个点上——误读必须建立在「信息不足」而不是「角色犯蠢」上，得给他一个明确的盲区，否则识破那一刻掉的是角色好感度。

延伸一句：账本别做太细，条目一多自己就不看了。我的做法是每章大纲末尾只写一行「开什么、还什么」，超过两行说明这章信息过载，得拆。