用 Agent 做选品报告：把"凭感觉"变成能迭代的工程

现在做选品报告，很多人已经不自己翻数据了。开一个 Agent，Claude Code、Codex 或者自己搭的都行，给它一个关键词、几个竞品链接，让它自己去搜、去抓、去算，最后交一份报告。几分钟就好，图表齐全，结论明确。

麻烦出在拿到报告之后。

它为什么推荐这个品？用了哪些证据？去掉哪一条，结论就会变？同一个品明天再跑一遍，它会不会给出另一套说法？你答不上来，它自己其实也答不上来。

这跟问一个选品很准的老手差不多。你问他为什么选这个，他多半会说："看得多了，感觉能做。"让他讲方法，他也讲得出来：看搜索量，看评论，看竞品价格带。可是换一个品类、换一个平台，或者这次的目标从冲量变成清库存，他讲的方法就跟着变了。他不是在糊弄你，真正支撑他判断的东西，本来就比他能讲出来的多。

所以，直接让 Agent 出报告，只是把一个人说不清的判断，换成了一个模型说得很漂亮的判断。

这篇文章想讲另一条路：把经验一点点拆开。能算的写成代码，需要理解的交给模型，要拍板的留给人。然后建一个循环，让你能拿出证据证明"这一版比上一版好"。整个过程跟做软件很像，所以我叫它选品工程。

图 1：全文路线图。实线是离线改进的循环，虚线是走向真实经营再回来。

下面用一个虚构的例子贯穿全文：一个亚马逊美国站的卖家，想找一个能小批量试单的家居收纳品。

一、先写清楚：选得好，是对谁而言

同一个品，放到两个商家手里，结论可能完全相反。

比如一款可折叠的布艺衣柜收纳箱。A 商家合作的工厂有现成的模具和面料，打样一周就能出来。B 商家要找新工厂，起订量 2000 件。对 A 来说这是一次低成本的试款，对 B 来说是一笔要压几个月的库存。

图 2：前提不同，同一个品的结论可以相反。

如果不把这些前提记下来，以后拿两个人（或者两个 Agent）的答案做比较，你会把"目标不一样"误当成"水平不一样"。

所以每做一次判断，先写一张任务单。用 Agent 的话，它就是项目里的一个文件，每次运行都让 Agent 先读它：

# task.md

平台和站点：亚马逊美国站
经营目标：三个月内找到一个能小批验证的品，首批不超过 500 件
资金与供应链：首批备货资金上限 ___；不开模；优先现有合作工厂
履约约束：FBA；头程按海运算
排除项：不做带电；不做需要额外认证的品类
信息截止时间（T0）：2026-09-30，只能用这个时间点之前能拿到的信息

不同目标下，"选得好"的标准差别很大。快速试款看的是试错成本，以及失败后能不能及时止损；做复购看的是用户会不会回来；最怕压库存的人，宁可错过一个好品，也不愿意押错一次。任务单就是把这些标准写到纸面上，让人和 Agent 按同一套标准做事。

二、把经验放回具体的题里拆

"你是怎么选品的？"这种问题得到的，通常是一套事后整理过的说法，跟他真实的判断过程差得很远。

更有效的做法是出题。从他过去碰过的品里挑一组，把当时能看到的资料还原出来，只给 T0 之前的信息，让他重新做一遍。他做的时候，你在旁边问：

• 你打开资料，第一眼看的是什么？
• 哪条信息让你改了主意？
• 这条证据要是不存在，你还会选它吗？
• 出现什么情况，你会撤回这个判断？
• 放弃的那几个，分别是在哪一步被筛掉的？

图 3：从一道历史题里，把经验拆成可以写下来的东西。

这套思路有现成的研究可以参考。认知心理学里有一种方法叫应用认知任务分析（ACTA，Militello 和 Hutton，1998），专门用来从专家身上提取经验。它的核心做法就是让专家回到具体任务里，讲他在关键节点注意到了什么、怎么做的判断。让专家凭空写出完整规则很难，可一旦放进具体情境，他能准确指出自己在看什么。

有两类材料尤其要留下来。

第一类是拒绝、犹豫和改判的案例。 如果只收集"选中"的答案，系统永远学不会什么时候该说"这个不做"。而且拒绝的理由往往比选中的理由信息量更大。"利润够，但同类产品退货率太高"，这一句里就藏着一条可以写进规则的边界。

第二类是用户的原话。 先看用户在什么场景下抱怨什么，再提痛点和机会的假设。每条评论都要记清楚：原文、来源、怎么抓到的、样本范围、抓取时间。

