gaokao-volunteer-system/docs/P0_EXECUTION_TASK_BREAKDOWN_2026-06-22.md

# P0_EXECUTION_TASK_BREAKDOWN_2026-06-22

最后更新: 2026-06-22
状态词: P0 执行拆分文档
真相源:
- `docs/UPGRADE_EXECUTION_BOARD_2026-06-22.md`
- `product/PRD_UPGRADE_2026-06-21.md`
- `docs/PAGE_REDESIGN_CHECKLIST_2026-06-21.md`
- `docs/FIELD_MAPPING_AUDIT_FIRST_PROFILE_2026-06-21.md`

> 本文把 P0-1 ~ P0-4 继续拆成页面 / 接口 / 状态 / 埋点四类子任务，供产品、前端、后端和埋点实现直接认领。

---

## 1. 拆分原则

P0 只解决一件事：

> 让“首页 -> 审核 -> Step 1 补充 -> 审核结果分流”这条默认主线真实成立。

因此所有子任务都必须满足：

- 不把 Step 2-4 偏好字段拉进 P0
- 不把政策中心 / 同分段参考的完整产品化混进 P0
- 不把生产 readiness 问题混进 P0
- 不把“设计占位”误报为“能力完成”

---

## 2. P0-1 首页任务化 + 审核主 CTA 前置

### 2.1 页面子任务

1. 定义首页首屏结构
   - Banner
   - 任务清单
   - 主 CTA
   - 次 CTA
   - 最近审核结果 / 报告入口
2. 定义首页任务卡文案
   - 默认第一任务 = 先审核现有志愿方案
   - 第二任务 = 完善个人档案
3. 定义首页状态态
   - 未建档但可先审核
   - 已有最近审核结果
   - 已有报告
   - 查分阶段切换态

### 2.2 接口子任务

1. 明确首页是否直接复用现有落地页接口，还是新增工作台聚合接口
2. 如果新增聚合接口，最小返回需包含：
   - 当前阶段
   - 是否存在最近审核结果
   - 是否存在可查看报告
   - Step 1 是否已完成
3. 若先不新增接口，需明确定义首页由哪些现有接口拼装

### 2.3 状态子任务

1. 定义首页展示状态来源
   - `stage`
   - `intake_status`
   - 报告是否 ready
2. 定义“最近审核结果可用”的判定条件
3. 定义首页主 CTA 不受 `profile_minimum_complete` 阻塞

### 2.4 埋点子任务

1. 首页曝光
2. 主 CTA 点击
3. 次 CTA 点击
4. 最近审核结果入口点击
5. 报告入口点击
6. 首页任务卡点击分布

### 2.5 完成判定

- 首页第一主动作已固定为审核
- 首页不再把完整规划 / 生成方案置顶
- 未建档用户点击后可直接进入审核链路

---

## 3. P0-2 审核页最小闭环

### 3.1 页面子任务

1. 定义审核页输入结构
   - 现有方案说明 textarea
   - 上传附件入口
   - 初步想法输入
2. 定义最小约束区
   - 省份
   - 科目组合
   - 分数
   - 位次
3. 定义结果区结构
   - 风险等级
   - 问题数量
   - 核心问题 3 条
4. 定义分流区结构
   - 去冲稳保
   - 去补 Step 1
   - 去完整规划 / 报告

### 3.2 接口子任务

1. 盘点现有可复用输入承接
   - 已有 `existing_plan_summary`
   - 已有附件上传
   - 已有 Portal intake 提交接口
2. 定义审核提交最小 payload
   - `existing_plan_summary`
   - `candidate_province`
   - `candidate_subjects`
   - `candidate_score`
   - `candidate_rank`
3. 定义审核结果最小返回结构
   - `review_result_id` 或等价结果主键
   - `risk_level`
   - `top_findings[]`
   - `recommended_action`
   - `available_actions[]`

### 3.3 状态子任务

1. 定义审核页本地状态
   - idle
   - submitting
   - success
   - failed
2. 定义审核结果状态
   - 无结果
   - 有结果待分流
   - 已进入后续动作
3. 定义与现有 Portal `stage` 的关系
   - P0 可先不改订单六态
   - 审核页结果状态优先作为页面层状态，不强绑订单状态机

### 3.4 埋点子任务

1. 审核页曝光
2. 审核提交点击
3. 审核提交成功
4. 审核提交失败
5. 审核输入来源
   - 首页进入
   - 订单状态页进入
   - 报告页进入
6. 审核结果默认推荐动作曝光

### 3.5 完成判定

- 未完成完整档案的用户可提交审核
- 页面有输入区、最小约束区、结果区、分流区
- 审核结果不再是孤立说明文本

---

## 4. P0-3 Step 1 最小建档

### 4.1 页面子任务

1. 把现有四步资料向导重新切分为 P0 最小视图
2. 明确 Step 1 只显示：
   - 省份
   - 科目组合
   - 分数
   - 位次
