G1.07.1content inventory设计研究
架构工作始于已有内容的清点
别名: 内容清单 · content inventory · 先清点再架构
概念解释
信息架构的第一份材料不是导航草图，是内容清单（content inventory）：现有对象逐条登记位置、类型、所有者、更新日期、入口和是否仍被引用。架构是对这批对象的组织，不是对想象中理想内容的组织。不先清点就画树，画的是愿望结构，上线后被未登记的页面、PDF、旧活动和影子站点撑裂。
清单回答「我们到底有什么」。审计回答「这些东西是否还该在」。清点在前，评价在后；把评价混进第一次登记，会漏掉不想看见的对象。
机制
未登记的内容仍会从搜索、外链、书签和内部转发里冒出来。架构若只覆盖工作坊里提到的「主要页面」，那些冒出来的对象会变成无类目的孤儿，或被临时塞进最不像的桶。清点把隐藏的体量变成可计算的输入：类型比例、陈旧比例、无主比例，这些数字决定树需要几层、分面有没有字段可吃、哪些入口其实指向重复物。
从组织图或竞品导航倒推内容，会把没有对应对象的类目画出来，同时把有对象却没被想起的类目漏掉。清单切断这条倒推。
怎么研究
把清点本身当成方法，并测量「未清点就架构」的后果。
- 范式：爬站 + CMS 导出 + 搜索日志里出现但站点地图没有的 URL，三源对齐；再对比「基于清单的树」与「基于工作坊的树」在树测试和死链上的表现。
- 自变量：清单覆盖率（登记对象 / 实际可达对象）、是否包含下载文件与过期活动页。
- 因变量：上线后孤儿页比例、无类目对象被搜索命中的次数、类目下实际条数为零的空桶数。
- 方法论注意点：人工点开首页再往下走，会系统性漏掉深页和文件。日志和全站抓取不是可选的补充。清单的字段设计（类型、所有者、日期）会影响后续审计能否做，缺字段的清单只是 URL 列表。
边界
从零开始的新产品几乎没有「已有内容」，清点对象变成竞品、业务对象和将要迁入的来源，而不是自己的 CMS。个性化动态页无法逐 URL 登记，要改登内容类型与模板，而不是每一个实例。巨大站点只能抽样加优先队列（流量高、转化高、法规必须），但抽样方案必须写明谁被故意留下未登记，不能把未抽样当成不存在。
怎么落地
- 架构项目的第一周只出清单：URL 或对象 ID、类型、来源系统、最后更新、入口。不许同步出导航稿。
- 三源对齐：CMS、爬虫、搜索与外链日志。只在一个源里出现的，单独标记。
- 清单字段先够支撑后面的去重和过期判断，不要一上来做成完美元数据工程。
- 验证：随机抽二十个从站内搜索或外链到达的地址，是否都在清单里。缺一条，架构就还在对愿望结构工作。