如何用Vibe Coding突破付费墙工作流 自制VS Code数据库扩展

最近有一款 VS Code 数据库扩展上线了，叫 SQL Workbench。

起因很简单：一个数据库管理插件，体验不错，状态栏切连接、左侧看库表、右侧跑 SQL、还能根据表别名提示字段。偏偏很多高频功能被放进了付费版。

作为一个长期在 VS Code 里写后端的人，这件事挺微妙：不是不愿意为好工具付费，但如果一个工具的核心价值刚好是每天最熟悉的那套工作流，会忍不住想一句话：这东西能不能自己做一个？

于是这个项目就开始了。

不是“我要做一个数据库客户端”。这个目标太大，也太容易做散。

真正想做的是：一个 SQL 优先的 VS Code 数据库工作台。

SQL 文件还是放在项目里，连接还是在状态栏切，库表结构可以顺手看，结果可以分页看，提示能懂表别名。至于那些危险的 GUI 编辑，比如直接在表格里改值、删列、删表，MVP 先不要。要改数据，就写 SQL。

这就是 SQL Workbench 的第一版边界。

一开始不是写代码，是拆产品

没有上来就让 Codex 初始化项目。

第一步是看竞品。

把竞品官网、截图和实际使用效果都喂给 Codex，让它先做功能拆解。这里很重要，不是问一句“帮我做个数据库插件”，而是让它先站在产品经理和架构师的角度回答几个问题：

• 这个插件到底解决了什么问题？
• 哪些功能是高频刚需？
• 哪些功能只是锦上添花？
• 哪些功能虽然炫，但 MVP 不该做？
• 哪些功能被放在付费版里，用户真正想要的是什么？

拆完之后，得到的核心判断是：竞品真正好用的地方不是“数据库管理”四个字，而是它把数据库工作嵌回了 VS Code 的日常路径里。

比如：

• 写普通的 .sql 文件，而不是打开一个专有查询窗口
• 在状态栏看到当前连接，并能快速切换
• 左侧树按分组展示连接和库表
• 点表能看字段、类型、注释、主键、是否可空
• 输入 bs. 时，只提示 biz_show bs 这张表的字段
• 查询结果不要一次塞满屏幕，要有分页、总数和耗时

这些才是每天都会用到的东西。

反过来，一些看起来很完整的能力，比如结果表格内联编辑、列信息直接编辑、删除表结构，这些都被暂时拿掉了。原因也很直接：

MVP 阶段不要把危险操作做得太顺手。

数据库工具最怕“做得很方便”，然后用户顺手点错。

所以第一版的原则是：看可以很方便，改必须通过 SQL。

产品定位：不是 DataGrip，也不是 Na vicat

如果把目标定成“替代 DataGrip”或者“替代 Na vicat”，这个项目第一天就会失控。

SQL Workbench 的定位更窄：

这里的几个词都很关键。

SQL 优先，意思不是“只支持 SQL”，而是把 SQL 当成主要入口。用户在自己的项目里创建 .sql 文件，用 Git 管理，用编辑器的快捷键、搜索、片段、格式化能力，不需要进入另一个厚重软件。

本地优先，意味着连接信息、SQL 文件、使用过程都尽量留在本机和当前工作区里。密码放进 VS Code SecretStorage，普通连接元数据放扩展状态里，不搞云端账号体系。

轻量，意味着不追求第一版支持所有数据库、所有高级对象、所有 GUI 操作。先把 MySQL/MariaDB、PostgreSQL、SQLite 跑通，把连接、Schema、补全、执行、结果这些主路径打磨顺。

这个定位确定之后，后面的技术选择就清楚很多。

MVP 功能表

最后定下来的 MVP，大概是这样：

这张表后来非常有用。

因为做 AI coding 最容易发生的一件事是：AI 太能写了，也容易加需求。

今天加个 ER 图，明天加个 Mock 数据，后天加个结构同步，再过两天项目就变成一锅粥。

MVP 表的作用，就是不断提醒自己：先把主路径做完。

是怎么用 Codex 做这个产品的

这次不是把 Codex 当“代码补全工具”用，而是当一个小团队用。

给它的角色是：主 agent 担任 CTO，负责理解需求、拆任务、写代码、验收；必要时可以分配子任务，但最终要自己把关。

整个过程大概分成几类对话。

1. 先让它做产品分析

一开始只给了竞品链接和截图，让 Codex 先分析，而不是动工。

输出包括：

• 竞品功能拆解表
• MVP / 完整版路线图
• 规划图和架构图
• 功能优先级
• 哪些付费能力值得参考

