TL;DR​

同一份投放账单，两个「获客成本」：线索成本 ¥8，询盘成本 ¥41——差 5 倍。一间店铺的关键词周账实测：线索 4,111 对询盘 824。线索是宽口径（收藏、加购、领券、点击联系全算，还按次数累加），询盘只有旺旺询单一种。看人气用线索，做预算只用询盘——拿 ¥8 的口径去配预算，缺口从一开始就是 5 倍。

处境：¥8 的获客成本，提气得让人想加预算​

月报里「线索成本」那条线漂亮极了：¥8 拉一个意向客户。按这个数配下一季度的获客预算，逻辑闭环。

直到把「询盘成本」摆在旁边：¥41。同一个账户、同一份消耗、同一个月，两个数字差 5 倍。本次对账来自开发 AI 运营 过程中的指标口径核查。

数据：5 倍的差距，和一个单向包含​

最后两行是关键：有询盘必 有线索，反之大不然。这说明线索是询盘的超集——（专业注：线索口径把收藏、加购、领券、点击联系等互动全部计入，且按次数累加；同一买家点三次「联系」，就是三条线索。询盘只有一种：买家主动发来的旺旺询单。两者不是「两个指标」，是「全部互动」和「其中最值钱的那种」。）

那 269 条「有线索、零询盘」的记录，就是热闹与生意的距离：互动发生了，询单没发生。

值多少：5 倍的预算缺口​

拿线索成本 ¥8 做预算底仓，市场费用会按「¥8 拉一个客户」配置；真实口径 ¥41，缺口从第一天起就是 5 倍。这不是乐观，是系统性错配——所有下游决策（报价、毛利、放量节奏）全部建在一个虚的分母上。线索口径可以用，只允许用在一件事上：看素材和活动有没有把人气做起来。

给运营者的纪律​

1. 两个口径分开记账，名字里带上口径：「线索成本 ¥8」「询盘成本 ¥41」——混着叫「获客成本」的报表，迟早出事。
2. 预算、调价、商品盈亏，只用询盘口径：询单不可灌水、紧跟成交，是唯一算数的分母。
3. 线索当人气温度计：线索突涨去看素材和活动；它上个月是你的人气参考，永远不是你的成绩单。
4. 人群调价同理：考核人群看询盘成本，完整逻辑见 询盘成本只差 10%，ROI 差 4 倍：人群报表要用两把尺子。

常见问题​

1688 的线索数和询盘数差在哪？​

询盘是旺旺询单，一个算一个；线索把收藏、加购、领券、点击联系按次数累加。实测同一账户：线索 4,111 对询盘 824，差 5 倍。

汇报该用线索成本还是询盘成本？​

对外报喜可以用线索口径，预算决策只能用询盘成本——实测两者 ¥8 对 ¥41，拿 ¥8 报预算就是给自己挖坑。

有线索没询盘说明什么？​

实测 269 个关键词·周有线索、零询盘——互动没走到询单那一步。看素材人气可以，别当获客成绩。

这套「指标口径分账」的做法，已经内建进 AI 运营——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。两个口径差 5 倍的指标，不该共用一个名字。

TL;DR​

同一件商品、同一个投放方案的 9 周真实账单：8 周 ROI 在 0~2.1 之间，其中一周冲到 61.6——6 笔订单带回 ¥15,143。如果你恰好在那一周看报表并决定加预算，下一个月就会眼睁睁看它回落到常态。大单是惊喜，不是基线；预算跟着询单的常态走，不跟大单的运气走。

处境：那一周的报表，完美得让人想加预算​

周报拉出来：某商品 ROI 61.6，消耗才 ¥246，成交 ¥15,143。任何运营都会心跳加速——这是十倍回报的信号，值得加预算、值得复制打法。

先把 9 周的账摊开再看。本次对账来自开发 AI 运营 过程中的一次商品周账下钻。

数据：9 周里的一根针​

同一商品、同一方案（全店推广），连续 9 周的原始周账：

消耗全程稳定在 ¥156~249，第 4 周唯一变化的变量是订单金额。9 周的常态 ROI 大约在 1 上下徘徊，61.6 是从天上掉下来的。

为什么它会骗人​

（专业注：周报粒度看不见订单内部分布。第 4 周 6 笔订单摊 ¥15,143，平均单笔 ¥2,524——是相邻各周单笔金额的几十倍。要分辨是「一笔大单」还是「六笔中单」，必须下钻到日级甚至订单级数据；周报给不了答案，但足以告诉你「这周不对劲，先别下结论」。）

大单周的三重错觉：它让你高估获客能力（其实询单量没变）、让你期待可复制性（大单是低概率事件）、让你在错误的位置加预算（常态 ROI ≈ 1 的商品，加多少亏多少的毛利口径都在那里）。

值多少：错配账​

