你的企业还在为“创建一条数据”头疼吗？我们刚踩过的坑，也许能帮你省下三个月

你是否有过这样的经历：明明系统里已经建好了各种规则，可业务人员在页面上创建一条物料或订单时，总是出现“默认值没填上”“编号没自动生成”“校验规则没生效”的诡异情况？更让人抓狂的是——同样的数据，通过API或自动化流程创建却一切正常。于是，技术团队开始互相甩锅：“前端说后端接口有问题”“后端说前端没调对”“规则引擎说它根本没被调用”……

别笑，这正是我们团队刚刚走过的弯路。今天这篇文章，就把我们花了整整一周、通过代码实测才搞清楚的真相，原原本本讲给你听。希望读完以后，你不仅能避开这个坑，还能对“规则引擎”这件事有一个全新的认知。

一、规则引擎到底是个什么“引擎”？它藏在哪儿？

很多企业级系统里都挂着“规则引擎”这个高大上的名字，但说实话，大部分人对它的理解是模糊的。我们不妨用一个比喻来理解：

规则引擎就像工厂里的“质检流水线”——每一个零件（数据）进来，都要经过“检查尺寸→填充缺项→自动编号→最终组装”这几个工位。不同的工位由不同的“规则”控制。而这条流水线的总控台，就是我们系统里的 CapabilityRuntime（能力运行时）。

在我们的系统里，规则引擎并不是一个虚无缥缈的概念，它实实在在地存在于 server/routes/rule-engine.js 这个文件里。它对外暴露了六个核心能力接口：

• 识别对象

：判断你拿到的到底是个什么东西

• 修复对象

：自动补全缺失字段

• 优化对象

：调整不合理的数据结构

• 比对对象

：新旧版本差异分析

• 创建对象

：这是最关键的——从数据校验、默认值填充、自动编号到创建后的副作用处理，全流程走规则引擎

• 验证对象

：最终合规性检查

这些接口背后，有一个统一的配置数据库 sciot_import.db 作为“规则大本营”。里面存着：

• 规则表

（sciot_rules_v2）：定义每个环节要做什么

• 提示词表

（sciot_prompts）：告诉AI怎么理解这个对象

• 模板表

（sciot_templates）：定义哪些字段需要AI生成、哪些需要自动计算

所以，当你说“规则引擎”的时候，其实是在说：一个由统一配置驱动的、覆盖数据全生命周期的自动化处理流水线。而这条流水线的理想状态，应该是所有数据创建入口——无论是人工页面、AI对话、飞书机器人还是后台批量导入——都经过同一个总控台。

二、四个创建入口，真的统一了吗？——真相可能让你坐不住

为了回答这个问题，我们花了整整三天，一行一行地读了核心代码，而不是靠grep搜关键词。结果发现：口号喊得很响，现实却裂成了四块。

我们的系统有四个主要的数据创建入口：

| 入口 | 走的是哪条路 | 前段规则（校验/填充） | 后段规则（创建后处理） | 是否经过统一总控 | |------|-------------|---------------------|---------------------|----------------| | 业务页面（用户手动创建） | 前端拼AML → 直接提交 → 只补后段规则 | ❌ 跳过 | ✅ | ❌ 完全绕过 | | AI对话 | 经AI代理 → 走统一总控 | ✅ | ✅ | ✅ | | 批量导入/后台Worker | 直接调统一总控 | ✅ | ✅ | ✅ | | 飞书/小程序 | 间接路径（待确认） | 待确认 | 待确认 | 部分 |

看到问题了吗？最核心、最常用的人工创建页面，居然绕过了规则引擎的前段规则！

我们拿代码实测结果说话：在 useCapabilityCreate.js 这个前端文件中，第1671行调用了 buildAML() 方法组装数据，第1681行直接通过 bomService._SCSAIApiRequest('ApplyItem', mainAml) 提交给后端，然后第1964行才补了一个 fetch('/api/rule-engine/execute-create-post') 跑后段规则。

这个流程意味着什么？意味着：

1. 1. 数据校验规则没跑

——如果某个字段要求必填，但用户漏填了，页面不会报错，数据直接提交

1. 2. 默认值没填充

——比如“创建时间”字段应该自动取当前时间，但没跑规则，结果为空

1. 3. 自动编号没生成

——比如“物料编码”需要按规则自动生成，但没触发，结果可能是空或重复

而同样的数据，通过AI对话或者后台导入，因为走了统一的 CapabilityRuntime 总控，这些规则全部生效。这就是为什么同一个对象，不同入口创建出来的结果不一样——不是代码写错了，是入口路径压根就没统一。

