AI客服翻出三年前的废弃文档，问题不在模型，在没人替它把资料组织过

摘要：提示词工程解决怎么问，上下文工程解决喂什么，可管线搭好了AI照样答错——缺的是上面那层信息结构。Nielsen Norman Group把这层叫上下文架构：用信息架构那套老手艺（层级、分类、标签、受控词表、本体、记忆规则）去组织AI能读到的一切。这篇把四条原则逐条拆开，配上好坏对照。更要紧的是反过来的那一半：你的网站正在给别人的AI当资料库，同一套原则你一条都躲不掉。

一句我登不上去，AI客服翻出了三年前的废弃文档，问题出在哪？

先说一个场景。用户在对话框里打了六个字：我账号登不上去。

你的AI客服很努力。它从知识库里捞回来一堆东西：一份两年前的排障笔记，一份早就废弃的密码重置流程，一份内部安全升级策略，还有几段员工在内部群里的讨论记录。然后它把这些拌在一起，给用户回了一段话——步骤是过时的，链接是死的，中间还夹了一句让用户联系安全团队。

用户看完更懵了，转头去发工单。你打开后台一看，火气多半直接往模型身上撒。

可这事真不怪模型。它只是老实地把你递过去的一堆资料读了一遍，读到什么就说什么。你递的是一间乱仓库，它当然搬出来一堆积灰的箱子。

Nielsen Norman Group在2026年6月发的那篇上下文架构里，作者Paz Perez把这件事讲得很直白：问题不在模型本身，问题在于系统必须去解读一堆嘈杂、没有结构的上下文。

提示词、上下文工程、上下文架构，这三个词到底差在哪一层？

这三个词最近半年被混着用，用得人心里发毛。其实它们是三个不同的年代，也是三个不同的活儿。

最早是提示词工程。那会儿大家发现，同一个模型，问法不一样结果能差出天壤，于是团队开始收集提示词、复用提示词，甚至把提示词当资产管起来。

接着是上下文工程，这个说法出自Shopify创始人Tobi Lütke。大家意识到光有提示词不够，真正起作用的是一小撮针对当前任务的上下文：指令、检索回来的知识、专门的工具、挑出来的记忆、还有当前状态，这几样得配合着来。活儿从写提示词变成了编排上下文。

现在到了智能体这一层。它不只是回你一句话，它替你干活——检索、调工具、维持状态、跨多个步骤行动，还越来越多地跟别的智能体互相协调。

这一步跨过去，设计问题就变了。你不再只是决定跟模型说什么，你在设计它思考和行动的那个环境。

顺带把一个容易混的东西摘出来。给AI建一个客户知识库那篇讲的是团队怎么把客户信息沉淀成机器能读的资料，落在喂什么料这一层；这篇要讲的是这些料本身该按什么结构组织，是上一层的事。

为什么Nielsen Norman Group会把信息架构这门老手艺搬出来？

因为这活儿人类干了几千年。

为了让人能看懂、能找到、能用上，我们发明了结构、分类法、标签体系、导航模式，就为了减少歧义、提高可找到性。图书馆的索书号是这个，超市货架的分区是这个，你手机里那几个文件夹也是这个。

大语言模型需要的是同一套地基。它跟人一样，面对一堆没有组织过的信息就会犯迷糊——只不过人会皱眉头，它会一本正经地编。

所以NN/g给这层活儿起了个名字：上下文架构。说白了就是把信息架构原则搬到AI系统上，让信息不光能被拿到，还能对人和机器双方都有意义、有结构、能用。

这里有个容易被忽略的转折。传统信息架构服务的对象是人，人看不懂会自己想办法——翻两页、点回退、搜一下。机器不会。机器读到什么就当成什么，然后立刻拿去做决定。这也是首页信息架构在AI时代重新变成流量入口那件事的另一面：同一门手艺，甲方换了。

确定性产品和概率性产品，设计方法为什么不能照搬？

传统数字产品是确定性的。我们一步步设计流程，把产品在每一步的行为定义清楚，写死在代码里。这样做的好处是每次输出都一样，系统按预期行事，我们只需要操心用户会怎么反应。

AI产品把这套逻辑掀了。大语言模型是概率性的，同一个输入可能给出不同输出。这个不确定性既是它的能力来源，也意味着你对系统产出的控制权没那么完整了。

挑战因此从定义精确结果，变成了塑造系统行为——同时还得考虑用户会怎么理解和回应这些结果。

这个转变对做惯了网站的人尤其别扭。做网站改一行CSS，一百个用户看到同一个页面。做AI产品改一句系统指令，一百次对话能给你一百种表现，九十七次变好三次变糟，你还得想办法把这三次找出来。

训练数据你管不着，那还剩什么是你能控的？

对绝大多数团队来说，训练数据不是能直接控制的东西。你用的是第三方模型、基础模型，训练在别处完成，参数在别人手里。

这就让上下文成了塑造系统行为的主要抓手。指令、检索回来的知识、工具、记忆、状态，这几样共同影响模型怎么理解任务、怎么生成回应。

更实际的一点是：上下文是可测的。团队可以改一版上下文，然后测一测系统行为到底有没有变好。模型权重你动不了，上下文你今天下午就能改一版。

保哥觉得这一点值得反复说给客户听。很多团队一遇到AI答得不对，第一反应是换个模型试试，换完发现还是不对，再换一个。换模型是最贵也最偷懒的解法，而真正能动的那个旋钮，一直摆在他们自己的知识库里。

上下文窗口里到底装着哪七类东西？

NN/g把上下文生态拆成了七类，这个清单值得抄下来贴在墙上。上下文不是一份系统提示词，它是一整套需要被发现和挑选的信息生态，是AI系统上下文窗口里的一切。

七类里只有最后一类归用户，前面六类的结构好不好，全看你团队有没有人真在管。

技能包为什么默认只加载名字和描述？

这个机制值得单拎出来说，因为它把命名的重要性放大了好几倍。

技能包是可复用的指令、脚本和资源打成的一个包，智能体按需加载。默认情况下只有技能的名字和描述被加载进上下文，完整内容要等到真被调用时才展开。Anthropic在Agent Skills的官方文档里把这套渐进披露讲得很清楚。

