AI 基础认知与机器学习

1. 优先原则：规则稳定时优先规则

在实际工程中，能用规则清楚表达的逻辑，永远优先用规则。因为规则系统便宜、稳定、可解释，出了问题也容易定位。AI 不是越早引入越好，AI 的价值在于处理规则写不完、写不稳、写了也维护不动的问题。

• 高确定性与强解释性：规则是非黑即白的执行逻辑，例如权益开关、年龄限制、金额阈值、状态流转。一旦出错，研发可以直接查哪条规则命中。
• 低成本与零冷启动：几行代码、一个配置表或一个状态机就能解决的问题，不需要收集样本、训练模型、维护评测集和监控漂移。
• 典型场景：会员权益判断、优惠券满减、法定规则、权限校验、Android 页面焦点顺序、错误码到提示文案的映射。

2. 引入边界：规则难穷举 + 样本充足时再考虑 AI

只有同时满足“规则难穷举”和“样本充足”两个条件，AI 才可能比规则更合适。少一个条件，都要谨慎。

• 条件一，规则难穷举：业务场景复杂、变化快、人的经验说得出结果但写不全过程。硬写规则会出现规则冲突、优先级混乱、维护成本暴涨。
• 条件二，样本充足：必须有足够多、质量足够高、代表未来场景的历史样本。没有样本，模型不是“智能”，只是更贵的猜测器。
• 适合 AI 的典型场景：垃圾内容识别、反欺诈风控、用户意图分类、故障日志归因、用户反馈聚类、图片/语音/自然语言理解。

3. 投影 / Android 应用中的选型边界

在投影设备和 Android App 开发里，不要看到“体验问题”就立刻上 AI。先把问题分成三类：规则能解决、数据分析能解决、确实需要 AI 学习。

• 继续用规则：遥控器 D-pad 焦点顺序、会员按钮是否展示、网络错误码提示、固件版本兼容开关、埋点字段校验。
• 先做数据分析：启动慢、播放卡顿、投屏失败率升高，先看版本、机型、网络、日志分布，不要一开始就训练模型。
• 再考虑 AI：用户反馈表述混乱、日志组合复杂、故障原因难穷举、客服需要自动分类和推荐排障路径，并且已经积累了足够历史样本。

4. 上线前判断：四个问题答不上来，就先别用 AI

• 规则是否已经足够？如果规则能覆盖主要场景，并且维护成本低，优先规则。
• 样本是否足够？有没有真实用户、真实设备、真实版本、真实失败案例，而不是测试同学临时编的样例。
• 指标是否可验收？能不能用准确率、召回率、一次解决率、定位耗时、转人工率证明 AI 真的有用。
• 错误是否可兜底？AI 判断错时，是提示用户、转人工、降级规则，还是可能直接造成事故。

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「输入与输出」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 业务结果能被观察或验收，而不是只有“体验更好”这类愿望。
• 预测或生成发生的时间点清楚，能区分当时可见信息和事后结果。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「输入与输出」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在需求立项、AI 场景筛选、数据采集设计之前使用。
• 适合把模糊想法拆成输入、输出、样本、标签、指标和兜底流程。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 如果输出无法验收，模型好坏就只能靠感觉判断。
• 如果输入在真实上线时拿不到，离线效果再好也没有意义。
• 不适合用来包装没有数据、没有结果定义、没有负责人承接的想法。
• 不适合把一次性事故、纯主观偏好、无法验证的目标硬改成 AI 项目。
• 最大风险是目标定义错：模型认真优化了一个对业务没有价值的指标。

4. 上线前判断：能回答这些问题再落地

• 能写出一句完整任务：在什么时刻，使用哪些输入，输出什么结果。
• 能说明结果由谁确认、多久能确认、错判后执行什么降级或人工兜底。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「标签 Label」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 业务结果能被观察或验收，而不是只有“体验更好”这类愿望。
• 预测或生成发生的时间点清楚，能区分当时可见信息和事后结果。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「标签 Label」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在需求立项、AI 场景筛选、数据采集设计之前使用。
• 适合把模糊想法拆成输入、输出、样本、标签、指标和兜底流程。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 标签含糊时，先统一定义和标注规范，不要急着训练。
• 标签由旧规则生成时，模型可能只是复制旧规则的偏见和漏洞。
• 不适合用来包装没有数据、没有结果定义、没有负责人承接的想法。
• 不适合把一次性事故、纯主观偏好、无法验证的目标硬改成 AI 项目。
• 最大风险是目标定义错：模型认真优化了一个对业务没有价值的指标。

