# CP-01 · 负责人不在，工作就停了。先做自动化就行吗？

账号保护请求依赖某一位负责人。如果这件事由我负责，先确认什么、留下什么记录、如何交给开发与运营？从公开案例出发，用示例议题CP-01走完受理到发布后复盘。

## D01 · 需求受理记录

- **议题**: CP-01 · 负责人缺席时的账号保护请求交接
- **现象 → 目的**: 请求和依据集中在个人手里 → 接手人能用同一份资料继续处理
- **初步方案**: 按请求集中查看资料、负责角色和进度
- **先索取的资料**: 延迟请求、正常完成请求和现行临时处理办法
- **预期变化**: 减少等待和重复确认，以每笔请求的耗时和确认次数检查

满足这些条件再往下走: 与运营确认问题和业务边界一致，再跟踪当前流程。识别规则、请求页面和审批业务分别界定。

## D02 · 现行业务流程表

- **受理**: 运营登记请求、对象和资料；缺项退回补充
- **审核**: 审核人员核对依据和适用规则；确认替代负责人的安排
- **审批**: 审批人员确认对象及操作范围，并关联审核版本
- **执行与确认**: 执行人员查询逐个对象的结果；客服据此答复
- **重复工作候选**: 单独发消息、追问进度、重新录入手工清单

满足这些条件再往下走: 把输入、工作、记录、下一位和退回条件连接起来，再确定测量区间。

## D03 · 数据申请与指标定义

- **统计单位**: 请求按一笔统计；账号误操作另按账号统计
- **处理时长**: 受理到逐对象结果确认；未完成请求单列
- **分段等待**: 资料补充、审核、审批、结果查询分别记录
- **工作负担**: 每笔请求的实际操作时间、重复询问和重复录入次数
- **比较条件**: 统一请求类型、范围和期间定义，同时报告数量和缺失情况

满足这些条件再往下走: 与运营、数据负责人确认定义及原始记录核对结果，再针对已确认的瓶颈比较方案。

## D04 · 方案比较与范围决定

- **A · 连接现有体系**: 优先评估；确认变更记录和替代负责人支持
- **B · 新建审批箱**: 暂缓；现有工具无法满足控制要求时再比较
- **C · 自动判断执行**: 另立议题；验证准确性、误操作、恢复和成本
- **本次范围**: 请求查询、交接、审批范围核对、结果关联
- **确定范围所需信息**: 开发说明结构限制与改动规模；运营指出可终止的手工作业

满足这些条件再往下走: 保留选择、排除理由和重新评估的条件，把将来可能做的事从本次需求中分开。

## D05 · 合规确认与设计映射

- **C-01 · 处理目的**: 处理依据与账号保护目的核对 → 隐私负责人确认 → D07字段
- **C-02 · 查看范围**: 运营、审核、审批、执行角色的最少信息 → 权限表与查看记录
- **C-03 · 保存删除**: 原始资料、审核版本和操作历史分别确认目的、期限及删除责任
- **C-04 · 复核恢复**: 客服查找操作记录的路径及恢复权限 → 运营流程
- **答复记录**: 问题、确认角色、答复日期、决定及对应文档版本

满足这些条件再往下走: 每项答复对应到设计修改。未确定的内容影响执行权限或必要数据时，暂缓确定该功能。

## D06 · 状态转换与异常定义

- **R-01 · 补资料后审核**: 运营补齐必要资料；记录审核角色和接收时间
- **R-02 · 审核后审批**: 将对象、操作和依据固定为审批人查看的版本
- **R-03 · 审批后变更**: 返回复核；保留变更前后及原审批历史
- **R-04 · 响应丢失**: 先查询逐对象结果，再判断已确认未处理的对象是否重试
- **关联测试**: R-01→T-01，R-02→T-02，R-03→T-03，R-04→T-04

满足这些条件再往下走: 明确各状态允许和禁止的操作、负责角色、记录与异常分支后，再细化页面。

## D07 · 页面字段与按钮说明

- **顶部信息**: CP-01、状态、负责角色、最近变更时间和交接角色
- **对象与依据**: 脱敏对象、资料引用、确认时间和规则版本
- **审批区域**: 批准版本v1与当前版本v2并列，突出范围变化
- **操作按钮**: 检查角色、状态和资料条件；说明不可用原因和下一步
- **等待与错误**: 结果查询、重复操作防护、逐对象结果和恢复路径

