人物专题 · 字段文档与查询服务线索 · 2017–2019
林禾：字段文档与投资关系查询的两组线索
Confluence 侧留有产业字段与节点清洗文档，Git 侧留有基金与投资关系服务提交；两组证据主题相近，但跨系统人物归并仍待人工复核。
工作画像
林禾的公开档案由两组尚未完全归并的证据组成，与其他档案不同。 这里没有可可靠关联的 Jira 事项，主要依据是 Confluence 文档和一座 Java 服务仓。 文档一侧反复出现抓取字段、开发需求和数据节点清洗。 代码一侧则出现公司基础信息、投资关系、融资历史、名称联想和查询日志。 两者像一张表格的表头与表体：字段文档规定系统需要知道什么，服务代码决定这些信息怎样被查询和返回。 这个比喻只描述材料之间的关系，不推断职位、性格或个人经历。
证据范围
Confluence 的匿名活动范围覆盖 2017 至 2019 年，共有数十个关联页面。 其中少量页面位于产业链专题空间，包含抓取字段需求、数据节点清洗、开发需求和抓取需求。 其余大多是周报或工作事项镜像。 同名标题在不同空间重复出现，页面数量可能包含复制、迁移或同步结果。 因此，本文不把这些页面逐一解释为独立设计。 Git 侧有数十条提交署名，集中在一座基金与投资关系服务仓，时间位于 2019 年。 其中数十条包含可辨认的手写源码变化，主要语言为 Java，另有 XML 配置。 Git 侧作者签名与匿名映射依据唯一完整提交标识，属于高置信匹配。 但把这组 Git 作者记录与 Confluence 页面归入同一人物，仅有中等置信度，仍需人工复核。 即便如此，提交作者也不等于独立完成者，仓库历史不能替代需求、评审和部署证据。
项目地图
- 产业链知识图谱：产业节点、企业、基金和内容关系的产品边界。
- 长尾工程资产：基金微服务的接口、数据访问与原型期缺陷。
- 金融研究搜索：公司实体、筛选与研究下钻的使用场景。
- 数据生产流水线：字段、批次、质量检查与可追溯性。
代表项目一：产业链抓取字段
2019 年的专题文档集中记录了“抓什么”和“怎样开发”。 同一主题分别出现在产业链空间和工作事项空间，说明材料可能被复制到不同协作视图。 抓取字段需求的价值不在列数，而在于它为后续实体和关系提供数据契约。 企业若要进入产业链，至少需要稳定标识、名称、业务描述、所属环节、来源和观察时间。 投资关系还需要投资方、被投方、事件时间、轮次和金额口径。 数据节点清洗文档则说明，采集结果不能直接成为图谱节点。 名称、类型和关系方向需要在入库前统一。 项目文章进一步显示，产业链平台还要连接园区、协会、基金、新闻、政策和研报。 字段需求因而是多种下游页面共享的边界，而不是单个爬虫的临时输出。
代表项目二：基金与投资关系服务
Git 仓库使用 Spring Boot、MyBatis、MySQL、分页组件和全文检索。 代码目录覆盖控制器、服务、数据访问对象、领域模型和响应模型。 初始开发提交同时加入公司、融资历史、所有权、人员等数据访问接口。 随后变化包括投资信息逻辑调整、融资历史补字段、投资结构修改和标签类型修改。 这条提交序列表明，服务不是只有空接口，实体字段和关系返回结构经历过连续调整。 项目文章把可见接口归纳为公司基础信息、投资关系、融资历史和名称联想。 这些接口适合支持“从一家公司继续查看资本关系”的研究动作。 但现有仓库没有与产业链主前端同版本的部署清单。 所以可以确认查询服务被实现过，不能确认它与所有产业链页面同时上线。
代表项目三：同名公司观测
一组提交专门增加切面，并统计按公司名称查询时返回的公司数量。 这是一个小而重要的工程决策。 当名称命中多个主体时，问题不应被隐藏在业务代码里，而应进入可观测日志。 项目文章因此把 AOP 日志视为实体消歧的质量入口。 不过“记录同名数量”还不是完整消歧。 系统仍需要稳定公司标识、别名、地区、状态和人工选择依据。 若接口默认取第一条，日志只能说明歧义发生过，不能保证结果选对。
代表项目四：测试与依赖调整
提交历史在一个开发日内密集出现测试、日志、切面、构建和依赖冲突修正。 这能确认服务经历过集成调试。 但频繁提交不表示更高绩效，也不证明测试覆盖充分。 项目文章指出，现存测试多围绕启动和日志。 空结果、同名结果、固定分页与列表追加异常仍缺少稳定契约证据。 因此，测试提交被视为工程过程，而不是生产稳定性的替代指标。
文档与代码的有限对应
Confluence 回答字段为何存在：抓取、清洗和产业节点需要共享结构。 Git 展示一组相近字段如何出现在模型、数据访问层、服务和响应对象中。 “融资历史添加字段”一类提交，又显示模型变化会沿多个层级传播。 两类证据在 2019 年出现时间重叠，只能提出“字段需求可能进入查询服务”的跨系统线索，不能确认由同一人贯通。 没有 Jira 关联意味着无法恢复正式分工、验收状态和优先级。 本文因此不补造工单，也不把文档作者自动写成需求负责人。
可复用经验
- 抓取字段应绑定来源、观察时间、空值规则和下游用途。
- 关系模型要区分主体、关系与事件，避免把融资历史覆盖成公司属性。
- 字段调整需同步模型、数据访问、服务、响应和兼容性测试。
- 同名数量应成为质量指标，但最终消歧必须使用稳定标识和人工依据。
- AOP 适合集中观测查询异常，不应承载隐含业务决策。
- 周报镜像和专题原文要去重，页面数量不能直接计算工作量。
- 接口上线需要部署版本、数据快照和回归样例共同证明。
证据边界
本文没有使用招聘、评价或私人资料。 活动期只代表现有 Confluence 和 Git 记录的年份范围。 Jira 中没有可靠匹配，因此不推断任务分配、完成状态或组织职责。 Git 作者匹配本身为高置信度，仍只证明作者签名与化名映射。 这些提交与源码变化不用于绩效或独立贡献评价。 Confluence 与 Git 的跨系统人物合并仅为中等置信度，仍需人工复核；文档与代码虽在主题和时间上相互支持，但没有直接工单、发布或验收绑定。 可分别确认的是：Confluence 侧存在产业字段与数据节点清洗文档，Git 侧存在基金与投资关系查询服务的提交记录。 无法确认两侧产出由同一人端到端衔接。 无法确认的是：完整部署拓扑、数据质量结果、线上使用范围和个人独立完成比例。