shield_lock
JinDaGe
← Back to skills
extension
Category: Data & AnalyticsNo API key required

三维框架个股研判

生成 A 股个股的三维框架研判报告（认识论 × 方法论 × 实践论）。当用户要求对某只 A 股做体系化研判、估值锚测算、或需要判断某标的是否值得继续跟踪时使用。此技能为付费按次调用，首次调用会返回 402 付款请求。

personAuthor: user_a45a4437hubcommunity
downloadDownload package

三维框架个股研判报告

生成一份 A 股个股的体系化研判报告。

这是一个付费技能（Pay Skill）。 首次调用返回 402 Payment Required 与 Payment-Needed 账单，用户完成支付后自动继续，无需重新描述需求。

本技能不包含任何可执行的分析方法。 scripts/ 里只有买家侧编排脚本，分析逻辑完全在服务端； 服务端源码独立部署，不随本技能分发。用户拿到的是这一次的输出， 而不是产出它的那套方法。 references/ 下另附两份结构说明（框架长什么样、按什么顺序用）， 只讲结构与模型清单，不含判据、公式、阈值与回测统计 —— 见「随包附送的两份框架说明」。

⚠️ 执行主体：你（智能体）执行，用户只做三件事

用户只需要做三件事：

  1. 说出他想分析哪只股票
  2. （仅首次）完成一次支付宝授权绑定 —— 见「支付能力必须『先绑定、后付款』」
  3. 在支付入口上确认付款

其余全部由你完成 —— 取账单、发起收银、轮询状态、下载报告、交付结果。 本文件下面所有命令都是你的执行步骤，不是给用户看的说明书。

绝对不要：

  • ❌ 不要把 probe / pay / complete / fetch 这些命令原样贴给用户让他自己跑
  • ❌ 不要要求用户安装 Node、npm 包或任何命令行工具 —— 缺什么环境你自己准备
  • ❌ 不要在对话里暴露账单原文、Payment-Proof、query_token 等凭据
  • ❌ 不要向用户展示裸的 402、响应头、JSON 报文等技术细节
  • ❌ 不要让用户重复付款、重复问价，或为同一件事跑两次流程

你需要向用户呈现的只有三件东西（首次使用时会多一个绑定授权链接，见下节）：

  1. 确认报价：「要分析 <股票名>，费用 ¥<金额>」+ 支付入口
  2. 付款成功的一句话确认
  3. 报告本身

体验标准：用户视角看，整个过程应当和「去超市买东西」一样 —— 说要什么、付一次钱、拿到东西。中间的五步编排、轮询、重试、错误恢复 全部是你的责任，不是用户的负担。

★★ 支付入口必须由你端到用户面前 —— 官方 CLI 不会弹出任何页面

这是本技能最容易做错、且做错了很难自查的一步（2026-09-18 实测确认）。

官方 CLI 只是在终端里打印一段文本。 它不打开浏览器、不弹窗、不唤起支付宝、不生成卡片。 你在屏幕上读到的那段输出，用户一个字都看不到 —— 除非你把它转述、呈现出去。 所以结论很硬：你不给链接，买家那边就是「什么都没有」 —— 没有页面、没有金额、没有二维码。

官方 CLI（402-buyer-pay）的输出形态如下。下面的样例是脱敏的： <...> 是占位符，实际运行时那里会打印真实值 —— 金额与链接就是从这里读的。

**✓ 支付待确认**
**商品名称**：单只个股 · 三维框架研判报告（含财务深挖）
**支付金额**：29.00 CNY
**商户名称**：<商户名称>

**交易号**：<一长串数字>