三、“任意对象都能创建”——这个能力到底有没有？

你可能要问了：那至少“任意对象都能创建”这个目标实现了吗？答案是：能力层面做到了，但路径层面没统一。

从技术能力来看，我们的 AmlBuilder（前端组装器）和 UnifiedRuleEngine.createItem（后端规则引擎）都支持创建任意复杂对象，包括：

• 普通字段（字符串、数字、日期） -

对象类型字段（比如一个“订单”里包含一个“客户”对象）

• 复杂关系对象

（比如“项目”关联多个“任务”，每个任务又有自己的子对象）

• 列表/数组字段

（比如“物料清单”里的一行行明细）

文档里甚至专门修复过一个bug：原来把WBS（工作分解结构）的 wbs_id（对象类型字段）错误地放到了关系列表里，后来修正为三种字段分类：普通属性、对象属性、关系属性。

所以，从技术实现上讲，系统确实能创建任意类型的对象。问题不在于“能不能”，而在于“通过哪个入口创建时，规则是否完整执行”。

四、真问题到底在哪儿？——三个层次，一个比一个扎心

经过这次深度诊断，我们把问题分层梳理清楚，不泛泛而谈，也不甩锅：

第一层（中风险，已实锤）：业务页面创建跳过了前段规则

这是最直接、最严重的问题。人工创建路径不跑 validate（校验）和 create_pre（前置处理），只跑 create_post（后置处理）。导致：

• 同一个对象，人工创建和自动创建，前段处理不一致 - 默认值、自动编号、数据校验在人工创建时全部失效 - 这就是文档里自己标注的“一致性风险中”的具体表现

第二层（低风险，已实锤）：提示词生成有两套路径

• 路径A

：服务端预生成，从 sciot_prompts 表里确定性拼接

• 路径B

：前端 PromptBuilder / AmlBuilder 动态拼装 两套路径可能输出不一致，导致AI看到的对象结构和前端组装的结构有差异。虽然目前影响不大，但长期看是隐患。

第三层（已知技术债）：旧规则表未完全迁移

sciot_import.db 里有两套规则表并存——新的 sciot_rules_v2 和旧的 sciot_rules。部分用户和模块仍然读旧表，存在数据不一致风险。这个属于P1级别的技术债，需要安排专项清理。

五、我们踩过的坑，你完全可以避免

写这篇文章，不是为了炫耀我们发现了什么问题，而是想告诉你：在复杂的业务系统中，“统一”这件事比想象中难得多。很多时候，你以为所有入口都走了同一条路，但实际上，代码里藏着无数条“小路”。

如果你正在建设或维护一个需要处理大量数据创建的系统，请一定检查以下几点：

1. 1. 所有创建入口是否真的走了同一个总控？

不是看架构图，而是看代码里每个入口调用的具体函数

1. 2. 规则引擎的前段和后段是否都覆盖了？

很多系统只关注创建后的处理，忽略了创建前的校验和填充

1. 3. 不同入口创建同一对象，结果是否一致？

这个测试案例应该写进你的回归测试集里

六、左帮右臂（BossAgents）能帮你做什么？

看到这里，你可能会问：这些问题我们自己能发现吗？能修吗？答案是：能，但要花大量时间。而时间，恰恰是企业在数字化转型中最稀缺的资源。

作为专注于企业级智能体技术的公司，左帮右臂（BossAgents） 的核心能力之一就是：帮企业把“规则”这件事管清楚、用到位。

• 规则统一诊断

：我们可以像这次一样，通过代码实测帮你梳理所有数据入口，找到“统一性裂缝”

• 规则引擎落地

：从配置管理到生命周期覆盖，帮你建立真正的“统一规则总控”

• 智能体集成

：不管是AI对话、飞书机器人还是小程序，确保所有入口都走同一条规则流水线

• 技术债清理

：旧规则迁移、路径统一、测试覆盖——这些脏活累活，我们帮你干

我们不做PPT上的架构师，我们做代码级的诊断师。因为只有深入到每一行代码，才能真正理解问题在哪、怎么修。

---

最后说一句：那篇写于2026年7月7日的诊断文档，最后一行写着“未改任何代码，先讲清做到没、真问题在哪”——这种实事求是的态度，正是我们面对每一个客户时的原则。如果你也有类似的困扰，不妨让我们来帮你做一次“规则统一性诊断”。毕竟，有些坑，踩一次就够了。