AI 時代，一些大型企業(yè)里跨部門、多階段的項目運作方式正在發(fā)生變化。那些過去需要人肉串聯(lián)的環(huán)節(jié)，正在被廣泛應(yīng)用的各類 AI Agent 逐步接管；而 AI 不再只是外掛在實際執(zhí)行之外的工具，它像員工一樣參與企業(yè)的項目，甚至可以被沉淀為組織的 SOP。

這個判斷不是感性的想象。根據(jù)管理協(xié)會 PMI（中國）發(fā)布的《2026 中國研發(fā)項目管理數(shù)字化洞察》，全球范圍內(nèi)超半數(shù)應(yīng)用 AI 的組織數(shù)量激增 86%；IDC 的預(yù)測更清晰：到 2030 年，70% 的開發(fā)者將與自主 AI 智能體協(xié)作，他們的角色會從「親自執(zhí)行」轉(zhuǎn)向「規(guī)劃與設(shè)計」。

這也意味著 AI 要真正落地到業(yè)務(wù)流程里，需要的不只是一個更聰明的工具，而是一個能讓 AI、人、流程、數(shù)據(jù)都順暢連接起來的平臺。所以當(dāng)我們在 AI 時代背景下重新審視項目管理這件事，討論的焦點可能不再是哪款工具「更好用」，而是它的創(chuàng)造邊界和開放生態(tài)有多大。

作為一個極具關(guān)注度和潛力的項目管理平臺，今年飛書項目把活動的名稱從「開發(fā)者日」改成了「生態(tài)日」，除了呼應(yīng)這些洞察，飛書項目負責(zé)人洪濤也在現(xiàn)場給出了三個直抵本質(zhì)的原因：首先是生態(tài)伙伴們渴望直接連接客戶的真實訴求；其次是飛書項目確信，只有把客戶、伙伴和平臺拉到一起，才能長出真正解決業(yè)務(wù)深水區(qū)難題、有生命力的好方案；而最深刻的變化在于——AI 正在重塑「開發(fā)者」的邊界。

這是一個極具關(guān)注度和潛力的觀察窗口。但在走進這次活動之前，我們得先回答一個更基礎(chǔ)的問題：一個項目管理工具，憑什么能暢談「生態(tài)」?

一個從真實用戶里生長出來的產(chǎn)品

飛書項目不是新產(chǎn)品。到今天，飛書項目已經(jīng)服務(wù)了數(shù)千家客戶，覆蓋游戲、汽車、銷售、工單、運營等多種復(fù)雜行業(yè)和業(yè)務(wù)場景。根據(jù) 2026 年賽迪報告，2025 年銷量前十的新能源乘用車品牌里有七家在用飛書項目；飛書項目在軟件研發(fā) SaaS 市場占比 46.8%、IPD SaaS 市場占比 68.6%，均為行業(yè)第一。

飛書項目的起點，是一群人自己的痛

飛書項目最早孵化自抖音的研發(fā)團隊。2018 年前后，抖音團隊已經(jīng)突破千人規(guī)模，用的項目管理工具越來越多，但這些工具之間不互通——信息同步靠人傳、流程對齊靠開會。作為被協(xié)作成本拖慢的團隊，他們決定自己動手解決問題。于是飛書項目問世——代號「Meego」，最初只有一套表格加一套流程圖，專門用來消化抖音內(nèi)部的復(fù)雜協(xié)同。

國內(nèi)大多數(shù) to B 產(chǎn)品的故事是調(diào)研了行業(yè)痛點、設(shè)計解決方案、并推向市場——這通常是一種外部視角。飛書項目的故事則與之相反：我們自己就是那個被痛點折磨的團隊，先為自己造了一個工具，充分驗證其能力后才把它分享給了別人。

這個起點決定了它之后的演化。2021 年正式商業(yè)化之前，飛書項目已經(jīng)在字節(jié)內(nèi)部被反復(fù)打磨了三年——抖音、今日頭條、剪映、飛書、火山引擎……每一條業(yè)務(wù)線的流程邏輯都不一樣，每一種復(fù)雜度都被這個產(chǎn)品吃下過一輪。三年下來，它積累的不是某個行業(yè)的方法論，而是應(yīng)對「業(yè)務(wù)復(fù)雜性」的解決思路。這也解釋了為什么一個起源于互聯(lián)網(wǎng)的工具，后來能在制造業(yè)、汽車、游戲這些完全不同的行業(yè)都跑得通。

商業(yè)化之后，打造開放平臺成了飛書項目的重點工作，「飛書項目開放平臺」隨之上線，汽車供應(yīng)鏈、通用軟件開發(fā)等專業(yè)領(lǐng)域的解決方案也由 ISV 伙伴相繼落地——平臺不再是自己做所有方案，而是讓生態(tài)伙伴一起參與。

今年，基于已形成的功能和用戶生態(tài)，飛書項目將全力圍繞 AI 進一步升級——把核心 AI 能力融合到管理鏈路中，并連同客戶、ISV、Makers 共同打造實用工具，讓 AI 成為生態(tài)共建的底層基建。這就是今天 Build 2026 生態(tài)日要回答的問題：開放生態(tài)是如何讓 AI 真正落地到組織流程、業(yè)務(wù)場景中去，并激發(fā)每一個人的創(chuàng)造力。

八年，三步棋——做深行業(yè)、打開平臺、培育生態(tài)。我不認為這條路徑是臨時起意的方向調(diào)整，它更像是一個從真實用戶里創(chuàng)造的產(chǎn)品，自然生長到這個階段的動作。

飛書項目何以談「生態(tài)」

「生態(tài)」在 to B 語境里被濫用得厲害——很多平臺說「我們是一個生態(tài)」，其實只是「我們有幾個合作伙伴」。如果把這個詞的門檻拉高一點，一個真正的生態(tài)至少要滿足三個條件：

1. 不是平臺方一個人做事，而是多方共建；

2. 參與的角色足夠多元，不只是單一類型的用戶；

3. 可以打造出平臺自己都想象不到的產(chǎn)品。

按這個標準去看飛書項目，它「談生態(tài)」的底氣其實不在對行業(yè)的深刻洞察，而在它已經(jīng)花了一整年時間，在飛書項目開放平臺上實打?qū)嶒炞C過這件事。從 ISV 伙伴到大型企業(yè)，從嚴苛合規(guī)行業(yè)到個體創(chuàng)造者，過去這一年里，飛書項目給出了極為亮眼的成績。

是工具，也是機遇

過去一年，飛書項目不僅讓無數(shù)企業(yè)用戶獲益，其開放平臺也吸引了一批深度共建的 ISV 伙伴——其中做得最具有代表性的兩家，是 Zadig 和詞元無限。

作為國內(nèi)開源 DevOps 領(lǐng)域的代表之一，Zadig 和飛書項目合作的出發(fā)點很直接：項目管理平臺和 DevOps 工具之間，長期存在一道墻——前者管「規(guī)劃」，后者管「執(zhí)行」，兩邊各自為戰(zhàn)，變更一發(fā)生就要在多個系統(tǒng)里手動同步。

Zadig 基于飛書項目開放平臺做了一個叫「Zadig DevOps+ 插件」的方案，把兩邊打通：開發(fā)在飛書項目里提交變更信息，測試工作流由 Zadig 自動執(zhí)行，執(zhí)行結(jié)果實時回傳到飛書項目的任務(wù)里；到發(fā)布環(huán)節(jié)，系統(tǒng)先跑一遍 AI 發(fā)布風(fēng)險檢測，然后走飛書審批，通過后自動執(zhí)行。整個過程不需要切系統(tǒng)，執(zhí)行即同步，審批則發(fā)布，一個平臺從想法到干活全搞定。

