从“拍脑袋”到“活数据”：企业类型管理如何告别硬编码时代？

一个让人头疼的场景

想象一下这个画面：你所在的企业已经上线了一套PLM系统，业务团队每天都在系统里创建零件、文档、变更单。突然有一天，产品经理跑过来说：“我们新上一款产品，需要系统能自动识别用户输入，比如用户说‘帮我创建一个零件’，系统就能自动匹配到正确的类型，别让用户手动选。”

你一听，觉得这个需求很合理。可当你打开代码一看，瞬间傻眼了——系统里所有的核心类型（零件、文档、变更单、供应商……）都是当初开发人员“拍脑袋”硬编码进去的，一共22个。更麻烦的是，这些类型定义跟SCSAI（你的PDM系统）里的真实数据完全脱节，SCSAI里明明有1000多个类型，系统却只认这22个。

更让人崩溃的是，随着业务发展，新的类型不断出现——比如“物料清单”、“工程变更请求”、“质量不合格报告”——但系统却像个“睁眼瞎”，完全识别不出来。用户每次都得手动去列表里翻，效率低不说，还容易选错。

这就是典型的“硬编码”与“真实数据”之间的鸿沟。今天，我们就来聊聊如何用一套“三层数据源”架构，彻底告别这种尴尬。

为什么“拍脑袋”要不得？

先别急着骂当初的开发团队。其实，硬编码在早期阶段是一种“快刀斩乱麻”的做法——业务还不稳定，类型就那么几个，写死反而简单。可问题是，当系统上线后，业务会像野草一样疯长：

• 类型数量暴增：从22个到1000+，手动维护？
• 数据源割裂：SCSAI里的类型和代码里的定义，到底谁说了算？
• 识别不准：用户说“物料”，系统却只认“零件”，因为“物料”这个别名压根没定义。

结果就是：系统越来越“笨”，用户越来越“烦”，IT团队越来越“累”。

解决方案：三层数据源，让数据“活”起来

我们重构的核心原则只有一句话：SCSAI 是数据源，种子只是离线兜底和中文增强。

什么意思？简单来说，就是让系统不再“自己说了算”，而是老老实实去SCSAI里拉取真实数据。但考虑到网络、性能等现实问题，我们还准备了两手“后手”，形成一套完整的三层架构：

第一层：SCSAI 实时查询（主力军）

系统每次启动，或者用户触发意图识别时，都会自动去SCSAI的ItemType表拉取数据。我们设了5分钟的缓存，既保证实时性，又避免频繁请求把SCSAI搞崩。拉回来的数据包括：

• name：英文名，比如“Part”
• label：中文标签，比如“零件”
• description：描述

同时，系统会自动过滤掉关系类型（比如“BOM结构”这种），只保留真正的业务类型。目前SCSAI里约有1000+个类型，我们设了2000条的上限，完全够用。

第二层：种子类型增强（中文优化）

SCSAI里的数据虽然真实，但缺点也很明显——中文支持不够。比如“Part”在SCSAI里可能就一个英文名，但中国用户习惯说“零件”或“物料”。这时候，我们预定义的22个“种子类型”就派上用场了。

种子类型里包含了：

• 中文标签：比如“Part”对应“零件”
• 别名：比如“物料”、“部件”都是“Part”的别名
• 图标和分类：比如“Part”属于“business”Category，图标是“?”

注意，种子数据只有在SCSAI里有同名类型时才会生效。也就是说，如果SCSAI里没有“Part”，那种子数据也不会被使用。这就保证了数据源的权威性始终在SCSAI手里。

第三层：离线兜底（最后的防线）

万一SCSAI挂了怎么办？比如网络断了，或者SCSAI服务器宕机。这时候，系统会优雅地降级——只返回那22个种子类型，并打上一个connected:false的标记，告诉前端：“数据可能不全，请留意。”

匹配逻辑：让系统“猜”得更准

有了数据源，下一步就是怎么匹配用户输入。我们设计了一套优先级明确的匹配逻辑：

优先级	匹配方式	置信度	示例
1	精确匹配 name	1.0	用户说“Part” → 直接命中
2	精确匹配 label	0.95	用户说“零件” → 命中
3	别名匹配	0.9	用户说“物料” → 命中
4	name 子串	0.7	用户说“Part BOM” → 含“Part”
5	label 子串	0.6	用户说“零件清单” → 含“零件”

这套逻辑的好处是：用户输入越精确，系统响应越快。即使输入模糊，系统也能给出一个合理的猜测。

自动分类：没有种子也不怕

SCSAI里1000多个类型，不可能每个都配种子。那遇到没有种子的类型怎么办？我们搞了一个“自动分类”功能，通过名称关键词猜测它属于哪个分类：

• business：part、product、document、vendor、customer……
• process：ecr、ecn、eco、bom、manufacturing……
• system：user、role、permission、identity……
• report：report、log、history、metric……
• other：以上都不命中时

比如，SCSAI里有个“Material”类型，没有种子覆盖，但系统看到“material”这个词，就会自动把它归到“business”分类下。这样，即使没有人工配置，系统也能“猜”个八九不离十。

意图识别：从“听懂”到“做对”

有了类型数据，接下来就是让系统理解用户到底想干什么。我们重构了意图识别模块，流程如下：

1. 能力识别：用户输入“创建一个零件”，系统先判断能力是“create”。
2. 类型匹配：接着系统去SCSAI里找“零件”对应的类型，找到“Part”。
3. 参数提取：如果用户说“Create10个零件”，系统还能提取出数量“10”。
4. 置信度计算：综合能力和类型的匹配度，给出一个0~1的分数。

如果用户输入不够明确，比如只说“修改”，系统会结合上下文——比如上一条对话里用户提到了“Part”——来补位。这就是“上下文补位”机制，让多轮对话变得更自然。

落地效果：从“修修补补”到“开箱即用”

这套重构方案落地后，我们修复了之前代码里的9个异步问题，修正了6个旧字段引用。现在，系统已经能够：

• 自动同步SCSAI数据：每次意图识别时，自动拉取最新类型列表。
• 智能匹配用户输入：无论是精确输入还是模糊输入，都能给出合理的类型推荐。
• 优雅降级：SCSAI不可用时，系统不会崩溃，而是返回离线种子数据。
• 支持多轮对话：通过上下文补位，让对话更加连贯。

这背后，是“左帮右臂”的思考

作为一家专注于企业智能化的公司，BossAgents（左帮右臂）深刻理解企业在数字化转型中遇到的“数据孤岛”和“系统僵化”问题。这次重构不仅仅是技术上的升级，更是一次思维方式的转变：

• 从“系统定义”到“数据驱动”：不再让开发人员拍脑袋定义类型，而是让真实业务数据说话。
• 从“硬编码”到“动态适配”：系统能够自动适应业务变化，新类型的加入不再需要修改代码。
• 从“单点识别”到“上下文理解”：让系统像人一样，能结合上下文理解用户的真实意图。

我们相信，未来的企业系统应该是“活”的——能够自我学习、自我适应。而“左帮右臂”正是致力于帮助企业实现这一目标：让系统成为员工的“左膀右臂”，而不是“绊脚石”。

如果你也在为系统的“僵化”头疼，不妨想想：你的系统里还有多少“拍脑袋”硬编码的东西？是时候让数据“活”起来了。