CODEX MULTI-ROLE PROJECT FLOW · V0.15 · CURRENT

项目推进总流程图

业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试是当前基线角色,不是封闭列表;项目Hub负责信息路由、成员与状态维护和阶段门禁,新增自定义角色必须先形成职责、成果和决定权契约。

V0.15 · 当前基线2026-09-07 生效;已合并本轮确认变更,并同步 Skill 与角色提醒。
VERSION / CHANGELOG

版本变更记录

每个新版本都保留上一版文件,并在当前版本中记录变更内容、影响范围和基线状态。

版本管理规则:从 V0.8 开始,新版本通过复制当前最新文件创建,禁止覆盖或删除历史版本。评审版本标记为 REVIEW,并记录创建日期和待定的生效日期;只有取得明确的定版确认后,才改为 CURRENT,并同步更新文件名、页面标题、导航、页脚、本表及仓库中的当前流程基线引用。
版本号口径:V0.x 用于验证期的角色、阶段、成果、信息流和文档管理调整;当角色责任与八阶段流程稳定且完成整体验证后,再升级为 V1.0。
版本日期状态主要变更影响范围
V0.15创建:2026-09-04
生效:2026-09-07
CURRENT
  1. 精简业务及产品资料与选填项;立项增加平台 SDK、个参资料,项目风险前移阶段 2,删除独立产品资料整合。
  2. 取消独立接口契约、架构决策记录和硬件实现资料;阶段 3 硬件约束选填,明确阶段 5 硬件、底层交付。
  3. 补充工时评估;产品确认授权范围内资源与排期,预算、采购或对外承诺由业务批准。
  4. 精简测试输入,改用缺陷清单并共同商议责任人;可靠性、专项报告及提测佐证选填。
  5. 平台与客户验收可按条件并行且须双通过;平台由产品出具结论、客户由业务确认,测试资料直交产品。
  6. 结项聚焦资料收集与复盘;豁免精简为项目负责人审批,统一编号、成果引用及 Skill、角色提醒。
文档版本管理、阶段 1–8 总流程、成果矩阵、关联信息流、Skill 及八角色 Hook。
V0.142026-09-02HISTORICAL 人工可读的正式成果、过程成果、标题、正文和结论统一使用中文,机器字段与枚举只保留在运行时工具参数中;项目Hub通过 Etunel 角色清单读取实际 role、display_name 和 relationship,成员角色不再向负责人追问成员、会话或任务编号;新增同源 JSON 和中文 HTML 两种版本的《项目成员清单》,并补充按阶段整理成果、过程记录、项目进度和成果索引的留档规则。 全局成果语言、项目创建、角色登记、Etunel 实际字段、项目文件与进度留档、项目Hub与各成员角色约束和内部培训材料。
V0.132026-08-28HISTORICAL 完成八角色跨文件一致性审核;新增项目成员/多账户/自定义角色规则和状态术语词典;区分项目创建时成员登记与阶段 4 角色分工;统一 NA、测试证据包、软硬件接口契约 和业务术语;同步测试主责的缺陷报告闭环;将信息流图谱顺序统一为阶段 3 方案设计后进入阶段 4 项目规划;重新生成项目Hub系统提示词。 全局角色与成员管理、状态与成果术语、阶段 1 业务输入、阶段 4 成员/任务分工、阶段 6 缺陷闭环、项目Hub提示词。
V0.122026-08-28HISTORICAL 校正 测试计划 的阶段 3 主责;统一 测试计划 和五类阶段 6 正式成果,完善共同最低结构、NA/BLOCKED/成果豁免 边界、缺陷分析报告 主责、平台提测与业务验收边界;把缺陷专业归类和根因责任从项目Hub/测试的越权表述中移回有权角色。 阶段 2 可测性评审、阶段 3 测试计划、阶段 5 提测准备、阶段 6 正式测试与缺陷闭环、阶段 7 验收证据、阶段 8 发布冒烟。
V0.112026-08-28HISTORICAL 校正硬件角色的阶段 3 设计职责;拆分 硬件设计包 与 硬件实现资料;完善原理图、PCB、Gerber/钻孔、BOM、贴片/生产资料、板卡/批次标识、板级测量和硬件版本链;建立 ECO→底层兼容评估→应用固件确认→技术版本矩阵→测试复验闭环。 阶段 3 硬件设计、阶段 5 板卡/样机实现、阶段 6 硬件 ECO 与回归、阶段 7 验收返工、阶段 8 硬件归档。
V0.102026-08-28HISTORICAL 校正嵌入式底层的阶段 3 设计职责;完善 嵌入式底层实现资料 最低内容、可消费/修复/归档版演进、板卡/BOM/ECO 与接口契约绑定、专项测试固件限制、应用层重新合版和发布归档边界;扩充流程图底层成果说明。 阶段 3 方案设计、阶段 5 底层实现与应用合版、阶段 6 底层缺陷回归、阶段 7 验收返工、阶段 8 底层归档。
V0.92026-08-28HISTORICAL 校正嵌入式应用层的阶段 3 设计职责;完善 嵌入式应用层固件包 最低内容、候选/提测/回归/发布版演进、底层重新合版、硬件变化兼容确认和最终固件唯一出口约束;继续清理项目Hub旧称和广播表述。 阶段 3 方案设计、阶段 5 实现集成、阶段 6 缺陷回归、阶段 7 验收返工、阶段 8 发布归档。
V0.82026-08-28HISTORICAL 新增文档内版本变更记录、版本号口径和历史文件保留规则;从本版本起不再通过重命名覆盖上一版。 全局导航、版本管理、项目Hub流程基线引用。
V0.72026-08-28HISTORICAL 修正技术负责人在阶段 3 与阶段 4 的责任顺序;明确总体方案、软硬件接口契约和架构决策的主责;明确项目Hub维护版本矩阵、技术负责人确认版本匹配。 阶段 3 方案设计、阶段 4 项目规划、阶段 5 集成提测、技术缺陷与变更评估。
V0.62026-08-28HISTORICAL 统一产品角色的阶段 2 与阶段 7 正式成果;补齐产品发起早期风险预检、产品定义评审和验收闭环;客户平台资料改为参考输入基线。 阶段 1 早期预检、阶段 2 产品定义、阶段 7 业务验收。
V0.5未登记HISTORICAL BASELINE 建立八阶段主流程、项目Hub中枢角色、角色化状态同步 S.1–S.4、异常协同 E.1–E.4、变更升级 X.1–X.6 和成果豁免 Y.1–Y.7;形成正式成果追踪矩阵。 总流程、项目Hub、全局信息流、门禁和成果追踪。

从业务需求到复盘结项

主线按成果和确认门推进;测试失败、业务验收驳回和需求变更通过回路返回正确阶段,不需要从头重启项目。

白色卡片=项目阶段 黄色门=角色/阶段确认 红色虚线=返工回路
01

业务需求

主责:业务
明确目标与价值。补齐业务对象、业务目标、范围。
正式成果项目背景说明
客户信息:对接客户名称、最终客户名称
项目名称:统一名称或客户规定的项目代号
产品要求:产品形态、提测平台
项目来源:新客户、新项目、旧产品升级、竞品替换或成本优化
需求背景:客户为什么提出这个需求,要解决什么问题
业务目标:本项目希望实现的业务结果
预期价值(选填):可验证的价值假设
订单、预计销售额等信息均为选填,仅在项目适用时补充
客户里程碑要求
提测时间
入库时间
小批量试产时间(选填)
量产时间(选填)
产品与业务确认需求基线
02

产品定义

主责:产品 · 批准:业务
把目标转成可实现、可验证的产品定义。技术负责人组织可行性评估,嵌入式应用层、嵌入式底层和硬件分别评估实现约束,测试评估可测试性。
正式成果立项资料
立项书:包含项目目标、项目基础信息、初步里程碑要求、项目干系人、版本说明等信息
规格书:包含产品硬件规格和主要元器件型号(主控芯片、Sensor、镜头、WiFi 芯片)
功能清单:定义设备支持的功能项
灯态:描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容
产测功能清单:描述产测工具支持项
平台 SDK
个参资料
结构板框图(选填):包含主要器件位置和禁止限制区域
测试验收标准
平台测试用例
客户验收测试用例和验收标准
里程碑要求
提测时间
客户验收时间
试产、量产时间(选填)
项目风险
技术风险
时间风险
其他风险
产品确认方案,业务批准范围
03

方案设计

主责:技术负责人 · 协作:嵌入式应用层 + 嵌入式底层 + 硬件 + 测试
基于产品定义和阶段 2 已有评审结论形成可实施方案。
技术负责人:总体架构、软硬件边界、关键决策嵌入式应用层:业务逻辑、应用协议、功能模块设计嵌入式底层:BSP、驱动、RTOS、HAL 设计硬件(选填):器件、PCB、电源/信号/热及接口约束测试:测试标准、测试用例范围、测试项
正式成果总体技术方案(选填)测试计划
测试标准、测试用例范围、测试项
技术负责人确认整体方案与测试计划,嵌入式应用层/嵌入式底层确认接口可实施,硬件约束选填,产品确认不偏离,测试确认可验证
04

项目规划

主责:项目Hub
基于已确认的产品基线和方案设计成果,生成实际任务、人员分工和排期,引用阶段 2 项目风险。任务计划草案先由技术负责人确认;项目Hub只对存在疑点的任务定向询问对应执行角色,资源与排期基线再提交产品确认;确认后的计划与排期可由项目Hub同步给业务。
正式成果项目计划
项目任务拆分(工时评估)
实际项目排期
角色分工
Etunel 实际 role 与 display_name
职责边界、任务主责和协作关系
加入、退出、替换与交接要求
每项任务只有一个主责角色
项目状态内部记录
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限
项目创建期内部状态在阶段 4 正式化
技术负责人确认任务计划,问题任务由对应执行角色定向确认,产品确认实际人员、资源与排期基线
05

嵌入式软硬件实现

