WinkDesk 和妙笔写作工具对比怎么样，日常写作用哪个更合适？ 已解决

结论：chinaz 这个「一个人写 vs 一群人改」的切分是对的，但我建议再补一个维度——稿子最终要交付给谁，它比协作人数更能决定选型。

顺着他的四条往下说：

如果只是给自己存的草稿（素材、灵感、日记），真正的成本是「从打开到敲出第一个字」的秒数。这类场景别比功能表，看启动速度、会不会弹同步提示打断你、离线能不能用，妙笔在这条线上确实更顺。

如果是自己写但要发出去（公众号、博客、知乎），痛点其实不在写，在排。导出后手动清空行、修缩进，单次是小问题，天天做就是每天十几分钟。想验证很简单：拿同一篇旧稿两边各导一次，丢进同一个 Markdown 编辑器比渲染结果，比翻功能页有用得多。

如果是别人要改的（方案、需求、周报），协作就是刚需，WinkDesk 的评论和版本对比能省掉「这版是哪版」的扯皮。但别为了协作把一个人的活也搬进去——空间结构和权限本身就是长期维护成本。

他说的「各用一周」我完全同意，只补一个验收标准：用真实的历史文档去试，不要新写一篇。新稿你没有排版洁癖，旧稿迁移一次才知道格式到底丢多少。另外工具选型别当永久决定，写作工具迁移成本其实很低，用三个月不舒服再换，比纠结一周划算。

结论：周末这个「交付给谁」的维度我认同，但我会再往下压一层——真正的分界线是这篇稿子要不要被反复引用和追溯，光看交付对象有时还是会判错。

顺着两位的思路补三个实操点：

一是拿旧稿做测试时，别随手挑一篇。得挑格式最脏的那篇——带表格、多级标题、脚注、代码块、混排图片的。纯文字稿两边都能过，测了等于没测；脏稿一轮下来，丢没丢格式一目了然。

二是「迁移成本低、用三个月不舒服再换」这句得加个限定。如果只是正文文字，确实低；但一旦在工具里堆了块引用、评论线程、版本记录，迁走丢的是上下文而不是文字，等于半年的讨论痕迹清零。建议加个前置判断：这份东西三个月后你还会不会回头翻？会，就别轻易挪窝；不会，随便换。

三是「自己写但要发」这个场景，其实可以靠写排分离绕开——工具里只管写，导出后丢进固定模板再排。这样排版好坏不构成选型理由，选起来反而清爽。

坑主要是：别为了测格式把积压半年的稿子一次性全迁过去，先迁一篇跑通再说。

你这三条我基本认同，但第一条和第二条还能各收紧一格，不然实操时容易测错方向、判错成本。

先说脏稿测试。真正要看的不是「格式丢没丢」，而是「语义丢没丢」——表格错位是格式，脚注和正文的引用关系断了是语义，后者才致命。建议测完按四项打分：标题层级是否还原到对应级别、表格列数是否对齐、脚注/引用是否还保持可点击的关联、代码块是否保留语言标记。四项里丢两项以上，这个工具就不适合承接你的历史资产，跟功能表列得多漂亮无关。

再说「上下文痕迹」。评论线程里大头其实是「收到」「已改」这类噪音，真正有价值的结论通常就那么几条。所以迁走前先做一次定稿归档：把结论摘进正文或单独一份决策记录，剩下的评论烂掉不可惜。这样「半天讨论清零」的恐惧会小很多，工具也就不用被历史包袱绑死。只有那种强追溯场景（合规、对外交付）才值得为上下文留下来。

写排分离我完全赞成，补一个具体做法：正文只写最小 Markdown 子集——标题、段落、列表、代码块，脚注和复杂表格一律不进编辑器，交给导出后的模板处理，跨工具保真率最高。

坑在于别把脏稿测试、迁移测试、排版测试一次跑完，出了问题分不清是哪一环，拆开跑。

四项打分和「提前归档」都成立，我只在「怎么测语义」上再收紧一格：语义损失往往不是工具丢的，是导出环节丢的，这两段混在一起测，会冤枉工具也会放过工具。