这里有两个容易踩的坑。一是低星评论适合用来发现问题，但不能拿来估算比例，因为写差评的本来就是不满意的那批人。二是 Agent 从评论里总结出"用户嫌太小"，这还只是一个假设。有多少人愿意为大一号多付钱，要另外验证。

三、哪些写代码，哪些交给模型，哪些由人来定

拆出来的每一个判断，都可以用三个问题过一遍。

图 4：一个判断该交给谁，按顺序问三个问题。

回到收纳箱的例子：

这里有一条用 Agent 时特别容易忽略的事：毛利这种东西，一定要写成脚本让 Agent 调用，不要让它自己算。 模型心算偶尔会错，错了还很难发现；脚本算错了，改一次就永远对了。

"放不进去"这句话最能说明模型的用处。

图 5：同一句差评，三种原因，三种动作。模型负责区分，人负责决定。

三种情况对应三种完全不同的动作。这种区分写死规则做不到，正好交给模型。但模型只负责把可能性列出来，并指出每种可能性的证据，要不要为此开一次新样，还是人说了算。

换一个场景，抖音卖女装：

• 整理款式和尺码、按明确的口径算不同退货率下的损失，交给代码。
• 视频和评论里哪些需求跟穿着场景有关，哪些只是这几天的内容热度，让模型给出解释，同时去找反例。
• 自己能不能稳定拍出对路的内容，扛不扛得住尺码售后和库存风险，只有商家自己能判断。

两个场景都看评论，可评论在决策里起的作用不一样。

还有一点：不要把每个判断都压成一个分数。毛利能算出精确数字；"这个问题值得做"算不出来。硬写成"需求强度 8 分"，只是把模糊藏进了一个看起来很精确的数字里。

对这类判断，换一个输出格式：结论、支持证据、反对证据、出现什么情况会改判。这样一来，"说不清"也有了固定结构。代码可以检查它有没有引用证据、有没有写改判条件，它就能进入工程。

四、Harness：让 Agent 在你画的框里干活

你现在用的 Agent，本身就跑在一个 harness 里。Harness 是包在模型外面的那层执行系统：给模型看哪些资料、开放哪些工具、最多走几步、什么时候必须停下来、结果怎么记，都是它负责。通用 Agent 自带的 harness 是为"什么都能做"设计的，选品工程要做的，是在它外面再加几层只属于你这个任务的规矩。

Anthropic 在 2024 年的一篇工程文章里分了两种做法：workflow 是按代码写好的固定路径走；agent 是由模型自己决定下一步做什么、用什么工具。选品两种都用得上。计算和校验走固定流程；只有遇到证据缺口时，才让模型在你允许的范围内决定去补什么。

图 6：在通用 Agent 外面，为选品加的几层框。

1. 先把每次判断存下来

一条判断记录大概长这样（字段是示意）：

{
  "task_id": "T-031",
  "platform": "amazon_us",
  "goal": "小批验证，首批≤500件",
  "cutoff": "2026-09-30",
  "candidate": "P1 可折叠衣柜收纳箱",
  "decision": "暂缓",
  "evidence": [
    {"id": "E1", "type": "竞品价格快照", "captured": "2026-09-28", "source": "tool"},
    {"id": "E2", "type": "差评原文37条", "captured": "2026-09-25", "source": "tool"}
  ],
  "reasoning": [
    {"claim": "约三成差评与尺寸有关", "cites": ["E2"], "source": "model"}
  ],
  "unknowns": ["工厂报价是否含包装", "'放不进去'是尺寸问题还是使用问题"],
  "flip_if": "核实头程运费后，单件毛利仍不低于目标线",
  "versions": {"model": "M", "prompt": "p-07", "examples": "x-03", "rules": "r-03", "harness": "h-02"}
}

有几个细节要注意：

• 证据要存快照。 证据更新后旧版本也要留着，不然复盘时你不知道上一次判断到底看到了什么。
• 事实和推断分开标。 工具抓回来的是事实（source: tool），模型推出来的是推断（source: model）。两者混在一起，推断会慢慢被当成数据用。
• 版本号要全。 提示词、示例改一个字也算一个新版本。以后结果变了，才能查到是谁引起的。

2. 接口要把边界写死

最小的接口只要三个：

• 读取证据(编号, 截止时间)
• 请求补证(缺什么, 允许去哪补)
• 提交判断(候选, 决定, 引用的证据, 未知项)

模型每次提交判断，检查脚本先做两项检查：引用的证据编号存不存在；有没有用到截止时间之后的资料。不通过就打回。很多 Agent 工具都支持在特定动作前后自动跑脚本（比如 Claude Code 的 hooks），这类检查可以直接挂上去，不靠模型自觉。

3. 执行循环先写小

