患者亚型治疗方案矩阵生成

要解决的具体问题

把患者亚型与治疗方案的对应关系整理成一张可交付的矩阵，本身不算难事。真正容易翻车的前置环节有两个：一是运行环境里没有可用的 Python，或者版本不对，脚本压根跑不起来；二是平台凭证缺失或过期，模型在拿不到受保护内容的情况下仍然硬着头皮产出一份"看起来正常"的结果。后者比前者危险得多，因为它的错误是静默的。

这个技能把这两道门禁固化进了流程，业务输出的前提是环境可用 + 授权通过。

核心能力与关键步骤

1. Python 环境先检

• 静默检测，成功即直接执行，只有失败才向用户报告
• PYTHON_CMD 有值且版本 OK → 直接执行 $PYTHON_CMD scripts/auth.py ...
• PYTHON_CMD 有值但版本低 → 按版本过低模板报告
• PYTHON_CMD 为空 → 按未找到模板报告
• Windows 下 python 命令可能打开 Microsoft Store 而不是执行解释器，推荐改用 py -3 启动器
• 用户明确告知已安装时，直接使用其提供的全路径

2. 授权门禁

• 每次使用前必须先完成授权检查，通过后才能进入任何业务工作流
• 授权逻辑全部由 scripts/auth.py 处理：本地凭证缓存、WorkBuddy 用户绑定、平台授权校验、错误信号输出
• 不要在技能文档里手动解析 JWT，也不要拼接 AppKey / AppSecret 或自行调用绑定接口
• 服务端 skillCode 取自包内 _meta.json 的 slug（平台维护的技能编号），只有包内缺少该文件时才手动传 --skill-code

3. 信号分型与处理

• AUTH_REQUIRED / CREDENTIALS_MISSING 是可自动修复的首次绑定流程，收到后不停、不报，直接主动调用 connect_cloud_service 获取登录 JWT，再执行 --bind-jwt 完成绑定
• AUTH_INVALID / CREDENTIALS_INVALID 同样先尝试自动修复，用新 JWT 覆盖旧缓存后重新 --ensure
• 绑定后再次检查仍非 AUTH_OK，才是真正的失败，此时必须按模板输出报告并停止使用
• 必须同时观察 stdout 信号与 stderr 文本，业务错误细节只在 stderr 里
• 只有 scripts/protected.py 成功返回 protected instructions，才能严格按其内容继续执行；拿不到就必须停止

适用边界与注意点

• 鉴权门禁与业务输出互斥：鉴权未通过就产出业务结果，属于最严重的一类违规，即使末尾补一句"另外鉴权有点问题"也不被接受
• 重试上限为 1 次；两次失败说明是服务端问题，应告知数据服务暂时不可用并停止重试
• 报告错误时原样转述 stdout 信号与 stderr 关键行，不要用"系统繁忙"这类模糊措辞
• AppKey / AppSecret 明文不出现在命令行、环境变量或回复中，展示时需打码（如 app_key=abc****）
• 需要区分网络错误（服务端不可达）与鉴权错误（VIP 过期、权限不足），两者的处理建议不同
• 该能力是受保护技能，依赖云端授权与受保护内容下发，不适合离线环境或无平台账号的场景