这意味着什么？意味着在决定用不用你这个技能的那一刻，系统看到的只有一个名字加一句描述。名字取得含糊，后面写得再详尽也白搭——它压根不会被打开。

这跟标题党的逻辑正好反过来。标题党是名字写得花哨骗人点进去，这里你要的是笨拙、直白、跟别人不重样。叫账号访问支持，比叫凭据恢复工作流管用得多。

为什么塞得越多反而答得越差？

这是最反直觉、也最容易被忽略的一条：更多上下文并不带来更好结果。

原因是每一个元素都在竞争模型的注意力。跟人一样，模型也会被信息过载影响。你把八十份文档一股脑塞进去，它未必能找出最该用的那三份，倒很可能被中间某份措辞强烈的旧文档带跑。

结构差的上下文会带来三样代价：拖慢系统、抬高成本、让输出变得不一致或者容易出错。所以清晰的上下文结构和优先级，跟内容本身一样重要。

这里可以借内容分块优化那篇讲过的道理：AI是按块检索的，你给它的每一块都在抢位置。区别在于分块讲的是切法，上下文架构讲的是切完之后怎么摆、谁摆在前面。

结构差的上下文，成本和延迟是怎么涨上去的？

这笔账很多团队没算过，算完往往会吓一跳。

假设一次客服对话，结构良好时检索回来三千个token的相关内容，结构混乱时检索回来一万五千个token的半相关内容。差出来的一万二千个token，每一轮对话都要付一次费、都要多等一会儿。

更麻烦的是它滚雪球。会话越长，塞进来的历史越多，噪声占比越高。到第十轮对话时，你付着五倍的钱，拿到的是更差的答案。

结构不是为了好看。它是那道决定你每个月账单和用户耐心的闸。

建筑师和工程师那个比方，为什么值得认真对待？

NN/g那篇文章的作者在转做用户体验之前，是纽约市公立学校的建筑师。她用了一个很好的类比。

工程师负责水管通、电路通、结构稳。建筑师关心的是另一组问题：这栋楼是干什么用的？人该怎么在里面走动？空间该怎么组织，才能让使用它的人觉得说得通？

让一栋房子有家的感觉的，不只是结构完整，还有自然光、房间的比例、以及那些人会聚在一起留下记忆的空间。

放到这儿是一样的道理。上下文工程搭的是基础设施——管线和组件；上下文架构定义的是住在这套基础设施上面的信息结构——结构、意义、行为。前者归工程团队，后者该归信息架构师，或者说，归那个真正懂用户怎么说话的人。

四条IA原则搬到AI系统上，具体是哪四条？

NN/g给的框架建立在核心信息架构原则之上，针对AI系统做了改写。这个框架还在演进，作者自己也说了，AI跑得太快，构建方式需要不断打磨。

四条原则是：组织上下文的结构、改善可发现性、对齐用户心智模型、设计记忆。

有一句话得先记住，因为它决定了这四条的分量：一个写得再好的提示词，也补不上糟糕的检索结构、不一致的标签、重叠的工具、以及嘈杂的记忆系统。

这句话保哥想再翻译一遍给做内容的人听：你花三天打磨的那段提示词，抵不过知识库里两个撞名的文件夹。

层级：哪份文件该压过哪份，得有人明说

层级建立的是信息的优先级和深度。放到客服智能体上，它长这样：

• 公司已批准的政策，排在团队笔记之上
• 当前有效的流程，排在废弃流程之上
• 账号恢复的核心指引，排在边缘情况之前

好处很直接：系统在推理和检索时，能识别出哪些信息该带更高的权威。

没有这层规则会怎样？系统面对一份2023年的排障笔记和一份上周更新的官方政策，它没有任何依据判断该信任谁，于是可能两个都用，甚至因为旧笔记写得更详细而更倾向旧的。

做过内容的人对这事有肌肉记忆。一个库跑三年，写得最认真最详尽的那篇，往往恰恰是最早写的那篇，也就是最过时的那篇。人凭日期一眼看穿，机器不行。

已批准的政策和团队随手记的笔记，优先级怎么写进系统？

有三种常见做法，成本和效果差别不小。

第三种最省事，也最脆。它依赖模型每次都乖乖听话，而模型不总是听话。前两种是把规则做进结构，比写进嘴里靠谱。

保哥的建议是两条一起上：结构里过滤，指令里再声明一遍。皮带背带同时用，裤子掉不下来。

分类：把知识库切成几个域，检索范围就小了一圈

分类做的是把相关概念归进清晰的领域。客服场景下的一组典型分类是：账号访问、账单、技术排障、安全、企业管理。

作用很实在——检索不用再搜遍全部客服文档，而是瞄准一个更小、更相关的子集。检索噪声降下来，回答准确率提上去。

这跟做站内分类是同一个道理。你把八百篇文章全堆在一个未分类里，搜索功能就得在八百篇里捞；切成八个类目之后，捞的范围小了一个数量级。WordPress分类和标签怎么用那篇讲的索引治理，讲的其实也是同一件事的另一头。

区别在于，网站分类切错了顶多用户多点两下，AI系统分类切错了，它会自信地把账单政策拿来回答登录问题。

分类切错了会怎样？两种最常见的切法错误

第一种是按你的组织结构切，不是按用户的问题切。

很多公司的知识库目录长得跟组织架构图一模一样：产品部文档、技术支持部文档、法务部文档。用户不关心这个。用户只知道自己登不上去，他不知道该去哪个部门的抽屉里翻。

第二种是切得太碎。有个团队把客服知识库切成了四十七个分类，每个分类底下三到五篇文档。结果是检索系统面对四十七个候选域，选错的概率比不分类还高。

分类的价值来自缩小范围，而不是来自分类这个动作本身。切到五个域能把范围缩到五分之一，切到四十七个域只是把选择困难从检索环节挪到了分类环节。

标签该跟用户的词对齐，还是跟内部术语对齐？

标签确保系统内部的语言，跟用户描述问题的方式对得上。

NN/g给的对照特别直观。系统里该用的标签是：锁定、无法登录、重置密码。而不该用的是：凭据失效、认证失败、身份恢复流程。

对齐后的标签同时改善检索和工作流选择，因为系统更容易把用户的话映射到内部概念上。

