用户问题与业务价值还原

• 区分"时间上紧急"与"业务上重要"的差异
• 用事实和业务价值来验证紧急性的能力
• 不盲从、敢于质疑的沟通方式

我会先问三个问题：这个需求影响的用户规模或营收规模是多少？如果不做，今天会发生什么样的可量化损失（如羊毛党套利、事故、监管处罚）？有没有一个明确的"截止事件"（如活动开始、合规截止日）驱动它？如果 PM 答不上来或只是"老板说要"，我会把紧急度拆成"业务价值"和"时间窗口"两个维度，判断它是否真的值得抢占今天其他任务。若经过验证它确实有业务价值且时间窗口真实，我接受并尽快排期；若只是"感觉急"，我会和 PM 对齐真实优先级，避免把"急"当"重要"。

研发最容易犯的错误是"PM 说急了就加班赶"，结果熬夜做出来的功能其实没人用也没损失。真正的紧急必须能落到可量化的业务损失或硬性截止时间上，用这两个维度去评估，既尊重 PM 又守住排期秩序。

• 主动澄清关键信息的能力
• 把"紧急"转化为可执行时间点的推动方法
• 用"影响范围"倒推时间的技巧

我会先用"倒推法"把 deadline 问清楚：需求最好的上线时间是什么？如果不能在最佳时间上线，最晚能接受的时间是什么？这个最晚时间由什么业务事件驱动（如活动、合规、竞品节奏）？我会主动提出"我按优先度评估，需要你明确 commit 时间，否则我无法排定优先级"，并给 PM 一个时间确认的格式（如"请在 X 前回复，否则默认按 P2 处理"）。通过把模糊的"紧急"翻译成具体的"最晚可接受上线时间 + 理由"，推动 PM 给出可执行 deadline。

没有 deadline 的"紧急"是伪紧急，会让研发被动加班。用倒推法把时间锚定到业务事件上，让 PM 自己说清楚极限时间，比反复追问"到底哪天"更有效，也把决策压力交还给需求方。

• 对"企业版"这类宽泛需求进行场景拆解的能力
• 识别核心用户与核心使用场景的提问方法
• 避免被"企业版"三个字带偏、追问到底层价值

我会追问：企业版的目标用户是谁（中小企业/大客户/内部团队）？他们当前最痛的问题是什么，是多人协作、权限管理、数据安全还是集成？企业版与个人版的核心差异是什么？预期靠企业版解决哪个业务指标（付费转化、留存、续费）？我会把这些答案收敛成"1-2 个核心场景 + 该场景的验收标准"，而不是一上来就铺开所有企业功能。如果 PM 说不清核心场景，我会指出"企业版"太宽泛，建议先聚焦一个核心场景做 MVP，避免做成没有重点的大而全。

"企业版"是一个典型的模糊需求，背后可能藏着 10 种完全不同的产品方向。只有把核心场景和用户画像问清楚，才能判断功能优先级，否则研发要么做多、要么做错，浪费大量成本。

• 对"对标"需求进行解构的能力
• 区分"照抄"与"借鉴价值"的思考方式
• 把对标落到自身业务目标上的方法

我会追问：竞品 X 的 Y 功能解决了什么用户问题？我们做这个功能的业务目标是什么（是补齐短板、抢用户还是防御）？竞品的这个功能运营效果如何、到底有没有验证过价值？我会把这个需求从"照抄功能"提升为"对标背后的问题与策略"，并建议只借鉴验证过的核心逻辑，而不是 1:1 复刻所有细节。若 PM 只停留在"竞品有我们也得"的层面，我会指出这是功能妥协而不是价值复制，推动明确预期收益和差异化点。

无脑对标会让产品沦为"竞品复刻机"，研发做出来的功能可能不符合本产品场景。把对标还原成"用户问题 + 自身目标 + 竞品验证"，才能决定做哪些、做多深，避免盲目投入。

• 对北极星指标进行结构拆解的能力
• 区分新增、留存、召回等不同 DAU 来源的思考
• 把模糊目标转成可执行、可验证的方案