这里有个经验：

不要一开始就让 AI 写代码，先让它写判断。

代码错了可以改，方向错了后面全是浪费。

2. 用截图校准 UI 细节

这个项目很多细节都来自截图。

比如状态栏切换连接。一开始设计并不直观，当前连接位置不明显。发了竞品截图，要求它参考竞品的 QuickPick 分组方式，把 Current 的位置调整得更容易看。

再比如左侧树，竞品可以展开表直接看列。讨论后决定：

• MVP 必须支持点表后右侧查看所有列信息
• 展开 table 左侧直接显示字段，可以放下一期

这就避免了为了“像竞品”而无脑堆功能。

3. 每个功能都反复追问边界

有几个问题是边做边问出来的。

比如 SQL 文件写在哪里？

答案是：写在 VS Code 当前项目里，就是普通 .sql 文件，不放在插件内部。这样用户可以用 Git 管理 SQL，也可以按业务目录组织。

比如 MVP 支持几个连接？

答案是：不做数量限制。连接可以分组，当前 SQL 执行哪个库，由状态栏的 Active Connection 决定。

比如查询结果要不要默认加 LIMIT 100？

一开始加过，后来发现不对。用户写什么 SQL，就应该执行什么 SQL。问题不是 SQL 没有限制，而是前端不该一次渲染巨大结果集。

所以后来改成：

• 不篡改用户 SQL
• 如果 SQL 没有显式 LIMIT，后端做分页查询
• 结果面板每页显示 10 条
• 显示 Total、页数和请求耗时
• 如果用户写了 LIMIT 10，Total 就是 10，不再额外统计全表

这比“偷偷加 LIMIT”舒服很多。

4. 让 Codex 自己跑验证

基本不会接受“代码已完成”这种结论。

每个阶段都要求它跑：

npm run compile
npm run check

涉及查询执行时，还让它用 SQLite 构造数据做运行时验证。

比如这次结果分页，它最后验证的是：

• select * from t 没有显式 LIMIT，会走服务端分页：总数 150，但第一页只取 10 条
• 点击第二页时，再向扩展端请求下一页数据，结果从第 11 条开始
• select * from t limit 5 会尊重用户写的 LIMIT：Total 为 5，不再额外统计全表总数

这种验证很朴素，但足够抓住核心逻辑：不篡改用户 SQL，同时避免前端一次性渲染巨大结果集。

中间踩过的一些坑

AI 很容易“顺手优化过头”

比如默认加 LIMIT 100。

从保护前端性能的角度看，这个方案很自然。但从数据库工具的体验看，这不对。用户写的 SQL 被工具改了，哪怕是善意的，也会让人不信任。

后来把问题拆开：

• SQL 执行语义不能乱改
• 渲染性能要通过分页解决

这个拆法一出来，方案就顺了。

UI 细节必须用截图逼近

只用文字说“像竞品一点”，基本没用。

截图能告诉 AI：

• 当前连接应该放在哪里
• 表格表头哪里错位
• 字段描述应该怎么展示
• 图标是不是偏小
• 新建连接应该是表单页，不是 QuickPick

视觉问题靠文字抽象很容易偏，靠截图反馈会快很多。

AI 能写，但必须验收

Codex 这类工具已经很强了，强到很容易让人放松警惕。

但它还是会犯一些工程层面的错，比如：

• 某个构造函数参数改了，调用处没同步
• webview 脚本里转义写错
• 类型编译没过
• 旧配置项没清理干净

所以做法是：让它写，也让它跑；让它解释，也让它证明。

发布到 VS Code Marketplace

本地跑通之后，开始发布。

大致流程是：

1. 准备 package.json 里的 publisher、displayName、description、icon、repository 等信息
2. 生成 .vsix 包
3. 创建 Visual Studio Marketplace publisher
4. 创建 Azure DevOps Personal Access Token
5. 使用 vsce 登录 publisher
6. 发布扩展

本地打包命令是：

npx --yes @vscode/vsce package

发布命令是：

npx --yes @vscode/vsce publish

这里也有几个小插曲。

比如 Marketplace 的 publisher 要走 Azure DevOps 那套账号流程，页面上会让你创建 organization，还会问一些区域、电话、拼音信息。它看起来像要你开通 Azure 付费服务，但发布 VS Code 扩展本身不需要你真的创建云资源。

再比如第一次发布后，扩展会显示 Verifying，需要等 Marketplace 审核和索引。能打开详情页，不代表马上能在 VS Code 扩展市场搜索到。