这条原则搬到网站上，就是那个老问题：你的产品页标题写的是行业黑话还是客户的话。区别在于以前写黑话只是少几个搜索流量，现在写黑话，AI在替客户找答案时会直接跳过你。

凭据失效和登不上去，差的不只是文雅程度

这两个词组的差别，本质是两套词汇体系的差别。

凭据失效是系统视角：从数据库的角度看，这条会话令牌到期了。登不上去是用户视角：我按了按钮，它不让我进。

模型做匹配，是在用户那句话和你的标签之间算相似度。用户说的永远是用户视角的话，你的标签越靠近系统视角，相似度就越低。

你写给机器看的词，最终要拿去跟人说的话做匹配。所以那些词其实该写得像人话。

顺带说一句，这也是为什么很多团队的AI客服上线三个月还不好用，却查不出原因——因为标签这层东西不在任何一张监控看板上，它只是安静地让每次匹配都差那么一点。

可发现性：LLM找信息，跟用户在烂网站上导航是一回事

NN/g这个类比下得很准：大语言模型经常在可发现性上卡壳，像用户在一个混乱的网站上找路。

我们想避免的是智能体检索到错的信息，或者走了不必要的步骤。当智能体能立刻找到该找的东西，它就更准也更省。

还有一层收益容易被漏掉：更好的可发现性也降低了系统负载，因为它在拿到正确上下文之前，需要处理的无关信息变少了。

这里可以对照查询扇出机制那篇讲的事。引擎把一个问题拆成十几个子查询去检索，每一路子查询都要面对你的信息结构。结构清晰，十几路都能捞对；结构混乱，误差会被扇出放大十几倍。

三个技能包名字撞在一起，智能体会干出什么蠢事？

NN/g给了一个很扎心的例子。三个技能包分别叫：

• account-support，描述是：账号问题时使用此技能
• customer-help，描述是：客户需要帮助时使用此技能
• access-workflow，描述是：访问相关工作流时使用此技能

用户说：我账号登不上去。三个技能听起来都沾边，智能体没法区分，于是它可能选错一个、问一堆不必要的澄清问题、或者干脆放弃技能去搜索大而全的客服文档。

这三个名字有个共同毛病：它们描述的是领域，不是动作。账号问题是个筐，什么都能往里装。

SEO智能体的技能架构那篇里也踩过同款坑——技能边界不清的时候，智能体不是不干活，它是干得特别热闹但全干错了地方。

受控词表在AI系统里具体长什么样？

受控词表确保系统对同一概念，用的是跟用户一样的词。

NN/g给的正面例子是这样一条技能定义：

• 名字：account-access-support
• 描述：当用户无法登录、被锁定、需要重置密码、或者访问账号遇到麻烦时，使用此技能

关键在描述那一行。它没写一句抽象定义，而是把用户可能说出口的四种说法全列了进去。用户说我登不上去，这句话就能连到正确的内部概念上。

做法上有个便宜的窍门：把这段描述当成关键词列表来写，而不是当成定义来写。你要的不是精确的语义边界，你要的是覆盖用户的说法。

无歧义命名有没有可操作的标准？

有。NN/g给的两个例子摆在一起就是标准本身：

• reset-password，描述：仅当用户需要重置、找回或修改密码时使用
• unlock-account，描述：仅当用户在多次登录失败后被锁定时使用

请注意两个描述里都有一个仅当。这个词干的活是划边界——不只是说我能干什么，还说了我不该在什么时候被叫起来。

保哥总结成三条可以照抄的规矩：名字用动词加宾语而不是名词短语；描述里写清触发条件而不是能力范围；每个描述都加一句仅当，逼自己想清楚边界在哪。

清晰的名字减少重叠，帮助智能体更快选对技能。这事儿的性价比高得离谱——改几个名字，一分钱不用花。

系统的概念模型，该照着谁的脑子画？

先把概念模型这个词说清楚。它指的是系统内部的一份表征：什么信息重要、不同信息之间怎么关联、以及某一条该在什么时候被用上。

上下文架构里很关键的一步，是让系统的内部模型跟用户的心智模型对齐。落到操作上就是：按用户描述问题的方式、形成预期的方式、推进任务的方式，来组织上下文。

这话听着抽象，但反例一摆就懂了。你团队里的人管一个功能叫SKU映射表，客户管它叫商品对照。你的知识库、你的工具描述、你的字段名全用前者，那么当客户问商品对照怎么导入时，系统在自己的世界里找不到这个东西。

NN/g强调过一句值得抄下来的话：问题不在于缺工具，也不在于缺MCP集成，而在于上下文层里的描述、标签和关系跟用户的心智模型对不上。工具都在，只是没人告诉系统这些工具跟用户的话怎么对应。

工具描述写成工程术语，会触发哪几类错误行为？

NN/g给的反面清单很具体。假设用户说：我登不上去，而且我很急。系统看到的工具描述是这样几条：凭据恢复工作流、处理认证状态转换、身份验证序列、触发身份升级协议。

结果是四类错误行为：

• 选错工具
• 触发昂贵的流程
• 问出让人一头雾水的澄清问题
• 压根没认出登不上去对应的是账号访问恢复

第二条要特别留意。触发昂贵流程不只是费钱，它常常意味着把一个本来能自助解决的问题升级成了人工工单，或者启动了一套需要用户提交身份证件的核验流程——用户只是想重置个密码，结果被要求上传证件照。

工具越多、描述越技术，这种误触发就越频繁。这也是为什么MCP生态铺开之后，工具描述反而成了新的瓶颈：MCP的官方入门文档把发现与调用的协议标准化了，但没人能替你把描述写成人话。

本体：把登不上去和账号访问连起来的那层关系

本体定义的是概念之间怎么关联。NN/g给的三条例子长这样：

• 登不上去关联到账号访问
• 账号锁定可能源于多次登录失败
• 紧急访问问题可能需要优先升级

有了这层关系，系统就能对意图做推理，进而准确选择工具。

注意第二条和第三条的措辞：可能源于、可能需要。本体不需要写成铁律，它是给推理提供路径的，不是给判断下结论的。写得太死反而会把系统卡住。

做SEO的人对这层东西其实不陌生，只是换了个名字。实体消歧讲的是怎么让引擎分清同名的两个东西，关系完整性审计讲的是schema堆满了但实体之间的关系没人审。想看这层关系在网页上具体怎么落笔，@graph那套写法是现成的例子。四件事说的都是：光有节点不够，边也得画上。