我会先把 DAU 拆成"新增用户 + 留存用户 + 召回用户"三大来源，再追问：当前 DAU 的构成比例是多少？主要瓶颈在哪一环（是拉新不足、留存太差还是流失严重）？本次提升 DAU 的目标是提升哪一环？我会用"目标-现状-差距"的框架，把提升 DAU 这个模糊目标落到具体的增长动作上，比如如果瓶颈是留存，就做新用户引导和激活；如果是召回，就做流失预警和触达。只有拆到可执行的环节，才能定验收指标和排期。

"提升 DAU"是一个结果指标，不拆解就无法行动。按用户生命周期拆解出瓶颈环节，才能设计对症的方案，也才能在评审时用结构数据支撑优先级，而不是空谈目标。

• 多方冲突时的决策与仲裁能力
• 理解产品、设计、技术三方视角的差异
• 用用户价值和业务目标作为仲裁标准

我不会站在任何一方直接站队，而是先问清楚：A 和 B 各自要解决的业务目标是什么？差异点是否影响用户价值和业务指标？技术实现上 A 和 B 的成本差异有多大？如果两者都能达成目标，我倾向选择实现成本低且风险小的方案；如果有明确差异，我会把"用户受益 + 业务目标 + 技术成本"三方摆到桌面上，拉上 PM 和 UX 一起对齐，必要时请设计评审或 leader 仲裁。关键是我把决策升级为"基于目标的选择"，而不是"研发听谁的"。

PM 和 UX 冲突很常见，研发若是简单"听 PM 的"或"听 UX 的"都会埋雷。用"业务目标 + 用户价值 + 技术成本"作为共同标准，让冲突回到事实层面，既能推动解决，也避免研发背锅。

• 识别需求内部矛盾的能力
• 把矛盾暴露出来并推动决策的沟通技巧
• 区分"矛盾"与"灵活度"的边界

我会先明确指出现象而不是指责："PRD 里一方面要求 X，另一方面又要求不要 X，这两个要求冲突，我需要 PM 确认以哪个为准。"然后询问：这个矛盾背后的业务场景是什么？在不同场景下是否可以分别成立（比如"对普通用户要 A，对 VIP 不要 A"）？如果确实是矛盾，我会给出一个可决策的对比，请 PM 拍板或明确分层规则。我绝不擅自替 PM 决定取舍，而是把矛盾显性化、推动一次明确决策，避免研发自行二选一造成返工。

需求矛盾如果研发不指出，就会在实现时自行站队，出了问题被 PM 追责。把矛盾摆到台面上并给出决策框架，是负责任的做法，也保护了研发自己。

• 对非功能需求的敏感度与优先级判断
• 把非功能需求量化并与业务风险挂钩的能力
• 主动补充研发视角的验收标准

我会把非功能需求按"对业务的影响"排序：如果不满足会不会导致事故、资金损失、合规处罚或用户流失？比如涉及支付就强调事务和一致性，涉及用户数据就强调安全和合规，涉及主链路就强调性能和可用性。我会请 PM 明确：哪些非功能需求是"必须满足"（P0），哪些是"尽力而为"（P1/P2），并把它们量化成可验收的指标（如 P99 延迟、可用性几个 9、数据备份策略）。若 PM 难以判断，我会给出基于业务风险的默认建议，帮助 PM 做决策。

非功能需求常被 PM 忽略，但往往是上线后事故的根源。研发主动把非功能需求量化并接到业务风险上，既是对产品的负责，也能在评审时争取到合理的资源。

• 对"功能→用户行为"因果假设的验证能力
• 运用 A/B 测试、数据埋点等验证手段的能力
• 避免把"期望"当"事实"的严谨态度

