跳到主要内容

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

总评​

不建议直接作 §20–29 实现依据。主线承接 L2 对，但几处「现行事实」写过头或写错：密钥存储、MonitorJob 性质、配置驱动、运行量级/成功率。先修这些，否则后续 ADR/任务包/验收基于错误前提。

必修 blocking​

  1. §17 凭证「按部署环境安全存储」与代码冲突：server/etc/config.railway.prod.yaml 含明文 Bot token / Google API Key / proxy 凭证 / JWT secret；不能写「已安全存储」，应写「目标迁环境变量/密钥管理；现行存在明文配置风险」。
  2. §18 「MonitorJob（价格异动等监控）」不属实：monitor_job.go 只监控 Website/Discord 是否长时间无新闻并发 Telegram 告警；是抓取源活性/停滞监控，非价格监控。
  3. §19 「全部走配置、不硬编码」非现行事实：monitor_job.go 写死 1h/2h/12h，push_log_model.go 写死 retry_count<3，cron_manager.go 有 @every 60s。应写「目标配置化；现行仍有硬编码待迁移」。
  4. §18 量级/效果断言缺证据：「累计上亿 token」「推送成功率高」非代码事实；需 DB 快照锚点，否则删/改「可统计」。
  5. §18 引 L2「第十一节验收」不准：验收在 L2 §12，§11 是边界与优先级。

建议 non-blocking​

  1. §17 来源表无授权字段属实；但现行另有 dn_source_eval_flag.eval_eligible（评测放行白名单/安全闸门，≠完整私域授权模型），宜补一句。
  2. §17 MCP/sys_api_perms 口径准确（dn_mcp_api_key status/expires_at/daily_limit；sys_api_perms 后台权限非资产隔离）。
  3. §18 「人工干预：sys_operation_log 一带」太虚：该表 user/module/action/api_path/status，不表达复核/阻断/重试业务状态；应写「后台操作证据底表，干预语义待工作台/状态机补齐」。
  4. §18 消费确认/反馈缺口正确（push_log 无确认/反馈字段；webhook 只返回 received）。
  5. §20–29 还缺 4 个可落地决策：授权模型落字段还是独立表、消费确认/反馈对象、密钥与配置迁移边界、可观测最小指标口径。

亮点​

  1. §17 用户金融执行凭证 vs 采集侧凭证分开，边界正确。
  2. §18 证据底表列举扎实（llm_call_log/translate_call_log/push_log/operation_log）。
  3. §19 不冻结 schema/阈值的写法对；把「现行已配置化」降为「目标/待迁移」即可。