OpenClaw 实战系列:B端系统架构适配AI时代,从穷举配置到数据价值榨干

🎯 开篇 · 一个B端产品经理的自问

做B端产品的都懂这种感觉：需求一来，第一反应就是”这能不能做成可配置的？”

规则引擎、表单设计器、流程编排器……往根上说都是一个思路：把业务逻辑从代码里抽出来，变成配置项。

但你没想过的是——这个思路的底层假设是什么？

三个字：可穷举。

你得把客户所有可能的需求排列组合想清楚，然后抽象成配置项。第一版十几个参数，三年后几百个。配置界面比业务系统本身还复杂。客户来一句”我们情况跟你们预设的都不一样”，你三年的配置心血瞬间白费。

有一篇文章把这个问题总结得很精炼——配置化的本质是穷举，而AI不需要穷举，它理解意图就够了。

这句话狠狠击中了我。但击中我的方式可能和大多数人不太一样。

我读完第一反应不是”说得真好”，而是：

好，怎么落地？

我不能全盘否定配置化，也不能指望客户明天就用AI。我需要找到一个可以开始动手的具体路径。

📐 第一章 · 我真正想做的事

过去这几个月，我一直在做一件事：

把我维护的B端系统里的一个功能模块，通过AI接口（OpenAPI）暴露出来，让Agent可以像人一样理解它、操作它。

我选的是KPI考核模块。

传统做法你得先穷举所有场景：得分分几种规则？录入分几个入口？审批走什么节点？每一组排列组合都得预先想到。

但数据本身的真正价值呢？

这8个字段，每个都是一个数据资产。传统页面只能展示2-3个维度的组合——比如”部门+得分”或”指标+趋势”。但AI不一样，AI可以利用每一个字段的每一个价值。

你不需要为每一种查询场景单独开发一个接口。只需要把数据结构和业务语义定义清楚，AI自己会组合、会解读、会给出结论。

这月某个部门的KPI得分、扣分集中在哪几个指标、去年同期对比如何——三个完全不同的问题，在传统架构里需要三张不同的报表页面。在AI架构里，一套接口就够了。

🔧 第二章 · 落地方法：把模块变成Skill

所谓的Skill，本质上是在你的Java项目里，用一套配置文件定义好三件事：

• “AI可以调用我的哪些能力” → 接口定义
• “每个能力需要什么参数” → 参数校验
• “每个能力返回什么” → 数据结构

下面这张流程图能说明整个调用链路：

┌─────────────────────────────────────────────────────────┐
│                    用户自然语言输入                       │
│   "帮我看看这个月某个部门的KPI完成情况"                      │
└────────────────────────┬────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────┐
│                  Agent / LLM (意图理解)                   │
│  ┌──────────────────────────────────────────────────┐   │
│  │  识别意图：查询该部门KPI得分明细                      │   │
│  │  匹配能力：得分明细查询                             │   │
│  │  填充参数：{部门:"某部门", 维度:"明细"}             │   │
│  └──────────────────────────────────────────────────┘   │
└────────────────────────┬────────────────────────────────┘
                         │ POST /openapi/call/{能力路由}
                         ▼
┌─────────────────────────────────────────────────────────┐
│                OpenAPI 接口层 (Skill协议)                 │
│  ┌──────────────────────────────────────────────────┐   │
│  │  ✅ 鉴权校验  →  appkey + signature + timestamp   │   │
│  │  ✅ 参数校验  →  必填参数完整性检查                │   │
│  │  ✅ 路由转发  →  匹配后端具体Controller            │   │
│  └──────────────────────────────────────────────────┘   │
└────────────────────────┬────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────┐
│              后端 Controller + Service                    │
│  ┌──────────────────────────────────────────────────┐   │
│  │  Spring Boot / MyBatis / MySQL                    │   │
│  │  拼接SQL、计算得分、组装响应                        │   │
│  └──────────────────────────────────────────────────┘   │
└────────────────────────┬────────────────────────────────┘
                         ▼
