从“混沌”到“清晰”：企业级规则、模板与提示词的分层存储实践

如果你正在管理一个复杂的企业系统，你一定遇到过这样的场景：一个同事不小心修改了一条规则，结果导致整个团队的系统行为都变了；或者，你想找回上周还运行得好好的旧版本规则，却发现它已经被覆盖得无影无踪。更令人头疼的是，当系统出现问题时，你很难判断到底是规则、模板还是提示词出了问题，因为它们全都混在一起，像一团理不清的乱麻。

这不仅仅是技术问题，更是管理上的痛点。当你的业务系统依赖大量规则、模板和提示词来驱动自动化流程时，它们的管理方式直接决定了系统的稳定性、可扩展性和团队协作效率。今天，我们就来聊聊如何通过分层存储与同步，让这些关键资产变得清晰、可控、可追溯。

现状：数据孤岛与混乱的根源

在大多数企业系统中，规则、模板和提示词的管理往往处于“野蛮生长”状态。以我们调研的典型场景为例，系统里存储着数千条规则、模板和提示词——它们全部混在一个本地数据库里，没有分层，没有版本，没有用户隔离。

数据全景：一个庞大的“数据湖”

先看看我们面对的数据量级：

• 规则引擎

：超过 2,300 条规则，覆盖验证、创建、识别、修复等 11 种操作类型

• 模板库

：超过 1,200 个模板，用于生成不同类型的对象

• 提示词

：超过 2,800 条提示词，用于指导 AI 生成结构化内容

• 业务提示词

：46 条，面向特定业务场景

这些数据全部存储在本地 SQLite 数据库中，通过一个统一的后端服务提供给前端应用和 AI 模块使用。

问题瓶颈：五个“致命”缺陷

1. 1. 无分层，标准与用户数据混为一谈

所有规则、模板和提示词都放在同一个表里。这意味着，任何人的修改都会全局生效——标准库的数据可以被随意覆盖，用户自定义的数据也可能被别人的操作影响。

1. 2. 无版本，改了就是“永久”

数据库中没有版本字段，也没有历史记录。一旦修改，旧版本就彻底丢失。你无法回滚，无法对比，无法审计。

1. 3. 无审核，误操作直接上线

规则和模板的修改没有审批流程。一个错误的规则改动，可能直接导致生产系统行为异常——比如自动创建了错误的对象，或者生成了无效的 AML 代码。

1. 4. 单源耦合，离线即瘫痪

所有数据都依赖本地 SQLite 数据库。如果 SCSAI 服务端不可用，系统虽然能继续运行，但无法从服务端获取最新数据，也无法将本地修改写回服务端——这实际上是一种“伪离线”状态。

1. 5. 无用户隔离，个性化无从谈起

系统中没有用户 ID 的概念。这意味着，不同角色（如管理员、开发者、业务用户）都共享同一套规则，无法实现个性化覆盖或权限控制。

服务端现状：一个被忽略的“宝藏”

你可能以为，SCSAI 服务端上应该已经存在这些规则和模板了。但实际调研发现，情况恰恰相反：

• Rule

表里只有 1 条空记录

• Template

表里有 15 条数据，但全是 SCSAI 平台自身的对象模板（如 Action、Form、Identity 等），与我们的业务规则完全无关

• BossAgents 的 6,000 多条数据全部在本地

，服务端上零数据

这意味着，服务端的 Rule 和 Template 字段设计虽然丰富（有 rule_type、natural_language_input、generated_aml 等字段），但完全未被使用。我们需要新建自定义的 ItemType 来承载业务数据。

目标架构：分层、隔离、可追溯

要解决上述问题，我们需要一个清晰的分层存储架构。核心思路是：标准数据上服务端、用户数据本地化、变更可审核、同步可配置。

核心设计原则

1. 1. SCSAI 为标准库主库

：所有标准规则、模板和提示词集中存储到 SCSAI 服务端新建的自定义 ItemType 中。

1. 2. 本地库为缓存

：sciot_import.db 作为本地缓存，存储从 SCSAI 同步来的标准数据，以及预生成的产物（如编译后的规则）。

1. 3. 用户私有库为个性化层

：每个用户一个独立的 SQLite 数据库，只存储与标准库的差异（自定义、修改、覆盖）。

1. 4. 优先级明确

：用户修改 > 用户自定义 > 标准副本 > SCSAI 标准 > 回退默认。

1. 5. 双向同步可配置

：支持 SCSAI→本地（缓存更新）、本地→用户（增量推送）、用户→SCSAI（审核提交）三种同步模式。

分层架构：三层存储，各司其职

┌──────────────────────────────────────────────────────────────┐ │  SCSAI 服务端（标准库主库）                                    │ │                                                              │ │  5 个新建自定义 ItemType:                                    │ │ 
BossAgent_Rule（规则）                                    │ │  - BossAgent_Template（模板）                                │ │  - BossAgent_Prompt（提示词）                                │ │  - BossAgent_BizPrompt（业务提示词）                         │ │  - BossAgent_RuleContribution（规则贡献记录）                │ └──────────────────────┬───────────────────────────────────────┘                        │ AML 查询/创建                        ▼ ┌──────────────────────────────────────────────────────────────┐ │  sciot_import.db（本地标准缓存）                               │ │  现有核心表保持不变                                           │ │  新增 sync_state（同步状态记录）                               │ │  新增 sync_pending（待写回变更记录）                          │ └──────────────────────┬───────────────────────────────────────┘                        │ sync-service 增量同步                        ▼ ┌──────────────────────────────────────────────────────────────┐ │  user_library_{userId}.db（用户私有库）                        │ │  ┌────────────────────────────────────────────┐              │ │  │  user_rules（规则：标准副本/修改/自定义）     │             │ │  │  user_templates（模板：标准副本/修改/自定义） │             │ │  │  user_prompts（提示词：标准副本/修改/自定义） │             │ │  │  sync_submissions（待审核提交）               │             │ │  │  sync_state（同步状态）                       │             │ │  └────────────────────────────────────────────┘              │ └──────────────────────────────────────────────────────────────┘ 

