ERP 数据录入出错，往往不是因为少做了一项“必填检查”，而是同一条业务规则只在一个入口生效：页面录入时被拦住了，批量导入却绕过去；字段格式正确，字段之间的业务关系却不成立。要把字段校验从0做到可上线、可维护，重点不是堆更多判断，而是先把规则说清楚，再按风险选择校验位置，并验证所有数据入口都遵守同一口径。

一、先说结论：字段校验要从业务规则开始，而不是从代码开始

1. 先回答三个问题，再选校验方式

我梳理字段校验时，会先问三个问题：什么情况下这条数据算错？错误会影响哪个后续环节？用户应该在什么时候、以什么方式发现并修正？这三个问题没有答案时，直接讨论前端提示、接口拦截或数据库约束，通常只是在选择技术形式，并没有解决规则本身不清楚的问题。

以采购申请为例，“申请数量必须大于0”是单字段规则；“申请组织必须与申请人有业务授权关系”是权限与组织规则；“某类物料必须填写需求日期”是条件必填规则。它们所需的数据、校验时机和失败处理并不相同，不能都压缩成一个“字段校验”开关。

我的核心判断是：规则先分层，校验再分层。先确定字段自身是否合法，再判断字段之间是否匹配，然后检查主数据、权限、业务状态和流程约束。最后再决定哪些规则适合即时提示，哪些需要提交时确认，哪些必须由服务端或数据层兜底。

2. 不要追求“校验越多越安全”

校验的价值不是让表单更难提交，而是减少可以被明确识别的错误，同时让用户知道怎么修正。每多一条拦截规则，就多一种误拦、漏拦或规则过期的可能。规则写得过严，用户会绕流程、填占位值，甚至转向线下表格；规则太松，错误则会流入审批、采购、库存或财务环节。

因此，选型时要同时看错误风险和操作成本。高风险、可客观判断的规则应尽量自动拦截；低风险、判断依据不稳定的情况，更适合提醒、复核或审批。不能把“系统能拦”误当成“业务应该拦”。

3. 把校验设计成一条闭环

一条可落地的校验规则，至少需要包含适用对象、触发时机、判断逻辑、例外条件、提示内容、责任人和测试方式。只写“数量要合理”不是规则；写清“当计量单位为箱时，数量必须为正数，并按采购单位允许的精度录入；不符合时阻止提交并提示用户检查单位和数量”，才接近可配置、可测试的要求。

• 定义：业务人员确认字段含义、规则边界与例外情况。
• 分层：区分字段格式、跨字段、主数据、权限和流程状态规则。
• 选型：按风险和数据入口选择提示、拦截、复核或底层约束。
• 验证：覆盖正常值、边界值、异常值以及页面、导入、接口等入口。
• 维护：明确规则变更责任人，并在业务或主数据变化后回归测试。

下面的决策关系是一个示意模型，不是行业统计：错误影响越大、越容易规则化，越应该自动校验；如果判断需要业务解释，自动拦截的风险也会随之增加。

二、为什么 ERP 录入校验容易失效：问题通常出在规则与入口之间

1. 字段填对了，整张单据仍可能不成立

ERP 表单里的每个字段看起来都能单独检查，但业务数据往往由多个字段共同表达。数量是数字，不代表数量有效；组织名称存在于下拉框，不代表当前用户可以在该组织下提交申请；物料编码格式正确，也不代表这个物料仍处于可用状态。

例如，一张采购申请包含申请组织、物料、数量、单位和需求日期。单字段检查可以发现数量为空、日期格式错误，却未必能发现物料的采购单位与申请单位不一致，也未必能发现申请组织无权采购该类物料。这类问题的关键不在输入框，而在字段间关系、主数据状态和组织权限。

2. 同一条数据可能从多个入口进入

一个常见设计误区是把页面表单视作唯一入口。实际项目中，数据还可能通过批量导入、外部接口、移动端、后台任务或历史数据迁移进入。若一条核心规则只写在页面脚本里，其他入口可能没有执行相同判断。

我会把“入口覆盖”作为规则评审的单独一栏，而不是测试阶段临时补查。比如，数量范围规则不只要在页面上测，也要确认导入模板和接口提交时会发生什么；如果某个入口确实不支持即时提示，也必须说明错误如何返回、由谁处理，以及失败数据是否会进入正式业务表。

3. 录入错误的成本，常在后续环节才显现

