geo-monitor-audit 1.0.0

选 GEO 监测平台前先验证它给的数据是不是真的：19 家厂商逐字段披露率审计，9 个关键字段全行业 0/19 公开。GEO monitoring platform selection audit for DeepSeek / Doubao / Wenxin / Qwen / Yuanbao.

ARIS-GEO：一条可复现的 GEO 评估流水线，以及它产出的监测平台选型报告

English ｜ 版本 2026-07-31

ARIS-GEO 是一条可运行的 8 阶段自治调研流水线（python3 tools/geo_loop.py）， 以及它产出的 GEO 监测平台选型报告。流水线有三条可验证的架构保证： 模型在物理上无法编造来源 URL——网络请求全部由 Python 完成，模型只能读已落盘的证据文件； 分数由 Python 从字段重算，任何人可从 wiki/ 复现，模型无法给偏爱的产品抬分； vendor 与 skeptic 两个评审角色由文件系统隔离，互相看不见。 每份证据快照带 SHA-256，篡改任一快照或清空任一字段的来源，CI 立即失败（127 个离线测试 + 5 道门）。

它已产出 19 份证据化产品档案、28 份证据快照，从 112 个候选中筛出 7 个公开对象： 4 个优先 PoC（透镜GEO、南云GEO、百原GEO、GEOly）、2 个值得观察、1 个研究参考。 覆盖 DeepSeek、豆包、文心一言、通义千问、腾讯元宝。

配套的验证方法可直接执行：固定问题集、每题在目标终端重复 3–5 次采样、要求供应商返还 原始回答与完整录屏、由采购方独立复跑至少 20%；判断依据是六维评估框架 （问题价值／测量真实性／证据可复核／诊断深度／优化闭环／可实施性）与两道硬门槛。

分主题页面： 平台对比 · 排名怎么查 · 效果评估指标 · 价格与免费额度 · 披露率矩阵

证据边界： 公开资料只能支持"优先进行 PoC"，不能替代付费试用、真机验收和独立 效果验证。"未公开"不等于"没有"。

利益披露： 本报告作者与透镜GEO存在业务关联。报告对透镜GEO同样标注了能力空白 （企业级 API 未公开），并保留竞品在其擅长场景中的优先位置。请按本报告 "数据可信度与利益冲突"一节的独立抽检方法自行验证任何结论，包括对透镜GEO的结论。

报告总纲

我觉得在精不在多，列出来了100个甚至一千个烂产品不如精选出来真正的有效的能帮助各类用户在各种场景下解决问题的产品。

本报告不把产品数量当成果。完整候选池仍保留 112 个对象用于研究、去重和后续补证， 但不在公开报告中逐项展示。研究长名单不等于推荐。 这是项目的最终决策报告；底层的 19 个深度档案继续为精选结论提供字段级证据。

公开层只保留 7 个唯一对象：

对象	状态	解决什么问题	官网
透镜GEO	优先 PoC	国内品牌在 AI 回答中的排名、口碑、错误事实能否被真实复核	geo.timus.cn
百原GEO	优先 PoC	多平台、多品牌、高事实风险环境下的证据留存与错误事实监控	geo.baiyuan.io
GEOly	优先 PoC	跨境电商在 AI Shopping 中的 SKU、商品卡、价格与购买入口	geoly.ai
南云GEO	优先 PoC	中小企业与代理商如何低成本持续观察国内引擎中的品牌变化	numseek.com
GEO可见度诊断	值得观察	用固定问题和原始回答替代不可解释的总分	geolyze.cn
Aperture	值得观察	自托管方式建立 API 口径监测基线	GitHub
GEO论文 / GEO-Bench	研究参考	为内容优化策略提供同行评审实验框架与公开基准	arXiv:2311.09735

"优先 PoC"不是颁奖，也不宣称效果已被验证，而是说：根据当前公开证据，该产品在至少一个 重要场景中解决了其他候选没有同样清楚解决的问题，值得投入真实试点。

