client-medical-diagnosis-consultation

star 4

客户端医疗诊断流程 skill,负责症状咨询、病情判断、疾病解释、追问策略、问卷卡使用和进入药品推荐前的判断。遇到诊断问题优先加载这个 SKILL。

lalala2726 By lalala2726 schedule Updated 4/27/2026

name: client_medical_diagnosis_consultation description: 客户端医疗诊断流程 skill,负责症状咨询、病情判断、疾病解释、追问策略、问卷卡使用和进入药品推荐前的判断。遇到诊断问题优先加载这个 SKILL。

Client Medical Diagnosis Consultation Skill

适用范围

  1. 用户主要在描述症状、问病情、问“我这是怎么了”、问是否像某个病时,优先使用这份 skill。
  2. 用户已经给出疾病名,但主要是在问症状、原因、区别、严重程度、注意事项时,也优先使用这份 skill。
  3. 这份 skill 只负责把病情方向看清楚,不负责直接进入商品推荐。

总体硬规则

  1. 只要当前任务仍属于病情判断,就必须先调用医学数据查询类工具,不允许只凭用户原话和常识直接判断。
  2. 只要还需要继续补信息,不管缺 1 个问题还是缺多个问题,都必须使用 send_consultation_questionnaire_card,不要直接文字追问。
  3. 文字输出只负责说明当前判断、解释结论和承接问诊卡,不负责逐条发问题。
  4. 只要当前任务属于症状判断、病情分析或后续荐药安全判断,且用户还没有发送就诊人卡、也没有明确拒绝,就优先引导用户发送就诊人卡。
  5. 需要就诊人资料时,先用一句简短中文说明原因,再调用 open_user_patient_list,不要先长篇解释。
  6. 用户明确表示先不提供就诊人资料后,本会话不要再次主动索取,除非用户自己发送就诊人卡。
  7. 用户刚完成问诊卡后,问卷里已经回答过的问题视为已确认信息,不要重复追问同一个问题或同义问题。
  8. 每轮只允许安排一个需要用户继续操作的动作,不要同轮同时打开就诊人列表、发送问诊卡、发送推荐药品确认卡或发送商品购买卡。
  9. 默认诊断顺序是先拿就诊人资料,再用问诊卡补症状和症状程度,再收敛诊断,再发推荐药品确认卡。

单轮动作互斥规则

  1. 如果缺就诊人资料,本轮只调用 open_user_patient_list,不要同轮发送问诊卡。
  2. 如果已经有就诊人资料,但缺症状细节或症状程度,本轮只调用 send_consultation_questionnaire_card
  3. 如果诊断已经收敛且允许进入开药确认,本轮只调用 send_prescription_consent_card,不要同轮发送问诊卡或商品购买卡。
  4. 如果用户拒绝提供就诊人资料,就不要反复索取;后续需要补症状时只发问诊卡。
  5. 如果用户拒绝继续推荐药品,本轮只给观察、护理或线下就医建议,不发商品卡。

诊断问题怎么判断

  1. 用户只描述不舒服、病情还不清楚:
    • 先进入病情判断流程。
  2. 用户已经给出疾病名,但主要是在问疾病解释:
    • 先进入疾病说明流程。
  3. 用户虽然提到了药,但当前信息仍明显不足以支撑选药:
    • 也先使用这份 skill,把病情方向补清楚。

红旗信号优先

  1. 先看有没有明显危险信号,例如:
    • 呼吸困难
    • 明显吞咽困难
    • 高热持续不退
    • 精神状态差
    • 症状急剧加重
  2. 如果存在明显红旗信号,优先建议尽快线下就医,再做简短解释。
  3. 命中红旗信号时,不要继续冗长追问,也不要进入药品推荐。

症状咨询流程

  1. 不管用户怎么描述,只要当前还在判断病情,先进入医学数据查询流程。
  2. 有可检索症状时,先调用 search_symptom_candidates
    • 只传症状关键词,不要把整句口语原样塞进去。
  3. 症状标准化后,再调用 query_disease_candidates_by_symptoms
    • 第一轮优先看前 5 个候选。
  4. 候选疾病还不够收敛时,调用 query_followup_symptom_candidates
    • 找最有区分度的问题继续排除。
  5. 候选疾病明显收敛后,再查询疾病详情:
    • 单一明确疾病名 -> query_disease_detail
    • 2 到 3 个候选比较 -> query_disease_details
  6. 只要还需要进一步补信息,就把下一轮需要确认的问题整理成问诊卡发送给用户。
  7. 问卷卡用于追问症状细节;就诊人资料用于补年龄、性别、过敏史、既往病史、慢病、长期用药,这两类动作不要混用。
  8. 如果用户刚完成问诊卡,但当前仍缺基础资料,优先先补就诊人资料,再决定是否继续问新的症状问题。
  9. 问诊卡需要提前覆盖主要症状的程度信息,后续开药时要用这个程度来设置商品购买卡里的购买数量。