错误数据不一定会立刻导致系统报错。物料选错可能在审批或采购执行时才被发现，组织选错可能影响权限与归属，单位错误则可能让数量看起来正常但业务含义发生变化。因而校验设计不能只看“保存是否成功”，还要追踪错误在哪个环节被发现、需要几个人返工、是否产生重复录入。

对一个项目来说，最有价值的基线不是笼统的“数据质量差”，而是可观察的过程指标，例如每百张单据的驳回次数、每周因字段问题退回的数量、导入失败记录占比、从提交到纠错的平均耗时。没有基线，就无法区分新规则究竟减少了错误，还是只是把错误推到了别的环节。

4. 搜索到的单一技术场景不能代表所有 ERP

围绕采购申请输入字段校验的技术内容，可以帮助读者理解某个具体业务模块中的字段检查需求；但单一模块、单一系统或单一实现方式，不能直接推导成所有 ERP 都采用同一配置方法。系统版本、表单配置能力、接口架构、数据权限模型和企业流程，都会影响规则的落点。

因此，本文把采购申请作为演示场景，而不把它当成通用产品说明。凡是涉及“某系统默认支持什么”“某版本必须在哪一层校验”的内容，都应回到产品文档、架构设计和项目配置中确认，不应凭经验推成统一事实。

三、常见误区：看起来做了校验，实际上只覆盖了表面

1. 把必填、长度和格式当作全部校验

必填、长度、日期格式、数字精度是基础校验，但它们只回答“输入值长什么样”。ERP 更需要回答“这个值在当前业务上下文中是否有效”。例如，物料编码格式正确但已停用，日期格式正确但早于允许的业务期间，组织字段有值但用户无权选择，都不是格式问题。

我通常把规则拆成五层：字段本身、字段组合、主数据状态、权限范围、流程状态。若需求清单只有“必填、长度、格式”，评审时就要追问：字段之间有没有依赖？主数据会不会失效？不同角色能否录入相同值？单据在不同状态下是否允许修改？

2. 以为前端提示等于数据安全

前端适合快速反馈，但它不能保证所有数据入口都被同样约束。页面校验可能因为界面改版、旧版本客户端、脚本异常或绕过页面的接口调用而失效。因此，关键业务规则通常需要在可信的服务端或业务处理环节再次确认；数据库层则适合承担适用范围明确的底层完整性约束。

这不是要求每条规则在每一层重复实现。重复实现会带来口径漂移：页面允许提交，接口却拒绝；提示文字说一种原因，服务端返回另一种原因。正确做法是先确定规则的权威来源，再安排不同层负责反馈、业务兜底和数据完整性，并通过测试保证口径一致。

3. 把规则写成“合理”“正确”“符合规范”

“数量要合理”无法测试，“日期要符合规范”也没有说明规范是什么。模糊词会让业务、开发和测试各自补充自己的理解，最后验收时才发现大家讨论的不是同一条规则。

一个可执行的规则描述应当包括条件、判断、动作和例外。例如：“当申请类别为备品采购时，物料、申请数量和申请组织为必填；数量必须大于0；若单位换算关系不存在，则不允许提交，并提示联系主数据维护人员。”该描述仍需业务确认，但已经具备讨论和测试的基础。

4. 把所有异常都设计成阻断

阻断式校验看上去最严格，但并不总是最安全。若数据缺失是暂时的、需要主管补充判断，或者企业存在紧急采购流程，直接拒绝可能迫使员工填写虚假值绕过系统。对规则不稳定、例外较多的场景，提示、暂存、审批或例外授权可能更合适。

选择提示还是拦截，应考虑错误后果、规则客观性、纠正难度和业务连续性。规则越客观、错误后果越大、修正成本越低，拦截越有价值；判断越依赖经验、例外越频繁，越应考虑人工确认和留痕。

5. 只测“正确输入”，不测边界与绕行入口

测试时只输入一条正常数据，最多证明系统在这一种条件下能工作。真正容易暴露缺陷的，往往是空值、空格、精度边界、过期主数据、重复提交、权限变化、多个字段互相冲突，以及导入模板中的非法值。

我建议测试用例按“规则类型 × 入口 × 结果”组织，而不是只按页面控件列用例。这样更容易发现某条规则在页面有效、导入无效，或错误被拦住却没有给出可处理反馈的情况。

四、专业判断逻辑：用风险、入口和维护成本共同选型

1. 先按规则类型分类，不急着选技术层