4. 上线前判断：能回答这些问题再落地

• 能写出一句完整任务：在什么时刻，使用哪些输入，输出什么结果。
• 能说明结果由谁确认、多久能确认、错判后执行什么降级或人工兜底。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「可学习模式」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 业务结果能被观察或验收，而不是只有“体验更好”这类愿望。
• 预测或生成发生的时间点清楚，能区分当时可见信息和事后结果。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「可学习模式」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在需求立项、AI 场景筛选、数据采集设计之前使用。
• 适合把模糊想法拆成输入、输出、样本、标签、指标和兜底流程。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 关键变量没记录时，模型只能猜影子，不能学到原因。
• 业务策略频繁变化时，旧数据可能很快过期。
• 不适合用来包装没有数据、没有结果定义、没有负责人承接的想法。
• 不适合把一次性事故、纯主观偏好、无法验证的目标硬改成 AI 项目。
• 最大风险是目标定义错：模型认真优化了一个对业务没有价值的指标。

4. 上线前判断：能回答这些问题再落地

• 能写出一句完整任务：在什么时刻，使用哪些输入，输出什么结果。
• 能说明结果由谁确认、多久能确认、错判后执行什么降级或人工兜底。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「监督学习」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 先确认问题类型：是要预测类别、预测数值、发现群组，还是决定优先级。
• 样本粒度一致，例如一次会话、一个用户、一个工单不能混着训练。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「监督学习」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 监督学习适合历史上有标准答案的审批、分类、预测和评分任务。
• 无监督学习适合没有标签时做探索、分群、异常发现和问题归并。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 没有可靠标签时，监督学习会变成错误答案放大器。
• 如果问题类型经常新增，模型要配合人工复核和持续再训练。
• 标签缺失或标签口径混乱时，不要急着上监督学习。
• 聚类结果不能直接当业务真相，必须由人解释和命名。
• 选错任务类型会让指标漂亮但动作错误，例如把排序问题做成分类问题。

4. 上线前判断：能回答这些问题再落地

• 能说出每个输出对应的下一步业务动作。
• 能解释误报、漏报、排序错、分群错分别造成什么损失。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「无监督学习」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 先确认问题类型：是要预测类别、预测数值、发现群组，还是决定优先级。
• 样本粒度一致，例如一次会话、一个用户、一个工单不能混着训练。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「无监督学习」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 监督学习适合历史上有标准答案的审批、分类、预测和评分任务。
• 无监督学习适合没有标签时做探索、分群、异常发现和问题归并。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 聚出来的类别不等于业务真相，需要人工解释和验证。
• 无监督结果不能直接当处罚、拒绝、扣费依据。
• 标签缺失或标签口径混乱时，不要急着上监督学习。
• 聚类结果不能直接当业务真相，必须由人解释和命名。
• 选错任务类型会让指标漂亮但动作错误，例如把排序问题做成分类问题。

4. 上线前判断：能回答这些问题再落地

• 能说出每个输出对应的下一步业务动作。
• 能解释误报、漏报、排序错、分群错分别造成什么损失。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「分类」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 先确认问题类型：是要预测类别、预测数值、发现群组，还是决定优先级。
• 样本粒度一致，例如一次会话、一个用户、一个工单不能混着训练。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「分类」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 监督学习适合历史上有标准答案的审批、分类、预测和评分任务。
• 无监督学习适合没有标签时做探索、分群、异常发现和问题归并。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 类别太多且样本少时，模型会学不稳。
• 类别之间重叠严重时，要允许多标签或先做人工仲裁。
• 标签缺失或标签口径混乱时，不要急着上监督学习。
• 聚类结果不能直接当业务真相，必须由人解释和命名。
• 选错任务类型会让指标漂亮但动作错误，例如把排序问题做成分类问题。

4. 上线前判断：能回答这些问题再落地