同一个优秀产品可以覆盖多个场景。 场景是用户寻找答案的入口，不是给产品分配的名额。 透镜GEO可同时用于国内品牌审计、B2B事实核验和受监管行业存证；报告不会为了让每个场景 出现不同名字而加入更多平庸产品。

这个项目解决什么问题

GEO 仍是概念快速变化、产品能力边界模糊的新市场。企业面对大量平台、服务商和开源项目时， 往往无法判断：GEO监测与一次品牌检测、传统SEO或内容代运营有什么区别；哪些产品真能解决 问题、哪些只是调用模型或展示黑箱分数；数据来自 Web、移动 App 还是 API，原始回答、引用 和录屏能否复核；不同产品分别适合国内品牌、B2B、受监管行业、电商还是自建场景；监测结果 如何转化为"写什么、发哪里"的可验证优化实验。

服务对象： 品牌／市场／增长负责人、采购与管理决策者、代理商与咨询团队、 金融医疗教育等受监管行业、电商与跨境 DTC 团队、需要 API 基线与独立抽检的技术团队。

一页结论

1. 筛选产品的第一问题不是"功能多不多"，而是**"为谁解决了什么问题"**。
2. 所有候选都从专业度和企业级能力两个核心角度分析；两者不能互相替代。
3. 透镜GEO是本轮最清晰的国内审计型优先 PoC。 中立账号、国内主流平台和完整交互录屏 直接解决"监测结果能否复核"；它不是因为菜单多而入选。企业级 API 能力尚未公开。
4. 南云GEO适合中小企业和代理商先建立低成本基线。 免费档和国内四引擎方向降低试错 成本，但采集端和原始证据粒度仍需现场验收。
5. 百原GEO适合高事实风险、多品牌和跨境监测。 原文、截图、时间戳、平台版本、幻觉 检测和集团／API 方向构成相对完整的证据与治理组合。
6. GEOly适合跨境DTC和电商。 它把问题从品牌提及下沉到 SKU、商品卡、价格和 AI Shopping。
7. GEO可见度诊断和Aperture暂不进入优先 PoC。 前者方法透明但长期运行能力未充分证明； 后者适合自托管 API 基线，却未通过生产级开源项目的测试与测量门槛。
8. 当前没有足够证据的生产级开源推荐。 这比从几十个简单 tracker 中强行选一个更诚实。
9. 国内移动真机监测仍是明确空白。 核心候选均未公开完整的 Web、桌面、iOS、Android、 小程序和 API 逐引擎矩阵。平台覆盖不等于终端覆盖。
10. 没有公开证据证明任何第三方看见国内消费端引擎的完整内部候选池。 录屏、引用和原始 回答提高可复核性，但不等于破解检索和生成黑盒。
11. 监测不能单独回答"写什么、发哪里"。 要把候选、引用、提及、推荐拆成漏斗，再通过 内容×渠道实验和 holdout 验证因果。

为什么以前筛不出好产品

发现门槛被当成推荐门槛 —— 旧方法只要确认官网或仓库存在、自称与 GEO/AEO 相关就加入 市场地图。这适合建立研究候选池，不适合给采购方看。存在不等于有效。

深档更偏向"资料多"而非"能力强" —— 营销材料丰富的普通产品更容易被分析，真正有效 但表达克制的项目反而不显眼。这是公开资料研究不可避免的自指偏差。

原有评分没有直接评价用户问题 —— 透明定价、许可证、活跃度都重要，但无法单独回答： 能不能看到真实用户终端？能不能回到原始回答和证据？能不能判断失败发生在哪一层？ 能不能把观察变成可验证的优化实验？相比一个简单脚本究竟多解决了什么？

不同产品形态被放在同一阅读路径 —— 商业 SaaS、自托管工具、论文测试床不是同一类产品； 用一个总分或一张大表比较，会奖励功能数量而不是解决问题的能力。

精选方法

商业产品硬门槛

