Airtable 裁員與 AI 產品路線:Core、Omni、Canvas 的承諾,使用者該怎麼看

Airtable 裁員公告提出 Core、Omni、Canvas、MCP 與效能路線。本文區分已存在功能與待推出承諾,整理團隊評估可靠性、權限和遷移成本的具體方法。

Share
Airtable 官方 Omni 建置應用程式示意
Airtable 官方既有 Omni 示意;並非裁員公告中尚待推出的 Canvas 畫面。 圖片來源:Airtable。

Airtable 裁員的消息在 X 引起討論,最受爭議的部分是主管把人員縮減與小團隊的交付效率放在同一則公告裡。

使用者最需要知道的是,正在依賴的工作系統,接下來會不會更可靠。

Bending Spoons 產品負責人 Federico Simionato 於 10 月 12 日 UTC 發表公告,表示將裁減 Airtable 團隊的大部分人員。貼文換算台北時間為 10 月 13 日。

他沒有在這則貼文提供人數或比例,因此不能把「大部分」換算成自行推估的裁員數字。

他提出的新方向同時包含基礎功能、AI 與效能。Core 團隊要按月處理用戶需求,Omni、Canvas、MCP 和自帶代理也有後續規畫,但公告對這組 AI 更新使用的是「coming soon」。

我會把這份路線當成值得追蹤的承諾,還不會因為裁員或 AI 名稱就判定產品已經變好。企業軟體的價值,要看原本工作的限制是否減少,而不是主管認為團隊應該多大。

如果你正在用 Airtable 管理內容、客戶或專案,最直接的影響是下一次續約和新流程建置。此時先分清楚能用的功能與還在等待的功能,比急著全面遷移更有幫助。

這次事件也讓一個問題變得具體:AI 建表與代理操作越容易,底層資料、權限及效能就越重要。產出漂亮介面只是開始,團隊每天能否穩定把工作做完,才會決定這套策略的結果。

Airtable 裁員公告提供了什麼,沒有提供什麼

Simionato 的原始公告把裁員描述為相信小團隊能交付更多、更好的產品,並感謝離職員工。

這是當事人的管理判斷,不能直接當成已驗證的生產力結果。

轉貼者 Dwayne 對這段說法提出批評,把它形容成主管慶祝沒有被解僱員工之後的效率。這反映社羣如何理解公告,卻不能補上公告沒有提供的財務、員工績效或裁員原因資料。

兩層說法應分開閱讀:原始貼文確認有人員調整與產品規畫,評論則對這種表達方式提出價值判斷。若把評論改寫為「Airtable 已證實 AI 取代員工」,就跨過了現有證據。

公告也沒有提出 AI 使用量與裁員的因果分析,更沒有說每個職位都被哪一個代理取代。即使同一則貼文提到 AI 產品,也只能確認策略並列,不能據此說是 AI 造成所有離職。

對讀者而言,這個區分會影響判斷。如果你關注職場變化,可以追蹤後續人員與組織資料。如果你是付費客戶,則應把注意力轉向交付、支援與可靠性,兩者需要的證據並不相同。

延伸閱讀:Stanford 與倫敦國王學院 41 國研究:導入 AI 的公司多了資深員工,新人真的變少了嗎?

Airtable 官方 Omni 建置應用程式示意
Airtable 官方既有 Omni 示意;並非裁員公告中尚待推出的 Canvas 畫面。 圖片來源:Airtable。

三條產品路線,應各自用不同證據驗收

Core 的承諾是回到用戶最常要求的功能,按月交付。Simionato 宣稱三週已交付三十多項,但沒有在該貼文列出完整變更清單。這個數字要保留為他的說法,不能當作三十多項都經過本站實測。

對既有用戶,功能數量不是最好的驗收指標。假設一個內容團隊最困擾的是資料同步、欄位維護與審核介面,就應確認這些項目是否真的改善,而不是拿與自己無關的小更新累加成效益。

Performance 和 Infra 團隊則要提高資料庫速度,以及記錄、欄位與同步的限制。

這些方向切中資料系統的底層需求,但公告沒有給出新的限制值、完成日期或延遲基準,不能提前寫成容量已增加。

