一、先说结论

我们用低代码平台，交付了一套覆盖分包商全生命周期的管理系统——从资质准入、合同履约、现场进度，到计量结算、支付控制、履约评价，全部在一个平台上闭环。

更值得说的是构建方式：这套系统的大部分结构，不是拖拽出来的，是对话出来的。

我们把业务需求写成结构化的自然语言描述，交给运行在Claw生态中的AI智能体，由它调用低代码平台的系统方法，直接创建数据表、字段关联、审批工作流、自动化规则和统计仪表盘。人负责业务判断与结果校验，机器负责把结构落地。

这不是"AI辅助写代码"，而是AI直接操作信息化系统。这是两者之间一条本质的分界线。

二、为什么分包商管理值得被认真对待

在建筑、工程、制造外包这类行业里，分包商管理长期处于一个尴尬位置：它是成本控制的关键环节，却往往用 Excel加微信群在管。我们梳理下来，最痛的四件事是：

其一，资质风险靠人肉盯。安全生产许可证、施工资质、特种作业证书，到期时间散落在各个项目的台账里。等到发现过期，往往是在一次检查或者一次事故之后。

其二，工程量的口径三套并行。合同清单一套、现场收方单一套、结算单再一套。同一个部位跨期次重复申报、变更没有回写合同，最终在竣工结算阶段集中爆发争议——而钱，可能已经付出去了。

其三，超付缺乏系统性拦截。结算行如果可以自由文本填写，系统就无法做量价校验。缺少"累计量控制、付款上限控制、单价一致性"的硬校验，超付就不是风险而是概率问题。

其四，履约评价是沉睡数据。评价表填得很认真，但评分不写入任何决策环节。优质的分包商和劣质的分包商，在投标资格、保证金比例、付款条件上毫无差别——那评价就是一张废纸。

这四件事，本质上不是管理意愿的问题，是系统结构上能不能承载的问题。

三、我们交付了怎样一套系统

系统围绕三条主线展开：准入—执行—评价，而支撑它们的是一套统一的数据底座。

模块一：分包商准入与档案

· 工商主体、资质证书、安许证的OCR识别与结构化入库

· 到期前30天自动预警，证照失效自动冻结投标与付款权限

· 涉诉、行政处罚、安全事故的外部风险数据同步

· 全字段变更留痕，支持版本对比

模块二：合同与履约

· 合同清单行级结构化（清单编码+WBS双主键），量价分离

· 变更索赔审批后自动回写合同工程量与合同额

· 合同交底任务自动推送至项目、成本、财务

模块三：现场执行

· 任务分派到清单行，明确计划量与工期

· 进度上报强制携带时间、定位、水印的现场影像

· 质量验收（检验批/隐蔽工程/分部分项）完成后方可进入计量

模块四：计量结算与支付

· 月度计量自动按"已验收合格工程量"预填基准数据

· 结算明细行挂接清单编码，单价取自合同价库，锁定不可改

· 十项防超付校验实时执行，红色项为硬阻断而非提示

· 扣款项（甲供材料、水电、罚款、质保金）当期自动计算

模块五：履约评价与看板

· 质量30%/进度25%/安全20%/配合度15%/合规10%的评分卡

· 扣分由业务单据自动触发，可下钻到具体来源单据，支持申诉

· A/B/C/D分级结果硬绑定保证金比例、付款上限、抽检强度、投标权限

四、什么是「小龙虾模式」

这是本文最需要讲清楚的一个概念。

Claw（中文社区昵称"小龙虾"）指的是以OpenClaw为代表的一类开源AI智能体运行框架。它和常见的 AI 助手最大的区别在于：它不是回答你的问题，而是调用工具去执行你的任务——登录系统、导出数据、创建记录、触发流程，都在它能力范围内。

行业里由此演化出一个说法：

关键差异不在"AI会不会做"，而在人是否还在回路里逐帧确认。

在这件事上做了什么？

低代码平台为这套生态定制了系统级的Informat Skill。它不是一个简单的说明文档，而是一整套可被智能体调用的系统方法集合——根据官方页面标注，当前版本已覆盖200+个系统方法，包括：

· 数据表：表、字段、记录的创建与管理

· 自动化：自动化流程编排

· 工作流：BPMN2.0流程设计

· 仪表盘：图表与统计分析

· 脚本：JavaScript执行

· API接口管理、定时任务调度、页面资源管理、多语言支持