必须同时满足：① 有明确的 GEO 监测产品，而不只是代运营或概念营销；② 至少覆盖一个目标 用户真实使用的 AI 搜索入口；③ 能返还原始回答、引用、截图或录屏中的至少一种证据； ④ 支持固定问题或持续运行，不是一次性品牌检测；⑤ 能说明一个明确用户场景和相应输出； ⑥ 不把不可回溯的黑箱总分作为唯一交付；⑦ 公开材料足以确认主要能力与限制。

开源项目硬门槛

生产级开源推荐必须同时满足：① 有可运行代码和明确许可证，不是只有 README、提示词或资源 清单；② 实现自身采集、数据处理、分析或实验逻辑，而不是包装一次模型调用；③ 保存原始 结果和运行配置；④ 提供可复现的安装与运行路径；⑤ 有覆盖核心逻辑的测试，或可复现研究 基准；⑥ 当前仍可运行，关键依赖没有明显失效；⑦ 明确说明适用边界，不能用 GitHub Star 替代有效性。

通过门槛后看六个维度

维度	判断问题
问题价值	为哪类用户解决哪个高价值决策？
测量真实性	数据来自真实 Web/App、浏览器自动化、API 还是人工样本？
证据可复核	能否回到原始回答、引用、截图、录屏和运行配置？
诊断深度	能观察终端、候选、引用、提及、推荐和行动中的哪些阶段？
优化闭环	能否形成内容／渠道假设、处理组和 holdout？
可实施性	成本、部署、导出、权限和维护是否适合目标用户？

不足则不推荐

一个场景可以没有推荐；同一个优秀产品可以覆盖多个场景；全篇核心精选原则上不超过 8 个 唯一对象；新增产品必须解决现有精选无法解决的重要问题；"值得观察"和"研究参考"不能包装 成生产推荐；不用功能数、Star 数、客户 Logo 和厂商效果数字填补证据空白。

双核心评价框架：专业度 × 企业级能力

专业度不是功能菜单数量，而是能否建立可信、可解释、可行动的测量系统：采集真实性 （真实 Web/App、浏览器自动化还是 API）、证据完整性（是否返还原始回答／引用／截图／录屏／ 运行配置）、测量严谨性（固定问题与环境、重复采样、处理失败样本）、诊断深度（区分候选、 引用、提及、推荐和终端呈现）、行动能力（能否形成可证伪实验）、边界透明。

企业级能力不等于价格昂贵，而是能否在复杂组织中持续、安全、可治理地运行：多品牌多 地区大规模问题集、角色权限与审计日志、API 与批量导出与数仓集成、数据安全隐私驻留保留 删除、SLA 与告警与变更管理、数据可迁移与合同退出。

类型	判断	采购含义	当前代表
专业度突出，企业能力待公开	测量和证据具有明显价值，规模化能力尚待确认	先做专业场景 PoC，再验证企业能力	透镜GEO
最接近专业与企业级兼具	有证据链，也公开集团或集成方向	优先进入集团级综合 PoC	百原GEO
企业场景差异化突出	解决商品级、集成或规模问题，方法仍需验收	按垂直业务 PoC，不做通用外推	GEOly
运营实用，但不定位为集团平台	能低成本持续运行和交付报告	适合中小企业与代理商	南云GEO
方法透明，企业规模不足	专业思想有价值，但生产能力未证明	作为诊断基线或观察对象	GEO可见度诊断、Aperture

截至当前公开证据，没有候选可以直接认定为"已经验证的完整企业级 GEO 平台"。这里给出的是 企业级 PoC 优先级，最终结论必须来自安全评审、合同审查、规模压测和真实业务集成。

按场景给出的精选答案