按第 4 周的 61.6 加预算，等于把这个组合当成十倍回报的产线来扩建。两种算法给出两个世界：9 周合并平均 ROI = ¥16,358 ÷ ¥1,872 = 8.7；剔除大单周，8 周常态 = ¥1,215 ÷ ¥1,626 = 0.7。平均数替大单撒了谎——一个平均数，两种人生。常态 0.7 意味着每花一块钱回七毛：这个组合此前每周烧的 ¥200 本来就是净亏，放大它只是放大亏损。

给运营者的纪律​

1. 分段看窗口，不看全程平均：把观察期切成 4 周一段，平均数会把「曾经好过」和「现在不行」匀成一个「还行」。
2. 询单是体温计：大单前后询单量持平，说明带客能力没变，变的是运气；询单同步萎缩才是获客能力恶化——两者的处理完全不同。
3. 大单记账为惊喜：预算决策按没有大单的常态效率来；有大单撑场的组合，观察期拉长，等没有大单护体的周期看它真实的样子。
4. 周报异常只触发下钻，不触发决策：看见极端值（61.6 或 0.0），第一步永远是下钻日级数据看分布，不是调整预算。

常见问题​

怎么识别 ROI 是被大单撑起来的？​

拉长窗口分段看：归因高度集中在某一周、之后回落、询单量没变——获客能力没变，变的是那一单的运气。

大单周的 ROI 为什么不可信？​

它不可复制。实测案例：某周 ROI 61.6，其余 8 周全部在 0~2.1——按 61.6 加预算，下一个周期就来不及了。

归因突然归零的商品怎么办？​

先看询单：询单没变是运气退潮，按常态效率决策；询单同步萎缩才是获客能力恶化，两者的处理完全不同。

这套「分段窗口 + 询单体温计 + 日级下钻」的核验方法，已经内建进 AI 运营——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。极端漂亮的数字，值得先验再信。

TL;DR​

「等 16 天再下结论」不够。我们把 5 个早已「定型」的历史周从平台重新拉了一遍，做了一次对照实验：结束后的广告周，最晚到第 29 天还在长新数据（晚加的词会回来「翻旧账」）；而到第 40 天以后，哪怕把历史周整个重采一遍，已有的旧数字一个都没被改；比定稿更残酷的是保留期——平台明细只留 6~7 周，54 天后 6 个计划全部无法补回。每周采集、本地存档——换来的是两样东西：不可逆的决定不踩坑，历史数据归你自己。

导火索：结束后第 29 天，还在长新数据​

一间工业品类目 B2B 店铺（已匿名）的例行续采里，8 月 10 日的一次采集，往一个已收尾 29 天的自然周写进了 27 行新的区域明细——涉及 5 个计划，行数 +22%。而按圈内流传的口径，这个周早在半个月前就该「16 天封账」了。

16 天到底是平台实测，还是以讹传讹？验证方法现成：往更老的历史周里再采一次。如果几十天前早已「定型」的周重采后会冒出新行、改掉旧值，说明 16 天远不是终点；顺手还能量出平台把明细到底留多久。8 月 21 日，我们把 5 个更老的周重新拉了一遍，就有了下面这个实验。

这个实验，来自开发 AI 运营 过程中的一次数据口径核查。

实验设计：把 5 个「已定型」的周重新拉一遍​

思路很朴素：基线 → 重采 → 逐行对照。

1. 选 5 个连续自然周（2026-06-08 ~ 07-06），补采前它们距当时已有 40~74 天，按任何口径都算「定型」；
2. 先导出一份基线（4 张明细表：总览 / 商品 / 关键词 / 区域，共 1199 行）；
3. 触发一次平台补采（指定日期范围，全量重拉），再导一次；
4. 逐行 diff：新增多少行、值变化多少、消失多少。2026-09-02 复查，结论未变。

对照结果：

1,199 行逐行对照的净结果：没有一个历史数字被修订（值变化 0、消失 0），唯一的差异是关键词表多出 11 行。这 11 行不是值改了，而是新长出来的实体——两种回补机制的区别见发现二；平台这次到底只重新返回了哪些计划的明细，藏在发现三。

发现一：值的账，16 天封不住，40 天后才是真终态​

先说结论的边界：「16 天」既对，也不对。

• 平台口径的归因回补约 15 天，「16 天封账」由此而来；
• 导火索事件正是反例：结束后第 29 天仍长出 27 行新区域数据，几乎是口径的两倍；
• 实验补上终止点：40~47 天龄的周重采后历史值零变化——回补终究会停，只是停止点比 16 天晚得多。

对运营的含义：用 16 天做「大概能看」的依据可以，作为「定稿」的依据不够。 计划去留这种不可逆决定，等满 4~5 周再看封账数据，才踩在实测的停止点之后。停计划前的完整检查清单，见 1688 广告计划什么时候该停？先过五道检查。

发现二：中途加过的词，会把以前的数据「补」回来​

人话版结论先行：你能「翻旧账」翻出多少东西，取决于你现在挂了哪些词。

