目录

前言

IPD：为确定性而生的战争机器

当高速公路修进了无人区

矛盾一：流程节奏 vs 探索节奏

矛盾二：谁在敲代码？

矛盾三：投资逻辑 vs 探索逻辑

矛盾四：控制权的问题

华为的困境不是孤例

方法论不是信仰，是工具

---

前言

最近看到一个话题，说的是2025年上半年，华为研发投入高达960亿人民币。

这个数字放在全球科技公司里，稳居前列。

但是在通用大模型领域并没有特别出彩的表现。

图1：同样的资源投入，截然不同的结果——问题的根源不在投入，在流程体系的底层假设。

而同期的幻方量化却搞出了Deepseek，震动了全球AI圈。

为什么被奉为圭臬的IPD流程，会在大模型这件事上失效了呢？

这篇内容不是关于「华为不行了」的吐槽。

恰恰相反，IPD是一套顶级方法论。

但一流的方法论用错了场景，就是创新的锁链。

这其实也是很多人诟病IPD流程的一个关键点。

今天就借着这个话题聊聊IPD的边界问题。

IPD：为确定性而生的战争机器

要理解为什么，先得理解IPD到底是什么。

IPD，集成产品开发流程。

华为在1998年花了数十亿人民币从IBM引入。

这套方法论的核心思想就一句话：把产品开发当作投资行为来管理。

怎么管？用一套极其精密的结构化流程，确保每一分钱都花在刀刃上。

整个开发过程被切分成五个阶段：概念、计划、开发、验证、发布。

每个阶段结束前，必须通过两道关卡：TR（技术评审）检查技术成熟度，DCP（业务决策评审）投票表决能不能继续。

表决顺序是先统计「终止」，再统计「重新定向」，最后才统计「继续」——只要「终止」票数够，项目就停。

图2：IPD 五阶段流程——每个阶段结束前必须通过 TR 和 DCP 两道关卡，「终止」票数够项目即停。

然后是跨部门团队——圈内俗称「八大员」：市场、财经、人力、质量、采购、服务、制造、合规，各部门在项目组里都有代表。

每个阶段，项目经理和架构师都要被这群人轮番「蹂躏」一遍，确认一切按流程走，才能进入下一阶段。

专业名词叫「过点」。

这套体系的设计前提是清晰的：需求可以在前期被明确定义，产品规格可以提前锁定，开发可以按阶段线性推进，跨部门评审可以降低风险。

在这个前提成立的世界里，IPD就是战争机器。

通信设备强依赖端到端的整体交付，极其复杂。

没有IPD，质量根本没法保持稳定。

华为2013年超过爱立信，成为全球第一通信设备厂商——IPD是发动机。

再看最近几年的新能源汽车，问界M7、M9从发布到交付的节奏，背后是IPD的流程底盘——同样的硬件系统工程，同样的多部门协同，同样的质量管控。

这已经被反复验证过了。

哪怕流程的效率变低，但质量好就足够了。

因为在通信设备、汽车这些领域，质量出错是致命问题。

基站坏了，全网瘫痪；汽车安全出问题，人命关天。效率低一点，可以接受——先保证不出错，再慢慢优化效率。

说到底，IPD的核心能力是什么？

它能保证你把一个已经知道能成功的产品，原样落地，质量稳定。 

你知道目标在哪，IPD帮你修一条最快的高速公路过去。

到这里，你可能已经看到问题了。

当高速公路修进了无人区

大语言模型的研发，和通信设备、新能源汽车，本质上是两类完全不同的东西。

通信设备有明确的3GPP标准，什么频段、什么调制方式、什么协议栈，白纸黑字写清楚。

汽车有百年工业积累，底盘、动力、安全、供应链，每一样都有成熟的工程体系。你知道交付物长什么样，知道技术路径怎么走，知道验收标准是什么。

而大模型呢？