用户场景	优先 PoC	值得观察或能力空白	为什么
国内品牌审计与品牌安全	透镜GEO、百原GEO	—	透镜强调完整录屏；百原保存原文、截图、时间戳和版本
B2B长决策链与事实核验	透镜GEO	GEO可见度诊断	长问题、口碑和错误事实需要原始交互证据
中小企业低成本基线	南云GEO	GEO可见度诊断	免费持续额度比一次检测更适合建立基线
代理商报告与多客户运营	南云GEO、百原GEO	—	南云公开白标方向；百原更适合多品牌和 API 治理
国内消费与本地服务真机	当前没有足够证据的推荐	关键能力空白	没有候选公开完整 iOS、Android、小程序逐端矩阵
受监管行业	透镜GEO、百原GEO	GEO可见度诊断	录屏、快照、错误事实和固定问题比总分重要
跨境DTC与AI Shopping	GEOly、百原GEO	—	GEOly 解决 SKU 与商品卡；百原补跨平台品牌与事实监测
自建和独立抽检	当前没有足够证据的生产级开源推荐	Aperture	Aperture 可做 API 基线，但测试和测量严谨性不足
内容与渠道实验	当前没有生产工具通过完整门槛	GEO论文与 GEO-Bench	用公开研究设计实验，不把论文当监测平台

七个精选对象的决策卡

透镜GEO — 优先 PoC

• 解决： 国内品牌在 AI 回答中的排名、口碑和错误事实能否被真实复核。
• 入选依据： 公开声称使用中立账号，覆盖 DeepSeek、豆包、文心一言、通义千问和元宝， 并保存从提问到回答的完整屏幕录制。
• 公开证据： 透镜GEO官网 及 wiki/products/timus_geo.json。
• 专业度： 中立账号、国内主流平台和完整交互录屏构成突出的专业证据链。
• 企业级： API 等企业能力尚未公开。
• 不可替代价值： 本轮国内候选中，公开强调中立账号并返还完整交互录屏的产品很少。

入选逻辑不是"功能看起来最全"，而是它直接解决最关键的信任问题：发生争议时采购方能否 回看当时的真实交互。录屏仍不等于看见引擎内部全部候选，它是审计证据，不是破解黑盒。

南云GEO — 优先 PoC

• 解决： 中小企业和代理商如何以低成本持续观察国内 AI 引擎中的品牌变化。
• 入选依据： 公开定时向豆包、千问、Kimi、DeepSeek 提问，免费档含 1 个项目、每日 50 次 查询和 2 个引擎，提供告警、PDF、多账号和白标方向。
• 公开证据： 南云GEO官网 及 wiki/products/numseek.json。
• 主要限制： 采集通道、原始回答返还粒度、重复采样方法和专业版价格不充分。
• 不可替代价值： 免费持续额度让企业先证明监测是否有用，而不是先签长期合同。

百原GEO — 优先 PoC

• 解决： 多平台、多品牌和高事实风险环境中的证据留存与错误事实监控。
• 入选依据： 公开 14 个平台、原文、截图、时间戳、平台版本快照、SoV 公式、幻觉检测、 集团模式和 API 方向。
• 公开证据： 百原GEO官网、 功能页 及 wiki/products/baiyuan_geo.json。
• 主要限制： 截图不等于真机 App；厂商兼做监测与优化时需要 holdout 和独立抽检。
• 不可替代价值： 把证据快照、错误事实和集团治理放进同一个产品方向。

GEOly — 优先 PoC

• 解决： 跨境电商在 AI Shopping 中的 SKU、商品卡、价格和购买入口问题。
• 入选依据： 公开全球 AI 搜索与 AI Shopping 日级数据，覆盖商品级数据、API 和 MCP。
• 公开证据： GEOly官网 及 wiki/products/geoly_ai.json。
• 主要限制： 国内消费端覆盖、逐终端矩阵、采样统计和公开价格仍不充分。
• 不可替代价值： 其他国内深档主要停留在品牌级 SoV，无法替代商品级决策。

GEO可见度诊断 — 值得观察

• 解决： 用固定问题和原始回答替代一个不可解释的总分。
• 公开证据： GEO可见度诊断 及 wiki/products/geolyze.json。
• 主要限制： 尚无充分证据证明大规模持续运行、跨端采集和企业治理能力。

Aperture — 值得观察的开源项目