实验店铺的某个计划中途加过几个词。重采历史数据时，平台把你现在挂在计划里的词，连以前每周的表现一起送了回来——有个词补出的历史周带着完整指标：11179 次曝光、¥342.7 消耗、10 条询盘、11 笔订单。这些数一直躺在平台那边，只是你不去采，它就不出现。

（专业注：机制叫「实体级回补」——接口按当前关键词列表返回历史周数据。行数会涨，已有行的值一个不变。所以看到重采后数据变多，先分清是旧数字被改了、还是长出了新行：前者要警惕，后者是白捡。）

但「白捡」有个前提：平台还得留着明细。留多久？这就是发现三。

发现三：真正的悬崖不是定稿晚，是明细被删​

回补慢只是「等」，保留期是「没」。重采时按计划逐个检查了平台还能不能返回明细：

• 40~47 天龄的两个周：同一批 6 个计划里，只有 3 个还能返回完整明细；
• 54~74 天龄的三个周：还是这 6 个计划，全部返回 0 行——不是值旧了，是明细已经从平台侧删除，永远无法补采；
• 40 天就返回全空的那 3 个，是计划级保留期更短、比全局悬崖走得更早——本次样本仅一例，待后续观察。

换句话说：凡是没在 6 周内落到自己库里的明细数据，平台已经替你删了。 「以后有空再导」不是拖延，是丢弃。

这套发现值多少：先算两笔账​

误杀账。 16 天口径最大的成本，是把「数据没到」误读成「计划不行」。发现二里那个补出历史数据的词，单周就有 10 条询盘、11 笔订单——一个正在起量的计划被提前误停，一周的损失就是这个量级，还没算重新起量要再搭的一两个结算周。等满 4~5 周再拍板，买的是「不做错决定」。

丢失账。 平台 6~7 周就删明细，「回头再补」是会过期的幻想。上季度哪个区域在供询盘、哪个词的成本在悄悄爬升——这些问题只有把数据落进自己库里的人才答得上来。每周一次采集导出，买的是「历史永远可查」。

给运营者的三条纪律​

1. 看趋势，随时看；下不可逆的决定，等 4~5 周。 16 天做参考线，29 天做保险线。
2. 每周固定采集或导出一次明细，本地存档。 平台侧的明细比你想的短命得多，存档才是你自己的数据资产。
3. 复盘前先补齐「结算尾巴」（每个周期还在陆续补记的那部分数据）。 评估某段时期的整体效果，要把每个周期的回补都算进去，否则结果会系统性偏低——分不清旧数字被改了还是长了新行时，用实验里那招：逐行对照。

给做数据集成的人：重叠窗口至少留 5 周​

如果你的系统在按周续采 1688 广告报表（或做类似平台的归因数据管道）：平台口径 15 天的归因窗口，实测最晚回补在 +29 天。严格周节奏 + 4 周重叠的配置，最后一次重写落在周末后 +22 天——恰好盖不住实测的 +29 天事件（我们那次是靠采集间隔偶然拉长才兜住的）。把重叠窗口从 4 周调到 5 周，每周请求量约多 20~25%——每多回溯一周，就多拉一周的分页明细，换的是不再漏数据。

常见问题​

1688 广告数据要等多久才算定稿？​

平台口径归因约 15 天，但实测最晚回补发生在周末后第 29 天。稳妥做法是等满 4~5 周再下计划去留的结论。

历史广告数据没及时导出，之后还能补回来吗？​

大概率不能。平台明细只保留约 67 周：实测 4047 天仅 3/6 计划可查，54 天后 0/6，超期永久丢失。

为什么重采后多了没见过的关键词行？​

接口按当前关键词列表返回历史周数据。晚加的词会补出历史行——实体级回补：行数会涨，已有行的值不会变。

这套「基线 → 重采 → 逐行对照」的核查方法，已经内建进 AI 运营——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。广告数据是一切分析的地基，而地基的口径，值得实测一次。

TL;DR​

同一个商品，挂在不同 1688 广告方案里，询盘成本能差 4 倍多。一间店铺三个主力商品的投放周账实测：同款成本从 ¥17 到 ¥78，且成本座次由方案主导——「核心商家成长」方案对三个商品都最贵，同一商品换个方案最多差 4 倍。落地成三条：评商品，用全方案合并口径；评方案，用同批商品同期对比；时间窗不重叠的方案数字，不能直接比。

处境：你准备停的，可能是被通道冤枉的商品​

周一复盘，某个商品在你主推方案里的询盘成本爆表，你开始琢磨把它停了。先别动——一间工业品类目店铺（已匿名）三个主力商品的真实账本显示：同一个商品在不同广告方案里，成本可以从 ¥20 摆到 ¥78。商品没变、页面没变、价格没变，变的只是它从哪个通道进场。这次对账，来自开发 AI 运营 过程中的一次投放周账核查。

