天天看點

像用實習生一樣用 AI 輔助你程式設計

不少人認為大模型現在已經這麼強了,做點事怎麼感覺這麼弱智。其實,政治的使用方法,是像帶實習生一樣使用AI工具——就像作者在正文中分享的經驗一樣。
像用實習生一樣用 AI 輔助你程式設計
我是不敢讓 ai 幫我寫程式的,每回問它的問題,十次倒有八次是錯的,問完之後還要自己去網上搜一遍,然後反複測試,才敢寫進代碼。不知道大家怎麼甩手給它的。——響馬

響馬毫無疑問是程式設計高手,幾十年的開發經驗,另外他寫的代碼都屬于一些底層代碼,被訓練過的比例極少,AI 大機率寫不出來高品質代碼,不放心讓 AI 幫忙寫程式正常。但對于普通程式員來說,不一定要像響馬那樣,拒絕 AI 的幫助。

比如我就是個普通程式員,寫的都是一些簡單的前端 UI 代碼,或者後端增删改查代碼,并沒有太高技術含量,就經常讓 AI 給我幫忙,還是讓我效率提升不少的。我總結下來經驗就是:像用實習生一樣用 AI 輔助你程式設計。

在科技公司或者開發團隊經常能看到這樣的場景:某些資深程式員,寫代碼特别牛,效率特别高,但是很多活都壓在他們身上,成為了團隊瓶頸,于是老闆說,這樣不行,給你幾個實習生或者新手程式員幫你分擔一些吧。

大多數時候這種提議是被拒絕的,倒不是他們藏私不願意帶人,而是在他們看來,把活交給實習生,一個簡單的任務都要花幾天時間,自己一小時就做完了,中間還要溝通,做完品質不行還要幫忙擦屁股,花的時間超過自己寫的時間,一點都不合算,另可自己做。

這些确實是事實,但是可能忽略了一些問題:

  1. 實習生是會成長的,很多事情教了一遍就不需要再教第二遍了。
  2. 再複雜的程式也是有些“體力活”的,比如說搭個腳手架,新增個子產品,簡單的重命名/重構,等等。對于資深程式員來說,老是幹體力活會倦怠的,但是對實習生來說正好是一個學習的好機會。
  3. 能從實習生身上學習到新的東西。當我們對一門技術太熟悉,會有路徑的依賴,不太容易發現或者接受新的技術,同樣的任務讓實習生做,雖然大多數時候不如你做的,但是也會有眼前一亮的時候,能學到一點新的東西或者開闊一下眼界:原來還可以這樣!
  4. 如果你的任務不能交給實習生做,也許架構上存在一些不足,無法合理的将功能拆分。有些程式員的活不能拆分出來,一個原因可能是架構還不夠好,子產品都在一起,無法拆分。當然即使拆分後肯定還是有些複雜子產品是無法進一步拆分的,這不在此列。

我在帶實習生上有一些經驗,是以在使用 Cursor 或者 GitHub Copilot 的時候,就是把 AI 當成一個實習生用,效果是很好的。

01 首先體力活都交給 AI 來做

體力活指的是那種重複的、要求不高的、繁瑣的工作。比如說:

  • 建立一個頁面、一個 API
  • 一個資料庫增删改查的子產品
  • 單元測試

這些活說難也不難,但是自己寫有點麻煩,是以我每次都是 Cursor 裡面用 CMD+i 喚出 Composer,把相關代碼檔案都添加上作為上下文,然後提出要求,一個初始的功能就有了。

比如我要為自己的部落格網站增加一個 Sitemap 的功能,我當然可以自己寫,但光檔案都得建立好幾個,還得寫一些基本的讀取資料庫和輸出 Sitemap 代碼,甚至我還得去查詢一下 Sitemap 規範。正因為如此,是以我一直懶得加上這功能。

像用實習生一樣用 AI 輔助你程式設計
像用實習生一樣用 AI 輔助你程式設計

很快就幫我把相關檔案都建立好了,雖然說 robots.txt 都給我做成動态的有點業餘,但是也還好,至少我知道了内容應該是什麼,懶一點就讓它重新生成個靜态檔案,勤快一點就手動建立一個。剩下的就是調試一下,沒什麼問題就可以釋出了。

像用實習生一樣用 AI 輔助你程式設計

理論上基于這個結果,還可以一直提要求,知道滿意為止,或者差不多了自己接管手動修改一下。

我個人是覺得,讓 AI 幫忙先實作一個基本的子產品,意義不僅僅在于減少了體力活,而是幫你開了個頭!萬事開頭難,很多時候真的就是因為沒有一個開頭就沒繼續,當有個初始的結果,哪怕爛一點,再基于它上面修改要簡單很多,更容易傳遞。

