如果你最近也在和流程圖死磕尤其是在圖形畫布上反復(fù)拖連線、挪節(jié)點(diǎn)、調(diào)箭頭那你一定要看看現(xiàn)在社區(qū)里討論度很高的那類“流程圖Skill”。我前陣子剛好被用戶管理模塊的流程圖折磨到崩潰改一個(gè)權(quán)限分支整張圖的布局全亂了。后來照著這個(gè)思路把流程圖的維護(hù)徹底“降維”到文字層面才算是真正解脫。這篇文章就把我折騰下來的完整過程、Skill設(shè)計(jì)邏輯、接入方式和踩過的坑都寫出來給同樣被畫圖折磨的朋友一個(gè)參考。1. 畫布上的一次次改圖事故到底坑在哪1.1 一次改到崩潰的真實(shí)經(jīng)歷前陣子我在整理用戶管理模塊的流程圖需求是先畫一張從賬號(hào)登錄到角色分流的圖。剛開始用免費(fèi)的繪圖軟件幾分鐘拖出來第一版開始節(jié)點(diǎn)、賬號(hào)密碼輸入、校驗(yàn)判斷、角色判斷、進(jìn)入不同首頁?？粗R齊還挺滿意。結(jié)果產(chǎn)品經(jīng)理過來說要加一個(gè)“連續(xù)輸錯(cuò)5次鎖定賬號(hào)”的邏輯。我當(dāng)時(shí)想這不就是在一個(gè)判斷后面加個(gè)分支嗎小事。結(jié)果真正動(dòng)手時(shí)才發(fā)現(xiàn)畫布上的連線不會(huì)自動(dòng)避讓更不會(huì)智能重排。我把新節(jié)點(diǎn)拖進(jìn)去之后原本三根清晰的箭頭全部纏在一起布局徹底亂掉。我花了二十多分鐘去對(duì)齊、繞線、調(diào)整位置最后的效果還是很丑甚至有一條線直接從三個(gè)節(jié)點(diǎn)中間穿過去。最后沒辦法我把整張圖刪掉重新畫了第二版。第二版剛畫完產(chǎn)品經(jīng)理又補(bǔ)了一句“管理員登錄后需要能看到重置密碼入口?！蹦且豢涛覂?nèi)心的崩潰感直接拉滿因?yàn)槲掖蟾拍茴A(yù)見到這張圖馬上又要重畫了。我相信畫過流程圖的人都有類似的經(jīng)歷改一個(gè)節(jié)點(diǎn)、動(dòng)一條線、加一個(gè)分支整張圖垮掉。不是繪圖軟件不夠好draw.io、ProcessOn這些工具已經(jīng)很成熟了真正的問題在于圖形化編輯這種交互方式天然就不適合高頻修改邏輯的場(chǎng)景。1.2 崩潰的本質(zhì)邏輯和布局被強(qiáng)行綁在一起一張流程圖本質(zhì)上包含兩件事一是“業(yè)務(wù)邏輯”也就是節(jié)點(diǎn)之間有序的依賴、分支、循環(huán)關(guān)系二是“視覺布局”也就是每個(gè)節(jié)點(diǎn)放在畫布的哪個(gè)坐標(biāo)位置、線條怎么繞、圖形尺寸是否統(tǒng)一。在傳統(tǒng)繪圖工具里這兩件事被混合記錄在同一張畫布上。你修改邏輯時(shí)布局不會(huì)自動(dòng)跟隨重建它只會(huì)把原本整齊的東西打亂。于是“增加一個(gè)分支”這種在邏輯上只需要幾秒的操作落到畫布上往往需要十分鐘來收拾殘局。更崩潰的是就算你這次把布局調(diào)好了下次再改的時(shí)候之前的微調(diào)又會(huì)作廢。我見過很多同事包括我自己最后都選擇“推倒重畫”而不是在舊圖上繼續(xù)改。這說明圖形化編輯的容錯(cuò)性太低了它把最重要的邏輯變更跟最不穩(wěn)定的視覺參數(shù)耦合在一起。換一個(gè)角度看流程圖的底層信息完全可以只靠文本描述1. 開始 2. 輸入賬號(hào)密碼 3. 校驗(yàn)賬號(hào)密碼 通過 - 4 失敗 - 3.1 3.1 失敗次數(shù) 1 如果次數(shù) 5 - 鎖定賬號(hào)結(jié)束 否則 - 回到 2 4. 判斷角色 管理員 - 5 普通用戶 - 6 5. 進(jìn)入管理員首頁 6. 進(jìn)入普通用戶首頁看這段文本完整表達(dá)了邏輯卻沒有一個(gè)坐標(biāo)參數(shù)。無論圖怎么渲染這段文字的維護(hù)成本都極低。這其實(shí)就是“讓修改回到文字里”的底層邏輯。1.3 文本化不是新鮮事但Skill把它變成了日常操作文本化繪圖的想法其實(shí)早就有了Mermaid、PlantUML這些方案已經(jīng)存在很多年。但過去它們有個(gè)門檻你得學(xué)語法、記關(guān)鍵字本質(zhì)上還是在改代碼。很多業(yè)務(wù)同學(xué)看到graph TD這類代碼就頭疼最后還是回到拖拽畫圖。而最近社區(qū)里討論度很高的那類“流程圖Skill”把這一步往前推了一大截你不需要自己寫語法AI負(fù)責(zé)把你的口語化描述轉(zhuǎn)成結(jié)構(gòu)化文本再根據(jù)文本渲染成圖。你要做的只是改一句人話比如“鎖定的條件從5次改成3次”AI會(huì)自動(dòng)更新文本清單里的判斷條件然后重新生成圖。這也正是我決定自己落地一個(gè)Skill的原因。手動(dòng)拖拽太累直接寫語法有門檻而讓AI在文字層面替我維護(hù)流程剛剛好。2. 這個(gè)熱門Skill做了什么把改圖變成改話2.1 Skill就是給AI寫的一份“崗位說明書”如果你用過Claude Code、Cursor或者Codex這類AI編程助手可能已經(jīng)接觸過“Skill”這個(gè)概念。它本質(zhì)上是一個(gè)可復(fù)用的技能包一個(gè)文件夾里面放一份規(guī)范的指令文件告訴AI在特定場(chǎng)景下應(yīng)該按什么順序、什么格式、什么原則來完成工作。Skill可以理解為給AI寫的一份“崗位說明書”。Agent是那個(gè)執(zhí)行任務(wù)的人Skill則是一本操作手冊(cè)。沒有技能包時(shí)AI像一個(gè)什么都懂一點(diǎn)但很隨意的實(shí)習(xí)生加載了技能包之后它就有了明確的工作流程和輸出標(biāo)準(zhǔn)。一個(gè)標(biāo)準(zhǔn)的流程圖Skill至少包含一個(gè)SKILL.md文件。這個(gè)文件頭部有frontmatter里面寫名字和描述正文部分則是詳細(xì)的工作規(guī)則。AI助手會(huì)掃描這些描述當(dāng)用戶任務(wù)匹配時(shí)自動(dòng)把技能包里的規(guī)范加載到上下文里。這也是Skill比普通Prompt高級(jí)的地方它是文件化的、可命中觸發(fā)的、可版本管理的。2.2 一個(gè)流程圖Skill的典型工作流我實(shí)際用下來這類Skill的工作流可以拆成四步用戶用自然語言描述需求比如“幫我畫一張用戶管理模塊的流程圖”。Skill讓AI先輸出結(jié)構(gòu)化的流程文本使用縮進(jìn)表達(dá)分支和嵌套不直接生成圖形代碼。AI再基于這份文本按用戶指定的渲染語法比如Mermaid或PlantUML生成圖表代碼。用戶后續(xù)要求修改時(shí)Skill強(qiáng)制AI先更新結(jié)構(gòu)化文本再重新生成代碼。整個(gè)過程相當(dāng)于把“菜譜”和“成品菜”分開。菜譜是那串文本成品圖是渲染出來的結(jié)果。你要調(diào)整口味改菜譜就行不用重新炒一盤菜去擺盤。這里有個(gè)容易被忽略的設(shè)計(jì)點(diǎn)先有文本后有代碼。很多AI在沒有約束的情況下會(huì)直接生成一大段圖表代碼用戶改起來還是像在讀天書。而Skill通過行為規(guī)范強(qiáng)制AI把邏輯沉淀成人類可讀的文本這樣后續(xù)每一次修改都變得可追蹤。2.3 它解決的不只是“改”還有“一致性”過去在畫布里改圖改完一次往往文檔里的舊截圖、PPT里的舊版本、需求文檔里的描述全都不一致。而文字化的流程文本可以作為“唯一事實(shí)源”一份文本可以被反復(fù)渲染成圖放進(jìn)設(shè)計(jì)文檔、PPT、Wiki甚至代碼注釋里。團(tuán)隊(duì)成員也能通過Git對(duì)流程文本做代碼評(píng)審。誰改了哪個(gè)分支、為什么去掉了一個(gè)判斷都能在diff里清楚看到。這是傳統(tǒng)繪圖軟件完全做不到的。也正因?yàn)檫@一點(diǎn)越來越多的開發(fā)團(tuán)隊(duì)愿意把流程類Skill納入工作流而不只是把它當(dāng)成畫圖的玩具。3. 手寫一個(gè)流程圖Skill從零搭一個(gè)能用版本3.1 最小的Skill目錄長(zhǎng)什么樣我不建議直接找一個(gè)閉源或黑盒的遠(yuǎn)程Skill來用自己動(dòng)手寫一個(gè)反而能徹底理解它的原理。下面是最小的目錄結(jié)構(gòu)flowchart-skill/ ├── SKILL.md └── templates/ └── flow-template.txtSKILL.md是整個(gè)技能包的核心。我寫了一個(gè)精簡(jiǎn)但完整的版本你可以直接參考--- name: flowchart-text description: 將任意業(yè)務(wù)、系統(tǒng)或算法流程轉(zhuǎn)化為結(jié)構(gòu)化文本并根據(jù)用戶要求對(duì)文本進(jìn)行增量修訂然后輸出可渲染的圖表描述。適用于用戶管理流程、業(yè)務(wù)審批流、算法邏輯圖等場(chǎng)景。 --- # 工作方式 當(dāng)用戶請(qǐng)求與流程圖相關(guān)時(shí)必須按以下順序執(zhí)行 1. 將需求整理成結(jié)構(gòu)化流程文本。 - 使用數(shù)字編號(hào)表示節(jié)點(diǎn)。 - 使用縮進(jìn)表示嵌套分支。 - 分支條件寫在節(jié)點(diǎn)行內(nèi)用“如果/否則”表達(dá)。 2. 在文本之后按用戶指定格式輸出可渲染圖表代碼。 - 如果用戶未指定默認(rèn)使用 Mermaid。 - 如果用戶指定 BPMN則輸出 BPMN 結(jié)構(gòu)描述。 3. 用戶提出修改時(shí) - 先基于上一次的完整文本做增量更新。 - 在回復(fù)開頭用“變更點(diǎn)”列明本次修改了哪些節(jié)點(diǎn)。 - 輸出完整的更新后文本而不是只輸出差異片段。 4. 當(dāng)流程超過 20 個(gè)節(jié)點(diǎn)時(shí)使用“子流程”拆分。 - 子流程用“詳見 [節(jié)點(diǎn)編號(hào)]”的方式引用。這樣一個(gè)文件就足以讓AI在多數(shù)編程助手里被觸發(fā)。frontmatter里的name是技能包唯一標(biāo)識(shí)description決定了模型在什么情況下加載它所以描述一定要寫清楚適用范圍越具體命中率越高。3.2 核心設(shè)計(jì)先文本后渲染很多人會(huì)問為什么不讓AI直接生成Mermaid代碼省一道步驟我的經(jīng)驗(yàn)是Mermaid代碼本質(zhì)上是一行壓縮過的字符串如果直接改它模型很容易把某個(gè)箭頭寫錯(cuò)而且diff可讀性極差。結(jié)構(gòu)化文本則友好得多。每次修改都是針對(duì)節(jié)點(diǎn)編號(hào)、分支條件和縮進(jìn)關(guān)系進(jìn)行更新出錯(cuò)時(shí)一眼就能看出來。渲染代碼反而應(yīng)該被視為“產(chǎn)物”每次由AI重新生成不需要人工維護(hù)。這里也涉及一個(gè)技術(shù)選擇渲染語法用什么。社區(qū)流行的是Mermaid因?yàn)镚itHub、Notion、各類文檔系統(tǒng)都原生支持零成本呈現(xiàn)。如果你的團(tuán)隊(duì)在用企業(yè)級(jí)BPMN工具那Skill的模板里可以換成BPMN XML結(jié)構(gòu)描述原理是一樣的。3.3 一個(gè)容易忽略的細(xì)節(jié)模型必須輸出“完整文本”我在第一次寫Skill時(shí)沒有強(qiáng)調(diào)“輸出完整文本”結(jié)果AI每次都只返回“這次改好了看第3條”。它以為用戶能記住上一版但上下文一長(zhǎng)就亂了而且后續(xù)如果用戶復(fù)制這段去渲染拿到的是殘缺內(nèi)容。所以我在技能規(guī)范里強(qiáng)制加了一條每次修改后必須輸出完整更新文本。這看起來浪費(fèi)一點(diǎn)輸出字?jǐn)?shù)但換來了極高的可操作性。你可以直接復(fù)制整段文字也可以把整段文字交給下一個(gè)模型去繼續(xù)處理不會(huì)因?yàn)樯舷挛慕財(cái)嗷蛘邚?fù)制遺漏而出錯(cuò)。4. 三個(gè)實(shí)戰(zhàn)場(chǎng)景從用戶管理模塊到算法作業(yè)再到BPMN4.1 案例一用戶管理模塊的分支流程我最初就是為了解決這個(gè)場(chǎng)景才建Skill的。把開頭那個(gè)“鎖號(hào)邏輯”寫成文本后修改兩個(gè)字的成本約等于零。產(chǎn)品經(jīng)理說“5次改成3次”我只需要讓AI把文本里的 5改成 3圖就自動(dòng)更新了。后來產(chǎn)品還要加“管理員可重置密碼”的功能。我在流程文本的角色判斷分支后面補(bǔ)了一條4. 判斷角色 管理員 - 4.1 普通用戶 - 5 4.1 管理員操作菜單 是否重置密碼 是 - 重置流程 否 - 進(jìn)入管理員首頁這就是一段文字不用連一條線不用調(diào)一個(gè)坐標(biāo)。AI收到這句話后能自動(dòng)把4.1節(jié)點(diǎn)以及相關(guān)分支全部重建。整套操作從半小時(shí)縮短到一分鐘。4.2 案例二算法作業(yè)里的“老三樣”流程圖社區(qū)熱詞里出現(xiàn)了一堆典型的算法作業(yè)題輸入十個(gè)數(shù)找最大值、判斷一個(gè)數(shù)能否同時(shí)被3和5整除、求兩個(gè)數(shù)m和n的最大公約數(shù)、輸入abc比較大小。這類題目特別適合用文字化流程來表達(dá)因?yàn)樗惴ū旧砭褪恰安襟E條件”。舉一個(gè)求最大公約數(shù)的例子1. 輸入 m, n 2. 如果 m % n 0 - 輸出 n結(jié)束 3. 否則: r m % n m n n r - 回到 2這個(gè)文本版的流程圖教學(xué)時(shí)可以直接貼在作業(yè)里老師一眼能看懂邏輯。而且學(xué)生改起來心里負(fù)擔(dān)小很多不像圖形工具那樣需要在畫布上重做。我自己實(shí)際體驗(yàn)是只要Skill被正確觸發(fā)這類算法流程幾乎不會(huì)出錯(cuò)。模型本身對(duì)算法邏輯的理解力很強(qiáng)Skill只需要提供一個(gè)穩(wěn)定的輸出框架剩下的都是模型的基本功。4.3 案例三從采購到銷售的業(yè)務(wù)流程與BPMN網(wǎng)關(guān)業(yè)務(wù)場(chǎng)景比算法場(chǎng)景復(fù)雜一些比如熱詞里那個(gè)“從采購到PS到銷售”的SAP流程。這類流程通常涉及多個(gè)部門、多個(gè)系統(tǒng)還有BPMN里的排他網(wǎng)關(guān)、并行網(wǎng)關(guān)。文字化方案在這里的價(jià)值更大。你可以用角色標(biāo)簽代替泳道用網(wǎng)關(guān)標(biāo)記表達(dá)分支1. [采購部] 創(chuàng)建采購申請(qǐng) 2. [排他網(wǎng)關(guān)] 庫存是否充足 是 - 直接創(chuàng)建采購訂單 否 - 走審批流程審批通過后創(chuàng)建采購訂單 3. [計(jì)劃部] 確認(rèn)到貨計(jì)劃PS節(jié)點(diǎn) 4. [銷售部] 根據(jù)到貨計(jì)劃創(chuàng)建銷售訂單 5. [并行網(wǎng)關(guān)] 同時(shí)觸發(fā)財(cái)務(wù)開票和物流發(fā)運(yùn)看到?jīng)]有泳道、網(wǎng)關(guān)、并行分支全部通過文本標(biāo)記表達(dá)。需要轉(zhuǎn)成BPMN建模工具里的圖時(shí)AI可以基于這段文本生成對(duì)應(yīng)的BPMN結(jié)構(gòu)描述再導(dǎo)入建模工具。對(duì)SAP顧問或者業(yè)務(wù)分析師來說這意味著他們可以在不打開重型建模軟件的情況下先在文字層面把流程聊清楚。4.4 一個(gè)小提醒不要上來就追求完美排版使用這類Skill時(shí)我的經(jīng)驗(yàn)是前幾版不要關(guān)注圖的樣式、顏色、布局先把節(jié)點(diǎn)和分支邏輯跑通。文本化流程最大的優(yōu)勢(shì)是邏輯本身排版是渲染階段的事情。很多初學(xué)者會(huì)花大量時(shí)間去調(diào)箭頭顏色結(jié)果業(yè)務(wù)邏輯還沒理清楚完全本末倒置。5. 把Skill接入主流AI編程助手路徑、驗(yàn)證與邊界5.1 三個(gè)主流環(huán)境下的Skill放入路徑下面是我目前知道的幾種常用接入方式不同工具版本可能有差異建議以官方文檔為準(zhǔn)AI編程助手常見Skill放置位置加載邏輯Claude Code~/.claude/skills/skill-name/SKILL.md根據(jù)任務(wù)描述自動(dòng)匹配并加載Cursor項(xiàng)目?jī)?nèi).cursor/skills/skill-name/SKILL.md或 Rules 目錄結(jié)合項(xiàng)目上下文觸發(fā)Codex CLI~/.codex/skills/skill-name/SKILL.md或AGENTS.md類似指令文件按規(guī)則加載5.2 接入后的第一個(gè)驗(yàn)證用例裝完之后我建議拿一個(gè)最簡(jiǎn)單的需求驗(yàn)證Skill是否生效。比如直接輸入“畫一張圖輸入10個(gè)數(shù)輸出其中最大的數(shù)?！比绻鸄I只是隨手畫了一個(gè)非常普通的圖沒有任何先文本后代碼的流程說明Skill沒有被識(shí)別。如果AI先給出一份編號(hào)清晰、分支明確的文本再基于文本輸出可渲染代碼說明技能包正常加載了。這個(gè)驗(yàn)證很關(guān)鍵因?yàn)楹芏嗳搜b完Skill后根本不知道有沒有生效就開始問復(fù)雜業(yè)務(wù)問題最后只能用普通Prompt硬跑效果自然不穩(wěn)定。5.3 Skill與普通Prompt的本質(zhì)區(qū)別很多時(shí)候團(tuán)隊(duì)問我到底要不要花時(shí)間做Skill直接寫Prompt不行嗎我一般這樣解釋普通Prompt是一次性的口頭叮囑說完就忘了。Skill是固化的標(biāo)準(zhǔn)作業(yè)程序放在項(xiàng)目倉庫里人人都可以復(fù)用。普通Prompt遇到復(fù)雜場(chǎng)景時(shí)很容易漏關(guān)鍵約束Skill則把關(guān)鍵約束寫死在文件里每次加載都會(huì)自動(dòng)帶上。從協(xié)作角度看Skill也更像一個(gè)可以評(píng)審、測(cè)試、迭代的“代碼資產(chǎn)”。這個(gè)資產(chǎn)可以進(jìn)Git可以打標(biāo)簽可以通過PR更新有問題時(shí)能快速回滾。普通Prompt在這些事情上完全無法管理。6. 我調(diào)試這個(gè)Skill時(shí)踩過的四個(gè)坑和最終解法6.1 坑一模型“不聽話”直接甩一大段渲染代碼我第一版Skill運(yùn)行得很差原因是我只在正文里寫了“建議按文本輸出”但模型往往直接生成完整圖表代碼。后來我把規(guī)則從“建議”改成“必須”并且在前言里寫明了強(qiáng)制性的處理順序。效果立刻不一樣。這背后其實(shí)是模型對(duì)指令優(yōu)先級(jí)的問題。你需要清楚告訴模型技能包里的規(guī)則在這個(gè)場(chǎng)景下優(yōu)先于默認(rèn)行為。換句話說寫Skill時(shí)語氣要像在寫代碼約束而不是寫建議文檔。6.2 坑二分支條件擠在一行渲染混亂早期版本我把分支寫成這樣“判斷角色如果是管理員就進(jìn)首頁如果不是就返回登錄?！盇I在生成圖表時(shí)常常分不清條件和動(dòng)作的邊界渲染結(jié)果亂套。后來我在Skill里嚴(yán)格定義了分支格式條件寫在節(jié)點(diǎn)行內(nèi)后面用-指向跳轉(zhuǎn)目標(biāo)目標(biāo)和分支都用縮進(jìn)方式排列。模型對(duì)固定格式的遵循程度遠(yuǎn)高于自由發(fā)揮這點(diǎn)非常關(guān)鍵。6.3 坑三復(fù)雜流程超過20個(gè)節(jié)點(diǎn)后完全失控有一次我處理跨部門流程一口氣寫了30多個(gè)節(jié)點(diǎn)。AI在生成圖表時(shí)先是漏掉了兩個(gè)節(jié)點(diǎn)然后又出現(xiàn)重復(fù)的箭頭。我意識(shí)到對(duì)模型來說長(zhǎng)流程的直接渲染是容易出錯(cuò)的。我的解法是在Skill里加入“子流程拆分”規(guī)則超過20個(gè)節(jié)點(diǎn)就拆成子流程用編號(hào)引用。主流程只保留骨架細(xì)節(jié)統(tǒng)一放子流程里。這樣既減輕了模型的認(rèn)知負(fù)擔(dān)也讓整體結(jié)構(gòu)更清晰。6.4 坑四多人協(xié)作時(shí)各改各的版本一團(tuán)亂團(tuán)隊(duì)里幾個(gè)人同時(shí)用同一個(gè)Skill但各自有各自的偏好有人喜歡中文節(jié)點(diǎn)有人用英文ID改出來的圖五花八門。后來我在Skill里加了輸出規(guī)范節(jié)點(diǎn)ID一律用數(shù)字編號(hào)標(biāo)簽一律用中文分支狀態(tài)在條件里明確寫出。規(guī)范定死之后所有人的產(chǎn)物風(fēng)格一致Git diff看起來清晰很多評(píng)審效率也上來了。這其實(shí)也說明了一個(gè)道理Skill的維護(hù)和更新跟代碼里定規(guī)范一樣需要持續(xù)投入。7. 這套文本化流程圖的思路后來還幫我做了這些事用順了這個(gè)流程圖Skill之后我發(fā)現(xiàn)“邏輯先文本化渲染交給工具”的思路其實(shí)能推廣到更多地方。比如我把它擴(kuò)展成了“狀態(tài)機(jī)文本化”和“時(shí)序圖文本化”做法幾乎一樣描述狀態(tài)和事件AI生成文案再讓工具渲染成圖?，F(xiàn)在我在寫設(shè)計(jì)文檔時(shí)也習(xí)慣先寫一段結(jié)構(gòu)化文本描述模塊邊界再貼進(jìn)文檔站點(diǎn)自動(dòng)出圖。甚至在代碼評(píng)審的時(shí)候我會(huì)用一小段流程文本說明調(diào)用鏈路評(píng)審人員不用看一大坨代碼就能理解設(shè)計(jì)意圖。這套方法那些“圖改著改著就崩了”的問題算是徹底告別了。如果你也天天被流程圖折磨真心建議你今天花半小時(shí)寫一個(gè)自己的Skill然后把畫布關(guān)掉。