从 AI Coding 到应用治理：企业如何管理不断增长的内部应用？

引言

2026 年 10 月下旬，Hacker News 上有人发帖问：你们公司也出现“内部 vibe coding 应用”这股风潮了吗？发帖人引用了 The Pragmatic Engineer 的一篇文章：一家输电线路施工公司里，几位不是开发的员工用 AI 做了施工规划应用，能自动查地籍信息、给线路经过的业主发邮件；另一家工业企业则自己做了内部社交网络。

评论区有人认为，AI 显著降低了内部工具的开发成本；也有人担心，随着应用越来越多，后续维护、功能扩展和人员交接可能成为新的负担。

不同部门各自开发 CRM、工单或审批工具，客户信息重复维护，权限规则不一致，甚至没有明确的维护负责人。这就是应用蔓延（Application Sprawl）在 AI Coding 时代的样子。几天就能做出一个 CRM 或审批工具，但这些应用由不同的人在不同时间创建：CRM 的客户表和工单系统的客户表慢慢对不上，三个应用各自维护一份员工名单，没人说得清哪条审批流程才算数。

当内部应用的开发越来越容易，企业该如何减少重复建设，并让这些应用长期保持可维护性？本文将从共享能力、治理方法和效果评估三个方面展开。

💬 嗨！你正在阅读 NocoBase 博客。NocoBase 是用 AI 持续开发和运行业务系统的开源平台：Agent 写代码、做执行，NocoBase 提供底座和治理能力，人来做决策。→ 欢迎在 GitHub 上了解我们

01｜明确内部应用的共享与独立边界

企业内部的应用往往服务于不同部门，业务规则和操作方式也各不相同。应用治理首先需要明确：哪些基础能力值得统一管理，哪些内容应该由业务部门自行决定？

例如，CRM 和工单系统都需要客户信息，但分别管理销售商机和客户请求。两者可以共享客户主数据，具体的业务模型和处理流程则保留各自的特点。

这一原则同样适用于权限、工作流和基础设施：

维度	建议统一或复用的能力	保持独立的业务部分
数据	主数据来源、数据标准、跨应用访问规范	应用自身的数据模型和业务记录
权限	认证接入规范、权限基础能力	各应用的角色分配、操作权限和数据范围
工作流	流程引擎、状态管理与通知能力	各应用具体的审批和业务流转规则
基础设施	部署规范、升级、备份与恢复	页面交互、部门专属业务逻辑

使用统一的应用底座，并不意味着多个独立应用会自动共享数据库或用户账号。跨应用的数据关联和身份管理，仍需根据实际架构进行设计。

在 NocoBase 3 中，NocoBase Core 以框架和依赖包的形式提供身份认证、权限、工作流、文件管理等基础能力。Coding Agent 可以基于这些能力开发业务页面、接口、数据模型和业务规则，相关代码保存在企业自己的项目仓库中。

这样，业务应用既能复用已有的基础能力，也能通过 Git、测试和代码评审管理后续修改。

划清共享能力与业务部分的边界后，团队就可以复用已有基础设施，同时保留不同业务应用的独立性。

02｜如何逐步治理现有的内部应用？

2.1 第一步：盘点现有应用与维护责任

字段	填什么
应用与用途	大家平时真正叫的名字、访问地址，以及一句业务语言的描述，例如“外勤销售记录拜访和商机”。
归属与维护人	应用消失了会来抱怨的部门，加上能回答问题、批准修改的具体人名；写不出人名就填“无”，当作风险处理。
构建与运行方式	怎么做的（Coding Agent、手写代码、SaaS 配置、带宏的表格）、跑在哪里，部署凭据由谁掌握，能否备份和恢复。
核心数据实体	主要的数据表或对象：客户、订单、员工、工单。在别的应用里也存在的，做标记。
数据来源与依赖	从哪些应用或外部系统读写数据，注明方向：只读、只写，还是双向。
身份与权限	用的是公司 SSO 和共享角色，还是自己的用户表；每个角色能看什么。
工作流与审批	每一条审批或自动化流程、谁审批、触发什么，标出可能与其他应用重复的。
使用与变更情况	大致的活跃人数、最近半年改了几次；已知的脆弱点，例如人工同步数据、只有一个人懂。

