[{"data":1,"prerenderedAt":326},["ShallowReactive",2],{"blog-technical-author-credentials":3,"blog-prev-technical-author-credentials":76,"blog-next-technical-author-credentials":249},{"id":4,"title":5,"author":6,"body":7,"canonical":60,"category":61,"cover":60,"date":62,"description":63,"draft":64,"extension":65,"keywords":60,"meta":66,"navigation":67,"noindex":64,"ogImage":60,"path":68,"seo":69,"seoDescription":60,"seoTitle":60,"stem":70,"tags":71,"updated":60,"__hash__":75},"blog\u002Fblog\u002Ftechnical-author-credentials.md","技术作者的履历怎么写：证书、项目、可查痕迹","元析智能",{"type":8,"value":9,"toc":53},"minimark",[10,14,19,22,25,29,32,35,38,41,44,47,50],[11,12,13],"p",{},"技术作者的履历不用写长，但每一句都得能被查。我们审过 30 多个软件站的作者页，能真正查证的履历不到一半，大多数写的是\"多年互联网经验\"\"熟悉分布式架构\"这类谁也验证不了的话。",[15,16,18],"h2",{"id":17},"证书列三个以内带编号","证书：列三个以内，带编号",[11,20,21],{},"证书对技术读者有信号价值，前提是具体。写法是机构加年份，比如\"2023 年通过 CKA 认证\"\"2022 年 AWS 解决方案架构师\"。有编号的可以放编号，没有编号就别硬凑。",[11,23,24],{},"列三个以内。一堆证书堆上去，反而像培训机构的广告。如果作者没有证书，不如空着，用项目经历补，别硬编。",[15,26,28],{"id":27},"项目经历写到你改了什么这一层","项目经历：写到\"你改了什么\"这一层",[11,30,31],{},"这是最容易写虚的地方。\"参与过大型电商系统的架构设计\"没有信息量，读者不知道你做了什么。改成\"把订单系统的 P99 从 800 毫秒降到 220 毫秒，主要动作是把两处同步调用改成异步\"，信息量立刻不一样。",[11,33,34],{},"要有数字，也要有动作。数字说明结果，动作说明你真的在现场。写不出动作的项目，多半不是你亲手做的，这种就别写进履历。",[11,36,37],{},"2025 年 8 月我们改过一个客户的技术作者页，把原来那三段\"熟悉\u002F精通\"式的描述全删了，换成三个具体项目，每个项目写清楚问题、动作、结果。改完之后，这个作者的文章在站内的停留时间从 50 秒涨到 1 分 40 秒。数据不是立刻涨的，是两个月后慢慢起来的。",[15,39,40],{"id":40},"可查痕迹放哪几个平台",[11,42,43],{},"优先级从高到低：GitHub、技术社区主页（知乎、掘金、V2EX）、公开演讲或会议页面、开源项目贡献记录、专利和论文。",[11,45,46],{},"GitHub 对开发者工具类公司最重要，因为代码和 issue 记录做不了假。技术社区主页次之，看的是持续输出。演讲和会议页面适合有行业积累的作者，能直接证明\"这个人在圈子里\"。",[11,48,49],{},"这些链接要双向：作者页指向账号，账号资料里也写清楚在哪家公司、负责什么。单向的链接说服力弱一半。",[11,51,52],{},"履历这件事，被验证一次就建立了信任，被拆穿一次就全废了。宁短勿虚。",{"title":54,"searchDepth":55,"depth":55,"links":56},"",2,[57,58,59],{"id":17,"depth":55,"text":18},{"id":27,"depth":55,"text":28},{"id":40,"depth":55,"text":40},null,"内容运营","2026-02-11","技术博客的作者页最怕写成简历。这篇讲三样东西怎么写才可验证：证书列几个、项目经历写到什么颗粒度、公开痕迹放哪几个平台，附一个改坏了的反面例子。",false,"md",{},true,"\u002Fblog\u002Ftechnical-author-credentials",{"title":5,"description":63},"blog\u002Ftechnical-author-credentials",[72,73,74],"作者信号","技术写作","E-E-A-T","7oQuNYoIEElrRCfxLs86SRl1mf5aXNJJiP0LRgAeWCs",{"id":77,"title":78,"author":6,"body":79,"canonical":60,"category":237,"cover":60,"date":238,"description":239,"draft":64,"extension":65,"keywords":60,"meta":240,"navigation":67,"noindex":64,"ogImage":60,"path":241,"seo":242,"seoDescription":60,"seoTitle":60,"stem":243,"tags":244,"updated":60,"__hash__":248},"blog\u002Fblog\u002Fcustomer-ticket-query-mining.md","从客服工单里挖 AI 查询：1400 条工单找出 96 个问法",{"type":8,"value":80,"toc":229},[81,84,87,90,93,96,99,106,112,118,121,125,192,195,199,202,205,208,211,214,217,220,223,226],[11,82,83],{},"最好的 AI 查询库不在关键词工具里，在客服工单里。2026 年 2 月我们翻了三个客户共 1400 条工单，挖出 96 个用户原话问法，其中 41 个在 AI 搜索里已经有现成回答，但回答里没有他们。",[15,85,86],{"id":86},"为什么工单比关键词工具准",[11,88,89],{},"关键词工具给的是\"别人搜过什么\"，带的是搜索框的痕迹——短、缺主语、被工具归并过。",[11,91,92],{},"工单给的是\"别人卡在哪\"。用户写工单时会把背景、环境、已经试过什么全写出来。这种句子拿去问 AI，得到的回答质量最高，因为信息完整。",[11,94,95],{},"我们对比过：同一个主题，关键词工具给出的月搜索量 2400，工单里对应的问题 37 条。37 条里的问法，没有一条能靠 SEO 关键词工具拿到。",[15,97,98],{"id":98},"三条筛选条件",[11,100,101,105],{},[102,103,104],"strong",{},"一、含疑问词。"," 怎么、能不能、为什么、是不是、有没有。陈述句多是需求和抱怨，问句才是查询。",[11,107,108,111],{},[102,109,110],{},"二、解决时长超过一天。"," 一天内解决的，说明文档已经答了，或者问题太个案。超过一天的，多半是文档没写清。",[11,113,114,117],{},[102,115,116],{},"三、重复出现。"," 同一个问题被 3 个以上客户问过，就是公共问题，值得写成内容。只出现一次的，写出来也没人搜。",[11,119,120],{},"1400 条过完，剩 96 条。",[15,122,124],{"id":123},"_96-个的分布","96 个的分布",[126,127,128,144],"table",{},[129,130,131],"thead",{},[132,133,134,138,141],"tr",{},[135,136,137],"th",{},"类型",[135,139,140],{},"数量",[135,142,143],{},"典型问法",[145,146,147,159,170,181],"tbody",{},[132,148,149,153,156],{},[150,151,152],"td",{},"配置类",[150,154,155],{},"38",[150,157,158],{},"怎么把同步任务设成增量",[132,160,161,164,167],{},[150,162,163],{},"报错类",[150,165,166],{},"27",[150,168,169],{},"报错 1045 是什么原因",[132,171,172,175,178],{},[150,173,174],{},"对比类",[150,176,177],{},"18",[150,179,180],{},"你们和 XX 有什么区别",[132,182,183,186,189],{},[150,184,185],{},"计费类",[150,187,188],{},"13",[150,190,191],{},"只跑一次任务怎么算钱",[11,193,194],{},"配置和报错占了三分之二，这跟工单的性质有关：能自己解决的不会来问。也说明这块最缺内容。",[15,196,198],{"id":197},"_41-个缺口长什么样","41 个缺口长什么样",[11,200,201],{},"我们把 96 个问法逐条拿去问 4 个引擎，看它答什么、引谁。",[11,203,204],{},"41 个已经有了像样的回答，但回答里的来源全是第三方：技术博客、论坛、竞品的文档。这 41 个最好办，因为问题已经被验证有答案，你只要写一个更好的，就有机会被替换进去。",[11,206,207],{},"剩下 55 个没有像样回答，AI 只能给一堆模糊的通用步骤。这类是首发机会，但风险是不确定有没有人搜。",[11,209,210],{},"我们的建议是先做前 41 个，做完再判断后 55 个。",[15,212,213],{"id":213},"一个副产物",[11,215,216],{},"翻工单还发现一件事：客服的问题分类错误率不低。1400 条里，有 200 多条被标错了类别，\"配置\"标签下混着计费问题。原因是客服赶时间，随手选。",[11,218,219],{},"这个错误率会直接影响客服的响应速度，也会让你以为某类问题少，其实是没被归类。顺手改标签规则比写内容收益更快。",[15,221,222],{"id":222},"谁该做这件事",[11,224,225],{},"内容团队自己翻工单，效率很低，因为看不懂技术细节。正确的做法是内容的人跟客服开一次两小时的会，让客服挑出 30 条\"最烦的问题\"，内容的人当场判断能不能写。",[11,227,228],{},"两小时能定下一个季度的选题。这比开选题会靠猜准得多。",{"title":54,"searchDepth":55,"depth":55,"links":230},[231,232,233,234,235,236],{"id":86,"depth":55,"text":86},{"id":98,"depth":55,"text":98},{"id":123,"depth":55,"text":124},{"id":197,"depth":55,"text":198},{"id":213,"depth":55,"text":213},{"id":222,"depth":55,"text":222},"GEO","2026-02-10","最好的查询库不在关键词工具里，在客服工单里。翻 1400 条工单挖出 96 个真实问法，41 个在 AI 搜索里已有回答但没我们的份。筛选条件只有三条。",{},"\u002Fblog\u002Fcustomer-ticket-query-mining",{"title":78,"description":239},"blog\u002Fcustomer-ticket-query-mining",[245,246,247,61],"工单","选题","AI查询","_uT9HLZ-bKCMcOTVBUDRBGDtRW3Sqpd7ZPFtvdC54ls",{"id":250,"title":251,"author":6,"body":252,"canonical":60,"category":237,"cover":60,"date":316,"description":317,"draft":64,"extension":65,"keywords":60,"meta":318,"navigation":67,"noindex":64,"ogImage":60,"path":319,"seo":320,"seoDescription":60,"seoTitle":60,"stem":321,"tags":322,"updated":60,"__hash__":325},"blog\u002Fblog\u002Fai-agent-docs-geo.md","AI 产品文档怎么写，才会被别的 AI 引用",{"type":8,"value":253,"toc":310},[254,257,261,264,267,271,274,277,281,284,287,292,295,298,301,304,307],[11,255,256],{},"AI 产品的文档，读者不止是人，还有别的 AI。2025 年 10 月到 2026 年 2 月，我们给一个 agent 编排平台做文档改造，重点是让它更容易被回答引擎引用，四个月里被引用的次数从每周 3 次左右到 15 次以上。",[15,258,260],{"id":259},"位置一定义段","位置一：定义段",[11,262,263],{},"每个核心概念第一段必须是一句可独立引用的话。比如“工具调用（tool call）指模型在生成过程中调用外部函数并读取返回值的过程”。这句话脱离上下文也成立，AI 引用时不会失真。",[11,265,266],{},"很多文档的开头是“在本节中我们将介绍……”，这种句子对 AI 没有任何价值。我们删了客户文档里 30 多处这种过渡句。",[15,268,270],{"id":269},"位置二能力边界","位置二：能力边界",[11,272,273],{},"AI 引用你的产品时，最常回答的问题是“XX 能做什么、不能做什么”。所以文档里要有一节明确写边界：支持哪些模型、上下文上限多少、并发限制、哪些场景不适用。",[11,275,276],{},"我们把这个部分做成表格，每行一个维度，给具体数字。这张表被引用的频率最高，因为它能被直接拆成答案。我们每季度核对一次数字，别让过期的上限被引用出去。",[15,278,280],{"id":279},"位置三错误与失败模式","位置三：错误与失败模式",[11,282,283],{},"AI 产品一定会失败，文档写清失败模式反而加分。“工具调用超时怎么处理”“模型返回格式不合法怎么办”“上下文超长时丢哪部分”，这三类问答几乎每个用户都会问，也是 AI 最容易被问到的。",[11,285,286],{},"写法是问答体：问题一句话，答案三句以内给结论，再展开。",[11,288,289],{},[102,290,291],{},"位置四：对比和替代",[11,293,294],{},"文档里加一节“和其他方案的区别”。注意是区别，不是贬低。写清适用场景的边界，比如“如果你只需要简单的链式调用，用脚本就行，不需要这个平台”。",[11,296,297],{},"这一节在 AI 回答里出现率高得惊人。用户问“XX 和 YY 哪个好”，AI 需要的是中立的差异描述，不是广告。",[15,299,300],{"id":300},"一个判断标准",[11,302,303],{},"写完一段文档，问自己：这段话能不能被单独摘出来，作为某个问题的答案？能，就达标；不能，就是给人看的上下文，AI 用不上。",[11,305,306],{},"还有一件事要排进流程：能力边界那节挂进发版检查清单，版本上线必须同步改。AI 产品迭代快，被引用出去的旧数字比没被引用更麻烦。",[11,308,309],{},"这件事的收益不在点击，在曝光。被 AI 提到 100 次，可能只带来 5 次访问，但那 5 次是带着信任来的。我们追踪过一个客户，从 AI 引用进入的访客，试用转化率是自然搜索的 2.3 倍。",{"title":54,"searchDepth":55,"depth":55,"links":311},[312,313,314,315],{"id":259,"depth":55,"text":260},{"id":269,"depth":55,"text":270},{"id":279,"depth":55,"text":280},{"id":300,"depth":55,"text":300},"2026-02-12","做 AI 工具的都希望被回答引擎推荐，但文档写成营销腔就没人引用。我们改了定义段、能力边界、失败模式、对比四类内容，一个 agent 平台被引用的次数翻了 5 倍。",{},"\u002Fblog\u002Fai-agent-docs-geo",{"title":251,"description":317},"blog\u002Fai-agent-docs-geo",[237,323,324],"AI 产品","文档写作","QDcm5pO48_8payqlI044h0SroPAi4HbDXdEJYGhBYHU",1794088108469]