飛書項目這次發布，可能被大部分人低估了

飛書項目在SaaS賽道的數據令人震驚，但真正讓行業矚目的卻是其AI生態的高速進化。日均接口調用量一年增長五倍背后，隱藏著一個被多數人忽略的戰略信號：系統的一等公民正在從「人」轉向「人+Agent」。本文深度解析飛書項目如何通過AI Friendly戰略重構研發管理范式，其開源CLI與AAMP協議如何為多Agent協作鋪設基礎設施，以及那些正在主動「蒸餾」自己的PMO們揭示的殘酷進化法則。

先擺幾個數據。

2025年，飛書項目在「軟件研發項目管理SaaS」和「IPD流程數字化SaaS」兩個賽道，市占率分別是46.8%和68.6%，全國雙第一。這個數據是賽迪最新發布的。

但更讓我愣住的不是這個，是另一組。

飛書項目開放平臺上線一年，活躍插件數量翻倍，日均接口調用量從500萬增長到2300萬。一年差不多五倍的量。

這個量級的增長在SaaS行業里是個什么概念？這東西已經不只是一個工具了，它是很多企業每天都在依賴的業務底座。

昨天我在上海參加了飛書項目生態日，聽了一整個下午，腦子里一直在盤一件事。

到底是什么讓飛書項目在這個賽道里跑成了現在這個樣子？然后又憑什么它今天在AI方面還能再往前沖一大截？

聽了半場，我記下了一個詞。

AI Friendly。

這個詞是飛書項目負責人洪濤提出來的，翻譯過來叫「對AI友好」。聽著挺普通對吧？我一開始也沒當回事兒。

但洪濤接著講了一句話，把我聽坐直了。

「過去我們的開放，更多是對人開放。從流程配置的靈活開放，到API接口的豐富開放，再到輕應用前端的全面開放。但今天，當越來越多的使用者變成了AI Agent，平臺還得對AI友好?！?/strong>

這句話我咂摸了一下午。因為它背后藏著一個我們很多人還沒反應過來的事情。

系統的一等公民，正在從「人」擴展到「人+Agent」。

坦率的講，我來之前期望沒那么高。我自己這半年都在做AI Agent落地的事情，踩坑踩到懷疑人生，來這兒最開始就是一個「看看友商在干啥」的吃瓜心態。但聽了洪濤開場那十分鐘，我就知道今天這場會，對在一線做AI落地的人來說，值得認真對待。

我想跟你聊聊，為什么。

洪濤開場講了一段話我覺得是整場最核心的判斷。他說，AI到底給咱們的研發項目管理帶來了什么麻煩？

沒聽錯，是麻煩。

寫代碼、寫文檔、出方案，確實變快了。但單點產出變快，不代表大家配合得更順。干活的節奏越快，信息不同步、流程斷開、責任扯皮的情況，反而會成倍放大。

這時候，如果一個項目管理平臺還停留在「記任務、看狀態」，那就徹底扛不住了。

那解法是什么？

洪濤給的答案只有一句話。「把結構化數據，變成AI的燃料。」

這句話我聽完當場抄在了備忘錄里。

因為它講透了一件事兒。我們很多人討論AI轉型，都在討論模型能力、Prompt技巧、Agent架構。但真正在企業里把AI跑穩的人都知道，AI如果只是一個聊天框，那是玩具。只有當AI真正吃透企業里那些結構化的流程數據，幫你去排期、去暴露風險，它才能解決真實的業務問題。

所以AI時代的研發管理，必須是把開放能力、結構化數據和流程系統，死死地焊在一起。

這一句話，就是AI Friendly戰略的底層邏輯。

好，帶著這個判斷，我再看飛書項目這次發布的東西，突然就看懂了。

先說一個容易被低估的事實。飛書項目的開放，不是今天才開始的。

