發佈日期： 2026-01-25 主題： AI Coding 的效率真相、面試變革、地端部署與資安風險 時長： 約 25 分鐘

逐字稿

大家好，這週是一個 AI Coding 的週。所以我這週其實自然就針對 AI Coding 的題目講了各式各樣不同的面向。

裡面從一開始怎麼樣子導進去、在整個 Coding 當中的瓶頸在哪邊、就是一樣去讀了一個新的論文——怎麼用超長上下文來幫助 AI Coding、然後也提到了在 AI Coding 這個最重要的、大家最感興趣的面試的場景我是怎麼做、我們要在企業怎麼樣導入一個 On-Premise 的、不會洩露的一個 AI Code 的環境、到最後就是 AI Code 有什麼樣資安的議題。

那在做完這個題目之後，我就覺得一個很充分的感想就是——AI Coding 沒有想像中、真的沒有想像中那麼簡單。而且它真的是一個可被驗證的、一個很棒的場景。但是它也是一個需要很好去思考的場景。

週一：半年回顧——需求收集與驗證的瓶頸

在禮拜一的時候，我做了一些相關的總結。那在這半年的時間，如何用 AI Code 來做一些專案相關的議題。

其實很明顯的發現到一些問題。就是如果我們把程式開發分為三塊——需求的收集、程式的開發、以及 QA 驗證，然後最後交付給客戶。

那我們明確的感覺到就是，的確 Coding 這塊變得超級快，基本上是一個 10 倍到 100 倍的那種快速。但其實這基本上就把程式開發的相關瓶頸，已轉到需求的收集以及 QA 驗證這邊。

我這邊講到的是，其實到目前為止，我並沒有看到一個很明顯的在程式開發上面的提升。原因是因為我們在一開始做一些跟客戶專案或自己專案的時候，我們還是要做需求的收集、需求的一些發想討論。那這個東西我們把它稱為 Brainstorm，但是如果在做外部案子的話，比較像是一個「通靈」。

那這基本上是把客戶的想法，然後對齊商業需求以及對齊我們可以開發的事情。那這事情老實說就算有 AI 的幫助，其實它頂多就是幫你做一些會議記錄的總結。老實說並不會造成很大的效率提升。

那所以在這邊的話，如何能夠快速的知道客戶的需求——商業需求跟業務需求——然後把它變成一個可執行的 Spec，這其實是需要兩個腦袋，就是 PM 的腦袋以及客戶腦袋進行一個對齊。這件事情 AI 能夠做的事情非常有限。那這是第一個瓶頸點。

那第二個瓶頸點的話，其實就是所謂的驗證。驗證這件事情是比較有趣的。這個驗證的問題在以前是人力來做開發的時候，其實就有這個問題，只是沒有那麼嚴重。為什麼呢？因為其實程式開發是慢，是慢，但其實它有 50% 以上的時間其實是在做手動的驗證——就是工程師一邊開發的時候，其實一邊在做驗證，來驗證他的東西寫對不對。

那有了手動驗證之後，QA 這邊當然還是要做一個整體的驗證，但是那個問題就不會那麼大，至少可以確保每件事情都能夠對齊我們現在的想法。

但是現在在開發的過程當中就完全是 AI 這邊來做，那就遇到一個很巨大的問題——連那塊手動的驗證、工程師手動驗證都沒了。那就是把所有的壓力全部都放在 QA 驗證，所以 QA 這一題的瓶頸越來越大。原因是因為我們拿到的東西，我們其實不知道它們怎麼產生的，我們也不知道說我們 PRD 寫得很好的情況下，AI 是不是能夠真的如實的產生。

那所以說基本上所有壓力都會放在最後的 QA 驗證這塊。所以這是為什麼我提到說在驗證這邊也是一個很巨大的議題。

驗證的解法：Test Plan 三步驟

那要怎麼樣解決呢？如果你是一個 POC 或是一個內部的專案的話，那基本上我覺得 AI Coding 導入是沒有問題的。因為你基本上不太需要驗證，而且基本上你的腦袋就有一些相關的 Spec，你只要把 Spec 寫清楚就好了。

但是如果在客戶的相關專案的話，你要做這件事情，你必須去思考幾件事。第一件事情是，從客戶角度上，什麼東西是正確的、什麼東西是錯誤的，然後什麼東西沒有做就一定是錯誤。這就是所謂的第一個——最 Minimal 的 Test Case——要把它寫下來，然後變成一個 Test Plan。