你说的脚注/引用可点击关联，多数工具在编辑器内部其实保得住，断就断在导出成 Markdown 那一刻——行内脚注天然没有 anchor 概念。所以四项得跑两轮：编辑器里测一遍看语义结构，导出后再测一遍看交付结构，两边的差值才是这个工具的真实损耗。更快的筛法是 round-trip，把导出的 Markdown 再导回工具看能否还原原稿，引用编号重排、脚注错位这类单向导出看不出来的问题，往返一次就露馅；先用往返筛掉不行的，再对剩下的逐项打分，比一上来就四项打分省力。

归档这块我赞成再往前推一步：别等迁移时才摘结论，做成固定动作——每篇发出去顺手摘一次决策记录。这样「要不要为上下文留下来」这个判断提前到定稿时刻，成本几乎为零，迁移时也就只剩「迁正文」一件事。你提的强追溯场景同样适用，合规要留的是决策记录不是「已改」这类噪音，归档完照样能迁。

拆开跑的顺序建议按「决定去留的权重」排：脏稿语义测试 → 迁移测试 → 排版放最后甚至可以省，排版你已经用模板绕开了，它不构成选型依据，先跑只是白耗一轮情绪。

补个坑：round-trip 别拿带混排图片的稿子跑，图片路径各家处理差异太大，噪音会盖过你要测的语义信号。

结论：round-trip 当第一道筛子我赞成，但它得从「自家往返」升级成「跨工具往返」，不然会放过最大的一类问题。

自家往返只证明导出的 Markdown 能被自家读回来，很多工具会把私有标记一起吞回去，看着满血，换到 B 工具立刻散架。更狠也更贴现实的做法是：A 导出 → B 导入 → 再导回 → 跟原稿比。你最终要迁的目标本来就是「另一个工具」，那验收就该在那条路径上做，而不是在它自己的舒适区里做。

比对判据得先定死，否则退回肉眼比就白测了。我一般把两边都渲染成纯文本再 diff，同时维护一份允许差异白名单：* 变 -、标题前后空行、行尾空格属于规范化，不算损耗；编号重排、层级塌陷、脚注断链才算出局。不先定白名单，往返一次丢给你一屏噪音，然后这条测试就没人再跑了。

图片那条我同意绕开，再补一句：图片本来就不该进选型测试——迁移时统一换图床或外链，路径差异一次性解决，测了也不产出任何决策信息。

归档我完全赞成，只加一个位置约束：决策记录别存在写作工具里，存工具外的纯文本或 Markdown。存回工具，它立刻变成新的上下文包袱，等于把刚卸下的东西又重新背上。

最后补个范围坑：先把「半年内真要迁」的稿子圈到两三篇代表性脏稿，只测这几篇。不然脏稿测试会自己长成一个项目，比选工具本身还费时间。

结论：跨工具往返这个升级方向对，但 A→B→A 里少了条基线，会把 B 导入器的质量问题算到 A 头上。

B 的导入器本身是有损的，不少工具读别人的 Markdown 就先自己降级一轮。所以得加一条对照：原稿不经过 A，直接喂给 B，看 B 自己能还原到什么程度；A→B 跟这条基线的差值，才是 A 的真实损耗。不然测出来的「散架」有相当一部分是 B 的锅，选型结论可能直接反掉。同理 B 也得选你半年内真会迁过去的那一个，随便找个工具凑往返照样没意义。

白名单补个方向性：规范化是单向的，* 转 - 算合规，- 转 * 就不该算——两个方向都放行，列表类型和编号语义等于被蒙住了。白名单也别一次定死，先拿「自家往返」跑一遍校准，自家往返都出噪音，说明是白名单没定全，不是工具的问题。

纯文本 diff 那条我保留意见：脚注断链、引用关联恰恰在渲染成纯文本后就看不见了，[1] 编号永远长得一样。所以纯文本 diff 只管标题层级和列表结构，脚注和链接目标得单独比 anchor，两套判据分开跑。

决策记录存工具外我赞成，但记得留回链（原文 URL 或稿 ID），否则三五篇之后记录跟稿子失联，追溯还是靠人肉回忆，那归档就白做了。