分类法和本体到底差在哪，别再混着用

这两个词被混用得太厉害了，值得掰扯清楚。

大部分团队只做了分类法就以为做完了。分类法能把范围缩小，但它没法告诉系统紧急这个词该触发什么，也没法告诉系统被锁定和登录失败之间有因果。

顺序上建议先分类法后本体。分类法便宜、见效快、错了好改；本体贵一些，但它决定了系统能不能真的推理，而不只是检索。

记忆设计：记什么、怎么索引、什么时候取回

记忆决定了系统在时间维度上的连续性和相关性。没有清晰结构，系统要么忘掉关键信息，要么被无关细节淹掉。

NN/g建议用系统指令来定义三件事：记什么、怎么索引、什么时候取回。三件事缺一件，记忆就会开始腐化。

随着对话变长、用户在同一个会话里持续工作，记忆结构变得越来越要紧。团队必须决定：这个AI系统需要知道什么，以及需要忘掉什么。

需要忘掉什么，这半句常被跳过。大家做记忆功能时想的都是让它记住更多，很少有人认真列过一张该忘清单。可实际出问题的，几乎全是没被忘掉的那些东西。

记忆没有结构，一个回头客会遭遇什么？

NN/g的例子是这样：老用户回来说，我账号还是访问不了。

系统从记忆里捞回来的东西分两堆。无关的那堆：旧的排障尝试、已经过期的账单纠纷、不相关的技术问题。相关的那堆：无障碍偏好、偏好的联系方式、企业账号状态。

问题是它把两堆一起端了上来。结果是三条：把无关信息推到台前、错过了重要的客户偏好、token用量和延迟一起涨。

作者点得很准：问题不在记忆本身，问题在于缺少一套治理什么该长期留存的结构。

保哥见过更离谱的版本。某个客户的AI客服把用户三个月前问过的退货政策一直带在上下文里，后来用户问物流，回答里总要多一句退货提醒。用户以为系统在暗示这单要退，体验相当微妙。

分面分类怎么把记忆切成互不污染的类型？

分面分类做的是把记忆组织成不同类型。NN/g列的五类是：

• 无障碍偏好
• 账单历史
• 安全验证
• 活跃的支持工单
• 临时排障步骤

好处是系统只取回跟当前任务相关的那一面。用户问物流，账单历史那一面根本不会被打开。

分面和分类的区别在于，分面是可以叠加的多个维度，而分类是互斥的单一归属。一条记忆可以同时是安全验证类和临时类，这两个标签不冲突，它们回答的是不同问题。

实操上不必一上来就设计十个分面。先切出三个够用的：这条记忆属于哪个业务域、它的时效是长期还是本轮、它敏不敏感。三个维度就能解决大半问题。

范围规则：哪些信息只该活在这一轮对话里？

范围规则定义记忆什么时候可用。NN/g给的两条：

• 临时排障细节，只该在当前会话内被访问
• 无障碍偏好，跨对话持续保留

它挡住的是无关信息污染未来的交互。这个词用得好——污染。一条本该在上周那次对话结束就消失的临时信息，如果活了下来，它会在接下来每一次对话里都插一句嘴。

怎么判断一条信息该不该跨会话？保哥用的土办法是问一句：三个月后这条信息还成立吗？无障碍偏好三个月后大概率还成立，用户上周试过的那个排障步骤三个月后毫无意义。

还有一类特别值得设成本轮即焚：用户在情绪激动时说的话。他上次骂了一句这破系统，你没必要在下次对话时还记着。

保留策略怎么定，才能兼顾连续性、相关性和隐私？

保留策略定义不同类型的信息该存活多久。NN/g的三条例子分别代表三种生命周期：

• 密码重置令牌，很快过期
• 活跃的账单纠纷，保留到解决为止
• 已解决的支持工单，归档

三条合起来是在连续性、相关性和隐私之间找平衡。第一条是安全考量，第二条是业务状态驱动，第三条是从活跃区移出但不删除。

注意归档和删除不是一回事。归档意味着它不再进入默认检索，但需要时能被翻出来。很多团队只有留和删两档，中间那档缺失，导致要么留一堆垃圾，要么把有用的历史一刀切掉。

做出海生意的还得多算一层合规账。欧盟用户的对话记忆存多久、存在哪、能不能被要求删除，这些不是技术选择而是法律约束，最好在设计记忆结构的第一天就问清楚，别等收到删除请求才发现记忆散在四个系统里。

记忆规则该不该让用户看见？

NN/g的答案是明确的：系统和用户双方都该对这些规则的应用方式有透明度。

清晰可见的记忆规则，帮助用户理解哪些信息被保留了、为什么重要、以及它们随时间被怎么使用。最终这些会转化成对产品的信任。

这一点在中文市场值得多花点力气。国内用户对被记住这件事的敏感度这两年明显上升，一个说不清自己记了什么的AI助手，很容易被当成在偷偷收集资料。

可操作的做法有三个层次：最轻的是在设置页列一张记忆清单让用户能看能删；中等的是在对话里首次调用某条长期记忆时明示一句我记得你之前提过；最重的是给每条记忆标注来源和时间。第一层几乎零成本，先做那个。

换个方向想：谁在给ChatGPT做上下文架构？

到这儿为止，讲的都是你自己搭AI系统时该怎么组织上下文。源头那篇文章也停在这里。

但对做网站、做电商、做外贸的人来说，还有另外一半，而且是分量更重的那一半。

把镜头转过来：当用户在ChatGPT里问该买哪个牌子的工业除湿机时，那个模型也在组装它的上下文。它去检索，拿回来一批网页，把这批网页塞进上下文窗口，然后基于这份上下文生成回答。

那么问题来了——这份上下文里的内容，是谁写的、谁组织的？

是你。是你和你的同行。你的产品页、你的帮助中心、你的对比表格，构成了它这一轮推理的原材料。你不是在设计那个AI系统，但你在给它供料，而且你供的那一份长什么样，完全由你决定。

你控制不了检索管线，但你控制喂进去的那一份

这个分工要说清楚，不然容易滑向那种什么都能优化的幻觉。

