模拟帝国驿站是什么 模拟帝国驿站游戏玩法与特色介绍
2026-07-11 3393829
2026-07-11 0
我最近做了一个 VS Code 数据库扩展，叫 SQL Workbench。
起因很简单：我看到一个数据库管理插件，体验不错，状态栏切连接、左侧看库表、右侧跑 SQL、还能根据表别名提示字段。偏偏很多高频功能被放进了付费版。
作为一个长期在 VS Code 里写后端的人，这件事挺微妙：我不是不愿意为好工具付费，但如果一个工具的核心价值刚好就是我每天最熟悉的那套工作流，我会忍不住想一句话：这东西能不能自己做一个？
于是这个项目就开始了。
不是“我要做一个数据库客户端”。这个目标太大，也太容易做散。
我真正想做的是：一个 SQL 优先的 VS Code 数据库工作台。
SQL 文件还是放在项目里，连接还是在状态栏切，库表结构可以顺手看，结果可以分页看，提示能懂表别名。至于那些危险的 GUI 编辑，比如直接在表格里改值、删列、删表，MVP 先不要。要改数据，就写 SQL。
这就是 SQL Workbench 的第一版边界。
我没有上来就让 Codex 初始化项目。
第一步是看竞品。
我把竞品官网、截图和实际使用效果都喂给 Codex，让它先帮我做功能拆解。这里很重要，不是问一句“帮我做个数据库插件”，而是让它先站在产品经理和架构师的角度回答几个问题：
拆完之后，我们得到的核心判断是：竞品真正好用的地方不是“数据库管理”四个字，而是它把数据库工作嵌回了 VS Code 的日常路径里。
比如：
.sql 文件，而不是打开一个专有查询窗口bs. 时，只提示 biz_show bs 这张表的字段这些才是每天都会用到的东西。
反过来，一些看起来很完整的能力，比如结果表格内联编辑、列信息直接编辑、删除表结构，这些都被我们暂时拿掉了。原因也很直接：
MVP 阶段不要把危险操作做得太顺手。
数据库工具最怕“做得很方便”，然后用户顺手点错。
所以第一版的原则是：看可以很方便，改必须通过 SQL。
如果把目标定成“替代 DataGrip”或者“替代 Navicat”，这个项目第一天就会失控。
SQL Workbench 的定位更窄：
这里的几个词都很关键。
SQL 优先，意思不是“只支持 SQL”，而是把 SQL 当成主要入口。用户在自己的项目里创建 .sql 文件，用 Git 管理，用编辑器的快捷键、搜索、片段、格式化能力，不需要进入另一个厚重软件。
本地优先，意味着连接信息、SQL 文件、使用过程都尽量留在本机和当前工作区里。密码放进 VS Code SecretStorage，普通连接元数据放扩展状态里，不搞云端账号体系。
轻量，意味着我们不追求第一版支持所有数据库、所有高级对象、所有 GUI 操作。先把 MySQL/MariaDB、PostgreSQL、SQLite 跑通，把连接、Schema、补全、执行、结果这些主路径打磨顺。
这个定位确定之后，后面的技术选择就清楚很多。
最后定下来的 MVP，大概是这样：
| 模块 | MVP 做什么 | 暂时不做什么 |
|---|---|---|
| 连接管理 | 新建、保存、测试连接，支持分组 | 云同步、多账号协作 |
| 连接类型 | MySQL/MariaDB、PostgreSQL、SQLite | Oracle、SQL Server、Redis 等 |
| SQL 编辑 | 使用普通 .sql 文件 | 专有查询文件格式 |
| 执行入口 | CodeLens、右上角按钮、Cmd/Ctrl+Enter | 复杂任务编排 |
| 连接切换 | 状态栏 + QuickPick | 多窗口连接会话管理 |
| Schema 浏览 | 左侧树查看库、表、字段 | 直接编辑表结构 |
| 表详情 | 右侧只读字段面板 | 可视化改列、删列 |
| SQL 补全 | 关键字、表名、字段、别名感知字段 | 完整 SQL 语义分析器 |
| 查询结果 | 只读表格、分页、总数、耗时 | 表格内联编辑 |
| 导出 | CSV / JSON | 报表系统 |
这张表后来非常有用。
因为做 AI coding 最容易发生的一件事是：AI 太能写了，你也太容易加需求了。
今天加个 ER 图，明天加个 Mock 数据，后天加个结构同步，再过两天项目就变成一锅粥。
MVP 表的作用，就是不断提醒自己：先把主路径做完。
这次我不是把 Codex 当“代码补全工具”用，而是把它当一个小团队用。
我给它的角色是：主 agent 担任 CTO，负责理解需求、拆任务、写代码、验收；必要时可以分配子任务，但最终要自己把关。
整个过程大概分成几类对话。
一开始我只给了竞品链接和截图，让 Codex 先分析，而不是动工。
输出包括：
这里有个经验：
不要一开始就让 AI 写代码，先让它写判断。
代码错了可以改，方向错了后面全是浪费。
这个项目很多细节都来自截图。
比如状态栏切换连接。一开始设计并不直观，当前连接位置不明显。我发了竞品截图，要求它参考竞品的 QuickPick 分组方式，把 Current 的位置调整得更容易看。
再比如左侧树，竞品可以展开表直接看列。我们讨论后决定：
这就避免了为了“像竞品”而无脑堆功能。
有几个问题是边做边问出来的。
比如 SQL 文件写在哪里？
答案是：写在 VS Code 当前项目里，就是普通 .sql 文件，不放在插件内部。这样用户可以用 Git 管理 SQL，也可以按业务目录组织。
比如 MVP 支持几个连接？
答案是：不做数量限制。连接可以分组，当前 SQL 执行哪个库，由状态栏的 Active Connection 决定。
比如查询结果要不要默认加 LIMIT 100？
一开始我们加过，后来发现不对。用户写什么 SQL，就应该执行什么 SQL。问题不是 SQL 没有限制，而是前端不该一次渲染巨大结果集。
所以后来改成：
LIMIT 10，Total 就是 10，不再额外统计全表这比“偷偷加 LIMIT”舒服很多。
我基本不会接受“代码已完成”这种结论。
每个阶段都要求它跑：
npm run checknpm run compile
涉及查询执行时，还让它用 SQLite 构造数据做运行时验证。
比如这次结果分页，它最后验证的是：
select * from t 没有显式 LIMIT，会走服务端分页：总数 150，但第一页只取 10 条select * from t limit 5 会尊重用户写的 LIMIT：Total 为 5，不再额外统计全表总数这种验证很朴素，但足够抓住核心逻辑：不篡改用户 SQL，同时避免前端一次性渲染巨大结果集。
比如默认加 LIMIT 100。
从保护前端性能的角度看，这个方案很自然。但从数据库工具的体验看，这不对。用户写的 SQL 被工具改了，哪怕是善意的，也会让人不信任。
后来我们把问题拆开：
这个拆法一出来，方案就顺了。
只用文字说“像竞品一点”，基本没用。
截图能告诉 AI：
视觉问题靠文字抽象很容易偏，靠截图反馈会快很多。
Codex 这类工具已经很强了，强到很容易让人放松警惕。
但它还是会犯一些工程层面的错，比如：
所以我的做法是：让它写，也让它跑；让它解释，也让它证明。
本地跑通之后，我们开始发布。
大致流程是：
package.json 里的 publisher、displayName、description、icon、repository 等信息.vsix 包vsce 登录 publisher本地打包命令是：
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 图标不是一回事：
package.json 里的 icon这些不是难题，但如果第一次发扩展，会很容易卡在“这到底是不是我配置错了”。
SQL Workbench 目前已经可以完成一条比较完整的数据库工作流：
.sql 文件写查询Cmd+Enter / Ctrl+Enter 执行当前语句bs. 只提示 biz_show bs 的字段它不是一个“大而全”的数据库客户端。
它更像一个顺手的小工具：你正在 VS Code 里写业务代码，需要查个表、跑段 SQL、看下字段注释，不想切到另一个软件，也不想为了几个高频能力开会员。
这个时候它就刚好够用。
这次最大的感受是：AI coding 会放大执行力，也会放大产品失控。
以前你想加功能，还得掂量一下开发成本。现在 Codex 可能十几分钟就能给你写一个雏形，于是你更容易高估“这个也顺手做了”的合理性。
所以产品判断反而更重要了。
我的建议是：
SQL Workbench 的 MVP 之所以能收住，是因为我们一直坚持一条线：
让开发者在 VS Code 里更舒服地写 SQL。
不属于这条线的，先放后面。
我觉得 AI coding 真正难的地方，不是怎么写一句神奇 prompt。
更重要的是会不会把 AI 放进一个工作流里。
我的常用方式是：
比如“补全不对”这件事，不要只说“你这里有 bug”。我会给它截图，说：当前 biz_show bs 已经有别名了，输入 bs.i 时不应该出现所有表的 id，应该只出现 biz_show 的字段，并且要带字段描述和类型。
这种反馈具体，AI 才能真的改对。
以前一个人做 VS Code 扩展，最麻烦的不是某个 API，而是杂事太多：
每一项都不算特别难，但加起来很消耗人。
Codex 把这些“中间体力活”降下来了。
它不能替你判断产品该不该做，也不能替你感受用户哪里别扭。但只要你能把问题说清楚，它可以很快把想法推到一个能运行、能安装、能发布的状态。
这对个人开发者很重要。
很多小产品过去不是死在技术难度，而是死在“做到一半太累了”。
现在这个门槛确实低了。
如果你也经常在 VS Code 里写 SQL，或者不想为了几个常用数据库工作流再开一个重型客户端，可以试试 SQL Workbench。
它目前支持 MySQL/MariaDB、PostgreSQL、SQLite，主打：
GitHub：github.com/DWmister/sq…
VS Code Marketplace 可以搜索：SQL Workbench
如果你也想学 AI coding，我的建议是别从“做一个 Todo App”开始。找一个你每天真的会用、真的嫌麻烦、真的愿意反复打磨的小工具。
AI 最适合的不是替你凭空变出伟大产品，而是陪你把一个真实的不爽，磨成一个能用的东西。