达人推荐子系统技术设计（TDD）

版本：v1 草案 ｜ 2026-08-17 ｜ 作者：backend-dev ｜ 状态：待主会话评审（评审通过后才出表设计迁移与代码，本文只出设计）

上游输入：《推荐子系统 PRD》v1.1（docs/product/xijian-recommend-prd.md，产品定义）｜《推荐子系统业务册》v1.1（docs/business/xijian-recommend-biz.md，SOP 评分卡/分档/一票否决）｜ 基线 v2.1 §2/§5.1/§5.2/§5.3/§6.13/§7.1/§7.4/§12A（唯一口径源）｜ docs/dev/influencer-schema-design.md（特征的表来源）｜ docs/dev/jixing-api-notes.md（集星字段与四坑）｜ docs/dev/msgbridge-contract.md §2.1/§2.5（批次归因）｜ docs/xijian-architecture.md §4/§5/§9（架构约束）｜ 代码实况 server/app/domains/influencers/grade.py、domains/jixing/enrich.py、app/scheduler.py、domains/config_center/cache.py

纪律声明：本文不定义任何口径数字。凡判定阈值/权重/比例一律指向 cfg 键（§8）并注基线出处；SOP 未给到子项分值的地方，本文只出打分框架，分值标「初值待运营校准，走 cfg」。

---

1. 定位与边界

1.1 本文覆盖

评分引擎（五维映射/硬门槛短路/证据 schema/沉底与探索位，P1-6.4）｜ 估价引擎（双锚/距离分段/输出结构/冷启动，P1-6.5）｜ 特征流水线（快照库与标签库 schema 草案/刷新策略/指纹去重，P1-6.1~6.3）｜ C/C 飞轮（权重版本/校准批次/度量/切换回滚——三期主体，P1 只建表与报表）｜ 归因链路（wcid→邀约→报名→履约，P1-6 + P1-11.2 接口点）｜ 运行形态（进程内计算论证/调度清单/性能实测）。

1.2 本文不覆盖（边界，不动摇）

• 反选决策：永远人工（基线 §9.1 三不自动化第一条）。系统只产出清单 + 建议价 + 决策留痕接口，绝不自动发起邀约；采纳名单转 ②A 邀约需人工再确认（发送侧属 P1-11.2，走 msgbridge shadow-first）。
• console UI：清单页/评分卡/证据展开/分档色标归 P1-6.6（frontend-dev）。本文只定 API 返回结构。
• AI 内容理解（二期）：内容质量 30 分、定位清晰度 20 分、评论区真实性由豆包视频模型产出（PRD §10 二期）。本文只留维度插槽与状态位（pending_ai），一期不给分、不猜分（PRD §01「不输出伪判断」）。
• 视频指标序列的数据源契约：中台统一 API 包待用户侧统发（P1-6.3、确认记录 C4）。本文只定义特征字段契约与降级策略，不预设中台接口形状。
• 商单/结算域口径：达标判定、ROI/CPM 公式、结款流程复用既有域（基线 §7.4/§7.5），推荐域只读消费，不另立一套。

1.3 与已落地代码的衔接点（不重复发明）

---

2. 评分引擎设计

2.1 总流程（短路优先，省算力也省误导）

候选池（scope.outreach_scope 过滤旁类）
 → ① 轨道门槛 track_gate（粉丝/等级/招募价，按轨）→ ② 一票否决 hard_gates（命中即 blocked，不再算分）
 → ③ 五维打分（逐维出 score/status/证据）→ ④ 汇总 raw/coverage/normalized/tier
 → ⑤ 强制规则（配合度<6 或黑名单 → 不作主选）→ ⑥ 排序（blocked 出列 → sunk 沉底 → 分数降序）
 → ⑦ 探索位插入（cfg 比例，可复现随机）→ ⑧ 逐人挂建议价（§3）
 → ⑨ 落 recommend_batch / recommend_item + 特征快照（§4）

2.2 SOP 五维 → 特征映射表

满分列 = SOP 100 分表（基线 §5.3：定位 20 / 内容 30 / 数据健康 30 / 商业匹配 10 / 配合度 10），落 cfg recommend.weights.<track> 三套模板（PRD §4.2 三轨独立）。子项分值 SOP 未给，全部走 recommend.subscore.<dim> 的分段规则表，初值待运营校准。