还有图标问题。Marketplace 图标、VS Code 扩展列表图标、Activity Bar 图标不是一回事：

• Marketplace 用 package.json 里的 icon
• Activity Bar 用 contributes.viewsContainers 里的图标
• VS Code 本地有缓存，刚发布后看到旧图标很正常

这些不是难题，但如果第一次发扩展，会很容易卡在“这到底是不是配置错了”。

现在这个扩展能做什么

SQL Workbench 目前已经可以完成一条比较完整的数据库工作流：

• 管理 MySQL/MariaDB、PostgreSQL、SQLite 连接
• 连接按分组显示
• 状态栏切换当前连接
• 使用普通 .sql 文件写查询
• Cmd+Enter / Ctrl+Enter 执行当前语句
• CodeLens 一键执行语句
• 左侧查看库表结构
• 点击表查看字段、类型、注释、主键、是否可空
• SQL 补全支持表别名，比如 bs. 只提示 biz_show bs 的字段
• Hover 表名查看轻量结构摘要
• 查询结果只读展示，支持分页、总数、耗时
• 支持 CSV / JSON 导出

它不是一个“大而全”的数据库客户端。

它更像一个顺手的小工具：你正在 VS Code 里写业务代码，需要查个表、跑段 SQL、看下字段注释，不想切到另一个软件，也不想为了几个高频能力开会员。

这个时候它就刚好够用。

给想做产品的人：先做窄，再做深

这次最大的感受是：AI coding 会放大执行力，也会放大产品失控。

以前想加功能，还得掂量一下开发成本。现在 Codex 可能十几分钟就能给你写一个雏形，于是更容易高估“这个也顺手做了”的合理性。

所以产品判断反而更重要了。

建议是：

• 先写清楚用户是谁
• 再写清楚用户每天最高频的 3 个动作
• 竞品功能不要全抄，要拆出“为什么用户需要它”
• MVP 必须有明确的不做清单
• 每次想加功能，先问它是不是主路径

SQL Workbench 的 MVP 之所以能收住，是因为一直坚持一条线：

让开发者在 VS Code 里更舒服地写 SQL。

不属于这条线的，先放后面。

给想学 AI coding 的人：别只学提示词

AI coding 真正难的地方，不是怎么写一句神奇 prompt。

更重要的是会不会把 AI 放进一个工作流里。

常用方式是：

• 先让它分析，不急着写代码
• 给它真实截图，而不是只讲感受
• 让它输出路线图和取舍
• 每次实现后都要求自测
• 自己保留最终产品判断
• 不满意就直接指出具体问题

比如“补全不对”这件事，不要只说“你这里有 bug”。给它截图，说：当前 biz_show bs 已经有别名了，输入 bs.i 时不应该出现所有表的 id，应该只出现 biz_show 的字段，并且要带字段描述和类型。

这种反馈具体，AI 才能真的改对。

复盘：这件事让个人产品更乐观了

以前一个人做 VS Code 扩展，最麻烦的不是某个 API，而是杂事太多：

• 产品定位
• 竞品分析
• UI 原型
• 技术架构
• VS Code API
• 数据库驱动
• Webview
• 图标
• README
• 截图
• 打包
• 发布

每一项都不算特别难，但加起来很消耗人。

Codex 把这些“中间体力活”降下来了。

它不能替你判断产品该不该做，也不能替你感受用户哪里别扭。但只要能把问题说清楚，它可以很快把想法推到一个能运行、能安装、能发布的状态。

这对个人开发者很重要。

很多小产品过去不是死在技术难度，而是死在“做到一半太累了”。

现在这个门槛确实低了。

最后，打个广告

如果你也经常在 VS Code 里写 SQL，或者不想为了几个常用数据库工作流再开一个重型客户端，可以试试 SQL Workbench。

它目前支持 MySQL/MariaDB、PostgreSQL、SQLite，主打：

• SQL 文件留在项目里
• 状态栏快速切连接
• Schema 只读查看
• 表别名感知补全
• 查询结果分页、总数、耗时
• CSV / JSON 导出
• 没有付费墙

GitHub：github.com/DWmister/sq…

VS Code Marketplace 可以搜索：SQL Workbench

如果你也想学 AI coding，建议是别从“做一个 Todo App”开始。找一个你每天真的会用、真的嫌麻烦、真的愿意反复打磨的小工具。

AI 最适合的不是替你凭空变出伟大产品，而是陪你把一个真实的不爽，磨成一个能用的东西。