开始记录织信的开发过程：不是为了写一个“拖拽搭页面”的工具，而是想把企业系统里那些长期反复出现的问题，沉淀成一套可以持续生长的底座。

写这个系列之前，我犹豫过很久。

一方面，低代码这个词已经被讲得太多了。拖拽表单、快速生成页面、自动建表、流程审批、数据看板，这些能力听起来都不新鲜。

另一方面，真正做企业系统时，我又一次次发现：很多困难并不是“页面做得够不够快”，而是系统在业务变化之后，还能不能继续被理解、被维护、被扩展。

织信就是在这样的背景下慢慢长出来的。

我想用开发日志的方式，把这个过程记录下来。不是写一组完美的产品介绍，而是尽量真实地写：为什么这么设计，哪些地方曾经想简单了，哪些模块看起来基础但越做越深，以及我为什么认为 AI 时代的低代码平台应该重新被理解。

最开始想解决的问题

最开始接触企业数字化时，我看到最多的不是“没有系统”，而是系统太多、表格太多、流程太散。

客户资料在 Excel 里，审批在聊天群里，合同在网盘里，任务在项目工具里，财务又有另一套系统。每个工具单独看都能用，但真正把业务串起来时，问题就出现了。

数据对不上。

流程不知道走到哪里。

权限说不清楚。

一个字段改名，要同步影响页面、报表、导入模板、接口和审批条件。

业务人员觉得系统不好用，开发人员觉得需求一直变，管理者又觉得数据不可信。最后大家重新回到线下沟通和手工表格。

所以我后来越来越明确：企业不只是缺一个软件，而是缺一种能让业务持续被建模、被执行、被治理的系统能力。

为什么低代码是入口，但不是终点

低代码确实能提升交付效率。

如果只是做一个客户登记表、请假审批、任务列表，用低代码很快就能搭出来。这件事有价值，但还不够。

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

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

请假审批之后，会牵涉组织架构、考勤规则、薪资计算和权限边界。

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

如果平台只解决“怎么把页面拖出来”，后面这些数据关系、流程流转、权限控制、报表统计和系统集成，迟早会重新变成孤岛。

这也是我不太想把织信只定义成一个低代码工具的原因。

我更希望它是一套企业数字化底座。

低代码是入口，因为它让业务系统可以更快被搭起来；但底座才是终点，因为企业真正需要的是系统可以长期运行、不断调整，并且在变化中保持一致。

做平台和做应用的区别

做一个固定应用，很多问题可以写死。

比如 CRM 里有哪些对象、哪些字段、哪些流程、哪些角色，开发时都能提前定义。

但做低代码平台不一样。

用户会自己创建应用，自己建表，自己加字段，自己配置视图、流程、权限和自动化。今天是客户管理，明天可能是采购审批，后天又变成设备巡检或项目管理。

这意味着平台不能只知道“当前这个页面怎么渲染”，还要知道：

这个业务对象是什么；

字段分别表达什么语义；

对象之间有什么关系；

谁可以看哪些数据；

流程在什么条件下流转；

自动化和 AI 可以调用哪些能力。

也就是说，平台要存业务数据，还要存描述业务数据的数据，也就是元数据。

这件事决定了织信很多模块的设计方向：表单不能只是页面，字段不能只是控件，权限不能只是菜单，流程不能只是连线，AI 也不能只是聊天窗口。

AI 让这件事变得更值得重做

现在 AI 编程已经很强，生成页面、接口、脚本都比以前快很多。

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

企业系统需要回答的问题更具体：

客户和合同是什么关系？

谁能看到这条记录？

哪个字段在审批中可以修改？

自动任务失败后怎么追踪？

AI 生成的数据能不能被审计？

如果这些信息都散落在代码、提示词和人的经验里，系统会越来越难治理。

低代码平台的价值，恰好是把业务对象、字段、关系、权限、流程和操作记录结构化地沉淀下来。这样 AI 才有机会在一个明确的业务环境里工作，而不是凭空猜测。

我理解的 AI + 低代码，不是在传统低代码旁边放一个问答框，而是让 AI 能理解平台里的模型、规则和工具，在授权范围内参与建模、配置、分析和执行。

第一阶段我最看重什么

如果从工程角度看，织信第一阶段最重要的不是把功能堆满，而是把底层模型打稳。

我最看重几件事。

第一，业务对象要清楚。应用、数据表、字段、视图、动作之间的关系不能混乱。

第二，字段要有语义。文本、数字、日期、人员、部门、关联记录、附件、状态这些类型，不能只是输入控件，还要支撑查询、统计、权限、流程和 AI 理解。

第三，权限要提前进入模型。企业系统最怕后补权限，因为一旦数据、字段、流程都跑起来了，再补权限会牵一发动全身。

第四，流程和自动化要围绕数据发生。流程不是孤立的审批图，它一定是在推动某个业务对象改变状态。

第五，系统要可追踪。谁改了什么、流程走到哪里、自动化执行是否成功、AI 使用了哪些工具，都应该留下记录。

这些能力看起来没有“拖拽页面”那么直观，但它们决定了平台能不能承载真实企业业务。

为什么要写开发日志

写开发日志，对我来说也是一种强制复盘。

平台型产品很容易越做越复杂，如果不把设计动机写清楚，时间久了连自己都会忘记当初为什么这么取舍。

我希望这个系列尽量保持工程视角：不只写功能是什么，也写为什么要做、边界在哪里、踩过什么坑、后面还要补什么。

这篇就作为开篇。

织信要做的，不是又一个让页面生成更快的工具，而是一套能让企业业务持续建模、持续运行、持续演进的系统底座。