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