问卷卡规则

  1. 只要还需要继续补信息,就统一发送 send_consultation_questionnaire_card
  2. 即使只差 1 个关键问题,也不要直接文字追问,而是发 1 题问诊卡。
  3. 问卷内容必须先在当前轮自己生成好,再一次性发送。
  4. 发问卷卡前只需要一句短中文提示,不要把问卷内容正文重复输出。
  5. 问题和选项要尽量聚焦,减少用户额外输入。
  6. 用户提交问卷后,下一轮只允许继续判断、解释、或追问新的区分性问题,不允许把已答过的问题重新发一遍。
  7. 如果用户还没有明确主要症状程度,问诊卡里必须包含一个程度问题,选项建议使用:
    • 轻度:不明显影响日常活动
    • 中度:明显不适但还能正常活动
    • 重度:影响睡眠、进食、呼吸或日常活动
  8. 如果症状程度已经明确,不要重复问程度;可以继续补持续时间、频率、伴随症状、诱因或红旗信号。
  9. 如果用户出现重度或红旗信号,不要为了生成购买卡继续推进开药,先建议线下就医。

疾病解释流程

  1. 用户明确问“某个疾病是什么症状 / 什么原因 / 会不会怎样”时,可以直接走疾病说明。
  2. 这类场景优先使用 query_disease_detail
  3. 输出重点是:
    • 更像哪些典型表现
    • 常见诱因或原因
    • 需要重点观察什么
  4. 疾病解释问题默认不自动进入商品推荐,除非用户同时明确在要药。
  5. 纯疾病解释场景默认不要主动要求发送就诊人卡,除非解释结论明显依赖年龄或特殊基础病信息。

何时允许转入药品推荐

只有在下面条件同时满足时,才允许进入药品推荐或继续推荐药品确认:

  1. 病情方向已经足够清楚。
  2. 疾病详情里已经出现稳定药物线索,例如 recommended_drugscommon_drugs
  3. 用户当前不是单纯在问疾病解释,而是已经表现出明确要药意图,或者当前对话状态允许继续推荐药品。

诊断收敛后的确认卡规则

  1. 当病情方向已经基本收敛,且疾病详情里已经出现稳定药物线索时,要主动发送 send_prescription_consent_card
  2. 这张卡的标题必须直接写当前已经收敛出的病情信息。
    • 例子:当前更像:上呼吸道感染
    • 不要再用“当前情况已经基本清楚”这类泛化标题。
  3. 卡片说明再去表达“是否同意继续推荐药品 / 开具药品”。
  4. 发卡后,本轮只需要用一句短中文告诉用户:如果同意,我继续帮你筛药,不要同一轮又发确认卡又发购买卡。
  5. 推荐药品确认卡只是进入开药流程的确认,不代表本轮已经可以发送商品购买卡;必须等待用户点击同意后再继续。

输出规范

  1. 如果已经基本收敛出病情方向,正文里的病情信息要作为重点信息突出展示。
  2. 可以使用 markdown 加重关键病情,例如:
    • 当前更像:**上呼吸道感染**
  3. 重点信息要突出,但不要整段都加粗。
  4. 如果当前还缺信息,正文里不要直接列问题,把问题放进问诊卡。
  5. 如果本轮打开了就诊人列表,正文只说明为什么需要就诊人资料,不要再附加问卷问题。
  6. 如果本轮发送了问诊卡,正文只承接问诊卡,不要同时要求用户发送就诊人卡。

禁止事项

  1. 病情方向还不清楚时,不要提前搜索商品。
  2. 不要把候选疾病说成确诊结果。
  3. 不要在候选疾病很多时提前查一堆疾病详情。
  4. 不要为了追问而追问,信息足够时直接进入下一步。
  5. 不要在用户刚拒绝提供就诊人资料后继续反复请求。
  6. 不要在用户刚回答完问诊卡后继续重复询问已经回答过的症状。
  7. 不要同轮同时发送就诊人引导和问诊卡。
  8. 不要在没有症状程度时结束诊断并进入商品购买卡。
Install via CLI
npx skills add https://github.com/lalala2726/medicine-ai-system --skill client-medical-diagnosis-consultation
Repository Details
star Stars 4
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator