如果你已經開始把大模型帶進日常開發，最直接的感受通常不是「會不會寫程式」，而是「能不能把很多零碎工作一次推進起來」。
這類工具真正有價值的地方，不只是補全幾行程式碼，而是能在編輯器裡同時完成對話、改檔案、預覽結果和繼續迭代。對於簡單頁面、原型驗證、樣式調整和功能補齊，這種工作方式往往比傳統的手動來回切換更順手。
這篇就整理一下，一個比較實用的思路：在 VS Code 裡接入 Claude 一類模型之後，怎麼把它用在真實的頁面生成和小功能迭代上。
一、先把工具鏈接通
這類 AI 編程外掛的核心流程其實都差不多：
- 在
VS Code裡安裝支援對話式改程式碼的外掛 - 在外掛設定裡填入模型服務的
Base URL - 設定自己的
API Key - 選擇要使用的模型名稱
完成這幾步之後，編輯器裡的 AI 能力才算真正可用。後面的體驗差異，大多不在「能不能用」，而在「模型品質怎麼樣、外掛互動是否順手、生成結果是否穩定」。
如果你之前沒有配過這類外掛，可以把它理解成這樣：
- 外掛負責把你的自然語言請求變成編輯器裡的操作流程
API負責把請求送到模型服務- 模型負責理解你的需求並回傳程式碼、修改建議或結構化結果
所以真正要配對的，其實就是三件事：外掛、介面位址、模型名稱。
二、適合先從小任務開始
很多人第一次上手，會希望它直接幫自己「做一個完整專案」。這不是不行，但對新手來說，最容易建立正確預期的方式，反而是先從非常小的任務開始。
比如：
- 生成一個簡單的前端頁面
- 給現有頁面補一個公告區塊
- 增加註冊表單
- 調整介面，讓樣式更正式一些
這種任務有幾個好處：
- 指令足夠清楚，模型更容易理解
- 結果可以立刻預覽，回饋很快
- 你能明顯看到「對話」和「改程式碼」是如何連動的
當需求比較明確時，外掛通常會一邊在側邊欄裡和你對話，一邊直接修改右側檔案。等到任務完成之後，你再看生成結果、預覽頁面、決定要不要繼續追加需求，這個節奏會比純聊天自然很多。
三、真正提效的不是一次生成，而是連續迭代
AI 編程最容易被誤解的一點，是大家總把注意力放在「第一次生成得像不像」。
但在實際使用裡，更重要的往往是第二輪、第三輪還能不能順著改下去。
一個比較常見的過程是：
- 先讓它快速生成一個能跑的頁面骨架
- 再追加一兩個明確功能
- 然後觀察程式碼和介面是否一起變得更完整
如果工具體驗比較順，整個過程會很像你在帶一個執行速度很快的初級開發同事：
- 你提需求
- 它先做出一版
- 你指出哪裡不夠
- 它繼續修改
這種「連續對話式迭代」比單次生成更接近日常開發場景，也是它最容易拉開效率差距的地方。
四、要學會區分「適合交給 AI 的部分」和「自己順手改更快的部分」
這也是非常關鍵的一點。
像頁面佈局、元件初稿、表單骨架、樣式潤飾、文案占位、重複性程式碼補齊，這些通常都很適合交給 AI 先做。
但如果只是：
- 改一行按鈕文字
- 調整一個頁腳說明
- 換一個很小的樣式細節
很多時候自己直接改會更快。因為這種修改的成本已經低到，不值得再發起一次完整的模型互動。
真正高效的使用方式，不是「什麼都交給 AI」，而是知道什麼時候該讓它一口氣做完大塊工作，什麼時候自己收尾更省時間。
五、API 設定是門檻，但不是難點
不少人卡住，其實不是卡在寫程式，而是卡在外掛設定。
常見需要確認的內容通常包括：
- 介面位址是不是填對了
- 密鑰是不是有效
- 模型名稱是不是和服務端一致
- 外掛是否要求特定格式的
Base URL
只要這幾項有一項不對，外掛表面上可能還能打開，但真正發請求時就會失敗。
所以如果你發現外掛沒有正常工作，排查順序通常可以很簡單：
- 先看介面位址
- 再看密鑰
- 最後看模型名稱和外掛要求的格式
把這三項核對清楚，大多數接入問題都能快速定位。
六、怎麼看生成結果值不值得繼續用
一個比較實用的判斷標準，不是看它「驚不驚艷」，而是看下面這幾件事：
- 生成出來的頁面能不能直接跑起來
- 結構是不是基本清楚
- 追加需求後有沒有明顯跑偏
- 改動量變大時，是否還能保持一致性
如果一兩輪對話之後，它已經能把頁面從空白推進到一個可繼續修改的狀態，那這個工具基本就有實用價值了。
反過來說，如果每次生成都需要你大面積返工，那它帶來的就不是提效，而只是把「寫程式」換成了「審程式」。
結語
在 VS Code 裡接入 Claude 一類模型，最值得期待的不是「從此不寫程式了」，而是很多原本零散、重複、容易打斷思路的工作，可以被一次性打包推進。
更現實的用法是：
- 讓它先搭頁面和功能骨架
- 用連續對話完成兩三輪迭代
- 自己處理最後那些細小但確定的修改
這樣配合下來，AI 更像一個加速器，而不是一個必須完全接管開發流程的替代者。