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