互联网会议研究：从跨年名单到可复算的热度指标

这项研究实际包含两条不同的数据管线。第一条从连续多届公开名单中识别重复出现的企业、机构和角色；第二条把搜索、媒体与社交平台的月度数据合成为会议热度。前者解决“谁持续出现”，后者尝试回答“会议期间的公共关注是否上升”。

Confluence 附件让处理过程比 Jira 状态更清楚，但也暴露了一个重要问题：文件存在、任务完成和指标经过验证，并不是同一件事。

名单管线：不是求交集，而是先对齐实体

【文档事实】早期页面记录了三类输入：会议官网名单、由公开机构汇总的四年名单，以及按年份收集的公开推送名单。附件并非一个最终文件，而是按阶段留下：

1. 原始嘉宾名单；
2. 企业与机构分类表；
3. 更新后的组织表；
4. 连续四年的逐年名单；
5. 某一年度剔除公共部门和企业后的其他机构分类；
6. 相邻两年重复主体及估值补充表；
7. 连续三年重复主体表；
8. 单年企业信息补充和多个年度分类结果。

这说明当时采用了“采集—分类—重整—跨年匹配—外部信息补充”的流水线，而不是一次性复制名单。

Jira 对交付字段的定义也很具体。【工单事实】企业被区分为上市与非上市，分别补充营收或最近估值；机构按地区分类；基金类主体计划补充投资数量与金额；公共部门和学者类角色则记录地区、职务或公开成就。这些字段服务于结构比较，而不只是名单展示。

实体对齐是结果可信度的核心

附件没有保存一套可执行的名称归一规则，但从“更新版组织表”和重复处理文件可以确认人工清洗发生过。合理的数据机制应把原始记录与规范主体分开：

~~~text 原始名称 + 年份 + 名单来源 ↓ 名称清洗：空格、全半角、公司后缀、职务文本 ↓ 候选匹配：标准名 / 别名 / 公开标识 ↓ 人工确认或保留歧义 ↓ 按规范主体计算跨年交集 ~~~

【分析推断】组织应保存标准名、别名、类型、地区和观察期；个人记录则只需内部随机标识及角色，不应在公开文章中建立可追踪画像。每次合并还应留下匹配依据和审核状态，否则简称相同会造成误合并，更名或中英文混用会造成漏匹配。

财务字段也需要时间语义。“最近估值”不是企业的固定属性；营收、投资数量、币种和汇率同样随时点变化。若缺少统计期间、估值日期、换算日和来源，跨年比较可能只是信息更新时间不同。

Jira 与附件出现了状态冲突

【工单事实】连续四届与连续三届的整理任务被标为完成，相邻两届比较仍是待办。【附件事实】工作区却存在一份相邻两年重复主体及估值文件。

最稳妥的解释不是直接判定任一系统错误，而是把状态拆开：附件证明某个阶段结果被生成；Jira 未完成可能表示它没有复核、没有补齐字段或没有被正式交付。这个冲突提醒我们，恢复历史项目时至少需要“已生成、已复核、已交付”三个状态，而不能以文件名替代验收。

热度管线：二十五张原始表如何变成月度指数

后续研究扩大到三类公开会议的横向比较。【附件事实】原始压缩包包含二十五张表，覆盖三场活动，并组合了国际社交平台、新闻稿聚合渠道、国内新闻媒体、搜索趋势和公开社交数据。另有会议日期、媒体权重、指数试算、国内外原始数据、综合结果与图表文件。

会议日期表覆盖五个年度的举办窗口，最终比较使用“举办月份”和“非举办月份均值”。这是一种事件窗口设计：先把不同来源汇总到月，再观察会议月份是否偏离当年基线。

媒体权重并非等权

媒体权重表给出了两组各三项权重。国内三项约为 0.396、0.274、0.330；国际三项约为 0.460、0.095、0.445。权重来自材料中记录的发行或基准数值，再归一到总和为 1。

若第 t 月第 i 个来源的计数为 c(i,t)，加权量可写成：

~~~text media_score(t) = Σ weight(i) × count(i,t) ~~~

【文档事实】综合表还出现了先分别归一化、再把三组来源各取三分之一的公式。某些搜索数据则以两个国家的人口占比合成区域值。也就是说，管线至少包含来源内聚合、尺度统一、来源间合成三层。