這套方案的效果是可以被量化的——發(fā)布效率提升 3 倍，交付周期縮短 35%，故障恢復(fù)時間降低 50%。馭勢科技用這套方案，把客戶交付周期從 4 天直接縮短為 3 小時；海大集團在容器化轉(zhuǎn)型中，借助統(tǒng)一的工作流和環(huán)境模板，整體交付效率提升了 25%。目前方案已經(jīng)在車企、新消費、政企等多個行業(yè)廣泛落地。

發(fā)布階段，審批即發(fā)布

詞元無限走的是另一條路線——它解決的是如何讓 AI Agent 真正接管研發(fā)流程。它構(gòu)建了一套面向企業(yè)級軟件研發(fā)的端到端智能解決方案：AI 理解需求、生成技術(shù)方案、拆解開發(fā)任務(wù)、調(diào)用 Coding Agent 執(zhí)行、接管測試用例的生成和執(zhí)行——原本需要 7-10 人/天的研發(fā)周期，被壓縮到了 1-2 人/天。他們在實踐中得出的一個核心結(jié)論是：企業(yè)缺的不是更強的 Coding Agent，而是一條能把 Agent 產(chǎn)出穩(wěn)定轉(zhuǎn)化為交付結(jié)果的流程閉環(huán)。 Agent 不能只是游離在流程外的效率工具，它必須深度融入業(yè)務(wù)流程，成為真正參與工作、輸出確定性結(jié)果的 「數(shù)字員工」。

因地制宜，全行業(yè)都可用

如果說 Zadig 和詞元無限從技術(shù)側(cè)驗證了飛書項目開放平臺的可能性，那雅迪科技集團證明的是大型制造企業(yè)同樣能在這個平臺上「長」出自己的方案。

雅迪科技集團落地了雙流程體系后，就在飛書項目上快速實現(xiàn)了數(shù)字化運轉(zhuǎn)——研發(fā)走 IPD、營銷走 IPMS，兩條流程在飛書項目上通過跨空間關(guān)聯(lián)能力實現(xiàn)關(guān)鍵節(jié)點的「握手」，真正做到了「開發(fā)一變，上市方案立刻同步」。光這一項改造，就幫雅迪科技集團把全新車型的開發(fā)周期縮短了 2 個月，產(chǎn)品上市時間準確性提升 20%。

飛書項目中實現(xiàn) AI 自動巡檢

更有意思的是后來發(fā)生的事情——雅迪科技集團的團隊沒有滿足于只是把流程搬上飛書項目。他們基于飛書項目的開放接口、飛書 aily 和 MCP 能力，自己打造了一套「IPD 智能項目助手」：

• 自動生成周報月報：AI 自動拉取項目進度和風(fēng)險，準時推給管理層，項目經(jīng)理節(jié)省下的 2 小時用來做真正有價值的事；

• 智能查詢歷史項目經(jīng)驗：把 6 年積累的研發(fā)質(zhì)量問題清單和解決方案全部結(jié)構(gòu)化沉淀到知識庫里。工程師問 AI「上一代冠能系列的車架如何進一步優(yōu)化升級」，系統(tǒng) 5 秒給出帶原始文檔鏈接的答案；

• AI會議質(zhì)檢：飛書項目和飛書會議深度集成，AI 自動提煉決策會議里的評審要素，待辦事項直接生成任務(wù)，讓會議告別「議而不決」；

• 「龍蝦團」智能預(yù)評審：正式評審前，讓一群 AI 智能體分別扮演市場、工程、成本等不同角色來「挑刺」，大幅提升整體效率。

這套 AI 項目給雅迪科技集團帶來的結(jié)果是：減少 20% 的資源浪費，節(jié)省 30% 的重復(fù)性工作工時。

