復雜的項目管理怎么做到「AI 友好」？飛書項目用「開放」給出答案

作者 | 文朋

項目管理始終是企業提升生產效率的重要抓手。

但長期以來，大多數項目管理工具解決的，更多只是記錄、同步與協同層面的表層問題：把需求記下來，把任務掛上去，把流程放進系統里。

一旦進入真實業務深水區，排期是否合理、依賴是否清晰、風險能否提前暴露，仍然高度依賴人的經驗去判斷、協調和補位。這也帶來一個尷尬的現實：盡管工具迭代多年，企業項目交付效率始終沒有實現質變。

隨著 AI 浪潮到來，越來越多企業開始嘗試把 AI 引入項目管理，用于寫總結、做分析、輔助排期等單點提效。但如果 AI 與項目工具之間仍只是“外部協作”關系，停留在流程之外，就很難觸及項目管理最核心的執行鏈路。

正如飛書項目負責人洪濤在飛書項目生態日上所說，未來的工作場景中，很大一部分操作可能不再由人一步步點擊完成，而是由 Agent 去操作軟件。

這意味著，項目管理工具若想真正實現提效，就不能只負責“記錄”，更要負責“連接”。只有當 AI 能夠連接業務流程中的數據與上下文，讀懂任務之間的關系、流程狀態以及背后的業務語境，AI 才有可能深度參與風險識別與動作承接。

4 月 23 日，在飛書項目“生態日”上，飛書項目發布了一系列新能力，包括 MCP（模型上下文協議）、CLI（命令行工具）等底層開放接口，以及 AI 節點、AI 字段、原生 AI 助手等場景化能力。

這些變化釋放出一個明確信號：飛書項目正在進一步結構化流程、數據與協作關系，讓 AI 真正進入項目流程，使其成為一個能夠承接 AI 落地的項目底座。

1 項目管理平臺的需求，正被 AI 改寫

如今，客戶對項目管理平臺中 AI 的期待已經非常明確：他們要的不是一個“會聊天”的助手，而是一個能夠接入流程、參與執行、真正推動項目向前的能力。

“去年，很多客戶在采購研發項目管理軟件時，對 AI 的關注還沒有這么強；但到了今年，AI 已經成為決策前必須評估的一項能力?！憋w書項目商業化負責人楊波在接受采訪時表示，如今在售前階段，客戶已經會主動了解 AI 能力、產品路線圖，甚至直接做能力測試。

這背后反映出，企業對 AI 的需求正在從“會生成”轉向“會執行”。在項目管理場景里，客戶當然希望 AI 能寫總結、做分析，但更核心的期待，是它能真正進入流程，更早識別風險，承接文檔撰寫、數據錄入、狀態維護等高頻重復工作，幫助團隊持續推進項目。

而在這方面，飛書項目已經做了較為充分的準備。

過去幾年，飛書項目持續幫助客戶把需求、缺陷、流程、節點、狀態等信息結構化沉淀下來。對 AI 來說，真正關鍵的從來不只是模型能力，而是是否具備高質量、可讀寫、可治理的數據基礎。

與此同時，由于飛書項目并不是一套寫死的標準數據模型，而是允許客戶根據自身業務去定義和配置工作項、流程、字段和表單等。這意味著，AI 在飛書項目面對的是更貼近真實業務現場的結構化、語義化信息，也更容易理解上下文并準確執行動作。

這也是飛書項目能夠承接 AI 落地的重要原因。根據 2026 年賽迪報告，在 2025 年銷量前十的新能源乘用車品牌中，已有 7 家選用飛書項目；在軟件研發管理 SaaS 和 IPD 管理 SaaS 領域，飛書項目也分別以 46.8% 和 68.6% 的市場份額位居第一。

值得注意的是，飛書項目此次在生態日上推出的一系列新能力，正是在進一步釋放這種“執行力”。

2 飛書項目將平臺重構為更“AI 友好”的基礎設施

這次發布中，一個值得關注的信號是，飛書項目正在圍繞“AI 友好”推動平臺演進。從產品視角看，其底層架構已呈現出明顯的“面向 AI 重構”的方向。

