企业衡量 AI 提效，最常用的方法是比较一项任务前后需要多长时间：分析从三天缩短到两小时，文档从一周缩短到一天，代码从半个月缩短到三天。
这些数字直观，也可能真实，却不一定会让项目更早完成。
一份分析即使提前交付，如果下一项试验尚未准备、决策人没有收到变化、外部伙伴仍按旧计划排期，节省的时间只会变成等待。更麻烦的是，AI 会同时加速多个上游任务，使方案、数据和假设变化得更频繁；如果依赖关系没有同步更新，组织反而可能更忙、更快地产生返工。
10 月 20 日，OpenAI 宣布收购药物研发协同平台 Orchestra Bio，并计划将其与生命科学研究工具 Rosalind 结合。公告中的一个细节很值得企业管理者关注：它没有只强调 AI 如何发现候选药物，而是强调如何连接研究发现与后续研究、决定和行动。文章举例说，一个生产批次失败，可能推迟临床试验启动；系统需要识别受影响的活动和时间线、收集相关信息，并比较响应方式，再由科学家与项目负责人决定下一步。
这条消息尚不能证明 AI 已经缩短了药物上市周期。OpenAI 没有披露收购金额、客户样本、项目周期变化、错误率或经独立验证的成效；公告描述的是产品方向，而不是已经实现的经营结果。
但它揭示了企业 AI 的下一类高价值问题：当单项工作越来越快，决定总周期的往往不再是任务本身，而是任务之间的依赖能否被及时看见、解释和重新安排。
局部提速，为什么没有自动变成整体提速
药物研发是一个极端但清晰的例子。美国 FDA 将其划分为发现与开发、临床前研究、临床研究、监管审查和上市后安全监测等阶段。OpenAI 的公告称，从靶点发现到美国监管批准平均约需 10 至 15 年；FDA 资料也强调，研发路径复杂、耗时且结果无法保证。
在这样的长周期系统里，工作不是简单串行。研发、临床、生产、质量、法规、供应链和外部合作伙伴同时推进，却又在关键节点相互依赖。上游实验的一个变化，可能影响样本、生产、申报材料和临床计划；某项工作本身提前完成，也可能因为前置条件未满足而无法进入下一环节。
这类现象同样存在于大多数企业：
所以，“每项任务都快了 30%”不能直接推导出“项目周期缩短 30%”。只有位于关键路径上的工作提前完成，而且节省的时间能够传递到后续活动，局部效率才会改变最终日期。
- 新产品设计更快，但供应商认证、产线改造和销售培训仍未完成；
- 合同审查更快，但价格例外、风险接受和客户确认仍在不同队列中等待；
- 软件开发更快，但测试环境、数据迁移、安全审批和业务验收没有同步；
- 市场内容生成更快，但品牌审核、素材授权、渠道排期和销售承接成为瓶颈；
- 设备异常分析更快，但备件、停机窗口和现场资格决定实际修复时间。
企业真正缺少的，是一张会随事实变化的依赖图
许多项目已经有甘特图、任务列表和周报，却仍难以及时回答三个问题：哪件事正在决定最终日期？一个变化会影响谁？现在最值得投入额外资源的是哪里？
问题通常不在没有计划，而在计划中的依赖过于粗糙。项目表可能写着“完成测试—提交审批”，却没有记录审批依赖哪一版数据、哪些异常必须先关闭、外部机构需要多少准备时间，以及结论变化后哪些材料必须重做。
美国政府问责局（GAO）的《项目进度评估指南》强调，可靠进度需要把活动按逻辑连接，识别有效关键路径，并用实际进展持续更新。指南指出，如果依赖缺失或连接错误，进度表就无法把前序延期传递到后续工作，也无法可靠判断应把资源转移到哪里。
AI 能够帮助企业把这张图变得更及时，但前提是依赖本身被结构化。对一项复杂计划，可以至少记录：
这不是为了给项目增加更多表格，而是让 AI 有能力从会议、工单、实验记录、代码变更和供应商进度中识别真实状态，再把变化映射回项目结果。
- 依赖要素：需要明确的内容
- 交付对象：前序工作究竟交付数据、样品、代码、文件、批准还是资源？
- 接受条件：后续团队以什么标准判断可以开始，而不是“基本完成”？
- 版本关系：后续工作依赖哪个版本，变化后是否必须重新验证？
- 时间约束：最晚何时交付、可等待多久、错过窗口会造成什么后果？
- 责任主体：谁确认完成、谁接收、谁有权改变顺序或接受风险？
- 传播范围：失败、延期或结论变化时，哪些活动与外部伙伴会受影响？
AI 最有价值的角色，不是自动催办，而是解释影响
把 Agent 接入项目系统后，最容易实现的功能是提醒逾期、发送催办和自动改日期。但如果系统只会根据计划日期追人，它只是一个更高频的项目秘书，甚至会增加沟通噪声。
更有价值的能力，是在事实变化时回答“所以呢”：
例如，一个制造批次失败后，AI 可以整理受影响的试验、样品、申报资料和合作伙伴排期，形成几种重排方案；但是否接受额外成本、改变研究设计或延后关键节点，仍由拥有相应专业与责任的人决定。
国际人用药品注册技术协调会（ICH）的质量风险管理指南提供了一个重要边界：风险管理应覆盖识别、分析、评价、控制、沟通与复审，并且投入的正式程度和记录深度应与风险相称。这意味着 AI 不应只给出新的时间表，还要保留变化依据、质量影响、接受条件和复审触发器。
- 哪个前提已经改变，证据来自哪里；
- 哪些下游活动依赖这个前提；
- 最终里程碑、成本、质量或客户承诺可能受到什么影响；
- 现在有哪些可行调整，各自需要什么资源与授权；
- 哪些判断仍然未知，必须由谁确认。
从“完成率”转向“关键路径兑现率”
企业如果继续只看任务完成数、按时率和节省工时，很容易奖励大量与最终结果无关的局部优化。AI 生成更多任务、拆分更多事项后，完成率甚至可能上升，而关键项目仍然延期。
更接近经营结果的指标包括：
可以把其中一个核心指标定义为“关键路径兑现率”：AI 在关键活动上节省的时间，有多少真正传递到了项目里程碑。某项分析提前两天，但后续仍按原日期开始，兑现率接近零；如果提前量让试验、审批或交付同步前移，它才形成真实周期收益。
- 位于关键路径和近关键路径上的活动，周期实际缩短了多少；
- 前序结果达到接受条件后，后续工作等待了多久才开始；
- 重大变化从发生到所有受影响团队收到并确认，用了多长时间；
- 因依赖遗漏、版本错误或状态失真造成了多少返工；
- 计划变更后，成本、资源和外部承诺是否同步更新；
- AI 提出的影响关系有多少被确认、驳回或补充；
- 最终里程碑是否更可靠，而不只是平均任务时间更短。
不要让 AI 根据一张过时的计划自动重排组织
依赖管理也有明显风险。项目系统里的日期和关系不一定代表真实工作，很多关键条件存在于人的经验、外部邮件、合同条款或尚未记录的例外中。AI 如果把不完整计划视为事实，可能把资源从真正重要的工作中移走，或把质量、安全和合规步骤当作可以压缩的等待。
因此，自动化深度应分层推进：
企业还需要保留基线计划与每次变更的理由。否则，系统不断根据最新信息优化，管理层却无法判断项目是因为真实情况变化而调整，还是因为目标在持续漂移。
- 观察层：发现状态变化、依赖缺口和潜在影响，不修改正式计划；
- 建议层：生成重排方案，标出依据、假设、冲突和需要批准的决定；
- 有限执行层：只对低风险、可逆且预先授权的动作更新任务、通知责任人或预留资源；
- 重大变更层：涉及质量标准、合同承诺、监管路径、安全边界或重大预算时，由明确责任人批准。
最合适的起点，是一个经常“局部完成、整体仍等”的项目
企业不必先建设覆盖全公司的智能项目中台。可以选择一类跨三个以上团队、周期较长、返工与等待明显的项目，例如产品上市、工厂技改、大客户交付、系统迁移或监管申报。
先回放几个已经结束的项目：标出关键里程碑、实际依赖和每次延期传播，区分任务执行时间、排队时间、等待确认时间与返工时间。然后让 AI 在不改动正式计划的情况下，尝试从历史记录中还原：最早可以在哪个时点发现风险，当时能看到哪些证据，哪些团队应该收到影响说明，以及哪些调整确实可能改变最终日期。
试点验收的重点不应是系统预测了多少延期，而是它能否找出真实依赖、减少无效等待、让变化及时传到正确的人，并保持质量与责任边界。
OpenAI 收购 Orchestra Bio 的意义，不只是 AI 厂商进入生命科学，也不只是多了一个研发 Agent。它说明，当 AI 开始深入高价值、长周期工作，竞争焦点会从“谁能更快完成一个专业任务”，转向“谁能把研究、生产、质量、监管和商业之间的复杂依赖组织起来”。
对所有企业而言，这都是同一个提醒：AI 可以让每个节点跑得更快，但只有依赖关系可见、变化影响可解释、关键路径能够及时重排，这些速度才会抵达最终结果。