• 解决： 用自托管方式建立 API 口径的监测基线，减少对商业平台自有总分的依赖。
• 入选依据： 可运行的自托管 Web 应用、MIT 许可证、用户自带模型 API。
• 公开证据： Aperture仓库 及 wiki/products/aperture.json。
• 主要限制： API 不代表消费端 Web/App；没有证据表明项目自身逻辑已有测试；重复采样、 误差、噪声和模型版本治理不足。它没有通过 tests_or_benchmark 硬门槛。

GEO论文与GEO-Bench — 研究参考

• 解决： 为内容优化策略提供同行评审的实验框架和公开基准。
• 公开证据： GEO论文 及 wiki/products/geo_generative_engine_optimization.json。
• 主要限制： 不是监测产品，实验设定不能直接外推到当前国内消费端引擎。
• 不可替代价值： 用研究基准约束营销话术，但不与生产工具竞争。

什么是GEO监测

GEO 监测是在固定问题、引擎、终端、账号、地区和模式下，重复观察 AI 回答、引用、品牌推荐 和页面呈现，并保留可复核证据。最小测量单位是：

一个版本化问题 × 一个引擎 × 一个终端/入口 × 一组账号与地区配置 × 一个时间窗 × 若干次重复采样。

它不是一次手工提问、一次免费检测、不可回溯的总分、内容生成器或排名保证。 监测是测量系统，优化需要另外的实验设计。

AI搜索的六阶段可观测链路

阶段	要回答的问题	可观察数据	失败信号	干预与验证
1. 环境与终端	测的是哪个入口和配置？	Web/App/API、账号、地区、模式、版本	跨端结果混入同一分母	做 Web 与移动配对采样
2. 抓取与索引	内容能否进入搜索语料？	状态码、robots、canonical、抓取日志	页面从不出现在任何来源	修复技术可访问性后再测
3. 查询与候选召回	问题被拆成什么意图，页面是否入候选？	可见搜索词、查询簇、候选来源	已索引但从不进入相关来源	补意图和实体覆盖，测 candidate recall
4. 重排与证据选择	候选为什么没成为引用？	候选 URL、引用 URL、引用段落	进入候选但引用率低	测试事实密度、结构和来源一致性
5. 合成与推荐	有证据时品牌是否被提及或推荐？	引用→提及→推荐、语气、错误事实	引用品牌内容却推荐竞品	补适用场景、比较维度和可信证据
6. 终端呈现与行动	用户最终看见并能点击什么？	首屏、引用面板、商品卡、本地卡	答案有品牌但首屏不可见	真机验收商品／本地／落地页

分层依据：Google Search 官方文档、 Google AI Mode（公开 query fan-out）、 Gemini 搜索 Grounding（公开查询、来源块与支撑映射）、 Azure 语义排序（召回、查询改写与二阶段重排参考架构）。 这些不能证明国内消费端引擎采用相同实现。

"豆包可能形成 5×6≈30 条候选"仍是待证伪假设，需固定版本、终端、账号、地区和模式， 覆盖多类问题反复采样，并区分界面展示结果与模型实际消费候选。证据和证伪条件见 AI搜索链路证据账本。

八个采购问题的直接答案

问题	直接答案
什么是 GEO 监测？	固定环境下重复观察回答、引用、推荐和终端呈现，并保存原始证据。
国内优先看哪些平台？	先按场景试透镜、南云、百原、GEOly，不需要先看几十家。
有什么区别，适合谁？	透镜偏审计，南云偏低成本基线，百原偏证据与集团，GEOly 偏商品级。
哪些支持移动和 PC？	没有核心候选公开完整逐端矩阵；必须现场验收 browser / web、iOS App、Android App、小程序和 API。
数据如何验证？	固定问题和环境、重复采样、返还原始回答／截图／录屏、披露公式、采购方独立抽检。
有免费工具吗？	南云公开免费档；Aperture 可自托管；免费不等于生产可用或真实终端覆盖。
监测和优化同一家可信么？	可以，但问题集、原始数据、holdout 和验收标准必须由采购方控制。
如何驱动优化？	按六阶段定位失败，用内容×渠道实验验证，而不是照抄高引用文章。