我会先把这个假设拆成"可验证的因果链"：XX 功能 → 用户使用某个环节 → 提升某个指标（如使用时长、留存）。然后设计验证方式：是否可以先做埋点看现状？是否可以用灰度或 A/B 测试对比有/无该功能的用户？是否有历史数据或竞品数据支持这个关系？我会建议先做最小验证（如先上线一个轻量版本、测一小部分用户），用数据确认因果再决定是否全量投入。如果一时无法验证，我会明确告诉 PM"这个假设目前没有数据支撑"，并给出一个验证路径和成本。

"做功能→用户用得更多"是常见但未必成立的因果假设。研发用数据验证替代拍脑袋，能避免把研发资源投在无效果的假设上，这也是把研发从"做功能"提升为"验证价值"的关键。

• 应对未知技术/方法论时的主动学习能力
• 诚实坦承认知边界并快速补齐的沟通方式
• 把论文/方法落地为可实现方案的能力

我会先诚实地说明"这篇论文我没读过，需要先去了解它的核心假设和适用条件"，但不以此为借口拖延。我会快速去读论文、博客或复现 demo，提炼出核心方法、前置条件、输入输出和业界实践，然后带着理解回到需求上：这个方法是否适用于我们的数据规模和业务场景？它的假设在我们这里成立吗？如果 PM 也无法解释清楚，我会指出"论文方法只在我们能验证其假设成立时才适用"，并建议先做小规模验证再决定是否落地。关键是把"没读过"转化为"主动补齐 + 评估适用性"。

认怂和不认怂都不对，正确的做法是快速补齐认知并评估适用性。这样既赢得 PM 的信任，也避免把论文方法盲目套用到不适用场景，造成返工或技术债。

• 用调研证据支持观点的能力
• 区分"用户说想要的"与"用户真正需要的"的洞察
• 有理有据地挑战 PM 判断的沟通方式

我会先列举我的调研证据：用户访谈、反馈数据、使用行为数据、竞品分析等，说明"用户嘴上说想要 XX，但行为上反映出实际需要 YY"。然后区分"表层的 XX"和"底层的 YY"：用户可能说想要某个功能，但真正要解决的是背后的某个问题。我会建议先验证 YY 是否真的能解决用户痛点，对比 XX 与 YY 分别的成本和收益，再请 PM 一起决策。如果数据充分，我会明确表达"现有数据不支持 XX"，并给出一个可验证 YY 的测试方案，而不是直接否定 PM。

用户调研数据是研发挑战 PM 假设的底气。把"用户说的"和"用户需要的"区分开，用数据支撑替代主观对抗，既能推动更正确的方向，也保护了研发避免做错功能。

• 对"老板要求"这类说法的辨别与求证能力
• 不质疑老板、但澄清真实意图的沟通分寸
• 区分"指令来源"与"业务价值"的方法

我不会直接质疑 PM 说谎，而是以"需要理解业务价值"为由，请 PM 向老板澄清这个需求背后的目标和背景：老板是为了什么业务指标、在什么背景下提出这个需求？如果 PM 能讲清楚"为什么老板要做、背后业务逻辑是什么"，能帮助我判断合理性；如果 PM 讲不清，我会通过正式渠道（如需求评审、与 leader 对齐、或邀请老板参与评审）来确认，而不是私底下猜疑。我的判断依据是"业务价值是否成立"，而不是"老板有没有说过"——真的老板需求通常带有清晰的业务背景，而编造的需求往往缺乏业务逻辑。

借"老板"之名压需求是常见博弈手段。研发不正面质疑而是推动澄清业务价值、必要时通过正式评审确认，既守住分寸又避免被"老板要求"裹挟。

• 在紧急场景下快速界定最小范围的能力
• 区分"核心必须项"与"可后置项"的判断
• 用 MVP 思维控制紧急需求风险的方法

我会把需求拆成"必须项 / 可后置项 / 可放弃项"三层：核心业务价值是什么，哪些是今天必须上线的（P0），哪些可以灰度后补（P1），哪些可以砍掉（P2）。然后向 PM 确认："今天只做核心链路 X，边缘场景和优化项下个版本补，是否可以？"用这种方式把"今天就要"落实成一个可执行的、最小的范围，并明确今天验收的边界。如果 PM 坚持全做，我会说明风险——为了赶工砍掉测试或引入技术债，反而可能造成事故，建议用 feature flag 或灰度控制。