而除了這些傳統(tǒng)的制造企業(yè)，如今最被我們熟知的自動駕駛行業(yè)也有自己的煩惱。他們一直面對著很特殊的雙重壓力：既要像互聯(lián)網(wǎng)一樣快速迭代，又要通過 ASPICE 這類嚴苛的合規(guī)標準。這兩件事本身是有矛盾的——快速迭代意味著變更多、版本多，但合規(guī)要求每一次變更都必須有完整的記錄、追溯和驗證鏈路。

飛書項目內(nèi)置的 AI 個人周報

過去這種矛盾的解決方式就是靠人扛——團隊的大量精力被合規(guī)流程消耗，創(chuàng)造性的判斷反而沒時間做。而借助飛書項目，輕舟智航的解法是：把合規(guī)要求做成流程的「默認動作」。

他們做了一條順滑的流水線：測試同學(xué)在車上發(fā)現(xiàn)問題，用語音先記下來；系統(tǒng)自動做初步分類打標；結(jié)合規(guī)則和歷史，把問題自動推給對應(yīng)責(zé)任人——合規(guī)不再是「人追著流程跑」，而是「系統(tǒng)推著流程走」。

在需求追溯這種更復(fù)雜的場景里，輕舟智航采取的是「AI + 人」的人機協(xié)同策略：AI 先用標簽把候選池子縮小，再做語義匹配，把需求和測試用例盡可能串起來，最后由人工審核驗收。輕舟智航負責(zé)項目交付的劉宇認為：AI 把鏈路里最費時、最容易錯的部分拿走，讓人回到真正需要專業(yè)判斷的地方。用流程內(nèi)的 AI 節(jié)點，無縫連接過去極度依賴人工推進的業(yè)務(wù)斷點后，平臺將徹底告別單一的「過程管理」，開始承載執(zhí)行與交付閉環(huán)，真正演進為「智能交付平臺」。

靈動高效，釋放快節(jié)奏行業(yè)的敏捷勢能

如果說上述案例證明了飛書項目能夠撐起汽車與制造行業(yè)極其復(fù)雜的研發(fā)協(xié)同與嚴苛合規(guī)，那么接下來的案例則展示了它在另一個維度的生態(tài)張力：不僅是重資產(chǎn)的實體產(chǎn)研，面對高敏捷、快迭代的互聯(lián)網(wǎng)及游戲企業(yè)，飛書項目的底層能力同樣能生長出完全契合業(yè)務(wù)心跳的專屬解法。

爪印工作室做的是游戲研發(fā)。游戲行業(yè)有個特殊的節(jié)奏：小瀑布，大敏捷，即重資產(chǎn)內(nèi)容——角色建模、劇情、動畫——生產(chǎn)必須按工序走瀑布，但玩法和版本又要敏捷到「今天決定、明天驗證」。傳統(tǒng)的項目管理工具要么太敏捷、要么太瀑布，爪印想要的是一套自己的流程結(jié)構(gòu)。

爪印工作室 FlowStack

他們沒有另起爐灶搭系統(tǒng)，先搭建了一個叫 FlowStack 的「流程資產(chǎn)倉庫」后，再連接飛書項目的輕應(yīng)用能力，對不同類型需求都得以高效輔助。其中沉淀了數(shù)百個標準節(jié)點和流程模板：新業(yè)務(wù)來了，不是從零畫流程，而是從 FlowStack 里選「積木」、拼裝成適配的流程；節(jié)點命名和責(zé)任部門強制統(tǒng)一，避免流程野蠻生長；所有分散的流程節(jié)點聚合起來，可以回答「這個環(huán)節(jié)被哪些流程用過、誰在維護、改動影響面多大」。

負責(zé)游戲研發(fā)項目管理的繆可對未來的期待很清晰：人負責(zé)判斷，AI 負責(zé)把復(fù)雜度算清楚、把關(guān)鍵提醒推到你面前。FlowStack 不是飛書項目提供的功能，是爪印工作室用開放能力自己搭出來的——這恰恰是「生態(tài)」最能打動人的那一面。

