lijiaoqiao/review/comprehensive_review_report_v3_2026-03-24.md

立交桥项目全面 Review 报告（2026-03-24）

• 报告版本：v3.0
• 评审日期：2026-03-24
• 评审范围：/home/long/project/立交桥 下 docs/、review/ 及交付物可验证性
• 评审方法：文档一致性审查、门禁可执行性审查、合规与安全交叉审查

---

1. 执行结论

结论：NO-GO（当前不可进入实施/发布）

阻断原因不是单点缺陷，而是“业务模型、合规红线、门禁证据”三者同时不一致。
尤其是以下新增硬约束未被吸收：

短期内，用户分享 token 只能分享给平台，不能直接分享给其他用户。

当前主方案仍为“用户A供给 -> 平台 -> 用户B购买/拿 Key 直用”的双边市场模型，与该约束冲突。

---

2. 关键发现（按严重级别）

2.1 P0-01：短期策略与核心业务模型冲突（直接阻断）

现象

多个核心文档把“用户对用户的 token/配额交易”作为当前主路径，不是“仅对平台共享”。

证据

• docs/llm_gateway_subapi_evolution_plan_v4_1_2026-03-18.md:223 定义 需求方（Consumer）。
• docs/supply_side_product_design_v1_2026-03-18.md:33 明确“供应方 -> 平台 -> 需求方”。
• docs/supply_side_product_design_v1_2026-03-18.md:159 需求方“浏览套餐/下单购买”。
• docs/supply_detailed_design_v1_2026-03-18.md:688 需求方“获取 API Key”。
• docs/business_model_profitability_design_v1_2026-03-18.md:15 明确“加价出售给需求方”。

影响

1. 与短期经营策略冲突，执行后会造成产品、运营、风控目标错配。
2. token 责任边界不清，用户争议和赔付责任上升。
3. 后续法务条款与用户协议难以闭环。

处理建议（必须先做）

1. 将短期模型改为 B2P（用户仅向平台共享），去除 C2C 交易语义。
2. 从 S0/S1 设计中下线“需求方选购套餐、需求方拿供应方来源 Key”流程。
3. 短期只保留“平台统一计费与平台统一调用凭证”。

---

2.2 P0-02：ToS 红线与商业主张自相矛盾（直接阻断）

现象

ToS 文档定义“账号共享禁令/转售禁令”为红线，但商业文档同时把“统购统销、加价转售”作为核心模式。

证据

• docs/tos_compliance_engine_design_v1_2026-03-18.md:107 R001 账号共享禁令。
• docs/tos_compliance_engine_design_v1_2026-03-18.md:108 R002 转售禁令。
• docs/business_model_profitability_design_v1_2026-03-18.md:26 “核心模式：统购统销（买断->加价出售）”。
• docs/supply_side_product_design_v1_2026-03-18.md:129 出售价公式明确加价。

影响

1. 规则引擎会阻断业务主流程，或业务主流程会违反规则引擎，二者必有其一失效。
2. 运营与法务无法建立统一执法口径。
3. GO/NO-GO 判定失真。

处理建议（必须先做）

1. 按供应商维度拆分可做/不可做模型，不再统一“统购统销”。
2. 未获法务书面放行前，禁止把“加价转售”写入默认商业主路径。
3. 将 ToS 红线映射到门禁表中的硬 Gate（见 P1-03）。

---

2.3 P0-03：法务结论与证据链未闭环，却出现“已拍板/可推进”表述（直接阻断）

现象

法务文档仍是“待确认”，但主基线与历史报告中已出现“已拍板/修复完成”语义。

证据

• docs/tos_legal_communication_plan_v1_2026-03-18.md:197 至 docs/tos_legal_communication_plan_v1_2026-03-18.md:202 多项法务事项未勾选。
• docs/tos_legal_communication_plan_v1_2026-03-18.md:216 文档状态是“沟通准备材料”。
• docs/llm_gateway_subapi_evolution_plan_v4_1_2026-03-18.md:409 对 S4 关键项标记“已拍板”。
• review/final_decision_2026-03-31.md:1 到 review/final_decision_2026-03-31.md:5 仍为空模板态。

影响

1. 决策链与证据链脱节，治理可信度不足。
2. 管理层看到“已修复/可推进”时存在误判风险。

处理建议（必须先做）

1. 把所有“已拍板”状态改为“待法务签署后生效”。
2. 引入法务签署文件路径作为发布硬门禁。
3. 复审报告只允许引用已存在证据，不允许前置写“预审结论”代替事实。

---

2.4 P1-01：关键参数与时间线存在多版本口径，SSOT 失效

现象与证据

1. 采购折扣系数冲突：

   • docs/llm_gateway_subapi_evolution_plan_v4_1_2026-03-18.md:396 = 60%
   • docs/supply_side_product_design_v1_2026-03-18.md:135 = 85%