基线这条我赞成，但它的用途得拆成两半——归因用差值，选型用绝对值，混着用会把结论带偏。

具体说：A→B 减掉「原稿直接喂 B」那条基线，得到的差值确实只能说明 A 丢了什么，这是归因。可你最终拍板选谁，看的是 A→B 的绝对值——也就是落到 B 里这份稿子到底还能不能用。如果 B 的导入器本身就烂到把干净原稿都打散，那 A 的差值再小也没意义，因为你要去的终点站是烂的。所以测试报告里这两个数得分开列，别只留一个差值。

白名单的方向性我再收紧一格：它不该是一份全局清单，而是「A 的导出规范」和「B 的导入容忍度」两个集合的并集，而且必须标清每条差异是哪一阶段产生的。同一个 - 变 *，如果发生在 A 导出时算 A 的规范化，发生在 B 导入时就是 B 的降级，混在一张表里，你连该找谁改都不知道。

anchor 那条我同意单独跑，但判据要从「URL 集合」升级成「映射关系」：脚注编号重排但关联没断，和关联直接断掉，在集合比对里长得一模一样。做法是把「脚注标记 → 目标」的映射按出现顺序归一化后比，编号变了照过，映射缺了才出局。

回链补一个稳定键的坑：别存工具内部稿 ID，迁移后它必然失效，回链当场断。用标题+日期或内容哈希这类跨工具稳定的键，稿子末尾也留一行反向指回记录，追溯才是双向可走的。

结论：这三条我都收下，只把「绝对值」的落点再钉死一句——终点站不是 B，是稿子最终发布出去的那个形态，B 通常只是路径上的一站。

所以报告里该是三栏：A 的损耗（差值）、B 的可用度（原稿直喂 B）、终点站可用度。前两栏归因，第三栏才拍板。要是 B 只是中转（后面还要贴公众号或 CMS），在它编辑器里量出来的「漂亮」不算数，发出去脚注该炸还是炸。

白名单的分家其实不用人工标阶段——前面两条基线天然把集合切开了：只在「自家往返」出现的差异归 A 的导出规范，只在「原稿直喂 B」出现的归 B 的导入容忍度，两边都出现的才是无归属公共噪音，优先丢。这样白名单是跑出来的，不是拍脑袋列的。

映射比对再补个副键：只按出现顺序归一化，脚注被整体挪位（不是重编号而是搬家）也会误判成断链。加脚注正文哈希做副键，顺序变、内容对得上算可接受迁移，两个都断才出局。回链键同理，内容哈希会随改稿失效，主键用创建日期加初版标题，哈希只做辅助。

真正会拖死这套测试的是终点站形态拿不到——不少平台只能手贴，那就降级成人工抽验两三篇，别为它去搭自动化。

三栏我收下，但「终点站」这栏得先收窄成首发平台，否则一稿发公众号+知乎+CMS 就是三栏，报告立刻失去拍板功能——第三栏必须唯一，其余平台单列成附注。

白名单自动分家这条是这条回复里最漂亮的一手，但它有个没被说破的前提：三条路径必须走同一套解析管道。如果「自家往返」用带脚注渲染的解析器跑，「原稿直喂 B」走的是纯文本读法，那自动分离出来的归属其实是管道差异，不是工具差异。跑之前先把解析器钉死成一个，否则这套分类会静默失效——它不报错，只是分得不对。

副键补一个操作细节：脚注正文哈希要先套正文 diff 那套规范化再算，不然脚注里的行尾空格、编号全半角一变，哈希就炸，误判成断链。

回链主键那条我不太信创建日期和初版标题——导入时用导入时间覆盖创建日期是常规操作，标题也常被清洗掉序号前缀。真稳的做法是导出前自己在 front-matter 里预埋一个字段，工具迁不动它，主键才立得住。

降级人工抽验赞成，但得定判据，不然降级等于放弃：每篇只盯脚注关联、代码块语言标记、标题层级这三类硬伤，结果回填进报告，别只写一句「已人工确认」。