唱吧的故事更有意思。唱吧的張楚楚原本是做運營的，后來轉(zhuǎn)型做項目管理——她不是技術(shù)出身，但她在飛書項目上用 MCP + 扣子 + OpenClaw 的組合，把自己的日常工作全面 AI 化，結(jié)果是從「一句話」需求到上線的準備周期，過去 10 天的耗時被壓縮到 2-3 天。

唱吧的故事證明了一件事——飛書項目的開放生態(tài)不只是大企業(yè)和專業(yè) ISV 的舞臺，一個非技術(shù)背景的業(yè)務(wù)同學(xué)，也能成為自己的「Maker」。

生態(tài)答案「三件套」

現(xiàn)在回到最開始的三個「生態(tài)條件」，飛書項目的底氣就坐實了。不過這片已經(jīng)有活力的土壤，走到 AI 時代，也遇到了新的問題——飛書項目自己對開放平臺的局限其實相當(dāng)坦誠，他們認為過去的開放體系在 AI 時代已經(jīng)開始不滿足于用戶訴求了。

如果我們具體到前面提及的案例，這種「不滿足」其實有三個側(cè)面：

• AI Agent 普及后，為「固定功能集成」設(shè)計的插件開始顯得笨重——你今天寫一個插件，明天 Agent 的使用方式就變了，老體系跟不上；

• 官方缺少「懂項目管理」的 AI，不是每家企業(yè)都有專業(yè)的數(shù)字工程團隊，對于他們來說，能不能「開箱即用」才是更現(xiàn)實的問題；

• AI 能力散落在個人手里，難以沉淀為組織能力。

正是對這三個問題的精準回應(yīng)，構(gòu)成了飛書項目在 Build 2026 上發(fā)布的「三件套」：飛書項目 CLI、飛書項目 AI 助手、AI 節(jié)點 + AI 字段——它們分別回應(yīng)接入層、應(yīng)用層、流程層的問題，共同構(gòu)成了飛書項目從「開放平臺」升級為「AI 生態(tài)」的新地基。

飛書項目 CLI：讓 AI Agent 接進業(yè)務(wù)

過去一年，OpenClaw 這類 AI Agent 工具在企業(yè)里快速普及，但 AI 再聰明，接不進業(yè)務(wù)系統(tǒng)就只是聊天框。傳統(tǒng)的插件體系解決不了這件事——每個新增空間要單獨接入，每個新接口上線還要適配一遍。開發(fā)者和企業(yè)都在重復(fù)造輪子。

飛書項目 CLI 給出的是另一種思路。一條命令行安裝，AI 就能批量處理各種數(shù)據(jù)，并且嚴格遵守每個人的權(quán)限管控。CLI 還被正式開源——這意味著它不再是飛書項目一家的產(chǎn)品，而是整個開發(fā)者生態(tài)可以共同維護和迭代的基礎(chǔ)設(shè)施。一個值得關(guān)注的技術(shù)細節(jié)是，CLI 相較 MCP 直連更節(jié)省 token 消耗，同樣的模型上效果也更好。對企業(yè)來說，這不只是「能跑通」的問題，而是得以規(guī)?；?、可持續(xù)地跑下去的優(yōu)勢。

如果說 CLI 讓 AI Agent 能「伸手」接入飛書項目，那么同步發(fā)布并開源的 AAMP 協(xié)議則讓 Agent 和 Agent 之間、Agent 和平臺之間能「對話」。飛書項目自己給了一個很貼切的類比——Email，AAMP 想做的就是「Agent 世界的 Email」。它讓本地 Agent 也能突破防火墻和 NAT 的限制，被飛書項目調(diào)度；它讓一家公司的 Agent 能和另一家公司的 Agent 協(xié)作完成任務(wù)，而不必為每一次合作單獨做集成對接。

CLI 讓 AI 握住了業(yè)務(wù)系統(tǒng)的方向盤，AAMP 讓 Agent 之間有了共同的語言。這兩塊地基合起來，才是一個真正為 AI 時代準備好的「接口層」。

