顾棠：把来源、任务与检索边界接在一起

工作画像

顾棠的公开工作画像，来自需求、文档和代码留下的交集。 在 Jira 中，与这一化名关联的记录横跨数据与自然语言处理、金融检索、数据平台和横向产品工程。 在 Confluence 中，留存的是数据方案、研发计划和持续修订的工作文档。 在 Git 中，可辨认的变化主要落在 Python 采集与处理、Shell 调度、检索配套组件和少量 PHP 接口。 如果要用一个中性的比喻，这些产出像“管线接头”：研究人员提出的来源、口径和对象，需要先被翻译成字段、任务和接口，才能继续流向搜索与图谱。 这不是性格判断，也不是职位描述。 它只说明现存材料中，需求发起、工作拆解和数据链路衔接反复出现。

证据范围

匿名聚合记录覆盖 2017 至 2019 年。 Jira 中有百余条关联事项，其中既包括被分配任务，也包括发起和拆解工作。 Confluence 中有近两百个关联页面记录，时间和主题覆盖范围比代码提交更宽。 Git 归并得到数百条提交署名，分布在多个仓库，活跃区间集中于 2017 至 2018 年。 这组 Git 身份归并为中等置信度：依据是作者名或提交标识片段与唯一账户标识一致，而不是完整提交标识直接命中。 因此，本文只用它说明“该化名可关联到哪些代码变化”，不把署名等同于独立完成，更不依据提交数量评价工作质量。 其中一个主仓库还保存了大量关系数据快照。 数据文件、调度脚本、第三方组件和手写业务代码必须分开理解，文件数量不能直接代表工程复杂度。

项目地图

• 数据与 NLP：异构资料如何变成可搜索的知识：来源字段、采集管线、词典和实体关联。
• 让金融资料可以被研究：查询、筛选、段落定位与研究工作台。
• 海纳数据平台：知识图谱合并与多源数据平台协作。
• 横向产品工程：上传、搜索条件、笔记和编辑器的共同对象。
• 长尾工程资产：采集脚本、第三方组件与服务快照的证据边界。

研究需求→来源与字段定义→采集任务拆解→数据入库

数据入库→实体与关系整理→搜索索引→产业链与公司下钻

搜索索引→筛选和上传需求→研究工作台→可引用材料

工单状态→研发计划文档→代码变化→项目复盘

代表项目一：数据与 NLP

一条已完成事项要求给研报数据增加“来源”字段。 它看似只增加一列，实际改变了后续去重、筛选、展示和证据追溯。 现有项目文章表明，研报还需要机构、作者、评级变化、报告类型和预测期等特有字段。 “来源”进入统一契约后，公告、研报、新闻和其他资料才能共享搜索入口，又保留各自口径。 另一条事项要求产业链统计纳入研报。 这意味着内容类型不只用于阅读，还要进入实体与产业关系计算。 Git 侧的公告数据仓可以看到来源专用 Spider、Item、Pipeline、新闻提取器和批量调度脚本。 文档中的字段要求与代码中的来源模型能够互证：前者说明为什么要保存，后者说明保存发生在哪条处理链。 但现有证据没有把某一工单绑定到唯一提交，也没有完整运行清单。 因此可以确认参与过需求和代码变化，不能确认某个模块由单人完整实现。

代表项目二：金融检索与研究工作台

顾棠关联的事项包括金融搜索产品规划、上传管理以及公司代码、名称和简称的对齐。 这些事项共同指向一个核心问题：研究者看到的筛选条件、上传内容和公司主体，必须与后端执行的查询保持一致。 项目文章显示，搜索系统需要处理空查询按时间排序、非空查询按相关性排序、同义词扩展、段落高亮和公司图谱。 上传内容又要求只对本人可见，并能进入本人的搜索结果。 这使“来源、所有者、公司标识、时间和可见性”成为同一对象模型的组成部分。 Git 中相应时期的 Python 与 Shell 变化覆盖公告采集、解析和调度。 另一座 PHP 服务仓保存了来源控制器、筛选控制器、PDF 控制器与请求工具的变化。 这些路径支持“采集和查询边界都被修改过”的判断。 它们不能证明当时所有页面与服务始终部署在同一版本。

代表项目三：知识图谱合并

海纳项目中有一项明确的“知识图谱合并”任务被标记完成。 同一时期的文档还保存月度研发计划，说明它不是完全孤立的一次提交。 数据与 NLP 文章揭示了合并的实际难点：公司全称、简称、曾用名与证券代码需要落到稳定主体，文档共现只能作为弱关系补充。 Git 仓库中的关系快照数量很大，但这部分更接近生成数据或中间产物。 不能因为文件很多，就认定全部关系由提交作者逐条设计。 可确认的工程痕迹，是采集器、调度脚本和关系数据共同存在；不可确认的是图谱合并的精确算法、误差率和验收样本。

代表项目四：第三方能力的接入

一座第三方组件仓包含中文分析插件、词典，以及一套神经机器翻译代码。 提交记录能确认相关代码被引入和调整。 但大量文件来自上游项目，不能据此声称这些算法由顾棠原创。 更可靠的表述是：留存变化涉及组件集成、配置和词典维护。 是否训练过自有翻译模型、是否进入生产调用链，现有项目文章已经明确列为证据缺口。

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

工单给出“来源字段”“产业链纳入研报”“知识图谱合并”和“上传管理”等动作。 文档补充字段范围、研发排期和上线顺序。 代码则显示采集模型、来源适配、调度与查询接口确实存在对应变化。 三类证据相交时，可以确认的是机制和参与轨迹。 只有工单而没有代码时，只能确认任务被记录或关闭。 只有代码而没有文档时，只能确认仓库发生变化，不能自动解释业务目的。 只有数据快照而没有生成清单时，也不能把快照数量换算成个人贡献。

可复用经验

• 数据字段要写清用途：筛选、去重、展示和追溯使用的口径可能不同。
• 新来源接入应同时更新字段契约、解析、索引、筛选和回归样本。
• 公司实体要用稳定标识连接名称变化，不能只靠文本相等。
• 需求事项最好绑定验收样例与运行版本，避免“已完成”无法复算。
• 第三方源码、生成数据和手写业务逻辑应分开统计与审计。
• 跨团队计划文档应记录依赖、负责人角色和交付状态，但不能替代运行证据。

证据边界

本文不使用招聘、评价或私人材料。 活动范围只表示当前归档中最早和最晚的可见记录，不等于完整任职时间。 Git 作者归并为中等置信度，且提交署名不证明单独设计、审核或上线。 工单完成状态不等于长期稳定运行，Confluence 页面数也不等于文档质量。 仓库中的关系文本、词典和第三方代码会放大文件触达量，本文没有将它们当作绩效指标。 可确认的是：顾棠关联产出持续连接数据来源、任务拆解、检索与图谱。 无法确认的是：各系统的最终采用范围、线上版本、个人独立完成比例与业务影响。