| name | polymarket-market-pulse-zh |
| description | 发现 Polymarket 上有利可图的预测市场。通过 AI 概率估算与市场隐含赔率的对比，识别定价偏差最大的前 3 个市场，从信息流、结算清晰度、流动性和波动性四个维度进行分析，并给出仓位建议。当用户提到 Polymarket 机会、预测市场推荐、每日市场脉搏、市场分析、找到错误定价的市场时使用此技能。 |
Polymarket 每日市场推荐
扫描 Polymarket 上的错误定价预测市场。通过网络搜索估算真实概率，对比市场赔率，推荐前 3 个最具盈利潜力的机会，并提供仓位建议。
工作流程
以下 7 个步骤是推荐的推理脚手架，不是硬性配方：你可以按事件特性调整各步的深度与顺序，文中出现的量化参数（证据更新幅度、edge 分档、排序公式）都是默认值——若你有更好的判断，可以偏离，但必须在报告中写明偏离理由。
两类要求不属于可调整范围：
- 认知红线（任何最终推荐都不可省略）：第 3 步的结算规则获取、A0 resolution source 实时查验、A1.5 事实溯源。
- 程序接口与风控：报告的可解析字段格式、流动性硬性门槛。仓位最终以代码层按概率重算的结果为准，报告中的仓位数字是人工审计字段。
你的概率估算是唯一进入交易管道的数字，把主要精力花在“把概率做准”上。
第 1 步：获取市场数据
运行市场数据获取脚本，从 Polymarket Gamma API 拉取活跃市场：
python scripts/fetch_markets.py --pages 5 --min-liquidity 5000
脚本通过 /events 端点获取数据（每个事件包含嵌套市场），按交易量、流动性、上线时间和竞争度四个维度各分页 5 页（每页 50 个事件），扫描约 1,000 个事件。自动合并去重、展开为独立市场。
如需深度扫描（如每周全面复盘），使用 --pages 20 覆盖最多 4,000 个事件。
如果脚本执行失败（网络错误、API 变更），改用手动 API 调用。端点详情见 references/polymarket-api.md。
第 2 步：初筛候选市场
从获取的市场中，用以下条件筛选至 10-15 个候选。
注意：脚本已自动过滤以下垃圾市场，无需手动处理：
- 加密涨跌赌盘（标题含 "Up or Down" 或时间段格式）
- 24 小时内到期的市场
- Coin flip 市场（所有 outcome 价格在 0.48-0.52 范围）
排除：
- 最大 outcome price > 0.95 或最小 < 0.05 的市场（已近定论，无 edge 空间）
- 流动性 < $5,000 的市场（太薄无法交易）
- 问题模糊或无法通过网络搜索研究的市场
优先选择：
- 7 天内新建的市场 — 定价效率较低
- 24 小时交易量高的市场 — 说明有活跃的信息流和关注度
- 能通过网络搜索获取强证据的主题
Longshot Bias 提醒（先验，不是配额）：
统计规律表明，Yes 价格 < 20% 的市场，Yes 侧常被系统性高估，No 侧是最常见的系统性 edge 来源。
筛选候选时把这一先验纳入考虑（Yes < 20% 且流动性 > $50k 的市场值得专门看一眼 No 侧），
但是否入选、选几个由证据决定——不要为满足数量而凑。
多结果市场（Top-N 偏差扫描）：
部分市场有 2 个以上结果（如选举、锦标赛冠军）。不要跳过这些市场。 多结果市场往往流动性最深、参与者最多，
但因为 outcome 数量多，个别 outcome 的定价效率反而更低。
处理方式：
- 对每个多结果市场，计算所有 outcome 的隐含概率之和（应接近 100%）。如果总和显著 > 100%，
说明存在系统性溢价（vig），No 侧更有优势。
- 提取定价偏差最大的 2-3 个 outcome 作为候选，其余跳过。
偏差判定：与快速 Web 搜索得到的粗略基准概率对比，偏差最大的即为候选。
- 每个被选中的 outcome 按照单独的二元市场处理——买入该 outcome 的 Yes 或 No。
- 流动性分析使用对应 outcome 代币的订单簿（取自
clob_token_ids）。
- 在报告元数据中注明：扫描了 N 个多结果市场，从中提取了 M 个 outcome 候选。
第 3 步：信息搜集与概率估算
对每个候选市场（约 10 个），进行网络调研并形成独立的概率估算。这是最关键的步骤。
结算规则获取（必须在概率估算之前执行）：
对每个通过初筛的候选市场（~10 个），必须获取完整结算规则和 annotations。
优先方式 — scrape 脚本（推荐）：
cd ~/.claude/skills/api-trade-polymarket/scripts && npx tsx scrape-market.ts --slug <event_slug> --sections context,rules
脚本通过 HTTP 获取页面 SSR HTML 中的 __NEXT_DATA__，返回 JSON 包含：
rules.description — 完整结算规则（比 API description 更完整，不截断）rules.resolution_source — 官方数据源market_context.annotations[] — 市场注释（含 summary、date、hidden 状态）market_data — volume、liquidity、各 outcome 的 bid/ask
纯 HTTP 方案，无浏览器依赖，速度快。
回退方式 — WebFetch：
如果 scrape 脚本返回数据不足（如 rules.description 为空），回退使用 WebFetch 访问 https://polymarket.com/event/{event_slug} 提取规则。
从返回数据中提取：
- 基本结算条件（
rules.description）
- Annotations 中的规则澄清和上下文信息（
market_context.annotations）
- 具体的定量门槛（如"80% 下降"、"连续 3 天"等）
- 官方数据源（如 IMF PortWatch、Binance、CME 等）
- 边界情况处理
将提取到的完整规则存储，在后续概率估算中直接引用。
注意： 页面 "Market Context" 标签的可见内容由客户端 JS 渲染，scrape 脚本返回的是 __NEXT_DATA__ 中的原始 annotations 数据（可能标记为 hidden: true）。Playwright 方案因 macOS 沙盒限制不可用。
为什么这一步是强制的： 市场页面上的 "Additional context" 经常包含创建后追加的定量门槛和数据源定义，
这些信息直接决定结算结果。仅靠 API description（截断 500 字符）做判断会导致严重误估。
Resolution Source 实时查验（A0 模块 — 必须在 A1 之前执行）：
如果 resolution rule 指定了具体的数据源（CDC case counter、FIDE 官网、AP/Fox/NBC、FIFA 官方、选举委员会等），必须直接访问该数据源获取当前状态，而不是依赖 AI 记忆或推测。
- 对每个候选市场，从
rules.resolution_source 中提取官方数据源 URL
- 访问该 URL（或搜索最新数据），获取当前真实状态
- 如果能查到具体数据，将其作为概率估算的硬约束输入；如果数据源不可访问或无明确当前状态，标注"resolution source 当前状态未确认"并在证据链中降低相关主张的权重
- 在报告中列出：数据源名称 + URL + 查询时间 + 查到的关键数据
示例：
- 麻疹市场：访问 CDC 页面 → 2026 年至今 1,575 例 → 距 12,500 差 10,925 例
- FIDE 候选人赛：访问 FIDE 官网 → Caruana 2.5/3 并列领先 → 不存在"两连败"
- 加州州长：搜索最新民调 → Swalwell 13-17% 领先
为什么这一步是强制的： AI 对正在进行中的事件（赛事、选举、疫情）的事实认知经常过时或错误。直接查验 resolution source 可以防止基于错误事实做出的交易决策。
信息搜集（A1 模块）：
- 对每个市场执行 2-3 个定向网络搜索
- 记录每个信息源的 URL 和关键发现
- 优先级：resolution source 指定的官方数据（A0 已获取） > 权威媒体 > 专家分析 > 社交情绪
事实校验（A1.5 模块 — 在 A2 之前执行）：
在开始概率推理之前，必须对自己即将使用的核心事实主张做交叉验证：
- 列出将用于概率估算的每个关键事实主张（如"Caruana 两连败""SC 麻疹爆发已结束"）
- 对每个主张，确认至少有一个可溯源的信息来源（URL + 日期）
- 如果某个主张无法溯源 → 标记为"未验证"，在证据链中降低其权重
- 禁止使用无法溯源的事实主张作为主要证据
推理与预测（A2 模块）：
- 从 resolution rule 的触发条件出发（不是从"事件本身"出发）
- 先评估 resolution 定义的触发条件被满足的概率
- 根据每条已验证的证据进行更新。参考幅度（默认值）：强证据 10-20% 偏移、中等 5-10%、弱 1-5%——证据的真实分量由你判断，可以偏离这些幅度，但要写明为什么这条证据值这么多
- 标注置信度：高 / 中 / 低
- Longshot 校准：对市场价 < 20% 的事件，默认假设市场高估了 Yes 概率。
从历史基准率出发，而非从市场价出发。问自己："同类事件在给定时间窗口内
发生的历史频率是多少？" 通常远低于市场定价。
详细方法论见 references/analysis-framework.md。
第 4 步：计算价值偏差（Edge）
对每个候选市场计算：
Edge = AI估算概率 - 市场隐含概率
其中 市场隐含概率 是第 1 步中 outcome_prices 的值（如 0.35 = 35%）。
筛选参考分档（默认值，可按证据质量偏离并说明理由）：
- Edge > 20%：强信号 — 高优先级推荐
- Edge 10-20%：中等 — 标准推荐
- Edge 5-10%：弱 — 仅在其他维度表现突出时才提及
- Edge < 5%：通常跳过
综合得分排序（默认排序方法）：
综合得分 = |Edge| × log10(Liquidity + 1)
示例：Edge 20% + $10k 流动性 = 0.20 × 4.0 = 0.80；Edge 10% + $500k 流动性 = 0.10 × 5.7 = 0.57。Edge 仍然主导但流动性极差的市场会被降权。
市场数据中已预计算 liquidity_score 字段（= log10(liquidity + 1)），直接使用即可。若你认为另一种排序更能反映真实机会（例如证据确定性极高的中等 edge 优于证据薄弱的大 edge），说明理由后可偏离。
硬性门槛（风控，不可偏离）： 流动性 < $5,000 的市场不得进入最终推荐。
选取最值得交易的市场，最多 3 个——达不到你的标准就少推荐，不要为凑数纳入弱推荐；一个都没有时明确说明本轮无推荐。
月化收益估算：
对每个通过 edge 阈值的候选市场，计算：
- 持有期
d：取自 end_date（如存在）；否则默认 90 天（标注"假设值"）。下限取 7 天。
expected_return = (p - c) / cmonthly_return = (1 + expected_return) ^ (30 / d) - 1
在逐市场分析中显示。标注：d<7 → "极短期仅供参考"；d>365 → "长期资金锁定"；无 end_date → "(假设 90d)"。
Longshot Bias 提醒：
不要仅仅因为"买 No 利润看起来少"而忽略这类机会——高胜率 × 适当仓位 = 稳定收益。
最终推荐里有没有"买 No"、有几个，由证据决定，不设配额；但如果你的候选里没有任何 No 侧机会，
值得回头检查一遍是否漏掉了被高估的 longshot。
第 4.5 步：评论区校验
对通过 Edge 筛选的前 3 个推荐市场，执行评论区校验。这是概率估算的最终验证环节，独立于第 3 步的网络调研。
获取评论：
对每个 Top 3 市场，运行 scrape 脚本获取评论（优先方式，自动处理 Series/Event ID 查找）：
cd ~/.claude/skills/api-trade-polymarket/scripts && npx tsx scrape-market.ts --slug <event_slug> --sections comments --comment-limit 20 --comment-sort likes
返回 JSON 中 comments.items[] 包含每条评论的 user、body、likes、created_at、is_holder、positions。
如需按时间排序：--comment-sort newest。
为什么优先用 scrape 脚本： 很多市场的评论挂在 Series entity 下（而非 Event），脚本会自动从 Gamma API 的 series[].id 字段提取 numeric Series ID 进行查询。
回退方式 — polymarket CLI：
polymarket events get <event_slug> -o json | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])"
polymarket comments list --entity-type event --entity-id <id> --limit 20 -o json
注意：CLI 仅通过 Event entity type 查询，部分 Series 维度的评论可能无法获取。
如果返回 0 条评论（部分事件确实没有评论），在报告中标注"该市场无用户评论"并跳过评论校验。
分析维度：
逐条审查评论，寻找以下信号：
- 新闻源引用： 评论中是否引用了第 3 步搜索未覆盖的新闻来源？如有，点开验证。
- 定量分析： 评论者是否提供了具体的数据、统计、或模型？逻辑是否成立？
- 内部信息信号： 评论者是否暗示掌握非公开信息（需谨慎评估可信度）？
- 对立观点： 与当前 AI 判断相反的评论，其推理是否合理？是否引用了被忽略的证据？
- 结算规则讨论： 评论者是否就结算标准的模糊地带展开讨论？这些讨论是否揭示了潜在风险？
概率修正：
- 如果评论揭示了第 3 步未覆盖的实质性新信息 → 重新评估概率
- 如果评论区存在关于结算标准的广泛争议 → 降低置信度
- 如果多位持仓者的推理一致支持某方向，且逻辑成立 → 作为佐证（非决定性）
- 如果未发现新的实质信息 → 维持原判断
输出要求：
在报告的每个推荐市场中，添加"评论区校验"区块，记录校验结果。
如果校验导致概率修正，在修正后的概率旁标注"（评论区校验后调整：原 XX% → 现 YY%）"。
第 5 步：流动性分析与仓位定量
对前 3 个市场分别获取订单簿：
python scripts/fetch_orderbook.py <token_id> --slippage 0.02
使用市场数据中的 clob_token_ids。看涨 Yes 用第一个 token ID；看涨 No 用第二个。
脚本输出：
- 买卖价差和中间价
- 2% 滑点内可执行的最大订单量
- 流动性等级和建议仓位范围
1/4 凯利仓位管理：
对前 3 个推荐市场分别计算：
-
f* = (p - c) / (1 - c) — p = AI 估算的买入方向胜率，c = 买入方向的入场价格
-
f_q = f* / 4
-
kelly_amount = f_q × 资金总额（默认资金 $10,000；如用户指定则使用用户值）
-
liquidity_cap = 0.10 × buy_capacity.max_cost_usd
-
recommended_size = min(kelly_amount, liquidity_cap)，用于人类可读报告中的建议仓位
-
Pulse Direct 在 live 执行前会在代码里重算 quarter Kelly，且 live 风控可能继续把这个数字往下裁
-
position_pct = recommended_size / bankroll（实际分配的资金比例）
显示：完整凯利 %、1/4 凯利 %、凯利金额（% → $）、流动性上限（% → $）、建议仓位以资金百分比为主（附 $ 等值），并说明 live 执行可能进一步下调。
安全规则：若 p ≤ c → 凯利 ≤ 0，不推荐。f* 显示上限 100%。
第 6 步：生成推荐报告
按 references/output-template.md 中的模板格式化最终输出。
每个推荐市场必须包含：
- 市场链接（
https://polymarket.com/event/{event_slug}，使用事件级 slug 而非市场 slug）
- 当前隐含概率和价差
- AI 估算概率、置信度和 edge 值
- 结算规则摘要 + resolution source URL（从 A0 模块获取的数据源及当前状态）
- 四维分析（信息流、结算清晰度、流动性、波动性）— 各 1-5 分并附简要说明
- 仓位建议（方向、规模范围、限价、下单策略）
- 完整的信息源列表（URL + 关键要点）
- 事实校验清单（A1.5 模块输出：每个关键事实主张 + 溯源 URL + 验证状态）
时间戳要求（重要）：
- 报告头部：记录报告生成时间和市场数据获取时间
- 每个市场：记录市场数据时间和 AI 判断时间
- 每个信息源：记录信息获取时间
- 所有时间使用 UTC 时区，格式：
YYYY-MM-DD HH:MM:SS
第 7 步：保存报告文件
将完整报告保存为 Markdown 文件：
mkdir -p ~/polymarket-reports
文件路径： ~/polymarket-reports/market-pulse-{YYYY-MM-DD}-{HHMMSS}.md
使用 Write 工具将报告保存到上述路径。保存后向用户确认文件路径。
示例文件名： market-pulse-2026-02-23-134500.md
追加推荐历史：
保存报告后，追加到 ~/polymarket-reports/recommendation-history.md：
- 若文件不存在，创建并写入表头：
| Date | Market | Link | Direction | Entry Price | AI Prob | Edge | Full Kelly | 1/4 Kelly | Position | Mo. Return | End Date | Status |
|---|
- 每个推荐市场追加 1 行（每次运行 3 行）。市场问题截断至 50 字符。Link 列填写 Polymarket 事件链接（如
https://polymarket.com/event/{slug}）。
- 禁止覆盖 — 始终追加。
- 先读取文件确认表头存在，再追加行。
终端摘要输出（重要）：
保存报告后，在终端（非文件）中向用户输出简明摘要，必须包含可点击链接：
Top 3 推荐市场逐个输出格式：
### {排名}. {市场问题} — {方向} @ {入场价}
- **链接：** https://polymarket.com/event/{event_slug}
- **Edge:** {edge} | AI {ai_prob}% vs 市场 {market_prob}% | 置信度：{confidence}
- **建议仓位：** {position}（{position_pct}% of bankroll）
- **EMR:** {monthly_return}%（{d}天）
然后输出一张候选池总览表，包含 Top 3 + 次优 5 个（共 8 个），按综合得分排序：
| # | 市场 | 方向 | 市场价 | AI 估计 | Edge | EMR | 链接 |
|---|------|------|--------|---------|------|-----|------|
| 1 | {问题，截断50字符} | {Buy Yes/No} | {market}% | {ai}% | {+X%} | {X%} | [link](https://polymarket.com/event/{slug}) |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 8 | ... | ... | ... | ... | ... | ... | ... |
注：EMR = Estimated Monthly Return（预估月化收益）。第 4-8 名未做深度流动性分析和评论区校验，仅供参考。
依赖
- polymarket CLI (Rust,
~/.cargo/bin/polymarket)：fetch_orderbook.py 和评论回退方案均依赖此工具。确认已安装：polymarket --version
- scrape-market.ts：位于
~/.claude/skills/api-trade-polymarket/scripts/，用于获取结算规则和评论。需要 npx tsx。
- fetch_markets.py 仍直接调用 Gamma API（CLI 无法替代其并发多维度扫描逻辑）。
CLI 快捷工具
以下 polymarket CLI 命令可在工作流中按需使用，无需额外脚本：
| 命令 | 用途 | 适用步骤 |
|---|
clob batch-prices <ids> --side buy | 批量价格查询 | Step 2 快速筛选候选价格 |
clob spreads <ids> | 批量 spread 查询 | Step 2 流动性快筛 |
clob price-history <id> --interval 1d | 价格历史 | Step 3 波动性分析 |
markets search "query" | 市场搜索 | 按关键词定向查找 |
markets get <slug> | 单个市场详情 | 任意步骤补充数据 |
故障排除
- 脚本返回空结果：降低
--min-liquidity 阈值或增加 --pages（如 --pages 20）以扫描更多市场
- 获取速度慢：
--pages 20 需要 80 次 API 调用（20 页 × 4 维度），约需 30-40 秒。可用 --pages 5 加速
- 订单簿获取失败：token ID 可能无效；通过 Gamma API 确认
enableOrderBook 为 true。fetch_orderbook.py 依赖 polymarket CLI，确认 CLI 可用。
- 通过筛选的市场太少：将 edge 阈值放宽至 5%，或纳入 edge 中等但流动性好的市场
--limit 参数：已废弃但仍兼容，会自动映射为 --pages- CLI 不可用：
fetch_orderbook.py.bak 是原始 urllib 版本，可在 CLI 不可用时回退
参考文件
