要用 AI 构建网站信息架构，应从人们实际要完成什么的证据出发，而非丢给模型一句空白的网站地图提示。先冻结内容清单和用户任务登记表，再让 AI 提议分组、层级、标签和备选路径。把每个提议都当作假设：是否采用，由卡片分类、树测试、任务走查、无障碍审查和负责人共同决定。

通用 AI 工作流说明如何约束证据并核验输出。本文将其用于信息架构（IA），即帮助人们找到并理解网站内容的组织、命名和路径。它不允许 AI 编造用户需求，也不允许宣称未经测试的导航已经成功。

关键要点

从研究、搜索日志、客服问题和观察到的行为中提炼任务。

把任务、内容、页面、功能、标签和导航组件区分开。

让 AI 给出多个候选结构，并为每个选择引用证据。

保留相互冲突的心智模型，而不是把它们平均掉。

用有代表性的参与者和真实任务测试可查找性。

为获批的 IA 定版本，并保留未解决的证据和例外。

如何用 AI 构建网站信息架构并以真实任务为基础？

有用的项目产出的是决策轨迹，而不只是一张图。核心产物包括：冻结的内容清单、证据登记表、规范化的任务陈述、候选结构、标签词表、测试方案和结果、例外日志，以及获批版本的层级结构。

以下概念要分开：

概念	示例	为什么重要
用户任务	更换已过期的付款方式	用用户的语言描述结果
内容	资格规则和操作说明	完成任务所需的信息
页面	账单设置帮助页	一种可能的承载容器
功能	更新银行卡表单	交互能力，而不是类别
标签	付款与账单	必须能被理解的路标
导航路径	账户 → 付款 → 更新银行卡	一条路线，不能证明任务容易完成

组织架构图不自动等于 IA；数据库 schema、产品团队职责图或现有 URL 列表也不是。这些输入可解释约束，但结构应支持用户理解的语言和关系。

用研究证据奠定架构基础

第 1 步：冻结目标、范围和内容清单

写一份项目表头，记录网站或栏目、受众、支持的 locale、业务与用户目标、研究期间、分析数据期间、内容快照日期、已知技术约束、审批人和排除范围。注明这项工作是诊断、局部改版、迁移还是全新结构。

盘点范围内的每个 URL 或内容对象，包括标题、用途、负责人、格式、受众、locale、生命周期状态、入站链接、经批准的流量或搜索证据，以及重复或质量备注。探索阶段不要删除看似无人使用的内容，把它标记出来，留待单独治理决定。

在让 AI 重新组织之前冻结清单。否则新页面、重定向或编辑改动会让候选结构无法比较。清单不完整时标出缺口，不要让模型按一般网站惯例填补。

第 2 步：建立真实用户任务的证据登记表

GOV.UK 建议团队先了解用户需求，而不是假设它们。［1］把每条研究观察转成可追溯的任务记录，同时在规范化措辞旁保留原始证据。

有用的证据可包括：有主持的访谈、情境调查、可用性测试、站内搜索词、客服工单、来电原因、反馈、失败的旅程、无障碍研究和观察到的变通做法。用户访谈综合流程可以帮助整理笔记，但只有获批的研究才能进入登记表。

每个任务记录：

稳定的任务 ID 和中立的陈述；
受众和所处情境；
预期结果和证据来源；
按既定尺度衡量的频率、重要性或严重程度；
相关的前置任务和后续任务；
locale 或地区差异；
不确定性、矛盾之处和研究缺口；以及
研究负责人和审批状态。

没有证据时，不要把“推广高级服务”这类利益相关者的要求变成用户需求；不要把缺乏上下文的搜索词当作完整任务；也不要让 AI 编造人物角色、频率、动机或痛点。

第 3 步：画树之前先梳理完整问题

用户常在一个更大问题的中途进入网站，之后又转到别处。GOV.UK 关于梳理用户完整问题的指南鼓励团队了解用户在与服务交互之前、之中和之后的各个步骤。［3］记录依赖和相邻任务，但不要声称网站负责所有环节。