因此可以先留下自己的參照值:打開常用資料庫需要多久、同步何時完成、哪些欄位或記錄限制阻止工作。未來更新發布後,用相同資料與工作條件重看,才能知道公告是否解決實際瓶頸。

第三條是 AI 路線,包括升級版 Omni、Airtable Canvas、更強的 MCP,以及 BYO agents,也就是使用者帶入自己的代理。

公告說即將推出,沒有交代各項的適用方案、介面或完整連接方式。

這意味著團隊不能把尚未公開的 Canvas 能力寫進下個月必須完成的交付承諾。可以預留試用空間,卻要讓主要工作仍有現行工具可執行的路徑,避免把產品路線當成專案依賴。

Omni 與 MCP 已經存在,新路線不是從零開始

Omni 官方說明將它定位為 Airtable 內建的 AI 助理,可協助建置、研究與處理資料。

這證明 Omni 原本就存在,但不能拿現行說明替未發布升級保證功能。

MCP 官方文件則說明,支援 MCP 的外部 AI 工具能連接 Airtable。

MCP 是讓 AI 與外部資料、工具溝通的協定,與在 Airtable 裡使用 Omni 是不同入口。

一個容易混淆的地方是「外部代理」與「把自己的模型金鑰交給 Omni」。

現行 Omni 文件說不支援自帶模型 API 金鑰。公告的 BYO agents 沒有詳細規格,因此不能把它寫成 Omni 已開放自帶金鑰。

兩種入口也有不同使用理由。若工作集中在同一個資料庫內,內建助理可能較容易取得結構脈絡。若團隊已用外部代理串接程式、文件和其他工具,MCP 才是值得評估的連接點。

這不是選哪個名稱比較新,而是選工作開始的位置。假設編輯在 Airtable 追稿,工程師在程式工具處理資料,兩人可能需要不同入口,但仍應對同一份記錄與狀態達成一致。

公告對「更強的 MCP」也沒有列出完整差異。現有連接能力不能算作未來更新的新成果。正式發布時,應對照新增工具、原有限制和權限行為,而不是隻確認連線成功。

代理能做什麼,仍由資料權限決定

官方文件說 Omni 跟隨操作使用者原有的權限,MCP 也遵循 Airtable 的存取權。AI 不是新增一個能跨過權限的身分,而是以已取得的權限幫你進行動作。

這對操作的直接影響是,助理找不到資料時,可能是使用者原本沒有權限。原有權限很大時,助理也可能具備相應的修改能力,連線成功不能等同範圍已縮小。

假設你只要代理整理本週稿件,可以先指定資料庫、表格與目標記錄,再要求只輸出待改清單。這是本文建議的試用情境,並不是官方聲稱每個代理都會自動採取這種工作方式。

若下一步要修改狀態,就把規則寫成可檢查的條件,例如只更新已完成編輯審核的稿件。

不要只說「整理一下」,因為那可能同時意味著改欄位、刪資料或調整結構,團隊難以知道結果是否符合預期。

資料整理也應與通知、同步或自動化執行分開。官方 MCP 說明指出,建立與修改自動化草稿後,啟用仍在 Airtable 介面完成。所以「代理建好」不能直接改寫成「流程已經開始正式運作」。

這個界線有助於團隊分工:代理提供建置成果,負責人檢查觸發條件與作用範圍,再進入實際執行。即使未來新版本更方便,最後仍需要知道哪些行為會影響客戶或同事。

現有用戶,先檢查一條最重要的工作流程

這次公告之後,不必用「留下或離開」當成唯一選擇。若資料庫仍穩定運作,可以先縮小觀察到一條重要流程,把新功能試用與續約判斷分開,避免一次改動整個團隊的工作習慣。

以內容排程為例,先選擇一個資料量適中、可還原的副本,記錄原有欄位、關聯與狀態。測試新功能時,用它處理相同任務,觀察是否少了手動步驟,也確認原本規則沒有被改壞。

若團隊的痛點是效能,就不要以 AI 生成摘要作為主要成效。應觀察常用視圖、同步完成與多人編輯的等待時間。反過來,若痛點是建置速度,才比較建立新流程需要多少人力與修改次數。

