想必技術圈兒的各位都已經體驗過各種AI程式設計工具了吧？從大名鼎鼎的Cursor、Cline，到冉冉升起的國產新星Trae們。從公眾號到抖音甚至小紅書，全部都是“我用AI程式設計一天上架一個APP”、“用了XXX我立刻裁掉一半程式設計師！”這樣吸睛的內容。
更有甚者，有些大廠甚至給出了“AI程式設計佔比”這樣離譜的KPI…似乎一夜之間AI程式設計已經成了絕對的“正確”，不擁抱AI程式設計的團隊已經“落伍”了。
然而根據我自己的體會，以及和一些朋友聊過後，發現“全員AI程式設計”不僅沒有看上去的那麼美，而且很有可能會毀了你的研發團隊！
如果你是獨立開發者，或者是一個創業初期的小團隊。 你作為老闆/技術負責人能夠完全掌控所有的程式碼和技術實現，那麼擁抱AI程式設計吧！它會極高地提高你的效率。它甚至會改變你的很多認知，之前不敢嘗試的領域也敢大膽涉足了。
如果你是一個資深的程式設計師，你對你所用的技術棧有較為深刻的理解和直覺，那麼也擁抱AI程式設計吧！ 它能幫你省下大量的時間，讓你可以更加專注地去解決真正需要解決的問題。
如果你是一個較大型專案的技術負責人。專案大到你無法review團隊產出的所有程式碼，無暇去了解、參與每一個技術決策。 你的手下有多於1個層級的技術團隊。 那麼請小心了，如果無腦在團隊裡推行AI程式設計，可能會帶來你難以想象的危害！
危害有兩方面：一是業務層面的，一是團隊層面的。
業務層面的危害比較直觀，也比較好理解。有可能AI一個撒歡兒+某個程式設計師的無腦提交，直接幹崩了你苦苦支撐，雖然難看但能work的屎山程式碼……也有可能是AI巧妙地掩蓋了一個原本會報崩潰的bug，導致你的業務幾個月後出現了一個極難排查的異常問題…… 列舉AI的幾宗罪：
1，檔案命名隨意、目錄結構混亂。在多個目錄出現重名檔案並引起後續混淆。
2，按捺不住的重構最佳化衝動。你讓它加一句日誌，它能把你整個類的實現都給重寫了。
3，想當然地憑空捏造資料結構、亂改引數、欄位名。
4，胡亂指定依賴庫版本，總是使用一些已經過時廢棄的方法。
5，喜歡重新發明輪子，而不是使用專案中已經提供的工具類。
6，喜歡透過捕捉異常、頭痛醫頭等方式掩蓋錯誤。
……
這些問題倒是都有解法。配置專案級的cursor rule、撰寫並維護良好的README、架構文件、介面文件等，都能大幅改善。但注意，只是改善，無法從根上杜絕。 還是需要依賴一執行緒序員的規範使用、認真review以及技術負責人足夠高密度的檢查和覆盤。
作為技術負責人，如果你手下的程式設計師、小組長們都有良好的素質、較強的責任心那還好。否則，你就等著被坑死吧……
團隊層面的問題則更加深遠。
首先是人才成長問題。一般具有一定規模的研發團隊，都會形成人才梯隊，遵循7-2-1的原則。大量的研發人員其實是比較初階的程式設計師。他們有幹勁兒，能加班兒，思維活躍，容易接受新技術，但在系統性思維、全域性性思維以及具體經驗上和老鳥兒們還是存在差距。
AI也許能幫助初階程式設計師快速上手專案，但很多所謂“經驗”、“技術直覺”是要靠自己寫程式碼一點一點摸索體會的。 如果過度依賴AI程式設計，會導致很多年輕程式設計師“知其然，不知其所以然”。在AI的幫助下很快交付了程式碼，但為什麼這裡選用這個設計模式，為什麼那裡要加個保護，其實他自己依然是懵的。他沒有經歷過“探索-受挫-覆盤-改進”這些過程，那麼他的認知必然上升有限，下次再遇到類似的場景，依然無所適從，只能再等著AI出手，也就無從談起對AI產出程式碼的檢查稽核了。
這裡又會涉及另一個問題。在沒有AI的時代，一個新人程式設計師遇到困難會怎麼辦？除了萬能的stackoverflow， 更多的是向mentor、老員工請教（所謂“傳、幫、帶”）。老人帶著新人解決一個個的問題。在一次次溝通中，新老員工既完成了知識傳遞，也完成了“認知對齊”（原諒我用了網際網路黑話，但似乎‘對齊’在這裡很適合）。Leader們可以較為容易地瞭解每個員工的實際水平、做事風格，可以有針對性地安排工作、培訓輔導。
但是大人，現在時代變了，AI來了。一個個“愣頭青”們無需請教老員工，直接問AI就好了。他們很快就被AI包在了資訊繭房裡，不斷地對外交付著產出，團隊內的有效溝通可能會下降，Leader們也很難了解新人們的實際情況，直到有一天把一個很重要的模組交給了他，而這位“愣頭青”則完全依賴AI生成的程式碼完成了交付，並且出現了前文提到的悲劇。
所以你看，如果盲目在技術團隊內推廣AI程式設計的話，有可能會影響新人員工的成長，也會干擾團隊內部的“認知對齊”。
那麼，是否有解決辦法呢？坦率地說我也沒想到好的辦法，這可能是AI時代技術管理者們需要重視的一個課題。我能想到如下幾點：
1，嚴格規範團隊內的AI使用。統一使用rules配置，完善專案說明文件、介面文件等。
2，在涉及公司業務的專案裡禁止使用全自動/Agent模式。遵循一次只改一個檔案，改一次review一次，review+測試後才提交。
3，加強單元測試。把問題儘早暴露，而且透過寫單元測試，也能很好地與AI對齊需求，有助於AI寫出你真正想要的程式碼。
4，更加完善的程式碼審查。這是一句正確的廢話。但是，沒辦法，歡迎來到AI時代！
當然，這些都是紙上談兵。員工在自己的電腦上敲程式碼，你沒法控制他實際如何使用AI。只能說，作為技術Leader，你肩上的擔子壓得更實了。
AI的參與相當於你團隊裡來了個新員工，而且是個無法績效打“C”的員工！作為技術負責人，你要為你的團隊產出負責，你自然也需要為這個AI的產出負責。
拉個討論群吧，關於AI、產品、技術和一切新東西，歡迎對此感興趣的小夥伴一起分享、討論～