字段校验可以先按业务逻辑归类，再讨论实现方式。以下分类不是产品功能清单，而是帮助业务、开发和测试建立共同语言。

2. 用风险矩阵判断拦截强度

风险评估不需要先发明复杂评分体系。项目早期可以用三个问题做定性判断：错误会造成多大影响？错误发生的可能性是否值得关注？错误是否容易在后续环节发现？这三项足以帮助团队区分首批上线的关键规则和可以后续优化的便利性规则。

如果企业希望量化排序，可以使用“影响程度 × 发生可能性 × 发现难度”的内部评分，但要把它视为项目排序工具，不是客观概率。评分尺度由业务团队统一定义，并记录依据；不要把某个固定分数包装成行业标准。

3. 按规则性质选择校验位置

即时校验适合反馈快、判断简单且不依赖复杂业务状态的规则，例如必填、格式和基本范围。它能减少用户反复提交，但不应被当作最终可信判断，因为页面之外的数据入口未必执行相同逻辑。

保存或提交时校验适合跨字段、依赖业务状态或需要查询主数据的规则。它更容易基于完整单据作判断，但可能增加等待时间，错误信息也需要指出具体字段和修正方向。

服务端或业务处理环节适合承接关键规则，尤其是页面、导入和接口都可能调用的规则。底层数据约束适合表达稳定、明确且与数据库结构匹配的完整性要求；但涉及复杂业务状态、动态权限或用户友好提示时，不能指望数据库约束独自承担全部职责。

可复用的原则不是“每一层都复制一份逻辑”，而是“同一条规则有明确权威来源，多个入口不能绕开它”。页面负责尽早提示，服务端负责业务确认，数据层负责适用的底层完整性，各层分工应根据系统架构明确。

4. 把错误提示当成规则的一部分

一条校验即使判断正确，如果只返回“提交失败”或内部错误码，用户仍不知道下一步做什么。好的提示至少回答三个问题：哪个字段有问题？问题是什么？用户可以采取什么动作？例如，“申请数量必须大于零，请检查数量和计量单位”，比“数据校验失败”更能帮助用户完成修正。

提示内容还要区分用户可处理和需要管理员处理的异常。用户能修改的格式错误，应直接告诉他如何修改；主数据停用或组织授权缺失，则应说明该联系哪个岗位或走什么流程。不要让用户反复尝试一个自己没有权限修复的问题。

5. 先设维护责任，再考虑规则数量

规则不可能永远不变。物料状态、组织范围、审批流程、字段口径都可能调整。如果没有责任人，今天的校验会在业务变化后成为新的阻塞点。每条关键规则至少要知道由谁确认业务含义、由谁实施变更、由谁执行回归测试。

如果规则变化频繁、需要业务人员调整且系统具备可管理的配置能力，可以考虑规则配置化；如果逻辑稳定、范围小、变更由技术团队控制，直接在应用逻辑中实现也可能更容易维护。配置化不是天然更先进：配置界面、权限、版本记录、冲突处理和测试机制都要付出成本。

五、采购申请案例：把一条模糊要求变成可执行校验

1. 从一句业务要求拆成字段清单

假设某企业希望“采购申请填完整、别选错物料”。这句话适合启动讨论，却不能直接进入开发。第一步是列出字段的业务含义、来源、责任人和适用环节，再把“完整”和“选错”拆成能够确认的判断条件。

这张表刻意把“候选规则”和“确认方”放在一起。实施中，字段清单的价值不只是告诉开发人员该怎么做，更是把规则决策还给真正拥有业务口径的人。若规则没有确认人，开发人员很容易被迫替业务做决定。

2. 分开处理字段级规则和组合规则

申请数量大于零属于字段级规则；物料与计量单位是否匹配、申请组织是否能申请指定物料，则属于组合规则。前者通常可以在输入时快速提示，后者需要拿到关联数据，并结合权限或主数据状态判断。

例如，用户录入“物料A、数量12、单位箱”，三个字段单独看起来都有效，但系统仍需确认物料A是否允许用“箱”采购，以及12箱是否符合企业的单位换算与精度口径。如果物料主数据里不存在这个单位关系，就不能仅凭“数量是正数”放行。

3. 先定义失败动作，再设计提示文案

不是所有失败都应有同一种处理方式。对于数量为零，可以明确阻止提交；对于物料已停用，可以提示更换有效物料并阻止继续；对于需求日期早于常规交期，如果企业有紧急采购例外，则可以要求补充说明并进入相应审批，而不是一律拒绝。

