最近我手頭有兩個Claude賬號先後被封，幾個低代碼開發的活兒一下子就停了。在找替代方案的時候，從網上翻到了這條影片，正好講的是同一個問題：不依賴任何雲端AI賬號，純靠本地顯卡跑模型寫代碼，到底行不行。
影片裡，博主用一台ASUS TUF A14筆記本演示了如何完全離線運行AI寫代碼。主角是這台搭載RTX 5060筆記本顯卡的機器，博主要驗證的問題很直接：不聯網、不花一分錢調用雲端API，本地顯卡到底能不能撐起真正的編程工作。
ASUS TUF A14這款機型今年已經更新到2026款，處理器換成了AMD Ryzen AI 9 465，但顯卡還是這顆RTX 5060，官方給出的定位是「學生推薦款」，主打輕薄機身加遊戲級性能。影片裡博主自己也提到了這個說法，他做這期內容的目的之一，就是看看這個「學生推薦」到底能不能「打」。
一台8GB顯存的筆記本，能不能替代Claude或者ChatGPT完成日常編程？這個問題背後其實是很多開發者近兩年一直在糾結的事：雲端AI好用，但賬號說封就封，每個月的API賬單和上下文額度也是實打實的開銷。如果本地顯卡真能扛住一部分工作，至少能保證賬號出問題的時候手裡的活兒不至於全部停擺。
整套流程的起點是Ollama。這是一個可以在本地運行開源大模型的免費工具，博主直接在瀏覽器搜索"Ollama"，從官網下載Windows版本，裝完之後敲一句 ollama --version 確認安裝成功。
選模型的時候他動了點心思。Ollama官網的模型列表里開源模型很多，他挑中的是Qwen3，理由是"對於編碼、思考、工具調用這些場景都覆蓋得到"。但這款模型有不同的參數規模可選，參數越大推理能力通常越強，與此同時對顯存的要求也越高。他這台筆記本顯存是8GB，於是選了8B（80億參數）這個版本，"我覺得8B參數的模型是最合適的",他這樣解釋自己的取捨。
下載模型用的命令是ollama run qwen3:8b。裝好之後，他直接在終端里打了句"hi"，螢幕右上角的任務管理器顯示GPU占用瞬間跳到了97%。這一步是整期影片裡比較直觀的證據：GPU真的在幹活，而不是CPU在硬扛。他又追加測試了一句"How are you"，同樣的現象重複出現。"就算斷網，它照樣能跑",他補了一句，這也是本地部署相對雲端服務最直接的差異——推理過程完全發生在這台機器內部。
跑通對話只是第一步，真正的編程場景需要一個能調用工具、能操作文件的客戶端。博主選的是OpenCode，一個功能上類似Claude Code的開源命令行工具，能通過ollama launch opencode直接從Ollama里拉起來。
打開之後會列出一串模型，既有雲端的也有本地的，他選中了剛裝好的Qwen3 8B。接下來是配置環節，他在VS Code里新建了一個opencode.json文件，手動寫好幾項參數：
首先是模型來源，格式是ollama/qwen3:8b。Qwen系列模型默認上下文窗口大約是8000 tokens，他把這個數字提到了16K，這樣模型能一次性"記住"更多代碼上下文。然後要指定provider為Ollama，標註它兼容@ai-sdk/openai這套接口協議，並且把請求地址指向本地的localhost:11434。
配置里還有一個容易被忽略但很關鍵的開關：tool call: true。打開這一項，OpenCode才能調用網頁搜索、創建文件之類的工具能力，否則模型就只是個純聊天窗口。上下文長度他設定為16384，輸出長度設為4096。
配置文件寫完，在終端里執行opencode，第一次沒能正常識別模型。他排查後發現配置欄位寫錯了，應該是複數的"models"而不是"model"。改完重新運行，Windows下還額外碰到一個執行策略的限制，需要執行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned才能放行腳本。這兩處小坑,恰好說明本地部署這條路不是純粹的"一鍵搞定"，多少還是需要一點排障耐心。
配置跑通之後，博主給了第一個正式指令：用TypeScript構建一個可復用的React數據表格組件，支持排序和分頁，先初始化一個Next.js項目再寫組件。模型自己拆解出一份任務清單，按步驟推進，先是新建項目結構，再逐步生成組件代碼。
等待過程中，項目目錄里陸續出現了components、types等文件夾，layout.tsx和page.tsx也被自動寫好。完成後他執行npm run dev，瀏覽器打開localhost:3000，一個帶分頁和排序功能的任務列表頁面渲染了出來。
緊接著他把需求往前推了一步：新增一個Next.js的API路由，支持POST請求創建新任務，用Zod做請求體校驗，並處理無效輸入的報錯邏輯。模型同樣列出計劃、定位相關文件、逐步實現。跑起來之後確實能新增任務，界面上出現了一個小的顏色顯示bug，他沒有糾結，手動填完表單點擊提交，任務照常被添加到了列表末尾。
"這些都是AI常見的小幻覺",他這樣評價那個bug，"用雲端的GPT或者Sonnet的時候，你得說得很具體，本地模型這一點更明顯，需要指令更精確才行"。
寫代碼之外，博主還測了一個理工科學生更常用的場景：Jupyter Notebook。他打開一個新的Notebook，選擇本地GPU作為運行環境，先跑一段代碼確認顯卡確實被識別成了"NVIDIA GeForce RTX 5060"，再執行一段用CUDA訓練的代碼，任務管理器里同樣能看到GPU核心在滿載運行，而不是CPU。他的結論是,對於日常需要跑數據、做訓練任務的理工科學生來說,本地顯卡這條路徑完全可用，不必事事依賴雲端算力。
影片的最後一段他切換了話題：遊戲。這台筆記本能流暢運行《美國末日》《戰神》以及最新的《惡靈古堡：安魂曲》，用的還是幾分鐘前跑AI模型的那顆RTX 5060。
回到最初的問題，本地AI到底有沒有替代雲端服務的能力？博主給出的答案不算模糊：自動補全、生成基礎組件、跑Jupyter Notebook這類日常任務，本地模型完全能頂上,並且能省下不小一筆token和金錢開銷。但涉及多智能體協作或者更複雜的推理任務，他仍然認為雲端AI更勝一籌。
這個結論對普通開發者的參考價值在於:本地部署不是全有或全無的選擇,而是可以按場景分工——簡單重複的編碼工作交給本地顯卡處理,複雜架構設計和疑難調試留給雲端模型。
