要点速览Polymarket Gamma 摄取为 Naly 提供了预测市场事件、市场、结果、价格、标签和结算元数据的公开结构化视图。Naly 使用这一层来选择文章候选、锚定错价汇总、支持 KBO 预测报道、保存来源引用，并为后续验证创建持久的市场快照。工程层面的主张很简单：编辑可信度始于可复现的市场输入，而不是生成的文字。
摘要
Polymarket Gamma API 应被视为 Naly 的市场发现和元数据来源，而不是交易接口。官方 Polymarket 文档将 Gamma 与 Data 和 CLOB API 区分开来：Gamma 覆盖事件、市场、标签、系列、体育元数据、搜索、评论和公开资料，而 CLOB 处理订单簿、价格、价差和经过身份验证的交易操作。对 Naly 文章来说，这一边界很有用。多数编辑流程在需要逐笔级别的订单簿细节之前，先需要问题文本、市场身份、结果标签、显示概率、类别标签、截止时间和结算语境。
本文的论点是，Naly 应将 Gamma 摄取到一个版本化的市场快照层。快照不是真相；它是在特定时间观察到的公开市场状态，绑定来源 URL 并保存原始载荷。这让 Naly 能够发布他人隐藏的内容：市场语境、信号的限制，以及生成文章时所使用的确切证据。
它在 Naly 中的位置
Gamma 摄取位于文章生成之前、外部来源发现之后。在 Naly 的发布路径中，它为以下四种下游用途提供证据包中的预测市场侧内容：
- 错价汇总需要当前事件和市场候选，并具备足够元数据，以便将市场隐含概率与有来源支持的推理进行比较。
- KBO 预测文章需要体育市场、球队或事件标签、事件截止时间和结果标签，并且这些内容可以在不手工输入市场语境的情况下渲染。
- 来源引用需要稳定的市场 URL、事件 slug 和市场标识符，以便读者审计文章为何讨论某个特定合约。
- 预测验证需要历史快照，以便后续结算能按 Naly 在发布时间实际看到的概率进行评分。
本地运行时事实主要影响形态，而不是新颖性。TypeScript 5.9 和 tsx 适合用于摄取脚本； drizzle-orm 配合 @neondatabase/serverless 可以持久化规范化记录和原始 JSON；Next.js 16 和 React 19 可以渲染生成的文章页面； ai 和 Claude SDK 包只能在摄取将市场状态显式化之后，再消费准备好的证据包。
技术机制
一个稳健的 Gamma 摄取循环有六个阶段。
发现。当 Naly 需要广泛发现活跃市场时使用 Gamma events；当文章锚定到已知 Polymarket URL 时使用市场或事件 slug。Polymarket 的市场数据指南建议使用 events 来完成活跃市场发现，因为 events 包含关联市场，从而减少 API 调用。对于体育等类别工作，标签和体育元数据应在候选排序前缩小抓取范围。
分页。Gamma 同时支持 offset 风格端点和 keyset 端点。对于大规模或重复抓取，keyset 分页更安全，因为
next_cursor会成为续传 token，而offset在 keyset markets 端点上会被明确拒绝。对于较小的定向文章任务，当查询窗口较窄且输出会立即被快照化时，offset 分页仍然可以接受。规范化。关键规范化规则是，结果标签和结果价格必须按位置映射。Polymarket 的市场数据概览将
outcomes和outcomePrices数组记录为一一对应数组，因此索引纪律很重要。数组错位不是外观问题；它会反转文章对市场的解读。快照化。同时存储规范化列和原始 JSON。规范化列应包括提供方、抓取时间戳、事件 id 或 slug、市场 id 或 slug、问题文本、存在时的 condition id、存在时的 token 标识符、结果标签、结果价格、active 和 closed 标志、结束时间、标签、来源 URL 和载荷哈希。原始 JSON 可保护 Naly 免受 schema 漂移影响，并让验证过程能够回放确切的摄取产物。
候选评分。文章任务应使用编辑标准而非交易执行标准来排序市场：新鲜度、可用时的成交量或流动性、临近结算程度、来源可用性、类别匹配度，以及该市场能否产生清晰的读者可见对比。候选评分绝不应暗示某个市场价格自动是错的；它应标记该市场值得研究。
发布绑定。当生成的文章引用某个市场时，文章应链接到已存储的快照 id、Polymarket 来源 URL，以及作者使用的外部证据集。这就是一个页面声称市场是 62 percent，与一个页面能够证明该数值何时、何地、来自何种载荷之间的区别。
速率限制是机制的一部分。Polymarket 记录了由 Cloudflare 执行的限流，以及针对 /events、 /markets、 /tags和 /public-search的具体 Gamma 限制。Naly 的日常发布不需要接近这些限制，因此正确姿态是保守：有界并发、带 jitter 的重试、用于幂等性的载荷哈希，以及在任务收到限流、空响应或结构异常响应时发出警报。
文献怎么说
近期 arXiv 工作支持快照优先的设计。Jia et al. 将去中心化预测市场数据描述为分散在链下元数据、成交层级交易记录和 oracle 结算事件中，并主张建立一个具备标识符解析、增量更新和一致性机制的统一关系系统。Naly 较小的发布系统面临同类问题：除非市场元数据后续能与价格、文章主张和结算结果连接，否则仅有市场元数据并不够。
Le 的校准研究与文章措辞直接相关。该论文使用大规模 Kalshi 和 Polymarket 数据集，认为校准取决于领域、期限和交易规模效应；把价格当作表面概率的消费者可能会系统性误读它们。对 Naly 来说，这意味着文章应写“市场隐含概率”“观察到的价格”或“公开市场信号”，而不是真相。文章只有在将原始市场观察与 Naly 的模型或有来源支持的推理分离之后，才能讨论可能的错价。
Dubach 关于 Polymarket 微观结构的论文主要讨论订单簿数据，但它为摄取设计提供了有用警示：高频市场证据存在特定来源的错误模式、摄取延迟和重要的连接关系。Gamma 比订单簿数据流粒度更低，但同一原则仍然适用。一个数字的来源必须可见。Gamma 快照、CLOB 中点价和链上交易记录彼此相关，但不能互换。
Madrigal-Cianci、Monsalve Maya 和 Breakey 将预测市场框定为贝叶斯逆问题，其中观察到的概率和成交量历史带有噪声、内生性，并受异质交易者类型影响。这强化了 Naly 的编辑立场。摄取的市场状态是证据，不是裁决。好的工程会让这种不确定性可检查，而不是在生成过程中被抹平。
设计权衡
Gamma 与 CLOB 是第一项权衡。Gamma 为 Naly 提供可发现性、文章语境和元数据。CLOB 提供更精确的定价和订单簿机制。对于日常工程文章和预测市场汇总，Gamma 应作为默认输入，因为它回答的是市场在讨论什么。当文章需要价差、中点价或价格历史精度时，可以加入 CLOB。
事件优先与市场优先摄取是第二项权衡。事件优先更适合广泛扫描，因为一个事件可以包含多个市场和共享元数据。市场优先更适合验证，因为最终评分会附着到某个具体二元结果上。Naly 应同时摄取这两种形态，但在评估单一结果时，应让文章链接指向市场层级的主张。
原始 JSON 与类型化 schema 是第三项权衡。只存原始 JSON 易于存储，但难以安全查询。只存类型化列易于查询，但在提供方字段演化时很脆弱。持久模式是两者兼用：类型化字段用于排序、渲染和连接；原始载荷用于审计、回放和迁移。
实时渲染与冻结渲染是第四项权衡。实时市场组件可能有用，但文章主张必须绑定到发布时间快照。否则，当 Polymarket 移动、关闭或结算某个市场时，旧文章可能会悄悄改变含义。对于 Naly 的信任策略，当页面提出有日期的主张时，冻结证据优于新鲜度。
故障模式
最危险的故障是结果与价格错位。如果 Yes 和 No 标签与价格被分开解析，文章就可能在看似合理的情况下反转信号。
第二种故障是复用过期市场。一个市场在发现时可能是活跃的，但到发布时间已经关闭。每个文章任务都应在绑定快照前立即重新验证 active、closed、archived 和 end-time 字段。
第三种故障是多市场歧义。一个 Polymarket 事件可以包含多个可交易市场。汇总文章可以引用该事件，但验证记录必须引用 Naly 评估的具体市场和结果。
第四种故障是 schema 漂移。公开 API 会改变字段名、默认值和嵌套关系。快照存储应包含载荷哈希、解析器版本、提供方 URL 和验证错误，以便漂移可被观察。
第五种故障是过度声称校准。市场价格是有用的公开信号，但文献警告不要把它当作跨所有领域和期限都干净的概率。Naly 的文案应保留市场隐含概率、Naly 估计和实际结果之间的区别。
第六种故障是引用丢失。如果一篇文章只存储渲染后的 markdown，后续验证就无法证明是哪一个市场页面和载荷支持了该主张。文章与市场的连接应是一等记录，而不是嵌入式文字。
实现说明
一个实用的 Naly 实现可以保持较小的摄取契约：
provider：polymarket-gamma。provider_url：用于发现的确切 Gamma 端点或公开市场 URL。fetched_at：UTC 服务器时间戳。event_key和market_key：稳定的提供方标识符或 slug。question：规范市场问题文本。outcomes：有序标签。outcome_prices：有序十进制字符串，只有在验证后才规范化为数值。status：active、closed、archived 和可发布性标志。raw_payload：完整的提供方响应。payload_hash：用于幂等性和回放的确定性哈希。parser_version：解释该载荷的代码契约。
文章生成器应以结构化证据的形式接收这些内容，而不是松散的提示文本。随后它可以通过现有 AI 栈生成 markdown，用站点流水线进行渲染，并保持引用附着在来源记录上。验证 worker 后续可以将文章的市场快照连接到结算数据，并评分已发布主张是否经得起时间检验。
工程原则是刻意保守的：摄取、规范化、快照化、引用，然后写作。这个顺序比要求模型浏览并总结市场页面更慢，但它创造了 Naly 真正需要用于获客和留存的产物：一篇公开文章，其市场证据可以在结果已知后被回放。