[{"data":1,"prerenderedAt":332},["ShallowReactive",2],{"blog-case-study-numbers-authorization":3,"blog-prev-case-study-numbers-authorization":126,"blog-next-case-study-numbers-authorization":243},{"id":4,"title":5,"author":6,"body":7,"canonical":110,"category":111,"cover":110,"date":112,"description":113,"draft":114,"extension":115,"keywords":110,"meta":116,"navigation":117,"noindex":114,"ogImage":110,"path":118,"seo":119,"seoDescription":110,"seoTitle":110,"stem":120,"tags":121,"updated":110,"__hash__":125},"blog\u002Fblog\u002Fcase-study-numbers-authorization.md","客户案例里的数字，哪些能写哪些不能写","元析智能",{"type":8,"value":9,"toc":99},"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,87,90,93,96],[11,12,13],"p",{},"2026 年 8 月我们改了一个客户的案例页，原来写着\"帮助某客户提升 300% 转化\"。问他数据来源，他说是客户自己说的，没有书面授权，也没说是哪个渠道涨的。这种句子写上去，风险比收益大。",[15,16,17],"h2",{"id":17},"三类数字要分开",[11,19,20],{},"第一类是客户自己的业绩，比如营收、转化率、成本下降。这类必须客户书面授权，而且要说清是哪个环节。",[11,22,23],{},"第二类是你产品带来的可测量变化，比如处理时间从 4 小时降到 20 分钟。这类最安全，有后台数据就能证明。",[11,25,26],{},"第三类是行业公开数据，用来做背景，注明来源。",[11,28,29],{},"第一类最容易出问题，因为它通常归因复杂，客户也不一定愿意公开。",[15,31,32],{"id":32},"怎么拿到授权",[11,34,35],{},"签合同时加一条：案例使用需书面确认，包括公司名、logo、数字和引用语。",[11,37,38],{},"实际执行时，把要用的内容整理成一页发给客户确认，让对接人签字。",[11,40,41],{},"有的客户只同意用行业和规模，不用公司名。这也是可以写的，写\"某头部 SaaS 公司\"就行。",[15,43,44],{"id":44},"没有数据怎么写案例",[11,46,47],{},"写过程。客户的原始问题、你们一起做的判断、方案改了几版、上线后哪些环节变了。",[11,49,50],{},"过程比数字更可信，因为它具体。读者能看出你真的参与过。",[11,52,53],{},"再写一句客户的原话，带职位，比如\"他们 CTO 说，最难的不是工具，是把旧流程停掉\"。",[15,55,56],{"id":56},"一个反直觉的结论",[11,58,59],{},"案例页里最有说服力的部分，往往不是结果，是限制条件。",[11,61,62],{},"写清\"这个方案适合什么规模、什么阶段、什么技术栈\"，读者会觉得你没在吹。",[11,64,65],{},"我们改过一个案例，加了\"不适合日活低于一万的团队\"这句，咨询量反而涨了。",[15,67,68],{"id":68},"一个具体的改写",[11,70,71],{},"原来那句\"帮助某客户提升 300% 转化\"，改完之后是：某电商 SaaS 的注册页，把表单从七项减到三项，四周后注册完成率从 11% 升到 14%，数据来自客户后台。",[11,73,74],{},"改完的区别在哪：说清对象、说清动作、说清时间、说清数据来源。",[11,76,77],{},"同一件事，第二种写法可信度高得多，也不容易被追问。",[15,79,80],{"id":80},"一个流程",[11,82,83],{},"我们的案例生产流程是：采访客户半小时、整理初稿、客户确认、法务看一遍、上线。",[11,85,86],{},"全程两周左右。慢，但省掉后面的麻烦。",[15,88,89],{"id":89},"一个态度",[11,91,92],{},"案例页是 B2B 软件最有价值的信任资产之一，也是最容易踩雷的内容。",[11,94,95],{},"写数字之前先问三句：谁的数据、有没有授权、能不能复现。三句都过了再写。",[11,97,98],{},"答不上来的，就写过程。过程不会撒谎，也更容易被记住。",{"title":100,"searchDepth":101,"depth":101,"links":102},"",2,[103,104,105,106,107,108,109],{"id":17,"depth":101,"text":17},{"id":32,"depth":101,"text":32},{"id":44,"depth":101,"text":44},{"id":56,"depth":101,"text":56},{"id":68,"depth":101,"text":68},{"id":80,"depth":101,"text":80},{"id":89,"depth":101,"text":89},null,"内容运营","2026-08-05","案例页最常见的错误是把客户的业绩当自己的功劳。这篇写三类数字的写法、客户授权的流程、没有数据时怎么写案例，以及我们的案例生产流程。",false,"md",{},true,"\u002Fblog\u002Fcase-study-numbers-authorization",{"title":5,"description":113},"blog\u002Fcase-study-numbers-authorization",[122,123,124],"客户案例","信任信号","内容合规","WxFSNQLFMlv1SLamcrwgNxV_3KW9sdHDQbHOQ1iHr0Y",{"id":127,"title":128,"author":6,"body":129,"canonical":110,"category":111,"cover":110,"date":232,"description":233,"draft":114,"extension":115,"keywords":110,"meta":234,"navigation":117,"noindex":114,"ogImage":110,"path":235,"seo":236,"seoDescription":110,"seoTitle":110,"stem":237,"tags":238,"updated":110,"__hash__":242},"blog\u002Fblog\u002Fgeo-fact-check-workflow.md","GEO 内容的审稿流程，我们改成了三道关",{"type":8,"value":130,"toc":223},[131,134,138,141,144,147,151,154,157,160,164,167,170,173,176,179,182,185,188,191,194,197,200,203,206,209,212,214,217,220],[11,132,133],{},"2026 年 8 月我们把 GEO 内容的审稿流程从一道改成三道，单篇周期从一天变成两天。返工多了，但同样的话题，被 AI 引用的比例不一样了。",[15,135,137],{"id":136},"第一道事实卡","第一道：事实卡",[11,139,140],{},"写之前先填一张卡片，五条事实，每条带来源。",[11,142,143],{},"来源只有三种：我们自己的后台数据、公开可查的官方文档、我们做过的测试。三种之外的，一律不写。",[11,145,146],{},"这一步的目的是把\"我记得\"换成\"能指出来\"。很多稿子的问题不是写得不好，是事实本身站不住。",[15,148,150],{"id":149},"第二道可引用段落","第二道：可引用段落",[11,152,153],{},"写完初稿，逐段检查三件事：这一段能不能独立读懂、第一句是不是结论、有没有具体数字或条件。",[11,155,156],{},"AI 引用的是段落，不是整篇文章。一段话如果离开上下文就看不懂，它就很难被摘出来。",[11,158,159],{},"我们的要求是每节至少有一段能单独拿出来回答一个问题。做不到，就把这节拆掉或者合并。",[15,161,163],{"id":162},"第三道上线后引用验证","第三道：上线后引用验证",[11,165,166],{},"上线两周后，拿文章覆盖的问题去问几个 AI 引擎，看有没有引用这篇。",[11,168,169],{},"记录下来：哪个引擎引用、引用了哪一段、上下文有没有被误解。",[11,171,172],{},"这一步不是为了打分，是为了知道哪类写法有用。我们攒了三个月数据，发现带具体数字的段落被引用的概率明显高。",[15,174,175],{"id":175},"角色怎么分",[11,177,178],{},"产品团队提供事实和边界，比如功能支持什么、不支持什么。",[11,180,181],{},"内容团队负责结构和段落，把事实变成能独立成段的回答。",[11,183,184],{},"SEO 或增长团队负责验证和记录，定期查引用情况。",[11,186,187],{},"三个角色各管一段，交接物是那张事实卡。",[15,189,190],{"id":190},"一个失败的做法",[11,192,193],{},"我们试过让写手一次写三千字长文，写完再统一审。",[11,195,196],{},"结果是事实错误集中出现，改起来比重写还慢。而且长文里真正能被引用的段落，往往只占三成。",[11,198,199],{},"现在改成一篇聚焦一个问题，八百到一千二百字，写完先审事实。",[15,201,202],{"id":202},"一个可以量化的验收",[11,204,205],{},"三道关走完，我们看两个数：事实卡上的五条事实，有多少条能在文章里找到对应句子；文章有多少段落能独立回答一个问题。",[11,207,208],{},"前一个数低于四，说明事实没用上。后一个数低于三，说明结构还是散文式的。",[11,210,211],{},"这两个数不需要工具，人工数一遍就行。",[15,213,89],{"id":89},[11,215,216],{},"GEO 不是写作技巧，是内容生产方式的问题。",[11,218,219],{},"同样的作者，同样的题目，加了三道关之后产出变慢，但质量稳定。长期看，稳定比快重要。",[11,221,222],{},"这套流程的成本主要在第一道。事实卡填一次能用很久，后面写同主题的文章可以直接复用。",{"title":100,"searchDepth":101,"depth":101,"links":224},[225,226,227,228,229,230,231],{"id":136,"depth":101,"text":137},{"id":149,"depth":101,"text":150},{"id":162,"depth":101,"text":163},{"id":175,"depth":101,"text":175},{"id":190,"depth":101,"text":190},{"id":202,"depth":101,"text":202},{"id":89,"depth":101,"text":89},"2026-08-04","以前一篇稿子写完就发，现在要过事实卡、可引用段落、上线后引用验证三道。返工多了一倍，但同样的话题，被 AI 引用的比例明显不同，流程可直接照搬。",{},"\u002Fblog\u002Fgeo-fact-check-workflow",{"title":128,"description":233},"blog\u002Fgeo-fact-check-workflow",[239,240,241],"GEO","审稿流程","内容生产","kNeQi_l9XJlfZvTK2lsvd6rLQAwd8kTGlPyjPmY4ESg",{"id":244,"title":245,"author":6,"body":246,"canonical":110,"category":320,"cover":110,"date":321,"description":322,"draft":114,"extension":115,"keywords":110,"meta":323,"navigation":117,"noindex":114,"ogImage":110,"path":324,"seo":325,"seoDescription":110,"seoTitle":110,"stem":326,"tags":327,"updated":110,"__hash__":331},"blog\u002Fblog\u002Fcloud-status-page-seo.md","云服务状态页，也是一块能排名的内容",{"type":8,"value":247,"toc":314},[248,251,254,257,260,263,271,278,281,284,290,293,296,299,302,305,308,311],[11,249,250],{},"云服务的状态页（status page）通常放在独立子域，设成 noindex，理由是“不想让故障信息被搜到”。这个做法在 2026 年已经不合适。2026 年 2 月我们给一个云厂商改状态页结构，故障期间自然访问涨了 5 倍，事后用户留存的反馈也更好。",[15,252,253],{"id":253},"为什么该让状态页被索引",[11,255,256],{},"用户遇到问题时第一反应是搜索。“XX 云 故障”“XX 云 502”“XX 云 控制台 打不开”。如果搜不到你的官方说明，他会去社交平台和论坛看猜测，谣言比故障本身更伤。",[11,258,259],{},"状态页被索引，用户第一眼看到官方口径：影响范围、开始时间、当前进展、预计恢复。这比任何客服话术都有效。",[15,261,262],{"id":262},"怎么改",[11,264,265,266,270],{},"第一，状态页从子域挪到主域的 ",[267,268,269],"code",{},"\u002Fstatus"," 下。子域权重独立，主域能继承，而且用户更容易找到。",[11,272,273,274,277],{},"第二，每次故障生成一个独立通告页，URL 带日期和简短描述，比如 ",[267,275,276],{},"\u002Fstatus\u002F2026-02-11-object-storage-timeout","。不要只在一个页面上滚动更新，那样历史故障无法被单独索引。",[11,279,280],{},"第三，通告页写固定结构：影响范围、时间线（发现、定位、修复、复盘）、根因、改进项。时间线是用户最关心的，一行一个时间点。",[11,282,283],{},"第四，故障结束后补复盘。写清为什么会发生、改了什么。这段内容是信任资产，也是搜索“XX 云 稳定性”时能落到的页面。",[11,285,286],{},[287,288,289],"strong",{},"订阅入口别只给 RSS",[11,291,292],{},"状态页除了给人看，还要给人订阅。邮件和短信订阅是最基本的，我们建议再加一个 Webhook，企业客户可以接进自己的监控系统。这些订阅入口不带来搜索流量，但能减少重复咨询。",[11,294,295],{},"还有个细节：故障结束后，通告页顶部换成“已恢复”，并保留时间线。别把通告删掉，删了下次故障用户又只能猜。",[15,297,298],{"id":298},"一个边界",[11,300,301],{},"状态页可索引，不等于把所有内部细节公开。客户名、内部系统代号、具体攻击手法不能写。我们一般要求法务和安全团队过一遍再发。",[11,303,304],{},"另外，状态页的实时数据（当前是否正常）用 JS 拉取没问题，但历史通告必须是静态 HTML，否则搜索引擎读不到。",[15,306,307],{"id":307},"数据上看到了什么",[11,309,310],{},"还有一件事：状态页要有归档。用户想查上个月那次故障影响到几点，翻不到就来问客服。我们按季度归档过去两年的通告，客服工单少了大概三成。",[11,312,313],{},"改完之后，那个客户在故障期间的自然访问从每天 300 多到 1600 多，其中大部分落在通告页。事后回访显示，看过官方通告的用户，续费意愿比没看到的高。故障本身不可控，但信息透明度可控。",{"title":100,"searchDepth":101,"depth":101,"links":315},[316,317,318,319],{"id":253,"depth":101,"text":253},{"id":262,"depth":101,"text":262},{"id":298,"depth":101,"text":298},{"id":307,"depth":101,"text":307},"技术SEO","2026-08-06","故障通告页看起来和 SEO 无关，但“XX 云 故障”这类词有真实搜索量，搜不到官方口径就会传谣言。我们把状态页改成可索引结构，故障期间自然访问涨了 5 倍。",{},"\u002Fblog\u002Fcloud-status-page-seo",{"title":245,"description":322},"blog\u002Fcloud-status-page-seo",[328,329,330],"云服务","状态页","信任","un35_dTQ5yzj5CvLE2wZiY0sv_Vnb6rM43p0YEe62hQ",1794088103128]