织信并不是一个单纯通过拖拽快速生成页面的低代码工具，而是一套面向企业长期发展的数字化底座。它试图解决数据分散、流程割裂、权限模糊和系统难以持续维护等问题，通过结构化沉淀业务对象、字段语义、数据关系、权限规则、流程自动化与操作记录，让业务能够持续建模、执行、治理和演进。在 AI 时代，这些清晰的模型与规则也将成为 AI 理解业务、参与配置、分析数据和执行任务的基础。

上一篇写到一个判断：

企业不缺软件，缺的是会成长的系统。

这句话其实也是我做织信时最核心的出发点。

如果只是做一个低代码工具，事情会简单很多。把表单拖出来，把页面配出来，把数据保存下来，再加一些流程和报表，看起来就已经是一个完整产品。

但真正接触企业数字化以后，我越来越觉得，低代码只是入口，不是终点。

企业真正需要的，不是一个“可以快速搭页面”的工具，而是一套可以持续承载业务变化的数字化底座。

为什么不是只做工具

工具解决的是局部效率。

比如做一个客户登记表，做一个请假审批，做一个项目任务表。如果只是这些场景，低代码确实能很快交付。

但企业业务不会停在一个表单里。

客户登记之后，会有跟进记录、合同、订单、回款、售后。

请假审批之后，会牵涉考勤、薪资、组织架构和权限。

项目任务之后，会牵涉成员、工时、成本、进度和风险。

如果平台只解决“页面怎么搭”，后面这些关系、流程、权限、报表和集成都会重新变成一个个孤岛。

这也是很多系统一开始很好用，后来越来越难维护的原因。

不是页面不够多，而是底座不够稳。

企业系统的难点在变化

企业软件最难的地方，不是第一版怎么做出来，而是业务变化以后还能不能继续演进。

今天客户分为 A、B、C 三类，明天可能要增加战略客户。

今天合同只需要部门负责人审批，明天大额合同还要财务和法务参与。

今天销售只能看自己的客户，明天主管要看本部门客户，区域负责人还要看跨部门数据。

这些变化单独看都不大，但它们会同时影响表单、数据、流程、权限、报表和接口。

如果每次变化都要重新改代码、重新测试、重新上线，企业系统就会慢慢变成负担。

所以我更希望织信解决的是：当业务变化时，系统能不能以较低成本跟着变化。

数字化底座应该有哪些能力

我理解的数字化底座，至少要有几层能力。

第一层是业务建模。

系统要能描述客户、合同、订单、项目、任务、设备、审批单这些业务对象，也要能描述它们之间的关系。

第二层是表单和视图。

用户需要用表单录入数据，用表格、看板、日历、详情页等不同视角处理数据。

第三层是流程和自动化。

业务不只是保存数据，还要推动事情往前走。审批、通知、状态流转、定时任务、自动计算，都应该成为平台能力。

第四层是权限。

企业系统必须回答谁能看、谁能改、谁能审批、谁能导出。权限不是附属功能，而是企业数据能否进入系统的前提。

第五层是集成。

企业不可能只有一个系统。低代码平台要能和外部数据库、第三方系统、脚本、API 连接起来。

第六层是 AI。

AI 不应该只是一个问答窗口。它应该理解平台里的业务对象、字段、流程、权限和工具，在授权范围内参与建表、分析、生成页面、推动流程。

这些能力组合在一起，才更接近“底座”。

低代码和 AI 的关系

现在 AI 编程很强，很多页面、接口和脚本都可以快速生成。

但企业系统不是一堆代码片段的集合。

它还需要稳定的数据模型、清晰的权限边界、可追踪的流程记录、可解释的业务规则和长期维护能力。

低代码平台能给 AI 提供一个结构化的业务环境。

数据表告诉 AI 有哪些业务对象。

字段告诉 AI 每个对象有哪些属性。

关联关系告诉 AI 对象之间怎么连接。

权限告诉 AI 当前用户能看什么、能做什么。

流程告诉 AI 一件事应该怎么推进。

API 和脚本告诉 AI 可以调用哪些工具。

如果没有这些结构，AI 生成得越快，系统可能越难治理。

所以我认为 AI 和低代码不是互相替代，而是互相补足。

低代码提供业务结构，AI 提升配置、开发和分析效率。

织信要做成什么样

织信不是想把所有企业软件都重新做一遍。

它更像是一个让企业自己搭建、扩展和运行系统的平台。

一个企业可以在上面搭 CRM、进销存、项目管理、生产管理、审批系统和数据看板。

开发者可以在上面配置数据模型、表单、流程、权限和插件。

业务人员可以在平台上不断调整字段、视图、流程和统计口径。

AI 可以在权限范围内辅助建模、生成页面、分析数据和处理任务。

这样，企业系统就不是一个项目交付完就结束的东西，而是可以持续生长的业务平台。

为什么我要写开发日志

写这个系列，不是为了写一组产品介绍。

我更想把织信从想法到实现的过程记录下来。

哪些模块先做。

哪些设计后来发现不对。

哪些能力看起来简单，真正做起来很复杂。

哪些地方为了第一版上线做了取舍。

哪些地方必须一开始就打好基础。

这些内容对我自己是复盘，对读者也许能提供一些真实的工程参考。

这篇文章想先把方向说清楚：织信不是为了把页面生成得更快一点，而是为了让企业系统在长期变化里仍然能被理解、被维护、被扩展。

页面可以很快搭出来，但真正决定系统生命力的，是底层模型是否清楚，权限是否进入结构，流程是否围绕数据发生，自动化和 AI 是否在可追踪、可治理的边界内工作。

这也是我做织信时反复提醒自己的地方：不要被“搭得快”这件事带偏。快很重要，但企业系统最终比拼的不是第一天有多快，而是三个月、半年、一年以后，业务继续变化时，系统还能不能稳稳地跟上。