放棄吧，不要再看 AI 寫的 Code 了！
前幾天跟一位工程師討論案子規格，他說：「我不太放心讓 AI 全權開發，祂會疊床架屋，明明一樣的東西在不同地方寫成兩套，以後很難維護。」
所以他都會去審核 AI 寫的程式。
我跟他說：「放棄吧，不要再看祂寫的 code 了。」
⸻
🎯 我建議應該這樣做：
1. 讓 AI 自己去 review 祂寫的 code
2. 讓祂提出改進方案並改完
3. 讓祂做完測試
我們要的是最後的結果。
你可以請祂加上 Regression Test，確保祂改的東西不會嚴重影響其他地方。
因為——你再怎麼看 code、再怎麼寫 code，都比不上祂。而且祂進步的速度，比任何軟體工程師都快太多了。
⸻
💡 這讓我想到一件事
軟體工程師剛升主管時，最常犯的錯：自己下去 coding。
以前我帶這些新手主管，都會特別跟他們講：
1. 綁住你的手腳
2. 不要做部屬該做的事
3. 就算覺得不完美，也要接受——否則永遠改不完，而且之後你的部屬會反過來盯著你追進度。
現在碰到的情況一模一樣。
只是這次，這個「部屬」比你更厲害：寫程式更快、學習更快，發展潛力無可限量。
⸻
🔥 這是我接觸軟體產業三十多年來，碰到最大的巨變
你可以選擇忽略祂，但祂的高速發展不會因為你的忽略而改變。
你也可以選擇接受祂，讓祂變成你的超級部屬。
不要再想著去看祂的 Code 了。許多傳統軟體工程機制都會面臨巨大改變：
• 傳統的 Code Review 機制
• 傳統的 Waterfall 流程
• 傳統的 CI/CD、Regression Test
這些將全部被 AI 接管，只是時間早晚的問題，所以——就接受這一切吧。
⸻
📍 寫 Code 不是瓶頸，Review 才是
很多人還在糾結 AI 寫的 code 品質好不好。
但真正用過的人都知道：寫 code 從來不是瓶頸。
瓶頸在哪？
1. 規劃——你自己都沒想清楚要什麼
2. Review——你花更多時間審核，而不是產出
有個十年經驗的工程師說得很直白：「我用 Claude Code 的工作流變成：丟一個模糊 prompt，跑出錯誤結果，反覆迭代，最後發現自己寫還比較快。」
但這問題不在 AI，問題在他還想「審核」每一行。而且這是「現在」，過一週或一個月後，有了新版 LLM，AI 的能力又會上升到另一個等級，任何「人」的 Review 都追不上祂的進化。
當你把 Review 的時間省下來，讓 AI 自己 Review 自己，整個生產力才會真正爆發。
⸻
⚔️ 回應那些擔憂的聲音
「AI 寫的 code 有安全漏洞！」
前陣子 BBC 才報導一個 vibe-coding 平台被駭的新聞。
但我要說：那是平台的問題，不是 AI 的問題。
你讓 AI 幫你做資安檢測，祂會比人類更徹底。我的經驗是，多跑幾輪，每輪都會有新的資安問題被提出。你要做的是決定哪些要改——決策權在你，讓 AI 解釋問題嚴重性並提供建議，你來做決定。
工具沒有對錯，用法才有。資安本身就是強度與體驗的 tradeoff，沒有最好，只有剛好。
「成熟 codebase 上 AI 不好用！」
這是很常見的藉口。
「我們的 codebase 太複雜了，AI 看不懂。」
真的嗎？還是你沒給祂足夠的 context？
我看到的現實是：成熟 codebase 上，AI 反而更有價值。因為沒有人比 AI 更快讀完幾萬行程式碼。你花三天搞懂的架構，祂三分鐘就理解了。
問題不在 AI，問題在你還沒學會怎麼用。
⸻
🚀 我想補充我之前說過的話
上週我寫過一篇文章「砍掉 UIUX 設計師、前端及後端工程師，留下自己和 Claude AI，網站功能迭代更新加速 10 倍！」，提到「這套模式的邊界」：
大型企業系統、需要高度資安合規的金融產品、百萬級併發的基礎設施、需要長期維護的大型 codebase，這些仍然需要專業團隊。
現在我想更新這個想法。
邊界正在消失。
一年前，我覺得 AI 只適合做 MVP。現在，我用 AI 在成熟產品上迭代，速度一樣快。
六個月前，我覺得複雜架構需要人來設計。現在，AI 設計的架構比我想的還周全。
一個月前，我覺得資安合規一定要專家。現在，AI 做的安全檢測比大多數資安工程師還徹底。
這個邊界不是固定的，它正在以超乎想像的速度縮小。
⸻
🕰 2000 年的既視感
這讓我想起 2000 年網路泡沫時，那些「專家」說的話：
「信用卡被盜刷的新聞層出不窮，誰敢在網路上刷卡消費。」
「網路不是剛需，人們的吃喝拉撒睡才是，網路的虛擬世界永遠取代不了人類生活實體需求。」
但如今呢？
你上一次不是用線上支付或線上刷卡買東西是什麼時候？
你的生活有多少比例已經「活在網路上」？
當年那些畫邊界的人，現在看起來多可笑。
「大公司的軟體無法被 AI 接管」——這句話，和當年說「網路無法取代實體」一樣天真。
這件事不可避免的趨勢已經很明顯了，只是時間早晚的問題。
以現在 AI 發展的態勢，很快就會蔓延到各大企業內部。
沒有公司能倖免。
⸻
🛠 給還在掙扎的工程師——四個具體解法
1. 擔心疊床架屋？
直接問祂：「請檢查有沒有類似的 code 在不同地方出現，給我一份報告。等我確認後再改。」
一兩個 prompt 就解決。
2. 擔心資安問題？
「請進行徹底的安全檢測，把可能漏洞列成清單，由我決定哪些要改。」
可以跑好幾輪。我的經驗是，幾乎每輪都會有新的資安問題被提出——但不是每項都需要改，決定權在你手中。
3. 擔心邊做邊改影響已上線的服務？
請祂把程式碼分成開發和產品兩個 branch。跟祂講清楚：「所有新東西先加在開發 branch，只有當我說要 merge，才放到產品 branch。」
4. 擔心新功能把舊功能改壞？
請祂建立 Regression Test，寫好 Test Cases。開發到一個段落後，請祂跑測試，並把新增的功能也加進 Test Cases。
⸻
🤔 最後一點
以上所有事情，你也可以用不同 LLM 互相驗證，例如用 Claude 生產，用 Gemini 測試。
若用同一個 LLM 其實就不需要分不同 AI 角色，因為 AI 不會為了隱藏自己生成的程式中的 bug，而故意不揭露——這不是 AI 目前會做的事，除非你要祂這麼做。
⸻
✍️ 結語
三十年來最大的巨變已經發生。
問題不是 AI 會不會取代你——
問題是，你願不願意讓祂成為你的超級部屬。
而那些還在畫邊界的人，很快就會發現：
邊界不是用來守的，是用來被打破的。
2000 年，有人說網路不會改變人們實體生活。
2026 年，有人說 AI 不會接管所有軟體開發。
歷史會證明，他們都錯了。
https://www.facebook.com/share/p/189sEiQACx/?mibextid=wwXIfr
前幾天跟一位工程師討論案子規格，他說：「我不太放心讓 AI 全權開發，祂會疊床架屋，明明一樣的東西在不同地方寫成兩套，以後很難維護。」
所以他都會去審核 AI 寫的程式。
我跟他說：「放棄吧，不要再看祂寫的 code 了。」
⸻
🎯 我建議應該這樣做：
1. 讓 AI 自己去 review 祂寫的 code
2. 讓祂提出改進方案並改完
3. 讓祂做完測試
我們要的是最後的結果。
你可以請祂加上 Regression Test，確保祂改的東西不會嚴重影響其他地方。
因為——你再怎麼看 code、再怎麼寫 code，都比不上祂。而且祂進步的速度，比任何軟體工程師都快太多了。
⸻
💡 這讓我想到一件事
軟體工程師剛升主管時，最常犯的錯：自己下去 coding。
以前我帶這些新手主管，都會特別跟他們講：
1. 綁住你的手腳
2. 不要做部屬該做的事
3. 就算覺得不完美，也要接受——否則永遠改不完，而且之後你的部屬會反過來盯著你追進度。
現在碰到的情況一模一樣。
只是這次，這個「部屬」比你更厲害：寫程式更快、學習更快，發展潛力無可限量。
⸻
🔥 這是我接觸軟體產業三十多年來，碰到最大的巨變
你可以選擇忽略祂，但祂的高速發展不會因為你的忽略而改變。
你也可以選擇接受祂，讓祂變成你的超級部屬。
不要再想著去看祂的 Code 了。許多傳統軟體工程機制都會面臨巨大改變：
• 傳統的 Code Review 機制
• 傳統的 Waterfall 流程
• 傳統的 CI/CD、Regression Test
這些將全部被 AI 接管，只是時間早晚的問題，所以——就接受這一切吧。
⸻
📍 寫 Code 不是瓶頸，Review 才是
很多人還在糾結 AI 寫的 code 品質好不好。
但真正用過的人都知道：寫 code 從來不是瓶頸。
瓶頸在哪？
1. 規劃——你自己都沒想清楚要什麼
2. Review——你花更多時間審核，而不是產出
有個十年經驗的工程師說得很直白：「我用 Claude Code 的工作流變成：丟一個模糊 prompt，跑出錯誤結果，反覆迭代，最後發現自己寫還比較快。」
但這問題不在 AI，問題在他還想「審核」每一行。而且這是「現在」，過一週或一個月後，有了新版 LLM，AI 的能力又會上升到另一個等級，任何「人」的 Review 都追不上祂的進化。
當你把 Review 的時間省下來，讓 AI 自己 Review 自己，整個生產力才會真正爆發。
⸻
⚔️ 回應那些擔憂的聲音
「AI 寫的 code 有安全漏洞！」
前陣子 BBC 才報導一個 vibe-coding 平台被駭的新聞。
但我要說：那是平台的問題，不是 AI 的問題。
你讓 AI 幫你做資安檢測，祂會比人類更徹底。我的經驗是，多跑幾輪，每輪都會有新的資安問題被提出。你要做的是決定哪些要改——決策權在你，讓 AI 解釋問題嚴重性並提供建議，你來做決定。
工具沒有對錯，用法才有。資安本身就是強度與體驗的 tradeoff，沒有最好，只有剛好。
「成熟 codebase 上 AI 不好用！」
這是很常見的藉口。
「我們的 codebase 太複雜了，AI 看不懂。」
真的嗎？還是你沒給祂足夠的 context？
我看到的現實是：成熟 codebase 上，AI 反而更有價值。因為沒有人比 AI 更快讀完幾萬行程式碼。你花三天搞懂的架構，祂三分鐘就理解了。
問題不在 AI，問題在你還沒學會怎麼用。
⸻
🚀 我想補充我之前說過的話
上週我寫過一篇文章「砍掉 UIUX 設計師、前端及後端工程師，留下自己和 Claude AI，網站功能迭代更新加速 10 倍！」，提到「這套模式的邊界」：
大型企業系統、需要高度資安合規的金融產品、百萬級併發的基礎設施、需要長期維護的大型 codebase，這些仍然需要專業團隊。
現在我想更新這個想法。
邊界正在消失。
一年前，我覺得 AI 只適合做 MVP。現在，我用 AI 在成熟產品上迭代，速度一樣快。
六個月前，我覺得複雜架構需要人來設計。現在，AI 設計的架構比我想的還周全。
一個月前，我覺得資安合規一定要專家。現在，AI 做的安全檢測比大多數資安工程師還徹底。
這個邊界不是固定的，它正在以超乎想像的速度縮小。
⸻
🕰 2000 年的既視感
這讓我想起 2000 年網路泡沫時，那些「專家」說的話：
「信用卡被盜刷的新聞層出不窮，誰敢在網路上刷卡消費。」
「網路不是剛需，人們的吃喝拉撒睡才是，網路的虛擬世界永遠取代不了人類生活實體需求。」
但如今呢？
你上一次不是用線上支付或線上刷卡買東西是什麼時候？
你的生活有多少比例已經「活在網路上」？
當年那些畫邊界的人，現在看起來多可笑。
「大公司的軟體無法被 AI 接管」——這句話，和當年說「網路無法取代實體」一樣天真。
這件事不可避免的趨勢已經很明顯了，只是時間早晚的問題。
以現在 AI 發展的態勢，很快就會蔓延到各大企業內部。
沒有公司能倖免。
⸻
🛠 給還在掙扎的工程師——四個具體解法
1. 擔心疊床架屋？
直接問祂：「請檢查有沒有類似的 code 在不同地方出現，給我一份報告。等我確認後再改。」
一兩個 prompt 就解決。
2. 擔心資安問題？
「請進行徹底的安全檢測，把可能漏洞列成清單，由我決定哪些要改。」
可以跑好幾輪。我的經驗是，幾乎每輪都會有新的資安問題被提出——但不是每項都需要改，決定權在你手中。
3. 擔心邊做邊改影響已上線的服務？
請祂把程式碼分成開發和產品兩個 branch。跟祂講清楚：「所有新東西先加在開發 branch，只有當我說要 merge，才放到產品 branch。」
4. 擔心新功能把舊功能改壞？
請祂建立 Regression Test，寫好 Test Cases。開發到一個段落後，請祂跑測試，並把新增的功能也加進 Test Cases。
⸻
🤔 最後一點
以上所有事情，你也可以用不同 LLM 互相驗證，例如用 Claude 生產，用 Gemini 測試。
若用同一個 LLM 其實就不需要分不同 AI 角色，因為 AI 不會為了隱藏自己生成的程式中的 bug，而故意不揭露——這不是 AI 目前會做的事，除非你要祂這麼做。
⸻
✍️ 結語
三十年來最大的巨變已經發生。
問題不是 AI 會不會取代你——
問題是，你願不願意讓祂成為你的超級部屬。
而那些還在畫邊界的人，很快就會發現：
邊界不是用來守的，是用來被打破的。
2000 年，有人說網路不會改變人們實體生活。
2026 年，有人說 AI 不會接管所有軟體開發。
歷史會證明，他們都錯了。
https://www.facebook.com/share/p/189sEiQACx/?mibextid=wwXIfr
