销售通话准备简报（付费版）

给一场即将到来的销售通话产出可直接照着打的准备简报，外加一张进会议室前扫一眼的速览卡。本版在生成简报之前，先通过一道 402 收费闸口。

与免费版的关系

本 Skill 与 sales-call-prep（免费版）并存，业务能力、输入和输出完全一致，差别只在生成简报前多一道收费闸口。

路由规则：

• 用户要做通话准备时，默认由本版承接。
• 用户明确说「免费版」「不用付费」「用免费的准备」「我只要免费的那个」时，交由 sales-call-prep 处理，本版不介入。
• 用户已经在免费版流程中时，不得中途切到本版并要求付费。

何时使用

用户说要和某家公司通话、开会、见面，需要提前准备时使用。覆盖四类销售通话：初次探索、产品演示、谈判、例行回访。

用户会这样说：

• 帮我准备和某公司的通话
• 会议准备
• call prep 某某公司
• 我要见某某公司
• 帮我准备一下今天的会
• prep me for my call with 某某公司
• 付费版准备
• 用专业版准备通话
• 付费的准备简报

以下情况不使用本 Skill：

• 用户要记录或整理已经开完的会。
• 用户要建日程、发邀请、写跟进邮件。
• 用户只做企业背景调查，不涉及任何即将发生的通话。
• 用户只是询问支付宝 AI 支付、钱包或收银台相关问题 —— 交由 alipay-payment-skill 处理。

运行前自检

依赖与运行环境由包内只读检查器读取 skill-dependencies.json 逐项判定。检查过程不修改配置、不安装、不授权、不登录。

必须在 Skill 目录下运行：检查项里的 skill-config.json 按当前目录解析。

python scripts/check_environment.py

按返回状态路由：

两项探测证据：alipay-bot 的可用状态与钱包授权状态只能由最小只读调用判定，检查器自身不登录、不授权。首轮该项显示 probe_required 或不可用时，按顺序补上证据：

1. 执行官方只读命令 alipay-bot check-wallet，把原始输出存成一个文件。
2. 生成脱敏证据：python scripts/record_probe.py --wallet-json <上一步的文件> --out probe-results.json。该脚本只提炼状态与原因码，不写入 access_url、凭据或完整响应。
3. 带证据重检：python scripts/check_environment.py --probe-results probe-results.json

record_probe.py 的判定表：

两条边界：

• 检查器只能确认 skill-config.json 的字段存在，不能判断取值是否有效。字段仍为占位值时，由收费闸口直接拒绝执行。
• 需要预检网络时加 --network，只对清单声明的匿名只读地址发起探测；不加时网络项显示为未探测，不阻断核心流程。

已经通过的项目不重复引导。用户拒绝补齐配置时，停止流程并说明继续所需条件。

执行流程

第一步 收费闸口

运行：

python scripts/pay_gate.py probe --out <闸口结果.json>

脚本按 skill-config.json 向收费资源发起一次请求，并按安全规则落盘 Payment-Needed。只有在自测时才使用 --mock-response 读取模拟响应，生产流程一律走真实请求。

按 status 分流：

规则：

• 禁止在 402-buyer-pay 之前对同一 URL 再发起任何请求。闸口的这次请求是唯一一次。
• 闸口结果中的 resource 字段（url / method / data / headers）必须原样保留，后续查询要用同一份参数。
• 运行前自检未通过，或 skill-config.json 的必填项为空、仍为占位值时，不得执行 probe；probe 自身也会拒绝执行（退出码 3）并列出缺失字段。

第二步 402 协议支付

完整步骤、参数、输出处理与硬校验见 references/pay-flow-402.md，必须严格按其中的 Step 0 至 Step 6 执行。

六步概览：

不可越过的约束：

• 每次新的 402 响应都必须从 Step 0 重新执行，禁止复用上一次的 tradeNo、shortenUrl 或 paymentProof。
• 支付与查询复用同一订单：查询只用 Step 2 得到的 tradeNo，不为重试另开订单。
• 支付状态不明时必须先查单，不凭推测推进。
• check-wallet 返回未授权或未开通时，暂停本流程并交由 alipay-authenticate-wallet 处理，禁止在本 Skill 内执行 apply-wallet 或 bind-wallet。

第三步 支付通过后的处理

