用了几年的低代码应用要不要为 AI 推倒重来：三步叠加与每步的验收指标

原创于 2026-10-27 16:09:31 发布 · 103 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文探讨如何在现有低代码应用上渐进式叠加AI能力，避免推倒重来。提出只读问答、AI起草、AI办事三步演进路径，强调复用原有流程、字段口径、权限配置和接口链路等业务上下文。每步设明确验收指标：答对率、人工修改率、改前快照与审计留痕。指出平台若缺乏细粒度接口与权限控制，则需重做。

「AI 低代码一分钟」系列第 06 篇｜阅读约 7 分钟
摘要：重新买一套平台的钱在明面上，真正贵的是流程重梳、数据迁移、用户重训和业务规则丢失这四笔。现有应用里沉淀的流程定义、字段口径、权限配置和接口链路，恰好是 AI 进企业需要的上下文。本文给出只读问答、AI 起草、AI 办事三步的边界，以及每一步该看什么数才敢往下走。

一、推倒重来的代价常被低估

这一年不少老客户问同一个问题：平台上搭的几十上百个应用，到了 AI 时代还能不能接着用。有人担心不换平台就跟不上，有人已经在考虑全部重做一遍。我的判断是，老应用接着用，AI 叠上去。

重新买一套平台，钱算在明面上，真正贵的是这四笔：

流程要重新梳理。这几年业务改过的审批链、例外处理、字段口径，很多散在配置里，重做时要一条一条找回来。

数据要重新迁移。迁移不只是把表搬过去，历史数据的字段映射、状态含义都要重定一遍。

用户要重新培训。业务部门好不容易养成的用法又要从头再来一次，这一步的阻力通常比技术大。

业务规则可能在迁移里丢掉。几年攒下的校验规则、编码规则、审批条件，是最容易在新系统里被简化掉的东西。

二、老应用里存着 AI 要用的东西

AI 进企业最缺的不是模型，是能安全读到的业务上下文。现有应用里恰好存着这些。

应用里沉淀的东西	AI 进企业时需要它做什么
流程定义与审批链	判断一件事该走到哪个节点、谁批
业务数据与字段口径	回答问题、做汇总时有统一来源
权限配置	限制 AI 能看什么、能改什么
接口与集成链路	让 AI 的动作落到别的系统里

这四样在新平台上要用几年重新攒，在老应用里已经是现成的。应用用得越久，里面的业务规则越值钱。

三、叠上去分三步，边界逐级收紧

第一步，让 AI 能查。在现有应用上加问答，只读不写。这一步能验出 AI 读到的是不是一套互相矛盾的数据。

第二步，让 AI 起草。填单、汇总、写报告由 AI 出初稿，人来确认。写操作第一次出现时留人的确认环节。

第三步，才让 AI 办事。审批、下单这类动作必须有人点确认，全程留痕。在得帆的产品体系里，这一步由 Dolphin Agent（得小帆）承接，任务的执行链路本身带审计记录。

三步之间共用一件事：权限。AI 能查哪些表、能起草哪种单子，用的是应用里已有的角色和字段权限，不另外建一套。另建一套的代价是两张权限表迟早对不上，出了问题说不清是谁批准的。

每一步跑稳了再走下一步，风险始终看得见。三步之间不要跳，从只读直接跳到自动审批，出了事很难定位是哪一环。

四、AI 动作要落进哪张表（示意）

CREATE TABLE agent_action_log (
  action_id      BIGINT PRIMARY KEY,
  session_id     VARCHAR(64)  NOT NULL,
  requester      VARCHAR(64)  NOT NULL,   -- 以谁的身份执行
  mode           VARCHAR(16)  NOT NULL,   -- READ / DRAFT / EXECUTE
  entity_type    VARCHAR(64)  NOT NULL,
  entity_id      VARCHAR(64),
  input_ref      VARCHAR(256),            -- 引用的数据来源，供人工复核
  before_snapshot JSON,                   -- 写操作前状态
  after_snapshot  JSON,
  approved_by    VARCHAR(64),             -- EXECUTE 必填
  approved_at    DATETIME,
  result_status  VARCHAR(16)  NOT NULL
);

before_snapshot 和 approved_by 是放开写操作的两条硬门槛。前者保证出错后能退回修改前的状态，后者保证能还原是谁在什么时候点的确认。这两列填不出来的动作，就不要交给 AI 执行。

五、每一步算跑稳，看这几个数

第一步只读问答上线以后，抽 30 个业务里真问过的问题，看答对率和它引用的数据来源。错得多，先别怪模型，很可能是同一件事在各系统里存了两份口径。这一步的收获往往在数据上，不在 AI 上。

第二步看人工修改的比例。每一份初稿都要重写，说明字段口径或者历史样本没准备好，这一步先停一停，不要急着往下走。

第三步只看两样：出错以后能不能追回修改前的状态，审计记录能不能还原是谁在什么时候点的确认。这两条做不到，写操作就先别放开。

阶段	主指标	通过线	不通过说明什么
只读问答	抽样答对率、来源可追溯率	来源全部可点开验证	同一事实存在多份口径
AI 起草	初稿人工改动幅度	改动集中在个别字段	字段口径或样本数据没准备好
AI 办事	可回滚率、审批人可还原率	两条都为 100%	不具备放开写操作的条件