图 7：执行循环。注意"未完成"和"等人审批"都是正常的结束方式。

有几条规矩要写进代码里，不能指望模型自己遵守：

• 抓取失败不等于没有需求。
• 字段缺失不能默认为零。
• 预算用完不能硬凑结论。

"暂停""失败""需要人介入"都应该是合法的结束状态。采购、上架、投放这类会花钱的动作，要单独设授权，模型不能自己触发。

OpenAI 在介绍 Codex 开放 harness 的文章里，把线程、执行轮次、事件流和审批请求都做成了外部应用可以控制的接口；文中的示例应用在执行重要的写操作前，必须先拿到人的批准。它讲的是编程 Agent，跟选品效果没关系。我们借的是它的思路：模型走的每一步，都能被限制、被记录，也能被中断和恢复。

五、怎么知道它变好了：先独立做题，再盲评

系统跑起来之后，最难回答的问题是：它到底有没有变好？

题库不用一开始就很大。 Anthropic 在 2026 年初的 Agent 评估文章里建议，先从 20 到 50 道题起步，题目最好来自真实出过错的案例。对选品来说，第二节整理出来的那批历史案例，就是第一批题。

图 8：独立做题，再盲评。做题的和打分的分开。

做题要独立。 人和 Agent 拿到同一份任务单、同一组候选、同样截止到 T0 的证据，各做各的。人不看 Agent 的答案，也不把专家答案喂给 Agent。如果专家记得某道题的后续结果（比如知道这个品后来卖爆了），这道题要单独标出来，不能算干净的新题。

评测时先冻结资料，所有人看到的证据完全一样。如果想专门测"补证能力"，再单独设一组题，给双方相同的数据权限和预算。

评审要盲。 答案收齐后，去掉作者和模型名，打乱顺序，再交给评审，人和 AI 都可以当评审。做题的和打分的要分开，这样才能减少"这个答案像我写的，所以我觉得好"。

评审标准要贴着任务来定：

1. 有没有违反硬约束（比如资金上限、排除品类）？
2. 证据撑不撑得住结论？
3. 有没有漏掉关键风险？
4. 对不知道的东西，有没有老实说不知道？
5. 给出的下一步，能不能真的执行？

要允许平局，允许"无法判断"，也允许两个答案都不合格。逼评审从两个烂答案里挑一个"对的"，得到的结论没有意义。

人和人之间也会有分歧。 先看分歧出在哪：是有人漏看了信息，还是两个人对库存风险的容忍度本来就不一样？如果有经验的人之间都没有稳定的口径，那就先回去把目标和标准讲清楚，合理的分歧可以保留。

AI 当评审要校准。 2023 年的 MT-Bench 研究发现，大模型当评审有几种稳定的偏差，对应的处理办法如下：

最后，用一批人工评过的案例检查 AI 评审和人的一致程度。这些做法能减少偏差，消除不了。换一个模型当评审，要重新校准。

另外，模型每次输出都会有波动，同一道题最好多跑几次。分数之外，一定要抽一些完整的运行记录来读。分数会骗人，运行记录里才看得到它是真的判断对了，还是碰巧对了。

实际操作中，三种评审各管一段：格式、计算、硬约束用代码检查；开放判断用盲评；关键分歧交给人复核。这样比看一个总分更容易发现问题。

六、把错误归因，每次只改一处

盲评结束后，先看具体错在哪，再决定改哪里。

图 9：错误归因，从最底层查起。

对应到收纳箱的例子：

很多人用 Agent 一看到结果不好，第一反应是改提示词或者换更强的模型。可从上面这张表能看出来，大部分问题出在前面几层，换模型解决不了。

每一轮尽量只改一类因素，记下改了什么，再跑同一批回归题。同时换模型、换数据、加 Agent 组件，就算结果变好了，你也说不清是谁的功劳，下次也没法复现。

题库要分三份。

图 10：题库分三份。留出题一旦被拿来调优，就降级成开发题。

一道题只要被你拿来反复调过提示词，它就变成了开发题，不能再算新题。

隔离不能只看文件名。 同一款商品的不同颜色、同一批评论切成的不同片段，不能一部分在示例题里，一部分在留出题里。如果要测的是"对未来的判断"，就按时间切：只给当时能看到的信息，不能把后来的销量和新评论倒灌进去。

图 11：数据泄漏。同源样本分到两边，或者把后来的信息倒灌进去，评测结果都会虚高。

Kapoor 和 Narayanan 2023 年研究了大量机器学习论文里的数据泄漏问题，同源样本混进测试集、时间信息处理不当，是让评估结果虚高的常见原因。选品评测一样会踩这些坑。

