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

“请做自动化”不能直接交给开发。

Nexon的公开案例介绍了通过连接现有系统与审批流程，减少账号保护工作中的人工交接和特定人员依赖。我要处理的议题是：让另一位有权限的同事，也能根据已有资料把请求继续处理下去。

我会先用一页写清现象、目的、系统修改方案和预期效果。每项修改都要对应一个具体问题，预期效果旁边写上上线后要看的指标。

现象

本方案假设请求和判断材料散落在不同地方，需要重复解释，还要另问处理状态。

目的

减少交接和确认进度的时间，同时检查错误账号操作是否增加。

系统修改

在同一请求中关联资料、审核、审批和执行结果。现有审批工具满足条件时，优先连接。

预期效果

减少等待和返工。分别观察总耗时、实际操作时间、复核、误操作和恢复情况。

这次范围是保护请求的交接与处理流程。重新制定检测规则，或让AI最终判定账号是否正常，另开议题验证，不一起塞进来。

收到的需求是“负责人不在就处理不了，能不能自动化”。我先要一笔最近停住的请求，确认是谁要做什么、卡在哪里，再列功能。客户受到的影响和运营重复做的工作分开记录。

受理记录要写清提出需求的角色、发生时间、业务范围、重复情况、临时处理方法，以及期望完成日期和原因。这个例子编号为CP-01，先改善请求交接，账号识别规则另立议题。

只知道慢，还不知道该改哪里。

找运营同时看正常结束、暂停和失败的请求。沿着接收、补资料、开始审核、审批、执行、确认结果的顺序追踪。一个请求里的多条消息不能算成多个独立请求。

假设一项请求从接收到结束用了6小时，实际检查只用了10分钟。我会先查剩下的5小时50分钟花在哪里：找不到负责人、缺资料，还是等审批？原因不同，修改方案也不同。如果卡在审批，就在保留必要控制的前提下改善流转和等待。

• 运营：反复询问的信息、负责人缺席时的交接方式、旧手工清单的用途。
• 开发：现有请求、审批、账号状态、执行记录能否连接。
• 安全与隐私负责人：规则责任人、查阅范围、保存与删除标准、用户复核途径。

文档先用运营和开发都能理解的业务名称：请求状态、批准范围、执行结果。实际连接哪些数据库字段和API，再与开发核对现有系统后确定。

进入下一步的条件：现有流程、责任角色、所用资料和未确认事项已经放在同一份工作文档里。

我会一起看正常完成、负责人缺席导致延迟、资料不足被退回的请求。沿着实际页面和交接记录走一遍，对照文档里的流程与真正的处理顺序。

每一步都问清楚：资料由谁产生、在哪里确认收到、下一位如何知道、缺席时由谁接手、哪些内容重复录入。说法不一致时，留下要核对的请求和负责角色，再用记录确认。

先把等待时间和操作时间分开。

处理时间长并不能直接说明该改哪里。我会索取受理、开始审核、审批、执行和结果确认的时间点，并单独记录人工操作时间，区分等待资料、排队审批和执行耗时。

数据申请写清统计期间、请求类型和纳入条件。同一请求产生五条消息，仍只算一笔请求。未完成请求要单独统计数量和当前等待时间，否则最慢的请求反而被排除。记录能证明的原因与访谈中的解释也分开保留。

拿到数据后，抽取部分记录与原始资料核对。缺失的时间点列入新增采集项。下面定义的是要索取的数据，而不是已经测出的效果。

加了功能以后，原来的工作减少了什么？

我把连接现有请求与审批工具、新建请求界面、自动判断并执行三种方案摆在一起，分别列出会消失和仍然保留的工作。

CP-01先考虑连接现有体系。另建一个审批箱可能让运营维护两份记录。如果现有工具无法追踪对象和依据的变更，再补请求详情能力。开发确认这些限制后才能确定范围。

比较的不只是开发工时，还包括查询成本、峰值延迟、规则维护和故障时的人工处理负担。识别规则的改变需要单独验证，不与本次交接改善混为一谈。

少展示个人信息，也要落实到页面。

合规检查要把依据和界面设计放在一起。这项韩国业务案例先核对《个人信息保护法》第15条的处理依据与目的、第16条的最少收集原则，以及安全措施标准。接着对照服务条款、隐私政策、保留规则和权限表。每一项找谁确认、确认后改哪里，都写进下面的表格。

请求人与审批人分开设置，具体安排与安全负责人确认。保留期限按各类数据的用途和适用要求确定。权限表和保留表同时记录决策负责人及确认日期。

