本文作者：得帆信息联合创始人兼CTO徐翔轩
今天我想和大家讨论一个非常基础、但又被普遍忽视的问题：企业的系统，究竟是怎么被构建出来的？
很多人可能会下意识地回答：找IT、提需求、开发、测试、上线，然后就完成了。
随着过去几年接触大量客户、项目和组织，我越来越感受到，传统的"构建路径"正在悄然发生变化。
构建方式正在改变，平台边界随之延伸
你可能已经注意到：越来越多的系统不是做给外部客户和合作伙伴使用，而是用于内部运营、管理、自服务，比如用于一场活动、一次数据采集、一个指标填报等。这些系统需求并不复杂，但变化频繁、生命周期短。提出这些需求的人，也不再是产品经理或技术人员，而是一线的业务团队、业务骨干。
这背后反映的是：系统不再是"被IT开发出来"，而是在平台上被组织构建出来。"谁来构建"、"构建依靠什么"、"构建能走多远"，这些基础逻辑，正在发生深刻变化。
平台结构与组织需求的"双向推动"
在得帆，我们花了两年多时间研究这个变化。我们发现，影响系统构建方式演进的，不是某一个技术本身，而是平台结构与组织需求的"双向推动"。一方面，企业内部的数据、服务、接口、规则等"原子能力"越来越丰富；另一方面，知识工作者的工具素养和表达意愿也在快速提升；而平台本身，也具备了更强的语言理解、规则感知、交互引导能力。
这就带来了新的可能性：构建系统，不一定要"从零开发"，而可以"基于已有能力+业务语言+平台支持"去组合、配置、交付。它不是"生成式"，更不是"替代开发"，而是组织内部构建能力的重塑和延伸。
企业级AI Coding平台
因此，这将推动平台走向新的形态------企业级AI Coding平台。
"AI Coding"不是某种技术标签，而是构建理念的变化：
- 开发的主角不仅是程序员，也包括能清晰表达业务逻辑的人；
- 系统的组成不只是字段和流程，还有权限规则、接口编排、治理逻辑；
- 平台要能支持语言驱动、能力调度、规则托管，并保证上线即用、运行可靠。
"AI Coding"不是更高效的工具，而是更强大、更开放、更可控的基础设施。
五种关键变化，重新定义"系统构建"
那么有哪些因素在推动系统的构建方式变化呢？这里可以提炼五个关键词：
01 Composable（能力组装）
企业的系统能力正在"去应用化"，过去一个系统是独立运行的，现在越来越多的能力是可复用的。平台的角色也随之发生转变，不再是提供完整功能模块的"搭建器"，而是一个具备调度能力、组合能力、管理能力的"编排中枢"。
"构建系统，就像搭积木，不是从0开发，而是基于已有能力快速拼装。"
02 Disposable（一次性系统）
很多系统需求的生命周期正在缩短，比如临时报表、活动报名等，可能只运行一两周就结束。传统系统要立项、评审、开发上线，早就错过了窗口。
系统开始"即需即建、用完即弃"，构建模式必须随之改变。平台必须支持"轻量、临时、快速响应"的构建方式，允许业务团队自己动手，交付一个"够用、好用、不折腾"的临时系统。
03 Self-Evolution（系统自进化）
构建不是一次性事件，而是一个"持续适配"的过程。
今天的业务经常会问这样的问题：
- 哪个字段没人填？能不能自动隐藏？
- 有没有冗余流程？能不能简化一下？
- 审批人是不是都点默认？那是不是规则可以调整？
系统必须具备自感知、自反馈、自优化的能力，构建平台也要跟上"运行中持续调整"的能力诉求。
04 Citizen Development（人人构建）
系统不再只是开发团队的专属工具。我们看到越来越多的HR、运营、财务、市场等业务岗位，开始用平台做系统，这些系统不一定很复杂，但足以支撑自己团队的效率场景。
因此，平台必须提供"可理解的语言、可引导的操作、可审计的规则"，同时确保构建出来的内容在权限、数据、合规等维度是受控的。
构建权力的下放，必须以治理能力的上收作为基础。
05 Centralized Governance（内建治理）
这是构建平台最被低估、但最核心的能力之一。
当构建者从专业开发者，拓展到业务团队、运营人员，甚至是AI Agent时，系统治理就必须"内建"。
权限谁设的？流程谁改了？数据去向哪儿了？字段有没有违规？模型调用是否合规？
这些治理问题不能事后靠人工审计，而要在构建阶段就嵌入规则，做到"治理即交付"。
此外，当系统运行时，可以根据具体的业务运转情况，自动调整和适配相应规则，以及资源的预警和动态调整，逐步靠近Agentic的目标。
总结一下：
构建方式正在变化，平台能力边界也在扩大，从"从零开发"，变成"基于能力组合、业务表达和平台支持"的高频协作。
这不仅是效率问题，更是范式的变化。
企业级AI Coding平台，是什么样的？
现在，我想分享得帆在思考和规划中的方向判断：我们认为，低代码平台在AI时代的演进方向，是走向一个新的平台形态------我们称之为"企业级AI Coding平台"。
这不是对某个产品形态的命名，而是我们对下一代构建平台能力结构的系统性思考。
为什么要走向这个方向？
传统低代码平台主要聚焦在"开发提效"，即如何更快做出表单、流程、数据模型、可视化视图等。这对专业开发者当然有用，但对组织整体的数字化能力释放、提升而言，并不足够。AI的演进，不只是让构建更快，而是让构建的"入口"、"过程"和"治理方式"发生了变化：
- 构建的入口：从开发者动手，变成业务表达意图；
- 构建的过程：从组件拼装，变成能力组合与逻辑协同；
- 构建的治理：从事后审计，变成平台内建规则守护。
平台需要走向一种新的能力结构，既能承载业务语言，又能调度企业能力，还能守住数据与合规的底线。
平台能力结构的三个核心方面
我们当前对平台能力结构的理解，包含三个方面：
01 语言驱动的构建体验
构建发起者不再只是开发者，也可以是一线业务人员、业务骨干、业务负责人、运营团队，甚至AI Agent。
例如，他们会说："我要一个内部打分系统，自动汇总结果，自动屏蔽提交人信息。"
平台要能理解意图、拆解结构、推荐规则、完成配置。
这不是"自动生成"，而是"语言协同构建"的全新路径。
02 基于企业能力的组件调度与组合
构建不能从零开始。企业已经沉淀了大量数据模型、流程模板、接口服务、规则脚本等"原子能力"。平台要能将这些能力抽象化、组件化、服务化，在构建过程中调度使用。
这不只是数据复用，更是组织构建经验的复用。
03 构建与治理的联动机制
我们特别强调：平台不仅要支持"能构"，更要确保"能管"。权限边界、敏感字段、接口调用、模型合规、流程闭环......这些都应内嵌在构建过程中，做到"构建即治理"。
总结来说：
企业级AI Coding平台，不是一个产品标签，而是一种新的构建逻辑。