客户旅程地图可以展示顺序和交接，而 IA 描述的是分组和可查找性。不要把旅程阶段直接转换为顶层导航。“发现、决定、购买、使用”也许是有用的分析框架，对想补办丢失银行卡的人却是糟糕的标签。

还要把任务陈述和实现需求分开。用户故事与验收标准描述的是产品行为，并不自动决定页面边界或菜单层级。

第 4 步：让 AI 给出多个候选分组，而不是一个答案

提供冻结的任务登记表、获批的清单字段、约束和输出 schema。从研究摘录中删去个人信息，并在提示中使用任务 ID。一条有边界的指令可以是：

仅使用所提供的任务和内容记录，提出三种替代分组。
每个分组和标签都引用支持的任务 ID。保留相互冲突的
模式，把缺乏支持的放置标为未解决。不要新增用户、
需求、页面、功能、研究发现或成功结论。返回层级、
交叉链接、备选标签以及需要研究人员回答的问题。

候选方案之间要有实质差异，例如任务导向、对象导向和生命周期导向。要求模型解释取舍，并指出需要多个入口的条目。拒绝虚构的证据、没有引用的放置、重复的 ID、遗漏的清单条目，以及超过约定深度的层级。

NIST 的生成式 AI 概况强调全生命周期的风险管理和评估。［4］在这里即是记录输入和模型配置、校验输出 schema、用真人测试提议，并在上线后监控获批结构。

如何测试、审批并维护结构？

第 5 步：与领域负责人审查层级和标签

在用户测试之前审查候选结构。除非研究表明用户理解并会寻找内部部门名称，否则去掉它们。检查同级条目概念上是否并列、标签是否重叠、有没有类别沦为“杂物抽屉”。

GOV.UK 的服务范围界定指南，是围绕用户想要达成的目标、而不是现有组织边界来规划服务。［2］应用这一原则时，别假装每个网站都是政府服务：用用户的说法定义任务及其边界，再单独记录组织约束。

为每个提议的标签维护一份小型词表，包含定义、纳入和排除的内容、测试过的备选说法、各 locale 的措辞和负责人。标签跨语言时，本地化术语表流程很有用。直译可能合并本应区分的概念或制造新歧义，因此要按 locale 分别批准标签。

第 6 步：做卡片分类并保留分歧

卡片分类有助于研究参与者如何为代表性条目分组，以及如何给这些分组命名。开放式分类用于发现模式，封闭式分类用于评估既定类别，两类问题都重要时可用混合式。卡片取自真实任务和内容，避免会泄露预期答案的内部术语。

记录招募标准、参与者背景、任务材料、主持规则、完成数据、分组标签、条目移动、评论和无障碍便利安排。去除身份标识后 AI 可总结模式，但研究人员应检查原始结果和离群值。

不要把所有参与者压缩成一个“平均用户”。新客户和资深管理员可能有不同的心智模型。有争议的卡片可能意味着有多条合理路径、标签含糊、任务是复合的，或招募对象有差异。把这些假设留到下一轮测试。

第 7 步：用真实任务做树测试

树测试去掉页面设计，只问参与者在一个纯文字层级中会去哪里找。编写描述目标、但不重复目标标签的情景。开展研究之前，先确定正确目的地和可接受的备选路径。

衡量完成率、直接性、首次选择、回退，必要时还有用时，以及定性解释。按任务和相关受众拆分结果，而不是依赖一个总体分数。高平均值可能掩盖一个几乎人人都找不到的关键任务。

当搜索引擎、深层链接、账户面板或帮助链接是常见入口时，要测试多个入口点。主菜单只是其中一条访问途径。不要因为参与者反复猜测后终于找到答案，就宣称层级有效。

第 8 步：走查内容、无障碍和边界情况

用真实内容检查拟议的树落地后是否站得住。对每个优先任务，从可能的入口走到结果，检查页面用途、标题层级、链接文字、面包屑、搜索词、重定向和下一步操作。

审查键盘和屏幕阅读器导航，但不要把无障碍简化为一个菜单组件。清晰的标签、可预期的结构、描述性标题、多条路径和持续维护的页面关系，都有助于定位。研究中要纳入有相关无障碍需求的人。