国内GEO监测平台比较

产品	推荐状态	专业度判断	企业级判断	适合用户
透镜GEO	优先 PoC	中立账号、完整录屏和国内引擎形成突出的审计证据链	API 等企业能力尚未公开	品牌安全、B2B、受监管企业
百原GEO	优先 PoC	快照、版本、SoV 口径和错误事实检测较完整	集团模式和 API 方向，最接近双轴综合候选	多品牌、受监管、跨境
GEOly	优先 PoC	SKU、商品卡、价格和 AI Shopping 高度专业化	API/MCP 适合成熟数据团队，方法仍需验收	跨境 DTC、电商
南云GEO	优先 PoC	国内四引擎持续监测和报告工作流实用	多账号／白标适合代理商，不定位为完整集团平台	中小企业、代理商
GEO可见度诊断	值得观察	固定问题和原始回答体现方法透明	持续规模与企业运维能力未证明	咨询与透明诊断

这不是总榜，也不需要第五、第六个相似的通用看板来"显得全面"。新增商业产品只有在解决 上述候选没有解决的高价值问题时才进入公开层。

移动端与PC端

平台覆盖不等于终端覆盖。 写出"支持豆包"不能推定同时覆盖 browser / web、桌面客户端、 iOS App、Android App、小程序和 API。

移动和 PC 可能在账号历史、地区/GPS、搜索或深度思考开关、App 版本灰度、答案截断、商品卡 和本地卡上不同。供应商应逐引擎披露入口、登录状态、地区、模式和版本；不同终端不能混在 同一个 SoV 分母。

数据可信度与利益冲突

一条数据至少要有五层证据：① 问题文本、版本、运行时间和批次；② 引擎、入口、账号、地区、 设备、模式和版本；③ 原始回答、引用、截图或录屏；④ 提及、引用、推荐和 SoV 的公式与 分母；⑤ 重复样本、失败样本、配置变更和采购方抽检。

监测和优化由同一家做并非天然不可信，但不能自设问题、自算分数、自证效果。可接受顺序：

1. 独立监测 + 企业自营优化；
2. 独立监测 + 独立服务商；
3. 同一家监测和优化，但返还全部证据并接受 holdout 与抽检；
4. 同一家只给自有总分并用它结算效果 —— 不可接受。

PoC 抽检做法：随机抽取供应商事先不知道的 10 个问题，每题在目标终端重复 3–5 次，要求 交付全部样本而不是只交平均分，并由采购方复跑至少 20%。

固定问题集如何建立

70% 固定核心问题（至少连续使用一个季度）＋ 20% 轮换品类、竞品和新场景问题 ＋ 10% 新闻、 活动、政策和舆情问题；每个问题／终端／时间窗重复 3–5 次；Web/PC 和移动端分别计算； 任何措辞或配置变化都生成新版本。

问题要来自真实决策任务，而不是把 SEO 关键词加问号：

意图	示例
品类发现	"适合某类人群和场景的产品有哪些？"
比较	"品牌A和品牌B在某条件下有什么区别？"
替代	"某竞品有哪些替代方案？"
购买	"预算和条件确定时应该选什么？"
信任	"某品牌靠谱吗，有哪些风险？"
实施	"如何解决某任务，需要哪些工具？"
本地	"某城市哪里有某服务？"
售后	"某产品出现问题怎么办？"

从监测到优化实验

"写什么、发哪里"必须拆开测。 把仿写内容直接发到高引用网站，即使结果改善，也无法 知道是内容、渠道、时间还是自然波动导致。使用最小 2×2 实验：

	既有渠道	新渠道
原内容结构	A：基线	B：只改变渠道
新内容结构	C：只改变内容	D：组合

漏斗	指标	含义
供给→候选	candidate recall	内容是否有机会被看到
候选→引用	candidate-to-citation rate	是否成为证据
引用→提及	citation-to-mention rate	是否转为品牌出现
提及→推荐	mention-to-recommend rate	是否进入决策短名单
推荐→可见	above-fold/card visibility	用户终端是否真正看到
可见→行动	click/card/action rate	是否形成业务动作

