车载控制器项目的利益相关方构成复杂，外部有整车客户，内部包含产品、硬件、安全、测试、生产制造等多个团队。各方站在自身岗位提出诉求，客户侧重功能体验，硬件团队关注器件约束，功能安全团队聚焦风险防控，制造团队关心下线可实现性。不同来源的诉求很容易发生冲突。很多项目收集完各方输入之后，直接整理成需求文档，没有专门处理诉求之间的矛盾，等到架构设计或者开发阶段才暴露分歧，引发大规模需求变更，增加返工成本。

需求挖掘阶段落地常见几类现实问题。利益相关方识别不全，漏掉制造、售后、供应链这类间接相关角色，后期才新增大量诉求。各方诉求混杂记录，不标注诉求来源，发生冲突时无法追溯是谁提出的原始期望。出现诉求矛盾只靠口头开会协调，没有留下分析、权衡、决策记录。达成共识的过程没有正式确认，后续某一方推翻之前的约定，项目缺少可回溯证据。利益相关方的需求发生变化，没有启动变更分析，直接修改文档。

按照 SYS.1 的过程成果，不仅要收集各方期望，还要达成共识，对变更的利益相关方需求开展分析，并且同步需求状态。冲突处理是需求挖掘环节不可缺少的一部分，不能全部推给下游需求分析阶段去解决。

亚远景 APMS 研发过程管理平台可以统一归集各利益相关方的原始诉求，每条诉求标记来源角色，记录提出时间。当多条诉求出现矛盾，在平台记录冲突现象、各方观点、权衡分析、最终决策结果，留存完整讨论记录。达成一致之后，将诉求转化为正式的利益相关方需求，完成相关方确认。后续任何原始期望发生变化，触发变更分析流程，评估变更带来的影响与风险，所有版本基线完整留存，方便后续追溯。

亚远景 DPAI 垂类 AI 可以批量梳理大量原始诉求，提示相互存在矛盾、互相排斥的条目，给系统工程师提供排查线索，冲突的权衡与最终决策依旧需要各岗位人员共同评审确认。

亚远景 PCAT 过程能力评估工具预置 SYS.1 专项检查点，内部预评估时核查利益相关方识别清单、诉求冲突处置记录、需求共识确认证据，识别只收集诉求但不处理矛盾的情况，在正式评估前发现短板。

工具提供诉求归集、冲突记录、版本基线的载体，但利益相关方识别、矛盾权衡取舍，需要依靠各个业务角色共同完成。把冲突处理纳入 SYS.1 需求挖掘的工作范围，早期化解分歧，才能够减少项目中后期的大范围需求改动，落实 SYS.1 各项基本实践。