# PRD 与技术规划专项专家评审报告（2026-03-24）

- 报告版本：v1.0
- 评审对象：`docs/` 下 PRD、供应侧产品设计、技术架构与执行门禁相关文档
- 评审专家视角：产品、架构、安全、测试、结算
- 评审方法：一致性审查、闭环性审查、最小功能粒度审查（含按钮级检查）

---

## 1. 执行结论

### 1.1 是否符合行业最佳实践能力

**结论：部分符合（可评估为 72/100）**

已达标项：
1. 已形成 SSOT + 门禁 + 任务 + 验收用例 + 决议模板链路（subapi 集成域）。
2. 凭证边界红线（M-013~M-016）已制度化，具备 P0 阻断口径。
3. 运维可靠性有明确回滚目标（10 分钟触发、30 分钟恢复）。

未达标项：
1. 供应侧核心商业参数仍存在多口径冲突（会直接影响计费结算一致性）。
2. 供应侧核心功能没有被纳入与 subapi 同等级的 Gate/测试闭环。
3. 数据库方言与主技术栈（PostgreSQL）不一致，存在可执行性风险。

### 1.2 功能设计是否闭环

**结论：subapi 集成域闭环较完整，供应侧交易域闭环不完整（综合 68/100）**

### 1.3 功能清单是否细化到最小可细化（按钮级）

**结论：未达到（42/100）**

当前文档主要到“模块/流程/API”层，尚未下钻到：
1. 页面级字段定义（必填、校验、默认值）。
2. 按钮级交互定义（可见性、禁用态、点击后状态迁移）。
3. 空态/错误态/权限态矩阵。
4. 前端交互与后端状态机一一映射。

---

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

## 2.1 P0-01：供应侧结算参数多口径冲突，存在错账风险

### 证据

1. `采购折扣系数=60%`：
   - `docs/business_model_profitability_design_v1_2026-03-18.md` 第11行、第23行。
2. `采购折扣系数=0.85`：
   - `docs/supply_side_product_design_v1_2026-03-18.md` 第135行。
3. `供应方收益=60%`：
   - `docs/supply_feature_technical_analysis_v1_2026-03-18.md` 第189行。
4. SQL 示例按 `85/15` 分账：
   - `docs/supply_detailed_design_v1_2026-03-18.md` 第842行、第843行。

### 影响

1. 报价、结算、财务预测口径不一致，无法形成可审计账务链路。
2. 同一交易在不同服务中可能产生不同收益分配结果。

### 处理建议

1. 立即冻结单一分账公式（建议以 v4.2 SSOT 指定口径为准）。
2. 统一改写 PRD/产品/技术/SQL 示例并加“版本生效日期”。
3. 将分账公式纳入 Gate（若口径不一致直接阻断发布）。

---

## 2.2 P0-02：供应侧主流程未纳入可执行 Gate 闭环

### 证据

1. 供应侧流程已定义为核心业务：
   - `docs/supply_side_product_design_v1_2026-03-18.md` 第42-68行、第155-164行。
2. 两周执行任务单以 subapi 集成为主，未形成 `SUP-*` 类型执行任务：
   - `docs/subapi_integration_risk_controls_execution_tasks_v1_2026-03-17.md` 第48-124行。
3. 门禁有供应侧指标（M-011/M-012），但缺少与之绑定的可复跑测试用例与任务映射：
   - `docs/acceptance_gate_single_source_v1_2026-03-18.md` 第32-33行。

### 影响

1. 供应侧“入驻-验证-上架-交易-结算-赔付”无法被发布门禁真实拦截。
2. “文档有流程、执行无证据”的治理断层持续存在。

### 处理建议

1. 新建 Workstream `SUP`（入驻、挂载、定价、订单、提现、赔付、争议）。
2. 对 M-011/M-012 补齐测试用例与证据路径（对应 `tests/supply/*`、`reports/supply/*`）。
3. 将供应侧闭环纳入 EXP-006 决议硬门槛。

---

## 2.3 P0-03：供应侧关键 SQL 示例存在明显错误，可能误导实现与报表

### 证据

1. SQL 中使用未定义别名 `su`：
   - `docs/supply_detailed_design_v1_2026-03-18.md` 第838行、第840行、第851行。
2. `supply_packages` 与 `supply_usage_records` 的关联条件可疑（`package_id` 对 `supply_account_id`）：
   - `docs/supply_detailed_design_v1_2026-03-18.md` 第870-873行。

### 影响

1. 直接复制执行会失败或产生错误统计。
2. 收入与消耗报表可能出现错误聚合，影响结算与决策。

### 处理建议

1. 将 SQL 示例转为“可执行 SQL + 单元测试样例”。
2. 在文档中标注示例执行环境与校验结果（通过/失败）。

---

## 2.4 P1-01：数据库方言与主技术栈冲突（PostgreSQL vs MySQL）

### 证据

