夜雨聆风总有人问我：你在折腾什么？
我的答案不是：
AI
Agent
大模型
低代码。
而是：
企业管理软件到底应该如何开发。
我越来越相信：
过去三十年，中国企业管理软件真正的问题，不是产品做得不好。
而是软件工程的方法错了。
过去三十年，我们一直采用这样的开发模式：
需求↓原型↓表单↓数据库↓流程↓代码↓上线每来一个客户。
增加几个表单。增加几个字段。增加几个流程。增加几张表。
最后：
系统越来越复杂。
代码越来越庞大。
二次开发越来越多。
企业越来越离不开实施顾问。
这不是某一家公司的问题。
这是整个行业共同的软件工程。
而我们想改变的，就是它。
我们过去两个月，一直在做一件事情。
不是开发产品。
而是在回答一个更底层的问题：
企业，到底应该如何被软件描述？
于是
我们重新开始，从第一性原理推导。
不断推翻。不断重建。
最后形成了两份最重要的文档。
第一份文档：EDL（Enterprise Description Language）
中文：企业描述语言。
它回答的是：
企业是什么？
EDL 不描述页面。
不描述数据库。
也不描述流程。
EDL 只描述企业。
例如：
企业里面有哪些对象？
这些对象之间有什么关系？
它们如何变化？
企业有哪些运行规则？
EDL希望把企业第一次变成一种可以计算、可以验证、可以演化的语言。
它不是低代码。
也不是 BPM。
它更像HTML对网页、SQL对数据库一样。
是一种新的企业描述标准。
第二份文档：EEAS
Enterprise Engine Architecture Specification中文：企业引擎架构规范。
如果说：EDL是语言。那么：EEAS 就是软件工程。
EEAS 定义了一件事情：
企业管理软件的架构原则。
例如：
企业模型必须先于页面。
对象必须先于表单。
元数据必须先于数据库。
配置必须优先于开发。
AI 必须是辅助，而不是决策者。
这些原则看起来简单，全部做到：
企业管理软件将会完全不同。
所以，我们真正想做的，不是一套 OA。
而是一套新的软件工程。
以后开发软件。
不是：
页面↓数据库↓
代码而是：
企业↓EDL（企业描述）↓Enterprise Engine（企业引擎）↓Runtime（运行时）↓Application（应用）OA、CRM、ERP、HRM、MES。都只是 Enterprise Engine 上运行的不同应用。
这意味着：
企业的软件第一次拥有了统一的底层模型。
而不是每开发一个系统，就重新设计一次数据库。
为什么我认为这件事值得做？
因为中国有几千万家中小企业。
他们真正需要的，不是越来越复杂的软件。
而是：
一套能够随着企业成长不断演化的软件。
今天：
企业变化。
意味着：
改需求。
改数据库。
改代码。
重新测试！重新上线！
未来：企业变化。意味着：
修改企业模型。重新编译。
自动生成新的系统。
软件开始真正跟着企业成长。
这不是 AI 的能力。
这是软件工程的能力。
AI 只是加速器，不是答案。
很多人会问：
是不是因为 AI，所以你们才提出这些理论？
答案恰恰相反。
AI 只是让我们更快地验证理论。
真正决定软件质量的。
仍然是：
模型—架构—工程。
AI可以帮助我们生成代码。
但不能替我们建立一套能够运行二十年的软件工程体系。
如果未来EDL、EEAS被证明是正确的。
我希望它是一套开放规范。
就像：
HTML。
SQL。
HTTP。
Git。
它们改变的，不是一家公司。
而是整个软件行业。
三十年前。
中国企业管理软件解决的是：
让纸质流程进入电脑。
未来三十年。
我希望我们解决的是：
让企业第一次拥有可以持续演化的数字模型。
这条路最终能够走通吗？
真正值得改变行业的，从来不是某一个产品，而是让整个行业开始使用一套更好的工程方法。EDL 和 EEAS 只是开始，我们更希望未来有越来越多的人参与讨论、质疑、验证，并共同把它打磨成属于整个行业的开放标准。
后记：我想找到中国企业管理软件三十年走不出来的原因
一开始我想重新做一套协同OA系统，最开始的问题其实很简单：
应该基于表单建模，还是基于字段建模？
为什么企业管理软件一定要围绕表单设计？
我以为答案很简单。
结果越讨论越发现不对。
表单只是页面。
页面只是展示。
展示怎么会成为企业的核心？
于是我们继续追问：
那是不是字段才是核心？
听起来很先进。
很多国际平台都在强调字段抽象。
但继续推演又发现：
字段没有业务语义。
字段脱离对象就失去意义。
如果把企业抽象成一个无限膨胀的字段库，最后得到的不是企业模型，而是一个巨大的配置垃圾场。
于是我们开始重新研究 SAP 和 Salesforce。
我们不得不承认，它们非常先进。
先进到什么程度？
先进到很多中国企业根本用不了。
不是企业太差。
而是它们默认企业拥有高质量数据、成熟流程、专业实施团队和长期治理能力。
而中国几千万中小企业最真实的状态是什么？
Excel，微信群，口头流程，数据不完整。
组织经常变化。老板亲自拍板。
如果一套系统只有“优秀企业”才能用，那它就不是中国企业的软件。
讨论到这里，我们突然意识到一个可怕的事实：
过去三十年，整个行业一直在描述软件，而不是描述企业。
表单是在描述软件。
数据库是在描述软件。
流程是在描述软件。
菜单、按钮、权限树，全都在描述软件。
我们从来没有真正描述过企业。
这一刻，很多问题一下子通了。
为什么系统越做越复杂？
因为页面越来越多。
为什么二次开发永远做不完？
因为每个新需求都要重新发明一次软件。
为什么数据永远对不上？
因为每个系统都在维护自己的世界。
真正的企业世界，其实只有三件事：
企业里有什么；
企业发生了什么变化；
企业为什么允许这种变化发生。
于是，我们终于得到了一套完全不同的工程模型。
EDL：Enterprise Description Language（企业描述语言）
它不描述页面。不描述数据库。不描述流程。
它只描述企业本身。
EEAS：Enterprise Engine Architecture Specification（企业引擎架构规范）
它不告诉你怎么画页面。
它只规定：软件必须服从企业模型，而不是企业去迁就软件。
这意味着什么？
意味着企业第一次拥有了自己的“源代码”。
过去：需求 → 表单 → 数据库 → 代码
未来：企业 → 企业模型 → 企业引擎 → 生成软件
注意，我们改变的不是开发效率。
我们改变的是：
企业变化时，软件如何变化。
过去企业变化，需要改代码。
未来企业变化，只需要改模型。
这是两个时代的差别。
说实话，讨论到最后，我自己都有点恍惚。
因为我们原本只是想做一套更好的 OA。
结果最后推导出来的，却是一套新的企业软件工程。
这件事最让我兴奋的地方：
中国企业管理软件过去三十年的很多复杂度，并不是企业天然复杂，而是软件工程制造出来的复杂。
如果这个判断是对的。
那我们接下来要改变的，就不是某一个产品。
而是整个行业的底层方法。
想到这里，我突然有一种很久没有过的感觉。
不是创业的兴奋。
不是赚钱的冲动。
而是一种工程师才会有的快感：
终于看见了问题真正的根因。
我先试试！