AI Coding 会杀死低代码吗？

AI Coding 淘汰的首先是“用拖拉拽替代手写代码”这套旧价值主张。下一代低代码若能成为机器可理解、可验证、可回滚的企业应用底座，它得到的不是一次续命，而是一项更难也更重要的新职责：让生成速度不以失控为代价。

第一部分 · 当代码突然变得很便宜

01为什么“AI 会杀死低代码”听起来如此合理

过去谈低代码，最常见的演示是把一个表格拖到画布上，绑定数据源，再配置一张表单。十几分钟后，一个管理应用已经可以打开、查询和提交。它之所以令人兴奋，是因为我们默认另一条路更慢：找开发人员，搭工程，选框架，写页面和接口，然后等待部署。今天，这个比较的前提变了。

现在，用户可以直接对 AI 说：做一个供应商准入应用，供应商提交资质，采购初审，法务审合同，财务核验账户；高风险供应商增加合规审批，所有操作必须留痕。几分钟之后，页面、接口、数据表和登录入口都可能已经出现。它未必可靠，却足够像一个产品。

Andrej Karpathy 在“Software Is Changing (Again)”的演讲中，把大模型看成一种新的计算形态：人开始用自然语言“编程”，软件的入口也随之改变。^[1] 沿着这个判断继续推演，拖拉拽确实显得绕远。业务人员真正想表达的不是“在第二列放一个下拉框”，而是“高风险供应商需要多一道合规判断”。如果自然语言能够直接承载后者，低代码画布作为主要入口的优势就会迅速缩水。

这不是低代码第一次被更高层抽象挑战。代码生成器、第四代语言、模型驱动开发和云服务都曾试图减少手工实现。AI 的不同之处在于，它不要求用户先学会一种精确语法，就能处理模糊意图、解释反馈并连续修改。这让过去属于低代码的“低门槛”不再独占。

所以我基本同意悲观判断的前半句：如果一个低代码平台最重要的能力仍然是少写代码，它的护城河正在消失。 固定模板未必比动态生成灵活，专有表达式未必比自然语言容易，受限组件也未必比普通代码自由。AI 没有必要先打败整个平台，它只要让平台原来的购买理由不再成立。

02从零到一个能跑的版本，真的便宜了

AI Coding 最明确的改变，是把软件的起点从“提交需求”改成“先做一个出来看看”。产品经理可以自行验证交互，运营可以生成一次性工具，创业者可以在一天内比较多个方向。大量过去进不了研发排期的想法，第一次获得了可运行的表达。

Addy Osmani 把这种体验概括为“70% 问题”：AI 可以很快把人带到一份令人惊讶的初版，剩下那段通往可维护、可用于生产的距离，却需要架构判断、边界处理和持续验证。^[2] 这里的 70% 不是测量所有项目的统计常数，更像一个有用的工程隐喻。前半程之所以显得快，是因为最容易展示；后半程之所以显得慢，是因为大量工作只会在失败、增长和变化中暴露。

一个投诉管理原型可能已经有登录、列表、详情和状态流转。真正上线前，问题会变成另一组：

• 同一客户重复提交时，系统如何识别并合并？
• 客服只能看本产品线，质量负责人可以跨产品线查看，这个限制是在每个页面里分别判断，还是由统一的数据权限执行？
• “24 小时未响应”按自然时间还是工作日历计算，节假日和暂停状态如何处理？
• 通知发送成功、状态更新失败时，下一次重试会不会造成重复升级？
• 一条投诉涉及客户隐私时，导出、搜索、日志和备份分别遵守什么规则？
• 半年后修改流程，正在处理的旧实例继续走旧版本还是迁移到新版本？

这些问题很少出现在第一张演示截图里，却决定企业敢不敢把客户关系和服务责任交给系统。

03最危险的不是原型粗糙，而是原型太像产品

粗糙原型反而容易让人保持警惕。真正危险的是一个界面完整、动画顺滑、还能部署到云端的原型。视觉完成度会替工程完成度背书，人很自然地认为“再修几个问题就能上线”。

然而，企业级能力通常不是在原型末尾依次安装的插件。数据模型是否能表达历史状态，决定了审计和迁移的上限；权限是在服务端统一执行还是散落在前端，决定了越权风险；事务边界如何划分，决定了中途失败后能否恢复；依赖是否可替换，决定了系统扩展时要不要推倒重来。这些选择在第一版里已经发生，只是当时没有人要求它们接受检验。

AI 让代码生产得越快，这种误判越容易扩大。一个 Agent 生成页面，另一个补接口，第三个修改数据库，第四个处理部署配置。每个局部都可能看起来合理，整个系统却没有人真正理解。代码数量增长十倍，并不会让审查、测试和架构理解自动增长十倍。瓶颈只是从“谁来写”移动到了“谁能证明”。

