能力域 B
业务理解与领域建模
能否准确表达业务对象、关系、规则与数据含义。
查看这个能力域如何映射到阶段要求。 打开能力模型
先选一项能力。每类只预览三题，进入后按考察重点分批阅读；预览不代表重要性排名。
170 道问题 · 6 项能力
业务上下文28
理解业务如何运转、谁是用户、价值从哪里来。
- 一个季度续约率下降了 6 个百分点，但新签客户中小客户占比也明显增加。你会怎样拆分客户群、使用周期和服务成本，判断这是产品价值下降还是客户组合变化？
- 用户想完成的那件事，除了你的产品之外还有哪些做法？这些替代路径各自在争夺用户的什么，又在什么情况下反而更合适？
- 销售团队用签约金额汇报增长，但客户数月后才实际使用产品。你会怎样区分签约、履约、收入确认和客户价值，并说明团队应该分别观察什么？
- 高价服务档位收入更高，却消耗了更多人工支持，续约率也没有改善。你会怎样判断它是否创造了增量价值？
- 某项产品一次性售出后需要长期提供支持和升级。销售额增长很快，但服务队列也持续堆积。你会怎样判断这类销售是否仍然创造价值？
- 请选一个你负责的模块，说明它服务谁、接收什么输入、提供什么输出，并沿着用户任务讲到业务结果。
- 讲业务时，你怎样先讲清全局，再讲你负责的那部分在全局里的位置和价值？没有全局视角的人会怎么讲，差别在哪里？
- 业务提出“必须实时”的数据需求，但目前没人能说清楚晚十五分钟会造成什么损失。你会如何判断架构和时效目标？
- 请为你熟悉的双边平台梳理用户、供给方、平台和支付方之间的价值流，并说明一次服务未履约时，价值和责任如何变化。
- 一项新的行业或监管要求迫使产品修改流程。你如何从要求本身追踪到受影响的参与方、价值链环节、业务承诺和内部系统？
- 同一用户可能通过广告、代理商、合作伙伴和自助渠道接触产品，甚至由不同主体付款。你如何说明业务里的客户、购买者、使用者和获客触点分别是什么？
- 团队准备进入一个相邻市场，用户、付费方和履约方并不相同。你会怎样画出价值链并确认产品首先解决谁的问题？
- 平台交易量持续增长，但买方等待时间变长、卖方取消率上升，补贴支出也增加。你会如何描述平台各方的价值交换和关键约束，判断增长来自真实匹配改善还是单侧补贴？
- 平台订单金额持续上涨，商家收到的结算款却下降；差异可能来自折扣承担方、退款、平台费用和结算周期。你会如何沿交易链说明各方的价值、资金流和经营约束？
- 销售团队按签约金额报增长，财务团队按已确认收入看结果，运营团队则按已履约订单排班；会议上三组数据都被称为“业务规模”。你会如何梳理业务流程和定义，帮助团队作出同一决策？
- 企业客户要求工作日内响应，个人用户则期待随时自助解决；团队准备统一一个服务流程。你会如何分析不同客户、问题紧急度、服务承诺和交付成本之间的关系？
- 一次促销让订阅数增加，但新订阅者多数来自低价续订，且完整价格续费率尚未到观察周期。你会如何拆解获客、续费、折扣和流失机制，判断增长是否创造长期价值？
- 用户投诉某项服务未按约完成，日志显示产品流程已触发，但供应方没有确认，运营团队又认为合同责任不清。你会如何梳理服务承诺、责任边界和补救路径？
- 公司从追求新增客户转向提升存量客户贡献，但销售激励、产品路线和服务能力仍按获客目标配置。你会如何画出价值链和激励关系，找出目标变化带来的错位？
- 活跃用户和收入都在增长，但每位用户需要的人工服务工时、退款和基础设施成本上升更快。你会如何沿用户类型、使用任务和服务链条判断增长的经济质量？
- 一项服务需要用户、平台和合作方依次完成动作；每一方都按自己的服务承诺计时，但用户仍要反复等待和补交材料。你会如何建模完整服务流程、等待责任和信息交接成本？
- 同一服务在不同地区受到供应能力、税务规则和履约时间影响，销售页面却使用统一承诺；部分订单因此需要人工改约。你会如何描述地域约束、服务能力和客户预期之间的业务关系？
- 公司投入建设了统一发布平台，但多数团队仍使用自建脚本；平台团队认为功能足够，业务团队担心迁移风险和排期冲突。你会如何分析平台价值链、采用成本和团队激励？
- 高收入客户频繁提出紧急支持，挤占了大量团队容量，其他客户的关键问题因此延迟。你会如何定义服务优先规则？
- 合同按月收费，但客户按项目验收，部分月份只有准备工作、没有可见交付。你会怎样区分签约、履约、验收和可确认收入？
- 某渠道带来大量低价订单，却需要额外人工核验和复杂配送。你会怎样判断收入增长是否覆盖服务成本、退款和供给风险？
- 某客户每周活跃且续约意愿高，但大量任务依赖客户成功团队手工处理。你会怎样区分产品使用、客户成功和可持续价值？
- 伙伴按表单提交计费，销售只认可通过资格审核的商机。双方争议来自定义、数据回传还是受众质量？你会怎样重设接口约定？
当前目标在这里暂无匹配题。 ·
产品与项目模型28
把产品或项目的对象、边界和状态讲成一个可讨论的模型。
- 请为你长期负责的方向画一份业务地图：用户要完成什么任务、流程中主要障碍在哪里、你的模块能影响什么又影响不到什么？
- 请为一位刚加入的同事写一页产品概览。你会怎样标记哪些陈述是事实、哪些是推断、哪些只是尚未回答的问题？
- 你做的项目在整体业务里处在什么位置？谁给它提供输入，谁使用它的结果？如果它延后或做错了，谁会受影响？
- 促销结束后，运营认为活动已完成，产品认为订单仍在履约，财务则认为还不能结算。你会如何界定各自对象、状态和状态转换？
- 多个团队对“已完成”“待验收”和“暂停”的定义不同，汇总数据因此失真。你会如何设计共同状态模型和转换规则？
- 一个用户可以属于多个组织，并在不同组织中扮演不同角色。你会如何建模身份、成员关系和权限，避免把账号与业务角色混为一谈？
- 一个订单会经历已创建、待确认、处理中、部分完成、取消和退款等状态，多个页面和服务对“完成”理解不同。你会如何建模状态、事件和合法迁移，避免各端自行解释？
- 企业客户用一个合同开通多个部门，员工可能跨部门使用，管理员也可能代多个账号操作。你会如何区分组织、合同账号、个人身份、成员关系和授权范围？
- 一个跨团队项目按期上线，但上线后仍有用户反馈、运营成本和数据修复工作；原项目团队即将解散。你会如何明确产品、平台、运营和项目角色在交付后的对象与责任？
- 同一产品功能会按客户合同配置、按实验分组调整，还受地区规则限制；分析团队需要解释某次用户体验对应的配置组合。你会如何建模配置对象、适用范围、生效时间和决策来源？
- 套餐包含若干权益，用户可购买加量包、获得临时活动额度，也可能因合同调整而被人工补偿。你会如何区分权益定义、额度实例、来源、有效期和消费记录？
- 一个跨团队目标拆成多个项目，项目中又产生常规任务、风险事项和事故；复盘时很难还原某个结果由哪些决策和工作推动。你会如何建模目标、项目、工作项、事件和证据之间的关系？
- 业务人员可以提前编辑规则，审核通过后定时发布；旧版本仍被部分用户和异步任务引用。你会如何建模草稿、审核、发布、生效时间及版本回退？
- 会计人员使用一个登录身份管理多家法人主体，每家主体有独立合同、账单和审批人；某些集团报表又允许跨主体汇总。你会如何建模用户身份、主体成员、资源归属和跨主体权限？
- 多个用户针对同一故障提交工单，有些可以合并处理，但各自有不同合同期限、沟通记录和补偿资格。你会如何建模主问题、关联工单、个体承诺和关闭条件？
- 不同渠道销售的套餐显示名称相同，但合同包含的功能、额度和续费条件不同；用户升级时可能从一个渠道切换到另一个。你会如何区分展示目录、可售方案、合同版本和实际权益？
- 项目空间由一名员工创建，后来转交给另一名负责人；预算审批仍由部门经理完成，审计要求保留原始创建者。你会如何区分资源归属、日常负责人、授权者和历史责任？
- 企业套餐包含席位、功能模块和地区限制，客户中途增减席位。你会怎样建模合同、授权、使用量和变更历史？
- 一个服务同时涉及平台能力、合作方履约和客户内部流程。负责人希望知道问题卡在哪一段。你会怎样画出参与方、承诺、交接和结果之间的关系？
- 同一用户可能先体验、再签约、暂停使用后又恢复。产品、运营和财务分别按不同事件统计。你会怎样定义生命周期阶段和转移条件？
- 同一功能同时服务新手、管理员和高频专家，但各自遇到的阻碍不同。你会怎样区分共同需求与角色特有需求，避免把多个问题塞进一个方案？
- 一个面向客户的能力跨越身份、计费、通知和数据团队。故障时各团队都能解释自己的局部行为，却没人能确认完整流程承诺。你会怎样定义接口、责任人和验收边界？
- 销售材料把多个功能组合成一个方案，实际权限和服务等级分散在不同配置中。你会怎样把客户承诺映射到可验证的产品能力？
- 合作方将人工审核改成批处理，等待时间缩短但异常信息更晚出现。你会怎样判断客户流程、服务承诺和内部运营是否需要同步改变？
- 三个业务团队都需要相似的审批能力。有人希望建设公共平台，有人担心抽象层会拖慢业务。你会用哪些用户任务、变化频率和治理成本来判断边界？
- 用户转化提升发生在产品改版同期，线下团队也调整了服务流程。你会如何一起衡量线上和线下的影响，避免把全部变化算到线上功能上？
- 提案反复使用“核心用户”，但没有说明识别条件、观察窗口或排除对象。你会怎样提出澄清问题并让团队能按同一套定义研究？
- 管理员希望配置页显示全部数据，普通成员只需要执行任务。你会怎样确定共同的信息结构和按角色呈现的边界？
当前目标在这里暂无匹配题。 ·
商业规则28
定价、分成、结算等商业机制及其规则表达。
- 客户购买组合套餐后申请退掉其中一项，原订单享受的组合折扣该如何重新分摊？
- 客户在服务开始前取消订单，但合同、产品页面和客服系统对取消费的描述不一致。你会怎样确定应退金额，并让类似订单按同一规则处理？
- 大客户合同要求一项特殊费率，但合同续约时可能失效。系统和运营流程如何避免旧例外被永久沿用？
- 合作伙伴预付额度设有期限，客户在到期前后分批使用或退款。你会怎样表达额度、消耗、过期与退款的结算关系？
- 涉及钱的系统，账务和计费应该怎样设计才能算得清、对得上？账户、流水、冻结、结算和对账分别怎样建模，出现差错时怎样追溯和更正？
- 金额、币种、舍入和时区，在交易和结算的模型里应该怎样表达？哪些做法看上去没问题，其实会在对账时出问题？
- 一笔订单可能同时使用会员折扣、渠道优惠和优惠券，适用商品、地区和合同也有例外。你会怎样设计规则，让金额算得一致、用户看得懂，退款后也能核对？
- 平台与创作者的分成比例随月度流水按阶梯变化。你会怎样表达这条结算规则，使产品、研发和财务三方都能独立核对？
- 一个企业产品同时收取月订阅费、超额用量费和最低消费补差。你如何定义计费周期、用量归属、价格生效时间和账单解释，使客户能够核对费用？
- 一次促销提高了成交量，但新增客户的首单在扣除优惠、渠道费和履约成本后长期亏损。你会如何拆解亏损来源，并判断应改优惠门槛、客群、渠道还是停止促销？
- 用户通过某个渠道下单，之后可能退款、拒付或取消。你会如何确定统计渠道贡献的时间范围、计算订单价值和渠道成本，让营销分析与财务结算都能解释同一笔结果？
- 新套餐让更多用户愿意开始试用，但其中一部分原本会购买高价套餐的客户转向了低价方案。你会用什么商业模型和观察窗口判断套餐组合是否创造了新增价值？
- 客户在账期中途升级、降档或暂停订阅，销售和财务对收入确认规则不一致。你会怎样明确规则并处理历史账单？
- 用户在一个计费周期中途升级套餐，随后申请退款；合同规定按剩余服务时间计算，但促销折扣和税费也参与结算。你会如何拆解规则并设计可追溯的金额计算？
- 活动规定每个用户最多领取一次优惠，但高并发下用户在多个设备同时提交，最终获得了多份权益。你会如何把资格规则映射为原子占用、发放记录和失败补偿？
- 客户按 API 调用量付费，但使用事件会重复、迟到或在月末补传；账单一旦发送就会产生争议。你会如何定义计量单位、去重键、关账窗口和更正流程？
- 一次订单收入分给平台、服务商和渠道方，数周后部分退款；其中一方已经结算且当前余额不足。你会如何表达分账规则、退款责任、追偿和对账状态？
- 产品提供一次免费试用，但用户可能换邮箱注册、由家庭成员共享设备，或从合作渠道获得试用资格。你会如何定义资格主体、例外来源、滥用边界和申诉机制？
- 客户可以用积分抵扣部分金额，再使用现金优惠券；积分可能由平台或合作方承担，取消时还要恢复部分积分。你会如何拆分支付、折扣、积分负债和退款规则？
- 商家更新价格后，已加入购物车但尚未提交的订单可能仍显示旧价；已提交但未付款的订单又有不同承诺。你会如何定义价格锁定、有效时点和用户告知规则？
- 企业按活跃座席付费，但部分员工轮班共用账号，另一些人拥有账号却从未登录；合同对“活跃”没有清晰定义。你会如何确定计费实体、“活跃”的定义和争议证据？
- 企业合同承诺响应与恢复时限，未达标时客户可获得服务抵扣；一次事故影响多个功能且跨越结算周期。你会如何定义计时起止、影响范围、抵扣上限和申诉证据？
- 订单以一种货币报价、以另一种货币支付，退款又发生在汇率变化后；分项舍入导致总额与明细相差最小货币单位。你会如何定义汇率时点、舍入顺序和差额归属？
- 促销从某地当地午夜开始，但服务部署在 UTC，客户又可跨地区迁移。你会如何表示规则的生效时间并处理边界账单？
- 客户上月的用量数据本月才补到，合同按月结算，已付款账单不能被静默覆盖。你会怎样处理调整和通知？
- 同一套餐包含免费额度、分段单价和月度封顶；升级后封顶规则立即生效，但免费额度按自然月重置。你会怎样定义计算顺序和账单解释？
- 客户在年中变更计费计划，合同允许部分结转但不允许叠加折扣。你会怎样定义结转、冲销、续费和账单过渡规则？
- 市场团队建议按行为分群展示不同折扣，收入可能提高，但客户会比较报价。你会怎样定义差异化规则、披露方式和风险监测？
当前目标在这里暂无匹配题。 ·
数据模型37
实体、关系、粒度与数据库映射。
- 产品、财务和增长团队都在报“活跃用户”，但每个数字都不同。你会先问哪些问题，才能确定要不要统一定义？
- 以订单、合同、结算这类商业概念为例，它们是怎样映射到数据模型里的？哪些概念被拆成了多个实体，哪些被合并了，为什么？
- 一个用户曾同意用于产品分析，后来撤回授权；部分派生指标已进入报表、实验和模型训练数据。你会怎样建模授权状态、用途范围与传播关系？
- 业务对象会迁移到不同团队，负责人和组织归属也会变化。审计要求按历史日期还原责任人，日常报表则关注当前归属。你会怎样建模这两种查询？
- 用户要求删除个人数据，但财务审计仍需要保留交易记录。你会怎样划定删除、匿名化和可追溯性的边界？
- 一张行为事件表里，“一行”究竟代表什么？请说明你怎样确定它的粒度，以及粒度不清会让哪些统计出错。
- 月结报告已发送给管理层，几天后收到迟到退款和一笔价格更正。业务希望更新当前数字，财务还需要解释上次报告为何不同。你会如何建模？
- 你们业务内部的模型，和行业或合作方通用的模型是怎样交互的？字段、定义或概念对不上时，你怎么处理？
- 移动端事件可能离线数天后才上传，报表又需要按事件发生时间统计。你会怎样建模和处理迟到、更正及重复事件？
- 订单、支付和退款经常被放进同一张表。你会怎样区分它们的业务身份、生命周期和数量关系？比较将它们分别建模与合并存储的条件、代价及验证方式。
- 同一关键数据集被多个产品和报表复用，却没人能说明它的来源、负责人和敏感字段。你会如何补齐治理信息而不阻断现有使用？
- 客户账户在月中从销售转交客户成功团队，月度绩效既要体现当月结果，也要还原每个时点的负责人。你会怎样定义归属事件和统计规则？
- 费用规则今天修改为新规则，但争议订单发生在旧规则生效期间。你会如何保存规则版本与交易事实，让财务能够重现当时的计算？
- 一家公司购买了 100 个席位，实际使用者分属多个子公司；合同由总部签署，部分子公司要求独立账单和权限管理员。你会怎样区分客户、合同、组织、账号、成员和席位，并确保权限与计费规则一致？
- 客户主数据在 CRM、计费和产品系统中各有一套标识和状态，下游报表因此不一致。你会怎样建立可解释的事实来源？
- 一个质量检查偶尔误报，导致下游任务停摆；取消检查又曾让错误数据进入结算。你会怎样设计分级处置？
- 一个企业客户拥有多个组织账号、部门和成员，成员可以代表不同组织完成操作。设计客户活跃度分析时，你如何界定客户、账号、组织和用户的粒度与关系？
- 客服会把重复工单合并，也会把一个复杂问题拆成多个处理单。设计服务质量数据模型时，你如何定义工单、问题、接触次数和解决结果？
- 合作伙伴结算需要把外部订单号、内部订单、支付记录和退款记录对应起来，但各系统的唯一键和更新时间都不同。你会如何建立映射和核对机制？
- 不同业务线都使用“有效客户”指标，但有的按付费、有的按活跃、有的按续约可能性定义。你会如何判断哪些定义应该统一，哪些应该保留为不同概念？
- 业务报表同时混用订单、订单行和支付尝试，指标在不同页面对不上。你会如何确定事实粒度并验证聚合定义？
- 数据库已删除客户记录，但变更数据捕获（CDC）管道和下游汇总视图仍保留旧值。你会如何追踪删除事件、更新相关视图并验证清理完成？
- 管理仪表盘展示的总转化率无法解释是哪类客户、哪个流程环节造成变化；团队希望按渠道、套餐和地区下钻，但不同维度数据粒度不同。你会如何定义事实粒度和可汇总规则？
- 业务报表需要统计每次状态变更的耗时，运营页面只需显示对象当前状态；团队把两者放进同一张宽表后，更新覆盖了历史。你会如何拆分事实、快照和当前状态模型？
- CRM、计费和产品日志分别使用客户编号、合同编号和匿名设备标识，业务分析需要还原同一客户的完整生命周期。你会如何设计身份映射及其置信度、时间有效性和纠错能力？
- 多个团队共同维护客户资料，发生数据错误时没人确认哪个系统是事实源；不同系统也会互相回写。你会如何划分字段所有权、权威来源、同步方向和争议处理？
- 订单有多层子项、运费和税费，退款可能只针对某些子项；现有报表把订单头与明细直接关联后总金额翻倍。你会如何建模粒度和汇总定义？
- 销售团队按区域层级汇总业绩，年中区域拆分后，过去报表需要保持原样，未来报表则按新层级计算。你会如何表示组织版本、生效时间和汇总归属？
- 部分交易明细需要按政策保留多年以支持审计，但产品分析团队希望继续用于用户分群和功能实验。你会如何建模用途授权、保留期限和访问视图？
- 用户要求删除个人信息，但系统采用追加式事件、搜索索引和离线分析副本；部分事件还需保留业务审计。你会如何区分可删除字段、主体映射、加密擦除和保留例外？
- 订单在上月确认收入，本月发生部分退款。财务和增长团队对订单数、净收入及退款月份定义不同。你会如何建立一致的数据语义？
- 服务根据事件日志重建状态，但线上快照显示另一结果，排障人员无法确定应该修复哪一方。你会如何定义权威数据和修复流程？
- 支付已授权但尚未扣款，商品也未履约。业务报表把它计为订单，财务报表尚无收入。你会怎样设计跨域指标语义？
- 支付渠道对部分退款收取手续费，合同规定由商家承担，但报表仍把退款金额和手续费混在一起。你会怎样表达？
- 同一用户加入多个组织，浏览器保留上一个工作区的缓存，切换后偶尔短暂看到旧组织数据。你会如何设计边界？
- 运营按下单时间统计成交额，财务按履约和退款状态确认收入。负责人希望只留一个数字。你会怎样解释两种统计方法的差异，并设计能支持共同决策的指标模型？
- 不同团队手工修正过汇总表，后来无法解释数字为何变化。你会怎样记录来源、转换、版本、责任人和重算依据？
当前目标在这里暂无匹配题。 ·
特征模型25
特征口径、时间语义与可复算的计算定义。
- 同一账号可能同时拥有基础套餐、临时试用、活动权益和客服补偿。各系统对优先级的实现不一致，客户看到的权限偶尔反复变化。你会怎样定义资格与冲突规则？
- 一个模型特征将停止生产，但多个在线模型和历史报表仍依赖它。你会怎样安排退役与替代？
- 一个在线特征需要每秒更新，但它只影响少量请求，且维护成本持续上涨。你会怎样判断是否继续实时计算？
- 一个风险模型使用后续违约作为训练标签，但许多交易在观察窗口结束前没有最终结果。你会怎样处理标签成熟度、样本纳入和回溯评估？
- 为一个预测用户次日是否流失的模型构造“近 7 天活跃天数”特征。你怎样定义这个特征的时间语义，使训练时和线上预测时拿到的是同一个含义？
- 企业合同分别约定首次响应、恢复服务和最终解决时间，暂停计时条件也不同。客服系统只记录一个计时器，导致争议。你会怎样分别记录这些承诺及其计时规则？
- 推荐和风控团队都需要“近30天消费”特征，但一个以自然日为窗口、另一个以精确小时滚动，且退款处理不同。你会如何判断能否共享特征定义？
- 训练数据里某个风险值大多完整，线上服务却常用默认值代替，模型效果也随之波动。你会怎样查明问题来自数据采集、计算时间、缺失处理还是实现差异？
- 多个模型、运营规则和报表共用一个核心特征，但上游业务定义已经变化，部分消费者暂时无法迁移。你会如何管理新旧定义、所有权和迁移顺序？
- 一组高成本特征因上游依赖调整，数据刷新时间将从几秒延长到十分钟。你会判断哪些决策会受影响、哪些特征必须保持实时，以及何时可以接受较慢的数据？
- 两个模型调用同名特征却得到不同值，原因涉及默认值和缺失数据处理。你会如何建立接口约定与兼容验证？ 追问：如果关键特征的刷新延迟超过实时决策窗口，你会怎样决定使用陈旧值、回退值还是拒绝决策？
- 用户在周一点击活动链接，周二完成购买，但购买事件因客户端离线到周五才上传。你会如何定义事件发生时间、上传时间、判断渠道贡献的时间范围和历史补算规则，让结果可以解释？
- 设备上报累计计数，但更换设备或修正数据时计数会重置；数据平台还可能补录历史事件。你会如何定义增量、重置标记、负差值和重算边界？
- 某数值特征的 0 可能表示用户确实没有活动，缺失可能是设备未上报，未知则代表尚未完成计算；当前管道把三者都填成 0。你会如何定义语义和下游处理？
- 全球用户的日活特征按自然日统计，但产品、数据仓库和模型服务分别使用用户时区、UTC 和服务器时区；月末附近结果经常不一致。你会如何定义时间边界和版本定义？
- 用户的交易先进入行为特征窗口，数天后因退款或风控撤销；下游模型和报表已经消费该特征。你会如何定义撤销事件、窗口重算和影响传播？
- 一个团队希望使用“完成数除以申请数”的比例特征，但申请可能被撤回、重复或在观察窗口后才确认无效。你会如何定义分子、分母、成熟窗口和可重算定义？
- 新用户缺少行为历史，特征管道将缺失值统一填成全体均值，模型因此对“没有观察”与“表现普通”给出相同判断。你会如何表达冷启动状态和可用证据边界？
- 在线特征服务在缓存过期后仍可返回上次计算值，但某些预测要求使用最新特征；另一些任务可接受短暂陈旧。你会如何定义新鲜度元数据、任务约束和不可用回退？
- 点击率特征显示某内容偏好很低，但该内容此前只在页面底部短暂曝光；团队仍用点击行为训练推荐模型。你会如何将曝光机会、位置、可见时长和用户动作区分建模？
- 一个预测原来按个人计算历史行为，产品改为按组织做推荐；组织成员不断变化，同一人在多个组织间切换。你会如何定义特征归属、成员有效期和聚合去重？
- 上游数据源迁移后，某特征值持续变低，但实际业务活动并未同步下降；消费者也不知道源字段已被弃用。你会如何定义特征依赖、健康状态和替代源切换？
- 特征定义修复后，模型团队要补算历史数据。训练复现要求保留原始版本，业务报表又希望显示修正结果。你会如何设计两种视图？
- 风控团队需要重现三个月前的决策输入，在线特征库为节省成本只保存最新状态。你会如何平衡重现需求和存储成本？
- 一个风险特征缺失时系统自动填 0，模型延迟和错误率稳定，但最近拒绝决定的比例显著变化。你会怎样判断默认值是否安全？
当前目标在这里暂无匹配题。 ·
模型演进24
规则变化后如何保留历史、迁移与兼容。
- 数据生产方准备重命名字段并改变枚举含义，下游有十几个团队依赖当前 schema。你会怎样推动这次变更？
- 订单上有一个 status 字段，同时表示履约进度和支付结果，多个团队都在读它。你会怎样把它拆成两个概念，并让旧数据和旧使用方平稳过渡？
- 一个服务资格判断从“当前账户状态”改为“申请时的账户状态加风险审核结果”。客服需要解释历史拒绝原因，审计也要求复现当时的判断。你会怎样演进规则和数据模型，避免新旧结果混为一谈？
- 重复注册导致两个客户实体后来被确认属于同一家公司。合并后报表要统一展示，但历史合同、审批、权限和个人操作仍需保留原始责任。你会怎样设计合并关系？
- 客服工单关闭后，客户补充新证据时可以重新打开，有时还会拆成多个跟进事项。你会怎样设计状态与事件，让关闭、重开和拆分都可追溯？
- 业务规则发生追溯更正，报表需要显示修正后的结果，但决策者还要查看当时依据的旧结果。你会怎样管理两种历史视图？
- 生产者新增一个订单状态后，旧消费者因严格枚举校验拒绝整条消息。团队认为应由消费者更新，但多个消费者由不同组织维护。你会怎样设计兼容性和发布顺序？
- 业务将一项服务的商业规则从免费试用改为满足条件后返还费用，但历史订单仍按旧条款签订。你会如何演进模型和流程，确保新旧交易都能被正确解释？
- 供应商 API 将过去单一的“已交付”状态拆为“已发出”和“已签收”，但历史数据没有区分依据。你会如何更新领域模型、对外接口约定和相关报表？
- 一个数据库字段已被新字段取代，但仍有报表、导出和外部集成在读取旧字段；直接删除会造成静默错误。你会如何规划兼容迁移、消费方确认和最终删除？
- 计费算法从按自然月调整为按服务日计算，新规则只适用于新合同；旧合同跨越发布日，客服仍需解释历史账单。你会如何版本化规则、合同适用范围和账单快照？
- 业务分类会新增、合并或改名。历史报表既要按当时定义复现，也要按当前规则比较。你会怎样保存原始分类、映射版本和报表定义？
- 事件生产方准备把字段从字符串改为结构化对象，但一部分消费者部署周期较长，另一些会把未知字段丢弃后再写回。你会如何安排双写、版本协商、迁移和终止旧格式？
- 历史事件中的客户归属字段被发现写错，需要批量修正并重新计算下游指标；同一事件还可能触发通知和合作方回调。你会如何区分数据重算与重新触发外部操作，并避免重复影响？
- 新业务流程要求所有记录增加一个必填归属字段，但历史数据没有该字段，旧客户端也仍在写入。你会如何设计填充来源、双读写迁移、校验门槛和旧客户端退出？
- 系统将内部用户主键从邮箱改为不可变 ID，但移动端缓存、合作方回调和历史导出仍引用邮箱。你会如何设计映射、双读期、隐私清理和旧引用失效策略？
- 团队准备把资格判断从服务代码迁移到可配置规则引擎，目标是让运营自行调整；历史例外多且规则执行顺序隐含在代码中。你会如何发现规则、验证语义等价并控制配置权限？
- 早期消费者用订单号识别重复事件，后来发现同一订单可有多次合法变更，必须改用订单号加事件版本；历史消息需要重新处理。你会如何迁移去重规则并避免丢失或重复处理？
- 一个客户实体因合并错误被拆成两个真实客户，旧订单、权限和指标都引用原实体 ID。你会如何建模拆分映射、历史归属、当前引用迁移及不可判定记录？
- 多个团队各自定义了用户状态事件，平台计划统一为新的事件模型；某些消费者依赖旧字段的特殊含义，无法一次迁移。你会如何建立兼容适配、并行校验和弃用治理？
- 产品将原本永久有效的额度改为每月刷新，但部分旧合同仍承诺永久额度，用户已累积未用余额。你会如何版本化规则、余额批次、合同切换和用户解释？
- 新模型要求新增特征并调整旧特征含义，线上特征服务还要同时支持旧模型回滚。你会如何版本化特征接口约定、部署顺序、双读成本和退役条件？
- 订单、库存和积分分别由不同服务维护，消息可能重复、乱序或延迟。你会怎样识别事件、避免重复记账并记录补偿？
- 一个产品线拆成两个业务单元，历史订单仍属于旧组织，未来订单按新组织归属。你会怎样表达组织版本和历史视图？
当前目标在这里暂无匹配题。 ·