并行:嵌入式应用层 + 嵌入式底层 + 硬件
嵌入式应用层、嵌入式底层和硬件依据已确认的方案设计基线、项目任务计划和角色分工并行实现、样机调试和自测。硬件先取得并核对器件规格书和结构板框图,形成并确认硬件设计包后,再据此推进硬件实现;嵌入式底层将可消费版本交给嵌入式应用层合版,嵌入式应用层负责生成并提交唯一的最终固件版本;接口、任务或器件约束发生重大偏离时返回技术负责人和项目Hub确认。
正式成果硬件设计包
原理图
PCB 源文档
贴片资料(PCBA_BOM、器件位置图 PDF、贴片坐标)
接口定义
嵌入式底层实现资料
硬件功能测试报告
BSP 输出路径
PSP 输出路径
WiFi 设备定频测试固件(选填)
嵌入式应用层固件包
正式固件、升级固件
自测用例
分区表
MD5 值文件
Flash 烧写固件
zn_debug文件
Changelog
串口使能证书
嵌入式底层提交可消费版本,嵌入式应用层合版并提交最终固件,技术负责人确认固件与硬件版本匹配
06

测试验证

主责:测试 · 修复:嵌入式应用层/嵌入式底层/硬件
执行功能、接口、软硬件集成和回归测试。
不通过测试与相关负责人共同商议缺陷责任人;项目Hub按确认分工安排修复,测试独立复验
通过形成必需测试正式成果及质量结论
正式成果功能测试报告
测试结论:通过/不通过
测试用例执行结果
bug: log日志
可靠性测试报告(选填)
高低温测试
跌落测试(选填)
防水测试(选填)
专项测试报告(选填)
画质、Wi-Fi/路由器、SD 卡、功耗、长稳、平台、试产等适用专项
提测佐证(选填)
平台要求的视频、截图、log材料
缺陷清单
bug条目、状态、模块、责任人
bug数量、回头率、冒头率等统计
测试确认质量结论和剩余风险
07

平台/客户验收

产品组织 · 平台:产品确认 · 客户:业务确认
平台验收在前,客户验收在后;输入就绪时可并行。产品确认收到测试直接交付的报告及已提供的提测佐证。
未通过按平台或客户问题定向整改,回到对应分支重新验收。
总条件平台通过(产品确认)+ 客户通过(业务确认),两项均通过后进入复盘结项。
正式成果平台验收报告或结论
产品出具并确认,无需业务确认
客户验收通过报告
业务确认客户验收结果
遗留问题清单
平台与客户共用一份,标明问题来源
平台验收通过(产品确认) + 客户验收通过(业务确认)
08

复盘结项

项目Hub组织 · 相关角色提供资料与复盘输入 · 业务确认结项
收集项目资料,开展项目复盘并完成结项。项目Hub整理各阶段已确认成果、必要过程记录、项目进度和成果索引,核对双线验收与遗留问题承接,汇总经验及改进项。
正式成果结项资料归档
形成最终结果的流程文件
变更记录结项报告流程闭环总结
项目复盘经验与改进项
贯穿全流程:变更申请(需求变更申请)

任何角色都可提出变更;项目Hub组织影响评估,产品评估范围,技术负责人评估总体方案,嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量,测试评估验证成本,变更按既定权限确认或批准,其中授权范围内的资源、排期调整由产品确认,涉及预算、采购或对外承诺时由业务批准;完成必要确认后更新对应基线,并从受影响阶段继续推进。

成果适用性:成果豁免(成果文件豁免)

正式任务的阶段成果默认由主责角色输出;确认不适用时,由主责角色说明原因、影响和替代证据,由项目 Hub 对应真人负责人批准或拒绝,项目Hub记录人工决定;批准仅满足被豁免的文件要求,其他测试、验收和阶段门禁仍须满足。验证期确需跳过时,记录缺失项、风险和后续补齐安排,不把跳过写成成果已完成。

STAGE INFORMATION FLOW ATLAS · V0.15 · CURRENT

各阶段角色信息流图谱

以下内容直接承接总流程图,展示每条会影响成果、决策、门禁、返工或版本的正式信息流,并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。

绿色:正式成果、候选成果或正式基线黄色:过程记录、关联成果或修订对象
00 / RULES

所有阶段共同遵守的流转规则

成员 Agent 的跨角色任务、问题和结论仍经项目Hub定向中继、校验和登记。阶段 7 测试资料由测试负责人直接交付产品负责人,产品向项目Hub确认接收,文件不由项目Hub转发。

正式任务流转路径:触发事件 → 主责角色与本角色真人负责人对齐 → 完成指定文件、专业自审与负责人确认 → 向项目Hub提交成果及确认信息 → 项目Hub检查文件或已约定的交付索引、版本、证据、确认、依赖和冲突 → 定向路由目标角色 → 目标角色完成任务后返回项目Hub → 项目Hub留档并安排下游。信息流图只使用正式角色名称,不单列角色内部的 AI 会话与人工确认过程。阶段 7 文件直接交付与接收确认按该阶段约定执行,不要求大文件经过项目Hub传输。
正式任务默认要求主责角色输出约定成果;确认不适用时记录原因、影响和替代证据。验证期可由负责人决定跳转、回退或暂缓,但必须保留缺失项、风险和补齐安排,不能把跳过写成已通过,也不能静默删除已有文件。
项目Hub业务产品技术负责人嵌入式应用层嵌入式底层硬件测试
主体是否为项目职能角色定义主要确认权限不能做什么
各专业角色是图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体;内部审查过程不作为跨角色信息流单列。以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付;阶段 4 的资源与排期基线及后续授权范围内的资源、排期调整由产品确认;涉及预算、采购或对外承诺时须由业务批准。不能替其他角色作出专业确认。
业务是;同时承担项目级组织授权业务节点同时包含业务专业判断和项目级组织授权的内部确认。除业务成果外,负责确认预算、采购/打样、对外承诺日期、暂停/取消,以及客户验收和项目结项;阶段 4 的计划与排期可由项目Hub同步知会业务,平台验收由产品确认而不经业务批准。不替代产品、技术负责人、硬件或测试等角色给出专业结论。
项目Hub是项目Hub运行中心 AI,是项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和豁免登记;所有成果豁免均须项目负责人(项目Hub对应真人负责人)批准或拒绝。不能自行承诺真实资源、预算、范围、日期或专业结论,也不能以推测代替角色提供的状态证据。
角色与成员配置:图中的八个角色是当前默认基线,不是永久封闭的角色集合。新增自定义角色前先定义目标、职责边界、参与阶段、正式成果、上下游依赖和确认权限,再由 Hub 真人负责人在 Etunel 中手动添加。项目Hub使用 etunel_list_roles 读取实际 role、display_name 和 relationship;各角色会话不向负责人重复确认成员 ID、会话 ID 或其他未由工具提供的字段。阶段 4 再通过《角色分工》将实际任务主责和交接关系正式基线化。
项目成员清单:项目创建完成后、首个正式任务派发前,项目Hub从同一次 etunel_list_roles 结果生成 JSON 版和全中文 HTML 版《项目成员清单》。两份清单只记录项目名称、版本、导出时间及工具实际返回的 role、display_name、relationship,不虚构成员、会话或人员编号。角色变化后生成新版本,不覆盖历史版本;该清单不替代阶段 4 的《角色分工》。
任务与状态规则:每项任务只有一个主责角色;依赖已经满足的多项任务可以形成任务波次,同一角色的内聚工作可以组成一个任务包。项目模式、任务结果、成果状态、阶段门禁、测试结论和业务验收含义不同,不得相互替代。对负责人使用“通过、失败、阻塞、不适用、延期”等自然中文;机器枚举只在工具字段明确要求时使用。
项目文件与进度留档:项目Hub按 项目资料/00-项目管理 和八个阶段目录整理资料,维护《项目概览》《项目进度》《成果索引》及必要的《阶段记录》。正式成果放入对应阶段的角色目录,重要草稿、退回原因、决定和阻塞放入过程记录;正式文件不覆盖,回退不删除历史。阶段交接和钉钉里程碑通知前先完成留档,但目录排版本身不是新的专业门禁。阶段 7 直接交付的测试资料以文件索引和产品接收确认为留档依据,项目Hub无需复制大文件。
任意角色
G.1提交已完成内部审查确认的消息、成果或请求说明完成情况、负责人确认、成果路径、版本、证据和待处理事项
项目Hub
项目Hub
G.2形式校验、跨角色冲突检查、登记并路由不替角色判断专业内容质量
目标角色
目标角色
G.3完成内部审查后返回结构化结果角色内部确认不单列;禁止转发完整聊天记录
项目Hub
项目进度与按需同步:项目Hub持续维护 项目资料/00-项目管理/项目进度.md,并在对应阶段的《阶段记录》中追加重要事件。创建项目、启动任务波次、接收正式成果、重要退回、阻塞与解除、决定与变更、阶段切换/跳转/回退/暂缓和结项时更新;普通消息、队列状态和空确认不逐条留档。关键变化只向实际受影响角色推送,也响应角色按阶段或任务发起的查询。
任意角色
S.1 · 按需查询请求与本角色职责相关的最新项目状态说清关注阶段或任务、需要的信息和用途
项目Hub
项目Hub
S.2 · 自动或按需生成并分发角色化项目状态快照关键状态变化时主动推送;收到 S.1 后按查询范围返回
请求角色及受影响角色
接收角色
S.3确认状态或携带证据提出纠正不得仅凭口头判断覆盖已登记状态
项目Hub
项目Hub
S.4 · 状态纠正校验依据、更新内部记录并重新分发保留旧状态、变更原因、证据引用和生效时间
全部受影响角色
ID触发条件发送 → 接收正式载荷约束/确认对项目执行的影响
S.1角色需要了解当前阶段、任务、依赖、风险或门禁状态,但现有上下文不足或可能已过期。任意角色 → 项目Hub查询范围、关注事项、所需详细度、期望时点和用途。只能查询项目授权范围内的信息;请求角色无需知道项目的内部存储结构。创建一次按需状态查询。
S.2收到 S.1;或阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线或期限发生关键变化。项目Hub → 请求角色及受影响角色项目状态快照:当前阶段与门禁、相关任务、依赖、阻塞、风险、决定、成果引用、下一步、期限和证据。按最小必要原则裁剪为角色化上下文;禁止转发无关角色的完整会话或未确认专业判断;所有状态必须有证据来源。角色获得可执行的最新上下文。
S.3角色收到状态快照。接收角色 → 项目Hub确认可以继续;或说明需要纠正的内容、正确值、原因、证据和负责人确认。没有证据的异议不得直接覆盖状态;存在争议时进入 E.1–E.4。确认可继续执行,或触发状态纠正。
S.4纠正请求通过版本、证据及跨角色一致性检查。项目Hub → 全部受影响角色变更内容、旧值与新值、原因、证据、生效时间及受影响任务。保留状态历史,不覆盖旧版本;改变正式基线时必须转入变更申请。相关角色切换到新的有效状态快照。
异常协同补充机制:条件流、阻塞流、跨角色冲突或无法按时收敛的问题进入 E.1–E.4。项目Hub分别提醒实际相关角色并提供完整问题包;问题复杂时建议各角色真人负责人线下沟通。讨论结果由当前主责角色的负责人带回本角色会话,完成本角色任务后再提交项目Hub;角色 Agent 之间仍不直接通信。
项目Hub
E.1 · 异常触发主动提醒当前主责角色及全部关联角色发送问题、证据、冲突点、影响范围、原流程位置和响应时限
当前主责角色及关联角色
项目Hub
E.2 · 复杂问题建议由当前主责角色组织线下会议提供建议参会角色、议题、待决策项、证据包和结论模板
当前主责角色及关联角色
当前主责角色
E.3提交参与角色统一确认的会议结论包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态
项目Hub
项目Hub
E.4校验、登记结论并恢复原异常流程只恢复被阻塞的原流程,不以会议记录替代正式成果
原流程及关联角色
ID触发条件发送 → 接收正式载荷约束/确认对原流程的影响
E.1条件流或阻塞流被触发;出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。项目Hub → 当前主责角色及实际关联角色问题摘要、证据与版本引用、冲突点、影响范围、所需角色和期望处理时间。项目Hub必须主动提醒,不得只更新状态;各角色依据正式问题包分别确认。原流程保持阻塞,等待问题关闭。
E.2涉及多个专业角色且结论冲突,影响范围/架构/接口/成本/进度/质量,或在要求时限内无法通过异步消息收敛。项目Hub → 当前主责角色及关联角色建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。项目Hub只建议会议和准备输入,不主持专业裁决;当前主责角色负责组织,关联角色共同参与确认。会议结论回传前,不恢复原流程。
E.3线下讨论完成并形成统一结论。当前主责角色 → 项目Hub会议决定记录:参与角色、统一结论、保留分歧、变更项、责任角色、期限、成果版本、证据和负责人确认。禁止只上传录音、聊天记录或未经参与角色确认的纪要;仍有分歧时继续保持阻塞并明确升级项。形成可登记的异常处置结论。
E.4统一结论通过项目Hub的形式、版本、证据和跨角色一致性检查。项目Hub → 原流程及关联角色登记结果、受影响成果或任务、恢复点、后续动作和新时限。项目Hub不改写专业结论;若结论改变正式基线,必须转入变更申请。从原来被阻塞的位置恢复当前流程。
通用约束执行要求不满足时
Etunel 消息Hub 使用工具实际提供的 role、kind、text、可选附件路径和关联字段;需要完成、阻塞或结算时,只从入站消息读取真实 message_id。机器字段不抄进给负责人的正文。字段不符合当前工具 schema 时停止调用并说明能力缺口,不得发明参数。
成果版本必须写清成果名称、当前版本、状态、替代关系和证据引用。作为草稿退回,并说明缺少内容。
成果责任原则上由流程图指定的主责角色创建、更新并提交对应成果。其他角色不能代签;项目Hub返回主责角色。
角色内部审查每个角色必须完成专业自查并取得当前真人负责人确认;跨角色流转时统一以正式角色名称表示。没有自查或负责人确认的成果不能作为正式成果提交项目Hub。
专业发起权专业活动由对应主责角色判断并发起;项目Hub只负责格式校验、任务路由、状态跟踪和结果登记。项目Hub不得越权替角色发起专业决策。
项目Hub审查边界仅做必填结构、文件、版本、证据、负责人确认,以及多个角色正式信息之间的重复、冲突和依赖一致性检查。不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。
成果豁免仅主责角色可提出不适用申请;由项目 Hub 对应真人负责人批准或拒绝,项目Hub记录人工决定;批准仅满足被豁免的文件要求,其他测试、验收和阶段门禁仍须满足。未批准时仍需要该成果;验证期跳转则记录缺失、风险和补齐安排。
角色确认专业结论由对应角色内部形成并确认;阶段 4 的资源与排期由产品确认,预算、采购及对外承诺等项目级组织授权仍由业务内部完成。信息流图只显示统一的正式角色主体。未完成负责人确认时不得作为正式结果发出。
项目状态同步项目Hub维护有版本和证据的项目状态内部记录,并在关键变化时主动向受影响角色推送,或按 S.1–S.4 响应角色查询与纠正。状态来源、版本或时点不明时不得作为任务执行依据。
异常协同项目对异常主动提醒关联角色;复杂问题建议当前主责角色组织线下会议,统一确认后提交结构化结论。未按 E.1–E.4 闭环,不得恢复原流程或推进门禁。
跨角色沟通成员 Agent 之间不直接通信;任务、问题、最终结论、约束和影响都通过项目Hub定向中继。阶段 7 测试报告及已提供的提测佐证可由测试负责人直接交付产品负责人,接收确认回传项目Hub登记。未经确认或未登记的信息不能作为正式下游输入;已按阶段 7 确认接收的文件不要求项目Hub重新转交。
门禁正常顺序推进时,只有必需成果完整、版本正确、证据可访问、确认齐全才能通过;阶段 7 直接交付的测试资料以产品确认收到为交接依据,不要求项目Hub接收大文件。跳转、回退或暂缓按负责人决定另行记录。未满足且没有明确跳转决定时,阶段保持阻塞;接收确认不等于验收通过。
00B / ARTIFACT TRACEABILITY