這事兒其實是飛書項目的基因。去年這個時候他們在北京辦了一場開發者日，當時來了大概一百號人。從那兒之后，開放平臺正式上線，接口、Webhook、輕應用、三方插件體系全開放出去，一年時間跑出來大幾十個優質的解決方案。活躍插件翻倍、日均調用量從500萬漲到2300萬這兩個數據，就是這一年開放的果實。

但你注意洪濤在開場講的另一句話，他說，開放平臺發布一年，數字增長以外更重要的是質變。

什么質變？

是越來越多的插件和解決方案，開始嘗試「AI × 飛書項目」。

這句話翻譯過來是，過去一年開放平臺承接的是「人的開發者」做出來的工具；往后開放平臺要承接的，是「AI的開發者」以及「人+AI一起開發出來的工具」。

這就是為什么今年活動從「開發者日」變成了「生態日」。

一字之差，里面的東西全變了。

因為「開發者」這個詞的含義正在被重新定義。以前開發者是程序員。今天一個懂業務的PMO配一套AI Coding工具就是開發者，一個一線產品經理用自然語言生成插件也是開發者。當開發者的邊界開始模糊，開發者日這個名字就自然不夠用了。

洪濤在開場還定義了一下什么叫生態。他說生態不是人多熱鬧，生態的標志是三件事。第一，平臺上開始長出真實的業務作品。第二，不同的角色開始圍繞同一個底座一起干活。第三，也是最實在的，伙伴們開始在這里獲得客戶、獲得收入、獲得持續投入的理由。

這三條放在一起，就是「生態日」這個名字的全部含義。

從「人的開發者」擴展到「AI參與的生態」，這是飛書項目今年判斷的起點。

而AI Friendly這個戰略，就是為了把這件事接住。

好，說回產品本身。

飛書項目這次發布的那張主架構圖，我在現場拍下來了，回家之后看了好幾遍。整個圖分三層。

第一層叫 AI 連接 Connection，里面有 MCP 升級、飛書項目 CLI、AI Coding 開發套件。第二層叫 AI 應用 Application，里面有 AI 節點、AI 字段。第三層叫 AI 助手 Agent，里面有飛書項目 AI 助手和 AAMP 協議。

發布會上一個叫楊澍的開放平臺負責人花了快一小時講這三層，我一開始以為就是常規產品更新，聽到后面越聽越覺得不對勁。

這三層對應的其實是一個AI Agent在業務系統里生存的三個階段。

Agent能不能進來。Agent怎么工作。Agent和其他Agent怎么協作。

這三個問題的答案，決定了一個SaaS平臺未來三年還有沒有戲。

先說第一層，Agent怎么進來。

這層升級最讓我眼前一亮的不是MCP，而是那個 CLI。

我跟你說，我自己做多Agent系統踩過的坑，跟這個完全對得上。MCP當然是好東西，飛書項目的MCP這次也升級到了市面上功能最全的項目管理MCP，覆蓋40多個工具，首家支持OAuth這種更安全的授權方式，現在已經有接近500家租戶在高頻使用，月活用戶6000多，每周調用次數超過150萬次。

但MCP有一個結構性的問題。在中大型項目里，你的tool數量一多，上下文窗口就會被吃光，AI開始出現幻覺、調用超時、邏輯混亂。這不是MCP的錯，是當初設計MCP的人沒預料到項目管理這種場景的復雜度。

CLI這東西的價值在哪呢？

它是漸進式披露的。AI想調用某個能力，先搜索命令，再讀那個命令的幫助文檔，最后執行。它不用一次性把所有能力塞進上下文。就像你去一個圖書館，不是一進門把所有書的目錄都背下來再說，而是查索引、找到相關那本再翻。

這種設計對大模型有三個直接好處。更穩定、更省token、效果更好。

現場那個演示我當時看完就想起我自己做的事情。我們之前糾結過很久到底用MCP還是自己搭 Function Calling。飛書項目給的答案是，兩個都要，但針對不同的場景。

