创建链路统一性诊断 v1(2026-07-07)
本文纠正 2026-07-06「P0-3 Create 绕开规则引擎」的错误结论。
结论基于代码实测(rule-engine.js / capability-runtime.js / AmlBuilder.js / useCapabilityCreate.js),
不是 grep 片段推断。
〇、先认错
昨天说「前端 buildAML() 直连 SCSAI + 后端 unified-create.js 直连 SCSAI,双重绕开规则引擎」。
两处都错:
- 「直连 SCSAI」措辞错——前端经
bomService._SCSAIApiRequest→fetch('/SCSAI-api/ApplyItem')→ Vite 代理 → 后端 → SCSAI,浏览器不直接碰 SCSAI。 - 「绕开规则引擎」定性错——系统里已有走规则引擎完整生命周期的统一创建入口(
/api/rule-engine/create-item与CapabilityRuntime.create),我 grep 到 unified-create/buildAML 就宣布"绕开",没读 create-item 实现,也没读规则引擎本身。
一、规则引擎到底是什么、存哪、怎么用
1.1 是什么
- 核心实现:
server/routes/rule-engine.js中的UnifiedRuleEngine类(旧名 RuleEngine,已统一)。 - 六能力统一 API(handleRuleEngine 分发):
/api/rule-engine/identify识别对象/api/rule-engine/repair修复对象/api/rule-engine/optimize优化对象/api/rule-engine/compare比对对象/api/rule-engine/create-item统一创建对象(集成规则引擎完整生命周期)/api/rule-engine/validate验证/api/rule-engine/create_post/execute-create-post创建后规则- 统一层:
server/core/capability-runtime.js的CapabilityRuntime,六能力(create/identify/repair/optimize/compare/generate/update/delete)全部先_initRuleEngine()→engine.execute(scope,...),规则命中走规则、否则降级 AML/LLM。
1.2 规则模板 / 提示词 存哪
- 配置主库:
sciot_import.db(唯一真相源) sciot_rules_v2—— ★ 统一规则表(核心,含 scope/action_script/severity)sciot_prompts—— 对象级提示词(兼容旧版)sciot_templates—— 模板(含 llm_fields / auto_fields 字段分类)sciot_rules—— 旧规则表(已知技术债,未完全迁移)- 权威设计文档:
docs/rules-templates-prompts-system.md(v3.5,5.8万字)
1.3 创建生命周期(理想态,create-item 实现)
validate → create_pre → 组装AML → (前端/后端提交 applyAML) → create_post
- validate:数据校验规则
- create_pre:默认值填充、自动编号、数据预处理(对应 SCSAI onBeforeAdd)
- create_post:创建后副作用(scope='create_post' 的 action_script)
二、四入口到底统一了吗?(核心问题)
| 入口 | 创建走哪条路 | 前段规则(validate/create_pre) | 后段(create_post) | 统一层 |
|---|---|---|---|---|
| 业务页 useCapabilityCreate.js | buildAML() + /SCSAI-api/ApplyItem | ❌ 跳过 | ✅ execute-create-post | ❌ 绕过 CapabilityRuntime |
| 对话框/AI | 经 ai-agent.js → CapabilityRuntime | ✅ | ✅ | ✅ |
| 飞书 | 经 staff-router/feishu-router → (间接 CapabilityRuntime 或 smartCreate) | 待确认 | 待确认 | 部分 |
| 小程序 | 后端 miniapp-routes → (待确认是否 CapabilityRuntime) | 待确认 | 待确认 | 部分 |
| 导入/worker object-importer / lite-scheduler | capabilityRuntime.create() | ✅ | ✅ | ✅ |
| create-item API | engine.createItem 完整生命周期 | ✅ | 需前端补 execute-create-post | ✅ |
实测证据:
useCapabilityCreate.jsL1671buildAML(mainAmlData,...)→ L1681bomService._SCSAIApiRequest('ApplyItem', mainAml)→ L1964fetch('/api/rule-engine/execute-create-post',...)
→ 业务页只走 create_post,跳过 validate/create_pre。
capability-runtime.jsL451/501/549/574 各能力均_initRuleEngine()后engine.execute(scope,...)。object-importer.js:684this.capabilityRuntime.create(...);lite-scheduler.js:236new CapabilityRuntime(...)给 worker。
结论:
- 「所有入口基于规则引擎统一创建」——在 AI对话 / worker / 导入 这条服务端链上是成立的(CapabilityRuntime 统一层)。
- 业务页这条最关键的人工创建路径是分裂的:它用
buildAML组装、直接提交、只补 create_post,没走 CapabilityRuntime 也没走 create-item 的前段规则。 - 文档自己已标注:「Create 场景有两套提示词生成路径(预生成 vs 前端 PromptBuilder 动态拼装),一致性风险中」。
三、「任意对象都能创建」做到没?怎么做的?
能力层面:✅ 已做到
AmlBuilder.buildAML(业务页/前端)覆盖:- 普通标量属性(L40-46)
- Item 类型属性(L48-55:
item_properties含 add/get 两种动作,正确生成) - 复杂关系对象(L57-114:
relationships含同名关系/异名关系、related_id 引用、子对象 item_properties、item_number 查询引用) 嵌套(L60)UnifiedRuleEngine.createItem(后端规则引擎)同样覆盖全部字段类型,且文档 v3.4 已修复「WBS 的 wbs_id(Item类型) 被错误放进 Relationships」的字段分类 bug(改为三种字段:properties / item_properties / relationships)。
所以
「含对象类、复杂关系对象、Item/List 属性都能创建」——能力具备,不是没做到。
四、真问题在哪(非泛泛,分层)
问题A(统一性,中风险,已实锤):业务页创建跳过前段规则
- 表现:业务页 buildAML 路径不跑 validate/create_pre,只有 create_post。
- 后果:validate/create_pre 里定义的默认值填充、自动编号、数据校验,在业务页人工创建时不生效——同一条对象,经 CapabilityRuntime 创建(worker/AI)和经业务页创建,前段处理不一致。
- 这是文档「一致性风险中」的具体落地。
问题B(统一性,低风险,已实锤):提示词两套生成路径
- 路径A:服务端预生成(sciot_prompts,确定性拼接)
- 路径B:前端 PromptBuilder/AmlBuilder 动态拼装
- 两者可能输出不一致 → 同一对象类,AI 看到的和前端组装的提示词/结构可能不同。
问题C(非创建,已知债):sciot_rules 旧表未完全迁移
- sciot_import.db 两套规则表并存,部分用户/模块仍读旧表。属 P1。
以上不是「创建能力缺失」,是「创建路径未统一在规则引擎前段」。
五、我没有做的事(防误报)
- 未改任何代码(按指示:先诊断,别乱改搞出更多问题)。
- 飞书/小程序入口是否经 CapabilityRuntime:本次只确认它们不直接实例化,间接路径(经 staff-router / miniapp-routes 调 capability-api)需进一步追,标记为「待确认」。
- 未给「解决方案」,因为用户要求先讲清做到没、真问题在哪,而非急着改。
BossAgents