4. 用少量清楚的规则先跑通试点

下表是一个情景模拟，用于说明如何观察字段校验上线效果。假设某采购团队每月处理300张申请，试点前记录到24张因字段问题退回；调整规则后，连续观察两个月，分别记录到15张和12张。这个数字不是外部行业数据，也不代表实际项目成果；真实发布时应替换为企业自己的统计结果，并说明统计周期、样本范围与“字段问题”的定义。

如果要用这组试点方法做真实评估，不能只看退回率。还要检查是否出现更多的线下补录、用户放弃提交、错误被转移到审批阶段，或者提示过多导致操作耗时增加。一个看起来下降的错误指标，可能只是统计口径变了。

5. 代码示例要表达业务边界，而不是假装覆盖系统架构

下面的伪代码仅演示“先判断是否适用，再进行字段校验，最后返回用户可处理的信息”的表达方式，不对应某个 ERP 产品或特定开发框架。实际实现应结合系统的数据访问、权限、事务和错误返回机制，并由业务确认例外条件。

function validatePurchaseRequest(request, user, masterData) {
const errors = [];

if (!request.organizationId) {

errors.push({

field: "organizationId",

message: "请选择申请组织。"

});

} else if (!user.allowedOrganizationIds.includes(request.organizationId)) {

errors.push({

field: "organizationId",

message: "当前账号无权在所选组织下提交，请检查组织选择或联系权限管理员。"

});

}

if (!request.itemId) {

errors.push({

field: "itemId",

message: "请选择申请物料。"

});

} else {

const item = masterData.getItem(request.itemId);

if (!item || item.status !== "active") {

errors.push({

field: "itemId",

message: "当前物料不可用于新申请，请选择有效物料。"

});

}

}

if (request.quantity == null || request.quantity <= 0) {

errors.push({

field: "quantity",

message: "申请数量必须大于零。"

});

}

if (request.needByDate && isApprovedException(request)) {

// 例外进入已确认的业务流程，不等于跳过全部校验。

} else if (request.needByDate && isOutsideAllowedDateRange(request.needByDate)) {

errors.push({

field: "needByDate",

message: "需求日期超出当前业务允许范围，请检查日期或提交例外说明。"

});

}

return {

valid: errors.length === 0,

errors

};

}

六、从规则清单到上线验收：按阶段推进，别一次性堆满校验

1. 盘点字段时，先找业务对象和数据来源

盘点字段不是抄表单标签。字段名称可能叫“申请部门”，实际含义却可能是成本归属部门、发起部门或采购组织。先问清字段表达什么、从哪里来、谁负责维护、后续哪些流程会读取，再讨论它是否必填和如何检查。

我建议用一次短会把业务、实施、开发、测试和关键用户拉到同一张字段表前。业务人员解释口径，实施或分析人员记录流程位置，开发人员判断数据依赖，测试人员补充边界场景。这样比把需求拆成多轮传话更容易提前发现同名异义和规则冲突。

2. 将口头规则改写成规则规格

每条规则可使用统一模板，确保业务和技术讨论的是同一个对象。模板不必复杂，但要足以回答“什么时候触发、依据是什么、失败怎么办、怎么验证”。

3. 用测试矩阵覆盖入口、规则和反馈

测试矩阵能把“规则已经开发”与“规则真的可用”区分开。对于每条规则，至少明确适用入口和预期结果。系统不支持某个入口做即时提示，并不代表可以忽略该入口，而是要把错误反馈方式写清楚，例如导入结果文件是否能定位到行号和字段。

4. 试运行期间收集能驱动决策的数据

试点阶段要记录的不只是“错误被拦下多少次”。我会优先关注四类信号：哪些规则触发频繁、哪些错误经常被误拦、用户是否能根据提示自行修正、是否出现其他入口绕过校验。触发次数高不一定意味着规则有价值，也可能说明界面设计、主数据质量或业务流程本身存在问题。

统计指标应有清楚定义。例如，“校验触发率”可以是触发规则次数除以提交次数，但一张单据可能触发多条规则；“误拦率”需要由业务复核确认哪些拦截原本不应发生；“纠错耗时”要说明是否包含联系主数据维护人员的等待时间。不同定义不可直接混用。

5. 规则变更要能追溯和回归

