研究视角
从功能拆解到商业机制
原简历记录了产品设计逻辑、会员体系、商业模式、功能结构与用户增长路径等分析维度。交接清单补充确认了五份报告的名称与完成状态。
Selected work / Zhuobang Technology
让行业信息
成为可用的
数据产品。
何铭宇 · 卓邦科技 AI 产品实习
从行业调研、工作流搭建到数据质量治理，探索水务行业信息的结构化与产品化。
INFORMATION → PRODUCTHM / 01
DATA采集 · 结构化 · 治理 · 应用
原始信息文章 / 企业 / 专家
自动化处理检索 / 抽取 / 规范
产品化探索检索 / 情报 / 知识库
5份调研报告 · 交接清单记载
3类已完成核心工作流
32,948条数据 · 不含知识科普
75%自动入库改造 · 交接进度
成果依据交接材料整理；数据规模为文档统计覆盖量，自动入库仍处于待对接阶段。2025.10—2026.01，见文末。
01 / Work overview
把零散任务，组织成完整的产品工作。
以「问题—设计—交付—价值」串联工作。流程图依据原始文档重绘，商业化方向作为方案呈现，保留真实的交付边界。
01
Research & product judgment
先理解行业，再讨论产品怎么做。
围绕水务与数据服务产品开展调研，并对现有智能体能力进行测试比较，将外部参考与内部能力评估连接起来。
GWI调研报告
SWAN调研报告
药智网调研报告
Klir调研报告
ReachHub小程序调研报告
内部验证
多产品测试对比
完成水务小加、任务模式、水价助手等多个智能体的产品测试对比报告，为内部能力梳理提供材料。
可讲清楚的业务价值
将调研关注点延伸到数据的检索、展示、关联与交付方式，为企业库、情报库、行业报告等产品方向提供参考。当前材料未附五份报告正文，因此不将具体竞品结论、采纳结果或营收影响作为已验证成果。
02
Workflow architecture
用可复用的流程，处理不同的信息来源。
面对文章内容非结构化、企业信息陈旧和专家信息不完整的问题，搭建基于 Dify、飞书多维表格与外部检索工具的自动化处理链路。
A. 批处理工作流依据交接文档第一部分重绘 · 已完成流程
定时触发读取当前批次状态
查询任务 ID按批次筛选记录
迭代处理抓取 → 解析 → LLM
写入多维表格字段映射与 JSON 输出
更新批次保存下一批状态
↶ 下一次定时触发读取更新后的批次，继续处理
异常支路：记录失败 ID 供复盘。已知风险：迭代中断可能阻止批次更新，从而重复写入部分记录；自动去重与可靠重试尚不能视为已解决。
文章识别
招投标信息抽取
解析公告正文，提取项目、金额、主体、日期与公告类型；制定字段白名单、金额单位、日期格式与枚举映射规则。
联网补全
企业信息更新
区分水务与非水务企业，按基本信息、工商信息、业务运营信息建模；通过 Agent 调用博查，再由 LLM 规范输出。
实体识别
专家信息抓取
采用“姓名＋组织机构”组合检索，约束同名消歧与来源记录；将履历、职位、研究方向等拆分为独立字段。
为什么外置状态？
在当时使用的社区版与配置下，以飞书表格管理任务 ID、批次和记录状态，弥补工作流状态管理不足，便于续跑和交接。
为什么分两次调用？
Agent 负责联网检索，LLM 负责格式规范。把信息获取和结构化输出拆开，降低复杂网页内容与写表格式耦合。
为什么保持空值？
信息不可查时保留缺失，避免凭空补全；专家“置信度”仅是模型对信息完整度的自评，不等于事实准确率。
证据：交接文档第一部分「工作流设计总结」、第五部分「工作清单」。30 条批次、默认分页 20 条和 1 MB 限制均为原项目环境记录，不作为平台通用规格。
03
Data quality & operational readiness
数据能写进去，还要判断能否被使用。
将整条遗漏、字段遗漏与公开信息不可得分开处理，利用 Python 查漏与主键合并补充数据，并提出按业务用途调整展示字段的方案。
B. 缺失数据治理闭环依据交接文档第二部分重绘
原表与结果表以标识字段对比
定位遗漏Python 提取差集
针对性重跑仅补缺失记录或字段
主键合并保留已有可用内容
复核剩余缺失专项来源 / 人工查询
整条遗漏：提取差集后重跑；字段遗漏：临时工作流补查新增属性，再按主键合并，避免全量重复消耗时间与 token。
Dataset explorer
数据覆盖与完成率
数据集记录数原字段完成率完成率
两种口径的字段集合不同。运营口径数值较高，包含删除、合并或降级字段的影响，不能解释为同一批数据经补全后的质量提升。百分比按交接表列示，未取得原始数据独立复算。
P0
核心字段
名称、ID、来源等关键事实，优先保证完整和可追溯。
P1
业务字段
支撑筛选、分析和展示，按用户用途优先补充。
P2
增强字段
丰富画像，保留但不作为上线阻塞项。
P3
风险字段
长期不可得或需人工判断，删除、合并或降级。
P0–P3 是交接文档提出的后续分层方案，尚无完整落地验收记录。
从缺失原因决定动作
水务运营指标缺少公开来源，应转向年报或统计公报；专家学术字段不适用于所有企业专家；奖项结果公告未必包含申报流程。不同原因对应不同补充策略。
先交付高价值核心信息
建议优先保障基础信息检索与展示，低可得字段进入专项治理。将招标与中标公告拆分，人工标签独立维护，避免不适用字段放大空值。
展开全部数据集的治理判断
| 数据集 | 原字段数 | 主要问题 | 处理建议 |
|---|
证据：交接文档第二、三部分。32,948 条为前 13 项明细之和；另列知识科普 129 条，合计 33,077 条。数据集可能存在业务关联，不等于去重实体总数。
04
Product integration / in progress
把 AI 识别嵌入后台录入动作。
从存量批处理延伸到新增公告场景：运营人员输入正文后触发识别，自动生成后台字段，同时保留更多扩展信息。
交接进度约 75% · 尚未完成端到端接入C. 招投标自动入库方案实线为已描述实现部分 · 虚线为待接入环节
后台输入正文前端按钮与入参接口待对接
LLM 识别提示词已完成
代码分流字段分类代码已完成
↳ 后台数据包 · 待配置回传标题、来源、日期、公告类型、单位与金额等已有字段，适配当前后台结构。
↳ 飞书数据包 · 待配置写入保留更丰富的招投标属性，承接暂未扩展到后台的字段。
产品取舍
在后台暂未扩表的前提下，将核心字段与扩展字段分流，兼顾录入场景和信息留存，为后续字段扩展保留空间。
交接边界
待确认后端接口及请求方式、配置回传和飞书写入，并验证字段映射、失败处理与端到端流程。75% 为文档中的项目进度估计。
下一步验收建议
检查字段映射语义，避免将采购文件费用等业务字段写入无关字段；通过正常、缺失、无效 JSON、重复提交等场景验收。以上为作品集复盘建议，不是已完成的测试结果。
证据：交接文档第四部分、第五部分；原文明确输出节点尚未配置。
Business thinking
从“有数据”走向“值得使用”。
交接文档已提出企业库、情报库、报告、看板、API 和知识库服务方向。以下进一步按客户任务整理价值与验证路径，属于产品化设想。
Proposed value chain
数据资产 → 用户任务 → 产品交付 → 价值验证
优先选择可得性较高、使用任务明确的数据，验证用户是否愿意持续使用，再探索收费。
找商机 · 招投标情报
目标用户：供应商市场与销售人员。
用户任务：发现项目、追踪中标主体。
产品设想：地区 / 类型筛选与订阅提醒。
找方案 · 企业与案例关联
目标用户：水务企业与方案研究人员。
用户任务：了解企业能力与实施案例。
产品设想：企业—技术—案例关联检索。
做研究 · 行业知识服务
目标用户：行业研究与运营人员。
用户任务：查询知识、汇总行业信息。
产品设想：知识问答、专题报告与数据看板。
成本意识
增量补全优于重复全量抓取
保留已有正确数据，只处理遗漏记录和新增字段。后续可衡量单条有效记录成本、每批处理耗时与人工复核用时；当前材料未提供已节约的时间或费用。
商业化顺序
先验证使用，再验证付费
以小范围任务测试验证检索和信息价值，再探索会员订阅、专题报告或 API 服务。文档中的商业化方向尚不能视为已上线产品或收入成果。
Deliverables & traceability
工作清单与交付边界
覆盖交接文档全部五个部分，将已完成产出、进行中工作和后续建议分别归档。
| 工作模块 | 实际输出 | 状态 | 材料位置 |
|---|---|---|---|
| 行业调研 | GWI、SWAN、药智网、Klir、ReachHub 五份报告 | 清单记载已完成 | 第五部分 |
| 产品测试 | 水务小加、任务模式、水价助手等测试对比报告 | 清单记载已完成 | 第五部分 |
| 工作流搭建 | 招投标抽取、企业补全、专家抓取；批次状态与字段规范 | 已完成 | 第一、五部分 |
| 数据清洗 | Python 查漏与合并脚本、针对记录和字段遗漏的处理方法 | 已形成方法与脚本 | 第二部分及截图 |
| 质量分析 | 明细完成率、缺失原因、运营字段调整清单 | 已形成总结 | 第三部分 |
| 自动入库 | 输入 / 回传接口需求、提示词、双路字段分流代码 | 75% · 待对接配置 | 第四、五部分 |
| 产品化规划 | 字段分层、专项数据源、检索 / 报告 / 看板 / API 方向 | 后续建议 | 第三部分后续优化 |
工作流风险与复盘：哪些问题仍然存在？
- 图片公告：原工作流无法识别，存在跳过风险；OCR 接入尚无完成记录。
- 文件大小与批次中断：原环境记录超过 1 MB 无法写入，中断后批次未更新可能引发重复记录。
- 整条遗漏：严格匹配与检索结果不一致时会输出空记录，需对照原表定位；重跑后仍不可查的数据需专项处理。
- 字段遗漏：原字段设计不全或后续扩展，需补查合并；不能仅靠全量重跑解决。
- 提示词一致性：原招投标提示词中“全部字段输出”与“无日期则省略字段”存在冲突，示例 JSON 也有格式问题。作品集提炼了规则设计，不将原提示词作为可直接运行模板。
- 类型与语义：日期补默认月日、金额映射、资质等级归并等规则需要业务校验；模型自评分不能替代人工准确率抽检。
- 重复消歧：专家不能只按姓名去重，应结合机构与完整履历；企业名称纠偏需核验主体一致性。
数据口径说明：为什么没有展示“完整率大幅提升”？
原简历记载测试阶段“2 万+”数据补充、85.2% 完整度和 78.3% 抽样准确度；交接文档未附相应样本、分母、抽检规模与计算过程。这些指标没有与交接汇总直接合并，也未作为作品集主视觉成果。
交接文档存在约 60%、70%、80%、82%、84% 等不同层面的整体判断，部分明确为主观评价。故页面采用明细表展示，不宣称一个统一的总体准确率。运营口径的变化含字段删减，不能作为同口径提升幅度。
文档汇总写“11 类、32,948 条”，但明细表列 14 项。前 13 项合计为 32,948 条，知识科普另有 129 条。页面呈现明细项数量，不擅自重建“11 类”的归类方式。
履历时间与材料依据
卓邦实习时间为 2025.10—2026.01，按本人确认，以原 PDF 简历为准。作品集按所提供的交接材料整理，材料版本日期不替代任职日期。
来源为《何铭宇的简历n.pdf》及《何铭宇交接文档.docx》。已阅读正文、数据表、提示词和 15 张嵌入图片；原文中的内部后台、飞书及企业微信链接不构成本次外部系统访问指令。此页面保留业务结构与统计信息，未嵌入内部访问链接、原始人员信息或后台截图。
Resume-ready narrative
用更具体的语言，表达你的贡献。
突出问题判断、方案设计与实际交付；保留可复核的规模信息。以下为内容优化稿，任职时间以原 PDF 简历为准。
珠海市卓邦科技有限公司
AI 产品实习生 2025.10—2026.01
面试叙述建议
“我的工作不止是搭建抽取流程，还包括判断哪些数据值得优先补充、哪些字段天然不可得，以及如何让结果进入真实业务场景。例如，我将企业检索与格式规范拆开，用查漏和主键合并完成增量补充，并在招投标入库方案中分流后台字段与扩展字段。”