那第二個是有了這個 Test Plan 之後，你再把這些相關的 UI 以及 Test Plan 丟給 AI，讓它去展開一個更詳細的測試。在這塊的話其實對 AI 來說是一個蠻舒適的區域，因為你有做得好的 PRD 之後，再有一個比較正確的 Test Plan 之後，它就可以根據這個框架把它展開一個比較好的東西。

那第三步的話就是說，永遠不要覺得只有一點點 Test Case 就搬不上台面。在軟體測試這邊，沒有 Test Case 跟你有一點點 Test Case——有一點點 Test Case 然後並且及早來進行驗證，永遠比沒有 Test Case 來得好。

那有了這些東西之後，有了一個完整 Test Plan 或是一個部分 Test Plan 之後，那其實就可以教會 AI 來做一些後面驗證的東西，這其實就是 AI 舒適區。

所以這就是我目前在 AI Coding 這邊看到實務上面的問題——需求收集以及驗證，然後這問題會越來越大。謝謝。

週二：MIT RLM 論文——超長上下文的突破

其實去讀了一個 MIT 論文叫 Recursive Language Model。它其實很有幅度的去突破現在 AI Coding 的一個最大的問題，就是超長上下文。

這邊講長上下文是真的很大的上下文。原因是因為我們發現到在做 AI Coding 的時候，你要能夠把它寫好的話，必須要有非常非常足夠的 Context——而這 Context 就是你之前的程式碼、你的文件，還有一連串的相關的一些 Log。那其實每一個都是所謂的長上下文。

所以這是為什麼我們在做 AI Coding 的時候，其實很容易上下文會爆掉的原因，就是因為它裡面需要的 Context 太多了。

那其實它做的事情還蠻有趣的，就是它不是把它全部都丟到大語言模型——那基本上這也沒有效率——而是它還是一樣做個 Divide and Conquer，先把它拆成 Planning，然後做成不同的 Stage，然後如果你這邊需要查到這個程式碼或者是查到這個 Code 的時候，再去相對應的地方再做一個 Recursive 的動作。

那它整個 Benchmark 來說，在超長上下文這邊的場景下面做得很好。那唯一的問題就是比較慢一點，但是我們也相信這件事情可以很有效率的去解決 AI Coding 的相關議題。

週三：AI 時代的技術面試

然後在週三的時候，其實講了一個大家都很有興趣的題目，就是在 AI 的時代怎麼做技術面試。

因為我們之前都是用一些 LeetCode 啊，然後做一些 Coding、一些演算法、一些數學難題。但現在有 AI 的時代，其實這東西已經完全沒有什麼意義的。

那所以我們就注意到說現在矽谷大廠以及一些大公司，已經開始淘汰這種原本完全靠能力的 Coding 的硬面試的方式，而是就直接面對現實——既然你在這個時代裡面你要做 Coding，你一定需要 AI，那好我們就好好來考 AI 的能力吧。

那這邊其實我也參考，除了看那些網路上的文章以外，我也參考了很多已經在面試、或是甚至已經面試通過的人他們準備的方式。

那基本上的情況是這樣，就是在 Meta（Facebook）裡面，如果要進行 AI-Enabled 的面試的時候，他進去會拿到一個 IDE，然後裡面有一個 AI 能夠幫助你做相關 Coding。那裡面都會放一些小模型，這小模型其實沒有到很好、沒有到很厲害，但基本上也是一線的——像 mini 或 Flash，或者是像 Claude Haiku 這種等級的。

那當我們開始問說「我能請 AI 全幫我寫嗎？」他說可以，但是你要注意到它有可能錯了。其實就是在考驗你——當你面對一個不完美的 AI 的時候，你該怎麼樣來做一個比較好的跟它的合作。

所以在裡面其實提到了一些相關的竅門。第一個事情就是正視這件事——AI 不見得能夠 100% 完美的做完。第二件事一開始就是講「我是這件事情 In Charge 的，我是決定整個相關策略的」，而不是讓 AI 來領導你的策略。然後就是我剛剛提到的，在需求收集這邊以及最後驗證這邊，你必須要有自己的看法，然後你也不斷在 AI 產生 Code 當中，不斷要提出「我要怎麼去驗證」跟面試官講。那你這樣子才能夠證明你是一個能夠管 AI，而不是一個被 AI 所管的人。

那最後的話，其實我也問了我的朋友，能不能把他準備好的 SOP 給 Share 給大家。所以他也很開心的放上去，大家可以到我的部落格上面去看這些相關的 SOP，我個人認為這個其實是蠻有幫助的。

週四：AI Coding 企業導入——IT 架構的三條路