正式成果—信息流追踪矩阵

流程图规划的每项正式成果都必须能够追踪到首次形成、评审或修订、正式确认以及下游分发。表中流程 ID 与各阶段信息流图和说明表一一对应。

判定原则:正式成果必须由指定主责角色输出;过程记录只能解释校验、评审、冲突、变更和确认,不得替代正式成果。阶段 3 的总体技术方案,以及阶段 6 的可靠性测试报告、专项测试报告和提测佐证为选填成果,未提交不阻塞推进,也无需另行豁免;已提交时仍须完成版本登记和相应确认。若其他必需成果获准豁免,则以下对应流转中的成果引用改为豁免记录和替代证据。
阶段正式成果主责角色首次形成/提交评审、修订与确认正式分发/下游使用
1 业务需求项目背景说明业务F1.1F1.2 条件修订;F1.4 产品与业务确认F1.3 评审分发;F1.5 正式基线给产品
1 业务需求客户里程碑要求业务F1.1F1.2 条件修订;F1.4 产品与业务确认F1.3 评审分发;F1.5 正式基线给产品
2 产品定义立项资料产品F2.2F2.3–F2.6 专业评审与修订;F2.7–F2.8 业务批准F3.1 方案设计输入;F4.1 项目规划输入
2 产品定义测试验收标准产品F2.2F2.3–F2.6 测试评审;F2.7–F2.8 业务批准F3.3 测试计划任务输入;F3.7 提交计划;F6.1 测试输入;F7.1 验收输入
2 产品定义里程碑要求产品F2.2F2.3–F2.6 专业评审;F2.7–F2.8 业务批准F4.1 项目计划 输入;S.2 状态同步
2 产品定义项目风险产品汇总;相关专业角色提供意见F2.2F2.3–F2.6 评估与修订;F2.7–F2.8 确认范围与风险F3.1/F4.1/F5.1 引用当前有效风险;后续风险意见经项目Hub交产品维护
3 方案设计总体技术方案(选填)技术负责人F3.2(提供时)F3.4–F3.8 修订;F3.9–F3.10 确认F4.1 项目规划输入;F5.1 实现输入;F8.2 收集、F8.6 归档
3 方案设计测试计划测试F3.7
提交测试标准、测试用例范围和测试项
F3.7 有缺口时经项目Hub转相关角色确认;F3.8 汇总;F3.9 技术负责人确认测试计划;F3.10 相关角色最终确认F4.1 测试任务规划输入;F6.1 测试任务输入
4 项目规划项目计划项目HubF4.1F4.2 技术负责人确认;F4.3–F4.5 定向修订;F4.6–F4.7 产品确认资源与排期F4.8 分发相关执行角色,可同步业务;F5.1 实现任务输入;后续由 X.4–X.5 按权限确认变更
4 项目规划角色分工项目HubF4.1F4.2 技术负责人确认;F4.3–F4.5 问题任务修订F4.8 随正式任务分发;F5.1 实现责任输入
4 项目规划项目状态内部记录项目HubF4.1 初始执行记录S.3–S.4 证据化纠正;E/X 流程更新F4.8 初始执行快照;S.2 自动或按需分发
5 软硬件实现硬件设计包硬件F5.2(所需输入资料齐备后)F5.2 硬件负责人确认;F5.3 技术负责人及受影响角色确认;F5.7 冲突修订;F5.8–F5.10 版本匹配确认F5.2 硬件实现依据;F5.3 定向分发;F8.2 收集、F8.6 归档
5 软硬件实现嵌入式底层实现资料嵌入式底层F5.4(WiFi 设备定频测试固件选填)F5.5 BSP/PSP 交嵌入式应用层合版;F5.7/F5.10 确认版本关系BSP/PSP 通过 F5.6 集成进统一固件;F8.2 提交归档资料
5 软硬件实现嵌入式应用层固件包嵌入式应用层F5.6 候选;F5.9 最终提测版F5.7 冲突修订;F5.8–F5.10 技术负责人确认F6.1 交测试;F6.8 回归版;F8.2 归档已验收版本
6 测试验证功能测试报告测试F6.2F6.3–F6.9 缺陷/回归更新;F6.10 确认F7.1 测试直接交付产品并确认接收;F8.2/F8.6 归档索引
6 测试验证可靠性测试报告(选填)测试F6.2(提供时)已提供时按 F6.3–F6.9 更新缺陷/回归;F6.10 确认已提供时由测试直接交付产品,F7.1 确认接收;F8.2/F8.6 归档索引
6 测试验证专项测试报告(选填)测试F6.2(提供时)已提供时按 F6.3–F6.9 更新缺陷/回归;F6.10 确认已提供时由测试直接交付产品,F7.1 确认接收;F8.2/F8.6 归档索引
6 测试验证提测佐证(选填)测试F6.2 登记索引(提供时)已提供时按 F6.3–F6.9 补充;F6.10 确认版本与索引F7.1 测试直接交付、产品确认接收;F7.2/F7.4 按需用于验收;F8.2/F8.6 归档索引
6 测试验证缺陷清单测试F6.2/F6.3F6.3 相关负责人共同确定责任人;F6.4–F6.9 修复与测试回归;F6.10 确认F7.1 验收限制输入;F8.2 收集、F8.6 归档
7 平台/客户验收平台验收报告或结论产品F7.3(二选一即可)产品确认;F7.8–F7.9 返工后重新确认;无需业务确认F7.10 双线门禁;F8.2 收集、F8.3 结项核对
7 平台/客户验收客户验收通过报告产品F7.5 草案F7.6–F7.7 业务确认客户结果;F7.8–F7.9 返工后重新确认F7.10 双线门禁;F8.2 收集、F8.3 结项核对
7 平台/客户验收遗留问题清单产品F7.3、F7.5 分别更新同一份清单,标明平台/客户来源F7.8–F7.9 更新处置结果、责任人与期限;F7.10 汇总核对双方问题F8.3 关闭或确认承接;写入结项报告
8 复盘结项结项资料归档项目HubF8.2 收集;F8.6 汇总F8.3 核对;F8.7 完整性与结项确认项目关闭后锁定归档
8 复盘结项变更记录项目HubX.1–X.5 持续记录;F8.6 汇总每次变更决定更新;F8.7 结项检查随结项资料归档锁定
8 复盘结项结项报告项目HubF8.6F8.2–F8.5 提供输入;F8.7 业务确认结项项目关闭依据与归档入口
8 复盘结项流程闭环总结项目HubF8.4–F8.5 复盘输入;F8.6 汇总F8.7 结项确认项目经验、改进项跟进与后续复用
01 / BUSINESS