例如，為了讓 AI 更深入地進入真實業務流程，飛書正式開源了“飛書項目 CLI”。

它是一款命令行工具，能夠幫助個人或 AI 工具更高效地訪問和操作飛書項目中的各類數據?；谶@項能力，AI 可以在授權范圍內完成與飛書項目相關的讀取、查詢、創建與更新操作。

例如，AI 可以查詢待辦、需求、任務、評論、工作流和排期等信息；查看工作項詳情、當前狀態及流程節點；創建需求、任務和子任務；更新標題、優先級、狀態、評論等字段；還可以在關鍵修改前先生成預覽，確認后再執行。

一旦 AI 進入真實項目流程，它面對的就不再是單輪問答，而是大量高頻、低成本、可自動化的操作需求。CLI 的價值，恰恰在于提供了更強的批量處理能力、更穩定的調用鏈路，以及更低的 token 消耗。

尤其是“漸進式披露更省 token”這一設計，很能說明飛書項目對 AI 真實使用場景的理解：它考慮的并不是 demo 能不能跑，而是當調用規模放大后，成本和穩定性是否依然可控。

如果說 CLI 是 AI 的“手”，那么 MCP（Model Context Protocol）的優化，就是在為 AI 提供一套更適合調用項目系統的“語義標準”。

它的意義并不只是把 OpenAPI 再包裝一層，而是圍繞 AI 的調用方式，重新設計了一套更適合智能體使用的接口體系。

一方面，它支持更安全的授權方式，讓 AI 能在可控權限下完成數據讀寫；另一方面，它的數據傳導方式也更自然，不再過度依賴 ID、Key 這類 AI 容易出錯的參數；同時，查詢語言更接近 SQL，從而降低了 AI 理解和生成查詢的門檻。

更重要的是，它并不是簡單地“把數據交給 AI”，而是更貼近任務場景地告訴 AI：哪些是待辦，哪些是已辦，哪些與個人相關，哪些與團隊相關。目前，飛書項目 MCP 已提供 40 多個工具，并仍在持續擴展。

至于開源通信協議 AAMP，它解決的則是平臺應用、本地 Agent 與不同運行環境之間的通信協同問題。

這意味著，在 Agent 連接這件事上，飛書已經開始從技術底層打通鏈路，讓 Agent 不只是停留在平臺內部，而是能夠與企業現有的 AI 工具、本地環境和工程系統實現真實聯動。

3 在開放能力之上，飛書項目把 AI 接入了流程骨架

如果說 CLI 和 MCP 解決的是“連接”問題，那么 AI 節點、AI 字段與 AI 助手強化的，就是 AI 如何真正深入項目流程并承擔具體執行任務。

其中，AI 節點的意義尤其突出。它讓 AI 從流程外走進流程內，成為流程中的一個行動單元，幫助團隊厘清復雜項目中的流程關系與環節職責，并承擔預審、分析、測試用例生成等明確工作。

更關鍵的是，飛書首次取消了“要想使用開放能力，必須由管理員先安裝”的限制。節點負責人可以直接把自己負責的節點轉化為 AI 節點，讓 AI 協助任務完成；如果效果不理想，還可以重新運行并持續優化。

AI 字段功能也迎來了更適配項目管理的更新。

過去，很多 AI 的使用方式本質上仍停留在個人 prompt 技巧層面，經驗散落在個體手中，既難復制，也難規?；?。

這一次，AI 字段則把這件事往前推進了一步：它把一次性指令升級為一種帶模板、帶應用市場、帶快速創建能力的開放形態。企業既可以把有效經驗沉淀下來，也可以先在視圖中臨時使用，而不必一開始就貿然寫回正式字段。

至于原生 AI 助手，作為開箱即用的通用 Agent，則被打造為飛書項目 AI 能力的統一入口。

它可以直接圍繞項目管理的核心場景提供官方能力：無論是快速生成報告、洞察項目風險、創建需求、完成節點流轉，還是了解產品功能用法，都可以通過這一入口完成。

