从「平台」到「生态」：一个项目管理工具的 AI 进化史

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 友好」的未来。在这个生态里，人类不再是机械重复的执行机器，而是思考、创造和决策的主角。我们行动准确，流程也在「自己生长」。