1. 主栈明确为 PostgreSQL：
   - `docs/technical_architecture_optimized_v2_2026-03-18.md` 第14行。
   - `docs/test_plan_go_aligned_v1_2026-03-18.md` 第5行、第70行。
2. 供应侧 DDL 仍为 MySQL 方言：
   - `docs/supply_detailed_design_v1_2026-03-18.md` 第198行（`AUTO_INCREMENT`）。
   - `docs/supply_detailed_design_v1_2026-03-18.md` 第237行（`ON UPDATE CURRENT_TIMESTAMP`）。
   - `docs/supply_detailed_design_v1_2026-03-18.md` 第379行（`STORED` 生成列语法差异）。

### 影响

1. DDL 无法直接在目标数据库执行，拖慢开发与验收。
2. 评审口径与实际实现环境脱节。

### 处理建议

1. 建立 `sql/postgresql/` 唯一 DDL 源。
2. 文档中的 SQL 一律引用该目录，禁止内嵌多方言片段。

---

## 2.5 P1-02：技术架构存在双基线冲突，实施团队易走偏

### 证据

1. 旧版架构默认重组件（Kong/Kafka/Istio）：
   - `docs/technical_architecture_design_v1_2026-03-18.md` 第67-74行。
2. 优化版明确 S0/S1 默认禁止这些组件：
   - `docs/technical_architecture_optimized_v2_2026-03-18.md` 第31-35行、第52-57行。

### 影响

1. 研发、运维、采购可能按不同架构执行。
2. 成本与复杂度不可控，影响交付节奏。

### 处理建议

1. 将 `technical_architecture_design_v1` 标记为“历史稿/不再执行”。
2. 在目录层设置“当前生效架构索引页”，避免误读。

---

## 2.6 P1-03：PRD 仍为评审稿，关键商业/产品决策未冻结

### 证据

1. PRD 版本标识为 `v0.1（评审稿）`：
   - `docs/llm_gateway_prd_v0_2026-03-16.md` 第3行。
2. 关键事项仍在“待决策问题”：
   - `docs/llm_gateway_prd_v0_2026-03-16.md` 第205-209行。

### 影响

1. 研发与测试难以对齐明确产品边界与发布目标。
2. 需求变更风险上升，迭代返工概率高。

### 处理建议

1. 输出 `PRD v1.0` 冻结稿（明确“已拍板项/未拍板项”）。
2. 每个 P0 功能绑定 `Requirement ID -> API -> Test Case -> Gate`。

---

## 2.7 P1-04：功能清单未细化到按钮/状态级，前后端联调风险高

### 证据

1. PRD 与供应侧文档主要是流程/模块级描述：
   - `docs/llm_gateway_prd_v0_2026-03-16.md` 第70-90行、第106-139行。
   - `docs/supply_side_product_design_v1_2026-03-18.md` 第222-253行。
2. 尚未看到“页面字段、按钮行为、禁用条件、错误提示、权限态”的结构化定义。

### 影响

1. UI 实现将依赖口头沟通，需求解释偏差概率高。
2. 测试无法编写页面级可执行用例（尤其异常态与权限态）。

### 处理建议

1. 为每个核心页面新增“按钮级规格表”。
2. 建立 UI 规格模板：按钮ID、触发条件、后端接口、成功态、失败态、审计事件。

---

## 3. 闭环性评估矩阵（专家联合结论）

| 业务域 | 需求定义 | 技术设计 | 执行任务 | 测试用例 | Gate/决议 | 结论 |
|---|---|---|---|---|---|---|
| Subapi 集成 | 完整 | 完整 | 完整 | 完整 | 完整 | 基本闭环 |
| 凭证边界治理 | 完整 | 完整 | 完整 | 完整 | 完整 | 基本闭环 |
| 供应侧交易闭环 | 中 | 中 | 弱 | 弱 | 弱 | 未闭环 |
| 前端交互（按钮级） | 弱 | 弱 | 无 | 无 | 无 | 未开始 |

---

## 4. 最小细化要求（按钮级）补齐清单

每个核心页面至少补齐以下 10 项：

1. 页面 ID 与目标用户角色。
2. 字段清单（类型、校验、默认值、脱敏规则）。
3. 按钮清单（主/次按钮、可见性条件）。
4. 按钮禁用条件（余额不足、权限不足、风控锁定等）。
5. 点击后状态迁移（loading/success/failed/retry）。
6. 错误码与文案映射。
7. 空态与异常态（无数据、网络异常、风控拦截）。
8. 审计事件（谁在何时做了什么）。
9. 埋点事件（转化漏斗、异常漏斗）。
10. 对应测试用例 ID（UI/E2E/API）。

---

## 5. 结论建议（GO 判定）

当前建议：**CONDITIONAL NO-GO（先补齐 P0/P1 后再复审）**

复审准入条件：
1. P0 全部关闭并有证据。
2. P1 至少完成“可执行不走样”的最低闭环（特别是按钮级规格和供应侧 Gate）。
3. 新版 PRD（v1.0）与技术规划 SSOT 互相引用且无冲突。