紧急需求最怕"范围不清 + 时间紧"，双重压力下容易出事故。主动界定最小范围、分层交付，是把紧急需求做成且不翻车的关键。

• 对"CRM"这类框架性需求的领域拆解能力
• 明确业务模块边界与优先级的方法
• 避免"大而全"陷阱的收敛技巧

我会按 CRM 的典型能力域拆开澄清：是销售管理（线索、商机、跟进）、客户管理（客户档案、生命周期、B2B/B2C）、还是营销管理（活动、触达、自动化）？目标用户是谁、核心业务闭环是什么？我会请 PM 明确本次范围是"全模块"还是"某一模块的核心链路"，并建议先聚焦一个最能产生业务价值的模块做 MVP，其余模块后置。若 PM 说不清，我会指出"CRM 范围太大，不做边界会失控"，推动先确定一个核心业务场景和验收标准。

"做 CRM"这类词背后是巨大的能力域，听起来简单实则极难。通过领域拆解和边界确认，把模糊的大词收敛成可执行的核心场景，是控制复杂度、避免返工的关键。

• 对会员体系业务要素的敏感度
• 明确等级维度与权益设计的方法
• 推动需求从概念到可执行规则的能力

我会追问关键问题：等级依据什么维度划分（累计消费、活跃度、积分、年限）？分为几级、各级的升降级规则是什么？每个等级对应什么权益（折扣、特权、服务）？权益的成本由谁承担？升降级对用户的心理预期和运营成本有何影响？我会请 PM 先确定一个最小可上线的等级模型（如 2-3 个等级 + 核心权益），把升降级规则和权益写清楚，避免直接铺开 10 个等级却没有规则。若 PM 说不清，我会建议先做"等级判定 + 基础权益"的 MVP，验证运营效果后再扩展。

会员等级体系如果等级维度和权益不确定，做出来就是空壳。把"分几级、怎么升、权益是什么"这三个核心规则问清楚，才能落地成可计算、可验收的功能。

• 对推送类系统核心要素的拆解能力
• 明确通道组合与优先级的方法
• 控制系统复杂度与成本的能力

我会先问：本次要支持哪些通道（App push、短信、邮件、Web push）？各通道的触达目标和使用场景是什么？通道之间是否有优先级或降级策略（如 push 失败退回短信）？每条通道的接入成本、计费成本和监管要求差异很大。我会建议先做最容易验证业务价值的单一通道（如 App push）作为 MVP，跑通"触达-转化"闭环后再扩展其他通道，避免一开始就接入短信+邮件+push 的高成本大系统。若 PM 坚持多通道，我会说明成本和复杂度，推动分阶段规划。

推送系统"支持哪些通道"决定了接入成本、计费成本和系统复杂度。先明确通道范围与优先级，用单通道 MVP 验证价值，是避免过度设计、控制成本的关键。

• 对消息中心这类系统的能力域拆解能力
• 明确消息类型与数据模型边界的方法
• 避免过度设计的方法

我会先问：消息中心要承载哪些消息类型——系统消息（公告、通知）、业务消息（订单、物流、优惠）、还是 IM 消息（实时聊天）？不同类型在数据模型、送达方式、实时性、存储策略上差异巨大（IM 需要实时通道和会话管理，业务消息需要和业务状态联动）。我会建议明确本次的第一优先消息类型，先把该类型的数据模型和链路做通，其余类型作为扩展点预留，而不是一开始就做成支持所有类型的庞然大物。若 PM 说不清，我会指出"消息中心"范围过大，建议先聚焦一个业务场景。

消息中心看似单一，实则承载多种差异巨大的消息类型。先明确类型和优先级，用最小可行模型起步，避免一开始就抓取所有消息类型导致过度设计。

• 对反馈闭环类系统的流程设计能力
• 明确处理流程与 SLA 的方法
• 推动从"收反馈"到"处理反馈"闭环的思考