更重要的是，在整個分析過程中，它始終只會在授權范圍內、基于用戶可讀取的數據進行分析與生成。用戶也可以把任務交給它處理，即便關閉頁面，它仍然能夠繼續執行。

從這些能力可以看到，飛書項目正在構建一種更貼近真實業務、也更具 “AI 原生”特征的應用模式。

在真實項目環境里，傳統平臺通常是“少數人配置、其他人使用”；但 AI 應用的擴散路徑并不是這樣。AI 落地往往會經歷一個更現實的過程：試點、調整、小閉環、擴展、標準化。

真正困難、也真正有價值的，正是把一次次局部提效沉淀為組織級能力。

飛書項目的獨特之處在于，它正在把這一過程完整接住：個人和小團隊可以低門檻試點；試點過程中可以按項目、按角色靈活調整；經驗成熟后，可以進一步沉淀為模板、流程和 SOP；再往后，還能推廣到團隊、部門乃至整個公司。

4 開放能力開始轉化為真實成果

一個平臺是否真正跑通，不能只看它發布了多少能力，更要看這些能力是否已經長出真實成果。

一個很強的信號是，去年飛書項目開放平臺上已經出現了 100 多款 AI 相關應用，而且其中很多并非官方開發，而是客戶自行構建的。

這說明飛書項目的開放底座已經足夠成熟，足以讓一線團隊先跑起來。這也解釋了為什么 MCP 和 CLI 的推廣會比較快：并不是平臺單向推動，而是那些最有 AI 意識、最有動手能力的人，已經開始主動把它們用起來。

飛書在生態日大會上披露的數據顯示，已有接近 500 家租戶在高頻使用相關能力，月活用戶數超過 6000，對飛書項目的操作次數累計超過百萬次。

從客戶案例來看，當 AI 真正進入流程后，項目交付方式和效率也在發生明顯變化。

例如，詞元無限讓 Agent 沿著需求理解、方案生成、任務拆解、代碼執行、測試生成一路推進，最終把原本需要 7 到 10 人天的工作壓縮到 1 到 2 人天。

雅迪的實踐，則把周報月報自動生成、歷史經驗檢索、會議質檢和預評審等高頻工作串聯起來。這也說明，AI 在項目管理中最先接管的，往往不是最終決策，而是那些高頻、重復、規則相對清晰的環節。

輕舟智航的案例則展示了另一種更符合企業現實的落地方式：測試問題的記錄、分診、分派與閉環，被做成了一條更順滑的流程鏈路。AI 先幫助縮小問題范圍、給出候選建議，再由人工驗收關鍵鏈路。

Zadig 的價值則更進一步。它不只是簡單打通項目管理系統，而是把“管理域”和“工程域”真正連成了一條鏈：開發變更即記錄，測試執行即同步，發布審批即發布，并疊加 AI 發布風險檢測。

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

這些案例說明，飛書項目的價值已經不再只是看板管理，而是真正開始承接并提效企業的項目執行。

當然，飛書開放能力更重要的地方，不只是讓客戶“使用”，更是讓更多角色開始“建造”。

例如，爪印基于飛書項目輕應用能力自研 FlowStack "流程資產倉庫"，已沉淀 200 多個標準節點、50 余項流程模板，再結合 AI coding 等能力，可以快速開發高頻小工具。這說明，項目經理和業務角色已經不再只是提需求的人，他們也可以直接把自己的業務理解轉化為可復用資產。

高遠則基于飛書項目開發了 ASPICE 插件，并已進入 15 家大型智能汽車企業，在國內智能駕駛 Top20 企業中覆蓋過半。這也說明飛書項目的開放能力并不只是支撐 demo，而是已經能承接行業級、專業級的復雜場景。

再結合客戶成功、實施體系、專家認證以及 AI 咨詢伙伴等配套能力的推進，顯然，飛書項目想做的已經不只是“賣一個項目管理功能”，而是在形成一整套可交付、可復制、可持續增長的 AI 落地機制。

這也是飛書項目在 AI 時代真正的分量所在：它正通過項目管理，為企業搭建一個真正讓 AI 開始工作的項目底座。