壹、先說結論

我們用低代碼平臺，交付了壹套覆蓋分包商全生命周期的管理系統——從資質準入、合同履約、現場進度，到計量結算、支付控制、履約評價，全部在壹個平臺上閉環。

更值得說的是構建方式：這套系統的大部分結構，不是拖拽出來的，是對話出來的。

我們把業務需求寫成結構化的自然語言描述，交給運行在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.轉載請註明來源。