用 Codex 做选品调研，联网那一档怎么开才安全
调研慢不是因为不会分析，是因为资料散。把它做成固定流程之后，字段固定、算法固定、报告结构固定，换个类目重跑一遍就行。但联网这一档要单独建目录、临时开、目录里只放调研数据，因为能读本地文件加能往外发请求这两个能力叠加才是真正的风险。数据要分自有、公开、估算三类分别标注，不足 12 个月不下季节性结论，进不进这个类目的最终判断留给人。
先讲结论：调研慢在收集，不在分析
做过选品调研的人都知道，真正花时间的不是分析，是收集。
开十几个标签页，翻竞品，抄价格，看评论，翻关键词工具，最后把这些手动拼成一张表。真正需要判断力的那部分——这个类目值不值得进——可能只占全部时间的两成。
Codex 能接手的正是那八成。但这类活有个前提条件是前面几篇没有的：它必须联网。
而联网这一档，是 Codex 权限模型里最需要小心的一档。所以这篇一半讲调研怎么做，一半讲权限怎么配。
先建一个专用的调研目录
不要在你平时干活的目录里做调研。建一个专门的：
ops/research/
├── .codex/
│ └── config.toml
├── AGENTS.md
├── input/
│ └── targets.csv 要调研的类目或竞品清单
└── reports/
.codex/config.toml：
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[sandbox_workspace_write]
network_access = true
为什么要单独建目录，而不是在原来的目录里临时开网络。
因为工作区就是沙箱边界。开了网络之后，它同时具备两种能力：读工作区里的文件、往外发请求。这两个能力单独看都还好，叠加起来才是需要警惕的组合。
所以正确做法是让这两个能力的作用范围尽量小：开着网络的那个目录里，只放调研数据，不放客户名单、不放财务表格、不放带密钥的配置文件。
如果你更谨慎，也可以不写进配置，每次命令行临时开：
codex -c 'sandbox_workspace_write.network_access=true'
用完关掉终端就没了。两种做法的区别是便利性和暴露时长的取舍，看你调研的频率。
数据分三类，报告里必须标清楚
这是调研 Skill 最容易被跳过、也最影响结论质量的一步。
Codex 本身没有任何平台数据，你能拿到的数据分三类，性质完全不同。
自有数据
你自己后台能导出的：销量、订单、广告数据、退货理由。
最准，因为是平台给你的原始数据，但只覆盖你已经在卖的东西。调研新类目时，它的作用是做参照系——你已知类目的转化率和退货率是多少，用来判断新类目的数字是高是低。
公开数据
竞品的商品页、价格、评论、店铺信息、行业报道。Codex 联网之后可以直接查和抓。
问题是不全面也不稳定——你抓到的是某个时点的快照。所以报告里要写清楚抓取时间。
估算数据
销量估算、类目规模、关键词搜索量、竞品营收。这类要接第三方服务。
**必须提醒的是：这类数据是估算，不是平台官方口径。**不同服务商对同一个商品给出的月销量可能差好几倍。
它适合做横向比较（A 比 B 卖得好），不适合当绝对数字写进商业计划。
选服务商时，先拿你自己在卖的几个 SKU 去验一下——它估的和你后台真实数字差多少，这个偏差就是你后面读所有数据要打的折扣。
把这三类的处理规则写进 AGENTS.md：
## 数据来源标注
报告里每个数字都要标明来源类型：
- 自有数据：`data/` 下我们自己的导出文件，最可信
- 公开数据：联网抓取的商品页、评论、报道，标注抓取日期
- 估算数据：第三方服务给的销量、类目规模、搜索量，一律标注「估算」
不要把三类数据混在一张表里不加区分。
竞品矩阵定哪些字段
矩阵的价值在字段选得对，不在收录得多。建议固定这些：
- ASIN 或商品链接
- 标题里的主关键词
- 售价、是否有折扣、变体数量
- 评分、评论总数、最近三个月新增评论数
- 上架时间
- 配送方式
- 主图风格、是否有视频、详情页内容形式
- 差评里出现最多的两个问题
最后两个是多数人会漏、但最有用的。前面那些数字告诉你市场长什么样，这两个告诉你还有什么位置可以站。
**「最近三个月新增评论数」比「总评论数」有用得多。**总评论数高只说明它卖了很久，新增评论数才反映现在的动销。
价格带和季节性怎么算才不失真
价格带
不要只看均价，均价会被少数高价商品拉偏。要的是分布：把在售商品按价格分段，每段有多少商品、这些商品的评论总量占比多少。
评论量加权之后才看得出真实的成交价格带。有时候一个类目挂了很多 80 美元的商品，但九成的评论集中在 25 到 35 美元这一段——那才是这个类目真正的价格带。
季节性
这条要给硬约束：不足 12 个月的数据，不下季节性结论。
只看三五个月就得出「这个品类在上升」，是调研里最常见的错误。让规则直接写死：数据不足 12 个月时，输出「数据不足，无法判断季节性」，而不是凑一个趋势出来。
报告里最有价值的是空位假设
报告的最后一节应该回答「所以我能做什么」，而不只是描述市场现状。
做法是从竞品差评的高频问题里提炼：如果排名前 20 的商品里有 12 个的差评都在抱怨同一件事，那这件事就是一个还没被解决的需求。
这一节值得单独展开，下一篇专门讲从用户抱怨反推产品机会。
用子代理拆开跑
调研是子代理最合适的场景之一。
20 个竞品，如果在一个会话里挨个分析，那 20 份评论原文全会进入上下文，几万字的噪声把真正的判断挤到角落。
正确做法是每个竞品派一个子代理，各自去读、去归纳，只把结论和几条证据片段带回主线程。主线程手上是 20 条干净的结论，再做跨竞品的共性判断。
权限上还能再收一层：主线程需要写报告文件，用 workspace-write；负责读评论的子代理只需要 read-only。每一层刚好够用。
有一点要注意：并发数别开太大。子代理要抓外部页面，并发太高等于对人家的站点压测。
抓取的边界
这一节不长，但比前面所有技术细节都重要。
Codex 能联网抓页面，但「技术上能抓」和「抓了没风险」是两回事。做法上守住几条：
- 遵守目标站点的规则和访问频率
- 只抓公开可见的内容，不绕登录、不绕验证
- 抓来的数据自用做判断，不二次分发
- 需要大量、持续的数据，走正规的数据服务商，别自己硬抓
调研这件事的价值在判断质量，不在数据量。为了多抓一点数据把账号或 IP 搭进去，不划算。
把这条也写进规则文件，让它每次都遵守，而不是靠你记得提醒。
三个必须人来判断的地方
报告出来之后，有三件事 Codex 给不了答案：
**供应链能不能做。**差评里说的问题，你的供应商改得动吗，成本加多少。
**资金和周期扛不扛得住。**这个类目的动销速度决定压货时间，而压货时间决定你要占用多少现金。
**风险你接不接受。**专利、认证、平台类目限制，这些要人去核。
报告的作用是把这三个问题的前置信息准备好，不是替你回答它们。
所以规则里要写清楚：不下「建议进入」或「建议放弃」的最终判断，只列出支持和反对的证据。
调研做完之后
调研的产出不是结论，是一组待验证的假设。
拿到报告之后通常还要做三件事：
- 找供应商问一下，排名前三的问题改造起来分别要加多少成本
- 把改造后的卖点写成一句话，看它能不能在商品页第一屏说清楚
- 如果改造成本高，先只做低成本那一档，看数据有没有变化
先验证便宜的假设，再投入贵的。这个顺序反过来的话，代价会很大。
下一步
下一篇讲这份报告里最难自动化、也最容易做出差异化的一段：怎么从用户的抱怨里反推出产品机会，以及两个必须承认的样本偏差。
