帮助中心的结构：按任务组织，不按功能组织

用户不会按你的功能菜单找答案，他会按自己正在做的事找。

一、三十篇文档，两次点击内找不到一篇

许澄的排班工具做了两年，帮助中心有三十多篇文章，按左侧菜单排：账号、门店、员工、班次、报表、设置。她自己用起来很顺，因为那就是她写代码时的模块顺序。

直到她请三位客户做了一次找答案测试：给一个任务，看对方多久能找到对应文章。任务是「把下周的班次复制到再下一周」。三个人里有两个先点进「班次」，再点「模板」，再点「复制」——路径存在，但要三次点击；第三个人直接放弃，回头来问她。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

她后来把目录整个重排：不再按模块，而按「你正在做什么」分成四层——第一次使用、日常任务、出问题了、查资料。同一篇文章可以出现在两个入口下，但只有一个主位置。重排之后，那个复制班次的任务变成「日常任务 → 排下一周的班 → 复制上周」，两次点击到达。

结构不是给作者看的，是给一个着急的人看的。 他不想理解你的产品有几个模块，只想确认「我这件事有没有人写过」。

二、四层信息架构：从「第一次」到「查资料」

帮助中心的内容看起来杂，其实只有四种用途。按用途分层，比按模块分组稳定得多。

「开始」层要短。 它的目标只有一个：让新用户在十分钟内完成一次有价值的事。超过五篇，说明你在把任务层的内容往前塞。

「任务」层是主体，也是最容易被写成功能说明书的地方。 每一篇的标题应该是用户会说的话，比如「把上周的班次复制到下周」，而不是「班次模板功能说明」。

「故障」层不是用来解决故障的，是用来分流故障的。 它要把用户送到正确的检查步骤或正确的入口，而不是承诺「按这里就能修好」。

「参考」层可以慢一点更新，但必须准确。 套餐限制、字段含义、退款政策一旦写错，会直接变成账单类工单。

层级之间允许交叉链接，但一篇文档只能有一个主归属。主归属决定它在导航里的位置，交叉链接只负责「相关阅读」。没有主归属的文章，最后会同时出现在三个地方，然后三个地方都过期。

三、一页一任务：页面模板的六个位置

结构定好之后，每篇文章的骨架要统一，否则用户每次都要重新适应。

首段的适用条件是防止误自助的关键。 「仅适用于按小时计费的套餐」「仅桌面端」「需要管理员权限」，这三句话写在首段，能挡掉大量「照着做但做不了」的工单。

成功标志要可观察。 「保存成功」不算，用户看不到；「列表里出现一条状态为已发布的记录」才算。写不出可观察的成功标志，通常说明作者自己也没跑通过这条路径。

出口要固定在同一个位置。 每篇文档的末尾都有「仍未解决」按钮，点开是一个预填了当前文章标题的工单表单。位置固定，用户第二次就知道去哪里。

四、五个入口、提交前分流与覆盖率

帮助中心不是只有首页一个入口。用户会在五个地方产生疑问，每个地方都要能两步内到达答案。

应用内帮助按钮不要直接跳首页。 首页要求用户重新描述问题，等于把成本推回给他。更好的做法是按当前页面映射三篇候选文章，加一个「都不是，联系我」的出口。

提交工单前的分流是拦截率最直接的测量点。 用户点「联系我们」之后，先不要给表单，而是让他选一个问题类型，然后弹出两到三篇候选答案，最后才是「仍未解决，继续提交」。这一步能同时做三件事：拦住本可自助的问题、给工单打上准确的类型标签、让提交者知道你已经写过什么。

分流页最多两级。第一级选类型（怎么用、配置、故障、账单、其他），第二级给候选文章。超过两级，用户会直接乱点，数据也就失去意义。

「其他」必须保留。 没有「其他」，用户会把自己归类错，你就再也分不清哪些问题是内容缺口。

结构做完要能回答一个数字：现有内容覆盖了多少个真实任务。