順手講一下這個CLI里最讓我佩服的一個設計。它內置了SKILL，而且是自動發現機制。AI用戶不需要手動找文檔，CLI在啟動時就會告訴AI「你這個場景應該用這個skill」。

這是一個很小的細節，但它背后是對Agent工作流特別深的理解。你去看所有搞Agent的人，都在吭哧吭哧寫System Prompt、寫工具說明。飛書項目把這一套沉淀到CLI里，對接入方來說就是一個命令行的事。

更關鍵的是，飛書項目CLI是開源的。

開源這件事在今天的AI時代，已經不是一個錦上添花的選項，它是一個分水嶺。你不開源，Agent開發者不信你。你開源，整個生態才能真正長起來。

飛書項目選了更難的那條路。

第一層還有一個即將上線的東西叫 AI Coding 開發套件。簡單講就是自然語言生成插件和AI應用，一句話讓AI幫你從零到一做一個飛書項目插件，甚至能自主上架。

這東西意味著什么？

以后在飛書項目生態里開發插件，不再是程序員的專利。這正是洪濤一開始說的那句話的落地。

AI正在重塑「開發者」的邊界。

第二層，AI 應用。這一層飛書項目發了兩個東西，AI 節點和 AI 字段。

AI節點很好理解，就是把一個AI應用（比如一個Code Agent、一個Test Agent）嵌入到項目流程里，當流程走到某一步，這個AI節點就自動觸發。聽起來很普通對吧？

但你得跟傳統的工作流產品對比一下。傳統的工作流，流轉到某一步你是等人來處理的?，F在這一步可以是AI處理，處理完直接把結果寫回項目實例。這就是把「人做的事情」和「AI做的事情」放在同一個流程圖里了。

AI節點還有一個挺妙的設計。它首次取消了「要用開放能力必須管理員先安裝」的限制。以前一個插件要用起來，管理員得先一個一個空間去配?，F在節點負責人自己就能把他負責的節點轉成AI節點，讓AI接管。這在大組織里是一個很大的解綁。

AI 字段這個設計我覺得更妙。

傳統的飛書項目，你的一個字段是文本、數字、日期、下拉選項這種固定的結構化數據類型?，F在多了一個字段類型叫「AI字段」。這一列每一個單元格在生成的時候都會調用一個AI應用。

舉個例子。你做招聘管理，每條記錄是一份簡歷，以前你要手動打分，現在加一個「AI評分」字段，每條簡歷自動觸發打分邏輯。你做一個需求池，每條需求加一個「AI分類打標」字段，每條需求自動貼標簽。

這次AI字段還升級了一個叫「快速創建」的模式。用戶可以把自己調得好用的指令，直接包裝成一個帶變量輸入的模板，在市場上架，給其他同學復用。同事只需要選配一下變量對應的字段就行。

這個設計真的太懂中國企業了。

你想想以前在企業里搞AI落地最痛的是什么？不是做不出來，是別人用不起來。好不容易調出一個精準的Prompt，想讓同事也用，得發內部文檔、開會講解、一個個教。有任何微調，還得挨個通知。

現在AI字段把這事兒給解了。調得好用的直接上架模板，整個組織都能用起來，有微調還能自動生效。這就是把個人的AI最佳實踐，變成了組織的AI資產。

這一層發布完之后我才反應過來飛書項目在走的路線。

先把底層的「AI連接」做到極致，讓Agent能順暢進來。再用「AI應用」把Agent能力下沉到業務場景里，讓普通用戶人人可用。最后用「AI助手」把整個東西封裝成開箱即用的產品。

層層遞進，自下而上。這是一個懂AI的團隊才會做的產品路徑。

第三層，AI 助手加AAMP協議。

這是我今天覺得最被低估的東西。

AAMP全稱叫 Agent Asynchronous Messaging Protocol。直譯是智能體異步通信協議。

你聽到這個名字第一反應可能是，誒這不就是一個協議嗎，協議嘛，又發不出什么新玩意兒。