你控制不了的：模型怎么切块、怎么算相似度、怎么排序、怎么决定引用谁。这些在人家的服务端，被检索和被引用是两套打法那篇拆过其中的区别。

你能控制的：进入这条管线的那份材料本身——它的层级怎么排、概念怎么分类、用什么词命名、废弃的东西还在不在、同一个意思有没有三种说法。

把这两列摆在一起你会发现，你能控的那一列，恰好就是信息架构那四条原则。同一套手艺，换了个使用场景。

你不是那个AI系统的架构师，你是它的资料供应商。而资料供应商也有优秀和糟糕之分。

站内分类法和AI的检索范围，是同一件事的两头？

是的，只是作用点不同。

你做客服知识库的分类法，是为了让检索只在一个子集里捞。你做网站的分类结构，是为了让引擎在理解你这个站时，能把内容归进正确的主题域。

两者的失败模式也一样。分类混乱的知识库让智能体捞错文档；分类混乱的网站让引擎搞不清你到底是卖除湿机的还是做设备租赁的，于是在两类问题下都不推荐你。

AI搜索的12类查询分类那篇给过一个视角：先搞清楚用户会问哪几类问题，再倒推你的内容该分成哪几个域。这个顺序不能反——先按自己的产品线切分类，再祈祷它刚好对上用户的问法，成功率不高。

顺带提醒一句，网站架构的深度问题在这里同样成立：层级太深的内容，人和机器都懒得挖到底。

你的产品命名，正在决定AI匹不匹配得上用户的问法

还记得那条原则吗——标签要跟用户的语言对齐，而不是跟内部术语对齐。

放到独立站上，这条几乎是逐字适用的。你的产品叫工业级空气处理解决方案，客户搜的是车间除湿机。你的服务页写的是全链路履约赋能，客户问的是能不能帮我发货到德国。

这不是文案好不好的问题，这是能不能被匹配上的问题。模型在做的事，是把用户那句话跟你页面上的词算相似度。你用的词离用户越远，相似度越低，你被捞出来的概率越小。

可操作的做法：把你最赚钱的五个产品，各写三条客户原话式的说法，塞进标题、首段和FAQ里。不是替换掉行业术语，是并存——术语给同行看，客户的话给模型匹配。

保哥带团队做这件事时有个笨方法：把销售的聊天记录导出来，看客户第一句话是怎么描述需求的。那才是真正的用户语言，比任何关键词工具给的都准。

帮助中心的层级，为什么直接影响被引概率？

因为帮助中心是最容易被引用、也最容易被组织得一塌糊涂的那类内容。

它天然符合被引的条件：问题导向、答案明确、篇幅短、更新频繁。帮助中心和知识库的索引控制那篇讲过这块的工程化做法。

但它也天然容易腐烂。产品迭代三轮，帮助中心里躺着三个版本的操作步骤，谁也没删。用户来搜的时候还能靠发布日期分辨，AI来检索的时候，三个版本在向量空间里长得几乎一样，它可能挑中最旧的那个。

层级在这里的作用就是那条已批准政策压过团队笔记的规则，只是搬到了公开网页上：当前版本放在主路径，历史版本要么删、要么明确标注已归档并从索引里摘出去。

这活儿不性感，却是所有措施里回本最快的。

废弃内容留在站上不删不改，等于往上下文里掺沙子

这一条值得单独说，因为它是中文站最普遍的病。

很多站的思路是内容只增不减——反正多一篇是一篇，说不定哪天能带来点流量。这个逻辑在十年前的SEO里勉强成立，在今天要重新算账。

算法层面的账：一篇讲2021年政策的旧文，跟一篇讲2026年现行政策的新文，在引擎眼里是同一个站给出的两个矛盾答案。它可能引用旧的，也可能两个都不引用。

检索层面的账：旧文占着位置，稀释了新文在同一主题下的权重密度。

处置办法有三档，按内容价值分：还有价值的更新并保留、已完全失效的删除并做好跳转、有历史意义但不再适用的明确标注时效并加noindex。三档都比放着不管强。

内部术语泄漏到公开页面，代价是什么？

代价是你的页面对模型来说，跟一份写给内部员工的备忘录没什么区别。

典型的泄漏点有几处：产品型号命名规则、后台功能名、部门缩写、项目代号。这些词在公司内部人人都懂，在公司外面一个人都不懂，包括那个正在替客户找答案的模型。

举个例子。某个做工业设备的客户，官网所有产品页标题都是型号打头：HXD-7200系列。团队内部管这叫标准做法，因为老客户就认型号。可新客户不知道HXD是什么，他搜的是双螺杆真空泵。结果是官网只能被老客户搜到，而老客户本来就会直接打电话。

改法不难：型号保留，前面加上客户的话。标题从HXD-7200系列改成双螺杆真空泵HXD-7200系列，两种人和一台机器都照顾到了。

同一个概念三种叫法，AI会当成三件事吗？

不一定会当成三件事，但一定会稀释你在这个概念上的分量。

受控词表这条原则搬到网站上，就是术语统一。你的博客叫它跨境电商独立站，产品页叫它自建站，帮助中心叫它品牌官网。三个词指的是同一样东西，但它们各自的出现次数被摊薄了。

更麻烦的是关联被切断了。模型建立你这个站跟某个概念的关联时，需要看到足够密度的共现。三种叫法各出现十次，效果不如一种叫法出现三十次。

实操建议：挑一个主术语，其余的降级成别称，在每篇文章首次出现时用一次别称做等价声明，比如自建站又叫独立站，之后全文统一用主术语。这样既照顾了搜不同词的用户，又保住了主术语的密度。

多语言站点的麻烦会翻倍，因为每种语言都要各自维护一份主术语表，还得保证跨语言的对应关系不错位。

站内搜索日志，为什么是最便宜的用户语言样本？

因为那是用户在你自己的地盘上，用自己的话，主动打出来的需求。没有中间商，没有工具的估算，没有平台的关键词建议。

关键词工具给你的是搜索量排序后的词，站内搜索日志给你的是你的客户实际怎么说话。这两份名单的重合度经常低得惊人。

用法有三条：

• 把高频搜索词里那些站内没有对应页面的，列成内容缺口清单
• 把用户的说法和你的官方术语做一张对照表，用来改标签和标题
• 把搜了之后没点任何结果的词单独拎出来，那些通常是你的分类没覆盖到的域