我会先问：反馈从提交到处理完的完整流程是什么——反馈如何分类、如何分配、如何处理、处理结果如何回传给用户？是否需要在 SLA 内响应（如 24 小时内处理、紧急问题 2 小时内）？反馈会进入哪个系统（工单、客服）？不同来源的反馈（App 内、客服、商店）是否统一？我建议先明确"反馈提交→分配→处理→回传"的最小闭环和基础 SLA，先把链路跑通，再逐步增加自动分类、智能回复等能力。若 PM 说不清 SLA，我会指出"没有 SLA 的反馈系统等于黑洞"，推动定义最基础的响应时限。

用户反馈系统若无处理流程和 SLA 就只是"收集工具"，无法形成闭环。明确流程和 SLA 才能让反馈真正被处理、被追踪，这是该系统价值所在。

• 对优惠策略中冲突场景的敏感度
• 明确叠加/互斥规则的方法
• 用规则表推动需求明确的能力

我会把优惠拆成"可叠加"与"互斥"两类，并列出常见冲突场景：满减、折扣、优惠券、会员价、平台补贴同时存在时，优先级如何？是否支持叠加？叠加顺序（先算哪个）如何？是否存在总额上限？我会用"规则矩阵"把优惠类型两两组合，请 PM 逐格确认叠加或互斥，并明确计算顺序和金额上限。因为优惠规则直接涉及资金和用户投诉，我必须把规则用表格形式确认清楚，避免实现时凭感觉导致资损或客诉。

优惠叠加是最容易出金钱事故的需求，冲突规则不明确会导致资损或用户体验差。用规则矩阵把组合场景显性化，让 PM 逐项确认，是规避风险、保障正确性的关键。

• 对订单状态机中异常分支的敏感度
• 明确异常状态处理规则的方法
• 用状态机梳理主流程与异常流的能力

我会先画出订单的主状态机（待支付→已支付→已完成），再主动补齐异常分支：支付超时怎么处理（自动取消还是保留）？取消的条件是什么（可取消时段、取消后库存和金额如何处理）？退款是全额还是部分、退款后状态如何流转？并发场景（用户同时支付和取消）怎么处理？我会把异常分支整理成状态机图，请 PM 逐条确认每个异常的触发条件、后续动作和资金处理，确保主流程和异常流程都覆盖，避免上线后出现"僵尸订单"或资损。

订单状态机最怕只画主流程忽略异常分支，上线后各种边界情况会引发事故。主动补齐超时、取消、退款等异常分支并确认规则，是订单系统稳定性的关键。

• 对支付链路稳定性与异常处理的敏感度
• 明确失败重试、降级、兜底方案的方法
• 把"支付成功"与"支付失败"同等重要的认知

我会先问：支付失败时用户看到什么？是否有重试机制，重试次数和间隔是多少？是否支持切换其他支付方式（如微信失败切支付宝）？支付中断（用户付了但回调丢失）如何对账和补偿？支付通道整体不可用时是否有降级方案（如暂停下单、提示维护）？我会建议明确"失败→重试→切换→兜底"的完整链路，并确保支付回调有对账和补偿机制，避免资金和状态不一致。若 PM 未考虑，我会指出支付失败体验直接决定用户流失和客诉，必须补齐 fallback 策略。

支付成功链路很重要，但支付失败的兜底同样关键。没有 fallback 策略的支付会在失败时造成用户困惑和资金对不上，补齐重试、切换、对账机制是支付系统的底线。

• 对导入类功能边界场景的敏感度
• 主动补充异常反例的能力
• 用反例帮助 PM 完善验收标准的方法

我会主动列出导入功能的异常反例清单：文件格式不对（不是 xlsx）、文件为空、字段缺失、字段类型错误、数据重复、超过行数上限、Excel 版本兼容等。对每个反例，我会确认期望行为：是报错终止、跳过错误行、还是给出错误提示让用户修正？错误信息如何定位到具体行？我会在评审时把这些反例逐条过一遍，请 PM 明确处理策略，把"导入成功"一个场景，扩展成"成功/部分失败/全部失败"的完整验收矩阵。

