[{"data":1,"prerenderedAt":357},["ShallowReactive",2],{"blog-content-differentiation":3,"blog-prev-content-differentiation":131,"blog-next-content-differentiation":248},{"id":4,"title":5,"author":6,"body":7,"canonical":115,"category":116,"cover":115,"date":117,"description":118,"draft":119,"extension":120,"keywords":115,"meta":121,"navigation":122,"noindex":119,"ogImage":115,"path":123,"seo":124,"seoDescription":115,"seoTitle":115,"stem":125,"tags":126,"updated":115,"__hash__":130},"blog\u002Fblog\u002Fcontent-differentiation.md","同一个功能，三家软件公司怎么写不一样","元析智能",{"type":8,"value":9,"toc":103},"minimark",[10,14,18,21,24,28,31,34,37,41,44,47,50,54,57,60,63,66,69,72,76,79,82,85,88,91,94,97,100],[11,12,13],"p",{},"软件公司的内容会同质化，因为大家写的是\"功能清单\"。差异不在功能，在场景、代价和证据。我们给三个客户写同一个功能，三篇内容角度完全不同。",[15,16,17],"h2",{"id":17},"为什么内容会同质化",[11,19,20],{},"因为大家查的是同一批关键词，看的是同一批竞品，写出来自然一样：功能介绍、使用步骤、优势罗列。",[11,22,23],{},"用户看了三篇，记住的是\"都差不多\"，选谁取决于价格。",[15,25,27],{"id":26},"差异化方向一场景","差异化方向一：场景",[11,29,30],{},"同一个功能，不同公司的用户场景不同。",[11,32,33],{},"比如\"自动化审批\"，A 公司卖给财务团队，写的是\"报销审批怎么减少来回\"；B 公司卖给研发团队，写的是\"发布审批怎么不卡上线\"；C 公司卖给法务，写的是\"合同审批怎么留痕\"。",[11,35,36],{},"功能一样，场景不同，内容完全不同。",[15,38,40],{"id":39},"差异化方向二代价","差异化方向二：代价",[11,42,43],{},"大多数内容只讲功能多好，不讲代价。",[11,45,46],{},"我们的做法是讲清楚\"用这个功能要付出什么\"：配置成本、学习成本、维护成本、什么情况下不适用。",[11,48,49],{},"讲代价的内容反而更容易被信任，因为它像真话。我们给一个客户写的\"为什么我们不做全自动审批\"，阅读量是功能介绍的 2 倍。",[15,51,53],{"id":52},"差异化方向三证据","差异化方向三：证据",[11,55,56],{},"同一个功能，你有没有别人没有的证据：真实客户数据、内部测试、失败案例。",[11,58,59],{},"我们一般要求每篇功能文至少一个证据：一个客户的真实使用数据、一次内部压测结果、一个踩过的坑。",[15,61,62],{"id":62},"一个示例",[11,64,65],{},"2026 年 5 月，三个客户都做\"日志检索\"功能。",[11,67,68],{},"A 的稿子：日志检索怎么配，配错了会怎样（场景 + 代价）。\nB 的稿子：100 亿条日志检索，我们的响应时间是多少（证据 + 数据）。\nC 的稿子：为什么我们放弃了全文检索，改用结构化查询（判断 + 取舍）。",[11,70,71],{},"三篇都讲日志检索，但没有一篇是重复的。同一个功能，三家的读者看完会记住不同的东西。",[15,73,75],{"id":74},"还有一个方向人","还有一个方向：人",[11,77,78],{},"同一个功能由谁来讲，可信度完全不同。客户 CTO 署名和写手署名，读者感受差别很大。",[11,80,81],{},"我们一般让客户方的技术负责人署名，我们做编辑和事实核查。这类内容的转化率，比纯公司署名的稿子高不少。",[15,83,84],{"id":84},"别做的三件事",[11,86,87],{},"第一，别抄竞品的小标题结构。抄结构，内容也会像。",[11,89,90],{},"第二，别写\"我们更懂用户\"这种话。用户不信，搜索引擎也不需要。",[11,92,93],{},"第三，别把所有功能都写一遍。选一个功能，写透，比写十个功能有用。",[15,95,96],{"id":96},"一句判断",[11,98,99],{},"差异化的前提是\"你有别人没有的东西\"。没有独家场景、没有独家数据、没有独家判断，写出来的内容注定同质化。",[11,101,102],{},"先积累素材，再谈差异化。素材不够，宁可少写。",{"title":104,"searchDepth":105,"depth":105,"links":106},"",2,[107,108,109,110,111,112,113,114],{"id":17,"depth":105,"text":17},{"id":26,"depth":105,"text":27},{"id":39,"depth":105,"text":40},{"id":52,"depth":105,"text":53},{"id":62,"depth":105,"text":62},{"id":74,"depth":105,"text":75},{"id":84,"depth":105,"text":84},{"id":96,"depth":105,"text":96},null,"内容运营","2026-10-18","软件公司的内容会同质化，因为大家写的是“功能清单”。差异不在功能，在场景、代价和证据。我们给三个客户写同一个功能，三篇内容角度完全不同。三个差异化方向、示例和别做的事都在这篇，适合内容同质化的团队。",false,"md",{},true,"\u002Fblog\u002Fcontent-differentiation",{"title":5,"description":118},"blog\u002Fcontent-differentiation",[127,128,129],"内容差异化","内容策略","软件内容","e-Ze4pY7FqJLjZ2dXA9YrJEhLC2kmPtbA_J5khdzYb4",{"id":132,"title":133,"author":6,"body":134,"canonical":115,"category":236,"cover":115,"date":237,"description":238,"draft":119,"extension":120,"keywords":115,"meta":239,"navigation":122,"noindex":119,"ogImage":115,"path":240,"seo":241,"seoDescription":115,"seoTitle":115,"stem":242,"tags":243,"updated":115,"__hash__":247},"blog\u002Fblog\u002Fhttp2-migration-pitfalls.md","老站迁到 HTTP\u002F2，先把这四个坑填了",{"type":8,"value":135,"toc":227},[136,139,142,145,148,152,155,158,161,165,168,171,174,178,181,184,187,191,194,197,200,203,206,209,212,215,218,221,224],[11,137,138],{},"2026 年 10 月我们给一个跑了八年的官网做协议升级，配置本身半小时搞定，后面的调整花了两周。协议换了，之前十几年的优化习惯要跟着改。",[15,140,141],{"id":141},"迁移本身很简单",[11,143,144],{},"服务器支持、证书配好、开 ALPN，基本就完事。云服务和 CDN 现在默认都支持 HTTP\u002F2，很多站其实早就开着了，只是没注意。",[11,146,147],{},"怎么确认？看 DevTools 的协议列，显示 h2 就是 HTTP\u002F2。命令行也能看，curl 带 --http2 参数。",[15,149,151],{"id":150},"坑一域名分片失效","坑一：域名分片失效",[11,153,154],{},"HTTP\u002F1.1 时代为了绕过并发限制，把图片、JS、CSS 拆到多个子域名。",[11,156,157],{},"HTTP\u002F2 支持多路复用，一个连接就能并发，分片反而变成负担：每个域名要单独 DNS、单独 TLS，多花几百毫秒。",[11,159,160],{},"我们这次把六个静态域名合成了两个，首屏的连接建立时间少了 400 毫秒。",[15,162,164],{"id":163},"坑二资源合并要重新考虑","坑二：资源合并要重新考虑",[11,166,167],{},"以前把十几个 CSS 合成一个大文件，减少请求数。",[11,169,170],{},"HTTP\u002F2 下请求不贵了，合并反而伤害缓存。改一个组件，整个大文件的缓存全部失效。",[11,172,173],{},"我们的做法是按页面拆分，首屏一份、其余按路由分。改一个页面不影响其他页面的缓存。",[15,175,177],{"id":176},"坑三服务端推送已经被放弃","坑三：服务端推送已经被放弃",[11,179,180],{},"HTTP\u002F2 的服务端推送（Server Push）当年被当成优势，现在主流浏览器已经移除支持。",[11,182,183],{},"还在用 push 的配置要清掉。它不但没收益，还可能造成重复下载，反而更慢。",[11,185,186],{},"替代方案是 preload，浏览器支持稳定，行为可预期。",[15,188,190],{"id":189},"坑四cdn-和中间层不支持","坑四：CDN 和中间层不支持",[11,192,193],{},"源站升级了，CDN 还是 HTTP\u002F1.1，用户端就享受不到。",[11,195,196],{},"还有反向代理、WAF、负载均衡，任何一层不支持，整条链路就退回旧协议。",[11,198,199],{},"迁移前逐层确认，从源站查到边缘节点。查的方式很简单，逐层用 curl 看返回的协议版本。",[15,201,202],{"id":202},"迁移后怎么验证",[11,204,205],{},"看三个数：首屏资源加载完成时间、连接建立时间、总请求数。",[11,207,208],{},"对比迁移前后各测三次。我们这次的改善主要来自连接数减少，首屏时间从 2.4 秒降到 1.9 秒。",[11,210,211],{},"再看真实用户数据。CrUX 里没有协议维度，但 LCP 的变化能反映出来，按地区分组看更明显，网络条件差的地区改善更大。",[11,213,214],{},"还有个细节值得记住：HTTP\u002F2 下单个大文件的下载主要受带宽限制，多路复用省的是排队时间。所以迁移之后该做的是减少总字节，不是继续拆文件。这两件事方向不同，别搞混。",[15,216,217],{"id":217},"一个判断",[11,219,220],{},"HTTP\u002F2 的收益和页面资源数量直接相关。一个只有五个请求的简单页面，迁移前后几乎没差别。",[11,222,223],{},"资源多、第三方多的站收益明显，尤其是以前用域名分片的站。",[11,225,226],{},"升级本身不难，难的是清理旧习惯。这件事没人会主动做，通常要等一次性能审计才会被发现。",{"title":104,"searchDepth":105,"depth":105,"links":228},[229,230,231,232,233,234,235],{"id":141,"depth":105,"text":141},{"id":150,"depth":105,"text":151},{"id":163,"depth":105,"text":164},{"id":176,"depth":105,"text":177},{"id":189,"depth":105,"text":190},{"id":202,"depth":105,"text":202},{"id":217,"depth":105,"text":217},"技术SEO","2026-10-17","协议升级本身不难，难的是升级之后旧的优化手法全部失效。这篇写域名分片、资源合并、服务端推送和 CDN 兼容四个坑，以及迁移后的验证方法。",{},"\u002Fblog\u002Fhttp2-migration-pitfalls",{"title":133,"description":238},"blog\u002Fhttp2-migration-pitfalls",[244,245,246],"HTTP2","协议升级","页面体验","JJszBGJyjINUoTMIZY_rAAYun_QNdsj5k1cq5z99cqY",{"id":249,"title":250,"author":6,"body":251,"canonical":115,"category":345,"cover":115,"date":346,"description":347,"draft":119,"extension":120,"keywords":115,"meta":348,"navigation":122,"noindex":119,"ogImage":115,"path":349,"seo":350,"seoDescription":115,"seoTitle":115,"stem":351,"tags":352,"updated":115,"__hash__":356},"blog\u002Fblog\u002Fzero-volume-longtail.md","零搜索量的长尾词值得写吗，我们只写三类",{"type":8,"value":252,"toc":334},[253,256,259,262,265,269,272,275,279,282,285,289,292,295,298,301,304,307,310,313,316,319,322,325,328,331],[11,254,255],{},"工具显示月搜 0 的词，我们站有 15% 的访问来自它们。但零量词不是都值得写，我们只写三类：报错原文、组合场景、新版本新工具。其余的不写，写了也是自娱自乐。",[15,257,258],{"id":258},"为什么会有零搜索量",[11,260,261],{},"三种情况。工具样本不足，软件行业的小词普遍被低估。词太新，工具还没来得及收。词是组合出来的，用户会这么搜，但没人统计过。",[11,263,264],{},"这三种情况里，第一种和第二种是真机会，第三种要验证。",[15,266,268],{"id":267},"第一类报错原文","第一类：报错原文",[11,270,271],{},"用户遇到报错，第一反应是把报错抄进搜索框。这类词的搜索量在工具里几乎是 0，但意图极强。",[11,273,274],{},"2026 年 7 月我们给一个客户写了一篇“某个 SDK 版本升级后连接超时”，工具显示 0，两个月带来 40 多个访问，其中 3 个直接转化成了工单。",[15,276,278],{"id":277},"第二类组合场景","第二类：组合场景",[11,280,281],{},"行业加角色加流程组合出来的词，工具一般收不到。但在具体场景里，用户就是这么搜的。",[11,283,284],{},"判断方法：把这个词丢进搜索框，看下拉和相关搜索有没有相关提示。有人搜过，就会有痕迹。",[15,286,288],{"id":287},"第三类新版本新工具","第三类：新版本、新工具",[11,290,291],{},"产品刚发布的版本号、刚上线的功能名、刚流行的工具名。这类词在发布后一到两个月会有一波搜索。",[11,293,294],{},"先写先占。等工具显示有量的时候，前十已经排满了。",[15,296,297],{"id":297},"不值得写的三类",[11,299,300],{},"纯概念组合，比如“日志管理的价值”，没人会这么搜。地域词，除非你有本地业务。别人的品牌词，抢不到还容易被投诉。",[15,302,303],{"id":303},"怎么验证",[11,305,306],{},"两个免费信号：搜索后台有没有曝光，搜索结果页有没有人认真做内容。有曝光说明有需求，有人做说明有价值。",[11,308,309],{},"两个都没有，先别写。",[15,311,312],{"id":312},"一个比例",[15,314,315],{"id":315},"怎么写零量词的页面",[11,317,318],{},"按问题写，不按关键词写。标题就是用户的问题原句，正文第一段给答案，后面写清前提。",[11,320,321],{},"这类页面通常会进文档区或 FAQ，不进博客主列表。放错位置，读者也找不到。",[15,323,324],{"id":324},"一个反常识的观察",[11,326,327],{},"零量词的页面，外链反而更容易拿。因为没人写过，第一个写的人会被引用。",[11,329,330],{},"我们有一篇讲某个报错的页面，被两个开源项目的 issue 引用，带来了稳定的访问。",[11,332,333],{},"我们内容排期里，零量词占 20% 左右。比例再高，就有自娱自乐的风险，因为零量词的转化路径通常更长。",{"title":104,"searchDepth":105,"depth":105,"links":335},[336,337,338,339,340,341,342,343,344],{"id":258,"depth":105,"text":258},{"id":267,"depth":105,"text":268},{"id":277,"depth":105,"text":278},{"id":287,"depth":105,"text":288},{"id":297,"depth":105,"text":297},{"id":303,"depth":105,"text":303},{"id":312,"depth":105,"text":312},{"id":315,"depth":105,"text":315},{"id":324,"depth":105,"text":324},"SEO","2026-10-19","工具显示月搜 0 的词，我们站有 15% 的访问来自它们。但只写三类：报错原文、组合场景、新版本新工具。其余零量词，写了也是自娱自乐。",{},"\u002Fblog\u002Fzero-volume-longtail",{"title":250,"description":347},"blog\u002Fzero-volume-longtail",[353,354,355],"长尾词","关键词研究","内容选题","5gR7mFB3BoPr-RpN9Weam8EHIYYla8nm4LugVyO44j0",1794088100669]