第二部分 · 企业购买的是可控变化

04企业级不是规模形容词，而是责任声明

“企业级”经常被误解成更多功能、更复杂的技术栈，仿佛只要上了微服务、容器和 Kubernetes，系统就自然完成了升级。其实，一个只有三张页面的审批工具，只要承载真实资金、客户数据或合规责任，就可能需要企业级保障。反过来，一个有几十张页面的演示项目，只要没人依赖它持续工作，依然只是原型。

我更愿意把企业级理解成一句责任声明：组织愿意把一段持续运转的业务交给这个系统，并且知道出问题时由谁发现、谁解释、谁恢复。

这份责任至少包含六种确定性：

• 结果的确定性。 相同业务条件得到一致结果，重复请求和并发操作不会悄悄制造不同事实。
• 边界的确定性。 身份、角色、租户和数据权限在所有入口保持一致，不能靠某个页面记得隐藏按钮。
• 运行的确定性。 依赖超时、网络抖动和流量波动出现时，系统能够隔离、降级或恢复。
• 变化的确定性。 模型、流程和接口升级时，影响范围可以分析，历史数据可以迁移，失败可以回退。
• 证据的确定性。 谁在何时依据什么信息做了什么，能够被审计、复盘和解释。
• 所有权的确定性。 业务语义、技术风险和生产发布分别有人负责，AI 不是责任主体。

这些要求与功能多少没有直接关系，却决定了软件能否从一次性产物变成组织资产。

05AI 提高的是产量，工程系统决定它会放大什么

2025 年 DORA 关于 AI 辅助软件开发的研究给了一个比“AI 有用”或“AI 有害”更准确的结论：AI 更像放大器。它会放大组织已有的优势，也会放大薄弱环节；研究同时观察到更高的交付吞吐和仍然承压的交付稳定性。^[3] 这并不能直接证明某个团队使用 AI 后一定更快或更不稳定，但它提醒我们，不应把局部编码速度等同于端到端交付能力。

如果团队已经有清晰边界、快速测试、短反馈环和可靠发布，AI 可以把成熟做法复制得更快。如果需求经常口头变化、权限规则散落、测试长期欠账、发布依赖人工记忆，AI 同样会更快地产生不一致。生成能力本身没有方向，工程系统决定它放大秩序还是放大混乱。

这也是低代码可能重新获得价值的地方。它不必与 AI 比赛谁更会生成代码，而可以提供一组已经存在的工程事实：统一身份如何接入，流程状态怎样持久化，哪些组件可以访问敏感字段，任务怎样计时，数据如何审计，应用如何发布和回滚。AI 不需要每次重新发明这些答案。

06低代码最值钱的东西，藏在画布下面

看一个成熟的表格组件，很容易只看到列、筛选、分页和按钮。可它真正积累的内容通常在界面之下：大数据量下如何分页，字段权限如何作用于查询和导出，并发更新如何发现冲突，国际化怎样影响排序与时区，移动端和无障碍如何保持可用，错误发生后如何重试，关键操作如何留下审计记录。

AI 当然可以现场生成一个表格。现场生成一个外观相似的表格，却不等于现场获得了过去几年中所有故障、修复和取舍。成熟组件的价值不是少写了多少行代码，而是把一段故障史压缩成了可重复使用的默认行为。

同样的积累也存在于工作流、权限、文件、消息、任务和集成组件中。一个审批引擎不只是把节点连起来，它还要处理撤回、转交、加签、重复提交、旧版本实例、处理人离职、时区和工作日历。一个文件服务不只是上传按钮，它还涉及病毒扫描、访问控制、生命周期和留存策略。

这并不意味着“用了成熟组件，应用就一定稳定”。组件可能被错误组合，平台本身也可能有缺陷。真正合理的判断是：复用经过验证的能力，可以减少每个项目从头犯错的范围，但不能取消架构和验收。

07从开发工具变成运行时契约

如果画布不再是核心，低代码还剩下什么？我认为答案是一套既能被人理解、也能被机器处理的应用模型：

• 一个业务对象有哪些字段、唯一性约束、状态和数据生命周期；
• 一个流程有哪些节点、转换、条件、校验和失败补偿；
• 谁可以执行某个动作，又能看到哪些字段和哪些数据行；
• 一个页面组合了哪些语义组件，组件依赖哪些业务能力；
• 应用需要怎样的容量、可用性、审计、恢复和部署区域；
• 变更会影响哪些运行实例，发布前必须通过哪些检查。

当这些内容只存在于画布坐标和私有 JSON 里，它仍然是封闭工具的配置。当它们拥有稳定语义、版本、接口、差异比较和验证规则时，就成为运行时契约。AI 可以生成契约，人可以审查契约，平台可以执行契约，流水线可以验证契约。

