数据接入治理系统开发
多源取数、清洗归一、质量闸门、血缘登记做成一条可重跑的工序线。判定口径（字典、权重、阈值）由客户在治理后台维护，系统只负责按口径执行并留痕。
看九道工序 →
工序
数据怎么处理
把治理拆成有先后、有交接物的九道工序。每道工序都留痕，出问题能定位到是哪一道判错了，而不是只能笼统说「数据质量不行」。
九道工序
取数
按客户在系统里配置的源清单发起请求，遵守各源的频率与并发限制，不做超出配置范围的访问。
存底稿
原始响应先原样落盘存档。后续所有处理都从底稿出发，底稿本身不被改写——这样任何一次判定都能回到原文复核。
解析清洗
结构化解析、去噪、去重。解析失败与格式异常的样本单独留存，不静默丢弃。
实体归一
把指向同一对象的不同写法合并为单一实体，消除同物异名与同名异物。归一规则由客户维护。
语义对齐
把不同来源的字段口径对到客户定义的术语上，使跨源数据可以放在同一张表里比较。
归类入表
按客户的分类维度落到对应结构，分类依据与命中的规则编号一并记录。
质量闸门
不达阈值的不放行，退回并登记不通过的原因与条目。闸门是硬拦截，不是提示。
入库
通过闸门才写入正式库。写入动作本身可追溯：谁触发、依据哪一批底稿、哪一版规则。
血缘登记
登记来源、处理链路与判定依据，串起前面八道工序，使每条数据都能回答它从哪来、经过哪几道处理、为什么被判为可信。
本页只讲方法框架。质量评分公式与权重、术语字典、来源可信度分级、实体归一规则均属客户专有内容，不在公开页面展示。这些口径归客户定义，我们负责把它们变成可执行、可复算、可审计的系统。
分工
哪一段交给代码，哪一段交给模型，哪一段必须客户拍板
治理系统里混着三种性质的工作，用错了地方就会出事：确定性的活交给模型会漂，判定口径交给我们会失控。所以先把三者的边界写清楚。
| 承担方 | 负责哪些环节 | 受什么约束 |
|---|---|---|
| 代码 | 抓取、去重、归一、查表、打分、入库、血缘登记。 | 都是确定性的部分：同样的输入得到同样的输出，可重跑、可复现、可逐条对账。 |
| 大模型 | 非结构化内容的抽取，以及初稿生成。 | 每一处输出都带代码校验或人工确认，不直接入库。模型给的是候选，不是结论。 |
| 客户 | 把关字典、权重、阈值，以及裁决与终审。 | 什么算可信由客户定义。我们不代客户设口径，也不把口径藏进代码里让人看不见。 |
这张表在项目启动时就要逐格确认。它决定了后面出现分歧时找谁——是代码逻辑错了、模型抽错了、还是口径本身需要客户重新裁决。
集成
接得通不等于接得住
联调环境跑通一次很容易，难的是生产环境里那些不常发生但一定会发生的分支：回调丢了、签名对不上、请求被风控挡住。
云服务的生产接入
把云服务从「能调用」推到「能上生产」，缺的通常不是接口文档，而是鉴权链路与失败兜底。我们按生产口径逐项做完，并留下可查的日志。
对超时未回调的任务设定时对账，是为了避免业务状态长期停在中间态——这类问题不报错，只会让数据慢慢对不上。
- 视频点播：上传凭证签发、播放鉴权、回调签名校验。
- 视频点播：对超时未回调的任务跑定时对账，补齐状态。
- 短信：正式通道开关与配置分离，验证码防刷加固。
- 短信：发送与回调日志留存，可按业务单据回溯。
- 对象存储：签名 URL 访问，不向前端暴露长期凭据。
信源可行性实测与一手取证
接入前先用真实浏览器对每个源做多轮探活，逐源判定：可直接订阅、需要额外连接器、还是不可用。判定结果连同实测记录一并交付，客户据此决定接哪些、放弃哪些。
重点是把探测器伪像识别出来——有些源看起来握手成功、状态码正常，实际取不到内容。这类源若按「可用」计入，后面整条工序线都会建在空数据上。
- 多轮探活，避免单次波动被当成结论。
- 三态判定：可直订 / 需连接器 / 不可用，逐源给理由。
- 识别探测器伪像：能连通但取不到内容的源不计入可用。
- 政府与监管网站的一手原文取证：常规 HTTP 客户端取不到时，改用无头浏览器直连落盘存档。
- 取不到的如实登记为未取得，不用二手转述顶替。
在研方案
AI 智能体访问生产数据的安全治理
当智能体需要读生产库时，靠提示词约束是不够的——约束必须落在数据库权限与网关上，才拦得住。
本节为方案与原型阶段，尚未落地实现。下面描述的是设计思路，不是可交付能力承诺，也没有生产运行记录。写在这里是为了说明我们对这个问题的判断，请不要据此作为选型依据。
四层设计（方案阶段）
数据库侧列级授权与脱敏视图作地基
权限收在数据库这一层：智能体连的是脱敏视图，看不到的列在数据库就取不到，而不是靠上层代码过滤。
只读语法校验网关做收敛与审计
所有查询过网关，先做语法校验再放行，非只读语句直接拒绝；放行与拒绝都记账，便于事后复核。
写操作走人工审批
需要写库的动作不由智能体自行决定，转为待审批工单，由人确认后执行。
限时明文授权
确需看明文时按次授权、到点自动回收，而不是长期开放一个高权限账号。
合规
数据采集合规与责任划分
这一节本来常被放在合同附件里，我们把它前置到官网。理由很直接：责任归属要在签约前谈清楚，避免到了验收环节才争议。
责任边界：数据源选择、抓取发起与数据使用，由客户配置并负责；我们交付的是工具与平台能力。系统运行在客户环境中，接哪些源、以什么频率取、取到的数据怎么用，都是客户在治理后台做出的配置决定。我们负责这套工具本身合规可控，并把上述约束做成系统的默认行为。
系统内置的采集约束
- 只采集公开内容。
- 遵守 robots 协议，遵守目标站点的频率与并发限制。
- 防护服务端请求伪造（SSRF），限制可被访问的目标范围。
- 不绕过验证码，不绕过平台风控。
- 敏感数据走官方授权渠道获取，不用旁路手段替代。
我们不承接的部分
- 不代客户决定采集哪些源，也不代为发起采集。
- 不提供绕过访问控制、登录态或风控的技术手段。
- 不把「数据处理与存储」作为单独售卖的服务——本公司经营范围不含该项，这条线的交付标的是软件开发。
- 不对客户的数据使用方式做合规背书，该判断归客户及其法务。