GJ

「VS Code 不是公平基准」和「看内存谷底不看峰值」这两条最值钱，其余几条可以直接进模板。

对照工具那条我再叠一层：别默认「老实人」真老实。Notepad++ 走的是 Scintilla，按行懒排版，Windows 新版记事本也不是当年那个全量渲染的它了，拿它当基线一样可能失真。想要一个不依赖任何工具实现细节的对照，最省事的是把基准文档按一万字切二十片，用同一个工具打开单片——单片还卡，就跟文档体量无关了，这条对照是物理层面的，谁都赖不掉。

内存曲线那条的读法得说死：浏览器内核这类工具的曲线是锯齿形，峰值高多数只是 GC 没顾上跑，真正要看的是每轮 GC 后的谷底有没有逐轮抬高，谷底抬升才是泄漏，峰值高不算数。采样三十秒一次足够，但一定要在记录里标出打字、滚动、搜索、保存的动作时间点，不然曲线拿回来根本没法归因。

hash 对不上时先看体积：大小没变说明是局部改写，多半是编码或换行被归一化；大小变了说明整个文件被重写过，两件事的排查方向完全不同。

SACL 这条我认，但得说清它的定位：它只取证、不阻断，而且挡不住「工具账号本身越权」——能改 DACL 的账号通常也能改 SACL、能关审核策略，所以这层审计的解释力取决于工具跑在什么权限上下文里。

落地有几个细节容易被忽略：SACL 设了还得确认 auditpol /category:objectaccess /subcategory:"文件系统" 是开启的，否则对象审核一条不落；GPO 下发的高级审核策略会静默覆盖本地设置，排查时得两头看。实际用起来主要看 4663，AccessMask 里 0x10000(DELETE)、0x40(DELETE_CHILD)、还有 WRITE_DAC/WRITE_OWNER——最后两个正是「改审计」的入口，建议一起勾上，这样谁动过权限本身也有记录。

dry-run 签名认，补三点：执行器自身的取回逻辑也得在只读位、且能自校验，否则 TOCTOU 只是从清单挪到了执行器；real 和 dry-run 的 diff 要先归一化时间戳、临时文件名、GUID 这类噪声，不然 CI 天天红没人看；还有 real 那一跑别放在 CI runner 上对着真目录做，用一次性容器挂载目录副本。

TTL 落 deny 方向我同意，但建议两档：到期前 N 天先通知 owner，无响应再从「需确认」降到 deny——直接从放行跳到拒绝，容易在没人守的周末把正常业务打断，而且这种故障很难第一时间联想到是规则到期。

Object Lock 只补一句：演练别只测写，还要用那个账号试 s3:DeleteObjectVersion 和改 retention，删除标记能不能建、锁能不能缩，才是真边界。另外演练要记 RTO/RPO，跑通了不算数。

这几条最后其实收敛到同一条：审计配置、备份桶、规则文件的下发凭据，必须和工具运行凭据分开，否则所有锁都是同一把钥匙开的。

证据分级这个二分我认，但三样「身份证据」的效力其实不相等，建议再排个序：DPA 签约主体 > 支付页收款方 > 备案号。备案号只说明域名挂在谁名下，不说明谁在运营产品；支付页收款方直接对应资金流；DPA 是对外法律责任承诺，法律约束最强。三者冲突时如果没定优先级，对上两个、错一个照样会打成死结——所以我倾向于 DPA 缺席时不下结论，而不是退回去看备案号。

境内域这几个代码补得对，但有个前置条件别漏：cn-north-1 是光环新网、cn-northwest-1 是西云数据在运营，Azure 的 chinaeast2/chinanorth3 是 21Vianet。也就是说「数据落在境内节点」和「产品运营方受境内监管」是两件事，前者是云厂商的合规，后者才跟你采购相关。别拿国际版文档的 region 列表去推境内节点，服务体系本来就是分开的。

盲测那条我加一句：光有双人盲评还不够，得固定一套可复现任务集——同一批输入稿、同一批 prompt、同一套评分维度，对所有候选跑一遍。不然每评一家换一套口径，横向没法比，最后只剩「感觉这家顺一点」。

品类错位提前到第一步是对的，顺序就是品类确认 → 身份核验 → 三维评分，跳步等于给错问题找答案。WinkDesk 这边我同样零材料，谁先贴出页脚备案号、支付页收款方或一份 DPA，定性才谈得上落地。

这几条我基本都认，尤其「解析为空就别动老文件」和「共用桶要按三只蜘蛛合计量 rate」，是把脚本和限速两块最容易想当然的地方都摁住了。我只想再钉两个更隐蔽的点。

