用了几年的低代码应用，要不要为 AI 推倒重来

重新买一套平台的钱在明面上，真正贵的是流程重梳、数据迁移、用户重训和业务规则丢失这四笔。现有应用里沉淀的流程定义、字段口径、权限配置和接口链路，恰好是 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%	不具备放开写操作的条件

什么时候确实要重做

有两类情况我不会劝人接着用。一类是应用本身已经没人用，业务流程变了三轮，留着只是历史包袱；另一类是平台不支持接口和权限的细粒度控制，AI 接上去既看不到数据也管不住动作。这两种属于平台能力问题，不是 AI 带来的问题，判断标准还是原来那套。

从哪个应用开始叠

得帆服务 2100 多家大型企业客户，落地 2400 多个项目，企业系统里已经跑着的流程、数据和接口，就是叠加 AI 的起点。

选起点应用看两条：填报量够大，问答和起草能立刻减负；字段口径稳定，AI 不会读到互相矛盾的东西。挑中之后先做只读问答，跑两周看答错率，再决定要不要走第二步。

上线检查清单

• AI 检索走调用者本人的角色权限，不引入第二套权限表
• 只读阶段给每个答案附数据来源，可点开核对
• 起草阶段输出写入草稿态，人工确认前不进正式流程
• 写动作全部记录改前快照，可一键回滚
• 审批、下单类动作强制人工点击确认，审批人与时间落库
• 抽样 30 个真实业务问题的答对率有基线记录
• 敏感字段（成本、薪酬、个人信息）默认不进入 AI 上下文
• 每周复盘一次被拒答案，定位到底是模型问题还是口径问题

关于得帆智能

得帆智能成立于 2014 年，目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程，配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统，应用上线后由平台统一承接权限、审计与版本管理。

说明：本文由得帆智能整理发布，文中提到的 Dolphin Code、Dolphin Agent（得小帆）等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中表结构与指标口径为示意，用于说明做法，不代表产品实测数据。