前言

在过去的五年里，无数企业投入巨资建设“企业级低代码平台”，旨在通过可视化的拖拽和配置来降低开发门槛、提升交付效率。然而，随着 Copilot、Cursor 等 AI 编码工具的爆发式增长，一个尴尬且危险的局面正在浮现：

那些曾经被视为“提效利器”的自建低代码平台，正在成为企业拥抱 AI 编码时代最大的阻碍。

这并非单纯的资源竞争或部门政治，而是两者在底层数据逻辑、上下文构建以及信任机制上存在根本性的互斥。在 AI 试图理解并重构软件工程的今天，自建低代码平台却因为其封闭性、文档缺失和黑盒逻辑，成为了 AI 无法触及的“技术荒原”。

一、 底层逻辑的冲突：文本 vs. 元数据

AI 编码工具（LLM）的本质是基于文本（Text）的预测引擎。它们在数以亿计的 GitHub 代码仓库中学习了 Python、Java、SQL 的语法、逻辑流和最佳实践。

只要是文本，AI 就能理解、补全甚至重构。

然而，企业自建低代码平台的本质是元数据（Metadata）。

当开发者在画布上拖拽一个组件，或在表单里配置一个流程时，并没有生成 AI 可读的代码。这些逻辑被转化为了数据库中的 JSON 字段、私有的 XML 协议，甚至是二进制的 BLOB 数据。

• AI 的视角： AI 看不懂你们公司私有的 XML 定义，也无法解析存储在数据库字段里的业务逻辑。
• 结果： 只要业务逻辑被锁死在低代码的私有协议里，AI 就成了“盲人”。它无法通过阅读代码来理解业务，也无法通过生成代码来修改配置。

低代码试图通过“消灭代码”来提效，而 AI 则是通过“极速生成高质量代码”来提效。在 AI 能力爆发的今天，标准化的文本代码反而比封闭的配置数据更具生命力。

因此，元数据的设计天然是反AI的。

二、 低代码的存储方式，让AI丢失了上下文

AI 编码工具的强大依赖于 Context Window（上下文窗口）。它需要读取项目的文件结构、引用关系（Import/Export）和类型定义，才能构建出完整的依赖树，从而给出精准建议。

传统工程有着清晰的文件系统和模块化规范，但在自建低代码平台中，逻辑往往是极度碎片化的：

• 一段校验脚本藏在前端页面的配置里；
• 一段数据处理逻辑埋在后端模型定义的 SQL 里；
• 一段流转规则写在工作流引擎的 XML 属性中。

这些碎片之间没有标准的“引用路径”供 LLM 索引。AI 无法获得全局视图，只能在局部的“脚本框”里写几行孤立的代码。

这导致 AI 无法进行系统级的重构，也无法理解模块间的副作用。

三、 RAG 的失效：文档缺失导致的“幻觉”

在企业级 AI 开发中，文档即是 AI 的特征工程（Documentation is Feature Engineering for AI）。

当开发者询问 AI “如何使用公司的 CorpTable 组件”时，AI 依赖 RAG（检索增强生成）技术去查找文档。然而，企业自建组件库往往面临严重的文档缺失问题。

1. 无法检索： AI 找不到关于 Props、Events 或 Slots 的说明，只能依靠训练时见过的开源组件（如 AntD）来“瞎猜”用法。
2. 上下文浪费： 为了让 AI 写对代码，开发者被迫将组件的源码整段复制给 AI。这不仅浪费了宝贵的 Token，还让 AI 被组件内部的实现细节干扰。
3. 部落知识陷阱： 用法全靠口口相传。新员工无法通过 AI 快速上手，老员工也疲于解答。

没有文档的自建组件库，在 AI 眼中就是一堆不可解释的黑盒。这直接导致 AI 生成的代码充满了属性名错误的“幻觉”，根本无法运行。

四、 信任的崩塌：黑盒与不可靠链

如果说文档缺失让 AI “难用”，那么自建平台中不可控的黑盒逻辑则让开发者对 AI 彻底“不敢用”。

AI 生成代码有一个隐含前提：底层依赖是确定性的（Deterministic）。但在企业自建环境中，组件往往因为历史包袱积压了大量“业务侵入逻辑”或 Bug：

• 调用 disable() 可能莫名其妙触发了一个网络请求；
• 传入空数据可能直接导致页面白屏。

为了规避这些 Bug，资深开发者习惯了编写大量的 Workaround（防御性代码/变通写法）。

• 冲突点： AI 只有标准知识，它会写出逻辑正确但无法在“黑盒”上运行的标准代码。
• 调试地狱： 当代码报错，报错堆栈往往指向混淆后的内核深处。AI 无法透视黑盒，无法分析原因。

最终，开发者发现：用 AI 生成代码后，修补 Bug 的时间比自己手写防御性代码的时间还要长。 这种技术上的不信任感，导致开发者在心理上抗拒在平台内使用 AI，甚至将 AI 视为逃离平台的工具。

从“低代码”转向“AI”是企业技术管理层必须接受的结论

企业自建低代码平台，本质上是上一个技术周期的产物。它假设“代码是昂贵的、难维护的”，因此试图用配置来替代代码。

然而，AI的爆发式生长改变了算式：代码变得廉价且易于生成，而私有的、黑盒的、无文档的配置数据，变成了新的技术债务。

对于企业技术决策者而言，现在是时候重新评估技术栈的演进方向了：

• 停止建造封闭的“高墙花园”。
• 转向构建标准化的、文档齐全的、对 AI 友好的（AI-Readable）基础设施。
• 衡量平台的指标，不应再是“少写了多少行代码”，而是“AI 能多大程度上理解并接管这些代码”。