为什么：同款商品的成本，方案说了算​

把三个主力商品在所有投放方案的周账摆到一起，先看全期汇总（询盘成本 = 累计消耗 ÷ 累计询盘）：

三层结构，一层比一层有用：

1. 全期最贵与最便宜差 4 倍多——¥78 对 ¥17。

2. 成本座次由方案主导。 「核心商家成长」对三个商品都最贵（¥49~78）——三个完全不同的商品，在这个方案里无一例外地贵。差异的主导因素是方案（它买什么流量），不是商品（它是什么货）。

3. 同期窗口内差 1.8~3.9 倍。 后三个方案的时间窗重合（2026-06-29 起 8 周），同期对比是干净的：商品 A 差 1.8 倍、商品 B 差 3.9 倍、商品 C 差 1.8 倍。

（专业注：前两个方案的数据止于 2026-06-29，后三个恰好从这天开始——新旧窗口不重叠。「老方案 ¥25、新方案 ¥77」这种跨期对比混着两种因素：方案差异和市场季节差异，直接下结论会误判；统计上这与辛普森悖论同源——分层看一致的结论，合并看可能反转。本文所有「差几倍」只取自同期窗口。）

还有一个反直觉的细节：「核心商家成长」不是冷启动贵，是越来越贵。 同期 8 周，它的询盘成本从 ¥26 一路走到 ¥107——「新方案再等等」的解释被排除，流量结构决定的钱，等不来。

值多少：两笔账​

误杀账。 商品 B 在「潜客人群收割」里 ¥20 一条询盘、月均十几条。只看它在「核心商家成长」里的 ¥78 就把商品停掉，扔掉的不是坏商品，是一条还在稳定供货的便宜通道。

对账账。 商品 B 的五个方案数字（¥37 / ¥25 / ¥78 / ¥20 / ¥22）哪个是真的？都是，也都不是。它的真实获客成本是合并口径：总消耗 ¥32,265 ÷ 总询盘 911 = ¥35。单方案数字既可能高估也可能低估商品——只有合计才是商品的真实身价，预算分配才有不漂移的锚。

给运营者的纪律​

1. 评商品，用合并口径：总消耗 ÷ 总询盘。分方案数字回答的是「通道贵不贵」，不是「商品行不行」。
2. 评方案，用同批商品同期比：固定一批商品、固定时间窗，方案之间的座次才有意义。
3. 跨时间窗的数字不直接比：新旧方案交接期尤其危险——老方案的历史成本不是新方案的标尺。
4. 持续恶化的方案不值得等：连续 4 周以上成本走高先降预算；去留判断配合封账纪律，见 1688 广告数据，等 16 天真的够吗？我们做了个重采实验，停投前的完整检查见 先过五道检查。

常见问题​

同款商品在不同广告方案里询盘成本差很多，正常吗？​

正常。三个主力商品的实测里，同款跨方案询盘成本从 ¥17 到 ¥78，排序跟方案走、不跟商品走——方案买的是不同的流量。

评商品该用哪个询盘成本？​

合并口径：商品在所有方案的总消耗 ÷ 总询盘。单方案数字只回答「这个方案买这条流量多少钱」，不能用来判商品好坏。

不同方案之间的成本能直接对比吗？​

只有时间窗重合的部分能直接比。新旧方案投放窗口不重叠时，成本差混着方案差异和市场季节差异，直接比会误判。

这套「把同款商品的所有通道摆到一行」的对账方法，已经内建进 AI 运营——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。每个商品的真实获客成本，值得算一次全的。

TL;DR​

一间店铺的真实账本：29 个历史周里，整店询盘成本稳定在 ¥2531；新方案上线后，**连续 7 周站上 ¥3449，第 8 周冲到 ¥69**。整店效率滑坡从不以事故形式出现，它以「每个计划单看都还行」的形式出现——所以需要一把专盯整体的尺子：自己历史定的区间 + 连续 3 周越线即告警。这次复盘里，警铃若在第 3 周拉响，后 5 周约 ¥7,400 的超支可以免掉。

处境：每个计划都「还行」，合起来在恶化​

单计划复盘时一切照旧：这个计划 ROI 和上月差不多，那个计划稳定，新计划还在爬坡。单看都过得去。

整店层面：7 月的每一周，询盘成本都站在 ¥40 以上——而之前 29 周里，这个数字只在春节周越过年门槛一次。本次复盘来自开发 AI 运营 过程中的整店周账核查。

方法：用自己的历史定线​

这把尺子的基准不是行业、不是目标，是你自己的历史：

1. 取过去半年每周的整店询盘成本（周消耗 ÷ 周询盘）
2. 剔除异常周：本例剔除了两类——春节周（¥121，消耗萎缩导致的假贵）和 6 月上旬的 3 周断档（周消耗 ¥90~281，接近停投）
3. 剩下的 26 周落在 ¥2041，主体集中在 **¥2531**——这条带就是「正常区间」
4. 告警条件：连续 3 周以上越过区间上沿，且消耗没有萎缩（消耗萎缩导致的成本升高是另一类问题）

