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 或内容中心实现