你的数据库已经有答案——只需提问
Source: Dev.to
每个 Laravel 应用程序都坐落在充满洞察的数据库之上。
本月有多少用户注册？哪些产品表现不佳？按地区划分的平均订单价值是多少？数据就在眼前，但要获取它通常意味着两件事之一：编写原始 SQL，或构建需要数天才能交付的自定义仪表盘。
我创建了 LaraGrep 来弥合这一鸿沟——一个 Laravel 包，让你可以用简洁的英文提问关于数据库的问题，并获得真实的答案。
每个开发者都熟悉的问题
你正在开会。客户问道：“我们有多少活跃订阅将在下个月到期？”
你知道数据是存在的，知道该连接哪些表。但要立即回答这个问题，你需要打开终端，编写查询语句，运行它，可能还要修正拼写错误，再次运行。
现在把这种情况乘以所有需要从数据库中获取*“一个快速数字”*的利益相关者。产品经理、销售团队、创始人——他们都有问题，而开发者就成了瓶颈。
有些团队会构建内部仪表盘。这对经常出现的问题有效，但对那些突如其来的临时查询就无能为力。维护这些仪表盘的成本会随时间累积。
LaraGrep 实际功能
LaraGrep 连接到你的 Laravel 应用，读取数据库模式，并使用 AI 将自然语言问题转换为安全的、参数化的 SQL 查询。与其他文本转 SQL 工具的关键区别在于，它不仅仅生成一个查询并寄望于成功。
它使用 agent loop：AI 执行查询，查看结果，思考所学内容，并决定是再运行另一个查询还是直接给出最终答案。这意味着它能够处理需要多步操作的问题——跨表连接数据、基于先前结果进行过滤、在出现意外时自我纠正。
询问 “我们在 Q4 相比 Q3 的畅销产品类别是什么？” 时，AI 可能在后台运行三到四个查询：
- 理解模式。
- 拉取 Q3 数据。
- 拉取 Q4 数据。
- 进行比较。
你只会看到最终答案。
Source: …
一个了解您模式的数据分析师
把 LaraGrep 想象成一名记住了您整个数据库结构的初级数据分析师。您描述表、列、关系，甚至提供 JSON 列中包含内容的提示。AI 会利用所有这些上下文来编写准确的查询。
Table::make('orders')
->description('Customer orders with payment status.')
->columns([
Column::id(),
Column::bigInteger('user_id')->unsigned()
->description('FK to users.id'),
Column::decimal('total', 10, 2)
->description('Order total in USD'),
Column::enum('status', ['pending', 'paid', 'cancelled']),
Column::json('metadata')
->template([
'shipping_method' => 'express',
'coupon_code' => 'SAVE20',
]),
Column::timestamp('created_at'),
])
->relationships([
Relationship::belongsTo('users', 'user_id'),
]);您提供的上下文越多，得到的答案就越好。列描述、枚举值、JSON 模板——所有这些都帮助 AI 理解不仅是结构，还有数据背后的含义。
对于大型数据库，您甚至不需要手动定义所有内容。将模式模式设置为 auto，LaraGrep 将直接从 information_schema 读取，提取表和列的注释作为描述。
实际使用案例
针对客户项目 – 为客户交付一个管理后台，客户可以输入 “显示上个月下单超过 3 笔但本周未登录的所有用户”，即可获得即时答案。无需自定义报表页面。无需 Jira 工单。无需等待。
针对自己的 SaaS – 你在晚上 11 点调试计费问题。与其在五个表之间编写 JOIN 查询，不如直接询问：“过去 48 小时内在 Pro 计划中有支付失败且订阅仍然有效的用户有哪些？” LaraGrep 会为你自动生成所需的 join 和过滤条件。
了解业务数据 – 早期创始人技术足够可以操作数据库，但并不总有时间正确地查询。“我的 MRR 是多少？” “本季度的流失率是多少？” “自然用户和付费用户的注册到首次购买时间对比如何？” 这些问题不应每次都花 20 分钟写 SQL。
生成报表 – LaraGrep 提供查询导出模式，AI 会把所有推理整合为一条优化后的 SELECT 查询并返回给你——没有 LIMIT，没有内存限制。随后你可以自行执行：使用 cursor() 进行流式处理，使用 chunk() 进行批量处理，或将其导入 Laravel Excel。AI 完成思考，执行权在你手中。
定期报表 – 配方系统会自动保存每一次成功的查询链。发现一个每周一都会问的问题？使用最新数据重放该配方——AI 会自动调整日期参数。将其接入计划任务，即可实现自动化报表，而无需构建任何仪表盘。
本地使用 Ollama
并非所有项目都能将数据库模式发送到外部 API。医疗、金融、政府合同——有充分的理由将所有内容保留在本地。
LaraGrep 开箱即用支持 Ollama。只需指向本地实例，选择模型，所有查询都留在你的机器上。没有数据会离开你的网络。设置只需三个环境变量：
LARAGREP_PROVIDER=openai
LARAGREP_API_KEY=ollama
LARAGREP_BASE_URL=http://localhost:11434/v1/chat/completions
LARAGREP_MODEL=qwen3-coder:30b权衡在于，本地模型的能力不如 GPT‑4o 或 Claude，难以处理复杂的多步骤推理。但对于直接的查询——计数、聚合、过滤查找——它们已经足够好。而在敏感环境中，“本地足够好”往往是唯一可接受的选项。
Source: …
“LaraGrep” 每次都击败 “Perfect in the Cloud”
设计即安全
让 AI 编写 SQL 听起来很危险——如果不小心使用的话，它本应如此。LaraGrep 采用了严格的做法：
- 只读模式 – 只允许
SELECT查询。任何修改尝试都会在到达数据库之前被拒绝。 - 参数化绑定 – AI 永远不会将用户输入直接插入原始 SQL。
- 模式校验 – 每个表引用都会根据你定义的 schema 进行校验，AI 不能查询你未公开的表。
- 执行超时 – 可配置的超时会在查询变慢时终止它们，防止锁表。
- 迭代上限 – 代理循环被限制在最大迭代次数，以防止 API 成本失控。
这并不意味着零风险。你仍然向外部暴露了读取数据的权限，因此必须使用认证中间件来保护端点。不过，与直接提供数据库 GUI 相比，攻击面已经大幅缩小。
入门指南
如果你有一个 Laravel 10+ 项目并且拥有 API 密钥（或 Ollama），可以在五分钟内完成部署：
composer require behindsolution/laragrep
php artisan vendor:publish --tag=laragrep-config
php artisan migrate- 在配置文件中定义你的表。
- 在
.env中设置你的 API 密钥。 - 发送 POST 请求：
curl -X POST http://localhost/laragrep \
-H "Content-Type: application/json" \
-d '{"question": "How many users registered this week?"}'就这么简单。响应中会包含自然语言的摘要，以及可选的完整调试跟踪，展示 AI 执行的每条查询。
对你的项目意味着什么
这场转变并不真正是让 AI 编写 SQL，而是让任何能够用文字描述需求的人都能访问数据库知识。
- 机构 – 在无需数周仪表盘开发的情况下，为客户项目立即提供价值。
- SaaS 开发者 – 在不切换到 SQL 客户端的情况下，保持对数据的近距离操作。
- 拥有非技术利益相关者的团队 – 减少开发者被打断的次数。
数据一直都在那里，现在更容易获取了。
LaraGrep 是开源的，代码托管在 GitHub 上：
github.com/behindSolution/laragrep
欢迎星标、提交 issue 和 pull request。如果你在项目中使用了它，期待听到你的使用体验。