[{"data":1,"prerenderedAt":325},["ShallowReactive",2],{"blog-content-repurposing":3,"blog-prev-content-repurposing":125,"blog-next-content-repurposing":226},{"id":4,"title":5,"author":6,"body":7,"canonical":110,"category":111,"cover":110,"date":112,"description":113,"draft":114,"extension":115,"keywords":110,"meta":116,"navigation":117,"noindex":114,"ogImage":110,"path":118,"seo":119,"seoDescription":110,"seoTitle":110,"stem":120,"tags":121,"updated":110,"__hash__":124},"blog\u002Fblog\u002Fcontent-repurposing.md","一篇长文拆成 6 个渠道：我们的内容复用流程和偷懒清单","元析智能",{"type":8,"value":9,"toc":99},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78,81,84,87,90,93,96],[11,12,13],"p",{},"写完一篇 4000 字长文只发一个渠道，是最常见的浪费。我们把它拆成 6 个渠道：公众号、Newsletter、知乎、视频脚本、社交媒体卡片、销售物料。",[15,16,17],"h2",{"id":17},"为什么要复用",[11,19,20],{},"一篇深度长文的成本不低：调研、写作、审稿，加起来 20 到 30 小时。只发一个渠道，等于只用了 30% 的价值。",[11,22,23],{},"我们 2025 年算过一笔账：复用流程跑起来之后，同样一篇内容带来的总曝光是原来的 3.2 倍，增量成本不到 6 小时。",[15,25,26],{"id":26},"六个渠道怎么拆",[11,28,29],{},"公众号：取长文的一个核心观点，写成 2000 字左右的独立文章，开头直接抛结论，结尾链回长文。",[11,31,32],{},"Newsletter：把长文缩成 800 字摘要，列 3 个要点，加一个\"完整版在这里\"的链接。",[11,34,35],{},"知乎：回答一个和长文主题对应的问题，用长文里的数据和案例，别整篇复制。",[11,37,38],{},"视频脚本：取最有画面感的一节，改成 3 分钟口播脚本，配 PPT 或录屏。",[11,40,41],{},"社交媒体卡片：把长文里的 5 个数字或 5 个结论做成图，配一句短文案。",[11,43,44],{},"销售物料：把长文里的框架整理成一页 PDF，给销售在和客户沟通时用。",[15,46,47],{"id":47},"拆的时候改什么",[11,49,50],{},"改开头：每个渠道的读者进入场景不同，开头要重写，别用同一个。",[11,52,53],{},"改长度：长文 4000 字，公众号 2000 字，Newsletter 800 字，卡片 100 字。",[11,55,56],{},"改钩子：公众号用故事开头，知乎用问题开头，视频用画面开头。",[11,58,59],{},"不改的：核心数据、案例、观点。这些是长文的价值，拆分时要保留。",[15,61,62],{"id":62},"一个例子",[11,64,65],{},"2026 年 4 月我们发了一篇\"API 限流怎么做\"的长文，4200 字。",[11,67,68],{},"公众号版讲了一个客户被限流打挂的故事，阅读 1.2 万。知乎版回答\"API 限流有哪些方案\"，拿了 800 多赞。视频脚本做了 3 分钟，播放 2 万。Newsletter 版带来 200 多个订阅。销售物料那页 PDF，被销售用了 30 多次。",[11,70,71],{},"同一批内容，六个渠道，总曝光是长文本身的 5 倍。",[15,73,74],{"id":74},"什么时候别复用",[11,76,77],{},"时效性内容别复用。热点过了，拆出来的内容也没人看。",[11,79,80],{},"数据没验证的别复用。一个渠道出错还能改，六个渠道同时出错，就是事故。",[11,82,83],{},"内部资料别外发。客户案例、报价逻辑这类内容，拆之前先确认能不能公开。",[15,85,86],{"id":86},"偷懒清单",[11,88,89],{},"我们内部有一个\"复用检查表\"：开头改了吗、长度改了吗、钩子改了吗、链接对吗、数据核实了吗、发布渠道的格式适配了吗。六项全过才能发。",[11,91,92],{},"这个表看起来麻烦，但比每个渠道重新写一遍省事得多。六个渠道的改法都是我们自己摸出来的，没有理论，全是试错。",[15,94,95],{"id":95},"一句判断",[11,97,98],{},"内容复用的核心不是\"一稿多投\"，是\"一稿多写\"。同一份素材，按渠道重写开头和结构，才是复用；直接把长文复制到五个平台，那是偷懒，效果也差。",{"title":100,"searchDepth":101,"depth":101,"links":102},"",2,[103,104,105,106,107,108,109],{"id":17,"depth":101,"text":17},{"id":26,"depth":101,"text":26},{"id":47,"depth":101,"text":47},{"id":62,"depth":101,"text":62},{"id":74,"depth":101,"text":74},{"id":86,"depth":101,"text":86},{"id":95,"depth":101,"text":95},null,"内容运营","2026-06-14","写完一篇 4000 字长文只发一个渠道，是最常见的浪费。我们把它拆成 6 个渠道：公众号、Newsletter、知乎、视频脚本、社交媒体卡片、销售物料。拆什么、改什么、哪些不能复用都在这篇，拆分清单可以直接抄，我们每周都在用。",false,"md",{},true,"\u002Fblog\u002Fcontent-repurposing",{"title":5,"description":113},"blog\u002Fcontent-repurposing",[122,123,111],"内容复用","内容分发","4pV4s2sH-f31_5hUn4CbmwYe60yRFEPMyF96OmmeCM0",{"id":126,"title":127,"author":6,"body":128,"canonical":110,"category":214,"cover":110,"date":215,"description":216,"draft":114,"extension":115,"keywords":110,"meta":217,"navigation":117,"noindex":114,"ogImage":110,"path":218,"seo":219,"seoDescription":110,"seoTitle":110,"stem":220,"tags":221,"updated":110,"__hash__":225},"blog\u002Fblog\u002Ffont-loading-chinese.md","中文字体加载慢，问题不在字体文件大小",{"type":8,"value":129,"toc":206},[130,133,136,139,142,145,148,151,154,158,161,164,167,170,173,176,179,182,185,188,191,194,197,200,203],[11,131,132],{},"2026 年 7 月我们给一个站查首屏，字体请求花了 1.9 秒，字体包 8 兆。中文字体确实大，但把它变慢的往往不是体积，而是加载时机和切换方式。改完之后同一个包首屏基本感觉不到等待。",[15,134,135],{"id":135},"中文字体为什么这么大",[11,137,138],{},"一个完整的思源黑体，包含两万多个字形，压缩后也有五到八兆。网页上真正用到常用字大概三千五，剩下九成多是浪费。",[11,140,141],{},"所以中文字体优化的第一件事不是压缩，是子集化：把你实际用到的字挑出来，生成一个只有几百 KB 的字体文件。",[15,143,144],{"id":144},"子集化怎么做",[11,146,147],{},"第一种，按页面用字生成。统计页面里出现的所有字符，生成对应子集。缺点是页面内容一改就要重新生成，适合内容稳定的官网。",[11,149,150],{},"第二种，按 unicode-range 分片。把字体切成多个小文件，浏览器按需加载。首屏常用字在第一个分片里，加载很快。",[11,152,153],{},"第三种，用在线字体服务，它们默认做分片。代价是多一个外部依赖，国内访问还要考虑稳定性。",[15,155,157],{"id":156},"font-display-三种取值","font-display 三种取值",[11,159,160],{},"block，字体没加载完文字不显示，最多等三秒。体验最差，用户看到一片空白。",[11,162,163],{},"swap，先用系统字体显示，加载完再换。文字马上可见，但切换时会有位移，字号大的时候很明显。",[11,165,166],{},"optional，如果字体没在很短的时间内加载好，这次就用系统字体，不切换。最不影响体验，但品牌字体可能经常不显示。",[11,168,169],{},"我们的选择是标题用 swap 加尺寸校正，正文直接用系统字体。",[15,171,172],{"id":172},"预加载和预连接",[11,174,175],{},"字体文件藏在 CSS 里，浏览器要等 CSS 解析完才发现它。用 preload 提前告诉浏览器，能省掉一个来回。",[11,177,178],{},"preload 要带 crossorigin，否则会因为请求类型不匹配被下载两次。这个坑我们踩过，字体反而更慢了。",[11,180,181],{},"字体放在第三方域名上，再加一条 preconnect，把 TLS 握手提前做掉。",[15,183,184],{"id":184},"什么时候干脆别用",[11,186,187],{},"一个官网只用了两种英文字体、没有中文需求，完全可以不加载自定义字体，用系统字体栈。",[11,189,190],{},"系统字体在 macOS、Windows、安卓上都不一样，但都好看，且零加载时间。首屏速度能提升几百毫秒。",[11,192,193],{},"品牌必须用特定字体，那就只用在标题和 logo 上，正文用系统字体。我们的默认建议就是这条。",[15,195,196],{"id":196},"一个验证方法",[11,198,199],{},"改完别只看 Lighthouse 的分数。把网络降到 3G，清缓存刷新，观察文字什么时候出现、什么时候变形。",[11,201,202],{},"再看真实用户数据。CrUX 里没有字体指标，但 LCP 如果卡在文字上，说明字体拖了后腿。",[11,204,205],{},"字体优化的收益常常被低估，因为它不像图片那么显眼。但首屏里最大的那块如果是标题文字，字体就是 LCP 的直接原因。",{"title":100,"searchDepth":101,"depth":101,"links":207},[208,209,210,211,212,213],{"id":135,"depth":101,"text":135},{"id":144,"depth":101,"text":144},{"id":156,"depth":101,"text":157},{"id":172,"depth":101,"text":172},{"id":184,"depth":101,"text":184},{"id":196,"depth":101,"text":196},"技术SEO","2026-06-13","一个中文字体包动辄八兆，但真正拖慢首屏的是加载时机和字形切换。这篇写子集化怎么做、font-display 三种取值怎么选、什么时候干脆别用自定义字体。",{},"\u002Fblog\u002Ffont-loading-chinese",{"title":127,"description":216},"blog\u002Ffont-loading-chinese",[222,223,224],"字体加载","页面体验","首屏","Sj3AIAaQl9sp9T_6h0hDGKZlWOxFU1oPgRu62eF9Nog",{"id":227,"title":228,"author":6,"body":229,"canonical":110,"category":111,"cover":110,"date":314,"description":315,"draft":114,"extension":115,"keywords":110,"meta":316,"navigation":117,"noindex":114,"ogImage":110,"path":317,"seo":318,"seoDescription":110,"seoTitle":110,"stem":319,"tags":320,"updated":110,"__hash__":324},"blog\u002Fblog\u002Ftutorial-post-structure.md","教程文缺三样东西：前置条件、验证方法、失败信号",{"type":8,"value":230,"toc":304},[231,234,238,241,244,247,250,253,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298,301],[11,232,233],{},"教程文写不好，八成不是文笔问题，是缺三样东西：前置条件、验证方法、失败信号。补上这三样，同一篇内容的支持成本能降一半。2025 年 12 月我们重写过一篇 SDK 接入文档，工单从每月 34 条降到 18 条。",[15,235,237],{"id":236},"开头别铺垫直接说给谁看","开头别铺垫，直接说给谁看",[11,239,240],{},"开头写两句话就够：这篇适合谁，做完能得到什么。比如“适合第一次接入的开发者，做完能用 20 行代码发出第一条消息”。",[11,242,243],{},"别用“下面我们来介绍”这种开场，读者是来判断要不要往下读的。",[15,245,246],{"id":246},"前置条件放最前面",[11,248,249],{},"版本号、权限、环境、依赖。缺一个，读者卡在第一步，然后去问客服。",[11,251,252],{},"我们那篇文档原来把版本要求写在第三步，结果一半的工单是“装了跑不起来”。挪到开头之后，这类工单基本消失。",[15,254,255],{"id":255},"每一步要有一个可观察的结果",[11,257,258],{},"写完一个动作，告诉读者现在应该看到什么。命令输出、界面变化、日志里的一行。",[11,260,261],{},"没有可观察结果的步骤，读者不知道自己做对没有，只能往下猜，猜错三步之后就来提问了。",[15,263,264],{"id":264},"验证方法单独成一节",[11,266,267],{},"给一条命令，或者一个检查点，让读者确认整体做完了。",[11,269,270],{},"这一步很多人省，觉得“按步骤做就行”。实际上读者会跳步、会漏步，验证是他自己发现问题的唯一机会。",[15,272,273],{"id":273},"失败信号要写",[11,275,276],{},"写清最常见的两三种报错，每一种对应什么原因、怎么处理。",[11,278,279],{},"我们统计过，一篇文档底部的“常见错误”如果写全了，工单量能降三成。这部分比正文更值钱。",[15,281,282],{"id":282},"截图放多少",[11,284,285],{},"关键界面放，每步都放会拉长页面，加载慢，而且读者记不住。",[11,287,288],{},"我们的标准是：一步之内出现的重要选择、容易点错的位置，配一张图。纯命令行的步骤不配图。",[15,290,291],{"id":291},"一个检查清单",[11,293,294],{},"写完过一遍：开头有没有说清给谁看；前置条件齐不齐；每步有没有可观察结果；有没有验证命令；有没有两三个报错解释；代码能不能直接复制运行。",[11,296,297],{},"六条全过，这篇教程才算能发。我们内部还有个土办法：让一个没碰过这个功能的人照着文档走一遍，走不通的地方就是该改的地方。",[15,299,300],{"id":300},"一个提醒",[11,302,303],{},"教程的更新频率比写作质量更重要。产品改一次，教程就得跟着改一次。我们给客户的文档都标了最近验证的版本号，过期的教程比没有教程更伤。",{"title":100,"searchDepth":101,"depth":101,"links":305},[306,307,308,309,310,311,312,313],{"id":236,"depth":101,"text":237},{"id":246,"depth":101,"text":246},{"id":255,"depth":101,"text":255},{"id":264,"depth":101,"text":264},{"id":273,"depth":101,"text":273},{"id":282,"depth":101,"text":282},{"id":291,"depth":101,"text":291},{"id":300,"depth":101,"text":300},"2026-06-15","教程写不好，八成不是文笔问题。我们重写过一篇 SDK 接入文档，补齐前置条件、验证命令和报错解释之后，相关工单从每月 34 条降到 18 条。",{},"\u002Fblog\u002Ftutorial-post-structure",{"title":228,"description":315},"blog\u002Ftutorial-post-structure",[321,322,323],"教程写作","技术文档","内容结构","l0xXot7ebSpA92eYe0ryMo5e0DiHE2cmnQ4luLGcne8",1794088104736]