第一轮先把全部应用都纳入清单，答案粗略一些也可以；一份覆盖所有应用、细节有限的清单，比只覆盖三分之一却填得很精确的清单更有用。它也是新接入的 Coding Agent 最先能读到的东西。

2.2 第二步：识别值得统一的基础能力

对清单里的应用按三个标准打分：

• 重复程度： 某项能力是否在多个应用中反复实现？
• 关联程度： 是否需要读取或修改同一类数据？
• 变更频率： 某项规则是否经常调整，每次都要同步到多个应用？

对重复程度高、关联紧密且经常变化的能力，可以优先考虑统一管理或复用。例如，员工和部门信息可以建立统一来源，CRM 与工单系统可以引用同一份客户主数据。

这些能力可以通过共享服务、外部数据源或可复用的业务模块实现，具体采用哪种方式，需要结合现有系统架构决定。

对于关联较少、运行稳定的应用，则没有必要为了统一而迁移，避免增加额外的开发和维护成本。

2.3 第三步：为 Coding Agent 建立统一的开发规范

当 Coding Agent 持续参与开发时，企业还需要解决一个问题：新的 Agent 如何了解已有的数据模型、权限规则和可复用能力？

如果缺少这些信息，Agent 可能在开发新功能时重复创建已有的数据结构，或采用与现有系统不一致的实现方式。

企业可以在项目仓库中维护 AGENTS.md，将主数据来源、共享能力、开发规范和变更要求整理成 Agent 能够读取的项目指引。

例如，可以加入以下约定：

开发前先检查已有的数据模型、权限和工作流，优先复用现有能力。

客户、员工、部门等主数据使用指定来源，不重复创建。

遵循现有项目结构和命名规范，不擅自修改底座。

涉及共享数据结构、角色或接口的变更时，先说明影响范围，等待人工审核。

提交前检查权限声明、数据迁移和测试结果。

这些约定需要随项目持续维护。特别是涉及共享规则的修改，Agent 应先提出问题，由负责人确认后再继续开发。

NocoBase 3 如何支持应用的持续开发？

有了开发约定，Coding Agent 还需要能够理解现有项目，并利用其中已经具备的能力。NocoBase 3 从应用底座、开发规范和交付管理三个方面提供支持。

NocoBase Core：提供可复用的应用基础。

Core 提供数据建模、身份权限、工作流和通知等基础能力。业务代码按照统一的项目结构组织，例如数据模型位于 database/，页面位于 client/pages/，接口位于 server/routes/。

Coding Agent 可以查看已有的数据结构和业务代码，在现有应用中开发新功能，减少重复建设。

AGENTS.md、Rules 和 Skills：让开发遵循项目规范。

AGENTS.md 是 Coding Agent 阅读项目规范的入口，.agents/rules/ 保存应用自身的开发约定，.agents/skills/ 则提供与已安装平台能力相匹配的开发技能。

对于团队协作，NocoBase Studio 还可以通过知识库保存业务资料，并通过项目记忆记录已经确认的规则和决策背景。这些信息能够供后续开发任务复用，减少人员或 Coding Agent 更换时的重复沟通。

NocoBase Studio：管理开发、评审与发布。

NocoBase Studio 是面向人与 Agent 协同开发的商业平台。团队可以通过 Studio 分配任务、跟踪开发进度，并结合代码检查、独立评审和预览环境验证修改结果。

开发完成后，负责人依据交付报告和验收标准检查结果，决定是否合并及进入后续发布流程。

通过这些机制，Coding Agent 可以基于已有应用继续开发，团队也能够更清楚地管理开发规范、变更过程和交付结果。

