https://www.knightli.com/tags/%E5%BC%80%E5%8F%91%E6%95%88%E7%8E%87/ Recent content in 开发效率 on KnightLi的博客 Hugo -- gohugo.io zh-cn Thu, 16 Apr 2026 17:47:17 +0800 https://www.knightli.com/2026/04/16/vscode-claude-api-coding-workflow/ Thu, 16 Apr 2026 17:47:17 +0800 https://www.knightli.com/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>