[{"data":1,"prerenderedAt":301},["ShallowReactive",2],{"blog-solo-writer-yearly-plan":3,"blog-prev-solo-writer-yearly-plan":112,"blog-next-solo-writer-yearly-plan":203},{"id":4,"title":5,"author":6,"body":7,"canonical":96,"category":97,"cover":96,"date":98,"description":99,"draft":100,"extension":101,"keywords":96,"meta":102,"navigation":103,"noindex":100,"ogImage":96,"path":104,"seo":105,"seoDescription":96,"seoTitle":96,"stem":106,"tags":107,"updated":96,"__hash__":111},"blog\u002Fblog\u002Fsolo-writer-yearly-plan.md","一个人一年写 50 篇，我们的选题和排期是这么排的","元析智能",{"type":8,"value":9,"toc":85},"minimark",[10,14,18,21,24,28,31,34,37,40,43,46,49,52,55,58,61,64,67,70,73,76,79,82],[11,12,13],"p",{},"一个人一年写 50 篇，靠的不是写得更快，是提前半年把选题排成表，每周只剩一件确定的事：把当周那篇写完。2025 年我们这个内容岗是 1.5 个人，全年发了 48 篇，平均每篇 2.5 个工作日，没有一次为了赶发布熬到半夜。",[15,16,17],"h2",{"id":17},"排期表只有三列",[11,19,20],{},"季度主题、双周选题、发布日。第一列决定我们这三个月在讲哪一类问题，第二列是具体标题，第三列写死到某天，我们固定在周二或周四发。",[11,22,23],{},"三列之外不写别的。计划写到“几点发、配几张图”这种颗粒度，最后一定执行不下去。",[15,25,27],{"id":26},"选题一次定-12-周","选题一次定 12 周",[11,29,30],{},"每季度最后一周开一次选题会，90 分钟，定下个季度 12 周的 12 个题。定完不再改，除非词表里出现明显更强的机会。",[11,32,33],{},"12 个题里留 2 个空位，专门给临时冒出来的东西。不留空位的话，只要客户临时提一个要求，整张表就散了。",[15,35,36],{"id":36},"一周的时间怎么分",[11,38,39],{},"周一半天查资料和读竞品，周二上午写 4 小时出初稿，周三补图改稿并给同事看一遍，周四发布。剩下一天处理临时的事、回复客户、看数据。",[11,41,42],{},"写初稿那 4 小时不开会、不回消息。我试过拆成两个小时两段，质量明显更差，第二天基本要重写。",[15,44,45],{"id":45},"永远提前三篇",[11,47,48],{},"发布队列里始终压着 3 篇已经写完的稿子。出差、生病、临时项目都不影响发布节奏。",[11,50,51],{},"这个缓冲是我交了学费才建的。2025 年 6 月我病了一周，博客断更两周，再恢复时流量掉了 18%，用了将近两个月才回来。",[15,53,54],{"id":54},"不做的三件事",[11,56,57],{},"不追热点。软件行业的所谓热点，一周后就没人搜了，写它挤占的是排期里的位置。",[11,59,60],{},"不接一句话临时选题，除非它能进表。能进表说明它有位置，进不了表说明不急。",[11,62,63],{},"不为周更硬写。宁可发 3 篇有数据的，不发 5 篇凑数的，这是我们 2025 年最确定的一条。",[15,65,66],{"id":66},"排期表用什么工具",[11,68,69],{},"飞书多维表格或者 Notion 都行，我们用的是最简单的表格：一行一个题，七列。太复杂的项目管理工具坚持不到第三个月。",[11,71,72],{},"表里有一列叫“素材状态”，写着差什么资料。没有这列，写稿时你会发现一半时间花在找截图和问客户上。",[15,74,75],{"id":75},"一年之后回头看",[11,77,78],{},"48 篇里真正带来询盘的是 11 篇，其中 9 篇是“场景加问题”型，2 篇是对比型。学习类的内容只带来了流量，没带来销售对话。",[11,80,81],{},"这个结果让我把 2026 年的排期改了比例：学习类从 30% 压到 15%，场景类提到 50%。如果你们也在做年度计划，这个比例可以直接拿去用。",[11,83,84],{},"一个人写不完不是产能问题，是选题没提前定。定完之后，剩下的只是坐下去写。",{"title":86,"searchDepth":87,"depth":87,"links":88},"",2,[89,90,91,92,93,94,95],{"id":17,"depth":87,"text":17},{"id":26,"depth":87,"text":27},{"id":36,"depth":87,"text":36},{"id":45,"depth":87,"text":45},{"id":54,"depth":87,"text":54},{"id":66,"depth":87,"text":66},{"id":75,"depth":87,"text":75},null,"内容运营","2025-10-09","一个人写 50 篇不靠写得更快，靠提前半年把选题排成表。我们 1.5 个人一年发 48 篇，平均每篇 2.5 天，每周只做一件确定的事：把当周那篇写完。",false,"md",{},true,"\u002Fblog\u002Fsolo-writer-yearly-plan",{"title":5,"description":99},"blog\u002Fsolo-writer-yearly-plan",[108,109,110],"内容排期","选题机制","小团队","Yhgd4Upnzg_Aekd-EPKRh9vxVh_YfUj3h9dbchcdYIc",{"id":113,"title":114,"author":6,"body":115,"canonical":96,"category":191,"cover":96,"date":192,"description":193,"draft":100,"extension":101,"keywords":96,"meta":194,"navigation":103,"noindex":100,"ogImage":96,"path":195,"seo":196,"seoDescription":96,"seoTitle":96,"stem":197,"tags":198,"updated":96,"__hash__":202},"blog\u002Fblog\u002Finp-long-task-sources.md","INP 高但不知道怎么改，先查这四类长任务占了多少",{"type":8,"value":116,"toc":182},[117,120,123,127,130,133,137,140,143,147,150,154,157,161,164,167,170,173,176,179],[11,118,119],{},"INP 高，八成是主线程被长任务占住了。今年 9 月我们给 7 个软件站查过 INP，四类来源能解释其中 6 个：框架水合、输入处理器里的同步计算、第三方脚本抢线程、大列表一次性渲染。定位方法不复杂，打开 Performance 面板录一段真实操作，看 Interactions 和长任务轨道。",[11,121,122],{},"先把概念说清楚。INP 是 Interaction to Next Paint，2024 年 3 月正式替代 FID 成为 Core Web Vitals 的交互指标。它算的是用户每次点击、按键到界面画出下一帧的延迟，取整段会话里偏差最大的那次。FID 只算第一次输入的延迟，所以有些站 FID 一直很好看，换成 INP 立刻露馅。",[15,124,126],{"id":125},"第一类框架水合","第一类：框架水合",[11,128,129],{},"Next.js、Nuxt 这类站，HTML 出来了，JS 还没执行完，这段时间用户点任何东西都没反应。一个开发者工具站首屏水合占了 1.2 秒，用户在这段时间点了三次导航，INP 直接记了 780 毫秒。",[11,131,132],{},"查法：Performance 面板里找 hydrate 或者 long task，看它和用户首次点击的时间关系。改法不是优化水合本身，而是让首屏不依赖 JS——导航用原生链接，首屏内容服务端渲染，交互组件按需加载。",[15,134,136],{"id":135},"第二类输入处理器里的同步计算","第二类：输入处理器里的同步计算",[11,138,139],{},"筛选、搜索、表单校验是重灾区。一个 B2B 后台的筛选器，每次点击同步算 1200 行数据的匹配，主线程卡 300 毫秒。用户连续点两下，感受就是卡死。",[11,141,142],{},"改法：把计算挪出事件处理器，用 requestAnimationFrame 或 startTransition 分帧；列表超过 200 行就上虚拟滚动。这类改动通常能砍掉一半的 INP。",[15,144,146],{"id":145},"第三类第三方脚本抢主线程","第三类：第三方脚本抢主线程",[11,148,149],{},"热力图、AB 测试、客服组件，都喜欢在用户第一次交互时上报。我们见过一个站，点击后 180 毫秒内跑了 4 个第三方回调。查法是 Performance 面板里看长任务下面挂的脚本 URL，一眼能认出是谁。",[15,151,153],{"id":152},"第四类大列表和复杂-dom","第四类：大列表和复杂 DOM",[11,155,156],{},"一次渲染 500 个 DOM 节点，浏览器光做样式计算就要 100 多毫秒。文档页的侧边目录、定价页的对比表都是高发区。改法是分页、虚拟滚动、content-visibility。",[15,158,160],{"id":159},"查-inp-的顺序","查 INP 的顺序",[11,162,163],{},"先看 RUM 的 P75 和 P95，差距大说明问题集中在少数交互上，找到那个元素比全局优化划算。再去实验室复现，最后才动手改。我们一般先修 P95 最差的那个交互，因为它往往和其他问题同根。",[15,165,166],{"id":166},"怎么归因到具体元素",[11,168,169],{},"实验室只能看到\"主线程卡了多久\"，看不到\"用户点了哪个按钮\"。要归因到元素，得在代码里埋一条 Interaction 记录：用 PerformanceObserver 监听 event 和 first-input，把 duration 超过 200 毫秒的交互连同比元素信息和页面路径一起上报。我们给客户搭的版本一天收上来十几万条，按页面聚合，最差的那个页面和按钮十分钟内就能锁定。",[11,171,172],{},"这一条比分数本身有用。分数只告诉你\"差\"，归因告诉你\"改哪里\"。",[15,174,175],{"id":175},"移动端是重灾区",[11,177,178],{},"同一个站，桌面端 INP 120 毫秒、移动端 380 毫秒，在我们查过的站里是常态。中低端安卓机的单核性能只有开发机的五分之一，脚本解析和执行的时间都要乘上去。所以 INP 的验收一定要看移动端，尤其是国内安卓机型的分布。",[11,180,181],{},"还有一条边界：INP 低于 200 毫秒就别折腾了。这类改动风险高、验收难，收益已经不明显，把时间花在内容和转化上更划算。",{"title":86,"searchDepth":87,"depth":87,"links":183},[184,185,186,187,188,189,190],{"id":125,"depth":87,"text":126},{"id":135,"depth":87,"text":136},{"id":145,"depth":87,"text":146},{"id":152,"depth":87,"text":153},{"id":159,"depth":87,"text":160},{"id":166,"depth":87,"text":166},{"id":175,"depth":87,"text":175},"技术SEO","2025-10-08","查过 7 个软件站的 INP，四类长任务能解释其中 6 个：框架水合、输入处理器里的同步计算、第三方脚本抢线程、大列表一次渲染。附带定位方法和每类的改法，附实测数字。",{},"\u002Fblog\u002Finp-long-task-sources",{"title":114,"description":193},"blog\u002Finp-long-task-sources",[199,200,201],"INP","交互延迟","长任务","z1Tf2GoNpNNz5tdk0UJax9AObIhacvt27Xs52lQm7_g",{"id":204,"title":205,"author":6,"body":206,"canonical":96,"category":290,"cover":96,"date":291,"description":292,"draft":100,"extension":101,"keywords":96,"meta":293,"navigation":103,"noindex":100,"ogImage":96,"path":294,"seo":295,"seoDescription":96,"seoTitle":96,"stem":296,"tags":297,"updated":96,"__hash__":300},"blog\u002Fblog\u002Ffirst-paragraph-conclusion-geo.md","首段结论写法：前 80 字答不完一个问题就别想被引用",{"type":8,"value":207,"toc":283},[208,211,215,218,221,224,228,231,234,237,240,247,253,259,262,265,268,271,274,277,280],[11,209,210],{},"62 个页面，只有 11 个能在前 80 字里回答标题承诺的那个问题。剩下 51 个都在铺垫：行业在变、客户很难、我们懂你。2025 年 10 月我们把这批首段全部抽出来，一张一张读，读完就知道为什么这些页面在 AI 搜索里没声音。",[15,212,214],{"id":213},"首段不是摘要是答案","首段不是摘要，是答案",[11,216,217],{},"很多人把首段当导语写，交代背景、引出主题、预告结构。这套写法在传统搜索里能活，因为用户会往下滚。AI 不会滚，它按块抓，抓到的第一块如果只是\"随着业务复杂度上升\"，它就把整页判为无答案。",[11,219,220],{},"首段的唯一任务是：让引擎在 80 字内拿到一个能脱离上下文成立的事实。这个事实要能直接回应用户的提问。",[11,222,223],{},"判断方法很简单。把首段单独复制出来，发给一个不了解你业务的人，问他\"这段话回答了什么问题\"。他说不上来，重写。",[15,225,227],{"id":226},"_60-到-110-字是甜区","60 到 110 字是甜区",[11,229,230],{},"我一开始以为越短越好，20 字把结论砸出来最干脆。试了之后发现不对。",[11,232,233],{},"太短的首段没有主题信号。一句话\"我们支持 12 种数据源\"，引擎不知道这页在讲什么，因为它没拿到主语和场景。30 字以内被引用的比例反而低。",[11,235,236],{},"我们最后落的标准是 60 到 110 字：第一句给判断，第二句给一个数字或条件，第三句给边界。三句话，三段信息，不重叠。",[15,238,239],{"id":239},"三种能用的开头",[11,241,242,246],{},[243,244,245],"strong",{},"判断加数字。","\"B2B 软件的 AI 引用有 7 成来自非产品页。我们统计了 47 条引用，只有 4 条指向首页。\"",[11,248,249,252],{},[243,250,251],{},"定义加边界。","\"GEO 是让 AI 搜索引用你的内容，不是让排名上升。它优化的对象是答案块，不是关键词位置。\"",[11,254,255,258],{},[243,256,257],{},"反常识加证据。","\"改内链对 AI 引用几乎没用。我们改过 60 个页面的内链结构，引用次数只动了 1 次。\"",[11,260,261],{},"这三种开头有个共同点：第一句就能被拿走单独用。",[15,263,264],{"id":264},"改完之后的数",[11,266,267],{},"40 个首段，9 周，引用次数从 9 次到 27 次。同期没有动标题、没有加外链、没有发新文章。三个站的样本，样本不大，但方向一致。",[11,269,270],{},"有个细节值得说：改动之后，被引用的句子几乎都是新写的首段第二句，不是第一句。第一句是判断，第二句是事实。引擎要事实。",[15,272,273],{"id":273},"三个别用的开头",[11,275,276],{},"别用\"随着某某发展\"，别用\"在某某形势之下\"，别用\"我们致力于\"。这三类开头我们一共删了 100 多段，删完页面反而更好读。",[11,278,279],{},"还有一种更隐蔽的：以问题开头。\"你是否也在为数据孤岛发愁？\"这看起来像结论前置，其实是把回答推给下一段。AI 抓不到问题背后的答案，只抓到一句反问。",[11,281,282],{},"首段写完，念一遍。如果念完还没说到具体的事，就别发了。",{"title":86,"searchDepth":87,"depth":87,"links":284},[285,286,287,288,289],{"id":213,"depth":87,"text":214},{"id":226,"depth":87,"text":227},{"id":239,"depth":87,"text":239},{"id":264,"depth":87,"text":264},{"id":273,"depth":87,"text":273},"GEO","2025-10-10","抽出 62 个客户博客首段，只有 11 个能在 80 字内回答标题承诺的问题。我们重写了 40 个首段，9 周后 AI 引用从 9 次到 27 次。附三种能用的开头句式。",{},"\u002Fblog\u002Ffirst-paragraph-conclusion-geo",{"title":205,"description":292},"blog\u002Ffirst-paragraph-conclusion-geo",[290,298,299],"内容写作","AI引用","297oOXQb2DKy8Sq_co9gLUrIGHZvSQg6YHdgdvl9cxs",1794088111776]