去年Stack Overflow调研显示，67%的开发者每周花超过5小时在理解遗留代码上。其中数据库Schema（数据库结构定义）的逆向工程，是公认最耗耐心却没有成就感的脏活。
一位独立开发者最近放出的工具，试图把这个过程交给AI——但不是简单的"AI包装"，而是让模型真正"看见"数据库内部。项目上线两周，GitHub星标破千。
01 | 遗留数据库：程序员的集体噩梦
FLG_Z_99。这个列名来自某金融系统的真实Schema。没人知道它代表什么，文档早在2017年就丢了。当你试图让Claude或Cursor帮忙写查询时，AI会自信满满地拼接根本不存在的JOIN关系，然后你调试三小时发现它 hallucinate（产生幻觉）了外键。
这是Legacy Lens作者的开场白。他厌倦了复制粘贴DDL导出文件，厌倦了每次都要手动解释"这个表其实是用户日志，那个字段存储的是压缩后的JSON"。
AI模型很聪明，但对本地基础设施是"盲人"。 给它连接字符串不够，它需要数据的语义地图。作者的原话是：「在"AI包装器"泛滥的世界里，瓶颈不是AI的智力，而是我们提供的上下文精度。」
02 | MCP协议：让AI获得"视力"的关键
Legacy Lens的核心赌注押在Model Context Protocol（模型上下文协议，简称MCP）上。这是Anthropic去年推出的开放标准，旨在让AI助手安全地连接外部数据源。
作者没有写一个简单的Python脚本包装OpenAI API。他搭建了一个专门的 introspection engine（内省引擎），作为AI在数据库内部的"眼睛"。设计哲学很产品经理：模块化、可复用。项目被拆成两个作用域明确的NPM包，而非单体脚本。
目前支持PostgreSQL、MySQL/MariaDB、SQLite、Microsoft SQL Server。Oracle不在列——作者调侃「除非我特别勇敢」。Node.js 20+环境，一行命令部署：npx @legacy-lens/mcp-server
安全边界设计得保守：只读Schema和样本数据（默认5行，上限10行），明确禁止AI执行任意读写SQL。定位是"改动旧系统之前的理解工具"，而非数据库管理界面。
03 | 为什么"非包装器"很重要
过去18个月，AI工具链出现严重的同质化。大量项目在做同一件事：把API调用包装成ChatGPT插件，收订阅费。Legacy Lens的差异化在于架构层的选择——它不提供"AI帮你写SQL"的幻觉，而是解决一个更基础的问题：让AI先理解它在看什么。
这种区分在Cursor用户群里反响明显。一位评论者说：「终于不用把半个数据库dump成文本塞进上下文窗口了。」另一位提到，处理400表系统时，传统方式需要手动梳理ER图，现在AI能直接回答"这个字段被哪些存储过程引用"这类问题。
作者目前在收集反馈决定下一个引擎。Oracle的呼声存在，但社区更关注DB2和Snowflake的支持。
工具开源在GitHub，MIT协议。没有商业版预告，没有Discord服务器，README里甚至没放赞助链接。这种克制在当下的AI工具圈反而显得稀缺。
如果你手上也有那种"想让人辞职"的数据库，会愿意把Schema暴露给AI助手吗？还是说，某些遗留系统的混乱程度，连AI看了都会沉默？
热门跟贴