2. 毛利率目标冲突：

   • docs/llm_gateway_subapi_evolution_plan_v4_1_2026-03-18.md:397 = 15-50%
   • docs/supply_side_product_design_v1_2026-03-18.md:136 = 15-30%

3. S0 周期冲突：

   • docs/llm_gateway_subapi_evolution_plan_v4_1_2026-03-18.md:110 = 12周（至 2026-06-08）
   • docs/supply_side_product_design_v1_2026-03-18.md:280 = 至 2026-04-30

影响

1. 商业测算、排期、人力分配无法统一。
2. 验收时“同项多口径”会导致争议。

建议

1. 将 supply_side_product_design 标记为“历史草稿/仅参考”或同步修正到 SSOT。
2. 以 acceptance_gate_single_source + v4.1 作为唯一定义来源。

---

2.5 P1-02：主技术栈宣称 PostgreSQL，但多处 SQL 仍为 MySQL 方言

证据

• docs/supply_detailed_design_v1_2026-03-18.md:193 AUTO_INCREMENT
• docs/supply_detailed_design_v1_2026-03-18.md:231 ON UPDATE CURRENT_TIMESTAMP
• docs/technical_architecture_design_v1_2026-03-18.md:821 ON UPDATE CURRENT_TIMESTAMP
• docs/security_api_key_vulnerability_analysis_v1_2026-03-18.md:245 AUTO_INCREMENT

影响

1. 文档驱动开发会直接生成不可执行 DDL。
2. 安全与账务演练无法在目标数据库复现。

建议

1. 建立 sql/postgres/ 唯一 DDL 仓，并在文档引用该目录。
2. CI 增加 SQL 方言 lint（禁止 MySQL 关键字进入 PostgreSQL 文档）。

---

2.6 P1-03：安全方案标准未统一（MD5 旧方案与 HMAC 新方案并存）

证据

• docs/security_api_key_vulnerability_analysis_v1_2026-03-18.md:176 使用 MD5 截断做 user_hash。
• docs/security_api_key_vulnerability_analysis_v1_2026-03-18.md:188 MD5 校验和。
• docs/security_solution_v1_2026-03-18.md:398 升级为 HMAC-SHA256。

影响

1. 开发团队不清楚该实现哪个版本，易引入弱实现。
2. 安全评审结论不可复现。

建议

1. 明确“已废弃”文档并打上禁用标记。
2. 安全标准集中到一个 security_ssot.md，其余文档仅引用。

---

2.7 P1-04：门禁与交付物可验证性不足（大量证据路径不存在）

证据

• 任务单引用了 tests/、evidence/、docs/compat/ 等产物路径：
  • docs/subapi_integration_risk_controls_execution_tasks_v1_2026-03-17.md:50
  • docs/subapi_integration_risk_controls_execution_tasks_v1_2026-03-17.md:148
• 当前仓库未发现这些目录：
  • /home/long/project/立交桥 仅含 docs/、review/、llm-gateway-competitors/
  • tests/、evidence/ 不存在

影响

1. 无法对“已完成/可发布”进行客观验收。
2. 现阶段更像“方案库”，不是“可执行工程仓”。

建议

1. 拆分“规划仓”与“实施仓”，或在当前仓新增真实工程目录。
2. 所有 Gate 必须附可复跑证据脚本和执行结果。

---

3. 本次审查对“短期 token 只可分享给平台”的专项结论

3.1 结论

当前文档基线不满足该约束。

3.2 必做改造（短期策略修订）

1. 将“需求方购买供应方套餐”改为“需求方购买平台标准化服务套餐”。
2. 去除“需求方获取 API Key（来源于供应侧共享）”语义，统一为平台颁发的租户级调用凭证。
3. 所有“供应方收益分账”先降级为“平台采购结算”，不对终端用户暴露供应方身份与份额。
4. 验收门禁新增硬指标：
   • direct_user_token_share_count = 0
   • consumer_receives_supplier_credential = false

---

4. 建议整改顺序（72小时内）

1. 24小时内：冻结并修订 SSOT（v4.1 + 验收门禁），删除/降级冲突条目。
2. 48小时内：输出法务签署版“可做/不可做矩阵”并回填 ToS 引擎规则。
3. 72小时内：补齐至少一套可执行证据（DDL校验、门禁脚本、回归记录）后再发起 GO 评审。

---

5. 复审准入条件（建议）

满足以下全部条件后，才建议从 NO-GO 转为 CONDITIONAL GO：

1. 短期策略已统一为“仅对平台共享”并完成全量文档替换。
2. 法务确认项全部闭环并有签署证据。
3. 关键口径（折扣、毛利、周期、SQL方言）单一来源且无冲突。
4. 至少一个端到端 Gate 具备可执行证据链（脚本 + 日志 + 报告）。

---

6. 评审范围说明

1. 本次未对 llm-gateway-competitors/ 中第三方开源项目做深度代码审计（规模过大且非当前自研基线）。
2. 本次结论基于项目仓内可见文档和可验证产物；对外部系统状态不做推断。