如何用 AI（自然语言）查询 DynamoDB
"给我看上周失败的订单"在你脑子里是一句话，在线上却是一个带占位符映射的 KeyConditionExpression。弥合这道鸿沟，才是"用 AI 查询 DynamoDB"的真正含义——因为 DynamoDB API 本身没有自然语言端点。每个请求依然是表达式或 ；AI 坐在工具层，把你的意图翻译成它们。
这种翻译可以真正出色，也可以悄悄致险，取决于一件事：模型能否看到你真实的 schema。本指南涵盖三种可行的搭配，以及每一种在哪里失灵。
如何用自然语言查询 DynamoDB？
三个现实选项：让一个通用 LLM 起草 PartiQL 然后你自己运行（快，但模型在猜你的属性名）；通过 MCP 服务器把一个 AI 代理连接到 DynamoDB，让它能真正地检查和查询；或者用一个内置 schema 感知助手的 DynamoDB 客户端——DynoTable 的 AI 聊天把自然语言变成针对你实际已索引 schema 的 PartiQL 或 SQL，计算精确的全表聚合，并把任何写入暂存等待你审阅。
选项 1：LLM 起草 PartiQL，你来运行
零配置版本：把查询描述给任何一个够格的模型，拿回 PartiQL，在控制台的 PartiQL 编辑器或通过 CLI 运行它：
aws dynamodb execute-statement \
--statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"它能用——也会以三种可预见的方式失灵：
- 模型看不到你的表。它会信心十足地编造属性名和键的形状（你的是
PK = ORDER#<id>，它写orderId）。你最终在调试幻觉出来的 schema，而不是在写查询。 - PartiQL 的限制照样适用。一条
SELECT只读取恰好一张表，而一个没有钉住键的WHERE会变成一次全表扫描——悄无声息地烧钱，和你自己写出来一模一样。模型很少会警告你；PartiQL 与 SQL 解释了这层 SQL 外表买到和买不到什么。 - 把 schema 或数据粘贴进聊天机器人是一个数据治理决策。提示词里的样本项就是离开你边界的生产数据。
适合对一个你能凭记忆粘出 schema 的表做一次性查询；作为工作流则摇摇欲坠。
选项 2：通过 MCP 连接的 AI 代理
对"模型看不到你的表"的结构性修复，是给代理工具而不是粘贴进提示词的 schema。Model Context Protocol（MCP）做的正是这件事：一个 MCP 服务器把 DynamoDB 操作暴露为带类型的工具，任何支持 MCP 的代理（Claude、IDE 助手、自定义代理）都能列出表、检查键、运行查询，并把真实结果送回对话。
完整的搭建方式——以及让代理触碰数据库所带来的同意、权限范围和写入安全问题——我们在通过 MCP 服务器使用 DynamoDB里详述。DynoTable 自己就带一个：它可以向外部代理暴露受门控、仅限本机回环的工具，带逐连接的同意与权限范围。
当_代理_本身就是产品时——一个客服机器人、一个内部 Slack 助手——这是正确的架构。但对于日常的交互式工作，它仍然要你自己把代理、服务器和凭证拼装起来。
选项 3：DynamoDB 客户端里的 schema 感知助手
DynoTable 的内置助手是集成版：它就住在你的表旁边（⌘;），并且读取你的已索引 schema——当前 profile 下的表、它们的键与索引、由表索引发现的属性路径与类型，甚至样本值——于是"把这个筛选到上周"解析到的是你真实的属性名，而不是猜测。输入 @ 可以显式引用 @table、@column 或 @gsi。
面对一个问题，按能力清单它会做的事：
- 替你写查询——只读的 PartiQL，或当问题需要
JOIN/GROUP BY/ 聚合（DynamoDB 的 API 所没有的分析能力）时用 Workbench SQL——并把结果作为一个卡片（chip）提出，你点一下就能作为真正的标签页打开。 - 计算精确的全表答案。问一个计数、求和、平均或按组细分，它会读取每一个匹配的项，而不是抽样一页——"上个月有多少订单？"反映的是真实的表。它还能把同一遍扫描重塑成一份转换后的导出文件。
- 把每一个写入都暂存。让它修一行数据，更改会以可审阅差异的形式落在暂存区——在任何权限模式下，助手都不能直接写入 DynamoDB、批量删除一张表或更改表结构。你来审阅，你来提交。
- 花你的钱之前先问你。会触达 AWS 并消耗容量的读取受权限门控（Manual / Auto / Full Auto，按 profile 设置），每一次门控决定都记入一份本地的、始终开启的审计日志。
信任模型和功能同样重要：助手运行在你自己的 AWS Bedrock 凭证上，直接与你账户里的 Bedrock 通信——提示词、schema 和表数据从不路过 DynoTable 的服务器，推理按 Bedrock 自己的费率计入你的账单，没有加价。工具结果被当作不可信数据处理，所以一行包含"忽略之前的指令"的数据劫持不了代理。
AI 改变不了 DynamoDB 的哪些事实
任何诚实的 AI 层都继承这个数据库的物理规律：
- 访问模式仍然说了算。对非键属性的"where status = X"就是一次带筛选的扫描，无论是谁写的——模型只是把这条昂贵的查询打得更快。如果某个问题总是逼出扫描，解药是建模（一个 GSI、一个更好的排序键），而不是更好的提示词。
- 读取消耗真金白银的容量。一次精确的全表聚合就是一次全表读取。好工具会把它门控起来并明说；定价计算器能在你批准之前告诉你完整扫一遍要花多少。
- 确定性有它的位置。对于一条你将在生产里永远运行的查询，在表达式构建器里手工构建一次表达式，交付精确的名称/值映射——AI 用于探索，构建器用于你提交进代码的东西。
常见问题
能用普通话/自然语言查询 DynamoDB 吗？ 对 API 本身不行——DynamoDB 只听表达式和 PartiQL。但 AI 层可以翻译：一个起草 PartiQL 的 LLM、一个通过 MCP 连接的代理，或像 DynoTable 那样感知 schema 的助手，针对你真实的 schema 生成并运行查询。
DynamoDB 有内置的 AI 查询功能吗？ DynamoDB API 没有自然语言端点。你能得到的任何 AI 查询能力都来自上层的工具层——这也正是为什么该工具层的安全模型（读取门控、暂存写入、你自己的凭证）才是需要评估的东西。
让 AI 靠近生产数据安全吗？ 这是一个权限问题。要看的点：读取要经过显式批准的门控、写入要落进可审阅的暂存区而不是直接执行、有审计日志、推理跑在你掌控的凭证上。DynoTable 的助手四条全占；一个拿着你粘贴数据的聊天机器人一条不占。
AI 能做表连接或 GROUP BY 吗？
通过 DynamoDB API 不行——根本没有执行它的引擎。DynoTable 的助手通过其只读的 Workbench SQL 回答这类问题（真正的 JOIN、GROUP BY 和聚合，在 DynamoDB 的访问模式规则之内），计数/求和/平均类的问题也落在那里。
要花多少钱？ 两个计价器：查询触及的 DynamoDB 读取容量（受门控的读取助手会先问你），以及计入你自己 AWS 账户的 Bedrock 推理费——DynoTable 不加价、不代理任何流量。
用自然语言问出你的下一个问题——下载 DynoTable，把 AI 指向你自己的 Bedrock，并让每一个写入都过一道审阅。