從“10萬行代碼全是bug”到“提交流程一次過”，作者用三周血淚史總結(jié)出一套AI編程防翻車三步法：先定位、再理解、后輸出。只要讓AI把上下文吃透，bug率立降80%。如果你也在用Cursor或ClaudeCode，這篇文章就是避坑指南。

最近大部分精力都鋪在“提示詞管理助手”2.0版本開發(fā)上，帶著我的好搭子claudecode和cursor一起奮斗。

昨天晚上終于完成了上線前的測(cè)試環(huán)節(jié)，把它打包提交審核了，現(xiàn)在就等待谷歌那邊過審就可以和大家見面啦~

這次迭代是我目前AI編程里耗時(shí)最多，難度最大的一次。

在“提示詞管理助手”2.0版本的開發(fā)過程中，我總結(jié)了一下我干的最多的事情：寫bug和改bug。

前兩周的時(shí)間完全聽AI的改架構(gòu)，寫了10萬行代碼全是bug，我本來滿懷期待覺得AI說沒問題，那應(yīng)該我可以收獲一個(gè)超級(jí)好用的版本。

結(jié)果啥都沒收獲還消耗了40刀的token。。。

只能從頭再來了，我咬著牙給自己打氣，你可以的，繼續(xù)肝吧。

然后我繼續(xù)迭代自己用claudecode和cursor的編程方法，盡可能的降低bug發(fā)生的頻率，一輪輪迭代過去了，終于見到了曙光。

打包提完審核的那一刻，感覺如釋重負(fù)，終于還是做出來了，我還是可以和我的AI搭子們一起做很多事情的。

前兩天跟大家分享了claudecode的整體編程思路，這次想更加聚焦的講一個(gè)更關(guān)鍵的問題：

AI編程到底怎樣能夠少寫bug，從而更高效的開發(fā)？

要真正解決AI編程bug率高的問題，我們要先搞清楚，它為什么寫代碼的過程中會(huì)出錯(cuò)。

以“提示詞管理助手”為例，我就經(jīng)歷了bug從幾乎沒有到寫啥蹦啥的全過程。

在早期幾個(gè)版本用cursor開發(fā)的時(shí)候，bug可以說是非常少了。cursor開發(fā)都是一版過的，然后有一些細(xì)節(jié)我修修補(bǔ)補(bǔ)就好了。

隨著功能的增加，代碼量也隨著增加，對(duì)應(yīng)的bug率也增加了很多。

最明顯的是在1.6.6版本后，我想優(yōu)化一下飛書的授權(quán)問題，搞了倆小時(shí)除了讓它更難用了，什么都沒有改出來。。。

項(xiàng)目越大，代碼量越多，AI越難準(zhǔn)確的理解現(xiàn)有邏輯結(jié)構(gòu)，bug也就會(huì)更頻繁的出現(xiàn)。

歸根到底其實(shí)還是上下文信息不夠，導(dǎo)致AI不能正確的完成對(duì)應(yīng)任務(wù)。

那其實(shí)只要能夠想辦法讓AI在寫代碼前獲得足夠的上下文，這樣bug也會(huì)降低很多很多。

于是我開始調(diào)整自己和AI協(xié)作的方式，在拿到一個(gè)需求后，我不會(huì)急著讓它寫代碼，而是遵循這樣一套流程：

1.定位代碼位置：先讓AI把和這個(gè)需求相關(guān)的所有代碼都找出來，明確說明這些代碼文件都存放在哪。

2.理解邏輯：搞清楚現(xiàn)有功能是如何運(yùn)作的，新功能需要在什么位置介入。

3.輸出方案：開始寫代碼，搞定需求

前兩步的重點(diǎn)是讓AI看清楚現(xiàn)狀，提供更多的上下文信息。

當(dāng)AI具備了足夠的上下文信息，再去寫代碼，成功率會(huì)很高，bug也會(huì)減少很多。

提示詞管理2.0版本的開發(fā)進(jìn)度中，我也采用了這個(gè)方法，對(duì)比之前的開發(fā)效率提升了太多了，要么那么多新功能和架構(gòu)調(diào)整，我壓根就搞不完。。。

那這個(gè)流程到底有多好用？我挑了兩個(gè)我親手踩過坑、后來靠它救回來的案例，帶大家一起體驗(yàn)一下它的絲滑。