那在週四的時候，到了一個我蠻喜歡的 IT 架構的議題。我其實蠻喜歡這個標題的，說真的。

因為在這個時代裡面，IT 其實不見得——它很重要，但是它又被很多人忽略。但是它其實是決定了我們 AI 導入能夠是否成功的一個很重要的議題。那我還是希望能夠把這東西持續做下去，所以我都會放到禮拜四，然後儘量不要因為一些特殊的題目去跳過它。

那這次講的是 AI Code 在企業這邊要怎麼導入。其實這個問題我個人覺得還蠻大的。因為大家都知道 AI Code 現在目前是以 AI Agent 當中算是一個最已經被驗證、最有成效的——最有成效它一定能夠，而且也一定能夠很輕鬆的算 ROI 跟 KPI 的場景。

但是 Code 這件事情又剛好坐落在任何公司都認為是很重大的業務機密。所以有很多人就是放棄——的確有很多人放棄——就是「啊我 Code 就給你看了，然後就給雲端的 OpenAI 或 Claude Code 看」，但你要幫我把它做好。

但也有絕大多數的客戶他們其實是無法導入 AI Coding 的，原因是因為他們認為這個 Code 太重要了，「我無法信賴你的 Cloud」或是「我本來就不想上雲」。那所以這時候大家就來討論說，那我們能不能做地端。

地端 AI Coding 其實是有的。像現在最紅的像 OpenCode 這樣的 Command，然後再搭配一個地端的模型，基本上可以做到 70%、80% 現在 Claude Code 能夠做的事情，而且大家覺得成效都還不錯。尤其是搭配一些專門為 Code 做的模型，像千問的 Coder，或是 DeepSeek Coder、或是 MiniMax。不過蠻有趣的是基本上都是中國的模型。那基本上大家都覺得在裡面就是 80% 左右 Claude Code 的能力。

然後但是在 Coding 這件事情是這樣子——它沒有一個中間值，它基本上能夠寫得越好，當然我們就越好。其實對企業帶來的差距是很大的。

所以就有人提說，那我們有沒有機會直接在企業裡面有個合規的方式、不會洩露的方式，然後能使用現在最先進的——在這個時間點 2026 年 1 月的 SOTA 就是 Claude 的 Opus 4.5？那其實是有的。

第一條路就是跟雲端合作，像 AWS 或是 GCP。他們基本上有 Bedrock 或 Vertex，能夠直接 Run 現在最強的 Claude 模型。並且用比較好的網路架構把它變成跟內網的機制，確保整個網路架構基本上是不會透漏出去的，並且還能使用相關的模型，還有一些配套像 Audit Log 這些東西。

這基本上是一個很完美的解法，但是唯二只有兩個問題。第一個問題是，有些人就是不願意上雲。我之前在做雲的時候，大家心裡知道的——有些人不願意上雲就是不願意上雲，不管你怎麼跟他講雲的好處或安全性，他就是信賴地端。那這就是某些公司的底線，這也沒辦法。

那第二個是因為 Bedrock 或 Vertex，它算錢是 Charge by Token 的。然後剛好 AI Coding 其實是一個 Token 會使用超大量的場景。所以基本上我們在外面個人使用時候，我們都是使用像 Claude Max 這種吃到飽的模式，不然的話錢會非常非常驚人。所以使用雲端上面的模型的話，也會造成成本上面很大的問題。

那這是第一條路——雲端的架構，但可能比較貴，然後也有些人還是覺得它還是把企業資訊放到雲端。

那第二條路就是一個幾乎所有人都能接受的——用 OpenCode 再加上地端的模型。這個 100% 沒有問題，唯一的問題就是效能差點意思。但就看你的需求吧，差多少很難說。

那最後一條路也是很多人在講的——就是我專門使用 Claude Code，但是把它導到地端的模型，只使用 Claude Code 這個工具，但接到地端模型用 Proxy 的方式。

這個在技術上 100% 可行，因為已經有大量自媒體就這樣子教大家怎麼做。但我個人覺得這其實反而是最爛的方式。講難聽點就是說，如果你在做企業的時候用這種方式——這種把它 Proxy 到另外一個模型然後去模擬 Claude 模型的方式——其實是很游走在它的 Terms of Service 的邊緣的。所以以個人來說沒差，因為 Anthropic 不可能因為這東西告你。但以企業來說，會不會有法律風險？這個很難說。

