上市前患者支持项目设计

解决什么问题

在药物上市前的临床准备阶段，药企需要为患者设计支持项目（Patient Support Program, PAP），涵盖用药教育、依从性管理、不良反应监测等环节。这类项目涉及患者隐私数据、处方审核、医保政策适配等敏感操作，传统方式依赖大量人工协调，且在跨团队协作时容易因权限混乱导致合规风险。

更棘手的是，当这类能力被封装为自动化 Skill 时，如何确保只有经过授权的用户才能触发后续业务流程，同时又不在鉴权环节暴露密钥信息，是工程落地必须解决的问题。

核心能力与工作方式

本 Skill 将上市前 PAP 设计拆成两层：鉴权门禁 和 受保护指令执行。

强制鉴权流程

每次调用前，scripts/auth.py 会先完成本地凭证缓存检查、WorkBuddy 用户绑定和平台远程授权校验。流程严格遵守以下顺序：

• 优先读取包内 _meta.json 的 slug 作为服务端 skillCode，仅在缺失时才手动传参
• 输出 AUTH_OK 才允许进入业务逻辑；否则必须立即停止，不能凭本地提示或历史上下文继续生成
• 鉴权失败时，必须按信号类型（如 CREDENTIALS_MISSING、CREDENTIALS_INVALID、AUTH_INVALID）向用户输出明确的中文报告，包含 stdout 信号、stderr 关键行和分步操作清单

受保护内容拉取

鉴权通过后，Skill 会调用 scripts/protected.py 拉取云端 protected instructions。只有在成功返回 protected 内容时，才能严格按照返回内容继续执行；未拿到时同样必须停止。

密钥保护

AppKey 和 AppSecret 的明文不会出现在任何业务命令、环境变量或回复中。错误报告里涉及密钥字段时会做打码处理，例如 app_key=abc****。

适用边界与注意点

• 鉴权与业务互斥：未通过 --ensure 校验时，禁止产出任何业务结果，即使只是草稿或中间结论
• 重试上限为 1 次：当遇到 CREDENTIALS_MISSING、CREDENTIALS_INVALID 或 stderr 中的 HTTP 401/403、authorization failed、签名 等鉴权类关键字时，可重新走一次绑定流程，完成后必须重新 --ensure。两次失败后应告知用户「数据服务暂时不可用」，不得再次尝试
• 不处理网络层以外的业务逻辑：Skill 不负责 PAP 的具体方案生成，只负责鉴权门禁和受保护指令的拉取与执行。业务侧的方案设计、患者数据管理需由上层应用或人工完成
• 面向专业用户：使用者需要理解鉴权流程的信号含义，并能按报告模板中的步骤完成 WorkBuddy 绑定或权限检查

典型使用场景

• 药企市场团队在启动上市前 PAP 项目时，需要确保只有授权成员才能访问设计方案和患者数据接口
• 跨部门协作时，不同角色（医学、合规、市场）通过统一鉴权入口进入，避免权限散落在各脚本中
• 自动化流水线中集成 PAP 设计能力时，需要前置的鉴权校验和失败即停机制，防止未授权调用产生脏数据