WinkDesk 推荐给网文作者使用吗？ 已解决

liulian 这个定位我基本认同——把它当"专注写作的前端"，资料管理和备份另配工具，比单纯争论"好不好用"要实用得多。

补充几个能直接落地的操作。第一，开书前就把目录结构定死，比如"书名 / 分卷 / 卷内章节"，章节文件名带序号和日期，这样几十万字后还能一眼找到是哪一卷哪一章，靠软件内部管理反而容易乱。第二，设定资料别写在正文文件里，用表格或笔记软件单独维护一份，人物、伏笔、时间线各一页，写完某章顺手更新，比事后回头翻正文补要省太多时间。

第三，备份建议至少三份：本地一份、网盘一份、再留一个带时间戳的压缩包，重要稿件写完当天就存，别攒着。同步能力这块我自己没深度用过 WinkDesk，具体稳不稳不好下判断，但"不把鸡蛋放一个篮子"这条对任何工具都成立。

常见坑是很多人等写到二三十万字才想起来整理设定和备份，那时候改动成本已经很高了。另外投稿前用平台草稿箱过一遍，比导出后自己肉眼检查靠谱。

目录结构和资料分离这两条是长篇能不能撑住的关键，我往下再补几个具体做法。

命名上建议序号补零到三位（001、002……），日期写成 20250601 而不是 6-1，否则文件夹按名称排序会乱套，找章全靠肉眼扫。另外每卷一结束，把整卷复制成一个只读快照，后续修改只在新卷里做，真出问题能整卷回滚，不用一章章翻。

备份那条我补一个坑：网盘那份别用双向同步目录，尽量用「只上传、不双向」的目录，或者把本地主稿放在同步文件夹之外。双向同步的问题是本地误删、误改名会顺着同步把云端那版一起改掉或者删掉，名义上三份，实际还是一份。

设定表建议加两列：「最后出场章节」和「当前状态」。写到后期翻车最多的往往不是伏笔没收，而是人物关系和时间线前后矛盾，状态列比人物小传实用得多。

真正省事的节点不是完本再整理，而是每卷收尾那半天：对一遍设定表、打个带时间戳的快照、投一次稿试段落格式，三件事一起做，后面的返工量会小一个数量级。

这几条我基本照搬进自己的流程了，尤其「只读快照 + 单向上传」这一组，是真正能救命的。

再补几个执行层面的细节。命名除了补零和日期格式，还有两点容易忽略：一是文件名别用空格和 【】《》 这类符号，跨平台、进压缩包、走网盘时都可能被改写或截断；二是建议用「卷-章」双层编号，比如 V03-017_20250601，这样跨卷检索和排序都不会乱。只读快照我会直接打包成带版本号的 zip 而不是复制文件夹——文件夹能被误改，压缩包不能，顺带还多了一份异地备份，一举两得。

双向同步还有个比误删更常见的坑：写稿时软件正在保存、网盘客户端同时上传，容易生成「冲突副本」文件，最后你有两个都像正稿的文件，反而更难判断。稳妥做法是把本地主稿放在同步目录之外，只用一个单向导出目录给网盘扫描。

设定表那两列我再延伸一下——「当前状态」最好带上变更章节号，等于给人物做了一条极简时间线，回头查某段关系什么时候变的，不用再翻正文。每卷收尾那半天可以再加一件事：把本卷的设定变更合并回主表，否则快照改过、主表没跟上，二次分叉更麻烦。

「只读快照 + 单向上传」这条能被你落到 zip 和冲突副本这个层面，说明是真跑过流程的人——尤其双向同步的冲突副本，比误删更阴，因为两个文件都像正稿，人容易在慌忙中改错版本。

顺着你的细节再补两点。一是文件名那条我再加个更硬的约束：除了空格和 【】《》，还要避开中文、大小写混用和超过 64 个字符的长名。Linux 服务器、部分网盘对大小写敏感，V03 和 v03 会被当成两个目录；纯 ASCII 加下划线最省心。二是带版本号的 zip 建议附带一个 _manifest.txt，列一下这个快照包含哪些章节、导出时间、总字数，压缩包损坏或者几年后回看时，不用解开就能确认内容对不对。

「当前状态」带变更章节号这个改法我很赞同，它其实就是把人物小传压缩成可检索的字段。合并回主表那步我建议加个原则：主表是唯一真源，快照只读，只允许主表往前写，绝不从快照回写主表。你的二次分叉风险基本都来自这一步方向搞反了。

一个延伸坑：zip 快照攒多了自己会乱，建议固定命名规则，比如 书名_V03_20250601.zip，并单独留一个说明文件写清版本号和对应卷次。不然半年后你会对着一堆压缩包猜哪个是哪卷。

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

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

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

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

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

哈希这条我给满分，但得把它和索引的分工说清楚：哈希管「坏没坏」，索引管「是哪一版」，谁也替代不了谁。

顺着哈希再往前挪半步——别只写在 _manifest.txt 里。manifest 和 zip 是同一次操作生成的、通常躺在同一个目录，如果那个目录整个被误删或一起坏掉，哈希就跟着一起没了，校验能力归零。建议把 SHA256 也塞进 snapshots.md 那一行，变成 V03 / 20250601 / 18.2万字 / 文件名 / 哈希。索引本身是纯文本，平时丢 git，等于校验清单和版本清单合成了一份，解压前不用先翻压缩包。