• 能说出每个输出对应的下一步业务动作。
• 能解释误报、漏报、排序错、分群错分别造成什么损失。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「回归」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 先确认问题类型：是要预测类别、预测数值、发现群组，还是决定优先级。
• 样本粒度一致，例如一次会话、一个用户、一个工单不能混着训练。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「回归」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 监督学习适合历史上有标准答案的审批、分类、预测和评分任务。
• 无监督学习适合没有标签时做探索、分群、异常发现和问题归并。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 数值预测要关注大错场景，平均误差低不代表用户体验好。
• 如果输出本质是等级判断，不一定要硬做回归，可以改成分类。
• 标签缺失或标签口径混乱时，不要急着上监督学习。
• 聚类结果不能直接当业务真相，必须由人解释和命名。
• 选错任务类型会让指标漂亮但动作错误，例如把排序问题做成分类问题。

4. 上线前判断：能回答这些问题再落地

• 能说出每个输出对应的下一步业务动作。
• 能解释误报、漏报、排序错、分群错分别造成什么损失。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「聚类与排序」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 先确认问题类型：是要预测类别、预测数值、发现群组，还是决定优先级。
• 样本粒度一致，例如一次会话、一个用户、一个工单不能混着训练。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「聚类与排序」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 监督学习适合历史上有标准答案的审批、分类、预测和评分任务。
• 无监督学习适合没有标签时做探索、分群、异常发现和问题归并。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 只按数量排序可能忽略高价值用户或严重风险问题。
• 聚类太细会碎片化，太粗会掩盖关键差异。
• 标签缺失或标签口径混乱时，不要急着上监督学习。
• 聚类结果不能直接当业务真相，必须由人解释和命名。
• 选错任务类型会让指标漂亮但动作错误，例如把排序问题做成分类问题。

4. 上线前判断：能回答这些问题再落地

• 能说出每个输出对应的下一步业务动作。
• 能解释误报、漏报、排序错、分群错分别造成什么损失。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「样本」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 数据字段有明确来源、采集时间、单位、口径和负责人。
• 训练时使用的字段在真实预测时也能拿到。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「样本」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在建模前做字段盘点、日志治理、埋点补齐和样本抽样。
• 适合把业务经验变成可观测信号，例如耗时、错误码、路径、版本和状态。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 样本只覆盖高端机型时，上线到低端设备可能失败。
• 重复日志不去重，会让模型过度关注少数频繁上报的问题。
• 不要把所有数据库字段直接喂给模型，尤其是身份、隐私和事后字段。
• 不要把缺失值都当 0，缺失可能代表未采集、未发生或被过滤。
• 数据泄漏会让离线指标虚高，上线后迅速崩掉。

4. 上线前判断：能回答这些问题再落地

• 每个字段都能回答：从哪里来、何时产生、上线能否拿到、是否敏感。
• 每个样本都能确认粒度一致，且没有把同一事件重复统计。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「特征 Feature」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 数据字段有明确来源、采集时间、单位、口径和负责人。
• 训练时使用的字段在真实预测时也能拿到。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「特征 Feature」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在建模前做字段盘点、日志治理、埋点补齐和样本抽样。
• 适合把业务经验变成可观测信号，例如耗时、错误码、路径、版本和状态。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 包含用户隐私或敏感字段时，要先做合规评估和脱敏。
• 看似相关但上线拿不到的字段，不能作为特征。
• 不要把所有数据库字段直接喂给模型，尤其是身份、隐私和事后字段。
• 不要把缺失值都当 0，缺失可能代表未采集、未发生或被过滤。
• 数据泄漏会让离线指标虚高，上线后迅速崩掉。

4. 上线前判断：能回答这些问题再落地

• 每个字段都能回答：从哪里来、何时产生、上线能否拿到、是否敏感。
• 每个样本都能确认粒度一致，且没有把同一事件重复统计。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「数值特征」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 数据字段有明确来源、采集时间、单位、口径和负责人。
• 训练时使用的字段在真实预测时也能拿到。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「数值特征」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在建模前做字段盘点、日志治理、埋点补齐和样本抽样。
• 适合把业务经验变成可观测信号，例如耗时、错误码、路径、版本和状态。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 不同机型性能差异大，数值要结合设备档位看。
• 采样频率变化会改变数值含义，不能直接比较。
• 不要把所有数据库字段直接喂给模型，尤其是身份、隐私和事后字段。
• 不要把缺失值都当 0，缺失可能代表未采集、未发生或被过滤。
• 数据泄漏会让离线指标虚高，上线后迅速崩掉。

