核心观点
后端出身的作者开始用 AI 搭前端页面：增删改查、筛选、状态标签，一次全给，第一眼「挺像那么回事」。真正用起来就发现别扭——信息很多却不知道先看什么，关联资源散在各处，下一步要做什么得靠人自己拼。组件没选错，错在把页面当成 CRUD 来做：数据齐了，页面却没帮用户排出理解和行动的顺序。
信息架构：先回答三个问题
看高密度页面，先别急着找组件，先把三件事想清楚：
- 用户打开页面时，最重要的是看到什么？
- 为了理解主信息，还要看到哪些关联资源、上下文？
- 用户看完后要作出什么判断、执行什么动作？
这三个问题过完，再回头看表格、看板还是日历，通常不会选得太偏。
CRUD 的边界
列表和详情页擅长回答「这条记录怎么增删改查」，却不回答「用户进来先看什么、需要什么反馈、依据哪些信息做决定」。API 只负责把数据和操作交出来，页面还得把关系摆清楚：先看什么、比较什么、在哪里操作。
同一个数据，不同的读法
GitHub Projects 把同一批任务放进表格、看板、路线图，数据没变，用户读它的方式变了：排分工用表格，让比较发生在固定位置；跟进度用看板，按状态分组，先找阶段再看条目；排交付用路线图，时间轴上立刻看出区间是否重叠。页面主要服务一种任务，就先把这一种做好——多一种视图，筛选、状态和操作就多一份维护成本。
怎么选信息结构
不能因为 API 返回一个数组就顺手做表格，也不能因为路由里有一个 ID 就默认做详情页。选择路径是：先看系统里有哪些对象和关系，再看用户要完成什么，接着判断信息本身的结构，最后落到表达方式。选完再走一遍真实操作：最常比较的信息有没有放在一起，最常做的操作是不是就在旁边。
六种「反列表/详情」的表达骨架
- 卡片网格：以识别对象为主，图片是主要入口，适合挑素材、选模板
- 看板：让阶段一眼可见，列名本身就在表达进度
- 日历：把时间占用摊开，适合排班、会议室预订这类真和「时间占用」有关的事
- 仪表盘：按问题组织指标，而不是摆一排大小相同的卡片
- 层级树：保留「它属于哪里」的归属关系
- 状态墙：先发现异常在哪里，再进细节
指南共整理了 19 种表达骨架，配套 demo 用同一套技术栈实现，对照时更容易看出差别来自信息编排，而不是组件库换了。
把指南交给 Agent
这份指南可以直接放进仓库，作为 AI 检查前端页面的依据。人先想清楚业务意图，AI 负责补方案、找不一致、做修改。检查报告要落到具体位置：哪些信息该放在一起、现在分散在哪里、准备怎么改，而不是一句「信息层次不清晰」。
个人点评
这篇文章最戳我的点是「代码写出来，页面不一定就设计好了」。用 AI 写前端时这个差别尤其明显：它能补组件、样式和交互，却不知道用户来到页面后最该先理解什么。作者把「页面看着不对」这种感觉，拆成「主信息没立住、关联信息散了、操作放错了位置」三个可检查的问题，AI 才有办法真正参与改造——这和我做内容运营时「把模糊的验收标准变成可勾选的清单」是同一个思路。19 种表达骨架的参考表也值得存一份，下次让 AI 搭后台页面时直接拿来当检查表。
原文链接：高密度页面怎么组织：一份信息呈现指南（作者：Jingchao @alswl）
转载声明：本文转载自 Jingchao 的 X 帖子，内容有删改，版权归原作者所有。