求职助手（Job Hunt Copilot）· Pay Skill v1.5.0
一、付费调用契约（Pay Skill · 支付宝 AI 按量付费 A402 / Machine Pay）
本技能为 SkillHub 付费技能（PAYSKILL），单次调用 9.9 元，计费协议为支付宝 AI 按量付费（A402，基于 HTTP 402 Payment Required 的 A2M 方案）。支付与验付一律复用支付宝官方能力，本技能不自研收款代码、不接触用户资金、不在包内保存任何密钥明文。
1.1 前置检查（发起下单前必做）
调用前先检查当前智能体的工具列表中是否存在支付宝支付能力工具（如官方 alipay-payment-skill / alipay-bot 提供的工具）：
- 存在 → 继续走下面的 probe → pay → complete → ack 编排。
- 不存在 → 终止流程并提示用户：合作智能体请升级至最新版；开放智能体请先从 SkillHub 安装「支付宝 AI 付」官方 Skill 后重试。
1.2 调用流程编排（probe → pay → complete → ack）
| 步骤 | 名称 | 动作 | 失败/边界处理 |
|---|---|---|---|
| ① probe | 探测 / 请求资源 | 按本技能正常流程准备交付（简历诊断 → 岗位分级 → 匹配分析 → 招呼语草稿）；向付费闸口发起资源请求，确认是否已持有本技能的支付宝有效付费凭证 | 已付费（凭证有效）→ 直接放行；未付费 → 进入 ② |
| ② pay | 推进支付 | 付费闸口返回 402 Payment Required 并在 Payment-Needed 头下发账单；把 Payment-Needed 交给支付宝官方支付能力拉起收银，由用户本人确认/扫码完成付款（Agent 只编排、不代付） |
用户取消 → 终止交付、不计费 |
| ③ complete | 验付 + 履约执行 | 付款成功后携带 Payment-Proof 重试原请求；付费闸口调用 alipay.aipay.agent.payment.verify 验付，通过后执行并返回交付物 |
凭证无效/过期 → 拒绝服务；结果不明不得要求用户重复付款 |
| ④ ack | 履约确认回执 | 交付物成功产出后，调用 alipay.aipay.agent.fulfillment.confirm 向平台回执（ack）；失败可重试且保持幂等 |
交付失败 → 不消费凭证、不回执，用户不为失败付费 |
一句话链路：客户端 probe 授权 → 服务端下发 402 账单 → 用户支付（pay）→ 携带 Payment-Proof 重试 → 服务端 verify 验付 → 放行交付 → ack 履约回执。
1.3 五项必备环节（对齐平台付费改造检查项）
- 402 账单下发 —— 未携带有效凭证时，付费闸口返回
HTTP 402 Payment Required，并在Payment-Needed响应头给出 Base64URL 编码的账单 JSON：out_trade_no（商户订单号，全局唯一，用于幂等与防重复支付）、amount、currency、resource_id（资源唯一标识，防串用）、pay_before（支付截止时间）、seller_signature、seller_sign_type（RSA2）、seller_unique_id，以及 method 层seller_name、seller_id(2088ID)、seller_app_id、goods_name、service_id。账单用商户应用私钥按 RSA2 加签，客户端可离线校验签名后再决定是否支付。 - 携带凭证重试 —— 用户在智能体内完成支付后，客户端必须携带
Payment-Proof请求头重试同一资源请求；凭证一次性有效，携带旧凭证重试会被拒绝，不会重复计费。 - 验付调用 —— 付费闸口调用支付宝接口
alipay.aipay.agent.payment.verify验签并核验凭证；业务层同时校验active状态、金额、out_trade_no、resource_id与账单完全一致，任一不符即拒绝放行（可再次返回 402）。 - 履约确认 —— 验付通过且交付物成功返回后，异步调用
alipay.aipay.agent.fulfillment.confirm向平台发送履约回执（ack），声明本次订单已履约；任务失败时不产生履约回执。客户端页面/App 回跳展示的"支付成功"不能替代验付与履约确认。 - 订单持久化与幂等 —— 订单、通行证与审计记录全部落盘/落库：
out_trade_no唯一约束配合防重放表，付费状态缓存于.pay_cache/state.json，同一Payment-Proof在 24h 幂等窗口内仅生效一次，保证同一凭证不被重复消费、同一订单不重复交付（不重复扣费、不重复履约）。失败不计费，计量记录不删除。
1.4 实现位置与支付依赖
scripts/payment_gate.py—— 本技能的付费闸口（支付依赖包）：实现 probe 探测、402 +Payment-Needed账单下发、Payment-Proof验签、alipay.aipay.agent.payment.verify验付、alipay.aipay.agent.fulfillment.confirm履约回执，以及.pay_cache/state.json幂等持久化。收款、扣费、结算全部交给支付宝官方能力，脚本只做闸口与编排。scripts/requirements.txt—— 支付依赖清单（RSA2 加签/验签所需）。references/payment-protocol.md—— A402 协议字段清单、验付与履约接口入参、幂等与安全细则。
1.5 安全红线
- 应用私钥只存服务端（环境变量 / KMS 注入），禁止写入技能包、日志或公开仓库（Java 用 PKCS#8，非 Java 用 PKCS#1）。
- 生产环境必须校验本地订单、金额与资源关系；
service_id使用API_开头的真实值（沙箱api_mock_service_id仅调试用）。 - 不向用户暴露支付链接、二维码原文或交易号等中间过程；不代付、不绕过平台支付环节、不内嵌非平台标准的支付实现。
二、为什么值 9.9 元（付费价值锚定）
按"价值定价"而非"成本定价"——你买的不是一段代码，而是封装的实战方法论与一次完整的求职推进：
- 一次调用交付：简历量化诊断（结构 / 量化 / 关键词 / 聚焦度 4 维打分）+ 岗位匹配度分析（匹配点 / 缺口 / 风险逐条映射）+ 高回复率招呼语草稿。市场上同类人工咨询单次 50–200 元。
- 省时间：把"海投 200 家没回音"压缩成"精准投 20 家有面试"，按一次无效投递浪费 15 分钟算，省下的时间远超 9.9 元。
- 壁垒：10 年线下连锁运营 + 密集求职实战踩坑方法论，不是通用提示词能反推的——光看输入输出学不走核心判断（动态经验型 + 产能提升型）。
- 即买即用：不订阅、不办会员，按次付费（A402 按量计费），花哪次钱、产出什么一目了然；交付失败不计费。
> 若需"免费引流版"（截断在简历诊断 / 岗位分级，不含匹配度深分析与招呼语定制），可另设一个低价或免费 Skill 做入口；本付费版聚焦深度交付，避免自相分流。
三、Overview
端到端求职辅助框架：简历优化 → 岗位匹配 → 招呼语定制草稿 → 用户自行投递 → 跟进管理。本技能是通用框架，所有个人化内容（经历弹药库、目标城市、行业偏好、排除规则）来自用户的「求职档案」，首次使用时通过 assets/profile-template.md 采集。
核心边界：本技能不自动操作任何第三方平台、不代替用户发送消息——所有岗位信息由用户主动提供，招呼语与岗位分析以草稿形式交付，发送动作由用户完成。
阶段 0：求职档案（首次使用必须先完成）
- 读取
assets/profile-template.md，向用户逐项采集（一次问一部分，别一次甩 10 个问题）：
- 基础信息：目标城市、期望岗位方向（最多 2-3 个）、薪资底线
- 简历：现有简历文件路径（只读，绝不修改原文件）
- 经历弹药库：3-7 条「事迹 + 量化数据」（如"主导 X 项目，3 个月增长 40%"）
- 偏好与排除：想进的行业/公司类型；明确不碰的行业、区域、公司名单 - 将档案写入工作目录
job-profile.md，作为后续所有阶段的单一事实来源 - 档案随求职进展随时更新（用户提到新经历、新排除项时主动提议更新）
阶段 1：简历诊断与优化
按 references/resume-optimization.md 框架执行：
- 只读简历（PDF/docx），输出诊断：结构、量化程度、关键词覆盖、岗位方向聚焦度（各按 10 分制打分 + 问题清单）
- 给出优化稿：新文件另存（如
简历-优化版-日期.docx），不覆盖原文件 - 优化以目标岗位 JD 为准绳：若用户提供了目标岗位，按 JD 关键词重排内容；没有 JD 则按档案中的岗位方向通用优化
- 从优化后的简历中提炼/补全「经历弹药库」，回写求职档案
阶段 2：获取岗位信息（用户手动操作，技能只做分析与草稿）
> 合规原则：本技能不自动启动浏览器、不自动导航、不自动抓取任何第三方招聘平台页面。所有岗位信息由用户主动提供。
- 请用户在 Boss直聘 等平台手动浏览目标岗位，将岗位列表 / 详情页的文本内容或截图粘贴给技能（也可直接复制 JD 文本）。
- 技能解析用户提供的内容，提取职位、公司、薪资、地点、JD 关键信息，进入阶段 3 分级。
- 可选增强：仅当用户已自行启动浏览器、开启调试端口并明确授权时，可借助
scripts/cdp_eval.js读取用户已打开的页面文本做辅助；技能绝不自动登录、绝不批量爬取、绝不绕过验证码。此增强非必需，无授权时跳过。 - 手动操作与页面信息提取要点见
references/cdp-cheatsheet.md。
阶段 3：岗位筛选与分级（基于用户提供的信息）
- 对用户提供的岗位内容做解析与分级：A（强匹配）/ B（可关注）/ C（剔除），规则见
references/screening-and-ledger.md，并结合档案中的排除规则（行业 / 区域 / 公司黑名单）。 - 去重：以跟进台账为准，已出现过的公司 / 岗位不再重复列出。
- 对 A 级岗位，提示用户补充该岗位的真实薪资与完整 JD（若粘贴内容未含），以便进入阶段 4 做匹配分析。
阶段 4：岗位匹配分析
针对每个 A 级岗位输出（进报告"推荐理由"）：
- 匹配点：JD 硬性要求 ↔ 简历 / 弹药库的对应证据，逐条映射
- 缺口：JD 要求但简历没有的，标注"面试需准备的说法"
- 风险：代招 / 猎头标"先确认实际雇主"；岗位信息模糊标"待确认"
- 匹配度评分：10 分制，≥7 分才建议投递
阶段 5：招呼语定制（只出草稿）
按 references/greeting-templates.md 规范：全文 ≤80 字、第一句钩子（从该岗位 JD 的核心需求切入）、一条最相关证据（从求职档案弹药库取）、结尾一个具体问题。每条招呼语旁注明来源岗位与使用的弹药。
交付即止：招呼语放入报告"招呼语草稿"节，供用户复制到 Boss直聘等平台自行发送。
阶段 6：跟进台账与报告
- 台账记录用户反馈的投递结果（用户告知"已发送 / 已读 / 有回复"后更新），状态机：已投递 → 已读 / 送达 → 回复（推进 / 婉拒）→ 关闭
- 提醒节奏：用户标记"已发送"的对话，下次会话主动问进展；超过 3 天无回音建议放弃
- 报告用 python-docx 生成
求职岗位分析-日期.docx存用户指定目录；样式：标题深炭灰 #333333、节标题琥珀橙 #C2620A、微软雅黑、表格橙色表头 - 文件被占用（PermissionError）时请用户关闭预览后重试，不要强制关闭用户的编辑器
红线
- 绝不代替用户发送消息：所有招呼语、回复、邀约回应只出草稿，由用户自行复制发送
- 绝不自动操作第三方平台：不自动启动浏览器、不自动导航、不自动抓取招聘页面；岗位信息一律由用户主动提供
- 简历原文件只读；优化稿另存新文件
- 任何浏览器读取仅限用户已打开并明确授权的页面，不自动登录、不批量爬取、不绕过验证码
- 付费能力统一走支付宝 AI 按量付费（A402）官方链路：只做 probe / 402 / 验签 / 幂等四件事，收款与扣费交给支付宝；不代付、不绕过平台支付环节、不在包内保存密钥
- 失败不计费：交付失败或用户取消时，不消费支付凭证、不发履约回执
Resources
scripts/payment_gate.py— 付费闸口（支付依赖）：probe 探测、402 + Payment-Needed 账单下发、Payment-Proof 验签、alipay.aipay.agent.payment.verify 验付、alipay.aipay.agent.fulfillment.confirm 履约回执、幂等持久化scripts/requirements.txt— 支付依赖清单（RSA2 加签/验签）references/payment-protocol.md— A402 协议字段、验付/履约接口入参、幂等与安全细则assets/profile-template.md— 求职档案采集模板（首次使用必读）scripts/cdp_eval.js— 可选增强：用户已自行启动浏览器并授权时，读取已打开页面文本的通用脚本（非必需，无授权跳过）references/cdp-cheatsheet.md— 用户手动操作参考、页面信息提取要点（仅读取已授权页面）references/resume-optimization.md— 简历诊断与优化框架references/screening-and-ledger.md— 岗位分级规则模板 + 跟进台账references/greeting-templates.md— 招呼语规范与话术模板