真正的问题是“热度”没有冻结成一个定义

指数试算表并列保留了多种方法：

• 以 10 为底的对数后乘以 20；
• 以 1.2 或 2 为底的对数；
• 最小—最大归一化到 0–10 或 0–100；
• 类似 z 分数的“减均值再除以标准差”；
• 占总量比例再乘固定常数。

这些不是同一个公式的参数微调，而是对“热度”含义不同的定义。对数变换压缩头部，最小—最大归一化依赖样本期极值，z 分数强调偏离常态，占比则强调同一时段的相对注意力。附件证明团队做过指标实验，却没有证明最终选择、冻结并验证了哪一种。

按现存综合表，较清晰的一条可复算路径是：

1. 每个来源按月聚合原始计数；
2. 对每个来源组做同口径归一；
3. 媒体组按权重合成，其他组保留独立得分；
4. 国内或国际的三个来源组各占三分之一；
5. 比较举办月得分与同年非举办月平均值；
6. 保存原始值、中间值、权重版本与最终值。

【分析推断】若重新实现，应先定义指数用途，再冻结样本窗口、缺失值规则和公式。用于检测单场会议的异常关注，可采用按来源标准化后的事件窗口差值；用于跨年绝对规模比较，则不能让每年分别做最小—最大归一化。

下面是依据附件公式整理的等价伪代码，不是历史采集程序。它刻意保留中间值，并对常数序列做显式处理：

def build_monthly_index(series_by_source, weights, event_month):
    normalized = {}
    for source, monthly in series_by_source.items():
        low, high = min(monthly.values()), max(monthly.values())
        if high == low:
            normalized[source] = {month: 0.0 for month in monthly}
        else:
            normalized[source] = {
                month: 100 * (value - low) / (high - low)
                for month, value in monthly.items()
            }

    score = {}
    for month in all_months(normalized):
        score[month] = sum(
            weights[source] * normalized[source][month]
            for source in normalized
        )

    baseline = mean(value for month, value in score.items() if month != event_month)
    return {"score": score, "event_delta": score[event_month] - baseline}

这个模型能说明什么，不能说明什么

“举办月高于非举办月”只能说明可观测渠道的同期关注发生变化，不能直接证明会议造成了变化。月粒度会混入同月其他新闻；不同会议持续天数不同；平台覆盖和采集规则也可能逐年变化。

原始计数更不能直接等同于影响力：

• 搜索量表达信息需求，不等于正面评价；
• 新闻量受媒体供给和转载机制影响；
• 社交量可能被头部账号或自动转发放大；
• 参会人数表达活动规模，不代表公共传播。

因此，公开结果宜同时展示分来源曲线、权重和事件窗口，不只发布一个总分。还应做去掉任一来源、改变对数底数和改变窗口长度的敏感性分析；排名若随参数大幅变化，就不应写成稳定结论。

代码交叉核验：没有把无关爬虫当成项目实现

【代码事实】GitLab 中存在一个时间相近的新闻采集仓库，使用爬虫框架抓取标题和详情，并写入数据存储。但其关键词是另一组商业主题，提交历史与会议附件也没有关联。

因此，本文没有用这个仓库反推会议数据的采集实现。二十五张表只能证明多渠道数据被整理，无法证明采集由哪套程序自动完成，也无法核验限流、去重、失败重试和平台口径。更晚年份的会议演示材料同样只证明主题被继续讨论，不能证明它复用了或验证了这套指标。

可复用的技术与研究经验

• 名单分析先做实体对齐，再做交集；原始名称、规范主体和匹配证据必须分层保存。
• 参与记录、经营指标和估值都要带观察时点，连续出现不能推断合作、投资或立场。
• 原始文件、阶段结果、复核结果和正式交付应有不同状态。
• 综合指数必须公开转换方法、权重来源、样本窗口和缺失规则。
• 排名发布前要做参数敏感性和来源剔除测试；不稳定的名次只适合作为探索结果。
• 自然人名单即使来自公开渠道，也不应在再次聚合后对外形成长期轨迹。

证据账本

本文不公开会议名称、参会者姓名、机构清单、内部链接和账号信息；个人只以角色类别出现。研究结论限定为资料恢复，不把名单出现推断为现实关系，也不把试算指数描述为正式影响力评价。