满足这些条件再往下走: 产品、设计、开发用同一请求走遍状态，补齐遗漏页面与提示后固定交付版本。

## D08 · AI任务与修改记录

- **输入与委托**: CP-01及最新D01～D07；查找冲突、异常与测试候选
- **审查示例①**: 批准后执行 → 当前对象和操作仍与批准版本一致时执行
- **审查示例②**: 失败后重试 → 响应丢失先查结果，再判断确认未处理的对象
- **修改理由**: 落实R-03、R-04，防止扩大审批范围和重复操作
- **实际使用时记录**: 工具、时间、输入版本、原文位置、采纳/修改/排除理由和复核人

满足这些条件再往下走: 将建议与原始资料对照，由对应负责人确认决定，再同步更新需求和测试。

## D09 · 开发交付与决定记录

- **R-01 补充资料**: D06状态转换 ↔ D07必要资料区域 ↔ T-01资料缺失
- **R-03 对象变更**: D06返回复核 ↔ D07版本比较 ↔ T-03执行阻断
- **R-04 响应丢失**: D06结果待确认 ↔ D07结果查询 ↔ T-04防重复操作
- **决定示例**: v1批准A/B后新增C，因批准范围改变而返回复核
- **未决问题**: 问题、负责角色、目标日期、影响范围及开始开发的前提

满足这些条件再往下走: 就交付范围和未决事项处理达成一致，固定版本；后续变化记录版本和影响项。

## D10 · 测试场景与缺陷记录

- **T-03 前提**: 请求CP-01，已批准v1对象A/B，拥有执行权限的角色
- **步骤**: ①新增C ②保存生成v2 ③尝试使用旧审批执行
- **预期**: 返回复核、阻止执行，显示新增对象C和下一审核角色
- **实际结果栏**: 待测试；执行时填写观察结果、环境版本、时间和证据
- **回归范围**: 未变更v1的正常执行、驳回后重提、响应丢失后的结果查询

满足这些条件再往下走: 保留逐需求测试结果、未解决缺陷的影响及复测证据，再决定发布。

## D11 · 发布、恢复与运营接收记录

- **发布前**: 政策与权限确认、需求版本、QA证据及未解决缺陷
- **发布后**: 角色访问、请求交接、批准版本比较和逐对象结果查询
- **停止条件**: 越过批准范围、重复操作、无法追踪结果等关键控制失效
- **恢复顺序**: 停止新执行 → 核对进行中结果 → 切回受理路径 → 判断账号恢复
- **结束旧工作**: 完成对照和运营接收后，停止单独手工传递并记录责任人

满足这些条件再往下走: 分别确认功能发布、运营接收、旧工作结束，再指定结果检查的时间和负责角色。

## D12 · 结果复盘与后续议题

- **起点问题**: 请求和依据依赖个人，导致交接与进度确认反复发生
- **保留的决定**: 优先连接现有体系；审批范围改变则复核；重试前核对结果
- **检查指标**: 按D03比较处理/操作时间、重复询问、录入、误操作与恢复
- **测量结果栏**: 测量后填期间、数量、前后值、缺失与解释；例子不含实测业绩
- **下一决定**: 改善→保留流程；停滞→调查剩余等待；副作用→缩小范围并恢复

满足这些条件再往下走: 检查接手人能否从D01追到D12，每个未完成事项都有负责角色和下一次确认时间。

## AI requests

### 1 · 先统一词语和范围

```text
这次只看CP-01从资料检查到提交审批的区间。
节点指一个框，节点名指标题，节点说明写检查内容，分支标签写在线上。
资料是否齐全与是否获批分开检查。
先用开始、条件、处理、下一步说明你的理解，暂时不要改页面。
```

### 2 · 确认后只改一个区间

```text
按刚确认的流程修改资料检查区间，审批后的部分保持不变。
节点包含名称和说明，分支结果贴在对应连线上；结果相同才合流。
统一节点尺寸、间距和起始高度，连线不要穿过框和标签。
修改后检查实际画面的开始、分支、合流和下一阶段连接。
```

### 3 · 追问遗漏的条件

```text
为什么把所有查询失败都画成结束？
区分可用已确认资料继续处理和缺少必要资料必须暂停的情况。
分别写出提示文案、下一负责角色和留下的记录。
将确认后的规则同步到设计说明与相关测试。
```

Source: https://www.intelligencelabs.tech/310dadb5-6b2f-811e-9e46-f4b1ddfe6b93

https://wekeylab.com/guides/account-protection-workflow/zh/