02 給“實習生”一個葫蘆,讓他們學着畫瓢

對于實習生來說,稍微複雜一點任務很難從無到有做出來,但是如果給他們一個已經做好的子產品作為參考,照着葫蘆畫瓢,那麼也能做個差不離。

讓 AI 幫你程式設計也是一樣的,你不能指望 AI 能像你一樣厲害懂你的代碼庫,但是你可以教它,把一個類似的實作代碼給它參考,甚至于寫一段僞代碼讓它實作。

就拿前面 sitemap 的例子,添加到上下文的 feed.xml/route.ts 就是“葫蘆”,有了這個“葫蘆”,它去“畫瓢”就容易多了,它可以從中去學習最佳實踐是什麼。

03 設計架構和技術選型的時候,選“實習生”熟悉容易上手的技術

技術選型是一個讓人糾結的事情,需要各種考量,現在更是多了一個次元,就是要考慮把 AI 當成你的團隊成員,想讓 AI 能更好的幫你幹活,那麼就少造一些輪子,少用一些偏僻的架構或類庫,用那種最流行的,訓練語料最多的架構和庫。

比如我在給自己搭建部落格的時候,選的 Nextjs、Tailwindcss、ShadcnUI、D1(Sqlite),這些都是相當流行和容易上手的架構和庫,是以我讓 AI 幫我實作一個 Sitemap,它能知道在什麼建立檔案,遵循什麼規範,寫 UI 也知道如何幫我添加正确的 CSS。

04 将複雜任務分解成簡單的任務,讓“實習生”幫你完成小的子產品

資深程式員和新手程式員的一個分界,就是能不能将複雜子產品拆分成簡單的小子產品。比如我要搭建一個自己的部落格網站,就 AI 現在的能力,是沒辦法自動完成這樣一個項目,但是我可以讓它幫我建立一個頁面,幫我實作一個資料庫讀寫的功能子產品,幫我基于資料庫讀寫子產品實作一個 API,而我自己,則可以聚焦于資料庫的表設計、系統的架構設計、UI 設計這些事情上。

05 向“實習生”學習

現在在實作功能的時候,哪怕我比較熟悉的,我會習慣性問一下 AI,讓它幫我生成一段代碼,雖然大多數時候它不一定比我寫的更好,甚至是錯誤的,但有時候它能提出一種全新的我沒考慮過的思路,那我就能從中學習到點什麼,以後可能就用的上了。

就像大數學家陶哲軒,也在用 AI 幫忙解決數學問題,并非 AI 數學比他厲害,而是給他提供了不一樣的思路。

我曾遇到過一個問題,我嘗試了幾種方法,但都無法解決。于是,我嘗試詢問 GPT,你建議我使用什麼其他方法來解決這個問題?GPT 給我提供了 10 種可能的方法,其中有 5 種我已經嘗試過,或者明顯沒有幫助。的确,有幾種方法并不實用。但其中有一種我還沒嘗試過的方法,那就是針對這個問題使用生成函數。當 GPT 建議我使用這種方法時,我意識到這就是我漏掉的正确方法。是以,将 GPT 視為一個交流夥伴,它确實具有一定的用處。——陶哲軒

06 對“實習生”産出的結果要驗證

既然 AI 隻是一個實習生,那麼就說明它生成的代碼是靠不住的,哪怕看起來很好,總是要像對待實習生一樣,去對代碼做審查,了解它實作的思路,對結果進行測試驗證,出現問題讓 AI 改進或者手動修複。

如果有人去責怪産品的問題是因為 AI 生成的品質不行,那隻能說明是在甩鍋,就像你生産環境的故障不能怪這是實習生寫的,難道你們不做 Code Review,不做 QA 的嗎?

07 最後

這是我在日常使用 AI 輔助程式設計的一點經驗分享。如果你把 AI 當成一個資深程式員,那麼你大概是要失望的,但是如果你把 AI 當作一個實習生,它真的可以做不少事情,讓你提升程式設計效率。

另外一些現在 AI 還不能完全替代專業程式員的地方:

  • 基于業務需求進行抽象和架構設計的能力
  • 對複雜問題進行分解和統籌規劃的能力
  • 出現問題定位和調試的能力
  • 當然還有出問題背鍋的能力

歡迎分享你的經驗!

本文由人人都是産品經理作者【賽博禅心】,微信公衆号:【賽博禅心】,原創/授權 釋出于人人都是産品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于 CC0 協定。

繼續閱讀