周川：从新闻采集到产业链数据跟踪

工作画像

周川留下的产出，主要位于数据管线的前半段。 公开页面变成结构化记录之前，要先识别来源模板、抽取标题与正文、统一日期、补充公司标识，并把任务交给调度脚本。 当这些记录进入产业链研究后，还需要一张跟踪表说明数据到了哪一步。 这组工作像一座“进料站”：它不决定最后的研究结论，却决定后续系统拿到的是原料、残片，还是带来源与状态的可用记录。 这个比喻只描述产出位置，不推断个人性格或组织角色。

证据范围

匿名聚合记录覆盖 2018 至 2019 年。 Jira 只有少量明确关联事项，均属于数据与自然语言处理项目并由该化名承担。 Confluence 有百余个关联页面，其中多数是周报与工作事项，也包括产业链数据跟踪表和事件分析图谱版本记录。 Git 归并得到百余条提交署名，分布在多个仓库。 变化主要集中在公告与新闻数据仓，其他部分分布在新闻采集、股票、公司、社会组织、行业报告和产业链迁移仓库。 Git 身份证据同时包含完整提交标识命中和唯一名称或账户标识命中，因此总体标记为混合置信度。 提交署名只证明版本历史中的作者字段，不表示独立完成、代码审核或生产运维责任。 另有一座新闻仓库存在损坏对象。 它有一批提交元数据仍可读，但只有少数能够展开完整文件差异；其余记录没有被猜测分类。

项目地图

• 数据与 NLP：新闻模板、来源字段、PDF 与网页解析。
• 金融研究搜索：采集结果如何进入索引、筛选和段落阅读。
• 产业链知识图谱：企业、产业节点、资讯和事件如何连接。
• 数据生产流水线：批处理状态、失败补偿和上线门禁。
• 长尾工程资产：股票、公司、社会组织和行业报告等小型仓库。

来源页面→新闻提取器→标题正文日期→来源与公司字段

来源与公司字段→批量调度→搜索索引→段落阅读

来源与公司字段→企业资料合并→产业链节点→数据跟踪表

周报与跟踪表→阶段状态→事件分析图谱→项目复盘

失败或模板变化→日志与修订→新闻提取器

代表项目一：新闻提取与来源适配

Jira 中最具体的一项工作直接以新闻提取脚本命名，并被标记完成。 Git 的公告数据仓中，相关时期可见大量 Python 与 Shell 变化。 手写源码路径集中在来源 Spider、新闻提取、生产脚本和运行目录。 代表性变化包括增加新的公告问答采集、修改解析规则，以及在提取器中补充社交内容解析。 项目文章进一步说明其机制：提取器先按站点和页面规则选择模板，再抽取来源、标题、发布时间和正文。 相对时间需要以采集时刻换算，正文则要清理样式、补齐图片路径并处理延迟加载。 因此，“增加一个来源”不是复制一个地址。 它至少涉及列表发现、详情解析、时间转换、正文清理、失败标记和调度。 工单给出任务对象，代码给出实现位置，数据与 NLP 文档则解释字段为何要进入统一搜索契约。

代表项目二：股票、公司与组织资料脚本

独立小仓库保存了股票行情、公司资料和社会组织数据的处理脚本。 股票仓可见月度行情获取、建表、启动脚本与存储更新目录。 公司和社会组织仓包含数据库初始化、数据抓取、表格处理及比较脚本。 行业报告仓则同时处理报告下载、PDF 与多个来源适配。 这些仓库大多提交次数少，适合被理解为任务型工具，而不是稳定平台。 代码存在能证明局部流程被实现过，不能证明数据持续更新、覆盖完整或长期在线。 个别初始提交还混入日志、表格和样本。 本文没有把这些生成物或数据快照算作额外的软件能力。

代表项目三：产业链数据跟踪

Confluence 在 2019 年留下产业链数据跟踪表的修改记录。 随后又出现事件分析图谱的版本页面。 这两类文档分别承担“数据准备到哪一步”和“产品版本准备展示什么”的作用。 产业链文章显示，平台需要连接产业节点、企业、地区、基金、新闻、政策与研报。 上游采集若不保存标准主体、观察时间和来源，下游图谱就无法解释一条关系为什么存在。 周川关联的公司、新闻、股票与行业报告脚本，正好覆盖这条链的多种输入。 但当前证据没有统一运行批次，也没有证明数据跟踪表中的每一项都来自这些仓库。 因此这里只确认“采集资产与跟踪文档在主题和时间上相互支持”，不宣称完整端到端归属。

代表项目四：迁移快照与证据损坏

产业链解析目录中有数次“迁移”提交，把新闻、行业报告、公司、股票和社会组织工具汇入同一目录。 这种迁移有利于保存当时环境，却会把独立历史压成一次大快照。 提交中的文件触达量因而不能等同于新写代码量。 另一座新闻仓库的对象损坏又说明，单靠裸仓并不能保证未来可复核。 可靠归档应同时保存仓库完整性检查、依赖锁定、输入样例和运行清单。

工单、文档与代码如何互证

Jira 把新闻提取器记录为具体交付任务。 Git 显示新闻模板、采集脚本和调度文件存在连续修改。 Confluence 的周报与产业链跟踪表提供了时间背景和下游用途。 三者共同支持“参与过新闻采集和产业数据准备”的判断。 它们没有提供逐工单提交绑定，也缺少部署日志与采集成功率。 所以不能从工单完成状态推导所有来源稳定，也不能从文档修改次数推导成果影响。

可复用经验

• 每个采集来源都应保存模板版本、抓取时间、原始响应和失败原因。
• 相对日期必须保存解析基准时刻，避免重放同一页面得到不同结果。
• 调度脚本应连接运行标识、输入数量、写入数量和失败清单。
• 小型任务仓要区分源码、样本、日志和数据快照。
• 产业链跟踪表应引用数据批次，而不是只写“已完成”。
• 仓库迁移前后要保存来源历史，避免一次快照掩盖真实演进。
• 裸仓库需要定期做完整性检查，并记录无法恢复的证据缺口。

证据边界

本文不读取或复述招聘、评价和私人材料。 活动年份只表示现存记录覆盖范围。 Git 归并包含高、中的两类证据信号；无法唯一匹配的作者没有并入该档案。 提交数没有被用作绩效、难度或产出质量指标。 损坏仓库中无法展开的大部分文件差异保持未分类。 可确认的是：新闻提取、批量调度、股票与企业资料脚本，以及产业链数据跟踪文档之间存在连续的工作轨迹。 无法确认的是：所有数据源的覆盖率、线上运行周期、下游采用效果和个人独立完成比例。