[{"data":1,"prerenderedAt":372},["ShallowReactive",2],{"blog-information-gain-paragraph":3,"blog-prev-information-gain-paragraph":96,"blog-next-information-gain-paragraph":190},{"id":4,"title":5,"author":6,"body":7,"canonical":80,"category":81,"cover":80,"date":82,"description":83,"draft":84,"extension":85,"keywords":80,"meta":86,"navigation":87,"noindex":84,"ogImage":80,"path":88,"seo":89,"seoDescription":80,"seoTitle":80,"stem":90,"tags":91,"updated":80,"__hash__":95},"blog\u002Fblog\u002Finformation-gain-paragraph.md","信息增益不是玄学，它落在一段具体的话里","元析智能",{"type":8,"value":9,"toc":70},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,64,67],[11,12,13],"p",{},"信息增益不是把文章写得更长，也不是多塞几个小节。它落在一段具体的话里：有一句话，同行写不出来，只有你能写。我判断一篇稿子能不能发，就看这一句在不在。",[15,16,17],"h2",{"id":17},"什么叫只有你能写的一句话",[11,19,20],{},"举个我们自己的例子。“我们在 8 核 16G 的机器上压过这个接口网关，QPS 到 1200 时，P99 延迟从 38 毫秒跳到 240 毫秒。”这句话同行写不出来，因为他没测过，也没必要测。",[11,22,23],{},"再比如“客户花了 11 万买这套系统，第三年续费时砍掉了 40% 的模块”。这种数字只有做过交付的人说得出。",[15,25,26],{"id":26},"四种能造出增益的原料",[11,28,29],{},"第一种是实测数据，自己跑出来的性能、耗时、排名、流量。第二种是客户现场细节，他们怎么用、卡在哪、内部谁反对。第三种是成本，报价区间、实施周期、人力投入。第四种是失败记录，什么方案没成，为什么。",[11,31,32],{},"这四样都不需要什么资源，只需要你在一线待过。写不出来往往是因为离业务太远，不是因为文笔。",[15,34,35],{"id":35},"我们毙过的一篇稿",[11,37,38],{},"2025 年 4 月，一篇 3200 字的“XX 选型指南”，结构清楚、小标题工整、配了图。审下来我毙了，因为里面每一句话都能在另外三篇文章里找到，没有一句是我们独有的。",[11,40,41],{},"那篇稿子改了两轮还是不行，最后换题重写。换成“我们给 6 家客户做选型时，报价差在哪四块”，两天就写完了，阅读量和咨询量都是原来那篇的三倍。",[15,43,44],{"id":44},"写作时怎么保住这句话",[11,46,47],{},"初稿第一件事就是把这句独有信息写出来，放在开头第二段，不要埋到文末。埋到文末的独家内容，读者看不到，AI 摘录时也不一定能摘到。",[11,49,50],{},"然后围绕它搭结构：这句话讲的是哪个结论，前面补背景，后面补怎么得到的、什么条件下成立。",[15,52,53],{"id":53},"一篇文章的标准",[11,55,56],{},"我们现在的标准是至少两处独有信息：一处是数据，一处是判断。只有数据没有判断，是调研报告；只有判断没有数据，是个人意见。",[11,58,59],{},"两处都凑不齐，说明这个题我们不该写。写不出来就换题，换题比硬写便宜得多。",[15,61,63],{"id":62},"这也解释了-e-e-a-t","这也解释了 E-E-A-T",[11,65,66],{},"E-E-A-T 里的经验和实操，最终都要落成这样的句子。作者署名、作者简介、更新时间只是外壳，外壳里没有这种话，搜索引擎和 AI 都看得出来。",[11,68,69],{},"我见过太多页面把作者简介写得很漂亮，正文全是转述。这种东西写一百篇，不如一篇带实测数据的。",{"title":71,"searchDepth":72,"depth":72,"links":73},"",2,[74,75,76,77,78,79],{"id":17,"depth":72,"text":17},{"id":26,"depth":72,"text":26},{"id":35,"depth":72,"text":35},{"id":44,"depth":72,"text":44},{"id":53,"depth":72,"text":53},{"id":62,"depth":72,"text":63},null,"SEO","2025-11-10","判断一篇稿子能不能发，我只看有没有一句话是同行写不出来的。实测数据、客户现场、成本和失败记录是四种能造出增益的原料，凑不齐就别写，换题比硬写便宜。",false,"md",{},true,"\u002Fblog\u002Finformation-gain-paragraph",{"title":5,"description":83},"blog\u002Finformation-gain-paragraph",[92,93,94],"信息增益","内容质量","选题判断","DlQ7Lc2zyKf2vCQItaKdtferfzdxF44z7Rk1Sb8xsbs",{"id":97,"title":98,"author":6,"body":99,"canonical":80,"category":178,"cover":80,"date":179,"description":180,"draft":84,"extension":85,"keywords":80,"meta":181,"navigation":87,"noindex":84,"ogImage":80,"path":182,"seo":183,"seoDescription":80,"seoTitle":80,"stem":184,"tags":185,"updated":80,"__hash__":189},"blog\u002Fblog\u002Fcls-real-causes.md","CLS 高不一定是图片没尺寸，我们查到的四类真凶",{"type":8,"value":100,"toc":169},[101,104,107,110,113,116,119,122,125,128,131,134,138,141,145,148,151,154,157,160,163,166],[11,102,103],{},"CLS 高，很多人第一反应是图片没写宽高。这个原因确实存在，但在我们今年查的 14 个软件站里，它不是主因：CLS 超过 0.25 的 5 个站，有 4 个的真凶是字体切换和动态插入的组件。图片没尺寸只占 1 个，而且那个站的 CLS 只有 0.18。",[11,105,106],{},"先把概念说清楚。CLS 是 Cumulative Layout Shift，衡量页面元素在加载过程中意外移动的幅度，0.1 以下算好，0.25 以上算差。注意\"意外\"两个字：用户点击后展开的内容不算，只有没人操作时自己跳的才计分。",[15,108,109],{"id":109},"字体切换导致的位移",[11,111,112],{},"中文站高发。回退字体和自定义字体的字宽不一样，字体一到位，整段文字重新换行，下面的内容全部移动。这种位移往往发生在首屏正文，分值很高。",[11,114,115],{},"一个做低代码平台的公司，CLS 0.29。移动端 h1 加两行副标题，字体到位后标题从两行变三行，下面按钮下移 48 像素。改法是把字体子集化和预加载做好，再用 size-adjust 校准回退字体的字宽，字号和行高都写死。",[15,117,118],{"id":118},"动态插入的组件",[11,120,121],{},"AB 测试、营销横幅、cookie 提示，这些组件在 JS 执行后往 DOM 里插东西，插在页面顶部就整页下移。",[11,123,124],{},"一个数据工具站的 CLS 是 0.31，查下来是 AB 测试脚本给导航条多加了一个\"免费试用\"按钮，导航从一行变两行，整页下移 64 像素。这种位移最隐蔽，因为产品经理认为那只是换了个版本。",[15,126,127],{"id":127},"懒加载内容的位置",[11,129,130],{},"用户往下读，上面的图片才开始加载，加载完撑开高度，把正在读的段落顶走。这种位移最招人烦，因为它发生在阅读过程中，而不是页面刚打开的时候。",[11,132,133],{},"改法是给懒加载的图片和广告位预留高度，或者用 content-visibility 配合 intrinsic size。",[15,135,137],{"id":136},"图片和-iframe-没尺寸","图片和 iframe 没尺寸",[11,139,140],{},"这个原因还在，主要是 iframe 和嵌入视频。img 现在大部分框架会带 width\u002Fheight，但第三方 iframe（地图、演示视频、客服）经常没有。",[15,142,144],{"id":143},"第五类单页应用的路由切换","第五类：单页应用的路由切换",[11,146,147],{},"这一点常被忽略。SPA 切换路由时，如果新页面先渲染一个空容器再填内容，或者旧页面在数据回来前先清空，中间会有一段时间页面高度不对，浏览器就记一次位移。文档站、控制台这类站高发。",[11,149,150],{},"查法是录一段站内跳转的 Performance，看路由切换后有没有连续两次布局变化。改法是用路由级的骨架屏，并且保证骨架和真实内容高度一致。",[15,152,153],{"id":153},"为什么中文站更容易中招",[11,155,156],{},"三条原因叠在一起：中文字体文件大、回退字体和自定义字体的字宽差异明显、正文行数多。同样一处字体切换，英文站位移 20 像素，中文站可能整段重排、位移 100 像素以上。",[11,158,159],{},"我们给中文站排优先级时，字体相关的位移永远排第一。先把字体加载路径修好，再去看图片和组件，顺序反过来会白干。",[15,161,162],{"id":162},"查法",[11,164,165],{},"Lighthouse 的 CLS 归因会给到具体元素，Chrome Performance 面板的 Experience 轨道能录到每一次位移和它的来源，真实用户数据那边用 web-vitals 库能拿到 largest shift 的元素。",[11,167,168],{},"我们一般先修移动端，因为移动端 CLS 通常是桌面端的两倍。修的顺序按\"移动端面积最大的一次位移\"来，不要按 Lighthouse 列出的顺序，前者是用户真正看到的，后者只是权重排序。",{"title":71,"searchDepth":72,"depth":72,"links":170},[171,172,173,174,175,176,177],{"id":109,"depth":72,"text":109},{"id":118,"depth":72,"text":118},{"id":127,"depth":72,"text":127},{"id":136,"depth":72,"text":137},{"id":143,"depth":72,"text":144},{"id":153,"depth":72,"text":153},{"id":162,"depth":72,"text":162},"技术SEO","2025-11-09","今年查的 14 个软件站里，CLS 超 0.25 的 5 个有 4 个主因是字体切换和动态组件，图片没尺寸只占 1 个。四类真凶按实际占比排序，附上每类的查法。",{},"\u002Fblog\u002Fcls-real-causes",{"title":98,"description":180},"blog\u002Fcls-real-causes",[186,187,188],"CLS","布局偏移","前端性能","5KIVOlLHlXCt8Pe7xtOlTgVHSUszsTJiPyIRnyvE6UQ",{"id":191,"title":192,"author":6,"body":193,"canonical":80,"category":178,"cover":80,"date":361,"description":362,"draft":84,"extension":85,"keywords":80,"meta":363,"navigation":87,"noindex":84,"ogImage":80,"path":364,"seo":365,"seoDescription":80,"seoTitle":80,"stem":366,"tags":367,"updated":80,"__hash__":371},"blog\u002Fblog\u002Fllms-txt-three-month-test.md","llms.txt 上线三个月实测：四个站零抓取，AI 爬虫压根不读它",{"type":8,"value":194,"toc":353},[195,198,201,204,207,210,213,216,219,299,302,305,308,311,314,317,320,323,326,329,332,335,338,341,344,347,350],[11,196,197],{},"llms.txt 现在写了不亏，但别指望它。2025 年 9 月我们给四个客户站在根目录加了 llms.txt，到 12 月 10 日拉日志统计：三个站 0 次请求，一个站 2 次，来自某个小团队做的 RAG 工具。同期 GPTBot 抓了 1.1 万次。",[15,199,200],{"id":200},"这东西本来想解决什么",[11,202,203],{},"llms.txt 是 2024 年 9 月由 Jeremy Howard 提的一个约定：在根目录放一个 Markdown 文件，告诉大模型这个站有哪些重要页面、每页讲什么、哪些内容可以拿来训练。",[11,205,206],{},"它解决的是真问题。大模型抓网页要洗 HTML、去导航、去广告，成本高还容易抓错。给一份干净的目录，理论上对双方都好。",[11,208,209],{},"问题是：这是社区约定，不是标准。没有任何一家大厂承诺会读。",[15,211,212],{"id":212},"我们的实测数据",[11,214,215],{},"四个站，三个是 B2B 软件官网，一个是开发者工具文档站。nginx 日志按天切，统计 user-agent 和 URL 路径。",[11,217,218],{},"三个月的结果：",[220,221,222,241],"table",{},[223,224,225],"thead",{},[226,227,228,232,235,238],"tr",{},[229,230,231],"th",{},"站点",[229,233,234],{},"llms.txt 请求",[229,236,237],{},"GPTBot 请求",[229,239,240],{},"其他 AI 爬虫",[242,243,244,259,273,286],"tbody",{},[226,245,246,250,253,256],{},[247,248,249],"td",{},"A（文档站）",[247,251,252],{},"2",[247,254,255],{},"4100",[247,257,258],{},"6300",[226,260,261,264,267,270],{},[247,262,263],{},"B",[247,265,266],{},"0",[247,268,269],{},"3100",[247,271,272],{},"4900",[226,274,275,278,280,283],{},[247,276,277],{},"C",[247,279,266],{},[247,281,282],{},"2400",[247,284,285],{},"3800",[226,287,288,291,293,296],{},[247,289,290],{},"D",[247,292,266],{},[247,294,295],{},"1500",[247,297,298],{},"2100",[11,300,301],{},"那 2 次请求来自一个小众的 RAG 检索工具，user-agent 里带了个私人项目名。跟主流 AI 搜索没关系。",[15,303,304],{"id":304},"为什么主流爬虫不来",[11,306,307],{},"三个原因，按重要性排。",[11,309,310],{},"第一，抓取流程没变。ChatGPT 搜索和 Perplexity 都是实时抓页面、实时切块，没有\"先读目录再去抓\"这一步。目录对它们没有用武之地。",[11,312,313],{},"第二，多一个请求就多一次失败风险。目录里的 URL 失效了怎么办？谁保证它和实际页面一致？大厂不愿意为一份没人维护的文件增加不确定性。",[11,315,316],{},"第三，Google 方面公开表过态，搜索侧不打算采信 llms.txt。这话不能代表所有引擎，但足够说明头部玩家的态度。",[15,318,319],{"id":319},"那还写不写",[11,321,322],{},"写。40 分钟的事，成本够低。",[11,324,325],{},"我的用法不是\"喂给 AI\"，是当站点地图的另一种形态：把最重要的 20 到 50 个页面按主题分组，每行一句说明。这份清单本身对内容团队有用，新人接手第一个月就靠它了解站里有什么。",[11,327,328],{},"另外，如果哪天真有引擎开始读，你已经在里面了。这种低成本的可选项，不做是懒惰，全押是赌博。",[15,330,331],{"id":331},"一个反常识的细节",[11,333,334],{},"我们顺手做了个对照：把 llms.txt 里的页面清单和实际抓取日志比对，重合度只有 31%。也就是说，就算按我们自己的清单，AI 爬虫抓的也主要是清单外的东西——它们更看重内链结构和页面本身的可读性。",[11,336,337],{},"这说明\"给 AI 一份目录\"的思路，和引擎实际的工作方式有偏差。引擎不是按目录找页面，是按链接和新鲜度找页面，然后按块摘内容。",[15,339,340],{"id":340},"比它更值得做的三件事",[11,342,343],{},"一是把重要页面的 HTML 洗干净。导航、页脚、推荐位这些重复内容，占了页面文本的一半以上。AI 抓走之后，主题信号被稀释。",[11,345,346],{},"二是给关键页面加更新时间，并真的更新它。",[11,348,349],{},"三是把文档页做成可独立引用的块。这一条我们测过，效果是 llms.txt 的几十倍。",[11,351,352],{},"一句话：llms.txt 是顺手写的，不是主线。",{"title":71,"searchDepth":72,"depth":72,"links":354},[355,356,357,358,359,360],{"id":200,"depth":72,"text":200},{"id":212,"depth":72,"text":212},{"id":304,"depth":72,"text":304},{"id":319,"depth":72,"text":319},{"id":331,"depth":72,"text":331},{"id":340,"depth":72,"text":340},"2025-11-11","2025 年 9 月给四个客户站加了 llms.txt，三个月 nginx 日志里 0 次请求。这个文件现在写了也没坏处，但把它当 GEO 主线的人会失望。",{},"\u002Fblog\u002Fllms-txt-three-month-test",{"title":192,"description":362},"blog\u002Fllms-txt-three-month-test",[368,369,370,178],"llms.txt","AI爬虫","GEO","fY7VWTLVy8RRkVWEU1S1F1WDnrBgHylQ1gfh0QaVI40",1794088110955]