做结构检查，找出孤立页面、循环路径、同名但含义不同的标签、只有一个且未作解释的子项的类别、放在多个父级下却没有规范归属的页面，以及不再服务于任何获批任务的内容。把这些问题交给人处理，不要让 AI 悄悄“修复” URL 或重定向。

第 9 步：审批架构并定版本

决策记录应包括内容清单快照、任务登记表版本、候选结构、研究计划、参与者标准、结果、选定的层级、标签词表、交叉链接、被否决的备选方案、未解决的风险、内容负责人的决定和生效日期。

研究团队负责解读用户证据；内容设计负责标签和页面用途；产品和服务负责人批准范围和取舍；工程团队确认技术可行性；无障碍专家和参与者验证相关障碍。模型不能替代这些职责。

上线后，监控站内搜索的改写、零结果搜索、客服联系、任务完成证据、常见回退、失效链接、孤立内容和特定 locale 的问题。内容、受众、产品或导航有实质变化时应重新测试，而不只是让 AI 再生成一张网站地图。

常见失败方式有哪些？

从“生成网站地图”开始，而没有任务证据： 先建立一套可追溯的任务和内容证据。
按部门组织网站： 按用户的理解来分组，职责归属另行记录。
把旅程阶段直接转换为导航： 用旅程表达顺序，用 IA 表达分组。
只接受一个 AI 结构： 比较多个替代方案，保留相互冲突的心智模型。
不带任务情景地测试标签： 使用真实的情景和预先确定的目标位置。
只优化主菜单： 把搜索、深层链接、交叉链接和上下文入口都纳入考虑。
把最终成功算作通过： 检查直接性、首次选择、回退和参与者的解释。

总结

冻结目标、证据期间和完整的内容清单。
从获批的研究和观察到的行为中提炼任务陈述。
让 AI 给出附引用的候选结构、备选方案和未解决的问题。
审查层级和标签，不把组织架构图照搬进来。
通过卡片分类、树测试、任务走查和无障碍研究进行验证。
批准并监控有版本的 IA，由人承担问责。

常见问题

AI 能从现有 URL 直接创建网站地图吗？

它可以提议重组，但 URL 反映的是当前实现，不一定体现用户需求。应把冻结的清单与真实任务证据结合起来，要求引用，并测试得出的结构。

网站层级应该有几层？

没有通用数字。使用能表达有意义关系、并支持经过测试的路径的最浅结构。比起深度，易懂的标签、合理的分组和顺利完成任务更重要。

主导航应该遵循客户旅程吗？

不一定。旅程描述的是顺序，而导航类别帮助人们从不同起点找到东西。应测试生命周期式的标签是否符合你的受众实际查找信息的方式。

搜索能代替信息架构吗？

不能。搜索依赖内容结构、标题、元数据、词汇和得到维护的目标页面。人们也会浏览、经深层链接进入，落地后还需辨明方向。

卡片分类参与者意见不一致怎么办？

保留分歧。它可能揭示不同的受众、多条合理路径、含糊的卡片或重叠的概念。用后续研究和树测试处理，不要强行制造共识。

AI 能根据利益相关者想法写用户任务吗？

AI 可以帮助改写一个有记录的假设，但不得把它变成研究证据。清楚标注哪些是假设，并在它们影响架构之前，用有代表性的用户加以验证。

如何验证本地化导航标签？

维护获批的概念和各 locale 的术语，再请母语使用者在情境中测试标签。不要依赖直译，也不要假设一个 locale 的类别边界可以原样移植。

何时再次审查 IA？

在受众、服务、内容、locale 或平台发生实质变化后，以及证据显示存在可查找性问题时进行审查。在正式研究轮次之间持续做轻量监控。

**免责声明：**本文提供一般信息，不能替代用户研究、无障碍评估、法律审查，或专业的内容与产品判断。

来源

GOV.UK Service Manual, Start by learning user needs: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs
GOV.UK Service Manual, Scoping your service: https://www.gov.uk/service-manual/design/scoping-your-service
GOV.UK Service Manual, Map a user's whole problem: https://www.gov.uk/service-manual/design/map-a-users-whole-problem
National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 6 日。

如何用 AI 构建网站信息架构（IA）：从任务到测试