通用业务流程设计与 Draw.io 流程图生成
目标
把用户提供的业务材料转成稳定、可评审、可继续修改的流程成果。优先保证业务事实、角色、节点、判断与分支正确，再处理版式。
本 Skill 不依赖任何特定企业、行业、知识库、OA、CRM、ERP 或内部流程分类。用户材料中的企业自定义术语、系统名、角色名应原样保留。
何时使用
用户出现以下需求时使用本 Skill：
- 根据需求、会议纪要、制度、SOP、操作说明生成流程图。
- 梳理业务流程、审批流、跨部门流程、系统流程、状态流、数据流。
- 先出草稿，再升级成详细流程说明书。
- 输出 Mermaid 草图或 Draw.io 可导入 XML。
- 对已有流程做检查、补充、局部修改或重新出图。
- 用户要求删除、修改、保留某几个已确认节点，并要求其他内容不变。
如果用户只是询问某个流程概念或方法，先回答问题，不强制出图。
核心原则
- 业务事实优先：用户明确给出的节点、编号、角色、系统、判断和分支，不得擅自改写。
- 原值继承：已有明确系统名、表单名、组织名、业务术语时逐字继承，不用通用词替代。
- 不伪造企业规则：材料未给出的审批层级、授权规则、系统归属、时限、表单字段、L1-L3 分类，不自行编造。
- 节点守恒：用户确认草稿后，正式图默认只能增加开始/结束、泳道背景、系统角标、阶段栏和连线等版式元素；不得新增、删除、拆分、合并或改名业务节点，除非用户明确要求。
- 判断与活动分离：审核、审批、检验、确认、验证、复核、评估等是可执行活动；“是否通过？”一类才是判断。判断菱形不占活动编号。
- 局部修改机械执行：修改已有流程时，采用“复制上一版 → 定位指定节点/字段 → 最小变更 → 校验其他内容不变”。用户未点名的内容保持不变。
- 不把未知系统写成线下：只有材料明确出现线下、人工、电话、纸质、现场、手工台账等，才写“线下”；否则无法判断时写“待确认”。
- 先结构后画图：正式 Draw.io 图必须先形成结构化中间结果，再调用脚本生成，避免模型直接手写复杂 XML。
工作模式识别
根据当前请求与上下文选择一个主模式：
QUESTION_ONLY：概念咨询、方法说明，不需要生成流程。CHECK_ONLY：检查已有流程，输出问题与修改建议。FAST_DRAFT：默认流程生成模式；先给草稿活动表 + Mermaid，供用户确认。DETAIL_PREVIEW：用户明确说“详细版、流程说明书、升级详细版”等时，生成详细说明书，不直接生成正式 Draw.io。BUILD_DRAWIO：用户明确要求“构建流程图、正式版、Draw.io、XML、可导入 draw.io”等时，生成正式图。LOCAL_MODIFICATION：用户针对上一版指定节点、角色、字段、分支或系统做修改。
如果用户只说“生成流程图/画流程图/出个流程图”，默认 FAST_DRAFT，不要直接生成正式 XML。
FAST_DRAFT：草稿输出
草稿必须先输出活动表，再输出 Mermaid。活动表固定五列：
| 活动编码 | 活动名称 | 角色/泳道 | 判断/分支 | 说明 |
|---|---|---|---|---|
规则：
- 活动编码使用两位数字，如
01、02。 - 活动名称写可执行动作，优先使用动宾短语。
- 纯判断问句不作为活动名称，也不单独占活动编码。
- 有判断时，把判断问句写在“判断/分支”；分支去向写在“说明”。
- 没有判断时填写
—，Mermaid 中不得额外生成菱形。 - 不为了凑数量而补“申请—审核—审批—归档”模板节点。
Mermaid 稳定格式：
- 使用
flowchart TD或flowchart LR。 - 节点 ID 仅使用 ASCII 字母、数字和下划线。
- 泳道用
subgraph SG01["角色名称"]。 - 中文节点文字放在双引号中。
- 判断使用
D02{"具体判断条件？"}，不显示活动编号。 - 跨泳道连线统一放在全部
subgraph ... end之后。
草稿末尾只给一个简短下一步：用户可以继续“调整草稿”，也可以“生成详细版”或“构建流程图”。
DETAIL_PREVIEW：详细流程说明书
详细版固定输出以下章节：
- 基础信息与流程归属
- 流程目标、适用范围、边界与触发条件
- 角色与职责分工
- 活动明细表与判断/异常规则
- 术语解释
- 系统/表单/字段建议
- 待确认事项
基础信息建议字段
- 所属组织/业务域
- 流程状态
- 流程层级
- 流程分类
- 流程名称
- L1 / L2 / L3（仅当用户已有企业流程架构或明确要求分类时填写；没有企业分类依据则写“待确认”，不要创造企业分类）
- 适用部门/角色
- 核心业务对象
- 主要系统
- 备注
活动明细表固定九列
| 活动编码 | 活动名称 | 流程角色 | 授权/责任类型 | 业务角色 | 输入 | 输出 | 处理说明 | 系统 |
|---|---|---|---|---|---|---|---|---|
其中：
授权/责任类型：用户或制度明确时继承；没有企业定义时写“待确认”，不要自创授权制度。系统：明确值逐字继承；可从上下文唯一确定时填写；无法唯一确认时写“待确认”；明确线下时写“线下”。- 术语解释针对非通用缩写、组织名、系统名、业务专有词；企业正式定义不明确时注明“需业务确认”。
BUILD_DRAWIO：正式图
第一步：构建中间结构
正式出图前，先形成 SWIMLANE_FLOW_V1。详细格式见：
@${CODEBUDDY_SKILL_DIR}/references/workflow-spec.md
要求：
LANES必须覆盖所有业务节点使用的泳道。STAGES可选；当流程明显分阶段或节点较多时应输出。task是业务活动；decision是真正有两个及以上不同出口的判断；terminal仅用于特殊终止节点。- 开始/结束不作为普通业务节点，渲染脚本会自动补。
- 系统角标只显示材料明确或可唯一确定的系统；不要按行业经验强猜具体产品名。
- 一个活动最多展示 3 个系统，多个系统用
/连接。
第二步：验证并渲染
把中间结构保存为临时文本文件，例如 process.swimlane.txt，再执行：
python "${CODEBUDDY_SKILL_DIR}/scripts/render_drawio.py" process.swimlane.txt -o process.drawio
脚本会做基础校验并生成可导入 Draw.io 的 XML。若校验失败，先修正结构，不要输出损坏 XML。
如需单独校验：
python "${CODEBUDDY_SKILL_DIR}/scripts/render_drawio.py" process.swimlane.txt --validate
第三步：最终检查
输出前检查：
- 活动节点数量、编号、名称与已确认草稿一致。
- 判断节点只来自明确的判断/分支，不因“审核/确认”等词自动新增。
- 每个 decision 至少有两个不同出口。
- 所有节点泳道均存在。
- 不存在孤立业务节点。
- 不存在“节点文本、泳道名称、待确认系统、人工处理”等占位文本。
- 系统名没有被错误替换。
- 开始/结束存在，主流程方向清晰。
- 失败/退回分支保持可读，不能覆盖节点正文。
LOCAL_MODIFICATION：修改上一版
当用户说“删掉 03/04”“把 06 的角色改成财务”“这一条系统改成 ERP”“其他不变”等：
- 以上一轮用户实际看见的活动表/流程基线为唯一底稿。
- 只改变用户明确指定的节点、字段或连线。
- 默认保留原编号，不连续重编号；只有用户明确要求重新编号时才重排。
- 删除节点时只删除指定节点及直接相关连线，再连接删除区间两侧的保留节点；不要生成替代节点。
- 用户没要求时，不重新推导流程、不优化角色、不合并步骤、不扩充异常路径。
- 修改后重新输出受影响的草稿或正式图，并核对未修改部分。
CHECK_ONLY：检查口径
检查已有流程时，重点看：
- 是否存在角色缺失或角色与活动不匹配。
- 活动是否可执行、颗粒度是否明显过粗/过细。
- 判断条件是否具体、是否至少有两个真实出口。
- 分支是否有明确去向、是否出现断链或死循环。
- 输入输出是否能支撑上下游活动。
- 系统/表单字段是否与材料一致。
- 泳道是否覆盖所有角色。
- 是否存在未经材料支持的新增节点、审批层级或异常规则。
- 图形是否可读：节点不重叠、连线不压文字、主流程方向一致。
输出“问题 → 影响 → 建议修改”，不要无依据重写整个流程。
文件与材料处理
用户上传 Word、PDF、Excel、图片等材料时：
- 先读取可用文本或表格内容，再执行流程梳理。
- 如材料中存在已有活动编号、活动表或流程图文字转写，优先作为事实基线。
- 若关键信息缺失，可以在结果中列“待确认事项”；不要为了完成图而猜企业制度。
通用视觉风格
正式 Draw.io 默认使用中性企业风格：
- 白色画布。
- 左侧为浅色角色栏，泳道横向排列。
- 活动节点为白底圆角矩形。
- 系统角标为深色小标签，放在活动框左上方外侧。
- 判断为菱形。
- 主线黑色正交箭头；通过/成功可绿色；退回/拒绝/失败可红色。
- 优先保证一屏可读；节点多时增加高度或分阶段，不无限拉宽。
更完整的结构规范与示例见：
@${CODEBUDDY_SKILL_DIR}/references/workflow-spec.md@${CODEBUDDY_SKILL_DIR}/references/output-templates.md@${CODEBUDDY_SKILL_DIR}/examples/purchase-approval.md
禁止事项
- 不引用或假设任何特定企业知识库。
- 不输出任何原企业名称、内部系统清单、内部流程模板名或内部 API 地址。
- 不因业务词语自动映射到任何具体企业系统或产品。
- 不把“详细版”误当成“正式 Draw.io”。
- 不在用户未确认草稿时悄悄扩充大量业务节点。
- 不直接手写复杂 Draw.io XML；优先使用脚本生成。