2.4 第四步：从新增需求入手，逐步优化存量应用

新需求出现时，先判断能否复用现有能力。例如财务部门要增加费用审核功能：员工身份、部门关系、审批机制和通知都已经存在，真正要新做的只是一张费用数据表、一条审核流程定义、几个页面和一个面向财务审核人的角色范围。Coding Agent 可以按照已有开发规范，复用 Core 提供的数据、权限与工作流能力，开发费用记录、审核流程和相关页面。员工信息可以根据实际架构关联已有数据来源，财务审核权限则在应用中明确声明。新功能完成后，通过测试和人工验收检查结果，再决定是否发布。

完成新需求的试点后，团队可以根据实际开发和维护情况，逐步评估现有应用的调整需求。对于运行稳定、与其他系统关联较少的应用，可以继续保留，无需为了统一而迁移。

📃客户实践：阳光电源如何在同一套系统中管理多个业务模块？

阳光电源的一支海外团队借助 AI 和 NocoBase 3，用约两个月搭建了覆盖商机、项目、技术方案、报价和订单等业务的系统。团队直接复用 NocoBase 的数据、权限和工作流能力，由 AI 根据业务需求生成具体功能，再由业务人员检查和调整。

原本分散在表格、文件和沟通工具中的业务信息，如今可以在同一套系统中管理。不同模块共享相关数据，也保留了各自的业务规则。随着需求增加，团队还可以在现有系统上继续扩展功能。

03｜如何评估应用治理的实际效果？

建立共享底座和开发规范之后，还需要判断这些措施是否真正降低了开发与维护成本。

企业可以从以下几个方面持续观察：

评估维度	建议记录的指标
重复建设	新应用中重复创建的数据结构和基础功能数量
变更管理	识别变更影响范围所需的时间，以及上线后的意外问题数量
开发交接	新开发者或 Agent 理解项目所需的时间、人工解释次数
日常维护	跨应用手工同步数据的次数和耗时
维护责任	没有明确负责人、缺少备份或恢复机制的应用数量
交付质量	Agent 修改被评审驳回、需要返工或发布后回退的次数

这些指标可以按月或季度记录，并结合应用数量、业务复杂度及实际使用情况进行比较。

应用治理的效果最终体现在日常工作中：新增功能是否减少了重复开发，修改现有系统是否更容易评估影响，以及新的开发者或 Coding Agent 是否能够顺利接手。

结尾

有时，在现有应用中增加一组数据、一个流程或一项功能，就能解决问题。让 Coding Agent 在开发前了解已有系统，优先利用现有能力，并为后续修改和交接留下清晰的依据，才能减少内部应用持续增加带来的维护负担。

如果你想让 Coding Agent 基于已有业务系统持续开发，立即查看 NocoBase 3 官方文档，获取更具体的开发方式和平台能力说明。

相关阅读

• 如何把 AI 用到经营中？从销售、库存到利润分析
• 如何用 AI 和 NocoBase 构建真实业务系统：以汽车租赁管理为例
• 10 个适合企业使用的开源 AI Agent 平台：从自动化到内部应用
• 如何用 AI 构建可投入生产的工单系统？
• 库存管理系统搭建对比：纯 AI 搭建 vs AI 基于 NocoBase 搭建
• 如何用 AI 和 NocoBase 在 2 小时内搭建一套企业 IT 运维系统
• NocoBase vs Baserow：灵活数据库与企业级系统
• 如何用 AI 和 NocoBase 搭建一套可投入生产的 CRM
• 企业 IT 资产管理系统搭建指南：从需求梳理到落地
• 7 款 Smartsheet 替代品：适合项目管理与业务流程的工具
• 5 个适合复杂关系模型的开源 AI 无代码工具
• 什么是 AI 无代码？AI 时代无代码平台的实用指南
• GitHub 上值得关注的 9 个开源 AI 无代码工具