飛書項目 AI 助手：深耕項目管理場景，開箱即用的「業(yè)務(wù)專家」通用 AI 助手雖然多，但它們大多不懂項目管理——除非你先花大量時間給它投喂上下文。對一線的 PMO 和業(yè)務(wù)管理者來說，「教 AI 用 AI」本身就是一種新負擔(dān)。

飛書項目 AI 助手的不同之處，在于它「懂項目管理」，無需復(fù)雜配置，管理者直接就能讓它做項目進展分析、度量圖表生成、團隊人力洞察、日常任務(wù)執(zhí)行——哪怕關(guān)閉頁面，它也會在后臺繼續(xù)工作，并把結(jié)果推給你。

這件事的意義，是把過去只有大型企業(yè)自建團隊才能做到的事情，下放給了一線管理者——這就是 AI 平權(quán)的具體形態(tài)。

AI 節(jié)點 + AI 字段：AI 能力聚合到企業(yè)流程企業(yè)里常見一種更隱秘的 AI 落地困境——就像前面提到的「唱吧」故事，張楚楚自己搭的 Agent 組合一旦隨她離開，組織里的這部分能力也會跟著消失。AI 停留在「個人技巧」而不是「組織能力」，這是今天企業(yè) AI 落地最大的隱性損耗。

AI 節(jié)點和 AI 字段要解決的，就是讓 AI 能力從「個人」沉淀為「流程」，它們分別體現(xiàn)在：

• AI節(jié)點把 AI 能力作為流程里的一個可配置單元，節(jié)點負責(zé)人可以自由轉(zhuǎn)換，每個實例都可以獨立配置，甚至可以隨時重新運行直到滿意為止。

• AI字段在本次發(fā)布后完成了一次完整重構(gòu)，用戶可以把自己好用的指令包裝成帶變量輸入的模板，除了讓其他項目也能復(fù)用，還能在市場上架。

這兩者合起來，AI 從「個人能力」升級為「組織能力」，讓那些依賴個人經(jīng)驗的復(fù)雜判斷，真正沉淀為組織的長期資產(chǎn)——讓后來的人、新來的人、不懂 AI 的人，都能接住這些能力。

AI 字段

全新發(fā)布的三件套各司其職，但它們共同指向同一件事——讓現(xiàn)有開放平臺里已經(jīng)產(chǎn)生的價值，能被更多用戶更低成本地復(fù)制和放大。這也印證著「生態(tài)」和「平臺」最本質(zhì)的區(qū)別：開放平臺是讓專業(yè)用戶能在上面搭東西；生態(tài)是讓它的邊界和可能性拓展到每一個使用者上，無關(guān)他們的專業(yè)基礎(chǔ)。

最后

如果我們用最淺顯易懂的方式描述 AI 時代：工作方式從「人扛流程」走向「系統(tǒng)扛流程」；AI 從「外掛工具」走向「組織成員」；而一個項目管理平臺的職責(zé)，也從「可用、好用」走向「能讓 AI 落地」。

看著飛書項目走到今天，這種變化背后的邏輯變得愈發(fā)清晰：當(dāng)系統(tǒng)里越來越多的使用者從人類變成 AI Agent 時，僅僅對「人」開放已經(jīng)不夠了。這也無不契合飛書項目接下來的核心 AI 戰(zhàn)略——AI Friendly。

只有當(dāng)一個系統(tǒng)對 AI 足夠友好、足夠開放，AI 才不會是一個只會聊天的玩具，而是真正懂業(yè)務(wù)、能實操的超級助手。從流程配置的靈活開放，到接口與前端體驗的全面開放，飛書項目所有的努力，最終都是為了走向這個「AI 友好」的未來。在這個生態(tài)里，人類不再是機械重復(fù)的執(zhí)行機器，而是思考、創(chuàng)造和決策的主角。我們行動準確，流程也在「自己生長」。