阶段 1:业务需求信息流

把客户背景、业务目标和关键里程碑转换成经产品与业务确认的需求基线。

主责业务
核心成果项目背景说明、客户里程碑要求
门禁产品与业务确认同一需求基线后进入产品定义
业务完成原始信息收集、成果自查和负责人确认后,以统一的“业务”主体提交成果。项目Hub完成文件、版本、证据和跨角色冲突检查后,在 F1.3 将业务成果评审版本路由给产品。产品与业务通过项目Hub澄清待确认项,并分别完成本角色负责人确认,确认同一需求基线。双方确认后,项目Hub登记留档并向产品分发正式业务基线,即可开启产品定义。
业务
F1.1提交完成内部审查的项目背景与客户里程碑要求草案附负责人确认、来源引用和实际成果文件
项目Hub
项目Hub
F1.2 · 条件触发仅在发现形式错误或跨来源冲突时返回问题触发范围仅限文件结构、版本、证据和已登记信息冲突;无异常则不启用此流
业务
项目Hub
F1.3分发已通过形式校验的业务成果评审版本附成果版本、证据引用、状态和待确认项
产品
产品 / 业务
F1.4产品与业务确认需求基线经项目Hub中转,双方分别确认同一版本
项目Hub
项目Hub
F1.5向产品分发正式业务基线并开启产品定义双方确认后留档,分发当前有效版本即可进入阶段 2
产品
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F1.1收到新的客户需求或业务机会,且业务已完成原始信息收集、自查和负责人确认。业务 → 项目Hub正式成果草案:项目背景说明、客户里程碑要求。
附带内容:负责人确认、来源引用、成果版本和实际文件。
项目Hub不重复判断业务内容质量,只检查形式和跨来源一致性。进入中心登记。
F1.2(条件流)仅当文件结构、版本、证据不合规,或与已登记正式信息发生冲突时触发;不存在上述问题时跳过。项目Hub → 业务过程记录:形式校验问题清单或冲突清单。
关联成果:受影响的项目背景说明/客户里程碑要求及其字段、版本、冲突来源和修正要求。
项目Hub不能生成业务缺失项或替业务补写事实;无错误或冲突时不得发起此流。触发后,错误或冲突关闭前阻塞登记;未触发则直接进入 F1.3。
F1.3业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。项目Hub → 产品评审分发成果:待评审的项目背景说明、客户里程碑要求。
附带内容:成果版本、状态、证据、待确认项和回复时限。
标明待评审状态;经产品与业务确认并留档后,才可作为阶段 2 输入。产品与业务通过项目Hub进入 F1.4 需求基线确认。
F1.4F1.3 已分发评审版本,业务内部审查和中心形式校验已完成。产品 ↔ 项目Hub ↔ 业务确认成果:经产品与业务各自负责人确认的项目背景说明、客户里程碑要求。
附带内容:确认状态、确认时间、确认条件和版本。
待确认项经项目Hub中转澄清;记录双方各自负责人确认状态、时间和版本,双方须确认同一版本。双方确认后通过门禁,进入 F1.5 并开启产品定义。
F1.5产品与业务确认同一需求基线,项目Hub已登记并留档正式版本且阶段门禁通过。项目Hub → 产品正式基线:项目背景说明、客户里程碑要求的当前有效版本。
附带内容:成果版本、基线与证据引用、阶段 2 任务和确认时限。
只允许分发已经确认并留档的当前有效版本;分发事件和接收状态必须登记,草稿或过期版本不得作为产品定义输入。产品接收后开启阶段 2。
02 / PRODUCT

阶段 2:产品定义信息流

产品形成立项资料、测试验收标准、里程碑要求及项目风险。技术负责人、嵌入式应用层、嵌入式底层、硬件和测试按指定范围提供专业可行性与风险意见,由产品汇总技术风险、时间风险及其他风险。

主责产品;业务批准范围
核心成果立项资料、测试验收标准、里程碑要求、项目风险
门禁产品确认方案,业务批准范围,约束和测试标准完整
项目Hub
F2.1下发产品定义任务附产品与业务已确认的阶段 1 基线及已知约束
产品
产品
F2.2提交立项资料草案与专业评审请求产品明确评审角色、问题、范围和期望输出
项目Hub
项目Hub
F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文,不新增专业问题
技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
评审角色
F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段
项目Hub
项目Hub
F2.5汇总跨角色冲突并返回产品裁决/修订项目Hub只指出冲突,不替产品作内容决定
产品
产品
F2.6提交内部确认后的产品方案关闭评审问题并标明保留风险
项目Hub
项目Hub
F2.7请求业务批准范围呈现范围、里程碑、成本/风险影响
业务
业务
F2.8批准、驳回或附条件批准附条件项必须有责任人与期限
项目Hub
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F2.1–2.2阶段 2 启动。项目Hub ↔ 产品输入基线:项目背景说明、客户里程碑要求。
产品提交的正式成果草案:立项资料(含平台 SDK、个参资料)、测试验收标准、里程碑要求、项目风险。
参考输入(非阶段成果):项目已有的器件规格、板框约束、串号表、平台对接文档和开发规范。
产品先自审,所有资料必须引用阶段 1 基线;专业评审由产品发起。进入专业评审路由。
F2.3产品提交可评审草案和评审请求。项目Hub → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试评审分发成果:按角色裁剪上述四类产品定义成果草案。
参考输入:只附与评审问题相关的现有器件、板框和平台资料;另含成果版本、基线引用、评审范围、问题和时限。
项目Hub只校验和路由;技术负责人看总体,嵌入式应用层看功能,嵌入式底层看 BSP/HAL,硬件看器件/板框,测试看可测性。并行评审。
F2.4各角色完成评审。技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 项目Hub过程记录:角色评审结果(角色评审结论)。
关联成果:四类产品定义成果的具体字段;提交结论、缺失、风险、证据、建议和是否阻塞。
不得只回复“可行/不可行”。形成冲突矩阵。
F2.5–2.6存在冲突或缺口。项目Hub ↔ 产品修订成果:受影响的 立项资料、测试验收标准、里程碑要求、项目风险 新版本。
附带内容:字段级修订清单、变更影响和关闭说明。
产品在内部确认最终版本后统一发出。问题未关闭则暂缓推进。
F2.7–2.8产品方案专业评审完成。项目Hub ↔ 业务批准成果包:四类产品定义成果的负责人确认候选版本。
附带内容:范围、验收、里程碑、风险、附条件事项、版本和确认状态。
范围批准由业务完成内部授权后统一给出。批准并留档后作为正式基线进入阶段 3。
03 / DESIGN

阶段 3:方案设计信息流

技术负责人依据产品定义基线,结合阶段 2 已有评审结论组织总体方案;产品、嵌入式应用层、嵌入式底层、硬件和测试依据同一产品基线,对方案和接口约束完成多轮确认。测试提交测试计划,无问题时由项目Hub汇总给技术负责人确认;有不可测试项或环境、治具缺口时,先经项目Hub转交相关角色确认,由测试修订计划后再汇总确认。