4. 上线前判断：能回答这些问题再落地

• 每个字段都能回答：从哪里来、何时产生、上线能否拿到、是否敏感。
• 每个样本都能确认粒度一致，且没有把同一事件重复统计。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「类别特征」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 数据字段有明确来源、采集时间、单位、口径和负责人。
• 训练时使用的字段在真实预测时也能拿到。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「类别特征」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在建模前做字段盘点、日志治理、埋点补齐和样本抽样。
• 适合把业务经验变成可观测信号，例如耗时、错误码、路径、版本和状态。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 类别命名不统一会制造脏数据，例如 AndroidTV、Android TV、ATV 被当成三类。
• 高基数类别可能泄漏身份或造成过拟合。
• 不要把所有数据库字段直接喂给模型，尤其是身份、隐私和事后字段。
• 不要把缺失值都当 0，缺失可能代表未采集、未发生或被过滤。
• 数据泄漏会让离线指标虚高，上线后迅速崩掉。

4. 上线前判断：能回答这些问题再落地

• 每个字段都能回答：从哪里来、何时产生、上线能否拿到、是否敏感。
• 每个样本都能确认粒度一致，且没有把同一事件重复统计。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「数据清洗」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 数据字段有明确来源、采集时间、单位、口径和负责人。
• 训练时使用的字段在真实预测时也能拿到。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「数据清洗」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在建模前做字段盘点、日志治理、埋点补齐和样本抽样。
• 适合把业务经验变成可观测信号，例如耗时、错误码、路径、版本和状态。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 不要为了指标好看删除真实难例。
• 清洗规则要可追溯，否则以后无法解释模型为什么变好或变差。
• 不要把所有数据库字段直接喂给模型，尤其是身份、隐私和事后字段。
• 不要把缺失值都当 0，缺失可能代表未采集、未发生或被过滤。
• 数据泄漏会让离线指标虚高，上线后迅速崩掉。

4. 上线前判断：能回答这些问题再落地

• 每个字段都能回答：从哪里来、何时产生、上线能否拿到、是否敏感。
• 每个样本都能确认粒度一致，且没有把同一事件重复统计。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「数据泄漏」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 数据字段有明确来源、采集时间、单位、口径和负责人。
• 训练时使用的字段在真实预测时也能拿到。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「数据泄漏」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在建模前做字段盘点、日志治理、埋点补齐和样本抽样。
• 适合把业务经验变成可观测信号，例如耗时、错误码、路径、版本和状态。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 每个特征都要标注生成时间，晚于预测时刻的一律警惕。
• 指标异常高时不要先高兴，先查有没有泄漏。
• 不要把所有数据库字段直接喂给模型，尤其是身份、隐私和事后字段。
• 不要把缺失值都当 0，缺失可能代表未采集、未发生或被过滤。
• 数据泄漏会让离线指标虚高，上线后迅速崩掉。

4. 上线前判断：能回答这些问题再落地

• 每个字段都能回答：从哪里来、何时产生、上线能否拿到、是否敏感。
• 每个样本都能确认粒度一致，且没有把同一事件重复统计。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「模型参数」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「训练」：理解模型到底学到了什么，以及为什么不是人工手写规则。
• 训练目标已经明确，知道模型应该优化什么、不能只看什么。
• 有固定验证集，调参和改特征不能只靠主观感受。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「模型参数」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合解释模型为什么会从数据中学到规律，而不是人工写规则。
• 适合在模型效果不稳定、误报漏报成本不同、需要调参时使用。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 不要把参数当成业务因果结论，它更多是相关性学习结果。
• 参数太多、样本太少时容易记住训练数据细节。
• 不要把参数或特征重要性直接解释成因果关系。
• 不要在没有评测集的情况下反复调超参数。
• 过度调参会把验证集也调穿，真实上线不一定变好。

4. 上线前判断：能回答这些问题再落地