规则一旦上线，就要按业务变化管理。物料状态新增、组织调整、审批流程变化、采购类别增加，都可能改变某条规则的适用范围。变更记录至少要说明改了什么、为什么改、谁确认、影响哪些入口、回归测试覆盖什么。

如果规则来自配置表或主数据，要明确谁能修改、是否需要审批、如何防止测试环境与生产环境口径不同。如果规则写在应用逻辑中，则要把相关测试用例和业务负责人保留下来，避免技术人员离岗后只能靠猜测维护。

七、不同情况下怎么选：先分清你真正面对的约束

1. 小型团队或规则简单：先把基础约束做扎实

如果字段数量少、入口单一、规则稳定，优先完成必填、格式、范围和少量关键组合检查，并确保核心规则在服务端处理环节有效。此时不必为了“架构完整”搭建庞大的规则平台，先把规则规格、测试用例和责任人补齐，往往更有价值。

但入口单一也要经过确认，而不是凭直觉认定。若团队实际通过表格导入或外部系统同步数据，就不能只实现页面校验。上线前至少列出数据写入路径，逐条确认哪些路径要执行关键规则。

2. 多入口、数据量大：优先统一规则口径与错误回传

当页面、导入、接口和后台任务并存时，最重要的不是增加更多页面提示，而是避免同一业务规则分散在多个实现里、逐渐产生差异。应优先明确可信的业务处理位置，统一错误结构，并让每个入口能把错误准确返回到单据、行号和字段。

批量导入尤其要考虑部分成功还是整体失败。整批拒绝能保持一致性，但可能让用户为一个错误重做大量数据；逐行处理更灵活，却必须清楚标注成功、失败和可重试记录。选择哪种方式，取决于数据依赖、事务设计和业务对批次一致性的要求。

3. 主数据变化频繁：校验重点应转向数据状态和责任链

如果物料、供应商、组织或单位关系经常变化，静态下拉选项和长期缓存可能让用户选择到已经失效的数据。此时要评估查询时效、状态同步、变更通知和历史单据兼容规则。不能简单地把“保存时查一次”当成适用于所有数据的解决方案，还要考虑查询失败时应阻断、重试还是转交处理。

主数据质量问题也不应全部推给录入校验。若用户频繁遇到“找不到正确选项”或“选项已停用”，根因可能是主数据治理、责任归属或同步机制，而不是员工不会填表。校验可以揭示问题，但不能代替主数据维护流程。

4. 例外较多：先记录、审批和观察，再逐步自动化

如果业务规则经常因为紧急订单、特殊组织、历史项目或客户要求而例外，先把例外条件记录清楚，不要急着用一条硬编码规则拦截所有情况。可以让用户提交说明，由授权人员审批，并统计例外原因，观察哪些例外是合理且重复出现的。

当例外类型稳定、条件可以明确定义之后，再决定是否把它转成规则。反过来，若还没有统一口径就先自动化，往往会出现大量临时豁免，最终形成谁都不敢改的复杂配置。

5. 系统能力有限：用流程和检查表补齐，而非假装已自动化

部分系统可能无法在某个入口实现即时校验，或缺乏灵活配置能力。此时可以通过导入模板校验、提交前清单、抽样复核或审批提示降低风险，并清楚说明这些措施的覆盖边界。人工控制不如自动规则稳定，但比声称“系统已全面防错”更诚实、可管理。

如果关键风险无法被现有系统可靠覆盖，应把它列入改造清单，明确短期控制措施、责任人和复评时间。控制措施的目标不是掩盖技术限制，而是在升级前维持可接受的业务风险。

八、选型中的取舍：校验越严格，不代表整体质量越高

1. 即时提示与提交拦截的取舍

即时提示能缩短发现问题的时间，适合格式、必填和简单范围检查；但过多实时请求可能增加页面等待，依赖远程主数据的规则也可能出现网络波动。提交拦截可以基于完整单据检查跨字段关系，却会让用户在填写较久后才发现问题。

合理做法是把反馈前移和最终确认结合起来：能安全、快速判断的规则尽早提示；依赖完整业务上下文的规则在保存或提交时确认；关键业务规则在可信处理环节再次执行。不同层的提示应保持相同的业务解释。

2. 自动拒绝与人工审批的取舍

自动拒绝适合条件明确、例外少、错误影响大的情况。它的优势是口径一致、执行快；短板是规则一旦过时，所有符合旧口径的业务都会受到影响。人工审批适合需要综合判断的情况，但会增加处理时间，也需要记录审批依据，避免审批成为无解释的“点通过”。

