[{"data":1,"prerenderedAt":324},["ShallowReactive",2],{"blog-batch-writing-workflow":3,"blog-prev-batch-writing-workflow":114,"blog-next-batch-writing-workflow":228},{"id":4,"title":5,"author":6,"body":7,"canonical":98,"category":99,"cover":98,"date":100,"description":101,"draft":102,"extension":103,"keywords":98,"meta":104,"navigation":105,"noindex":102,"ogImage":98,"path":106,"seo":107,"seoDescription":98,"seoTitle":98,"stem":108,"tags":109,"updated":98,"__hash__":113},"blog\u002Fblog\u002Fbatch-writing-workflow.md","一天写四篇：我们的批量写作流程和它的代价","元析智能",{"type":8,"value":9,"toc":87},"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],[11,12,13],"p",{},"一天写四篇，不是四篇都在从零想。我们的批量日是这么排的：上午两篇结构固定的短稿，下午两篇要查资料的，晚上不回看，第二天统一改。2026 年 3 月试了一整月，产出 15 篇，是平时的两倍多。",[15,16,17],"h2",{"id":17},"提前一周把事做完",[11,19,20],{},"选题、素材、模板，全部在前一周定好。批量日当天不查词、不定题、不找图，只写。",[11,22,23],{},"素材包里每篇要有：三个必须回答的问题、一个独家信息、两张截图或一段代码。缺一样，这篇当天写不了。",[15,25,26],{"id":26},"上午写短的",[11,28,29],{},"上午的两篇是 800 到 1000 字的短稿，结构固定：结论、三个小节、一个清单。这类内容不需要太多思考，写得快。",[11,31,32],{},"我上午能写两篇，中间休息 20 分钟。速度来自结构固定，不是打字快。",[15,34,35],{"id":35},"下午写要查资料的",[11,37,38],{},"下午的两篇通常是数据文或教程，需要翻后台、跑数、看文档。一篇要两到三小时。",[11,40,41],{},"这两篇写完当天不追求完美，能出完整初稿就算完成。",[15,43,44],{"id":44},"第二天统一改",[11,46,47],{},"批量日不修改，第二天上午花两小时统一过一遍：删废话、补第一人称、检查有没有独家信息。",[11,49,50],{},"隔一夜再看，能砍掉的东西比当天多。当天觉得必要的段落，第二天往往一眼就知道该删。",[15,52,53],{"id":53},"代价是什么",[11,55,56],{},"第一个月的代价很明显：数据文比例从 30% 降到 12%，全是结构化的短稿。阅读完成率掉了 9 个百分点。",[11,58,59],{},"第二个月我们把批量日改成两周一次，数据文单独安排，情况才平衡。",[15,61,62],{"id":62},"什么内容不适合批量",[11,64,65],{},"需要实测的、需要采访客户的、需要跑对比实验的，一天最多一篇。硬塞进批量日，出来的东西一定是空壳。",[11,67,68],{},"我们的分工是：批量日写“已知答案”的题，单独安排写“需要找答案”的题。",[15,70,71],{"id":71},"给一个人团队的建议",[11,73,74],{},"先别追求四篇。能稳定一天两篇、每周两天，一个月也有 16 篇，够用。",[11,76,77],{},"另外，批量日之后一定要留一天不写。连续两天四篇，第三天的稿子质量明显下滑，这个我自己试过两次，两次都一样。",[11,79,80],{},"我们后来把批量日固定成每两周一次，平时一天一篇。这样既有集中产出的效率，也不会把内容质量压平。",[11,82,83],{},"如果你的选题里一半以上需要查资料，批量日就不适合你。先算一下比例，再决定要不要这么做。",[11,85,86],{},"批量写作的价值在减少切换成本，不在追求数量。切换一次大脑要 20 分钟，一天切八次，什么都写不出来。",{"title":88,"searchDepth":89,"depth":89,"links":90},"",2,[91,92,93,94,95,96,97],{"id":17,"depth":89,"text":17},{"id":26,"depth":89,"text":26},{"id":35,"depth":89,"text":35},{"id":44,"depth":89,"text":44},{"id":53,"depth":89,"text":53},{"id":62,"depth":89,"text":62},{"id":71,"depth":89,"text":71},null,"内容运营","2026-05-25","一天四篇不是四篇都在写。我们上午写两篇结构固定的短稿，下午写两篇要查资料的，晚上不回看。试了一个月产出 15 篇，但也暴露了代价。",false,"md",{},true,"\u002Fblog\u002Fbatch-writing-workflow",{"title":5,"description":101},"blog\u002Fbatch-writing-workflow",[110,111,112],"内容生产","写作流程","小团队","puckOWYLJ3lsdH2i69ZkDM35fE7R4ntcs-W1aVLW4wA",{"id":115,"title":116,"author":6,"body":117,"canonical":98,"category":216,"cover":98,"date":217,"description":218,"draft":102,"extension":103,"keywords":98,"meta":219,"navigation":105,"noindex":102,"ogImage":98,"path":220,"seo":221,"seoDescription":98,"seoTitle":98,"stem":222,"tags":223,"updated":98,"__hash__":227},"blog\u002Fblog\u002Fcache-three-layers.md","浏览器、CDN、服务端三层缓存，只配一层等于没配",{"type":8,"value":118,"toc":207},[119,122,125,128,131,134,137,140,143,146,149,153,156,159,162,165,168,171,174,177,180,183,186,189,192,195,198,201,204],[11,120,121],{},"2026 年 6 月我们接手一个站，首页加载 4.2 秒，查下来是缓存配反了：HTML 缓存一年，JS 和 CSS 缓存五分钟。用户每次访问都在重新下载样式和脚本，而首页本身永远是他一年前看到的版本。",[15,123,124],{"id":124},"三层缓存各管什么",[11,126,127],{},"浏览器缓存管单个用户，决定他第二次访问要不要重新下载。",[11,129,130],{},"CDN 缓存管一个区域的所有用户，决定请求要不要回到源站。",[11,132,133],{},"服务端缓存管数据，决定每次请求要不要查数据库、拼页面。",[11,135,136],{},"三层都配好，一个老用户访问首页可以只发一次 HTML 请求，其余全命中。",[15,138,139],{"id":139},"浏览器缓存怎么配",[11,141,142],{},"带内容哈希的静态资源，缓存一年，加 immutable。文件名变了 URL 就变了，不用担心更新问题。",[11,144,145],{},"HTML 不缓存或者只缓存几分钟。它是入口，缓存久了用户看不到新内容。",[11,147,148],{},"字体和图片可以长缓存，但要确认 URL 带版本或者哈希。",[15,150,152],{"id":151},"cdn-缓存怎么配","CDN 缓存怎么配",[11,154,155],{},"关键是缓存键。默认按 URL 缓存，如果 URL 里带了没意义的参数，缓存会被打散。",[11,157,158],{},"动态页面要么不缓存，要么用短时间加回源校验。我们一般给 HTML 设 5 分钟，给接口设不缓存。",[11,160,161],{},"还有一点，回源要带压缩。很多站 CDN 到源站这段没开 gzip，白白多传几倍数据。",[15,163,164],{"id":164},"服务端缓存怎么配",[11,166,167],{},"页面级缓存最有效，整页存起来，命中直接返回。",[11,169,170],{},"对象缓存其次，把数据库查询结果存内存。",[11,172,173],{},"数据变了要能主动清缓存，否则内容更新了用户还看到旧的。我们通常用版本号做键，发布时改版本号，旧缓存自然失效。",[15,175,176],{"id":176},"最常见的三种配错",[11,178,179],{},"第一种，就是开头说的两层配反。判断方法很简单，看响应头的 Cache-Control，HTML 和静态资源必须不一样。",[11,181,182],{},"第二种，静态资源文件名没哈希却设了长缓存。发版之后用户还跑旧代码，出了问题很难查。",[11,184,185],{},"第三种，CDN 缓存了带用户信息的页面。这个更危险，A 用户可能看到 B 用户的数据。",[15,187,188],{"id":188},"怎么验证配对了",[11,190,191],{},"用 curl 看响应头，重点看 cache-control、etag、age、x-cache 四个字段。",[11,193,194],{},"age 大于 0 说明命中了 CDN，x-cache 显示 HIT 或 MISS。连续请求同一个静态资源两次，第二次应该全是 HIT。",[11,196,197],{},"再打开 DevTools 的 Network 面板，看 Size 列有没有 from cache。这一步最直观。",[15,199,200],{"id":200},"一个态度",[11,202,203],{},"缓存是性价比最高的性能优化。改配置不写代码，效果立竿见影。",[11,205,206],{},"但它也是最容易出事故的地方。每次改缓存策略，尤其是 HTML 和带用户信息的页面，一定要先在测试环境验证，别直接调到生产。",{"title":88,"searchDepth":89,"depth":89,"links":208},[209,210,211,212,213,214,215],{"id":124,"depth":89,"text":124},{"id":139,"depth":89,"text":139},{"id":151,"depth":89,"text":152},{"id":164,"depth":89,"text":164},{"id":176,"depth":89,"text":176},{"id":188,"depth":89,"text":188},{"id":200,"depth":89,"text":200},"技术SEO","2026-05-24","静态资源该缓存一年，HTML 只该缓存五分钟。我们见过把两层配反的站，用户每次访问都在重新下载。这篇写三层各配什么、怎么配错。",{},"\u002Fblog\u002Fcache-three-layers",{"title":116,"description":218},"blog\u002Fcache-three-layers",[224,225,226],"缓存","CDN","页面体验","y2rj8uPfGTph9tGcf-y8gYIUZWoYf0TTatwwzpbQ9TM",{"id":229,"title":230,"author":6,"body":231,"canonical":98,"category":99,"cover":98,"date":313,"description":314,"draft":102,"extension":103,"keywords":98,"meta":315,"navigation":105,"noindex":102,"ogImage":98,"path":316,"seo":317,"seoDescription":98,"seoTitle":98,"stem":318,"tags":319,"updated":98,"__hash__":323},"blog\u002Fblog\u002Fcontent-types-division.md","博客、文档、落地页、案例：四类内容各管什么，别互相抢",{"type":8,"value":232,"toc":305},[233,236,239,242,245,248,251,254,257,260,263,266,269,272,275,278,281,284,287,290,293,296,299,302],[11,234,235],{},"软件公司做内容最容易犯的错，是让四类内容干同一件事。博客负责获客、文档负责留存、落地页负责转化、案例负责信任，分工错了会互相抢词。",[15,237,238],{"id":238},"四类内容的分工",[11,240,241],{},"博客：回答用户的问题，覆盖信息型查询，目标是让不知道你的人找到你。",[11,243,244],{},"文档：教用户怎么用产品，覆盖产品功能词和操作词，目标是让用了的人留下来。",[11,246,247],{},"落地页：承接商业意图，覆盖\"工具\"\"软件\"\"方案\"这类词，目标是让找到你的人转化。",[11,249,250],{},"案例：证明你能解决问题，覆盖\"客户案例\"\"行业方案\"这类词，目标是让犹豫的人下决心。",[15,252,253],{"id":253},"分工错了会怎样",[11,255,256],{},"最典型的是博客抢落地页的词。博客写了一篇\"项目管理工具怎么选\"，排到第 8；产品落地页也想做这个词，排在 20 开外。两个页面互相抢，谁也上不去。",[11,258,259],{},"我们 2026 年 3 月处理过一个这样的站：博客和落地页抢\"客服系统\"这个词，互相蚕食了四个月。",[11,261,262],{},"解法：博客文章改成\"客服系统选型的 5 个坑\"，把商业意图的\"客服系统\"留给落地页；博客内链到落地页，把流量导过去。",[15,264,265],{"id":265},"我们的分工表",[11,267,268],{},"按关键词类型分，最清楚：",[11,270,271],{},"信息型词（怎么、是什么、为什么）→ 博客。\n操作型词（怎么配置、报错、版本）→ 文档。\n商业型词（工具、软件、价格、替代品）→ 落地页。\n证明型词（案例、客户、行业方案）→ 案例页。",[11,273,274],{},"一个词只归一类，归完写进关键词库，避免后面撞车。",[15,276,277],{"id":277},"一个边界",[11,279,280],{},"不是所有词都能干净归类。\"API 监控\"这种词，博客、文档、落地页都能做，这类词要按搜索意图再拆一层。",[11,282,283],{},"我们的做法是看 SERP：如果前 10 名多是博客文章，博客做；如果多是产品页，落地页做。跟着 SERP 走，比自己拍脑袋准。",[15,285,286],{"id":286},"一个常见的浪费",[11,288,289],{},"很多软件公司的文档写得像博客，讲行业趋势，不讲自家功能。这类内容既不解决用户问题，也不带来搜索流量。",[11,291,292],{},"文档就写\"怎么用\"，别写\"为什么这个行业需要\"。",[15,294,295],{"id":295},"一句判断",[11,297,298],{},"内容分工不是组织架构问题，是关键词归属问题。先分词，再分内容，最后才分人。",[11,300,301],{},"分工清楚了，四类内容各做各的，流量才会叠加，而不是互相抵消。",[11,303,304],{},"最后补一句：这个分工表不是死的，产品阶段不同，权重会变。早期获客靠博客，成熟期转化靠落地页和案例，排期要跟着阶段走。",{"title":88,"searchDepth":89,"depth":89,"links":306},[307,308,309,310,311,312],{"id":238,"depth":89,"text":238},{"id":253,"depth":89,"text":253},{"id":265,"depth":89,"text":265},{"id":277,"depth":89,"text":277},{"id":286,"depth":89,"text":286},{"id":295,"depth":89,"text":295},"2026-05-26","软件公司做内容最容易犯的错，是让四类内容干同一件事。博客负责获客、文档负责留存、落地页负责转化、案例负责信任，分工错了会互相抢词。我们的分工表、一个抢词案例和三个判断边界都在这篇。",{},"\u002Fblog\u002Fcontent-types-division",{"title":230,"description":314},"blog\u002Fcontent-types-division",[320,321,322],"内容矩阵","内容分工","站点结构","tuVuHiA4RA1sgBNvuyRkB2si4KMCPB3uJZZ4p68DK44",1794088105343]