你的脏数据，是平台亲手造的

Lin 的那句话，值得每个做数据平台的人记下来。

她是一家 400 人制造企业的供应链负责人。系统上线八个月后，她发来一张截图：1914 张采购单，供应商字段全部为空。而供应商字段是必填的——从项目第一周起就是必填的。她的原话只有一行：「表单不让我保存这种数据。那是谁保存的？」

答案她其实已经猜到了：是平台自己保存的。

这不是运维事故，也不是用户误操作。这是一个行业级的架构盲区：数据校验的锁，只装在门最少的那一扇上。 平台越跑越久，脏数据不是漏进来的，是平台亲手放进去的。

🚪 表单只是一扇门

一扇有锁的门，护不住一栋有八扇门的房子。

主流低代码平台几乎都把「数据校验」写在表单设计器的文档里，和条件显示、动态计算并列。文档写在哪里，建设者就把校验做在哪里——大多数团队的第一反应，都是在表单上加必填、加正则、加取值范围。

问题在于，表单恰恰是使用频率最低的写入入口。

数一数一个跑了一年的平台，数据从哪些门进来：表单、Excel 导入器、公开 WebAPI、定时脚本、工作流流转时的关联更新、来自 ERP 的入站 Webhook、一个会增删改记录的 AI Agent，还有迁移那个周末实习生随手粘进来的 CSV。

八扇门。一把锁。而那把锁，装在唯一一扇需要有人坐在工位前才能打开的门上。

这就是为什么 Lin 的 1914 张采购单能带着空供应商字段顺利入库——大概率是某次批量导入或 API 同步干的。填表的人被校验拦得死死的，走旁路的数据畅通无阻。校验越严，旁路越诱人：业务方赶工期，发现导入器能绕过必填，下次就直接用导入器。

☑️ 导入路径的校验，只是个没勾的复选框

更关键的事实是：多数平台的导入路径不是没有校验能力，而是校验默认关闭，需要显式开启。而现实中，负责部署实施的人往往不是最终为数据质量负责的人——交付验收看的是功能跑通、报表出数，没有人验收「第八扇门有没有锁」。

实施阶段是雷区最密集的时刻：旧系统数据要按期搬进来，映射没对齐、字段类型不匹配、必填字段在旧库里本来就是空的——怎么办？先把校验关了，数据先过去，回头再补。回头是永远不会来的。

于是形成了一个非常工程化的闭环：平台提供了校验能力，平台的默认配置却在系统性地绕过校验。 脏数据的所有权由此变得暧昧——用户说不是我填的，实施说校验是开着的，平台方说功能我提供了。最后买单的是数据，以及所有依赖这张表做决策的人。

这个买单的成本是可以量化的。Gartner 2021 年发布的数据质量市场指南估算，糟糕的数据质量平均每年给每个组织造成约 1290 万美元 的损失（Gartner, Market Guide for Data Quality Tools, 2021）。哈佛商业评论 2016 年的一项研究则发现，接受调研的 75 家企业中，只有 3% 的数据质量达到基本可用标准，47% 新建数据中至少存在一处关键性错误（Nagle, Redman & Sammon, "Only 3% of Companies' Data Meets Basic Quality Standards", HBR, 2016）。数据质量的经典「1-10-100 法则」也早已指出：录入时修正的成本是 1，流程中修正的成本是 10，错误数据流入决策后的代价是 100。

🤖 第八扇门，正在变成最宽的那一扇

如果说前七扇门是历史遗留，第八扇门——AI Agent——正在让这个架构缺陷以更快的速度放大。

一个会自主增删改记录的 Agent，不需要坐在工位前。它调用 API 写入数据，绕过表单的方式和定时脚本一样彻底，但比脚本危险得多：脚本的逻辑是人写的，一次评审后行为可预期；Agent 的行为是模型在运行时决策的，没有哪份文档能穷举它会往哪些字段填什么值——尤其是大模型常见的「幻觉补全」，会把缺失字段用看起来合理的值填满。

一张被四百人手工维护、数据质量尚可的表，接上一个没有约束的 Agent，相当于给一栋八扇门的房子又开了一扇 24 小时无人值守、且钥匙谁都能拿的门。

这不是在反对 AI 进数据平台。恰恰相反——Agent 要被信任，前提是写入路径上有门禁。没有约束的 Agent 写入，不是自动化，是失控。

🔧 把锁从门上挪到数据层

解法在架构层面其实很清楚：把校验从表单设计器里拿出来，下沉到数据模型层。这是数据库领域几十年前就给出的答案——约束属于 schema，不属于界面。

具体来说，数据层约束意味着：

1. NOT NULL / CHECK / UNIQUE / FOREIGN KEY 约束直接定义在表结构上。 一旦约束落在数据库引擎层，无论写入来自表单、COPY 批量导入、ORM、API 还是 Agent，任何违反约束的写入都会被引擎拒绝并返回明确错误。PostgreSQL、MySQL、SQL Server 都原生支持这套机制，不需要应用层配合。

2. 低代码平台需要在引擎之上暴露同样的语义。 表设计器里的「必填」应编译为数据模型的 NOT NULL 属性而非表单控件属性；导入器和 API 网关在写入前执行同一套 schema 校验（例如基于 JSON Schema 的请求校验），校验失败返回结构化错误而非静默截断或置空。

3. 迁移路径要有隔离区。 违反约束的迁移数据进 quarantine 表而不是被静默接受，迁移报告输出「通过 / 拒绝 / 待修复」三列计数，把「回头再补」变成有数字、有截止日的工单。

4. 对 Agent 写入，叠加运行时门禁。 字段级写权限白名单、只读字段（如金额、审批状态）在 API 层硬拒绝、写入后异步跑一遍约束与异常检测、所有写操作带调用方身份进审计日志。上线前先在影子表做 dry-run，对比 Agent 产出与现有数据的分布差异。

对正在用平台的团队，有三件事现在就能做：

第一，盘点你的门。 列出所有写入路径，逐条确认校验覆盖情况——重点不是表单，是导入器和 API。旁路贡献了绝大多数脏数据。

第二，给导入路径的校验做一次默认开启的演练。 找一个测试环境把那个没人勾的复选框勾上，跑一遍存量数据。过不了关的记录数，就是你平台数据质量的真实水位。

第三，Agent 接入前先建门禁。 按上面第 4 条落地：白名单 + 硬拒绝字段 + 审计 + dry-run。这不是拖慢 Agent 落地，而是让它能活过第一个季度。

💡 小结

Lin 的 1914 张空供应商采购单，本质上是一份架构诊断报告：校验放错位置的平台，会亲手生产污染自己的数据，且随着入口增多和 AI Agent 加入，污染速度只会更快。Gartner 的数字说的是钱，HBR 的数字说的是面——脏数据的代价早已被量化，缺的从来不是理由，而是把约束从「界面的门锁」重构为「数据层的地基」的那一次架构决定。脏数据从来不是用户的错，是你平台的默认配置投的票。