（专业注：为什么用「连续 3 周」而不是单周——单周越线在 29 个历史周里出现过 4 次，全是噪音；连续越线一次都没出现过。基线自己会告诉你阈值该多严。）

这次预警的完整复盘​

• 6 月 8~22 日：断档 3 周。周消耗从 ¥1,900 量级掉到 ¥90~281，接近停投
• 6 月 29 日：新投放方案上线（方案切换的细节与数据，见 同款商品换方案，询盘成本差 4 倍）
• 6 月 29 日起：连续 7 周越线——¥46 / 43 / 40 / 43 / 40 / 49 / 34，全部高于历史上沿 ¥31
• 8 月 17 日当周：¥69，消耗放大到 ¥5,210 而询盘没跟上

断档重启不等于回到原点：环境变了、方案换了，旧的成本水位不再适用——这正是单计划视图看不见、只有整店线能暴露的变化。

值多少：超支账​

越线的 7 周（6-29 ~ 8-10）合计消耗 ¥24,699、询盘 592 条，实际成本 ¥41.7。若效率仍在历史水平（¥28），同样的询盘该花 ¥16,576——7 周多花约 ¥8,100。警铃若在第 3 周拉响、第 4 周开始干预，后 5 周约 ¥7,400 超支可免。这就是这把尺子的价格：定一次线，盯一个数。

给运营者的纪律​

1. 线必须用自己的历史定：至少半年周数据，剔除春节、大促、断档这类异常周。三五周的平均值当标尺，比没有标尺更害人。
2. 连续 3 周越上沿 + 消耗未缩 = 告警：单周越线是噪音，连续越线是结构。
3. 告警先找共同原因，再动计划：方案切换、断档重启、类目竞争变化都是账户级事件——逐个修计划治标不治本。
4. 成本数字本身要等封账：判线用的周数据有结算尾巴，口径纪律见 1688 广告数据，等 16 天真的够吗？我们做了个重采实验。

常见问题​

整店广告效率下滑有什么信号？​

周询盘成本连续 3 周以上越过自己的历史区间上沿，且消耗没有萎缩——单计划可能都「还行」，合起来在滑坡。

「正常区间」怎么定？​

取自己过去半年周询盘成本，剔除异常周（春节、断档），中位数上下各浮约一成作区间。周数不够的店先积累。

告警之后第一步做什么？​

先找共同原因再动计划：查当期有没有方案切换、断档重启这类账户级事件——整店越线多半是账户层的变化。

这套「历史定线、整店盯盘」的预警逻辑，已经内建进 AI 运营——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。效率滑坡不该靠季度复盘才发现。

在 VS Code 扩展面板给 Claude Code 发消息时，面板长时间转圈无响应，最终报 API Error: 500 [1234][网络错误，请稍后重试]——而同一时刻终端里的 claude 完全正常。这篇文章记录这次排查的完整过程和结论。

记过账的人都知道：难的不是记，是坚持。打开 App、找入口、选类目、填金额、存——每一步都在劝退。而情绪和服药记录更散落：今天心情怎样、药吃了没有，往往等想起来已经过了记的最佳时机。

Life 的答案是：像发消息一样说出来。

• 「今天午饭花了 32 块」→ 一笔餐饮支出，金额、时间、类目自动就位
• 「上个月借小李 2000，今天还了 500」→ 借贷台账记好，未结 1500 自动算清
• 「这个月吃饭花了多少」→ 不用翻列表，直接问

👉 访问 Life：life.ccleeai.com ｜ 使用文档：aidevhub.ai/docs/life

在数据报表页面点击表格某一行查看详情时，被点的行和另外几行同时高亮，控制台还在不停刷 React duplicate key 警告。

在开发 AI运营 时遇到此问题——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。广告周报页面里有多张明细表（计划×关键词、计划×地域），每张表都要支持点击行高亮、联动查看该行的投放明细。上线后点任意一行，同一计划下的所有行会一起「点亮」。

TL;DR​

Ant Design 的 Table 用 rowKey 的返回值作为每行的 React key。当 rowKey 取的字段不是数据的真实业务键——列名凭猜测、或漏了参与唯一性的维度——多行会生成相同的 key：所有按 key 匹配的行交互（选中、高亮、展开）一次命中多行，React 还会抛出 duplicate key 警告。修法：先用 information_schema 查表的真实列，再选定真正唯一的列或复合列做 rowKey，并用 GROUP BY HAVING 验证。

问题现象​

下面是一个最小复现（Ant Design 5 + React 18）：

import { Table } from 'antd';
import { useState } from 'react';

