第 0 节
这份稿子是给你拍板用的，不是给你验收界面用的
读者是产品负责人。读完这一份，你应该能对第 4 节里的 九个决策 逐条说出「选哪个」。
界面长什么样不在这一份里——那是并行产出的交互稿 （design/mockups/marketagent-prototype/）的事。
两份稿内容同源，但各自自包含，不互相引用文件。
四层声明：这份稿子站在哪一层，缺哪一层
第 1 层 · 事实
✅ 已提供，且过了独立对抗性验证
字段契约表 docs/96 + 4 份独立复核 docs/97-*。凡 96 与 97 冲突，一律以 97 为准（97 推翻/修正了 96 的 20+ 处）。
第 2 层 · 需求
✅ 已提供（PRD docs/98）
但本项目没有原始 PRD ，所以场景出处大面积是「反推」。反推项天然待你确认，不得当成已确认需求往下做。
第 3 层 · 设计
⚠ 本稿在做，但只做「说法」这一半
本稿覆盖：叙事、决策论证、覆盖对照、红线自查。不覆盖屏级形态 ——那半边在交互稿里。
第 4 层 · 验收
⚠ 部分：本稿回填了对照矩阵
第 7 节把 PRD §6 的 41 行逐条回填了「本稿落点 / 交互稿落点」。用户验收不由本稿标注。
天然待确认
7 条「反推项」和 6 条「需求有事实无」是天然待你确认的，本稿一条都没有替你定案。
「反推」的意思是：这条需求的出处只有「从界面/代码倒推」，没有任何人写下来说过要做它。
逐条见第 7 节覆盖表的「状态」列。
⚠ 派单原文写的是「8 条反推项」，而 PRD §6 矩阵里逐行数出来是 7 条 。
这是 PRD 内部统计与表体的一处出入，第 8 节 Q13 已报出。不影响任何结论——41 行本稿一行没漏。
顶上那个「D9 视角」开关是干什么的
第 4 节的 D9 问的是：产品要不要在界面上主动说出自己的能力边界 （「这个数我拿不到」「这块只能参考」）。
它是贯穿性的——选了它，其余八条的答案会自动收敛。所以它不适合用文字描述，得让你看见。
顶栏那个开关切换的就是它。整份稿子里10 处 「按 D9-X · 界面这里该说的话」区块会随之出现或消失：
A 全部 10 处展开 · B 只留标为 critical 的 4 处 · C 全部折成一行灰字。
现在就切一遍 ——你会看到这三条路在信息密度上的真实差别，比读任何一段文字都快。
那 4 处 critical 是：D2 —— 配额耗尽必须并进错误可区分性一起做；
D3 —— VOC 是规则不是 AI；D6 —— 认证类问题的「我不知道」；
第 5 节 —— 配额耗尽的独立形态与文案。判据是同一条：
不说这句，用户会照着现有信息做出一个具体的错误动作。
而「哪些算 critical」正是选 B 之后每一次都要重新争论的东西 ——这也是 PM 不建议 B 的理由。
未经拍板
本稿默认展示 D9-A，那是 PM 的推荐，不是你的决定。
凡受 D1–D9 影响的地方，本稿都做成可切换对比，并在每张决策卡底部写明「当前展示的是哪个选项 · 未经用户确认」。
没有任何一处替你挑了答案。
怎么把意见留在稿子上
右下角的批注入口可以点任意元素 → 写意见 → 贴图 → 一键复制成 Markdown ，
导出的每条自带页签、选择器、元素文字，我们这边能精确定位到你说的是哪一块。
比起「第 3 节那个表不对」，这个能省掉一整轮来回。
本稿的边界：不做什么
不画屏 ——没有一处是界面稿。屏级形态在并行的交互稿里。不替你拍决策 ——九个决策全是可切换对比 + 带理由的推荐，没有一处按某个选项定稿。不画事实层里不存在的字段 ——拿不准的一律进第 8 节待澄清，不用「合理推断」填空。不改产品代码 ——market_agent 全程只读。
第 1 节
这个产品在解决什么
一句话：帮人判断「亚马逊美国站上，这个类目值不值得我做」。
你填一个商品编号、一条类目路径或一个关键词，等大约 19 秒，
拿到一份 9 个模块的市场报告，右侧还能接着追问 AI。
用户是谁，他在什么处境里
他要在几十个候选类目里筛掉大部分 ，只对少数几个深调研。所以他要的不是「一份完美的报告」，
是「快速判断这个类目值不值得继续看」。他做的是要花钱的决策 ——备货、开模、认证、广告预算。所以「数据可不可信」对他比「数据齐不齐全」更重要。
一个标着「不确定」的空白，远好过一个看起来确定但是错的数字。 他不是工程师。 他分不清「上游没这个字段」和「这次网络抖了」，也不该被要求分清——
但他必须知道「我要不要重试一次」 。
⚠ 这三条是从界面与代码反推 的，本项目没有原始需求文档。第 8 节 Q10 请你确认使用节奏（粗筛 vs 深调研）——
它会实质改变 D2 与 D7 的答案。
先把几个词说成人话（后面全篇会用）
词 人话是什么 对用户意味着什么
ASIN 亚马逊给每个商品的 10 位编号，形如 B0 开头 + 8 位 你想「照着某个竞品查市场」时填的就是它 类目路径 nodeIdPath类目树上一路走到这层的编号串，真实数据长这样：1055398:1063306:1063314:8529229011（冒号分隔 ） 「我要看哪个市场」最精确的写法 SellerSprite 本产品唯一 的数据来源，通过 MCP 协议提供 45 个数据查询工具 它给不了的，本产品就给不了；它被限流，你的报告就缺块 版块 section报告里的一个分析模块，固定 9 个（市场容量、品牌格局、价格带、产品体验、VOC、流量格局、上架时间、产品迭代、全球市场） 左栏那 9 行就是它们 版块状态 三档 complete / partial / unavailable 你判断「这块数据能不能信」的第一眼依据。⚠ 同一个状态左右两栏用了两套中文说法（Q9） 口径链路 lineage每个数字附带的「从哪个工具、哪些原始字段、按什么公式、在什么样本上算出来」的说明 页头「来源和口径可追溯」这句承诺的载体 缺失项清单 missingDataLog结构化的「这次缺了什么」列表，每条带优先级 「数据质量与缺失项」面板里那几行 决策可用度 decisionReadiness每个版块一条判断：够用 / 谨慎参考 / 不能用 直接告诉你「这块结论能不能拿去拍板」——目前界面不显示 取数诊断 dataSourceDiagnostics后端记录的「这次哪些工具可用、哪些失败了、为什么」 目前界面一个字都不显示 限流 SellerSprite 说「你这一分钟问得太多了」，原文是中文的「每分钟访问已达上限」 你的报告会静默缺几块，而当前界面几乎无法让你知道是因为这个 哨兵值 上游用一个特殊数字表示「没有」，比如用 -1 表示「没有 Prime 价」 程序不认识它，界面就会把 -1 当真价格显示出来（现状：$-1） 兜底类 分类规则一条都没命中时，评论被塞进的默认桶：其他负面 / 其他正面 / 中性待判定 你看到的 VOC 分类里，71% 落在这三个桶里 VOC Voice of Customer，从评论里提炼「用户在抱怨什么、想要什么」 报告第 5 个版块 主张接地 claim-grounding一道校验：AI 说的每句结论必须能在报告里指到证据，指不到就丢弃 它防编造，但它会把认证/知识产权类问题整条丢掉 （见 D6）
第 2 节
它现在的真实状况：不是「功能不够」，是「说话不算数」
四份独立验证报告一共坐实了 20 多条问题。摊开看，绝大多数不是「少做了一个功能」，
而是「界面说了一句系统兑现不了的话」。 这个区别决定了本轮该修什么——
补功能很贵，把话说准很便宜，而且后者才是这批问题的根。
七句对不上的话（每条都有代码行号级证据）
界面说：「统计窗口：近 12 个月」下拉框标签就叫「时间范围」
↔
系统做的：三次不同选择产生逐字节相同 的数据请求F1 / 97-fake-controls §V2-a
界面说：某版块「完成」SkillRail 左栏状态
↔
系统做的：背后有一次被静默吞掉的限流失败F2 / 97-ratelimit §V1-b（7 个实例）
界面说：「已获取 2/5 字段：price、primePrice」价格校验覆盖度
↔
系统做的：primePrice 的值是 -1（哨兵值），界面显示成 $-1，26/30 行F6 / 97-voc §c-2
界面说：「判断 Query、Listing 和自然/广告流量 集中程度」左栏模块描述
↔
系统做的：广告成本永远是「暂缺」，且上游 45 个工具里没有任何广告类工具 G6 / 97-capability §5.1
界面说：「分析完成度 78%」左栏进度条
↔
系统做的：分母恒为 9，其中 2 个版块结构上不可能算完成 ，100% 永远到不了F7 / 97-capability §1
界面说：「来源和口径可追溯」页头徽章，产品核心卖点
↔
系统做的：中文计算说明躺在数据里不显示，界面显示的是英文公式串；取数时间戳、指纹全部零渲染F10 / 97-voc §b-5、§b-6
你问：「这个类目有认证要求吗」右侧 AI 追问
↔
系统做的：拿当前选中版块 的内容答一段无关文本，外加一条把责任推给「外部 Agent 引用无法回溯」的误导性告警F8 / 97-capability §5.4
归成四类，好记也好排优先级
类型 它长什么样 为什么危险 典型条目
假控件 控件能点、能选，但对系统行为零影响
用户拿着一个他以为选过的口径去做判断。这是最接近「功能性欺骗」的一类
时间范围下拉框（S7）、站点下拉框（S10）
假完成 状态标「完成」，而背后有失败被吞掉
用户根本不知道有缺失 ——比「看到缺失但不知道原因」更坏
版块状态只看指标不看告警（S11）、价格带刻意排除校验指标（S18）
假可用 用一个哨兵值撑出「这个字段有值」的声明
唯一一条界面显示了错误数值 的缺陷，其余都是诚实降级
primePrice 显示 $-1，并据此宣称 2/5 字段可用（S19）
答非所问 系统答不了，但它假装答了
本文所有问题里潜在损失最大的一条 ：用户可能带着毫无依据的认证判断去投产
认证 / 知识产权类追问（S24）
按 D9-A · 界面这里该说的话
每一条「说话不算数」在界面上都对应一句该说而没说的话。举三个：
假控件 → 「本报告的统计口径：2026 年 7 月单月截面。当日 <15 号取上月，否则取当月。」 （这句所需的数据已经在界面上了 ，就摆在假控件旁边）
假完成 → 「本版块 4 个指标已算出，但有 1 次取数因每分钟访问上限失败，重试可能补齐。」
答非所问 → 「认证与知识产权不在本报告的数据范围内，本次没有相关证据可引用。」
按当前 D9 视角，这三句边界说明不会出现在界面上 ——用户继续按现有信息判断。
图 1｜五种完全不同的失败，共用同一句话；而其中两种的正确动作是相反的。
这是当前最大的单点信息损失 ：用户拿到的那句话，恰好是唯一一句无法帮他决定下一步的话。
上游限流 ERROR_VISIT_MAX
账号配额耗尽 secret_no_remaining → ERROR_UNAUTHORIZED
上游超时 withTimeout 30s
平台 60 秒超时 route.ts:7 maxDuration
数据源密钥失效 secret_expired
▼ ▼ ▼ ▼ ▼
用户看到的同一句话
「报告生成失败，请稍后重试。」
MarketInsightDashboard.tsx:130-135 兜底文案；504 的 body 不是本产品的 JSON 错误体
▼ ▼ ▼
稍后重试 限流：等一分钟就好正确
停止重试 配额耗尽：重试永远无效，要补额度与上一条方向相反
联系管理员换密钥 鉴权失败：用户自己解决不了正确
三种颜色。
这张图为什么画了：逐条对 skill §7b 的两个测试
正向测试 （画成图会不会出现文字里没有的箭头或框中框）——会 。
文字只能顺序描述「S12 限流、S29 鉴权、S30 平台超时、S31 配额耗尽」四个分散的场景；
图上出现的是文字里没有的「五进一，再一分三，且其中两支方向相反」 的收束—发散结构。
「相反」这件事，只有把两支画在同一层才看得见。
反向测试 （删掉图，读者要不要反复回看）——要 。
这五种失败在 PRD 里分属 S12 / S29 / S30 / S31 四个场景 + §3.2 一张表，
「哪几种压成了同一句话」和「各自该做什么」不在同一处，一遍读下来拼不出来。
量化线 ：方框 9 个（5 + 1 + 3），远超「少于 3 个就别画」。
一张想画但判定不该画 的图，以及理由
候选：D9 如何收敛其余八条决策。 形状是 D9 一个框扇出到 D1–D8 八个框。
正向测试不通过 ：图上不会出现文字里没有的箭头或框中框——它只是把「D9 会影响其余八条」这一句话装进九个方框，
关系是单层扇出，没有任何交叉、回路或层级。
反向测试也不通过 ：删掉它，读者一遍读下来就懂。所以不画。
改用顶栏那个 D9 开关——它让你直接看见 密度差别，比一张扇出图有用得多。
第 3 节
贯穿主张：诚实优先于完整
系统拿不到的，界面必须明确说拿不到、为什么拿不到、以及用户下一步该做什么。
在补数据源之前，先把「说话算数」补齐 ——这是本轮「把体验做好」里最高性价比、也最不可跳过的一段。
为什么这条主张在这个产品上特别成立：成本已经付过了
「自曝边界」听起来像是要新做一堆东西。在这个产品上不是。
后端为「自曝边界」设计的四套机制已经全部做好并落进每一份报告了，只是前端没接 ：
机制 它回答用户的哪个问题 后端产出情况 前端消费情况
missingDataLog「缺了什么，那我该怎么办」
每条带 7 个字段：缺哪个字段 / 该从哪个源拿 / 为什么缺 / 关联指标…真实报告 21 条每条都带全
面板只取其中 4 项 ，把「该怎么办」那几个字段全丢了
dataSourceDiagnostics「这次为什么缺：是这次没给，还是永远没有」
failedTools 存着结构化三元组 工具名 + 所属版块 + 中文原因 ，原因就是人话「每分钟访问已达上限」grep -rn dataSourceDiagnostics app → 0 命中
lineage「这个数字是怎么算出来的」
带中文人话 计算说明 calculationNotes、取数时间 retrievedAt、请求指纹
中文说明零命中；界面显示的是英文公式串 ；时间与指纹全部零渲染
decisionReadiness「这块结论能不能拿去拍板」
每个版块一条：够用 / 谨慎参考 / 不能用，带 summary 与阻塞项 id
目前无处展示 （红线 10：要用属于新增前端能力，须显式立项）
这一条直接决定 D9 该怎么选
选「自曝边界」不是引入一个新方向，是把已经付过的成本兑现出来。
本产品自己早就选了这条路，只是没走完——四套机制的后端全做好了，前端一套都没接。
这也是为什么第 1.3 条事实很反直觉但很省钱：「让失败原因可见」主要是接线，不是采数。
按 D9-A · 这四套机制接上之后，界面会多出什么
缺失项每条后面多一句「该从哪儿拿」 ——比如「广告成本 · 本产品未接该数据源 · 建议去 Amazon Ads 查」；
报告里多一个取数诊断面板 ：本次可用工具数、失败工具名与中文原因；
点开任何一个数字，看到的是中文计算说明 而不是英文公式串，外加取数时间；
每个版块头部多一枚决策可用度 标记：够用 / 谨慎参考 / 不能用。
按当前 D9 视角，这四套已经做好的后端机制继续不出现在界面上 ——成本照付，用户看不见。
三条最容易照着抄错的地方（照抄 96 会出事）
事实层有两份文档（96 字段契约表、97-* 对抗性验证）。
凡两者冲突一律以 97 为准 ，因为 97 推翻/修正了 96 的 20+ 处。下面三条是最容易踩的：
红线 11 · 本轮新增，也是最直接会复现「14 类虚构字段」的一条
lineage.rawFields[] 不是「上游返回了这些字段」的证据，是 section builder 里写死的字符串常量。price-band.ts:105 是字面量数组，:252/:342 追加的正是价格校验字段的标签——
所以 rawFields 里赫然写着 buyBoxPrice / coupon / variantMinPrice，
而这三个字段在所有真实取样里一个非空值都没有 。
渲染它本身无害（只是显示一串常量），但把它当字段可用性依据，就是上一版「14 类虚构字段」的同一条路 。
96 与 97-voc 都把它列进了「白送能力」清单而漏了这个前提。
判断上游到底给不给某字段，只认三类 A 级证据 ：availableTools（真实工具快照）、
failedTools（真实失败原因）、price_validation_coverage（由真实样本算出的覆盖度）。
红线 8 · 反向修正
sampleSummary.warnings 不是「零渲染」。report-service.ts:66-68
并入 report.warnings，再挂到容量版块，partial 时会被渲染出来。
照抄「零渲染」会设计出重复告警 ——同一句话在页面上出现两次。
红线 9 · 反向修正
TrendMeta 不是「零消费」。reason 已经渲染成洞察卡、
sourceKind 决定告警等级，只有 sourceTool 一个字段未用 。别整体列进白送清单。
红线 1 · 上一版最容易踩的一处
页面上已经有一个进度条 （左栏「分析完成度」+「N/9 完成」+ 百分比），语义是数据完备度 ，报告返回后才有数据。
而生成过程 的进度、步骤、ETA、排队位置、单步耗时一个字段都不存在 。
新画一个生成进度条 → 页面上两个百分比互相打脸；误把既有那个当虚构字段删掉 → 删掉一个真实功能。
两个都错。
第 4 节 · 本稿最重要的部分
九个决策：每个都请你拍一次
每张卡的读法固定四问：这是在选什么 · 选错的代价 · 推荐哪个 · 为什么 。
选项标签可以点，点了就切换到该选项的优缺点、业务影响，以及「选了它，界面会变成什么样」 。
本稿默认停在 PM 推荐的那一项，但那不是你的决定。
建议先拍 D9 （在最下面那张卡，也可以直接用顶栏开关试）。它是贯穿性的——
定了 D9，其余八条的答案会自动收敛一大半。当前顶栏视角：A · 明确自曝边界 （PM 推荐，未经你确认 ）。
D1
那个「时间范围」下拉框怎么办
最接近「功能性欺骗」
选项 A 依赖待澄清
影响场景 S7 · S8
这是在选什么
界面上有个下拉框标签叫「时间范围」（近 30 天 / 近 6 个月 / 近 12 个月），报告里对应那行叫「统计窗口」。
三次不同选择产生逐字节相同的上游请求 ——它从校验之后就再没被任何取数逻辑读过一次。
你要决定：把它接上真的、删掉、还是置灰。
选错的代价
用户拿「近 12 个月的市场规模」去做年度备货判断，而他手上其实是单个最近完整月的截面 。
对选品来说，这是一个会直接改变结论的差别。
无论选哪个，这三处清理都必须做
已落盘的历史报告 ——每一份都带着一个与数据无关的窗口声明；AI 推理上下文 ——report-context.ts:165/:241 把含假窗口的样本规则喂给了 AI。
这不是文案层欺骗，是把假口径喂进了推理层 ，AI 会读到「本报告统计窗口 = 近 12 个月」并据此措辞；sections/voc.ts:91
A 接上真实窗口参数B 删掉控件，改成只读展示真口径C 保留但置灰 + 标注
优点 用户真正拿到他想要的能力。这是唯一在功能上前进的选项。
缺点 前提未知。 当前主取数工具暴露的参数只有返回字段与分页，上游是否支持时间窗参数在本仓库内零证据 。这不是前端接线，是数据源能力调研。
业务影响 上游若支持 → 产品能力实质提升；若不支持 → 这个选项根本不存在 ，会白白拖住其余选项的决策。
选了它，界面会变成什么样
下拉框保留且真的生效；报告里「统计窗口」那行随之变化。但在探针结论回来之前，这一屏画不出来 ——
我们不知道上游接受什么参数，画出来就是虚构。本稿因此不为该选项画任何形态。
优点 立刻消除欺骗。而且真口径已经在界面上了 ——真实月份与「当日 <15 号取上月」的判定原因就摆在假控件旁边，复用成本极低。
缺点 用户会感到「能力被拿走了」——他之前以为有的东西没了。
业务影响 短期体感是功能减少 ，换来的是「这个产品说的话可以信」。对花钱的决策，后者长期价值更高。
选了它，界面会变成什么样
输入区少一个下拉框；报告顶部那行从可选的「统计窗口：近 12 个月」变成只读的
「统计口径：2026 年 7 月单月截面（当日 <15 号取上月，否则取当月）」 ；
趋势类卡片另标「以该月结尾回溯 13 个点」。用户不会失去信息，只是从错的窗口换成对的窗口。
缺点 一个永久置灰的控件是一种新的困惑 ——用户会一直问「什么时候能用」；且它仍占着「统计窗口」这个语义位。
业务影响 把一个明确的欺骗换成一个长期的悬念。置灰控件在真实产品里通常会被永久遗忘。
选了它，界面会变成什么样
下拉框还在，灰的，旁边一行小字「当前仅支持单月截面」。
页面上会同时存在一个不能用的窗口控件和一个真实的窗口声明 ，两者语义打架。
PM 推荐 · B，并把 A 作为探针回来后的独立轮次
① 「数据口径可信」是选品决策的地基，比「能选窗口」更基础——一个错的窗口标注比没有窗口标注更有害 ；
② B 的真口径素材已经在界面上，用户不会真的失去信息；
③ 现在选 A 等于承诺一件还不知道能不能做 的事，而这正是上一版产生虚构字段的同一类错误；
④ B 与 A 不冲突——删掉假控件后，探针确认上游支持时再把真控件加回来，是干净的增量，不需要回滚。
未经用户确认
当前展示：B · 删掉控件，改成只读展示真口径 （PM 推荐）
· 选项 A 依赖第 8 节 Q1–Q4 的共同前置 ：上游能力调研，当前被账号额度耗尽硬阻断 。
D2
限流怎么办：本轮最重要的取舍
3/3 报告全部命中
不依赖实采，可照常推进
影响场景 S12 · S28 · S30 · S31
这是在选什么
限流不是风险，是现状 ：3 份真实报告全部命中「每分钟访问已达上限」。
单份报告要打 59±2 次 上游请求、峰值约 30 并发 ，而限流窗口是分钟级 ——结构上必然触顶 。
你要决定：只把它说清楚 ，还是同时把它变少 ，还是两件一起。
选错的代价
用户的报告完整性目前是随机的 ：同一个关键词跑两次，缺的版块不一样，而两份都标着「完成」。
他不知道该信哪一份，也不知道重试有没有用。
两个必须先说清的事实
① 仓库内没有 上游 QPS 阈值，也没有任何请求计数、失败率、耗时埋点 ——
我们连「哪个方案有效」都没有测量依据 。这本身就是一条需求（Q6）。
② 缓存与重试在项目自己的设计文档里早就写过 （含建议 TTL、任务队列/重试/超时/进度清单）。
所以这不是「新需求要不要做」，是「既有设计什么时候补齐」。
图 2｜一次报告的取数形状：一波并发把当分钟配额吃光，然后才轮到串行尾链。
这解释了一件光看文字看不出的事——为什么偏偏是 review 每次都失败 ，
以及为什么「给它加退避」是已被精确定位的最小修复点 。
① 解析输入 关键词 / ASIN / 类目路径 → 一条类目路径市场定义 + 候选打分
▶
② 主并发波 约 30 个请求同时发出分布类 · 趋势类 · 品牌 · 价格 · 上架时间…
此刻：当前这一分钟的上游配额已经被吃光
限流是 HTTP 200 + payload 里带错误码，任何基于状态码的重试中间件都不会被触发 ；应用层零重试、零退避、零并发闸。
失败被就地吞成 warning，不抛不重试
③ 串行尾链：review ×13 两条串行链，逐个取评论3/3 报告的必败工具
▶
④ 两个版块被打伤 产品体验 + VOC 未满足需求5 个 P0 版块里的两个
最小修复点：只给串行尾链加退避
前面的并发波已经过去，等一等配额就回来了——救回来的正好是上面那两个版块。
D2 选项 B
四种颜色。
图 2 为什么画了：逐条对 skill §7b 的两个测试
正向测试 —— 会 出现文字里没有的东西：图上有一个时间序上的因果 （并发波在前 → 配额耗尽 → 串行尾链在后必败），
而 PRD 的文字是分散的三句陈述（「59±2 次」「峰值 30 并发」「review 是串行尾链」）。
「前面吃光了后面的」这条箭头，文字里根本没有。
反向测试 —— 要反复回看 ：不画的话，读者必须自己把 §3.4 的并发数字、
S12 的失败清单、D2 选项 B 的「最小修复点」三处拼起来，才能理解为什么退避只加在一个地方就够。
方框 6 个 ，过量化线。
A+D 先做：可见性 + 把「重试」变成可点动作B 串行化 + 指数退避C 加缓存A 只做可见性（单选）
优点 素材已经全在手上 ——失败原因带工具名、版块、中文原因，只差接线。再前进一小步：既然限流是本次波动，就把「重试」这个正确动作直接给用户 。
缺点 用户手动重试仍会重打 59 次全量请求，不配合缓存时重试会加剧限流 。
业务影响 信任度上升（诚实了），用户第一次有了「我能做点什么」的选项。筛选效率暂时不变。
选了它，界面会变成什么样
缺失项每条从「这块不能判断」变成
「广告成本 · 本产品未接该数据源 · 建议去 Amazon Ads 查」 与
「上架节奏 · 本次撞上每分钟访问上限 · 重试可能补齐」+ 一个可点的重试按钮」 ——
同一个位置给两句方向完全不同的话 ，因为一类重试无用、一类重试就好。
优点 最小修复点已被精确定位 （见图 2）：给串行尾链加退避即可救回两个 P0 版块 。
业务影响 报告完整性大幅提升。60 秒不是物理墙，是一行常量 （平台默认已是 300 秒），所以「拉长」不必然撞上限。
选了它，界面会变成什么样
界面本身几乎不变，变的是等待时长 ——所以它必须和 D7 一起看：等更久而界面一个字不变，是负分。
优点 唯一能同时改善速度和限流 的选项：同关键词的第二次查询、历史报告复用都不再打上游。
缺点 缓存意味着「数据可能不是最新的」，要在界面上说清；且当前报告存储无「查询 → 报告」索引 ，要新建。
业务影响 用户体感最好（第二次瞬间返回）。对选品场景特别合适 ——用户本来就在几十个类目间来回比较，重复查询是常态。
选了它，界面会变成什么样
报告顶部多一行「本结果取自 8 分钟前的缓存 · 立即重新取数」 。
⚠ 仓库里已有 一个真实的持久磁盘缓存（缓存的是翻译结果），所以稿子里不许写「本产品零缓存」 ，
新缓存层要与它区分。
优点 改动最小，不引入任何取数行为变化，零回归风险。
缺点 用户仍然每次拿到不完整的报告，跨次结果仍然不可比 。相当于把问题从「看不见」改成「看得见但解决不了」。
选了它，界面会变成什么样
和 A+D 一样，但没有那个重试按钮 ——用户看清了一个他解决不了的问题。这在体验上是负分。
PM 推荐 · A+D 先做（同一轮），B 与 C 一起作为第二轮，按 C → B 的顺序
① 「知道为什么缺 + 知道该怎么办」优先于「缺得少一点」 ——前者让用户立刻做出正确动作，后者只是把概率改善一点；
② C 排在 B 前面，因为 C 同时解决「慢」和「限流」 ，而 B 只解决限流且会让「慢」变差；先 C 后 B，B 拉长的等待被缓存命中大量抵消；
③ 不推荐单选 A ；④ 拉长等待不构成拒绝 B 的理由——选品决策的时间尺度是天，不是秒 。
配套必做（不是选项，是前提） ：补请求计数 / 失败率 / 耗时埋点（Q6）。没有它，任何方案的效果都无法验证。
按 D9-A · 这里必须一起做的一条边界
「限流」和「账号配额耗尽」共用同一个用户入口，但正确动作相反 （见图 1）——
一个「稍后重试」，一个「停止重试并补额度」。把它并进 D2 的错误可区分性一起做 ，
修法在错误分类，不在文案层。这条被标为 critical：D9 选 B 时它仍然保留。
按当前 D9 视角，「配额耗尽 vs 限流」的区分不会出现在界面上 ——用户看到的仍是同一句「请稍后重试」。
未经用户确认
当前展示：A+D · 可见性 + 可点重试 （PM 推荐）
· 依赖第 8 节 Q6 （补埋点是否立为前置）与 Q10 （粗筛还是深调研）。
D3
VOC 分类：接 AI，还是明示这是规则
方向变更，不是修 bug
不依赖实采
影响场景 S20
这是在选什么
版块名叫「VOC 未满足需求」，描述是「用评论原文归纳用户痛点」。用户的期待是AI 读完评论帮我总结 。
实际是关键词正则匹配 ——而且这是 README 里明文声明过的架构选择，不是「写好了忘了接」。
你要决定：把它接成 AI ，还是诚实说明它是规则 。
选错的代价
真实数据里 71% 的评论落进兜底类 （21 个分类槽位里 15 个是「其他正面」）。
而这个版块叫「未满足需求」，三份报告里负面分类总共只出现过 1 条 。
换句话说：这个版块目前几乎没有在产出它名字承诺的东西 ，而用户不知道。
兜底率高的根因不是规则少，是三条用户看不见的隐含规则
短文本直接消失 ——少于 5 个词的评论连兜底类都进不去。情绪先于关键词，而情绪纯按星级判定（不看文本） 。所以一条 5 星评论里写 “it leaks”，
因为情绪是正面，「漏水」规则根本不参与匹配 ，最终落进「其他正面」。
这一条最致命——「高星低满意」恰恰是选品最想找的机会点。 中性评论 100% 兜底 ——10 条规则里没有一条是中性的，3 星与无星级评论必然全落进「中性待判定」。
A 接 LLM 分类B 明示这是规则 + 改进规则C 维持现状
优点 兑现用户对「AI 读评论」的原始期待；能处理星级与文本情绪不一致（当前最大的漏判源）。435 行分类器 + 109 行任务队列已经写好了。
缺点 ① 这是架构方向变更 ，README 的声明要改；② 死代码要重新接线并清理孤儿分支；③ 把 LLM 成本与延迟引入报告生成主链路 （当前 AI 只在追问侧）；④ 评论池只有 5–10 条 ——接了 AI 也只是更准地分析 10 条评论。
业务影响 版块从「关键词计数」变成真正的用户声音归纳。但若不同时解决评论池太小，收益有限。
选了它，界面会变成什么样
分类名从固定 13 个桶变成 AI 归纳的自由标签；「分类方式」那行改写成「AI 归纳」。
但样本量下限提示仍然要保留 ——10 条评论上的任何「用户未满足需求」结论都不该做成强断言。
优点 诚实且低成本 ：加一行「分类方式：关键词规则匹配（非 AI 归纳）」，配合已有的中文计算说明就能落地；再把三条隐含规则告诉用户，他就能自己判断该不该信 。
缺点 用户的原始期待仍然没被满足；改进规则能降低兜底率，但天花板仍是关键词 。
业务影响 期待被正确管理，用户不会被误导。但这个版块的竞争力不会提升 。
选了它，界面会变成什么样
版块头部多一块口径说明：「分类方式：关键词规则匹配，非 AI 归纳。情绪按星级判定，不读文本——5 星评论里的抱怨会被归入正面。少于 5 个词的评论不参与分类。本次样本 7 条，结论仅供参考。」
这四句话就是这个选项的全部产物 ，它们让用户去点开证据看原文，而不是直接采信分类结论。
缺点 用户带着「AI 归纳」的预期，拿到 71% 落兜底类的关键词计数，而且不知道自己拿到的是这个 。这是本文期待落差最大的一条。
PM 推荐 · 本轮做 B（含改进规则 + 样本量下限提示），把 A 立成独立的方向变更决策
① 「知道这是规则匹配」能让用户自己校正判断 ——他会去点开证据看原文；现在他连「这是规则」都不知道，无从校正；
② A 是真正的方向变更，不该被夹在一轮体验优化里顺手做掉 ；
③ B 不是 A 的替代，是 A 的前置 ——即使将来接了 AI，「分类方式是什么」这句说明也该保留（届时改成「AI 归纳」）。
提请注意（不是能替你决定的） ：若选 A，请一并考虑「评论池只有 5–10 条」这个更上游的约束。
而扩大评论池会直接加剧 D2 的限流 （review 是调用次数最多的工具）。D2 与 D3 在这里是耦合的。
按 D9-A · 界面这里该说的话（本条标为 critical）
VOC 版块头部那四句口径说明就是这条决策的全部产物 ：
分类方式是规则不是 AI · 情绪按星级判定不读文本 · 短文本不参与分类 · 本次样本量。
标 critical 的理由 ：不说这四句，用户会把「负面分类只有 1 条」读成「这个类目用户没什么痛点」，
而真相是规则没命中 ——这直接导致一个错误的选品判断。
按当前 D9 视角，「这是规则不是 AI」不会告诉用户 ——他会按 AI 归纳的预期读这个版块。
未经用户确认
当前展示：B · 明示这是规则 + 改进规则 （PM 推荐）
· 与 D2 耦合；「扩大评论池」本期不做（第 6 节 8-9）。
D4
进度条口径怎么定（那个到不了 100% 的「分析完成度」）
口径缺陷，不是数据源天花板
不依赖实采
影响场景 S14 · S15
这是在选什么
左栏「分析完成度」进度条结构上永远到不了 100% ：分母恒为 9，而其中两个版块（流量格局、全球市场）
恒不 complete 。理论上限 78%，实测常见 67%。你要决定这个百分比的分母该怎么算 。
选错的代价
「分析完成度」是用户对「这份报告能不能用」的第一眼判断。永远不满的进度条会被读成
「这个工具不行」或「我操作错了」 ——他会反复重跑、换输入，而每次重跑就是 59 次上游请求。
必须先纠正的一个成本预期
这不是「数据源不可逾越的限制」，是口径缺陷 。
没有任何地方硬编码 partial：一个是被一条硬编码「不可用」的广告成本指标污染了判定，
另一个是 5 条指标的状态表达式里根本没写 complete 分支 。
所以不要因为「看起来是天花板」而选择维持现状。
A 分母只算可完成的 7 个B 标成「参考模块」，不计入分子分母C 修状态计算，让两个模块真能 completeD 维持 78% 上限
缺点 用户会问「那另外两个模块算什么」；而这两个模块并非无用 ，从分母里消失等于暗示它们不重要。
业务影响 进度条可信了，但「9 个模块」的叙事被削弱成「7 个真模块 + 2 个附属」。
选了它，界面会变成什么样 进度条文案从「N/9 完成」变成「N/7 完成」，其余不变。那两个模块仍然在左栏列着，但不在计数里，也没解释为什么。
优点 与 A 数学等价，但叙事更诚实 ：明确告诉用户「这两块是参考级，本产品的数据源支撑不到判定级」。而且这句话是真的 ——广告成本上游确实没有，权威报告与海关数据确实无数据源。
缺点 要在界面上引入「参考级 / 判定级」这个新概念，是信息架构改动。
业务影响 用户第一次清楚知道「哪些结论能拍板、哪些只能参考」 ——这恰好是选品用户最需要的分层。顺带解决了那 3 条常驻缺口的归属问题。
选了它，界面会变成什么样
左栏 9 个模块分成两组：「判定级 · 7」 与「参考级 · 2」 ，进度条只算判定级；
参考级那两个模块下方常驻一行「本产品未接该数据源，属固有边界，不随本次取数变化」 。
那 3 条永远亮着的「需关注」从警告位挪到这里 ，警告位就腾出来给真正随次变化的限流失败了。
优点 100% 可达，9 个模块保持平等，表面最好看。
缺点 那条硬编码「不可用」的广告成本指标是真实的能力缺口 ，把它移出状态计算等于用口径掩盖缺口 ——
这正是价格带版块已经犯过一次、而本轮要修的那个错（S18）。
业务影响 实质是制造两个新的「完成的谎言」 ，与本轮「诚实优先」的主张直接冲突。
选了它，界面会变成什么样 进度条能到 100%，9 个模块全标「完成」。而广告成本那一格仍然是空的。
缺点 用户反复重跑追求 100%，且会认为工具不行或自己填错了。
选了它，界面会变成什么样 和现在一模一样：进度条停在 67% 或 78%，没有任何解释。
PM 推荐 · B
① 选品用户真正需要的不是「进度 100%」，而是「哪些结论能拿去拍板」 ——B 直接给了他这个分层，A 只是让数字好看；
② B 的叙事是有事实支撑的真话 ，不是话术；
③ C 必须明确拒绝 ——它会重复价格带那个错误，而那个错误正是本轮要修的。不能一边修一边再犯一次。
④ B 顺带解决「需关注永远亮着」：4 条结构性常驻缺口里有 3 条正好属于这两个参考模块。
按 D9-A · 界面这里该说的话
参考级那两个模块下方常驻一行：
「本产品未接该数据源（广告成本 / 权威报告 / 海关编码），属固有边界，不随本次取数变化。」
这句话把 4 条结构性常驻缺口里的 3 条 从「需关注」警告位挪走，
警告位才腾得出来给真正随次变化的限流失败。不说这句，那个警告就会继续常亮，然后被永久忽略。
按当前 D9 视角，「哪些只能参考」不会标出来 ——9 个模块看起来一样重，进度条继续停在 67%。
未经用户确认
当前展示：B · 参考级 / 判定级分层 （PM 推荐）
· 依赖第 8 节 Q11 （这个分层要不要贯穿整个产品，还是只用在进度条上——那是架构级决定）与 Q7 。
D5
primePrice 显示成 $-1 怎么办
唯一一条「界面显示了错误数值」
影响场景 S18 · S19
这是在选什么
界面在 26/30 行 上显示 $-1 作为 Prime 价格，并据此宣称「已获取 2/5 字段：price、primePrice」 。
上游用 -1 表示「没有 Prime 价」，而显示逻辑只判「没返回」，没判哨兵值。
你要决定：归一化成「暂无」 ，还是标注它的真实语义 。
选错的代价
用户可能真的把 $-1 当数据读（「负价格？打折？」），更可能的是他会认为整个产品的数据质量不可信 ——
一个显示负价格的产品，其他数字他也不会信了。而「2/5 字段可用」这句声明也是假的 ，实际只有 1 个字段真可用。
A 把 -1 归一化成「暂无」B 标注语义（显示「无 Prime 价」）C 维持现状
优点 消除错误显示；顺带修正「2/5 字段可用」这句假声明（会变成 1/5，那是真实值 ）。
缺点 它把两件不同的事压成了一件：「这个商品确实没上 Prime」 和「我们没取到这个字段」 都显示成「暂无」。
业务影响 「价格校验覆盖度」会显示为更低的真实值。这不是退步，是把一直存在的真相显示出来。
选了它，界面会变成什么样 价格校验表里 26 行的 $-1 全部变成「暂无」；覆盖度文案从「已获取 2/5」变成「已获取 1/5」。
优点 保留了「这个商品确实没有 Prime 价」这个信息，比「暂无」更精确 ——「暂无」混淆了「没取到」和「确实没有」。
缺点 要区分「上游返回 -1（确实没有）」与「上游没返回（没取到）」两种情况，实现上比 A 复杂。
业务影响 信息量最高：用户能区分「这个商品没上 Prime」和「这个字段我们拿不到」。但必须同时修正可用性声明 ，否则 -1 仍会撑出一个假的「2/5」。
选了它，界面会变成什么样
那 26 行显示 「无 Prime 价」 （灰字，与真实价格明显不同的排版），
剩余没取到的行显示「暂无」；覆盖度文案变成 「已获取 1/5 字段：price。primePrice 上游明示无此价；
buyBoxPrice／coupon／variantMinPrice 当前取数路径稳定拿不到。」
缺点 用户看到负价格，会对整个产品的数据质量失去信任。
业务影响 PM 的原话：这条我认为不构成一个真实选项。
选了它，界面会变成什么样 和现在一模一样：26 行 $-1。
PM 推荐 · B，并把「可用性声明必须按真实可用字段计算」作为 B 的必要组成部分
① 「这个商品没有 Prime 价」和「我们拿不到 Prime 价」对定价判断是两件完全不同的事——B 保住了这个区分；
② A 与 B 在诚实度上等价，但 B 的信息量更高；
③ 无论选 A 还是 B，「可用性声明由哨兵值撑出来」这半个问题必须一起修 ——
光改显示不改可用性判定，界面还是会说「已获取 primePrice」。这是同一个缺陷的两半，拆开修等于没修。
按 D9-A · 这条修完，界面上会多出一个更难看的真数字
价格带版块的「可用字段覆盖度」会公开显示为一个更低的数字（2/5 → 1/5） 。
如果同时接受了 D4 的「参考级 / 判定级」分层，这个更低的数字正好落进正确的位置 。
这是「诚实优先」在这份稿子里最具体的一次代价，请你在拍板前先看一眼。
按当前 D9 视角，覆盖度下降这件事不会被主动说明 。
未经用户确认
当前展示：B · 标注语义 （PM 推荐）
· 「补齐另外三个价格字段」本期不做（第 6 节 8-4），依赖 Q1 / Q3 ，当前被额度耗尽硬阻断 。
D6
认证 / 知识产权类追问怎么办
潜在损失最大的一条
选项 A 依赖待澄清
影响场景 S24
这是在选什么
「这个类目要不要 FDA/CE 认证」「有没有专利风险」是选品的一票否决项 ，用户一定会问。
而系统当前的行为不是「诚实说缺失」，是答非所问 ：拿当前选中版块的内容答一段无关文本，
外加一条把责任推给「外部 Agent 引用无法回溯」的误导性告警 。你要决定：接上游的商标类工具 ，还是在路由层直接说边界 。
选错的代价
用户可能带着一个毫无依据的认证判断去投产。
这比诚实缺失更难被识别为数据缺口——他可能以为系统答的就是认证问题。
为什么会「答非所问」：完整失败链（五步）
问题路由函数顺序短路 ，含「认证 / 知识产权 / IP」的问题永远命中「选品顾问」技能 ，进不到「数据缺口解释」技能；
而只有「选品顾问」会开启全局最严格的证据校验 ——认证问题被路由进了最严的通道；
该校验要求引用的证据文本命中认证/IP 关键词，而对 5.0 MB 全量真实报告扫「认证|专利|知识产权|合规|certification|patent|license」→ 0 次命中 ；
于是主张被整条丢弃 ，落到「拿当前选中版块内容生成一段确定性回答」+ 那条误导性告警；
而上游确实有 4 个商标类工具 ，全仓零接入 。
A 接 4 个商标类工具B 路由层直接返回能力边界说明C 维持现状
优点 上游确实有这 4 个工具（真实工具快照实证），这是一条真实可行的接入路径 ，能真正回答用户的问题。
缺点 依赖待澄清 Q2 ：这 4 个工具的返回字段在本仓库内完全未知 ——只有工具名，没有结构。在探针结论回来前，任何字段级需求都不能写。
业务影响 若探针确认可用 → 补上一个一票否决级的能力；若不可用 → 这个选项不存在 。现在不能承诺。
选了它，界面会变成什么样
本稿不为该选项画任何形态。
我们只知道 4 个工具名，不知道它们返回什么。凭工具名推断能力，正是上一版产生 14 类虚构字段的同一类错误。
优点 立刻消除「答非所问」这个最危险的行为。修法明确 ：在路由层就识别这类问题并直接返回边界说明，而不是放进证据校验让它被丢掉 。
缺点 用户拿不到答案——但他会知道自己拿不到 ，并去别处查。
业务影响 用户损失一个功能，但避免了一个可能造成真实金钱损失的误导 。「我不知道」是一个用户能处理的答案，「答非所问」不是。
选了它，界面会变成什么样
追问「这个类目要认证吗」，回答区直接给一段边界说明：
「认证与知识产权不在本报告的数据范围内。本产品的数据源未接入商标/认证类数据，本次报告里也没有相关证据可引用。建议去目标类目的亚马逊合规页面或官方认证机构核实。」
并且不再出现那条把责任推给「外部 Agent」的告警。
缺点 用户拿着无依据的认证判断投产。PM 原话：这是我在整份 PRD 里唯一会明确反对的选项。
选了它，界面会变成什么样 和现在一模一样：一段关于价格带或市场容量的文字，加一条误导性告警。
PM 推荐 · 立刻做 B；A 作为探针结论回来后的独立评估项
① 「明确说不知道」的价值远高于「看起来答了」 ——尤其在一票否决项上。
一个知道自己缺认证信息的用户会去查官方渠道；一个以为系统答过的用户不会；
② B 是 A 的前提 ：即使将来接上商标工具，也会有它答不了的认证问题（比如具体品类的 FDA 要求），
那时仍然需要 B 这条边界说明的通路。所以 B 不是过渡工作。
顺带必须处理的一处（最低成本、最高优先级） ：AI 的方法论提示词里在指示 AI 去读一批永不存在的字段
（自然/广告流量占比、Query 集中度、CPC/CPS、广告费）。这比前端文案更危险——它在引导 AI 编造。
它和左栏那句「判断自然/广告流量集中程度」应当一起改。
按 D9-A · 界面这里该说的话（本条标为 critical）
这是整份稿子里最该说、也最难说出口的一句「我不知道」。
标 critical 的理由 ：认证与知识产权是一票否决项 ——
用户可能带着一个毫无依据的认证判断去投产，这是本文所有问题里潜在损失最大的一条 。
即使 D9 选 B（只在会造成错误决策处自曝），这一条也必须留下 。
按当前 D9 视角，系统继续拿别的版块内容答认证问题 ，并附一条把责任推给「外部 Agent」的告警。
未经用户确认
当前展示：B · 路由层直接返回能力边界说明 （PM 推荐）
· 选项 A 依赖第 8 节 Q2 ，当前零观测、被额度耗尽硬阻断 。
D7
等待体验：18.7 秒干等，超时则全部丢弃
不依赖实采
影响场景 S2 · S30
这是在选什么
报告生成是同步请求，用户原地等约 18.7 秒，界面从第一秒到最后一秒一个字都不变 ，没有取消按钮。
超时（60 秒）则已完成的 7 个版块全部丢弃 。你要决定：只改文案 / 放宽时限 / 中途落盘 / 做成异步任务。
选错的代价
用户会刷新页面（按钮已禁用，刷新是他唯一的动作）。刷新即丢弃 ——中途死掉不留任何部分结果。
他会重打一次，于是再打 59 次上游请求，更容易撞限流 。
两个必须先纠正的成本预期
① 60 秒是一行常量，平台默认已是 300 秒 ——这不是需要架构改造才能突破的物理墙；
② 这个时限在本地开发时不生效 ，这解释了为什么它可能一直没被当成问题。
A 维持同步 + 只改文案B 把 60 秒调到 300 秒C+B 中途落盘 / 分段返回（顺带放宽时限）D 异步任务化 + 真进度 + 可取消
选了它，界面会变成什么样
那两行静态文案换成有信息量的等待说明，比如
「正在向 SellerSprite 取 9 个模块的数据，通常 20 秒左右。期间请不要刷新——中途刷新会丢弃已取到的部分。」
⚠ 不得画进度、步骤名、剩余时间、排队位置 ——这些数据一个都不存在（红线 1）。
优点 覆盖一大批当前会超时的情况，成本极低 （一行常量）。
缺点 用户可能要等 5 分钟且期间仍然什么都不知道 ——把「失败得快」换成「卡得久」。单独做可能是负分。
业务影响 成功率上升，等待体验可能更差。必须与 C 或 D 组合。
选了它，界面会变成什么样 界面完全不变，只是那一行「正在生成报告」可能停留 5 分钟。
优点 用户不再「白等」——哪怕只拿到 7 个版块也比 0 个好 ；也与限流的现实吻合（本来就常缺块）。放宽时限与它组合后是纯收益。
缺点 这是新增服务端能力 （当前唯一落盘发生在全部完成之后，无兜底），要按新功能估。
业务影响 用户价值最高的一项：把「全有或全无」改成「有多少给多少」 。对「先粗筛再深看」的选品流程尤其合适。
选了它，界面会变成什么样
超时不再是一句「报告生成失败」，而是一份标着「本次未取全」的部分报告 ：
已完成的 7 个版块正常可读，未完成的 2 个显示「本次生成在第 N 个模块被时限截断，可重试补齐」 。
⚠ 这里复用既有的「数据完备度」进度条 表达完整度，不新画第二个百分比 （红线 1）。
优点 彻底解决；仓库里已有可抄的先例 （一套 5 态任务状态机）。
缺点 最大的改动量；且必须沿用既有词汇，不得新造术语 （红线 2）。
业务影响 体验最好，且为将来「批量跑多个类目」打开了门。
选了它，界面会变成什么样
生成变成一个可离开的任务，回来看结果，可取消。
真进度只能用代码里已有的四个中间态词汇 ：
resolving_input（解析输入）／collecting_sample（取样本）／calculating_metrics（算指标）／saving_report（保存报告）。
⚠ 但这四个词目前全仓零赋值 ——要做必须先让后端产出中间态，所以本期不做 （第 6 节 8-1）。
PM 推荐 · C + B 一起做（C 为主、B 顺带），D 作为独立的下一步
① 「给我已完成的部分」击中的是真实痛点 ——用户等 18.7 秒的目的是拿数据，而当前设计让他有可能等满 60 秒拿到零数据；
② B 单独做是负分，与 C 组合后是纯收益；
③ D 是正确的终局，但它是架构级改动，不该被压进一轮体验优化里 ——而且它的价值有一大半（不白等）已经被 C 拿到了；
④ 取消按钮的价值低于「中途落盘」 ：用户想取消，通常是因为「我等太久了什么都没有」。有了 C 之后这个诉求会大幅下降，所以取消可以放到 D 里一起做。
按 D9-A · 界面这里该说的话
部分报告顶部要有一句
「本次生成在时限内只取到 7 / 9 个模块，其余可重试补齐。」
以及等待期间那句「期间请不要刷新——中途刷新会丢弃已取到的部分。」
后一句尤其便宜：用户现在唯一能做的动作恰好是最坏的那个 ，而没人告诉他。
按当前 D9 视角，等待期间与超时之后都不额外说明 ——用户继续按「报告生成失败，请稍后重试」处理。
未经用户确认
当前展示：C+B · 中途落盘 + 放宽时限 （PM 推荐）
· 依赖第 8 节 Q10 （粗筛 vs 深调研会实质改变这条的答案）。
D8
「白送能力」包做多少
零外部依赖
不依赖实采
影响场景 S8 · S9 · S12 · S13 · S17 · S25 · S27
这是在选什么
后端已产出、前端零渲染的能力共 7 项确认 + 8 组补充 。这批需求的特点是：
数据已经在报告里了，不依赖任何上游改动、不增加任何请求。
它们是本轮「把体验做好」里唯一完全没有外部依赖 的一块。你要决定做多少、分几轮。
选错的代价
做少了，「可追溯」这个核心卖点继续停在一句承诺上；一次全做，
信息架构最难的那三项会被赶工做粗 （比如 191 条类目候选怎么展示而不淹没用户，是一个真实的设计问题）。
两条必须避开的坑 + 两条有前置条件的
坑 1 ：sampleSummary.warnings 不是零渲染 ，照抄会做出重复告警（红线 8）。坑 2 ：TrendMeta 只有一个字段未用 ，别整体列进来（红线 9）。前置 1 ：同比/环比结构化值确实零消费，但当前趋势数据不足导致它恒为空 ——先验证再画，否则又是一个永远显示不出来的组件。前置 2 ：评论有用票数是后端需求不是 UI 需求 （解析后在序列化前就蒸发了），别混进 UI 包。
A 一次全做（除两条有前置的）B 分三档，但 P0 与 P1 合并为同一轮C 只做 P0
优点 一轮之内把「可追溯」这个卖点真正兑现；边际成本低（同一批面板改动）。
缺点 单轮改动面大，设计层要同时处理 6 个面板；P2 那三项需要更谨慎的信息架构设计，赶在同一轮里容易做粗 。
选了它，界面会变成什么样 下面 P0 + P1 + P2 三档一次性全部落地。
优点 每档都能独立交付并验证。P0 三项直接回答用户「我该怎么办 / 这是哪一份 / 这是什么时候的」。
选了它，界面会变成什么样
P0 + P1 合并做（本轮）：
缺失项每条从 4 项信息补到 7 项：缺哪个字段 / 该从哪个源拿 / 为什么缺 ；
历史列表 6 条不再长得一样——补上创建时间 （那里已经有一个时钟图标，旁边恰恰没有时间 ）与各版块状态 ；
指标卡补上统计窗口 （否则 $7,713,411 是哪 30 天的没人知道）；
新增取数诊断面板 ：本次可用工具数、失败工具及中文原因；
口径详情里的英文公式串换成中文计算说明 （数据里本来就有中文）；
AI 引用从 metric: market_revenue 这样的机器 id 换成人话标签 （人话就在同一个对象上）。
P2 放下一轮 ：决策可用度全文、类目判定的 191 条候选与打分、取数时间与请求指纹。
它们是追责级 信息——价值真实但触发频率低，用户只在怀疑时才看。
缺点 P1 里的取数诊断面板正是 D2 推荐方案的载体 ——不做它，D2 的可见性需求就没有落点。
选了它，界面会变成什么样 只有上面 P0 那三项；用户知道「缺什么」，但仍然不知道「为什么缺」。
PM 推荐 · B，但 P0 与 P1 合并为同一轮
① P1 的取数诊断面板是 D2 推荐方案的实现载体，它和 P0 是同一件事的两半
（P0 说「缺什么、该怎么办」，P1 说「为什么缺」），拆开会让用户看到半个答案；
② P2 三项是追责级信息，放到下一轮不损失日常体验；
③ 不推荐一次全做，不是因为成本，而是因为 P2 需要更谨慎的信息架构设计。
按 D9-A · 界面这里该说的话
白送包里每一项都是一句自曝边界的话 ——
这正是 D8 与 D9 的关系：D9 决定说不说，D8 决定这一轮说多少。
所以 D9 若选 C，D8 的 P0+P1 有一多半会失去意义（面板还在，但没什么可写）。
这是九条决策里耦合最紧的一对，建议一起拍。
按当前 D9 视角，白送包大部分内容没有落点 ——数据继续躺在报告里不显示。
未经用户确认
当前展示：B · P0+P1 合并本轮，P2 下一轮 （PM 推荐）
· 与 D2 强耦合（取数诊断面板是 D2 的载体）。
D9
贯穿性取舍：产品要不要在界面上自曝能力边界
建议先拍这一条
成本已经付过
影响：全部九条
这是在选什么
本产品当前的界面策略是隐性乐观 ：拿不到就显示「暂无」、状态算不出就算「完成」、
数据源没接就说「判断自然/广告流量」、AI 答不了就拿别的内容顶上。
「诚实优先」的主张要求反过来：明确说出边界 。你要决定的是这条原则本身。
选错的代价
选错的代价不在某一屏，在整个产品的信息密度 ——这就是顶栏那个开关存在的理由。
现在就切一遍试试 ：A 全部展开 / B 只留会造成错误决策的 / C 全部折起。
这条决策有一个别的决策都没有的特点
选「自曝」不是引入一个新方向，是把已经付过的成本兑现出来。
第 3 节那张表已经列清：missingDataLog、decisionReadiness、lineage、
dataSourceDiagnostics 这四套机制全部是为「自曝边界」设计的，后端全都做好了，只是前端没接 。
本产品自己早就选了这条路，只是没走完。
A 明确自曝边界B 部分自曝C 维持隐性乐观
优点 用户能校正自己的判断；「可追溯」这个卖点第一次成立 ；避免用户拿错的判断花钱 。
缺点 产品看起来「能力更少了」——会出现「参考级 / 判定级」分层、更多的「我拿不到」、更低的字段覆盖度数字。
业务影响 短期功能感知下降。长期：这是从「看起来能用」变成「真的能用来做决策」的唯一路径 。对花钱的决策场景，可信度就是核心竞争力。
选了它，这份稿子（和界面）会变成什么样
把顶栏切到 A ：全文所有「按 D9-A · 界面这里该说的话」区块展开。这就是它的信息密度。
优点 平衡感知与诚实：只在「会造成错误决策」的地方说，其余保持乐观。
缺点 「哪里算会造成错误决策」没有客观边界 ，实际执行会退化成逐条讨论；不一致的诚实度本身会让用户困惑 （这块说不知道、那块又不说）。
选了它，这份稿子（和界面）会变成什么样
把顶栏切到 B ：只有标为 critical 的边界块留下，其余折成一行灰字。
请注意折起来的那几条——判断「它们算不算会造成错误决策」，就是选 B 之后每一次要做的争论。
缺点 本文列出的 20+ 条问题没有一条能真正修好 ——因为它们的根都是「不肯说不知道」。
业务影响 短期感知好，直到用户第一次发现某个数字是错的。在花钱的决策场景，这个发现迟早会来，而且是一次性的信任崩塌。
选了它，这份稿子（和界面）会变成什么样
把顶栏切到 C ：所有边界块折起。页面清爽了很多——这正是它的诱惑，也正是它的代价。
PM 推荐 · A
① 用户的处境决定了这个答案——他做的是要花钱的决策 ，而「一个标着不确定的空白，远好过一个看起来确定但是错的数字」；
② 本产品自己已经选了这条路，只是没走完，选 A 是兑现已付成本 ；
③ 不建议 B ：它听起来稳妥，实际会让每一条决策都要重新辩论一次「这条算不算会造成错误决策」，
而已经证明这个判断在具体条目上极难达成一致（比如 $-1 明显算，但「进度条到不了 100%」算不算？）。
一条明确的原则比九次个案讨论便宜。
未经用户确认
当前展示：A · 明确自曝边界 （PM 推荐，同时也是顶栏视角的默认值）
· 拍了这一条，D1 / D4 / D5 / D6 的答案会自动收敛一大半。
第 5 节
一个坏消息：数据源账号额度用完了，而且它被报成「超时」
这不是假设，是当前状态
MarketAgent 的 SellerSprite 密钥于 2026-08-26 配额耗尽 ：
工具列表只返回 1 个工具 secret_no_remaining（描述「当前没有可使用的次数」），4 轮 ×90 秒轮询结果一致；
强行调用一律回「未授权」。也就是说：此刻打开这个产品，用户会看到「超时」，而真相是「额度花完了」。
为什么「额度用完」会变成「超时」
数据源账号其实有三种状态，而代码只预判了两种 ：可用（45 个工具）／密钥失效／余额为 0 。
校验函数只拦「密钥失效」，「余额为 0」直接通过校验 ，于是取数照常发起，
每次调用回一个代码里没有登记过的错误码 ，落到兜底分支被归成「超时」。
一条能救掉一次错误排查的提醒
以后再遇到本产品报「超时」，先跑一次工具列表看是不是 secret_no_remaining ，
不要先去查网络或调时限——那三件事一件都救不了它，只有补额度能救 。
这本身已经被立成一条需求（并进 D2 的错误可区分性）。
它挡住了什么，没挡住什么
开放项 本轮结论 它决定什么
Q1（U1） 未能验证 工具确实存在于上游且零接入，返回结构零观测 价格带的 5 个校验字段能不能补齐（D5 的后续）
Q2（U2） 完全未能验证 只确认了工具名存在，字段、入参、能不能回答问题全部未知 。四项里最空的一项D6 选项 A 是否存在。 这是一票否决级能力，不能靠推测立项
Q3（U3） 部分验证 4 次未被限流的成功取样 里，这三个字段连同全部别名一次都没有值。
但「上游没这个字段」还是「上游恒为空」尚未区分 措辞只能写「当前取数路径稳定拿不到」，不能写「SellerSprite 不提供该字段」
Q4（U4） 部分验证 3 次真实运行中这两个工具调用成功、未报错、返回 0 行 ——
「因为限流所以空返」的解释被证伪 ；但字段名清单仍是零观测流量格局该不该被标成「参考模块」（D4 选项 B 的依据之一）
好消息：九项决策里六项完全不受影响
D2 / D3 / D4 / D7 / D8 / D9 六项完全不依赖实采 ——它们的依据全部是代码层面的结构性事实。
建议不要为了等额度而搁置整轮，先推进这六项。
受阻的只有：D1 选项 A、D5 的后续补字段、D6 选项 A。
而这三项的推荐方案（B）恰好都不依赖实采。
需要你做一件本稿做不到的事 ：补充 SellerSprite 账号额度 （续费 / 换套餐 / 换一把有余量的密钥）。
按 D9-A · 界面这里该说的话（本条标为 critical）
配额耗尽需要一个与限流完全相反 的独立形态：
「数据源账号的调用额度已用尽。这不是网络问题，重试不会有帮助——请联系管理员补充额度。」
标 critical 的理由 ：这是唯一一处「按现有提示行动会让情况更糟」 的地方——
用户照着「请稍后重试」反复重试，既救不了自己，也让运维一直查错方向。
按当前 D9 视角，配额耗尽继续被显示成「超时」 ——用户与运维都会被带向错误的排查方向。
探针顺手推翻的一条前提，以及一处必须报出的数字冲突
被推翻的前提 ：「那 3 次真实取数样本全部撞上限流」不准确 ——
那 3 次里，Q3 / Q4 相关的调用是成功 的。
所以不能再用「那 3 次都限流了所以不算数」来解释这两项的空值。
数字冲突 ：派单原文写「193 份历史数据带着假窗口标注」，但
96 与另外三份 97 报告都说 3 份 ，只有一份写 193——
而 193 在同一份报告里 有另一个明确定义：去重后的类目路径条数 。
本稿按 3 份采用 ，并列为待澄清 Q12。
为什么要单独报这一条 ：派单要求「凡 96 与 97 冲突一律以 97 为准」，
但本例是 97 内部四份之间冲突 。照抄一个与三份独立报告矛盾的数字，会把一个已知错误固化进设计稿 。
它不阻塞任何决策 ——无论 3 份还是 193 份，「落库的窗口声明与数据无关」这个事实都成立，清理动作都必须做。
第 6 节
本期明确不做的 12 条，以及为什么
规矩是：漏掉不算漏，写明「本期不做 + 理由」才算数。
以下每一条都在第 7 节覆盖表里有对应行，没有一条是静默漏掉的。
# 不做的 理由
8-1 真进度条 （步骤名 / 剩余时间 / 排队位置 / 单步耗时）剩余时间、排队位置、单步耗时三类数据完全不存在 ，任何依赖它们的界面都是虚构。步骤名虽有 4 个词，但全仓零赋值 。⚠ 且页面上已有一个「数据完备度」进度条，新画会打脸 （红线 1）。 8-2 接真实时间窗参数 （D1 选项 A）上游主取数工具是否支持时间窗参数在本仓库内无证据 。这是数据源能力调研，不是前端接线。待探针。 8-3 接商标类工具补认证/IP （D6 选项 A）4 个工具确认存在且零接入，但返回字段完全未知 （Q2）。把未验证的推测写成字段级需求，正是上一版产生 14 类虚构字段的同一类错误。 ⚠ 且探针当前被额度耗尽硬阻断 。 8-4 补优惠券 / Buy Box 价 / 变体最低价 请求与解析路径本来就完整（不是「没接」），问题在上游这几次没返回。「是否永远不返回」属无法验证 （Q1/Q3）。⚠ 特别注意：不要拿 rawFields 里写着这三个字段当「上游支持」的证据 ——那是硬编码常量（红线 11）。 8-5 同比 / 环比徽标 结构化差值字段确实零消费，但三份真实报告里它出现 0 次 ——当前趋势数据不足，它恒为空。先验证趋势数据可用性，否则会画一个永远显示不出来的组件。 8-6 评论有用票数 它被解析出来后既没进证据表也没进证据卡，序列化前就蒸发了 。这是后端需求不是 UI 需求 ，不能混进白送能力包。 8-7 多站点支持 后端三处硬约束只支持美国站，且非美国站时评论链接会整体消失。这是产品范围决策，不是本轮体验优化的范畴。 8-8 离线 / 演示 / mock 模式 连接器注册表无任何开关，历史计划里引用了 12 次的 mock 文件根本不存在 ，README 已承认无 mock 模式。这是新增架构能力，不是接线。 8-9 扩大评论池 与 D2 直接耦合——review 是调用次数最多（13 次）也是 3/3 报告必败的工具，扩大评论池会直接加剧限流 。必须等 D2 的取数策略定下来。 8-10 单条评论定位 （「跳到这一条评论」）依赖 Q5：解析出的评论 id 是不是亚马逊的 review id 未知。在确认前不许把该能力写进需求。 本轮只做措辞约束——只能写「该商品的 Amazon 评论页」 （红线 4）。 8-11 为两个死错误码设计界面 这两个错误码声明了但全库无抛出点 ，是死码。 8-12 为四个永不产出的枚举值设计界面 「低置信」徽标、「样本池回退」选择依据、official 可信等级、低/中成本等级。代码里已有两个走不到的死分支，设计照做会做出永远没人见过的形态 （红线 3）。
第 7 节
覆盖对照：PRD 矩阵 41 行，逐条回填
PM 的要求是：「设计落点」列由 design 回填，回填时必须逐条对上，静默漏一条即视为未交付。
本节把 PRD §6 矩阵的全部 41 行 列出，每行给两个落点——
本稿落点 （这一份把它讲在哪一节）与交互稿落点 （屏级形态归并行的交互稿）。
没有一行是空的。
回填时发现的一处统计出入，如实报出
PRD §6 表尾统计写「✓ 22 · 反推 8 · 事实无 6 · 设计无 6（合计 42）」，
而逐行数下来是 41 行：✓ 23 · 反推 7 · 事实无 6 · 设计无 5 。
另外 PM 移交要点第 3 条写「⚠ 需求有事实无的 5 条 」，而矩阵里这一类是 6 行 。
本稿按行取数，并把 6 行全部按「不要画数据、只画明确说不知道」处理（取更严的那一边）。
已列为 Q13。不影响任何结论——41 行一行没漏。
全部 41
✓ 四层齐 23
⚠ 反推项 7
⚠ 需求有事实无 6
⚠ 需求有设计无 5
显示 41 / 41 行
场景 状态 本稿落点（这份 explainer） 交互稿落点（屏级形态）
S1 空工作台 ⚠ 反推项 §1 用户处境第 1 条（第一次打开的 3 秒） 待交互稿：空态屏 S2 正在生成（同步等待） ⚠ 需求有事实无 §4 D7 选项 A / C+B / D，含红线 1、2 的逐条约束 待交互稿：等待屏（不得画进度/步骤/ETA ） S3 加载历史报告 ⚠ 反推项 §4 D2 选项 C（复用历史是可消除的限流来源） 待交互稿：历史列表 + 加载态 S4 自动识别猜错且不可见 ✓ 四层齐 §2 假控件类；§8 Q8 命名一致性旁及 待交互稿：提交前识别结果可见可改 S5 解析失败建议自相矛盾 ✓ 四层齐 §2 图 1（可自行修复 vs 不可自行修复的失败要给不同动作） 待交互稿：解析失败屏 S6 复制类目路径查不到 ✓ 四层齐 §1 名词表「类目路径」逐字说明冒号格式 待交互稿：类目路径输入与识别 S7 假的时间范围控件 ✓ 四层齐 §2 七句对不上的话第 1 条；§4 D1 全卡 待交互稿：输入区（按 D1 拍板结果定稿） S8 真实取数口径要可见 ✓ 四层齐 §4 D1 选项 B 的「界面会变成什么样」；D8 P0 指标卡补统计窗口 待交互稿：报告头 + 指标卡 S9 类目判定的候选与打分 ✓ 四层齐 §4 D8 选项 B 的 P2（191 条候选怎么展示是真实设计问题） 待交互稿：P2 轮次，本轮不定稿 S10 站点占位控件 ✓ 四层齐 §2 假控件类（危害低于 S7：只有一个选项，用户无法做出错误选择 ） 待交互稿：输入区。不与 S7 打包 S11 「完成」会说谎 ✓ 四层齐 §2 假完成类；§4 D2 可见性的上游根因 待交互稿：版块状态徽标。必须排在 S12 之前 S12 限流 vs 永久缺口 ✓ 四层齐 §2 图 1；§3 四套机制表；§4 D2 全卡 待交互稿：缺失项面板 + 取数诊断面板 S13 缺了该怎么办 ✓ 四层齐 §3 missingDataLog 行；§4 D8 P0 第 1 项 待交互稿：缺失项每条 7 字段 S14 恒亮的「需关注」 ✓ 四层齐 §4 D4 选项 B 的「界面会变成什么样」（3 条常驻缺口挪去参考级） 待交互稿：告警分层 S15 进度条到不了 100% ✓ 四层齐 §2 七句对不上的话第 5 条；§4 D4 全卡 ；§3 红线 1 待交互稿：左栏进度条（复用，不新画 ） S16 面板只在一个版块可见 ⚠ 反推项 §3 四套机制表（信息本就按版块组织，却只在一个版块可见） 待交互稿：面板挂载位置 S17 口径链路可读性 ✓ 四层齐 §2 第 6 条；§3 lineage 行；§4 D8 P1 中文说明替英文公式 待交互稿：口径详情弹层 S18 价格带「完成」但 2/5 ✓ 四层齐 §2 假完成类；§4 D4 选项 C 的拒绝理由（不能再犯同一个错） 待交互稿：价格带版块状态 S19 primePrice = $-1 ✓ 四层齐 §2 第 3 条 + 假可用类；§4 D5 全卡 待交互稿：价格校验表 S20 VOC 是规则不是 AI ✓ 四层齐 §4 D3 全卡 ，含三条隐含规则待交互稿：VOC 版块口径说明块 S21 评论链接可回溯性 ⚠ 需求有事实无 §6 第 8-10 条：本轮只做措辞约束 （红线 4） 待交互稿：只能写「该商品的 Amazon 评论页」，不得写「查看这条评论」 S22 译文恒「暂无」且静默失败 ✓ 四层齐 §9 红线 6 自查：只画「暂无」态 ，需求是「能分清没开和挂了」 待交互稿：中文对照列的「暂无」态 + 状态说明 S23 追问等待态 ⚠ 反推项 §4 D7 边界（追问路径至少有工具轨迹可用，与 S2 素材前提不同） 待交互稿：追问等待屏 S24 认证/IP 答非所问 ✓ 四层齐 §2 答非所问类 + 第 7 条；§4 D6 全卡 （含五步失败链） 待交互稿：追问回答区边界说明 S25 引用是机器 id ✓ 四层齐 §4 D8 P1 第 6 项（人话标签就在同一个对象上） 待交互稿：引用 chips S26 失败提示是开发者话术 ✓ 四层齐 §2 图 1 的反向：这一条要求把技术原因藏起来，与 S12 方向相反 待交互稿：追问失败提示 S27 历史列表 6 条一样 ✓ 四层齐 §4 D8 P0 第 2 项（时钟图标旁恰恰没有时间） 待交互稿：历史列表项 S28 同关键词两次不同 ⚠ 反推项 §4 D2「报告完整性目前是随机的」；本稿标注它是静态论证 + 强间接证据，非实测 待交互稿：跨次可比性说明 S29 密钥失效整站不可用 ⚠ 反推项 §2 图 1 第 5 支（联系管理员换密钥） 待交互稿：鉴权失败屏 S30 60 秒超时全丢 ✓ 四层齐 §2 图 1；§4 D7 全卡 （含「60 秒是一行常量」的成本纠正） 待交互稿：超时后的部分报告形态 S31 配额耗尽被误报成「超时」 ✓ 四层齐 §2 图 1（动作相反的两支 ）；§5 全节 ；§4 D2 的 critical 边界块 待交互稿：配额耗尽独立形态（与限流文案相反 ） lineage.rawFields 当字段可用性依据⚠ 需求有事实无 §3 红线 11 全块 （本稿全文零处 拿它当依据）待交互稿：只能渲染、不得当依据 「真进度条」（步骤/ETA/排队/耗时） ⚠ 需求有设计无 §6 第 8-1 条 + §4 D7 选项 D；§9 红线 1、2 自查 本期不做 「接真实时间窗参数」 ⚠ 需求有设计无 §6 第 8-2 条 + §4 D1 选项 A（明写不为它画形态） 本期不做 ，待探针「接商标类工具补认证/IP」 ⚠ 需求有事实无 §6 第 8-3 条 + §4 D6 选项 A + §5 Q2 行 本期不做 ，字段结构未知「补优惠券 / Buy Box / 变体最低价」 ⚠ 需求有事实无 §6 第 8-4 条 + §5 Q1/Q3 行 + §4 D5 选项 B 的措辞 本期不做 ；措辞只能写「当前取数路径稳定拿不到」「同比 / 环比徽标」 ⚠ 需求有设计无 §6 第 8-5 条 + §4 D8「前置 1」 本期不做 ，先验证趋势数据可用性「评论有用票数」 ⚠ 需求有事实无 §6 第 8-6 条 + §4 D8「前置 2」 本期不做 ，属后端需求「多站点支持」 ⚠ 需求有设计无 §6 第 8-7 条 + §7 S10 行 本期不做 「离线 / 演示模式」 ⚠ 需求有设计无 §6 第 8-8 条 + §7 S29 行 本期不做 「扩大评论池」 ⚠ 反推项 §6 第 8-9 条 + §4 D3 的「D2 与 D3 在这里是耦合的」 本期不做 ，等 D2 取数策略
第 8 节
待澄清：13 条，一条都没有替你假设答案
规矩是：待澄清可以为空，但必须显式声明「无待澄清」，不许自己假设答案继续画。
本清单非空 ——以下每一条本稿都没有自行填答案。
Q1–Q4 · 必须由探针回答（当前硬阻断 ）
四项的具体结论见第 5 节表格。共同前置是一次非限流环境下的重采样 + 扩展探针 ，
而这需要你先补充账号额度 。
Q5–Q11 · 需要你或 tech-lead 回答
# 问题 为什么问 / 它会改变什么
Q5 解析出的评论 id 是不是亚马逊的 review id（形如 R…）？能不能拼出单条评论的链接？
「跳到这一条评论」的能力完全取决于这个答案 。id 是被解析并保留的，但它是不是亚马逊的 id 未知。在确认前不许把该能力写进需求。 Q6 是否同意把「补请求计数 / 失败率 / 耗时埋点」立成 D2 的前置 需求？
仓库内无任何耗时/失败率埋点 。没有它，我们无法验证 D2 任何方案的效果，也无法回答「限流是不是最主要的失败模式」（当前只能说「唯一被观测到的」）。 Q7 市场容量版块在报告级告警里被显式排除 ，与其余 8 个版块规则不对称。这是有意的产品设计，还是遗留？
影响 D4 的分母定义与告警分层。事实层只确认了「存在这个不对称」，没有确认它的意图。 Q8 左栏模块名「市场容量分析」与版块标题「市场容量及趋势」不一致，哪个是准的？
同一个模块两个名字，用户会以为是两块内容。低成本修正，但改哪个方向属于产品命名决策 。 Q9 版块状态的中文说法左右两栏不一致：左「完成 / 部分 / 暂缺」，右「已完成 / 部分完成 / 暂不可用」。统一成哪一套？
同一个状态两套说法会让用户以为是两种不同状态。统一是必须的，用哪套是产品决策。 Q10 本产品的目标使用节奏是什么：单类目深调研 ，还是几十个类目批量粗筛 ？
会实质改变 D2 与 D7 的答案。 粗筛场景下缓存与中途落盘的价值远高于「报告完整」；深调研场景下相反。PM 按「先粗筛再深看」反推，但那是推断，需要你确认。 Q11 「参考级 / 判定级」这个分层要不要贯穿整个产品 ，还是只用在进度条上？
若贯穿，它会成为整个信息架构的主轴（每个版块、每个指标都要标级），设计层的工作量与信息密度完全不同 。这是架构级决定。
Q12–Q13 · 数字与统计口径
# 问题 影响
Q12 已落盘的历史报告实际是 3 份 还是 193 份 ？
只影响 D1「历史数据清理」的工作量估算与是否需要迁移脚本，不影响 D1 的结论 。本稿按 3 份采用。 Q13 本稿新增 PRD §6 矩阵的表尾统计（22/8/6/6，合计 42）与逐行数出的结果（23/7/6/5，合计 41 ）不一致；PM 移交要点又写「需求有事实无 5 条」而矩阵里是 6 行。以哪个为准？
不影响任何结论 ——41 行本稿逐行回填，一行没漏，且「需求有事实无」按更严的 6 行处理。报出来是为了不把一个已知的统计错误固化进设计层 。
三条显式声明的不确定性（不是问题，是诚实标注）
本稿所有场景的出处都不是「来自需求文档」 ——本项目没有 PRD。
docs/superpowers/ 下 10 份是实现计划，且其中 12 项标识符在代码里根本不存在。
反推项与本轮新提项一律待你确认。 有 4 条事实是转述实证，本轮无法复跑 ：报告生成 18.7 秒 / HTTP 201 / 485,741 字节；测试全绿；
.env 的实际取值；本机 Codex CLI 可用性。下游若要基于它们做决策须自行复验。 那三份真实报告是同一批连着跑出来的，样本本身有系统性偏差。
凡「数据能力天花板」类结论，只有那些在代码里就能证明与数据无关的才可当地基
（两个版块不可完成、4 条结构性缺失、状态恒定、状态排除逻辑、文案与路由）。
第 9 节
11 条「不得画」红线：本稿逐条自查
这 11 条是事实层给设计层划的红线。逐条自查是交付条件，不是形式。
第 1、8、9 条是上一版最容易踩的三处；第 11 条是本轮新增，也是最直接会复现「14 类虚构字段」的一条 。
# 红线 本稿自查
1 不得画依赖运行时进度数据的界面；但已有的「数据完备度」进度条不得重画、不得删
通过 本稿零处 画进度条组件。D7 选项 C 明写「复用既有进度条表达完整度，不新画第二个百分比」；D7 选项 A 明写「不得画进度、步骤名、剩余时间、排队位置」；§3 单列一块说清「两个都错」。2 若要做真进度，必须沿用既有词汇 ，不得新造术语
通过 D7 选项 D 逐字列出四个既有中间态 resolving_input / collecting_sample / calculating_metrics / saving_report，并注明「全仓零赋值，所以本期不做」。本稿未新造任何进度术语。 3 不得画四个永不产出的枚举值
通过 「低置信」徽标、「样本池回退」、official、低/中成本等级——本稿一处都没画 ，且在第 6 节 8-12 明写不做 + 理由。4 不得把评论证据的链接说成「跳到这一条评论」
通过 覆盖表 S21 行与第 6 节 8-10 都逐字写死措辞：只能写「该商品的 Amazon 评论页」 。本稿正文中零处 出现「查看这条评论」类表述。5 不得画 Buy Box 价 / 优惠券 / 变体最低价的真实值；也不得写成「上游恒 null」
通过 本稿零处出现这三个字段的任何数值。措辞统一采用探针给的精确说法「当前取数路径稳定拿不到」 ，未写「SellerSprite 不提供该字段」 （见 D5 选项 B、§5 Q3 行、第 6 节 8-4）。6 不得画中文标题/原文的真实译文——只能画「暂无」态
通过 本稿零处出现译文样例。覆盖表 S22 行明写「只画『暂无』态，需求是『能分清没开和挂了』」。7 不得把左栏「数据源 SellerSprite · Active」当成健康状态
通过 本稿零处把它当健康信号。§5 的排障提醒走的是另一条路径：「先跑一次工具列表看是不是 secret_no_remaining」 ，而不是看那个徽标。8 不得把 sampleSummary.warnings 当「零渲染」
通过 §3「三条最容易照着抄错的地方」单列一块，明写它会被渲染 、照抄会做出重复告警 ；D8 卡片的「两条必须避开的坑」再列一次。9 不得把 TrendMeta 整体列进白送清单
通过 §3 与 D8「坑 2」都写明只有一个字段未用 ，其余已在消费。本稿的 D8 白送包清单未包含 TrendMeta 。10 decisionReadiness 的 summary 与阻塞项目前无处展示，要用属于新增前端能力，须显式立项 通过 §3 四套机制表里该行的「前端消费情况」逐字写「目前无处展示（红线 10：要用属于新增前端能力，须显式立项） 」；D8 把它放在 P2 轮次 而非本轮，即为显式立项。11 🔴 不得把 lineage.rawFields[] 当成「上游返回了这些字段」的证据
通过 §3 用一整块红色提示写清它是写死的字符串常量 ，并列出只认三类 A 级证据 ；第 6 节 8-4 再警一次。
本稿全文零处拿 rawFields 作任何字段可用性依据 ——覆盖表里它单独占一行，标注「只能渲染、不得当依据」。
视觉与形态自查
形态 ：--kind explainer —— 单栏 1100 居中、零缩放 （全稿没有任何缩放变形声明，量出来即真实尺寸）、无设备框、无五页签外壳。token ：./tokens.micro.css 是 design/tokens.micro.css 的逐字副本 （shell 复制，非手抄），并在 <head> 里被真实引用。零自配颜色 ：app.css 内不含任何颜色字面量，全部走 var(--…)；弱底一律用项目自带的 -soft 变体，未给基色自配 alpha。两张图 ：用 HTML + CSS 画，直接消费 token 变量 ，因此浅色/暗色自动跟随，也不需要一份手算的 hex 等价表。图 1 三色、图 2 四色，均不超过四种。批注层 ：annotate.css（</head> 前）与 annotate.js（</body> 前）均在位，未被删除。