跳到主要内容

CC 评审结论（L3 §17–19）

总评​

第六部分忠实、克制、代码事实底盘扎实，迄今质量较高：缺口三联（授权字段/质量置信字段/消费确认）口径与 §13/§15/§16 完全一致，未冻结阈值/schema，无 FinBayes 残留，透明名一致。MCP 鉴权/sys_api_perms/证据表/配置位置均核验属实。但 2 处代码事实错误 + 1 处 L2 锚点错误（系统性）+ 来源表字段失准。

必修 blocking​

  • B1 §18 MonitorJob 定性反向错误：文档写「价格异动等监控」——实际 monitor_job.go 是 monitorWebsite/monitorDiscord：CountActiveSourcesByPlatform + 「过去1小时未收到 Website 新闻」报警 + 恢复通知 + Redis 去重（monitor:alert:sent，2h 不重复）+ Telegram。MonitorJob 恰是「来源静默/死源告警」，不是价格监控（DH 不做行情）；文档既错标用途、又把其本职覆盖的「来源异常告警」列为待补缺口，自相矛盾。→ 改：现行 MonitorJob 已覆盖来源静默/恢复 Telegram 告警（含去重防风暴）；缺口是统一进运营告警体系（失败率/成本/积压未覆盖）。
  • B2 §18 L2 锚点错位（系统性）：「运营可干预/质量可评估」验收实在 L2 §12「验收与评估标准」，非 §11（§11 是边界与优先级）。§18 标题与末段两处误引「L2 第十一节」；§9.5（:567）、§21 stub（:1023）同错。→ 全部改 L2 第十二节；建议对 L2 引用统一加「L2」前缀（bare 章号在 L2 与本文两套编号间歧义）。
  • B3 §17 来源表字段枚举失准：文档「source/status/category/std_config/tags」——实际 crawler_source_model_gen.go 字段为 source_no/source_name/platform/source_type/title/language/external_id/status/is_deleted/category_id/kol_id/std_config/tags/created_at；kol 表为 kol_name/organization/market/strategy_style/remark/status。「无授权/适用限制维度」缺口结论属实，但字段枚举须据实修正。

建议 non-blocking​

  • N1 §17 补一句：dn_mcp_api_key（入库）vs 采集侧凭证（yaml/env）存储位置差异，便于密钥管理不混淆。
  • N2 §18 处理质量行交叉引用 §13「低置信须独立字段」约束。
  • N3（核验通过）sys_api_perms = RBAC 后台菜单权限（module/action/api_path/perms/is_auth），MCP 校验 status=1 + expires + DailyLimit 属实。
  • N4 §18「标准化 LLM 累计上亿 token 级」量级未在只读核验中查证；若写入文档建议标「量级示意、以监控为准」，避免 stale 数字固化。
  • N5（核验通过）§19 配置位置 etc/yaml + llm_config/llm_provider 属实；重要度分层=战略可调参数承接白皮书，边界守得好。

亮点​

  • 缺口三联口径横跨 §13/§15/§16/§18 一致，各带 ADR-候选/WP 编号，对 §20–29 承接充分。
  • 诚实区分「现行已具备」vs「待补设计」（§17 授权模型明确待补；§18 逐行标真实/缺口）。
  • 边界纪律到位（阈值/加密/密钥/指标全留工程包）。
  • 承接 L2 §10「授权可控」准确（system-product-definition.md:382）。