智能体是一种新用户

智能体是一种新用户。

这句话不是科幻预告。它是在改你们的用户画像表。过去表上有：终端用户、管理员、实施、伙伴开发者、偶尔还会写上「售前要给客户演示的人」。现在要加一行：一次只读一块、不欣赏首页、可能从 IDE 侧栏、客服问答框或客户公司内部助手进来的读者。它不点你们精心设计的「从这里开始」，也可能从不滑动到页脚的反馈按钮。它甚至不会抱怨导航难用——它只会在别处拼出一份「看起来像答案」的东西，把锅留给你们的产品。

新用户入场，产品经理通常会开需求会：权限怎么改、埋点怎么加、引导页要不要重做。文档侧却常默认「读者还是人，而且还会从首页逛进来」。于是发布检查单上仍只有：错别字、截图是否糊、导航有没有挂错——没有问：这块事实能不能被机器稳定拿到？拿不到，新用户对你们来说等于不存在；存在的是它从公网常识、过期 PDF、竞品说明里拼来的替代事实。

把这句话写进画像，不是为了讨好潮流词。是为了让发布假设换一套：从「给人逛完」扩到「给一次只读一块的读者也留得出入口」。入口背后，仍是那份你们认账的事实——门可以多，源应一。

行业公开调研里，人们仍大量从导航进文档站；传统搜索也还在。但 AI 搜索、编码助手、以及业界讨论中的 MCP 一类通道，已经从几乎可以忽略，长到没法用「以后再说」打发。有团队把「为 LLM/AI 提供表征」写成一类业务影响面——前一年几乎不在表上的类别，现在已经有可观占比；更值得注意的是，期望与现状的差距并不夸张，说明不少人已视其为高潜力，而不是玩具展台。

比例年年会变。趋势不容易反转：文档站不再是唯一门口，却最好仍是门口背后那一份事实。

国内现场里，新用户不一定叫 Agent，也未必穿着英文缩写出场。它可能是客户公司内部的知识助手，被要求「按我们买的产品写开通步骤」；可能是研发用的编码补全，在 IDE 里问「这个回调超时怎么处理」；可能是客服侧边栏的问答，三秒内要吐出「如何导出报表」。路径不同，胃口类似：要现行、要可检索、最好自包含。你们若只优化给人逛的目录与首屏插画，等于在新渠道上自愿缺席——缺席的代价很少立刻出现在文档站的 PV 里，却会出现在错误实施、错误报价和错误集成里。

发现侧还可以用答案引擎优化与GEO这类问法自检：前者关心答案引擎能否稳定引用你们的事实，后者关心生成式入口里你们是否还以正确形态出现。问法可以超前，交付仍从结构与已发布块开始——先有可被拿到的页，再谈被引用、被摘要、被写进别人的工作流。

MCP 等通道是行业问句，也是投入计划里跳得很快的项。Baklib 主路径上，先把已发布结构与稳定 URL 立住；不把「开箱即是 Agent 网关」写成今天的交付承诺。新用户要的是吃得到的事实，不是先给一张未铺好的管线概念图。管线可以规划；肚子空着时，先画管线只会让错误传播得更快。

再看一层更日常的「新用户」：它不一定来自你们自己上的对话框。客户公司可能已经有内部知识助手，实施同事把你们帮助中心某页丢进去，助手再转述给一线。转述链一长，版本冲突就会被自动化。你们若仍只按「人从首页逛进来」做发布，等于默认这条链不存在——而它往往比文档站首页更早碰到客户。

把智能体写进画像，会改几件很具体的事——改的是发布标准，不是再写一篇「AI 战略」PPT。画像表上多一行，发布单上就要多几条可勾选项；勾不上的，就不要假装「我们已经 AI Ready」。

它一次可能只读一块。长篇线性教程对它不友好；FAQ、任务型帮助、带版本的短说明更易命中。人机粒度怎么折中、怎样才算「对人好又对机器吃得下」，邻近篇会写细则；这里只留一句：发布时要有可单独成立的知识片段——一小块可检索、可引用、带齐办事所需前提的事实，而不是必须先读完系列第一章才懂的半截话。

它不看视觉层级。字号、首屏插画、卡片阴影、面包屑动画，对它几乎无效；标题是否像任务、元数据是否带产品版本、链接是否稳定、危险限制是否写在块内而不是「见系列导读」，更性命攸关。人还会被设计安慰；机器只吃结构和字。

它可能从不「从首页进来」。每一页都可能是第一页——被引用、被检索、被粘贴进工单、被助手当成唯一上下文。前言里的重要限制，若只活在系列第一章，新用户很容易饿着肚子答错；答错之后，客户很少回头查「原文到底在哪一版」。

提示工程 在消费侧，常常变成「助手怎么问你们的文档」；文档侧能做的，是让答案所需的前提写在块内，而不是指望提示词补全残缺事实。提示再巧，也变不出你们没发布的权限边界。国内团队可以做一个极小的画像练习：列出三件「客户侧助手最可能问错」的事（权限模型、导出限制、关键集成边界），检查帮助中心是否各有一页现行说明、URL 能否分享、是否已发布。缺的不是再画一张用户旅程图，是这三页在不在、能不能被深链、能不能被检索命中。

再加一条很土的现场检查：把这三页的链接丢进内部群，让从未读过系列导读的同事只看这一页，判断能不能安全办完。人办不完的页，机器更办不完——画像表上那位新用户，不会比这位同事更会猜你们的伏笔。

画像练习做完，往往会露出三种缺口。缺口一：页在，但标题不像问法，检索命不中。缺口二：页在，但限制写在系列别处，单页不成立。缺口三：页在飞书或群文件，不在已发布站，助手与客户侧工具根本拿不到。三种缺口里，第三种最常见，也最容易被「我们内部其实有文档」掩盖。内部有，不等于新用户有入口。

对人机写法怎么折中、怎样才算块状就绪，邻近篇会写细则；本篇到此收住。入场要先承认桌上多坐了一位，再谈怎么把菜单写得它也点得着。

Baklib 不要求你们为机器另建一座幽灵站。更稳的是：同一真源，发布时同时服务人和机器。另养一份「只给机器人看的说明书」，通常会在第二周开始分叉，变成新的孤岛——人改了帮助中心，机器那份还停在上周的导出步骤上。分叉一旦发生，你们会同时维护两套「官方」，却谁也说不清哪套算数。

帮助、文档、开发者文档等叶子用建设侧模板点亮；内容块状、可检索、可版本。需要时提供 llms.txt 一类声明，并保持结构化站点——单独文件不是银弹，长页仍会被截断，根子仍是已发布块好不好、能不能单独成立。开发文档 与帮助中心门脸不同：前者偏规格与接口，后者偏「此刻怎么做完这件事」；事实源应一，改默认值应回到同一处真源再发出去。AI 客服 只读已发布库，检索再总结，人能点回原文——它是到达层，不是第二套知识库，更不是空模型对外的快捷方式。

落地检查可以短，短到能贴进发布单：

新用户画像有没有写进发布假设；高风险三问有没有现行页；对话与搜索是否避免空模型对外；标题是否像人（和助手）会问的话；版本与限制是否写在页内。人还是主读者之一——目录与可读性不能丢；只是桌上已经多坐了一位，发布时假装看不见，损失的是渠道与信任，不是情怀。

智能体是一种新用户。新用户入场，产品会改交互；文档该改的是发布假设——从「给人逛完」扩到「给一次只读一块的读者也留得出入口」。入口背后，仍是那份你们认账的事实。事实立不住，画像表多写一行，也只是多写一行。