降级源的坑（必须标注在证据里）：SOP 要的是中位数播放，集星只给稿均（均值）播放。均值被爆款拉高，与 SOP 的抗噪意图相反——一期用降级源时，证据项必须写 source.degraded=true, note="集星稿均，非中位数"，且该子项的分段表用独立 cfg 子键，序列到位后切换不影响历史快照可比性（快照存的是当时的 feature_version）。

2.3 一票否决硬门槛（短路实现）

gate 注册表 recommend/scoring/gates.py，每条 gate 返回 pass | blocked | manual | unknown 四态。unknown 绝不当 pass（数据源未接入不等于没问题，PRD §03 舆情源仍「评估中」）。

• 轨道门槛（PRD §4.2，与一票否决分开）：品宣 fans_count ≥ 20w、品效 item_level ≥ 6、团购 item_level ≥ 4 + 招募价约束 → cfg recommend.track_gates（基线 §5.1 有出处）。不过轨道门槛者不进本轨清单（不是 blocked，是不同轨的事）。
• 短路语义：任一 gate = blocked → 立即返回，不计算任何维度（省算力，且避免「85 分但不能选」的误导展示）；manual/unknown 不阻断打分，但在清单上以「待人工核对项」清单展示（基线 §6.13 判据 1「硬门槛不过者单列并注原因」）。

2.4 证据结构（参照 grade_evidence 先例）

一分一证据，落 recommend_item.evidence（JSON）。schema 草案：

{ "schema":"recommend.evidence.v1", "track":"effect",  // brand|effect|group
  "weight_version_id":12,        // champion 权重版本（可回放）
  "feature_version":"feat.v1",   // 特征口径版本（降级源切换时递增）
  "gates":[ {"code":"category_conflict","result":"pass","evidence":{...}},
            {"code":"violation_risk","result":"unknown","note":"舆情源未接入，不视为通过"} ],
  "dimensions":[
    {"code":"data_health","max":30,"score":24.5,"status":"scored","items":[
      {"code":"median_vv","value":12000,"score":8.0,"max":10,
       "rule":"cfg:recommend.subscore.data_health.median_vv_tiers",
       "source":{"type":"metric","field":"douyin_account_metric.video_avg_vv",
                 "fetched_at":"2026-08-17T03:00:00","degraded":true,"note":"集星稿均，非中位数"}} ]},
    {"code":"content_quality","max":30,"score":null,"status":"pending_ai"},
    {"code":"cooperation","max":10,"score":null,"status":"pending_human","note":"首次合作，SOP 明示待人工"} ],
  "raw_score":41.5, "coverage":0.6, "normalized_score":69.2,
  "tier":null, "tier_reason":"coverage 低于 recommend.tier_min_coverage，不给档位",
  "cfg_snapshot":{"recommend.tier_thresholds":{...},"recommend.tier_min_coverage":0.7} }

汇总口径：raw = Σ 已评维度得分；coverage = Σ 已评维度满分 / 100；normalized = raw / coverage。 分档裁决建议：分档基于 normalized，但 coverage < cfg("recommend.tier_min_coverage") 时不给档位，只标「证据不足」——不能拿 60 分可评满分里的 45 分冒充 75 档。该阈值初值待运营校准。分档线 85/75/65 有出处（基线 §5.3），走 recommend.tier_thresholds。

2.5 沉底、强制规则与探索位

• 低推荐沉底：influencer.grade == "low_recommend" 或 recommend_penalty_reason 非空（P0 已写入，基线 §2 CPM>80）→ sunk=true，只改排序不改分数（分数要可解释、可回测；改分会污染飞轮的相关性统计）。
• 强制规则（基线 §5.3）：配合度人工分 < cfg("recommend.cooperation_min_score") 或 influencer.blacklisted → not_primary=true，清单上明示「总分再高也不作主选」，同样只影响标注与排序。
• 探索位插入算法（PRD §4.3、§08 自我强化偏差刹车）：