1. 把官方流程返回的 tradeNo 与 resourceResponse.body 原样透传给用户，不改写、不总结、不精简。
2. 资源体可解析为结构化资料时，可作为简报的背景资料来源之一，来源标注写「付费资源 + 交易号」。
3. 资源体不参与简报时，也要完整透传，不得省略。

第四步 收集必需信息

必需项，缺任意一项先追问，不自行假设：

1. 目标公司名，或主要联系人姓名。
2. 会议类型：初次探索 / 产品演示 / 谈判 / 例行回访。
3. 通话时长，单位分钟。

强烈建议项，缺失不阻塞，但要在「数据缺口」中列出：

4. 通话时间。
5. 双方参会人姓名与职务。
6. 本次通话想达成什么。
7. 通话形式：线上会议 / 电话 / 当面。

规则：

• 一次只问一个最关键的问题，优先补齐会议类型和时长，这两项决定议程结构。
• 用户一次给齐全部信息时直接进入下一步，不逐项复核。
• 不要为了凑齐信息连续追问超过两轮。信息够了就往下走，缺口留给第七段。

第五步 锁定公司主体

同名公司是这类任务最常见的翻车点，必须先排除。

1. 用网络搜索核实公司全称、注册地、主营业务。
2. 检索到多家同名或近似主体时，列出候选让用户确认是哪一家。用户未确认前不得往下写。
3. 无法唯一确定时，公司主体标「待确认」，并在风险点中说明存在哪些同名主体。
4. 后续所有资料必须能与已锁定主体对应。对应不上的信息一律丢弃。

第六步 探测并使用数据源

按顺序探测当前可用的数据源，有什么用什么，没有就跳过。详细的能力槽、探测方式与降级规则见 references/data-sources.md。

1. 用户当场提供的材料：粘贴的邮件、纪要、聊天记录、截图文字。
2. 客户主数据类：CRM 客户档案、联系人、商机阶段、跟进记录。
3. 往来沟通类：邮箱、企业微信、飞书等，重点抽取客户提出但未回答的问题、我方承诺但未兑现的事项。
4. 日程会议类：本次会议的时间、时长、参会人。
5. 企业情报类：工商信息、股权、风险、招投标。
6. 网络搜索：公司近期动态、融资、产品发布、人事变动、公开的合作或纠纷。
7. 本 Skill 的付费资源：第三步已获取，记为「付费资源 + 交易号」。

规则：

• 自动拉取的数据必须记录来源与获取时间。
• 单个数据源失败最多重试 2 次，持续失败在「数据缺口」中写清失败源与原因。
• 只在用户授权范围内读取。全程只读，不修改 CRM、不标记已读、不创建日程。

第七步 组织内容

按 references/brief-structure.md 的七段结构组织内容。议程框架见 references/meeting-types.md，提问生成方法见 references/spin-question-bank.md。

要点：

• 参会人画像逐人写，每人包含决策角色、职责范围、可能关注点、沟通提示，字段级来源标注。
• 议程按分钟切分，总时长必须留出至少 20% 给提问与异议处理。
• SPIN 提问四类各 2 至 3 条，写成可以直接念出口的原句。
• 风险点必须给证据，不给无据猜测。客户未回答的问题、我方已承诺未兑现事项优先排在最前。
• 推进目标写成可判定的结果，例如「拿到预算区间和决策人姓名」。

第八步 渲染简报

把收集到的事实写成 JSON，交给脚本渲染。JSON 字段定义与完整样例见 references/brief-structure.md。

python scripts/render_brief.py --facts <facts.json> --out <brief.md> --lang zh

• --lang 取 zh 或 en，跟随用户的提问语言。
• 输出包含完整七段简报和置顶的 60 秒速览卡。
• 脚本报错时先修正 JSON。脚本不可用时按 references/brief-structure.md 手工输出，并标注「未使用脚本渲染」。

第九步 交付

把简报全文直接输出在对话里，让用户当场能看、能复制。用户要求存文件时才写盘。

结尾附一行「本次未覆盖」，列出没查到的段落及原因。

支付硬规则