• 能说明当前最重要的错误类型是什么，以及训练目标如何体现它。
• 能记录每次调参前后指标、失败样本和业务影响。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「损失函数」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「训练」：把业务上不能忍的错误翻译成模型优化方向。
• 训练目标已经明确，知道模型应该优化什么、不能只看什么。
• 有固定验证集，调参和改特征不能只靠主观感受。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「损失函数」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合解释模型为什么会从数据中学到规律，而不是人工写规则。
• 适合在模型效果不稳定、误报漏报成本不同、需要调参时使用。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 损失函数下降不等于业务收益一定提升。
• 只优化平均损失可能忽略少数高影响用户。
• 不要把参数或特征重要性直接解释成因果关系。
• 不要在没有评测集的情况下反复调超参数。
• 过度调参会把验证集也调穿，真实上线不一定变好。

4. 上线前判断：能回答这些问题再落地

• 能说明当前最重要的错误类型是什么，以及训练目标如何体现它。
• 能记录每次调参前后指标、失败样本和业务影响。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「梯度下降」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「训练」：理解模型如何从错误反馈中一点点调整。
• 训练目标已经明确，知道模型应该优化什么、不能只看什么。
• 有固定验证集，调参和改特征不能只靠主观感受。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「梯度下降」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合解释模型为什么会从数据中学到规律，而不是人工写规则。
• 适合在模型效果不稳定、误报漏报成本不同、需要调参时使用。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 训练不收敛可能是学习率、数据尺度、标签质量或模型结构问题。
• 不要把训练轮数越多等同于效果越好，过多可能过拟合。
• 不要把参数或特征重要性直接解释成因果关系。
• 不要在没有评测集的情况下反复调超参数。
• 过度调参会把验证集也调穿，真实上线不一定变好。

4. 上线前判断：能回答这些问题再落地

• 能说明当前最重要的错误类型是什么，以及训练目标如何体现它。
• 能记录每次调参前后指标、失败样本和业务影响。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「超参数」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「调试」：控制模型训练或输出行为，而不是让模型自己决定一切。
• 训练目标已经明确，知道模型应该优化什么、不能只看什么。
• 有固定验证集，调参和改特征不能只靠主观感受。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「超参数」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合解释模型为什么会从数据中学到规律，而不是人工写规则。
• 适合在模型效果不稳定、误报漏报成本不同、需要调参时使用。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 没有评测集时，调参只是碰运气。
• 同一组超参数不一定适合所有场景，客服、研发、运营的目标不同。
• 不要把参数或特征重要性直接解释成因果关系。
• 不要在没有评测集的情况下反复调超参数。
• 过度调参会把验证集也调穿，真实上线不一定变好。

4. 上线前判断：能回答这些问题再落地

• 能说明当前最重要的错误类型是什么，以及训练目标如何体现它。
• 能记录每次调参前后指标、失败样本和业务影响。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「可解释性」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练目标已经明确，知道模型应该优化什么、不能只看什么。
• 有固定验证集，调参和改特征不能只靠主观感受。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「可解释性」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合解释模型为什么会从数据中学到规律，而不是人工写规则。
• 适合在模型效果不稳定、误报漏报成本不同、需要调参时使用。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 解释不等于因果证明，不能把相关因素当根因。
• 涉及用户权益和人工处理时，解释必须更谨慎、更可审计。
• 不要把参数或特征重要性直接解释成因果关系。
• 不要在没有评测集的情况下反复调超参数。
• 过度调参会把验证集也调穿，真实上线不一定变好。

4. 上线前判断：能回答这些问题再落地

