夜雨聆风引言：AI Coding 会终结低代码吗
过去十余年，低代码开发平台在企业软件建设中扮演了重要角色。它通过数据模型、界面模型、逻辑模型、流程模型和报表模型，把大量重复、通用的软件开发工作封装起来，使开发者和业务人员能够用配置、建模和少量代码交付应用。
今天，这套价值逻辑正在受到 AI Coding 的直接挑战。
AI 已经不再只是补全几行代码。新一代 Coding Agent 可以阅读代码库、理解任务、修改多个文件、执行测试、分析失败原因，并以分支或 Pull Request 的形式提交结果。GitHub 对 Coding Agent 的定义也已从 IDE 中的代码辅助，延伸到“接收 Issue、探索仓库、完成修改并创建 Pull Request”的异步工程任务。这意味着，过去必须依靠平台抽象和可视化配置才能降低的代码门槛，如今也可能被自然语言和通用代码智能体降低。
于是，一个看似尖锐的问题出现了：当 AI 可以直接写代码，企业为什么还需要低代码开发平台？
一个简单直接的回答是：
AI Coding 解决“写代码”的问题，开发平台解决“交付企业应用”的问题。
这个判断仍然成立，但需要更准确的解释。随着 Coding Agent 的能力向测试、评审、持续集成和运维任务延伸，AI Coding 已经不只是在生成代码。因此，更完整的表述是：
AI Coding 的中心对象是代码库和工程任务；开发平台的中心对象是企业应用及其全生命周期。
两者不是简单的替代关系。AI Coding 解决的是通用的软件生产能力，开发平台承担的是企业语义沉淀、公共能力复用、工程约束执行和应用生命周期治理。未来真正有竞争力的开发平台，不是给原有设计器增加一个聊天窗口，而是把 AI 变成软件生产体系中的一等参与者，将自身重构为 AI 原生开发平台。
一、重新认识低代码开发平台
如果把低代码平台理解为“拖拉拽页面的工具”，它确实很容易被 AI Coding 替代。但这只是低代码平台最表层的交互形式。
一个完整的企业级低代码开发平台，通常包括三个相互关联的平面。
1. 开发平面
开发平面负责把业务需求转化为软件资产，典型能力包括：
数据实体、字段、关系和校验规则的数据模型； 页面、组件、布局和交互行为的界面模型； 前端交互逻辑和后端处理逻辑； 审批、编排和状态流转的流程模型； 查询、统计、报表和打印模型； 外部系统连接、API 编排和数据集成； 测试、构建、版本管理和部署。
传统平台的主要操作对象是可视化模型或元数据，运行时再由解释引擎执行，或者由生成器产出部分代码。
2. 运行平面
企业应用不是若干页面和接口的简单集合。它通常依赖一组长期稳定、跨项目复用的公共能力，例如：
用户、组织、岗位、角色和数据权限； 审批流、业务规则、消息和定时任务； 主数据、编码规则、文件、打印和电子签章； 事务、缓存、搜索、集成和异常处理； 日志、监控、审计、告警和运行分析。
这些能力决定了一个应用是否真正“可运行、可管理、可持续维护”。它们也是开发平台区别于纯代码生成工具的重要基础。
3. 控制平面
控制平面负责管理应用从创建到退役的全过程，包括开发、测试、预生产和生产环境管理，版本与依赖管理，发布审批，安全扫描，质量门禁，数据策略，合规审计和运行治理。
微软的低代码应用生命周期管理指南明确提醒，不应把低代码工作负载视为低复杂度工作负载。低代码应用仍然需要正式的需求管理、版本控制、自动化测试、CI/CD、部署控制和维护支持。由此可见，低代码平台的范围从来不只是“开发器”，而是一套企业应用生产和治理体系。
二、传统低代码平台的核心价值
低代码平台过去的成功，经常被概括为“少写代码、快速开发”。这种表述没有错，但没有触及其最深层的价值。
1. 用抽象压缩重复劳动
传统软件开发需要反复编写数据库访问、表单校验、权限判断、状态流转、接口封装和异常处理代码。低代码平台通过元模型，把这些通用实现压缩为更高层次的声明。
一次建模能够替代大量样板代码，同时让平台统一生成或执行技术实现。这种抽象压缩降低了交付成本，也减少了不同开发者自由发挥带来的差异。
2. 把个人经验变成组织资产
优秀的平台会把行业模型、页面模板、流程模板、集成连接器和公共组件沉淀下来。开发团队不再每个项目从零开始，而是在已有资产上组合和扩展。
因此，低代码平台的复用对象不只是代码片段，还包括业务概念、领域模型、交付规范和经过验证的解决方案。
3. 以约束换取一致性
专有框架和元模型有时会被视为限制，但对大规模企业交付而言，适当约束本身就是价值。统一的数据访问方式、异常处理方式、权限模型和发布流程，可以显著降低项目之间的技术离散度。
低代码平台通过“平台默认正确”的方式，把部分架构决策、安全要求和工程规范前置到建模与生成阶段。
4. 扩大软件建设的参与范围
可视化模型降低了业务人员、实施顾问和初级开发者参与软件建设的门槛。业务专家可以更直接地表达流程和规则，专业开发者则负责复杂扩展和平台能力建设。
这种价值不只是让不懂代码的人写应用，更重要的是缩短业务知识进入软件系统的路径。
5. 对应用全生命周期负责
代码被生成出来，并不等于应用已经交付。一个企业应用还必须经过测试、部署、安全审查、运行监控、故障处理和持续升级。
开发平台通过统一环境、流水线、运行时和治理规则，把单次开发行为变成可重复、可审计的组织交付能力。
由此可以得到一个更本质的结论：
低代码平台最持久的价值，不是让开发者少敲键盘，而是把企业的业务知识、公共能力和工程约束固化为可重复使用的组织能力。
三、AI Coding 带来的结构性挑战
AI Coding 对低代码的影响不是增加了一个新的开发工具，而是改变了软件生产中的稀缺资源。
1. 代码生产不再是最主要的瓶颈
低代码过去用模型代替样板代码，是因为手工编码昂贵、缓慢且容易出错。当 AI 能快速生成表单、接口、数据访问、测试和部署脚本时，“减少代码量”本身不再构成牢固壁垒。
对于通用场景，开发者完全可能让 AI 直接使用成熟框架和开源组件，得到比专有平台更灵活、更透明的实现。
2. 自然语言正在成为新的开发入口
传统低代码降低了编程语言门槛，却引入了新的学习成本：用户需要理解平台概念、控件体系、属性面板和专有 DSL。AI Coding 进一步把入口提升到需求和意图层，用户可以直接描述“我要一个什么应用”。
这并不意味着可视化界面会消失。复杂模型仍然需要图形化检查和人工调整，但可视化设计器不应再是平台唯一的操作入口。
3. 封闭元数据正在由资产变成障碍
大量传统低代码平台把模型保存在数据库、压缩包或私有格式中，只能通过专用设计器读取和修改。这种机制对人类开发者已经不够友好，对 AI 更是如此。
AI 擅长处理文本、代码、结构化 Schema、文档和可调用工具。无法检索、比较、校验和批量修改的黑盒元数据，会阻断 AI 对系统的理解，也难以融入 Git、代码评审、自动测试和现有 DevOps 工具链。
4. 黑盒运行时削弱了软件的可维护性
有些平台只保存模型，在专有运行时中解释执行。应用一旦遇到平台未覆盖的场景，开发者便难以调试、优化或替换底层实现。
在 AI Coding 时代，源码本身变得更容易理解和修改。不能产出透明代码、不能使用标准工具链、不能脱离专有运行时演进的平台，会面临更强的锁定质疑。
5. AI Coding 的工作边界持续扩张
Coding Agent 已经可以围绕一个工程任务完成检索、设计、修改、测试和提交。可以预期，它还会继续向需求澄清、架构分析、质量保障和运行诊断延伸。
因此，开发平台不能把未来战略建立在“AI 只会生成局部代码”这一假设上。平台真正应该回答的问题是：当通用智能体具备越来越完整的工程能力时，平台还能为它提供哪些不可替代的企业上下文、受控能力和确定性保障？
四、AI Coding 仍然没有自动解决企业应用交付
AI Coding 很强，但从“能完成代码任务”到“能稳定交付企业应用”之间，仍然存在明显距离。
首先，通用模型并不了解某家企业对客户、合同、订单、预算和组织权限的具体定义。代码库只能呈现已经实现的部分，无法天然表达全部业务制度、例外规则和决策依据。
其次，AI 生成具有概率性。同样的需求可能得到不同架构和实现。如果缺少平台约束，团队会更快地产生更多风格不一致、依赖复杂且难以治理的代码。
再次，企业应用中的很多难题不是算法和语法问题，而是身份、权限、数据、流程、集成、合规和历史系统问题。这些能力需要稳定接口、运行保障和明确责任，不能依赖每次生成时临时拼装。
最后，企业交付要求可证明。组织必须能够回答：需求由谁提出，AI 使用了哪些上下文，修改了什么，经过哪些测试和审批，为什么允许发布，出现问题如何回滚。单次代码生成的正确性不能替代全过程的证据链。
DORA 2025 关于 AI 辅助软件开发的研究将 AI 描述为组织能力的放大器：它既会放大优秀的工程体系，也会放大原有的流程缺陷。换言之，没有稳定的平台工程、反馈机制和治理能力，代码生成速度的提升未必会转化为更好的交付结果。
五、核心转变：模型不会消失，封闭的建模方式会消失
AI Coding 并没有否定建模。
数据实体、业务状态、权限关系、页面结构和审批流程，本来就是企业应用中真实存在的语义结构。无论使用可视化设计器、自然语言还是编程语言，这些结构都需要被表达、验证和持续维护。
真正需要改变的是模型的存在方式。
1. 从设计器私有数据转向开放语义资产
AI 原生平台中的模型应该具备以下特征：
有明确、稳定且可演进的 Schema； 可以文本化保存并进入版本控制； 可以进行差异比较、合并和代码评审； 可以被 AI 检索、解释、创建、校验和修改； 可以通过 CLI、API 或 MCP 等接口操作； 能够生成确定、可测试、可追溯的软件产物。
模型可以采用 JSON、YAML、领域 DSL 或其他声明式形式，不必全部转换成 Java、TypeScript 等通用编程语言。关键不在于文件后缀，而在于它是不是开放、可理解、可验证、可迁移的工程资产。
2. 从“人操作界面”转向“人和智能体共享控制面”
传统平台默认操作者是人，所以核心能力集中在图形界面。AI 原生平台必须把智能体视为一等用户，为所有关键操作提供结构化、可组合、可审计的接口。
可视化设计器仍然服务于理解、检查和局部调整；CLI、API 和 MCP 服务于自动化与智能体操作。两者应操作同一套语义对象，而不是形成两套相互割裂的资产。
3. 从黑盒执行转向透明产码
平台应当能够依据模型生成前端、后端、测试、接口描述和部署配置等标准软件资产。生成结果需要对 AI 和开发者可读、可测试，并尽可能使用主流工程工具链。
但是，“生成源码”不等于允许任意修改所有生成代码。平台必须明确唯一事实源和修改边界。较稳妥的方式是：
以语义模型为主源，采用确定性代码生成，设置稳定扩展点，保护生成区域，并记录生成版本和修改来源。
如果同时允许模型和源码无约束地双向修改，就会产生难以解决的语义冲突。AI 原生平台需要开放，但开放不等于放弃工程秩序。
六、AI 原生开发平台的参考架构
AI 原生开发平台可以抽象为六个层次：
这些层次共同形成一个闭环：
业务意图进入平台，企业知识帮助 AI 理解需求，元模型约束应用结构，公共组件提供稳定能力，AI Coding 生成和修改代码，质量与治理机制验证结果，运行反馈再进入下一轮演进。
因此，可以用一个乘法公式概括其价值：
AI 原生开发平台 = AI Coding × 企业语义 × 公共能力 × 工程治理 × 闭环反馈
之所以使用乘法而不是加法，是因为任何一项接近于零，整体效果都会显著下降。只有模型而没有 AI，平台效率难以跃迁；只有 AI 而没有企业语义，生成结果容易偏离业务；只有代码而没有治理，交付速度越快，风险扩散也可能越快。
七、从低代码走向 AI 原生的七项改造
1. AI 建模：让智能体操作元模型
数据、页面、逻辑、流程和报表等元模型仍会长期存在，但模型创建、查询、校验、修改和发布都应开放为结构化操作。
AI 可以根据需求生成初始模型，根据规则发现模型缺陷，根据数据库或既有代码反向理解业务结构，也可以配合人类通过可视化界面完成调整。
平台需要为这种协作提供 Schema、约束、示例、错误信息和模型测试，而不是仅仅给 AI 一个模拟鼠标点击设计器的能力。
2. 平台产码：让软件产物透明、标准、可演进
平台应能够从语义模型生成前后端源代码、数据库迁移、测试用例、API 契约、部署描述和说明文档。
生成器需要满足确定性、可重复、可测试和版本兼容要求。相同模型在相同版本下应产生相同结果；平台升级时应能说明生成差异；生成代码应保留来源和模型标识，以便定位问题和增量再生。
产码的目标不是让平台彻底退出，而是使平台资产进入标准软件工程体系，让 AI Coding、IDE、Git、CI/CD 和安全工具都能参与后续工作。
3. 公共能力组件化：从平台内置功能变成可调用能力
审批流、权限、打印、报表、消息和规则引擎等企业级能力相对稳定，应该从“只能在设计器里配置的功能”转化为可被生成代码和智能体使用的公共服务。
这里需要区分不同开放方式：
API 承载跨语言、跨系统的稳定服务契约； SDK 为代码开发提供类型、封装和本地开发体验； MCP 把上下文、工具和提示模板暴露给智能体； Skill 描述何时使用某项能力、如何组合步骤、怎样验证结果； 权限与策略系统决定智能体是否可以调用以及是否需要审批。
按照 MCP 官方规范，Resources、Tools 和 Prompts 分别承担上下文、可执行动作和交互模板的职责。因此，Skill 或 Prompt 不能替代稳定 API。真正执行审批创建、权限授予和生产发布的，必须仍然是确定、可鉴权、可审计的服务接口。
4. 企业知识工程化：让平台真正“懂业务”
AI 原生平台需要把领域知识、行业知识、项目知识和平台知识组织起来。知识不应只是若干上传到向量库的文档，还应包括：
统一术语和业务对象定义； 规则、制度及其适用范围； 数据模型、接口和系统依赖； 历史决策、架构约束和例外说明； 模型资产和公共组件的机器可读说明； 需求、模型、代码、测试与运行指标之间的追踪关系。
这些知识需要版本、权限、时效性和来源管理。AI 给出的结论应尽可能附带依据，过期制度不能与现行规则具有同等优先级。
5. 长程闭环：覆盖软件研发全生命周期
只在代码编辑阶段增加 AI，得到的是 AI 辅助开发工具；只有让 AI 参与需求、设计、开发、测试、发布和运行反馈，才接近 AI 原生开发平台。
例如，在建设一个采购申请应用时，需求智能体首先识别企业采购制度和审批规则；建模智能体生成数据、页面和流程模型；架构智能体选择组织权限、流程和消息组件；Coding Agent 生成扩展代码；测试智能体构造边界场景；发布智能体准备变更证据并提交审批；运行智能体持续分析失败流程和用户反馈。
这里的“自动化”不等于取消人。高风险决策、需求取舍、架构例外和生产发布仍应保留人工门禁。平台的作用是让智能体可以连续工作，同时确保每一步都有输入、输出、证据和责任边界。
6. Agentic 原生：让平台开发的应用能够被智能体使用
传统应用主要面向人类点击页面；未来企业中的大量操作会由智能体发起。因此，AI 原生平台产出的应用应天然具备 Agent-ready 能力：
自动生成清晰、稳定的 API 和工具定义； 自动生成供智能体理解的能力说明、示例和限制； 以业务动作而不是底层 CRUD 作为工具粒度； 支持调用者身份传递、最小权限和数据范围控制； 对关键操作提供确认、审批、幂等、撤销和补偿机制； 完整记录智能体调用、参数、结果和责任主体。
UI 不会消失，但它的角色会发生变化。一部分应用仍需要固定界面；一部分场景可以由对话驱动；还有一部分界面可以由智能体根据任务即时生成。无论采用何种 UI，底层业务能力都不应只存在于页面按钮之后，而应成为有语义、有权限、有审计的可调用动作。
7. 治理原生：把 AI 的不确定性纳入工程控制
传统平台治理主要控制人和应用；AI 原生平台还要控制智能体、模型、提示、工具和自主执行过程。
平台至少需要管理：
智能体可以访问哪些代码、知识、数据和环境； 哪些工具只读，哪些工具可以修改状态； 哪些操作可以自动执行，哪些必须人工批准； AI 生成内容通过哪些静态检查、测试和安全扫描； 使用了哪个模型、提示、上下文和工具版本； 任务成功率、人工干预率、错误类型、成本和延迟； 发生异常时如何停止、回滚和追责。
治理不是 AI 创新的对立面。只有把风险控制变成平台能力，组织才敢于让智能体承担更长、更重要的任务。
八、渐进式改造路线
现有低代码平台没有必要推倒重来，可以分三个阶段演进。
第一阶段：打开黑盒
首先把现有模型、组件和平台操作变得机器可读、机器可操作：
为元模型建立稳定 Schema 和文本化表示； 支持导入、导出、差异比较和版本控制； 为核心操作提供 CLI、API 或 MCP； 补齐公共组件说明、示例和错误处理文档； 建立企业知识、平台资产与代码仓库的检索能力。
这一阶段的目标，是让 AI 能够看懂并操作现有平台。
第二阶段：重构生产方式
在开放资产的基础上，逐步建立透明产码、标准工程和公共能力复用：
输出标准前后端代码和测试资产； 明确模型、生成代码和手写扩展的边界； 将公共能力服务化，并提供 API、SDK 和工具接口； 接入代码评审、自动测试、安全扫描和发布流水线； 建立模型到代码、测试和制品的追踪关系。
这一阶段的目标，是让平台进入主流 AI Coding 和 DevOps 生态。
第三阶段：形成智能体闭环
最后把单点 AI 功能连接成覆盖生命周期的多智能体系统：
建立需求、设计、开发、测试、发布和运维智能体； 为长程任务提供状态、记忆、检查点和人工门禁； 用评测集持续衡量生成质量和任务成功率； 将运行反馈、用户反馈和故障数据回流到需求与模型； 让平台产出的应用自动具备 Agent-ready 接口。
这一阶段的目标，是让平台从“AI 可以使用的开发工具”升级为“由人和智能体共同运行的应用交付系统”。
九、评价平台成效的指标也要改变
传统低代码项目常用开发人数、开发周期和代码量衡量效率；AI Coding 产品则常用代码建议接受率。两类指标都不足以衡量 AI 原生开发平台。
更合理的指标应覆盖结果、质量和治理：
从需求确认到生产发布的交付前置时间； 需求一次通过率和返工比例； 自动生成模型、代码和测试的可维护性； 公共组件与领域资产复用率； 自动测试覆盖率和质量门禁通过率； 变更失败率、回滚率和平均恢复时间； 长程任务成功率与人工介入次数； 安全、权限和合规策略违规次数； 从需求到模型、代码、测试、发布的可追踪完整度； 单个有效业务变更的综合成本。
AI 的价值不能只看“生成了多少”，而要看平台是否以更低风险、更短周期交付了正确的企业应用。
十、AI Coding 与 AI 原生开发平台的核心价值差异
回到文章开头，最简单的概括仍然是：
AI Coding 解决“写代码”的问题，开发平台解决“交付企业应用”的问题。
这句话的价值在于指出了两者不同的责任结果，但不应把 AI Coding 狭义地理解为代码补全。更准确的延伸是：
AI Coding 的中心对象是代码库和工程任务；AI 原生开发平台的中心对象是企业应用及其全生命周期。
两者的核心价值差异可以从以下维度观察：
AI Coding 更像一台越来越强的通用软件生产引擎。它可以快速理解和操作代码，但并不天然拥有某家企业的业务语义，也不天然承担应用长期运行的组织责任。
AI 原生开发平台则是这台引擎的企业级工作环境和控制系统：它为 AI 提供正确的上下文、可复用的业务能力、可执行的工程规则、受控的操作权限以及覆盖全生命周期的反馈闭环。
因此，未来的开发平台不是与 AI Coding 竞争谁更会写代码，而是要回答三个更重要的问题：
如何让 AI 准确理解企业要建设什么； 如何让 AI 优先复用企业已经拥有的能力； 如何证明 AI 建设的应用可以安全、可靠、合规地长期运行。
谁能回答好这三个问题，谁才真正拥有 AI 原生软件开发平台的核心价值。
参考资料
Microsoft：Power Platform Well-Architected Microsoft：Establish effective application lifecycle management practices GitHub Docs：Get started with Copilot agents on GitHub DORA：State of AI-assisted Software Development 2025 Model Context Protocol：Architecture Model Context Protocol：Server primitives overview