**支付方式**：
- **电脑端用户**：请 [点击此处](https://u.alipay.cn/<短链码>) 打开收银台页面扫码支付
- **手机端用户**：请 [点击此处](https://u.alipay.cn/<短链码>) 唤起支付宝APP完成支付
MEDIA: file:///<本机临时目录>/openclaw/alipay-bot-cli/qrcode/payment_<交易号>-<哈希>.png

⚠️ 这一节曾把一次真实收银的原文原样抄进技能包（含卖家实名、交易号、 真实短链、本机绝对路径），是发布前的隐私扫描把它拦下来的（2026-09-18）。 引样例的目的是让你认出形态（哪一行是金额、哪一行是链接、哪一行是二维码）， 不是让买家知道卖家是谁、包是从哪台机器上打出来的。

你必须做到的四件事：

  1. 金额要说出具体数字：把 **支付金额**：29.00 CNY 读出来告诉用户。 ❌「费用已生成，请确认支付」　✅「要分析北方华创，费用 ¥29.00」
  2. 支付链接要作为可点击链接交给用户 —— 不要只贴成纯文本、不要塞进代码块里。
  3. 二维码要单独交付：MEDIA: 那一行指向一张真实存在的 PNG 文件。 ★ 这张 PNG 不是一个小二维码方块，而是整张收银台页面 —— 上面直接印着「支 | AI付」品牌头、「扫码授权付款」、金额 ¥29.00 和带支付宝 logo 的二维码。 换句话说：买家嘴里的「那个支付页面」，就长这样。 交付这一张图 = 金额 + 二维码同时到位，这是整个流程里对买家最有说服力的一步。 ⚠️ MEDIA: 是 openclaw 客户端的媒体约定，WorkBuddy 不会自动渲染它 —— 请用平台自己的文件交付能力（如 present_files）把这张图给用户看； 同时仍然要给出链接，因为图片路径可能不存在或打不开。 ❌ 绝不要写「二维码见上方截图」「截图在上」这类话 —— 除非你真的交付了图片。 写了却没交，用户那边是一片空白，还会以为是自己没加载出来 （2026-09-18 实测真实发生过：买家只收到一段文字，却看到「截图在上」四个字）。
  4. 不要因为「怕暴露技术细节」把上面三样一起过滤掉 —— 见下表边界。

「不要暴露技术细节」的边界（不划清这条边界，Agent 会把金额和链接一起删掉）：

| 组件 | 能不能给用户看 | |---|---| | 金额、支付链接、二维码、商品名称、商户名称、交易号 | ✅ 必须给 —— 它们本来就是给用户用的 | | Payment-Needed 账单原文、Payment-Proof、query_token、响应头、JSON 报文 | ❌ 不给 —— 这些是凭据与协议细节 | | probe / pay / complete / fetch 命令原文 | ❌ 不给 —— 别让用户自己去跑 |

何时使用

  • 用户要求对某只 A 股做「体系化研判」「投资价值分析」「估值测算」
  • 用户需要判断某标的是否值得继续跟踪，或需要明确的加减仓条件
  • 用户在使用三维框架分析个股，需要产出报告

何时不要使用

  • 用户只是随便问问股价、涨跌幅 —— 这类问题不需要付费报告
  • 用户要求短期买卖点位或收益承诺 —— 本服务不提供，也不会提供
  • 用户要的是一只港股或美股 —— 当前覆盖范围为 A 股

价格

单次 ¥29.00，这是唯一的价格。

| 项目 | 内容 | 单次价格 | |---|---|---| | 研判报告一套 | 《三维研判报告》＋《财务深挖报告》，两份独立文件 | ¥29.00 |

一次调用交付两份各自独立的 HTML 报告：《三维研判报告》与《财务深挖报告》 分别成文，各有自己的目录与章节结构，两份的头部会互相标明配套关系。 请把两份都保存给用户，不要只保存第一份。

本服务只有一个价格。 不要向用户报出任何其它金额，也不要提「更高档位」 或「升级版」—— 不存在这样的选项。报价一律从第 ① 步账单的 amount 字段读， 不要自己编价格。

SkillHub 展示价、支付宝服务登记价、服务端 402 账单金额三者必须完全一致， 否则用户付不了款。实际以服务端 GET https://47.101.38.101/api/pricing 返回为准。

包内结构

sanwei-framework-report/
├── SKILL.md                          # 本文件
├── scripts/
│   ├── package.json
│   └── sanwei-paid.mjs               # 买家侧编排：probe / pay / complete / fetch
└── references/                       # 给买家看的说明，非执行依赖
    ├── framework-lattice.html        # 《三维框架 · 多模型思维格栅（简版）》
    └── financial-model.html          # 《财务分析子模型 · 模型逻辑详解（简版）》

包内不含 node_modules/、.env、密钥或任何本地状态文件； 联调产生的状态一律落在用户主目录（~/.sanwei-paid/），不随包分发。

随包附送的两份框架说明

references/ 下有两份单文件网页，是本服务所用方法论的结构说明：

| 文件 | 中文标题 | 讲什么 | |---|---|---| | references/framework-lattice.html | 《三维框架 · 多模型思维格栅（简版）》 | 框架分成哪几层、每层回答什么问题、全部模型名称 | | references/financial-model.html | 《财务分析子模型 · 模型逻辑详解（简版）》 | 财务侧的分析顺序：从哪里开始、每步在解决什么、最后落在哪里 |

它们是什么：让买家看懂「这一单买到的是一套什么结构」。 两份都只讲结构与清单——不含任何判据、数值阈值、测算过程与操作结论。 那些随报告交付，不随包分发。报告和这两份说明是两回事，不要混为一谈。

你要做的：把报告交付给用户之后，补一句告诉他这两份说明也在本地技能目录里， 并给出绝对路径（本技能安装目录下的 references/），让他需要时自己打开。

  • ✅ 可以说：「另外附两份框架说明，方便你看懂报告的结构：<绝对路径> （《三维框架 · 多模型思维格栅（简版）》《财务分析子模型 · 模型逻辑详解（简版）》）」
  • ❌ 不要说「这是分析方法的完整说明」或「照这个你自己也能做」——不是，也做不到。
  • ❌ 不要把这两份说明当成报告内容去解读、续写或据此给出买卖结论。

依赖（你自己准备，不要让用户装）

买家侧支付能力由支付宝官方 CLI 提供（请勿自行实现付款或签名）：

# 由你执行。这是环境准备，不是用户任务。
# ⚠️ 版本已锁定（2026-09-17）：不要改回 @latest。
#    @latest 每次安装拉到的都可能是另一份代码 —— 那样「这个包已审过」的结论
#    明天就不成立。需要升级时，先重新核对官方包的完整性签名与 postinstall 脚本，
#    核完再把下面的版本号改掉。
npx -y @alipay/agent-payment@1.0.26 install

编排脚本零第三方依赖，仅使用 Node 内置模块（要求 Node ≥ 18）。

环境缺失时的处理原则：

| 缺什么 | 你怎么做 | |---|---| | Node < 18 或没有 Node | 先找宿主环境自带的运行时（多数智能体沙箱自带）；确实没有再装 | | 支付宝官方 CLI 未安装 | 自己执行上面的 npx 安装命令，不要让用户去装 | | 安装需要用户授权 / 联网确认 | 说明「我需要安装一个支付组件」并请求一次授权，然后接着往下做 | | 支付钱包未开通 | 先完成绑定再付款，见下节；不要把命令行细节丢给用户 |

支付能力必须「先绑定、后付款」

支付宝「AI 付」的绑定关系是一对一：一个买家环境 ↔ 一个支付宝账号。 绑定由用户本人在他自己的支付宝里完成，一次即可、长期有效。

⚠️ 不要指望「付款时顺带授权」。 那条路会让第一个付款的人永久占用这个环境 —— 此后换任何账号扫码都会被支付宝拦下（错误码 ALIN42294： 「付款账号和支付宝当前登录账号不一致，请用付款账号登录支付宝后再继续付款」）。 这是买家侧最容易踩、也最难自查的坑，必须在付款前主动处理掉。

# ⓪ 判断当前是否已绑定（无副作用，可随时执行）
alipay-bot check-wallet --json
#   → {"status":"bound"}   已绑定，直接走 ①
#   → 其它                 未绑定，执行下面的绑定流程

# 未绑定时：取授权链接
alipay-bot apply-wallet -a "<agent 名称>"
#   → 把返回的**授权链接**呈现给用户，让他在支付宝里完成核身
#   → 用户会拿到一个 **6 位绑定码**

# 用户把 6 位码给你之后：
alipay-bot bind-wallet -c <6位码>

这一步的用户配合只有两下：点开授权链接完成核身 → 把 6 位码告诉你。 命令本身不要丢给用户，你只负责给他授权链接、替他把码填进去。

唯一需要用户亲自操作的是「确认付款」本身（以及首次的这次绑定）—— 必须由用户本人在支付界面上完成。其余任何环节，能自己做就自己做。

调用流程

端点在服务端

POST https://47.101.38.101/api/report
Content-Type: application/json

{ "sku": "REPORT_BASIC", "symbol": "<股票代码>.SZ" }

服务端地址固定为 https://47.101.38.101，已写进本技能包与编排脚本的默认值， 调用时不需要再传 --resource-url。该地址只走 HTTPS（IP 证书）， 未付款时端点返回 402 与 Payment-Needed 响应头。

你的五步

下面五条命令由你连续执行完。用户只在两处参与：⓪（仅首次）完成绑定、② 确认付款。

# ⓪ 确认支付能力已绑定（首次必做，无副作用）
#    未绑定 → 先按上一节的绑定流程处理，绑完再继续
alipay-bot check-wallet --json

# ① 取账单：预期 HTTP 402 + Payment-Needed（脚本会原样保存账单与原始请求）
#    → 用户此时只应看到「费用 ¥xx，请确认支付」
node scripts/sanwei-paid.mjs probe --symbol <股票代码>.SZ

# ② 发起收银：调用官方 CLI 生成支付入口
#    → ★ 它只会**打印**一段文本（金额 + 链接 + 二维码），**不会弹出任何页面**。
#      你必须把这三样端到用户面前，见上文「支付入口必须由你端到用户面前」。
#    → ⚠️ **退出码 10 = 已生成收银入口、正在等用户付款，这是正常状态，不是失败。**
#      任务面板可能把它显示成 failed —— 不要据此告诉用户「支付失败」。
node scripts/sanwei-paid.mjs pay --state-dir "<状态目录>"

# ③ 取回资源：付款后查询原订单（官方 CLI 会自动发送履约回执）
node scripts/sanwei-paid.mjs complete --state-dir "<状态目录>"

# ④ 取报告：报告异步生成，轮询到 DONE 后下载
node scripts/sanwei-paid.mjs fetch --status-url "<status_url>" --out report.html

④ 期间的等待要主动管理：报告生成需数分钟到十几分钟。 不要干等，也不要让用户盯着终端 —— 告诉用户「报告正在生成，完成后我发给你」， 按下面的节奏轮询，拿到后直接把报告交给用户。

② 之前必须先把报价说清楚。用户有权在付款前知道要花多少钱、买的是什么。 报价从第 ① 步的账单里读（amount 与 goods_name），不要自己编价格。

402 账单长什么样

账单在 Payment-Needed 响应头里，是 Base64URL 编码（已去 padding）的 JSON， 两层结构（响应体只用于调试，支付依据是响应头）：

HTTP/1.1 402 Payment Required
Payment-Needed: eyJwcm90b2NvbCI6eyJvdXRfdHJhZGVfbm8iOiJQUzIwMjYwOTEzLi4uIn0s...

解码后的结构：
{
  "protocol": {
    "out_trade_no": "PS20260913...", "amount": "29.00", "currency": "CNY",
    "resource_id": "/api/report", "pay_before": "2026-09-13T16:12:58+08:00",
    "seller_signature": "<RSA2 签名>", "seller_sign_type": "RSA2",
    "seller_unique_id": "<卖家标识>"
  },
  "method": {
    "seller_name": "...", "seller_id": "...", "seller_app_id": "...",
    "goods_name": "单只个股 · 三维框架研判报告（含财务深挖）",
    "seller_unique_id_key": "seller_id", "service_id": "API_xxx"
  }
}

做法：把 Payment-Needed 的原文原样落成文件，交给官方 CLI 发起收银， 由用户确认付款。不要自己解析、解码或修改账单字段。

付款后

用原来的请求参数重试（方法、请求体、请求头必须一致），并携带 Payment-Proof。 服务端会调用 alipay.aipay.agent.payment.verify 校验凭证，通过后受理任务并发送履约确认。

Payment-Proof 同样是 Base64URL 的两层结构，脚本会从官方 CLI 的输出里取得， 不需要手工拼接或向用户索要。

注意：如果付款后拿不到凭证，不要重新下单，也不要问用户要第二遍钱 —— 应当提示用户稍后重试。

取报告

报告异步生成（数分钟到十几分钟），验付通过后返回：

{
  "resource_id": "/api/report",
  "content": "{...受理结果...}",
  "job_id": "J20260913...",
  "status": "ACCEPTED",
  "query_token": "…",
  "status_url": "…/api/report/{job_id}?token=…",
  "download_url": "…/api/report/{job_id}/download?token=…&doc=main",
  "docs": [
    {"kind": "main", "title": "三维研判报告", "url": "…?token=…&doc=main"},
    {"kind": "fin",  "title": "财务深挖报告", "url": "…?token=…&doc=fin"}
  ],
  "fulfillment_confirmed": true
}

轮询 status_url 到 DONE，然后遍历 docs 逐份下载（通常 2 份）。 download_url 只指向主报告、仅为兼容保留 —— 不要只下它那一份。 首次间隔 10 秒，此后每 15–20 秒一次，不要密集轮询。

两份报告都交付之后，补一句把 references/ 下那两份框架说明的绝对路径告诉用户 （见上文「随包附送的两份框架说明」）—— 只说路径与用途，不要展开讲内容、不要据此延伸结论。

三条硬约束

  1. 账单原样保存 —— 不解码、不改字段，直接交给官方 CLI。
  2. 原始请求保持一致 —— POST 请求在 pay 与 complete 两处必须携带一致的 方法、请求体与请求头。
  3. 状态不明先查单 —— 不重复付款、不重复请求资源；成功路径不追加独立回执。

状态码

| 状态码 | 含义 | 该怎么处理 | |---|---|---| | 200 | 已受理，或有新状态 | 正常处理返回体 | | 402 | 需要付款，或凭证未通过校验 | 看响应体里的 error 字段区分 | | 403 | 查询凭证无效 | 用受理时返回的 query_token 重试 | | 404 | 订单或任务不存在 | 重新发起调用 | | 409 | 报告尚未就绪 | 继续轮询 | | 502 | 资源已生成但履约确认失败 | 用同一 Payment-Proof 重试，不要重新付款 | | 503 | 支付结果暂不可确认 | 提示用户稍后重试，切勿让其重复付款 |

脚本自身的退出码 ≠ HTTP 状态码（别混淆）

sanwei-paid.mjs 用退出码区分「失败」与「还没付款」：

| 退出码 | 含义 | 怎么处理 | |---|---|---| | 0 | 成功 | — | | 10 | 已生成收银入口，正在等用户付款 | 正常状态，不是错误。等用户付完再走 ③ | | 2 | 参数不对 | 检查命令参数 | | 4 | 没有拿到 402 账单 | 服务端未返回 Payment-Needed 头 | | 5 | 没找到 alipay-bot | 你自己装（见「依赖」），不要让用户装 | | 6 | 请求本身失败 | 看报错文案；状态不明先查单，不要重复付款 |

⚠️ 任务面板有时会把退出码 10 显示成 failed —— 那是显示问题，不是支付失败。

使用边界（请务必遵守）

调用本技能时，向用户说明：

  • 报告是分析工具的输出，不是买卖建议
  • 报告不包含目标价、不包含买卖点位、不承诺任何收益
  • 投资决策与风险由用户自行承担
  • 若用户要求「能不能买」「买多少」，应说明本服务不提供此类结论

常见问题

Q：能不能先看报告再付款？ 不能。报告在服务端生成，验付通过后才交付。

Q：付款后生成失败怎么办？ 任务状态会变为 FAILED 并附原因。同一订单不会重复扣费。

Q：重复提交同一个订单会重复收费吗？ 不会。订单已绑定任务的，重试会直接返回原任务，是幂等的。

Q：本地联调的状态文件会跟着技能包一起发布吗？ 不会。状态目录默认在 ~/.sanwei-paid/，不在技能包内。

Q：为什么付了款还返回 402？ 常见三类：① 支付宝服务登记价与服务端账单金额不一致；② 服务端未在返回账单前 持久化订单；③ 使用了过期的凭证。状态不明时先查单，不要重复付款。

Q：用户扫码后提示「付款账号和支付宝当前登录账号不一致」（ALIN42294）怎么办？ 说明这个环境已经绑定到另一个支付宝账号了 —— 绝大多数情况是首次付款时被动绑定 造成的（谁先付，这个环境就归谁）。支付宝的弹窗会明确告诉你它要哪个账号。两条路：

① 让原绑定账号的人来付（弹窗上点「登录付款账号」）； ② 换绑：由原账号本人在支付宝里关闭 AI 付 → 回到 ⓪ 重新绑定。

⚠️ 不要反复更换付款人去试 —— 在绑定关系改变之前，换谁来扫都会被拦。 只要在 ⓪ 步把绑定做对，这个错误根本不会出现。