主责技术负责人组织方案与接口确认,主责选填的总体技术方案,并确认测试计划;硬件接口与约束为选填;测试主责测试计划
核心成果测试计划;总体技术方案为选填
门禁方案确认、接口可实施、需求不偏离、测试可验证,测试计划经技术负责人确认
总体技术方案为选填,未提供不阻塞阶段推进,也无需另行豁免;必要的技术决定及接口约束仍须写入角色确认记录。硬件的器件、PCB、电源/信号/热及接口约束在本阶段为选填,未提供不阻塞,也无需豁免;已提供时完成对应确认。阶段 5 的硬件前置输入和设计包交付要求不变。
项目Hub
F3.1下发总体方案设计任务附产品定义基线、阶段 2 已有评审记录和现有技术参考资料
技术负责人
技术负责人
F3.2提交设计要点与待确认接口约束含边界、关键决策、非功能和风险;附已提供的总体技术方案
项目Hub
项目Hub
F3.3并行分发角色化设计任务各角色依据同一产品基线和已分发的接口约束开展工作
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
嵌入式应用层
F3.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发
项目Hub → 嵌入式底层 / 技术负责人
嵌入式底层
F3.5提出引脚、电平、时序和器件约束HAL 与硬件设计存在依赖时
项目Hub → 硬件 / 技术负责人
硬件
F3.6反馈硬件约束(选填)器件、PCB、电源、信号、空间、热及接口约束,提供时说明实际影响
项目Hub → 技术负责人 / 嵌入式底层 / 产品
测试
F3.7提交测试计划,说明是否存在可测性缺口无问题:项目Hub汇总给技术负责人确认
有不可测试项或环境、治具缺口:项目Hub转交相关角色确认
项目Hub
项目Hub
F3.8汇总测试计划与设计反馈,请求确认无问题时直接提交;有缺口时先取得相关角色确认,由测试修订计划后再汇总
技术负责人
技术负责人
F3.9返回方案、接口及测试计划确认结果确认与整体方案、接口及实施依赖一致;附已提供的选填成果
项目Hub
项目Hub
F3.10请求各角色确认接口可实施、测试可验证嵌入式应用层、嵌入式底层、产品、测试分别确认;硬件选填内容已提供时确认
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F3.1–3.3阶段 2 门禁通过,产品定义基线有效。项目Hub ↔ 技术负责人/协作角色按主责角色分别形成的正式成果草案:技术负责人按需提供总体技术方案。测试按任务编制 测试计划,包含测试标准、测试用例范围、测试项,并在 F3.7 提交。
过程记录:技术负责人提交设计要点与待确认接口约束,各相关角色完成接口与约束确认。
输入内容:阶段2四类产品成果、现有技术参考资料、阶段 2 已有的可行性与风险评审记录(如有)、设计范围和时限。
方案设计不得依赖尚未形成的 项目计划;所有设计必须引用同一产品基线。开启并行方案设计。
F3.4嵌入式应用层需要新的资源、HAL 或协议。嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人过程记录:接口需求及确认结果。
关联或修订成果:已提供的总体技术方案。
提交内容:接口需求、调用频率、性能、资源指标、理由和受影响功能。
接口调整经项目Hub转交相关角色确认,不得私下约定。更新接口确认结果;改变正式基线时走变更申请。
F3.5嵌入式底层依赖引脚、电平、器件或时序。嵌入式底层 → 项目Hub → 硬件 / 技术负责人过程记录:接口与硬件约束确认。
提交内容:HAL、引脚表、时序、电气约束、板卡依赖和证据。
涉及既有板卡时引用明确版本;新设计注明约束版本。冲突时阻塞相关设计。
F3.6硬件提供本阶段选填约束时。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品关联或修订成果:必要时修订已提供的总体技术方案。
过程记录:硬件约束与接口确认。
提交内容:限制、替代方案、成本、性能和交期影响。
本阶段硬件约束为选填,未提供不阻塞;已提供时器件替换不得静默发生。按已提供内容更新接口与约束确认;改变正式基线时走变更申请。
F3.7测试已形成测试计划,或识别出不可测试项、环境/治具缺口。测试 → 项目Hub;无问题时汇总给技术负责人;有缺口时定向转交相关角色确认正式成果:测试计划,包含测试标准、测试用例范围、测试项。
存在缺口时附带:不可测试项、环境/治具缺口、影响、依据及需要相关角色确认的问题。
确认回传:相关角色经项目Hub返回确认结果,测试据此修订测试计划;涉及接口或验收标准时同步对应主责角色修订。
无问题时无需等待缺口确认;项目Hub只汇总和中继,不代替专业角色确认。测试仍主责计划编制与修订,技术负责人经 F3.8–F3.9 确认测试计划。影响本阶段门禁的缺口应先关闭;验证期需跳转时,由负责人明确记录决定。无问题:进入 F3.8–F3.9 汇总确认;有缺口:先定向确认、修订,再返回该确认路径。
F3.8–3.10专业评审完成。项目Hub ↔ 技术负责人;项目Hub ↔ 各相关角色最终确认成果:测试计划的内部确认版本,以及已提供的选填成果(总体技术方案)。
附带内容:方案与接口确认结果、保留风险、证据引用和统一版本关系。
测试计划仍由测试编制和维护,技术负责人确认其与整体方案、接口及实施依赖一致;相关角色按本领域完成最终确认。每个确认绑定同一版本;选填成果未提供不阻塞本阶段;成员角色之间不直接通信。全部确认并登记为正式基线后进入阶段 4 项目规划。
04 / PLANNING

阶段 4:项目规划信息流

项目Hub根据产品基线和已确认的方案设计成果生成实际任务计划,先由技术负责人确认整体任务结构、技术顺序和依赖;仅对存在疑点的任务,定向向对应执行角色补充确认。资源与排期由产品确认,计划与排期可由项目Hub同步给业务。

主责项目Hub;技术负责人确认技术结构,产品确认资源与排期
核心成果项目计划、角色分工、项目状态内部记录
门禁技术负责人确认技术任务结构、顺序和依赖;问题任务完成定向确认;产品确认资源与排期基线
项目风险已在阶段 2 由产品汇总形成,本阶段只引用并反馈新增风险,由产品维护当前有效版本;不重新创建阶段 4 风险成果。产品资料整合不再作为独立成果,任务按需引用已有立项资料、方案记录和成果索引。
项目Hub
F4.1提交任务计划与正式角色分工草案,请求整体确认附产品/方案基线、角色清单、任务拆分、技术顺序、依赖、初始排期和风险
技术负责人
技术负责人
F4.2确认整体任务计划或返回调整意见确认任务结构、技术顺序、依赖关系、专业角色覆盖和关键风险
项目Hub
项目Hub
F4.3 · 问题任务仅对存在疑点的任务发起定向确认缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发
对应执行角色
对应执行角色
F4.4只确认被询问任务的工期、资源和风险不得要求执行角色重复确认整份任务计划
项目Hub
项目Hub
F4.5提醒关联角色并协调剩余冲突、重排计划问题仍未关闭或日期不可达时按 E.1–E.4 处理
技术负责人及受影响角色
项目Hub
F4.6请求资源与排期基线确认真实人员、资源安排和排期由产品负责人确认
产品
产品
F4.7确认或要求调整资源与排期基线记录产品负责人确认状态、范围、条件和版本
项目Hub
项目Hub
F4.8向相关执行角色发布基线计划和正式任务执行角色取得充分任务输入;计划与排期可同步业务(仅知会);后续按 S.1–S.4 同步
相关执行角色
业务(可同步知会)
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F4.1–4.2阶段 3 方案设计门禁通过,项目Hub已依据产品基线、方案设计成果和项目创建期角色清单形成任务计划草案。项目Hub ↔ 技术负责人正式成果草案:项目计划、角色分工、项目状态内部记录 初始版。《角色分工》列出 Etunel 实际 role 和 display_name、职责边界、任务主责、协作关系和交接要求。
输入基线:阶段 2 产品成果、阶段 3 已确认的必需成果及已提供的选填成果和角色清单;另含任务拆分、关键路径、输入输出、依赖、初始排期和风险。
技术负责人确认技术任务结构、顺序、依赖、版本关系、专业角色覆盖和技术风险;项目Hub不向全部执行角色征求整份计划确认。每项任务只设一个主责角色。形成技术结构与角色覆盖已确认的任务计划草案。
F4.3–4.4(条件流)项目Hub发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据;任务之间存在冲突;或技术负责人明确标记待确认项。项目Hub ↔ 对应执行角色修订对象:项目计划、角色分工、项目状态内部记录 中的问题任务。
过程记录:任务澄清请求/任务澄清回复,包含方案成果引用、上下游依赖、工期、资源、风险和负责人确认。
必须定向发送给该任务的执行角色,不得广播给全部角色,也不得要求执行角色重复确认无疑点任务。补齐或修正问题任务;未触发时直接跳过。
F4.5定向确认后仍存在资源冲突、关键路径冲突或日期不可达。项目Hub ↔ 技术负责人及受影响角色修订成果:项目计划、角色分工、项目状态内部记录 新版本。
过程记录:冲突解决记录,包含冲突点、方案约束、可选排法、阶段影响和响应时限。
项目Hub必须主动提醒,不得静默覆盖技术负责人或执行角色的确认;复杂冲突按 E.1–E.4 闭环。保持计划草案,冲突关闭前不得基线化。
F4.6–4.7技术负责人已确认整体计划,问题任务和剩余冲突均已关闭,资源安排与排期候选基线已形成。项目Hub ↔ 产品待确认成果:项目计划、项目状态内部记录 候选基线。
附带内容:人员与资源安排、工时评估、排期、里程碑、风险、确认范围、条件和状态。
项目Hub不能代替产品确认资源与排期;产品完成负责人确认后统一回复。本环节不替代预算、采购/打样及对外承诺所需的业务授权。产品确认后可基线化。
F4.8技术负责人确认有效、问题任务已关闭且产品确认资源与排期基线。项目Hub → 相关执行角色;可另行同步业务正式基线:项目计划、角色分工、项目状态内部记录。
执行角色状态快照:只包含该角色相关任务、充分输入、依赖、方案成果引用、门禁、风险、时限、成果文件和完成条件。
业务同步(按需):项目计划、实际项目排期和关键里程碑。
每个角色只接收与自身任务和依赖相关的计划内容;后续角色加入、退出、替换或变化必须登记并交接,改变基线时走变更申请;执行状态按 S.1–S.4 同步;业务同步为知会,不等待业务确认,也不新增门禁。相关角色接收任务,开启阶段 5。
05 / IMPLEMENT

阶段 5:嵌入式软硬件实现信息流

三条实现流依据阶段3方案设计基线和阶段4项目任务计划并行推进;硬件先取得并核对器件规格书和结构板框图,形成并确认硬件设计包后再据此实施;固件只有一条正式出口:嵌入式底层先提供可消费版本,嵌入式应用层完成合版并提交统一固件,项目Hub维护其与硬件版本的唯一映射。