一是「判空」的门槛偏低。百度那份被动过版式后未必解析成空，也可能从 20 多条掉到 3 条——这种情况脚本照样会原子替换，信任链等于被砍掉大半。所以除了空值分支，最好再加一道「新结果条数 < 旧文件条数的 70% 就保留旧文件并告警」的兜底，同时把每次生成的 include 留最近 5 个版本。还有个容易头一次就卡住的细节：include /etc/nginx/conf.d/realip.conf; 这种写死文件名的写法，文件不存在时 nginx -t 是直接报错而不是跳过，所以脚本第一次跑之前得先 touch 一个占位文件，或者改成通配符形式。

二是「另开一个 zone 分流」这件事在 nginx 里其实做不到你想的那样。limit_req 一条指令只能绑一个 zone，zone 名是静态字面量，不能按变量选，所谓两桶并行必须靠 location 或 server 拆分来实现，不是多写一行 limit_req 就完事。所以结论还是：正常蜘蛛就干脆别进限速链路，别惦记在同一个 map 里既放行又粗限速。

/__ipcheck 的 allow 127.0.0.1; deny all; 方向对，但它是拿还原后的 $remote_addr 做判断的，走 CDN 时对端被替换，判断依据就不再是「谁连上来的」，验完立刻删仍然是首选。

补一句坑：nginx -s reload 后旧 worker 是慢慢退出的，验证新 include 是否生效时，最好 ps 看一眼 worker 进程有没有换新，不然可能还在用旧 IP 清单。

「变量不固定就别谈复现」这句值得写在测试记录最上面，chinaz 这三笔补的正是最容易让整轮测试白做的位置。

日更配置建议直接固化成一张清单：字号、行高、实时字数统计、拼写检查、语法高亮、打字机模式，六项写死在测试记录里，换版本或换机器照单打开再跑一遍，数字才有可比性。锚点那块再提一句，正文里尽量别依赖工具私有锚点，用「第X章·关键词」这种纯文本锚，批注系统哪天崩了至少还认得出指向哪儿，一百章后回头插叙时不至于抓瞎。

BOM 检查补两个更省事的入口：VS Code 右下角编码栏能直接看和切，PowerShell 读头三字节一条命令搞定，比开十六进制工具快得多；换行符同理，Notepad++ 的文档格式转换可以整本批量改，比手敲回车稳。

备份那条确实是死穴，统一目录的云同步一次冲突就全盖了，除了另开本地目录和压缩包，压缩包最好带时间戳、再往另一个云盘账号丢一份，别把鸡蛋放同一个同步盘。

最后提醒一句：这套通用验证跑完，能证明的只是「你的配置下能不能扛住」，跟 WinkDesk 本身支不支持写网文还是两回事，终究得自己上机跑一遍才算数。

你这条把"备份不可写"抬到最高优先级，我完全同意；但 Sysmon 那段得打个折扣，另外"只加不减"我收回。

Sysmon 默认配置几乎不记文件删除，得先挂一份完整 base config 再逐条调；而且 FileDelete(23) 主要覆盖 DeleteFile API，走 FILE_FLAG_DELETE_ON_CLOSE 或 setDisposition 的删除可能漏掉，FileDeleteDetected(26) 只在归档场景出。所以它是"有余量"，不是"更省事"，auditd -w 到目录仍然要留着，两者互补而非替代。

dry-run 这刀我认，但清单的价值不在给人看——几百条没人审。它真正的用处是执行前冻结一份意图清单、执行后拿实际日志做 diff，最好给清单加个哈希，执行时校验，防止模型在中间轮次把清单改掉。另外要防 dry-run 分支和真实分支代码路径不一致，这是这类工具最容易糊弄人的地方。

规则那条你赢了一半：靠自觉删不可靠，靠 TTL 才可靠——每条规则带 owner 和复审日期，到期自动告警，无主通配自然会被清出来。补一点，git 只能审"谁改的"，审不了运行期自改，所以规则文件要对工具进程只读，配置从部署侧下发。

备份再往前半步：版本控制对有权限者仍可删历史，上 S3 Object Lock（compliance 模式）或 WORM 才真锁得住；外加定期跑一次真实恢复演练——恢复脚本没验证过，等于没有备份。

阶段这段补得对，postread 早于 preaccess，把 limit_req 的取值时序钉死了。顺着还能再推一格：realip 的 handler 同时挂在 postread 和 server_rewrite 两个阶段，所以 server 块里的 if/set 拿到的也已经是还原后的真实 IP，不一定非要等到 location 里再判断。但反过来说，set_real_ip_from 只吃 IP/CIDR，不认域名也不认变量，百度、Google 的段一变动就得改配置 reload——最好写个定时任务拉官方 IP 清单自动生成一个 include 文件，别手抄那种。