我一開始也是這個反應。聽完之后我直接改變看法。

事情是這樣的。你現在想象一個場景。你作為一個員工，你有自己的AI助手（比如你裝了OpenClaw本地版）。你的公司有自己的AI助手（比如飛書項目AI助手）。這兩個AI助手現在要協作完成一個任務。

怎么協作？

傳統的做法是，你的AI助手調用公司AI助手的API。但這里有一個大問題。你的AI助手跑在你本地（可能是你的筆記本，可能是一個NAT后面的內網環境），公司AI助手不能主動來找你。你的AI助手要不停地去輪詢，才能知道公司那邊有沒有給你派活。

AAMP解決的就是這個事兒。它是一個雙向異步通信協議，支持本地Agent在NAT、防火墻限制下也能被遠端Agent找到。

你聽著是不是還是覺得很技術很無聊？

那我換個說法。

互聯網剛誕生的時候，人和人之間怎么協作？靠email。洪濤在開場講過這個比喻，email不性感吧，但沒有email，全球化辦公就別做了。

AAMP就是給Agent配的email。

沒有這個協議，Agent只能在同一個平臺里玩。有了這個協議，你的Agent和我的Agent和她的Agent可以異步通信，互相委托任務，互相協作，即使來自不同團隊、跑在不同機器上。

現場一個叫嘉碩的工程師演示了這個，我看完當場愣住了。

一個市場部同學在飛書項目里輸入一句話「幫我開發一個倒計時組件」，這個需求通過AAMP協議發到了一個本地Agent的郵箱里。本地Agent收到之后調用命令行工具開始開發，開發完回傳結果，插件自動上架。

整個過程，市場部同學什么代碼都不懂，什么部署都不會，他只需要說人話。

這個演示看著還有點卡頓，協議速度不是完美的。但我當場就判斷，這事兒的方向對得不能再對了。

因為它解決的是一個所有搞多Agent協作的人都繞不開的問題，Agent的身份邊界和通信通道。

這東西關鍵還開源。

AAMP是開源協議，意味著它不是飛書項目一家的東西，任何平臺任何智能體只要遵循這個協議，都能互相通信。飛書項目主動把主動權讓出去了。

這個動作在SaaS行業里是很少見的。大部分公司在這種關鍵基礎設施上，第一反應是建圍墻，讓用戶鎖死在自己的生態里。飛書項目反過來，主動降低自己的護城河，去建一條所有人都能用的高速公路。

這是一個有點反直覺但方向完全正確的選擇。因為在Agent時代，誰先把標準定下來，誰就贏了生態。

講到這兒，我想講講下午的另一場分享。

下午有一場叫「AI+項目管理一線落地實踐」的分享環節，50分鐘時間，六位一線PMO輪番上，每人八分鐘。這種短平快的環節特別見功力，水的人兩分鐘就被看穿。

第一個上來的是唱吧的PM張楚楚。她講了一個事兒。她們設計團隊以前一個月要出幾百個物料，每個都得手動調用一堆AI工具?，F在她們在飛書項目里搭了一個智能體，設計師只做最后的審核，一句話的需求進去，圖就出來了。

但讓我記下來的不是這個場景，是她在分享最后講的一段話。

她說，現在網上有個詞叫「把同事蒸餾成skill」，聽著挺殘酷。她的原話是這樣的。

「這就是一個蒸餾過程，但你又不得不去做。因為你不蒸餾別人，別人也會蒸餾你?！?br/>

我聽完當場愣住了。

這句話的殺傷力在于，它直接戳破了AI時代最大的一個幻覺。很多人還在討論AI會不會取代我，但真正在一線的人已經不再討論這個問題了。他們討論的是，我要在被取代之前，先把自己的經驗沉淀成可以被他人調用的能力。

張楚楚后來補了一句更狠的。

「我抱著未來公司可以不用項目管理的心態去做很多事情。我列了項目管理日常在做的所有事情，把可AI化的做了標注，把已AI化的也做了標注?！?/p>