這些指標最好包含失敗後的恢復。一次生成成功很有吸引力,但資料欄位改錯時能否找到差異、恢復資料、持續工作,同樣會決定系統是否值得長期使用。

正在評估新平台的團隊則應先盤點遷移成本。表格資料能匯出,不代表關聯、公式、介面、自動化和整合會完整搬走。因此比較方案時,要把重建這些結構的時間一起計算。

公告中的人員調整會讓支援與開發速度成為後續觀察點。可以記下同類問題的回應與修復時間,卻不能在沒有服務中斷證據時,先把裁員推論成產品必然不可靠。

把建置成果與維護責任寫在同一張表

新流程評估還有一個常被忽略的成本:誰維護它。代理可以協助建立介面,但欄位定義、錯誤處理和成員交接仍需要團隊有人負責。若只看第一次完成速度,容易低估後續工作。

例如客服團隊打算新增客訴分類,可以先寫清楚哪些類別可自動判斷、哪些需要人工確認。分類完成後,也要保留原始內容與修正方式,讓後來的人能理解為何某筆資料被歸到這一類。

若每次需求變更都需要從頭生成,最初省下的時間可能又花回去。因此試用時,可以加上一個小型修改:新增狀態、調整一個欄位或替換一條規則,看看同事是否看得懂並能接手。

這套方法也能檢查 Core 與 AI 是否真的相互支持。

基礎元件穩定,代理建置出的流程才比較容易維護。如果兩條路線各自展示,卻不能一起處理日常變更,使用者得到的仍是分散的便利。

管理策略要看結果,也要保留尚未回答的問題

我比較看重這份公告是否讓 Core 和效能重新成為可衡量的交付。

AI 入口變多確實可能讓建置更方便,但如果主要資料庫仍慢、同步仍卡住,使用者不會因為多一個代理就免除原有成本。

小團隊能否更快,取決於分工、產品複雜度、支援負荷與知識交接。公告提供了一個主張,還沒有提供足以比較組織調整前後的資料,因此對管理成效最合理的評價仍是等待結果。

最能改變我的判斷的,是重要用戶需求持續被解決、效能限制有明確改善,以及新 AI 功能公開可用且有清楚規格。單次展示或交付項目數量,還不足以替代這些使用結果。

相反地,如果團隊持續找不到新功能對應的文件,或主要流程修復時間變長,就應重新評估依賴程度。這個判斷建立在服務行為,而不是把社羣對裁員的情緒直接套到產品品質。

延伸閱讀:Anthropic 投入 2 億美元研究 AI 經濟衝擊:五大問題與企業實驗框架

常見問題

Airtable 裁員已經證明 AI 取代人力了嗎?

沒有。原始公告確認團隊縮減,並提出小團隊交付更好的管理主張,卻沒有提供 AI 替代職位或生產力的因果資料。把兩個話題放在一起,不足以證明每項人員變動的原因。

Canvas、BYO agents 和新版 Omni 現在都能用了嗎?

原始公告將這組更新列為即將推出。現有 Omni 與 MCP 有官方說明,但不能把原本存在的功能當成新版已上線。是否能使用,要等對應正式公告與帳戶可用範圍。

現在就應該把所有流程搬離 Airtable 嗎?

若現有流程仍滿足需求,可以先用重要工作與支援表現持續觀察。若限制已經影響交付,則比較替代方案和重建成本。最有用的決策依據是你的依賴與實際瓶頸,不是單一貼文的情緒。

續約之前,可以把觀察交給實際使用資料庫的同事共同填寫。建置者、日常操作人與管理者看到的問題往往不同,納入三者的紀錄,會讓產品承諾更容易對應到真實需求。

從產品承諾,回到每天要做完的工作

Airtable 這次事件值得關注,因為它把組織、人員與 AI 產品路線放到同一張考卷上。使用者能做的,是把各項承諾轉成自己可觀察的工作結果,讓續用或遷移有具體依據。

現階段,我會保留可用的既有流程,為 Core、效能和新 AI 更新設不同觀察點。

等到功能、文件與穩定性真的改變,再調整使用方式,會比提前把 coming soon 當成既成成果更可靠。

若你想持續追蹤 AI 如何進入真實工作系統,歡迎免費訂閱 AI 郵報。

資料來源