不少人認為大模型現在已經這麼強了，做點事怎麼感覺這麼弱智。其實，政治的使用方法，是像帶實習生一樣使用AI工具——就像作者在正文中分享的經驗一樣。
我是不敢讓 ai 幫我寫程式的，每回問它的問題，十次倒有八次是錯的，問完之後還要自己去網上搜一遍，然後反複測試，才敢寫進代碼。不知道大家怎麼甩手給它的。——響馬
響馬毫無疑問是程式設計高手，幾十年的開發經驗，另外他寫的代碼都屬于一些底層代碼，被訓練過的比例極少，AI 大機率寫不出來高品質代碼，不放心讓 AI 幫忙寫程式正常。但對于普通程式員來說，不一定要像響馬那樣，拒絕 AI 的幫助。
比如我就是個普通程式員，寫的都是一些簡單的前端 UI 代碼，或者後端增删改查代碼，并沒有太高技術含量，就經常讓 AI 給我幫忙，還是讓我效率提升不少的。我總結下來經驗就是：像用實習生一樣用 AI 輔助你程式設計。
在科技公司或者開發團隊經常能看到這樣的場景：某些資深程式員，寫代碼特别牛，效率特别高，但是很多活都壓在他們身上，成為了團隊瓶頸，于是老闆說，這樣不行，給你幾個實習生或者新手程式員幫你分擔一些吧。
大多數時候這種提議是被拒絕的，倒不是他們藏私不願意帶人，而是在他們看來，把活交給實習生，一個簡單的任務都要花幾天時間，自己一小時就做完了，中間還要溝通，做完品質不行還要幫忙擦屁股，花的時間超過自己寫的時間，一點都不合算，另可自己做。
這些确實是事實，但是可能忽略了一些問題：
- 實習生是會成長的，很多事情教了一遍就不需要再教第二遍了。
- 再複雜的程式也是有些“體力活”的，比如說搭個腳手架，新增個子產品，簡單的重命名/重構，等等。對于資深程式員來說，老是幹體力活會倦怠的，但是對實習生來說正好是一個學習的好機會。
- 能從實習生身上學習到新的東西。當我們對一門技術太熟悉，會有路徑的依賴，不太容易發現或者接受新的技術，同樣的任務讓實習生做，雖然大多數時候不如你做的，但是也會有眼前一亮的時候，能學到一點新的東西或者開闊一下眼界：原來還可以這樣！
- 如果你的任務不能交給實習生做，也許架構上存在一些不足，無法合理的将功能拆分。有些程式員的活不能拆分出來，一個原因可能是架構還不夠好，子產品都在一起，無法拆分。當然即使拆分後肯定還是有些複雜子產品是無法進一步拆分的，這不在此列。
我在帶實習生上有一些經驗，是以在使用 Cursor 或者 GitHub Copilot 的時候，就是把 AI 當成一個實習生用，效果是很好的。
01 首先體力活都交給 AI 來做
體力活指的是那種重複的、要求不高的、繁瑣的工作。比如說：
- 建立一個頁面、一個 API
- 一個資料庫增删改查的子產品
- 單元測試
這些活說難也不難，但是自己寫有點麻煩，是以我每次都是 Cursor 裡面用 CMD+i 喚出 Composer，把相關代碼檔案都添加上作為上下文，然後提出要求，一個初始的功能就有了。
比如我要為自己的部落格網站增加一個 Sitemap 的功能，我當然可以自己寫，但光檔案都得建立好幾個，還得寫一些基本的讀取資料庫和輸出 Sitemap 代碼，甚至我還得去查詢一下 Sitemap 規範。正因為如此，是以我一直懶得加上這功能。
很快就幫我把相關檔案都建立好了，雖然說 robots.txt 都給我做成動态的有點業餘，但是也還好，至少我知道了内容應該是什麼，懶一點就讓它重新生成個靜态檔案，勤快一點就手動建立一個。剩下的就是調試一下，沒什麼問題就可以釋出了。
理論上基于這個結果，還可以一直提要求，知道滿意為止，或者差不多了自己接管手動修改一下。
我個人是覺得，讓 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 協定。