并行主责嵌入式应用层、嵌入式底层、硬件
核心成果硬件设计包、嵌入式底层实现资料、嵌入式应用层提交的统一固件包
门禁嵌入式应用层提交最终固件,技术负责人确认固件与硬件版本匹配并可提测
F5.2 硬件资料要求
前置输入(由上游资料责任角色提供):
1、外设器件和关键器件(主控、flash、sensor、复位按键、指示灯、WiFi模块、音频功放驱动芯片、IR-CUT驱动芯片、电机达林顿管驱动芯片)规格书。
2、结构板框图(包含主要器件位置和禁止限制区域)。
硬件设计资料(纳入硬件设计包):
1、原理图。
2、PCB 源文档。
3、贴片资料(PCBA_BOM、器件位置图 PDF、贴片坐标)。
4、接口定义。
执行前提:硬件先核对项目实际使用器件的规格书,以及结构板框图的来源、适用范围和版本。结构板框图在阶段 2 可选填,但进入 F5.2 前须补齐;资料缺失或冲突时,经项目Hub向对应资料责任角色补齐,不以假设替代输入,仅阻塞依赖这些资料的硬件任务。
项目Hub
F5.1并行下发三类实现任务附方案设计基线、项目任务计划、角色分工、风险和任务边界;硬件另附器件规格书、结构板框图
嵌入式应用层 / 嵌入式底层 / 硬件
硬件
F5.2取得前置输入后提交硬件设计包器件规格书、结构板框图齐备后设计;硬件负责人确认后提交
项目Hub
项目Hub
F5.3定向分发硬件设计包及约束变化设计包先完成技术及接口确认,后续只向受影响角色分发完整影响包
技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试
嵌入式底层
F5.4提交嵌入式底层实现资料硬件功能测试报告、BSP 输出路径、PSP 输出路径
WiFi 设备定频测试固件(选填)
项目Hub
项目Hub
F5.5将已登记的嵌入式底层版本交给嵌入式应用层合版按已登记的 BSP/PSP 输出路径交付;定频测试固件仅用于专项测试
嵌入式应用层
嵌入式应用层
F5.6集成底层版本并提交统一固件候选绑定应用、底层和板卡版本,引用已确认的接口定义,包含 MD5、分区、自测和 Changelog
项目Hub
任一实现角色
F5.7报告接口、器件或资源冲突接口约束不一致、资源超限或 ECO 影响时
项目Hub → 技术负责人
项目Hub
F5.8创建软硬件联调与版本矩阵确认任务统一固件候选和硬件候选版本均可用时
嵌入式应用层 / 硬件 / 技术负责人
嵌入式应用层
F5.9提交最终提测固件版本联调问题关闭后,由嵌入式应用层提交最终固件,附完整版本链、自测和偏离说明
项目Hub
技术负责人
F5.10确认最终固件与硬件版本匹配并可提测联调问题已关闭且最终版本已提交;确认板卡、BOM、统一固件及其应用/底层版本链匹配
项目Hub
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F5.1阶段 4 项目规划门禁通过。项目Hub → 嵌入式应用层 / 嵌入式底层 / 硬件待产出成果:嵌入式应用层固件包、嵌入式底层实现资料、硬件设计包。
输入与任务:阶段3已确认的必需成果及已提供的选填成果、阶段4 项目计划(项目任务计划)与角色分工、阶段2 项目风险,以及任务、输出格式、依赖和期限。
硬件额外输入:F5.2 所列器件规格书和结构板框图。
三方必须使用相同的方案设计基线和项目计划版本;硬件输入未齐时先补齐资料,不阻塞其他依赖已满足的任务。依赖已满足的实现任务并行启动。
F5.2–5.3硬件已取得并核对 F5.2 所列输入资料,形成或修订硬件设计包;后续发布样机、板卡、BOM 或 ECO。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试前置输入:项目实际使用的外设器件和关键器件规格书、结构板框图(主要器件位置和禁止限制区域),具体清单见本阶段 F5.2 硬件资料要求。
正式成果:硬件设计包,登记明确版本。
硬件设计资料(纳入硬件设计包):原理图;PCB 源文档;贴片资料(PCBA_BOM、器件位置图 PDF、贴片坐标);接口定义。先由硬件负责人确认,再经项目Hub中继技术负责人及受影响角色完成技术与接口确认。
所需输入资料未齐备或版本未核对时,先经项目Hub补齐,不得提交正式硬件设计包;设计包确认前不得投板或以未确认设计推进样机制作;没有影响分析不得切换硬件版本;禁止使用“最新板”或“当前 BOM”替代明确版本组合。输入缺失时阻塞相关硬件任务;影响接口、底层或应用固件时阻塞受影响任务。
F5.4–5.5嵌入式底层已形成硬件功能测试报告,BSP 与 PSP 输出路径可访问且版本明确。嵌入式底层 → 项目Hub → 嵌入式应用层正式成果:嵌入式底层实现资料 当前版本。
必需内容:硬件功能测试报告;BSP 输出路径;PSP 输出路径。
选填内容:WiFi 设备定频测试固件。
附带信息:输出版本、适配板卡、BOM/ECO、配置及适用的接口定义版本,以及必要的应用层集成说明、已知限制和风险。
BSP/PSP 路径必须指向可访问的实际输出;硬件功能测试报告记录底层已执行的硬件功能测试,不代替测试角色的整机质量结论。WiFi 设备定频测试固件为非必选项,未提供不阻塞合版、提测或阶段推进,也无需另行豁免;提供时标明 TEST_UTILITY_ONLY,仅用于专项测试,不得作为最终提测或发布固件。项目Hub登记必需成果后,将 BSP/PSP 可消费版本交嵌入式应用层合版。
F5.6嵌入式应用层收到已登记的嵌入式底层可消费版本。嵌入式应用层 → 项目Hub正式成果候选:嵌入式应用层固件包。
提交内容:正式/升级/烧写固件、自测用例、分区表、MD5、zn_debug文件、Changelog、串口使能证书,以及应用/底层/板卡版本链及适用的接口定义版本。
必须形成可追溯的应用层+底层统一版本;禁止提交无法复现的单一二进制。进入软硬件联调候选。
F5.7引脚、时序、资源、器件或协议冲突。角色 → 项目Hub → 技术负责人过程记录:实现冲突记录。
关联成果:受影响的硬件设计包、嵌入式底层实现资料、嵌入式应用层固件包及相关接口约束;提交冲突、证据、版本、影响和建议。
项目Hub立即冻结受影响版本。等待技术裁决及相关设计、接口约束更新。
F5.8统一固件候选和硬件候选版本均已就绪。项目Hub → 嵌入式应用层 / 硬件 / 技术负责人联调输入:统一固件候选、硬件候选及对应版本链。
过程记录:软硬件联调任务、候选版本矩阵和联调问题记录。
候选版本就绪即可启动联调,不以联调问题已关闭作为启动条件。开展软硬件联调并处理问题;问题关闭后进入 F5.9–F5.10。
F5.9–5.10联调问题已关闭;F5.9 提交最终提测版本,F5.10 在提交后进行匹配与可提测确认。嵌入式应用层 → 项目Hub;技术负责人 → 项目Hub最终确认成果:嵌入式应用层固件包、硬件设计包;引用已集成的嵌入式底层实现资料。
过程记录:版本矩阵、集成记录、集成批准;包含最终固件、应用/底层版本链、板卡/BOM/ECO、自测和偏离说明。
最终提测固件只能由嵌入式应用层提交;嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。确认后由项目Hub将该唯一固件版本交给测试。
06 / TEST

阶段 6:测试验证与缺陷返工信息流

测试提交测试报告和缺陷清单,由测试与实际相关角色负责人共同商议缺陷责任人;项目Hub按确认分工安排修复和重新提测。

