把 Airtable 接上 AI 代理

1. 什麼會殺死一個 Airtable 資料庫

值得誠實地看看這些資料庫是怎麼走到盡頭的，因為同一套劇本一再重演，而且跟工具本身的好壞毫無關係。

• 資料庫是一個人搭起來的。 做得很好，與業務嚴絲合縫，對設計它的人來說一目了然。這是最好的時刻。
• 輸入壓在同一個人身上。 其他人只看資料庫，不去填 —— 不是出於抗拒，而是因為填那一筆需要知道哪一欄該放什麼。
• 過了一個忙碌的月份。 三週不更新就夠了：從那之後沒人再信這些數字，於是沒人去改，於是它們真的變錯了。

成本不是 Airtable 的訂閱費，那點錢很有限。成本是你所取代的那套真正軟體值多少個半天，乘以你並沒有那套軟體這個事實 —— 以及你依據一張過期表格做出的判斷。這正是買不起工具的公司的典型樣貌：自己搭是對的選擇，而它要求有人把它維持下去。

2. AI 代理在 Airtable 裡做什麼

Airtable 的官方連接器對你所指定的資料庫給出讀取與寫入的存取權。具體涵蓋如下：

• 讀取紀錄。 找出某一筆、把兩張資料表對起來、回答那些必須看資料庫而不是靠手翻才答得出的問題。
• 新建一筆紀錄。 那筆缺漏的資料 —— 一位新聯絡人、一筆收到的訂單、一處開工的工地 —— 在事情發生的當下補上，而不是拖到週五。
• 更新一筆紀錄。 改一個狀態、補一個留白的欄位、訂正一個在別處已經變了的資料。

讓這件事真正有用的組合幾乎總是同一個：代理去讀資訊誕生的那個工具裡發生了什麼 —— 信箱、收款、已訂的會面 —— 並把軌跡留在 Airtable。資料庫不再是謄寫的差事，而成了一面映照。

3. Airtable 特有的限制 —— 一次一個資料庫

範圍以兩層指定，這不是走形式：在 Airtable，同一個帳號往往放著彼此毫不相干的資料庫。

• 工作區，把一個團隊或一位客戶的資料庫歸在一起。
• 資料庫本身。代理看得見你指定的那一個，看不見其餘的。

這是本頁最具體的一條建議：只分享你的代理需要的資料庫。 很多公司不假思索地把業務追蹤表和一些本不該落在程式可及範圍內的資訊 —— 薪資檔案、面談紀錄、正在談的案子 —— 一起放在 Airtable 裡。指定資料庫這個三十秒的動作，能把這個問題一次解決。

這也讓這個連接器比大多數都更少暴露：它不對任何人說話。它寫下的東西既不會送到顧客那裡，也不會公開，更不會扣錢。這裡的風險是被看到或被改動的資料 —— 而指定資料庫就把它封住了。

4. 它不做什麼

• 它不重排你的資料庫。 你的資料表、欄位與檢視是你的成果。代理填充結構，不會因為另一種劃分在它看來更好就整個重來。
• 它不成批刪除。 大規模清理在實務上是收不回來的，即使有垃圾桶。這類操作要嘛一筆一筆核准，要嘛就不做。
• 它不用推估值去填空欄位。 未填寫的格子保持空白，而不是被一個看似合理的值補上 —— 那是敗壞一個資料庫最不起眼的方式，也是事後最難察覺的方式。
• 只要你沒有放寬，它就不會未經核准寫入。 在這個連接器上，詞彙理順之後放寬是合理的：這裡的寫入是可回復的，不同於一次寄件或一次公開發布。

5. 往一個不是自己設計的結構裡寫

這是 Airtable 特有的難處，值得點明。一個資料庫就是一套私人詞彙：你的「狀態」欄位裡的值只有在貴公司才說得通，你的「專案」資料表並不指別處所說的那個「專案」，有時兩個名稱相近的欄位指的卻是不同的東西。

一個不理解這種結構就往裡寫的代理，做出來的是整潔的混亂：格式規矩的資料列，放錯了地方。避開這個毛病，歸結為兩個習慣：

• 頭幾天保留核准，不是出於不信任，而是為了看清代理把東西歸到哪裡。正是在那裡，你會發現自己資料庫裡的含糊之處 —— 而且往往帶著意外。
• 把含糊的東西講明白。 一次性說清「待處理」在貴公司指的是「等顧客」而不是「等我們」，勝過日後任何一次修正。

這項定框的工作要花一個小時，而且不必重來。順帶一提，它也是你的資料庫有史以來第一份說明。

6. 時間拉長之後會有什麼不同

• 第 1 週。 寫入經過核准，你調整歸放的方式。看得見的收穫不多；真正的收穫是資料庫不再依賴某一個人。
• 第 3 個月。 資料列在事情發生的當天增加。你搭好的檢視與儀表板重新開始說得上話 —— 它們並沒有變得不準，只是斷了供給。
• 第 2 年。 資料庫在一段長時間裡是完整的，這既少見又珍貴：可以比較，可以看出季節性，可以決定停掉某件事。這也是你能判斷這個資料庫是否值得變成一套真正工具的時刻 —— 而這個問題在滿是空缺的資料上無從回答。

不承諾任何量化的時間節省：那取決於你原本追蹤什麼、多久追一次。得到保證的是，在沒人有空去填的時候，資料庫仍然是被填上的。

7. 常見問題

延伸閱讀

接著讀：接上 Google 試算表、接上 Notion，或全部可用的連接器。