隨著AI技術(shù)的飛速發(fā)展，AI編程工具逐漸成為開發(fā)者的新寵。它們能夠在短時(shí)間內(nèi)生成代碼框架，極大地提升了開發(fā)效率。本文作者通過親身體驗(yàn)，分享了使用Trae編輯器和Claude-3.5/3.7開發(fā)項(xiàng)目的心得，探討了AI編程工具在高效與困擾之間的平衡，并對未來的發(fā)展提出了展望。

最近，我基于Trae編輯器和Claude-3.5/3.7進(jìn)行了較為高頻的使用，開發(fā)了一個(gè)略復(fù)雜的產(chǎn)品Demo。同時(shí)，我的領(lǐng)導(dǎo)（沒有編程背景）也在使用AI編程軟件做一個(gè)企業(yè)官網(wǎng)。以下是我的使用體驗(yàn)和感受。

做60分容易，做90分難

由于是從0開始做這個(gè)項(xiàng)目，我大概確定了使用的技術(shù)方向和功能后，就通過Trae 提供的 Builder(Beta)，將提示詞輸入后，很快就生成了60分的一個(gè)項(xiàng)目代碼，通過運(yùn)行，基本提到的內(nèi)容都基本涵蓋。運(yùn)行起來也不錯(cuò)。

但隨著我把項(xiàng)目從大框架往細(xì)化去進(jìn)行時(shí)，隨著代碼量的增加，變出現(xiàn)了問題。

問題一：代碼無法完整讀取

由于prompt數(shù)量的緣故，無法完整的獲取到代碼， 導(dǎo)致在修復(fù)部分問題時(shí)，原本可能已經(jīng)有的方法， 由于沒有獲取到，導(dǎo)致會(huì)再次生成，導(dǎo)致出現(xiàn)了重復(fù)的代碼。

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

特別是我使用的python ，由于語言的特性， 重復(fù)的方法名并不會(huì)報(bào)錯(cuò)，還可以編譯運(yùn)行，導(dǎo)致你修改了在后面的方法， 結(jié)果系統(tǒng)執(zhí)行的是前面的方法，一直無法排查到原因的情況。

問題二：會(huì)進(jìn)入問答循環(huán)

由于prompt數(shù)量的緣故，當(dāng)對話量和代碼量不斷增加時(shí)，bug排查工作就會(huì)面臨挑戰(zhàn)。

在這個(gè)過程中，常常會(huì)陷入問答循環(huán)的困境。

這是因?yàn)楦鞣N因素導(dǎo)致AI不能很好地解決問題，進(jìn)而只能重復(fù)之前回答過的內(nèi)容，使得問題無法得到有效解決。

我的領(lǐng)導(dǎo)也遭遇過這種情況，他因?yàn)閷Υa缺乏了解，所以想到的應(yīng)對策略是新開啟一個(gè)對話，讓AI重新開始作答，以清除之前的記憶狀態(tài)。

然而，我卻只能憑借仔細(xì)閱讀代碼、設(shè)置斷點(diǎn)的方式來排查bug，等找到bug之后，再利用自己的能力或者尋求AI工具的幫助來修復(fù)和完善代碼，這種方式相較于領(lǐng)導(dǎo)的辦法更為高效。

問題三：等待，等待，等待

或許是使用量較大，做了流量的控制，在周末使用Trae，特別是Claude-3.7時(shí)，很容易遇到等待，大概100左右的排隊(duì)，從提問到獲得知識(shí)，可能需要10分鐘左右甚至更長的時(shí)間，無形中影響了體驗(yàn)。

總結(jié)

從目前來看，上述兩個(gè)問題，與當(dāng)下大模型token的輸入量、算力有很大的關(guān)系，在未來會(huì)得到很好的解決，當(dāng)下的體驗(yàn)還是有待提升。

因此，對于沒有太多編程經(jīng)驗(yàn)的來說，做到60分是很容易的。對于編寫基本的python腳本、基本的網(wǎng)頁可能是滿足的，但如果再復(fù)雜一點(diǎn)的，可能就需要你有一定的編程經(jīng)驗(yàn)了。通過閱讀代碼，幫助AI工具定位問題和代碼， 來讓AI幫你修復(fù)bug，確實(shí)是個(gè)高效的方式，至少比查百度和 CSDN 要快速很多。

跳不脫認(rèn)知邊界

在做第一版項(xiàng)目時(shí)，我表達(dá)了項(xiàng)目功能后，由于沒有說具體的編程框架，導(dǎo)致AI在一個(gè)文件里生成所需要的代碼，隨著功能的增加，代碼逐漸超過了1000行，而如果使用 Trae提供的代碼替換功能，如果文件代碼超過1000行，就無法進(jìn)行替換了，同時(shí)在問答效果上，也會(huì)大大折扣。

有了第一次經(jīng)驗(yàn)，我于是便對代碼進(jìn)行重構(gòu)，新起了一個(gè)工程，在第一次的提示詞中，增加了“使用MVC理念進(jìn)行編程，同時(shí)盡量讓每個(gè)文件代碼控制在300行左右“，再一次生成中，果然遵循了MVC的設(shè)計(jì)理念，代碼做了分拆，效果上自然也好了很多。

而對于沒有編程理念的，可能遇到后，就會(huì)問AI工具，如何進(jìn)行分拆，也不一定出現(xiàn)使用MVC設(shè)計(jì)理念的情況，僅僅是讓代碼能夠運(yùn)行而已。而對于編程小白來講，似乎也很難知道MVC設(shè)計(jì)理念或其他的方法。

因此，在使用AI編程工具時(shí)，在寫prompt時(shí)，大多數(shù)人只能想到生成HTML、python代碼等較為知曉的工具，而對于該工具是否是最理想的， 是否有更好的替代，對于沒有太多編程經(jīng)驗(yàn)的來講，也不太敢去嘗試，畢竟可能會(huì)付出更多潛在的成本，用一個(gè)相對熟悉一點(diǎn)的語言，通過自身的知識(shí)加AI的輔助，或許是個(gè)不錯(cuò)的選擇。

而這或許恰恰就是一個(gè)不錯(cuò)的機(jī)會(huì)。畢竟現(xiàn)在的AI，盡管有了推理模型，但不同的prompt所輸出的效率差距，還是很大的。

總結(jié)

從個(gè)人使用的角度來看，AI編程工具確實(shí)提高了很大的效率，但目前它更像是一個(gè)“拐杖”，提供一定的輔助和幫助。對于編程能力較高的人，AI工具可以節(jié)省時(shí)間和提高效率；對于編程小白，AI工具可以幫助他們完成基礎(chǔ)任務(wù)。

只是大多數(shù)人，希望它是輪椅，而且還是個(gè)電動(dòng)的。很顯然，當(dāng)下還有點(diǎn)距離。

特別說明： 本文章所有的結(jié)論，都是基于最近使用基于 Trae 編輯器和 Claude-3.5/3.7 所使用的結(jié)果，考慮到個(gè)人能力的差異，并不代表當(dāng)下AI編程的真實(shí)實(shí)力，僅僅作為自己使用的感受。