Polymarket Bot 教程 · 第 31 章，共 32 章
让你的 Polymarket bot 正式上线：首次入金 25-50 USD、止盈和止损规则、提醒阈值（Telegram/email）、reconciliation 频率，以及第一周的扩展计划。
本章内容
从 paper 切换到 live 的过程，是大多数 builder 不小心亏掉第一笔入金的地方。本章提供上线前检查清单，以及前一周的执行纪律，帮助你在 bug 变成亏损之前发现它们。
- 上线前检查清单
- 首次入金：25-50 USD
- 来自生产环境的 TP/SL 规则
- 监控：Telegram、email、dashboard
- reconcile 频率：每个 fire_exits 周期
- 第一周：保持贴近，保持小仓位
- 扩展：何时追加入金
上线前检查清单
在把 bot 从 paper 切到 live 之前，按顺序逐项检查如下内容。
- 30 笔已关闭的 paper trades。书面成功标准已达到或超出。
- paper 和 live 之间的 diary 格式完全一致。使用同一套 JSONL schema。
- VPS 已部署。bot 是唯一运行的进程；systemd unit 已配置。
- HALT 文件机制已测试。
touch /opt/pmt/HALT可在 30 秒内停止 bot。 - Telegram alerts 已配置。测试提醒发送成功。
- 每日亏损 kill switch 已测试。模拟 10% drawdown；确认 halt 触发。
- 链上 reconciliation 已测试。手动制造 diary 不一致；确认 halt 触发。
- 入金地址是 proxy wallet-即 Polymarket 替你交易时实际持有资金的智能合约钱包（对应 POLY_FUNDER_ADDRESS）-而不是 EOA（你自己的外部账户，externally-owned account）。已通过 SDK
wallet show验证。 - USDC/pUSD 授权已设置。standard exchange 和 NegRisk exchange 都已完成。
- 首次入金金额已书面确认：smoke test 为 25-50 美元。
如果有任何一项未完成，不要上线。过去的生产案例里，每一项都曾让 builder 真金白银地亏损过。
首次入金：25-50 USD
smoke-test 的入金故意设得很小。目标是验证 live 路径是否正常，而不是赚钱。
你在测试什么：bot 的下单是否与 Polymarket 对这笔交易的视图一致。diary 是否正确记录。take-profit 的 GTC 是否真的挂出。bot 是否能从短暂的 API error 中恢复。模拟一次 daily-loss halt 时是否会触发。
预期结果：5-15 笔小额交易，整体大致与 paper diary 一致。任何偏差都应视为 bug，而不是“live 比 paper 更嘈杂”的特性。
如果你因为真实策略亏损把这 25-50 美元亏掉了，说明策略还需要更多 paper 运行。如果是因为 bug 亏掉的，那就先修 bug，再考虑扩容。
来自生产环境的止盈与止损规则
先讲两个定义，因为这一节会反复用到。止盈（take-profit，TP）是一个预设的卖单，当价格涨到你的目标位时自动锁定收益；止损（stop-loss，SL）则是当价格跌破某个限位时把仓位砍掉，让一笔坏交易不至于失控。下面会用到两种 Polymarket 订单类型：GTC（Good-Til-Cancelled，挂在订单簿里等待、直到成交或你主动取消的限价单）和 FOK（Fill-Or-Kill，要么立即全部成交、要么整单取消）。还有一个词 mark 会反复出现，它并不是一种订单类型，而是指你用来衡量仓位的当前 mid（中间价）。下面是我们 trader 的生产默认值，已经在数千笔交易中稳定运行。
- Buy：在 best ask 上方 1c 以 FOK 买入。如果 ask > 0.85，则跳过-这就是「0.99 陷阱」（the 0.99 trap）：一个几乎已成定局、价格在 0.90 以上的市场，上行空间极小，可一旦翻盘就会暴跌，风险收益完全倒挂。
- Take-profit：以 entry + 4-6c 的价格 GTC 卖出，在 buy fill + 5s settlement wait 后立即挂出。
- Stop-loss via mark：监控 mid；如果 mid 跌到 entry - 8c，则以 best bid 做 FOK 卖出（不挂单；mid blow-through 发生得很快）。
- Time exit：如果头寸在 X 小时内仍未平仓，且 PnL 介于 -2c 到 +2c，则按市价 FOK 退出。
这些数值会因策略而变化，但模式是一致的：take-profit 始终使用 GTC，stop-loss 通常使用 FOK（因为 mid 快速穿透时，GTC 止损往往无法成交），并设置 time exit 以避免被陈旧信号拖住。
监控：Telegram、email、dashboard
bot 需要能够被实时观察。分三层。
- Telegram alerts：每次成交、每次 halt、每个超过阈值的 error 都要提醒。使用独立的 channel 或 group；不要和私人消息混在一起。
- Daily summary email：每天结束时发送，包含总交易数、胜率、PnL、触发的 halt 列表。每天早上都要读。
- Dashboard：可选但很有用。一个简单的 HTTP endpoint，读取 diary 并渲染 open positions + 最近成交 + 累计 PnL。
模式是：任何值得知道的状态变化 → Telegram。日终总结 → email。实时查看 → dashboard。
reconcile 频率：每个 fire_exits 周期
reconciliation 必须足够频繁，这样 drift 才能在下一笔交易放大之前被发现。频率取决于交易频率。
- 每天少于 10 笔交易的策略：每小时 reconcile 一次。
- 每天 10-100 笔交易的策略：每 15 分钟 reconcile 一次。
- HFT 策略（每天 100+ 笔交易）：每个 exit-firing 循环都要 reconcile。
reconciliation 的成本是每个持仓 token 一次链上读取。20 个 token 就是 20 次 RPC calls；如果使用 free-tier RPC，这完全在预算内。不要在这里过度优化。
第一周：保持贴近，保持小仓位
live 部署的第一周最危险。你会发现 paper 运行没暴露出来的 live-path bug。纪律如下：
- 保持贴近-在清醒时间内每小时查看一次 Telegram channel。
- 保持小仓位-仓位大小保持最低（5 shares）；即使有 bug，损失也应是几美元，而不是几百美元。
- 前 3-5 天每天结束时手动 reconcile。直接将 diary 与 Polymarket UI 对照。
- 记录每一个意外。即使是很小的困惑，最终也会变成 bug。
第一周结束时：如果没有 bug 且 diary 与现实一致，就可以扩展到正常规模。如果出现了 bug，就先修复，再跑一周 smoke test。
扩展：何时追加入金
追加资金的触发条件，每一档对应不同阈值。
- +50% deposit：30 笔 live trades，胜率与 paper 相差不超过 5 个百分点，没有因 bug 引发的生产 halt。
- +100-200% deposit：100+ 笔 live trades，样本内持续盈利，基础设施至少经历过一次小规模故障测试。
- +500%+ deposit：仅在持续 6 个月以上稳定盈利后。资本增速应比成功更慢-你要先确认 edge 真实存在，而不是一个即将消失的 regime。
过早扩容的最大单一风险：在某个市场 regime 中盈利的策略，到了下一个 regime 就不再盈利。更大的仓位不会修复这个问题，耐心才会。