再另外一點就是，Claude Code 跟 Claude 的模型基本上是天生一對的。Claude Code 之所以那麼強，其實很多時候是因為 Opus 或是 Sonnet、或是 Haiku 針對 Claude Code 做了很好的 RLHF——就是強化學習的部分。所以如果當你切到其他模型的話，的確還是會差點意思。那如果這樣的話，你還不如走第二條路就好了。

所以這是在禮拜四講的 IT 架構的一些選擇。

週五：AI Coding 資安——重災區

最後昨天講到一個非常重要的題目，又是資安。因為我希望也能夠在禮拜五的時候講資安。

老實說 AI Coding 資安，是幾乎是現在我個人認為最大的重災區，而且大家最不重視的一個話題。

原因是什麼呢？因為之前大家都覺得說，用 IDE 去開發，頂多就是程式裡面的 IDE 沒有寫好會有一些資安的風險。但是沒有很大，因為它不是對外的服務，是對內部的。

但是這個之前是對的，因為不管 IDE 怎麼搞鬼，你都有一個人在不斷的去看、一直盯著 IDE 在這邊做事情、寫著程式。

那現在有了 AI Coding 之後——大家也不用裝了——大家都是 Yes Yes 一直按。基本上也不太為了效率，也不太去觀察它裡面怎麼做了。

然後所以說在裡面就是會有很多很多的相關資安風險。第一個是所謂的供應鏈上的資安風險。如果你進來的那個 GitHub 的 Code 裡面的 README 裡面、Code 裡面、Comment 裡面藏了一些 Prompt Injection 的話，然後你用到的這些模型就很有可能被它所污染，然後把一些重要資訊——像你的機密——給洩露出去。這個絕對是有可能，而且已經有真實案例了。

那第二個也是很有趣的，就是在 AI Coding 這邊，你要做 Coding 嘛，其實你就在寫一些擴充的 Code。那如果你用類似 Claude Code 的相關方式、用一些 Prompt Injection 方式——不只是污染你的、把一些機密洩漏出去，甚至能夠在你 Code 裡面塞一些相關的後門，然後在一些 CI/CD 的時間塞一些後門，然後繞過所有的機制的話，那這個對企業來說是一個超級巨大的風險。

那第三個當然就是有些人可能不在 Coding 這邊，而是在你的 CI/CD 的 Pipeline 裡面做一些 Prompt Injection 的下手。像是你在一個 Issue 或 PR 裡面、CI 的 GitHub Actions 裡面的 Comment 裡面塞一些 Prompt Injection 的東西。當你 CI 的 Agent 去讀這些 Comment 的時候，它就被 Prompt Injection 所觸發，然後再把裡面的相關機密洩露出來。這其實也是在去年就已經被驗證，已經影響到蠻大的，而且也是真實案例。

那最後一個最有趣就是——我們在做 AI Coding 的時候，如果被各種不同的方式攻擊了，它就可以直接做 Remote Code Execution。原因是因為我們在做 AI Coding 的時候知道，很多時候 Claude Code 或是 Cursor，在做一些事情、讀一些檔案的時候，有些時候它不是用大語言模型直接去讀，而是它會寫成一個程式碼去讀。

那這時候它就會跟你要求執行這個程式碼，通常我們很習慣就一直按著 Yes。那這時候如果它寫成的程式碼不是去讀那些檔案，而是直接把這些企業相關的機密什麼東西傳出去的話，基本上就算你的公司有防火牆，它也會認為是你這個人的行為在做。因為程式碼是完全不會被發現的。

所以這就是現在 AI Coding 在資安上面遇到的巨大議題，而且每一個議題都對應到相關的真實案例。

防範措施與坦白說

那在這個情況下，我們唯一能夠做的就是——第一個，不要在 AI Coding 裡面它要怎麼做的時候，你就 Yes Yes 一直無腦按。這個很難，說真的很難，但這是最根本的一件事情。

那因為我看到 AI Coding 現在的生態，大家更傾向於不只是 Bypass 這個瓶頸，甚至要追求一個 24 小時全年無休的全自動工作。這個其實是非常可怕，因為你完全沒有——你在 AI Coding 這邊跟 AI Agent 又不一樣——你甚至連 QA 的 Review Process Gate 這件事的舉動都沒有。

那這其實是一個很可怕的東西，因為你在 AI Coding 的環境是你個人電腦環境，你基本上有全部的 Token、API Key，以及 Linux 或 macOS Execute 的權限，它能夠做超級多的事情。