┌─────────────────────────────────────────────────────────┐
│                  Agent 返回给用户                        │
│  "某部门本月KPI完成率87%，3个指标有扣分，主要因为..."    │
└─────────────────────────────────────────────────────────┘

三层各司其职：

第一层 🧠 Agent层——负责理解意图和命中准确度

Agent不需要猜测用户想干什么。

每个Skill都定义好了能力名称、请求参数和返回值结构。Agent通过自然语言理解用户说的是什么，然后匹配到对应的能力，生成正确的请求体发出去。

Prompt和function calling设计的目标极其简单：确保准确度，不要让Agent瞎猜。

第二层 🔌 接口层——后端控制一切

这是最关键的决策：后端说了算。

在传统方案里，后端往往是”被动”的——前端要什么数据，后端就提供什么接口。前端变了，后端跟着改。

但在这个新架构里，后端变成”主动”的：

后端控制的几件事：
┌────────────────────────────────────────────┐
│ ① 鉴权：谁可以调这个接口？什么权限？         │
│    → appkey + 签名 → 验证调用方身份          │
│                                            │
│ ② 参数校验：传进来的参数合法吗？               │
│    → scope必须是company或dept，不能乱传      │
│                                            │
│ ③ 数据组装：SQL怎么写？返回结构什么样？        │
│    → 后端工程师定义DAO和VO，保证数据质量       │
│                                            │
│ ④ 业务逻辑：得分的计算公式是什么？             │
│    → 业务规则写在后端，Agent不绕过           │
└────────────────────────────────────────────┘

Agent没有绕过业务逻辑的权限。它只是一个聪明的调度器——以前用户点菜单、选条件才能完成的操作，现在Agent一步到位。但执行时候调用什么数据、执行什么计算，后端说了算。

第三层 🗄️ 数据层——从这里开始榨干价值

传统做法里，数据层是”被动”的——前端需要什么就取什么。新架构里，数据层是”主动”的——每个字段都应该被定义为可被AI利用的资产。

数据不再只是给页面展示用的，而是给AI解读和利用的。 这中间的差异，就是你能不能把B端系统从”工具平台”升级到”智能平台”的关键。

🤔 第三章 · 页面其实是为了穷举

B端系统页面存在的本质目的，其实就是穷举。

你要在页面上展示所有可能的操作入口——因为用户不知道有什么可以做的。你要把筛选条件全部列出来——因为你不知道用户想按什么维度查。你要把报表的每一个维度做成可拖拽的配置——因为你怕漏掉用户可能需要的组合。

页面的底层逻辑就是”把所有可能性摆在台面上”。

但问题来了——如果没有最终的结论，页面再丰富也是浪费时间。

用户翻了三页筛选条件、点了五次下拉菜单、切了两个tab，最后得到一张表格。然后呢？他没有时间逐行分析，他要的是结论。

AI的加入给出了一个全新的交互范式：

用户说：”销售部这个季度KPI完成情况怎么样？主要扣分点在哪？”

传统做法 → 跳转到KPI报表页，加载完数据，用户自己看排名、看趋势、手动做对比分析

AI做法 → “销售部Q1全面KPI得分为82.6分，略低于公司平均的85.4分。主要扣分集中在3个指标：①营收目标值设置偏高（实际完成率87%），②客户满意度数据有2个月未录入，③部门培训考核指标缺失。建议优先补数据再调整目标值。”

页面从操作入口变成了异常兜底和校验入口。AI才是高频操作的主入口。

你甚至可以想象未来的B端系统中，传统页面只保留两个场景：① AI搞不定时的降级入口，② 权限敏感操作的二次确认页面。 其余日常操作，全部由AI直面用户。

🔄 第四章 · 拆掉配置化的墙

说到”配置化”，不得不面对一个隐秘的现实：配置化越成功，信息孤岛越严重。配置项越多，系统越重，越不敢改。