导入功能最容易因为只考虑"完美数据"而忽略各种异常，导致上线后用户导入失败却不知道错在哪。主动补充反例并把处理策略明确化，是提升导入功能可用性的关键。

• 对生成类功能的失败场景敏感度
• 主动补充失败反例与重试机制的能力
• 把"生成成功"与"生成失败"同等对待的认知

我会补充反例：模板渲染失败、数据超大导致生成超时、PDF 文件损坏无法打开、字体或编码问题、并发生成导致资源耗尽、生成结果与预期不一致等。对每个失败场景，我会确认期望行为：是否重试、重试次数、是否给用户失败提示、是否记录日志便于排查、失败后是否需要补偿。我会建议把"PDF 生成"当作一个可能失败的异步任务来设计，包含超时、重试、失败告警和结果校验，而不是假设它总是成功。

生成类功能看似简单，实则容易在数据异常、资源耗尽时失败。把失败场景和重试、校验机制一并设计，才能保证生成的 PDF 可靠可用。

• 对上传类功能的边界场景敏感度
• 主动补充文件大小、类型、空值等反例的能力
• 明确限制与错误提示策略的方法

我会补充反例清单：文件超过大小限制（几十 MB 或 GB）、空文件、文件类型不在允许范围、文件名含特殊字符、上传中断（网络断开）、并发上传、磁盘空间不足等。对每个反例，我会确认：是否设置大小和类型限制、超出后前端是否拦截、错误提示是否友好、上传中断是否支持断点续传或重试。我会建议在评审时明确"上传限制参数 + 每类错误的前端提示 + 失败重试"，把上传从"拖一拖就成功"扩展成考虑各种边界的健壮功能。

上传功能若只考虑正常文件，遇到大文件、空文件、格式错误就会各种翻车。补齐大小/类型限制、错误提示和失败重试，是上传功能可用性的基础。

• 对登录类安全与异常场景的敏感度
• 主动补充密码错误、锁定、暴力破解等反例的能力
• 明确安全策略与错误提示的方法

我会补充登录的异常反例：密码错误（是否提示剩余次数）、连续错误是否锁定账号（次数和时长）、账号被锁定如何解锁、验证码/二要素校验、暴力破解防护、异常登录检测（异地登录）等。我会确认安全策略：错误尝试次数限制、锁定时限、是否需要找回密码流程、错误提示是否泄露账号是否存在（避免枚举）。我会建议把登录做成"多要素校验 + 锁定策略 + 安全预警"的健壮流程，而不是只验证"账号密码正确就放行"。

登录是最敏感的功能，异常和安全场景（密码错误、锁定、暴力破解）不处理好会造成账号安全和体验问题。补齐安全策略和异常处理，是登录功能的底线。

• 对样例数据重要性的认识
• 主动推动数据样本获取的能力
• 用真实数据验证实现的严谨性

我会先说明样例数据对开发的重要性：没有真实数据，我只能用 mock 数据，容易漏掉字段格式、边界值、长度限制等真实情况。然后我会主动给出"需要什么数据"的清单：样本字段、字段类型、取值范围、典型边界值、真实业务量级，并说明用途（用于联调、边界测试、性能预估）。我会请 PM 从真实系统或运营侧导出脱敏样本，或提供一个最小可用的真实字段集。如果暂时拿不到，我会先用 mock 数据先行开发，但在联调和验收阶段强调"必须用真实数据验证"，避免带病上线。

真实样例数据能提前暴露字段、边界、兼容性问题，是降低返工的有效手段。用清单化方式推动 PM 提供样本，比单纯说"没数据没法做"更有建设性。

• 识别流程理解偏差的能力
• 用可视化方式推动对齐的方法
• 把"理解不一致"显性化的沟通技巧