1.Cursor案例：版本號(hào)管理的bug修復(fù)

這是個(gè)小bug，主要是因?yàn)槲以谡{(diào)架構(gòu)的時(shí)候動(dòng)的太多了，導(dǎo)致我的版本號(hào)管理文件好像被誤刪了，現(xiàn)有的版本管理邏輯和舊的對(duì)不上。

第一步：用Cursor快速定位文件

我需要cursor幫我修復(fù)這個(gè)問題，于是我先讓它找對(duì)應(yīng)的文件：

cursor自己查找了對(duì)應(yīng)代碼，告訴我現(xiàn)在的new是哪些文件來控制的，現(xiàn)在的邏輯是什么。

第二步：和Cursor一起梳理邏輯

然后繼續(xù)和cursor討論，得出一個(gè)功能開發(fā)的邏輯。

第三步：讓Cursor生成修復(fù)方案

確認(rèn)cursor都理解了，就讓它開發(fā)就好了。

然后我測(cè)試了一下效果，改的沒有任何問題。

2.claudecode：提示詞增刪改查bug修復(fù)

這是個(gè)超級(jí)大的bug，我花了好幾天時(shí)間在上邊才把它改明白。

我之前寫代碼的時(shí)候過于讓AI發(fā)揮，于是提示詞增刪改查它給我做了3套系統(tǒng)，導(dǎo)致我后續(xù)修改的時(shí)候，每次修改都只能疊加更多的bug。

第一步：讓Claudecode定位文件

于是我需要claudecode幫我徹底解決這個(gè)問題，老樣子還是讓它先定位問題：

因?yàn)檫@個(gè)bug我改了一下午我實(shí)在沒修復(fù)，這一次我就直接用“AI協(xié)作教練”提示詞出的指令，讓claudecode先把這塊的邏輯完整的讀一遍。

然后claudecode吭哧吭哧干了半天，給了我一個(gè)文檔，基本上覆蓋了這個(gè)場(chǎng)景下的所有邏輯。

第二步：和claudecode一起梳理邏輯

然后我和它繼續(xù)討論，讓它給到了我明細(xì)的流程圖。

第三步：讓claudecode生成修復(fù)方案

基于流程圖，讓它梳理清楚當(dāng)前bug的原因，然后做修復(fù)。

終于一次過了，太不容易了。

這兩個(gè)案例一個(gè)小一個(gè)大，但是其本質(zhì)都是一樣的：幫AI看清現(xiàn)狀，給與AI更多的上下文，從而讓它寫代碼的時(shí)候變得更靠譜，降低代碼率。

在寫這篇稿子的時(shí)候發(fā)現(xiàn)，“提示詞管理助手”2.0版本過審了，那我想在結(jié)尾跟大家聊一些我自己開發(fā)中的心路歷程，聊聊我那些質(zhì)疑過自己無數(shù)次的瞬間。

我開發(fā)一共花了3周，在前兩周架構(gòu)優(yōu)化失敗后，我腦子中其實(shí)有一個(gè)聲音告訴我，這個(gè)產(chǎn)品你其實(shí)沒必要做那么重，只要能用就行了。

新功能簡(jiǎn)單做一下，沒有什么致命bug，前端樣式和架構(gòu)其實(shí)都不用調(diào)。只需要花一兩天新版本就能推上去了，開發(fā)難度降低了很多。

從理性角度來講這是正確的，但我想認(rèn)真做好產(chǎn)品。

我可以接受花更多的時(shí)間，可以接受少寫一點(diǎn)文章少一些流量，我想把這個(gè)產(chǎn)品做好，堅(jiān)持迭代下去。

我在“提示詞管理助手”開發(fā)完，去找小排老師和大銘老師得瑟的時(shí)候是這么說的：我的新版本開發(fā)完了，我感覺我的AI編程水平又往前邁了一大步。

如果我當(dāng)時(shí)選擇了偷懶，選擇了不面對(duì)這一關(guān)，會(huì)錯(cuò)過很多美麗的風(fēng)景的。

我想，還是要認(rèn)真做好每一件事情，對(duì)得起自己，對(duì)得起用戶，對(duì)得起良心。

這世界的力終究是反作用的，你給這個(gè)世界什么樣的力，它會(huì)還回來的。