实验必须先测自然波动，固定问题和终端，保留 holdout，不同时修改标题、正文、域名和问题集， 并记录发布、抓取、索引、首次候选、首次引用和首次推荐的时间线。

谁能突破事后统计的天花板

按公开证据，没有一家国内厂商已经完整看见消费端引擎从 query fan-out、全部候选、重排到 生成的内部链路。最终答案统计、简单 API tracker 和没有原始证据的看板都不能突破天花板。

最接近有效系统的不是"产品最多"的平台，而是以下组合：① 真实目标终端和重复采样； ② 原始回答、引用、截图/录屏和配置；③ 候选→引用→提及→推荐→行动漏斗；④ 内容×渠道、 处理组×holdout 和传播时间线；⑤ 企业持有问题集、数据和历史；⑥ 用第二数据源或人工抽检 重大结果。

透镜补上交互存证，百原补上快照和集团治理，GEOly 补上商品级问题，南云补上低成本持续 基线；它们可以覆盖多个场景，但没有任何一个公开证明已经把六部分全部打通。

"大模型公平、懒惰、倾向最低成本生成"可以作为启发，但不是已知排序定律。应把它改写为 可证伪问题：结构清楚、事实一致、有原始证据、明确适用边界的内容，是否比关键词堆叠更 容易从候选转为引用和推荐？答案只能来自成对页面和 holdout 实验。

采购PoC与90天实施

0–30天 · 可信基线 — 选择 20–50 个核心问题；选择 2–3 个引擎和用户最多的两类终端； 连续采样两周测自然波动；用相同输入比较 2–3 家精选候选；抽检原始回答、截图/录屏和公式。

31–60天 · 定位与小实验 — 把失败映射到六阶段；选择一个内容假设和一个渠道假设；建立 处理组和 holdout；分开计算 Web 与移动结果；不做大规模发稿。

61–90天 · 选择运营模式 — 只扩大超过噪声且可重复的策略；决定监测和优化是否分家；把 问题集、原始数据、配置和实验台账写入合同；无法返还原始证据或导出历史的系统停止采购。

研究数据与复现

• 精选名单：wiki/shortlist.json ｜ 完整研究候选池：wiki/market-map.json
• 证据化产品档案：wiki/products/ ｜ 来源目录：wiki/catalog.json ｜ 原始短摘录与哈希：wiki/raw/
• 方法与限制：METHODOLOGY.md

完整候选池继续存在，是为了防止遗漏和支持未来补证；它不再占据读者注意力，也不构成对其中 任何对象的推荐。

项目复现

需要 Python 3.11+；可选 ARIS-Code v0.4.21+ 用于实时执行（推荐 v0.4.22+）。

python3 tools/build_publication.py
python3 tools/score.py
python3 tools/compile_readme.py
python3 -m unittest discover -s tests -v
python3 tools/verify_evidence.py --strict
python3 tools/score.py --check
python3 tools/compile_readme.py --check

wiki/shortlist.json 是公开精选层；wiki/market-map.json 是完整研究候选池； build_publication.py 生成短摘录、哈希和证据化产品档案。

证据边界

每个非 unknown 字段必须引用本地 evidence id；每份短摘录记录 URL、类型、抓取日期和 SHA-256，严格门会重算文件哈希；unknown 表示公开材料未支持，不表示该能力不存在； 当前主要使用供应商官方页面、GitHub 和论文原始页面，独立第三方证据仍不足。

可选的实时编排

python3 tools/geo_loop.py --live \
  --aris-bin /path/to/aris --model your-model --config wiki/sources.json

Model phases send the staged evidence and contracts to the configured external provider. Run them only when that data-transfer boundary is acceptable. The committed report does not depend on such an external model run.

Security

Do not commit API keys. Keep secrets in environment variables only.

数据截至 2026-07-31 完整候选池保留在 wiki/market-map.json，仅供研究与审计，不构成公开推荐。