// 数据粒度：关键词 × 商品 —— 同一个关键词会按推广商品拆成多行
const data = [
  { keyword_id: 88, keyword: 'summer dress', offer_id: 101, clicks: 12 },
  { keyword_id: 88, keyword: 'summer dress', offer_id: 102, clicks: 7 },
  { keyword_id: 90, keyword: 'maxi skirt', offer_id: 103, clicks: 5 },
];

export default function WeeklyKeywords() {
  const [selected, setSelected] = useState<string[]>([]);
  return (
    <Table
      rowKey={(r) => String(r.keyword_id)} // 坑：keyword_id 在该粒度下不唯一
      columns={[
        { title: '关键词', dataIndex: 'keyword' },
        { title: '商品', dataIndex: 'offer_id' },
        { title: '点击量', dataIndex: 'clicks' },
      ]}
      dataSource={data}
      rowSelection={{ selectedRowKeys: selected, onChange: setSelected }}
      onRow={(r) => ({ onClick: () => setSelected([String(r.keyword_id)]) })}
    />
  );
}

症状有两个：点击第一行，前两行（keyword_id 都是 88）同时高亮；控制台反复出现：

Warning: Encountered two children with the same key, `88`.
Keys should be unique so that components maintain their identity across updates.

根因​

antd Table 的行身份就是 rowKey 的返回值。 它被直接用作该行 React 元素的 key。key 重复时，React 的 diff 会把多行视为同一个元素：渲染可能错乱，受控状态会在行间互相串。

所有按 key 匹配的行交互都会被放大。 rowSelection 的 selectedRowKeys、onRow 点击、expandedRowKeys 全部按 key 比较——key 重复时一次匹配命中多行，这就是「点一行亮一片」的直接原因。

键列选错往往发生在数据侧。 这次的实际根因：键列是凭命名猜测的——以为地域表有 region_id，表里实际的业务键列是 area_name；以为关键词表的粒度是关键词，实际是关键词×商品（offer_id 也参与唯一键）。键列漏配维度，同组所有行的 rowKey 就完全相同。

解决方案​

第一步：查表的真实列，别凭命名猜​

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = 'ad_weekly_keywords'
ORDER BY ordinal_position;

确认业务键到底是哪些列，表里是否真的存在你以为的那一列。

第二步：验证键（或键组合）唯一​

SELECT keyword, offer_id, COUNT(*)
FROM ad_weekly_keywords
GROUP BY keyword, offer_id
HAVING COUNT(*) > 1;
-- 返回 0 行 = 唯一；同时确认键列无 NULL

第三步：用复合键配置 rowKey​

<Table
  rowKey={(r) => `${r.keyword}::${r.offer_id}`}
  // 或者更稳：JSON.stringify([r.keyword, r.offer_id])
  dataSource={data}
  ...
/>

拼接复合键时用一个字段值里不可能出现的分隔符（或直接 JSON.stringify 成数组），避免 a + b 与 ab 撞键。

改完后行点击只高亮一行，duplicate key 警告清零。这和React 列表 key 重复导致 DOM 报错是同一族问题——key 唯一，diff 与行交互才谈得上正确。

常见问题​

Ant Design Table 的 rowKey 应该怎么设置？​

设置为数据中唯一标识一行的字段或字段组合：单字段唯一就直接用，单字段不唯一就用多列拼复合键（分隔符防撞或 JSON.stringify）。别用不唯一的业务字段，也别图省事用数组 index——排序、筛选、分页后状态会串行。

React duplicate key 警告怎么解决？​

key 重复意味着 React 把多个节点当成同一个元素，渲染错乱、状态互串。先定位产生重复 key 的列表渲染处，换成真正唯一的 key，再从数据源侧用 GROUP BY HAVING 验证唯一性——只消警告不查数据，问题迟早换个形式复发。

在对生产数据批量跑 LLM 语义校验时，2449 次调用全部「成功」返回，但结果全部降级为默认值，日志里几乎没有失败记录。

在开发 AI运营 时遇到此问题——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。商品标题优化链路里，需要让 LLM 对「关键词 × 商品」组合做语义校验：每批词一次调用，只返回一个小小的 JSON 判定。这本该是最简单的一类 LLM 调用，结果首跑 2449 对全部走了兜底降级，Layer2 一次有效 LLM 判定都没产生。

TL;DR​

DeepSeek / Qwen 等思考模型的推理文本与正文共享同一份 max_tokens 预算。结构化小输出调用如果不显式关闭 thinking，推理链会独自吃满预算：finish_reason 变 length、content 返回空字符串，而解析失败的重试循环又只记异常不记解析错误——静默重试耗尽后整体降级，全程不报一条错。两件事要做：结构化调用显式关闭 thinking；解析失败时先记 finish_reason，别只 catch 异常。

问题现象​

下面这段最小复现代码展示了整个过程（需要 pip install openai 和一个支持 thinking 的模型）：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