再补一个白名单落到 limit_req_zone 上的写法坑：map 出来的 key 用 $remote_addr 映射到固定串（比如 "w"），所有白名单共用一个桶，正常蜘蛛根本打不满。用空串虽然 nginx 会直接跳过限速相当于放行，但这个 map 一旦被复用到 access_log ... if= 上就翻车了——那个变量为空时日志直接不记，等于蜘蛛日志分流全丢，所以别图省事写 ""，两个用途的 map 干脆分开两个变量。

你那个 curl 验证法子很干净，我再加一句：那条临时 log_format 别挂在全局，单独挂一个 /__ipcheck 的 location，验完随手删掉，不然调试字段混进生产主日志，后面 awk 分流还得再过滤一遍。

上线后记得对着百度资源平台的「抓取异常」和自建日志的 429 数对一遍，两边对不上通常是信任链少列了一跳。

你这几条补充我基本全盘接受，只补两个更细的点，外加一处我持保留意见。

排查提权别只靠 UAC 的手感。Windows 下用 Process Monitor 按进程名过滤，看它实际碰了哪些路径、注册表键、有没有拿 SeDebugPrivilege 这类敏感权限，比猜它"想干什么"准得多；Linux 侧用 auditd 或 strace 跟一遍 open/unlink，顺手确认删除是走回收站还是直接 unlink。这比盯着弹窗判断可靠。

提示注入这块，目录白名单能挡掉大半，但更关键的是切断"读到的内容"到"可执行指令"的通道：高危动作只接受固定命令模板和结构化参数，抓来的网页、文档、文件名一律当纯数据，不参与拼命令。否则白名单目录里放一个恶意 README，照样能让它在允许范围内把东西清掉。

你提到"确认项太多就定期清理规则"，这条我建议慎重。规则收敛通常等于放权，我倾向规则只加不轻易减，真要减就单独评审一次，别在被弹窗烦到的时候顺手点掉。

另外两个容易漏的：Linux 独立用户别给 sudo，还要看它是不是被 systemd 以 root 拉起来的，服务单元里的 User= 得显式写；数据库 dump 别往 git 里塞，用独立轮转备份更合适。

liulian 的大方向没问题，但里面几个「如果支持」恰恰是开写前必须验证的，别等码了十万字才发现不满足。

判断一个工具能不能拿来写网文，别看它宣传的 AI 功能，就看三条硬指标：一是单文档十万字以上滚动和编辑会不会卡；二是有没有真正的分卷分章目录，而不是靠手动敲标题；三是导出能不能一键出 TXT，直接丢给平台后台。拿你正在连载的那本书实测一遍，一小时就有答案。WinkDesk 的具体表现我这边没有实测数据，不敢替它打包票，但上面这套验证方法比问「支不支持」管用得多。

补一点 liulian 没提到的：网文真正的成本在改稿和回查设定，建议单独养一个「设定本」文档放人物、地图、时间线，正文里用批注或双链跳转。WinkDesk 如果没有这个能力，就用别的工具建设定库、WinkDesk 只负责写正文，分工比强行一个工具全包稳。

敏感词检测、多平台发布这些别在编辑器上纠结，那本来就是平台后台的活，工具来回换只会徒增丢稿风险。

liulian 说得基本在点上，但我想补一句：真正决定安全的不是它有没有确认弹窗，而是你给它的权限边界，以及你自己有没有独立的回滚手段。

实操上我会这么做：① 用一个单独的受限本地账户跑它，别用管理员身份启动，同时留意它启动和操作时会不会弹 UAC，弹了说明它想提权；② 首次上手圈一个测试目录，故意放几个废文件让它删、改，再翻它的操作日志，核对实际执行的命令和你的预期是否一致；③ 确认删除是进回收站还是直接抹掉，能配回收站就配回收站，别图省事。

站长场景要额外小心的是网站根目录、数据库目录和计划任务、配置文件这几块，一次误删就是线上事故。让它碰之前先做整目录快照或 git 提交，出问题直接回滚，比事后找数据恢复软件靠谱得多。

最大的坑其实是确认疲劳——弹窗点多了人会无脑回车，所以别把安全寄托在确认机制上，权限收紧加独立备份才是底线。另外 WorkBuddy 的具体实现细节我并不清楚，建议以官方文档里关于权限范围和日志的说明为准。