一個項目經理，在系統性地把自己做的事情AI化。

她在主動地蒸餾自己。

這不是被動應對AI時代，這是在成為這個時代的原生物種。

真正讓我坐直的是另一個分享的人，字節剪映的楊淼。他上來分享的是一個K8S海外機房容災的項目，要跟60多個中臺、300多個外部服務去確認容災能力。每周老板問他「哪些ready了、哪些有風險、誰沒進展」，他得在各個部門群里挨個艾特，搜集，整理。

這種活兒最容易想的就是，直接讓AI幫我總結群聊。

他一開始也這么干的。然后拿到的是什么呢？是「XX中臺表示資源緊張正在評估方案」、「語音中臺正在和項目組溝通資源缺口」這種summary。

這種總結回答不了任何問題。你要知道的是哪些需要你今天去復試，哪些需要上升到老板。前面這些回答全是廢話。

然后他做了一個我覺得特別對的事情。

他把「讓AI做什么」重新設計了一遍。AI不去自由判斷，AI帶著問題去采集。他提前寫好一個樣文件，把要回答的三個問題作為固定字段，讓大模型在采集的時候必須填這些格子。大模型只做中間一段「語義歸一化」，前后的采集和分析都用代碼處理。

他講到這兒的時候我就在想，這哥們是真懂工程的人。

因為市面上95%的人討論AI Agent，都在討論模型能力、prompt技巧、工具調用。但真正把Agent跑穩的人都知道，中間這一段的自由發揮越少越好，前后的確定性代碼越多越好。

楊淼最后的個人思考是這樣一句話。

「新時代PMO的角色，是壓縮組織里面的摩擦。」

這句話我當場記下來了。

接著上來的是字節中國交易與廣告的鄭宇。他講了一個特別聰明的框架。他把工作按照《高效能人士的七個習慣》分成四象限，然后說AI的價值不是幫你做第一象限（緊急重要）的事，而是讓你從第三第四象限（不重要的事）里解放出來，把精力回流到第二象限（不緊急但重要）的長期投入。

他講完之后有人問他幻覺問題怎么解決，他給的答案我覺得是全場最珍貴的一句話。

「AI是被關在小屋子里的人，他的能力就是做詞語接龍?？刂粕舷挛牡钠?，做分治。單團隊單指標的內容，AI能百分百不出幻覺。然后在這個前提下，建立工程循環調用它?！?/p>

這句話如果你是做LLM應用的，應該會跟我一樣會心一笑。

好，聽完這幾個分享，我心里已經有一個判斷了。

現在所有真正在一線把AI用起來的人，方法論都在往同一個方向收斂。

都在做一件事兒，把AI的自由度向下壓，把周圍的上下文和流程向上拉。

這個判斷有了之后，我再回頭看飛書項目上午發布的那一整套東西，突然就全連上了。

它在修路。

它修的是一條讓Agent能穩穩跑在真實業務流程里的路。而一線PMO們搭 harness、搭AI評審、搭個人智能體，做的是在路上跑自己的車。兩邊是一回事，只是分工不同。

講完自己用的，我想講講生態伙伴是怎么用的。這塊我覺得是整場活動信息密度最高、也最能說明問題的部分。

第一個要講的是雅迪。

雅迪是電動兩輪車行業的龍頭，一年要發幾十款新品。整車研發是個很復雜的東西，他們依托飛書項目落地了IPD（集成產品開發）和IPMS（集成產品市場營銷）兩套流程體系。

效果是什么？

新車開發周期縮短了兩個月，產品上市準確性提升了20%。這兩個數據不是PPT吹的，是現場雅迪研發數字化負責人陳曦親口講的。

更厲害的是他們基于飛書項目的開放接口和底層數據，自己做了一個「AI項目副駕」，嵌到整車研發流程里。自動生成周報月報、智能查詢歷史項目經驗、AI會議質檢，都做進去了。