技术路线不确定——预训练要多少数据、什么架构、怎么训练最高效，Google和OpenAI和Deepseek给出的答案都不一样。效果不可预测——模型的涌现能力没法事先规划，它会不会推理、推理到什么程度，训出来才知道。

需要快速试错——一个训练任务跑几个月，跑完发现参数不对，得重新来。

换句话说：你连地图都没有，高速公路修得再好，往哪开？

这是IPD和大模型研发之间最根本的冲突。但光讲这个太抽象，笔者拆成四个具体维度来讲。

图3：IPD 与大模型研发在四个维度上的底层矛盾——不是谁对谁错，是用错了场景。

矛盾一：流程节奏 vs 探索节奏

IPD的「阶段-关口」节奏，假设的是：

你每个阶段可以先停下来，审一审，再决定要不要继续走。

大模型研发呢？

持续训练、持续优化、持续调整。你不可能每训练一轮都过一遍TR加DCP——训练跑了一个月，你停下来说「等一等，先过个评审」？

评审完了市场都变了。

比如IPD的「过点」机制。

一个硬件项目，从概念到计划阶段，要准备十几份评审材料。

每个职能代表都要签字。一个需求变更——哪怕是改一个外壳的颜色——要重新走一遍变更评审流程。

硬件节奏慢，一个项目周期以年计，这个开销可以接受。

但如果把这个节奏套到大模型研发上？

想象一下：算法团队想试一个新的模型架构，需要先写变更申请，等市场代表确认商业价值，等财经代表确认预算影响，等质量代表确认测试方案，等合规代表确认没有风险。

等所有人都签完字，竞争对手的模型已经迭代了两个版本。

IPD的节奏是用「月」来规划评审周期的。

大模型的竞争节奏是用「天」，甚至「小时」来计算的。

矛盾二：谁在敲代码？

IPD体系下有一个微妙但至关重要的特征：

核心角色是项目经理、架构师和各职能代表。

至于真正写代码的人——「在成都或者西安的外包手里。」

IPD的组织逻辑是「重量级团队主战，职能部门主建」。

产品开发的核心工作是决策、评审、协调——通过跨部门协同来降低风险。

编码是执行层，可以外包。

但在大模型研发中，算法工程师就是核心生产力。

模型架构的选择、训练策略的调整、RLHF的反馈设计——这些事情没有算法工程师的判断，产品经理和项目经理根本没法定。

当然，这不是说华为没有优秀的算法人才。

华为2012实验室、诺亚方舟实验室的研究水平毋庸置疑。

但一个组织的创新产出，不只取决于「有没有牛人」，更取决于「牛人是在做决策，还是在执行别人的决策」。

如果你的流程把算法工程师定位成「执行层」，他们就会像执行层一样工作——等需求、写代码、交差。

而大模型研发需要的是：算法工程师自己判断方向、自己设计实验、自己决定什么值得试。

矛盾三：投资逻辑 vs 探索逻辑

IPD把产品开发当作投资——这本身没有错。

但它的投资逻辑是：每个阶段末可以「终止」项目。

DCP投票时，「终止（No Go）」是第一优先级被统计的票。

「重新定向（Redirect）」是第二优先。

最后才是「继续（Go）」。

这套逻辑对硬件产品是完美的：你在概念阶段就大概知道要花多少钱、用多少时间、有没有市场。如果数字不对，及时止损，避免沉没成本滚雪球。

但大模型研发更像科研探索，而不是工程交付。

你不会在第一个训练周期结束后就知道「这个方向能不能走通」。

有时候前三个月的实验都是失败的，第四个月突然涌现出能力。

IPD的投资逻辑是「分阶段下注，不对就跑」。

大模型研发的逻辑是「持续下注，跑到看见信号为止」。

假设你在DCP1时毙掉了一个语言模型——因为它的表现不如当时已有的产品——你不会知道给它更多数据和算力后，它会不会变成下一个GPT。

矛盾四：控制权的问题

不是瀑布和敏捷的问题，是产品控制权的问题。