resp = client.chat.completions.create(
    model="deepseek-reasoner",
    messages=[
        {
            "role": "user",
            "content": (
                '判断下面的关键词是否适合写入商品标题，'
                '只返回 JSON：{"suitable": true} 或 {"suitable": false}。\n'
                "关键词：summer women dress\n"
                "商品：floral midi dress for women"
            ),
        }
    ],
    max_tokens=2000,  # 推理段与正文共享这份预算
)

print("finish_reason:", resp.choices[0].finish_reason)
print("content:", repr(resp.choices[0].message.content))

thinking 开启时的典型输出：

finish_reason: length
content: ''

HTTP 层一切正常：没有超时、没有 5xx、SDK 不抛异常。如果外层是「解析失败就重试、重试耗尽就兜底」的循环，日志里最后只会留下一条「重试耗尽」的 warning——看起来就像偶发网络问题。

根因​

思考模型的推理段不单独计预算。 DeepSeek、Qwen 等模型的思考内容（reasoning content）与最终正文共用 max_tokens 这一个上限，没有独立的「推理预算」字段。

结构化小输出调用的预算往往设得小。 一个布尔判定预期输出只有几十个 token，max_tokens 给到 2000 已经绰绰有余——但推理链的长度完全不可控，一旦它先吃掉 2000 个 token，模型就再也没有机会输出正文：finish_reason 返回 length，content 是空字符串，接口却正常返回 200。

工程侧还有一个放大器。 空字符串不是合法 JSON，但很多重试循环只 catch 网络与 API 异常，解析失败被当成「这一轮没结果」静默重试。这类吞掉异常的静默失败在重试循环里尤其难查：重试 N 次全部是同一个根因，日志里却只有最后一条兜底 warning，极易误判为网络抖动。

解决方案​

第一步：结构化输出调用显式关闭 thinking​

布尔判定、JSON 抽取、分类打标这类调用不需要多轮推理，按供应商传参关闭：

def thinking_disabled_extra_body(provider: str) -> dict:
    """结构化小输出调用：按供应商显式关闭 thinking。"""
    if provider == "deepseek":
        return {"thinking": {"type": "disabled"}}
    if provider == "qwen":
        return {"enable_thinking": False}
    return {}


resp = client.chat.completions.create(
    model=model_name,
    messages=messages,
    max_tokens=2000,
    extra_body=thinking_disabled_extra_body("deepseek"),
)

关闭之后，2000 token 预算全部留给 JSON 判定本身。实测修复后重跑，2449 个词×商品对全部正常返回判定结果——而修复前整批静默降级，日志里只有 3 条「重试耗尽」warning。

第二步：别让解析失败静默发生​

即使关掉了 thinking，也要把「解析失败」变成一条带证据的日志，下次任何原因导致的空输出都能在一条日志里定位：

import json
import logging

logger = logging.getLogger(__name__)


def parse_judgment(resp) -> dict | None:
    content = resp.choices[0].message.content
    try:
        return json.loads(content)
    except (TypeError, json.JSONDecodeError):
        # 关键：记录 finish_reason 与原始 content，而不是只记异常
        logger.warning(
            "LLM 输出解析失败: finish_reason=%s content=%r",
            resp.choices[0].finish_reason,
            content,
        )
        return None

排查 LLM 降级时，先看 finish_reason：length 说明输出预算被打满（大概率是推理占的），stop 才是正常结束。这一步比翻异常日志有效得多。

如果你的返回 JSON 还要过一层 schema 校验，在 TypeScript 项目里用 Zod 时留意另一个校验 LLM 输出静默丢字段的坑。

常见问题​

如何关闭 DeepSeek 的 thinking 输出？​

OpenAI 兼容接口通过 extra_body 传 {"thinking": {"type": "disabled"}}；Qwen 用 {"enable_thinking": False}。布尔判定、JSON 抽取这类结构化小输出调用不需要推理链，默认关掉最稳，预算全部留给正文。

为什么 DeepSeek API 调用成功但返回空内容？​

思考模型的推理段与正文共享 max_tokens，预算被推理吃满后 finish_reason 返回 length、content 为空，且不抛任何异常。关闭 thinking 或按实测推理长度调大 max_tokens，排查时先看 finish_reason 再看异常日志。

磁盘清理时用 docker ps -as 巡检各容器可写层，etcd 容器赫然 385M——而它挂载的数据卷 etcd_data 里只有 8K。当时磁盘清理没敢动它：一旦 recreate，Milvus 的全部元数据就随可写层一起蒸发。

在开发 AI客服 时遇到此问题——7×24小时AI客服，快速解答产品使用问题；它的知识库检索跑在 Milvus 上，而 Milvus 的元数据全靠这个 etcd。

TL;DR​

compose 的 volumes: 只负责「把卷挂到容器某个路径」，应用往哪写由它自己的参数决定。etcd 没设 data-dir 时默认写到工作目录下的 default.etcd——挂载点 /etcd 它根本没用，385M 数据全在可写层，docker compose up -d 的任何一次重建都会把它带走。修复用 etcd 原生迁移路径：在线快照 → restore → 停机换数据 → 补 ETCD_DATA_DIR → 带卷重建，零丢失，全程停机不到两分钟。

