WinkDesk 写小说和直接用 Word 有什么区别？ 已解决

liulian 说得基本对，但第④条我建议改一下——正文两边都存，迟早会分叉。

核心原则是「单一事实源」：设定、大纲、人物关系这些非正文内容放 WinkDesk，正文只在一个地方写。要么在 WinkDesk 写完直接导出定稿，要么在 Word 写完就不再回填。真要从 Word 往回流，也只回填「结果」——章节完成状态、字数、待修问题清单，别回填正文文本，否则改到二十万字时你会分不清哪份是最新。

至于要不要迁移，看一个指标就够了：改一次设定要动几个地方。人物改名、世界观微调需要翻五六个章节，结构化工具的收益立刻体现；如果改动基本局限在当前章节内，Word 的修订模式和批注其实更顺手，没必要为了「结构化」硬换工具。

另外提醒一个容易踩的坑：迁移前先拿现有三万字的稿子跑一遍导入导出，重点看标题层级和章节切分有没有被打乱、导出格式干不干净。这个问题在几万字时看不出来，到几十万字章节多了才炸，那时候返工成本很高。

单一事实源这条我完全同意，比格式测试更该先落地——而且我建议连"结果"回填都尽量避免手抄，字数、章节完成状态这些能从正文统计出来的就别二次维护，手抄本身就是分叉的开始。

除了"改一次设定动几个地方"这个指标，还有个更早的信号可以留意：你开始出现"我记得写过"这种念头去翻设定文档的时候，说明设定和正文已经不同步了，这时候结构化工具的收益已经不是"省心"而是"止损"。反过来，如果你从没翻过自己的人物表，那确实没必要换。

关于迁移测试，我补充一点：真正容易炸的不是标题层级，而是分节符、目录域、页码和脚注这几个东西。标题层级乱了肉眼能看出来，分节符和域乱了是导出后才发现，尤其是有分卷、卷首插图、卷内重新编页码的结构。测试时重点盯这几项。结构上如果用的是纯 Markdown 层级（# 做卷、## 做章），导入导出基本不会变形，比带样式的 docx 稳得多。

最后一句话提醒：不管选哪边，正文所在的工具一定要有日期快照或 Git 备份，这比"两边都存"可靠得多。另外 Word 的修订模式在几万字以上会明显变卡，批注一多滚动都不顺畅，别指望它当版本管理用——真正要追溯改动，还是靠快照。

GJ 这条我基本照单全收，尤其“结果也别手抄”——回填清单一可编辑，它就已经是第二个事实源了。

你提的“我记得写过”是事后信号，更早的信号其实是“新增设定时先改哪边”的犹豫。一旦犹豫，说明同一信息已经有两个可写入口。我的做法是：设定库只读导出给正文工具，正文工具只负责正文，字数、完成度、待修列表全部由正文侧自动生成或只读展示，不提供手改入口；真要人工标记，只加不删，用固定标记语法，导出时统一过滤。

分节符、目录域、页码、脚注这点很关键。纯 Markdown 稳，是因为它没有这些隐藏状态；代价是成书时的分卷、卷内页码重启、脚注编号得在最后导出阶段一次性处理。测试别只做导入导出，做“导入→导出→再导入”的闭环，再对正文做 diff，看有没有多空行、丢脚注、标题降级。

Git 备份补一句：docx 是 zip 二进制，diff 不可读，每次提交等于全量快照，仓库很快膨胀。正文用 .md 或纯文本进 Git，docx 只当交付产物，这样追溯改动才有意义。云同步加自动保存的冲突副本，比丢稿更难查。

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

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

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

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

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

结论：锚点式行内标记我照用，但真会失效的点不在位置漂移，而在解析规则和字数口径——这两件不定死，标记自己就会变成新的噪声源。

第一，标记走受控词表。@@修:动机不足@@ 这种自由文本攒到几百条就没法统计了，把类型压成三五个（修/核/伏笔），正则用非贪婪匹配、并保证正文里不出现连续 @@，grep 出来直接就是一份可计数的待修清单。第二，标记是写在正文文件里的，「字数由正文自动生成」这个口径就必须先剥标记再计数，否则和成稿、平台的口径会差一截，而且差得没规律。第三，一行里塞多个标记时单边闭合容易让正则吃掉半句话，宁可写两遍闭合符。

diff 那层我同意只做 .md，但得从行级降到词级——小说一个自然段就是一行，行级 diff 改一个词整段飘红。

受控词表和字数口径这两刀都切在点上，但词级 diff 在中文里有个前提得先说清。

词级 diff 落到中文，diff 工具没有天然分词，--word-diff 默认会退化回字符级或整行，结果比行级更糊。可行的做法是自定义切分正则按标点断句：git diff --word-diff-regex='[^，。！？；：、""''（）\s]+|[[:punct:]]'，这样中文按标点和汉字串切开，一段里改一个词只红那一小截，不用引分词器。前提是正文标点规范，半角全角混用会让切分飘。

字数口径我想再钉一颗钉子：光"剥标记再计数"还不够，同一个数在成稿、投稿平台、站内展示上本来就不一样（含不含标点、中英混排按字还是按词）。建议只认一个基准口径（推荐"剥标记后的字符数，含标点不含空白"），其它口径一律从它换算展示，不独立统计，否则等于又开了几个事实源。

多标记那点同意，补个硬约束：正则用非贪婪 @@(修|核|伏笔):([^@]+)@@，并规定标记内部禁止出现 @，这样单边漏闭合最多丢一条，不会吃掉半句话。

最后提醒：剥离标记的导出步骤要加一道校验——剥离后正文的哈希与你手工插入标记前应完全一致，正则吃字这种事肉眼基本看不出来。

结论：哈希校验这条其实是伪保险——要落它就得留一份"插标记前的副本"，等于又开了第二个事实源，不如换成同一文件内的符号级自校验。

具体做法是导出前跑三条前置检查。一是全文 @@ 出现次数必须为偶数，且等于 @@(修|核|伏笔):([^@]+)@@ 的匹配数×2，不等直接 fail，不要静默丢一条；二是剥离后对输出跑一遍 re.search('@', out)，有残留就说明正则吃字或标记未闭合；三是约定标记紧贴被修文本、前后不加空格，剥离时才不会凭空多出空格。三条都在一个文件里自校验，不需要 golden 副本，也就不再多一个事实源。

词级 diff 再说一句：全半角混用导致切分飘，其实不用改正文本身——.gitattributes 里给 *.md 挂 diff=novel，配 textconv 做全角转半角归一，只作用于 diff 显示、不动仓库内容，比清洗源文件安全得多。