探索候选池 = 过硬门槛 且 coverage < cfg("recommend.explore_coverage_max") 且 未履约
e_min/e_max = round(N * cfg("recommend.explore_slot_ratio_min|max") / 100)   # 强制下限/上限
e    = clamp(e_min, 0, min(e_max, len(候选池)))   # 候选不足可少，但必须回报实际比例
step = max(1, N // (e + 1))                      # 插入位 [step, 2*step, ...]，均匀分散不堆尾部
候选池内排序 = 以 md5(f"{batch_id}:{task_id}") 为种子的可复现打散（回放一致）

响应必带 explore_ratio_actual；候选不足导致低于下限时给出显式 note，不静默降配额（基线 §6.13 判据 2）。

---

3. 估价引擎设计

3.1 双锚公式（PRD §05）

建议上限 suggest_max = min(market_high, income_cap)                   # 取低
建议下限 suggest_min = min(max(base_fee, market_low), suggest_max)
income_cap = P30(预测产出) / (roi_target + 1)                          # roi_target 走 cfg

+1 不是魔法数字：基线 §7.4 定义 ROI = (GMV − 费用) / 费用，要求 ROI ≥ r ⟺ 费用 ≤ GMV/(r+1)。PRD §05 的例子（GMV 3,000、ROI≥2 → 上限 1,000）正是 3000/(2+1)。roi_target 取 cfg("settlement.explore_roi_min")（实探）/cloud_edit_roi_min/live_roi_min，按任务类型选，不另立推荐域自己的达标线。

3.2 行情锚（market anchor）

合成：market_x = Σ wᵢ·xᵢ，权重走 recommend.market_anchor_weights（初值待校准）。样本量不足即降权归零并重新归一（n < cfg("recommend.market_anchor_min_samples")），证据记 dropped_sources——不足样本的源静默参与是"用噪声当行情"。

3.3 收益锚（income anchor）

• 预测产出：该达人在同轨 + 同品类任务上的 GMV 样本，窗口 cfg("recommend.income_anchor_window_days")（建议初值 90，PRD §08 滚动窗口刹车）；样本条件：视频满 cfg("data.ramp_protection_days") 天（基线 §8 爬坡保护）、剔除鸽约（fulfillment_label.is_ghosted）。
• P30 实现：statistics.quantiles(samples, n=100, method="inclusive")[29]（stdlib，无需 numpy；本机实测 quantiles([1..10], n=10, method="inclusive")[2] == 3.7）。P 值走 cfg("recommend.income_anchor_percentile")（已有键，默认 30）。
• 分层回退链（每级记 fallback_level 进证据）：① 达人自身样本（n ≥ recommend.income_anchor_min_samples）→ ② 同层级（item_level）+ 同品类群体 → ③ 同轨全体 → ④ 收益锚缺席：只出行情锚 + 显式标注，绝不用默认值假装。
• 佣金点不进现金（基线 §7.1）——估价只算现金部分（车马费/自报价），契约测试要有断言。

3.4 距离与车马费分段

resident_city_code（集星直供，6 位行政区划码）→ 项目地城市 code（项目域字段；未接入前由请求参数传入）。距离方案三选一：① 城市质心 + Haversine 直线距离（静态 JSON，约 300 城）→ ✅ 一期采用，零外部依赖且精度对"几十公里粒度的分段"足够；② 城市码同城/省内/跨省三档——质心表缺城时的兜底分支；③ 地图 API 驾车距离——❌ 需外部 key 且增外呼，YAGNI。

• 分段表 cfg("recommend.travel_fee_distance_tiers") 已在种子占位为 []（基线 §12A「待运营给现行标准」）。为空时车马费项短路为 0 + 日志告警 + 证据标 base_fee_unavailable（与 grade.py 白名单空集短路同构），不猜数字。层级系数 cfg("recommend.travel_fee_level_coefficients") 同为待运营。

3.5 输出结构与冷启动降级

{ "schema":"recommend.price.v1", "suggest_min_fen":90000, "suggest_max_fen":110000,
  "binding_anchor":"income",     // 哪把尺子卡住了上限
  "market":{"high_fen":150000,"low_fen":80000,"sources":[...],"dropped_sources":["peer_dist"]},
  "income":{"p30_gmv_fen":300000,"roi_target":2,"cap_fen":100000,"sample_n":7,"fallback_level":1},
  "base_fee_fen":0, "base_fee_status":"unavailable", "confidence":"medium",  // 由样本量与回退级派生
  "quote_fen":150000, "quote_flag":"over_cap", "target_price_fen":110000,    // 「压价至 ¥X 或换人」
  "cfg_snapshot":{...} }

冷启动策略（PRD §10 一期「数据就绪即做」）：

---

4. 特征流水线

4.1 表 schema 草案（P1-6.1 建，本文只出设计）

命名与类型沿用达人域约定（influencer-schema-design.md §0）：无 xijian_ 前缀、金额列名带 _fen、比率 DECIMAL(10,4) 标度 0–1、多值 JSON、不建物理 FK。

① influencer_feature_current（当前特征，与账号 1:1，值变才写）

account_id BIGINT UNIQUE / window_days SMALLINT（默认 30，与 metric 表同口径）/ median_vv INT / vv_mad_ratio DECIMAL(10,4) / publish_cnt INT / max_gap_days INT / last_publish_at DATETIME / fans_count INT / fans_growth INT NULL（NULL=历史点不足）/ refund_rate、interaction_rate、fake_signal_score DECIMAL(10,4) NULL / item_density INT NULL（接单密度，PRD §03）/ source_map JSON（逐特征来源与degraded标记，证据要用）/ computed_at / fingerprint CHAR(32) / created_at / updated_at

② influencer_feature_snapshot（推荐时刻全量快照，append-only）

id / batch_id / influencer_id / account_id / track / features JSON / feature_version / source_map JSON / created_at，唯一约束 uq(batch_id, account_id)。

为什么两张表：current 是"最新值"（打分快取，高频刷新、值变才写）；snapshot 是"当时值"（回测地基，PRD §07「模型可换，特征快照库是不动产」）。合成一张会逼出"要么丢历史，要么每次刷新都写一行"的两难。快照不可变、不去重、不清理——它是资产不是缓存。

③ fulfillment_label（履约标签库，护城河本体）

id / order_id UNIQUE / influencer_id / account_id / task_id / track / deal_price_fen / gmv_fen / exposure / roi DECIMAL(10,4) / cpm_fen / refund_rate / is_ghosted / on_time_delivery / response_minutes / cooperation_score TINYINT(1–10 人工) / settled_at / label_version / fingerprint / created_at / updated_at

为什么物化而不是查商单视图：① 回测要冻结口径（商单表会随业务演进改列，标签要按 label_version 稳定）；② 跨库聚合（历史单在 lynoxi）成本高；③ 对外产品化时它就是精算数据集（PRD §01A）。写入方 = 商单/结算域的「已结算」事件（P0-5/P1-9），推荐域只读消费。

④ recommend_batch / recommend_item（清单与决策留痕）

• recommend_batch：id / task_id / track / requirement JSON（反选需求表单 SOP §2 四问）/ weight_version_id / candidate_count / explore_ratio_actual / created_by / created_at
• recommend_item：id / batch_id / influencer_id / account_id / rank / is_explore / gate_result / raw_score / coverage / normalized_score / tier / not_primary / sunk / evidence JSON / price_suggestion JSON / decision（adopted|skipped NULL）/ decision_reason / decided_by / decided_at，唯一约束 uq(batch_id, account_id)（基线 §6.13 判据 4 的落点）

4.2 数据源 → 特征的刷新策略

4.3 指纹去重与值变才写（铁律 3 的落地）

• feature_current：整轮特征值排序 JSON → md5 → 与库中比对，相同则整行不写（零 UPDATE、零 binlog）。手法与 enrich.py::_fingerprint 一致，指纹只覆盖本模块负责的列。
• feature_snapshot：不做值去重（快照必须每批都写），靠 uq(batch_id, account_id) 防重复生成。fulfillment_label：按 order_id upsert + 逐字段值变才写。
• influencer.recommend_index 回写值变才写，recommend_index_at 语义 = 变更时间（与 grade_at/layer_at 同构，不是"上次计算时间"）。

---

5. C/C 飞轮机制（三期主体，本文出地基）

5.1 权重版本管理

recommend_weight_version：id / track / role（champion|challenger|archived）/ version_no / weights JSON / subscore_rules JSON / derived_from_id / source（seed|challenger|manual）/ promoted_at / retired_at / note / created_by / created_at

每轨同时最多一个 champion + 一个 challenger（MySQL 无部分唯一索引 → 应用层保证 + ix(track, role)）。清单必记版本（recommend_batch.weight_version_id）让任何历史清单可回放。cfg 里的 recommend.weights.<track> 只是种子默认值；上线后权威值在版本表，cfg 仅在无版本行时兜底（避免两份真相）。

5.2 校准批次

recommend_calibration_batch：id / track / batch_no / window_start / window_end / champion_version_id / challenger_version_id / metrics JSON / sample_size / verdict（challenger_win|champion_win|inconclusive）/ applied_action（promote|rollback|none）/ created_at

• cfg("recommend.calibration_batch_k") 现为占位 "待确认"（str）。语义定义：连续 K 个 verdict=challenger_win 的批次才晋升。读到非数字 → 自动晋升链路整体短路（仍跑影子对比与度量，只是不晋升）+ 显式告警，与 grade.py 白名单短路同构。
• cfg("recommend.calibration_rollback_line") 同为占位：质量指标跌破该线自动回退上一版；未定案前同样短路（只告警不动作）。

5.3 效果度量（PRD §09 指标的可计算定义）

显著性护栏：任一指标样本 < cfg("recommend.metric_min_samples") → verdict=inconclusive，不下结论、不触发晋升/回滚（小样本噪声当信号是飞轮最容易犯的错）。季节作控制变量：按 window 同期对比，不跨季节直接比（PRD §08 分布漂移刹车）。

5.4 自动切换、回滚与限速

challenger 生成: ① 逐维 clamp 到 champion ± cfg("recommend.weight_change_limit_pct")（已有键，20）
                ② 归一化到总分 100  ③ 归一后二次校验，仍越界 → 拒绝该 challenger 并记原因
晋升: 连续 K 批 challenger_win 且 cfg("recommend.auto_promote_enabled")=1 → promote（旧版 archived）
回滚: 质量指标跌破 rollback_line → 自动回退上一版
告警: 连续回滚 ≥ cfg("recommend.rollback_alert_streak") → 冻结自动晋升 + 告警（人只在异常时介入）
审计: 每次 promote/rollback 一条 audit（action=recommend.weights.promote/rollback），走既有 audit()

步骤 3 的坑值得单独测：先 clamp 再归一是常见做法，但归一会把被压制维度的份额转嫁给其他维度，可能反而突破 ±20% 限速——必须二次校验，否则"限速"形同虚设。 shadow-first 同构：recommend.auto_promote_enabled 默认 0（只影子跑批、只出报表），与 msgbridge 三态门同一纪律——自动改权重是"重大影响结果的决策"（基线 §9.1 第 2 条）。

---

6. 归因链路（漏斗数据从哪来）

recommend_batch + recommend_item ─▶ 人工圈定（decision=adopted/skipped+可选原因，基线 §6.13 判据 4）
 ─▶ ②A 定向邀约（P1-11.2，人工确认后发起；契约 §2.1 的 send-miniprogram 返回 wcid，
     server 存 wcid ↔ (batch_id, influencer_id)，不新增任何接口）
 ─▶ 达人点卡片 ─▶ wcid 回流（架构 §6.2）─▶ influencer_binding.wcid/batch_id（P0 已建列）
 ─▶ 报名意向 ─▶ 商单（P0-5）─▶ 履约 ─▶ fulfillment_label（§4.1③）

与 P1-11.2 的接口点（必须对齐，否则漏斗断在这一段）：邀约批次需要能反查推荐批次。建议 ①邀约批次表加列 source_recommend_batch_id，或 ②统一批次号命名 rec:<recommend_batch_id>（msgbridge 的 note 已用 xijian:<batch_no> 作幂等标记，天然可承载）。推荐方案 ①（显式列，可索引），②作为消息台侧的可读兜底。此项需在 P1-11.2 开工前确认。

---

7. 运行形态

7.1 进程内计算（无独立服务、无向量库、无特征平台）

量级实测（本机 Python 3.12，纯 Python 五维 × 每维 5 子项分段查表 + 证据对象构造）：N=1,000 → 9.9 ms；N=6,660（当前达人量级，上游口径）→ 76.4 ms；N=20,000（达人广场采集 19,299 行量级，基线 §8 实测）→ 264.6 ms（单人 10–13 μs）。

结论：打分不是瓶颈，取数才是（一次批量拉 1e4 行特征表约数百 ms）。单次清单生成 p95 < 2s 完全可达，无需异步化、无需独立算分服务。

• 不上向量库：可解释加权评分是查表 + 加权求和，没有相似度检索需求；语义理解是二期 AI 的事，且那也是逐条打分不是召回。
• 不上特征平台：特征 ~15 个、日级更新、消费方唯一。Feast 之类的价值在"多消费方 + 在离线一致性"，两个条件都不成立（ADR：内部工具不做企业级预设计）。不引 numpy：分位数用 stdlib（§3.3 已验证），依赖表保持 10 个包不变。
• 复杂度解锁：PRD §07 —— 该轨履约标签 ≥1000 且分层后每层 ≥300 才上浅层统计学习。当前百级，不上模型。

7.2 APScheduler 任务清单（@scheduled 注册表模式，不改 app/scheduler.py）

调度纪律（APScheduler 进程内的两个真坑）：① 全部 job 显式 max_instances=1 + coalesce=True——特征刷新慢于间隔时会堆积并发，重复打集星接口触发反爬；② 单进程部署（systemd + uvicorn 单 worker）是当前形态，若将来多 worker 必须只在一个进程起调度器，否则 job 重复执行。写进 job 注册处的注释。

---

8. cfg 键清单

8.1 已有与复用（不新建，避免两份真相）

• 已在种子的 recommend.* 7 键（config_center/seed.py 实测）：explore_slot_ratio_min(10)、explore_slot_ratio_max(20)、income_anchor_percentile(30)、weight_change_limit_pct(20)、travel_fee_distance_tiers([] 占位)、calibration_batch_k(待确认)、calibration_rollback_line(待确认)
• 跨域复用 8 键：data.ramp_protection_days（取数窗口）｜settlement.explore_roi_min/cloud_edit_roi_min/live_roi_min（收益锚 roi_target 与达标度量）｜settlement.explore_cpm_max（达标度量）｜grade.cpm_low_recommend_threshold（沉底，经 P0 分级结果间接消费）｜grade.travel_category_whitelist（品类匹配）｜ark.daily_request_limit（二期 AI 成本闸）

8.2 本文新增设计（29 键，P1-6.1 随迁移落，全部注 baseline 出处）

计数：新增 29 键（编号 1–29）。其中 14 键无可用初值（4/5/6/8/13/14/15/16/17/18/19/21/26/28）→ 一律以 value="待确认"（str）占位入种子，依赖它的判定短路 + 告警，不编默认值（沿用 recommend.calibration_batch_k 与 grade.travel_category_whitelist 的先例）；#10 键本身有默认值，仅其第 6 条 gate 待确认；#1–3 以 SOP 五维满分为初值（有基线出处），三轨差异待校准。

---

9. P1-6 任务映射与实现顺序

模块布局（单模块 ≤200 行有效代码，机检）：

app/domains/recommend/
├── router.py / schemas.py（清单生成、决策留痕、单人评分卡）｜ service.py（批次编排：候选→打分→估价→落库）
├── scoring/{engine,gates,dimensions,evidence}.py ｜ pricing/{engine,market_anchor,income_anchor,distance}.py
├── features/{build,refresh,snapshot}.py ｜ flywheel/{attribution,challenger,promote}.py
└── data/city_centroid.json（静态城市质心，§3.4）

---

10. 开放问题与上游缺口

G1/G2 已裁决（主会话拉 SOP 原文核对，2026-08-17）：G1——硬门槛六条以 SOP 原文为准（5=拒绝复盘、6=承接条件缺失），"云剪短片号 pass"属 §4 三分钟初筛规则，作为独立的预筛 gate 类别注册（不占硬门槛六条）；PRD 该处归类错误待修。G2——评分表就是五项，"六维"是 §5 数据观察维度（数据健康度 30 分的子观察项），权重模板按五项落地，基线 §5.3 已同步修正。（不自补，报告上游）

---

附：信息来源

• docs/product/xijian-recommend-prd.md v1.1 §01–§10 ｜ docs/business/xijian-recommend-biz.md v1.1 §01/§03/§04/§05/§06 ｜ docs/business/xijian-business-baseline.md v2.1 §2/§5.1/§5.2/§5.3/§6.13/§7.1/§7.4/§8/§9.1/§12A
• docs/dev/influencer-schema-design.md §0/§2.2/§2.3/§4/§7 ｜ docs/dev/jixing-api-notes.md §1/§2/四坑 ｜ docs/dev/msgbridge-contract.md §2.1/§2.5 ｜ docs/xijian-architecture.md §4.1/§5.2/§5.4/§6.2/§7/§9 ｜ docs/dev/execution-plan.md P1-6
• 代码实况：server/app/domains/influencers/grade.py（证据+cfg_snapshot+短路先例）、domains/jixing/enrich.py（fingerprint 值变才写）、app/scheduler.py（@scheduled 注册表）、domains/config_center/{cache,seed}.py（cfg 语义与 7 个 recommend 种子键）、app/models/douyin_account.py（metric 字段）
• 性能数据：本机实测（Python 3.12，uv run python 跑纯 Python 打分基准，N=1000/6660/20000 → 9.9/76.4/264.6 ms），分位数 API 验证 statistics.quantiles([1..10], n=10, method="inclusive")[2] == 3.7

变更记录