流程图改到崩溃这个热门Skill让修改回到文字里上个月接了个老系统的流程梳理需求用户模块的审批流程图画了四十多个节点光是把“财务复核通过后是否进入线下支付”这个分支改清楚我就在绘图软件里拖了近二十分钟连线拽歪了要重拉节点错位要重新对齐好不容易改完旁边几个被波及的箭头又乱了。那次之后我突然意识到现在这类“让AI帮我改流程图”的事其实已经有了一条更顺的路——给Claude Code、Codex这类工具配一个专门的Skill让流程图回到文字里用文字描述改动AI直接改代码化的流程图文件。这篇文章就把我完整跑通的思路写出来包括这个Skill到底怎么工作、为什么要选文字化格式、SKILL.md怎么设计以及实际用下来到底省了多少力。1. 流程图改到崩溃的根源我们在用图形工具做逻辑编辑1.1 拖拽式修改的隐性成本先说我自己的情况。过去几年我画流程图主要用两类方式一类是ProcessOn、draw.io这种在线拖拽工具一类是Visio这种桌面工具。单看“画一个新流程”它们确实比纯文字直观得多。但一旦进入修改阶段尤其是流程已经跑了一阵、分支越来越多之后问题就全冒出来了。最明显的是布局连锁反应。你在图中间挪了一个节点为了不挡线旁边的节点也得跟着挪挪完节点入边出边的拐点全部重排。这个过程在视觉上并不难但极其费时间而且改得越多图的“呼吸感”越差最后左边挤成一团、右边空出一大片。另一个隐藏成本是“语义追踪”。图形工具里你看到的是一个个方块和箭头但你心里真正要改的是“审核不通过应该回到重新提交”这种业务规则。每次都得先在脑子里做一道翻译题把业务规则翻译成“哪个节点、哪条连线、出入口怎么接”然后才能动手。翻译错了改动就白做。版本对比就更折磨了。公司里协同画图经常是领导今天要A版本明天又回到B版本。图形工具虽然有历史记录但两版之间到底多了哪些节点、哪条线改过方向肉眼比对非常吃力。你只能同时开两个窗口来回看或者在导出图里用红笔画圈。其实流程图的本质是逻辑的可视化它的信息源应该在逻辑层而不应该是一堆图形对象的位置坐标。我们被图形工具的交互方式带偏了一直在“编辑图形”而不是“编辑逻辑”。1.2 思维模型与编辑模型错位这个错位往深了说是“思维模型”和“编辑模型”不一致。你脑子里想的是一个有向图节点是业务动作边是流转条件。这是非常清晰的结构化思维。但图形工具逼着你用鼠标去操作屏幕上的像素对齐、连线、拐弯、缩放。前者是逻辑操作后者是图形操作两者之间的翻译成本就是每次改图时烦躁感的来源。还有一个被忽略的问题协作口径。两个人对着一个流程图说“把这里改成那样”这里的“这里”和“那样”都依赖视觉上下文。但如果你把同一张图写成文字比如“节点A在审核通过后流向节点B审核不通过流向节点C”协作双方讨论的就是明确的节点名和流向歧义会少很多。这也是为什么很多做架构设计的团队现在越来越倾向先在文档里把流程写清楚再让工具自动出图。我后来想明白一件事流程图应该像代码一样被对待。节点名就是变量名连线就是函数调用条件分支就是if-else。改代码的时候没有人会要求你去手动调整IDE里的缩进和颜色你改的是文本重新编译就完了。流程图如果也能这样——改动发生在文字层出图由工具自动完成——那“改到崩溃”的问题就从根上解掉了。这也是我接下来要做的Skill方案的理论基础。2. Skill不是魔法是一份给AI看的“岗位说明书”2.1 Skill机制的工作原理近半年大家都在聊Agent聊AI编程很多人一听“Skill”就觉得是某种黑科技好像装上之后AI突然就会了新技能。实际拆开看Skill就是一份给AI看的“岗位说明书”核心是一份SKILL.md文件里面用自然语言描述这个技能负责什么场景、遇到任务应该按什么步骤执行、有哪些规则必须遵守、有哪些行为被禁止。AI在执行相关任务时会读取这份说明书然后照着里面的约束来工作。我用一个生活化类比你把一个实习生叫来帮你改一篇文档你当然可以每次把要求从头说一遍但更高效的做法是写一张工作卡写上“这是一份排版规范碰到这类文档就按第1、2、3步执行不要改目录不要动图表数据”。Skill就是这个工作卡。它解决的问题本质上是稳定性——零散的prompt每次都要重新交代规则一口气说太多还会遗漏而Skill可以把规则固化下来让AI每次的表现基本一致。2.2 Skill与Agent的分工边界有好几个朋友问过我Skill和Agent到底什么关系是不是有了Agent就不用Skill了。我的理解是它们不是一个层级的东西没必要二选一。Agent是执行者的角色它负责接收任务、调用工具、规划步骤Skill是知识包是Agent在执行某一类专业任务时使用的规范手册。换个说法Agent是那个“干活的人”Skill是它手里的“操作规程”。所以Skill的重点不是给AI灌多少知识量而是把“应该怎么做”的流程约束给到AI。AI模型的底子里已经知道什么是流程图也知道Mermaid怎么写但它不知道你的项目里节点ID命名规则是什么、哪些区域的图可以动、哪些是客户定死的不能碰。这些现场规则就是Skill的发挥空间。换句话说Skill真正管住的是AI的“行为边界”而不是“知识上限”。2.3 主流工具里Skill的落点我实测下来Claude Code、Codex这类工具对Skill的支持比较成熟Cursor也在跟进。它们的实现方式大同小异在指定目录下放一个“技能文件夹”文件夹里有SKILL.md和辅助文件。工具会扫描这些目录在相关任务触发时自动加载对应的说明。以我本地环境为例Claude Code里我把技能放在~/.claude/skills/下面每个技能一个目录目录里的SKILL.md用Markdown写文件头带YAML格式的技能描述。Codex的自定义技能目录逻辑类似Cursor则是项目级配置。具体的目录路径各家版本更新比较快我建议以各自官方文档为准思路是一样的把规则写成文件让工具在合适的时机读进去。理解了这一层之后你完全可以举一反三不只改流程图像周报生成、代码评审、接口文档整理都是同一个路数。3. 让流程图“回到文字里”的前提选对文本化载体3.1 三种文本流程图格式怎么选文字化修改的第一步是让流程图本身存在于一个文本文件里。这一步没得商量你想让AI改图就得给AI能读能写的文本格式。目前主流的选择有三条实际效果差别还挺大。Mermaid是最容易上手的Markdown社区里到处都是渲染效果也不错GitHub直接支持。它的语法简洁看几眼就能看懂适合绝大多数业务流程图、系统流程图。但Mermaid对复杂布局的控制能力弱节点一多、连线一多自动布局有时候会跑得比较怪而且它默认不会严格按你书写顺序排列节点这点在改大图的时候要留意。PlantUML的语法和Mermaid类似但对活动图、时序图、用例图的支持更均匀尤其是泳道图和状态图表达力比Mermaid强。它的缺点是渲染依赖Java环境出门在外换个电脑没装环境就出不了图而且语法细节比Mermaid略繁琐。Graphviz的DOT格式走的是另一条路——它对布局的控制力是最强的会按照你对节点和边的定义自动计算力导向布局。但代价是写起来比较“机械”每条边、每个节点属性都要显式声明人直接读起来不如前两种友好。对我们这个场景来说它更适合那些“布局很重要、节点关系很复杂”的架构图。三种格式我做了个简单的对比方便你按场景选格式文本可读性布局控制适用范围适合的修改方式Mermaid最高接近伪代码较弱依赖自动布局业务流程图、系统流程图、需求文档配图AI直接改文本渲染即出图PlantUML高语法规整中等支持泳道分区时序图、活动图、带泳道的流程AI改文本需要Java环境渲染Graphviz DOT中等比较啰嗦强精确控制节点坐标与布局依赖关系图、树形结构、算法图AI改文本布局稳定但成本高如果你只是想把现有流程“从图形改到文字”跑通我建议从Mermaid起步性价比最高。后面发现表达力不够再平滑迁到PlantUML也不迟。3.2 为什么复杂流程图需要先做“降级”这里必须说一个现实问题很多团队手上现成的流程图是BPMN格式的工具里导出来是.bpmn文件本质是XML还有一堆网关、泳道、子流程、边界事件。这种文件AI确实能读但让它直接改问题很多。BPMN的语义约束比Mermaid复杂得多网关的收拢发散规则、子流程的嵌套边界AI一个不留神就改出语义错误而且这个错误在渲染层面不一定难看出来要跑规则校验才能发现。我的做法是“降级处理”把BPMN图先转写成Mermaid或PlantUML把大脑里的业务规则用简单文本表达出来AI在文本层工作等改清楚了再决定要不要导回BPMN工具去做最终发布。这不是说BPMN不好而是BPMN适合的是“建模与执行”不太适合“快速修改和讨论”。你想让修改回到文字里就得选择一个方便人读、方便AI写的中间形态。对大多数业务场景这个中间形态就是Markdown里嵌Mermaid或者PlantUML文件。流程图文件放进Git仓库管理每次改动都留痕这才是“文字化”真正带来的红利。4. 从零手写一个流程图修改Skill4.1 目录结构与SKILL.md骨架我实际做的这个Skill名字叫flowchart-editor主要职责就一条按用户的文字描述修改指定流程图文件中的节点和连线并保持无关内容不动。目录结构很朴素~/.claude/skills/flowchart-editor/ ├── SKILL.md └── templates/ └── flowchart-template.mdSKILL.md是核心templates目录放一些标准的流程图模板方便AI在新建文件时参照。SKILL.md的头部是YAML frontmatter给工具做技能索引用的。我写的是--- name: flowchart-editor description: 读取、解析、修改 Mermaid / PlantUML / Graphviz DOT 格式的流程图。用户用自然语言描述流程图改动本技能负责将改动落实到文本文件并保持最小化修改原则。 ---后面的正文部分我没有写一堆论文式的规则说明而是直接给AI一套“接到任务后的行动顺序”。这是整个Skill的精髓所在。我强烈建议不要泛泛写“你要认真修改流程图”要把步骤写死让AI照着走。4.2 核心规则先读全图再定位最后最小化修改我踩过最大的坑是让AI改图结果它把整个文件重新生成了一遍。明明只改一个分支最后交回来一个风格完全不同的图。出问题的根因就是Skill里没有约束行为边界。后来我在SKILL.md里写死了四阶段工作流## 工作流程 1. 读取阶段 先读取目标流程图文件的完整内容记录所有节点ID、连线关系、条件标签。 禁止跳过节点读取禁止只截取用户提到的局部片段。 读完以后先复述当前流程的主干路径。 2. 定位阶段 将用户描述中的改动动作映射到具体的节点ID或连线。 如果用户描述存在歧义先输出两种可能的理解让用户确认后再执行。 未确认前禁止直接修改文件。 3. 修改阶段 只允许修改地图上明确指向的节点或连线。 未提到的节点、注释、样式、布局顺序一律保持原样。 禁止顺手优化流程逻辑禁止删除用户没有要求删除的分支。 4. 输出阶段 修改完成后列出 diff 摘要包括 - 新增/删除/替换了哪些节点 - 新增/删除/修改了哪些连线 - 每条变更对应哪一句用户描述这套规则把AI的工作从“自由发挥的改图”变成了“受控的文件编辑流程”。特别是“禁止顺手优化”这条我吃了太多次亏一定要写进去。模型在理解上下文之后经常会觉得某个分支不合理自作主张帮你“校正”一下。对写作文档没什么对流程图这种精确表达业务逻辑的东西就是事故现场。4.3 给每个节点和连线一个“定位ID”为了让AI能精准改图流程图里的节点和连线不能只有显示文字必须有一套稳定的定位ID。这是我做Skill过程中悟出来的另一个关键点。在SKILL.md里我放了一节“对目标文件的要求”## 对目标文件的要求 - 每个节点必须带唯一ID格式建议模块前缀_业务名_序号例如 UM_AUDIT_001。 - 每条连线必须带文字标签格式建议动词 条件例如“复核通过”。 - 禁止在节点定义里重复使用同一ID禁止出现未命名的裸连线。 - 如果源文件缺ID可以先补充ID再执行修改但补充ID时应保持原有逻辑不变。为什么连线的标签这么重要因为AI在执行“把审批通过后的节点直接连到结束”这个操作时它需要知道“审批通过”到底是哪条线。如果每条线都带清晰的条件标签AI的定位就从“猜”变成了“查”。节点ID的作用也一样它是AI和用户之间共同的语言锚点。用户说“UM_AUDIT_001之后加一个节点”AI就不会改错地方。实际的文件长这样flowchart TD A[申请提交] --|提交成功| B[初审] B --|初审通过| C{财务复核} B --|初审不通过| A2[退回修改] C --|复核通过| D[进入支付] C --|复核不通过| B每个节点都有可辨识的名字每条线都有条件标签。AI改起来非常明确用户说“把‘进入支付’后面加一个‘人工复核’节点”AI就知道改D节点之后的部分其他不动。5. 用“人话”描述改动把模糊需求翻译成精确变更5.1 让AI先复述理解再动手规则写好了文件格式规范了但还有个最核心的问题没解决用户怎么把自己脑子里的改动说清楚。这一步很多教程不讲但它直接决定Skill好不好用。我实测下来最有效的办法是强制AI在动手前先复述它理解的流程。比如你说“用户提交申请后如果资料不齐全要先补充资料再进入初审”。这个描述看着清楚但对AI来说至少有两个问题第一“资料不齐全”这个条件是挂在“申请提交”之后还是挂在“初审”之前第二“补充资料”和“申请提交”是什么关系是新增节点还是复用已有节点这些问题不确认AI改完你八成还是得返工。所以我Skill里硬性规定定位阶段有歧义时AI必须先输出它当前对流程主干的理解通常在10行以内然后用一个问题问用户确认。这样看起来多了一步实际上省掉了后面整轮的返工。人改图的时候这种“确认需求”的过程通常发生在脑子里很容易漏掉AI反而能把它显性化这是好事。5.2 一套可以直接套用的改动描述模板为了降低描述成本我还总结了一套描述模板团队里几个不熟悉AI的同事也能直接用新增节点在“A”和“B”之间新增节点“C”原A到B的连线改为A到C、C到B。删除节点删除节点“C”原A到C和C到B的连线合并为A到B。修改条件把“A”到“B”的连线条件从“X”改成“Y”原连线删除。增加分支在“A”之后新增一条到“C”的分支条件是“Z”原A到B的连线保留。调整结构把“B”节点从“A”的直接下级改为挂在“C”下面。这套模板的本质是把“业务描述”拆成AI能执行的最小操作单元。我在SKILL.md里也放了这套模板告诉AI在接收用户模糊描述时先帮用户转成模板结构再执行。比如用户说“财务复核那一步不通过的要先看有没有异常有异常的走特殊通道”AI应该自己翻译成“在‘财务复核’的‘复核不通过’分支上新增一个判断节点‘是否异常’异常流向‘特殊通道’正常流向‘退回修改’”。5.3 兜底规则不确定时只提建议不动图最后一条兜底规则也是我血的教训换来的AI不确定的时候宁可什么都不改只输出文字建议。写代码的时候AI改错了编译器会报错你能及时发现。流程图改错了很多时候渲染出来是“正常”的只是业务逻辑错了这个错误会在评审甚至上线时爆雷。所以我专门在SKILL.md里写了一条## 兜底规则 - 当用户描述无法映射到任何节点或连线时禁止猜测。输出当前理解让用户澄清。 - 当同一个节点存在多个同名或相似节点时列出全部候选让用户选中目标ID。 - 当你认为用户描述的修改会导致流程图存在逻辑矛盾时指出矛盾点但不要自己修正。这条规则看着保守但它保证了Skill的“可预期性”。AI在保守模式下也许偶尔显得笨——多问两句少干一点——但对流程图这个场景减少误操作比追求速度更值钱。你拿回来一版AI独立改完的图结果每个分支都被重排了一遍那才叫灾难。6. 实测一周后的效率对比与避坑清单6.1 一个真实改动案例的耗时对比Skill配好之后我拿那个三十多节点的用户管理模块做了连续一周的实测。其中一次改动是“审批通过后的节点直接连到款项核对不要再经过信息同步。”传统拖拽方式下我需要先找到审批通过那条线删掉指向信息同步的边拉一条新边到款项核对还得调整附近节点的位置防遮挡。那天我实测大概花了12分钟其中光对齐就占了至少5分钟。用Skill改造后我直接把这句话打给AI它先复述了一遍主干路径确认了“款项核对”的节点ID是UM_PAY_CHECK_010然后执行修改最后输出了一条diff摘要。整个过程我介入两次一次确认理解一次Review diff。总耗时大约4分钟其中大部分时间是我自己看diff确认没改错。注意不是AI读得快是我们把“定位、翻译、执行”这三步里的定位和翻译成本转移给了AI和文字化结构。我顺手统计了几个常见操作类型大概是这么个对比操作类型拖拽工具方式文字描述Skill方式新增一个分支节点5-8分钟2-3分钟调整一条连线的条件标签3-5分钟1-2分钟删除一个中间节点并重连6-10分钟2-4分钟两版方案间来回切换每次5分钟以上30秒git reset或切换文本全图大范围重构半小时起步5-10分钟迭代出文本稿这个表看着有点夸张但请相信真正的时间节省大头不在“改”本身而在“确认自己没改错”和“发现改错了回滚”。文字化之后每一次改动都像代码提交一样可以被Review这一点是绘图软件给不了的。6.2 高频踩坑记录与对应规则补丁跑了一周踩坑还是免不了我把最常遇到的三个记录在这里给想自己搭这个Skill的朋友当参考。第一个坑AI改图改出“幽灵节点”。有一次它新增了分支但原节点到新节点的线没加图上凭空出现一个孤岛。我排查下来是源文件里两个节点ID太像AI定位错了。后来我把“每个节点必须有唯一ID”写进SKILL.md并且统一用“模块_业务_序号”的命名规范这个坑就基本消失了。第二个坑AI在一张大图上改“半截活”。它改了一处分支后相关的另一处分支没同步导致整个流程图逻辑前后矛盾。原因是它一次接收的上下文太长处理到后面忘了前面。解决办法是我在SKILL.md里建议用户把大改动拆成几条小指令逐条执行或者明确让AI分步执行并输出中间结果。改图这种事一次干一件事最稳。第三个坑也是最隐蔽的格式文件里的中文标点全半角问题。绘图软件对输入很宽容可以帮你纠错但AI生成的文本如果不小心混入全角逗号或中文冒号作为语法符号渲染就会直接失败。这个坑对新手特别不友好报错很抽象。我在SKILL.md里加了一条生成或修改后必须自查语法符号是否为半角并在输出摘要里附上“渲染前自查”的清单。一句话的事能省掉一整轮排查时间。最后再分享一个我现在固定的工作流。凡是改动超过二十个节点的大流程图我先把流程图文件放进Git仓库改之前先commit一个干净版本。AI改完我直接看git diff红色删除线加绿色新增行哪里动了、动了什么一分钟定位完。确认没问题再git commit一张图的整个生命周期就变成了一串可回溯的提交记录。这个习惯建议所有想把流程图文字化的朋友直接抄作业真的是用下来最值的一步。