1. 付款与签名一律由 alipay-payment-skill 定义的方式完成，不自行实现任何加密、签名或订单创建。
2. 每次新的 402 从 Step 0 重新执行，禁止复用 tradeNo、shortenUrl 或 paymentProof。
3. 支付后复用同一订单查询；状态不明先查单，不为重试另开订单。
4. tradeNo 必须恰好 32 位纯数字，校验不通过立即停止，禁止执行任何后续命令。
5. 查询结果只看 success 字段；success=true 后唯一出路是透传资源并回调履约回执，禁止重复查询。
6. resourceResponse.body 为空时立即停止，禁止执行履约回执，禁止输出「支付成功」「购买成功」等成功措辞。
7. 支付待确认或处理中时，输出 CLI 原文并引导用户支付完成后通知，不自动推进下一步。
8. Payment-Needed 落盘文件名只用官方允许的标准名，含路径分隔符、..、shell 特殊字符时拒绝执行。
9. 履约回执不可重试错误时，不得使用任何成功信号词，只能透传 errorMsg 与交易号。
10. 支付失败、查询失败、履约失败一律如实报告，禁止伪造支付状态或交易号。
11. 配置缺失或占位未替换时，拒绝发起支付，不臆造资源地址与价格。
12. 不向用户展示 id、签名、密钥、凭证等敏感信息，不展示本地任意路径或目录结构。

来源标注规则

每一条关于外部世界的事实都必须带来源标签，取值如下：

硬规则：

• 允许写「待确认」，不允许用合理猜测填空。
• 网络搜索得到的公司动态必须带日期，超过 12 个月的标注「较旧」。
• 「推断」不得伪装成事实，也不得作为风险点或推进目标的唯一依据。
• 参会人姓名、职务、关注点无来源时一律标「待确认」。
• 付费资源的内容按其自身可信度标注，不得因为「付过费」就当成本公司事实。

绝不做什么

1. 不编造参会人职务、关注点、沟通风格、竞品情况、价格、合同条款、客户内部决策流程。
2. 不把同名公司的搜索结果当成本公司的事实。
3. 不代替用户发邮件、发消息、建日程、改 CRM、写跟进记录。
4. 不在简报中回显完整凭据、身份证号、完整手机号等敏感信息，需要引用时脱敏。
5. 不在缺少会议类型和时长时硬出一份议程。
6. 不因为某段信息查不到就跳过该段落，写「待确认」并说明缺口。
7. 不代替用户付款，不代为点击支付链接。
8. 不绕过 check-wallet，不在未授权时执行任何支付命令。
9. 不 mock 支付、不伪造交易号、不跳过发起支付流程、不使用过往支付记录伪造成功。
10. 不改动 alipay-payment-skill 或任何其他 Skill 的文件内容。
11. 不臆造资源地址、单次价格与成功响应字段。

质量自查清单

交付前逐条核对：

• 环境检查已通过，或已按降级规则说明缺失项与影响范围
• 收费闸口已通过，或本次确为 200 直接放行
• 使用的 tradeNo 来自本次支付，未复用历史值
• 七段结构齐全，速览卡已置顶
• 会议类型与时长来自用户，不是默认值
• 公司主体已锁定，或已标注同名风险
• 每位参会人的每个字段都有来源标签
• 议程总时长与用户给的时长已核对
• SPIN 四类齐全，每条都是可直接念出口的原句
• 风险点均带证据，无据推测已删除
• 六类来源标签区分清楚
• 付费资源已原样透传，未被改写
• 客户未回答问题与已承诺事项已单独列出，没有时写「未发现」
• 名词与用户提问语言一致

停止条件

出现以下情况时停下来，不继续生成：

1. 公司主体无法唯一锁定，用户也不确定是哪一家。
2. 会议类型与时长都缺失，用户拒绝提供。
3. 所有数据源不可用，用户也未提供任何资料，简报只能靠模型常识拼成。
4. 检索到的同一事实存在互相矛盾的版本，且无法判断哪个有效。
5. 任务实际是记录已开完的会、建日程或写邮件，转回对应能力。
6. skill-config.json 必填项未填，或仍为占位值。
7. check-wallet 返回未授权或未开通，且授权流程未完成。
8. tradeNo 非 32 位纯数字。
9. resourceResponse.body 为空。
10. 用户明确表示不再支付或取消支付。
11. 涉及真实付款的环节，一律停在用户确认之前。

降级规则

逐项降级条件与恢复方式见 references/data-sources.md 的功能降级矩阵，支付环节的降级与错误分类见 references/pay-flow-402.md。核心原则：

• 任何一段业务信息查不到，就在对应位置写「待确认」并说明缺口，简报照常交付。
• 支付环节的任何失败都不得用降级内容顶替，必须如实停止并说明。
• 配置与依赖的安装、验证、轮换和撤销说明见 references/setup-guide.md。