不能只问“有没有隐私问题”。我会提供要显示的字段、查看角色、使用目的、保存位置和删除方案，让负责人审查具体设计。现有处理依据是否覆盖新用途，需要一并核对。

每项记录问题、依据文件、确认角色、答复日期和影响的设计位置。例如列表显示原始资料的要求，可以先改成脱敏对象和状态，详细依据由有权限的人查看，再把审查结果同步到权限表和页面说明。

保存期限和代批权限根据服务政策及适用规则确定。尚待确认的内容写上负责角色和所需资料，避免开发在实现时自行决定。

先定状态怎么变，再定页面长什么样。

建议主流程为：资料不全 → 待审核 → 待审批 → 待执行 → 结果确认 → 完成。驳回、取消、重新审核另设分支。完成的标准是实际结果与批准的操作一致，不是有人点过按钮。

先画一个请求详情页。顶部显示状态、负责角色、最后更新时间；正文放原因和资料；底部显示当前可执行操作。资料旁写确认时间和适用规则版本。页面以外，服务端也要校验权限与状态。

保留审批时看到的对象和依据，在执行前与当前请求核对。我把这一组内容称为“审核版本”。存储方式、请求标识和结果查询方式与开发确定；依据的有效期由政策负责人确认。

用一条虚构请求走一遍。

运营提交账号A、B的保护请求。审核人确认资料与目标，审批人批准这两个账号。执行前，运营又加入账号C。我的页面会把旧的批准状态改为待复核，明确展示已批准2个目标／当前3个目标。C看起来理由相同，也不能擅自扩大旧批准范围。

重新确认并批准后执行，但响应中断。运营先用开发提供的结果查询能力，分别确认A、B、C的结果。已成功项跳过，只有确认尚未处理的目标按既定流程重试。客服也按这些确认后的结果回复。

状态表要回答谁凭什么资料执行哪个动作、之后发生什么变化。先写正常流程，再加入资料不足、驳回、审批后变更、重复点击、响应丢失和部分成功。

每次状态转换都注明权限、检查条件和留下的记录。审批对应一份包含对象和操作的审核版本。执行前比较当前请求与批准版本；有变化就回到复核。页面和服务器处理必须表达同一条规则。

让接手的人在同一页面继续处理。

先画一张请求详情页。顶部放请求编号、状态、负责角色和最近变更时间；中间放对象、原因、资料和批准版本；下方放当前可用操作及历史。需要跳转到其他系统时，也注明返回路径。

按钮不能只写名称，还要写哪个角色在什么状态看得到、点击前检查什么、处理中如何避免重复提交，以及成功或错误时显示什么。页面隐藏按钮与服务器校验权限分别确认。

下面用A、B两个对象获批后新增C的例子，将批准对象与当前对象并排显示，突出变化并要求重新审核。执行响应丢失时，先查询结果，而不是直接重试。

让AI整理，但不能让它把空白编满。

收到资料后，我会让AI整理业务流程和缺失条件，再对照原始资料检查。需要决策的部分交给运营、开发和安全负责人确认。整理文档省下来的时间，用来检查例外和执行条件。

给AI的材料使用公开案例和示例请求，去掉客户信息，把当前流程、已定规则和待确认问题分开。这个议题我会这样提问。

议题：特定负责人不在，账号保护请求就停止处理。
区分已确认的信息与假设，整理现象、目的、修改方案、预期效果。
按资料收集、审核、审批、执行、结果确认，说明谁在什么条件下推进。
包括审批后变更、响应丢失、重复执行、部分成功。
用业务名称，不要编造数据库字段或API名称。
不清楚的内容，列明确认角色和所需资料。
区分哪些旧工作消失，哪些仍保留。

收到答案，先看条件。如果写“批准后自动执行”，就追问审批后目标变了是否仍会执行。写“成功率99%”，就检查分母、失败定义和测量资料。没有依据的数字直接删除。

让运营看遗漏异常，开发看实际状态与连接能力，安全与隐私负责人看权限和数据范围。确认后的修改写回同一份需求，不能让AI草稿和会议记录成为两套规则。

我先把整理好的D01～D07交给AI，让它找条件冲突和遗漏异常，再分别整理状态表、页面说明和测试候选。每次任务保留输入版本。

修改记录还要写原因。“批准后执行”遗漏了审批后对象变化；“失败后重试”遗漏了服务器成功但响应丢失。下面是这类表述的审查示例，并不是一次新模型测试的原文。

AI提出的数据库字段和API名称必须与开发核对。确认前，业务文档使用已确认的业务名称，把实现映射留在技术评审中。

