哈嘍，我是老劉
老劉用Flutter開發客户端也有六七年了，這兩年在工作中使用AI的地方有很多。
有的地方很爽，有的地方很難受，但是總體感覺還是利大於弊的。
不過前兩天看到這篇文章，也確實道出了AI編程中那些我們不得不面對的問題。
比如老劉聊過的一家 8 人的初創團隊，使用 AI 編碼，一週的PR 數量翻了三倍。
結果線上事故也翻了三倍。
原來兩週一次迭代，最近三天一次合併，半天一次回滾。
項目管理工具一片綠，線上監控一片紅。
這不是“AI 要讓程序員失業”。
這是“AI 正在讓團隊失控”。
為什麼會這樣？
很簡單：AI 寫得快，但不會替你做工程治理。
它能自動補全，卻不會自動覆盤。
它能一秒生成代碼，卻不能替你建立邊界、規範和兜底機制。
所以 CTO 們喊停，不是倒車。
是先把安全帶繫上，把車燈調亮，把路標豎好。
先把“能不能跑”換成“穩不穩跑，能不能收”。
接下來我們聊聊，AI開發在真正的企業開發中到底扮演了什麼角色，以及如何有效的利用AI。
AI 編程的真相，提效是事實，翻車也是真事
先説好的一面。
AI 編程確實有三大利好，老劉親測有效：
第一，提升效率。
標準化、重複性強的代碼，AI "嗖嗖"就來。
寫個 CRUD 接口，以前半小時，現在 5 分鐘。
寫個數據模型類，以前敲鍵盤敲到手痠，現在描述一下需求就行。
老劉團隊統計過，純編碼環節效率提升了 60% 都不止。
第二，降低門檻。
新人上手更快，能看懂結構、補齊語法。
以前新人寫個複雜的動畫效果，需要查手冊，自己調試，折騰很久。
現在 AI 直接給出標準寫法，還帶註釋。
第三，重構利器。
對遺留系統做現代化改造有奇效。
比如老劉的項目時原生 + Flutter混合開發。
當一個需求對老頁面或者老模塊的修改高於50%的時候，我們就會用Flutter重寫。
這種情況下AI將老頁面轉換為Flutter頁面的效率奇高。
但是，硬幣總有另一面。
AI 編程有三大致命坑，每個都能讓你懷疑人生：
第一坑：架構缺位。
AI 不懂你的全局業務與約束，容易"就地拼貼"。
它只看到你當前的代碼片段，不知道你的系統邊界在哪裏。
結果就是，單個模塊看起來很完美，整體架構一團糟。
老劉見過一個場景，新增一個促銷用的大模塊，AI 生成的代碼每個函數都很優雅。
但是這些代碼拼在一起，就好像是找了一堆實習生寫的代碼，拼接到一起，就成了一個大的系統。
第二坑：隱形技術債。
Demo 看着順眼，長線維護是"堆屎山"。
AI 為了快速實現功能，經常選擇最直接的路徑。
不考慮擴展性，不考慮維護性，不考慮性能優化。
3 個月後你再看這些代碼，想改一個小功能，牽一髮動全身。
第三坑：維護地獄。
"調試像考古"，上下文與意圖缺失。
AI 生成的代碼往往缺少關鍵的業務邏輯註釋。
你知道它做了什麼，但不知道為什麼這麼做。
出了 bug，你得像考古學家一樣，一層層挖掘代碼的真實意圖。
更要命的是生產環境的三座大山：
性能問題：小樣本 OK，大流量崩。
AI 寫的代碼在測試環境跑得飛起，一上生產就趴窩。
安全漏洞：權限邊界出血，數據泄露風險。
AI 不懂你的安全策略，有可能在權限控制上留後門，這裏並不是説它是故意的，而是很多情況可能會考慮不到。
可擴展性：沒考慮未來增長，架構僵化。
當用户量從 1000 漲到 10 萬，系統很有可能會撐不住。
一句話總結：
AI 是"強力螺絲刀"，不是"自動蓋房機"。
它能幫你擰螺絲，但房子的設計圖，還得你來畫。
（1、至少現階段是這樣）
（2、Claude Code在這方面表現會好一點）
那麼我們應該怎麼辦呢？是徹底拋棄AI回到原來？還是有切實可行的手段降服AI？
別跟風，給 AI 上"繮繩"的 5 步工作法
答案當然不是拋棄，而是給AI套上"繮繩"。
老劉結合這兩年的實戰經驗，總結了一套"防失控"的 5 步工作法：
第一步：邊界清單先行
別什麼都交給 AI，先畫清楚紅線。
適合交給 AI 的：
- 樣板代碼：比如 CRUD 接口、數據模型類
- 單元測試：特別是邊界值測試和異常處理測試
- 文檔生成：API 文檔、代碼註釋自動補全
- 重構建議：代碼優化和性能提升建議
不適合交給 AI 的：
- 核心業務邏輯：支付流程、用户權限控制
- 安全關鍵代碼：加密解密、身份驗證
- 複雜算法：推薦算法、計費邏輯
這個邊界不是一成不變的，根據團隊、項目和AI工具的不同而變化，但在團隊內必須明確且統一的。
也就是説團隊裏每個人都要知道，哪些能碰，哪些不能碰。
第二步：設計先、落碼後
這是最關鍵的一步。
不要上來就讓 AI 寫代碼，先由人畫清架構圖、數據流、接口邊界。
把整個系統的"骨架"搭好，再讓 AI 按"空位"補代碼。
就像裝修房子，先把水電佈局、承重牆確定好，再讓 AI 幫你貼瓷磚刷油漆。
老劉的做法是：每個功能模塊開發前，先用 30 分鐘畫個簡單的架構圖。
標清楚輸入輸出、依賴關係、邊界約束。
然後把這個架構圖貼給團隊，大家 Review 通過了，再開始用 AI 寫具體代碼。
第三步：雙層防線
Code Review 和自動化測試，一個都不能少。
Code Review 重點看什麼？
- 業務邏輯是否正確
- 權限控制是否到位
- 異常處理是否完善
- 性能是否有問題
別隻看代碼風格和語法錯誤，那些 AI 比人做得好。
要看 AI 看不到的東西：業務上下文、安全邊界、性能瓶頸。
自動化測試要覆蓋核心鏈路。
特別是用户註冊、登錄、支付這些關鍵流程，測試用例必須跟上。（當然，如果能結合TDD其實更好）
第四步：可觀測與壓測
別拿"小樣本正常"當真相。
AI 生成的代碼在開發環境跑得好，不代表生產環境也 OK。
必須要有：
- 性能基準數據
- 壓力測試驗證
- 完善的監控報警
老劉團隊的做法是：每各版本都要跑壓測。
模擬真實用户量，看看系統會不會崩。
監控指標也要跟上：響應時間、錯誤率、資源使用率。
第五步：迭代與回滾
小步快跑，灰度發佈，預設回滾預案。
別搞"豪賭式上線"，一次性把所有 AI 代碼都推到生產。
先推 10% 流量，觀察 24 小時。
沒問題再推 50%，最後推 100%。
每個階段都要有明確的回滾觸發條件：
- 客户端可以看崩潰率，用户投訴等指標。
- 服務端要看響應時間，內存佔用等指標。
還有三條紅線，踩到任何一條都是找死：
- 不懂就上：對 AI 生成的代碼不理解，就直接用
- 不審就上：跳過 Code Review，直接合並
- 無人負責：沒有明確的責任人，出了問題找不到人
這些坑老劉都見過團隊踩，甚至有些我們團隊自己都踩過，每一個都是血的教訓。
總結：與其追風，不如馭風
説到底，AI 是工具而非替代。
架構設計、業務判斷、技術責任，還是要由人類技術負責人扛。
AI 可以讓你的手速更快，但不能替你做決策。
它可以幫你生成代碼，但不能替你承擔後果。
記住這句話：別指望 AI 寫出你的戰略，它只會加速你的選擇。
方向錯得越早，坑就挖得越快。
所以，與其盲目追風，不如學會馭風。
讓 AI 成為你手中的利器，而不是脱繮的野馬。
最後問個問題：你的團隊把哪些環節交給了 AI？又有哪些"生死線"你絕不交？
歡迎在評論區分享你的經驗和踩坑故事。
如果看到這裏的同學對客户端開發或者Flutter開發感興趣，歡迎聯繫老劉，我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。
覆蓋90%開發場景的《Flutter開發手冊》
