差的流程设计
目的像口号：规范管理、提高效率；角色很多但责任不清；审批层层加码；KCP泛化；流程图能画完但没人愿意照做。
AI + 流程设计实战
AI+流程设计新范式：用Skill重构流程文件生产力
用Why牵引业务本质，用Gate保障人机协同，用Skill稳定产出可评审流程文件
业务本质人机协同AI偏差修正流程文件落地
FORMATRoadshow Deck
COURSEAI + 流程设计
VERSION2026.06.15
1 / 1
课程安排
一天课程总览
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
02 / 33 · 课程安排
Why一天课不追求跑完整个S1-S6，而是训练关键判断能力和高质量输入能力。
| 时间 | 模块 | 训练产出 |
|---|---|---|
| 09:00-09:40 | Why与流程设计质量 | 好/差流程设计判断框架 |
| 09:40-10:40 | S1 业务本质设计 | 客户、痛点、主要矛盾、目的、KPI |
| 10:40-10:50 | 休息 | |
| 10:50-11:50 | S2 场景分析 | 场景维度、差异化路径、落点 |
| 12:00-13:30 | 午餐 | |
| 13:30-15:00 | S3 活动设计 | 主路径、分支、规则、KCP、RACI |
| 15:00-15:10 | 休息 | |
| 15:10-16:00 | S4 数字化承载判断 | 活动到系统/RPA/AI/Agent的边界 |
| 16:00-17:00 | 综合演练：S1+S3 | 本质设计包 + 活动设计包 + 互评反馈 |
正反教材
什么是好的流程设计，什么是差的流程设计
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
03 / 33 · 正反教材
Why学员必须先有判断标准，否则只会判断“像不像文件”，不会判断“能不能解决问题”。
好的流程设计
目的可验证：周期、一次通过率、风险暴露率；场景差异有管理意义；活动有明确主导和输出；控制点少而准；能支撑系统固化。
判断一句话：它是否改变了真实业务协同方式，而不是只改变了文件格式。
案例
合同评审流程：同一主题的两种设计质量
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
04 / 33 · 案例
Why用真实场景让学员看到：业务本质没有想清楚，AI写得再顺也会变成通用文件。
| 维度 | 低质量写法 | 高质量写法 |
|---|---|---|
| 核心矛盾 | 加强合同评审管理 | 销售响应速度与重大条款风险之间的平衡 |
| 场景 | 所有合同走同一审批链 | 标准合同快速评审，非标/重大金额/高风险条款分流 |
| KCP | 合同审批、合同归档 | 非标条款识别、授权边界校验、重大风险裁决 |
| 系统化 | OA流转审批 | 模板条款库、风险条款自动提示、审批路由自动判断 |
判断力底座
不是所有知识点都适合交给Skill一跑了之
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
05 / 33 · 判断力底座
WhySkill能提高产出效率，但判断力来自关键知识点的反复研讨。没有判断力，学员只能接受AI输出，无法和AI有效互动。
| 必须讲透的知识点 | 为什么不能省 | 课堂训练方式 |
|---|---|---|
| 流程本质设计 | 决定流程服务谁、解决什么矛盾、用什么KPI证明价值，是后续所有设计的源头。 | 保留原教材深度研讨，老师引导多轮追问，学员先判断再用Skill结构化。 |
| 场景差异化设计 | 决定哪些场景值得分流，哪些只是噪音；否则流程会变成分支迷宫。 | 用案例讨论“保留/合并/剥离”场景的理由。 |
| 活动颗粒度与规则识别 | 决定活动是否可执行、可交接、可系统化，不能只靠AI自动拆解。 | 业务专家讲最佳做法，流程专家判断颗粒度，AI负责固化成表。 |
| 数字化承载条件 | 决定系统、RPA、Agent是否真的能落地，而不是停留在“建议自动化”。 | 按规则清晰度、数据结构化、风险边界、验收标准逐项判断。 |
课程原则：Skill负责提效，老师负责建立判断标准，业务专家负责提供真实经验。
课前准备
环境与资料准备
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
06 / 33 · 课前准备
Why把技术准备前置，课堂时间留给业务判断和协同练习。
工具
Qoder/Codex环境、流程文件总成Skill及子Skill、Cloudflare Pages用于HTML发布。
资料
选择一个真实流程，准备现行制度、流程图、表单、痛点清单、KPI数据。
分工
每组设置业务Owner、流程Owner、AI操作者、评审员。
成熟度
流程成熟度：先判断企业在哪一级
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
07 / 33 · 成熟度
Why成熟度决定流程文件深度：初级组织先管清责任，成熟组织再谈智能化。
判断题1
流程异常主要靠人找人协调，还是靠流程规则自动分流？
判断题2
关键活动是否有可验证输出和记录，还是只写“完成审核”？
判断题3
系统是否承载规则判断，还是只是把纸面审批搬到线上？
成熟度越低，越要先解决责任、边界、规则；成熟度越高，越要关注数据、自动化和智能化。
质量标准
流程设计质量的六个维度
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
08 / 33 · 质量标准
Why质量标准是评审AI输出的尺子。
导向正确边界清楚场景充分活动可执行控制有效文件可评审
评审时不要先问“写得好不好”，先问“是否解决了业务矛盾”。
总成架构
总成Skill：一条主线，六个子能力
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
09 / 33 · 总成架构
Why总成Skill的价值不是替代专家，而是把专家方法编排成稳定工作流。
S1 本质→S2 场景→S3 活动→S4 承载→S5 图形→S6 文件
课堂重点不背Skill步骤，而是学会在每个节点做关键判断。
信息输入
两种输入方式：访谈输入与文件导入
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
10 / 33 · 信息输入
Why输入方式影响AI理解业务的深度。
访谈输入
适合从零设计。AI分轮追问，业务专家补充背景、痛点、矛盾、边界和规则。
文件导入
适合已有材料。AI先抽取事实，再识别冲突、缺口和待确认点。
自检工具
信息充分性自检表：10个问题快速定级
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
11 / 33 · 自检工具
WhyA/B/C/D不是靠感觉判断，而是靠关键信息是否支撑设计决策。
| 问题 | 有/无 | 影响 |
|---|---|---|
| 流程从什么事件开始，到什么结果结束？ | □ | 决定边界 |
| 客户是谁，最在意什么？ | □ | 决定价值主张 |
| 当前最大痛点和主要矛盾是什么？ | □ | 决定设计取舍 |
| 有哪些场景差异会影响路径或规则？ | □ | 决定分支 |
| 关键角色和责任边界是否清楚？ | □ | 决定RACI |
| 审批、授权、裁决规则是否明确？ | □ | 决定控制点 |
| 系统、数据、接口是否已知？ | □ | 决定数字化承载 |
| KPI和现状数据是否可获取？ | □ | 决定目标 |
| 制度、模板、表单是否已有？ | □ | 决定文件接口 |
| 哪些内容必须由人确认？ | □ | 决定Gate |
8项以上为A/B级，可进入设计；5项以下先追问，不直接生成文件。
继承机制
继承需求包：跨Skill不丢信息
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
12 / 33 · 继承机制
Why多Skill协同最容易断链，需求包是把前面判断传到后面的“数据总线”。
| 字段 | 来源 | 传给谁 | 用途 |
|---|---|---|---|
| 业务矛盾 | Gate 1 | S2/S3/S6 | 约束场景和活动取舍 |
| 场景分类 | Gate 2 | S3/S5/S6 | 生成分支、剪裁指南和活动说明 |
| 角色与授权 | Gate 3 | S3/S5/S6 | 生成RACI、泳道和职责描述 |
| KCP风险 | Gate 3/4 | S3/S5/S6 | 映射控制点和测试程序 |
| 数字化承载 | Gate 4 | S3/S5/S6 | 回写系统节点、接口和人工确认点 |
| 用户反馈 | 任意Gate | 全链路 | 触发联动修订而非局部改字 |
Gate
人机协同实操手册：看、判、改
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
13 / 33 · Gate
Why人机协同不只是分工，而是每次AI输出后如何操作。
看
看关键字段：客户、矛盾、场景、角色、规则、KCP、接口、表头。
判
按通过/不通过条件判断：是否有业务事实支撑，是否能指导执行。
改
用结构化反馈：改什么、为什么改、影响哪些下游表格和图形。
反馈模板：把【不符合点】、【业务依据】、【期望修改】、【联动检查项】一次说清。
Gate案例
Gate判断案例：通过/不通过怎么识别
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
14 / 33 · Gate案例
WhyAI产出常常“看起来对”，但没有解决真实业务问题。
| Gate | 不通过信号 | 通过标准 |
|---|---|---|
| G1 本质 | 目的写成“规范管理、提升效率” | 能说清客户、矛盾、价值主张和KPI |
| G2 场景 | 场景只是罗列类型，没有流程差异 | 场景会影响路径、规则、角色或控制点 |
| G3 活动 | 活动都是“提交、审核、审批” | 每个活动有主导、输入、输出、规则和结果 |
| G4 承载 | 一律建议系统自动化 | 先判断标准化程度、风险边界和人工确认点 |
| G5 流程图 | 线条能连上但责任看不清 | 二维泳道、水平主线、分支和KCP清楚 |
| G6 文件 | 章节齐全但表头漂移 | 模板一致、语言正式、接口明确、可评审 |
1 / 13
流程本质研讨
流程本质设计要保留深度研讨，而不是直接生成答案
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
15 / 33 · 流程本质研讨
Why流程本质设计是思考训练，不是填表动作。AI可以帮助追问和结构化，但不能替代业务团队对矛盾、取舍和价值主张的共识形成。
客户是谁→核心痛点→主要矛盾→价值主张→KPI证明
老师讲透
用原教材讲清客户、痛点、痒点、爽点、价值主张、主KPI与制衡KPI，建立判断尺子。
小组研讨
业务Owner、流程Owner和关键角色代表讨论真实矛盾，先形成业务判断，不急着让AI写。
Skill结构化
AI把研讨结果整理成流程本质设计表，并标记不确定项、冲突项和需要补证据的地方。
验收标准：不是表格填满，而是能清楚解释“为什么这个流程要这样设计”。
S1
S1 业务本质设计：先回答四个问题
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
16 / 33 · S1
Why业务本质设计决定后续所有活动和规则是否有针对性。
服务谁
客户、流程Owner、管理层、员工、监管方分别在意什么？
痛在哪里
时间长、返工多、风险漏、体验差、责任不清，哪个最关键？
矛盾是什么
效率与合规、标准化与灵活性、授权与风险、体验与成本。
怎么证明
2个主KPI + 1个制衡KPI，避免单点优化。
KPI
KPI设计：常见陷阱
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
17 / 33 · KPI
WhyKPI不是装饰，它会反向约束活动设计和控制强度。
| 陷阱 | 问题 | 修正 |
|---|---|---|
| 只看周期 | 可能牺牲合规和质量 | 增加一次通过率/风险暴露率 |
| 只看审批通过率 | 可能鼓励放松审核 | 增加异常识别率/重大风险拦截率 |
| 只看满意度 | 可能掩盖成本和控制问题 | 增加单位处理成本或返工率 |
| 指标不可取数 | 无法评估流程效果 | 明确数据来源、口径和统计周期 |
S2
S2 场景分析：不是越多越好
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
18 / 33 · S2
Why场景分析的目的，是找到需要差异化设计的业务组合。
穷举要素→提炼特征→组合场景→筛选场景→落到流程
只保留会影响路径、角色、规则、KCP或系统承载的场景。
1 / 4
S3
S3 活动设计：质量核心
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
19 / 33 · S3
Why所有业务本质和场景判断，最终都要落到活动、规则、接口和KCP。
路径
主路径、分支、回流、裁决路径是否清晰。
责任
主导、协助、咨询、知会是否符合真实协同。
规则
校验、约束、路由、推导、动作是否可执行。
控制
KCP不超过5个，通常3个左右，可测试。
活动共创机制
活动说明必须由业务专家代表共创，AI只做固化和校验
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
20 / 33 · 活动共创机制
Why活动说明的价值，是把对应角色的最佳路径、作业规则和经验判断固化下来。AI如果脱离业务专家直接生成，很容易变成通用、漂亮但不可执行的描述。
| 角色 | 课堂职责 | AI协同方式 |
|---|---|---|
| 业务专家代表 | 讲清真实作业步骤、例外场景、判断规则、常见错误和最佳经验。 | AI根据口述内容提炼活动说明、规则类型、输入输出和作业文档。 |
| 流程专家/老师 | 判断颗粒度是否合适、职责是否唯一、规则是否可执行、KCP是否过多。 | AI生成检查清单，辅助发现缺口和前后不一致。 |
| 流程Owner | 确认活动路径是否符合流程目标，是否解决原有痛点和接口问题。 | AI把确认结果回写到需求包，联动后续流程图和流程文件。 |
课堂话术：不是“AI帮你写活动说明”，而是“业务专家把最佳实践讲出来，AI把它变成可复用、可评审的流程资产”。
颗粒度
活动颗粒度决策树
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
21 / 33 · 颗粒度
Why颗粒度影响责任、效率和系统化可能性。
| 判断问题 | 倾向合并 | 倾向拆分 |
|---|---|---|
| 是否同一主导角色连续完成？ | 是 | 否 |
| 是否没有独立交付物或责任交接？ | 是 | 否 |
| 是否跨系统、跨岗位或跨审批权？ | 否 | 是 |
| 是否存在关键控制点或裁决点？ | 否 | 是 |
| 是否需要单独系统配置或RPA/Agent承载？ | 否 | 是 |
AI偏差
AI常见偏差与人工修正
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
22 / 33 · AI偏差
WhyAI最大的风险不是写错字，而是产出“通用正确但业务无效”。
| 偏差 | 表现 | 修正追问 |
|---|---|---|
| 目的空泛化 | 规范管理、提升效率 | 能用什么KPI证明？ |
| 角色复合化 | 一个角色对应多个岗位不说明规则 | 何种场景匹配哪个岗位？ |
| 规则模糊化 | 按制度执行 | 属于校验/约束/路由/推导/动作哪类？ |
| KCP泛化 | 每个审批都叫KCP | 发生概率×影响程度是否足够高？ |
| 场景遗漏 | 只按标准场景设计 | 走流程最痛苦的场景是什么？ |
| 格式漂移 | 表头和模板不一致 | 用模板表头强校验。 |
S4
S4 数字化承载：活动到承载方式
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
23 / 33 · S4
Why数字化分析不是附加章节，而是反向修订活动设计的依据。
| 活动特征 | 优先承载 | 回写位置 |
|---|---|---|
| 高频、规则清楚、输入结构化 | 系统固化 | 活动说明、系统Owner、流程图系统节点 |
| 跨系统搬运、规则简单 | RPA | 作业文档、输入输出、异常处理 |
| 资料多、需归纳比对 | AI辅助 | 活动说明、人工确认点、记录保存 |
| 需要经验但可复核 | Agent候选 | 权限边界、输出格式、禁区 |
| 最终审批、资金、权限、重大风险 | 人工确认 | KCP、SOD、裁决规则 |
系统/RPA承载条件
系统固化和RPA承载，需要把规则写到可配置、可测试
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
24 / 33 · 系统/RPA承载条件
Why识别出“可以系统化/RPA化”只是第一步。真正能承载，取决于规则、数据、异常和验收标准是否足够清楚。
| 承载方式 | 前提条件 | 规则要写到什么程度 | 评价标准 |
|---|---|---|---|
| 系统固化 | 流程稳定、字段结构化、权限清晰、规则长期有效。 | 字段来源、必填规则、校验逻辑、路由条件、阈值、权限边界、异常处理。 | 规则可配置、结果可复现、异常可追踪、操作有日志。 |
| RPA承载 | 操作高频重复、界面稳定、输入输出清晰、人工判断少。 | 操作步骤、页面路径、字段映射、等待条件、失败重试、人工接管条件。 | 成功率、平均处理时长、异常率、人工接管率、维护频率。 |
| 不宜承载 | 规则频繁变化、输入不稳定、需要大量现场判断或高风险裁决。 | 先沉淀标准作业、模板、FAQ和案例，再考虑自动化。 | 自动化收益低于维护成本时，保留人工或半自动。 |
一句话：能不能承载，不看愿望，看规则是否能被机器稳定理解和执行。
Agent边界
AI Agent：为什么要先定边界
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
25 / 33 · Agent边界
WhyAgent设计不先讲技术，而先讲它替人承担什么、哪里必须留给人。
价值
承担高频资料处理、预审、比对和风险提示。
前提
输入可结构化、规则可描述、输出可复核、过程可留痕。
禁区
最终审批、资金支付、权限变更、强合规裁决、重大风险放行。
Agent承载前提
Agent适合承载经验型活动，但必须先给知识、标准和边界
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
26 / 33 · Agent承载前提
WhyAgent不是“把经验判断交给AI自由发挥”，而是把知识库、评价标准、正反案例和人工断点配置好，让它在边界内辅助执行。
知识库
制度、模板、FAQ、历史案例、作业指南、风险条款库，且要有版本和适用范围。
评价标准
什么叫合格输出、什么叫高风险、什么必须退回人工，必须有可检查的评分或Checklist。
正反案例
给出优秀样例、错误样例、边界样例和解释原因，让Agent学习判断差异。
人工断点
资金、法律责任、权限变更、重大例外、客户承诺等节点必须明确人工确认。
Agent承载验收：依据可引用、判断可解释、输出可复核、风险可截停、过程可追踪。
流程图
流程图硬约束与自检
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
27 / 33 · 流程图
Why图一乱，责任、路径和控制点就会被误读。
| 自检项 | 通过标准 |
|---|---|
| 责任人 | 一眼能看出每个活动属于哪个泳道。 |
| 方向 | 主线从左到右，避免斜线和上下为主流向。 |
| 回流 | 回流线沿顶部/底部绕行，不穿越主流程框。 |
| 分支 | 两种以上路由使用菱形。 |
| KCP | 关键控制点在图中明确标识，且与KCP表一致。 |
1 / 9
文件装配
14章流程文件：每章数据来源
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
28 / 33 · 文件装配
Why正式文件不是重新写一遍，而是把S1-S5确认结果装配成可评审文本。
| 章节 | 主要来源 |
|---|---|
| 目的、适用范围、术语 | S1 本质设计 + Gate 1 |
| 角色职责、KPI | S1/S3 + Gate 3 |
| 流程图、活动说明 | S3/S5 + Gate 5 |
| 业务规则、KCP | S3/S4 + Gate 3/4 |
| 相关文件、记录保存 | S3/S6 + 模板规则 |
| 剪裁指南、版本记录 | S2/S6 + 用户反馈 |
联动修订
反馈联动修订机制：改一处，查三处
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
29 / 33 · 联动修订
Why高质量协同不是局部改字，而是保证上下游一致。
| 修改项 | 必须联动检查 |
|---|---|
| 角色 | 角色职责表、活动RACI、流程图泳道 |
| 活动 | 流程图节点、KCP、业务规则引用、记录保存 |
| 场景 | 适用范围、分支条件、剪裁指南、活动差异 |
| KPI | 流程目的、活动输出、记录来源、统计周期 |
| 系统/Agent | 系统Owner、人工确认点、权限边界、异常处理 |
1 / 2
综合演练
综合演练只做S1+S3
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
30 / 33 · 综合演练
Why一天课时间有限，先练质量核心：本质判断和活动设计。
输入
提供预填案例包：业务背景、痛点、现有规则、角色、少量表单。
产出
一张本质设计表 + 一张活动设计表 + 3个KCP。
互评
按评分卡评审：业务矛盾、活动可执行、规则清楚、KCP有效。
评分卡
演练评分卡
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
31 / 33 · 评分卡
Why互评要结构化，否则只会评价“写得是否完整”。
| 维度 | 评分问题 | 分值 |
|---|---|---|
| 业务本质 | 是否说清客户、痛点和主要矛盾？ | 20 |
| 目的/KPI | 是否能用KPI证明流程改善？ | 15 |
| 活动设计 | 活动是否有主导、输入、输出和规则？ | 25 |
| 场景差异 | 是否把关键场景落到路径或活动？ | 15 |
| KCP | 是否少而准、可测试？ | 15 |
| 联动一致 | 活动、规则、KCP、角色是否一致？ | 10 |
课后落地
课后落地路线图：谁来做
用 Skill 演练驱动知识点讲解，课堂产出可评审的流程设计成果
32 / 33 · 课后落地
Why流程能力建设必须落到责任人，否则培训结束就回到个人经验。
| 阶段 | 动作 | 责任人 |
|---|---|---|
| 第1周 | 选择3个高价值流程试点，准备输入包 | 流程Owner / BPO |
| 第2-3周 | 用总成Skill产出初稿并完成Gate评审 | 流程Owner / 业务骨干 |
| 第4周 | 形成内部模板、案例库和常见偏差库 | 质量部 / 流程管理部门 |
| 第2个月 | 评估系统化、RPA、AI/Agent机会 | IT / 流程Owner |
| 持续 | 沉淀为企业内部流程文件开发机制 | GPO / 管理层 |
结束
真正的能力不是让AI写流程文件
而是把业务本质、方法规则、模板标准和评审机制，变成可复用的人机协同系统。
FORMATRoadshow Deck
COURSEAI + 流程设计
VERSION2026.06.15
1 / 4