但他們做得最有意思的一個東西，是「龍蝦團」智能預評審。

我第一次聽這個名字的時候以為是某種茶歇。陳曦在臺上講完我才反應過來，這是一群AI智能體。

場景是這樣的。電動車項目每個評審節點之前，以前是把所有干系人叫到一個會議室，市場、工程、成本、法規、外觀各方挨個提意見，然后再回去改，再開評審會。一個來回就是一兩周。

現在雅迪在正式評審之前，先放一群AI智能體來預評審。讓AI分別扮演市場、工程、成本等不同角色來挑刺兒。相當于正式過堂前，先讓這群AI幫你交叉把關。

我聽完心想，這個設計太漂亮了。

它解決的不是「AI能不能做評審」這個問題，而是「AI能不能幫人把評審這件事情做到不返工」這個更高維的問題。人還是最終決策者，但AI接管了前面最耗時、最容易忽略細節的交叉把關環節。

最后的效果是什么？資源浪費減少20%，重復工時減少30%。

你想想這是個什么量級的事情。一家制造業龍頭，不是買了一個SaaS產品用，而是把SaaS產品當底座，在上面長出一群屬于自己業務的智能體。

這種用法只有底座真的開放、真的AI友好，才能跑得起來。

陳曦在圓桌上講了一句話特別打動我。她說，在制造業讓AI落地，必須平衡AI的發散性和兩輪車研發的絕對嚴謹之間的張力。她給出的秘訣是三句話。

「科學的數據模型是AI的地基，知識沉淀是AI的養料，而守門人機制是AI的安全閥。三者缺一不可?！?/p>

我覺得這一句話夠所有做AI落地的企業抄進PPT里用三年。

第二個是輕舟智航，智能駕駛公司。他們面對上千條項目需求，完全靠人工對齊鏈路成本極高。借助飛書項目，他們落地了ASPICE（汽車行業的標準流程）。

然后干了一件我覺得特別漂亮的事兒。

路測問題100%自動創建。

場景是這樣的。工程師在路上測車，遇到問題直接語音記錄，回收之后系統自動分類打標，結合規則和歷史數據推送給對應的責任人。整個「記錄—分診—分派—閉環」打成了一條自動化流水線。

輕舟智航項目交付負責人劉宇在圓桌上講了一句話。

「先把鏈路跑順，AI才有抓手。鏈路順了，人才能把精力放回判斷和解決問題上?！?/p>

這句話我建議你多讀兩遍。

因為它其實是在說，在AI真正發揮價值之前，你得先有一個能夠承載Agent的業務底座。Agent不能憑空跑，它得跑在一條結構化的、可追溯的、權限清晰的流水線上。

飛書項目做的事情，就是那條流水線。

第三個是爪印工作室，做游戲的。游戲研發有一個眾所周知的痛點，內容修改牽一發而動全身。

他們形容自己的業務是「小瀑布，大敏捷」。重資產內容生產必須按工序走瀑布，但玩法和版本又要求敏捷到「今天決定、明天驗證」。

這兩個東西放在同一條流水線上是反直覺的。

爪印的解法是什么呢？依托飛書項目的輕應用能力，他們自研了一個叫 FlowStack 的「流程資產倉庫」，把研發節點和流程模板全部資產化，現在已經沉淀了200多個標準節點、50余項流程模板。

結合輕應用和AI Coding，他們做出來一個什么效果呢？

一個像FlowStack這種量級的產品，從管理思路到落地可用的系統，只需要2天。

爪印項目管理負責人繆克講了一句話。

「讓創造舉重若輕，不是把流程做沒，而是把復雜流程變成可以被表達、被復用、被治理的東西?！?/p>

繆克在圓桌上還給出了一個我覺得特別準的判斷。他說，AI時代項目管理的終極形態是什么？

「人做判斷，AI做推演；人抓創意與取舍，系統把重活搬走?！?/p>

