上一篇写数据模型，最后留了一个问题：
数据模型定义了业务对象，但这些对象在企业组织里，谁能看、谁能改、谁能审批、谁能导出，这些事情最终都要交给权限体系。
权限这个模块，我一开始其实是低估过的。
刚开始做企业软件时，很容易觉得权限无非就是角色、菜单、按钮。管理员能看全部，普通员工只能看自己的，部门主管能看本部门，好像就差不多了。
真正做低代码平台以后才发现，这个理解太轻了。
在一个固定业务系统里，权限复杂但边界还算明确。因为系统的对象、字段、流程、页面都是开发时确定的。
但在低代码平台里，用户可以自己建表、加字段、配流程、改页面、做自动化。业务对象是动态的，组织结构是动态的，流程节点也是动态的。
这时候权限就不只是“谁能打开哪个菜单”，而是平台必须回答的一个底层问题：
当业务模型不断变化时，系统还能不能稳定、准确地判断一个人对一条数据、一个字段、一个动作到底有没有权限？
权限最难的地方不是菜单
菜单权限是最容易理解的。
比如销售可以进入 CRM，财务可以进入回款模块，管理员可以进入配置中心。
这类权限通常很好做，因为它控制的是入口。
但企业系统真正麻烦的地方，不在入口，而在数据。
同样是客户模块，不同人看到的数据可能完全不同。
销售只能看自己负责的客户。
销售主管可以看本部门客户。
区域负责人可以看某几个区域的数据。
老板希望看全部。
还有一些特殊情况，比如一个客户被多个销售协作，或者一个项目临时授权给外部顾问查看。
这时候问题就来了：
大家打开的是同一个客户模块，但每个人看到的客户列表都不一样。
这已经不是菜单权限能解决的事情。
它进入了数据权限。
一条数据不只有“能看”和“不能看”
数据权限也不是简单的能看、不能看。
真实业务里，一条记录往往有很多层操作。
能不能看列表？
能不能看详情？
能不能编辑？
能不能删除？
能不能导出？
能不能发起审批？
能不能把这条数据转交给别人？
能不能修改某几个敏感字段？
比如客户数据，普通销售可以编辑客户名称、电话、来源，但不能修改客户负责人。
主管可以修改负责人，但不能删除客户。
财务可以查看合同金额和回款情况，但不一定能看到客户跟进记录。
管理员什么都能做，但他的操作要留下审计记录。
这就说明，权限不能只停留在“这条数据能不能看”。
它要拆成数据范围、字段权限、动作权限、特殊规则和审计要求。
字段权限比想象中更麻烦
字段权限是做企业系统时很容易后补的东西。
前期为了快，很多系统会先把表单做出来，后面客户说某些字段不能给某些人看，再临时加控制。
但在低代码平台里，如果字段权限一开始没有进入设计，后面会非常痛苦。
因为字段不是固定的。
今天用户加一个“合同金额”，明天加一个“客户评级”，后天又加一个“成本预算”。这些字段都有可能需要权限控制。
更麻烦的是，字段权限还分很多种状态。
隐藏。
只读。
可编辑。
必填。
流程节点内可编辑。
特定条件下可编辑。
比如费用报销单，在发起人提交前，金额可以编辑。提交以后，发起人不能改金额，但财务审核时可以修改费用归类。流程结束后，所有人只能查看，不能再修改。
同一个字段，在不同角色、不同流程节点、不同数据状态下，权限可能完全不同。
这就是字段权限真正麻烦的地方。
它不是一个静态配置，而是和流程、状态、角色、条件一起变化。
行权限和字段权限会互相影响
做权限时，还有一个很容易被忽略的问题：
行权限和字段权限不是孤立的。
行权限决定一个人能不能看到某条记录。
字段权限决定他看到这条记录后，哪些字段可见、可编辑。
但很多时候，字段本身又会参与行权限判断。
比如：
负责人等于当前用户，可以查看。
所属部门等于当前用户部门，可以查看。
客户等级为战略客户，只允许指定角色查看。
项目状态为保密，只有项目成员可见。
这里的负责人、部门、客户等级、项目状态，都是字段。
也就是说，系统要先读取字段值，才能判断这条数据对当前用户是否可见。
如果字段权限和行权限的边界设计不清楚，就很容易出现绕不开的循环：
用户没有字段权限，所以不能读字段。
但系统又需要读字段，才能判断用户有没有数据权限。
这种问题在简单系统里不明显，在平台型产品里会被放大。
所以权限体系里必须区分“系统判权所需字段”和“用户可见字段”。
系统可以为了判权读取必要字段，但不代表这些字段一定展示给用户。
这个边界必须非常清楚。
权限不能只靠角色
很多企业系统一开始都会用角色权限。
销售、销售主管、财务、管理员。
角色是必要的，但如果只靠角色，权限很快会变硬。
因为真实企业里的权限，往往不是纯角色决定的。
它还和组织结构有关。
和数据归属有关。
和流程节点有关。
和临时协作有关。
和业务状态有关。
同样是销售主管，有的人管华东区，有的人管华南区。
同样是财务，有的人只能处理某个法人主体的数据。
同样是项目成员，有的人能看成本，有的人只能看任务。
如果全部用角色表示，角色数量会爆炸。
销售主管、华东销售主管、华南销售主管、能看成本的项目成员、不能看成本的项目成员……
最后系统里会出现一堆谁也说不清的角色。
所以我现在更倾向于把权限拆成几类东西：
角色解决“你是什么身份”。
组织解决“你属于哪里”。
数据归属解决“这条数据和你是什么关系”。
流程节点解决“现在轮到谁处理”。
规则表达式解决“特殊条件下怎么判断”。
这样权限才不会全部压到角色上。
流程里的权限最容易出问题
如果一个系统没有流程，权限已经够复杂了。
一旦有流程，权限复杂度会再上一个台阶。
因为流程会改变数据状态，也会改变人的操作边界。
比如一个合同审批流程：
发起人提交前，可以编辑合同内容。
提交后，发起人不能再改核心字段。
部门负责人审批时，可以填写审核意见，但不能改合同金额。
法务审核时，可以修改法务条款。
财务审核时，可以查看付款计划。
流程结束后，合同进入归档状态，普通人只能查看。
这时候权限不是静态的。
同一个人，对同一条数据，在流程前、流程中、流程后，权限都可能不同。
低代码平台要支持用户自己配置流程，就意味着平台也要支持这种动态权限变化。
这也是为什么我觉得流程和权限不能分开设计。
流程不是只负责“把任务推给下一个人”，它还会影响每个节点上哪些字段能看、哪些字段能改、哪些动作能做。
权限还要服务于 AI
现在做权限，还有一个以前不需要考虑的问题：
AI 能不能安全地访问业务数据？
如果 AI 只是聊天工具，问题还不大。
但如果 AI 要接入低代码平台，帮用户查数据、分析数据、生成报表、修改配置、触发流程，那权限就必须跟上。
用户问 AI：
“帮我看看这个客户最近的合同和回款。”
AI 不能因为自己是系统能力，就绕过用户权限。
它应该只能看到当前用户有权看到的数据。
用户让 AI：
“把这个客户负责人改成张三。”
AI 也必须先判断当前用户有没有修改负责人字段的权限。
用户让 AI：
“导出本月所有合同。”
AI 需要判断导出动作权限、数据范围权限，以及字段脱敏要求。
所以 AI 进入平台以后，权限不是变简单，而是变得更重要。
AI 应该是用户能力的延伸，而不是权限的后门。
这是我觉得企业 AI 应用里必须守住的底线。
我对第一版权限体系的要求
权限体系不能一上来就做成无所不能。
太复杂的权限配置，用户会害怕，开发也会失控。
第一版我更看重几个基本能力。
第一，角色权限要清楚。
用户能不能进入应用、模块、页面，能不能执行新增、编辑、删除、导出这些动作，要有清晰配置。
第二，数据范围要能表达。
至少要支持本人、本部门、本部门及下级、全部、按字段归属、按表达式这些常见模式。
第三，字段权限要进入模型。
字段的可见、只读、可编辑，不能只靠前端临时判断，要成为平台能力。
第四，流程节点权限要可配置。
流程中每个节点，哪些字段可编辑，哪些动作可执行，要能被配置出来。
第五，系统判权和用户展示要分开。
系统为了判权可以读取必要字段，但用户最终能看到什么，要由字段权限决定。
第六，权限结果要可解释。
当用户问“为什么我看不到这条数据”时，系统最好能给出原因，而不是只返回一个没有权限。
这点很难，但对企业系统非常重要。
做权限时最容易踩的坑
第一个坑，是只做菜单权限。
菜单权限看起来够用，但一进入真实业务，数据权限和字段权限马上会出现。
第二个坑，是把所有权限都塞进角色。
角色会越来越多，最后谁也不知道每个角色到底代表什么。
第三个坑，是后补字段权限。
字段权限如果一开始没进模型，后面和流程、表单、列表、导出、AI 结合时会很难补。
第四个坑，是前端判权太多。
前端可以控制显示，但真正的权限判断必须在后端兜住。否则只要换个入口，就可能绕过限制。
第五个坑，是权限没有审计。
企业系统里，谁看了什么、谁改了什么、谁导出了什么，有时候比权限本身还重要。
第六个坑，是权限配置太灵活。
这听起来像好事，但如果没有边界，用户很容易配出互相矛盾的规则，系统也很难解释结果。
权限体系不是越自由越好，而是要让常见场景简单，让复杂场景有出口。
写在最后
权限是低代码平台里最不像“功能”的功能。
它不像表单那么直观，也不像流程那么容易演示，更不像 AI 那样有话题感。
但它决定了一个平台能不能真正进入企业核心业务。
因为企业愿不愿意把客户、合同、订单、项目、财务这些数据放到平台里，很大程度上取决于它是否相信这套权限体系。
对织信来说，权限体系不是一个附属模块。
它应该和数据模型、表单引擎、流程引擎一起构成底座。
数据模型定义业务对象。
表单引擎承载数据录入和展示。
流程引擎推动业务流转。
权限体系负责在整个过程中回答：
谁，可以在什么条件下，对什么数据，做什么事情。
这个问题如果回答不好，平台越灵活，风险越大。
这个问题回答好了，低代码平台才有机会从“搭工具”走向“承载业务”。
下一篇，我想写流程引擎。
因为权限解决的是边界，而流程解决的是业务如何往前走。
下一篇标题暂定：
织信开发日志 06：流程引擎不只是画审批流