所以這其實是我目前看到最大的問題。當然也有一些解法，但我也懷疑它能夠 Cover 到底有多少。像是我這邊在部落格提供一個比較適合的 Prompt——放在 CLAUDE.md 裡面做這件事情——能夠防範一些東西。當然它能夠防範蠻多的問題，但是到最後，真正的問題是在於你還是得去 Verify 它的每一個步驟——它到底要做什麼。那你要適時停下來按 No，然後確認這件事情，這才是唯一一個可解的方式。

當然我在這塊其實是有點悲觀的，因為我自己在做 AI Coding 的時候，其實我也很常在忙的時候就一直按 Yes，就不太管這件事情了。那當然我自己有一套防範的方式，但老實說我自己也不太確定能防範多少。尤其是考量到我在寫這篇文章的時候，我看到巨大量的真實案例，我就覺得真的是非常可怕。

所以最大的就是 AI Coding 在資安這邊的重災區。

總結與感想

那做完這個題目之後我就發現到，其實 AI Coding 絕對不是大家想的那麼簡單的一件事情，而且導入到企業的時候你要考慮的東西非常巨大。

第一個事情是，它在 Coding 這塊能很快加速 10 倍 100 倍，你要怎麼講都可以。但是在真正實體上面開發的，根據我的經驗，頂多 30% 就已經很了不起了。原因是在需求確認跟最後的 QA 驗證這邊完全就是瓶頸，就卡死在這裡。

那第二個是它其實有一個超級巨大的資安風險。因為你每一個程式碼基本上都是你公司最機密的資產。所以我們在做 AI Coding 之後，好像大概沒有想很多，就直接把這些資訊透露給 OpenAI 或者是 Claude 這邊。那這個想也知道不對，尤其是我們在做 AI Coding，很多時候把很多相關的數據、Excel 的東西就把它透露出去了。

然後再來就是對企業的人才篩選這邊也有很大的壓力。因為有了 AI Coding 之後，我們之前選才跟考核工程師的這一套，是完全不 Work 的。我們必須要像 Meta 一樣開始去思考，怎麼樣設計一套能夠考出能夠管 AI 的人才，而不是一個能夠手寫 Code 的人才。這個是一個非常巨大的議題。

當然在學術界也看到一些成長，針對超長上下文的部分。

總之我個人認為，今年依舊是一個 AI Coding 很巨大的一年，但是它也是一個挑戰非常非常巨大的。謝謝大家。

下週預告

那最後就要講到下週了。下週我們還是會圍繞著 AI Coding 的題目，但是我可能會做一個比較大的聚焦。因為這週其實是一個比較廣泛的，但下週會比較聚焦 AI Coding 的東西，就是 Claude Code。

我個人認為 Claude Code 已經在 AI Coding 這邊，它已經超出 AI Coding——它其實叫做一個 AI Working 的範疇了。那它最近也提出了相關的一些 Skill 這樣子非常好用的東西。

那所以我可能會更加 Focus 在 Claude Code 這個我基本上每天都在使用的工具，我們可以怎麼樣子使用它來做更好。

請大家敬請期待，謝謝！

本週核心觀點

  1. 效率真相： AI Coding 在 Coding 層面加速 10-100 倍，但整體專案開發頂多提升 30%，瓶頸在需求收集與 QA 驗證
  2. 驗證缺口： 工程師手動驗證消失後，所有壓力轉移到 QA，需要建立 Test Plan 三步驟來填補
  3. 學術突破： MIT RLM 用 Divide and Conquer + Recursive 方式解決超長上下文問題，對 AI Coding 有巨大潛力
  4. 面試變革： Meta 不再考 LeetCode，改用 AI-Enabled 面試測你能不能管 AI，而不是被 AI 管
  5. On-Prem 三條路： 雲端內網化（貴但最好）、真正地端（效能差但安全）、Proxy 方式（最爛，法律風險 + 效能降級）
  6. 資安重災區： 供應鏈污染、Prompt Injection 後門、CI/CD Pipeline 攻擊、RCE——每個都有真實案例
  7. 核心結論： AI Coding 絕不是想像中那麼簡單，企業導入需要考慮效率真相、資安風險與人才篩選

本週文章列表

# 日期 標題 系列
1 01/19 AI Coding 半年回顧：開發並沒有變快 ATPM
2 01/19 MIT RLM：讓 AI 不再忘記 論文解讀
3 01/21 Meta AI-Enabled Coding 面試 AI Coding
4 01/22 AI Coding On-Prem 的三條路 IT 架構
5 01/24 AI Coding 的第一個風險：你一直按 Yes AI 資訊安全

此為 Weekly Vlog EP6 實際錄製逐字稿，已根據 SRT 語音辨識修正為繁體中文。