这份数据大部分站都有，只是没人看。装了站内搜索的独立站跑三个月，就能攒出几百条真实的用户语言样本，成本是零。

没装站内搜索的怎么办？退而求其次有三个来源：客服工单的首句、询盘表单里的备注栏、以及搜索控制台里那些带疑问词的长尾查询。质量比站内搜索差一档，因为它们已经被平台过滤过一轮，但胜在现成。

结构化数据在这套框架里到底扮演什么角色？

它扮演的是把关系显式写出来那一层，也就是本体在网页上的落地形式。

分类法解决这个页面属于哪一类，标签解决用什么词称呼它，而结构化数据解决这个东西跟那个东西是什么关系——产品属于哪个品牌、评论评的是哪个产品、这篇文章的作者是谁、这个组织和那个组织什么关系。Google关于结构化数据如何工作的说明把机器可读这件事讲得很基础，而schema.org的入门指南给的是词表本身。

用上下文架构的话说：schema词表就是一份现成的受控词表，只不过它的使用者是机器，制定者是一个跨引擎的联盟。

要注意的是它的边界。Schema对AI搜索到底有没有用那篇给过实测结论：它不是排名开关，它是让机器少猜一点的辅助。堆得越多不等于效果越好，这跟上下文塞得越多反而越差是同一个道理。

llms.txt、分块、上下文架构，三者是什么层级关系？

这三个词常被放在一起说，其实它们在三个不同高度上。

顺序是从上往下的。上面那层错了，下面两层做得再漂亮也是把错的东西喂得更高效。llms.txt之后的4层内容架构讲的是下面两层的工程做法，语义化HTML的可提取性讲的是中间那层，这篇讲的是最上面那层。

保哥见过太多团队从最下面那层开始做——先配llms.txt，再补schema，最后发现AI还是不推荐自己。因为最上面那层的问题从来没被碰过。

从哪儿开始？一份四步的起手顺序

四条原则一起上会把人吓退。按下面这个顺序做，每一步都能单独交付。

1. 先统一术语。挑出业务里最核心的十个概念，各定一个主术语，其余全部降级成别称。这一步不需要任何工程配合。
2. 再清废弃。把明显过时、互相矛盾、重复三份的内容处理掉。清理比新增见效快。
3. 然后划层级。给内容标上权威等级和时效，让检索知道该信谁。
4. 最后补关系。把概念之间的关联显式写出来，能上结构化数据就上。

前两步占了七成收益，且几乎不花钱。第三步需要一点元数据工程，第四步是长期活儿。

顺序反过来做是最常见的错误——先上schema、先配llms.txt，把没整理过的一团东西包装得很机器友好，然后疑惑为什么没用。

怎么给现有知识库做一次上下文审计？

不用买工具，一张表加半天时间就够。抽二十个真实的用户问题，对每一个记录四件事：

二十条跑完，问题会自己冒出来。通常你会发现，答错的那几条里，八成不是模型理解错了，而是它拿到的材料本身就不对。

这套方法对公开网站同样适用，只是把检索回了哪几篇换成在AI里问这个问题时它引用了谁。

分类法该做多深？三层还是五层

经验值是三层，超过四层要有充分理由。

深度带来的是精度，代价是每一层都增加一次选错的机会。三层大概能覆盖大多数业务的复杂度：业务域、问题类型、具体场景。

宽度上，同一层的兄弟节点建议控制在七个以内。这不是什么魔法数字，只是超过七个之后，人在维护时就开始记不住有哪些，记不住就会重复创建，重复创建就会互相污染。

还有一条：宁可让分类稍微粗一点，也别让它变得需要专人解释。一个需要培训才能用对的分类法，三个月后一定会被用错。

那要不要干脆扁平化，一层拉平？也不行。完全扁平等于没分类，检索范围没被缩小，四条原则里最省钱的那条收益就没了。扁平的真正适用场景是内容总量很小的时候——文档不到五十篇，切分类的收益抵不过维护成本，那就先别切，等长到两百篇再回头补。

命名规范文档写成什么样才有人真遵守？

短、带例子、有反例。

保哥见过太多写了二十页没人看的规范。真正被遵守的规范通常不超过一页，长这样：

• 用动词加宾语命名动作类条目，比如重置密码，不要用密码管理
• 用客户会说的词命名对象类条目，不要用内部代号
• 每个条目写一句仅当开头的触发条件
• 禁止使用的词单独列一张表，比如赋能、闭环、抓手

最后一条最有用。与其教大家怎么写好，不如直接告诉大家哪些词不许用。禁用词表是唯一一种执行成本接近于零的规范，因为它可以被搜索检查。

怎么验证改动真的让AI答得更准，而不是自我感动？

唯一靠谱的办法是留对照、跑前后。

做法是这样：固定一份问题清单，改动前跑一遍记录答案，改动后再跑一遍，同一批人盲评。别只看整体感觉变好没有，要落到具体条目上——哪几条从错变对，哪几条从对变错。

会有从对变错的。这很正常，改分类法这类动作是有副作用的，你把某个域收窄了，原本靠模糊匹配蒙对的问题可能就蒙不对了。重要的是净收益为正，而不是零副作用。

主题层可见度那篇提过一个思路，放在这儿也成立：别盯着单个问题的输赢，看整个品类下你的出现率变化。单点波动是噪声，面上的移动才是信号。

评测集该怎么攒，多少条才算够？

从二十条开始，稳定跑起来之后扩到一百条左右，再多的边际收益就下降了。

攒的来源有四个，按质量排序：真实客服工单里的原话、站内搜索日志里的高频词、销售被问最多的问题、团队拍脑袋想的。前三个是金子，第四个只用来补空缺。

组成上要有配比：七成是常见问题，两成是边缘情况，一成是应该被拒答的问题。最后那一成经常被忘掉，可它测的是护栏有没有生效——一个什么都敢答的AI客服，比一个偶尔说不知道的更危险。

每条记录三样东西：问题原文、期望答案要点、最近一次的实际表现。别追求完美的评分体系，能看出变好还是变坏就够用。

内容团队和工程团队的分工怎么切？

切法其实很清楚，只是很多团队没切，导致两边都以为对方在管。

