如何用 AI 查詢 DynamoDB（自然語言）

「給我看上週失敗的訂單」在你腦中是一句話，在網路上卻是一個 帶佔位符對應的 KeyConditionExpression。彌合那道落差，才是 「用 AI 查詢 DynamoDB」的真正含義——因為 DynamoDB API 本身沒有自然語言端點。每個請求仍然是運算式或 PartiQL；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 vs SQL 解釋了這層 SQL 外衣 買得到什麼、買不到什麼。
• 把 schema 或資料貼進聊天機器人是一個資料治理決定。 提示裡的樣本項目，就是離開你邊界的生產資料。

對於一個你能憑記憶貼出 schema 的一次性查詢還不錯；作為 工作流程就很不牢靠。

選項 2：透過 MCP 連接的 AI 代理程式

「模型看不到你的資料表」的結構性解法，是給代理程式 工具，而不是貼進提示的 schema。Model Context Protocol（MCP） 做的正是這件事：一個 MCP 伺服器把 DynamoDB 操作以帶型別的工具 公開出來，任何支援 MCP 的代理程式（Claude、IDE 助理、自訂代理程式）都能 列出資料表、檢視索引鍵、執行查詢，並讓真實結果回饋到 對話中。

完整的設置——以及讓代理程式碰資料庫所帶來的同意、範圍 與寫入安全問題——我們在 搭配 MCP 伺服器使用 DynamoDB 中詳談。DynoTable 本身就內建一個：它能向外部代理程式公開有閘門、僅限 loopback 的 工具，附逐連線的同意與範圍控制。

當 代理程式 本身就是產品時——支援機器人、內部的 Slack 助理——這是正確的架構。但對於日常的互動式工作，它仍然 讓你自己組裝代理程式、伺服器和憑證。

選項 3：DynamoDB 用戶端裡感知 schema 的助理

DynoTable 的內建助理是整合版：它 就住在你的資料表旁邊（⌘;），並讀取你的已建索引 schema——目前 profile 底下的資料表、它們的索引鍵與索引、由 資料表建索引發現的屬性路徑與型別， 甚至樣本值——所以「把這個過濾到上週」解析的是你真實的屬性 名稱，不是猜的。輸入 @ 可明確引用一個 @table、@column 或 @gsi。

按照能力目錄，它會對一個問題做這些事：

• 替你寫查詢——唯讀的 PartiQL，或當問題需要 JOIN / GROUP BY / 彙總（DynamoDB 的 API 所沒有的分析能力）時的 Workbench SQL——並把結果以一個 晶片的形式提出，點一下就打開成一個真正的分頁。
• 計算整表的精確答案。 問一個計數、加總、平均或 逐群組拆解，它會讀取每一個相符的項目，而不是取樣一個 分頁——「上個月有多少訂單？」反映的是實際的資料表。它也能在 同一趟讀取中把資料重塑成一個轉換後的匯出檔。
• 暫存每一次寫入。 請它修一列，變更會落在 暫存區成為可檢視的差異——這個助理在任何 權限模式下都不能直接寫入 DynamoDB、批次刪除資料表或 變更資料表結構。你來檢視，你來提交。
• 花你的錢之前先問你。 會打到 AWS 且花費容量的讀取 是權限閘控的（Manual / Auto / Full Auto，逐 profile），而且每一次 閘控決定都落在一份本機、常開的稽核記錄裡。

信任模型和功能一樣重要：這個助理跑在你 自己的 AWS Bedrock 憑證上，直接與你帳戶裡的 Bedrock 對話—— 提示、schema 與資料表資料從不經過 DynoTable 的伺服器，而 推論以 Bedrock 自己的費率計費給你，沒有加價。工具 結果被視為不受信任的資料，所以一列寫著「ignore previous instructions」的資料無法挾持這個代理程式。

AI 不會改變 DynamoDB 的哪些事

任何誠實的 AI 層都繼承這個資料庫的物理法則：

• 存取模式仍然說了算。 對非索引鍵屬性的「where status = X」 不管由誰來寫都是一次過濾掃描——模型只是更快地打出那個 昂貴的查詢。如果某個問題一直逼出掃描，解法在建模（一個 GSI、一個更好的 排序索引鍵），不在更好的提示。
• 讀取花的是真實容量。 一次整表的精確彙總就是一次 整表讀取。好工具會把它閘控起來並講明白； 定價計算器在你核准之前就告訴你 跑完整一趟要花多少。
• 決定論有它的位置。 對於一個你會在生產環境永遠跑下去的 查詢，在 Expression Builder 中把運算式親手組一次， 交付確切的 names/values 對應——AI 用於探索，建構器用於你 提交進版本庫的程式碼。

常見問答

我可以用白話英文查詢 DynamoDB 嗎？ 對 API 本身不行——DynamoDB 只講運算式和 PartiQL。 但 AI 層可以翻譯：一個起草 PartiQL 的 LLM、一個透過 MCP 連接的 代理程式，或一個像 DynoTable 那樣感知 schema 的助理，針對你 真實的 schema 產生並執行查詢。

DynamoDB 有內建的 AI 查詢功能嗎？ DynamoDB API 沒有自然語言端點。你拿到的任何 AI 查詢 能力都來自上層的工具——這正是為什麼那個工具的安全模型 （讀取閘門、暫存寫入、你自己的憑證）才是該 評估的東西。

讓 AI 靠近生產資料安全嗎？ 這是一個權限問題。要找的是：讀取被明確核准所閘控、 寫入落在可檢視的暫存區而不是直接執行、 一份稽核記錄，以及跑在你掌控的憑證上的推論。DynoTable 的 助理四項全中；一個貼著你資料的聊天機器人一項也沒有。

AI 能 join 資料表或做 GROUP BY 嗎？ 透過 DynamoDB API 不行——沒有引擎能做這件事。 DynoTable 的助理透過它唯讀的 Workbench SQL 回答這些問題（在 DynamoDB 存取模式規則之內的真正 JOIN、 GROUP BY 與彙總），計數／加總／平均 這類問題也落在那裡。

它要花多少錢？ 兩個計費表：查詢碰到什麼就花什麼的 DynamoDB 讀取容量（ 助理在閘控讀取前會先問），以及計費到你自己 AWS 帳戶的 Bedrock 推論——DynoTable 不加價、不代理任何流量。

用白話問出你的下一個問題——下載 DynoTable， 把 AI 指向你自己的 Bedrock，並讓每一次寫入都留在檢視這道關卡之後。