AI 并不了解你的用户

访谈里有一句很短、也很不容易被绕开：我觉得你必须了解你的用户；AI 并不了解你的用户。

模型可以读你们的公开文档，可以模仿语气，可以拼出流畅步骤。它不知道你们的客户会在哪一步吓到、哪句术语会让实施同学误操作、哪类例外一旦写满会变成销售承诺。不知道，不是模型懒，是它没有你们的现场——没有你们听过的投诉、没有你们踩过的回滚、没有你们在续约前被追问过的那一页。现场知识若不写进结构，模型再强也只能在空地上组词。

文档职能存在的理由，往往就在这里：还知道读者是谁，还知道哪句话会害人。共情和场景，是不可自动化的那一层。自动化的是组词；不可自动化的是「这句对谁说、在什么前提下说」。本篇不复述幻觉机制专论。这里只钉用户：模型不懂你们的用户；口粮若来自你们已发布的、按口径写过的知识，综合才不至于信口开河。口粮差，综合只会更快地答错人。答错人的句子读起来往往很圆，害起来也很正式。

同一句「支持导出」，对试用用户可能是「能不能先试试」；对合规客户可能是「导出是否含审计字段」；对实施伙伴可能是「批量上限与失败重试」。模型若没被喂进这些场景差异，会给出一句很圆、谁都用不上的话。圆话听起来专业，害起来也很正式——因为它像官方，却对不上任何人的任务。对不上任务的官方，比明显的胡话更难拦截。

客户成功 天天碰到这种差异：续约前客户问的，和首周试用问的，不是同一层恐惧。把恐惧写进结构——任务页写清前提，规格页写清边界，政策页写清承诺——才是共情的可执行形态。共情不是多写形容词，是少写会害人的省略。省略「仅管理员」、省略「不可逆」、省略「灰度中」，模型会把省略补成流畅步骤；流畅步骤一执行，锅记在产品头上，很少有人回头查「原文到底有没有写前提」。

客户自助服务 要成立，前提是自助材料真的按用户任务组织，而不是按公司部门组织。知识片段 说人话，是可检索、可引用的事实块——若写得可检索却不可用，缺权限前提、缺不可逆提示，助手采到后，会把不可用放大成「官方步骤」。片段短可以；对用户的场景判断不能缺。短而清楚，好过长而圆滑：圆滑常掩盖未裁定的前提。

共情还表现在拒绝：拒绝把路线图语气写进现行帮助，拒绝把销售话术写进错误码表，拒绝把内部绰号写进对外步骤。模型很少主动拒绝；人要拒绝。拒绝，是了解用户的另一种形式。不会拒绝的综合，只会把所有听过的句子揉圆。

作者更担心准确度与技能退化；工程师更担心成本、法务与用户信任。画像不同，共同点是：模型不懂你们的用户，答错了锅在组织。锅在组织，意味着编制讨论里「有了 AI 还要文档人吗」问法本身就问错了——要问的是：谁把用户场景写进真源，谁在发布闸门签字。

答错人有两种。一种是事实错：默认值、权限、例外写反。一种是场景错：对了事实，找错读者——把企业版前提当成全员步骤，把灰度能力写成现网承诺。第二种更阴险，因为读起来很专业，害起来也很正式。社区与支持对话里，用户声音是另一条渠。把反复出现的失败句收进帮助，把「看过文档仍失败」变成结构补丁，才是把用户理解写回真源。模型可以总结工单主题；决定「哪句对外怎么写」，仍要人。总结主题不是代言用户；代言用户要落到可发布句。

两套角色若只各自害怕、不共用真源，害怕会变成互相甩锅。共用已发布口径之后，害怕才变成共同把关：作者守场景，工程守变更，支持守回流。把关的对象是用户，不是彼此。现场还有一种常见错位：对内演示很会「懂客户」，对外帮助却按组织架构排目录——模型再聪明，采到的也是部门地图，不是用户任务。懂用户，要先写进目录与前提，再谈对话框。

把「了解用户」写成可检查的页属性，共情才不会停在口号。适用对象是谁、前提权限是什么、不可逆吗、是否仅某版本——这些写进知识片段与帮助任务页，模型代读时才有粮，人也才点得回原文。写进结构，是文档职能还在的理由；指望模型自己猜读者，是把共情外包给概率。

客户成功与客户自助服务都依赖同一前提：材料按用户任务组织。社区里反复出现的失败句，应回流成结构补丁，而不是只变成周报形容词。Baklib 侧顺序固定：人写清场景并发布，AI 客服再综合已发布知识；帮助中心与客户交流社区分工不同，但都服务「答对人」。AI 并不了解你的用户——了解用户，是人写进真源里的那一层判断。

把答错人的成本说具体，会更难用「模型以后会懂」搪塞。试用用户按企业版前提操作失败，可能直接流失；合规客户按缺审计字段的导出说明做完，可能变成法务事件；实施伙伴按灰度能力当现网承诺交付，可能变成合同纠纷。三类伤害，模型都可能用同一句圆滑步骤触发——因为它不懂你们的用户分层。

客户成功要的是按阶段写清恐惧；客户自助服务要的是按任务组织材料；知识片段要的是可检索且含前提。社区回流失败句，是把用户声音写回真源的渠道，不是让模型直接对外发言的渠道。Baklib 顺序不变：人写清并发布，AI 客服从已发布知识综合；帮助中心与客户交流社区各司其职。AI 并不了解你的用户——这句话保护的不是编制虚荣，是客户不被圆滑的错步骤带着走。

Baklib 侧：问答只综合已发布的、按你们口径写过的知识；用户是谁，仍要人写进结构里。

帮助中心 承载任务与场景；AI 客服 读已发布再总结；客户交流社区 一类渠道收集声音，再回流进库。顺序是：人写清用户与场景 → 发布 → 模型代读；不是：模型先猜用户 → 人再擦屁股。别人打开浏览器能看到前提、边界、适用对象写清了，才算把「了解用户」做成了可验证的页，而不是做成了口号。

AI 并不了解你的用户。了解用户，是文档职能还在的理由之一。口径在库，判断在人；口粮对了，综合才像帮助。模型可以组词，组织仍要定：这句话对谁说、在什么前提下说、说错了谁负责收回。定不清这三句，对话框只会更快地把糊涂端给客户。

可验证的页，才是共情的落地：试用者看得到怎么开始，合规客户看得到边界，实施伙伴看得到上限与失败路径。模型可以帮忙组句；组句之前，组织要先决定这句话是说给谁听的。决定不清楚，组句只会把不清楚说得更流畅。

把关若只发生在聊天里，不发生在发布状态上，害怕仍会回到甩锅——因为浏览器里对不上的那一页，才是客户看见的「官方」。作者守场景，工程守变更，支持守回流，共同对象是用户，不是彼此。