ARTICLE · 1024180
AI 会写软件之后,谁来负责软件本身?
从 AI Builder 到 AI 共同维护的 Business Runtime，企业软件正在进入下一阶段
适合阅读：CTO / CIO / 企业数字化负责人 / 企业软件负责人 / 架构师
一、AI 已经把软件怎么做，变得越来越容易
过去,一个企业要开发 CRM、ERP、项目管理系统,通常需要一整个团队:产品经理、架构师、前端、后端、测试、运维,忙上几个月。
而现在,自然语言 + AI + 代码生成 + 低代码 + Agent,已经可以相当快地产生一个能跑的软件。
软件第一次做出来的成本,正在快速下降，软件的构建能力,正在快速普及。会做出一个系统,正在变成一件门槛越来越低的事。
但正因为如此,一个更重要的问题浮出来了:AI会写软件以后，谁来负责软件本身？
二、第一个版本做出来，不代表软件真正完成了
今天,你用 AI 很快做了一个销售 CRM,十分钟就生成了客户、商机、联系人、销售管道、仪表盘,看起来很漂亮。然后——
第二个月：销售流程变了。 第三个月：组织架构调整了。 第四个月：新增了渠道业务。 第五个月：客户分级规则改了。 第六个月：老板要一个新的经营指标。 第七个月：Agent 要接进来。 第八个月：权限体系又变了。 |
那么问题来了:这八个月里不断变化的软件,谁来维护?
传统的方式,是把这些变化,一次次交给开发团队。于是出现了一个很讽刺的局面:AI 可以很快地生成软件,但企业仍然会慢慢陷入维护软件越来越难的泥潭。第一次做出来省下的时间,后面在一次次修改里,又还回去了、甚至还得多搭进去。
所以,真正的 AI-Native,不应该只降低 Construction Cost(构建成本),还应该降低 Software Evolution Cost(软件演进成本)。
三、软件，真正进入了持续演进的时代
传统的软件生命周期,是一条直线,做完就基本定型了:
传统： Requirement（需求）→ Development（开发） → Testing（测试）→ Release（发布）→ Maintenance（维护） |
而 AI-Native 的软件生命周期,是一个不断转起来的循环:
AI-Native： Business Intent（业务意图）→ AI Build（AI 构建） → Review（审查）→ Run（运行）→ Observe（观察） → AI Proposes Change（AI 提出修改）→ Review（审查） → Update（更新）→ Run Again（再次运行） |
过去,软件维护主要由开发者负责;以后,AI 可以参与软件维护,但分工是明确的:
人类负责 | AI 负责 |
Intent（意图） | Understand（理解） |
Policy（策略） | Generate（生成） |
Boundary（边界） | Modify（修改） |
Approval（审批） | Execute（执行） |
Governance（治理） | Verify（校验） |
当然不是说 AI 替代软件工程师， 而是软件工程的维护方式，开始发生变化。
四、AI 要维护软件，首先必须理解软件
如果 AI 面对的,是一大堆分散的实现——数据库 Schema、ORM、REST API、React、工作流代码、权限代码、报表代码——那么它要维护这套软件,就得先啃懂这一大片散落的技术细节,既慢又容易出错。
但如果系统本身有一套清晰的业务描述:业务对象(Business Object)、字段、关系、视图、动作、工作流、权限——那么 AI 面对的,就是一个 Business Model(业务模型)。这时候,AI 才能真正理解这些事:
· 企业里的客户到底是什么 · 销售机会和客户是什么关系 · 什么情况下需要审批 · 哪个角色可以修改 · 某个 Action 会产生什么结果 |
这就是 Business Context(业务上下文)，而这也呼应了一个正在发生的趋势:AI 真正的壁垒,越来越来自企业特有的业务上下文、核心记录系统(System of Record)、业务规则和 Metadata,而不是简单地调用一个基础模型。模型是通用的,而这些,是你企业独有的。
所以,AI 要维护软件,首先必须有一套AI 能读懂的软件描述语言。这套语言,就是 Metadata / Business Ontology。
五、ObjectStack，把业务定义变成软件的一等公民
过去,代码是系统的核心。而现在,业务定义,可以成为系统的核心。举个例子,在这套体系里,Customer 不再只是一张 database table,而是一整个 Business Object:
Customer（客户） ├── Fields（字段） ├── Relations（关系） ├── Views（视图） ├── Actions（动作） ├── Permissions（权限） └── Workflow（流程） |
然后,ObjectStack Runtime 围绕这份定义,提供数据、API、UI、MCP、权限、工作流等运行能力( Object、Field、Relation、View、Action、Workflow、Permission、ObjectQL、Runtime、MCP )。
AI 不需要每次都从底层的技术实现,去反推企业的业务是什么。它可以直接从 Business Model 开始理解、开始修改。业务定义成了系统的中心,AI 面对的,就是一个它读得懂的世界。
六、AI 拥有了修改软件的可能
企业说了一句话:给客户增加一个『年度采购潜力』字段。
传统的路径,是一条长链:产品经理 → 开发 → 数据库 → API → 前端 → 测试 → 发布。
而在 ObjectOS 的方向里(以下结合 ObjectOS 官方文档,以官方最新资料为准),它是这样一条链:
Business Intent（业务意图） ↓ AI Builder ↓ Metadata Change（业务定义变更） ↓ Validation（校验） ↓ Review（审查） ↓ Runtime Update（运行时更新） |
根据 ObjectOS 当前官方文档,AI Builder 相关能力涉及创建 / 修改 Package、Object、Field、View、Action、Flow,以及 Human-in-the-loop 审批、Diff(变更对比)、Live Preview(实时预览)、Rollback(回滚)、Audit(审计)等。
AI 不只是帮你写新增功能的代码， 它开始直接操作业务定义。
这,就是 AI 真正进入软件生命周期的关键一步——它改的不是散落各处的实现,而是那份集中、清晰、可校验的业务定义。
七、AI Builder 真正重要的，不是生成，而是持续修改
我们简单看一下：
它是什么 | |
一次性 AI App 生成 | Prompt → App（说一句，生成一个应用，就结束了） |
持续 AI 软件演进 | Business → App → Change → Review → App → Change → …（不断循环） |
真正成熟的 AI-Native 软件,不是一次生成一个 App就完事,而是让这个 App,从第一天起,就具备持续被 AI 修改和演进的能力。生成只是起点,能不能一直改下去、一直跟着业务长,才是关键。
根据 ObjectOS 当前官方文档,它把模板(Template)和 AI Builder 串联了起来,形成这样一条路径(以官方最新文档为准):
Template（模板，如 Helpdesk / CRM / Procurement 等公开模板） ↓ Fork（复制一份） ↓ AI Extend（用 AI 扩展） ↓ Review（审查） ↓ Run（运行） |
八、 Build AI 和 Run AI 闭环
过去我们习惯把AI 构建软件和AI 在软件里干活当成两件事。但如果构建时的 AI(Build-time AI)和运行时的 Agent(Runtime Agents),共用同一套 Agent / Skill / Tool 架构,那么一件很有意思的事情就发生了——它们能连成一个闭环:
AI Build（AI 构建） ↓ Business Metadata（业务定义） ↓ Running App（运行的应用） ↓ AI Agent（运行时的 Agent） ↓ Business Action（执行业务动作） ↓ Business Feedback（业务反馈） ↓ AI Proposes Change（AI 提出修改建议） ↓ Human Approval（人工确认） ↓ Business Metadata Update（业务定义更新） |
Build → Run → Learn → Change → Rebuild： 软件开始转起来了。
它不是AI 帮企业开发一次软件,而是AI 开始参与企业软件的整个生命周期——构建它、运行它、从运行中学习、提出修改、经人确认后更新,然后再运行。软件不再是「做完就定型」,而是一个转起来的、持续演进的系统。
九、MCP 的意义，是让 AI 真正进入 Runtime
过去,API 是给程序员调用的。而现在,业务对象和业务动作,可以成为 Agent 的工具。比如围绕客户这个对象:
Customer（客户） → Get Customer（读取客户） → Update Customer（更新客户） → Create Opportunity（创建商机） → Trigger Approval（触发审批） |
AI 可以通过 Business Runtime,调用这些业务能力( MCP Server、Object / Action 暴露、类型化工具,以及 Permission / RLS / Audit,)。
MCP 真正的意义,不是「多了一个接口」,而是——企业的业务能力,开始拥有一种 AI 可以标准地理解和调用的方式,而且每一次调用,都受权限、行级安全和审计的约束。这也是 MCP 这类标准协议,正在推动 AI Agent 与企业系统更规范协同的原因。
十、AI 共同维护，不等于AI 想怎么改就怎么改
最容易让企业心里一紧的是：AI 会不会把我的系统改坏?
真正的企业级 AI,不是 AI Autonomous(AI 自治),而是 AI Governed(AI 被治理)。
AI 可以提出修改、生成变更、执行任务。但企业,可以通过一整套机制,牢牢地控制它:
Typed（类型化） · Validation（校验） · Diff（变更对比） Review（审查） · Permission（权限） · RLS（行级安全） Audit（审计） · Human Approval（人工确认） · Rollback（回滚） |
企业真正需要的，不是一个什么都能做的 A， 而是一个知道什么能做、什么不能做，且所有改动都可追踪的 AI。
十一、 ObjectOS 和普通 AI Builder 的区别
今天,做一个自然语言 → CRM,正变得越来越容易。AI 公司、SaaS 公司、低代码公司、软件公司、系统集成商,未来都可能提供这种能力。所以——
AI Builder 本身,不是最终的壁垒。
真正该关注的,是它背后这一串问题:AI 操作的是什么?修改的是什么?改完之后由谁运行?权限在哪?审计在哪?数据在哪?企业的 Business Model 有没有沉淀下来?AI 能不能进入 Runtime?能不能持续地修改软件?
把两者摆在一起,区别就清楚了:
它的路径 | |
普通 AI Builder | Prompt → Generate → Finish（生成完，就结束了） |
ObjectOS | Business Intent → Business Model → Build → Govern → Run → Agent → Evolve（持续演进） |
一个止于生成,一个贯穿构建、治理、运行、演进的全过程。这,才是真正的产品差异。
十二、ObjectUI
ObjectUI，它的重点,不是我们 UI 组件很多,而是一件更本质的事:
AI 要能修改软件，UI 也必须变得 AI-friendly。
道理很简单:如果 AI 只能改后台的业务逻辑,却读不懂、也改不动界面,那它其实还没有真正进入完整的软件系统。所以 UI 也要从代码走向Schema:
传统：UI = React Code（界面是一堆 React 代码） AI-Native：UI = Schema（界面是一份结构化定义） ↓ Renderer（渲染器） ↓ Production UI（生产级界面） |
(根据 ObjectUI 当前 README / ROADMAP,涉及 schema-driven UI、renderer、views、components 及相关 AI 能力,以当前仓库为准。)
业务定义(Business Metadata)+ Schema 驱动的 UI(Schema-driven UI)+ 运行时(Runtime),共同构成了AI 可以持续修改软件的基础。后端能改、界面也能改,AI 才算真正进入了完整的软件系统。
十三、未来的软件，可能不再是做完以后交付
过去,一个软件项目,是做完 → 上线 → 维护。而未来,它可能越来越像一个持续运转的 Business Runtime:不断地 Build → Run → Change → Review → Evolve。
软件，可能不再是一个完成品，而越来越像一个不断演进的业务系统。
这也是为什么,几样东西可能会逐渐融合:订阅制 SaaS、AI Agent、Metadata、Runtime、Governance——它们正在从各自独立的东西,走向一个整体。软件不再是一次性交付的项目,而是一个企业和 AI 共同持续经营的系统。
十四、这对企业，意味着什么？
价值一 软件从固定产品，变成持续演进的系统。
它不再是三年前做好、之后越来越难改的东西,而是能一直跟着业务长。
价值二 业务变化，不一定意味着重新开发整套系统。
大多数变化,落在调整业务定义上,而不是又立一个开发项目。
价值三 企业可以让 AI 参与软件建设，而不只是把 AI 当聊天工具。
AI 从一个旁边的问答框,变成软件生命周期里的一个参与者。
价值四 企业可以把 Business Model 沉淀为长期资产。
业务对象、规则、流程、权限,成为企业自己能看、能管、能带走的资产。
价值五 AI 模型可以变化，但 Business Model 和 Runtime 不该被模型绑死。
模型换了,你的业务系统还在,不用推倒重来。
价值六 企业可以在 AI 自动化和治理之间，取得平衡。
既享受 AI 带来的效率,又始终握着权限、审批和审计这道安全阀。
十五、为什么现在，是这个方向的时间窗口？
如果下面这几个趋势,正在同时发生——
AI Build（AI 构建） + AI Agent + Business Context（业务上下文） + MCP + Metadata + Governance（治理） |
那么,企业就会需要一套能够承载这些能力的 Business Runtime。而这,正是 ObjectStack 和 ObjectOS 想站的位置。两者的分工是这样的:
是什么 | |
ObjectStack | 开放的技术基础 |
ObjectOS | 企业可以直接使用的商业化 AI-Native Business Operating System |
既不是ObjectOS = ObjectStack 商业版,也不是ObjectStack 是 ObjectOS 免费版。一个是开放的技术基础,一个是面向企业、可以直接使用的商业产品。
十六、给企业一个新的软件采购判断标准
这一节,可以作为文章的商业结论。未来选择 AI 企业软件,不能只问一句你有没有 AI?,还应该问这 7 个问题:
该问的问题 | |
1 | AI 能不能理解我的 Business Model？ |
2 | AI 能不能进入我的核心业务系统？ |
3 | AI 能不能执行真实的业务 Action？ |
4 | AI 是否受企业权限和治理约束？ |
5 | AI 能不能参与构建和修改软件？ |
6 | 业务变化之后，系统能不能继续演进？ |
7 | 如果未来换 AI 模型，企业是否仍然拥有自己的 Business Model？ |
如果一个产品给你的答案,只是我们有一个 AI Chat,那它还停留在AI 功能的层面。只有当 AI 能进入 Business Runtime、并持续参与软件生命周期时,它才开始接近真正的 AI-Native Business System。
结语：AI 能不能，让你的业务系统更有生命力
大家一开始都在问:AI 下一代模型会多强?但企业最终真正关心的,可能是另一个问题——
AI，能不能让我的业务系统，变得更有生命力？
我们可以把这条演进,简单收束一下:
过去：软件由人开发→ 人维护 现在：人开发 + AI 辅助 未来：人定义目标和边界 + AI 参与构建、运行和演进 + Business Runtime 负责承载与治理 |
最终,可能形成一种新的软件形态——AI-Maintained Business System(AI 共同维护的业务系统)。人依然掌握目标、边界和治理,而 AI,成为软件生命周期里的一个持续参与者。
ObjectOS 想做的,不只是让 AI 帮企业做出一个软件,更重要的是——让 AI 从第一天起,就进入软件的生命周期:从 Build,到 Run,到 Change,再到 Evolution。让软件不再只是被开发出来,而是能随着企业业务,一起持续成长。而 ObjectStack,是这一切背后开放的技术基础。
未来的软件,可能不再是做完交付的软件,而是和企业一起持续演进的软件。
如果你正在为企业选择下一套核心系统——也许值得把问题,从它有没有 AI,换成AI 能不能真正进入并持续参与我的软件生命周期。这个问题的答案,决定了 AI 在你企业里,是一个短期的功能,还是一份长期的能力。
ObjectStack（开放技术基础） · ObjectOS（AI-Native 企业业务操作系统）