关键设计细节

1. 标准库主库（SCSAI）

新建 5 个自定义 ItemType，字段设计参考 SCSAI 现有 Rule 和 Template 的丰富字段：

• BossAgent_Rule

：包含 rule_type（规则类型）、target_itemtypes（目标对象类型）、natural_language_input（自然语言输入）、generated_aml（生成的 AML 代码）、is_active（是否激活）、risk_level（风险等级）、approval_status（审批状态）等

• BossAgent_Template

：包含 aml_content（模板内容）、variables（变量定义，JSON 格式）、template_type（模板类型）、template_code（模板编码）、category（分类）、status（状态）等

• BossAgent_Prompt

：包含 operation_type（操作类型）、prompt_content（提示词内容）、version（版本号）、is_active（是否激活）等

2. 本地标准缓存（sciot_import.db）

现有 10 张核心表保持不变，新增两张表：

• sync_state

：记录每条数据的最后同步时间、同步状态（已同步/待同步/冲突）

• sync_pending

：记录用户本地修改但尚未写回 SCSAI 的变更，包含变更类型（新增/修改/删除）、变更时间、变更内容

3. 用户私有库（user_library_{userId}.db）

每个用户一个独立数据库，包含三类数据：

• standard_copy

：从标准库复制过来的副本，用户可在此基础上修改

• modified

：用户对标准库数据的修改，标记为“待审核”

• custom

：用户完全自定义的数据，仅自己可见

同步机制：让数据流动起来

分层存储的关键在于同步。我们需要一个智能的同步服务（sync-service）来管理三层之间的数据流动。

同步流程

1. 1. SCSAI → 本地缓存（标准更新）

定时或事件触发，从 SCSAI 查询最新的标准数据，更新本地缓存。冲突时以 SCSAI 为准。

1. 2. 本地缓存 → 用户私有库（增量推送）

当用户登录或主动刷新时，将本地缓存中的标准数据增量推送到用户私有库。用户可以选择“接受标准更新”或“保留自己的修改”。

1. 3. 用户私有库 → SCSAI（审核提交）

用户的修改或自定义数据，可以通过审核流程提交到 SCSAI。审核通过后，这些数据成为新的标准库内容，供其他用户使用。

优先级规则

当用户操作时，系统按以下优先级选择数据源：

1. 1. 用户对标准数据的修改（modified） 2. 用户自定义数据（custom） 3. 本地缓存中的标准副本（standard_copy） 4. 本地缓存中的标准数据（从 SCSAI 同步） 5. 回退默认值

这意味着，用户可以在不影响标准库的情况下，自由地修改和测试规则。只有当他们确定修改有效并提交审核后，这些修改才会影响其他用户。

落地实践：从混乱到有序

有了分层存储架构，我们来看看如何落地实施。

第一步：数据迁移与清洗

将本地 sciot_import.db 中的 6,000 多条数据按照“标准”和“用户”进行划分。标准数据（如初始规则、通用模板）迁移到 SCSAI 服务端的新 ItemType；用户数据（如个性化规则、测试模板）保留在用户私有库中。

第二步：建立同步服务

开发 sync-service 模块，负责三层之间的数据同步。该服务需要：

• 支持 AML 查询和创建操作 - 实现增量同步，避免全量传输 - 处理冲突检测和解决 - 记录同步日志，便于审计

第三步：前端改造

前端应用需要适配分层架构：

• 规则管理面板：显示当前用户可用的所有规则（标准+用户修改+用户自定义），并标明来源 - 模板库：类似处理，支持用户复制标准模板进行修改 - 提示词管理：支持版本对比和回滚

第四步：审核流程集成

在用户私有库中，所有修改都标记为“待审核”。用户提交审核后，系统自动创建审核任务，通知管理员审批。审批通过后，数据写入 SCSAI 标准库，并更新本地缓存。

结语：让规则、模板和提示词成为企业资产

分层存储不仅仅是一个技术方案，更是一种管理理念的转变。它让规则、模板和提示词从“混乱的数据”变成了“可管理的企业资产”。

BossAgents（左帮右臂） 专注于为企业提供智能化的规则、模板和提示词管理解决方案。我们的分层存储与同步机制，能够帮助你的企业：

• 告别数据混乱

：标准数据与用户数据分离，每个人都在自己的“沙盒”中工作

• 实现版本追溯

：每一次修改都有记录，每一次回滚都有依据

• 建立审核流程

：错误操作不再直接上线，审核机制为你保驾护航

• 支持个性化需求

：不同角色、不同团队可以拥有自己的规则覆盖，互不干扰

• 确保数据安全

：本地缓存与 SCSAI 主库双向同步，数据永不丢失

从“混沌”到“清晰”，从“被动救火”到“主动管理”，这就是分层存储带来的改变。如果你也在为规则、模板和提示词的管理而烦恼，不妨试试这个方案——它可能就是你一直在寻找的答案。