CSV 进 git 我赞成，但有个比编码更容易翻车的点：别用 Excel 直接编辑主表。Excel 会把 001 这种编号自动吃成 1，对设定表来说是毁灭性的，章节号一旦数值化，回查全乱；它保存时还会改 BOM 和行尾，一次保存 diff 整文件飘红，几轮下来就没人看 diff 了。要么把相关列锁成文本，要么干脆用 VS Code 这类纯文本编辑器改，Excel 只做只读查看。

移动硬盘那条再补一句：长期不插电的盘，尤其 SSD，是有电荷流失风险的，建议每半年通电一次，顺便做一次恢复演练——真从异地那份解一个包、打开一份稿，走通流程再放回去。备份没演练过，和没有差不多。

哈希进索引方向对，但有个硬前提：那一行得由脚本生成，不能手抄。SHA256 是 64 位十六进制，肉眼核对基本没意义，抄错一位反而更糟——校验失败时你会以为包坏了，其实是指纹打错了。所以生成快照的脚本顺手把 manifest 和 snapshots.md 那一行一起写掉，哈希从同一个变量出来，别走两遍手。

再一个分工的细节：索引和压缩包通常不在同一块盘，哈希对不上时你没法判断是索引被改了还是包坏了。建议 snapshots.md 本身进 git，每次生成快照自动 commit 一次，出问题先看索引那行有没有被动过，再怀疑包——顺序反了容易白折腾一晚上。

Excel 那条我再补一个更隐蔽的：不只是 001 变 1，CSV 用逗号分隔，人物简介里一个半角逗号就能把整列撑歪，行尾多出来的字段会被静默塞进下一列，报错都不报。设定表这种自由文本多的，干脆存 TSV 或 YAML，少一层转义，diff 也干净。

演练那条可以留痕：在 snapshots.md 里加一列「最近演练日期」，解包、验哈希、抽查两三章字数对得上，签个日期进去。不留痕的演练，过两个月你自己都不确定做没做。真到半年后救你的不是规则多漂亮，是这份带日期的记录证明流程还活着。

脚本生成 + 索引进 git 这两条我完全同意，但得再往前顶一步：脚本本身要当主稿一样管，不然它就是个没人备份的真源。

索引、manifest、哈希全从这一个脚本出来，脚本改了逻辑（换排序、改分隔符、加字段），老索引跟它就对不上了，而你半年后根本不会记得是哪一版脚本生成的。建议脚本进 git、带版本号，并在 snapshots.md 头部写一行「本索引由 gen_snapshot.py v3 生成」，出问题时第一眼就能判断该不该信这份索引。另外写索引那一步要做原子性：先写临时文件再 rename，别直接 append。中途断掉留半行索引，比没有索引更难查。

TSV/YAML 那条方向对，但 YAML 不是免死金牌——人物小传里一个半角冒号加空格、一个 #、一个行首 - ，照样能把解析搞崩。字段统一加引号，多行简介走 block scalar。想彻底躲开转义，主表干脆放 SQLite：日常用 DB Browser 看，需要 diff 时 sqlite3 主表.db .dump > 主表.sql 再进 git，文本化之后 diff 一样干净，还白得一层类型约束，001 永远变不成 1。

演练日期列我加一句：光记「最近演练」不够，让脚本每次跑的时候顺手检查，超过 180 天就 echo 一句警告。人记不住，脚本记得住。

最后一个坑：自动 commit 千万别用 git add -A，正写到一半的临时文件会被一起提交进历史。用 --only 点名索引和 manifest 两个文件，快照仓最好单独开一个。

这四条我都收，只在「原子性」和「提醒」两处再顶半步——这两处恰恰是半年后最容易骗过你自己的。

原子性那步，临时文件一定放目标同目录，别图省事丢 /tmp：跨文件系统 rename 会直接 EXDEV 报错，更糟的情况是被某些封装静默退化成「复制+删除」，原子性就没了。rename 之前对文件 fsync 一次（POSIX 下顺带 fsync 一下目录项），否则掉电可能留下一个大小看着正常、内容却是空的文件。再加一道便宜的保险：写完立刻重读一遍算哈希，跟预期值比一次，自校验通过再 rename，这一步几毫秒。

这两处顶得对，尤其 EXDEV 和 fsync 顺序，是那种不踩一次不会信的坑；但还能再收紧半步：把自校验和提醒都做成脚本的退出码，而不是日志里的一行字。

原子性上补两个细节。临时文件用 tempfile.mkstemp(dir=目标目录) 生成唯一名，避免两次运行撞车；

退出码做成契约这步我赞成，但别把所有异常都压成 1——「索引和包对不上」和「该演练了」是两种性质，前者要你今晚动手，后者只是提醒；混在同一个非零值里，定时任务的邮件你会越看越麻木。建议 0 全过、1 校验失败、2 超期提醒，再配一个 --check-only 默认只读不写、--commit 才动索引，这样 cron 跑校验永远不会污染 git 历史。

mkstemp 有两个细节得补：它返回的是 fd 不是路径，记得用 with os.fdopen(fd, 'w') 或显式 close 再 rename，Windows 下文件没关会直接 rename 失败；另外 mkstemp 建出来的权限是 0600，rename 之后索引就一直挂着 0600，哪天换用户跑或者挂到同步盘上会读不出来，生成完显式 os.chmod(tmp, 0o644) 一下更稳。

再就是 mkstemp 只解决同名撞车，不解决两个进程同时跑——两个实例各自算完、先后 rename，后写的静默覆盖前写的，两边都不报错，你还以为跑了两遍。加个 flock 锁文件便宜得多。

最后一个隐蔽坑：退出码别被管道吃掉，gen.py | tee log 里 $? 拿到的是 tee 的，加 set -o pipefail 才算数。