你把业务逻辑抽出来变成配置项，本质上是把人对业务的理解”编码”成机器能执行的规则。但这个编码过程损失巨大——人的判断力是连续的、有弹性的，规则是离散的、刚性的。而且改一个规则可能牵涉几十个配置项的连锁反应。

看看配置化的三个阶段：

AI带来的变化是：不需要编码了，直接理解。

在KPI模块里，最明显的变化是输入数据的处理：

不再需要用户去适应系统的格式。系统去理解用户的表达。

🧩 第五章 · 不是取代，是重心的转移

那传统配置化就全扔了吗？当然不是。

我画了一个四象限来分析每个场景应该放在什么位置：

                    确定性高
                      │
                      │
  ┌───────────────────┼───────────────────┐
  │                   │                   │
  │  🟢 结构化配置     │   🟡 提示词路由   │
  │  （传统配置项）     │   （Agent调度）    │
  │  工单优先级分类     │   function calling │
  │  审批流节点选择     │   上下文理解       │
  │  权限角色管理       │   意图匹配         │
  │                   │                   │
  ├───────────────────┼───────────────────┤
  │                   │                   │
  │  🔴 硬编码规则     │   🟢 AI理解       │
  │  （不可协商）       │   （最佳场景）     │
  │  财务记账规则       │   非结构化数据提取  │
  │  合规审计约束       │   复杂条件综合判断  │
  │  数据权限隔离       │   模糊意图识别     │
  │                   │                   │
  └───────────────────┼───────────────────┘
                      │
                      │
                    确定性低

• 硬编码规则 → 不可商量，错了就是事故
• 结构化配置 → 确定性高、范围有限，传统方式最高效
• AI理解 → 模糊、复杂、难以穷举的场景，AI的优势区间
• 提示词路由 → 中间地带，Agent调度但由后端控制边界

但我的重点在这里——我最近感触最深的一个认知：

AI不是消灭了配置化，而是把配置化的重心从”穷举规则”转移到了”定义数据价值”上。

过去花80%的时间在想规则怎么配，现在应该花80%的时间在想数据结构怎么设计、接口怎么暴露、每个字段在AI视角下有什么价值。

这不是不干活了——这是换了一种更高级的干活方式。

💡 第六章 · 从单个模块到全系统：推广路径

一个KPI模块跑通了，怎么推广到全系统？

关键原则：先核心后外围，先查询后写入，先辅助后主导。

不要一次性铺开。从最痛的那个模块开始，跑通流程，让团队看到效果，再做推广。

⚠️ 第七章 · 三个必须接受的现实

1️⃣ AI的不确定性，在B端是致命的

AI可能把工单分错类、把审批路由判断错。在B端这是生产事故。

解决方式不是”让AI更准”——而是人工兜底。

AI推荐 → 人工确认 → AI全权处理

这个信任曲线必须走。不能跳过。

2️⃣ AI不是免费的

每次调用都有token成本：

每个场景都要算账。不要为了AI而AI。

3️⃣ 这不是革命，是渐变

不指望客户明天就全面拥抱AI。策略是：

• 先做查询和分析类（容错高）
• 再做录入和修改类（可控范围内）
• 最后做审批和决策类（建立信任后）

🎬 结语

B端产品过去十几年的核心范式是：穷举，然后配置。

做得好的，系统功能丰富但臃肿；做得差的，配置项比业务功能还多。

AI带来的底层改变不是消灭配置化——而是给了你一个选择：穷举不再是必要条件。

你不需要预设所有可能性。只需要把数据价值和接口能力准备好，AI自己会组合、会理解、会给出结论。

对B端产品经理来说，新的课题变了——
过去是："这个能不能做成可配置的？"
现在变成了："这个数据怎么能被AI利用起来？"

每一个字段都是资产。以KPI模块为例——那个你拖了三个月都没想好怎么展示的备注字段，AI不仅能读懂，还能从中提取关键信息辅助决策。你敢说自己系统里的所有字段，没有一个是在躺着睡觉的吗？