NN/g那篇的落点也在这里：随着AI系统嵌入日常产品，信息架构师和上下文工程师之间的协作变得关键。

现实中最常见的错配是，工具描述由写代码的人顺手写了。他写的是这个函数干了什么，而系统需要的是用户什么时候会想要这个。这两句话不是一回事。

一个人的小团队，这套东西要不要做？

要做，但只做前两步。

统一术语和清理废弃，这两件事对一人公司同样成立，而且因为没有沟通成本，做起来比大团队还快。你不需要写规范文档，你只需要在自己心里定一版，然后照着改。

不用做的是：正式的本体建模、复杂的分面记忆结构、跨团队的治理流程。这些是给多人协作的组织准备的，一个人用不上。

判断标准很简单：如果这套结构只有你一个人用，那么它存在的形式是不是文档并不重要，重要的是它在你的内容里一致地体现出来。

预算有限，四条原则先补哪一条？

看你的症状。

• 答案经常引用过时内容，先补层级
• 答案总从不相干的地方拿材料，先补分类
• 用户换个说法就问不出来，先补标签和词表
• 多轮对话越聊越乱，先补记忆

四条里投入产出最高的通常是标签和词表，因为它改的是字符串，不动任何架构。最贵的是记忆，它牵扯存储、隐私和状态管理。

如果症状不止一个，从最便宜的那条开始。这不是妥协，是因为改完之后其他症状的表现会变，你需要重新观察。

保哥的失手复盘：把分类法做得太细，反而更难检索

这个坑是保哥自己踩的，代价是三周。

当时给一个做工业耗材的客户搭客服知识库，我的判断是分类越细检索越准，于是按产品线、应用场景、客户类型三个维度交叉，切出了六十多个分类。文档也认真归好了位。

上线之后准确率反而低于分类前。查下来原因很直接：很多问题天然横跨多个分类，比如某型号在食品行业的合规要求，它同时属于产品线、应用场景和合规三个域。检索时系统得先猜该进哪个域，猜错就全错。

后来砍回十二个分类，把交叉维度改成标签而不是分类——一篇文档只属于一个分类，但可以带多个标签。准确率立刻回来了。

教训写在这儿：分类要互斥，标签才能叠加。想用分类表达多维度，就是在给检索出难题。

出海独立站案例：把询盘知识库重排之后发生了什么？

一家做实验室仪器的外贸B2B站，客户主要在欧洲和中东。他们的问题是AI客服答得很飘，而且海外客户在ChatGPT里问相关设备时，回答里从来没有他们。

动手的顺序就是前面那四步。第一步统一术语，发现同一类设备在官网、产品手册和帮助中心里有三种叫法，其中一种还是内部研发代号；第二步清废弃，删掉和归档了一批停产型号的页面，那些页面还挂着旧的技术参数；第三步给帮助中心的文档加了状态和适用型号两个字段，让检索能过滤；第四步补了产品和应用场景之间的结构化关联。

结果分两块。AI客服这块，那份二十条的评测清单从答对九条变成答对十六条，改善最明显的恰恰是最初出错最多的型号类问题。公开可见度这块变化慢一些，两个多月后才在几个具体的应用场景问题下开始被提到——依据是他们自己每周跑一次的固定问题清单，不是感觉。

值得说的是，整个过程里没有新写一篇内容。全是在整理已经有的东西。

中文语境有哪些额外的麻烦？

三个，都挺烦人。

第一是同义词密度高。同一个概念在中文里的说法往往比英文多，而且不同地区的叫法还不一样。大陆叫软件，台湾叫软体；大陆叫质量，港澳有时叫品质。做出海的团队如果同时覆盖多个中文市场，术语表得分地区维护。

第二是缩写不规范。英文缩写有比较稳定的约定，中文的简称往往是各家自创的。你写的产品简称，出了公司大门可能没人认得。

第三是分词。中文没有天然的词边界，一个术语切错了位置，语义就跑偏了，连带影响的是实体能不能被认全，标签匹配的准确度也跟着往下掉。

应对办法没什么巧的：术语表里把别称列全，包括错别字和常见的口语说法。宁可列得啰嗦，也别漏掉客户真正会打出来的那个词。

还有个容易被忽略的细节：中英混排的产品名，客户可能全用中文打、全用英文打、或者中英混着打。三种写法最好都收进别称，别指望模型自己能对上——它对得上是运气，对不上是常态。

长上下文模型会不会把这套东西淘汰掉？

不会，理由有两条。

第一条是注意力仍然是稀缺的。窗口从二十万涨到一百万，能塞进去的东西变多了，但每个元素竞争注意力这件事没有改变。塞进去不等于被用上，这是两回事。

第二条更根本：结构解决的不是容量问题，是歧义问题。就算你能把整个知识库一次性塞进上下文，系统面对三份互相矛盾的密码重置流程，仍然不知道该信哪一份。这个问题不是靠更大的窗口能解决的，只能靠有人明确告诉它优先级。

反过来说，窗口变大之后，结构的价值可能还会上升。因为窗口小的时候你被迫只塞最相关的几条，窗口大了之后诱惑就来了——干脆全塞进去吧。那时候没有结构的团队会输得更快。

三个最常见的误读分别是什么？

第一个误读：上下文架构就是把提示词写得更规整。不是。NN/g明确说过，上下文架构远不止是写清晰的提示词或者用标题和项目符号来排版指令，它是围绕AI系统的整个信息环境的设计。好的写作改善的是可读性，上下文架构塑造的是系统怎么解读信息、怎么做决定、怎么行动。

第二个误读：这是给做AI产品的团队准备的，跟做网站的没关系。前面那半篇讲的就是这件事——你的网站正在给别人的AI当上下文源，同一套原则你躲不掉。

第三个误读：做完就一劳永逸。分类法会随着业务变化而失配，术语会随着市场变化而漂移，记忆会随着时间累积而变脏。这是一件需要有人定期维护的事，跟AI运营的治理层是同一类工作。

上下文从来不是中立的，这句话该怎么理解？

这是NN/g那篇的收尾，也是整件事的分量所在。

我们在设计上下文时做的决定，塑造了系统怎么解读任务，并直接影响它的输出。这些决定包括三样：我们选的命名、我们定义的关系、我们编码的约束。

