一、自定义的五个粒度层级
把「支持低代码」拆开看，它至少包含五个粒度层级。层级越深，能表达的业务越复杂，但对系统稳定性的影响也越大，升级时的存活率越低。评估时最好先确认业务需求真实落在哪一层，而不是笼统地要求「越灵活越好」。
| 粒度层级 | 自定义对象 | 典型需求 | 对升级的影响 |
|---|---|---|---|
| 字段级 | 增加字段、调整字段属性与校验规则 | 增加「项目编号」「合同号」等业务字段 | 最小：随元数据配置一并迁移 |
| 表单级 | 调整布局、分组、显示逻辑、必填条件 | 按费用类型显示不同的填报项 | 较小：布局与元数据一并保留 |
| 流程级 | 审批节点、条件分支、并行与加签规则 | 金额分档走不同审批链、跨部门会签 | 中等：需确认流程定义是否随版本升级 |
| 模型级 | 自定义单据类型、表结构与实体关系 | 新增一类台账、扩展辅助核算维度 | 较大：需确认自定义模型的升级兼容策略 |
| 代码级 | 在内核或标准对象上挂脚本、插件、扩展点 | 复杂取数逻辑、跨系统调用、特殊校验 | 最大：升级前必须逐项回归测试 |
这五个层级不是选得越深越好。实务中合理的做法是：能用字段级与表单级解决的不上升到流程级，能用配置解决的不用代码。原因很直接——每一层自定义都是一笔长期负债，系统每次升级都要为它做一次兼容验证，层级越深，验证成本越高。
粒度评估的三个提问
- 业务需求的真实落点在哪一层，是否存在用浅层配置就能满足的等效方案
- 该层级是厂商官方提供的扩展点，还是需要改动标准对象或内核
- 同一个需求用不同层级实现后，升级验证的工作量差多少
二、复杂逻辑怎么表达：四种方式的取舍
业务逻辑的表达方式，决定了自定义内容能不能被厂商的升级包正常对待。四种常见方式的能力上限与风险各不相同。
| 表达方式 | 能力上限 | 适用场景 | 主要风险 |
|---|---|---|---|
| 参数与开关配置 | 低，只能做固定的分支与阈值 | 费用标准、审批阈值、显示开关 | 能力不足时容易被绕过，改回代码 |
| 公式与规则引擎 | 中，可做条件组合与四则运算 | 取数、分摊、校验、提醒规则 | 公式可读性差，规则变更缺少留档 |
| 可视化流程与页面设计器 | 中高，可编排流程与页面交互 | 审批链、填报页面、条件分支 | 版本差异大，跨版本迁移需人工核对 |
| 脚本或插件代码 | 高，几乎不受限 | 跨系统调用、特殊算法、复杂校验 | 与内核耦合，升级极易失效，且难追溯 |
选型时最有价值的一次演示，是让对方用规则引擎或流程设计器实现一条本单位真实存在、且带条件分支的逻辑，而不是实现一条演示用的简单流程。真实的复杂逻辑通常包含多层条件嵌套、跨单据取数、按组织差异化的阈值——这些地方最能暴露配置能力的上限。
这里有一份低成本的自查清单，可以避免把配置能力当成代码能力的替代品：把本单位历史上通过补丁、脚本或人工干预解决过的业务需求列出来，逐条判断在新的低代码平台上能否用配置实现。凡是必须落到脚本层的，都要在合同里单独约定升级支持责任。
三、升级存活率：最容易被忽略、代价最大的一项
自定义内容的升级存活率，是低代码评估中最容易漏掉、也最容易在第一次升级时集中爆发的问题。它取决于三类机制是否存在。
- 官方扩展点机制：厂商是否提供受支持的扩展点（钩子、事件、插件接口），自定义逻辑挂在这些扩展点上，而不是直接改标准对象或内核文件
- 元数据版本管理：自定义的字段、表单、流程是否以元数据形式独立存储，并能随版本迁移，而不是散落在代码与数据库结构里
- 升级前差异比对：升级时是否提供自定义内容清单与冲突报告，让实施方能提前知道哪些自定义会失效、需要重新适配
第一类机制尤其关键。把自定义逻辑挂在官方扩展点上，升级时厂商的升级包不会覆盖它；直接改标准对象或内核文件，升级包一旦覆盖，轻则功能丢失，重则系统无法启动。判断方法很简单：问厂商「如果我不小心把自定义写在标准对象上，你们的下一个升级包会不会覆盖它」，得到的回答基本能反映真实的设计水平。
第二类机制有一个规范层面的支撑点。《会计软件基本功能和服务规范》（财会〔2024〕12 号，财政部 2024 年 7 月 29 日印发，2025 年 1 月 1 日施行）要求会计软件结构具备开放性，提供易于理解的标准数据接口，便于实现与其他信息系统集成或数据交换；同时，该规范为施行前已投入使用的会计软件留出了升级完善期，要求其在规定期限内完成升级。这意味着在可预期的几年内，多数企业都会经历一轮软件升级，自定义内容的迁移不会是一次性的偶发事件，而是常态。
升级存活率的三个验证动作
- 要求厂商出具上一版本的升级说明，看其中「自定义内容兼容性」章节写了什么
- 索取一份真实的升级冲突报告样例，确认能否逐项列出失效的自定义内容
- 在试点环境做一次「自定义后升级」的演练，观察自定义字段、流程与脚本的存留情况
四、不能自定义的底线在哪里
低代码扩展能力再强，也有几处是不能碰的。这些底线并不来自厂商的技术限制，而是来自会计软件应当遵守的基本要求。
最核心的一条是已记账凭证的不可逆性。《会计软件基本功能和服务规范》第二十一条要求，会计软件应当提供不可逆的记账功能，不得提供对已记账凭证的删除和插入功能，不得提供对已记账凭证日期、币种、汇率、金额、科目、操作人等的修改功能。如果一套低代码平台的宣传口径是「什么都能改」，那么在凭证环节就必须追问清楚：它如何处理这条不可逆要求？答案是绕不过去的——合规的做法只能是通过红冲、反记账等受控流程，而不是直接修改或删除。
第二条与自动审核规则有关。《会计信息化工作规范》（财会〔2024〕11 号，2025 年 1 月 1 日施行）第十七条要求，对于会计信息系统自动生成且具有明晰审核规则的会计凭证，可以将审核规则嵌入系统由系统自动审核；未经自动审核的凭证应当先经人工审核再进行后续处理；系统自动审核的规则应当可查询、可校验、可追溯，其设立与变更应当履行审签程序，严格管理，留档备查。低代码允许业务人员自行调整审核规则时，必须同时把变更审签与留档机制设计进去，否则灵活性会直接转化为控制缺口。
第三条与操作日志和数据归属有关。同一系列规范要求软件能够按操作人员、操作时间、操作内容查询用户操作日志，并要求会计数据归用户所有、不得以任何理由拒绝导出。自定义内容如果使得日志记录被绕过（例如通过脚本直接写库），或者使得数据只能存在于该平台的私有格式中，都会在检查与退出时形成障碍。
| 自定义对象 | 是否可自定义 | 判断依据 |
|---|---|---|
| 业务字段与填报表单 | 可 | 属于元数据配置，不影响会计规则与审计轨迹 |
| 审批流程节点与分支 | 可，但须留变更记录 | 流程变更应留下版本与审批记录，避免控制被静默修改 |
| 取数与分摊规则 | 可，但须可校验 | 规则应可查询、可校验，变更须审签留档 |
| 已记账凭证的内容 | 不可 | 不得提供删除、插入与关键要素修改功能，只能走红冲等受控流程 |
| 用户操作日志 | 不可绕过 | 日志须可按操作人员、时间、内容查询，不得被自定义逻辑跳过 |
| 会计数据的导出 | 不可限制 | 数据归用户所有，不得以任何理由拒绝导出 |
五、评估清单：把上面几节变成可以打勾的动作
低代码扩展能力的评估结论，最终应当落在一份可复核的清单上，而不是「感觉挺灵活」。
- 列出本单位未来两年最可能提出的十项扩展需求，逐项标注落在哪个粒度层级
- 要求厂商对其中至少三项用真实规则实现，拒绝用演示数据与简化流程替代
- 要求厂商明确列出官方扩展点清单，并说明哪些对象属于「不建议改动」
- 索取一份升级冲突报告样例，确认能逐项列出失效的自定义内容
- 在试点环境做一次自定义后升级的演练，记录字段、流程、脚本的存留情况
- 确认凭证不可逆、日志不可绕过、数据可导出这三条底线在配置层面无法关闭
- 把自定义内容的维护责任、升级适配责任写入合同，明确超出官方扩展点的改动由谁承担
第六条最容易被跳过，却最值得当场验证。让厂商在演示环境里试着关闭凭证的不可逆保护，如果关不掉，说明设计上守住了底线；如果能关掉，那么这套灵活性在检查场景下就是风险。这一点与前面几节的判断标准是一致：低代码的价值在于让业务变化不必每次都提开发需求，而不是让会计控制可以被随意改写。
最后提醒一句评估的相对性。低代码国家标准与团体标准正在快速成型——例如《系统与软件工程 低代码开发平台通用技术要求》（GB/T 46900-2025，2025 年 12 月 31 日发布，2026 年 7 月 1 日实施）规定了低代码开发平台的通用能力要求与等级要求，适用于需方、供方、维护方和独立评价方开展研发设计、测试评估、实施应用和产品选型；中国通信标准化协会发布的《低代码和无代码开发平台通用功能要求》（T/CCSA 568-2024，2024 年 11 月 11 日发布，2025 年 1 月 1 日实施）则规定了平台应具备的共性功能要求，并明确可用于企业用户建设平台与产品选型参考。这些标准适合作为评估的框架来源，但不能替代针对本单位业务的实测——标准回答的是「平台该有什么」，实测回答的是「它能不能解决我的问题」。
资料来源：《系统与软件工程 低代码开发平台通用技术要求》（GB/T 46900-2025，2025 年 12 月 31 日发布，2026 年 7 月 1 日实施）；《低代码和无代码开发平台通用功能要求》（T/CCSA 568-2024，2024 年 11 月 11 日发布，2025 年 1 月 1 日实施）；《会计信息化工作规范》（财会〔2024〕11 号）第十七条；《会计软件基本功能和服务规范》（财会〔2024〕12 号）第七条、第二十一条。