這句話跟雅迪陳曦那個「守門人機制」其實講的是同一件事。

無論什么行業，讓AI落地的底層邏輯都是把「人和AI的分工」重新設計一遍，而不是直接讓AI全盤接手。

講完三家客戶，再講兩家ISV。

詞元無限，一家做AI Agent技術的公司。他們基于飛書項目的AI節點，把技術方案生成、智能編碼、智能測試三個環節封裝到項目流程里。

這是他們演示的一個完整場景。

以前一個中等復雜度的需求，從PRD評審到開發到測試，要跑7到10人天。現在跑完全流程是多少？

1到2人天。

這個壓縮比不是簡單的提效，它是研發流程的范式變化。

拆開看，每個環節都是AI在工作。PRD理解和技術方案生成由一個Agent做，原本2-3人天壓縮到0.5人天。開發環節Agent拆解任務，Coding Agent并行執行，原本3-5人天壓縮到1人天。測試環節Testing Agent接管，原本1-2人天壓縮到0.5人天。

三個Agent串起來，人只做review和關鍵決策。

詞元無限的創始人王磊在臺上講了一句話我印象很深。

「企業真正缺的，不是一個更強的Coding Agent，而是一條能把Agent產出穩定變成交付結果的流程閉環。」

這句話跟洪濤開場講的「把結構化數據變成AI燃料」是同一件事，從另一個角度講出來了。

順便說一下，詞元無限的Coding Agent在SWE-bench和MONKEY-bench上拿過全球第一，尤其是C++和Java這兩個企業最主流的編程領域，雙榜登頂。這個數據不是吹的，是公開榜單。

第二個是Zadig，一家云原生DevOps平臺公司。他們做的事情更有意思，把飛書項目的「管理域」和代碼倉庫的「工程域」打通了。開發者在飛書項目里提交代碼變更，測試工作流自動觸發，結果實時回傳。到發布環節，AI先做發布風險檢測，再走飛書審批，通過后自動執行。

一個平臺完成「從想法到執行」的完整閉環。

最后的效果是發布效率提升3倍，交付周期縮短35%，故障恢復時間降低50%。

Zadig的創始人李倩現場講了一個讓我特別觸動的事。她說發布這件事在嚴肅場景下，是關乎生死的事情。比如數字貨幣交易所，一次發布延遲可能意味著上千萬交易被阻塞。比如車企充電業務，一次發布遺漏某個依賴項，可能導致充電樁幾十分鐘無法使用。

這種級別的發布決策，不只是流程自動化的問題，它需要AI能真正介入風險判斷。

Zadig做了一個叫「AI發布風險檢測」的東西，把飛書項目的需求數據，和Zadig的全鏈路工程數據打通。當你點擊發布的那一刻，AI會匯總所有的需求改動、關聯服務、代碼掃描結果、運行時健康等信息，自動給出發布風險結論。

李倩講了一句話我覺得特別能代表這一類工具的價值。

「不是出了問題再報警，是提前告訴你，這次發布有風險?！?/p>

這種事要做到，必須依托一個足夠開放、足夠可控的底座。

還有一家我想順手提一下的ISV叫高遠，一家做汽車行業解決方案的公司。他們基于飛書項目做了一個專門針對汽車行業的ASPICE插件，過去一年拿下15家大型智能汽車企業客戶，在國內智能駕駛TOP 20公司中覆蓋率已經很高了。

這家公司給我的啟發是，在飛書項目這個底座上，甚至可以長出專門服務某個垂直行業的解決方案。這就是生態能力的真正體現，不是通用工具堆功能，而是底座足夠開放、足夠AI友好，讓懂行業的團隊能做出行業最懂的東西。

講了這么多生態案例，我想說一個共同點。

這些客戶和ISV有大有小、行業各異，但他們選飛書項目的原因出奇地一致。

底座夠開放。夠AI友好。權限模型夠安全。數據模型夠結構化。

