WorkBuddy 客户拜访 · 需求分析和落地培训计划
当用户要去做一次 WorkBuddy 产品客户拜访/演示（面向一家企业客户），并希望产出一份标准化的《需求分析和落地培训计划》方案文档时使用本技能。产出物是一份单文件、自包含、可直接打开预览的 HTML，视觉风格与示例完全一致。
何时使用
- 用户说「做 WorkBuddy 拜访」「给 XX 公司出一份 WorkBuddy 方案」「需求分析和落地培训计划」
- 用户给了客户公司名，要求产出面向该客户的 WorkBuddy 落地方案
- 任何需要产出「企业 AI 落地 + 基础培训」标准化提案的场景
前置信息（必填/尽量补齐）
- 客户公司全称（必填，用于封面「致：」与标题）
- 客户公司简称（用于正文称呼，如「易而达」）
- 服务方（编制/落款主体）：必须使用当前使用者（安装本技能的用户）自己的公司主体。确定顺序：用户在本次对话中明示 → 用户记忆/历史对话中的既有口径 → 若都没有，必须先询问用户「方案落款的服务方公司名称」，不得默认任何具体公司名、不得编造。注意：模板中所有出现「服务方」署名的位置（封面、服务团队构成、页脚）必须使用同一主体
- 日期：默认当前年月（如「2026年7月」）
- 客户行业与已知背景：若用户只给公司名，先用 WebSearch 调研公开资料（官网/年报/新闻）补全企业画像、产品线、组织架构、工作场景
> 若信息不足，先向用户确认公司名与行业，再决定是否调研。不要在没确认客户主体的情况下编造核心数据。
付费解锁流程（本技能为付费技能，无本地模板时必须先完成）
完整视觉模板 plan_template.html 托管在卖家的支付宝 AI 按量付费（A402）资源服务上，按次付费解锁。若 references/plan_template.html 已存在（作者本机或本会话已解锁），直接跳过本流程，勿重复支付。
- API 基址：
https://base-ai.szalive.com:8788 - resource_id：
PLAN_TEMPLATE_V1；定价¥1.99/ 商品名WorkBuddy拜访方案模板/ 收款方workbuddy渠道拜访客户增长（以服务端下发的 402 账单为准） - 订单号规则：
ORDER_{13位时间戳}_{6位随机hex}，全局唯一、全程同一订单复用
本技能走支付宝官方「AI 按量付费」协议（A2M / 402 Payment Required）。买家侧付款由官方 alipay-bot 命令行工具完成。
0. 前置：确认买家侧付款能力（强制，不可跳过）
一条命令合并检测（不要分两次往返）：
alipay-bot --version && alipay-bot check-wallet
- 返回
status: bound→ 直接进 probe；本会话内已确认 bound 的，后续调用禁止重复检测。 - 返回「未开通」→ 执行
alipay-bot apply-wallet，把生成的开通链接/二维码给用户扫码；等待用户扫码期间，并行执行「工作流程」第 2 步的公开调研，不要干等。扫码完成后一次check-wallet确认即可（扫码通常直接完成绑定，不一定会有授权码）。 - 命令不存在 → 引导用户安装官方支付宝 Agent 支付能力：
bash npx -y @alipay/agent-payment@latest install
装好后重复上面的合并检测。 - 用户拒绝安装或始终无法开通 → 才终止付费流程，如实说明原因。不要伪造已付款或解锁。
1. probe：取 402 账单
用一条 curl 完成请求并把账单头直接落盘（禁止模型转写 Base64——慢且极易出错）：
curl -sS -D /tmp/probe_headers.txt -o /tmp/probe_body.json \
-X POST "https://base-ai.szalive.com:8788/v1/paid-resource/prepare" \
-H "Content-Type: application/json" \
-d '{"resource_id":"PLAN_TEMPLATE_V1","out_trade_no":"<订单号>"}' && \
grep -i '^Payment-Needed:' /tmp/probe_headers.txt | cut -d' ' -f2 | tr -d '\r\n' > /tmp/bill.b64
服务端返回 402 Payment Required + Payment-Needed 响应头（Base64URL 账单 JSON，含 protocol/method 两层）。
/tmp/bill.b64 必须只含 Payment-Needed 响应头的原始值（一整串 Base64URL）。不得解码、改写、截断、换行或二次编码——凭据被改动是支付失败最常见的原因。
落盘后先做一次非空校验：wc -c /tmp/bill.b64 应为几百字节以上。
- 非空 → 进步骤 2 付款；
- 为 0 字节 → 说明该订单返回的是
200（已支付/已解锁），直接按步骤 3 处理取资源，不要重复发起付款。
2. pay：用 alipay-bot 完成付款
alipay-bot 402-buyer-pay \
-f /tmp/bill.b64 \
-r "https://base-ai.szalive.com:8788/v1/paid-resource/prepare" \
-m POST \
-H "Content-Type: application/json" \
-d '{"resource_id":"PLAN_TEMPLATE_V1","out_trade_no":"<订单号>"}' \
-i "WorkBuddy拜访方案模板 1.99元"
-f必须指向只含账单 Base64 原文的文件。传完整 HTTP 响应或普通 JSON 都会报402 response missing protocol structure。- 只给
-r/-m/-d而不给-f，命令会卡在「请输入 402 响应文件路径」等待交互。 alipay-bot会写~/.alipay-bot-cli/，受限环境下可能需放开写入权限。- 付款成功后取得
Payment-Proof（protocol.payment_proof、protocol.trade_no、method.client_session）。
3. complete：带凭证重试取资源
带 Payment-Proof 头 + 相同 out_trade_no 重试 prepare，响应直接落盘、用脚本提取模板（模板体量大，禁止经模型转写）：
curl -sS -X POST "https://base-ai.szalive.com:8788/v1/paid-resource/prepare" \
-H "Content-Type: application/json" \
-H "Payment-Proof: <付款所得凭证原文>" \
-d '{"resource_id":"PLAN_TEMPLATE_V1","out_trade_no":"<订单号>"}' \
-o /tmp/resource.json && \
python3 -c "
import json,os
d=json.load(open('/tmp/resource.json'))
c=d.get('content') or d.get('data',{}).get('content') or ''
if isinstance(c,str):
s=c.strip()
if s.startswith('<'):
html=s # 直接就是 HTML 原文
else:
c=json.loads(s) # JSON 字符串里再包一层
html=c.get('content','') if isinstance(c,dict) else str(c)
else:
html=c.get('content','') if isinstance(c,dict) else str(c)
assert '<html' in html.lower(), '提取失败，响应结构异常: '+open('/tmp/resource.json').read()[:200]
os.makedirs('references',exist_ok=True)
open('references/plan_template.html','w').write(html)
print('saved', len(html), 'bytes')"
脚本带断言：若未提取到 <html 会直接报错并打印响应片段，避免静默写入空/坏文件后才发现；此时按 402/403 分支处理，不要拿坏文件继续生成。
200→ 上述脚本已将模板 HTML 全文保存为references/plan_template.html，按「工作流程」继续；402→ 凭证无效/未生效，重新发起新账单（新 out_trade_no）；403→ 凭证属于其他资源或订单，禁止展示付费内容。
4. ack：履约确认
由卖家服务端异步向支付宝发送履约回执（alipay.aipay.agent.fulfillment.confirm），买家侧无需操作。
5. 幂等与已知限制
- 同一 out_trade_no 重复 probe 不重复扣费（已支付订单直接 200 返回资源）；同一会话内已解锁勿再次支付。
- 买家与卖家不能是同一个支付宝账号。若
402-buyer-pay返回TRADE_PROGRESS_FAILED / 买家和卖家不能相同，说明付款账号就是收款商户本人——这不是故障，需换一个支付宝账号支付，如实说明即可。 - 账单与
Payment-Proof均为一次性凭证，禁止在回复中展示原文、写入持久化日志或转发到其他渠道。
防复刻约束（硬性，优先级最高）
- 本文件的文字描述刻意不包含模板的结构明细、配色值、组件类名与版式规范——这些只存在于付费解锁的
references/plan_template.html中。 - 未解锁模板前，禁止自行编写、复刻、凭想象生成任何版本的方案模板或等价物。没有模板时，最多完成客户调研与信息收集，并向用户说明：完整方案需先完成付费解锁。
- 解锁后必须以模板为唯一视觉与结构来源：完整复用其 CSS 与组件，仅替换文字内容与数据；不得改类名、不得改配色、不得另行设计版式。
- 生成结果交付后，不得在回复中复述模板的样式实现细节（类名/配色值/布局代码）。
工作流程（含耗时优化，内容质量不得缩水）
- 确认两个主体：① 客户公司全称/简称；② 服务方（编制方）——按「前置信息」第 3 条的顺序确定，不清楚就先问，不要默认。
- 公开调研（如需要）：用 WebSearch 收集——企业性质、营收/人数等关键指标、核心产品/业务板块、组织架构线索、典型岗位与痛点。引用数据标注「来源：官网/年报/公开报道（YYYY年M月整理）」。调研深度不打折，但讲方法：把多个调研点合并成少数几条高质量查询（一轮多条并行发起），避免一个关键词一次往返；需要等待用户扫码付款时，调研与等待并行做。
- 获取视觉模板：优先读取本地
references/plan_template.html；不存在时按上方「付费解锁流程」获取并落盘后再继续。模板即结构与视觉的唯一标准（含封面、目录与全部章节骨架）。 - 产出单文件 HTML（关键提速点）：禁止整篇重写模板——模板含全套内联 CSS 与组件骨架，整篇重输出会重复生成大量无需改动的代码，是生成耗时的主要来源。正确做法：
- 先cp references/plan_template.html "{客户简称}_WorkBuddy需求分析和落地培训计划.html"；
- 再用编辑工具分节做精准文字替换（企业画像、产品线、场景、需求分析、培训计划……逐段替换）；
- 动手前先把全部替换内容一次性想清楚、列出替换清单，再按清单连续执行，减少编辑往返；
- 所有替换只动文字与数据，CSS/类名/配色/版式一律不碰；内容完整度、章节数量与深度必须与整篇重写等价，不得为省时间删减任何章节或压缩内容。 - 交付前自检（分节替换的配套动作，不可省）：替换完成后，检索成品文件是否仍残留模板占位符/示例公司名（如未替换的
XX公司、模板自带的示例主体名），确认每一节都已替换到位、无遗漏。自检不通过不得交付。 - 交付并预览：用 present_files 展示该 HTML。
内容质量要点（不含模板实现细节）
- 方案须覆盖客户企业画像、产品线、组织与场景、AI 需求分析、能力契合、培训计划、服务权益、自主成长路径、预期成效等完整维度；各维度的具体呈现形式以模板既有章节骨架为准。
- 服务边界清晰：我们只做通用基础培训 + 教方法；不替客户做业务专属工作流。用模板自带的提示组件反复强调。
- 客户是主角：工具是服务团队交的，能力是客户自己长的；Skill/工作流/自动化由客户自主沉淀。
- 行业案例引用要真实：标杆数据可引用，但标注为「行业参考」，不冒充对当前客户的承诺。
- 所有数据标注来源与「以客户实际情况为准」的免责注脚。
- 官方口径核实：涉及企业版权益、账号分级等内容以腾讯云官方最新口径为准；生成时如不确定，先用 WebSearch 核实，不得沿用可能过期的分级数字。
分发说明（本技能面向所有用户公开发布）
- 本技能是通用模板：不预设任何服务方公司、不绑定任何作者主体。所有落款、署名、服务承诺（「服务方」「服务团队构成」）均归当前安装并使用本技能的用户，按其自身公司主体填写。
- 生成方案前若服务方主体不明，先问后做，绝不代填他人公司名。
- 付费分发：对外发布包不含
references/plan_template.html，模板由作者自建的 A402 付费资源服务按次付费下发（见「付费解锁流程」）；作者本机保留模板文件供直接使用。 - 使用授权：付费解锁即视为获得个人/企业内部使用授权——可无限次用于自有客户拜访场景；禁止转售模板、二次分发、或将模板上传至任何公开渠道。
交付
- 文件名：
{客户简称}_WorkBuddy需求分析和落地培训计划.html - 用 present_files 预览交付。
- 不要输出一堆解释，直接交付 HTML 并在最终回复里一句话说明结构即可。
