医药优势谈判话术生成器

医药谈判话术为什么难复用

医药行业的谈判场景远比想象中碎片化。医保目录谈判、医院药事会准入、省级招标议价、集采续约，每个场景的话术策略、利益诉求、风险点都不同。一位资深 BD 可能积累了大量实战经验，但这些经验通常散落在邮件草稿、会议纪要和个人笔记里，新团队成员接手时只能从零开始踩坑。

更麻烦的是，医药行业的合规要求严格，很多话术涉及政策解读和价格策略，写错了不是丢单的问题，是合规事故。

这个技能要解决的就是：把零散的谈判经验结构化，让 Agent 能在具体场景下生成符合业务逻辑的话术草稿。

技能如何工作

整个技能的工作流分三层，每一层都有明确的门禁。

第一层：Python 环境检测

任何脚本执行前，必须先检测本地 Python 环境。检测逻辑很简单：如果 PYTHON_CMD 有值且版本合规，直接执行 scripts/auth.py；如果版本低或未检测到，则按模板报告。Windows 用户可能需要用 py -3 启动器绕过 Microsoft Store 的拦截。

这一层的目的是避免 Agent 在没有可用 Python 的情况下盲目重试。

第二层：授权门禁

这是整个技能的核心约束。技能被标记为受保护能力，每次使用前必须通过 scripts/auth.py 的授权检查。授权脚本负责三件事：

• 读取本地凭证缓存（_meta.json 中的 slug 作为服务端 skillCode）
• 校验凭证是否有效（过期或失效时自动触发重新绑定）
• 输出明确的信号：AUTH_OK、AUTH_REQUIRED、AUTH_INVALID、AUTH_BIND_OK

关键设计是：AUTH_REQUIRED 不是失败，而是首次绑定的正常信号。Agent 不应该在这里停下来向用户报告，而是自动调用 connect_cloud_service 获取 JWT，然后执行 --bind-jwt 绑定。

只有在绑定后重新检查仍然失败时，才输出鉴权失败报告，并且停止所有业务推理。

第三层：受保护内容拉取

授权通过后，技能通过 scripts/protected.py 向云端请求 protected instructions。这一层的意义在于：话术生成的核心逻辑不放在本地 SKILL.md 里，而是放在云端受保护资源中。Agent 必须拿到云端指令才能继续，不能凭本地提示或历史上下文生成话术。

这保证了内容更新和权限管控的一致性。

适用边界与注意点

有几个工程上的坑需要注意。

鉴权失败绝不能降级产出。 这是最容易踩的坑。Agent 可能在鉴权失败后仍然按照业务流程生成一份话术草稿，然后在末尾轻描淡写地提一句"另外鉴权有点问题"。这是严格禁止的。鉴权门禁和业务输出是互斥关系。

重试上限是 1 次。 当出现 CREDENTIALS_MISSING、CREDENTIALS_INVALID、HTTP 401/403 或 stderr 中的鉴权类关键字时，可以重新走一次绑定流程。两次都失败说明是服务端问题，应该告知用户"数据服务暂时不可用"，停止重试。

Windows 环境的 Python 别名陷阱。 python 命令可能打开 Microsoft Store 而不是执行脚本，建议用 py -3 启动器，或在系统设置中关闭 python.exe/python3.exe 的执行别名。

AppKey/AppSecret 不要暴露。 错误报告时必须打码，不要把密钥明文拼接到业务命令或回复中。