這幾個詞翻譯過來其實就是一句話，飛書項目是一個能讓Agent真正跑得動的平臺。

這句話說起來簡單，做起來極難。國內真正做到這一點的項目管理SaaS，目前屈指可數。

這也是我開頭講的那個數據的答案。

飛書項目為什么在兩個賽道都能拿下全國第一？

因為它的開放基因比行業走得早、走得深。早到去年的開發者日就已經把API、Webhook、輕應用全開放出去；深到今年的生態日把開放從「對人」擴展到「對AI」，把MCP、CLI、AAMP協議全部開源出去。

這種級別的開放能力，加上制造業、汽車、游戲、互聯網等各行業頭部客戶沉淀下來的業務流程，構成了一個其他玩家一時半會兒追不上的護城河。

再拉開一點時代視角來看這件事。

IDC去年有一組預測數據，到2029年，能有效衡量人機協作的企業，利潤率將比僅關注生產效率的企業高出15%。到2030年，70%的開發者將與自主AI智能體協作，他們的角色會從「親自執行」轉向「規劃與設計」。

Gartner那邊也給了一組數據，到2027年，75%的企業將在知識管理中采用AI增強技術，使知識檢索和應用效率平均提升40%。

還有一組更直接的數字。全球范圍內，超半數項目應用AI的組織數量，在過去一年激增了86%。

這三組數據放在一起告訴你一件事。AI Native的項目管理范式不是一個「未來可能發生的事」，它是一個「正在發生、且加速發生的事」。

在這個時代窗口里，誰先把底座做好，誰就接住了接下來五年的企業數字化轉型浪潮。

回到文章開頭那個問題。

AI Friendly這個戰略的真正含義是什么？

表面上看，它是一套新的產品能力。MCP升級、CLI、AI節點、AI字段、AI助手、AAMP協議。每一個拎出來都是實打實的工程成果。

但再往下一層看，它是一次哲學層面的重構。

系統的一等公民，正在從「人」擴展到「人+Agent」。

以前所有SaaS平臺的設計，權限系統、數據模型、UI交互，都是圍繞「人怎么用」來設計的。Agent只是一個工具、一個插件、一個按鈕。

現在飛書項目做的事情，是在重新設計平臺的公民體系。Agent不再是一個被動工具，它是一個有身份、有權限、有通信通道、可以和人、和其他Agent異步協作的一等公民。

這種級別的重構，大部分人會低估它。因為它不性感。MCP升級、CLI發布、AAMP協議，聽起來都是技術細節，沒有「XXX模型吊打GPT」那種爆款敘事。

但做過系統的人都知道，決定一個系統能走多遠的，從來不是最閃亮的那一層，而是最下面那幾層管道。

飛書項目這次干的事情，是在修Agent時代的高速公路。

等高速公路修好了，所有在上面跑的人，速度都會跟著起來。

生態日、AI Friendly、開源協議，這三件事連在一起看，其實講的是同一個故事。

飛書項目在用自己的方式告訴整個行業，在Agent時代，項目管理平臺的角色正在發生根本性變化。從一個「記錄與跟蹤」的工具，變成一個「人+Agent協同的行動系統」。

這件事做成了，不只是飛書項目贏，是整個國內的AI+項目管理生態跟著一起贏。

而現在從市占率、從生態增長、從產品節奏、從開源策略任何一個維度看，飛書項目目前都是國內跑得最快的那一個。

我昨天回來之后打開筆記本，對著飛書項目發布的那張三層架構圖看了半天。有幾個事情我當場就決定要回去重做。

這場會對我個人的價值，遠遠超過一次活動體驗。

最后我想把唱吧那位張楚楚的話再引一遍。

「你不蒸餾別人，別人也會蒸餾你?！?/p>

這句話放在今天任何一個想把AI用起來的人面前，都是一面鏡子。

大時代啊，朋友們。

本文由 @鳴老師 原創發布于人人都是產品經理。未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議