问题现象​

compose 里的 etcd 服务看起来是「正确」的——卷挂了：

  etcd:
    image: quay.io/coreos/etcd:v3.5.5
    environment:
      - ETCD_AUTO_COMPACTION_MODE=revision
      - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379
      # ... 没有任何 data-dir 相关配置
    volumes:
      - etcd_data:/etcd

但两个数字对不上：

$ docker ps -as --format "{{.Names}}\t{{.Size}}" | grep etcd
rag-service-etcd-1   385MB (virtual 199MB)     ← 可写层 385M

$ docker exec rag-service-etcd-1 du -sh /etcd
8K    /etcd                                     ← 挂载的卷是空的

$ docker exec rag-service-etcd-1 ls -la / | grep etcd
drwx------  3 root root 4096 default.etcd         ← 数据在这：容器根目录

根因​

挂载 ≠ 使用。 volumes: etcd_data:/etcd 只保证「卷被挂到 /etcd 这个路径」，至于 etcd 往哪写，由它自己的 --data-dir 参数决定。etcd 的缺省 data-dir 是工作目录下的 default.etcd——这份 compose 既没设 ETCD_DATA_DIR 环境变量，也没传 --data-dir 命令行参数，于是 etcd 在容器根目录自建了 default.etcd，把全部数据写进了可写层。挂载点 /etcd 从第一天起就是空的。

这类「卷是摆设」最阴险的地方在于平时完全无症状：服务正常跑、数据正常读写、监控全绿。只有当你需要 docker compose up -d --force-recreate（换配置、回收可写层、迁移宿主机）的那一刻，可写层被整体丢弃，数据才消失——而那通常是你在做紧急运维、最不需要第二起事故的时候。

解决方案​

用 etcd 原生的快照迁移路径，在线快照保证一致性，短暂停机只出现在最后的数据切换。

步骤 1：在线一致性快照​

docker exec rag-service-etcd-1 sh -c \
  'ETCDCTL_API=3 etcdctl --endpoints=http://127.0.0.1:2379 snapshot save /tmp/etcd-snap.db'
docker cp rag-service-etcd-1:/tmp/etcd-snap.db /root/etcd-snap.db

snapshot save 对运行中的 etcd 是安全的（不走文件复制，走 Raft 后端快照），不停机、不锁写。

步骤 2：restore 成目标 data-dir 结构​

docker run --rm -v /root:/host quay.io/coreos/etcd:v3.5.5 \
  etcdctl snapshot restore /host/etcd-snap.db --data-dir /host/etcd-restored

restore 会生成带完整 member/ 结构的数据目录（快照本身不能直接当 data-dir 用）。

步骤 3：停机切换，数据入卷​

docker stop rag-service-etcd-1
rm -rf /var/lib/docker/volumes/etcd_data/_data/*      # 卷是空的，清掉挂载残留
cp -a /root/etcd-restored/. /var/lib/docker/volumes/etcd_data/_data/

步骤 4：补上缺失的配置，带卷重建​

  etcd:
    environment:
      - ETCD_DATA_DIR=/etcd        # ← 缺的就是这一行
      # ...
    volumes:
      - etcd_data:/etcd

docker compose up -d etcd    # 配置变更触发 recreate，新容器以卷为 data-dir

步骤 5：验证​

docker exec rag-service-etcd-1 etcdctl --endpoints=http://127.0.0.1:2379 endpoint health
du -sh /var/lib/docker/volumes/etcd_data/_data    # 数据应在卷里
docker ps -as | grep etcd                          # 可写层应回落到 KB 级

本次修复后：可写层 385M → 8KB，数据落卷 123M，上游 Milvus 自动重连、元数据读写正常。

常见问题​

Docker 挂载卷后目录是空的怎么回事？​

两种常见原因：一是空卷挂载遮盖了镜像内原有目录（Docker 的既有行为）；二是应用的数据目录参数根本没指向挂载点，数据写进了容器可写层——本文的 etcd 案例就是这种。用 du 分别看卷目录和容器可写层的大小，一眼可辨。

etcd 数据怎么安全迁移到新的 data-dir？​

etcdctl snapshot save 在线做一致性快照（不停机），etcdctl snapshot restore --data-dir 生成带 member 结构的目标目录，停容器后把数据放到新位置、以新 data-dir 启动，最后 endpoint health 加上游重连验证。全程停机只在切换那一段。

compose 里挂了卷为什么没生效？​

volumes: 只把卷挂到容器的某个路径；应用写哪里由它自己的配置决定——etcd 看 data-dir，postgres 看 PGDATA，redis 看配置文件里的 dir。挂载点和应用配置对不上，卷就只是个空目录，数据全在可写层，重建即丢。