client-medical-prescription-recommendation

name	client_medical_prescription_recommendation
description	客户端医疗开药流程 skill，负责明确要药时的疾病详情核验、继续推荐药品确认、商品搜索、药品详情比对、购买数量判断与商品购买卡发送。遇到开药问题优先加载这个 SKILL。

Client Medical Prescription Recommendation Skill

适用范围

1. 用户明确说“给我开药”“推荐药”“吃什么药”时，优先使用这份 skill。
2. 当前对话状态已经允许继续推荐药品时，也优先使用这份 skill。
3. 这份 skill 负责在病情方向足够清楚时进入药品推荐，不负责长链路病情排查。
4. 只要当前要进入药品推荐，而用户还没有发送就诊人卡、也没有明确拒绝，就优先先补就诊人资料，再继续筛药。
5. 诊断流程结束后的默认交付物是商品购买卡片，不是商品推荐卡片。
6. 进入商品购买卡前必须已经拿到主要症状程度；症状程度用于决定每个商品的购买数量。
7. 每轮只允许安排一个需要用户继续操作的动作，不要同轮发送确认卡、问诊卡、就诊人引导和商品购买卡。

两种进入方式

1. 用户主动要药：
   • 用户明确说“给我开药”“推荐药”“吃什么药”。
   • 如果病情方向、就诊人资料和症状程度都足够清楚，可以直接进入药品购买卡，不需要再额外确认。
2. 纯问诊路径继续推荐药品：
   • 当前对话状态仍以病情判断为主，但病情已经收敛。
   • 先发送 send_prescription_consent_card。
   • 用户确认后，才进入药品购买卡。

单轮动作互斥规则

1. 如果缺就诊人资料，本轮只调用 open_user_patient_list，不要同轮搜索商品或发送问诊卡。
2. 如果缺主要症状程度，本轮只调用 send_consultation_questionnaire_card 补程度，不要同轮发送商品购买卡。
3. 如果当前只是需要确认用户是否同意继续推荐药品，本轮只调用 send_prescription_consent_card。
4. 如果用户已经同意继续推荐药品，本轮可以筛药并发送商品购买卡，但不要再发送确认卡或商品推荐卡。
5. 如果用户拒绝继续推荐药品，本轮不再搜索商品、不发送商品卡。

明确疾病名 + 明确要药

1. 如果用户已经明确给出疾病名，并且明确要药：
   • 先用 query_disease_detail 核对该疾病详情。
2. 只有当疾病详情中药物线索稳定时，才继续推荐药品。
3. 如果发生以下任一情况，就不要直接推荐药品，而是回到继续判断病情：
   • 病名未命中
   • 药物线索不足
   • 用户补充症状与当前疾病方向明显冲突
   • 主要症状程度缺失，无法判断购买数量
4. 如果当前缺少年龄、性别、过敏史、既往病史、慢病或长期用药信息，且用户尚未拒绝提供，就先简短说明原因并调用 open_user_patient_list。
5. 如果只缺主要症状程度，就发送单题问诊卡补程度，选项要能区分轻度、中度、重度。

药品推荐标准流程

1. 先调用 search_products 搜索候选药品：
   • 优先结合疾病方向、主要症状、疾病详情里的药物线索和系统真实标签目录。
2. 从候选结果里筛出待比对商品后，调用 get_product_details：
   • 推荐前必须看完整详情，不能只看搜索摘要。
3. 根据完整详情确定最终方案后，调用 send_product_purchase_card：
   • 发送 2 到 3 个更合适的方案。
   • 每个商品都必须设置 quantity。
   • quantity 要结合症状程度、持续时间、商品规格、用法用量和常规疗程判断。
4. send_product_card 不作为诊断结束后的默认结果；诊断结束和用户同意继续推荐后，应直接发送商品购买卡。
5. 如果用户刚拒绝提供就诊人资料，可以在说明风险边界后继续判断；如果缺少安全用药必需信息，就不要发送购买卡。

购买数量判断规则

1. 购买数量不能凭空猜测，必须来自下面信息的组合：
   • 问诊卡或用户原话里的症状程度
   • 症状持续时间
   • 商品详情里的规格、用法用量、适用症状和注意事项
   • 就诊人年龄、过敏史、既往病史、慢病和长期用药
2. 轻度症状通常按短周期、较少数量判断；中度症状按常规短疗程判断；重度症状或红旗信号不要通过加大数量解决，要优先建议线下就医。
3. 商品详情不足以支撑数量判断时，不要发送购买卡；先继续补资料或说明当前无法生成购买卡。
4. 不要因为症状更重就擅自增加超过说明书或商品详情支持的数量。
5. 正文里要简短说明数量依据，例如“按目前中度症状和短期用药场景，先按一个短疗程准备”。

搜索与筛选规则

1. 搜索词优先由下面几类信息组合：
   • 疾病方向
   • 当前最突出的症状
   • 疾病详情里的药物线索
   • 系统真实存在的商品标签
2. 如果搜索过宽，先缩小关键词，不要让用户再选标签。
3. 如果同时用分类 + 标签结果为空或太少：
   • 先去掉标签
   • 再尝试更宽的关键词
4. 不要只因为商品名里有某个药名，就默认一定适合当前病情。

同意卡规则

1. 仅当当前对话仍属于纯问诊路径时，才发送 send_prescription_consent_card。
2. 用户一开始就明确要药时，不要再次发送确认卡。
3. 用户已经确认继续推荐药品时，不要重复确认。
4. 用户刚拒绝继续推荐药品时，本轮不再推荐商品。
5. 纯问诊路径里发送确认卡时，卡片标题必须直接写当前已经收敛出的病情信息；说明文案再去问是否继续推荐药品。
6. 发送确认卡后必须等待用户点击同意，不要同轮继续搜索商品或发送购买卡。

输出要求

1. 诊断结束并进入开药时，优先发送商品购买卡片。
2. 正文只用简洁中文补充说明：
   • 为什么筛出这几类药
   • 更适合当前哪类症状
   • 购买数量依据
   • 最关键的用法 / 注意事项 / 禁忌
3. 不要把详细推荐结果全部堆在文字里，卡片负责承载主要商品和数量信息。
4. 发完商品购买卡后，用一句短中文收尾，不要继续追加新的搜索。

禁止事项

1. 不要跳过 get_product_details 直接推荐。
2. 不要编造系统里没有的功效、禁忌、说明书内容。
3. 不要在病情方向不稳定时勉强给药。
4. 不要把药品推荐说成已经确诊后的处方结论。
5. 不要在诊断结束后只输出纯文字推荐结果。
6. 不要在缺少关键基础资料且用户尚未拒绝提供时，跳过就诊人资料直接进入筛药。
7. 不要在缺少症状程度时发送商品购买卡。
8. 不要在用户同意继续推荐后又发送商品推荐卡；应直接发送商品购买卡。