切片地图 · 知识 ∩ 字段

S01 切片处于「双侧库存充足、对接为零」的起步状态：106 张卡片与 230 个候选字段均未做任何合入与确认匹配。知识侧高度集中在前端开户/KYC 流程的状态机与路由枚举，字段侧则集中在申请件编号、注册/审批时间、授信额度等后端落库结果，两者天然错层——卡片描述的是过程分支，字段记录的是终态快照。真正能对上的主要是「申请—审批—额度」这条主干，外呼名单与激活前的中间态大概率无字段可验。

▸ 先用「申请—审批—额度」主干（app_no / approval_datetime / credit_limit / is_open_apply）做第一批确认匹配打通口径，同时向前端与数据团队分别提出：补齐 OPEN_STATUS 状态码落库、拉取外呼名单与渠道漏斗的口径说明。

S02 支用与交易切片目前处于严重的知识—数据两侧失联状态：知识卡片高度集中在前端链路（路由分发、按钮态、勾选框、SDK 回传契约、cashState 枚举），而机筛出的 3593 个字段绝大多数是后端交易流水、征信报文与营销客群标签，两侧几乎不在同一层面对话。已合入知识仅 4 条、确认匹配仅 9 个，说明 255 张待审卡片里大量是前端实现细节，难以在数仓找到落点。切片核心资产——借据生成与借新还旧——在知识和字段两侧都近乎空白。

▸ 先做一次码值对齐：拉取 tm_trans_info_inbs / ca_txn_detl 等主交易表中 9012、9022 及 S/C 类型码的实际分布，用它锚定借据主表，再据此把 255 张待审卡片按'能落到字段'与'纯前端实现'分流，前者优先审入、后者降级归档。

S03 还款生命周期切片处于「知识与数据双向未对接」的起步状态：181 张待审卡片几乎全部来自前端/交易系统的还款交互与状态机口径，而 550 个机筛字段候选中大量是征信报文（CBI/SLIK/PEFINDO）、Vintage 统计与消息营销客群拆分字段，与本切片的出账→还款→逾期→清算主链路交集有限。核心账务链路（账单状态、还款计划、结清标志、逾期天数）两侧都有落点，但尚无一条确认匹配，口径映射尚未开始。

▸ 先做一次「核心账务链路」定向对齐：拿 acctStmtStatus↔stmt_status、结清标志、逾期天数、账期日期这四组做人工确认匹配，跑通映射方法后再批量审卡；同时把 Flex code 与提额/奖励两条链路作为埋点缺口提给数据团队。

S04 是典型的"知识超前于数据"切片：196 张卡片已把质押、杠杆、八源提额、Market code 毕业规则的口径写得相当细，但已合入知识 0 条、已确认匹配 0 个，说明卡片尚未过审、字段对齐工作还没真正启动。588 个机筛候选里绝大多数是通用授信额度表（credit_limit / use_limit / limit_adj_date）和支付侧 deposit 交易流水，与本切片核心的"额度纵向成长"语义只有关键词重合，真实可对应的比例偏低。当前最大风险是 Market code、杠杆率、提额渠道这些切片专属概念在数仓侧几乎看不到落点。

▸ 先做一轮 Market code / 杠杆率 / pledgeType 三个切片专属概念的定向字段勘探（跳出 588 个关键词候选，直接问业务系统库和埋点侧），同时推动 196 张卡片中质押与毕业规则相关的核心卡先行过审合入，让匹配工作有可锚定的基线。

S05 转分期与重组切片的知识侧已相当厚实——159 张待审卡片覆盖了 EXTENSION 全链路（准入 riskCode ZQ01、Flex code 位段、预付门槛、期数方案、减免维度、结果三态），但合入量为 0，知识尚未沉淀为可用资产。字段侧则几乎完全落空：17 个机筛候选中 15 个是 AppsFlyer 安装归因时间戳，与转分期业务毫无关系，仅 restructured_count 与 phase_of_contract 沾边，且来自 Pefindo 外部征信而非自有还款计划表。这是典型的"知识远跑在数据前面"的切片，机筛召回本身也基本失效（installment/install 的字符串误命中）。

▸ 暂停机筛扩量（当前召回被 install/installment 字符串误命中污染），改为由数据团队定向定位借据展期申请表、还款计划表（ZQ01 新借据）与 riskCode/Flex code 标签表三张核心表，同时优先合入 159 张卡片中的准入与状态机部分作为字段对齐基准。

S06 是典型的「两侧各自跑、中间没接上」状态：知识侧 21 张卡片高度集中在 C 端前端的逾期展示与罚息口径（isOverDue、STMT_STATUS、blockCode、0.3%/日），字段侧 97 个候选却几乎全是 csrecord_c3 催收作业表和 cindy vintage DPD 分档统计表——两者主题同为逾期，但层级完全错位，一个讲前端呈现规则，一个是后台催收作业与风险统计。已确认匹配 0 个不是遗漏，而是当前知识确实覆盖不到催收作业域，切片纵向链条（DPD 推进→三渠道催收→承诺/回收）只建成了最前端的一小段。