主责测试
核心成果功能测试报告、缺陷清单;可靠性测试报告、专项测试报告、提测佐证(均选填)
门禁阻断缺陷清零,必需成果及其测试依据完整,测试完成内部确认并提交质量结论
可靠性测试报告、专项测试报告和提测佐证均为选填。未提供这些选填成果不阻塞阶段 6 交付、后续验收或归档,也无需另行豁免;已提供时确认对应版本和测试负责人意见。可靠性测试报告包括高低温测试、跌落测试(选填)、防水测试(选填)。选填设置不改变已确认的测试范围和质量门禁。
无缺陷路径:F6.2 → F6.10。测试已完成且无缺陷时,仍提交功能测试报告和零缺陷清单,直接进入最终质量结论确认,不创建无必要的修复任务。发现缺陷时才进入 F6.3–F6.9 的责任确认、修复和回归流程;两条路径均须满足 F6.10 的质量门禁。
项目Hub
F6.1下发测试任务、最终固件和版本矩阵只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件
测试
测试
F6.2提交功能测试报告和缺陷清单测试完成且无缺陷:提交报告和零缺陷清单,直接进入 F6.10;有缺陷则进入 F6.3,关联版本、用例和证据
项目Hub
项目Hub
F6.3分发缺陷清单,协调相关负责人商议责任人测试与实际相关角色负责人共同确定每项缺陷的责任人
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
责任角色
F6.4向项目Hub返回确认的责任分工、原因分析和修复计划责任人、协作关系、处理时限和影响范围经对应负责人确认
项目Hub
项目Hub
F6.5向责任角色派发修复或专业澄清任务同时将确认结果同步给测试维护缺陷清单;责任争议由相关负责人协调,项目Hub不自行归责
责任角色
测试(同步确认结果)
责任角色
F6.6提交应用修复、底层修复或硬件 ECO必须生成新版本并声明替代关系和影响范围
项目Hub
项目Hub
F6.7将固件相关修复交给嵌入式应用层重新合版底层修复必须合版;硬件变化由嵌入式应用层确认固件兼容性
嵌入式应用层
嵌入式应用层
F6.8提交统一回归固件或确认原固件继续有效最终回归固件仍只能由嵌入式应用层提交
项目Hub
项目Hub
F6.9下发定向回归任务和统一固件附版本矩阵、缺陷清单及必要变更说明;具体定位资料按问题提供,不默认提交整包
测试
测试
F6.10提交内部确认的最终质量结论和剩余风险功能测试报告和缺陷清单完整,已提供的选填成果完成确认后
项目Hub
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F6.1–6.2技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。项目Hub ↔ 测试测试输入:嵌入式应用层固件包、版本矩阵、测试计划。
必需成果草案:功能测试报告、缺陷清单。
选填成果:可靠性测试报告、专项测试报告、提测佐证。
提测佐证内容(选填):平台要求的视频、截图、log材料。
佐证提交方式:提供时只向项目Hub登记文件索引、版本和交付状态;文件由测试直接交付产品,F7.1 确认接收。
测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件;缺陷必须关联可复现环境和版本。底层实现资料和硬件设计包不再列为阶段 6 的常规测试输入,不因未附这两类资料拒绝提测;具体测试或定位确需信息时按实际问题经项目Hub查询,不重新要求整包提交。启动测试并更新测试状态;测试完成且无缺陷时,F6.2 提交功能测试报告和零缺陷清单后直接进入 F6.10,不创建无必要的修复任务;有缺陷则进入 F6.3。
F6.3测试发现缺陷或测试异常并形成可追踪记录。测试 → 项目Hub → 实际相关角色提交与更新成果:测试主责的《缺陷清单》。
分发内容:缺陷编号、现象、状态、模块、版本、环境、用例、复现、证据、影响、风险、优先级和回归要求。
商议结果:缺陷责任人、主责角色、协作角色及处理时限。
测试与实际相关角色的负责人共同商议解决缺陷的责任人,每项缺陷明确一名责任人和一个主责角色。项目Hub只登记已确认的分工并路由,不自行指定责任人;跨层技术问题由技术负责人提供判断依据,需求含义由产品澄清。分歧未收敛时按 E.1–E.4 协调。确认缺陷责任分工后,由责任角色在 F6.4 返回原因与计划,项目Hub在 F6.5 派发任务。
F6.4相关负责人已共同确认缺陷责任人,责任角色完成原因分析与计划确认。责任角色 → 项目Hub过程记录:确认的责任人、主责与协作角色、原因分析和修复计划,包含影响、方案、风险、修复成果计划、期限、需重测范围和证据;必要时引用技术/产品决定。“无法复现”“符合设计”或“不修复”必须带理由与证据;责任人调整仍需相关负责人共同确认。项目Hub接收确认结果,进入 F6.5 派发任务并同步测试。
F6.5项目Hub收到 F6.4 已确认的原因分析、责任分工和修复计划。项目Hub → 责任角色;同时项目Hub → 测试派发任务:按已确认分工向责任角色派发修复或专业澄清任务,明确输出、期限和回归要求。
同步确认结果:将已确认的责任分工、原因分析及修复计划同步给测试,由测试维护同一份《缺陷清单》的责任人、状态和回归要求。
项目Hub不自行归责;实现角色不直接替换或关闭测试主责的《缺陷清单》。阻断缺陷使阶段阻塞;等待修复成果和目标版本复验。
F6.6–6.8应用修复、嵌入式底层修复或硬件 ECO 已提交。责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试实现角色修订成果:嵌入式应用层固件包、嵌入式底层实现资料或硬件设计包。
同步给测试的确认结果:责任分工、修复进展及必要变更说明,包含目标版本、影响和建议回归范围;测试据此维护《缺陷清单》。回归统一按 F6.9 提交统一固件、版本矩阵、缺陷清单及必要变更说明;具体定位资料按问题提供,不默认提交实现资料整包。
硬件 ECO 额外内容:新旧板卡/PCB/BOM/ECO 差异、受影响批次、返工/回退方式、板级验证证据、底层驱动/HAL 兼容评估、应用固件有效性确认和新版本矩阵。
实现角色无权直接替换或关闭《缺陷清单》。嵌入式底层修复不得直接交给测试;必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估;即使不修改固件,也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵,测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。形成唯一可回归的固件与硬件版本矩阵,并由测试复验。
F6.9统一回归固件和硬件版本矩阵通过项目Hub校验,必要时由技术负责人确认。项目Hub → 测试回归输入:统一固件、版本矩阵、缺陷清单及必要变更说明。具体定位资料按实际问题经项目Hub提供,不默认提交底层实现资料或硬件设计包整包。
过程记录:回归任务,包含修复范围、受影响用例和时限。
旧版本不得覆盖;测试不得接收嵌入式底层单独提交的固件。执行定向回归。
F6.10测试完成且无缺陷时由 F6.2 直接进入,或缺陷处理及必要回归完成后进入;均须阻断缺陷清零且必需成果及其测试依据齐全。测试 → 项目Hub最终确认成果:功能测试报告、缺陷清单的负责人确认版本。
已提供时一并确认:可靠性测试报告、专项测试报告、提测佐证。
附带内容:质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。
测试内部确认状态必须记录;剩余风险必须有接受方;选填成果未提供不作为门禁阻塞项。提测佐证提供时只登记索引、版本和测试负责人确认,无需向项目Hub上传大文件。门禁通过并留档后开启验收。
07 / ACCEPT

阶段 7:平台验收与客户验收信息流

平台验收在前、客户验收在后;各自输入就绪时可并行开展。平台结果由产品确认,客户结果由业务确认,两部分均通过后才完成阶段 7。

主责产品组织两部分验收;平台由产品确认,客户由业务确认;项目Hub登记与协调
核心成果平台验收报告或结论、客户验收通过报告、遗留问题清单
总门禁平台验收通过 + 客户验收通过,两项缺一不可
资料交接:测试负责人直接向产品负责人交付测试报告及已提供的提测佐证,文件不经项目Hub转发。产品只需确认收到对应资料;项目Hub登记文件名称、版本和接收确认,不要求大文件上传或重复转交。提测佐证仍为选填,未提供不阻塞验收;收到材料不等于验收通过。
产品
F7.1确认收到测试报告及已提供的提测佐证测试直接交付文件;项目Hub仅登记产品接收确认
项目Hub

第一部分:平台验收

项目Hub
F7.2组织平台验收,明确验收对象和依据优先启动平台验收;产品使用已收到的测试资料
产品
产品
F7.3出具平台验收报告或结论产品负责人确认通过或不通过,无需业务确认;更新同一份《遗留问题清单》,标明平台来源
项目Hub

第二部分:客户验收

项目Hub
F7.4组织客户验收,准备客户验收资料客户验收输入就绪时,可与平台验收并行,不必等待平台先通过
产品
产品
F7.5提交客户验收报告和遗留问题清单客户反馈按联络边界取得;更新同一份《遗留问题清单》,标明客户来源并保留平台问题
项目Hub
项目Hub
F7.6请求业务确认客户验收结果只确认客户验收部分,不追加平台验收审批
业务
业务
F7.7确认客户验收通过或退回整改明确客户反馈、结论、版本及遗留问题承接
项目Hub

共用返工与验收总门禁

项目Hub
F7.8定向路由平台或客户验收未通过的问题只处理实际受影响部分;需要测试时返回阶段 6
实际相关责任角色
责任角色
F7.9提交整改成果、说明及必要复验结果平台返回 F7.2–F7.3;客户返回 F7.4–F7.7,分别更新结论
项目Hub
项目Hub
F7.10核对平台通过 + 客户通过,登记验收基线汇总核对同一份《遗留问题清单》及来源;平台有产品确认、客户有业务确认,两项均通过后进入阶段 8
项目Hub
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F7.1测试门禁通过,测试已向产品交付必需测试报告。测试负责人 → 产品负责人(直接交付文件);产品 → 项目Hub(接收确认)接收确认:产品确认已收到测试报告及已提供的提测佐证,说明对应文件名称和版本。
验收输入:功能测试报告、缺陷清单及已提供的选填成果(可靠性测试报告、专项测试报告、提测佐证),以及嵌入式应用层固件包、版本矩阵和已知限制。
项目Hub只登记交付索引与产品接收确认,不中转文件,不以大文件上传为交接条件;选填成果未提供无需补交。接收确认不替代后续验收结论。产品取得平台与客户验收所需输入。
F7.2–7.3平台验收所需输入就绪。项目Hub → 产品 → 项目Hub正式成果:平台验收报告或结论,二选一即可;同步更新平台与客户共用的《遗留问题清单》,标明平台来源、责任人、状态和期限。
内容:验收对象与版本、测试或平台结果引用、通过/不通过、问题和限制、产品负责人确认。
平台验收由产品出具报告或明确结论并确认,无需业务确认;项目Hub只登记,不代产品判断。平台通过后登记该分支完成;不通过进入 F7.8–F7.9。
F7.4–7.5客户验收所需资料与客户联络条件就绪,不要求平台已经通过。项目Hub → 产品 → 项目Hub正式成果草案:客户验收通过报告;更新与 F7.3 共用的同一份《遗留问题清单》,标明客户来源,保留平台问题及其处置记录。
内容:客户验收对象、版本、反馈、结果、问题、责任人和期限。
客户验收可以与平台验收并行;客户信息由业务或产品负责人按联络边界取得并回传,不虚构客户 Agent 或客户确认。形成提交业务确认的客户验收材料。
F7.6–7.7客户验收材料与反馈齐备。项目Hub → 业务 → 项目Hub待确认成果:客户验收通过报告及客户相关遗留问题。
确认内容:客户验收通过或退回整改、对应版本、反馈依据和负责人确认。
业务确认仅针对客户验收,不作为平台验收的批准环节;未确认、未完成或退回整改均不计为客户通过。客户通过后登记该分支完成;否则进入 F7.8–F7.9。
F7.8–7.9平台或客户验收未通过、资料缺口或结论需要修订。项目Hub → 实际相关责任角色 → 项目Hub过程记录:验收问题与定向返工记录。
修订内容:受影响的上游成果、整改说明、必要复验结果,以及对应平台/客户验收结论和遗留问题清单。
需要测试时返回阶段 6,由测试独立复验;责任分工按已确认规则协调。完成后回对应验收分支;版本变化影响另一分支时,该分支也需更新确认。未通过的分支保持处理中,不重启整个项目。
F7.10平台验收通过,且客户验收通过。项目Hub登记双线结果门禁依据:产品确认的平台验收报告或结论、业务确认的客户验收通过报告,以及平台与客户共用的同一份《遗留问题清单》。
登记内容:汇总核对 F7.3、F7.5 分别更新的平台/客户问题及来源、状态、责任人与期限;登记两部分结论、验收对象与版本、确认人、未关闭问题的承接人和期限。
总条件为平台通过 + 客户通过;任一未通过、未完成或待确认均不得进入阶段 8。两部分结论应对应一致的验收对象与有效版本,不再追加平台的业务确认。登记双线验收基线,进入阶段 8 资料归档与复盘结项。
08 / CLOSE