1 · 先统一词语和范围

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

2 · 确认后只改一个区间

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

3 · 追问遗漏的条件

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

把决定和待答问题一起交出去。

会议记录要写清决定、理由、适用范围、剩余问题、负责角色和目标日期。被排除的方案也留下原因，下一次会议才不会从头争论。

每条需求都要连接页面行为和测试。R-03要求D07显示版本差异，也要求T-03验证旧审批无法执行。只改一份文档，会让不同团队实现不同规则。

根据开发估算和限制确定优先级。本次不做的范围，也从页面和通知中移除。开发过程中新增的异常，要更新决定记录及受影响的需求、政策和测试。

点一次成功，不代表流程检验完了。

提交QA问题之前，记录账号与请求状态、权限、操作步骤、预期和实际结果。页面问题还要写设备、系统、浏览器及版本。不要用一句“不能用”，让多个团队重新找一遍发生条件。

按上表逐项记录验收结果。后续如果还要修改识别规则，就把制定规则的资料与验证资料分开。验证过程中改过的规则，再用新资料确认。

统计单位也要固定：请求时间按请求统计，错误账号操作按账号统计。一个请求里的多条消息不是多个独立成功样本。出现误操作时，先检查原因和能否恢复。

按角色和状态组合测试，而不是只走一次成功流程。T-03先批准v1的A、B，再新增C，尝试沿用旧审批执行。预期是返回复核并阻止执行。

发现问题后，记录设备、系统及浏览器版本、权限、请求状态、输入、复现步骤、预期和实际结果、发生时间及证据位置。偶发问题也要保留尝试次数和条件，将观察事实与原因候选分开。

修改后重跑原条件，并检查未变更的正常审批、驳回后重提等相邻流程。只有实际结果和证据支持时，才将测试改为通过。

旧工作都还在，改善就没做完。

上线前让运营、开发、安全负责人看同一份状态表和检验结果。数据范围、权限、结果确认、恢复方式仍有未决事项，该部分就不发布。先在有限运营范围内，将新流程结果与现有记录对照。

对照期间可以双重检查，但不能长期让人维护两份数据。定好旧手工传递清单何时停用，新流程出问题如何恢复。现有审批工具能满足条件，就不再建一个审批箱。这次也不加入全自动账号判断，因为错误操作的影响比普通等待更大。

• 是否改善：对同类请求比较总耗时中位数、95分位和实际操作时间。
• 副作用：同时记录复核、补资料、误操作、恢复的数量和比例，写明总量及观察周期。
• 工作是否减少：用运营记录确认状态询问、复制粘贴、重复手工输入是否减少。

完成条件有三项：下一位有权限的同事能根据同一份依据继续处理；超出批准范围的操作会被阻止；处理结果和恢复记录能在同一请求中查看。上线后再用上述指标确认等待和重复沟通是否减少。

交接资料包括：一页议题说明、现状与调整后的流程、数据及权限核对表、状态与页面、QA条件、上线恢复与测量计划。目的不是多做文档，而是填掉下一位同事还得重新询问的空白。

发布记录写清版本、范围、前提、顺序、确认角色、停止条件和恢复步骤。运营还要知道旧工作什么时候结束。没有退出条件的对照期，会让两套手工流程长期并存。

恢复旧页面不会自动撤销已经执行的账号操作。恢复时先确认逐对象的真实结果，需要撤销账号操作时，按单独的权限和流程处理。

先在有限运营范围核对，再决定扩大。记录各角色访问、交接、版本比较、结果查询及运营接收情况。关键控制失效时停止扩大。

最后写清改了什么，还剩什么。

留下的不只是文档数量，而是问题、依据、选择、协商、页面规则和测试之间的联系。接手的人要能看出哪些可以调整，哪些需要重新确认。

按D03的定义比较相同类型的请求。除耗时外，同时检查重复询问、手工工作、误操作和恢复负担。请求量、构成或观察期间不同，要先解释这些差异。

如果期待的变化没有出现，就重新查资料补充、私聊交接或审批排队的剩余等待。后续议题要带着仍未改善的区间和所需资料开始。

参考资料

议题来自Nexon的账户安全流程改善文章（2023年12月1日）。本文写的是由我负责时会采用的设计方案，界面演示和A、B、C请求均为说明用示例。

法规核对日期为2026年9月24日，包括韩国《个人信息保护法》第15、16条及安全措施标准。实际应用时，根据服务的处理目的、数据和权限进行审查。 官方条文 · 安全措施标准

韩文、英文和中文版本介绍的是同一套以韩国规则为基础的设计方案。