氣變成可控工程)
1. 為什么我們需要一個“分層模型”來看AI編程最近和不少朋友聊起AI編程大家普遍的困惑是工具都裝了提示詞也會寫但項目一復(fù)雜就開始失控。小需求跑得飛快大需求改幾輪就崩最后得出的結(jié)論往往是“AI編程只適合寫玩具”。這個判斷我不同意但我也承認(rèn)它反映了一個真實的瓶頸——我們?nèi)钡牟皇歉鼜?qiáng)的模型而是把AI編程這件事組織起來的框架。我想把這個框架叫作“分層模型”英文就是AI Programming: A Layered Model。它不是什么玄學(xué)理論而是我在大量實操里總結(jié)出來的一個觀察當(dāng)AI編程在一個項目里穩(wěn)定地產(chǎn)生價值的時候它的工作方式并不是一個黑盒在變魔術(shù)而是像傳統(tǒng)軟件工程一樣有清晰的層級劃分。每一層有自己的職責(zé)、輸入、輸出和質(zhì)量標(biāo)準(zhǔn)。如果你能把這些層理清楚AI編程從“碰運(yùn)氣”變成“可管理的工程行為”其實沒那么難。這套模型適合誰適合已經(jīng)在用AI輔助寫代碼、但覺得效果不穩(wěn)定的人適合想帶團(tuán)隊落地AI編程、卻不知道怎么定規(guī)范的技術(shù)管理者也適合那些對AI編程既好奇又懷疑、想搞清楚它邊界在哪的同學(xué)。下面我用實際項目和踩坑經(jīng)歷把每一層拆開講。2. 分層模型的整體設(shè)計從“一條提示詞”到“一個系統(tǒng)”2.1 傳統(tǒng)編程和AI編程的本質(zhì)差異先說一個我常用來打比方的例子。傳統(tǒng)編程好比請一個廚師你給他一份固定菜譜他嚴(yán)格按照步驟執(zhí)行火候、調(diào)料都精確到克。而AI編程更像把一個幫廚直接推到主廚的位置他能做菜但他并不知道你今天想做的是宴席還是快餐。決定權(quán)完全在你怎么布置廚房、怎么拆解任務(wù)、怎么驗收結(jié)果。傳統(tǒng)軟件工程里有經(jīng)典的層次劃分UI層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層每一層向下依賴、向上提供服務(wù)。這套思路其實完全可以遷移到AI編程里。區(qū)別在于傳統(tǒng)代碼里的層與層之間靠函數(shù)調(diào)用、接口協(xié)議來連接而AI編程里的層與層之間靠的是上下文、提示詞、工具調(diào)用和反饋回路來連接。當(dāng)我把一次完整的AI編程過程拆開來看它的工作鏈條大概是這樣的意圖層你想做什么最終目標(biāo)和約束條件是什么規(guī)劃層這個目標(biāo)可以被拆成哪些步驟每一步的驗收標(biāo)準(zhǔn)是什么上下文層AI需要了解哪些項目背景、歷史決策、現(xiàn)有代碼才能正確行動執(zhí)行層AI直接生成代碼、調(diào)用工具、修改文件的具體動作。驗證層如何確認(rèn)AI生成的結(jié)果是對的編譯、測試、人工審查反饋層發(fā)現(xiàn)錯誤之后如何把問題拋回給AI讓它自我修正這六個層次串在一起才是一次完整的AI編程。大部分人的習(xí)慣是把所有東西揉在一起寫一大段提示詞讓AI一口氣完成。這在簡單任務(wù)里沒問題就像讓幫廚做一道西紅柿炒蛋他閉著眼也能做。但一旦任務(wù)復(fù)雜煮糊的概率就急劇上升。2.2 為什么要按層拆而不是追求“一句話搞定”有人會問AI編程最大的賣點不就是自然語言直接出代碼嗎為什么要把它搞得像系統(tǒng)工程一樣復(fù)雜我理解這種想法但實際經(jīng)驗告訴我越是追求“一句話搞定”越容易在復(fù)雜項目里翻車。原因有三點。第一AI的上下文窗口是有限的你把所有需求、背景、細(xì)節(jié)塞進(jìn)一條提示詞里超過一定量之后它就開始“忘事”。分層可以把上下文管理的焦點集中在當(dāng)前真正需要的部分。第二AI生成的代碼是否正確需要逐層驗證。如果不分層錯誤就像埋在混凝土里的鋼筋表面看不出問題等要改的時候才發(fā)現(xiàn)爛透了。第三分層給了你一個定位問題的錨點。項目出了問題你能判斷是意圖理解錯了、規(guī)劃不合理、上下文不完整還是執(zhí)行出錯了而不是籠統(tǒng)地罵一句“這AI太笨了”。我這套分層模型的雛形是在一個真實項目里被逼出來的。當(dāng)時我用AI做一個內(nèi)部數(shù)據(jù)報表系統(tǒng)一開始圖省事所有需求都堆在幾個長提示詞里。前兩周還好后面每次改動都像拆雷AI改一個地方就把另一個地方弄壞了。后來我痛定思痛把項目按層整理了一遍建立了規(guī)范的工作流情況立刻好轉(zhuǎn)了。后面我會詳細(xì)拆這個項目的實操過程。3. 六層模型逐層拆解每一層都在解決什么問題先給一張總覽表后面逐層展開。注意表格的作用是幫你建立整體認(rèn)知真正的手感還是要靠實操去磨。層級職責(zé)核心產(chǎn)出常見失敗模式意圖層定義目標(biāo)和約束需求描述、驗收標(biāo)準(zhǔn)目標(biāo)模糊做出來不是想要的規(guī)劃層任務(wù)拆解與排序步驟清單、依賴關(guān)系任務(wù)太大AI難以獨(dú)立完成上下文層提供必要背景信息項目背景、代碼結(jié)構(gòu)、歷史決策信息缺失導(dǎo)致AI自由發(fā)揮執(zhí)行層生成代碼與調(diào)用工具代碼diff、文件修改生成了但跑不通或風(fēng)格不統(tǒng)一驗證層判斷結(jié)果是否正確測試報告、審查意見只看“能跑”沒看“對不對”反饋層把錯誤信息送回AI修正修正后的代碼、更新后的計劃反饋含糊AI原地打轉(zhuǎn)3.1 意圖層AI編程的地基也是被忽視最多的地方意圖層是所有層的基礎(chǔ)但它恰恰是被忽視最多的。很多人在AI編程工具里直接敲一句“幫我寫一個用戶登錄模塊”這就是典型的目標(biāo)模糊。你認(rèn)為自己表達(dá)清楚了但對AI來說“幫我寫一個用戶登錄模塊”這句話的信息量約等于零。我在意圖層總結(jié)出來的寫法是四段式背景 目標(biāo) 約束 驗收標(biāo)準(zhǔn)。不需要寫長篇大論但四個要素必須齊全。舉個例子我接一個需求要開發(fā)一個登錄功能我交到意圖層的描述是這樣的背景系統(tǒng)是面向企業(yè)內(nèi)部的CRM現(xiàn)有用戶體系基于企業(yè)微信。目標(biāo)實現(xiàn)一個Web端登錄功能支持企業(yè)微信掃碼登錄以及賬密登錄作為備用。約束前端框架用Vue3后端用Go認(rèn)證協(xié)議用OAuth2不引入新的用戶表復(fù)用現(xiàn)有賬戶體系。驗收標(biāo)準(zhǔn)掃碼登錄端到端不超過3秒賬密登錄錯誤提示要區(qū)分用戶不存在和密碼錯誤安全方面要求登錄失敗連續(xù)5次鎖定15分鐘。這四條寫下來其實不需要多久但它決定了AI后續(xù)所有工作的邊界。沒有這些約束AI大概率會自由發(fā)揮給你設(shè)計一套注冊、登錄、找回密碼、郵件驗證全都有的系統(tǒng)——聽起來很完整但不是你要的東西。3.2 規(guī)劃層讓AI當(dāng)一個會拆任務(wù)的項目經(jīng)理意圖明確之后下一步是規(guī)劃。這里要區(qū)分兩種情況。如果你用的是ChatGPT這類通用對話模型規(guī)劃任務(wù)通常需要你自己做或者明確要求AI先輸出方案再動筆。如果你用的是Copilot、Cline這類深度集成IDE的工具工具本身已經(jīng)內(nèi)置了一些規(guī)劃能力。我在規(guī)劃層堅持一個原則一個任務(wù)要讓AI在30分鐘內(nèi)能完成主體工作。超過這個粒度就繼續(xù)拆。這個數(shù)字不是拍腦袋定的而是從大量實踐中觀察出來的。任務(wù)粒度越小AI的完成質(zhì)量越穩(wěn)定出錯了也更容易定位和重做。規(guī)劃層的輸出是一份清晰的步驟清單每步要有獨(dú)立的驗收條件。比如做登錄功能我會拆成五個步驟后端實現(xiàn)企業(yè)微信OAuth2授權(quán)對接驗收標(biāo)準(zhǔn)是用測試賬號能走通完整回調(diào)流程。后端實現(xiàn)本地賬密認(rèn)證邏輯驗收標(biāo)準(zhǔn)是單元測試覆蓋正確密碼、錯誤密碼、用戶鎖定三個場景。后端用戶表結(jié)構(gòu)確認(rèn)與遷移腳本驗收標(biāo)準(zhǔn)是遷移腳本能反復(fù)執(zhí)行而不報錯。前端登錄頁UI實現(xiàn)和表單校驗驗收標(biāo)準(zhǔn)是邊界輸入空值、超長輸入、特殊字符不觸發(fā)報錯。聯(lián)調(diào)兩個登錄方式的端到端測試驗收標(biāo)準(zhǔn)是主流瀏覽器全部通過。拆得這么細(xì)的好處是任何一步失敗了AI失敗的影響范圍被限制在一個很小的區(qū)域內(nèi)。它不需要重新理解整個項目只需要修復(fù)這一個步驟里出問題的文件。3.3 上下文層AI的記憶決定它是在幫忙還是在添亂上下文層是決定AI編程體驗優(yōu)劣的關(guān)鍵但也是最少被討論的。你可以把AI想象成一個很聰明但只有七秒記憶的實習(xí)生。它每次響應(yīng)你的時候都像剛睡醒一樣。你給它的上下文越充分它表現(xiàn)得越像一個資深的同事實習(xí)生夢游。我在實操中維護(hù)上下文的常用手法有四種第一種在項目倉庫里維護(hù)一份CONVENTIONS.md或AGENTS.md文件。這份文件里記錄了項目的技術(shù)棧、目錄結(jié)構(gòu)、代碼風(fēng)格、命名規(guī)范、測試要求、禁止事項比如“不要修改xxx文件”“不要使用xxx依賴庫”。AI編程工具大多支持自動讀取這類文件比如Cursor的Rules、Cline的規(guī)則設(shè)置。每次會話開始時AI會自動加載這份文件作為長期記憶。這相當(dāng)于給AI發(fā)了一本員工手冊。第二種寫一份模塊級的README說明。很多人在項目里為每個復(fù)雜模塊維護(hù)一份簡短的說明描述這個模塊是干嘛的、核心數(shù)據(jù)流是什么樣的、有哪些歷史坑。AI要改這個模塊之前先讓它讀一遍這份文檔效果比直接丟給它一堆源碼好太多。第三種把“對話壓縮”當(dāng)習(xí)慣。當(dāng)對話上下文變得很長AI開始答非所問的時候不要再繼續(xù)往下聊。停下來新開會話把項目背景、當(dāng)前進(jìn)度、遇到的問題壓縮成一段新的提示詞重新開始。這個習(xí)慣能救回很多即將崩掉的會話。第四種善用“代碼引用”。好一點的AI編程工具支持file、folder這種代碼引用功能。我在提示詞里永遠(yuǎn)會顯式引用相關(guān)文件而不是指望AI自己去找。AI連項目結(jié)構(gòu)都不清楚的時候讓它自己在幾千個文件里翻找目標(biāo)代碼純屬碰運(yùn)氣。3.4 執(zhí)行層AI動手寫代碼的地方也是矛盾最集中的一層執(zhí)行層就是AI實際生成代碼、生成diff、修改文件的地方。這里最大的爭議點是AI生成的代碼到底應(yīng)不應(yīng)該被信任我的答案是不信任但也不用視為洪水猛獸。用流程來管理風(fēng)險而不是用態(tài)度。執(zhí)行層的核心原則是讓AI改對能改的守住不能動的邊界。具體操作上有三件事。第一件事明確告訴AI哪些文件可以改、哪些不能碰。用Cline這類帶文件讀寫權(quán)限的工具時我通常會先把不能動的文件加入忽略列表。AI閑不住你越不限制它它越喜歡順手給你“優(yōu)化”一下無關(guān)代碼這是最常見的翻車原因。第二件事嚴(yán)格執(zhí)行“小步提交”。讓AI完成一個小任務(wù)之后立刻測試通過后提交再進(jìn)入下一個任務(wù)。我在項目里經(jīng)?？吹接腥藞D方便一口氣讓AI完成五六個模塊最后跑起來發(fā)現(xiàn)到處都是錯又難以定位每個錯誤對應(yīng)哪個修改只能全部回滾重來。這完全是自討苦吃。第三件事風(fēng)格約束要寫在規(guī)則文件里不要靠每次對話臨時叮囑。臨時叮囑一是容易忘二是消耗上下文窗口。我在規(guī)則的代碼風(fēng)格部分通常會寫清楚的包括縮進(jìn)用幾個空格、注釋語言用中文還是英文、變量命名用駝峰還是下劃線、是否允許使用lodash這類工具庫、組件文件組織方式。當(dāng)AI生成的代碼風(fēng)格和項目原有代碼風(fēng)格一致的時候Code Review的心理壓力和實際工作量都會小很多。3.5 驗證層別被“能跑”騙了“對不對”才是關(guān)鍵很多人在AI編程里的驗證方式就是AI生成代碼運(yùn)行一下程序沒報錯好了。這是極大的誤區(qū)?！澳芘堋敝徽f明語法正確、資源能加載完全不代表邏輯正確、邊界處理得當(dāng)、性能達(dá)標(biāo)。我見過最典型的翻車案例是AI生成了一段導(dǎo)出Excel的代碼運(yùn)行起來確實導(dǎo)出了文件但只在數(shù)據(jù)量小的時候正常。數(shù)據(jù)量一大單元格數(shù)量超過Excel單表上限程序直接崩了。語法沒有錯邏輯看起來也對但邊界條件沒考慮到。所以驗證層必須有超越“能跑”的標(biāo)準(zhǔn)。我的驗證層分四個等級等級一編譯通過無報錯。等級二核心功能的人工冒煙測試通過。等級三關(guān)鍵邏輯的自動化測試通過單元測試、集成測試。等級四極端情況驗證通過大數(shù)據(jù)量、并發(fā)場景、異常輸入、安全測試。等級越高對AI編程結(jié)果的信任度越高。反過來說如果所有驗證都只能停留在等級一說明你壓根不該讓AI碰這個項目的核心邏輯。這里還有一個實操心得讓AI自己寫測試代碼但不要讓它自己驗證自己。AI寫測試用例的價值很大因為它能快速覆蓋大多數(shù)正常路徑和常規(guī)邊界。但AI寫的測試有一定的“路徑依賴慣性”經(jīng)常測試沒跑到特別極端的情況比如大量并發(fā)這種需要真實環(huán)境才能暴露的問題。所以讓AI補(bǔ)測試代碼、用測試結(jié)果反饋修正代碼這個流程可以跑起來。最終的質(zhì)量責(zé)任必須由人兜底。3.6 反饋層AI編程能力提升的真正按鈕前面所有層次做得再好也不能保證一次就對。AI編程真正強(qiáng)大的地方在于它能利用反饋進(jìn)行快速迭代。這個反饋層的設(shè)計直接影響一次任務(wù)從失敗到成功需要多少輪對話。反饋層最常見的錯誤是含糊的抱怨“這個不行功能沒實現(xiàn)好”“還是有bug”。這種反饋對AI來說約等于沒有。它只能瞎猜然后改出另一個錯誤版本你再反饋它再猜陷入死循環(huán)。高效的反饋格式我總結(jié)成一個公式期望行為 實際行為 錯誤信息 相關(guān)文件。舉個例子當(dāng)我發(fā)現(xiàn)AI生成的登錄接口有問題時我給出的反饋不是“登錄還是不對”而是期望行為用戶輸入正確賬號密碼后接口返回200并帶上token。實際行為接口返回401提示密碼錯誤。錯誤信息控制臺輸出“invalid credentials, expected hash length 60, got 32”——這說明密碼hash格式有問題。相關(guān)文件/backend/service/auth.go。這樣的反饋AI幾乎一次就能定位問題。因為它不需要猜測、不需要全局搜索只需要看著明確的信息去修改具體文件。在復(fù)雜項目里這種反饋習(xí)慣能把問題解決速度提升數(shù)倍。4. 一個真實項目走下來內(nèi)部報表系統(tǒng)改造為了讓你把這套模型串起來我拿一個真實的項目來講。這個項目我之前提過是給公司內(nèi)部做的數(shù)據(jù)報表系統(tǒng)技術(shù)棧是React Node.js PostgreSQL。系統(tǒng)原本是手動維護(hù)的一個月要花不少時間在導(dǎo)出、匯總、發(fā)郵件這類瑣事上。我打算用AI編程把整個流程自動化。當(dāng)時我還沒形成清晰的分層意識只是覺得AI寫代碼快想全速往前沖。結(jié)果前期多少個晚上都在給AI“收拾爛攤子”。后來我停下來重新用分層模型把整個項目梳理了一遍才真正體會到這個框架的價值。4.1 意圖層落地把“做個自動化報表系統(tǒng)”翻譯成可執(zhí)行的需求最初我對AI說的話是“幫我做一個報表自動化系統(tǒng)?！苯Y(jié)果AI給我輸出了一整套完整的SaaS平臺設(shè)計——用戶權(quán)限、多租戶、計費(fèi)模塊都有。我只想要一個內(nèi)部工具它給我設(shè)計了一堆用不上的功能。后來我在意圖層花了一個小時把真正需要的東西寫清楚了背景市場部每周需要從業(yè)務(wù)數(shù)據(jù)庫導(dǎo)出訂單數(shù)據(jù)按區(qū)域、產(chǎn)品線匯總生成Excel報表并發(fā)送到指定郵箱。目標(biāo)實現(xiàn)一個Web應(yīng)用讓市場部同事選擇報表周期和區(qū)域系統(tǒng)自動生成Excel并發(fā)送郵件。約束數(shù)據(jù)庫只讀訪問無用戶系統(tǒng)僅限內(nèi)網(wǎng)訪問部署在公司現(xiàn)有的Docker服務(wù)器上。驗收標(biāo)準(zhǔn)一次完整的報表生成從點擊到收到郵件不超過5分鐘支持最大50萬行訂單數(shù)據(jù)郵件內(nèi)容包含報表摘要和附件。這段描述寫完AI的設(shè)計方案立刻從“通用SaaS平臺”收斂為“內(nèi)部工具”。后續(xù)所有工作都圍繞真實需求展開沒有跑偏。4.2 規(guī)劃層落地項目從“一次搞定”到“五天迭代”有了明確意圖下一步是規(guī)劃。我用AI輔助做了任務(wù)拆解同時在關(guān)鍵節(jié)點做了人工干預(yù)。最終形成了這樣的規(guī)劃清單第一階段頁面原型骨架React路由、布局、表單組件。第二階段后端API數(shù)據(jù)庫查詢、匯總計算、Excel生成。第三階段郵件服務(wù)SMTP發(fā)送、附件處理。第四階段報表頁面打磨篩選條件、導(dǎo)出記錄、錯誤提示。第五階段Docker化部署。每個階段下面再拆出若干個小任務(wù)每個小任務(wù)都對應(yīng)獨(dú)立的驗收標(biāo)準(zhǔn)。整個項目分五天完成每半天處理一個任務(wù)包。這個節(jié)奏對AI編程來說剛剛好既能快速看到成果又有充足的時間處理意外情況。工具選擇上我主用Cline配合Claude模型IDE用的是VS Code。選擇Cline的核心原因有兩個一是它的文件讀寫能力比較強(qiáng)適合處理多文件項目二是它的執(zhí)行過程有清晰的diff展示我能看到AI每一步改了哪些文件。這一點比那種黑盒式的一鍵生成體驗要安全得多。4.3 上下文層落地一份AGENTS.md一套項目筆記項目推進(jìn)到第二天的時候我意識到一個嚴(yán)重的問題AI每次新會話開始都像失憶了一樣不記得之前做了什么決策、為什么這個模塊要這么寫。同一個問題第一天它給了一個方案第二天又給了完全不同的方案。解決方案就是給項目建上下文文件。我在項目根目錄建了一個AGENTS.md內(nèi)容包括項目技術(shù)棧和目錄結(jié)構(gòu)說明。數(shù)據(jù)庫只讀約束的強(qiáng)調(diào)任何代碼都不得執(zhí)行寫操作這是底線。Excel生成邏輯中關(guān)于數(shù)據(jù)量上限的約束超過多少行必須分Sheet。代碼風(fēng)格要求前端組件用函數(shù)組件Hooks命名以use開頭后端路由處理函數(shù)統(tǒng)一放在routes目錄。已知問題清單比如PostgreSQL連接池默認(rèn)配置在并發(fā)高時會報錯需要在代碼中顯式配置上限。這份文件寫完后AI的“失憶”問題明顯緩解。每次新會話開始AI自動讀取這份文檔后再動手生成的代碼風(fēng)格和約束遵循度大幅提升。我還在項目的docs目錄下維護(hù)了一個“決策日志”文件記錄每次重要決策的來龍去脈。比如“為什么不用定時任務(wù)而是手動觸發(fā)”“為什么用Excel而不是CSV”。這些歷史決策上下文在項目后期改代碼時特別重要它防止AI“好心辦了壞事”——比如自作主張把手動觸發(fā)改成定時任務(wù)因為它覺得那樣更自動化但業(yè)務(wù)上并不需要。4.4 執(zhí)行與驗證落地生成的代碼不直接合并先看diff再測試在執(zhí)行層我堅持一個規(guī)矩AI生成的所有代碼先看diff再運(yùn)行測試最后才允許合并到主干。不要覺得這一步多余。AI編程最舒服的地方就是它大大解放了生產(chǎn)力最危險的地方也是它能在幾秒鐘內(nèi)改動大量文件而你對這個改動的審視速度永遠(yuǎn)跟不上它的產(chǎn)出速度。我記得項目第三天AI要加一個“按時間范圍篩選訂單”的功能。它正確地修改了后端API但順手在數(shù)據(jù)庫連接配置里改了連接池大小。這個修改不在我的任務(wù)范圍內(nèi)雖然不一定會引發(fā)故障但無意義的改動增加了排查問題的復(fù)雜度。我沒有接受這次合并而是讓AI把連接池配置改回去。從那以后每次讓它改代碼我都會加一句“只修改與本次任務(wù)直接相關(guān)的文件不要順便重寫、優(yōu)化或調(diào)整無關(guān)鍵碼?！彬炞C層的執(zhí)行上我讓AI先給Excel生成模塊寫了單元測試覆蓋了數(shù)據(jù)格式、空數(shù)據(jù)處理、大數(shù)據(jù)量分Sheet幾個場景。這個測試本身寫得還靠譜幫我發(fā)現(xiàn)了一個真實的bug當(dāng)訂單數(shù)據(jù)里出現(xiàn)空值的時候AI生成的時間格式化代碼會直接崩潰。沒有測試兜底這個bug大概率要在生產(chǎn)環(huán)境被用戶發(fā)現(xiàn)。人機(jī)協(xié)作的節(jié)奏是上午給AI分配任務(wù)讓它獨(dú)立工作輸出diff和測試報告下午我集中做代碼審查和業(yè)務(wù)驗收把問題以反饋層的形式拋回給AI修復(fù)。這樣一個周期循環(huán)下來項目推進(jìn)得比預(yù)期還要順利。4.5 反饋層落地從“低級AI”變成“團(tuán)隊協(xié)作者”的秘密項目前半段效率低很大原因是我不知道怎么跟AI打交道。我在反饋層踩過不少坑也總結(jié)出了幾個特別有用的技巧。第一個技巧是給AI“劃句子”。就是在長段的反饋里用編號把幾個獨(dú)立的問題分開讓它逐條處理這樣它會按照邏輯依次修復(fù)不會漏掉任何一個。比如1. 報表導(dǎo)出時日期格式不符合中國習(xí)慣請改為YYYY-MM-DD2. 當(dāng)選擇“全部區(qū)域”時查詢速度大幅下降請檢查是否漏掉了索引3. 郵件標(biāo)題中請加上報表周期否則收件人不好區(qū)分。第二個技巧是合理利用“再想想”策略。當(dāng)AI給出的方案明顯復(fù)雜或繞路時先別急著用。直接告訴它“這個實現(xiàn)太繞了重新想一個更簡單的方案?！贝蠖鄶?shù)時候它換一個思路后給出的方案反而更干凈利落。第三個技巧是遇到連續(xù)兩輪修復(fù)不成功時馬上停手。不要繼續(xù)在同一會話里糾纏。正確做法是新開會話把項目的AGENTS.md、當(dāng)前任務(wù)的說明、最近的錯誤日志、此前嘗試過的方案和失敗原因一次性濃縮給新會話。很多時候換個“狀態(tài)的AI”反而能改出來。這個現(xiàn)象背后的原因比較復(fù)雜但操作層面很實用。4.6 這個項目的最終結(jié)果和反思整個項目做完市場部的同事反饋很好原來每周要花半天做的事現(xiàn)在幾分鐘就完成了而且不再擔(dān)心漏發(fā)、錯發(fā)。整個開發(fā)周期比原計劃還縮短了兩天。讓我更感慨的是AI編程的真正價值不是“替代程序員”而是把程序員從大量瑣碎低效的編碼勞動中解放出來讓你有更多精力放在真正需要判斷力的事情上——需求定義、架構(gòu)設(shè)計、代碼審查、業(yè)務(wù)理解。而這些事情的共同點恰恰是判斷什么是正確的目標(biāo)什么路徑是合理的。分層模型并不是層層加碼增加你的工作量它其實是幫你把最有價值的判斷力用在正確的地方。5. 分層模型日常實操的常用配方與避坑指南如果你讀完前面的內(nèi)容想直接把分層模型用起來我整理了一份最小可行的操作配方你可以直接抄作業(yè)。5.1 新項目從零到一的啟動清單一個全新的項目我會按這個順序來打基礎(chǔ)建立項目倉庫初始化目錄結(jié)構(gòu)。寫AGENTS.md把技術(shù)棧、代碼規(guī)范、目錄說明、禁止事項一次性寫清楚。把需求意圖用四段式背景 目標(biāo) 約束 驗收標(biāo)準(zhǔn)寫成REQUIREMENTS.md。用AI輔助起草任務(wù)拆解人工復(fù)核后生成PLAN.md按階段排列。開始第一階段的任務(wù)每完成一個子任務(wù)就測試并提交。每天晚上統(tǒng)一處理反饋把當(dāng)天遇到的問題和解決方案追加到?jīng)Q策日志里。這套流程跑幾個來回即使項目換人接手新人也只要讀三個文件REQUIREMENTS、PLAN、AGENTS.md就能快速進(jìn)入狀態(tài)。5.2 各層的常見問題和定位口訣分層模型還有一個好處就是自帶排障能力。項目出問題你可以按層定位快速找到病因。做出來的東西根本不對路或者AI總是“想當(dāng)然”——意圖層出問題的概率最大。重新審視目標(biāo)描述補(bǔ)全約束和驗收標(biāo)準(zhǔn)。任務(wù)太重AI一次完成不了經(jīng)常做到一半就亂——規(guī)劃層太粗糙把任務(wù)繼續(xù)切小。AI問你一堆基礎(chǔ)問題或者答案自相矛盾——上下文層供給不足。喂AGENTS.md喂決策日志喂相關(guān)代碼。生成的代碼跑不起來或者風(fēng)格跟項目格格不入——執(zhí)行層的邊界沒守好。查看diff禁用核心文件的修改權(quán)限加強(qiáng)代碼風(fēng)格約束。程序能跑但結(jié)果不對——驗證層缺失補(bǔ)測試補(bǔ)邊界值檢查。同一個問題反復(fù)改不好AI原地打轉(zhuǎn)——反饋層的表達(dá)方式有問題檢查反饋是否具體到“期望行為 實際行為 錯誤信息 相關(guān)文件”。這套口訣我在團(tuán)隊內(nèi)部做了分享效果還不錯。很多同事說以前項目崩了只能唉聲嘆氣現(xiàn)在至少能像分析普通bug一樣給AI編程中的問題定位心態(tài)也不那么容易崩了。5.3 兩個容易被忽略的細(xì)節(jié)最后補(bǔ)充兩個容易被忽略的實操細(xì)節(jié)。第一個是關(guān)于AI編程工具的選擇。網(wǎng)上流行觀點是“工具不重要模型才重要”這話大方向沒錯但不同工具在不同層級的能力側(cè)重點不一樣。比如有些工具對執(zhí)行層的控制力強(qiáng)能精確控制文件修改范圍驗證層的集成也做得好有些工具在規(guī)劃層表現(xiàn)更好擅長自動拆解任務(wù)。我的建議是根據(jù)你的項目類型和團(tuán)隊習(xí)慣選工具選定之后把規(guī)則沉淀到項目的AGENTS.md里。只要上下文層的下游規(guī)則固定了工具切換的成本是可控的——真正昂貴的從來是項目規(guī)則混亂導(dǎo)致的無效溝通。第二個是關(guān)于提示詞倉庫的管理。很多人只在寫提示詞的時候很用心寫完用完就扔。我更推薦在項目里建一個prompts目錄按使用場景保存高復(fù)用的提示詞模板。比如代碼審查提示詞、測試用例生成提示詞、bug定位提示詞、任務(wù)拆解提示詞。下次做同類任務(wù)直接套用微調(diào)上下文層的建設(shè)成本會隨著項目累積逐漸下降A(chǔ)I的表現(xiàn)也會越來越穩(wěn)定。6. 一些心里話AI編程分層模型對我意味著什么寫這篇文章復(fù)盤整個項目的時候我越來越確定一個感受AI編程分層模型最大的價值不是提供了什么神奇技術(shù)而是給了我們一套理性對話的框架。技術(shù)圈有個現(xiàn)象AI編程討論到一定程度就會走向兩個極端。一個極端是無限吹捧好像AI馬上要取代所有程序員了另一個極端是極度抵觸覺得AI寫的代碼都是垃圾。兩個極端都忽略了最基本的現(xiàn)實AI編程的真實能力很大程度上取決于使用者的系統(tǒng)性水平。同樣一把電鉆有人用來打一排整齊的孔有人能把墻打穿。差別不在于電鉆本身而在于使用者懂不懂測量、定位、換鉆頭、控力度。分層模型這套框架本質(zhì)上是把“用AI編程”從一門手藝活變成了一門可以分解、可以管理、可以復(fù)盤的工程活。它讓每一條提示詞的編寫都對應(yīng)到一個清晰的層級目標(biāo)讓每一次AI輸出都有明確的驗證標(biāo)準(zhǔn)讓每一次錯誤反饋都成為模型的養(yǎng)料而不是無效爭吵。我現(xiàn)在帶新人做AI編程相關(guān)項目時第一課永遠(yuǎn)不會講提示詞的寫法而是先讓他們花時間理解這套分層模型。先把問題拆清楚再談優(yōu)化先把驗證鏈路搭起來再談效率。很多新人覺得這一步太麻煩想直接沖進(jìn)編碼環(huán)節(jié)。這個時候我都會勸一句前期麻煩的點恰恰是后期省時間的點。工程師面對一個新工具最大的專業(yè)素養(yǎng)不是追求手速而是追求可控。AI編程分層模型就是我目前找到的實現(xiàn)可控的最佳路徑。最后再分享一個實操中的小技巧。如果你接觸過Cline這類提供“計劃 執(zhí)行”模式的AI編程工具你可能會發(fā)現(xiàn)它經(jīng)常會在執(zhí)行前先生成一份計劃然后讓你確認(rèn)。很多人在這一步忙著點確認(rèn)根本不好好讀計劃結(jié)果就是AI按它自己的想法執(zhí)行了一堆你并不需要的操作。我從這跌過幾次之后養(yǎng)成了嚴(yán)格審計劃的習(xí)慣計劃里列出要改的文件我會逐個確認(rèn)是否合理不該動的文件出現(xiàn)直接拒絕執(zhí)行并把理由寫進(jìn)反饋。多養(yǎng)成幾次這個習(xí)慣AI的自覺性會顯著提高。它慢慢學(xué)會了你的邊界在哪里。套用分層模型的話說這個細(xì)節(jié)本質(zhì)上是從執(zhí)行層入手倒逼反饋層和上下文層的同步優(yōu)化。它很不起眼但對工作流穩(wěn)定性的提升是實打?qū)嵉摹? AI編程分層模型：讓代碼生成從碰運(yùn)氣變成可控工程
1. 為什么我們需要一個“分層模型”來看AI編程最近和不少朋友聊起AI編程大家普遍的困惑是工具都裝了提示詞也會寫但項目一復(fù)雜就開始失控。小需求跑得飛快大需求改幾輪就崩最后得出的結(jié)論往往是“AI編程只適合寫玩具”。這個判斷我不同意但我也承認(rèn)它反映了一個真實的瓶頸——我們?nèi)钡牟皇歉鼜?qiáng)的模型而是把AI編程這件事組織起來的框架。我想把這個框架叫作“分層模型”英文就是AI Programming: A Layered Model。它不是什么玄學(xué)理論而是我在大量實操里總結(jié)出來的一個觀察當(dāng)AI編程在一個項目里穩(wěn)定地產(chǎn)生價值的時候它的工作方式并不是一個黑盒在變魔術(shù)而是像傳統(tǒng)軟件工程一樣有清晰的層級劃分。每一層有自己的職責(zé)、輸入、輸出和質(zhì)量標(biāo)準(zhǔn)。如果你能把這些層理清楚AI編程從“碰運(yùn)氣”變成“可管理的工程行為”其實沒那么難。這套模型適合誰適合已經(jīng)在用AI輔助寫代碼、但覺得效果不穩(wěn)定的人適合想帶團(tuán)隊落地AI編程、卻不知道怎么定規(guī)范的技術(shù)管理者也適合那些對AI編程既好奇又懷疑、想搞清楚它邊界在哪的同學(xué)。下面我用實際項目和踩坑經(jīng)歷把每一層拆開講。2. 分層模型的整體設(shè)計從“一條提示詞”到“一個系統(tǒng)”2.1 傳統(tǒng)編程和AI編程的本質(zhì)差異先說一個我常用來打比方的例子。傳統(tǒng)編程好比請一個廚師你給他一份固定菜譜他嚴(yán)格按照步驟執(zhí)行火候、調(diào)料都精確到克。而AI編程更像把一個幫廚直接推到主廚的位置他能做菜但他并不知道你今天想做的是宴席還是快餐。決定權(quán)完全在你怎么布置廚房、怎么拆解任務(wù)、怎么驗收結(jié)果。傳統(tǒng)軟件工程里有經(jīng)典的層次劃分UI層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層每一層向下依賴、向上提供服務(wù)。這套思路其實完全可以遷移到AI編程里。區(qū)別在于傳統(tǒng)代碼里的層與層之間靠函數(shù)調(diào)用、接口協(xié)議來連接而AI編程里的層與層之間靠的是上下文、提示詞、工具調(diào)用和反饋回路來連接。當(dāng)我把一次完整的AI編程過程拆開來看它的工作鏈條大概是這樣的意圖層你想做什么最終目標(biāo)和約束條件是什么規(guī)劃層這個目標(biāo)可以被拆成哪些步驟每一步的驗收標(biāo)準(zhǔn)是什么上下文層AI需要了解哪些項目背景、歷史決策、現(xiàn)有代碼才能正確行動執(zhí)行層AI直接生成代碼、調(diào)用工具、修改文件的具體動作。驗證層如何確認(rèn)AI生成的結(jié)果是對的編譯、測試、人工審查反饋層發(fā)現(xiàn)錯誤之后如何把問題拋回給AI讓它自我修正這六個層次串在一起才是一次完整的AI編程。大部分人的習(xí)慣是把所有東西揉在一起寫一大段提示詞讓AI一口氣完成。這在簡單任務(wù)里沒問題就像讓幫廚做一道西紅柿炒蛋他閉著眼也能做。但一旦任務(wù)復(fù)雜煮糊的概率就急劇上升。2.2 為什么要按層拆而不是追求“一句話搞定”有人會問AI編程最大的賣點不就是自然語言直接出代碼嗎為什么要把它搞得像系統(tǒng)工程一樣復(fù)雜我理解這種想法但實際經(jīng)驗告訴我越是追求“一句話搞定”越容易在復(fù)雜項目里翻車。原因有三點。第一AI的上下文窗口是有限的你把所有需求、背景、細(xì)節(jié)塞進(jìn)一條提示詞里超過一定量之后它就開始“忘事”。分層可以把上下文管理的焦點集中在當(dāng)前真正需要的部分。第二AI生成的代碼是否正確需要逐層驗證。如果不分層錯誤就像埋在混凝土里的鋼筋表面看不出問題等要改的時候才發(fā)現(xiàn)爛透了。第三分層給了你一個定位問題的錨點。項目出了問題你能判斷是意圖理解錯了、規(guī)劃不合理、上下文不完整還是執(zhí)行出錯了而不是籠統(tǒng)地罵一句“這AI太笨了”。我這套分層模型的雛形是在一個真實項目里被逼出來的。當(dāng)時我用AI做一個內(nèi)部數(shù)據(jù)報表系統(tǒng)一開始圖省事所有需求都堆在幾個長提示詞里。前兩周還好后面每次改動都像拆雷AI改一個地方就把另一個地方弄壞了。后來我痛定思痛把項目按層整理了一遍建立了規(guī)范的工作流情況立刻好轉(zhuǎn)了。后面我會詳細(xì)拆這個項目的實操過程。3. 六層模型逐層拆解每一層都在解決什么問題先給一張總覽表后面逐層展開。注意表格的作用是幫你建立整體認(rèn)知真正的手感還是要靠實操去磨。層級職責(zé)核心產(chǎn)出常見失敗模式意圖層定義目標(biāo)和約束需求描述、驗收標(biāo)準(zhǔn)目標(biāo)模糊做出來不是想要的規(guī)劃層任務(wù)拆解與排序步驟清單、依賴關(guān)系任務(wù)太大AI難以獨(dú)立完成上下文層提供必要背景信息項目背景、代碼結(jié)構(gòu)、歷史決策信息缺失導(dǎo)致AI自由發(fā)揮執(zhí)行層生成代碼與調(diào)用工具代碼diff、文件修改生成了但跑不通或風(fēng)格不統(tǒng)一驗證層判斷結(jié)果是否正確測試報告、審查意見只看“能跑”沒看“對不對”反饋層把錯誤信息送回AI修正修正后的代碼、更新后的計劃反饋含糊AI原地打轉(zhuǎn)3.1 意圖層AI編程的地基也是被忽視最多的地方意圖層是所有層的基礎(chǔ)但它恰恰是被忽視最多的。很多人在AI編程工具里直接敲一句“幫我寫一個用戶登錄模塊”這就是典型的目標(biāo)模糊。你認(rèn)為自己表達(dá)清楚了但對AI來說“幫我寫一個用戶登錄模塊”這句話的信息量約等于零。我在意圖層總結(jié)出來的寫法是四段式背景 目標(biāo) 約束 驗收標(biāo)準(zhǔn)。不需要寫長篇大論但四個要素必須齊全。舉個例子我接一個需求要開發(fā)一個登錄功能我交到意圖層的描述是這樣的背景系統(tǒng)是面向企業(yè)內(nèi)部的CRM現(xiàn)有用戶體系基于企業(yè)微信。目標(biāo)實現(xiàn)一個Web端登錄功能支持企業(yè)微信掃碼登錄以及賬密登錄作為備用。約束前端框架用Vue3后端用Go認(rèn)證協(xié)議用OAuth2不引入新的用戶表復(fù)用現(xiàn)有賬戶體系。驗收標(biāo)準(zhǔn)掃碼登錄端到端不超過3秒賬密登錄錯誤提示要區(qū)分用戶不存在和密碼錯誤安全方面要求登錄失敗連續(xù)5次鎖定15分鐘。這四條寫下來其實不需要多久但它決定了AI后續(xù)所有工作的邊界。沒有這些約束AI大概率會自由發(fā)揮給你設(shè)計一套注冊、登錄、找回密碼、郵件驗證全都有的系統(tǒng)——聽起來很完整但不是你要的東西。3.2 規(guī)劃層讓AI當(dāng)一個會拆任務(wù)的項目經(jīng)理意圖明確之后下一步是規(guī)劃。這里要區(qū)分兩種情況。如果你用的是ChatGPT這類通用對話模型規(guī)劃任務(wù)通常需要你自己做或者明確要求AI先輸出方案再動筆。如果你用的是Copilot、Cline這類深度集成IDE的工具工具本身已經(jīng)內(nèi)置了一些規(guī)劃能力。我在規(guī)劃層堅持一個原則一個任務(wù)要讓AI在30分鐘內(nèi)能完成主體工作。超過這個粒度就繼續(xù)拆。這個數(shù)字不是拍腦袋定的而是從大量實踐中觀察出來的。任務(wù)粒度越小AI的完成質(zhì)量越穩(wěn)定出錯了也更容易定位和重做。規(guī)劃層的輸出是一份清晰的步驟清單每步要有獨(dú)立的驗收條件。比如做登錄功能我會拆成五個步驟后端實現(xiàn)企業(yè)微信OAuth2授權(quán)對接驗收標(biāo)準(zhǔn)是用測試賬號能走通完整回調(diào)流程。后端實現(xiàn)本地賬密認(rèn)證邏輯驗收標(biāo)準(zhǔn)是單元測試覆蓋正確密碼、錯誤密碼、用戶鎖定三個場景。后端用戶表結(jié)構(gòu)確認(rèn)與遷移腳本驗收標(biāo)準(zhǔn)是遷移腳本能反復(fù)執(zhí)行而不報錯。前端登錄頁UI實現(xiàn)和表單校驗驗收標(biāo)準(zhǔn)是邊界輸入空值、超長輸入、特殊字符不觸發(fā)報錯。聯(lián)調(diào)兩個登錄方式的端到端測試驗收標(biāo)準(zhǔn)是主流瀏覽器全部通過。拆得這么細(xì)的好處是任何一步失敗了AI失敗的影響范圍被限制在一個很小的區(qū)域內(nèi)。它不需要重新理解整個項目只需要修復(fù)這一個步驟里出問題的文件。3.3 上下文層AI的記憶決定它是在幫忙還是在添亂上下文層是決定AI編程體驗優(yōu)劣的關(guān)鍵但也是最少被討論的。你可以把AI想象成一個很聰明但只有七秒記憶的實習(xí)生。它每次響應(yīng)你的時候都像剛睡醒一樣。你給它的上下文越充分它表現(xiàn)得越像一個資深的同事實習(xí)生夢游。我在實操中維護(hù)上下文的常用手法有四種第一種在項目倉庫里維護(hù)一份CONVENTIONS.md或AGENTS.md文件。這份文件里記錄了項目的技術(shù)棧、目錄結(jié)構(gòu)、代碼風(fēng)格、命名規(guī)范、測試要求、禁止事項比如“不要修改xxx文件”“不要使用xxx依賴庫”。AI編程工具大多支持自動讀取這類文件比如Cursor的Rules、Cline的規(guī)則設(shè)置。每次會話開始時AI會自動加載這份文件作為長期記憶。這相當(dāng)于給AI發(fā)了一本員工手冊。第二種寫一份模塊級的README說明。很多人在項目里為每個復(fù)雜模塊維護(hù)一份簡短的說明描述這個模塊是干嘛的、核心數(shù)據(jù)流是什么樣的、有哪些歷史坑。AI要改這個模塊之前先讓它讀一遍這份文檔效果比直接丟給它一堆源碼好太多。第三種把“對話壓縮”當(dāng)習(xí)慣。當(dāng)對話上下文變得很長AI開始答非所問的時候不要再繼續(xù)往下聊。停下來新開會話把項目背景、當(dāng)前進(jìn)度、遇到的問題壓縮成一段新的提示詞重新開始。這個習(xí)慣能救回很多即將崩掉的會話。第四種善用“代碼引用”。好一點的AI編程工具支持file、folder這種代碼引用功能。我在提示詞里永遠(yuǎn)會顯式引用相關(guān)文件而不是指望AI自己去找。AI連項目結(jié)構(gòu)都不清楚的時候讓它自己在幾千個文件里翻找目標(biāo)代碼純屬碰運(yùn)氣。3.4 執(zhí)行層AI動手寫代碼的地方也是矛盾最集中的一層執(zhí)行層就是AI實際生成代碼、生成diff、修改文件的地方。這里最大的爭議點是AI生成的代碼到底應(yīng)不應(yīng)該被信任我的答案是不信任但也不用視為洪水猛獸。用流程來管理風(fēng)險而不是用態(tài)度。執(zhí)行層的核心原則是讓AI改對能改的守住不能動的邊界。具體操作上有三件事。第一件事明確告訴AI哪些文件可以改、哪些不能碰。用Cline這類帶文件讀寫權(quán)限的工具時我通常會先把不能動的文件加入忽略列表。AI閑不住你越不限制它它越喜歡順手給你“優(yōu)化”一下無關(guān)代碼這是最常見的翻車原因。第二件事嚴(yán)格執(zhí)行“小步提交”。讓AI完成一個小任務(wù)之后立刻測試通過后提交再進(jìn)入下一個任務(wù)。我在項目里經(jīng)?？吹接腥藞D方便一口氣讓AI完成五六個模塊最后跑起來發(fā)現(xiàn)到處都是錯又難以定位每個錯誤對應(yīng)哪個修改只能全部回滾重來。這完全是自討苦吃。第三件事風(fēng)格約束要寫在規(guī)則文件里不要靠每次對話臨時叮囑。臨時叮囑一是容易忘二是消耗上下文窗口。我在規(guī)則的代碼風(fēng)格部分通常會寫清楚的包括縮進(jìn)用幾個空格、注釋語言用中文還是英文、變量命名用駝峰還是下劃線、是否允許使用lodash這類工具庫、組件文件組織方式。當(dāng)AI生成的代碼風(fēng)格和項目原有代碼風(fēng)格一致的時候Code Review的心理壓力和實際工作量都會小很多。3.5 驗證層別被“能跑”騙了“對不對”才是關(guān)鍵很多人在AI編程里的驗證方式就是AI生成代碼運(yùn)行一下程序沒報錯好了。這是極大的誤區(qū)?！澳芘堋敝徽f明語法正確、資源能加載完全不代表邏輯正確、邊界處理得當(dāng)、性能達(dá)標(biāo)。我見過最典型的翻車案例是AI生成了一段導(dǎo)出Excel的代碼運(yùn)行起來確實導(dǎo)出了文件但只在數(shù)據(jù)量小的時候正常。數(shù)據(jù)量一大單元格數(shù)量超過Excel單表上限程序直接崩了。語法沒有錯邏輯看起來也對但邊界條件沒考慮到。所以驗證層必須有超越“能跑”的標(biāo)準(zhǔn)。我的驗證層分四個等級等級一編譯通過無報錯。等級二核心功能的人工冒煙測試通過。等級三關(guān)鍵邏輯的自動化測試通過單元測試、集成測試。等級四極端情況驗證通過大數(shù)據(jù)量、并發(fā)場景、異常輸入、安全測試。等級越高對AI編程結(jié)果的信任度越高。反過來說如果所有驗證都只能停留在等級一說明你壓根不該讓AI碰這個項目的核心邏輯。這里還有一個實操心得讓AI自己寫測試代碼但不要讓它自己驗證自己。AI寫測試用例的價值很大因為它能快速覆蓋大多數(shù)正常路徑和常規(guī)邊界。但AI寫的測試有一定的“路徑依賴慣性”經(jīng)常測試沒跑到特別極端的情況比如大量并發(fā)這種需要真實環(huán)境才能暴露的問題。所以讓AI補(bǔ)測試代碼、用測試結(jié)果反饋修正代碼這個流程可以跑起來。最終的質(zhì)量責(zé)任必須由人兜底。3.6 反饋層AI編程能力提升的真正按鈕前面所有層次做得再好也不能保證一次就對。AI編程真正強(qiáng)大的地方在于它能利用反饋進(jìn)行快速迭代。這個反饋層的設(shè)計直接影響一次任務(wù)從失敗到成功需要多少輪對話。反饋層最常見的錯誤是含糊的抱怨“這個不行功能沒實現(xiàn)好”“還是有bug”。這種反饋對AI來說約等于沒有。它只能瞎猜然后改出另一個錯誤版本你再反饋它再猜陷入死循環(huán)。高效的反饋格式我總結(jié)成一個公式期望行為 實際行為 錯誤信息 相關(guān)文件。舉個例子當(dāng)我發(fā)現(xiàn)AI生成的登錄接口有問題時我給出的反饋不是“登錄還是不對”而是期望行為用戶輸入正確賬號密碼后接口返回200并帶上token。實際行為接口返回401提示密碼錯誤。錯誤信息控制臺輸出“invalid credentials, expected hash length 60, got 32”——這說明密碼hash格式有問題。相關(guān)文件/backend/service/auth.go。這樣的反饋AI幾乎一次就能定位問題。因為它不需要猜測、不需要全局搜索只需要看著明確的信息去修改具體文件。在復(fù)雜項目里這種反饋習(xí)慣能把問題解決速度提升數(shù)倍。4. 一個真實項目走下來內(nèi)部報表系統(tǒng)改造為了讓你把這套模型串起來我拿一個真實的項目來講。這個項目我之前提過是給公司內(nèi)部做的數(shù)據(jù)報表系統(tǒng)技術(shù)棧是React Node.js PostgreSQL。系統(tǒng)原本是手動維護(hù)的一個月要花不少時間在導(dǎo)出、匯總、發(fā)郵件這類瑣事上。我打算用AI編程把整個流程自動化。當(dāng)時我還沒形成清晰的分層意識只是覺得AI寫代碼快想全速往前沖。結(jié)果前期多少個晚上都在給AI“收拾爛攤子”。后來我停下來重新用分層模型把整個項目梳理了一遍才真正體會到這個框架的價值。4.1 意圖層落地把“做個自動化報表系統(tǒng)”翻譯成可執(zhí)行的需求最初我對AI說的話是“幫我做一個報表自動化系統(tǒng)?！苯Y(jié)果AI給我輸出了一整套完整的SaaS平臺設(shè)計——用戶權(quán)限、多租戶、計費(fèi)模塊都有。我只想要一個內(nèi)部工具它給我設(shè)計了一堆用不上的功能。后來我在意圖層花了一個小時把真正需要的東西寫清楚了背景市場部每周需要從業(yè)務(wù)數(shù)據(jù)庫導(dǎo)出訂單數(shù)據(jù)按區(qū)域、產(chǎn)品線匯總生成Excel報表并發(fā)送到指定郵箱。目標(biāo)實現(xiàn)一個Web應(yīng)用讓市場部同事選擇報表周期和區(qū)域系統(tǒng)自動生成Excel并發(fā)送郵件。約束數(shù)據(jù)庫只讀訪問無用戶系統(tǒng)僅限內(nèi)網(wǎng)訪問部署在公司現(xiàn)有的Docker服務(wù)器上。驗收標(biāo)準(zhǔn)一次完整的報表生成從點擊到收到郵件不超過5分鐘支持最大50萬行訂單數(shù)據(jù)郵件內(nèi)容包含報表摘要和附件。這段描述寫完AI的設(shè)計方案立刻從“通用SaaS平臺”收斂為“內(nèi)部工具”。后續(xù)所有工作都圍繞真實需求展開沒有跑偏。4.2 規(guī)劃層落地項目從“一次搞定”到“五天迭代”有了明確意圖下一步是規(guī)劃。我用AI輔助做了任務(wù)拆解同時在關(guān)鍵節(jié)點做了人工干預(yù)。最終形成了這樣的規(guī)劃清單第一階段頁面原型骨架React路由、布局、表單組件。第二階段后端API數(shù)據(jù)庫查詢、匯總計算、Excel生成。第三階段郵件服務(wù)SMTP發(fā)送、附件處理。第四階段報表頁面打磨篩選條件、導(dǎo)出記錄、錯誤提示。第五階段Docker化部署。每個階段下面再拆出若干個小任務(wù)每個小任務(wù)都對應(yīng)獨(dú)立的驗收標(biāo)準(zhǔn)。整個項目分五天完成每半天處理一個任務(wù)包。這個節(jié)奏對AI編程來說剛剛好既能快速看到成果又有充足的時間處理意外情況。工具選擇上我主用Cline配合Claude模型IDE用的是VS Code。選擇Cline的核心原因有兩個一是它的文件讀寫能力比較強(qiáng)適合處理多文件項目二是它的執(zhí)行過程有清晰的diff展示我能看到AI每一步改了哪些文件。這一點比那種黑盒式的一鍵生成體驗要安全得多。4.3 上下文層落地一份AGENTS.md一套項目筆記項目推進(jìn)到第二天的時候我意識到一個嚴(yán)重的問題AI每次新會話開始都像失憶了一樣不記得之前做了什么決策、為什么這個模塊要這么寫。同一個問題第一天它給了一個方案第二天又給了完全不同的方案。解決方案就是給項目建上下文文件。我在項目根目錄建了一個AGENTS.md內(nèi)容包括項目技術(shù)棧和目錄結(jié)構(gòu)說明。數(shù)據(jù)庫只讀約束的強(qiáng)調(diào)任何代碼都不得執(zhí)行寫操作這是底線。Excel生成邏輯中關(guān)于數(shù)據(jù)量上限的約束超過多少行必須分Sheet。代碼風(fēng)格要求前端組件用函數(shù)組件Hooks命名以use開頭后端路由處理函數(shù)統(tǒng)一放在routes目錄。已知問題清單比如PostgreSQL連接池默認(rèn)配置在并發(fā)高時會報錯需要在代碼中顯式配置上限。這份文件寫完后AI的“失憶”問題明顯緩解。每次新會話開始AI自動讀取這份文檔后再動手生成的代碼風(fēng)格和約束遵循度大幅提升。我還在項目的docs目錄下維護(hù)了一個“決策日志”文件記錄每次重要決策的來龍去脈。比如“為什么不用定時任務(wù)而是手動觸發(fā)”“為什么用Excel而不是CSV”。這些歷史決策上下文在項目后期改代碼時特別重要它防止AI“好心辦了壞事”——比如自作主張把手動觸發(fā)改成定時任務(wù)因為它覺得那樣更自動化但業(yè)務(wù)上并不需要。4.4 執(zhí)行與驗證落地生成的代碼不直接合并先看diff再測試在執(zhí)行層我堅持一個規(guī)矩AI生成的所有代碼先看diff再運(yùn)行測試最后才允許合并到主干。不要覺得這一步多余。AI編程最舒服的地方就是它大大解放了生產(chǎn)力最危險的地方也是它能在幾秒鐘內(nèi)改動大量文件而你對這個改動的審視速度永遠(yuǎn)跟不上它的產(chǎn)出速度。我記得項目第三天AI要加一個“按時間范圍篩選訂單”的功能。它正確地修改了后端API但順手在數(shù)據(jù)庫連接配置里改了連接池大小。這個修改不在我的任務(wù)范圍內(nèi)雖然不一定會引發(fā)故障但無意義的改動增加了排查問題的復(fù)雜度。我沒有接受這次合并而是讓AI把連接池配置改回去。從那以后每次讓它改代碼我都會加一句“只修改與本次任務(wù)直接相關(guān)的文件不要順便重寫、優(yōu)化或調(diào)整無關(guān)鍵碼?！彬炞C層的執(zhí)行上我讓AI先給Excel生成模塊寫了單元測試覆蓋了數(shù)據(jù)格式、空數(shù)據(jù)處理、大數(shù)據(jù)量分Sheet幾個場景。這個測試本身寫得還靠譜幫我發(fā)現(xiàn)了一個真實的bug當(dāng)訂單數(shù)據(jù)里出現(xiàn)空值的時候AI生成的時間格式化代碼會直接崩潰。沒有測試兜底這個bug大概率要在生產(chǎn)環(huán)境被用戶發(fā)現(xiàn)。人機(jī)協(xié)作的節(jié)奏是上午給AI分配任務(wù)讓它獨(dú)立工作輸出diff和測試報告下午我集中做代碼審查和業(yè)務(wù)驗收把問題以反饋層的形式拋回給AI修復(fù)。這樣一個周期循環(huán)下來項目推進(jìn)得比預(yù)期還要順利。4.5 反饋層落地從“低級AI”變成“團(tuán)隊協(xié)作者”的秘密項目前半段效率低很大原因是我不知道怎么跟AI打交道。我在反饋層踩過不少坑也總結(jié)出了幾個特別有用的技巧。第一個技巧是給AI“劃句子”。就是在長段的反饋里用編號把幾個獨(dú)立的問題分開讓它逐條處理這樣它會按照邏輯依次修復(fù)不會漏掉任何一個。比如1. 報表導(dǎo)出時日期格式不符合中國習(xí)慣請改為YYYY-MM-DD2. 當(dāng)選擇“全部區(qū)域”時查詢速度大幅下降請檢查是否漏掉了索引3. 郵件標(biāo)題中請加上報表周期否則收件人不好區(qū)分。第二個技巧是合理利用“再想想”策略。當(dāng)AI給出的方案明顯復(fù)雜或繞路時先別急著用。直接告訴它“這個實現(xiàn)太繞了重新想一個更簡單的方案?！贝蠖鄶?shù)時候它換一個思路后給出的方案反而更干凈利落。第三個技巧是遇到連續(xù)兩輪修復(fù)不成功時馬上停手。不要繼續(xù)在同一會話里糾纏。正確做法是新開會話把項目的AGENTS.md、當(dāng)前任務(wù)的說明、最近的錯誤日志、此前嘗試過的方案和失敗原因一次性濃縮給新會話。很多時候換個“狀態(tài)的AI”反而能改出來。這個現(xiàn)象背后的原因比較復(fù)雜但操作層面很實用。4.6 這個項目的最終結(jié)果和反思整個項目做完市場部的同事反饋很好原來每周要花半天做的事現(xiàn)在幾分鐘就完成了而且不再擔(dān)心漏發(fā)、錯發(fā)。整個開發(fā)周期比原計劃還縮短了兩天。讓我更感慨的是AI編程的真正價值不是“替代程序員”而是把程序員從大量瑣碎低效的編碼勞動中解放出來讓你有更多精力放在真正需要判斷力的事情上——需求定義、架構(gòu)設(shè)計、代碼審查、業(yè)務(wù)理解。而這些事情的共同點恰恰是判斷什么是正確的目標(biāo)什么路徑是合理的。分層模型并不是層層加碼增加你的工作量它其實是幫你把最有價值的判斷力用在正確的地方。5. 分層模型日常實操的常用配方與避坑指南如果你讀完前面的內(nèi)容想直接把分層模型用起來我整理了一份最小可行的操作配方你可以直接抄作業(yè)。5.1 新項目從零到一的啟動清單一個全新的項目我會按這個順序來打基礎(chǔ)建立項目倉庫初始化目錄結(jié)構(gòu)。寫AGENTS.md把技術(shù)棧、代碼規(guī)范、目錄說明、禁止事項一次性寫清楚。把需求意圖用四段式背景 目標(biāo) 約束 驗收標(biāo)準(zhǔn)寫成REQUIREMENTS.md。用AI輔助起草任務(wù)拆解人工復(fù)核后生成PLAN.md按階段排列。開始第一階段的任務(wù)每完成一個子任務(wù)就測試并提交。每天晚上統(tǒng)一處理反饋把當(dāng)天遇到的問題和解決方案追加到?jīng)Q策日志里。這套流程跑幾個來回即使項目換人接手新人也只要讀三個文件REQUIREMENTS、PLAN、AGENTS.md就能快速進(jìn)入狀態(tài)。5.2 各層的常見問題和定位口訣分層模型還有一個好處就是自帶排障能力。項目出問題你可以按層定位快速找到病因。做出來的東西根本不對路或者AI總是“想當(dāng)然”——意圖層出問題的概率最大。重新審視目標(biāo)描述補(bǔ)全約束和驗收標(biāo)準(zhǔn)。任務(wù)太重AI一次完成不了經(jīng)常做到一半就亂——規(guī)劃層太粗糙把任務(wù)繼續(xù)切小。AI問你一堆基礎(chǔ)問題或者答案自相矛盾——上下文層供給不足。喂AGENTS.md喂決策日志喂相關(guān)代碼。生成的代碼跑不起來或者風(fēng)格跟項目格格不入——執(zhí)行層的邊界沒守好。查看diff禁用核心文件的修改權(quán)限加強(qiáng)代碼風(fēng)格約束。程序能跑但結(jié)果不對——驗證層缺失補(bǔ)測試補(bǔ)邊界值檢查。同一個問題反復(fù)改不好AI原地打轉(zhuǎn)——反饋層的表達(dá)方式有問題檢查反饋是否具體到“期望行為 實際行為 錯誤信息 相關(guān)文件”。這套口訣我在團(tuán)隊內(nèi)部做了分享效果還不錯。很多同事說以前項目崩了只能唉聲嘆氣現(xiàn)在至少能像分析普通bug一樣給AI編程中的問題定位心態(tài)也不那么容易崩了。5.3 兩個容易被忽略的細(xì)節(jié)最后補(bǔ)充兩個容易被忽略的實操細(xì)節(jié)。第一個是關(guān)于AI編程工具的選擇。網(wǎng)上流行觀點是“工具不重要模型才重要”這話大方向沒錯但不同工具在不同層級的能力側(cè)重點不一樣。比如有些工具對執(zhí)行層的控制力強(qiáng)能精確控制文件修改范圍驗證層的集成也做得好有些工具在規(guī)劃層表現(xiàn)更好擅長自動拆解任務(wù)。我的建議是根據(jù)你的項目類型和團(tuán)隊習(xí)慣選工具選定之后把規(guī)則沉淀到項目的AGENTS.md里。只要上下文層的下游規(guī)則固定了工具切換的成本是可控的——真正昂貴的從來是項目規(guī)則混亂導(dǎo)致的無效溝通。第二個是關(guān)于提示詞倉庫的管理。很多人只在寫提示詞的時候很用心寫完用完就扔。我更推薦在項目里建一個prompts目錄按使用場景保存高復(fù)用的提示詞模板。比如代碼審查提示詞、測試用例生成提示詞、bug定位提示詞、任務(wù)拆解提示詞。下次做同類任務(wù)直接套用微調(diào)上下文層的建設(shè)成本會隨著項目累積逐漸下降A(chǔ)I的表現(xiàn)也會越來越穩(wěn)定。6. 一些心里話AI編程分層模型對我意味著什么寫這篇文章復(fù)盤整個項目的時候我越來越確定一個感受AI編程分層模型最大的價值不是提供了什么神奇技術(shù)而是給了我們一套理性對話的框架。技術(shù)圈有個現(xiàn)象AI編程討論到一定程度就會走向兩個極端。一個極端是無限吹捧好像AI馬上要取代所有程序員了另一個極端是極度抵觸覺得AI寫的代碼都是垃圾。兩個極端都忽略了最基本的現(xiàn)實AI編程的真實能力很大程度上取決于使用者的系統(tǒng)性水平。同樣一把電鉆有人用來打一排整齊的孔有人能把墻打穿。差別不在于電鉆本身而在于使用者懂不懂測量、定位、換鉆頭、控力度。分層模型這套框架本質(zhì)上是把“用AI編程”從一門手藝活變成了一門可以分解、可以管理、可以復(fù)盤的工程活。它讓每一條提示詞的編寫都對應(yīng)到一個清晰的層級目標(biāo)讓每一次AI輸出都有明確的驗證標(biāo)準(zhǔn)讓每一次錯誤反饋都成為模型的養(yǎng)料而不是無效爭吵。我現(xiàn)在帶新人做AI編程相關(guān)項目時第一課永遠(yuǎn)不會講提示詞的寫法而是先讓他們花時間理解這套分層模型。先把問題拆清楚再談優(yōu)化先把驗證鏈路搭起來再談效率。很多新人覺得這一步太麻煩想直接沖進(jìn)編碼環(huán)節(jié)。這個時候我都會勸一句前期麻煩的點恰恰是后期省時間的點。工程師面對一個新工具最大的專業(yè)素養(yǎng)不是追求手速而是追求可控。AI編程分層模型就是我目前找到的實現(xiàn)可控的最佳路徑。最后再分享一個實操中的小技巧。如果你接觸過Cline這類提供“計劃 執(zhí)行”模式的AI編程工具你可能會發(fā)現(xiàn)它經(jīng)常會在執(zhí)行前先生成一份計劃然后讓你確認(rèn)。很多人在這一步忙著點確認(rèn)根本不好好讀計劃結(jié)果就是AI按它自己的想法執(zhí)行了一堆你并不需要的操作。我從這跌過幾次之后養(yǎng)成了嚴(yán)格審計劃的習(xí)慣計劃里列出要改的文件我會逐個確認(rèn)是否合理不該動的文件出現(xiàn)直接拒絕執(zhí)行并把理由寫進(jìn)反饋。多養(yǎng)成幾次這個習(xí)慣AI的自覺性會顯著提高。它慢慢學(xué)會了你的邊界在哪里。套用分層模型的話說這個細(xì)節(jié)本質(zhì)上是從執(zhí)行層入手倒逼反饋層和上下文層的同步優(yōu)化。它很不起眼但對工作流穩(wěn)定性的提升是實打?qū)嵉摹?