AI 時代，一些大型企業里跨部門、多階段的項目運作方式正在發生變化。那些過去需要人肉串聯的環節，正在被廣泛應用的各類 AI Agent 逐步接管；而 AI 不再只是外掛在實際執行之外的工具，它像員工一樣參與企業的項目，甚至可以被沉澱為組織的 SOP。
這個判斷不是感性的想像。根據管理協會 PMI（中國）發布的《2026 中國研發項目管理數字化洞察》，全球範圍內超半數應用 AI 的組織數量激增 86%；IDC 的預測更清晰：到 2030 年，70% 的開發者將與自主 AI 智能體協作，他們的角色會從「親自執行」轉向「規劃與設計」。
這也意味著 AI 要真正落地到業務流程里，需要的不只是一個更聰明的工具，而是一個能讓 AI、人、流程、數據都順暢連接起來的平台。所以當我們在 AI 時代背景下重新審視項目管理這件事，討論的焦點可能不再是哪款工具「更好用」，而是它的創造邊界和開放生態有多大。
作為一個極具關注度和潛力的項目管理平台，今年飛書項目把活動的名稱從「開發者日」改成了「生態日」，除了呼應這些洞察，飛書項目負責人洪濤也在現場給出了三個直抵本質的原因：首先是生態夥伴們渴望直接連接客戶的真實訴求；其次是飛書項目確信，只有把客戶、夥伴和平台拉到一起，才能長出真正解決業務深水區難題、有生命力的好方案；而最深刻的變化在於——AI 正在重塑「開發者」的邊界。
這是一個極具關注度和潛力的觀察窗口。但在走進這次活動之前，我們得先回答一個更基礎的問題：一個項目管理工具，憑什麼能暢談「生態」?
一個從真實用戶里生長出來的產品
飛書項目不是新產品。到今天，飛書項目已經服務了數千家客戶，覆蓋遊戲、汽車、銷售、工單、運營等多種複雜行業和業務場景。根據 2026 年賽迪報告，2025 年銷量前十的新能源乘用車品牌里有七家在用飛書項目；飛書項目在軟體研發 SaaS 市場占比 46.8%、IPD SaaS 市場占比 68.6%，均為行業第一。
飛書項目的起點，是一群人自己的痛
飛書項目最早孵化自抖音的研發團隊。2018 年前後，抖音團隊已經突破千人規模，用的項目管理工具越來越多，但這些工具之間不互通——資訊同步靠人傳、流程對齊靠開會。作為被協作成本拖慢的團隊，他們決定自己動手解決問題。於是飛書項目問世——代號「Meego」，最初只有一套表格加一套流程圖，專門用來消化抖音內部的複雜協同。
國內大多數 to B 產品的故事是調研了行業痛點、設計解決方案、並推向市場——這通常是一種外部視角。飛書項目的故事則與之相反：我們自己就是那個被痛點折磨的團隊，先為自己造了一個工具，充分驗證其能力後才把它分享給了別人。
這個起點決定了它之後的演化。2021 年正式商業化之前，飛書項目已經在字節內部被反覆打磨了三年——抖音、今日頭條、剪映、飛書、火山引擎……每一條業務線的流程邏輯都不一樣，每一種複雜度都被這個產品吃下過一輪。三年下來，它積累的不是某個行業的方法論，而是應對「業務複雜性」的解決思路。這也解釋了為什麼一個起源於網際網路的工具，後來能在製造業、汽車、遊戲這些完全不同的行業都跑得通。
商業化之後，打造開放平台成了飛書項目的重點工作，「飛書項目開放平台」隨之上線，汽車供應鏈、通用軟體開發等專業領域的解決方案也由 ISV 夥伴相繼落地——平台不再是自己做所有方案，而是讓生態夥伴一起參與。
今年，基於已形成的功能和用戶生態，飛書項目將全力圍繞 AI 進一步升級——把核心 AI 能力融合到管理鏈路中，並連同客戶、ISV、Makers 共同打造實用工具，讓 AI 成為生態共建的底層基建。這就是今天 Build 2026 生態日要回答的問題：開放生態是如何讓 AI 真正落地到組織流程、業務場景中去，並激發每一個人的創造力。
八年，三步棋——做深行業、打開平台、培育生態。我不認為這條路徑是臨時起意的方向調整，它更像是一個從真實用戶里創造的產品，自然生長到這個階段的動作。
飛書項目何以談「生態」
「生態」在 to B 語境裡被濫用得厲害——很多平台說「我們是一個生態」，其實只是「我們有幾個合作夥伴」。如果把這個詞的門檻拉高一點，一個真正的生態至少要滿足三個條件：
1. 不是平台方一個人做事，而是多方共建；
2. 參與的角色足夠多元，不只是單一類型的用戶；
3. 可以打造出平台自己都想像不到的產品。
按這個標準去看飛書項目，它「談生態」的底氣其實不在對行業的深刻洞察，而在它已經花了一整年時間，在飛書項目開放平台上實打實驗證過這件事。從 ISV 夥伴到大型企業，從嚴苛合規行業到個體創造者，過去這一年裡，飛書項目給出了極為亮眼的成績。
是工具，也是機遇
過去一年，飛書項目不僅讓無數企業用戶獲益，其開放平台也吸引了一批深度共建的 ISV 夥伴——其中做得最具有代表性的兩家，是 Zadig 和詞元無限。
作為國內開源 DevOps 領域的代表之一，Zadig 和飛書項目合作的出發點很直接：項目管理平台和 DevOps 工具之間，長期存在一道牆——前者管「規劃」，後者管「執行」，兩邊各自為戰，變更一發生就要在多個系統里手動同步。
Zadig 基於飛書項目開放平台做了一個叫「Zadig DevOps+ 插件」的方案，把兩邊打通：開發在飛書項目里提交變更資訊，測試工作流由 Zadig 自動執行，執行結果實時回傳到飛書項目的任務里；到發布環節，系統先跑一遍 AI 發布風險檢測，然後走飛書審批，通過後自動執行。整個過程不需要切系統，執行即同步，審批則發布，一個平台從想法到幹活全搞定。
這套方案的效果是可以被量化的——發布效率提升 3 倍，交付周期縮短 35%，故障恢復時間降低 50%。馭勢科技用這套方案，把客戶交付周期從 4 天直接縮短為 3 小時；海大集團在容器化轉型中，藉助統一的工作流和環境模板，整體交付效率提升了 25%。目前方案已經在車企、新消費、政企等多個行業廣泛落地。
發布階段，審批即發布
詞元無限走的是另一條路線——它解決的是如何讓 AI Agent 真正接管研發流程。它構建了一套面向企業級軟體研發的端到端智能解決方案：AI 理解需求、生成技術方案、拆解開發任務、調用 Coding Agent 執行、接管測試用例的生成和執行——原本需要 7-10 人/天的研發周期，被壓縮到了 1-2 人/天。他們在實踐中得出的一個核心結論是：企業缺的不是更強的 Coding Agent，而是一條能把 Agent 產出穩定轉化為交付結果的流程閉環。 Agent 不能只是游離在流程外的效率工具，它必須深度融入業務流程，成為真正參與工作、輸出確定性結果的 「數字員工」。
因地制宜，全行業都可用
如果說 Zadig 和詞元無限從技術側驗證了飛書項目開放平台的可能性，那雅迪科技集團證明的是大型製造企業同樣能在這個平台上「長」出自己的方案。
雅迪科技集團落地了雙流程體系後，就在飛書項目上快速實現了數字化運轉——研發走 IPD、營銷走 IPMS，兩條流程在飛書項目上通過跨空間關聯能力實現關鍵節點的「握手」，真正做到了「開發一變，上市方案立刻同步」。光這一項改造，就幫雅迪科技集團把全新車型的開發周期縮短了 2 個月，產品上市時間準確性提升 20%。
飛書項目中實現 AI 自動巡檢
更有意思的是後來發生的事情——雅迪科技集團的團隊沒有滿足於只是把流程搬上飛書項目。他們基於飛書項目的開放接口、飛書 aily 和 MCP 能力，自己打造了一套「IPD 智能項目助手」：
自動生成周報月報：AI 自動拉取項目進度和風險，準時推給管理層，項目經理節省下的 2 小時用來做真正有價值的事；
智能查詢歷史項目經驗：把 6 年積累的研發質量問題清單和解決方案全部結構化沉澱到知識庫里。工程師問 AI「上一代冠能系列的車架如何進一步優化升級」，系統 5 秒給出帶原始文檔鏈接的答案；
AI會議質檢：飛書項目和飛書會議深度集成，AI 自動提煉決策會議里的評審要素，待辦事項直接生成任務，讓會議告別「議而不決」；
「龍蝦團」智能預評審：正式評審前，讓一群 AI 智能體分別扮演市場、工程、成本等不同角色來「挑刺」，大幅提升整體效率。
這套 AI 項目給雅迪科技集團帶來的結果是：減少 20% 的資源浪費，節省 30% 的重複性工作工時。
而除了這些傳統的製造企業，如今最被我們熟知的自動駕駛行業也有自己的煩惱。他們一直面對著很特殊的雙重壓力：既要像網際網路一樣快速疊代，又要通過 ASPICE 這類嚴苛的合規標準。這兩件事本身是有矛盾的——快速疊代意味著變更多、版本多，但合規要求每一次變更都必須有完整的記錄、追溯和驗證鏈路。
飛書項目內置的 AI 個人周報
過去這種矛盾的解決方式就是靠人扛——團隊的大量精力被合規流程消耗，創造性的判斷反而沒時間做。而藉助飛書項目，輕舟智航的解法是：把合規要求做成流程的「默認動作」。
他們做了一條順滑的流水線：測試同學在車上發現問題，用語音先記下來；系統自動做初步分類打標；結合規則和歷史，把問題自動推給對應責任人——合規不再是「人追著流程跑」，而是「系統推著流程走」。
在需求追溯這種更複雜的場景里，輕舟智航採取的是「AI + 人」的人機協同策略：AI 先用標籤把候選池子縮小，再做語義匹配，把需求和測試用例儘可能串起來，最後由人工審核驗收。輕舟智航負責項目交付的劉宇認為：AI 把鏈路里最費時、最容易錯的部分拿走，讓人回到真正需要專業判斷的地方。用流程內的 AI 節點，無縫連接過去極度依賴人工推進的業務斷點後，平台將徹底告別單一的「過程管理」，開始承載執行與交付閉環，真正演進為「智能交付平台」。
靈動高效，釋放快節奏行業的敏捷勢能
如果說上述案例證明了飛書項目能夠撐起汽車與製造行業極其複雜的研發協同與嚴苛合規，那麼接下來的案例則展示了它在另一個維度的生態張力：不僅是重資產的實體產研，面對高敏捷、快疊代的網際網路及遊戲企業，飛書項目的底層能力同樣能生長出完全契合業務心跳的專屬解法。
爪印工作室做的是遊戲研發。遊戲行業有個特殊的節奏：小瀑布，大敏捷，即重資產內容——角色建模、劇情、動畫——生產必須按工序走瀑布，但玩法和版本又要敏捷到「今天決定、明天驗證」。傳統的項目管理工具要麼太敏捷、要麼太瀑布，爪印想要的是一套自己的流程結構。
爪印工作室 FlowStack
他們沒有另起爐灶搭系統，先搭建了一個叫 FlowStack 的「流程資產倉庫」後，再連接飛書項目的輕應用能力，對不同類型需求都得以高效輔助。其中沉澱了數百個標準節點和流程模板：新業務來了，不是從零畫流程，而是從 FlowStack 里選「積木」、拼裝成適配的流程；節點命名和責任部門強制統一，避免流程野蠻生長；所有分散的流程節點聚合起來，可以回答「這個環節被哪些流程用過、誰在維護、改動影響面多大」。
負責遊戲研發項目管理的繆可對未來的期待很清晰：人負責判斷，AI 負責把複雜度算清楚、把關鍵提醒推到你面前。FlowStack 不是飛書項目提供的功能，是爪印工作室用開放能力自己搭出來的——這恰恰是「生態」最能打動人的那一面。
唱吧的故事更有意思。唱吧的張楚楚原本是做運營的，後來轉型做項目管理——她不是技術出身，但她在飛書項目上用 MCP + 扣子 + OpenClaw 的組合，把自己的日常工作全面 AI 化，結果是從「一句話」需求到上線的準備周期，過去 10 天的耗時被壓縮到 2-3 天。
唱吧的故事證明了一件事——飛書項目的開放生態不只是大企業和專業 ISV 的舞台，一個非技術背景的業務同學，也能成為自己的「Maker」。
生態答案「三件套」
現在回到最開始的三個「生態條件」，飛書項目的底氣就坐實了。不過這片已經有活力的土壤，走到 AI 時代，也遇到了新的問題——飛書項目自己對開放平台的局限其實相當坦誠，他們認為過去的開放體系在 AI 時代已經開始不滿足於用戶訴求了。
如果我們具體到前面提及的案例，這種「不滿足」其實有三個側面：
AI Agent 普及後，為「固定功能集成」設計的插件開始顯得笨重——你今天寫一個插件，明天 Agent 的使用方式就變了，老體系跟不上；
官方缺少「懂項目管理」的 AI，不是每家企業都有專業的數字工程團隊，對於他們來說，能不能「開箱即用」才是更現實的問題；
AI 能力散落在個人手裡，難以沉澱為組織能力。
正是對這三個問題的精準回應，構成了飛書項目在 Build 2026 上發布的「三件套」：飛書項目 CLI、飛書項目 AI 助手、AI 節點 + AI 欄位——它們分別回應接入層、應用層、流程層的問題，共同構成了飛書項目從「開放平台」升級為「AI 生態」的新地基。
飛書項目 CLI：讓 AI Agent 接進業務
過去一年，OpenClaw 這類 AI Agent 工具在企業里快速普及，但 AI 再聰明，接不進業務系統就只是聊天框。傳統的插件體系解決不了這件事——每個新增空間要單獨接入，每個新接口上線還要適配一遍。開發者和企業都在重複造輪子。
飛書項目 CLI 給出的是另一種思路。一條命令行安裝，AI 就能批量處理各種數據，並且嚴格遵守每個人的權限管控。CLI 還被正式開源——這意味著它不再是飛書項目一家的產品，而是整個開發者生態可以共同維護和疊代的基礎設施。一個值得關注的技術細節是，CLI 相較 MCP 直連更節省 token 消耗，同樣的模型上效果也更好。對企業來說，這不只是「能跑通」的問題，而是得以規模化、可持續地跑下去的優勢。
如果說 CLI 讓 AI Agent 能「伸手」接入飛書項目，那麼同步發布並開源的 AAMP 協議則讓 Agent 和 Agent 之間、Agent 和平台之間能「對話」。飛書項目自己給了一個很貼切的類比——Email，AAMP 想做的就是「Agent 世界的 Email」。它讓本地 Agent 也能突破防火牆和 NAT 的限制，被飛書項目調度；它讓一家公司的 Agent 能和另一家公司的 Agent 協作完成任務，而不必為每一次合作單獨做集成對接。
CLI 讓 AI 握住了業務系統的方向盤，AAMP 讓 Agent 之間有了共同的語言。這兩塊地基合起來，才是一個真正為 AI 時代準備好的「接口層」。
飛書項目 AI 助手：深耕項目管理場景，開箱即用的「業務專家」通用 AI 助手雖然多，但它們大多不懂項目管理——除非你先花大量時間給它投餵上下文。對一線的 PMO 和業務管理者來說，「教 AI 用 AI」本身就是一種新負擔。
飛書項目 AI 助手的不同之處，在於它「懂項目管理」，無需複雜配置，管理者直接就能讓它做項目進展分析、度量圖表生成、團隊人力洞察、日常任務執行——哪怕關閉頁面，它也會在後台繼續工作，並把結果推給你。
這件事的意義，是把過去只有大型企業自建團隊才能做到的事情，下放給了一線管理者——這就是 AI 平權的具體形態。
AI 節點 + AI 欄位：AI 能力聚合到企業流程企業里常見一種更隱秘的 AI 落地困境——就像前面提到的「唱吧」故事，張楚楚自己搭的 Agent 組合一旦隨她離開，組織里的這部分能力也會跟著消失。AI 停留在「個人技巧」而不是「組織能力」，這是今天企業 AI 落地最大的隱性損耗。
AI 節點和 AI 欄位要解決的，就是讓 AI 能力從「個人」沉澱為「流程」，它們分別體現在：
AI節點把 AI 能力作為流程里的一個可配置單元，節點負責人可以自由轉換，每個實例都可以獨立配置，甚至可以隨時重新運行直到滿意為止。
AI欄位在本次發布後完成了一次完整重構，用戶可以把自己好用的指令包裝成帶變量輸入的模板，除了讓其他項目也能復用，還能在市場上架。
這兩者合起來，AI 從「個人能力」升級為「組織能力」，讓那些依賴個人經驗的複雜判斷，真正沉澱為組織的長期資產——讓後來的人、新來的人、不懂 AI 的人，都能接住這些能力。
AI 欄位
全新發布的三件套各司其職，但它們共同指向同一件事——讓現有開放平台里已經產生的價值，能被更多用戶更低成本地複製和放大。這也印證著「生態」和「平台」最本質的區別：開放平台是讓專業用戶能在上面搭東西；生態是讓它的邊界和可能性拓展到每一個使用者上，無關他們的專業基礎。
最後
如果我們用最淺顯易懂的方式描述 AI 時代：工作方式從「人扛流程」走向「系統扛流程」；AI 從「外掛工具」走向「組織成員」；而一個項目管理平台的職責，也從「可用、好用」走向「能讓 AI 落地」。
看著飛書項目走到今天，這種變化背後的邏輯變得愈發清晰：當系統里越來越多的使用者從人類變成 AI Agent 時，僅僅對「人」開放已經不夠了。這也無不契合飛書項目接下來的核心 AI 戰略——AI Friendly。
只有當一個系統對 AI 足夠友好、足夠開放，AI 才不會是一個只會聊天的玩具，而是真正懂業務、能實操的超級助手。從流程配置的靈活開放，到接口與前端體驗的全面開放，飛書項目所有的努力，最終都是為了走向這個「AI 友好」的未來。在這個生態里，人類不再是機械重複的執行機器，而是思考、創造和決策的主角。我們行動準確，流程也在「自己生長」。