很多业务不必二选一。系统可以先拦截明确错误，再把条件性例外导向有权限的审批流程；审批通过只针对特定单据或条件，不应无意间关闭所有相关校验。

3. 配置化与代码实现的取舍

配置化适合规则数量多、业务调整频繁、业务人员需要参与维护的场景，但要承担配置权限、版本管理、冲突检测、发布流程和测试机制的成本。代码实现适合逻辑稳定、变更少、由技术团队集中维护的规则，但业务口径变动时，需要走开发和发布流程。

判断时不要问“哪种更先进”，而要问：谁会改规则？多久改一次？修改是否需要审批？如何回滚？错误配置造成影响时谁负责？如果这些问题没有答案，过早配置化只会把维护问题从代码搬到配置页面。

4. 规则覆盖率与录入体验的取舍

提高覆盖率不等于把所有可能情况都变成阻断。规则越细，维护负担和用户理解成本也会增加。先覆盖高影响、可判定、能稳定执行的规则，再根据数据观察补充低风险规则，通常比一次性追求“零错误”更稳妥。

如果拦截数量增加但纠错时间变长、误拦投诉上升，说明需要重新评估规则、提示和操作路径。如果退回率下降，人工纠错耗时却没有变化，可能表示问题被转移到其他环节。评价校验效果时，至少要把质量、效率和用户负担放在一起看。

九、上线前检查清单：让规则能验收，也能长期维护

1. 业务口径检查

• 每个字段是否有明确业务含义，而不只是表单标签？
• 必填条件、允许取值、精度和例外情况是否由业务负责人确认？
• 单字段规则和字段组合规则是否分开描述？
• 主数据、权限和流程状态是否影响字段有效性？
• 争议规则是否标注待确认，而不是由技术实现人员默认决定？

2. 实现与入口检查

• 页面、导入、接口、移动端和后台任务等数据入口是否已经盘点？
• 关键规则是否有明确的权威处理位置？
• 页面提示、服务端返回和底层约束之间是否存在口径冲突？
• 导入失败能否定位到具体文件行、字段和原因？
• 主数据查询失败、网络异常和重复提交时，系统行为是否明确？

3. 测试与维护检查

• 是否测试了正常值、边界值、无效值、例外值和跨字段冲突？
• 是否验证不同入口执行关键规则的结果一致？
• 错误提示是否告诉用户问题位置、原因和修正方法？
• 是否定义上线前后的观察指标及其计算口径？
• 每条关键规则是否有业务确认人、维护人和回归测试责任人？

这份清单的目的不是让项目组勾完所有项目就宣布“数据质量有保障”，而是让规则的范围、责任和限制可见。若某一项暂时无法实现，应明确替代控制方式和后续计划，而不是把未覆盖风险留在模糊表述里。

十、结语：先让规则可解释，再让校验自动化

1. 从一张字段表开始，而不是从一段代码开始

ERP 字段校验从0到1，真正的起点不是开发页面，而是把业务语言转成可讨论、可测试、可维护的规则。先识别字段含义和数据来源，再区分字段自身、字段关系、主数据、权限和流程状态，最后按风险、入口和维护成本选择校验方式。

我更愿意把“拦住多少错误”看作校验系统的一个结果，而不是唯一目标。能否让用户理解问题、能否覆盖所有适用入口、是否减少返工而没有制造更多误拦、业务变化后是否还能维护，同样决定这套规则有没有实际价值。

2. 下一步从一个业务场景做小范围验证

如果你正在启动 ERP 数据录入治理，可以先选一个字段范围清楚、错误记录可追踪的单据场景，例如采购申请；整理10至20条候选规则，逐条确认责任人、例外条件和入口，再挑出少量高风险规则试运行。这个数量只是便于启动讨论的建议，不是标准配置，实际范围应由项目规模和规则复杂度决定。

试点前先记录退回原因、人工纠错耗时和适用入口；试点后同时看错误是否减少、误拦是否增加、用户能否自助修正。若结果不理想，不要立刻增加更多校验，先追查规则定义、主数据、权限和提示方式。字段校验的成熟，不是把所有人挡在提交按钮之外，而是让正确数据更容易进入业务流程，让错误在最容易修正的位置被发现。

免费注册

咨询方案

扫码咨询方案