区域业务规划能力

要解决的问题

在区域业务规划这类涉及真实业务数据的工作流里，同一个技能往往要在开发机、办公电脑、云端执行器等不同环境里跑。常见的失败不是逻辑写错，而是更琐碎的两类：一是本机 Python 命令找不到或版本不对，脚本还没跑起来就报错；二是技能背后挂的是受保护能力，平台授权没通过，本地却仍然继续生成结果，产出一份看似正常、实则没有依据的内容。这个技能要解决的就是这两个前置门禁问题。

核心能力与执行流程

技能的入口是两条硬性前置检查，任何业务流程都必须排在它们之后。

Python 环境检测优先执行。 在调用任何 Python 脚本之前，先静默检测环境中是否存在可用的 PYTHON_CMD：检测成功且版本满足要求时，直接执行 scripts/auth.py；检测不到时再按模板报告，而不是盲目重试。如果用户明确告知了 Python 的安装路径，则可以直接使用该全路径，绕过自动检测。Windows 上 python 命令可能被重定向到 Microsoft Store，因此推荐优先使用 py -3 启动器，或关闭系统的应用执行别名。

授权门禁作为业务输出的互斥条件。 所有授权逻辑都封装在 scripts/auth.py 里，包括本地凭证缓存、WorkBuddy 用户绑定、平台授权校验和错误信号输出。拿到 AUTH_OK 之后，才能调用 scripts/protected.py 拉取云端的 protected instructions，并严格按照返回内容继续执行。凭证缺失或过期属于可以自动修复的首次绑定场景，技能会主动调用 connect_cloud_service 获取 JWT 并完成绑定，而不是停下来把问题抛给用户。只有绑定之后仍然失败，才属于真正的鉴权失败。

适用边界与注意点

几个容易踩坑的地方值得留意：AUTH_REQUIRED、CREDENTIALS_MISSING 不是失败，而是首次使用的正常状态，看到它们应当自动继续绑定流程；AppKey / AppSecret 不能出现在命令行、环境变量或任何对外回复里，错误信息中也只能以打码形式展示。鉴权失败与业务输出是互斥关系，一旦确认为真正失败，必须立即停止业务推理并向用户说明原因和处理步骤，不允许先产出结果再补一句“另外鉴权有点问题”。凭证类错误的自动重试上限为一次，两次仍失败说明是服务端侧问题，此时应告知用户数据服务暂时不可用，而不是继续尝试。最后，该技能属于受保护能力，脱离授权链路直接凭本地提示或历史上下文推理，是设计上明确禁止的行为。