▸ 先把 csrecord_c3 催收作业表拉一次实际取值分布（audittp/auditstatus/reducestatus 的枚举与占比），据此向催收运营补齐工单状态机与 PTP 口径知识；同时向数据团队申请把账单主表（OVERDUE_DAYS/OVERDUE_TIMES/STMT_STATUS/PENALTY_*）和 blockCode 相关字段纳入本切片候选，否则已有的 21 张卡片永远无法闭环验证。

S07 处于「知识侧已成型、落地侧为零」的典型初建状态：48 张待审卡片已经把 blockCode 字符匹配语义、frozenState 映射、riskCode 标签体系讲得相当细，但 0 条合入、0 个确认匹配，知识尚未被任何字段验证过。128 个机筛候选中噪声占比很高——大量 coupon_writeoff / score_writeoff（卡券核销、评分核销）和 freeze_amt（资金冻结金额）字段是关键词误召，与账户级冻结处置无关。真正可用的骨架是散布在多个系统的 block_code 字段以及一张 blockCode 操作日志表。

▸ 先放弃 coupon/score_writeoff 与 freeze_amt 两类误召字段，集中人力把 dwd_acct_ty_base_block_code_op_log_day 打透——用它确认 blockCode 取值分布与变更事件枚举，即可一次性锚定 frozenState 映射、解冻闭环和 DPD30 不可逆冻结三大缺口。

S08 定价与费用切片处于典型的「双向未接通」状态：160 张待审卡片已经把 PL 两费结构（service fee 头息 + admin fee 月费）、取现砍头息 6%、罚息 0.3%/日、价格券降档等口径写得相当细，但合入知识 0 条、确认匹配 0 个，说明审核与对齐流程还没启动。数仓侧 615 个候选字段中大量是 penalty/fee/rate 的余额与已还金额列，费用「结果金额」层面覆盖较好，但费率配置、券折扣、头息拆分这些「定价规则输入」层面几乎无字段落点。当前瓶颈不在字段量，而在卡片评审与命名口径映射。

▸ 先做一次「费项主数据对齐」：把 service fee / admin fee / inst_handle_fee / penalty / late_charge 五个命名拉通成一张费项映射表，用它驱动 160 张卡片的批量评审与字段确认，同时向业务侧提出 flex_code 头息位段与券使用流水两处埋点需求。

S09 处于典型的「知识已成型、数据侧未接通」状态：61 张卡片已把 riskCode/Y001/marketCode 位段/beta·gamma 这套客群语义讲得相当细，但已合入 0 条、已确认匹配 0 个，说明尚未做过一次实质对表。821 个候选字段绝大多数是 Vintage/渠道口径的存量报表指标（cindy_setup_mob_vintage_*、vic_dd_rate_channel_*），与客群与角色主题只是关键词相关，真正带客群语义的落点只有 risk_code、app_customer_group、cust_group、experiment_group 等零星几支。切片当前的瓶颈不是知识量，而是缺少 marketCode 位段与 SegCode 在数仓的物理落点。

▸ 先向数据团队定点索取 market_code、seg_code、whitelist_flag 三支原始字段所在的表（很可能在未被机筛覆盖的用户主表/授信结果表里），一次性打通 marketCode 位段解析，这将同时解锁 beta/gamma 区分、毕业迁移和白名单三块验证。

S10 是典型的「数据洪流、知识真空」切片：827 个候选字段几乎全是 SLIK/Pefindo/CBI 上游报文的原始落库字段，而 5 张待审卡片全部是 KTP OCR 身份要素解析规则（TempatTglLahir 拆分、NIK、JenisKelamin 映射），与外部征信查询主题基本不重叠，已合入知识 0 条、已确认匹配 0 个。当前卡片池实际归属身份识别/OCR 切片，S10 的知识建设尚未真正起步。

▸ 先做切片归属清理——把这 5 张 KTP OCR 卡片转派给身份识别切片，再从 tm_cris_slik_ideb_info 的十余个风险汇总指标入手，让风控出一份「查询触发时机 + 指标时间窗口径 + 印尼监管术语对照表」的首批知识卡，用它去锚定 827 个字段中真正属于 S10 的核心子集。

S11 处于纯冷启动状态：116 张卡片全部待审、0 条知识合入、241 个候选字段 0 个确认匹配。更关键的是两侧存在结构性错位——知识卡片几乎全是前端会员态/Market code/价格券的展示与交互口径（Home.vue、memberCardState、marketCode 位段），而字段候选集中在后端权益领取流水、积分对账与营销权益指标（equity_claim_list、bonus_point、equity_cust_ind），二者描述的是权益链路的两端，天然难以直连。

▸ 先按「后端权益单据链路」拉通一条主线——请业务补 equity_type 码值表与权益领取状态机口径，同时请数据团队定位 market_code 原文字段与会员状态/到期时间字段，用这两条打通前端知识与后端字段的接缝，再批量审卡片。