OPC 方向判断 · 定 Z（支付宝 AI 付 · 即时判断）
给「任务单元执行者」做敢下注的完整方向判断：先确认对象、接住原话问题，再采集业务事实，调用云端 OPC 引擎（支付宝 AI 付按次计费），用户授权支付后即时返回全量报告。判断只在服务端执行，包内不含引擎、不含任何 Key、不经手收钱。
何时使用
- 用户已经过免费初筛（分数/模式/一句话方向），要求继续解锁完整判断（传导链、反向提醒、往 Z 走、行动路径）。
- 用户直接要「敢下注的方向判断 / 完整报告 / pro 报告」，且判断对象是他本人拍板负责的业务任务单元（一人公司/小微/独立开发者/AI创业者等）。
- 用户谈理论本体（价值观/意义）、个人情绪、或团队组织诊断时——不用本技能，改用对应本体层技能。
工作流（支付宝 AI 付三步）
0. 付费前置检查（必须先做）
检查当前 Agent 是否具备支付宝 AI 付能力（支付宝 402 支付工具 / alipay 支付 skill / alipay-bot 已可用）：
- 已具备：继续；
- 不具备：向用户说明「当前 Agent 暂不支持付费调用」，终止流程，不要发请求。
1. 对象确认 + 问题归位 + 采集（支付前一次定稿）
先确认两件事（任一为否则终止，说明边界）：这是不是由对方负责、要对外产出结果的业务任务单元？问的是不是这个单元的业务方向？（个人情绪/组织人事/代答不入本服务；不按人数与注册形态设限。）
再记录原话三问，随 case 一起提交（只用于校准口径与回显，不参与打分）：
- 你现在最想解决的是什么？（question_summary）
- 这个问题让你正准备做什么决定？（decision_context）
- 之前试过什么，结果如何？（tried_before）
然后围绕五维采集客观业务事实（18 个字段，字段表见 references/case_fields.md，与 opc-direction-judge 的采集表一致）。组装 case JSON：
{
"consent": true,
"client_ref": "opc-instant-alipay",
"company": {
"question_summary": "用户原话：最想解决什么",
"...18 个采集字段...",
"case_type": "business",
"team_size": 1,
"decision_maker_is_owner": true
}
}
team_size 仅记录、不设上限；decision_maker_is_owner=true 表示本人拍板负责（代答不入本服务）。向用户说明：业务事实会进入作者案例库用于提升判断精度。首请求发出后 body 不可再改（服务端按 body 哈希绑定订单，改了会被拒）。
1.5 预检（推荐，支付前必做）
把 company 发给 POST https://egg5d.com/opc/api/v1/opc/preflight（服务端只做范围 + 字段校验，不落库、不触发支付）：
data.pass = true→ 继续；data.pass = false→ 把data.errors逐条展示给用户，修正后重新预检——通过前不进入支付（避免「收了钱才拒」）。
2. 首请求（不带 Payment-Proof）
POST 到 https://egg5d.com/opc/api/v1/opc/aipay/judge，请求体就是第 1 步的 case JSON（原样，不做任何加减）。
3. 支付与履约（交给当前 agent 的支付宝 AI 付能力）
- 服务端校验通过后返回 HTTP 402 +
Payment-Needed响应头（base64url 账单，内含 out_trade_no、amount=9.9、resource_id、service_id=API_400F5DBCC7594B97 等）。 - 把
Payment-Needed头值原样存到本地安全文件，交给支付宝 AI 付支付流程（例如alipay-bot 402-buyer-pay --file <该文件> --resource-url <同端点> -m POST -d <同 body> --intent-summary "原始请求：…"），向用户申请支付宝授权。 - 用户授权后，用支付流程给出的查询命令（如
402-query-payment-status）完成履约：服务端带Payment-Proof重试同一 body → HTTP 200 + code=0 + case_id + 全量 pro 报告 + Payment-Validation 回执，并自动确认履约。 - 只有服务端返回的全量 pro 报告才能交付；402 之前的中间响应一律不交付。
输出呈现
先给 fixed_judgment 一句话定向句（X/Y/Z），再给：
- 五维分数与分档（
scores/bands）； - 传导链根果（
root_dim/fruit_dim：谁是根谁是果）； - 三依据（
three_bases：数据/行为/结构）； - 反向提醒（
reverse_warning）； - 行动路径（
action_plan：今天 1 个动作 + 本周 2-3 个 + 下月复诊指标 + 专家团工具）； - case_id 与「自动判断版」边界声明。
语气温暖但有锋芒；不改写结论、不用「可能/也许/看情况」稀释判断。
异常与边界处理
| 情形 | 处理 |
|---|---|
| 重试仍 402 | 支付未完成/账单过期：走新的首请求→支付流程（body 不变，服务端开新订单） |
HTTP 200 但无 Payment-Validation / code≠0 |
未履约成功：不要交付报告，按响应提示处理或同一 Payment-Proof 重试 |
body code=VERIFY_FAILED 等 |
验付/履约失败：不重复扣款，稍后用同一 Payment-Proof 重试；仍失败建议联系客服 |
| HTTP 422 | 范围/字段不通过（非业务对象/代答/缺字段等）：修正后重新发起；此时未触发支付（正常应先过 1.5 预检） |
| HTTP 401/429/5xx | 按响应说明处理，不静默降级成本地猜答案 |
服务端契约速查见 references/a2m-flow.md。
不要做什么
- 不把免费初筛当完整判断交付（那是 opc-direction-judge 的活）。
- 不内置/请求任何 pro Key、商户密钥或支付凭据——收钱与验付全在服务端与支付宝侧；Payment-Proof 由支付流程生成并原样传递，不展示明文、不跨会话复用。
- 支付成功后不修改 body 重试；不为讨好用户改判。
- 不做陪跑、不接个人情绪/团队组织诊断。
配置
零配置默认端点即可用；可用环境变量 OPC_API_ENDPOINT 或 config.json 覆盖。不要填写任何 API Key。