这些都不是中立的决定。它们决定了意义如何被构造、结果如何被产生。这是设计工作，就该按设计工作来对待。

说得更直白些：当你把某个产品分到某个类目下，你就已经决定了它在哪些问题下会被想起来；当你选择用行业术语而不是客户的话，你就已经决定了哪一类人能找到你。这些选择每天都在发生，只是大多数时候没人意识到自己在做选择。

AI带来了新工具，但底层挑战没变。我们仍然在为人的目标组织信息，区别只在于，现在AI系统也是一个主动参与者，它解读你摆出来的结构，然后照着行动。

这套东西和SEO到底是不是同一件事？

有重叠，但不是同一件事，混为一谈会让两边都做不好。

重叠的部分：都关心信息怎么被组织、术语怎么统一、结构怎么让机器读懂。分类清晰、术语一致、废弃内容及时清理，这几件事对搜索引擎和对AI系统的好处是同一份。

不重叠的部分：SEO关心的是排名和点击这条链路，它的度量是位置和流量；上下文架构关心的是系统解读得对不对，它的度量是答案准确率。你可以有一个排名很好但AI答不对的站，也可以有一个AI客服很聪明但搜索毫无存在感的产品。

机器优先架构那篇讲的是网站怎么改造才让智能体能操作，内容分层架构讲的是同一份内容怎么同时伺候两套引擎。这篇讲的是更上游的那件事：这些内容在被写出来之前，概念本身该怎么组织。

三件事叠起来才完整。只做最上游的会显得务虚，只做下游的会一直在打补丁。

上线前，照着这张清单把上下文过一遍

不长，十条，逐条能回答就算过关。

• 核心概念有没有一份主术语表，别称是不是都挂在主术语底下
• 同一个概念在官网、产品页、帮助中心里的叫法是不是一致
• 分类有没有互斥，需要多维度的地方是不是改用了标签
• 分类深度是不是控制在三层以内，同层兄弟节点有没有超过七个
• 文档有没有状态和时效字段，检索时能不能按字段过滤
• 已停用、已废弃、已被替代的内容处理掉了没有
• 技能和工具的描述里，有没有写清仅当什么情况下使用
• 工具描述用的是用户的话还是工程术语
• 记忆有没有分类型，哪些跨会话、哪些本轮即焚有没有明确
• 有没有一份二十条起步的评测清单，改动前后跑得起来

十条里超过五条答不上来，就别急着上新功能，先把这十条补齐，性价比比什么都高。

常见问题解答

上下文架构和上下文工程到底谁管谁？

不是谁管谁，是两层活儿。上下文工程搭的是管线和组件——检索怎么实现、工具怎么接、记忆存在哪儿，这些归工程。上下文架构定义的是住在这套管线上面的信息结构——哪些概念该进来、怎么命名、彼此什么关系、该记住还是该忘掉，这些归信息架构。NN/g用建筑打的比方很贴切：工程师保证水电通、结构稳，建筑师决定这栋楼是干什么用的、人怎么在里面走动。两者缺一不可，但顺序上先有结构再有实现，返工会少很多。

我不做AI产品，只做独立站，这套原则对我有用吗？

有用，而且是反过来用。当用户在ChatGPT或者AI概览里提问时，模型会去检索一批网页塞进它的上下文窗口，你的产品页、帮助中心、对比内容就是那份上下文的组成部分。你控制不了它的检索管线和排序逻辑，但你完全控制喂进去的那份材料长什么样——术语统不统一、废弃内容清没清、分类对不对得上用户的问法。这四条原则里，标签对齐和清理废弃这两条，对独立站的收益比对内部AI系统还直接。

为什么塞更多资料进去，AI反而答得更差？

因为每个元素都在竞争模型的注意力，模型跟人一样会被信息过载影响。你塞八十份文档进去，它未必挑得出最该用的那三份，反而可能被某份措辞强硬的旧文档带偏。结构糟糕的上下文还会带来三样额外代价：拖慢响应、抬高token成本、让输出变得不稳定。真实场景里，结构良好时检索回三千个token就够用，结构混乱时可能拉回一万五千个半相关的内容，多出来的部分每一轮都要重新付费，会话越长这个雪球滚得越大。

分类法和本体的区别，一句话怎么说清？

分类法回答这个东西属于哪一类，本体回答这个东西跟那个东西是什么关系。分类法是树，有明确上下层，作用是缩小检索范围；本体是网，边可以任意连，作用是支持意图推理。做错的代价也不同：分类法错了会捞不到或捞太多，本体错了是捞到了但推理跑偏。落地顺序建议先分类法后本体，前者便宜、见效快、错了好改，后者贵一些但决定系统能不能真的推理而不只是检索。

技能包和工具的命名，有没有可以照抄的规矩？

有三条。第一，用动词加宾语命名，比如重置密码，别用密码管理这种名词短语，前者是动作后者是筐。第二，描述里写触发条件而不是能力范围，把用户可能说出口的几种说法都列进去，比如无法登录、被锁定、需要重置密码。第三，每条描述加一句仅当开头的边界声明，逼自己想清楚这个技能什么时候不该被叫起来。之所以命名这么要紧，是因为技能默认只把名字和描述加载进上下文，完整内容要等被调用时才展开——名字含糊，后面写得再好也没机会被打开。

怎么判断改动真的有效，而不是自我感动？

固定一份问题清单，改动前跑一遍记录答案，改动后再跑一遍，同一批人盲评，落到具体条目上看哪几条从错变对、哪几条从对变错。清单从二十条起步就够用，稳定之后扩到一百条左右，再多边际收益就下降了。组成上七成常见问题、两成边缘情况、一成应该被拒答的问题，最后那一成测的是护栏。要有心理准备会出现从对变错的条目，改分类法这类动作有副作用，目标是净收益为正而不是零副作用。

长上下文模型出来之后，这套结构还有必要吗？

更有必要。窗口变大解决的是容量问题，结构解决的是歧义问题，两者不能互相替代。就算你能把整个知识库一次塞进上下文，系统面对三份互相矛盾的密码重置流程，仍然不知道该信哪一份——这只能靠有人明确告诉它优先级。而且窗口变大之后诱惑也变大了，干脆全塞进去的做法会让没有结构的团队输得更快，因为噪声占比会随着塞进去的量同步上升。

权威参考资料