先說(shuō)一句大實(shí)話在微服務(wù)和生成式AI鋪天蓋地的今天還愿意把數(shù)據(jù)流圖拎出來(lái)一個(gè)字一個(gè)字地講已經(jīng)算是稀有動(dòng)物了。可偏偏就是這些看著過(guò)時(shí)的東西在真正解決復(fù)雜業(yè)務(wù)梳理時(shí)比任何花哨的架構(gòu)圖都頂用。我最近把某主流建模平臺(tái)上的AI能力完整過(guò)了一遍又順手用它把一個(gè)訂單系統(tǒng)的數(shù)據(jù)流圖從上下文級(jí)別一路拆到第三層整個(gè)過(guò)程讓我對(duì)“自頂向下分解”這件事有了完全不一樣的理解——以前這活兒靠人肉一層層畫現(xiàn)在靠提示詞和對(duì)話式AI就能把臟活累活吃掉一大半但真正決定圖形質(zhì)量的還是你對(duì)業(yè)務(wù)邊界和父子關(guān)系的那點(diǎn)判斷力。這篇文章不會(huì)跟你聊太高深的AI原理也不打算復(fù)述官方文檔。我只想從一個(gè)每天跟圖和模型打交道的人的角度把“數(shù)據(jù)流圖自頂向下分解”的完整步驟、某平臺(tái)AI生態(tài)里到底哪些功能能直接用在DFD上、以及我在實(shí)操里踩過(guò)的坑一次性講清楚。適合誰(shuí)看剛接觸DFD的分析師、被逼著畫圖又不會(huì)畫的開(kāi)發(fā)、還有想用AI提效但沒(méi)找到門道的架構(gòu)與產(chǎn)品同學(xué)都能從里面拿走點(diǎn)能直接用的東西。1. 為什么到現(xiàn)在還在講數(shù)據(jù)流圖它到底解決什么問(wèn)題1.1 復(fù)雜度不是被AI消滅的而是被結(jié)構(gòu)化拆解的很多團(tuán)隊(duì)現(xiàn)在一拿到新項(xiàng)目就急著建數(shù)據(jù)庫(kù)表、寫接口文檔、畫界面原型結(jié)果系統(tǒng)上線三個(gè)月后開(kāi)始頻繁返工因?yàn)榘l(fā)現(xiàn)業(yè)務(wù)邊界從一開(kāi)始就是糊的。數(shù)據(jù)流圖的價(jià)值恰恰在于它逼著你先把“數(shù)據(jù)從哪里來(lái)、經(jīng)過(guò)哪些處理、存到哪里、輸出給誰(shuí)”理清楚然后才允許你碰實(shí)現(xiàn)細(xì)節(jié)。你可能會(huì)說(shuō)這不就是業(yè)務(wù)流程圖嗎差遠(yuǎn)了。業(yè)務(wù)流程圖關(guān)心的是職責(zé)流轉(zhuǎn)和審批路徑數(shù)據(jù)流圖關(guān)心的是數(shù)據(jù)的加工、存儲(chǔ)、流動(dòng)節(jié)奏。同樣一個(gè)訂單創(chuàng)建場(chǎng)景流程圖會(huì)畫出“用戶提交→客服審核→倉(cāng)庫(kù)發(fā)貨”而數(shù)據(jù)流圖會(huì)畫出“訂單數(shù)據(jù)從用戶終端流入系統(tǒng)被訂單處理過(guò)程讀取后寫入訂單存儲(chǔ)同時(shí)產(chǎn)生通知數(shù)據(jù)流向消息隊(duì)列”。前者是在講業(yè)務(wù)故事后者是在講數(shù)據(jù)契約。這種契約關(guān)系恰恰是后來(lái)做接口設(shè)計(jì)、庫(kù)表拆分、異步解耦時(shí)最容易出問(wèn)題的環(huán)節(jié)。1.2 自頂向下分解是這個(gè)方法的靈魂不是可選項(xiàng)數(shù)據(jù)流圖最核心的方法論就是“自頂向下、逐層分解”。你不用在第一版就把所有細(xì)節(jié)畫全而是先從黑盒視角建立上下文再一層層放大看內(nèi)部。這種思路和人類理解復(fù)雜事物的方式天然一致——先看地圖再看街道最后才研究某個(gè)路口紅綠燈的配時(shí)邏輯。某平臺(tái)AI生態(tài)出現(xiàn)之后很多人以為AI能直接生成一張完美的頂層圖結(jié)果發(fā)現(xiàn)它生成的第一版往往是把所有過(guò)程堆在一起的大雜燴。原因很簡(jiǎn)單大模型訓(xùn)練數(shù)據(jù)里的“完美DFD”來(lái)自于已經(jīng)分解完畢的形態(tài)而不是你正在經(jīng)歷的混沌初始狀態(tài)。但AI真正好用的地方是它擅長(zhǎng)從你的碎片化輸入中提煉出候選實(shí)體、候選過(guò)程、數(shù)據(jù)流向關(guān)系然后讓你像剝洋蔥一樣逐層展開(kāi)。換句話說(shuō)AI不是替你做分解而是幫你把分解的速度提上去把遺漏攤在桌面上。提示自頂向下分解的四層基本邊界——系統(tǒng)上下文、一級(jí)子系統(tǒng)、二級(jí)業(yè)務(wù)過(guò)程、三級(jí)基礎(chǔ)動(dòng)作——不是死的。我見(jiàn)過(guò)醫(yī)院信息系統(tǒng)畫到六級(jí)還剎不住車也見(jiàn)過(guò)創(chuàng)業(yè)公司一個(gè)二級(jí)圖就能講清楚整個(gè)MVP。什么時(shí)候停取決于你畫圖的目的是給人評(píng)審還是給代碼落地。1.3 標(biāo)題里藏著一個(gè)“AI生態(tài)系統(tǒng)”它到底是個(gè)什么物種“AI生態(tài)系統(tǒng)”聽(tīng)起來(lái)很高端說(shuō)穿了就是建模工具里嵌了一組能輔助建模的AI服務(wù)比如提示詞生成模型、模型一致性校驗(yàn)、圖表解說(shuō)、自動(dòng)補(bǔ)全等等。它們不負(fù)責(zé)創(chuàng)造業(yè)務(wù)智慧只負(fù)責(zé)把你腦袋里那點(diǎn)還沒(méi)成型的需求描述翻譯成結(jié)構(gòu)化的模型雛形。在DFD場(chǎng)景里這套生態(tài)能干的活主要有四類把自然語(yǔ)言需求初步轉(zhuǎn)化成上下文圖或一級(jí)數(shù)據(jù)流圖在你畫完父圖后自動(dòng)建議子過(guò)程的拆分粒度檢查父圖與子圖之間數(shù)據(jù)流不對(duì)應(yīng)、過(guò)程編號(hào)不匹配等問(wèn)題對(duì)當(dāng)前圖的業(yè)務(wù)場(chǎng)景生成一段說(shuō)明文字方便評(píng)審會(huì)議裝進(jìn)PPT我不建議你把AI生成的第一版圖當(dāng)作最終交付物。它的產(chǎn)出大概率有三種問(wèn)題命名太抽象比如“數(shù)據(jù)處理”這種誰(shuí)都看不懂的名字、過(guò)程邊界混在一起、數(shù)據(jù)流名稱和實(shí)際字段對(duì)不上。但你完全可以拿它當(dāng)“草稿引擎”在這個(gè)基礎(chǔ)上快速迭代。2. 實(shí)操前的認(rèn)知準(zhǔn)備數(shù)據(jù)流圖自頂向下分解的底層盤面2.1 你至少得先分清這幾種圖符否則AI也救不了你DFD和UML類圖不同它只有四種基本元素但就是這四種元素新手至少要錯(cuò)三回。外部實(shí)體是系統(tǒng)邊界之外的人和系統(tǒng)比如“顧客”“銀行支付網(wǎng)關(guān)”“倉(cāng)庫(kù)管理系統(tǒng)”。它們負(fù)責(zé)數(shù)據(jù)的發(fā)源和終結(jié)但不能被分解。處理過(guò)程是整個(gè)圖的核心表示數(shù)據(jù)在這里發(fā)生變換比如“校驗(yàn)訂單”“計(jì)算運(yùn)費(fèi)”“生成對(duì)賬單”。數(shù)據(jù)存儲(chǔ)是數(shù)據(jù)的靜止?fàn)顟B(tài)比如“訂單表”“庫(kù)存臺(tái)賬”“操作日志”。數(shù)據(jù)流是箭頭代表數(shù)據(jù)的移動(dòng)它必須有名字而且名字應(yīng)該是名詞不是動(dòng)詞。我見(jiàn)過(guò)最典型的錯(cuò)誤是把“發(fā)送郵件通知”畫成外部實(shí)體因?yàn)榻Ｕ哂X(jué)得這個(gè)動(dòng)作是外部系統(tǒng)做的。其實(shí)只要這個(gè)動(dòng)作發(fā)生在你開(kāi)發(fā)的系統(tǒng)內(nèi)部哪怕它是調(diào)用了一個(gè)第三方郵件API邏輯上依然應(yīng)該是一個(gè)處理過(guò)程“發(fā)送郵件通知”而第三方平臺(tái)才是外部實(shí)體。AI生成的圖也經(jīng)?？ㄔ谶@里——它無(wú)法替你判斷某個(gè)功能到底屬于系統(tǒng)內(nèi)部還是系統(tǒng)外部這個(gè)邊界只有畫圖的人自己清楚。2.2 父圖與子圖的守恒關(guān)系是分解質(zhì)量的生命線自頂向下分解最難的不是畫而是保證上下層級(jí)嚴(yán)格對(duì)應(yīng)。這里有一條鐵律父圖中每一個(gè)處理過(guò)程在下一層都必須有一張子圖來(lái)展開(kāi)子圖的輸入輸出數(shù)據(jù)流必須與父圖中連接該過(guò)程的數(shù)據(jù)流完全一致。這就是有名的數(shù)據(jù)流守恒原則。用生活化一點(diǎn)的話說(shuō)你在頂層答應(yīng)給別人送一輛完整的汽車拆到第二層就不能只交付發(fā)動(dòng)機(jī)更不能自己偷偷加一個(gè)油箱蓋。數(shù)據(jù)守恒就是確保每一層拆完之后“接口承諾”沒(méi)變。某平臺(tái)的AI生態(tài)在這里給了很大的甜頭當(dāng)你畫完二級(jí)圖AI可以自動(dòng)對(duì)比父圖過(guò)程中掛接的數(shù)據(jù)流和子圖邊界的輸入輸出標(biāo)記出哪些在父層有但子層消失了哪些子層憑空多出來(lái)了。這在純手工時(shí)代是要拿眼球逐條盯的體力活現(xiàn)在幾秒就出結(jié)果。注意數(shù)據(jù)守恒指的是數(shù)據(jù)流的邏輯一致性不是名稱的逐字復(fù)制。父圖里的數(shù)據(jù)流叫“用戶信息”子圖里拆成“用戶基礎(chǔ)資料”和“用戶偏好設(shè)置”是允許的前提是你清楚后者是前者的拆解結(jié)果。但如果你在子圖里莫名出現(xiàn)一條“商品推薦結(jié)果”父圖中卻沒(méi)有對(duì)應(yīng)數(shù)據(jù)流那就是典型的非法新增。2.3 分層不是畫地圖每一層都在回答不同的業(yè)務(wù)問(wèn)題頂層上下文圖回答的是“系統(tǒng)站在世界面前它跟誰(shuí)交互”。一級(jí)圖回答的是“系統(tǒng)內(nèi)部主要分成幾條業(yè)務(wù)主線”。二級(jí)圖回答的是“每條主線里數(shù)據(jù)具體經(jīng)過(guò)了哪幾個(gè)關(guān)鍵加工環(huán)節(jié)”。到了三級(jí)、四級(jí)關(guān)心的就是某個(gè)加工的詳細(xì)輸入輸出規(guī)則了。很多團(tuán)隊(duì)把DFD畫不下去不是因?yàn)槟芰Σ粔蚨且驗(yàn)樵阱e(cuò)誤的層級(jí)糾結(jié)錯(cuò)誤的問(wèn)題。比如在上下文圖階段就考慮“訂單狀態(tài)字段應(yīng)該放在哪個(gè)存儲(chǔ)里”——這等于還沒(méi)學(xué)會(huì)走就開(kāi)始想跑步。正確的做法是層級(jí)越高越關(guān)注邊界與交互層級(jí)越低越關(guān)注加工邏輯與存儲(chǔ)方案。AI生態(tài)在這里的作用是讓每一層都保持相對(duì)干凈的粒度你給AI一個(gè)“繼續(xù)往下拆”的指令它會(huì)基于當(dāng)前的模型狀態(tài)去推測(cè)可能的子過(guò)程而不會(huì)強(qiáng)行把不相干的需求塞進(jìn)來(lái)。3. 某平臺(tái)AI生態(tài)的核心能力盤點(diǎn)哪些是DFD分解的真朋友3.1 提示詞生成模型從一句話到一張初稿圖這是整個(gè)AI生態(tài)里最先被用到也是最容易讓人誤判的功能。它的基本用法很簡(jiǎn)單你在輸入框里描述需求比如“一個(gè)顧客通過(guò)電商平臺(tái)下單系統(tǒng)進(jìn)行庫(kù)存檢查、訂單確認(rèn)與支付處理并最終把訂單信息寫入數(shù)據(jù)庫(kù)”模型會(huì)嘗試返回一個(gè)包含外部實(shí)體、處理過(guò)程、數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)流的模型結(jié)構(gòu)。但這個(gè)初稿的質(zhì)量高度依賴你輸入的精準(zhǔn)程度。我發(fā)現(xiàn)一個(gè)規(guī)律輸入里包含具體名詞訂單、庫(kù)存、支付、物流時(shí)生成結(jié)果可以少改一半輸入全是抽象動(dòng)詞處理、管理、維護(hù)時(shí)AI基本會(huì)生成一個(gè)“四不像”——表面上結(jié)構(gòu)完整實(shí)際上每個(gè)節(jié)點(diǎn)都沒(méi)法落地。我比較推薦的做法是先把需求寫成一個(gè)“主語(yǔ)謂語(yǔ)賓語(yǔ)”的事件清單再交給AI。比如不寫“系統(tǒng)需要管理訂單相關(guān)事宜”而是寫“顧客提交訂單”“系統(tǒng)校驗(yàn)庫(kù)存”“系統(tǒng)生成支付請(qǐng)求”“支付網(wǎng)關(guān)返回結(jié)果”“系統(tǒng)更新訂單狀態(tài)”。這個(gè)清單喂給AI之后生成的一級(jí)圖骨架通常能保留八成以上過(guò)程命名也相對(duì)貼近業(yè)務(wù)。3.2 模型校正與一致性校驗(yàn)專門抓你看不見(jiàn)的漏傳統(tǒng)建模工具里一致性校驗(yàn)通?？坎寮蚴止z查做得好的也大多是語(yǔ)法級(jí)檢查比如“某個(gè)數(shù)據(jù)流沒(méi)有源或目標(biāo)”。到了AI生態(tài)這一代校驗(yàn)開(kāi)始具備語(yǔ)義判斷能力。它會(huì)模擬一個(gè)“較真的分析師”角色檢查每個(gè)處理過(guò)程是否真的有輸入輸出、每個(gè)數(shù)據(jù)存儲(chǔ)是否真的被讀或?qū)?、每條數(shù)據(jù)流的命名是否符合“名詞性”規(guī)范。我實(shí)際測(cè)試的時(shí)候它還真給我揪出過(guò)一個(gè)問(wèn)題我在二級(jí)圖里畫了一個(gè)“生成發(fā)票”的處理過(guò)程它只有輸出數(shù)據(jù)流“發(fā)票數(shù)據(jù)”沒(méi)有輸入。邏輯上發(fā)票不可能憑空生成必須有訂單信息和客戶信息作為輸入。AI提示“該過(guò)程缺少輸入數(shù)據(jù)流”我順著補(bǔ)了兩條數(shù)據(jù)流后來(lái)評(píng)審現(xiàn)場(chǎng)才沒(méi)被別人問(wèn)住。3.3 與圖對(duì)話你問(wèn)它答老模型也能秒變業(yè)務(wù)文檔“與圖對(duì)話”是我個(gè)人覺(jué)得被低估的功能。它的交互方式是你選中某張DFD圖然后直接跟AI對(duì)話問(wèn)“這個(gè)圖里訂單處理過(guò)程中間有哪些數(shù)據(jù)存儲(chǔ)被訪問(wèn)”它會(huì)結(jié)合圖結(jié)構(gòu)回答并且給你標(biāo)注節(jié)點(diǎn)。這個(gè)功能在兩種場(chǎng)景下格外有用第一你接手的是一張前人畫的陳年舊圖沒(méi)人給你講背景第二要臨時(shí)做項(xiàng)目匯報(bào)但又沒(méi)有時(shí)間從頭看模型。對(duì)我來(lái)說(shuō)它更實(shí)在的價(jià)值是反向解釋。有時(shí)候AI生成的過(guò)程命名太抽象我看不懂某個(gè)過(guò)程的職責(zé)直接在圖里問(wèn)一句“這個(gè)校驗(yàn)訂單的過(guò)程到底做了什么”它能結(jié)合輸入輸出數(shù)據(jù)流給出合理推測(cè)。雖然這個(gè)推測(cè)不一定完全正確但作為理解切入點(diǎn)的效率比逐條看數(shù)據(jù)流高很多。3.4 生成解釋文本評(píng)審PPT的救星每個(gè)畫過(guò)DFD的人都經(jīng)歷過(guò)這種尷尬圖明明畫得很清楚但一到評(píng)審會(huì)議上從第一張圖開(kāi)始講解講不到五分鐘就邏輯亂套。AI生態(tài)里的解釋文本生成功能可以在你選中的圖層上自動(dòng)生成一段段落式的說(shuō)明文字把外部實(shí)體、主要處理過(guò)程、數(shù)據(jù)流走向、關(guān)鍵存儲(chǔ)都串成一個(gè)順暢的業(yè)務(wù)故事。這個(gè)功能有個(gè)隱藏用法把生成的不同層級(jí)解釋文本拼在一起稍作修正其實(shí)就是一份不錯(cuò)的系統(tǒng)分析說(shuō)明書(shū)初稿。你不用額外花時(shí)間寫文檔直接從模型里導(dǎo)出再潤(rùn)色細(xì)節(jié)省掉了一整天的活兒。4. 實(shí)操全流程用AI生態(tài)把一個(gè)訂單處理系統(tǒng)從零拆到可落地的三級(jí)圖4.1 第一步準(zhǔn)備需求素材喂給AI之前你要干的事我不會(huì)一上來(lái)就打開(kāi)建模工具而是先在文檔里把業(yè)務(wù)從頭到尾“講”一遍。以當(dāng)時(shí)那個(gè)訂單處理系統(tǒng)為例我整理出的信息大概是這樣用戶可以瀏覽商品、下單、付款、查看訂單狀態(tài)管理員可以管理商品信息、處理退款、查看銷售報(bào)表系統(tǒng)依賴庫(kù)存系統(tǒng)和第三方支付網(wǎng)關(guān)訂單創(chuàng)建后要經(jīng)歷庫(kù)存預(yù)占、支付確認(rèn)、發(fā)貨通知三個(gè)階段整個(gè)流程產(chǎn)生的數(shù)據(jù)需要落庫(kù)包括用戶數(shù)據(jù)、商品數(shù)據(jù)、訂單數(shù)據(jù)、支付流水這段描述沒(méi)有結(jié)構(gòu)化但信息密度足夠。我把它拆成大約十幾條事件描述每一條都盡量用“主語(yǔ)動(dòng)作數(shù)據(jù)對(duì)象”的結(jié)構(gòu)然后作為提示詞發(fā)給AI。這個(gè)準(zhǔn)備階段永遠(yuǎn)不要省略因?yàn)锳I生成的質(zhì)量上限就是你輸入的信息上限。4.2 第二步生成上下文圖并快速修正邊界我輸入的核心提示大概是這樣的請(qǐng)為一個(gè)電商訂單處理系統(tǒng)生成上下文級(jí)數(shù)據(jù)流圖包含外部實(shí)體、系統(tǒng)邊界、與外部實(shí)體之間的數(shù)據(jù)流外部實(shí)體包括顧客、管理員、庫(kù)存系統(tǒng)、支付網(wǎng)關(guān)。AI返回的上下文圖骨架基本可用但有一個(gè)明顯問(wèn)題它把“管理員”這個(gè)外部實(shí)體掛進(jìn)來(lái)的數(shù)據(jù)流寫成了“管理請(qǐng)求”太泛沒(méi)法指導(dǎo)后續(xù)分解。我改成三條具體數(shù)據(jù)流商品管理信息、退款審核請(qǐng)求、銷售報(bào)表查詢。這個(gè)修改看著不大但影響深遠(yuǎn)——上下文圖的數(shù)據(jù)流最終會(huì)決定一級(jí)圖的處理過(guò)程劃分。實(shí)操提示上下文圖的數(shù)據(jù)流數(shù)量一般在5到10條之間比較合適。如果超過(guò)15條說(shuō)明系統(tǒng)邊界沒(méi)劃好大量本該屬于內(nèi)部處理的功能被錯(cuò)誤地外溢到了外部交互層。4.3 第三步從上下文圖拆出一級(jí)圖用AI提議人工勾選一級(jí)圖是對(duì)系統(tǒng)內(nèi)部主線的劃分。我把上下文圖里系統(tǒng)的核心處理過(guò)程設(shè)置好然后讓AI給一級(jí)過(guò)程拆解建議。它給我的方案大致是商品管理、訂單處理、支付處理、庫(kù)存協(xié)同、報(bào)表統(tǒng)計(jì)。這五個(gè)過(guò)程方向沒(méi)毛病但我做了一次關(guān)鍵調(diào)整把“庫(kù)存協(xié)同”并入了“訂單處理”理由是庫(kù)存預(yù)占和釋放與訂單狀態(tài)變更的耦合度過(guò)高分開(kāi)畫會(huì)引入一堆跨過(guò)程的數(shù)據(jù)流反而增加理解成本。這一步體現(xiàn)了人的價(jià)值——AI給的是一個(gè)按領(lǐng)域均勻劃分的方案但實(shí)際建模時(shí)過(guò)程劃分要考慮耦合度和事務(wù)邊界。調(diào)整后的一級(jí)圖包含三個(gè)處理過(guò)程商品管理、訂單處理、報(bào)表統(tǒng)計(jì)。外部實(shí)體顧客通過(guò)“訂單信息”與訂單處理交互支付網(wǎng)關(guān)通過(guò)“支付請(qǐng)求/支付結(jié)果”與訂單處理交互庫(kù)存系統(tǒng)通過(guò)“庫(kù)存預(yù)占請(qǐng)求/庫(kù)存確認(rèn)結(jié)果”與訂單處理交互。管理員還是和商品管理、報(bào)表統(tǒng)計(jì)交互。圖面干凈很多。4.4 第四步鎖定訂單處理過(guò)程向下展開(kāi)二級(jí)圖一級(jí)圖確認(rèn)后最核心的工作就是對(duì)“訂單處理”進(jìn)行二級(jí)分解。我先選中這個(gè)處理過(guò)程在AI輔助下請(qǐng)求拆分建議。AI結(jié)合父圖的數(shù)據(jù)流輸入輸出給出了一個(gè)初步二級(jí)過(guò)程列表校驗(yàn)訂單、預(yù)占庫(kù)存、發(fā)起支付、處理支付回調(diào)、更新訂單狀態(tài)、生成發(fā)貨通知。這里我做了幾次修正“預(yù)占庫(kù)存”和“發(fā)起支付”在邏輯上有先后關(guān)系但因?yàn)樗鼈兎謱俨煌獠肯到y(tǒng)我保留了兩個(gè)獨(dú)立過(guò)程不合并?！案掠唵螤顟B(tài)”在AI初始建議里沒(méi)有單獨(dú)成過(guò)程被我手動(dòng)加進(jìn)去。因?yàn)橛唵螤顟B(tài)變化是整個(gè)系統(tǒng)里最關(guān)鍵的數(shù)據(jù)流轉(zhuǎn)中樞拆出來(lái)更便于后續(xù)維護(hù)狀態(tài)機(jī)?！靶ｒ?yàn)訂單”的命名被我改成“校驗(yàn)訂單信息與庫(kù)存可用性”這樣在三級(jí)圖里能明確知道它的驗(yàn)證范圍。二級(jí)圖的輸入輸出必須嚴(yán)格對(duì)標(biāo)父圖里“訂單處理”連接的數(shù)據(jù)流。AI在這里幫我做了守恒檢查父層有“訂單信息”“支付請(qǐng)求”“支付結(jié)果”“庫(kù)存預(yù)占請(qǐng)求”“庫(kù)存確認(rèn)結(jié)果”“發(fā)貨通知數(shù)據(jù)”我在二級(jí)圖邊界上逐一確認(rèn)這些數(shù)據(jù)流都存在沒(méi)有被改名改丟。4.5 第五步繼續(xù)下鉆關(guān)鍵子過(guò)程到三級(jí)圖就基本夠用對(duì)于這個(gè)系統(tǒng)我進(jìn)一步對(duì)“支付處理回調(diào)”和“更新訂單狀態(tài)”做了三級(jí)展開(kāi)。三級(jí)圖開(kāi)始出現(xiàn)具體的數(shù)據(jù)存儲(chǔ)比如“支付流水表”“訂單狀態(tài)表”“通知記錄表”處理過(guò)程偏向技術(shù)細(xì)節(jié)比如“驗(yàn)簽”“冪等校驗(yàn)”“事務(wù)更新”。到這個(gè)層級(jí)我已經(jīng)能夠把每個(gè)數(shù)據(jù)流對(duì)應(yīng)到接口請(qǐng)求參數(shù)或數(shù)據(jù)庫(kù)字段級(jí)別開(kāi)發(fā)拿到圖之后可以直接開(kāi)始設(shè)計(jì)接口。如果一個(gè)系統(tǒng)還需要再往下拆我通常會(huì)停下來(lái)反問(wèn)自己是系統(tǒng)的業(yè)務(wù)復(fù)雜性真的有這么高還是我為了畫圖而畫圖4.6 第六步AI一致性校驗(yàn)與人工評(píng)審的最后一公里所有層級(jí)畫完后我用AI生態(tài)里的一致性校驗(yàn)功能對(duì)整個(gè)模型跑了一遍。它給出的問(wèn)題有兩類一類是缺漏比如“生成發(fā)貨通知”過(guò)程缺少對(duì)“訂單信息存儲(chǔ)”的讀取另一類是命名不統(tǒng)一比如父圖里叫“支付結(jié)果”二級(jí)圖里卻叫“支付回調(diào)結(jié)果”。這兩類問(wèn)題如果不揪出來(lái)到了編碼階段就會(huì)變成程序里的空指針和字段映射錯(cuò)誤。人工評(píng)審我一般會(huì)拉上業(yè)務(wù)方和開(kāi)發(fā)一起看。業(yè)務(wù)方負(fù)責(zé)確認(rèn)過(guò)程和真實(shí)業(yè)務(wù)動(dòng)作是否一致開(kāi)發(fā)負(fù)責(zé)確認(rèn)數(shù)據(jù)的可落地性。這一步不能省因?yàn)锳I校驗(yàn)解決的是邏輯關(guān)系但業(yè)務(wù)理解只有人才有。5. 關(guān)鍵參數(shù)與細(xì)節(jié)決策分解粒度、命名規(guī)范、父子對(duì)應(yīng)5.1 分解的粒度怎么判斷“到此為止”有一個(gè)我用了很久的判斷標(biāo)準(zhǔn)如果當(dāng)前層級(jí)的每個(gè)處理過(guò)程都能在半小時(shí)內(nèi)跟開(kāi)發(fā)講清楚輸入輸出和基本邏輯就不用再拆了。如果一個(gè)過(guò)程還需要畫三四張子圖才能講明白說(shuō)明它欠拆。更工程化的參考標(biāo)準(zhǔn)是三級(jí)圖以下的處理過(guò)程大概率會(huì)對(duì)應(yīng)到未來(lái)具體的函數(shù)或模塊二級(jí)圖的過(guò)程對(duì)應(yīng)到服務(wù)或子系統(tǒng)一級(jí)圖的過(guò)程對(duì)應(yīng)到主業(yè)務(wù)流程主線。對(duì)于多數(shù)管理系統(tǒng)拆到三級(jí)夠用對(duì)于涉及復(fù)雜算法或底層引擎的系統(tǒng)拆到四級(jí)甚至五級(jí)都不夸張。5.2 命名規(guī)范可以很土但必須是“數(shù)據(jù)語(yǔ)言”AI生成的過(guò)程命名通常帶著一股“學(xué)術(shù)腔”比如“數(shù)據(jù)聚合處理”“信息管理中樞”。這些名字放在PPT里唬人可以放在DFD里是災(zāi)難。DFD的命名要遵循兩個(gè)原則第一處理過(guò)程用動(dòng)詞開(kāi)頭說(shuō)明行為第二數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)用名詞說(shuō)明數(shù)據(jù)對(duì)象千萬(wàn)不要用“數(shù)據(jù)信息”“相關(guān)數(shù)據(jù)”這種什么都包含又什么都沒(méi)說(shuō)的詞。我給AI輸出的一次修正命名是這樣的把“數(shù)據(jù)處理”改成“更新訂單狀態(tài)”把“信息交換”改成“同步庫(kù)存數(shù)據(jù)”把“歸檔管理”改成“生成訂單歸檔記錄”。改名之后整張圖的可讀性提升幾個(gè)檔次后續(xù)在AI對(duì)話里提問(wèn)也會(huì)得到更準(zhǔn)確的回答。5.3 父子圖編號(hào)體系從第一天就要嚴(yán)格建很多新手在畫子圖的時(shí)候不建立編號(hào)映射導(dǎo)致父子圖之間靠人腦記憶關(guān)聯(lián)圖一多必亂。標(biāo)準(zhǔn)化做法是上下文圖不編號(hào)一級(jí)過(guò)程編號(hào)1、2、3二級(jí)過(guò)程編號(hào)1.1、1.2、2.1、2.2這樣一直延伸。數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)也最好有簡(jiǎn)短編碼比如D1代表用戶數(shù)據(jù)存儲(chǔ)F1-1代表訂單處理子系統(tǒng)的輸入數(shù)據(jù)流。某平臺(tái)的AI生態(tài)在識(shí)別編號(hào)映射方面表現(xiàn)不錯(cuò)。當(dāng)你在AI對(duì)話框里問(wèn)“1.1過(guò)程的數(shù)據(jù)流邊界是什么”它能基于模型上下文準(zhǔn)確回應(yīng)。如果編號(hào)混亂AI的表現(xiàn)也會(huì)跟著變傻所以我畫圖前會(huì)先把編號(hào)規(guī)則跟團(tuán)隊(duì)交代清楚。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄6.1 AI生成圖的過(guò)程邊界總是重合怎么辦最常遇到的情況是AI把“校驗(yàn)訂單”和“計(jì)算訂單金額”合并成一個(gè)過(guò)程或者把“支付回調(diào)”和“訂單狀態(tài)更新”分成兩個(gè)獨(dú)立過(guò)程但之間沒(méi)有任何數(shù)據(jù)流。遇到這種問(wèn)題不要試圖通過(guò)微調(diào)提示詞來(lái)徹底解決——質(zhì)變的關(guān)鍵在于你自己先把最關(guān)鍵的業(yè)務(wù)序列列出來(lái)再要求AI按給定序列生成。我試過(guò)在提示詞里加上一句“請(qǐng)按以下業(yè)務(wù)順序拆解處理過(guò)程檢查商品是否存在→校驗(yàn)庫(kù)存→計(jì)算金額→創(chuàng)建訂單→扣減庫(kù)存→發(fā)起支付”這樣生成的邊界就正常很多。AI畢竟是個(gè)語(yǔ)言模型它需要你給它一根明確的主線。6.2 父圖有數(shù)據(jù)流子圖找不到排查的順序是什么先看子圖邊界上是不是漏畫了出入口數(shù)據(jù)流再看同樣的數(shù)據(jù)是不是在子圖內(nèi)部換了個(gè)名字再看數(shù)據(jù)流是不是被某個(gè)處理過(guò)程“吞掉”了而沒(méi)有向下傳遞。我習(xí)慣用AI的一致性校驗(yàn)先自動(dòng)掃一遍再看它標(biāo)記的高概率問(wèn)題最后人工重點(diǎn)盯“從存儲(chǔ)直接到外部實(shí)體”這種不走處理過(guò)程的非法直連。6.3 提示詞寫了很多AI卻只返回了一堆總結(jié)性文字這個(gè)問(wèn)題十有八九是因?yàn)槟愕男枨竺枋隼锶狈Α翱杀唤Y(jié)構(gòu)化的動(dòng)作”。AI如果沒(méi)法從你的話里提取出過(guò)程的輸入、輸出、存儲(chǔ)關(guān)系它就會(huì)退回語(yǔ)言模型的默認(rèn)安全行為——給你輸出一段正確但沒(méi)有建模價(jià)值的廢話。解決辦法是改用事件清單的方式輸入每條都寫成“誰(shuí)→對(duì)什么數(shù)據(jù)→做了什么”然后再加一句“請(qǐng)將上述事件轉(zhuǎn)換為DFD結(jié)構(gòu)”。6.4 多人協(xié)作時(shí)AI改動(dòng)覆蓋了隊(duì)友的細(xì)節(jié)怎么辦某平臺(tái)AI生態(tài)在協(xié)作場(chǎng)景下和普通在線文檔一樣存在版本沖突問(wèn)題。我會(huì)在每次AI生成或大量修改之前先保存一個(gè)命名清晰的版本比如“訂單系統(tǒng)-二級(jí)圖-人工修正版”。一個(gè)額外的習(xí)慣是AI的自動(dòng)建議功能可以設(shè)置成“僅生成草案”而不是直接覆蓋原圖這樣AI的任何輸出都先進(jìn)入一個(gè)待審查圖層。這個(gè)習(xí)慣幫我躲過(guò)了好幾次“AI覺(jué)得好就亂改”的驚魂時(shí)刻。7. 走到最后說(shuō)幾句不吐不快的經(jīng)驗(yàn)在整個(gè)流程反復(fù)滾了若干遍之后我最大的體會(huì)是AI生態(tài)在某平臺(tái)上不是替你成為分析師而是把你變成了一個(gè)更耐心的分析師。過(guò)去畫一張三級(jí)圖我至少得花一整天去擺框、連線、改命名留給思考業(yè)務(wù)邏輯的時(shí)間其實(shí)不到三分之一?，F(xiàn)在AI承擔(dān)了擺框和檢查的雜活我的精力能集中到過(guò)程邊界的判斷、數(shù)據(jù)守恒的推敲、粒度的取舍上——這些才是DFD真正值錢的地方。最后再分享一個(gè)落地方案別追求讓AI一次性生成完美成品。先讓它給你一張“不低于及格線”的初稿然后按上下文→一級(jí)→二級(jí)→三級(jí)逐層確認(rèn)和修正。每修正完一層就把本層圖里的命名和編號(hào)固定下來(lái)再往下拆。這樣一步一步走你得到的不僅是一套能落地的數(shù)據(jù)流圖還有一套能講清楚來(lái)龍去脈的系統(tǒng)分析底稿。這套底稿比任何單張圖都更有長(zhǎng)期價(jià)值。