换句话说：AI拿到的不是"怎么描述一个表"，而是"怎么真的建一个表"的能力。

这是"让AI直接操作信息化系统"这句话的技术落点。

五、对话式构建，实际是怎么发生的

我们把整个构建过程拆成了五步，每一步的产出都可验证、可回滚。

第一步：把业务需求写成结构化描述

这是唯一需要人深度投入的环节，也是决定生成质量的关键。我们发现，写得越像一份简明的PRD，AI的生成质量越高。

我们所采用的一段典型输入如下：

#分包商管理系统

##1.目标
管理分包商从准入到结算退出的全生命周期，实现资质合规前置校验、
工程量统一口径、防超付硬拦截、履约评价闭环。

##2.功能结构
- 分包商档案
- 合同管理
- 现场进度
- 计量结算
- 支付管理
- 履约评价

##3.核心要求
###3.1分包商档案
- 工商主体、资质证书、安许证、银行账户
- 证照到期自动预警，失效自动冻结付款
- 支持按专业、区域划分可承接范围

###3.2计量结算
- 明细行必须挂接清单编码，单价取自合同价库
- 累计工程量不得超过变更后合同量
- 累计付款不得超过约定比例上限
- 未完成质量验收的工程量不得计入本期

###3.3履约评价
- 评分由业务单据自动触发扣分
- 分级结果影响投标权限、保证金与付款比例

第二步：AI生成数据模型

智能体调用Informat Skill的数据表方法，创建数据表、字段、字段类型与表间关联关系。

这里有一个值得称道的工程设计：Skill内置了"先读文档与参数定义、再执行调用"的闸门机制。当AI第一次操作某个领域（比如建表）时，脚本要求它先读取该领域的设计文档和参数结构，确认后才允许执行；后续同类操作则放行。同时脚本在本地对必填项、枚举值、参数类型做二次校验。

这个机制解决的是AI构建系统时最致命的问题——参数臆造。没有它，AI生成的结构看着漂亮，实际调用全是错的。

第三步：AI编排流程与自动化

用同样的对话方式描述业务规则：

"结算单审批流：分包商申报 → 现场工程师核定 → 成本复核 → 财务审核 → 项目经理审批，单笔超过50万自动升级至分管领导。"

智能体据此生成BPMN工作流节点、条件分支与自动化监听规则。

第四步：AI生成仪表盘

"生成分包成本分析看板：按项目维度展示合同额、累计结算、付款比例；异常预警区单独列出超限单据。"

第五步：人工校验与收敛（不可省略）

这一步必须诚实说明：AI生成的是高质量的起点，不是可以直接投产的终点。

我们的做法是分三条轨道校验：

1.数据模型校验——字段类型、关联关系、主键设计是否符合长期演进要求

2.业务规则校验——尤其是防超付、权限穿透这类"错了代价很大"的规则，逐条对照需求复核

3.性能与权限校验——索引、查询效率、角色可见范围

六、三条踩坑经验

第一，先立模型，再谈页面。AI生成页面的速度远快于生成正确的数据模型。如果表结构、关联关系、主键没有想清楚，页面做得再快也是技术债。我们坚持先把数据模型校验通过，再生成界面。

第二，把"错了代价最大"的规则留给人工。像防超付校验、权限穿透这类规则，AI可以做初稿，但必须由熟悉业务与财务的人逐条确认。这不是不信任AI，是风险分级。

第三，权限体系必须在第一天就设计好。低代码平台权限引擎粒度可以下钻到组织、角色、应用、模块、记录、字段、控件、数据行。这套东西一旦系统成型后再补，改造量远超从一开始就设计。

七、结尾

低代码走到今天，正在完成一次分层：

·轻量的表单工具解决"有没有"的问题

·企业级低代码解决"能不能长期用"的问题

·AI原生+Claw生态解决的是"谁都能建、且随时能改"的问题

三者不在同一个维度上竞争。

我们这次实践最大的收获，不是省了多少人天——而是确认了一件事：当AI具备了直接操作业务系统的能力，"提需求"和"交付系统"之间的距离，正在被压缩到一次对话。

对业务侧而言，这意味着不再需要等排期；对IT侧而言，这意味着从"做需求的执行者"变成"定规则的治理者"。

文章注释说明：© 2026 深圳高益科技有限公司.All Rights Reserved.转载请注明来源。