WORKBUDDY FDE · PROJECT FILE
CASE 03 / 企业主体信息匹配 · 对外脱敏版
V3

一张模糊客户名表，为什么做到了第三版

第一版交出去以后，问题才真正开始出现：业务名称和法律主体之间，并不存在一条天然正确的直线。

VERSIONED DELIVERY RECORD
FILE / 01

第一份交付，不是项目的答案

THE FIRST HANDOFF

项目从财务人员日常使用的一张客户名称表开始。首版 Skill 很快完成移交，客户侧确认收到并进入试用。

这一步的价值不是证明方案已经成熟，而是把讨论从“能不能做”推进到“哪些名称真的匹配不了、为什么匹配不了”。

交付记录 · 脱敏重绘FIRST VERSION
这是第一版主体查询 Skill，可以先交给财务同学试用；需要优化的地方再继续沟通。
已收到，先试用。
依据项目交付截图脱敏重绘；客户名称、群组、人员、头像、时间与文件信息均未保留。
FILE / 02

一个业务名称，为什么不止一个答案

THE REAL PROBLEM

真正的难点不是补齐“有限公司”几个字，而是判断门店、分支机构、连锁总部和内部代号究竟指向谁。

ALIAS

简称与缺字

地区、组织形式或品牌信息被省略，同一简称可能对应多个候选。

输入 某某药房
结果 候选 A / B / C
BRANCH

门店与总部

业务名称可能写的是门店，法律主体却可能属于分支或独立公司。

门店 ≠ 总部
分支 需要单独判断
INTERNAL CODE

内部代号

编号加地名的内部叫法无法直接公开检索，只能由客户配置映射。

代号 [已隐藏]
映射 客户侧维护
FILE / 03

从首版交付，到 V3 通用化

VERSION HISTORY
FIRST
VERSION

先把主体查询交到真实使用者手里

输入模糊名称，检索公开企业信息，补全主体抬头、登记信息和分支关系；不确定结果保留人工判断。

  • 真实财务任务
  • 首版 Skill
  • 客户侧试用
ISSUES

错例逐渐变成产品规则

简称、地区差异、同名主体、连锁关系和内部代号表明：这不是简单搜索，而是一个需要消歧和证据链的主数据任务。

  • 多候选
  • 分支判断
  • 内部映射
  • 低置信复核
V3

客户配置与通用能力被分开

通用 Skill 负责读取、标准化、候选评分、增量续跑和结果生成；客户特定的内部代号映射独立保存，不进入通用能力包。

  • Excel / CSV
  • 批量分片
  • 断点续跑
  • Excel / HTML
  • 人工确认清单

不是给出一个名字，
而是留下处理链路

每个确定结果需要来源；每个不确定结果需要候选、状态和人工确认位置。

01读取原表保留原始名称与行号
02名称标准化处理简称与写法差异
03候选检索获取可能的法律主体
04评分消歧地区、主体与分支判断
05分层输出成功、待确认与未找到
06人工闭环关键财务用途最终核对

到了千级数据量，问题变了

当需求从少量试用增长到千级批量时，纯联网检索开始面对速度、上下文、调用成本和平台限制。团队没有继续把“能跑”写成“能规模化”，而是把它标记为下一阶段的工程边界。

01 / DATA SOURCE接入授权的结构化企业数据服务避免长期依赖逐条网页检索和不稳定页面。
02 / BATCH CONTROL批次、续跑与失败恢复已查询记录不重复处理，失败项保留重试位置。
03 / AUDIT来源、版本与人工修正日志重要财务字段不能只留下最终答案。
04 / HUMAN REVIEW低置信结果必须回到人工系统负责缩小范围，不替代关键主体确认。

这份档案里，能够被核验的材料

EVIDENCE 01首版交付记录

证明项目进入真实财务任务，并完成第一版 Skill 移交。

EVIDENCE 02V3 通用化交付包

包含 Skill 说明、配置样例和多项执行脚本。

EVIDENCE 03内部代号问题样例

证明项目真实遇到非工商名称；具体主体信息不对外展示。

EVIDENCE 04项目时间线与规模讨论

记录客户试用、版本演进及千级批量需求带来的工程判断。

PROJECT STATUS真实场景首版已交付，V3 已完成通用化沉淀；正式全量验证、生产上线和客户验收仍待补证。