01
入口与定位
先回答你是谁、给谁、为什么值得继续。这里主要解决陌生用户的第一眼判断。
- 首页定位
- 对象说明
- 唯一优先的下一步
五层结构
这套知识，至少应该被分成五层。
如果不先分层，首页就会同时承担解释、教学、证明和导航，最终谁也服务不好。
02
旅程与触点
不要只看单页，要把发现、决定、执行、等待、恢复连成完整旅程。
- journey map
- service blueprint
- 触点清单
03
系统与状态
系统在做什么、做到哪了、失败了怎么办，都应该持续可见。
- 状态反馈
- 日志与进度
- 异常说明
04
交接与恢复
跨角色、跨系统、跨 agent 的时候，要让 owner、回执和恢复路径继续可见。
- handoff owner
- 人工接手
- 恢复路径
05
目标与治理
最后把体验判断拉回目标、指标和验证，不然知识库就会停在理念层。
- 目标对齐
- 指标映射
- 验收定义
全链路视角
首页只是入口，真正的体验是一整条链路。
用户从第一次看见你，到决定继续，到真正使用，再到出错后恢复，中间任何一段没接住，体验都会断。
flowchart LR
A["第一次看见"]
B["准备继续"]
C["开始使用"]
D["切到别处"]
E["出了问题"]
A --> B
B --> C
C --> D
D --> E
第一次看见
还不知道这是不是给自己的
准备继续
不知道下一步该做什么
开始使用
看不见进度，也不知道为什么卡住
切到别处
不知道现在轮到谁处理
出了问题
不知道怎么回退、补救或找人接手
用户心里会想
- 这是给我的吗？
- 我该先做哪一步？
- 现在做到哪了？
- 这一步是谁在处理？
- 出错以后我还能怎么办？
页面上要说清
- 你是谁、适合谁、值不值得看
- 只给一个清楚的下一步
- 持续告诉我进度、结果和异常
- 切换系统或角色时明确说明
- 直接给出补救和人工入口
系统背后要接住
- 定位、导航和信息层级一致
- 流程、通知和规则别互相打架
- 进度、日志和失败原因能被看见
- 交接时知道谁接手、谁负责
- 支持回退、补录和人工介入
结构预览
用矩形结构图先看清每类问题的组织方式。
这里不再直接陈列历史图，而是用统一的黑白结构预览把角色、语言、研究、交接和证据关系说明清楚。
Atlas
站点总览图
先把首页、章节、方法、案例、技能包和来源的责任分开，再决定从哪开始看。
这个站要先帮用户做哪一个决定？
Roles
用户与角色图
帮助团队先回答你在为谁设计，以及这些人分别最在意什么。
这条体验链里到底有谁在看、谁在做、谁在接手？
Mental
概念与理解图
把表达形式、术语和预期结果放在同一视图里，帮助你找到误解从哪里开始。
用户现在看到的，和他以为自己看到的，是不是一回事？
Methods
研究与结构图
告诉团队研究问题、方法和产出物怎样真正接到一起，而不是各做各的。
你现在缺的是页面，还是还没整理清楚研究与结构？
Service
服务链与交接图
把触点、状态、owner 和恢复放进一条看得见的服务链。
问题到底出在页面，还是出在页面背后的交接与恢复？
Behavior
行为与动机图
帮助你区分用户为什么开始、为什么停下、为什么愿意继续。
真正驱动用户行动的，是按钮，还是动机与反馈？
阅读路径
不同任务，应该走不同路径。
知识站不该只有一种线性阅读方式。它更像一个服务入口：不同的人带着不同任务进来，应该被分流到最合适的下一页。
4 个判断点
如果你还不知道怎么判断，可以先看这 4 条。
它们不是抽象理论，而是最常决定“第一轮就改对”还是“反复来回改”的那几条底线。
一眼看懂
首页定位第一次进来的人，要能马上知道你是谁、做什么、适不适合自己。
5 秒内能不能说清这个页面是干嘛的？
一直看得见
状态反馈等待、执行、成功、失败都应该可见，不能让人一直靠猜。
如果任务要跑 30 秒，用户会不会开始慌？
关键动作能确认
确认与控制越自动化，越要让人能确认、修改、暂停和拒绝。
高影响动作之前，人能不能先确认？
出错后能补救
失败恢复系统错了以后，要能回退、补救、切人工，而不是把人困住。
一旦失败，用户能不能知道下一步？