Evan Bottcher 在 Martin Fowler 网站讨论数字平台时，把平台定义为一组可自助使用的 API、工具、服务、知识和支持。好的平台不是强制每个团队走同一条路，而是提供一条安全、合规、成本更低的“铺装道路”。^[4] 下一代低代码也应该如此。它不能只是更大的共享服务部门，也不能用“治理”替代使用体验。它必须让采用可信默认值，比绕过平台重新实现更容易。

第三部分 · 自然语言加 CLI，不是魔法输入框

08自然语言应该表达业务意图

拖拉拽适合调整局部布局，不擅长承载完整意图。用户说“做一个供应商准入应用”时，真正需要被理解的是业务对象、角色、流程、例外和责任，而不是控件坐标。

一个有用的 AI 不应立即生成页面。它首先应该把描述整理成一份可讨论的计划：

这一步看似没有“写代码”，却避免了最昂贵的一类错误：AI 用顺畅的交互掩盖了自己替用户做出的假设。自然语言的价值不是让模糊永远保持模糊，而是更快地把模糊变成可以确认的结构。

09CLI 是自然语言与工程交付之间的桥

为什么还需要 CLI？因为一句话可以表达目标，却不适合直接成为生产变更。企业交付需要知道目标环境、当前版本、具体修改、验证结果和回退材料。CLI 把这些动作变成可记录、可复现、可组合的命令，也让 AI 不必操纵像素坐标或猜测内部 JSON。

Spark CLI 的当前设计提供了一个具体例子。它要求先选择认证配置、App、可编辑版本和工作流，再使用“增加节点”“连接流程”“增加校验”这类业务语义命令。高影响写操作需要明确的 --yes，修改后还可以执行配置检查并导出包。页面继续承担可视化检查和人工治理，CLI 则负责自动化、批处理、结构化输出与 AI 调用。^[5]

下面这段是基于真实命令语义整理的说明性案例。它假设应用、工作流、表单和可复用 Step 已经存在；名称用于展示方法，并不声称对应某个生产环境。

# 先证明目标上下文，而不是凭聊天记录猜测
spark auth use spark-dev
spark-designer task app use customer-service
spark-designer task current
spark-designer task workflow use "Complaint Handling"
spark-designer task workflow current
spark-designer task workflow describe --json

# 读取服务端实际注册的规则，再形成变更计划
spark-designer task workflow rule-types

# 人确认计划后，增加重大投诉的质量复核环节
spark-designer task workflow add-node \
  --type status \
  --name "Quality Review" \
  --step "Quality Review" \
  --yes

spark-designer task workflow connect \
  "Product Review" \
  "Quality Review" \
  --name "Escalate Major Complaint" \
  --form qualityReview \
  --yes

# 重新读取结果，执行检查，并留下可恢复材料
spark-designer task workflow describe --lang zh-CN
spark-designer task check workflow-config --yes
spark-designer task package export \
  --output complaint-management-backup.json

这比原稿中虚构一条 platform create 命令更慢一点，也更真实一点。AI 仍然可以把自然语言转成这些操作，但它必须展示目标上下文、实际能力目录和预期差异。用户确认后才写入，写入后重新读取，再交给设计器和运行环境验证。CLI 的意义不只是少敲几次键，而是让一次生成拥有可以追问的证据链。

10从一句需求到可信运行，需要一个闭环

把 AI 与低代码组合起来，一次完整交付大致会经过七个环节：

1. 表达意图。 业务人员描述目标、角色、例外和不能失守的约束。
2. 形成计划。 AI 拆解对象、流程、权限、组件和待确认问题，不立即写生产数据。
3. 证明上下文。 工具读取实际 App、版本、环境和组件目录，避免修改错误目标。
4. 组合能力。 平台优先匹配统一身份、工作流、SLA、审计和通知等成熟组件。
5. 生成差异。 AI 只生成平台尚未覆盖的模型、配置或扩展代码，并明确影响范围。
6. 验证结果。 自动检查主流程、权限矩阵、重复提交、超时升级、异常恢复和性能基线；人验证业务语义与高风险决策。
7. 运行与反馈。 平台提供监控、审计、版本、灰度和回滚，生产证据再进入下一次变更。

这里的第三种形态并不是前两种的机械叠加。真正的变化是生成空间不同。自由 AI Coding 可以选择任意框架、依赖和实现；可信平台要求优先使用批准的组件、统一身份和标准连接器，关键操作必须审计，发布必须经过指定门禁。限制减少了一部分自由，也减少了企业每次重新证明同一类基础问题的成本。

第四部分 · 低代码也必须完成一次自我革命

11“又快又好”不是一句自动成立的口号

AI 与低代码结合，确实可能同时提高速度与质量，但原因需要说清楚。

