产品和公司变化太快
能力、名字、套餐、入口和边界都在变。动态事实必须保留具体页面与抓取日期；一份报告只是有保质期的快照。
AI 时代，我们到底该怎么研究一个产品？
从传统市场与竞品分析出发，补上 AI 产品的数据渠道、分析维度、证据纪律和七个真实案例。
VIVI XIAO
2026.08.05
2026.08.05
AI PRODUCT RESEARCH · METHOD / DATA / CASES / SKILL
过去做咨询或战略分析，我们通常怎么研究？
先把行业、竞争、用户与自身能力放在一张桌面上，再形成进入判断和行动建议。
市场
- 市场如何定义，边界在哪里
- 规模、增速、渗透率与关键变量
- 产业链、价值分配和利润池
- 政策、技术、成本与供给约束
- 周期、结构性机会与风险
常用资料
国家统计局、工信部、海关总署、Wind / CEIC、行业协会、券商与咨询报告
竞品
- 主要玩家、份额、分层与区域
- 定位、目标客户与价值主张
- 产品、功能、定价与版本节奏
- 渠道、获客、销售与合作伙伴
- 商业模式、成本结构与盈利能力
- 组织能力、关键资源与替代关系
常用资料
官网、Pricing、Changelog、年报与招股书、SEC、Capital IQ、Bloomberg、PitchBook
用户
- 核心任务、场景与现有替代方案
- 决策链、预算来源与采购阻力
- 完整工作流与关键触点
- 痛点、首次价值与复用原因
- 满意、流失与切换行为
常用资料
深访、焦点小组、问卷、可用性测试、销售与客服记录、评论区与社区
自身能力
- 能力、资源、品牌、渠道与数据
- 自建、购买或合作的边界
- 团队、流程、成本与时间窗口
- 治理、安全与合规约束
- 为什么是现在，从哪里切入
常用资料
内部经营数据、管理层访谈、财务模型、专家评审、PoC 与组织能力盘点
最后交付什么
市场测算模型 · 产业链地图 · 竞品矩阵 · 用户旅程 · 机会优先级 · 进入策略
零、为什么 AI 产品研究突然变难了？
不是传统框架失效，而是研究对象变化更快、入口更多、成本和风险也更难被一张表解释。
数字很多，但定义更多
Stars、下载、安装、注册、任务、Token 和活跃用户不是一回事。先确认数的是人、事件、实例、工作负载，还是注意力。
证据分散在不同系统
产品能力在文档，增长在商店和流量平台，开发者采用在 GitHub，失败在 Issues，团队方向在招聘，风险在政策页。
必须回到真实任务和用户反馈
一次 Demo 或模型榜单不能代替端到端完成率、失败恢复、权限、人工接管和持续使用。用户反馈必须进入价值判断主链路。
现在最危险的不是找不到数字
而是把一个真的数字放进错误的句子里。研究第一步不再是“打开哪个数据库”，而是先画一张证据地图。
一、传统产品研究没有过时，但要多加五层
市场、竞品、用户和自身能力仍然有用；AI 产品要求继续追问模型、上下文、分发、成本和治理。
| 层次 | 研究问题 | 不能停在哪里 |
|---|---|---|
| 模型 | 基础模型是什么？单模型还是多模型？自研、开源部署还是第三方 API？ | 模型榜单领先，不等于端到端任务更好用。 |
| 上下文与工作流 | 能读取什么信息？只回答问题，还是能计划、调用工具、执行动作并交付结果？ | 真正差异常藏在任务编排、失败恢复和人工接管。 |
| 分发 | 用户从独立入口来，还是借助工作区、云、GitHub、微信等既有平台？ | 母平台导流不能直接写成产品独立增长能力。 |
| 单位经济 | 席位、Credits、Tokens、模型费率、工具调用、重试与人工复核如何共同计费？ | 真正该比较的是完成一个可用结果的总成本。 |
| 治理 | 权限、审批、日志、回滚、数据保留、训练政策与第三方子处理商如何设计？ | Agent 的风险不是只会答错，还可能执行错。 |
一个粗略的价值公式
基础模型 × 上下文与数据 × 工具和执行环境 × 工作流设计 × 交互体验 × 可靠性与治理
二、AI 产品的数据，到底去哪里找？
不期待一个平台回答全部问题。先写问题，再选择最接近原始事实的渠道，并把“不能证明什么”一起记下。
| 要回答的问题 | 优先入口 | 适合观察 | 不能直接推出 |
|---|---|---|---|
| 产品现在是什么 | 官网、Pricing、Docs、Changelog、Status、Privacy、Security、API / MCP | 能力、价格、发布时间、负责人、数据政策 | 满意度、留存、市场份额 |
| 有哪些竞品与新品 | Product Hunt、GitHub、Hugging Face、应用商店、插件市场 | 定位、发布节奏、维护频率、Issue、衍生项目 | 长期成功、生产采用、真实活跃 |
| 规模与增长如何 | Similarweb、Sensor Tower、七麦、点点、Google Trends、OpenRouter | 流量、下载、榜单、搜索兴趣、Token 工作负载 | 全端用户、精确收入、留存与购买意愿 |
| 用户怎么用、哪里失败 | 商店评论、G2、Reddit、Hacker News、Discord、GitHub Issues、视频评论区 | 首次价值、失败、切换、复用、价格抱怨的具体情境 | 总体用户分布与无偏满意度 |
| 增长玩法是什么 | Meta Ad Library、TikTok Creative Center、YouTube、B 站、小红书、抖音、TikHub | 广告主题、任务 Demo、KOL、内容和传播路径 | 真实用户数据库、自然留存与商业效果 |
| 团队与战略意图 | LinkedIn、招聘、Crunchbase、PitchBook、IT 桔子、财报、SEC EDGAR | 团队构成、岗位变化、融资线索、经营与监管事实 | 产品独立团队、未披露交易与实时人数 |
我的使用顺序
先用官方页面确定“现在是什么” → 再用行为数据判断“外部发生了什么” → 再用用户反馈确认“真实任务里发生了什么” → 最后才写增长、竞争与机会判断。
口径参考：Product Hunt Points · GitHub Stars · Hugging Face Download Stats · Similarweb Methodology · Google Trends FAQ · Chrome Web Store Metrics · TikHub About；完整链接见资料附录。
三、我现在会从哪几个维度分析一个 AI 产品？
九个模块不是固定篇幅，而是九个必须被明确回答的问题。第一步永远是定义研究对象。
00先定义研究对象
产品、公司、母公司、模型还是市场？范围没写清，用户、收入、团队和生态数据都会串层。
01团队与产品哲学
创业公司看创始人和约束；大厂产品看公开负责人、产品 mandate 与母公司战略，不硬编“创始人故事”。
02时间线与商业模式
记录改变产品形态的节点，并拆订阅、席位、用量、免费额度、Credits、超额费用与母平台价值。
03增长引擎
产品增长、投放、KOL、内容、销售、平台分发、网络效应、社区和渠道合作分别如何形成闭环。
04用户与用例图谱
按任务聚类：谁在什么情境使用、输入是什么、价值在哪一步发生、最大摩擦和替代方案是什么。
05生态与扩展性
区分 API、SDK、MCP、内置 Skills、插件市场与开源仓库；继续看安装、调用、维护与治理。
06社区与关键传播者
找最早传播者、场景教育者、技术维护者、持续强化者和桥梁人物；证据不足就不凑名单。
07竞争格局
同时看直接竞品、邻近替代和捆绑竞品；比较首次成功率、修订时间、恢复、权限和单位任务成本。
08风险与天花板
把模型依赖、成本、隐私、版权、越权执行、学习门槛、留存和母平台入口变化绑定到真实信号。
四、我实际会怎么跑一轮研究？
90 分钟先跑轻量版；需要完整深研时，再扩展九个模块、竞品测试、成本实验和独立语义审计。
定义 Scope
写清对象、产品形态、地区、套餐、日期和三个最需要回答的问题。
建立官方事实底座
官网、定价、文档、更新、隐私、安全、API 与公司公告；先记事实，不急着下结论。
找行为信号
按产品形态去开发者平台、流量平台、商店、搜索或模型路由平台，至少找两类信号。
找用户声音
专门找失败、切换、复用与成本不可预测的情境，不只看总评分。
处理冲突
拆开下载、活跃、事件、创建量、收入与母公司数据；冲突口径同时保留。
只写五个结论
每条都附研究对象、来源、时间、口径，以及它仍然不能证明什么。
五、AI 时代做产品研究，最需要防什么？
大多数错误不是“数据造假”，而是 Scope、时间窗口、指标语义和推断边界没有被写进结论。
01不要把代理指标写成业务事实
Waitlist 不是活跃，下载不是留存，Token 不是用户数或收入。
02不要把母公司的数据借给产品
母公司资源可以分析，但必须标为母公司层事实。
03不要把一次快照写成增长趋势
不同时间、地区和定义的数据，不能随手连成增长曲线。
04不要只测模型
用真实材料测完整任务：完成率、引用、时间、修订、恢复与成本。
05不要把 Credits 横向硬比
比较 cost per successful outcome，把失败、重试和人工复核算进去。
06不要把“有接口”写成“生态繁荣”
总量还要与活跃、复用、维护者、开放程度和头部集中度一起看。
07不要迷信社交声量
分开原创体验与新闻转述、发布期与常态期、独立发帖与重复转发。
08不要忽略数据、版权与 Agent 安全
检查训练、保留、权限、日志、回滚、预算上限和 Prompt Injection。
09不要让研究失去保质期
价格与商店 7–14 天；团队与社区 30 天；能力与政策 30–90 天。
每个数字先问八件事
谁的数据 · 数的是人还是事件 · 是否去重 · 累计还是窗口 · 窗口多长 · 哪个地区与平台 · 官方如何定义 · 哪天获取
评测与风险参考：NIST ARIA · OWASP Top 10 for LLM Applications 2025；完整链接与新鲜度表见资料附录。
六、七个案例，让我更确定这套方法是必要的
同一套方法重跑七个不同形态的产品。重点不是排名，而是看同一个数字为什么不能横着抄。
| 案例 | 看见的信号 | 最容易写错 | 研究动作 |
|---|---|---|---|
| Notion | Pricing、帮助中心与旧 Release 保留不同 Workers 计费日期 | 把“官网”当成单一、永远一致的来源 | 记录具体页面、适用范围、抓取日期与冲突 |
| Codex | 2026-06-02 披露 500 万+ 周活，约 20% 非开发者 | 写成 8 月实时用户数，或借用 OpenAI 整体经营数据 | 保留历史快照日期，拆产品边界、计费与母公司 |
| WorkBuddy | 官方称 DAU 位居国内效率智能体前列，但无绝对值 | 继续推渗透率、领先幅度或同比增长 | 明确“排名信号”能说明什么、不能说明什么 |
| 豆包 | QuestMobile App MAU 约 3.4 亿、DAU 约 1.4 亿 | 写成全端、注册或模型调用规模 | 先标平台、地区、窗口与第三方估算口径 |
| Gemini Notebook | Google 披露 3000 万+ people、60 万+ organizations | 把 people 写成 MAU，把 organizations 写成付费客户 | 保留官方原词和未披露定义 |
| 飞书 / Lark | 两者独立运营、账号不互通；定价与人数上限不同 | 合并为一个全球用户与套餐口径 | 按区域产品、品牌主体、套件与平台分别研究 |
| OpenClaw | Stars、npm 下载、new claws 同时很大 | 把注意力、包拉取、实例写成 WAU | 分别标记语义，并用个人体验解释任务而非规模 |
这组案例为什么放在一起
它们覆盖独立公司产品、大厂内部产品、消费级助手、企业协作平台、开发者工具与开源 Agent。产品形态不同，研究对象与第一证据也不同。
Notion、Codex、WorkBuddy：三个最容易写错的句子
官网冲突、历史快照和没有绝对值的排名，都要求研究者保留限定词，而不是挑一个最好看的版本。
Notion
当前事实
Pricing 与帮助中心写 Workers 于 2026-10-15 开始消耗 credits；旧 Release 仍残留“8 月 11 日”。
另一个口径坑
每 1,000 credits 约 4,348 次运行，是按典型 0.0023 美元 / 次折算的示例，不是固定容量。
不要只写“来源：官网”；写清是哪一个页面、哪一天、解释哪一种事实。
Codex
当前事实
OpenAI 于 2026-06-02 披露 500 万+ 周活用户、约 20% 非开发者；这是历史快照。
计费事实
Sol / Terra / Luna 每百万输入 token 分别消耗 125 / 50 / 5 credits；典型 Sol 任务约 5–40 credits。
用户、计费、产品边界和母公司经营是四个层级，不能合成一句话。
WorkBuddy
当前事实
腾讯称其 DAU 位居国内效率智能体前列，但没有披露绝对 DAU。
产品变化
截至 2026-08-05 最新 5.3.8；5.3.3 加入企业智能体、腾讯文档、长期记忆与插件推荐。
排名只能证明相对位置；版本、价格、权限和组织路径还要单独追。
豆包、Gemini Notebook、飞书 / Lark：大产品更要先拆 Scope
规模越大，越容易把 App、全端、母平台、区域产品与商业化混成一个数字。
豆包
规模口径
QuestMobile 2026 年 3 月豆包 App MAU 约 3.4 亿，春节后 DAU 约 1.4 亿；都是第三方 App 活跃口径。
产品边界
办公、PPT 与浏览器执行继续增加，但 7 月下线自建 / 官方智能体；开放边界并非只扩张。
大规模是真的，但要先问：哪个端、哪个地区、什么窗口、谁在估算。
Gemini Notebook
采用口径
Google 于 2026 年 7 月披露 3000 万+ people 与 60 万+ organizations，但未给活跃窗口、付费和去重定义。
商业化路径
独立入口继续存在，同时接入 Gemini Apps，并由 Workspace、Google AI plans 与 Cloud 承接。
大厂产品要分开产品采用、生态分发和独立经营。
飞书 / Lark
区域与账号
官方明确两者由不同主体独立运营，账号不能跨客户端直接登录。
定价与商店
飞书免费版上限 100 人；Lark Starter 上限 20 人。Google Play 1M+ 仅是 Lark Android 累计下载下界。
品牌家族、区域产品、套件、商店与用户数不能合并。
OpenClaw：Stars、npm 下载与实例是三种语言
公开市场证据与我的高频使用体验可以互相解释，但不能互相替代。
≈ 385kGitHub Stars
更接近开发者注意力、收藏和认可，不是安装或生产采用。
≈ 3.22mnpm 单周下载
更接近包拉取，可能含自动化、重复安装与 CI，不是独立用户。
4.5m / weeknew claws
Foundation 的实例口径尚未完全定义，不能直接写成 WAU。
29 / 64 / 142渠道 / 提供方 / 插件
生态规模也是供应链、权限、维护和治理负担。
数据核验日：2026-08-05。来源与原始口径见 OpenClaw 完整案例报告。
七个案例的共同结论
统一的是证据纪律，不是统一的指标、模板或分数表。不同产品形态需要不同的“第一证据”。
SaaS 与工作空间
把经营、工作流、平台捆绑与任务成本放在一起看。
大厂内部产品
分开产品采用、母公司资源、生态分发与独立经营。
消费级助手
拆 Web、App、预装、商店、内容分发和第三方估算。
开源 Agent
拆 Stars、Forks、包下载、实例、真实运行与治理边界。
企业协作 AI
把权限、数据边界、管理员控制和组织采用一起看。
任何动态产品
保留页面、日期、窗口、定义、冲突和不能推出的结论。
AI 产品研究不是信息搜得越多越好，而是每个结论都能回答：研究的是谁、数字怎么算、证据在哪里、什么时候还有效。
七、所以我把这套方法做成了一个 Skill
Product Deep Research 不是替你自动得出真相，而是把来源、口径、边界和不知道的部分留在桌面上。
真正缺的不是再收藏十个网站，而是一条不会弄丢来源、不会混淆口径、产品更新后还能重新运行的研究流程。
这次七个案例共运行 63 个模块，登记 285 条原子结论 与 125 个来源；所有案例均通过结构校验和独立语义审计。
AI 帮我扩大搜索和整理能力；价值判断、边界意识与“这件事好像哪里不对”的直觉，仍然由人负责。
STEP 01定义 Scope
对象、产品形态、地区、套餐、日期与核心问题。
STEP 02Sources registry
来源、获取日期、可信等级、适用范围与新鲜度。
STEP 03Claims registry
原子结论、支持来源、事实 / 推断、时间与口径。
STEP 04九个研究模块
团队、商业模式、增长、用例、生态、社区、竞争与风险。
STEP 05Validator
检查模块完整性、来源闭环、动态指标、冲突和 Scope。
STEP 06独立语义审计
核对网页是否支持结论、限定词是否丢失、推断是否冒充事实。
STEP 07编译最终报告
只有两层质量门都通过，才生成可复现哈希与运行摘要。
完整 Skill：github.com/Vivixiao980/vivi-ai-product-research · 七个案例见仓库 case-studies 目录。
AI 时代，我们到底该怎么研究一个产品？
VIVI XIAO · 2026.08.05
市场、竞品、用户、自身能力
模型、工作流、分发、UE、治理
过去先找资料，再做判断；现在还要维护 Scope、指标语义、证据与保质期。
METHOD · DATA · CASES · SKILL
过去做咨询或战略分析，我们通常怎么研究？
四组问题先把商业对象放回现实，再交付市场、竞争与进入判断。
市场
- 边界、规模、增速与渗透率
- 产业链、利润池与价值分配
- 政策、技术、成本与供给约束
- 周期、结构性机会与风险
竞品
- 玩家、份额、分层与区域
- 定位、功能、定价与版本节奏
- 渠道、获客、销售与合作伙伴
- 商业模式、成本与组织能力
用户
- 核心任务、场景与替代方案
- 决策链、预算与采购阻力
- 完整工作流与关键触点
- 首次价值、复用、流失与切换
自身能力
- 资源、品牌、渠道、数据与团队
- 自建、购买或合作的边界
- 组织约束与真正能赢的切口
- 为什么是现在，从哪里进入
常用资料
统计局、工信部、Wind / CEIC、协会与行业报告
官网、Pricing、Changelog、年报、SEC、PitchBook
深访、问卷、可用性测试、销售客服与评论区
内部经营数据、管理层访谈、财务模型、PoC
典型交付市场测算 · 产业链地图 · 竞品矩阵 · 用户旅程 · 机会优先级 · 进入策略
为什么 AI 产品的研究变难了？
传统框架没有失效，但研究对象更快、更散，也更容易被“真数字、错句子”误导。
产品边界一直在变
名字、入口、套餐、模型和能力不断重组。报告只能是带日期的快照。
数字相似，语义不同
Stars、下载、安装、任务、Token、活跃用户与收入不能排成一条增长曲线。
证据分散在不同系统
能力在文档，增长在平台，失败在 Issues，战略意图在招聘、政策与发布记录。
必须回到真实任务
Demo 与榜单不能代替完成率、修订时间、失败恢复、权限、人工接管与持续使用。
最危险的不是找不到数字，而是把一个真的数字放进错误的句子里。
在传统产品研究的基础上，AI 产品研究需多考虑五个维度
这五个维度直接影响产品能不能长期成立，而不只是“模型看起来强不强”。
模型
是否强依赖模型能力？模型升级、切换或下线会不会让产品不可用？
继续看：供应商锁定、迁移路径、评测与回退。
上下文与工作流
积累了哪些数据材料？能读到什么信息？能否计划、调用工具并交付结果？
继续看：失败恢复、人工接管、可复用规则。
分发
分发渠道（distribution channel）来自独立入口，还是工作区、云、GitHub、微信等母平台？
继续看：平台导流与产品独立增长能力要分开。
单位经济（UE）
席位、Credits、Tokens、工具调用、重试与人工复核，怎样合成一次成功结果的成本？
继续看：cost per successful outcome，而非单次模型费。
治理
权限、审批、日志、回滚、数据保留、伦理与第三方处理如何设计？
继续看：Agent 不只会答错，也可能执行错。
找数据之前，先写下要解决的问题
先定义“要证明什么”，才知道去哪找，以及什么证据仍然不够。
产品现在是什么？
能力、套餐、入口、模型、地区、版本与基准日分别是什么？
公司与团队是谁？
独立创业公司、大厂产品线还是开源项目？谁对产品方向负责？
增长发生在哪里？
自然流量、平台分发、应用商店、开发者采用、内容传播还是销售？
用户为什么持续用？
首次价值在哪一步发生？失败、修订、复用和切换的真实情境是什么？
商业模式与 UE 成立吗？
订阅、席位、用量、Credits、超额费用和人工成本如何共同计费？
风险与天花板在哪里？
模型依赖、权限、隐私、版权、越权执行、留存与母平台变化如何影响上限？
同一个问题，要去不同入口找证据
入口、观察与待定信息同时写下；任何单一平台都只能回答一部分。
| 要回答 | 入口 | 适合观察 | 仍然待定 |
|---|---|---|---|
| 产品事实 | 官网、Pricing、Docs、Changelog、Status、Privacy、API / MCP | 能力、价格、发布日期、数据政策 | 满意度、留存、份额 |
| 竞品与新品 | Product Hunt、GitHub、Hugging Face、应用商店、插件市场 | 定位、维护、Issues、衍生项目 | 生产采用、长期成功 |
| 规模与增长 | Similarweb、Sensor Tower、七麦、点点、Google Trends、OpenRouter | 流量、下载、榜单、搜索、工作负载 | 全端用户、留存、收入 |
| 用户声音 | 商店评论、G2、Reddit、HN、Discord、GitHub Issues、视频评论 | 失败、切换、复用、价格抱怨 | 无偏总体满意度 |
| 增长玩法 | Meta Ad Library、TikTok Creative Center、YouTube、B 站、小红书、抖音、TikHub | 投放主题、任务 Demo、KOL 与传播路径 | 自然留存、真实转化 |
| 团队与战略 | LinkedIn、招聘、Crunchbase、PitchBook、财报与 SEC | 岗位变化、融资、经营与监管事实 | 实时组织、未披露交易 |
顺序官方事实底座 → 行为数据 → 用户反馈 → 增长、竞争与机会判断。
分析产品的维度，可以归成四类
九个模块不是九篇作文；它们是四组必须回答的问题，第一步永远是 Scope。
边界与来路
产品、公司、母公司、模型还是市场？地区、端和时间窗是什么？
谁在做、为什么这样设计、真正约束是什么？
生意与增长
关键转折、套餐、席位、用量与母平台价值。
PLG、投放、KOL、销售、分发、社区与网络效应。
使用与生态
真实任务、输入、价值点、摩擦与替代。
API、SDK、MCP、Skills、插件与维护。
教育者、维护者、强化者与桥梁人物。
竞争与上限
直接竞品、邻近替代与捆绑竞品。
模型、成本、隐私、版权、权限、留存与平台变化。
一轮 90 分钟研究，我会这样跑
轻量版先形成可复核结论；完整深研再扩展模块、竞品测试、成本实验与语义审计。
定义 Scope
对象、产品形态、地区、套餐、日期和三个核心问题。
官方事实底座
官网、定价、文档、更新、隐私、安全、API；只记事实，先不解释。
行为信号
按形态去开发者平台、商店、流量、搜索或模型路由平台，至少找两类信号。
用户声音
专门找失败、切换、复用与成本不可预测的情境，不只看总评分。
处理冲突
拆开下载、活跃、事件、创建量、收入与母公司事实；冲突口径并存。
只写五个结论
每条都带研究对象、来源、时间、口径，以及它仍然不能证明什么。
Sources registry 来源、日期、可信等级、适用范围、新鲜度。
Claims registry 原子结论、支持来源、事实 / 推断、时间与口径。
现场拆解 Codex：AI 每一步做什么、得到什么
用证据链演示，而不是让 AI 直接生成一篇“看起来完整”的公司介绍。
| 研究步骤 | AI 做了什么 | 得到的数据 | 能下的结论 |
|---|---|---|---|
| 定义 Scope | 把 Codex、ChatGPT、OpenAI 与 Work 分层；锁定 2026-08-05。 | 当前边界把 Codex 保留为软件开发与技术工作的专门体验。 | 母公司用户、收入与基础设施不能直接借给 Codex。 |
| 官方事实 | 查产品页、Help Center、Rate Card、发布公告并登记抓取日期。 | 6 月 2 日披露 500 万+ 周用户，约 20% 非开发者；Sol / Terra / Luna 输入费率为 125 / 50 / 5 credits。 | 增长和计费都是真的，但用户数是历史快照，不能写成 8 月实时。 |
| 行为与传播 | 查多端入口、GitHub、集成、Meetups；X 贴文不足以稳定量化时不凑声量。 | 桌面、Web / Cloud、IDE、CLI、GitHub、Slack、Linear 等入口形成连续分发。 | 主增长引擎更像平台分发 + PLG，而非已被证明的付费投放。 |
| 用户声音 | 从 Issues 与真实任务找环境复现、权限、验证、成本波动和人工审阅。 | 用户需要的不只是代码生成，而是可验证、可审阅、可恢复的任务结果。 | 价值单元应是成功完成的任务，不是一次回答或一个 Token。 |
| 处理冲突 | 保留 Work / Codex 边界变化、历史快照、模型下线与典型任务 5–40 credits 的限定词。 | 同一产品在两个月内即可换入口、模型和计费语义。 | 结论必须带日期、页面与“仍未知”：收入、留存、付费转化、独立 DAU。 |
结论：Codex 的优势不是一个模型分数，而是 ChatGPT 分发、执行环境、可复用工作流与治理控制面共同形成的产品系统。
打开 Codex 完整 report.md →Notion：官网也会互相冲突
独立 SaaS 的官网不是一个来源，而是一组带版本与适用范围的页面。
Scope 与事实
研究 Notion 产品与 Notion Labs 公司，基准日 2026-08-05。Plus / Business 为 10 / 20 美元每成员每月；Workers 增加 Agent credits 计费轴。
最容易写错
Pricing 与帮助中心写 2026-10-15 开始消耗 credits，旧 Release 仍残留 8 月 11 日。约 4,348 次运行只是按典型单次成本折算，不是固定容量。
研究结论
不要只写“来源：官网”。
记录具体页面、获取日期、适用范围与冲突；把席位与 Agent 使用量放进同一单位经济模型。
WorkBuddy：排名信号不能替代绝对规模
大厂内部产品更要区分产品线事实、母公司原则与没有披露的数据。
Scope 与事实
它不是独立创始人故事，而是腾讯内部产品线。官方称按 DAU 位居国内效率智能体前列，但没有公开绝对 DAU。
最容易写错
- 从“前列”推出渗透率或领先幅度
- 把腾讯整体用户与收入借给 WorkBuddy
- 用版本更新代替活跃与留存
研究结论
排名只能证明相对位置。
增长、付费、留存仍未知；版本、权限、组织采用与 CodeBuddy 共用账号积分要分别验证。
豆包：3.4 亿 MAU 先问是哪个端
消费级大产品的规模往往是真的，但平台、地区、窗口与第三方估算必须跟着数字走。
Scope 与事实
QuestMobile 口径的 2026 年 3 月豆包 App MAU 约 3.4 亿；春节后 App DAU 约 1.4 亿。
最容易写错
- 把 App 活跃写成全端或注册用户
- 把第三方估算写成官方披露
- 把用户规模写成模型调用规模
研究结论
先标平台、地区、窗口和估算者。
68 / 200 / 500 元连续包月说明商业化分层出现，但收入、付费率与跨端去重仍待确认。
Gemini Notebook：people 不是 MAU
大厂产品 adoption、生态分发和公司经营必须分开研究。
Scope 与事实
Google 披露超过 3,000 万 people 使用、60 万+ organizations；没有给活跃窗口、去重、付费定义。
最容易写错
- people 写成 MAU
- organizations 写成付费客户
- 借 Google 整体收入推产品独立经营
研究结论
产品采用不等于公司经营。
最值得追踪的是 Gemini 内分发、Workspace 转化、企业权限与云电脑能力，不是虚构一张融资表。
飞书 / Lark：同一品牌家族也要拆四层 Scope
区域产品、账号体系、套件子产品与母公司信号混在一起，任何增长结论都会失真。
Scope 与事实
官方明确两者由不同主体独立运营，账号不能跨客户端直接登录。飞书免费版上限 100 人；Lark Starter 上限 20 人。
最容易写错
Google Play 100 万+ 只是 Lark Android 累计下载下界，不是 MAU；更不能与飞书中国版用户合并。
研究结论
先定义 subject、region、metric window、commercial status。
品牌家族、区域产品、套件、商店与用户数必须分账。
OpenClaw：Stars、下载与实例是三种语言
公开市场证据与个人高频使用体验可以互相解释，但不能互相替代。
公开信号
- 385,155 GitHub Stars：注意力与收藏
- 3,221,010 次周 npm 下载：包拉取
- 450 万 new claws / week：未定义实例口径
个人经验
我用 7 只“龙虾”做研究、选题、创作、日报和发布。它能解释哪些任务有价值、哪里需要人工接管；不能证明市场规模。
研究结论
注意力、安装、运行与留存分开标。
本地运行不等于天然安全；插件越多，权限、维护、日志、回滚与 Prompt Injection 的治理负担越大。
最后要守住的，是证据纪律
统一的是研究纪律，不是统一的指标、模板或分数表。
代理指标不是业务事实
Waitlist 不是活跃，下载不是留存，Token 不是用户或收入。
母公司数据不能借给产品
资源可以解释，但必须标为 parent scope。
一次快照不是增长趋势
不同时间、地区和定义的数据不能随手连线。
真实任务比模型榜单重要
比较完成率、修订、恢复、权限和成功结果成本。
社交声量不是留存
分开原创体验、新闻转述、发布期与常态期。
研究有保质期
价格与商店 7–14 天；团队与社区 30 天；能力与政策 30–90 天。
每个数字先问：谁的数据、数人还是事件、是否去重、累计还是窗口、地区与平台、官方定义、获取日期。
把方法固化成 Product Deep Research Skill
Skill 不替人自动得出真相；它把来源、口径、边界、冲突和不知道的部分留在桌面上。
STEP 01定义 Scope
对象、产品形态、地区、套餐、基准日与核心问题。
STEP 02Sources registry
来源、获取日期、可信等级、适用范围与新鲜度。
STEP 03Claims registry
原子结论、支持来源、事实 / 推断、时间与口径。
STEP 04九个研究模块
团队、商业、增长、用例、生态、社区、竞争与风险。
STEP 05Validator
检查模块完整性、来源闭环、动态指标、冲突与 Scope。
STEP 06独立语义审计
核对网页是否支持结论、限定词是否丢失、推断是否冒充事实。
STEP 07编译最终报告
质量门通过后，生成报告、复现哈希与运行摘要。
这套 Skill 怎么用？
演示模式适合现场讲；文档模式适合同事纵向阅读、截图与打开完整案例。
最小输入
- 研究对象与明确 Scope
- 基准日、地区、套餐或平台
- 三个最想回答的问题
- 允许使用的渠道与需要排除的口径
示例：研究 Codex，截至 2026-08-05。区分 Codex、ChatGPT 与 OpenAI；重点回答增长引擎、商业模式、用户声音和治理风险。每个动态结论保留页面与日期。
输出与使用说明
- 报告：九个模块 + 摘要 + Sources / Claims registry
- 校验：结构 validator + 独立语义审计
- 复现：run-id、版本、时间、来源与哈希
- 人工职责：价值判断、冲突取舍与最终表述
完整 Skill：github.com/Vivixiao980/vivi-ai-product-research · 按 D 可随时打开纵向文档模式。