先有基线，再加复杂度。 现在 Agent 框架很多，加一个"自动补证"、再加一个"二次复核"都很容易。但先做一个最小 workflow 当基线，之后每加一个组件，都在同一个模型、同一批题、同样的初始资料和预算下对比四件事：

题库小的时候，几分的差距可能只是波动，要回去看具体案例，多跑几次。如果一个组件带来不了稳定的收益，就不要留着它。

七、"训练 AI"和"验证生意"是两件事

平时说"训练 AI"，很多时候指的是改提示词、规则、示例和工具描述，模型本身的参数一点没动。

真正改参数的训练，要等到任务边界和评审口径都稳定了、高质量样本也攒够了，再去评估值不值得做。常见的三种：

• SFT（监督微调）：给示范答案，让模型学做法。
• DPO（直接偏好优化）：给"好答案和差答案"成对的样本，让模型学取舍。
• 强化学习：给奖励信号，让模型在反复尝试中优化行为。

三种都需要各自的数据和验证条件，起步阶段一种都不需要。OpenAI 的模型优化文档也是这个顺序：先建评估，再改提示词，微调是最后的可选项。评审口径还不稳、数据来源也说不清的时候急着训练，很可能把错误固化进模型里。

更重要的是，要把三层结果分开看。

图 12：三层结果。下面两层可以离线验证，最上面一层只能在真实经营里验证。

前两层可以用离线题库验证，第三层不行。Agent 的判断越来越像专家，不代表它能预测销量；离线评测分数高，也推不出生意会更好。

经营验证要单独设计。事先定好观察多久、最多投多少钱、看哪些指标；把价格、流量、素材、供货这些条件记下来。能做对照就做对照，做不到就老老实实写明结论里还有哪些不确定。

只拿上线后的销量回头看，有两个常见的误判。一是看不到没上线的那些候选，被放弃的品里可能有更好的。二是容易把平台流量的变化，算成选品能力的提升。

图 13：只看上线的那几个，等于只看幸存者。

真实的经营反馈回来以后，再去修正前面的假设、规则和题库。系统可以从中学习，但一个品卖得好，不能直接升级成人人适用的秘方。

八、如果明天开始，我会这样做

图 14：起步路线。⑤ 和 ⑥ 之间会循环很多轮。

1. 只挑一个平台、一个经营目标、一个你最常做的决策环节。
2. 整理一小批能还原当时信息的历史案例，选中的、放弃的、犹豫过的都要。20 到 50 个就够起步。
3. 先把一部分案例锁起来当留出题，调优期间不看。
4. 把这个决策环节拆开，分清哪些写代码、哪些给模型、哪些由人定。写好 task.md，把稳定的部分写成最小流程。
5. 让人和 Agent 独立做题，匿名盲评，找出最主要的那一类错误。
6. 每轮只改一处，用开发题和回归题检查有没有变好、有没有改坏别的。
7. 方案定下来以后，用留出题做最终检验。如果看了结果又接着调，这批题就变成开发题，再另留一批新题。
8. 离线验证通过后，再用可控的小投入，验证真实的经营结果。

Agent 让出一份报告变得很便宜，但一份报告值不值得信，跟它出得快不快没关系。

经验暂时讲不全没关系，工程也可以从很小做起。把经验写成代码，最后真正要留下来的是这几样：每次判断的前提，用过的证据，允许采取的动作，还有一轮一轮改进的记录。

以后每改一次，都应该答得上三个问题：改了什么？为什么改？有什么证据说明它变好了？

参考资料

以下资料是方法上的参考，不能拿来证明选品收益。

经典研究

1. Militello & Hutton, Applied Cognitive Task Analysis (ACTA), 1998 https:/​/​doi.​org/​10.​1080/​001401398186108
2. Zheng 等, Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, 2023 https:/​/​arxiv.​org/​abs/​2306.​05685
3. Kapoor & Narayanan, Leakage and the reproducibility crisis in machine-learning-based science, 2023 https:/​/​doi.​org/​10.​1016/​j.​patter.​2023.​100804

工程资料

4. Anthropic, Building effective agents, 2024 年 12 月 https:/​/​www.​anthropic.​com/​engineering/​building-​effective-​agents
5. Anthropic, Demystifying evals for AI agents, 2026 年 1 月 https:/​/​www.​anthropic.​com/​engineering/​demystifying-​evals-​for-​ai-​agents
6. OpenAI, Codex as a platform: build on the open agent harness https:/​/​developers.​openai.​com/​blog/​codex-​as-​a-​platform
7. OpenAI, Model optimization（持续更新的文档） https:/​/​developers.​openai.​com/​api/​docs/​guides/​model-​optimization