經(jīng)驗(一):建議在編碼前增加一個反問環(huán)節(jié))
一、問題為什么 AI 寫完了代碼結(jié)果卻不符合預(yù)期在使用 AI 輔助開發(fā)的過程中我逐漸發(fā)現(xiàn)一個問題有時候AI 并不是沒有完成開發(fā)任務(wù)而是從一開始就沒有完全理解我們真正想要的東西。我們通常習(xí)慣直接向 AI 描述需求然后讓它按照要求實現(xiàn)。但實際開發(fā)中的需求往往沒有那么完整即使已經(jīng)明確了大致目標(biāo)也可能遺漏頁面交互、業(yè)務(wù)規(guī)則、特殊字段以及各種邊界情況。面對這些沒有明確說明的部分AI 往往會根據(jù)現(xiàn)有信息自行推斷并選擇一種它認(rèn)為合理的方式繼續(xù)開發(fā)。問題在于AI 能夠合理地補全信息并不意味著它補全的內(nèi)容符合真實業(yè)務(wù)需求。例如我們要求 AI 開發(fā)一個功能卻沒有明確某些字段是否參與判斷、不同業(yè)務(wù)狀態(tài)應(yīng)該如何處理。AI 可能會按照自己的理解完成代碼但等到實際測試時才發(fā)現(xiàn)這些細(xì)節(jié)與預(yù)期不符最終不得不修改方案甚至重新實現(xiàn)。因此我認(rèn)為除了優(yōu)化需求描述和提示詞之外還有一個值得嘗試的方向在正式開發(fā)之前增加一個讓 AI 主動反問的環(huán)節(jié)。二、思路讓 AI 從需求執(zhí)行者變成需求討論的參與者這里需要先明確一個前提對于正式的業(yè)務(wù)需求還是應(yīng)該優(yōu)先與需求提出者進行溝通確認(rèn)真正要解決的問題和業(yè)務(wù)口徑。本文討論的主要是個人開發(fā)場景或者已經(jīng)與需求方完成初步對齊但在具體實現(xiàn)過程中仍然存在許多細(xì)節(jié)尚未明確的情況。在這種情況下我們不必急著讓 AI 開始編碼而是可以先讓它站在需求分析者的角度審查當(dāng)前需求并主動提出需要確認(rèn)的問題。具體來說可以讓 AI 從三個方面展開分析1. 找出需求中尚未明確的細(xì)節(jié)例如頁面需要支持哪些交互某個字段為空時應(yīng)該如何處理用戶執(zhí)行操作之后數(shù)據(jù)和頁面狀態(tài)應(yīng)該如何變化這些問題看起來很細(xì)但它們往往直接決定了最終實現(xiàn)是否符合預(yù)期。2. 主動識別業(yè)務(wù)邊界和異常情況除了正常流程還需要考慮特殊場景。例如哪些字段發(fā)生變化后應(yīng)該被視為一條新記錄重復(fù)操作是否需要攔截不同業(yè)務(wù)狀態(tài)下功能的判斷規(guī)則是否一致開發(fā)者未必能夠在第一次描述需求時考慮周全而 AI 可以通過系統(tǒng)性地檢查規(guī)則幫助我們發(fā)現(xiàn)遺漏。3. 針對不同實現(xiàn)方案進行比較有些需求并不是只有一種實現(xiàn)方式。這時可以讓 AI 提供幾個候選方案說明各自的實現(xiàn)邏輯、優(yōu)缺點、潛在風(fēng)險和適用場景再由開發(fā)者根據(jù)實際業(yè)務(wù)情況進行判斷。需要注意的是AI 不應(yīng)該為了提問而提問也不應(yīng)該把所有不確定的事情都拋給開發(fā)者。對于能夠通過閱讀現(xiàn)有代碼、檢查接口調(diào)用鏈路等方式確認(rèn)的信息應(yīng)該優(yōu)先自行調(diào)查只有真正影響業(yè)務(wù)邏輯或?qū)崿F(xiàn)結(jié)果的問題才需要進一步反問。三、案例之前在開發(fā)一個涉及多個模塊的防止重復(fù)錄單功能時我對這一點的感受比較明顯。由于我進入公司時間還不長對部分業(yè)務(wù)鏈路的理解還不夠深入再加上 AI 提效后頁面和業(yè)務(wù)細(xì)節(jié)可能隨著開發(fā)推進而不斷調(diào)整因此僅憑最初的需求描述很難一次性考慮周全。在開發(fā)前我嘗試讓 AI 主動審查需求并針對不明確的地方向我提問。其中一個重要問題就是如何判斷兩條記錄是否重復(fù)。由于需要綜合多個業(yè)務(wù)字段生成重復(fù)指紋因此必須明確哪些字段應(yīng)該參與計算以及不同字段的變化是否意味著一條新的記錄。在這個過程中AI 提出了幾個值得討論的問題某些特定字段是否應(yīng)該參與重復(fù)指紋的計算不同業(yè)務(wù)場景下哪些字段發(fā)生變化后應(yīng)該被視為新的記錄對于當(dāng)前需求采用方案 A 還是方案 B 更合適這些問題看似細(xì)小但實際上可能直接影響重復(fù)判斷的準(zhǔn)確性。如果一開始沒有考慮到這些情況AI 仍然可能按照已有信息完成代碼但真正進入測試階段后才會暴露出規(guī)則遺漏或判斷不準(zhǔn)確的問題。通過提前討論我能夠進一步明確自己的需求也可以結(jié)合真實業(yè)務(wù)對不同方案作出選擇。所以我意識到AI 的價值不只是更快地實現(xiàn)已經(jīng)明確的需求還在于幫助我們發(fā)現(xiàn)那些自己尚未意識到的需求缺口。尤其對于業(yè)務(wù)經(jīng)驗不足、進入公司時間不長或者面對陌生業(yè)務(wù)模塊的開發(fā)者來說這種輔助分析的作用可能更加明顯。四、實踐如何把需求反問真正融入開發(fā)流程結(jié)合自己的使用體驗我認(rèn)為可以將這一環(huán)節(jié)整理成一套相對簡單的流程。第一步明確初始需求先描述要解決的問題、預(yù)期目標(biāo)和大致改動范圍。如果涉及真實業(yè)務(wù)優(yōu)先與需求提出者對齊關(guān)鍵口徑。此時不必追求一次性描述所有細(xì)節(jié)但應(yīng)該明確當(dāng)前已經(jīng)知道什么以及哪些地方仍然存在疑問。第二步分析優(yōu)先要求 AI 檢查需求中的模糊點、潛在邊界情況以及可能存在的多種實現(xiàn)方案。同時讓它區(qū)分三類信息已經(jīng)明確的需求和業(yè)務(wù)規(guī)則??梢酝ㄟ^閱讀現(xiàn)有代碼或調(diào)查項目自行確認(rèn)的信息。需要開發(fā)者或需求方作出判斷的問題。這樣可以避免 AI 把本來能夠自行查明的信息反復(fù)拿來詢問。第三步逐項討論關(guān)鍵問題讓 AI 優(yōu)先提出真正影響實現(xiàn)結(jié)果的問題并說明為什么需要確認(rèn)。對于技術(shù)實現(xiàn)問題可以讓 AI 提供多個方案并進行對比對于業(yè)務(wù)規(guī)則問題則需要由了解業(yè)務(wù)的人作出判斷。沒有必要把所有細(xì)節(jié)一次性討論完也沒有必要為了流程完整而反復(fù)確認(rèn)一些顯而易見的內(nèi)容。重點是解決那些可能導(dǎo)致返工的問題。第四步整理并確認(rèn)最終方案當(dāng)關(guān)鍵問題得到解決后讓 AI 將討論結(jié)果整理成一份明確的需求說明包括本次需求的目標(biāo)和改動范圍。已確認(rèn)的業(yè)務(wù)規(guī)則和邊界情況。關(guān)鍵實現(xiàn)方案及選擇理由。驗收標(biāo)準(zhǔn)和仍需驗證的事項。確認(rèn)無誤后再進入正式開發(fā)。通過這一過程原本模糊的需求就能夠逐步轉(zhuǎn)化為相對清晰、可執(zhí)行、可驗收的開發(fā)任務(wù)。五、可復(fù)用的提示詞為了讓這個環(huán)節(jié)更容易應(yīng)用到實際項目中可以使用下面這段提示詞作為起點。在開始開發(fā)之前請先不要編寫代碼。 請你扮演一名有經(jīng)驗的需求分析師和業(yè)務(wù)測試人員 審查我提供的需求盡可能發(fā)現(xiàn)需求理解偏差、 業(yè)務(wù)規(guī)則遺漏和潛在的邊界問題。 請按以下步驟執(zhí)行 1. 復(fù)述你對需求目標(biāo)、業(yè)務(wù)流程和改動范圍的理解。 2. 找出尚未明確的細(xì)節(jié)包括業(yè)務(wù)規(guī)則、 字段判斷、狀態(tài)變化、異常處理和邊界情況。 3. 區(qū)分哪些信息可以通過閱讀現(xiàn)有代碼自行確認(rèn) 哪些問題確實需要我作出判斷。 4. 對存在多種實現(xiàn)方式的部分提供候選方案 說明優(yōu)缺點、適用場景和潛在風(fēng)險。 5. 優(yōu)先提出最重要的問題說明每個問題的原因 不要一次性羅列大量低價值問題。 6. 不要擅自決定尚未明確的關(guān)鍵業(yè)務(wù)規(guī)則 也不要在需求未確認(rèn)前開始編碼。 待關(guān)鍵問題討論完成后請整理出 - 最終確認(rèn)的需求 - 明確的改動范圍 - 已確認(rèn)的業(yè)務(wù)規(guī)則和邊界情況 - 推薦的實現(xiàn)方案及選擇理由 - 驗收標(biāo)準(zhǔn)和待驗證事項 在最終方案得到確認(rèn)后再進入開發(fā)階段。這段提示詞并不是一套必須嚴(yán)格遵守的固定流程而是一個可以根據(jù)需求復(fù)雜度調(diào)整的模板。對于簡單需求可以只檢查關(guān)鍵歧義對于涉及多個業(yè)務(wù)模塊、復(fù)雜狀態(tài)流轉(zhuǎn)或重要數(shù)據(jù)判斷的需求則值得投入更多時間進行討論。六、局限并不是所有問題都應(yīng)該交給 AI 反問當(dāng)然AI 提出的疑問和給出的方案也不一定正確。有些問題可能是因為它沒有充分閱讀現(xiàn)有代碼而不是需求本身存在缺陷有些看似合理的方案也可能與實際業(yè)務(wù)規(guī)則沖突。因此不能因為 AI 提出了問題就要求開發(fā)者逐一回答也不能因為 AI 給出了推薦方案就默認(rèn)它的判斷一定合理。更合理的方式是讓 AI 先調(diào)查能夠確認(rèn)的事實再針對真正影響實現(xiàn)結(jié)果的問題提出疑問最后由開發(fā)者結(jié)合業(yè)務(wù)情況作出判斷。此外反問環(huán)節(jié)也有成本。對于改動范圍明確、風(fēng)險較低的簡單任務(wù)沒有必要進行復(fù)雜的需求分析。只有當(dāng)需求存在較多不確定性或者遺漏細(xì)節(jié)可能導(dǎo)致較大返工時前期討論才更有價值。反問的目的不是讓 AI 問出更多問題而是用盡可能少的溝通提前發(fā)現(xiàn)真正重要的問題。七、總結(jié)我認(rèn)為一個值得嘗試的改變是不再把正式編碼作為與 AI 對話的第一步。與其直接通過幾輪的簡單對話就要求 AI 實現(xiàn)需求不如先讓它幫助我們檢查需求、發(fā)現(xiàn)遺漏、分析方案并通過討論逐步明確實現(xiàn)邊界。這不僅有助于減少需求理解偏差也能夠幫助開發(fā)經(jīng)驗不足的人補充業(yè)務(wù)分析視角。歸根結(jié)底AI 輔助開發(fā)的關(guān)鍵不僅在于如何準(zhǔn)確地向 AI 提問也在于如何讓 AI 反過來向我們提問。好的 AI 輔助開發(fā)不應(yīng)該只是“我提出需求AI 負(fù)責(zé)實現(xiàn)”應(yīng)該是我與 AI 共同梳理需求、發(fā)現(xiàn)問題由人確認(rèn)關(guān)鍵決策再讓 AI 完成實現(xiàn)。