3. 明确 Step 2-4 在 P0 只允许：
   - 隐藏
   - 或显示为后续增强，不阻塞当前提交
4. 明确“未填完整档案，也可以先审核”提示位

### 4.2 接口子任务

1. 复用现有 `/portal/{token}/info` 提交链路
2. 为 P0 明确最小建档 payload
   - `candidate_province`
   - `candidate_subjects`
   - `candidate_score`
   - `candidate_rank`
   - `mode=draft|submit`
3. 明确 P0 不要求提交：
   - `candidate_interests`
   - `target_cities`
   - `target_majors`
   - `university_preferences`
4. 评估是否需要给 `IntakePayload` 放宽提交校验，避免 P0 继续被“至少一个偏好字段”卡住

### 4.3 状态子任务

1. 定义 `profile_minimum_complete`
   - 四字段齐全 = true
   - 否则 false
2. 定义草稿保存成功状态
3. 定义回填来源
   - `order_intakes.payload_json`
   - `orders` 冗余字段

### 4.4 埋点子任务

1. Step 1 页面曝光
2. Step 1 草稿保存点击 / 成功 / 失败
3. Step 1 提交点击 / 成功 / 失败
4. Step 1 字段缺失分布
5. 从审核结果页跳来补 Step 1 的来源记录

### 4.5 完成判定

- Step 1 可独立保存
- Step 1 保存后可回填到审核页和报告页
- Step 2-4 不再是 P0 审核门槛

---

## 5. P0-4 审核结果分流

### 5.1 页面子任务

1. 定义审核结果分流卡片
   - 推荐去冲稳保
   - 推荐补充 Step 1
   - 推荐进入完整规划 / 报告
2. 每个动作附适用说明
3. 明确默认推荐动作展示位

### 5.2 接口子任务

1. 定义分流动作枚举
   - `go_cwb`
   - `go_step1`
   - `go_full_plan`
2. 定义审核结果返回里的推荐动作字段
3. 若暂不存正式结果对象，先定义轻量动作记录结构

### 5.3 状态子任务

1. 定义 `review_entry_source`
   - home
   - status
   - report
   - direct
2. 定义 `review_followup_action`
   - cwb
   - step1
   - full_plan
   - none
3. 定义“已分流”与“未分流”判定

### 5.4 埋点子任务

1. 审核结果曝光
2. 默认推荐动作点击
3. 冲稳保入口点击
4. Step 1 补充入口点击
5. 完整规划 / 报告入口点击
6. 分流后返回率 / 流失率

### 5.5 完成判定

- 审核结果页至少存在一个默认推荐动作
- 三条分流路径都能进入对应目标页
- 分流动作可以记录和回放来源

---

## 6. 跨 P0 公共子任务

### 6.1 页面公共任务

1. 统一“审核优先”文案
2. 统一 Step 1 与后续增强的边界提示
3. 统一首页 / 审核页 / 档案页 / 结果页的跳转关系

### 6.2 接口公共任务

1. 统一最小字段命名
2. 统一审核输入、Step 1 保存、审核结果分流的数据承接方式
3. 统一是否新增聚合接口还是复用现有 Portal 接口

### 6.3 状态公共任务

1. 统一 `stage`、`intake_status`、页面层审核状态之间的关系
2. 保持订单 6 态不被 P0 页面状态污染
3. 把审核页/结果页状态定义为页面域状态优先

### 6.4 埋点公共任务

1. 统一页面来源字段
2. 统一动作枚举
3. 统一漏斗口径
   - 首页 -> 审核页
   - 审核页 -> 结果页
   - 结果页 -> 分流动作
   - 分流动作 -> 后续页面

---

## 7. 当前阻塞与先行修正点

### 7.1 现有实现与 P0 口径冲突点

1. `IntakePayload` 当前 `mode=submit` 只要求 Step 1 最小建档字段：
   - `candidate_province` / `candidate_score` / `candidate_rank` / `candidate_subjects`
2. `candidate_interests` / `target_cities` / `target_majors` / `university_preferences` 已不再是提交阻塞条件
3. 现有资料向导已统一为“五步资料向导”，Portal `stage` 仍围绕支付 / 补资料 / 交付状态，不含审核结果分流语义


### 7.2 必须先澄清的决策

1. P0 是否直接复用当前 `/portal/{token}/info`，还是新建独立审核页提交接口
2. `candidate_province` 是否进入 Step 1 主提交链，而不是只停留在下单阶段
3. 审核结果对象是先做轻量页面结果，还是先建独立持久化对象

---

## 8. 下一步建议

1. 基于本文继续输出《P0 最小接口变更清单》
2. 基于本文继续输出《报告版本与档案版本关系说明》
3. 在接口清单确定前，不要开始拆 Step 2-4 或内容中心实现