我会先把我理解的流程画出来（用状态图或泳道图），和 PM 的流程图并排对比，标出差异点：是哪一步的先后顺序不同、哪个分支的触发条件不同、还是某个环节职责归属不同。然后针对差异点逐条确认："我看到 PRD 里流程是 A→B，但我的理解是 A→C→B，请确认正确的路径。"我会把"理解不一致"转化为"具体差异点清单"，推动 PM 逐条确认或修订流程图，避免开发到一半才发现理解南辕北辙。

流程理解不一致是返工的主要来源。用可视化对比把差异点显性化，让 PM 逐条确认，比口头"我觉得不对"更高效，也更有说服力。

• 对需求假设的识别与验证能力
• 用数据确认假设成立的方法
• 避免基于错误假设开发的严谨态度

我会先识别出 PRD 里所有"假设"类语句，把它们列出来，逐一标注"是否可验证"和"验证方式"。对这个具体条件，我会想办法验证：是否有历史数据、指标、调研能直接确认？是否可以通过查询数据库、埋点数据或与业务方确认来验证？如果暂时无法验证，我会在实现中对该假设做防御性处理（如加参数开关、容错），并明确告知 PM"这个假设目前没有数据支撑，可能影响结果"。我会把验证结果反馈给 PM，推动在假设成立或不成立时都定义好行为。

PRD 里的假设往往是隐性风险，基于错误假设开发会导致功能与预期不符。识别并验证假设，对无法验证的假设做防御性设计，是严谨工程的体现。

• 对 API 网关能力域的拆解能力
• 明确能力范围与优先级的方法
• 避免过度设计的能力

我会先拆解 API 网关的典型能力域：路由转发、鉴权认证、限流熔断、日志监控、协议转换、灰度发布等。然后问：本次要解决的核心问题是什么（是统一入口、安全控制、还是流量治理）？对应哪些能力是必须的（P0），哪些可以后置？我会建议先聚焦"统一入口 + 鉴权 + 基础限流"这些核心能力作为 MVP，监控和高级治理后置，避免一开始就做成功能齐全的巨型网关。若 PM 说不清，我会用"网关解决什么问题"倒推最小能力集。

"API 网关"是一个能力域极广的框架性需求，若范围不清会过度设计。先明确要解决的核心问题，再收敛最小能力集，是控制复杂度、避免大而全的关键。

• 对 A/B 实验平台能力域的拆解能力
• 明确实验维度与作用域的方法
• 控制平台复杂度与成本的能力

我会先问：实验要支持哪些维度——页面 UI 实验、推荐/算法实验、功能开关实验、策略参数实验？不同维度的实验在曝光、分流、埋点、统计方法上差异很大（页面实验需要前端 SDK 分流，算法实验需要服务端流量分配）。我会建议明确本次的优先维度，先把该维度的分流、埋点、统计链路打通，形成最小可用的实验闭环，再去扩展其他维度。若 PM 说不清，我会指出实验平台范围过大，建议先支持"功能/参数实验"这一最易落地、最通用的维度。

A/B 实验平台"支持哪些维度"决定了系统架构和复杂度。先聚焦一个维度做通闭环，再横向扩展，避免一开始就做全维度导致过度设计。

• 对 mock 数据局限性的认识
• 主动补充真实数据异常反例的能力
• 用真实数据风险推动 PM 完善的需求能力

我会先指出 mock 数据的局限：mock 数据是"理想化"的，字段格式、长度、边界、异常值都和真实数据脱节，用它开发容易出现"开发环境正常、生产环境崩"。然后我会主动补充真实数据的异常反例：空值、超长字段、特殊字符、枚举值不在预期内、重复数据、异常时间戳等，并逐条确认期望行为。我还会推动 PM 提供真实脱敏数据样本或接口文档中的字段定义，用真实数据跑一遍联调，把潜在问题提前暴露。

mock 数据掩盖了真实数据的各种异常，是上线事故的温床。主动补充真实数据反例并推动用真实样本验证，是把开发从"理想环境"拉回"真实世界"的关键。