1. 為什么“能立刻復(fù)用”才是 AI 編程工作流的真正門檻我見過太多人收藏了幾百個(gè) AI 編程提示詞真正干活的時(shí)候還是一個(gè)一個(gè)手動(dòng)粘貼。問題不在于提示詞寫得不好而在于這些提示詞沒有被組織成工作流——也就是有固定輸入、固定處理鏈路、固定輸出格式的一套可重復(fù)執(zhí)行流程。所謂“能立刻復(fù)用”我的標(biāo)準(zhǔn)很樸素?fù)Q一個(gè)項(xiàng)目、換一個(gè)語言、換一個(gè)同事這套流程照樣跑得通不需要重新調(diào)教。它不依賴某個(gè)特定工具的付費(fèi)版本不依賴某次對(duì)話的上下文記憶更不依賴你當(dāng)時(shí)心情好不好、提示詞寫得全不全。這篇文章要拆的就是三個(gè)我自己在真實(shí)項(xiàng)目里反復(fù)用、反復(fù)改、最后穩(wěn)定下來的 AI 編程工作流。它們分別解決三類高頻場(chǎng)景讀陌生代碼庫(kù)、寫新功能模塊、排查和修復(fù)缺陷。三個(gè)工作流之間可以獨(dú)立使用也可以串起來形成一條從理解到交付的完整鏈路。適合誰看如果你已經(jīng)用過 AI 編程工具但總覺得“它給的代碼不太敢用”或者“每次都要重新解釋一遍背景”那這篇就是寫給你的。如果你還沒開始用也沒關(guān)系我會(huì)把每個(gè)環(huán)節(jié)的操作意圖和判斷標(biāo)準(zhǔn)講清楚你照著搭一遍就能跑。先給一個(gè)整體認(rèn)知AI 編程工作流的核心不是“讓 AI 寫代碼”而是把人的判斷力嵌入到 AI 的執(zhí)行鏈路里。純讓 AI 寫你得到的是不可控的文本把判斷點(diǎn)設(shè)計(jì)進(jìn)去你得到的是可復(fù)用的生產(chǎn)力。下面三個(gè)工作流每一個(gè)都圍繞這個(gè)原則展開。2. 工作流一陌生代碼庫(kù)的快速理解與地圖構(gòu)建2.1 這個(gè)工作流解決什么問題接手一個(gè)陌生項(xiàng)目時(shí)最耗時(shí)的不是寫代碼而是搞清楚“這個(gè)功能在哪、數(shù)據(jù)怎么流、改哪里不會(huì)炸”。傳統(tǒng)做法是順著入口文件一層層點(diǎn)進(jìn)去或者靠全局搜索關(guān)鍵詞碰運(yùn)氣。一個(gè)中型項(xiàng)目光建立基本認(rèn)知就要花掉半天到一天。這個(gè)工作流的目標(biāo)是在 30 分鐘內(nèi)產(chǎn)出一份可用的代碼庫(kù)地圖包含模塊劃分、關(guān)鍵調(diào)用鏈、數(shù)據(jù)流向和改動(dòng)風(fēng)險(xiǎn)點(diǎn)。它不是讓 AI 替你讀代碼而是讓 AI 幫你把讀代碼的結(jié)果結(jié)構(gòu)化你只需要驗(yàn)證和補(bǔ)充。2.2 操作步驟與關(guān)鍵細(xì)節(jié)第一步生成項(xiàng)目骨架摘要。把項(xiàng)目的目錄結(jié)構(gòu)用tree -L 3 -I node_modules|.git|dist這類命令導(dǎo)出排除依賴和構(gòu)建產(chǎn)物丟給 AI讓它輸出一份模塊職責(zé)說明。這里的關(guān)鍵是限制層級(jí)不要一上來就給全量文件列表否則 AI 會(huì)陷入細(xì)節(jié)你也讀不完。我通常用的提示詞結(jié)構(gòu)是這樣的以下是一個(gè)項(xiàng)目的目錄結(jié)構(gòu)已排除依賴和構(gòu)建產(chǎn)物。 請(qǐng)完成三件事 1. 按目錄層級(jí)說明每個(gè)頂層目錄的職責(zé) 2. 標(biāo)出你認(rèn)為最可能包含核心業(yè)務(wù)邏輯的 3 個(gè)目錄并說明理由 3. 指出哪些目錄是配置、測(cè)試或工具類可以暫時(shí)跳過。 輸出用表格不要展開每個(gè)文件。這個(gè)提示詞的設(shè)計(jì)意圖很明確先建立粗粒度認(rèn)知把注意力引到核心區(qū)域同時(shí)明確告訴你哪些可以暫時(shí)不看。很多人失敗是因?yàn)橐簧蟻砭妥?AI 分析所有文件結(jié)果得到一堆正確但無用的廢話。第二步抽取關(guān)鍵調(diào)用鏈。選定核心目錄后挑出 3 到 5 個(gè)最相關(guān)的入口文件比如路由定義、主服務(wù)文件、核心控制器讓 AI 追蹤一條完整的請(qǐng)求鏈路。這里有個(gè)技巧不要讓它自由發(fā)揮而是指定起點(diǎn)和終點(diǎn)。比如“從 HTTP 路由/api/order/create開始追蹤到數(shù)據(jù)庫(kù)寫入為止列出中間經(jīng)過的函數(shù)和文件”。為什么必須指定終點(diǎn)因?yàn)?AI 在追蹤調(diào)用鏈時(shí)容易發(fā)散給它一個(gè)明確的邊界輸出才會(huì)收斂。實(shí)測(cè)下來指定起止點(diǎn)的調(diào)用鏈抽取準(zhǔn)確率明顯高于開放式提問。第三步標(biāo)注改動(dòng)風(fēng)險(xiǎn)點(diǎn)。這是最容易被忽略但價(jià)值最高的一步。讓 AI 基于調(diào)用鏈標(biāo)出哪些文件被多個(gè)鏈路共享、哪些函數(shù)有副作用、哪些配置影響范圍廣。我常用的問法是“在上述調(diào)用鏈中哪些文件的修改可能影響其他功能請(qǐng)按影響范圍從大到小排序并說明判斷依據(jù)。”注意AI 標(biāo)注的風(fēng)險(xiǎn)點(diǎn)只是候選必須人工驗(yàn)證。我的做法是拿它給的列表去全局搜索引用次數(shù)引用越多、越底層的文件改動(dòng)風(fēng)險(xiǎn)越高。這一步花 5 分鐘能省掉后面幾小時(shí)的回歸測(cè)試。2.3 實(shí)操心得與常見坑坑一目錄結(jié)構(gòu)給太多。我第一次做的時(shí)候把整個(gè)src下所有文件都貼進(jìn)去了結(jié)果 AI 的輸出又長(zhǎng)又淺每個(gè)文件一句話等于沒分析。后來改成只給到三級(jí)目錄效果立刻不一樣。信息密度比信息總量重要?？佣雎耘渲梦募?。很多人只讓 AI 看代碼文件但項(xiàng)目的很多行為是由配置決定的。我的習(xí)慣是額外把package.json、pom.xml、requirements.txt這類依賴清單和主配置文件一起給它讓它說明“這個(gè)項(xiàng)目用了哪些關(guān)鍵依賴可能影響哪些實(shí)現(xiàn)方式”。這一步能幫你快速判斷技術(shù)棧和潛在約束?？尤?AI 的地圖當(dāng)最終結(jié)論。我踩過的最大的坑就是完全信任 AI 給的模塊劃分結(jié)果它把一個(gè)核心工具類歸到了“測(cè)試相關(guān)”我差點(diǎn)漏掉。后來我養(yǎng)成了一個(gè)習(xí)慣AI 給的地圖只用來導(dǎo)航關(guān)鍵節(jié)點(diǎn)必須自己點(diǎn)開確認(rèn)。地圖的價(jià)值是讓你知道該去哪而不是替你看完所有地方。這個(gè)工作流跑順之后我接手新項(xiàng)目的認(rèn)知建立時(shí)間從半天壓縮到了半小時(shí)左右而且產(chǎn)出的地圖可以直接分享給同事減少重復(fù)溝通。3. 工作流二從需求到可運(yùn)行模塊的增量生成3.1 為什么不能一次性讓 AI 寫完整個(gè)功能新手最容易犯的錯(cuò)誤是把一個(gè)完整需求一次性丟給 AI期待它輸出一個(gè)能直接跑的模塊。結(jié)果往往是代碼看起來對(duì)但跑起來報(bào)錯(cuò)或者能跑但風(fēng)格和項(xiàng)目完全不搭再或者它悄悄改了你沒讓它改的地方。這個(gè)工作流的核心思想是增量生成 逐層驗(yàn)證。把一個(gè)大功能拆成若干可獨(dú)立驗(yàn)證的小步驟每一步都讓 AI 只做一件事做完立刻驗(yàn)證驗(yàn)證通過再進(jìn)入下一步。這樣即使某一步出錯(cuò)影響范圍也可控。3.2 四步增量生成法第一步接口先行。先讓 AI 根據(jù)需求定義出函數(shù)簽名、輸入輸出類型和關(guān)鍵注釋不寫實(shí)現(xiàn)。這一步的目的是鎖定契約。比如你要加一個(gè)訂單導(dǎo)出功能先讓它輸出def export_orders( start_date: str, end_date: str, status: Optional[str] None, format: str csv ) - ExportResult: 導(dǎo)出指定時(shí)間范圍內(nèi)的訂單。 start_date/end_date: ISO 格式日期字符串 status: 可選訂單狀態(tài)過濾 format: 導(dǎo)出格式支持 csv/xlsx 返回 ExportResult包含文件路徑和記錄數(shù) 拿到簽名后你自己先審一遍參數(shù)夠不夠、類型對(duì)不對(duì)、返回值合不合理。這一步花 2 分鐘能避免后面大量返工。接口定錯(cuò)了實(shí)現(xiàn)寫得再好也是白費(fèi)。第二步單函數(shù)實(shí)現(xiàn)。選定其中一個(gè)函數(shù)讓 AI 只實(shí)現(xiàn)它并明確要求“不要修改其他文件不要引入新依賴”。這個(gè)約束非常重要因?yàn)?AI 有“順手優(yōu)化”的傾向不加限制它會(huì)自作主張改一堆東西。我常用的提示詞模板請(qǐng)實(shí)現(xiàn)下面這個(gè)函數(shù)要求 1. 只實(shí)現(xiàn)這一個(gè)函數(shù)不要改動(dòng)其他代碼 2. 不引入新的第三方依賴 3. 遵循項(xiàng)目現(xiàn)有的錯(cuò)誤處理風(fēng)格見下方示例 4. 實(shí)現(xiàn)后附上 3 個(gè)邊界情況的測(cè)試用例。 [函數(shù)簽名] [項(xiàng)目現(xiàn)有錯(cuò)誤處理示例]第三步本地驗(yàn)證。拿到實(shí)現(xiàn)后立刻在本地跑一遍包括 AI 給的邊界用例再加上你自己想的兩個(gè)。驗(yàn)證不通過就把報(bào)錯(cuò)信息貼回去讓它修但一次只修一個(gè)問題。我見過有人把五個(gè)報(bào)錯(cuò)一起丟給 AI結(jié)果它改了一個(gè)引入兩個(gè)越修越亂。第四步集成與回歸。單函數(shù)驗(yàn)證通過后再讓它接入調(diào)用鏈然后跑一遍相關(guān)模塊的現(xiàn)有測(cè)試。這一步的關(guān)鍵是確認(rèn)沒有破壞原有功能。如果項(xiàng)目沒有測(cè)試至少手動(dòng)觸發(fā)幾條相關(guān)路徑。3.3 提示詞里的三個(gè)關(guān)鍵約束增量生成能不能穩(wěn)定復(fù)用取決于提示詞里有沒有這三個(gè)約束約束類型具體寫法解決什么問題范圍約束“只修改 X 文件不要?jiǎng)悠渌募狈乐?AI 順手改壞無關(guān)代碼依賴約束“不引入新依賴用現(xiàn)有工具庫(kù)實(shí)現(xiàn)”防止依賴膨脹和版本沖突風(fēng)格約束“參考下方示例的錯(cuò)誤處理/日志/命名風(fēng)格”保證生成代碼融入項(xiàng)目這三個(gè)約束看起來簡(jiǎn)單但少了任何一個(gè)復(fù)用性都會(huì)大打折扣。我早期不帶風(fēng)格約束結(jié)果 AI 生成的代碼用了一套完全不同的異常處理方式code review 的時(shí)候被同事挑了一堆問題。提示風(fēng)格約束最好附上真實(shí)代碼片段而不是用文字描述。文字描述“用項(xiàng)目現(xiàn)有風(fēng)格”對(duì) AI 來說太模糊給一段真實(shí)示例它模仿得準(zhǔn)得多。3.4 實(shí)操心得這個(gè)工作流我用了大半年最大的體會(huì)是AI 生成的代碼質(zhì)量和你拆解的粒度強(qiáng)相關(guān)。拆得越細(xì)每一步越可控最終質(zhì)量越高。反過來你越想省事讓它一次寫完返工成本越高。另外一個(gè)心得是保留每一步的對(duì)話記錄。增量生成會(huì)產(chǎn)生多輪對(duì)話如果中間某一步出了問題你需要能回溯到是哪一步引入的。我的做法是每一步驗(yàn)證通過后把該步的輸入輸出單獨(dú)存一份形成一條可追溯的生成鏈。這在排查“為什么最終代碼和預(yù)期不一樣”時(shí)特別有用。4. 工作流三缺陷定位與修復(fù)的閉環(huán)流程4.1 為什么缺陷排查需要獨(dú)立工作流寫新功能和修 bug 是兩種完全不同的認(rèn)知模式。寫功能是正向構(gòu)建修 bug 是反向推理。很多人把修 bug 也當(dāng)成“讓 AI 寫代碼”結(jié)果 AI 給了一堆修改建議但根本沒定位到根因改完這個(gè)壞那個(gè)。缺陷排查工作流的核心是先定位、再修復(fù)、后驗(yàn)證三步嚴(yán)格分開。定位階段只找原因不改代碼修復(fù)階段只改定位到的點(diǎn)驗(yàn)證階段確認(rèn)修復(fù)有效且無副作用。4.2 定位階段讓 AI 做假設(shè)而不是給答案把報(bào)錯(cuò)信息、相關(guān)代碼片段和復(fù)現(xiàn)步驟給 AI 后不要問“怎么修”而是問“可能的原因有哪些按可能性排序并說明每個(gè)原因的驗(yàn)證方法”。這個(gè)問法的區(qū)別很關(guān)鍵。直接問“怎么修”AI 會(huì)跳過推理直接給方案方案可能對(duì)也可能錯(cuò)你沒法判斷。問“可能原因和驗(yàn)證方法”AI 會(huì)輸出一個(gè)假設(shè)列表你可以逐個(gè)驗(yàn)證驗(yàn)證過程本身就在縮小范圍。我常用的定位提示詞現(xiàn)象[報(bào)錯(cuò)信息 復(fù)現(xiàn)步驟] 相關(guān)代碼[代碼片段] 請(qǐng)完成 1. 列出可能導(dǎo)致該現(xiàn)象的 3-5 個(gè)原因按可能性從高到低排序 2. 對(duì)每個(gè)原因給出一個(gè)具體的驗(yàn)證方法比如打印什么變量、注釋哪行代碼、改什么輸入 3. 不要給出修復(fù)方案只做原因分析。拿到假設(shè)列表后從可能性最高的開始驗(yàn)證一次只驗(yàn)證一個(gè)。驗(yàn)證方法要具體可執(zhí)行比如“在 X 函數(shù)入口打印 Y 變量的值”而不是“檢查一下 Y 是不是有問題”。4.3 修復(fù)階段最小改動(dòng)原則定位到根因后修復(fù)要遵循最小改動(dòng)原則能改一行不改兩行能改一個(gè)文件不動(dòng)兩個(gè)文件。讓 AI 修復(fù)時(shí)明確告訴它根因是什么并要求“只做必要修改不要重構(gòu)不要優(yōu)化無關(guān)代碼”。這里有個(gè)反直覺的經(jīng)驗(yàn)AI 在修復(fù)時(shí)比在生成時(shí)更容易過度發(fā)揮。因?yàn)樗吹搅松舷挛臅?huì)覺得“這里順便優(yōu)化一下更好”。但修 bug 的場(chǎng)景下任何額外改動(dòng)都是風(fēng)險(xiǎn)。我的做法是在提示詞里加一句“如果你認(rèn)為有其他需要改動(dòng)的地方先列出來不要直接改”。4.4 驗(yàn)證階段回歸清單修復(fù)完成后驗(yàn)證不能只測(cè)原來報(bào)錯(cuò)的那條路徑。我通常會(huì)列一個(gè)回歸清單原報(bào)錯(cuò)路徑是否恢復(fù)正常與根因相關(guān)的相鄰功能是否正常定位階段提到的其他可能原因?qū)?yīng)的路徑是否正常項(xiàng)目現(xiàn)有測(cè)試是否全部通過這個(gè)清單讓 AI 幫你生成也行但執(zhí)行必須人工。我試過讓 AI 自己判斷“修復(fù)是否完整”它幾乎總是說“是的修復(fù)完整”參考價(jià)值有限。4.5 常見問題速查表現(xiàn)象可能原因排查動(dòng)作AI 給的修復(fù)方案改了多處提示詞沒限制改動(dòng)范圍加“只做必要修改”約束重新生成定位階段假設(shè)都不對(duì)提供的上下文不足補(bǔ)充調(diào)用棧、日志、輸入數(shù)據(jù)修復(fù)后原問題消失但新問題出現(xiàn)改動(dòng)引入了副作用回退用最小改動(dòng)重新修AI 反復(fù)給同一個(gè)錯(cuò)誤方案陷入了錯(cuò)誤假設(shè)換一個(gè)問法從數(shù)據(jù)流角度重新描述驗(yàn)證時(shí)無法復(fù)現(xiàn)原問題復(fù)現(xiàn)條件不完整補(bǔ)充環(huán)境、數(shù)據(jù)、時(shí)序信息注意如果 AI 連續(xù)兩輪都沒定位到根因不要繼續(xù)追問而是自己動(dòng)手加日志。AI 的推理基于你給的信息信息不夠時(shí)它只能猜。這時(shí)候人工介入比繼續(xù)對(duì)話更高效。4.6 實(shí)操心得修 bug 這個(gè)工作流我最大的收獲是把“讓 AI 修”變成了“讓 AI 幫我推理”。以前我總期待 AI 直接給答案后來發(fā)現(xiàn)它最強(qiáng)的能力是快速生成假設(shè)和驗(yàn)證路徑而不是給出正確答案。把定位和修復(fù)分開之后我的排查效率反而提高了因?yàn)轵?yàn)證假設(shè)的過程本身就在逼近真相。另外一個(gè)細(xì)節(jié)報(bào)錯(cuò)信息要貼全不要只貼最后一行。調(diào)用棧里的每一層都可能藏著線索AI 需要完整上下文才能給出靠譜的假設(shè)。我習(xí)慣把完整的錯(cuò)誤輸出、相關(guān)日志和復(fù)現(xiàn)命令一起給它信息越完整假設(shè)越準(zhǔn)。5. 三個(gè)工作流如何串成一條完整鏈路單獨(dú)用這三個(gè)工作流已經(jīng)能解決大部分日常場(chǎng)景但它們的真正價(jià)值在于可以串聯(lián)。一個(gè)典型的新需求交付鏈路是這樣的先用工作流一快速理解相關(guān)模塊產(chǎn)出一份改動(dòng)區(qū)域的地圖然后用工作流二增量生成新功能每一步驗(yàn)證如果過程中出現(xiàn)缺陷切到工作流三定位修復(fù)修復(fù)完成后回到工作流二繼續(xù)增量生成直到功能完整。這條鏈路跑順之后我處理一個(gè)中等復(fù)雜度需求的周期從兩三天壓縮到了一天以內(nèi)而且代碼質(zhì)量更穩(wěn)定因?yàn)槊恳徊蕉加序?yàn)證點(diǎn)不會(huì)到最后才發(fā)現(xiàn)方向錯(cuò)了。串聯(lián)時(shí)有一個(gè)關(guān)鍵原則每個(gè)工作流的輸出要能被下一個(gè)工作流直接消費(fèi)。比如工作流一產(chǎn)出的地圖要能直接作為工作流二的上下文工作流三定位到的根因要能直接指導(dǎo)工作流二的修復(fù)生成。這就要求每個(gè)環(huán)節(jié)的輸出格式盡量結(jié)構(gòu)化而不是一段自由文本。我自己的做法是給每個(gè)工作流定義固定的輸出模板地圖用表格生成用代碼塊加驗(yàn)證清單排查用假設(shè)列表加驗(yàn)證記錄。模板固定之后工作流之間的銜接幾乎不需要額外轉(zhuǎn)換直接復(fù)制粘貼就能用。6. 工具選型與提示詞管理的幾個(gè)實(shí)際考量6.1 工具不是關(guān)鍵鏈路才是市面上 AI 編程工具很多有 IDE 插件形態(tài)的有對(duì)話形態(tài)的也有命令行形態(tài)的。我的建議是先用你手頭最順手的那個(gè)把三個(gè)工作流跑通再考慮換工具。工具之間的差異遠(yuǎn)小于工作流是否清晰帶來的差異。我試過同時(shí)用三四個(gè)工具結(jié)果每個(gè)都只用了皮毛。后來固定用一個(gè)把提示詞模板和工作流打磨熟效率反而更高。工具是載體工作流是內(nèi)核別本末倒置。6.2 提示詞要版本化管理三個(gè)工作流里的提示詞模板我建議單獨(dú)存一個(gè)文件按工作流分類每次調(diào)整都記一筆改了什么、為什么改。這聽起來有點(diǎn)重但實(shí)際用起來很輕——就是一個(gè) Markdown 文件的事。為什么要版本化因?yàn)樘崾驹~的效果會(huì)隨著模型更新、項(xiàng)目變化而漂移。你今天調(diào)好的模板下個(gè)月可能就不靈了。有版本記錄你能快速定位是哪次改動(dòng)導(dǎo)致的而不是從頭再調(diào)一遍。6.3 上下文管理的一個(gè)實(shí)用技巧AI 編程最頭疼的問題之一是上下文長(zhǎng)度限制。項(xiàng)目一大相關(guān)代碼就貼不下。我的處理方式是分層提供上下文第一層給目錄結(jié)構(gòu)和接口簽名第二層給核心函數(shù)實(shí)現(xiàn)第三層給具體報(bào)錯(cuò)或需求細(xì)節(jié)。按需逐層展開而不是一次性全給。這個(gè)技巧配合工作流一特別有效先用粗粒度信息建立認(rèn)知需要深入哪個(gè)模塊再展開哪個(gè)模塊的細(xì)節(jié)。既省上下文又讓 AI 的注意力集中在當(dāng)前任務(wù)上。6.4 關(guān)于多工具協(xié)作有人喜歡讓多個(gè) AI 工具互相 review比如一個(gè)生成、一個(gè)檢查。我試過效果不穩(wěn)定。原因是不同工具的上下文和風(fēng)格不一致互相 review 容易產(chǎn)生噪音。我的做法是同一個(gè)工作流內(nèi)只用同一個(gè)工具保證上下文連貫不同工作流之間可以換工具因?yàn)樗鼈兊妮斎胼敵鍪墙Y(jié)構(gòu)化的不依賴上下文記憶。如果你確實(shí)想用多工具建議只在驗(yàn)證環(huán)節(jié)引入第二個(gè)工具做交叉檢查而且只檢查關(guān)鍵邏輯不要全量 review。全量 review 的成本高收益卻不一定比人工抽查高。7. 我踩過的坑和最后想說的這三個(gè)工作流不是一開始就設(shè)計(jì)好的是踩了無數(shù)坑之后慢慢收斂出來的。最早我迷信“一句話讓 AI 寫完整個(gè)功能”結(jié)果每次都要花大量時(shí)間調(diào)試和返工。后來我強(qiáng)迫自己把每個(gè)環(huán)節(jié)拆開、驗(yàn)證、再組合才發(fā)現(xiàn)效率反而上去了。最大的一個(gè)認(rèn)知轉(zhuǎn)變是AI 編程的瓶頸不在 AI 的能力而在人的拆解能力。你能把問題拆成 AI 能可靠執(zhí)行的小步驟AI 就能穩(wěn)定產(chǎn)出你拆不清楚再?gòu)?qiáng)的模型也幫不了你。這三個(gè)工作流本質(zhì)上就是三套拆解框架分別對(duì)應(yīng)理解、構(gòu)建、修復(fù)三種場(chǎng)景。如果你現(xiàn)在只能記住一件事我希望是每一步都要有驗(yàn)證點(diǎn)。沒有驗(yàn)證點(diǎn)的 AI 生成等于在賭有驗(yàn)證點(diǎn)的 AI 生成才是工程。工作流的價(jià)值不在于讓 AI 多干活而在于讓每一步的產(chǎn)出都可控、可查、可復(fù)用。最后一個(gè)實(shí)用建議先從工作流二開始練因?yàn)樗钯N近日常寫代碼的場(chǎng)景練熟之后再補(bǔ)工作流一和工作流三。三個(gè)都跑順之后你會(huì)發(fā)現(xiàn) AI 編程從“偶爾用用”變成了“離不開”區(qū)別就在于你有沒有把它組織成工作流。