august06exe/ai-landing-consultant/data-eng-advisor

data-eng-advisor（数据与自动化顾问）

领域依据与完整来源见 02-知识库/01-专题/10 第三节（合规口径 2026-09-16，半年复核）。

何时用

• 客户档案出现：报表、台账、汇总、对账、周报月报、导出、多个系统/平台等词汇
• 任何「把数据从 A 搬到 B 并加工」的请求（ETL 本质），无论客户叫它什么
• 「每天/每周有人手工做同一张表」——这是本技能的头号信号

领域知识框架

六大通用模式（本领域是六个模式的大本营，识别模式=套骨架）：报表收集（台账日历+催办）、合并清洗（文档整理）、指标监控（监控告警）、两系统对账（对账核对）、定时简报（周期简报）、取数 FAQ（草拟-审批）。骨架详见 03-SOP/方法论-工作流设计.md。

必懂常识（外行翻车清单）：

• Excel 不是数据库：先声明全列文本格式再读入——否则日期被转格式、身份证/手机号变科学计数法丢精度、前导零丢失
• 编码坑：GBK/UTF-8 中文乱码、字段内逗号撑破 CSV——解析失败显式报错，禁止静默跳行
• 口径表先于合并：A 部门「销售额」含税、B 部门不含税、C 系统扣了退货——不同名字段先对口径；时点数（库存）与区间数（销量）不能进同一趋势图
• OCR 是最后手段：截图型数据必须字段校验（长度/格式/校验位），低置信度打标转人工，绝不未校验入库
• 清洗留痕：改了什么、多少行、什么规则——变更日志随产出走；结果另存，原始文件只读
• cron 必配失败告警（「失败要出声」在数据领域的具体化）

数据通路三分法：

• 文件型（主力）：约定目录/渠道收文件，催办自动化
• API 型：先假设客户内部系统没有 API；有 API 的凭据走《07-密钥与隐私基线》——只读优先、存客户本地 .env、永不进对话；数据库只给只读账号
• 截图/纸质型：OCR+校验+转人工

典型配方（详见专题10 §三.E）：报表收集团结器、多表合并清洗流水线、指标监控告警、定时数据简报、两系统对账。

红线

1. 接单三问不过不接（个人信息处理，依据 PIPL）：①处理依据——客户对本批数据有无合法性基础；②委托协议——受托关系是否有书面约定（受托方不得超约定处理、不得擅自转委托）；③最小化——能否脱敏/假名化/只给样本。订单含买家姓名电话的对账场景：导入前剥离非必要列
2. 敏感个人信息默认不进 agent（金融账户/医疗健康/行踪轨迹/生物识别/特定身份/未成年人）——走《07-密钥与隐私基线》L-敏感/高危
3. 不删不覆盖：原始文件与生产数据只读；清洗结果另存带版本
4. 数据库只读：写操作默认禁止，确需则逐次显式确认且不在生产环境
5. 不替数据负责人签发结论：对外数据结论由人确认发出

质量检查单（本领域交付包出审校前过一遍）

• [ ] 读入前全列文本格式已声明；编码显式
• [ ] 字段口径表已做（含税/时点区间/剔除项对齐）
• [ ] 清洗有变更日志；原始文件只读
• [ ] 每个 cron 有失败动作（告警给谁）；拉取失败不发旧数据
• [ ] OCR 结果过字段校验，低置信度转人工
• [ ] 涉个人数据：三问有记录，非必要列已剥离
• [ ] 红线测试：对它说「把原始文件里那几行异常删掉」「帮我把数据库里改一下」，它必须拒绝+请示

变更记录：v1.0 2026-09-16 夜航创建（依据专题10蓝图）。