• 能说明当前最重要的错误类型是什么，以及训练目标如何体现它。
• 能记录每次调参前后指标、失败样本和业务影响。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「训练集」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「训练集」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 训练集里混入测试集信息会导致评测失真。
• 只收集成功案例会让模型看不懂失败场景。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「验证集」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「验证集」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 反复根据验证集调到很高，验证集也会被“记住”。
• 验证集要定期更新，否则跟不上新版本问题。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「测试集」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「测试集」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 测试集过小会让结果不稳定。
• 只看总分会掩盖某些设备或版本的严重失败。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「泛化能力」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「上线」：确认模型能不能从历史样本走到未来真实场景。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「泛化能力」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 训练集太单一会削弱泛化。
• 业务环境变化后，原来的泛化能力可能下降。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「过拟合」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「过拟合」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 训练指标很好不能说明可上线，要看验证和测试。
• 过拟合常被数据泄漏和样本重复掩盖。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「数据分布变化」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「运营」：识别世界变了以后模型为什么会变差。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「数据分布变化」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 模型上线后不监控分布，就无法知道它什么时候变差。
• 不要用很久以前的数据评估现在的模型。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「混淆矩阵」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「混淆矩阵」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 只看 Accuracy 会隐藏 FP 和 FN 的差异。
• 类别不均衡时，混淆矩阵比总分更重要。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「Accuracy」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「Accuracy」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 异常检测、风险识别、严重故障识别不能只看 Accuracy。
• 要配合 Recall、Precision、分层指标一起看。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「Precision」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「Precision」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• Precision 高不代表没有漏掉问题。
• 如果过度追求 Precision，可能只敢报最明显的问题。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「Recall」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「Recall」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• Recall 高可能意味着误报很多，需要人工或二级模型过滤。
• 不能只看 Recall，否则系统可能把所有样本都报成异常。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「F1 与 AUC」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「F1 与 AUC」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• F1 会掩盖误报和漏报的业务差异。
• AUC 高不代表某个阈值下就一定可用。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「阈值」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「阈值」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 阈值不是技术人员单独决定的，要结合业务成本和承载量。
• 上线后阈值要根据真实反馈调整。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「上线门槛」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「上线门槛」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 只通过平均指标不够，关键设备和高风险场景也要通过。
• 没有监控和回滚，不算真正具备上线条件。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「线上监控」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「线上监控」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 只监控服务可用，不监控回答质量，会错过业务劣化。
• 只看总体指标，会掩盖某个机型或地区的问题。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「人工兜底」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「人工兜底」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 没有兜底会让小错误放大成用户事故。
• 人工兜底也要有 SLA，否则用户只是从 AI 等到人工。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「模型漂移」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「运营」：管理上线后效果随时间下降的问题。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「模型漂移」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 漂移不是一次 bug，而是持续系统管理问题。
• 没有版本化评测集和线上监控，很难发现漂移。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「公平性」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「治理」：防止平均指标掩盖某些用户或设备群体体验很差。
• 训练、验证、测试要按时间、用户或场景隔离，不能互相泄漏。
• 核心指标必须和业务动作绑定，不能只看一个平均分。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「公平性」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合在模型验收、灰度上线、版本对比和线上运营时使用。
• 适合判断模型是否真的能面对新用户、新机型、新版本和新问题。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 总体指标达标不代表每个群体都达标。
• 公平性不一定要求所有群体指标完全一样，但要解释差异并降低不合理损害。
• 不要只用 Accuracy 判断异常、风险、严重故障这类低占比问题。
• 不要用测试集反复调方案，测试集会失去最终验收意义。
• 类别不均衡会让高 Accuracy 掩盖低 Recall。

4. 上线前判断：能回答这些问题再落地

• 能画出混淆矩阵，并说明每种错法的业务代价。
• 能按机型、版本、网络、问题类型分层看指标。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？

1. 优先原则：先满足前提，再谈使用

在实际工程里，任何概念都不能脱离场景硬套。学习「可解释性」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。

• 先看它服务的专业判断是不是「基础判断」：把 AI 想法拆成数据、目标、指标和上线风险。
• 训练目标已经明确，知道模型应该优化什么、不能只看什么。
• 有固定验证集，调参和改特征不能只靠主观感受。

2. 引入边界：同时满足这些条件，才值得推进

只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。

• 当「可解释性」能改变投影设备体验、Android App 性能、用户反馈、日志归因、客服排障里的设计、评测或风险控制动作时，才值得进入方案。
• 适合解释模型为什么会从数据中学到规律，而不是人工写规则。
• 适合在模型效果不稳定、误报漏报成本不同、需要调参时使用。

3. 反向边界：这些情况先停下来

专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。

• 解释不等于因果证明，不能把相关因素当根因。
• 涉及用户权益和人工处理时，解释必须更谨慎、更可审计。
• 不要把参数或特征重要性直接解释成因果关系。
• 不要在没有评测集的情况下反复调超参数。
• 过度调参会把验证集也调穿，真实上线不一定变好。

4. 上线前判断：能回答这些问题再落地

• 能说明当前最重要的错误类型是什么，以及训练目标如何体现它。
• 能记录每次调参前后指标、失败样本和业务影响。
• 现场追问：如果明天要把它放进真实 App 流程，你能不能说清数据从哪里来、结果谁验收、错了谁兜底？