如何用 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，並讓每一個寫入都過一道審閱。