快，主要来自 AI 对意图的理解，以及对样板配置、文档和差异实现的自动化。质量，主要来自成熟组件和统一运行时，不是因为 AI 突然不犯错。稳定性来自故障边界、监控和恢复机制。可靠性来自约束、测试、审计和发布责任。可维护性来自模型、代码、版本与决策记录共同存在。

这几件事缺一不可。只有自然语言，没有稳定平台，容易得到快速增长的代码堆；只有封闭平台，没有更好的意图入口，用户仍然困在漫长配置中；两者都有，但没有验证与责任，错误只会以更高速度进入生产。

所以更准确的关系不是一句整齐的“AI 提供速度，低代码提供稳定”。AI 也能帮助测试和治理，低代码也可能拖慢交付。真正有效的是分工：让概率性的生成负责提出候选，让确定性的系统负责执行约束，让人对不可外包的判断负责。

12下一代平台至少要改变七件事

低代码不会因为拥有多年组件就自动获胜。很多积累如果仍被锁在浏览器点击、私有格式和人工操作里，AI 无法可靠调用，企业也很难验证。

Forrester 的 Diego Lo Giudice 与 John Bratincevic 把类似方向称为 AppGen：AI 原生、理解业务的全栈平台，用中间模型连接业务意图与可执行系统，并把领域知识和治理放进平台。^[6] 这个名称是否会成为行业共识并不重要，他们关于时间表和“重塑整个开发生命周期”的判断也仍是预测。更值得注意的是，低代码与生成式 AI 的边界正在融合，竞争单位从某个编辑器变成了整条应用交付链。

安全同样不能靠平台口号。NIST 的 Secure Software Development Framework 要求组织把安全需求、来源、设计决策、发布完整性和漏洞响应纳入整个生命周期。^[7] 下一代低代码若想承载企业核心，就要把这类要求变成默认可执行的检查，而不是在采购文档里勾选一次。

13平台越强，越要给边界和退出留位置

并不是所有软件都适合建立在统一低代码平台上。高度创新的交互、极端性能或实时要求、底层基础设施、复杂算法产品，以及平台尚未验证过的监管场景，可能需要更直接的工程控制。即使是常见企业应用，独特业务规则也不应被强行塞进不合适的组件。

平台锁定也会因为 AI 而加深。过去，开发者至少知道自己点过哪些配置；未来，AI 可能持续调用平台专有语义，应用数量快速增加，团队反而更难看见依赖边界。一个负责任的平台应该提供数据导出、开放接口、版本化模型、可观察的运行行为和明确的扩展边界。最好的“铺装道路”有清楚路标，也允许使用者在承担成本后离开，而不是把护栏修成围墙。

还要警惕错误的确定感。稳定组件被错误组合，仍会得到不稳定系统。自动生成的权限矩阵可能完整却误解了组织规则；所有测试都通过，也可能只是测试了 AI 自己写下的假设。平台能降低风险，不能替业务负责人定义“正确”，也不能替技术负责人接受生产后果。

14低代码的终局，不是 No Code，而是 Trusted Build

AI Coding 确实会淘汰一批低代码产品。那些主要依靠模板、拖拉拽和“不会编程也能做应用”生存的平台，很难继续证明学习成本和锁定成本值得付出。自然语言更直接，普通代码更开放，AI 还会继续提高两者之间的转换效率。

但代码变便宜，不等于企业软件的全部成本变便宜。相反，候选实现越多，经过验证的组件、清晰的运行时契约、自动化的治理和可恢复的交付过程越稀缺。企业不需要更多无法说明来源的代码，它需要更低成本的可信变化。

未来有竞争力的低代码，用户未必先看到画布。他可能先说出业务目标，由 AI 形成结构化计划；平台从可信能力目录中组合页面、数据、流程和权限；CLI 与 API 把每次修改变成可追踪动作；测试、策略和人工审批共同决定是否发布；运行证据再反过来帮助下一次生成。

我把这种形态称为 Trusted Build，不是为了再造一个市场名词，而是为了改变验收问题。我们不再只问“它能不能生成”，而要继续问：

• 它是否准确表达了业务意图和未知假设？
• 它是否复用了经过验证的能力，而不是重新发明基础设施？
• 它能否证明权限、数据、性能和失败路径符合要求？
• 它的变更是否可解释、可回退、可交接？
• 当平台不再合适时，组织是否仍然拥有自己的数据和业务知识？

如果这些问题有答案，AI Coding 与低代码就不是一场简单的替代战争。AI 改变应用的入口，低代码提供经过时间筛选的能力，工程体系把两者约束成可以负责的交付过程。

真正值得争夺的，不是“谁让不会编程的人也能做软件”。那道门已经被 AI 推开。下一个更难的问题是：当每个人都能生成软件时，谁能让这些软件值得企业长期托付？