阶段 8:资料归档与复盘结项信息流

项目Hub组织收集各阶段已确认资料,核对验收与遗留问题承接,开展项目复盘并完成结项。本阶段不安排测试或发布验证任务。

协调项目Hub组织;实际参与角色提供资料和复盘输入;业务确认结项
核心成果结项资料归档、变更记录、结项报告、流程闭环总结(项目复盘)
门禁双线验收通过、资料归档完整、复盘完成、遗留问题已关闭或落实承接
项目Hub
F8.1下发资料收集与项目复盘任务只面向实际参与、持有成果或承担遗留事项的角色
实际相关角色
实际相关角色
F8.2提交各阶段最终资料与成果索引沿用已确认版本,附变更记录、必要过程记录及资料位置
项目Hub
项目Hub
F8.3核对双线验收结果与遗留问题承接平台采用产品确认,客户采用业务确认;遗留问题落实责任人与期限
产品 / 业务
项目Hub
F8.4组织项目复盘,收集经验与改进建议围绕目标完成、计划偏差、协作、质量问题和改进措施
实际相关角色
实际相关角色
F8.5提交复盘结论与改进项说明经验、问题原因、改进措施、责任人和跟进安排
项目Hub
项目Hub
F8.6汇总资料归档、变更记录、复盘总结与结项报告核对资料索引、有效版本、确认记录及遗留事项承接
归档库
业务
F8.7确认项目结项或要求补充依据归档完整性、项目复盘和遗留事项承接进行结项确认
项目Hub
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F8.1–8.2阶段 7 平台验收和客户验收均已通过。项目Hub ↔ 实际相关角色收集资料:各阶段正式成果的当前有效版本、必要过程记录、变更记录、项目进度、成果索引和对应确认。
实现资料:已验收的应用层统一固件、被集成的底层版本、硬件设计包及匹配版本关系。
沿用已确认成果,不重新要求制作同内容文件;实际未参与的角色不虚构成果。测试直接交付产品的资料保留文件索引和产品接收确认,项目Hub无需收存或重复转交大文件。形成结项资料清单与缺口清单。
F8.3各阶段资料与验收记录已收集。项目Hub ↔ 产品 / 业务核对内容:产品确认的平台验收报告或结论、业务确认的客户验收通过报告、遗留问题清单。
承接信息:未关闭问题、风险、责任人、期限和后续跟进方式。
只核对已有双线验收结果,不重新给平台增加业务批准;遗留事项必须已关闭或有明确承接。确认结项范围与后续责任。
F8.4–8.5项目事实、阶段成果及主要问题已整理。项目Hub → 实际相关角色 → 项目Hub复盘输入:目标完成情况、计划与实际偏差、协作与质量问题、有效经验和改进建议。
输出:各角色确认的复盘结论与改进项,汇入《流程闭环总结》。
复盘基于已有事实和记录,不把未执行的验证写成已完成;改进项说明责任人和跟进安排。完成项目复盘并形成可跟进的改进项。
F8.6资料收集、验收核对和项目复盘完成。项目Hub → 归档库正式成果:结项资料归档、变更记录、结项报告、流程闭环总结。
汇总内容:最终资料索引、有效版本、阶段确认、验收结论、复盘经验、改进项与遗留责任。
保留历史版本和引用,不以完整聊天记录代替项目档案;选填成果未提供不作为归档阻塞项。形成可追溯的结项包。
F8.7结项包完整且遗留事项已有承接。业务 → 项目Hub确认对象:结项报告、流程闭环总结和结项资料归档完整性。
结项决定:确认结项或补充清单、负责人确认与时间。
待补充的结项必需项未完成时不关闭;确认结项不代表新增测试、发布或生产验证已经执行。确认后锁定四类结项成果,关闭项目并按安排跟进遗留与改进项。
X / CROSS-CUTTING

贯穿全阶段:变更、阻塞与超时信息流

变更申请 和异常升级不属于某个单一阶段;项目Hub必须暂停受影响任务,组织并行影响评估,再按既定权限确认或批准变更并决定是否重开阶段。授权范围内的资源、排期调整由产品确认;涉及预算、采购或对外承诺时由业务批准。其他变更沿用已确认的职责与授权边界。

任意角色
X.1提交变更申请或阻塞记录附原因、证据、受影响版本和紧急度
项目Hub
项目Hub
X.2冻结受影响任务并并行征询影响产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
评估角色
X.3返回内部确认的范围、方案、工期、成本和测试影响现实承诺由角色内部确认后统一发出
项目Hub
项目Hub
X.4按授权范围提交综合影响和确认请求授权内资源、排期调整交产品;预算、采购或对外承诺交业务
产品 / 业务
按授权范围接收
产品 / 业务
按权限确认或批准
X.5返回确认、批准或拒绝变更的决定产品确认授权内资源与排期;涉及预算、采购或对外承诺须业务批准
项目Hub
项目Hub
X.6超时提醒与升级专业事项升级给对应角色;项目级组织授权升级给业务
对应角色
ID触发条件发送 → 接收提交内容(对应正式成果)约束状态结果
X.1范围、接口、器件、版本、资源或日期发生变化;或出现无法继续的阻塞。任意角色 → 项目Hub过程记录:变更申请或阻塞记录。
关联成果:当前基线、受影响成果及版本、任务、原因、证据和紧急程度;批准后写入变更记录。
必须关联当前基线和受影响任务。创建变更或阻塞记录。
X.2–X.3中心确认变更可能影响正式成果。项目Hub ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试过程记录:角色影响评估。
提交内容:对受影响正式成果逐项给出范围、方案、工期、成本、测试、返工和版本影响,并列出建议修订的成果和版本。
各角色只评估自己的责任范围;现实承诺在角色内部确认后统一发出。受影响任务冻结。
X.4–X.5影响评估齐全,变更事项与适用授权范围明确。项目Hub ↔ 产品(授权范围内的资源、排期调整);涉及预算、采购或对外承诺时,项目Hub ↔ 业务过程记录:变更决定记录,注明授权依据、确认或批准角色、负责人及决定时间。
成果影响:综合影响清单、确认/批准/拒绝/延期建议和新基线候选;取得必要确认或批准后更新变更记录、相关正式成果和项目状态内部记录。
授权范围内的资源、排期调整由产品确认,不额外等待业务批准;涉及预算、采购或对外承诺时,须取得业务批准,不以产品确认替代。其他变更沿用已确认职责与授权,不扩大产品权限;技术与质量判断仍由对应专业角色确认。不得隐藏已完成工作损失、成本或里程碑影响。取得必要确认或批准:建立新基线并重开受影响阶段;拒绝或延期:维持原基线。
X.6确认或任务超过约定时间。项目Hub → 对应角色;项目级组织授权事项发给业务过程记录:升级通知。
提交内容:逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的期望时间。
接收角色在内部完成确认后统一回复。保持等待确认或阻塞。
Y / ARTIFACT WAIVER

贯穿全阶段:成果文件缺省与豁免信息流

必需成果默认必须输出,选填成果未提供无需豁免。仅主责角色可申请豁免;项目Hub校验并汇总申请,必须由项目负责人(项目Hub对应真人负责人)批准或拒绝,Hub AI 不得自行决定。

发起者该成果在流程中的主责角色
审批人项目负责人(项目Hub对应真人负责人);项目Hub AI 仅登记与执行决定
门禁结果需要成果 → 审查豁免 → 已豁免或仍需成果
成果主责角色
Y.1提交成果豁免申请说明为何本项目不适用,并附证据和替代信息
项目Hub
项目Hub
Y.2校验发起资格与可豁免性非主责角色、无证据或不可豁免成果直接退回
主责角色
项目负责人
项目Hub对应真人负责人
Y.3人工确认批准或拒绝成果豁免依据申请、证据、替代方案与影响,记录确认人、时间和条件
项目Hub
登记与门禁更新
项目Hub
Y.4A批准:记录已豁免并分发豁免记录仅满足被豁免的文件要求,其他测试、验收和阶段门禁仍须满足
全部受影响角色
项目Hub
Y.4B拒绝:仍需该成果返回主责角色生成文件或补充证据
成果主责角色
ID触发条件发送 → 接收正式载荷约束/确认门禁与版本结果
Y.1主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。主责角色 → 项目Hub成果类型、阶段、原因、事实证据、适用范围、替代成果、下游影响、风险和负责人确认。只有该成果主责角色可发起;“暂时来不及”不属于不适用。进入豁免审查,此时仍需要该成果。
Y.2中心收到豁免申请。项目Hub → 主责角色资格校验、结构校验、补充问题或不可豁免的事实依据。安全、法规和核心验收证据可明确为不可豁免。资料缺口退回补正;最终批准或拒绝仍由项目负责人确认,门禁不提前放行。
Y.3项目Hub已校验并汇总豁免申请、事实证据、替代方案和影响。项目负责人(项目Hub对应真人负责人) → 项目Hub(记录人工决定)成果类型、项目范围、基线引用、批准或拒绝决定、确认人、确认时间、附加条件及失效条件。所有成果豁免必须由项目负责人明确批准或拒绝;沉默、AI 判断或形式校验不算批准。取消独立的下游征询与业务确认环节,不改变不可豁免要求,也不伪造专业或验收结论。批准后登记;拒绝或未确认时仍需该成果。
Y.4A豁免批准。项目Hub → 全部受影响角色已豁免状态、豁免记录、替代成果和附加条件。不能删除原必需项;保留豁免记录。项目范围或输入基线变化时自动失效并重新评估。仅满足被豁免的文件要求,其他测试、验收和阶段门禁仍须满足。
Y.4B豁免拒绝或附加条件未满足。项目Hub → 主责角色拒绝理由、必须生成的成果、补充证据和期限。主责角色仍须输出正式文件。仍需该成果,阶段继续阻塞。