IPD所有的开发都是结果导向，使用各种流程控制不允许投资失败，验收节点长，所以僵化是必然的。

这句话的重心在后半句：不允许投资失败。

IPD的设计目标是用流程控制来降低失败的概率。

这在硬件领域是合理的——一套注塑模具几十万，开错了重来。

一个基站部署到全国，出了问题全网瘫痪。

失败的成本太高了。

所以「不允许失败」是理性的。

但大模型研发中，失败是常态。

或者说，

失败本身就是研发过程的一部分。

你需要的不是「不允许失败」，而是「允许失败，但从失败中学到东西并快速调整」。

传统产品和AI产品的本质差异也在这里：

传统产品基于规则和逻辑进行固定响应，结果可控。

AI产品由概率生成结果，结果不可控。

当你的产品本身就是概率性的，你却用一套追求「确定性」的流程来管理它——这是底层逻辑的矛盾。

华为的困境不是孤例

反过来看，这个逻辑的另一个方向也成立。

互联网公司的管理基因是「敏捷开发、快速试错、小步快跑」。

产品上线了可以随时改，AB测试可以同时跑十几个版本，用户反馈第二天就能进入需求池。

但当他们面对硬件时——一套模具开下去几十万、认证周期以月计、供应链一锁就是半年——「快」的基因变成了「急躁」，「试错」变成了「浪费」。

硬件重流程管理，软件重敏捷开发。

这句话说起来简单，但它的底层逻辑是：每一种管理方法论，都是为特定类型的「不确定性」设计的。

图4：硬件面对的是「执行不确定性」，大模型面对的是「方向不确定性」——两种完全不同的东西。

华为的问题不是IPD不好，是它把为「执行不确定性」设计的工具，用在了「方向不确定性」的场景里。

回到你自己的公司。

回想一下——你的团队里，是不是也有类似的情况？

一套流程体系，当初是为某个成熟业务线设计的，后来公司要做新业务，直接把老流程搬过去——「既然这套流程在过去是成功的，那它在未来应该也会成功」。

然后你就发现：

创新项目永远过不了评审，新业务总是在论证阶段被「合理」地毙掉，最有创造力的人在用80%的时间填流程单据。

这不是任何人的错。

这是流程基因决定的。

方法论不是信仰，是工具

笔者写这篇文章，不是为了说「IPD不好」。

恰恰相反——笔者自己就是IPD的信徒和实践者。

在硬件产品开发领域，IPD是最系统化、最经得起检验的方法论之一。

但正因为我用过，我知道它的边界在哪。

任何方法论都有自己的「神学假设」——那些它认为理所应当成立的前提条件。

IPD的假设是：

你大概知道要做什么，你大概知道怎么做，你需要的是一套机制来保证执行不出错。

当这个假设成立时，IPD就是最强的武器。

2013年的通信设备、今天的问界汽车，都是证明。

当这个假设不成立时——你连方向都需要探索，技术路线本身就需要验证——IPD就会把「控制」变成「扼制」，把「评审」变成「拖延」，把「不让失败」变成「不让尝试」。

华为如果要做通用大模型，需要的不是在IPD框架里塞进几轮敏捷迭代。

需要的是给AI研发单独建一套流程体系——一套承认不确定性、允许快速试错、把算法工程师放在决策核心的体系。

说到底，一流的方法论用错了场景，就是创新的锁链。

下次当你评价任何公司的创新表现时，先别看它投入了多少钱、请了多少人。

先看它的流程体系是为什么场景设计的。

如果一套为「确定性交付」设计的管理体系，正在管一个「不确定性探索」的创新项目——那无论投多少钱，大概率不会有好结果。

这个判断框架，可能比「华为为什么做不出通用大模型」这个问题本身，更值得带走。

作者简介

卫朋，《硬件产品经理》作者，实战派产品及流程专家，人人都是产品经理受邀专栏作家，CSDN认证博客专家、嵌入式领域优质创作者，阿里云开发者社区专家博主。