先列出上个月工单对应的任务清单，本例是 30 个任务；再看帮助中心里有主归属页面的任务，本例 24 个。覆盖率 24 ÷ 30 = 80%。剩下 6 个任务对应 36 张工单，就是下一批要补的内容。

任务清单 30 个（来自上月工单归类）
已有主页面 24 个
覆盖率 = 24 ÷ 30 = 80%

缺口 6 个任务，月工单 36 张
按单张 12 分钟计 = 36 × 12 = 432 分钟 = 7.2 小时/月
补 6 篇 × 30 分钟 = 3 小时（一次性）

缺口要按工单量排序，不按你的写作兴趣排序。 六个缺口里，可能有一个任务占了 20 张工单，其余五个各占三四张。先写那一个，回本最快。

旧文章迁移时保留旧链接。 重排目录会让一批 URL 失效，凡是曾经出现在邮件、应用内提示或外部搜索结果里的链接，都要做一次重定向。做不到重定向，就保留旧页面并在顶部加一句「本文已迁移到新地址」。

导航深度控制在两次点击以内。 首页 → 层级页 → 文章，正好两次。三层以上，用户会在第二层放弃，然后回到搜索框里输入一句完整的话。

目录不要超过七个一级项。 超过七个，用户开始逐个点开看，而不是选择。四层架构加一个「搜索」，已经够了。

五、行动清单与复算验收

先把任务清单列出来，再动目录。顺序反过来，你会把现有文章重新摆一遍，缺口一个没补。

• 从最近一个月工单里提取「用户想完成的任务」，去重后得到任务清单。
• 给每个任务标上月工单数，按数量从高到低排序。
• 检查每个任务是否有唯一主归属页面，统计覆盖率。
• 把现有文章按「开始、任务、故障、参考」四层重新归类。
• 为每篇文章补齐首段结论、成功标志、失败处理与出口。
• 在五个入口中至少落地三个，确认两步内可达。
• 在「联系我们」前加一层候选答案分流，保留「其他」选项。
• 为迁移过的旧链接设置重定向或顶部提示。

验收标准：给定任意一个上月出现过的任务，你能在两次点击内到达主页面，且该页面首段写明了适用条件与成功标志。

使用边界与实操验收

本文处理的是帮助中心的结构与入口，不涉及文章正文怎么写、排查树怎么画、搜索怎么调，那些在后面几篇。

「按任务组织」本身不是本文的贡献。 已有文章讲过这个原则；本文把它落成四层、六个页面位置、五个入口与一个覆盖率算法，解决的是「知道原则之后具体怎么摆」。

四层不是唯一答案。 产品极简时，两层就够；开发者工具可能需要把「参考」提前。但无论几层，一级项不要超过七个，导航深度不要超过两次点击。

覆盖率的分母必须来自工单，不能来自功能列表。 用功能列表算覆盖率，很容易做到 100%，却对工单毫无影响。

关键参考与核验范围

核验日期：2026-10-25。以下链接仅作为公开文档入口，用于核对内容组织与导航设计的通用概念，本文未逐条引用其内容。

• Diátaxis 文档类型框架 ：用于核对教程、操作指南、参考与解释四类内容的边界。
• GOV.UK 内容设计指南 ：用于核对按用户任务组织内容与导航层级的一般做法。

引用口径。 本文只借用两份材料的组织思路：内容按用户要完成的事分类，导航层级要收敛。文中的 30 个任务、24 个页面、36 张工单全部来自教学假设，与上述材料无关。

核验范围。 核验的是「四层架构 + 一页一任务 + 五入口 + 覆盖率」这套结构是否仍然可操作，不是比对某个建站工具的功能。工具会变，层级原则不变。

如何自行复核。 找三个真实用户，各给一个任务，记录点击次数与耗时；任何一个人超过两次点击或超过一分钟，就说明结构还需要调整。

系列导航

• 上一篇：自助支持是一本账：工单分类、可自助比例与四笔成本
• 下一篇：FAQ 的写法：从工单原话到可执行答案
• 回到目录：一个人的自助支持：帮助中心、排查树与工单减少
• 相关阅读：SaaS 帮助文档：早期文档不是附属品，而是可复制交付