豆包常用的 100 条日常生活提示词,推荐收藏
在豆包里问“今晚吃什么”,在 WorkBuddy 里整理旅行清单,或者请 Codex 帮忙核对家庭预算,生活任务看似简单,却很容易漏掉人数、时间、预算和忌口这些关键条件。条件不说清,换哪个智能体都只能给大概建议。这 100 条 Prompt 覆盖日程、购物、做饭、出行、沟通与学习,把真实情况填进【】里,得到的回答才更容易照着做。
使用时把【】替换为自己的时间、预算、偏好或记录;没有把握的数据留空并请 AI 列出需要确认的事项。涉及价格、行程或规则的建议,按提示词里的核验要求查当前信息。
01日程与生活管理
场景 1|根据今天的事情安排合理日程
今天要处理【事项】,可用时间是【时间段】,固定安排有【日程】,精力状态【状态】。按时间块排出可执行日程,写清每段的开始、结束和地点切换;把通勤、吃饭与缓冲算进总时长。先核对是否超出可用时间;若放不下,按截止时间和影响划出必做项、可延期项,并给一份最低可行安排。
场景 2|把一堆待办事项按轻重缓急排序
请整理以下待办【清单】,背景目标是【目标】,截止时间和影响分别是【信息】。按紧急性、重要性、依赖及拖延成本排序,指出可以委派、取消或协商延期的项目。缺少关键信息时先列问题。
场景 3|根据空闲时间安排今天能完成的事情
我今天有【空闲时段/总时长】,待办是【清单】,每项大概需要【耗时/未知】。请按时间块安排最重要且能完成的任务,给估时留出误差空间。明确今天不建议硬塞进去的事项。
场景 4|制定一个不容易放弃的晨间计划
我通常在【起床时间】起床,需在【出门/开工时间】前完成【必做事项】,当前习惯是【情况】。设计一个不超过【分钟】的晨间流程,从最小版本开始,标出准备动作和连续几天后的调整条件,不要依赖意志力或昂贵装备。
场景 5|制定一个睡前收尾计划
我的睡觉目标是【时间】,睡前常被【干扰】打断,第二天要【早晨任务】。请设计一套【分钟】内能完成的收尾步骤,包含放下设备、准备明日物品和放松环节。提供忙碌日的两步简化版。
场景 6|帮我安排一个高效率但不过度紧张的周末
这个周末我有【可用时段】,想完成【事务】并留出【休息/社交】。请安排一份松弛可执行的计划,考虑地点切换、天气或预约限制。每天最多设【数量】个重点,并保留临时取消后的替代安排。
场景 7|将长期目标拆成每周可以执行的小目标
我的长期目标是【目标】,希望在【期限】达成,目前进度和每周可投入时间为【信息】。拆成阶段成果和每周行动,设可检查的完成标志。如果目标或时间不匹配,请指出需调整的范围,不要只给鼓励语。
场景 8|分析最近有哪些事情一直拖延
我反复拖延的事项是【清单/描述】,通常发生在【时间/情境】,可能原因有【猜测】。请区分任务太大、目标不清、害怕失败、资源不足或优先级冲突,并为每项给一个 10 分钟内可启动的动作和验证方法。
场景 9|帮我设计一个简单的习惯养成计划
我想养成【习惯】,当前生活节奏是【作息】,过去失败的原因是【原因】。设计一个足够小的起步动作,安排触发场景、记录方法、漏做时的恢复规则和两周复盘指标。避免把连续打卡当唯一成功标准。
场景 10|根据最近的生活状态重新调整时间分配
最近【工作/家庭/健康等】状态变化为【情况】,每周时间大致分配【现状】,最想改善的是【目标】。请找出时间与精力的错配,提出可尝试两周的调整方案。把必要责任、可协商事务和自我照顾分开列出。
02购物与消费决策
场景 11|判断一个东西到底值不值得买
我在考虑购买【商品/服务】,价格【金额】,用途【场景】,现有替代品【情况】,预算上限【金额】。把“不买、继续用现有替代品”和“购买”放在同一张对照表中,比较使用频率、能解决的问题、总成本、维护及退换条件。给“买/暂缓/不买”的条件结论:指出哪一个未知信息最可能改变判断;涉及当前价格或条款时注明核验来源与日期。
场景 12|比较两个商品应该选哪个
请比较【商品A】与【商品B】,我的主要用途【用途】、优先考虑【标准】、预算【金额】。先核对参数是否同口径,再做优缺点表,标明影响体验的差异、无法确认的信息及适合哪类需求,不以宣传词代替证据。
场景 13|根据预算推荐最适合的商品类型
我计划花【预算】买【商品类别】,用途【场景】,必须满足【条件】,不需要【功能】。先推荐合适的产品类型和参数范围,再给筛选顺序。如要推荐具体型号,请核验当前价格、供货和规格并附来源。
场景 14|帮我分析商品参数哪些真正重要
商品页面参数【规格信息】很多,我主要用于【场景】,候选产品是【型号】。请将参数分成关键、次要和可忽略项,解释它们如何影响实际使用。指出宣传表述、测试条件或单位不清之处,别把更高数值一概视为更好。
场景 15|看懂商家复杂的产品介绍
请把【商品介绍/合同条款】改写成普通消费者能理解的话。逐项解释功能、限制、费用、续费/退货条件和容易误解的承诺。区分商家明确写出的内容与推断,涉及法律权利时标记需核对当地现行规则。
场景 16|判断商品升级款是否值得多花钱
我已有【旧款/现有设备】,考虑升级到【新款】,差价【金额】,主要需求【需求】。请比较与需求相关的新增能力、兼容性、生命周期和旧设备处置价值。计算差价对应的真实收益条件,资料不足时给出待核验清单。
场景 17|购买某类商品前应该检查什么
我准备购买【商品类别】,使用者和环境是【情况】,预算【金额】。请做一份下单前检查清单,覆盖核心规格、兼容、安全认证/售后、总价和退换规则。对会随地区或时间变化的信息标注核验来源。
场景 18|根据自己的需求生成购物清单
我需要为【场景/人数/周期】准备【购物目标】,已有物品或食材【清单】,预算【金额】。请按必需、可选、已有可替代分类,给数量、规格和购买优先级。合并重复项,说明数量估算依据。
场景 19|分析一件东西应该买贵一点还是够用就行
我在【低价选项】和【高价选项】之间犹豫,使用频率【频率】、关键需求【需求】、可承受预算【金额】。请比较故障/维护风险、性能余量和使用年限,说明何种情况下多花钱值得、何种情况下基础款足够。
场景 20|帮我识别购物时可能存在的消费陷阱
请检查这段促销信息【页面/话术】,我考虑购买【商品】。找出限时稀缺、先涨后降、默认续费、捆绑、模糊性能和隐藏费用等线索,区分已能确认与需核验之处。最后列下单前应查看的条款。
03家庭记账与个人财务
场景 21|根据收入和支出制定月度预算
我每月税后收入【金额】,固定支出【清单】,可变支出和储蓄目标【信息】,家庭人数【人数】。请按我的真实现金流拟月度预算,列类别、金额、依据和弹性。先核对收支是否平衡,不预设固定储蓄比例,指出缺失数据。
场景 22|分析这个月的钱主要花到哪里去了
这是本月流水【脱敏账单/分类汇总】,周期【日期】,币种【币种】。请检查重复交易和分类误差,汇总各类别金额及占比,标出与上月可比的变化。无法确认的商户不要擅自归类,并说明结论受哪些数据限制。
场景 23|帮我给家庭支出进行分类
请将这份家庭流水【脱敏记录】整理为适合月度复盘的支出类别。保留日期、金额和商户,区分固定/可变、必要/可选及一次性大额。对歧义交易标“待确认”,输出分类规则和汇总表。
场景 24|制定一个简单可执行的存钱计划
我希望在【期限】为【目标】存下【金额】,当前可用存款【金额】,月净收入和必要支出【数据】,收入波动【情况】。请测算每月所需储蓄及现金缓冲,提供保守与常规两种方案。核算不成立时说明需改的目标或期限,不推荐投资产品。
场景 25|判断某项大额消费会不会影响预算
我想购买【物品/服务】,总价和付款方式【信息】,家庭月现金流【收支】,近期已知大额支出【清单】。请测算购买后各月现金余量和应急资金变化,写清假设与遗漏项。只做预算影响分析,不评价借贷是否合适。
场景 26|比较一次性购买和长期订阅哪个更划算
请比较【一次性方案】和【订阅方案】,价格、使用频率、预计期限、续费条件和退出成本如下【资料】。计算不同使用期限下总成本和盈亏平衡点。价格/条款不清时列待核验项,不默认我会持续使用。
场景 27|帮我计算一个长期消费的真实成本
我考虑【长期消费/服务】,初始费【金额】,周期费用【金额】,预期使用【时长】,另有维护、税费或退出费用【信息】。列出“初始费+周期费×期数+维护/税费+退出费”的计算式和每项数值,给出总成本、月均/年均成本,以及不同使用年限下的结果。价格变化、折扣和提前终止单列情景;缺失费用标为待查,不当作零。
场景 28|整理家庭固定支出和可变支出
根据这份脱敏流水【记录】和账单【账单】,整理家庭支出。区分每月固定、周期性但非月度、可变和一次性项目。注明金额、扣款日、合同期限、可取消性及信息来源,输出下月现金流提醒。
场景 29|为某个大额购买制定攒钱计划
我计划在【日期】前购买【目标】,预计总成本【金额】,现有专款【金额】,每月可结余【范围】,同时必须保留【应急储备】。请计算可行的储蓄进度、每月检查点和超支备选方案。不假设收益率或推荐金融产品。
场景 30|找出日常生活中可以减少的无效支出
这是最近【周期】的脱敏支出汇总【数据】,我的优先目标是【目标】。找出可能低使用率、重复订阅或可替代支出,提供“可取消/先试减/保留”建议及验证周期。不要仅因金额小就判定无效,也要说明生活质量权衡。
04旅行与出行规划
场景 31|根据天数规划一份旅行路线
我计划在【日期】去【目的地】共【天数】天,同行【人数/成员】,兴趣【偏好】,已订交通住宿【信息】。请按地理位置和开放时间排路线,估算每日移动强度并留出缓冲。营业时间和票务需核验官方渠道。
场景 32|根据预算设计一次旅行
旅行目的地【地点】、日期【日期】、人数【人数】,总预算上限【金额】,偏好【偏好】。请拆分交通、住宿、餐饮、门票和机动费用,给预算内行程与超支优先删减项。当前票价、签证或入境要求需查官方最新信息并注明日期。
场景 33|根据兴趣决定一个城市怎么玩
我到【城市】停留【时长】,喜欢【兴趣】,不喜欢【活动】,住宿大致在【区域】。请推荐按兴趣组合的游览区域和活动,说明各自耗时、交通及适合时段。避免仅堆景点,开放状态需在出发前核实。
场景 34|帮我安排一天不赶时间的旅游行程
我将在【城市/区域】有一天,起点【地点】、结束地点【地点】,同行情况【信息】,节奏希望【轻松程度】。每天最多安排【数量】个主要活动,留出用餐、休息和天气备选。给交通衔接与删减顺序。
场景 35|比较两个旅游目的地的区别
比较【目的地A】与【目的地B】供【日期/季节】旅行,同行者【情况】、预算【金额】、兴趣【偏好】。按交通、气候、花费、活动、体力要求和预约难度对比。季节性与入境信息用官方来源核验,最后按不同优先条件给选择建议。
场景 36|根据出行人数整理旅行物品清单
我们有【人数】人,去【目的地】旅行【天数】,天气和活动【信息】,交通方式【方式】。按证件、衣物、药品/急救、电子设备和儿童/老人特殊用品整理清单,标明共用与每人份。药物建议只做携带提醒,不替代医生意见。
场景 37|帮我检查旅行前还有什么没有准备
出行信息是【目的地、日期、人数、交通、住宿】,目前已办【事项】。请按出发前、途中、到达后检查证件、订单、交通衔接、通信、支付和紧急联系人。签证、法规、天气和营业状态必须核验官方最新来源。
场景 38|根据航班或火车时间安排前后行程
我的交通信息【班次、起降/到站时间、机场/车站】,住宿【地址/入住时间】,还有【接送/活动】安排。请计算合理到达、换乘和缓冲时间,考虑行李与交通延误。时刻表和入场规定需以承运方/场馆当前信息为准。
场景 39|设计适合带老人或孩子的轻松路线
同行有【老人/孩子年龄与行动需求】,目的地【地点】,行程【天数】,体力和休息偏好【情况】。请设计低切换、少排队的路线,标休息点、无障碍/婴儿设施核验项和退出方案。健康需求请由家属/专业人员确认。
场景 40|将一堆想去的景点整理成合理路线
我想去【景点清单】,旅行日期【日期】、住宿位置【区域】、每日可用时长【时长】。请按距离、开放时间、预约和兴趣重排,说明每个景点的取舍与交通方式。最新开放/预约规则需核实,给下雨或闭馆备选。
05吃饭、买菜与做饭
场景 41|根据冰箱现有食材决定今天吃什么
冰箱里有【食材及数量】,需在【时间】内做饭,人数【人数】,口味/过敏限制【信息】,厨具【设备】。请给两种可行菜式和步骤,优先使用易坏食材。若食材状态不安全,提醒丢弃而不是提供风险处理技巧。
场景 42|根据几种食材生成简单菜谱
我有【食材/数量】,可用调料【清单】和厨具【设备】,想做【口味/用餐人数】。请给一道步骤不超过【数量】步的家常做法,标出火候、替代材料和大致耗时。食品安全关键温度/保存信息不确定时提示核验权威指南。
场景 43|帮我安排一周家常菜单
请为【人数】人安排【天数】天家常菜单,预算【金额】,饮食偏好/过敏【信息】,每天做饭时间【时长】。兼顾食材复用、营养多样和操作难度,给每日三餐或晚餐菜单及备菜建议。涉及疾病饮食请先咨询医疗专业人员。
场景 44|根据人数计算大概需要买多少菜
我要为【人数】人准备【餐次/菜品】,其中有【儿童/老人/特殊食量】。请按常见份量估算每种食材购买量,列出估算依据和可调整范围。若提供实际菜谱,请优先按菜谱换算,不把估算当精确营养处方。
场景 45|生成一份一周买菜清单
根据菜单【菜单】为【人数】人生成一周买菜清单,已有库存【食材】,预算【金额】。合并重复食材,给建议数量、适合购买的时间和易腐品优先顺序。把不确定份量单独标出,便于到店调整。
场景 46|把一道复杂菜改成家常简单做法
请把【菜名/原做法】改成适合【厨艺水平】、只有【厨具】、最多用【时间】完成的家庭版。保留关键风味步骤,标出可以省略或替换的环节及会造成的差别。生熟处理和过敏信息要清楚。
场景 47|根据厨具条件推荐能做的菜
我能使用的厨具只有【厨具】,现有食材【清单】,可做饭时间【时长】,口味限制【信息】。请推荐【数量】道能实际完成的菜,列步骤、用具和共用备料。不推荐需要额外设备或未提供食材的做法。
场景 48|利用剩菜剩饭设计下一顿饭
目前剩下【熟食/食材】、存放时间与方式【信息】,家里还有【材料】。请先判断已知保存信息是否足以安全使用。不确定或超出安全条件就建议丢弃。若可使用,给一个充分加热、避免交叉污染的下一餐方案。
场景 49|根据预算设计一桌家常饭菜
我要为【人数】人安排一桌预算不超过【金额】的家常饭,场合【场景】,已有食材【清单】,忌口【信息】。请搭配主食、荤素菜和汤/替代项,估算采购量与费用区间,注明价格因地区和日期变化需现场核对。
场景 50|判断几道菜怎么搭配更合理
现有菜品/候选菜【清单】,用餐人数【人数】,场景【场景】,饮食限制【信息】。请从口味、主配菜、份量和制作时间检查搭配,给出删减或替换建议。营养信息如无可靠数据只做一般性描述。
06居家整理与家庭事务
场景 51|制定一次全屋整理计划
我要整理【房屋面积/房间】,可投入【时间】和【人数】,最困扰的区域是【区域】。请按区域、物品类别和先后依赖分批安排,每批给结束标准、收纳材料和休息点。避免一次性把全屋物品清空造成无法恢复。
场景 52|判断哪些东西应该保留或丢掉
我在整理【物品类别】,判断困难的原因是【情况】,存放空间【限制】。请设计简单决策问题,分别处理常用、备用、纪念和待确认物品。涉及证件、药品、贵重物或他人物品时增加核对步骤,不直接建议丢弃。
场景 53|设计一个容易坚持的家庭清洁计划
家庭成员【人数/作息】、房间【清单】、宠物/过敏情况【信息】,每周可投入清洁时间【时长】。请把日常、每周和月度任务分配到现实时段,明确责任轮换和最低可行版本。清洁剂混用风险要提醒按标签使用。
场景 54|根据房间情况规划收纳方式
房间尺寸与布局【描述/尺寸】,常放物品【清单】,使用者【成员】,预算【金额】。请按使用频率和动线设计收纳位置,优先利用现有家具。标出需实测的尺寸、承重和安全固定问题,不推荐影响通道或消防出口的方案。
场景 55|搬家前生成完整打包清单
我将在【日期】从【住所类型】搬到【新住所】,家庭成员【人数】,搬运方式【方式】。请按证件贵重物、易碎品、日用品、家具、电器和清洁分组列清单,标打包时间、箱号和开箱优先级。提醒确认物业/运输规则。
场景 56|搬家后生成开箱和整理顺序
新家【房间与设施情况】,搬入物品【概况】,入住人数【人数】,接下来【日期】有【安排】。请按安全、睡眠、洗漱、做饭、工作和美观排序开箱,给每阶段完成标准。预留破损登记、设备测试和包装回收步骤。
场景 57|帮我制定家庭常用物品采购清单
家庭成员与生活习惯【情况】,现有库存【清单】,每月采购预算【金额】。请整理常备消耗品、低频备用品和按需购买品,估计补货触发点及安全储存提醒。避免重复采购,危险品与儿童/宠物接触风险单独标出。
场景 58|规划一次低预算房间改造
我想改造【房间】,现状问题【问题】,尺寸/租住限制【信息】,预算上限【金额】,能自己施工的范围【范围】。请按影响和成本排序提出方案,区分无需施工、可逆改造和需专业施工。电气、承重或消防事项建议由合格人员核验。
场景 59|分析一个房间为什么总是显得乱
房间照片/布局描述【材料】,常用物品【清单】,日常动线【描述】,整理习惯【情况】。请从物品无固定位置、容量不足、拿取麻烦、视觉杂乱和家庭分工等角度诊断。先给无需购买的调整动作,再给需补充信息。
场景 60|根据家庭需求重新规划空间用途
房屋户型【描述/图示】,成员和活动需求【清单】,限制条件【预算/租赁/采光】。请提出空间用途方案,说明动线、隐私、噪音、储物和可逆性。对尺寸和结构的判断需现场测量,涉及拆改需核验物业与专业要求。
07社交与人际沟通
场景 61|帮我想怎么回复一条不知道怎么回的消息
对方发来【消息】,我们的关系是【关系】,我真正想表达【意思】,希望达到【结果】。请给一条自然、不冷淡也不过度承诺的回复。再给简短和更正式版本,模糊处先指出,不替我揣测对方动机。
场景 62|把一句容易让人误解的话说得更合适
这句话【原话】准备发给【对象】,背景【背景】,我想表达的重点是【重点】。请保留意思,消除可能被理解为指责、讽刺或命令的部分。提供自然版和明确版,并说明哪些词可能引起误解。
场景 63|帮我礼貌拒绝一个邀请
【对象】邀请我参加【活动】,我不能/不想参加的真实原因是【原因】,关系维护目标【目标】。请写简短礼貌的拒绝,表达感谢但不编借口。若愿意改约,提供具体替代时间,否则不要留模糊承诺。
场景 64|帮我邀请朋友参加一次聚会
我想邀请【对象】参加【活动】,时间地点【信息】,活动风格【描述】,需要对方准备【事项】。请写一条轻松清楚的邀请,交代回复截止时间和费用/交通等重要信息。分别给熟人版与较正式版。
场景 65|帮我表达感谢但不要太客套
【对象】做了【具体帮助】,对我带来的实际影响是【影响】,沟通渠道【当面/消息】。请帮我写一段真诚简洁的感谢,具体说出我感谢什么。避免夸张和模板话,可提供一句短版。
场景 66|帮我向别人道歉但不要过度卑微
我在【情境】中做了【具体行为】,造成的影响可能是【影响】,目前已采取【补救】。请写一段承担责任的道歉:指出行为、承认影响、说明补救和后续做法。不要为自己开脱,也不要承诺无法保证的事。
场景 67|帮我处理一次尴尬的聊天
最近我和【对象】因【情境】聊天变得尴尬,已发生的对话【简述】,我希望【关系目标】。请提供一个自然重启对话的方式和一个尊重对方空间的备选。不要推断对方心理或制造操控话术。
场景 68|帮我委婉提醒别人一件事
我需要提醒【对象】关于【事项】,约定/影响是【事实】,希望对方在【日期】前【行动】。请写友善明确的提醒,避免责备。若对方可能没看到,再给一个简短跟进版本。
场景 69|把情绪化的话改成正常沟通
我现在想说【情绪化原话】,发生的事实是【事实】,我希望对方【具体行动】。请先保留合理诉求,改写成“事实—影响—请求”的表达,再给一个需要设边界的版本。不要否定我的感受或放大冲突。
场景 70|分析一次沟通为什么会产生误会
这次对话【对话内容/摘要】,双方关系与背景【信息】,我的理解是【理解】。请区分原文事实、双方可能的不同假设和真正未说清的词。提供一条低冲突的澄清消息,不断言任何人的意图。
08学习与知识获取
场景 71|用零基础能理解的方式解释一个概念
请向没有【领域】基础的人解释【概念】,目的是帮助我【任务】。先用一句话定义,再拆解关键组成,给一个准确、日常的例子和一个不适用的情况。术语首次出现时解释,避免错误类比。
场景 72|用生活中的例子解释一个复杂知识
我想理解【知识点】,目前卡在【困惑】。请用贴近【生活/工作场景】的例子解释机制,指出例子与真实概念不完全相同的地方,再用一个小问题检查我是否理解。若例子会误导,请换更准确的说明。
场景 73|给我设计某个领域的入门学习路线
我想入门【领域】,已有基础【情况】,希望达到【可观察目标】,每周能学【时长】。请按先修知识、核心主题、实践项目和复盘节点排路线,建议可靠教材/官方文档并核验版本。不要堆课程链接。
场景 74|判断学习一个技能应该先学什么
我想学【技能】,最终要能完成【任务】,当前水平【水平】,可用工具【工具】。请拆出完成任务所需的子技能,按依赖与练习反馈排序。说明哪些知识暂时可跳过,并给本周第一个小练习及通过标准。
场景 75|根据一本书生成阅读重点
我准备读【书名/版本】,想解决【问题】。请基于我提供的目录/摘录【材料】规划阅读重点:哪些章节优先、每章要回答的问题和可跳读部分。没有书籍内容时不要假装读过,版次与事实需核验。
场景 76|整理刚学完内容的知识框架
我刚学完【主题】,笔记/材料是【内容】,需要用于【复习/应用】。请按概念、关系、流程、条件和例子整理成层级大纲,标出易混点和我尚未理解的缺口。不要把未提供内容补成确定知识。
场景 77|根据知识点给我出练习题
请围绕【知识点】为【水平】设计【数量】道递进练习题,目标是检查【能力】。每题给题型和考查点,先不要展示答案。等我作答后逐题解释错误原因,并给一条针对性复习建议。
场景 78|用问答方式检查我是不是真的学会了
请通过逐题问答检查我是否掌握【主题】,我的目标水平是【标准】。一次只问一个问题,从基础到应用逐步加难。根据回答调整下一题,最后按已掌握、需复习、尚未覆盖总结,并给出证据。
场景 79|把零散知识整理成方便复习的笔记
请把这些学习材料【笔记/摘录】整理成便于【考试/工作应用】的复习卡片。每张卡只问一个问题,答案简洁且可自测。术语、公式和出处保持准确,材料没有解释的地方列为待补,不要补造定义。
场景 80|帮我找到一个知识点之间的关联
我想理解【知识A】和【知识B】之间的关系,背景是【学习/应用任务】。请从共同问题、前置关系、机制差异、适用范围和相互作用比较。给一个能检验关系的实例,并指出哪些关联只是类比或推断。
09语言与表达训练
场景 81|把一句中文翻译成自然英文
请将这句话译成适合【场景/对象】的自然英文:【中文原句】。【中文原句】。保留语气、事实和礼貌程度,不逐字硬译。给一个首选版本和一个更正式/口语备选,并解释可能有歧义的表达。
场景 82|把生硬的英文改成常用表达
请润色这段英文【文本】,使用场景是【邮件/演讲/聊天】,读者是【对象】。保留原意和专业术语,改成自然常见表达。逐项说明重要修改,无法判断语境的句子请提问,不改变承诺强度。
场景 83|解释一句英文到底是什么意思
请解释这句话【英文句子】在【上下文/场景】里的意思。先给自然中文释义,再拆关键短语、语气和可能的隐含条件。如果没有足够上下文,请列出不同解释及判断线索,不武断选一个。
场景 84|帮我区分几个容易混淆的英文词
我总把【词A】【词B】【词C】混淆,使用场景【场景】。请比较词义、搭配、正式程度和常见误用,每个词给两句短例句及中文解释,最后出三道填空题检验区别。
场景 85|根据场景教我最自然的英语说法
我需要在【场景】对【对象】表达【中文意思】,希望语气【礼貌/坚定/轻松】。请给最自然的英文表达、一个直接版和一个更委婉版,说明使用差别。不要使用过时或地区不匹配的说法,地域不明时标注差异。
场景 86|陪我进行一次英语日常对话练习
请和我练习【场景】英语对话,我的水平【水平】,目标是【能力】。你扮演【角色】,每次只说一句并等我回答。先自然交流,结束后纠正最影响理解的错误并给更地道表达,不在中途打断。
场景 87|帮我纠正一段英文中的语法问题
请检查这段英文【文本】,用途【场景】,目标读者【对象】。按句标出语法、拼写、搭配和清晰度问题,给修正版并解释规则。保留作者风格,区分必须修改与可选润色。
场景 88|根据我的水平生成英语阅读材料
请为【英语水平】生成一篇关于【主题】的【字数】词阅读材料,用于练习【词汇/理解/考试】。控制词汇难度,必要生词给释义。文后出理解题与答案,标出可能不自然或存在争议的表达。
场景 89|从一篇文章中提取值得学习的表达
从这篇英文材料【文本】中提取适合我学习的表达,水平【水平】,目标【用途】。每项列原句、语境含义、常见搭配和自创例句。保留来源语境,不将专有表达误当通用规则。
场景 90|用简单英语重新解释复杂英文内容
请把这段复杂英文【文本】改写成适合【水平】读者理解的简单英语。保留原有结论、条件和术语含义,难词用简单词替换或解释。另附中文要点,标出删减后可能失去的细节。
10兴趣、娱乐与个人创作
场景 91|根据我的兴趣推荐今天可以做什么
我现在在【地点】,可用时间【时长】,预算【金额】,最近感兴趣的是【爱好】,不想做【限制】。请推荐几件今天能实际开始的活动,按室内/室外和独处/社交分类。需要预约或营业信息时提示核验。
场景 92|推荐适合某种心情看的电影
我现在的心情/想要的观影体验是【描述】,可接受类型【类型】,不想看到【内容】,观看平台【平台】。请推荐【数量】部并解释匹配原因、节奏和内容提醒。上映、片源和年龄分级等当前信息要核实,别剧透关键情节。
场景 93|根据几部喜欢的作品推荐类似作品
我喜欢【作品A】【作品B】【作品C】,尤其喜欢【具体元素】,不喜欢【元素】。请分析共同偏好后推荐作品,逐部说明相似点和差异。不要只按题材匹配,作品是否可观看及地区片源需核验。
场景 94|帮我制定一个阅读书单
我想围绕【主题】阅读,当前基础【水平】,目标【目标】,每月能读【数量/时间】,偏好【偏好】。请按入门、深入和不同观点安排书单,解释排序与适读对象。核实作者、版本和出版信息,不确定的书目标明待查。
场景 95|根据一个灵感帮我扩展成完整创意
我的初始灵感是【灵感】,准备做成【作品形式】,面向【受众】,限制【时间/资源】。请提供 3 个不同方向,每个写核心体验、展开步骤、所需素材和可能风险。保留原灵感,不套用现成作品的独特表达。
场景 96|帮我设计一次周末家庭活动
家庭成员【人数/年龄】,活动日期【日期】,地点范围【范围】,预算【金额】,偏好和限制【信息】。请设计包含集合、活动、用餐和返程的轻松计划,给天气/体力备选。票价、开放和交通信息需现场或官方核实。
场景 97|为一次聚会设计有趣的小游戏
聚会人数【人数】,年龄/关系【情况】,场地【场地】,总时长【时长】,希望氛围【氛围】。请设计【数量】个规则简单、无需昂贵道具的游戏,写清准备、步骤、计时和退出方式。避免涉及隐私、羞辱或强迫参与。
场景 98|根据照片帮我想朋友圈或社交平台文案
这张照片内容是【描述】,发布平台【平台】,我想表达【情绪/信息】,受众【对象】。请写【数量】条自然文案,分别偏简洁、轻松和有细节。不推断照片里未说明的人物关系、地点或经历。
场景 99|帮我给照片、相册或作品起名字
请为【照片/相册/作品】起名,内容和创作意图是【描述】,希望风格【风格】,使用场景【场景】。给【数量】个不超过【长度】的候选,说明含义与适配点。避开未经授权的人名、品牌或容易误读的词。
场景 100|根据过去一段时间的经历整理生活回顾
请根据我的【日记/照片说明/事件记录】整理【周期】的生活回顾,用于【个人回顾/分享】。请按重要变化、完成的事、未完成原因、学到的经验和下阶段关注点整理。仅根据我提供的信息,不编故事或把困难强行包装成成长。
生活安排与消费测算最终都要回到自己的真实条件。涉及价格、合同、旅行规定或服务条款的内容会变化,复制 Prompt 后最好把核验来源和日期也一并要求出来。
理解数据漂移与模型漂移:用 Python 进行漂移检测
模型上线,并不意味着工作结束。
离线测试时 AUC、F1、MAE 都很漂亮,真正跑进生产环境几个月后,效果却可能一点点变差。更麻烦的是,代码没有报错、接口没有超时、服务也一直在线,模型甚至还在正常返回结果。
问题往往不在“模型坏了”,而在于模型面对的世界已经变了。
用户变了,业务规则变了,设备和渠道变了,数据采集方式变了,甚至“什么样的输入对应什么样的答案”也变了。模型仍然按照训练时学到的规律工作,但这些规律未必还适用于今天。
这类变化通常被统称为 Drift(漂移)。
理解漂移,真正重要的并不是记住几个统计检验,而是回答三个问题:
到底是输入数据变了,还是输入与目标之间的关系变了? 检测到分布变化,是否意味着模型性能一定下降? 当真实标签不能及时拿到时,生产系统应该监控什么?
下面从这三个问题出发,把数据漂移、概念漂移、常见检测方法,以及 Python 中如何落地讲清楚。
01先把“漂移”和“模型变差”分开
很多介绍会直接把漂移理解为“模型准确率随时间下降”,但严格来说,这两件事并不完全等价。
漂移描述的是数据或数据关系发生变化;模型性能下降描述的是这种变化最终对模型造成的结果。
一个很重要的现实是:
检测到数据漂移,不代表模型一定已经失效。
比如一个贷款模型使用年龄、收入、负债率等特征。某段时间用户年龄分布发生明显变化,但模型真正依赖的是收入和负债率,那么年龄漂移可能很明显,模型性能却几乎不受影响。
反过来也可能发生:几个输入特征的边际分布看起来都没有明显变化,但它们和目标变量之间的关系已经发生改变,模型性能仍然会下降。
因此,生产监控最好不要采用“发现某个特征漂移 → 立即重新训练”的简单逻辑,而是把漂移看成一个风险信号和排障线索。
如果已经能够拿到真实标签,应优先观察模型本身的性能指标;如果标签存在几天、几周甚至几个月的延迟,再通过输入漂移、预测漂移、数据质量等信号提前发现异常。
02三种最值得区分的漂移
用概率分布来表示,会更容易看清它们之间的差别。
训练数据可以看成来自一个联合分布:
其中:
是输入特征; 是真实目标; 描述输入数据怎么分布; 描述“什么样的输入更可能对应什么结果”。
生产环境发生变化,本质上就是这些分布中的某一部分发生了变化。
1. 数据漂移:输入的人群变了
数据漂移(Data Drift,也常称 Covariate Shift)通常指:
也就是生产环境里的输入分布,和训练时不一样了。
例如一个电商购买预测模型,训练时用户主要来自一二线城市;几个月后产品开始大规模下沉,新用户的年龄、地区、设备类型、消费能力都发生变化。
模型代码没有变,但它面对的数据已经不是原来那批数据。
常见原因包括:
用户结构发生变化; 新渠道或新地区上线; 季节、节假日带来周期性变化; 上游采集系统或埋点发生调整; 传感器老化、设备更换; 数据清洗和特征工程逻辑发生变化。
这里尤其要注意最后两类情况。
因为有些“漂移”其实不是业务世界变了,而是数据管道变了。比如某个字段从元改成分、缺失值填充策略发生变化、类别编码顺序被修改。这类问题通常应该先按数据质量故障处理,而不是急着重新训练模型。
2. 目标漂移:结果的基础比例变了
目标漂移(Target Drift / Prior Probability Shift)指:
比如欺诈检测模型训练时,欺诈订单占 1%,某段时间突然上升到 5%;或者一个用户流失模型面对的整体流失率发生明显变化。
这类变化有时会直接影响模型阈值、校准结果和业务策略。
实际监控中,如果真实标签能较快返回,目标分布本身就是一个很值得观察的信号。
如果标签迟迟拿不到,也可以先观察预测结果的分布。预测漂移不能证明目标真的变了,但在没有标签时,它经常能提供一个比较及时的代理信号。
3. 概念漂移:规则本身变了
概念漂移(Concept Drift)更麻烦,它指的是:
也就是输入和结果之间的关系发生了变化。
比如垃圾邮件识别模型过去发现“免费”“中奖”“点击链接”等模式很有效,但攻击者逐渐改变话术,旧特征仍然存在,垃圾邮件的表达方式却已经变了。
再比如信用风险模型中,同样的收入、负债和职业信息,在不同宏观经济周期里可能对应不同的违约概率。
这时并不是简单的“用户群变了”,而是模型当初学到的规律已经过时。
概念漂移通常还可以按变化过程分为:
突变式漂移:某个时间点前后规律快速切换; 渐进式漂移:新旧模式在一段时间内同时存在,新模式逐渐占主导; 增量式漂移:数据关系持续、缓慢地朝一个方向变化; 概念再现:旧模式在某个时间段重新出现,比如明显的季节性业务。
这也是为什么“固定每三个月重新训练一次”并不总是理想。不同业务的漂移速度完全不同,更合理的方法通常是根据性能和漂移信号决定什么时候进入调查、校准或重训练流程。
03LLM 时代,漂移又多了一层
到了大语言模型应用,事情会更复杂一些。
传统机器学习通常监控结构化特征,而 LLM 系统面对的是自然语言、Embedding、检索文档、Prompt、模型 API 和自动评估器。任意一层变化,都可能让最终输出质量下降。
其中比较值得监控的有四类。
输入和意图漂移
表面上看,用户输入仍然是一段文本,但用户真正提出的问题可能已经变了。
比如一个内部编码助手最初主要服务后端工程师,半年后数据分析人员大量进入,问题逐渐从 Java、Go 转向 SQL、Pandas 和数据处理。
平均文本长度可能几乎没变,但任务分布已经完全不同。
一种简单做法是给请求做意图分类,再监控不同意图所占比例。相比只统计字数、语言或请求量,这更接近实际业务变化。
Embedding 漂移
文本可以先转换为高维向量,再比较参考窗口和当前窗口中的 Embedding 分布。
这类方法对于 RAG、语义搜索、分类和推荐系统尤其有用,因为原始文本即使表面差异很大,也可能表达相同含义;反过来,相似的文字也可能对应完全不同的任务语义。
实践中可以使用距离度量、降维后的分布比较,或者训练一个二分类器判断某条样本来自“参考期”还是“当前期”。
如果分类器很容易分辨两批数据,通常意味着二者存在明显的整体分布差异。
检索语料漂移
RAG 系统还有一个传统模型不太明显的问题:知识库本身也在变化。
旧文档没有下线、新旧制度同时存在、索引更新不完整、Chunk 策略被修改,都可能导致检索结果和几个月前完全不同。
所以只监控用户输入还不够,还应该观察:
检索命中文档的来源分布; Top-K 结果的相关性; 无结果率和低相关结果比例; 新旧文档占比; 关键知识的覆盖情况。
很多所谓“模型突然变笨”,最后排查出来其实是检索层发生了变化。
评估信号漂移
生成式任务很难像分类任务一样实时拿到标准答案,因此越来越多系统会使用规则评估、人工抽检或 LLM-as-a-Judge 来持续观察质量。
这里要区分两件事。
如果同类输入上的自动评分持续下降,它说明系统输出质量可能发生了变化;但如果评估模型、评分 Prompt 或评分标准本身被修改,那么变化也可能来自评估器,而不是被评估系统。
所以生产环境最好把“被测模型版本”和“评估器版本”同时记录下来,否则时间一长,很难判断分数究竟为什么变了。
04真正的漂移监控,应该看哪些信号?
如果把生产模型看成一条完整链路,比较实用的监控顺序通常是:
数据质量 → 输入/预测分布 → 模型性能 → 漂移定位。
如果真实标签能够及时拿到,首先看业务真正关心的模型指标:
分类:Precision、Recall、F1、ROC-AUC、PR-AUC、校准误差; 回归:MAE、RMSE、MAPE 等; 排序/推荐:NDCG、Recall@K、CTR 等; LLM:任务成功率、事实正确性、拒答质量、人工评分等。
当这些指标下降时,再结合输入特征、目标、预测和分群的漂移去定位原因。
如果暂时没有标签,则可以先观察:
缺失率、异常值、字段范围等数据质量指标; 关键特征的单变量漂移; 多变量联合漂移; 预测分布变化; 用户群、渠道、地区等重要分群的变化; LLM 场景下的意图、Embedding、检索和自动评估信号。
这种方式比“每个字段都设一个报警器”更实用,因为后者很容易造成告警疲劳。
05常见的漂移检测方法
不同检测方法回答的问题并不完全一样。实际使用时,不需要寻找一个“万能算法”,而应该根据特征类型、样本规模和监控目的选择。
K-S 检验:判断两个连续分布是否不同
Kolmogorov-Smirnov 两样本检验是一种常见的非参数检验。
它比较两个经验累积分布函数之间的最大差异,原假设是:
两组样本来自相同的连续分布。
如果 p-value 很小,就有理由拒绝这个假设。
Python 中可以直接使用 SciPy:
from scipy.stats import ks_2samp
result = ks_2samp(
reference["age"].dropna(),
current["age"].dropna()
)
print("KS statistic:", result.statistic)
print("p-value:", result.pvalue)
不过 p-value 不能简单理解成“漂移有多严重”。
样本量很大时,非常微小、业务上几乎没有意义的差异也可能得到很小的 p-value;样本很小时,又可能检测不到真实存在的变化。
因此生产中通常会同时看统计显著性和变化幅度,而不是只设一个 p < 0.05 就结束。
PSI:简单、直观,但阈值不是自然定律
Population Stability Index(PSI)会先把变量分桶,再比较参考数据和当前数据在各个桶中的占比差异。
它在信用评分和风控领域使用非常广,也常被用于模型监控。
常见经验规则会把 PSI 粗略解释为:
小于 0.1:变化较小; 0.1~0.2:出现一定变化; 大于 0.2:变化比较明显。
但这些值本质上是经验阈值,不是适用于所有业务的数据定律。
分桶方式、样本量、变量本身的波动性,都会影响 PSI。因此更稳妥的做法是先用历史正常数据建立基线,再结合业务容忍度确定阈值。
Wasserstein 距离:直接衡量“搬动分布要走多远”
Wasserstein Distance 也叫 Earth Mover's Distance。
可以把两个分布想象成两堆土:要把第一堆土搬成第二堆土的形状,最少需要做多少“搬运工作”。
它非常适合连续数值变量,因为结果直接反映两个分布之间的距离,而且不像 p-value 那样随着样本量增大就天然变得更敏感。
JS 散度:适合比较概率分布
Jensen-Shannon Divergence 基于 KL Divergence,但它是对称的,而且不会像 KL 那样因为某些概率为 0 而直接变成无穷大。
对类别变量、离散分布,以及经过分桶后的数值变量都比较常用。
Page-Hinkley:更适合连续监控时间序列
前面几种方法通常是在比较“参考窗口”和“当前窗口”。
Page-Hinkley 则更接近在线变化检测:数据不断流入时,它持续累计偏离程度,用来发现序列均值发生了明显变化。
它适合监控:
实时预测误差; 传感器数据; 连续业务指标; 流式学习场景。
不过它对阈值比较敏感。阈值太低容易频繁误报,太高又可能错过真正变化,因此需要结合历史数据调参。
06单变量没有漂移,不代表整体没有变化
生产中还有一个很容易忽略的问题:逐个特征检查,只能看到单变量漂移。
假设模型有两个特征 和 。
它们各自的分布都没有明显变化,但两者之间的相关关系发生了改变,那么模型看到的联合数据结构已经变了。
这时逐列 K-S、PSI 可能全部正常,但模型仍然处在训练时没有见过的数据区域。
一个常见的多变量检测思路是“域分类器”:
给参考数据标记为 0; 给当前数据标记为 1; 把两批数据混在一起训练一个二分类器; 看分类器能不能轻松区分两批数据。
如果分类器的区分能力接近随机,说明两批数据整体比较相似;如果区分能力很强,说明联合分布很可能已经发生变化。
对 Embedding 等高维数据,这种方法也很常见。
07参考窗口怎么选,比算法本身更重要
很多漂移系统效果不好,问题并不出在 K-S、PSI 或 Wasserstein,而出在比较对象选错了。
通常需要两个窗口:
Reference Window:认为模型表现正常的一段基准数据; Current Window:最近一段需要监控的数据。
Reference 不应该简单理解成“所有训练数据”。
比如电商业务有明显季节性,如果拿春节期间的数据和普通工作周直接比较,检测器几乎一定会报警,但这种变化本来就是正常业务周期。
实际可以采用几种策略:
当前周 vs. 上周; 当前月 vs. 去年同期; 当前窗口 vs. 训练集中的对应季节; 当前窗口 vs. 最近一段确认性能正常的数据; 同时保留短期基线和长期基线。
窗口也不能过小,否则统计量波动太大;但过大又会把短暂异常平均掉。
所以真正成熟的漂移监控通常不会只设置一套窗口。
08用 Evidently 快速生成数据漂移报告
如果不想自己维护每一套统计检验,可以使用开源工具 Evidently。
它可以对数值、类别、文本和 Embedding 数据做评估,并通过 DataDriftPreset 快速生成漂移报告。
下面继续使用 Adult 数据集构造一个简单示例。
1. 准备数据
import numpy as np
from sklearn import datasets
adult_data = datasets.fetch_openml(
name="adult",
version=2,
as_frame=True
)
adult = adult_data.frame
# 人为构造两批分布不同的数据
adult_ref = adult[
~adult.education.isin(
["Some-college", "HS-grad", "Bachelors"]
)
].copy()
adult_cur = adult[
adult.education.isin(
["Some-college", "HS-grad", "Bachelors"]
)
].copy()
# 再人为制造一部分缺失值
adult_cur.iloc[:2000, 3:5] = np.nan
这里的目的不是模拟真实业务,而是人为构造两批差异比较明显的数据,方便观察漂移报告。
2. 运行 DataDriftPreset
from evidently import Report
from evidently.presets import DataDriftPreset
report = Report(
[DataDriftPreset()],
include_tests=True
)
result = report.run(
adult_cur,
adult_ref
)
result
Evidently 会根据列类型和配置计算各列的漂移情况,并汇总整个数据集的漂移结果。
如果希望明确使用某一种方法,也可以在 DataDriftPreset 中指定,例如:
report = Report(
[DataDriftPreset(method="psi")],
include_tests=True
)
不过在真实项目里,不建议为了“统一”而强制所有字段都使用同一种方法。
连续数值、低基数类别、高基数类别、文本和 Embedding 的统计性质并不一样。更合理的做法通常是按数据类型选择方法,并为关键字段单独定义阈值。
3. 导出结果
result.save_html("data_drift_report.html")
json_result = result.json()
HTML 适合人工分析,JSON 则更适合接入监控平台、CI/CD 或告警系统。
但不要把“报告显示 Drift = True”直接等价为“自动重训”。
更稳妥的流程应该是:
检测到异常
↓
确认数据质量
↓
确认漂移发生在哪些关键特征 / 分群
↓
检查模型性能或获取标签
↓
判断是否需要调阈值、重新校准、更新数据或重新训练
漂移检测的价值,更多在于尽早发现生产环境正在离开模型熟悉的区域,而不是替代对模型性能的判断。
09生产环境里,什么时候应该重新训练?
“漂移了就重训”听起来很合理,但实际往往太粗糙。
重新训练至少应该同时考虑三件事:
第一,性能是否真的下降。
如果指标稳定,仅仅有一个不重要特征发生漂移,重训的收益可能很小。
第二,漂移是否影响模型真正依赖的区域。
关键特征、高重要性特征、核心用户群发生变化,比边缘字段的小幅波动更值得关注。
第三,新数据是否已经足够代表新的环境。
漂移刚发生几天就立即重训,可能只是把一次短期活动、节假日或异常事件写进模型。
因此,更合理的生产策略通常是:
漂移作为预警; 性能作为核心判断; 业务影响决定优先级; 重训只是修复手段之一。
有时候真正需要做的是修复上游数据、重新校准阈值、更新特征工程、调整 RAG 索引,甚至只是等待短期波动结束。
10写在最后
模型在训练完成的那一刻,学习到的其实只是过去某个时间窗口里的世界。
真正困难的是上线以后。
数据持续变化、用户持续变化、业务持续变化,而模型不会因为环境变化自动知道自己的认知已经过时。
所以漂移监控真正要解决的,并不是“有没有一个统计量超过阈值”,而是建立一套持续判断机制:
现在的数据还像训练时吗?模型还可靠吗?如果不可靠,问题到底发生在哪一层?
把这三个问题持续回答好,模型监控才真正从“看几个指标”进入生产级 MLOps。
参考资料
Jie Lu, Anjin Liu, Fan Dong, et al. Learning under Concept Drift: A Review. SciPy Documentation: scipy.stats.ks_2samp.Evidently Documentation / Open-source ML Observability Course: Data Drift、Embedding Drift 与 Drift Detection Methods. Evidently GitHub: DataDriftPreset当前 API 与示例。NannyML Documentation: Covariate Shift、Concept Drift 与模型性能监控。