493 lines
77 KiB
HTML
493 lines
77 KiB
HTML
<!doctype html>
|
||
<html lang="zh-CN">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
<meta name="color-scheme" content="light">
|
||
<link rel="icon" href="data:,">
|
||
<title>Codex 多角色项目推进总流程图|V2.1</title>
|
||
<style>
|
||
:root{--ink:#182d42;--muted:#586b7b;--navy:#112e49;--blue:#236fa3;--teal:#087f7a;--amber:#95601b;--line:#d9e3e9;--paper:#f3f6f8;--soft:#eaf5f3}
|
||
*{box-sizing:border-box}html{scroll-behavior:smooth;scroll-padding-top:24px}body{margin:0;background:var(--paper);color:var(--ink);font:16px/1.75 "Microsoft YaHei","PingFang SC",system-ui,sans-serif}a{color:var(--blue);text-underline-offset:3px}h1,h2,h3,p{margin-top:0}h1{font-size:clamp(30px,4vw,48px);line-height:1.35;margin-bottom:20px}h2{font-size:26px;line-height:1.45;margin-bottom:16px}h3{font-size:18px;margin-bottom:10px}p{margin-bottom:12px}ul,ol{margin:10px 0;padding-left:24px}li+li{margin-top:6px}strong{font-weight:700}
|
||
.hero{background:linear-gradient(120deg,#102b44,#18536c);color:white;padding:54px 32px 42px}.hero-inner,.wrap{max-width:1160px;margin:auto}.eyebrow{font-size:13px;letter-spacing:2px;opacity:.82;margin-bottom:16px}.hero p{max-width:850px;color:#deedf4;font-size:18px}.badge{display:inline-block;padding:5px 12px;border:1px solid #81b2c6;border-radius:6px;margin:12px 8px 0 0;font-size:14px}.wrap{padding:28px 24px 60px}.section{background:white;border:1px solid var(--line);border-radius:12px;padding:30px;margin-bottom:24px}.note{border-left:4px solid var(--teal);background:var(--soft);padding:16px 20px;margin:18px 0}.note.warn{border-color:#c58b37;background:#fff5e7}.small{font-size:14px;color:var(--muted)}.kicker{color:var(--teal);font-weight:700;font-size:13px;letter-spacing:1px;margin-bottom:8px}.nav{display:flex;flex-wrap:wrap;gap:9px;margin:18px 0 0}.nav a{background:#f0f5f8;border:1px solid var(--line);border-radius:5px;padding:6px 11px;text-decoration:none;font-size:14px}.nav a:hover{background:#e0eef4}
|
||
.cycle{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:14px;margin:22px 0}.step{border:1px solid var(--line);border-radius:8px;padding:18px;background:#f7fafb}.step .num{color:var(--teal);font-size:13px;font-weight:bold;margin-bottom:8px}.step h3{margin-bottom:6px}.step p{font-size:14px;color:var(--muted);margin-bottom:0}.step:last-child{border-color:#9bc9c3;background:var(--soft)}
|
||
.table-wrap{overflow-x:auto;margin:18px 0}table{width:100%;border-collapse:collapse;font-size:14px}th,td{padding:13px 14px;text-align:left;vertical-align:top;border:1px solid var(--line)}th{background:#edf3f6;color:#27465d;font-weight:700}td:first-child{font-weight:600}caption{text-align:left;font-weight:700;margin-bottom:10px}.overview td:first-child{width:17%}.overview td:nth-child(2){width:20%}.overview td:nth-child(3){width:36%}.flow-title{display:flex;align-items:center;gap:16px;margin-bottom:14px}.stage-num{flex:0 0 auto;display:grid;place-items:center;width:48px;height:48px;background:var(--navy);color:white;border-radius:9px;font-size:22px;font-weight:bold}.flow-title h2{margin-bottom:0}.owner{color:var(--muted);margin-bottom:20px}.triplet{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:16px;margin:18px 0}.pane{border:1px solid var(--line);border-top:3px solid var(--blue);padding:18px;border-radius:7px}.pane:nth-child(2){border-top-color:var(--teal)}.pane:nth-child(3){border-top-color:#c58b37}.pane h3{font-size:17px}.pane p,.pane li{font-size:15px}.pane ul{padding-left:20px}.pane p:last-child{margin-bottom:0}.detail{padding-top:12px;border-top:1px solid var(--line);margin-top:18px}.gate{background:var(--soft);padding:15px 18px;border-radius:7px;margin-top:18px}.gate strong{color:#066660}.tag{font-size:12px;border-radius:4px;padding:3px 7px;background:#eef4f7;white-space:nowrap;margin-left:6px}.back{display:block;text-align:right;font-size:13px;margin-top:18px}footer{color:var(--muted);font-size:14px;text-align:center;padding:10px 24px 30px}.template td:first-child{width:23%}
|
||
@media(max-width:800px){.cycle,.triplet{grid-template-columns:1fr 1fr}.triplet .pane:last-child{grid-column:1/-1}.wrap{padding:20px 16px 40px}.section{padding:24px}.hero{padding:36px 24px}table{min-width:700px}.template{min-width:540px}}
|
||
@media(max-width:520px){.cycle,.triplet{grid-template-columns:1fr}.triplet .pane:last-child{grid-column:auto}.section{padding:20px}.hero{padding:30px 20px}.flow-title{gap:12px}h2{font-size:23px}.stage-num{width:42px;height:42px;font-size:20px}.hero p{font-size:16px}}
|
||
@media print{html{scroll-behavior:auto}body{background:white;font-size:11pt}.hero{background:white;color:var(--ink);padding:18px 0}.hero p{color:var(--muted)}.badge{border-color:var(--line)}.wrap{max-width:none;padding:0}.section{border-radius:0;padding:18px 0;margin:0;border-width:0 0 1px}.nav,.back{display:none}h1{font-size:25pt}h2{font-size:18pt}.table-wrap{overflow:visible}table{min-width:0;font-size:9pt}th,td{padding:7px}.triplet,.cycle{display:block}.pane,.step{margin-bottom:10px;break-inside:avoid}.flow-title,.gate,.note,h3{break-inside:avoid}thead{display:table-header-group}tr{break-inside:avoid}a{color:inherit}footer{padding:16px 0}}
|
||
</style>
|
||
</head>
|
||
<body>
|
||
<header class="hero" id="top">
|
||
<div class="hero-inner">
|
||
<div class="eyebrow">CODEX · 多角色项目流程 · V2.1</div>
|
||
<h1>中心下发任务,真人交付结果<br>按八个阶段推进项目</h1>
|
||
<p>真人角色负责组织和完成工作,提交完成情况与结果性资料。中心整理结果,由中心真人项目负责人决定进入下一环节、补充、退回或暂缓。</p>
|
||
<span class="badge">保留八阶段</span><span class="badge">真人角色负责执行与提交</span><span class="badge">中心真人负责人决定推进</span>
|
||
</div>
|
||
</header>
|
||
<main class="wrap">
|
||
<section class="section" id="version">
|
||
<div class="kicker">版本与适用范围</div>
|
||
<h2>V2.1:补齐排期、成果确认、归档和结项规则</h2>
|
||
<p><strong>编制日期:2026-10-20。</strong>本版依据 YT42-Test2《流程更新》截至 2026-10-20 的已确认规则,在 V2.0 八阶段结构上补充阶段汇报、需求交接、工时与周期评估、预排期维护、成果查看、Bug 双方确认、完整归档及关闭后的登记要求。</p>
|
||
<p>沿用真人角色组织执行、提交专业结果,中心真人负责人决定推进的分工。项目中的人名、型号、日期、工时、问题数量、单次放行和豁免决定留在项目记录中;其他项目依据自身需求、授权和有效基线执行。</p>
|
||
<div class="note"><strong>当前固定路径采用 V2.1,历史版本通过 Git 保留。</strong>本轮已按授权同步<a href="../ep-hub/SKILL.md">中心业务 Skill</a>、记录模板及通知脚本说明。仓库更新不等于已发布、安装或迁移在途项目;Etunel 配置与通信仍使用 etunel-use。</div>
|
||
<p class="small">历史对照:<a href="https://git.playones.com/chenmingxuan/EP-Hub-Skill/src/commit/3fb9c0658de56c3914f5b27c2df1f415bd73661d/doc/Codex多角色项目推进总流程图.html">V1.0 原流程文档(Git 历史)</a>。模板来源:<a href="文档模板参考/README.md">文档模板参考</a>。旧文档中的过程节点用于历史对照;各项目按已确认采用的流程版本执行;本页展示 V2.1 的任务与结果要求。</p>
|
||
<nav class="nav" aria-label="文档导航">
|
||
<a href="#rules">共同规则</a><a href="#reporting">阶段汇报</a><a href="#notifications">阶段群总结</a><a href="#records">成果与过程留档</a><a href="#overview">八阶段总览</a><a href="#stage1">01 业务需求</a><a href="#stage2">02 产品定义</a><a href="#stage3">03 方案设计</a><a href="#stage4">04 项目规划</a><a href="#schedule-template">预排期格式</a><a href="#stage5">05 软硬件实现</a><a href="#stage6">06 测试验证</a><a href="#stage7">07 内部/外部验收</a><a href="#stage8">08 复盘结项</a><a href="#exceptions">变更与阻塞</a><a href="#templates">任务与提交格式</a>
|
||
</nav>
|
||
</section>
|
||
|
||
<section class="section" id="rules">
|
||
<div class="kicker">各阶段统一采用的工作方式</div>
|
||
<h2>下发任务 → 真人执行 → 提交结果 → 中心确认</h2>
|
||
<div class="cycle" aria-label="各阶段统一任务循环">
|
||
<div class="step"><div class="num">01 · 中心</div><h3>下发任务</h3><p>明确主责真人角色、有效输入、任务范围、完成时间、结果资料和完成条件。</p></div>
|
||
<div class="step"><div class="num">02 · 真人角色</div><h3>组织并完成工作</h3><p>自行安排工作、评审、自查和协作;是否使用 Agent 以及如何使用,由真人角色决定。</p></div>
|
||
<div class="step"><div class="num">03 · 真人角色</div><h3>提交完成情况与资料</h3><p>提交专业结论、实际成果及版本、完成情况、必要授权结论和遗留问题。</p></div>
|
||
<div class="step"><div class="num">04 · 中心</div><h3>确认是否推进</h3><p>中心 Agent 整理结果,中心真人负责人决定推进、补充、退回或暂缓,并留下记录。</p></div>
|
||
</div>
|
||
<p>这个循环适用于每项任务和阶段收口。同一阶段可有多项任务,每项任务只有一个主责真人角色。单项任务被接受后,可启动依赖已经满足的后续任务;跨阶段推进须取得中心真人负责人明确决定;已有条件授权的,条件实际满足后按原范围执行并登记依据,不重复申请同一批准。推进不把未交或待确认成果改写为已完成。</p>
|
||
<div class="note"><strong>成果不能如期交付时:</strong>真人角色可提交中心真人负责人确认,说明待交成果、延期原因、影响及计划交付时间。真人确认后,由中心 Agent 记录待交项、责任人、新交付时间和确认决定;在每个阶段结束时提醒中心真人负责人及相关责任角色,直至交付或另有明确处理决定。是否推进由中心真人负责人依据实际影响决定,延期成果仍记为未交付。</div>
|
||
<div class="table-wrap"><table>
|
||
<caption>谁负责什么</caption>
|
||
<thead><tr><th>主体</th><th>主要责任</th><th>决定范围</th></tr></thead>
|
||
<tbody>
|
||
<tr><td>中心真人项目负责人</td><td>组织项目推进,明确任务与阶段完成条件,处理项目级协调,依据提交结果决定下一步。</td><td>阶段推进、补充、退回、暂缓,以及成果豁免;保留其他角色的专业决定和业务授权范围。</td></tr>
|
||
<tr><td>中心 Agent(项目Hub)</td><td>协助整理任务、完成情况、成果索引、版本、遗留问题和进度;记录真人决定并协调后续任务。</td><td>不代替真人批准,不代写专业结论,不逐项核实角色内部工作步骤。</td></tr>
|
||
<tr><td>各专业真人角色</td><td>对任务执行、专业评审、自查、结果真实性和正式提交负责;自行组织所需协作。</td><td>在本角色职责内给出专业结论;涉及其他专业或授权事项,取得相应有权角色的结论并随结果提交。</td></tr>
|
||
<tr><td>角色 Agent(按需使用)</td><td>按真人角色安排协助工作;不构成接收或提交任务的必经环节。</td><td>不替真人确认或批准;成员 Agent 跨角色信息仍交中心定向中继。</td></tr>
|
||
</tbody>
|
||
</table></div>
|
||
<h3>执行过程由真人角色负责</h3>
|
||
<ul>
|
||
<li>中心不要求角色逐步汇报,也不对每一项内部评审、操作或细节设置单独的 Agent 核实任务。必要的专业检查仍由真人角色组织完成。</li>
|
||
<li>任务交付渠道不强制限定为 Etunel 角色会话。只需真人角色实际收到任务,并让最终提交和中心决定可追踪;工具显示已发送不等于真人已接收或任务已完成。</li>
|
||
<li>真人角色可直接开展必要的线下沟通与专业协作。使用多个角色 Agent 时,其跨角色任务、问题和结论仍由中心中继,不开放成员 Agent 直连。</li>
|
||
<li>只有影响任务完成的阻塞、跨任务依赖冲突或需要中心决定的变更,才在执行中提交中心。专业角色能够在既定任务范围内解决的问题,由其自行处理。</li>
|
||
<li>必要的专业结论、授权和验收结果随成果一并提交;中心依据结果判断,不把这些工作再次拆成逐项确认回路。</li>
|
||
</ul>
|
||
<h3>中心按结果确认</h3>
|
||
<ul>
|
||
<li>中心 Agent 将提交内容与下发的完成条件对应,整理已完成项、缺失项、成果与版本、专业结论、必要授权、依赖和剩余风险,交中心真人负责人决定。</li>
|
||
<li>请求中心真人确认成果前,逐项提供本次范围涉及的全部有效文件名、版本、确认用途及可点击完整地址,或直接展示对应文件。已有索引可引用,但须能定位本次涉及的各份文件;不能只给总目录、摘要或中心确认记录。</li>
|
||
<li>沿已有成果身份和真实入口交接;包内内容可引用有效索引,缺项和可访问范围如实说明。只补入口时不重复申请已有效的结果确认,不编造路径或声称尚未提供的文件已供查看。</li>
|
||
<li>可读可用和专业结论由有权真人确认。Agent 无法访问成员磁盘或共享目录,只说明本端访问失败,不据此判定未提交、文件不存在或成果不兼容;不把 Agent 下载、解包、截图或重算哈希设为固定推进前置。</li>
|
||
<li>中心可以针对影响完成判断的缺口提出补充要求,说明缺什么、影响什么;不要求证明全部工作过程或重复提交同一有效资料。</li>
|
||
<li>中心真人负责人决定推进时,明确接受的结果、版本和适用范围。退回或暂缓时,明确原因、待处理事项、责任角色及下一步。</li>
|
||
<li>测试结论与版本放行决定分别记录。测试不通过时,项目、产品双方真人可共同确认核实,以核实结论作为版本放行依据;保留原测试结论,并记录版本、未通过项、影响、放行条件及双方确认。外部验收结果和预算授权仍由有权角色确认。</li>
|
||
<li>文件或需求有差异时,由有权真人明确采用内容、对象、版本和影响范围。当前文件同步、过去审阅对象和差异对既有结论的影响分别记录,不补造历史审阅事实。</li>
|
||
<li>同一成果、版本和范围的有效确认继续沿用。只有实质变化、用途超出原范围或出现相反证据时,才补充相应结果和确认;尚未完成或未经真人确认的材料只进入过程记录。</li>
|
||
</ul>
|
||
<div class="note"><strong>八个默认角色保持不变:</strong>项目Hub(中心)、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试。阶段 4、8 由中心真人负责人组织,相关真人角色提供具体工作与结果,中心 Agent 协助整理。新增角色仍须先明确职责契约,由中心真人负责人完成实际配置。</div>
|
||
<p class="small">一个项目使用一个持续的中心贯穿生命周期。使用 Etunel 时,其运行时继续负责投递、队列、重试、去重、会话授权和文件传输,本流程不另设软件机制。钉钉仅用于已授权的辅助通知,通知不替代任务提交、批准、验收或项目事实记录。</p>
|
||
<a class="back" href="#top">返回顶部 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="reporting">
|
||
<div class="kicker">先汇报结果,再决定阶段安排</div>
|
||
<h2>中心主动提交阶段成果汇总</h2>
|
||
<p>本阶段任务均取得所需真人完成确认后,中心 Agent 须主动在中心持续聊天提交汇总。成果已交但必要确认未齐,或仍有未完成、延期、拟承接事项需要中心判断时,同样提交汇总;成果、版本、确认或遗留发生实质变化时补充说明。仅更新本地记录不算已向中心真人汇报。</p>
|
||
<div class="table-wrap"><table><caption>汇报中逐项说明什么</caption><thead><tr><th>内容</th><th>必须说明</th></tr></thead><tbody>
|
||
<tr><td>阶段概况</td><td>项目、阶段、汇报日期;全部确认完成、部分完成或已交待确认;本次需要的决定。</td></tr>
|
||
<tr><td>任务与成果</td><td>唯一主责真人、必需/选填、适用完成条件、应交/已交、版本及有效文件入口;成果包说明内容与缺项。</td></tr>
|
||
<tr><td>确认与时间</td><td>确认人、真实确认时间、对象/版本、结论、范围及条件;原计划、当前计划、提交与确认后实际完成时间。</td></tr>
|
||
<tr><td>未完成与待确认</td><td>实际状态、原因/依赖、负责人、原计划与当前计划、影响、必须完成阶段及补齐或承接建议。选填未交、豁免、取消分别说明。</td></tr>
|
||
<tr><td>提请决定</td><td>接受哪些结果;推进、补充、退回或暂缓;第八阶段为是否关闭。建议与真人决定分开记录。</td></tr>
|
||
</tbody></table></div>
|
||
<div class="note"><strong>没有遗留时明确写:</strong>“未完成项:无;待确认项:无”。有任何未完成或待确认事项时,如实列出。选填未交不自动阻塞,也不需要豁免;外部平台要求另按实际判断。</div>
|
||
<p>中心决定后,沿原任务登记决定人、日期、范围、条件和下一步。带遗留推进仍保留未完成状态;阶段八保留业务结项结论和其他必要确认。尚无决定时,阶段安排保持待决定。</p>
|
||
<a class="back" href="#templates">查看汇报格式 ↓</a>
|
||
</section>
|
||
|
||
<section class="section" id="notifications">
|
||
<div class="note">阶段内已授权的关键进展、阻塞和失败通知继续保留,同轮合并;阶段交接固定合为一条,等待推进决定时先在中心会话汇报,实际关闭后发一次结项总结。</div>
|
||
<div class="kicker">项目已授权启用后执行</div>
|
||
<h2>每次阶段交接发送一条群总结</h2>
|
||
<ul>
|
||
<li>中心真人明确同意推进,或已有条件授权实际满足后,将上一阶段总结与下一阶段安排合成一条发送;等待决定时,先在中心持续聊天汇报,不提前写已进入下一阶段。</li>
|
||
<li>阶段八明确结项关闭后发送一次结项总结,说明最终成果、实际关闭结论,以及仍需跟进的遗留、责任和已确认安排。</li>
|
||
<li>首次须由中心真人确认发送账号、目标群和通知范围;账号或群变更时重新确认。在已确认范围内执行,不因每次交接重复申请同一授权。</li>
|
||
<li>先更新事实记录,再发送。写清已确认成果、未完成/待确认事项、实际推进决定,以及下一阶段已确认任务、负责人和期限;未知写待确认,不把通用职责写成本轮已派任务。</li>
|
||
<li>每条信息及子条目单独换行,用直接、自然的语言保留责任人、时间、条件和实际状态;总结及发送结果留在阶段过程记录,避免同一交接重复发送。</li>
|
||
<li>通过已确认的项目通知入口执行。请求已接受、投递成功和已读分别记录,不能代替真人接收、完成或验收;失败不阻塞主任务,结果未知时不盲目重发。</li>
|
||
</ul>
|
||
<a class="back" href="#top">返回顶部 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="records">
|
||
<div class="note"><strong>计划主表与日期口径:</strong>已有项目沿用已确认的唯一主表,新项目默认使用可编辑 Excel 八列模板,Markdown 进度只保留摘要和入口。模板不预填日期、工时、人数或迭代轮数。条件授权日期、条件实际满足日期和实际切换日期分别记录,阶段交接管理日期取实际切换日期。实际执行据真实回报更新并保留来源和历史,改动已确认日期、范围或资源安排由有权真人确认;日常状态更新不重批整表。</div>
|
||
<div class="kicker">八阶段共同采用的留档规则</div>
|
||
<h2>正式成果只留最终版与确认记录</h2>
|
||
<h3>正式成果区</h3>
|
||
<ul>
|
||
<li>保存各真人角色完成并确认后的全部有效成果及配套资料,包括文档、固件、硬件资料及其他约定产出。正式区须有有效原件/成果包,或真实完整外部入口及对应确认;不能仅放概括目录或中心确认记录,就称全部资料已归档。</li>
|
||
<li>每项成果只登记一个最终有效版本,并保留该版本对应的真人确认记录。</li>
|
||
<li>正式成果条目只列成果名称、最终版本、文件位置或链接地址;确认记录分条列出确认人、确认时间、对应成果与版本、确认结论及范围和条件。</li>
|
||
<li>未完成项、待确认材料、候选固件、草稿及旧版不登记为最终正式成果;中心 Agent 整理、生成或收到文件均不等于真人确认。</li>
|
||
<li>同一文件或连贯成果包可以承载多个结果,不为凑齐名称另造文件。文件名含“草稿”“预览”时,正式状态以有效真人确认和实际采用决定为准,保留确认对象及原提交来源。</li>
|
||
<li>成果文件正文按真人确认的最终版本保存,不因记录分区而删改成果内容。</li>
|
||
</ul>
|
||
<h3>过程记录区</h3>
|
||
<ul>
|
||
<li>旧版成果、草稿和对应的历史确认保留在过程记录中,不删除历史资料,不覆盖旧文件。</li>
|
||
<li>任务要求、输入基线、完成情况、评审意见、修订过程、退回原因、风险、延期、阻塞及下一步分条保存。</li>
|
||
<li>中心的推进、退回、暂缓、版本放行和豁免决定保存为过程记录,关联最终成果与必要真人确认。</li>
|
||
<li>成果实质变化后,新版经真人完成并确认,再替换正式成果区的当前条目;旧版、旧确认与替代关系转入过程记录留存。</li>
|
||
<li>各阶段已约定的《变更记录》《流程闭环总结》等交付文档,真人完成并确认后的最终文件仍是正式成果;其草稿与编写过程放入过程记录。</li>
|
||
</ul>
|
||
<h3>成果中的链接</h3>
|
||
<ul>
|
||
<li>正式成果通过链接交付,或成果中含有相关链接时,记录链接地址即可。</li>
|
||
<li>外部成果登记真实完整入口、用途、版本及对应确认,不强制下载或复制全部外部文件,也不要求另作链接摘要或截图。</li>
|
||
<li>项目已明确授权本地复制归档时,将已取得且确认有效的原件及配套资料按阶段、成果分类复制到正式区,保留原交接资料、历史入口和路径映射;目录、索引及汇总改指正式位置。</li>
|
||
<li>复制或补地址日期单独记录,不替换原提交、采用、确认、实际完成或阶段起止日期;归档位置变化不重新申请已有有效确认。</li>
|
||
<li>成果对应的真人确认仍单独保留;链接内容的核实由真人角色负责,不因留档增加中心逐项核实任务。</li>
|
||
</ul>
|
||
<h3>所有阶段记录都分条展示</h3>
|
||
<ul>
|
||
<li>每个阶段按“正式成果及确认记录”和“过程记录”两个栏目展示,分开登记。</li>
|
||
<li>一项成果单列一条;每项确认、决定、待办和风险分别列条目,不打包成一个自然段。</li>
|
||
<li>同一事项的时间、责任人、内容、影响和下一步分别列子项,便于阅读和跟进。</li>
|
||
<li>阶段结束时,只把最终成果及确认列入正式成果小结;延期提醒、未决项和后续安排列入过程记录。</li>
|
||
</ul>
|
||
<p class="small">正式成果区和过程记录区分别对应阶段目录中的 <code>正式成果/</code> 与 <code>过程记录/</code>;<code>阶段记录.md</code> 按两个栏目分条展示。阶段 4、8 由中心真人负责人组织完成的成果也须经对应真人确认后,才登记最终版。</p>
|
||
<h3>项目、阶段与任务分别记录</h3>
|
||
<ul>
|
||
<li><strong>项目层:</strong>记录当前阶段、整体进度和当前需要处理的事项;未按期完成的事项持续列出原计划、当前有效计划、未完成原因、影响范围及必须完成的阶段。整体进度用阶段状态和关键成果说明,百分比须有已确认的计算依据。项目计划主表由中心按实际回报维护,Markdown 项目进度同步摘要;不另建一套重复任务。</li>
|
||
<li><strong>阶段层:</strong>逐项汇总本阶段每个任务的成果、完成及确认情况,分别列负责人、应交与已交成果、版本与位置、时间、缺口、下一步和任务原记录入口。未完成和待确认情况归入过程栏目。</li>
|
||
<li><strong>任务层:</strong>按可独立确认的交付结果或同一负责人的内聚任务包,一项一份 Markdown;前部维护现状,后部按时间追加接收、提交、退回、确认、改期等关键历史,不记录角色内部每一步操作。</li>
|
||
<li><strong>跨阶段:</strong>同一事项沿用所属阶段的原记录,涉及阶段引用,项目层持续跟进;完成或明确处置后保留历史,承接后仍需跟进的继续显示。</li>
|
||
<li><strong>三类时间:</strong>原计划保留首次确认期限,当前计划保留最新经确认的有效期限,每次改期保留旧值、新值、原因和真人决定;实际完成时间是任务提交后经对应真人明确确认完成的时间。提交时间另记,未确认写“尚未确认完成”,取消或豁免不写为实际完成。</li>
|
||
<li><strong>线下确认:</strong>接受中心真人明确转述的线下接收和确认事实,保留实际确认人、真实时间、对象与版本、结论、范围和条件,以及转述人、来源和补录时间;不新增截图、审批单或重复确认。</li>
|
||
<li><strong>阶段管理日期:</strong>开始取中心真人实际启用该阶段的日期,完成取明确结束/进入下一阶段的决定日期,第八阶段取明确关闭日期。进行中时完成日期留空;工程开工、测试、验收发生日期另记,不用管理日期计算工程提前/延期或总人时。</li>
|
||
<li><strong>提交与接收:</strong>本人明确已通过其他渠道提交时据实登记,入口未给、接收可用未确认及验收结论未取得分别说明,不因本聊天无附件回退成未提交。队列待投递不推翻线下已完成事实,也不按队列等待时长判定工程延期。</li>
|
||
<li><strong>记录更新顺序:</strong>先更新原任务,再同步阶段摘要、项目进度及适用成果索引;需要决定或通知时,使用已更新的事实。未知不填零、不造时间、负责人、地址、专业结论或签名。</li>
|
||
<li><strong>易读排版:</strong>标题后用一句话说明现状,各栏目分条、字段加粗、留出空行,详细历史置后;链接使用明确名称,未知信息如实标明。</li>
|
||
</ul>
|
||
<a class="back" href="#templates">查看分条记录格式 ↓</a>
|
||
</section>
|
||
|
||
<section class="section" id="overview">
|
||
<div class="kicker">八阶段总览</div><h2>每阶段都以提交结果和中心决定收口</h2>
|
||
<div class="note"><strong>正常顺序:</strong>业务需求 → 产品定义 → 方案设计 → 项目规划 → 嵌入式软硬件实现 → 测试验证 → 内部/外部验收 → 复盘结项。测试不通过时,可安排修复、复验,也可由项目、产品双方真人核实后作出版本放行结论;验收问题回到受影响环节处理,不要求从头重启。</div>
|
||
<p>各阶段开始时,中心说明本阶段必须完成、后续阶段处理、当前不需要的内容。任务只覆盖当前必需项;后续资料不提前成为当前阶段的完成条件。阶段结束或需要中心判断安排时,先按<a href="#reporting">阶段汇报要求</a>提交成果、确认、遗留和有效入口,再取得推进决定。</p>
|
||
<div class="table-wrap"><table class="overview">
|
||
<thead><tr><th>阶段</th><th>真人工作责任</th><th>提交的正式成果</th><th>中心决定推进的结果依据</th></tr></thead>
|
||
<tbody>
|
||
<tr><td><a href="#stage1">01 业务需求</a></td><td>业务主责,产品参与需求对齐</td><td>业务需求(包含项目背景说明、客户里程碑要求)</td><td>业务与产品形成一致的需求基线,产品具备继续定义的输入。</td></tr>
|
||
<tr><td><a href="#stage2">02 产品定义</a></td><td>产品主责,相关专业角色参与</td><td>立项资料(含风险);测试验收标准;里程碑要求</td><td>产品定义完整,业务范围已批准,验收标准可判断。</td></tr>
|
||
<tr><td><a href="#stage3">03 方案设计</a></td><td>技术负责人组织方案工作;测试编制计划</td><td>测试计划;总体技术方案(选填)</td><td>方案与接口可实施、需求未偏离、测试可验证;技术负责人认可测试计划。</td></tr>
|
||
<tr><td><a href="#stage4">04 项目规划</a></td><td>中心真人负责人组织,相关真人角色提供评估</td><td>项目计划;角色分工;项目状态内部记录</td><td>专业评估与技术依赖明确,中心统筹总排期,产品授权范围内的具体事项及必要业务授权已确认,首批任务可执行。</td></tr>
|
||
<tr><td><a href="#stage5">05 嵌入式软硬件实现</a></td><td>应用层、底层、硬件分别主责任务;技术负责人给出集成结论</td><td>硬件设计包;嵌入式底层实现资料;嵌入式应用层固件包</td><td>适用成果齐备,技术负责人确认最终软硬件版本匹配、可提测。</td></tr>
|
||
<tr><td><a href="#stage6">06 测试验证</a></td><td>测试主责;修复任务由相应实现角色主责</td><td>功能测试报告;缺陷链接(选填,不交缺陷清单文件);可靠性测试报告、专项测试报告、提测佐证(选填)</td><td>测试提交真实结论与依据;通过时由中心真人负责人确认推进,不通过时可依据项目、产品双方核实的版本放行结论推进。</td></tr>
|
||
<tr><td><a href="#stage7">07 内部/外部验收</a></td><td>项目组织;内部验收任务交真人角色;外部验收结果由产品/业务确认</td><td>内部验收结果记入验收记录;平台验收报告或结论;客户验收通过报告;遗留问题清单</td><td>本阶段约定的内部验收完成,外部验收取得对应产品/业务确认,版本一致,问题和风险有承接。</td></tr>
|
||
<tr><td><a href="#stage8">08 复盘结项</a></td><td>中心真人负责人组织;各角色提供归档与复盘输入</td><td>结项资料归档;变更记录;结项报告;流程闭环总结</td><td>归档完整、复盘完成,Bug 处理或承接经中心和产品双方确认,业务确认结项,中心真人负责人决定关闭。</td></tr>
|
||
</tbody>
|
||
</table></div>
|
||
<div class="note warn"><strong>必需与选填按本版各阶段说明执行。</strong>选填成果未提交不阻塞推进,无需豁免;已提供时登记版本和专业结论。缺陷信息以选填链接提供,不提交缺陷清单文件。可靠性测试报告、专项测试报告、提测佐证是否提交,由中心真人负责人决定,已有有效决定可沿用。必需成果不能如期交付时,提交真人确认、记录并逐阶段提醒;不适用或豁免另按对应规则处理。</div>
|
||
<a class="back" href="#top">返回顶部 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage1" data-stage="1">
|
||
<div class="flow-title"><span class="stage-num">01</span><h2>业务需求</h2></div>
|
||
<p class="owner">业务真人角色主责;产品真人角色参与需求对齐。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>交业务整理项目背景、客户目标、需求范围和客户里程碑,明确交付一份《业务需求》文档,并确认交付时间。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>业务自行核实客户资料并与产品对齐,提交一份《业务需求》文档,包含项目背景说明、客户里程碑要求,说明双方一致的需求基线、未决事项和日期性质。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理需求范围、资料版本和影响当前定义的缺口;</li><li>中心真人负责人依据业务与产品的一致结论,决定启动产品定义或退回补充。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>《业务需求》中的项目背景说明区分对接客户与最终客户,写明业务对象、目标与范围;预期价值、订单及预计销售额选填,不强制成功指标。</li>
|
||
<li>《业务需求》中的客户里程碑要求包含提测、入库时间;小批量试产、量产时间选填。客户期望日期与已批准的正式承诺分开说明。</li>
|
||
<li>需求对齐和资料核实由业务、产品真人完成,中心不逐项下发澄清确认任务;不增加早期风险预检作为固定前置条件。</li>
|
||
</ul></div>
|
||
<div class="gate"><strong>进入阶段 2:</strong><ul><li>业务与产品确认同一需求基线,影响该基线的冲突已处理,产品具备继续定义的输入;</li><li>中心真人负责人明确同意推进。</li></ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage2" data-stage="2">
|
||
<div class="flow-title"><span class="stage-num">02</span><h2>产品定义</h2></div>
|
||
<p class="owner">产品真人角色主责;业务、技术负责人、实现与测试真人角色按实际需要参与。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>交产品依据业务基线完成立项资料、测试验收标准和里程碑要求;</li><li>给出当前范围、上游资料和成果要求,风险体现在立项资料中。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>产品自行组织可行性、可测试性和实现约束评审,完成修订,取得业务对客户范围和验收边界的批准,汇总提交《立项资料》《测试验收标准》《里程碑要求》三类成果及专业结论。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理产品基线、业务授权和验收条件;</li><li>中心真人负责人依据提交结果决定启动方案设计或补充当前必需内容。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>《立项资料》包含立项书、功能清单、产品规格书等,风险体现在立项资料中,不单独形成《项目风险》成果;《测试验收标准》包含平台测试用例、客户验收测试用例和验收标准。</li>
|
||
<li>《里程碑要求》包含提测、客户验收时间,试产与量产时间选填;产品在《立项资料》中汇总并维护技术风险、时间风险及其他风险。</li>
|
||
<li>结构板框图在本阶段选填,后续硬件任务需要时补齐;模板中人力和费用属于早期估算,不代替正式资源、排期或预算授权。</li>
|
||
<li>各专业评审由真人角色组织,产品在提交中汇总结论,不要求中心逐轮中转并确认每条评审意见。</li>
|
||
</ul></div>
|
||
<div class="gate"><strong>进入阶段 3:</strong><ul><li>产品定义已确认、业务范围已批准,直接影响本阶段的约束已处理,验收标准可判断;</li><li>后续依赖如实登记,由中心真人负责人决定推进。</li></ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage3" data-stage="3">
|
||
<div class="flow-title"><span class="stage-num">03</span><h2>方案设计</h2></div>
|
||
<p class="owner">技术负责人真人组织方案与接口收口;测试真人主责编制《测试计划》。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>依据产品基线,向技术负责人下发方案收口任务,向测试下发测试计划任务;</li><li>相关实现角色的任务按实际需要确定,明确各项主责和输入关系。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>技术负责人自行组织方案、接口和可实施性评审,产品给出需求一致性结论,测试提交《测试计划》;</li><li>提交时一并提供技术负责人对方案和测试计划的确认结论。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理方案结论、测试计划及当前未解决的约束;</li><li>中心真人负责人判断是否具备项目规划条件,不再逐个要求角色 Agent 确认同一细节或重复版本。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>《测试计划》必需,包含测试标准、测试用例范围和测试项,由测试编制与维护、技术负责人认可。</li>
|
||
<li>《总体技术方案》选填;方案、必要接口约束和专业决定可保留在已有记录中,不因未提交选填方案文件而阻塞。</li>
|
||
<li>应用层的业务模块及应用接口、底层的 BSP/驱动/RTOS/HAL 由对应真人角色处理;硬件器件、PCB、电源、信号、热与接口约束在本阶段选填,已提供时按本领域给出结论。</li>
|
||
<li>不新增独立软硬件接口契约、架构决策记录或本阶段硬件设计包。尚未形成的项目计划不作为方案设计前提。</li>
|
||
</ul></div>
|
||
<div class="gate"><strong>进入阶段 4:</strong><ul><li>方案与接口可实施、需求未偏离、测试可验证,测试计划已有技术负责人的确认结论;</li><li>中心真人负责人决定推进。</li></ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage4" data-stage="4">
|
||
<div class="flow-title"><span class="stage-num">04</span><h2>项目规划</h2></div>
|
||
<p class="owner">中心真人负责人组织;技术负责人、产品及执行真人角色提供任务、依赖、工期和资源评估。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>明确规划目标,将技术结构与依赖、任务工期评估、资源与排期等工作交相应真人角色;</li><li>中心真人负责人负责组织形成计划,中心 Agent 协助汇总。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>相关真人角色完成各自评估,中心真人负责人组织形成《项目计划》《角色分工》《项目状态内部记录》,随结果保留技术结构结论、产品授权范围内具体资源/排期事项的确认及必要业务授权。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理可执行计划、责任分工和待解决约束;</li><li>中心真人负责人确认首批任务的输入与依赖已就绪,决定进入实现阶段。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>项目计划包含实际工作项、工时评估、周期、依赖和排期;中心真人负责人统筹总排期与跨角色资源协调。技术负责人核实技术结构、顺序、并行及依赖,不要求全员重新确认整份计划。</li>
|
||
<li>应用层、底层、硬件开始评估工时时,向三方提供全部有效产品需求文档。各真人明确本人范围、已有成果及剩余工作;未估事项、投入和外部等待分别说明。</li>
|
||
<li>初版单列;迭代轮数不含初版,各轮内容和周期可不同。研发开发、自测与修复,独立测试与回归,以及样机、环境、器件或生产等等待分别记录,保留实际单位和起算条件。</li>
|
||
<li>三领域报开发周期后,汇总给技术负责人核实范围、遗漏/重复、顺序、并行、合版和软硬件依赖;核实无问题后交测试衔接初版、各轮测试和回归周期及资源。测试可以先估自身工作量,再按核实后的研发节奏完善;项目日期由中心真人统筹确认。</li>
|
||
<li>各角色工时沿原任务按工作项以表格记录,列主责真人、原估/当前估及单位、周期与起算条件、投入/等待、提交或确认日期、来源和状态。变更保留旧值、新值、原因及真人确认;未知不填零,工作日不直接换成人日或小时。</li>
|
||
<li>产品只确认对象、权限依据和范围明确的资源/排期事项,不笼统承担全项目、其他专业或工厂周期;相关专业分别提供实际评估。预算、采购或对外承诺由业务批准。已提交的有限输入按原范围登记,不扩大为全部资源已落实。</li>
|
||
<li>角色分工写明每项任务的唯一主责、协作、人员变化和交接。相关执行角色只接收本角色任务所需的计划与资料。</li>
|
||
<li>规划引用阶段 2《立项资料》中的风险内容,不另造风险成果或《产品资料整合》。计划可同步业务,同步回执不增加批准条件。</li>
|
||
</ul></div>
|
||
<div class="detail" id="planning-method"><h3>预排期与实际执行</h3><ul>
|
||
<li>采用<a href="#schedule-template">八列预排期格式</a>,工作项按真实需求、已有成果、剩余工作、依赖及资源增减;不固定套用参考任务数量、迭代轮数、人员、工时或日期。模板预排日期留空,实际编制按专业评估和中心确认填写。</li>
|
||
<li>每项工时为合计人时,不再乘参与人数;人数不代表资源已落实。工时、开发周期、测试周期、投入比例及外部等待保留各自含义;NA、空白保留原义,不转换为零。</li>
|
||
<li>客户目标、内部预计、当前有效计划和实际执行分别记录;里程碑名称、编号及完成条件按实际项目确定。客户验收与量产目标分别跟进,不因一项预计改变自动调整另一项。</li>
|
||
<li>中心按真人实际回报维护唯一计划主表的“实际执行情况”,记录更新日期、进展、实际起止、成果/版本/入口、确认、偏差和下一步;未回报写待登记,不用预排日期代填实际日期。</li>
|
||
<li>改期经中心真人明确确认后更新,原计划、旧值/新值、原因、影响和决定依据沿原任务或阶段记录保留。Markdown 项目进度同步摘要,成果确认沿原记录维护。</li>
|
||
<li>串行、并行与起算条件依据真实依赖确定;表中重叠不直接代表技术依赖、已开工或跨阶段授权。八阶段继续管理成果、确认和归档,每轮测试明确对应固件及硬件版本。</li>
|
||
</ul></div>
|
||
<div class="gate"><strong>进入阶段 5:</strong><ul><li>专业评估及技术依赖已有结论,中心统筹总排期,产品授权范围内的具体事项与必要业务授权完成,首批依赖就绪任务可执行;</li><li>中心真人负责人决定推进。</li></ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage5" data-stage="5">
|
||
<div class="flow-title"><span class="stage-num">05</span><h2>嵌入式软硬件实现</h2></div>
|
||
<p class="owner">硬件、嵌入式底层、嵌入式应用层真人分别负责各自任务;技术负责人给出整体集成与可提测结论。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>按产品、方案和计划,把依赖就绪的设计与实现任务交对应真人角色;</li><li>明确成果包、输入版本、交付时间和下游用途。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>真人角色自行组织设计、实现、自测、合版和联调,分别提交正式成果。</li><li>应用层交唯一最终提测固件,技术负责人提交最终软硬件版本匹配及可提测结论。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理适用成果、版本关系、技术结论和遗留问题;</li><li>中心真人负责人依据结果决定提测,或对具体未满足项退回补充。</li></ul></div>
|
||
</div>
|
||
<div class="table-wrap"><table><caption>实现成果包保持原有内容</caption><thead><tr><th>主责真人角色</th><th>正式成果</th><th>结果资料内容</th></tr></thead><tbody>
|
||
<tr><td>硬件</td><td>硬件设计包</td><td>原理图、PCB 源文档、贴片资料(PCBA_BOM、器件位置图 PDF、贴片坐标)、接口定义。</td></tr>
|
||
<tr><td>嵌入式底层</td><td>嵌入式底层实现资料</td><td>硬件功能测试报告、BSP 输出路径、PSP 输出路径;WiFi 设备定频测试固件选填。</td></tr>
|
||
<tr><td>嵌入式应用层</td><td>嵌入式应用层固件包</td><td>正式/升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书。</td></tr>
|
||
</tbody></table></div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>按实际依赖推进。缺少硬件、软件或环境只阻塞依赖该输入的工作,已具备部分继续执行;到样、整机、PQ、AI 及环境按真人实际回报登记,计划日期和收到输入不证明后续工作已完成。</li>
|
||
<li>硬件真人开始设计前取得实际外设、关键器件规格书及结构板框图;缺失只影响相应硬件任务,需上游协调时向中心提出具体缺口。</li>
|
||
<li>底层提供可消费的 BSP/PSP,应用层负责合版。统一固件与硬件候选就绪后即可组织联调;联调问题关闭后提交最终提测版。</li>
|
||
<li>设计确认、接口协调、自测及联调由真人角色自行完成,中心不逐步核实。最终版本与软硬件匹配关系随结果提交,由技术负责人给出专业结论。</li>
|
||
<li>PSP 仓库/commit、BSP build 及消费入口是版本和输入信息,不直接代替最终固件身份,不把另一构建的结果写到指定最终包。已有配置提供有效 BSP 消费入口且真人明确无需独立获取时,沿原入口衔接,不重复索包或路径。</li>
|
||
<li>已有包身份和真实入口时,定向交相关真人确认可用性;需要补交接时只补实际缺口。Agent 访问失败不恢复为重做实现或反复上传整包的要求。</li>
|
||
<li>底层不直接向测试交最终固件;定频测试固件只用于专项测试。不另设《硬件实现资料》,也不把硬件前置输入重新列为产出。</li>
|
||
</ul></div>
|
||
<div class="gate"><strong>进入阶段 6:</strong><ul><li>适用成果齐备,最终统一固件与硬件版本匹配,技术负责人明确可提测;</li><li>中心真人负责人决定推进。</li></ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage6" data-stage="6">
|
||
<div class="flow-title"><span class="stage-num">06</span><h2>测试验证</h2></div>
|
||
<p class="owner">测试真人负责测试执行、缺陷信息维护与独立质量结论;修复工作由相应实现真人角色主责。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>交测试依据统一固件、版本矩阵和测试计划开展验证,每轮明确固件及硬件版本、变更、必测范围、完成时间与提交要求;</li><li>三类选填资料的提交决定沿用或由中心真人负责人明确。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>测试自行组织策略、执行、缺陷协调和独立复验,提交《功能测试报告》及约定提供的选填资料,缺陷信息可提供链接,不提交缺陷清单文件;</li><li>给出通过/不通过结论、实际覆盖范围和风险。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理本次测试结果、被测版本与质量条件;</li><li>中心真人负责人明确确认或退回测试结果。</li><li>测试不通过时,由项目、产品双方真人确认核实,核实结论可作为版本放行依据;</li><li>中心据此记录放行及阶段推进决定。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>《功能测试报告》必需;缺陷信息以选填链接提供,不要求提交实际缺陷清单资料。无缺陷时在功能报告中说明零缺陷,不要求零缺陷清单或无必要的修复任务。</li>
|
||
<li>功能报告包含测试结论、测试用例执行结果及 bug log。《可靠性测试报告》《专项测试报告》《提测佐证》选填,是否提交由中心真人负责人决定;未提交选填文件不阻塞,不免除必测范围。</li>
|
||
<li>可靠性报告列高低温测试,跌落、防水测试选填;专项报告列适用专项;提测佐证为平台要求的视频、截图和 log。外部平台资料要求与内部选填决定分别记录,不把决定不交写成平台已经接受。</li>
|
||
<li>每次执行、复测或回归前由测试明确本次策略,不增加独立正式文件或额外审批。测试与实际相关真人负责人商议缺陷责任,每项缺陷明确一名责任人和一个主责角色。</li>
|
||
<li>需要修复任务时,将缺陷、主责与修复要求交中心安排;实现角色自行处理定位和修复,提交版本、自测及影响结论。底层修复经应用层重新合版;硬件 ECO 提供底层兼容、应用有效性及版本矩阵更新结果。</li>
|
||
<li>测试独立复验并维护缺陷状态。回归输入为统一固件、版本矩阵及必要变更说明;需要定位或复验具体缺陷时引用对应缺陷链接。只在实际需要时补充定位资料或技术负责人的版本结论,不要求中心逐轮核实修复细节。</li>
|
||
<li>底层实现资料、硬件设计包不作为常规测试必交输入。大文件由测试保管,通过链接交付时,中心只记录链接地址及对应真人确认,不重复上传或复制文件。</li>
|
||
</ul></div>
|
||
<div class="note warn"><strong>测试结果的人工确认保留。</strong><ul><li>测试真人提交后,中心真人负责人须实际查看并明确确认。</li><li>中心 Agent、已读、消息送达或工具任务完成都不能代替确认。</li><li>确认前按实际记为已提交待确认,不宣称测试结果已被接受或已进入正式验收;</li><li>实质变化后的结果或被测版本须重新提交确认。</li></ul></div>
|
||
<div class="note"><strong>测试不通过时的版本放行:</strong><ul><li>项目真人负责人和产品真人负责人共同核实不通过项、实际影响、剩余问题及处理安排,明确该版本是否放行。</li><li>核实结论写明版本、依据、放行范围与条件、遗留责任和双方确认人及时间,作为版本放行依据。</li><li>中心 Agent 保留原“不通过”测试结论,同时记录双方核实结论及后续安排;</li><li>未形成双方明确结论时,不自行放行。</li></ul></div>
|
||
<div class="gate"><strong>进入阶段 7:</strong><ul><li>测试通过时,按约定完成测试、提交功能报告与依据,中心真人负责人确认推进;</li><li>测试不通过时,可依据项目、产品双方核实后明确作出的版本放行结论推进,并保留未通过项和放行条件。</li><li>后续成果延期须经中心真人确认并记录,放行不表示外部验收已通过。</li></ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage7" data-stage="7">
|
||
<div class="flow-title"><span class="stage-num">07</span><h2>内部/外部验收</h2></div>
|
||
<p class="owner">项目组织验收;内部验收任务交对应真人角色,外部验收结果由产品/业务确认。平台结果由产品确认,客户结果由业务确认。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>依据已确认的测试结果、版本放行结论及验收标准,由项目组织内部和外部验收。</li><li>内部验收可由中心向对应真人角色下发任务;</li><li>外部验收由产品/业务取得并确认结果。</li><li>明确本阶段适用的验收范围、对象、版本、交付时间和成果要求。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>承担内部验收任务的真人角色提交验收结论与依据,记入已有验收记录。</li><li>外部验收结果由产品/业务确认;</li><li>产品汇总《平台验收报告或结论》《客户验收通过报告》和共用《遗留问题清单》,客户结果由业务确认。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理内部验收结果、外部产品/业务确认、对应版本和遗留承接;</li><li>中心真人负责人依据本阶段约定的验收范围和实际结果,决定进入复盘结项或退回处理。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>测试真人直接向产品真人交付已完成并确认的最终测试报告及已提供的提测佐证;中心正式成果记录沿用最终版及确认。链接资料只记链接地址,不收转大文件;产品接收情况列入过程记录。</li>
|
||
<li>验收分为内部和外部。内部验收由承担任务的真人角色执行并提交结果;外部验收由产品/业务取得实际反馈并确认。各自输入就绪时可并行开展。</li>
|
||
<li>平台联系、发包/寄样、收件和进度跟进按项目明确唯一主责,不默认全部由产品或中心真人亲自执行。实际执行协调、产品接收可用、平台结果及客户业务确认分别登记;职责确定不证明动作已发生。</li>
|
||
<li>平台结果由产品确认,无需业务批准;客户验收通过报告由产品出具或更新,客户结果由业务确认。客户反馈由具备联络权限的真人取得。</li>
|
||
<li>沿同一份共用遗留记录标明内部/外部来源、实际验收方、对应版本、责任人、处置和状态;第八阶段按<a href="#bug-confirmation">中心与产品双方确认规则</a>继续,不另要求测试提交重复缺陷清单。未通过时提交具体问题及需中心安排的修复或变更,回到受影响环节处理。</li>
|
||
<li>返工产生新测试结果时,重新完成阶段 6 的结果确认;仍不通过而拟放行时,重新取得项目、产品双方的核实结论。版本变化影响其他验收项时,同步更新相应结果。</li>
|
||
</ul></div>
|
||
<div class="gate"><strong>进入阶段 8:</strong><ul><li>本阶段约定的内部验收完成,适用的外部验收取得产品/业务确认;</li><li>平台由产品确认,客户由业务确认,项目同时要求平台和客户验收时须两项均通过。</li><li>验收对象与有效版本一致,问题和风险有明确承接,中心真人负责人决定推进。</li><li>内部验收完成或版本已放行不能替代外部验收结果。</li></ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="stage8" data-stage="8">
|
||
<div class="flow-title"><span class="stage-num">08</span><h2>复盘结项</h2></div>
|
||
<p class="owner">中心真人负责人组织;各真人角色提交归档和复盘输入;业务保留结项确认职责。</p>
|
||
<div class="triplet">
|
||
<div class="pane"><h3>中心下发什么任务</h3><ul><li>向实际参与的真人角色下发资料归档、遗留承接和复盘任务,明确所需现有成果、事实及改进安排,不要求重做同内容文件。</li></ul></div>
|
||
<div class="pane"><h3>真人提交什么结果</h3><ul><li>各真人角色提交本角色资料和复盘结论。</li><li>中心真人负责人组织形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》,中心 Agent 协助整理,业务给出结项结论。</li></ul></div>
|
||
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 汇总完整成果及入口、验收结论、Bug 双方确认、业务结项确认和遗留承接;</li><li>中心真人负责人决定结项关闭或退回补充,留下决定与后续责任安排。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>正式成果归档收齐各阶段真人完成并确认的有效原件、成果包或真实外部入口及对应确认,沿用有效版本和配套资料;本地复制按项目明确授权执行,保留原交接与映射,不强制下载外部文件。</li>
|
||
<li>《结项资料归档》包含各阶段成果目录、有效完整入口、适用版本、阶段管理起止及依据,成果提交、采用和确认日期分别记录。汇总纳入第八阶段正式成果,不另造一类交付要求。</li>
|
||
<li>成果汇总和《结项报告》按项目已确认格式或模板编制;单工作表 Excel 可作为汇总参考,不强制其他项目使用相同工作表数量、字段粒度或报告栏目。模板中已有内容和日期依据真实记录填写,缺少工时、迭代、评审或签名时保留未知,不按文件数量推算。</li>
|
||
<li>过程资料另行归档:旧版、草稿、历史确认、变更过程、项目进度、产品接收情况及其他过程记录均保留,不混入最终正式成果记录。</li>
|
||
<li>复盘基于事实说明目标完成、计划偏差、协作与质量问题、经验和改进措施。改进项写入流程闭环总结,明确责任人和跟进安排,不另设正式成果。</li>
|
||
<li>业务依据归档、复盘和遗留承接确认结项或提出补充;中心记录这一结论后决定关闭。业务不重复批准已由产品确认的平台结果。</li>
|
||
<li>本阶段不安排冒烟、发布验证或其他测试,不要求重做发布固件。发现新的实现或质量问题,回到相应阶段处理。</li>
|
||
<li>结项必需项完成后锁定四类结项成果;仍有延期成果时,提交中心真人负责人明确补齐或承接安排后再决定是否关闭,未交资料保留待交状态。按安排跟进遗留与改进项,结项不表示后续改进已经全部实施。</li>
|
||
</ul></div>
|
||
<div class="detail" id="bug-confirmation"><h3>全部 Bug:中心先确认,产品再次确认</h3>
|
||
<ol>
|
||
<li>中心真人负责人先确认问题事实、适用版本、实际处理结果或后续承接安排;研发、测试等真人提供已有事实或专业意见。</li>
|
||
<li>中心将已确认内容提交产品真人负责人再次确认,并由产品在职责范围内决定处理方式。未知部分明确标出,不把中心尚未确认的事实交产品代查。</li>
|
||
<li>中心和产品对事实、处理结果或后续安排均无异议后,沿原任务及共用问题记录登记双方最终确认。产品提出调整时,中心协调确认受影响内容,再交产品确认;有分歧或缺少确认时保留待确认。</li>
|
||
</ol>
|
||
<ul>
|
||
<li>范围覆盖项目全部 Bug,包括后续发现和此前已处理的问题。已有适用的有效确认直接引用,仅补齐缺少或受变化影响的部分。</li>
|
||
<li>已修复、延期处理、暂不修复分别记录;未修复保留真实状态、责任人及后续安排。双方无异议不表示全部已修复,问题状态与最终处置确认分开。</li>
|
||
<li>逐项记录编号/名称、对象/版本、处理结果/状态、双方各自确认人、真实时间、结论、范围/条件、来源及后续责任/安排。过程事实与分歧随时登记,最终确认另记,保留历史;未知不编造。</li>
|
||
<li>复用原报告和共用记录,不新增测试必交清单或重做已接受测试。原不通过、版本放行及外部验收各自保留;需要新实现或验证时,按实际职责回到受影响阶段办理。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="gate"><strong>项目关闭:</strong><ul><li>约定的内部与外部验收已完成并确认,归档完整可追踪,复盘完成,Bug 处理或承接已取得中心和产品双方确认,其他遗留已处理或落实承接,业务明确确认结项;</li><li>中心真人负责人决定关闭。</li><li>延期成果按真人确认的处理决定结清或明确承接,不能将未交付写成已归档。</li><li>模拟项目只能记录模拟完成。</li></ul></div>
|
||
<div class="detail"><h3>关闭决定后的登记与跟进</h3><ul>
|
||
<li>登记实际决定人、日期、原话、范围及条件,同步项目概览、进度、阶段、原任务、成果索引、报告和成果汇总的当前状态。锁定本次有效结项成果及目录,旧版和原交接记录保留。</li>
|
||
<li>停止对已结束阶段和已确认结果重复催办;队列未送达或工具未结算另记,沿原事项处理,不撤销真人关闭决定、不重派同一业务任务。</li>
|
||
<li>项目关闭不把原测试不通过改成通过,不把 Bug 改成已修复,不证明实际量产或出货。后续真实质量事项沿已有记录和责任渠道处理,需要新工作时按实际授权安排。</li>
|
||
<li>按<a href="#notifications">已授权通知规则</a>发送一次结项总结,记录实际发送结果,不因后续文档整理重复发送。</li>
|
||
<li>项目期间的流程补充、模板和反馈先在项目保留;完成后汇总拟纳入共享 Skill 的具体内容和文件入口,经有权真人对整合范围统一明确确认后再更新。项目关闭或本文件保存不代替整合确认。</li>
|
||
</ul></div>
|
||
<a class="back" href="#overview">返回八阶段总览 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="exceptions">
|
||
<div class="kicker">按影响处理,不增加固定过程确认</div><h2>变更、阻塞、豁免与留档</h2>
|
||
<div class="table-wrap"><table><thead><tr><th>情况</th><th>真人角色提交</th><th>中心处理</th></tr></thead><tbody>
|
||
<tr><td>影响完成的阻塞</td><td>受影响任务、事实与依据、缺少的输入或决定、影响、建议动作和期望时间。</td><td>中心 Agent 整理,中心真人负责人安排协调、补充任务或暂缓;只阻塞受影响任务,条件满足后恢复。</td></tr>
|
||
<tr><td>需改变基线的事项</td><td>《变更申请》:旧基线、拟变更内容、原因、范围、版本、成本/排期/质量影响及建议。</td><td>按权限取得产品、业务或相应专业结论,由中心记录决定、生效范围及后续任务。不得自行改变范围、接口、排期或验收条件。</td></tr>
|
||
<tr><td>专业意见冲突</td><td>真人角色自行组织讨论,提交收口结论;无法收口时写明分歧、证据及需要中心决定的事项。</td><td>中心协调有权真人角色解决,中心 Agent 不替专业角色裁决;需要修改基线时按变更处理。</td></tr>
|
||
<tr><td>结果不满足完成条件</td><td>实际完成部分、缺失项、原因、影响和补充安排;保留有效成果。</td><td>中心真人负责人决定补充、退回或暂缓,并明确待补项;不把部分完成写成全部完成。</td></tr>
|
||
<tr><td>成果不能如期交付</td><td>待交成果、原因、影响、主责真人角色及计划交付时间,提交中心真人负责人确认。</td><td>真人确认后,中心 Agent 记录延期及处理决定,在每个阶段结束时提醒中心真人负责人和责任角色,持续跟进到交付或明确处理;是否推进由中心真人负责人决定。</td></tr>
|
||
<tr><td>测试不通过但拟放行版本</td><td>原测试报告、不通过项与影响、待放行版本、放行范围及条件、遗留处理和项目/产品双方真人核实结论。</td><td>中心以双方明确核实结论作为放行依据,记录原测试结论、版本放行决定和后续安排;不将“不通过”改写成“通过”。</td></tr>
|
||
<tr><td>必需成果不适用/申请豁免</td><td>《成果豁免申请》:成果名称、适用依据、原因、事实、替代证据、影响和风险。</td><td>由中心真人负责人明确批准或拒绝。批准只满足该文件要求,测试结果确认、项目/产品版本放行核实及内部/外部验收仍按相应规则办理。</td></tr>
|
||
<tr><td>跳转、回退或暂缓</td><td>说明触发原因、当前缺失成果、影响、风险及补齐计划。</td><td>中心真人负责人明确决定;记录原状态、目标环节与约束,保留历史,不把跳过写成通过。</td></tr>
|
||
</tbody></table></div>
|
||
<div class="note"><strong>处理文件差异时:</strong>列出对象、版本、差异及影响,由有权真人明确采用口径。当前文件同步不证明历史审阅一致;不把另一型号、平台、构建或使用阶段的结论补到当前对象。已有有效确认、明确跳过的事项不恢复为前置,实质变化只补充受影响部分。</div>
|
||
<h3>成果与过程分开留档,记录逐条展示</h3>
|
||
<ul>
|
||
<li>中心维护项目概览、项目进度、阶段记录和成果索引,按正式成果和过程记录分区、分条更新。</li>
|
||
<li>正式成果目录及当前成果索引只登记真人完成并确认的最终成果及对应确认,不混入任务状态、草稿、旧版或推进决定。</li>
|
||
<li>中心 Agent 在过程记录中登记经真人确认的延期事项;阶段结束时分条提醒待交成果、责任人、约定日期与影响,交付后更新对应条目。</li>
|
||
<li>任务、输入基线、提交过程、退回、阻塞、中心决定和下一步进入过程记录;旧版、草稿及历史确认也在过程记录中保留。</li>
|
||
<li>外部链接成果登记真实完整入口及对应确认,不强制重复下载;本地已取得有效资料的复制归档按项目授权办理,保留来源与映射,不能只用概括目录代替有效成果。</li>
|
||
<li>同一有效成果不重复制作或确认;新版经真人确认后更新最终成果条目,旧版移入过程记录并保留替代关系,不删除历史。</li>
|
||
<li>不适用、未执行、失败、延期和豁免分别说明;未验证内容不写为通过。模拟材料和真实结果分开,模拟完成不代表发布、客户验收或生产就绪。</li>
|
||
</ul>
|
||
<p class="small">预算、采购、对外承诺和暂停/取消等业务授权仍由业务负责;产品只确认明确授权范围内的具体资源/排期事项,中心真人统筹项目总排期与协调。中心真人负责项目推进与成果豁免,不能借推进决定代替其他必要授权。</p>
|
||
<a class="back" href="#top">返回顶部 ↑</a>
|
||
</section>
|
||
|
||
<section class="section" id="templates">
|
||
<div class="kicker">可直接用于各阶段</div><h2>任务与阶段记录的分条格式</h2>
|
||
<p>各栏目均用列表逐条填写,一条表达一个事项;有多个字段时逐项列子条目。不要求复杂 JSON,不增加独立审批文件。</p>
|
||
<div class="table-wrap"><table class="template"><caption>中心下发任务</caption><thead><tr><th>栏目</th><th>需要写清的内容</th></tr></thead><tbody>
|
||
<tr><td>阶段与任务</td><td><ul><li>当前阶段、任务目标、唯一主责真人角色及必要协作角色。</li></ul></td></tr>
|
||
<tr><td>输入与范围</td><td><ul><li>有效资料、版本及位置;</li><li>本阶段必须完成、后续处理和当前不需要的内容。</li></ul></td></tr>
|
||
<tr><td>交付与时间</td><td><ul><li>正式成果或成果包、最低结果内容、必需/选填划分、完成时间和下游用途。</li></ul></td></tr>
|
||
<tr><td>完成条件</td><td><ul><li>能够按结果判断的条件;</li><li>须提交的专业结论及授权,不列内部操作检查清单。</li></ul></td></tr>
|
||
<tr><td>执行中反馈</td><td><ul><li>只有影响任务完成的阻塞或需中心决定的变更及时提交;</li><li>其他工作由真人自行组织。</li></ul></td></tr>
|
||
</tbody></table></div>
|
||
<h3>中心聊天中的阶段成果汇报</h3>
|
||
<ul>
|
||
<li><strong>概况:</strong>项目、阶段、汇报日期、全部确认完成/部分完成/已交待确认、本次需决定事项。</li>
|
||
<li><strong>成果:</strong>逐项列任务/成果、主责真人、必需/选填、实际状态、已交版本与全部有效文件入口、确认人/时间/范围/条件。</li>
|
||
<li><strong>遗留:</strong>逐项列状态、责任、原计划/当前计划、原因/依赖、影响、必须完成阶段和补齐或承接建议;选填未交、豁免/取消分别说明。</li>
|
||
<li><strong>时间与记录:</strong>任务提交、确认后实际完成、阶段管理日期分别记;引用完整原记录,突出改期和相对上次汇报的实质变化。</li>
|
||
<li><strong>请中心决定:</strong>接受哪些结果、推进/补充/退回/暂缓或结项关闭、遗留处理建议;决定未取得时写待明确。</li>
|
||
</ul>
|
||
<h3>角色工时与研发/测试衔接记录</h3>
|
||
<div class="table-wrap"><table class="template"><thead><tr><th>栏目</th><th>记录内容</th></tr></thead><tbody>
|
||
<tr><td>角色与范围</td><td>角色、唯一主责真人、工作项、需求及输入版本、已有成果与剩余工作。</td></tr>
|
||
<tr><td>工时</td><td>原估/当前估、单位、投入及人数、本人提交/确认日期、来源、状态;真实实际工时另记。</td></tr>
|
||
<tr><td>周期</td><td>初版单列;初版后的各轮内容、开发/自测/修复、独立测试/回归、起算条件、投入和外部等待分别说明。</td></tr>
|
||
<tr><td>核实与交接</td><td>技术负责人核实人/日期、对象版本、范围、依赖及结论;交测试的版本/范围/渠道和实际接收;测试衔接及资源要求。</td></tr>
|
||
<tr><td>变更与日期</td><td>旧值、新值、原因、影响及真人确认;中心统筹确定的有效日期及依据。估算、资源承诺和实际完成分别记。</td></tr>
|
||
</tbody></table></div>
|
||
<h3 id="schedule-template">项目预排期:八列格式</h3>
|
||
<p>模板预排日期保持为空。实际编制时按本项目真实工作填写,不套用其他项目日期、任务数量或工时;未知写待评估/待确认。下表只展示列结构。</p>
|
||
<div class="table-wrap"><table><caption>预排期与实际执行主表</caption><thead><tr><th>里程碑</th><th>工作项</th><th>预排开始日期</th><th>预排结束日期</th><th>预排工时/人时</th><th>负责角色</th><th>参与人数</th><th>实际执行情况</th></tr></thead><tbody><tr><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr></tbody></table></div>
|
||
<p class="small">每项任务唯一主责真人、完成条件、原估/当前估和改期依据沿原任务记录维护;参与人数不再乘工时。“实际执行情况”按真实回报登记进展、时间、成果/版本/入口、确认、偏差及下一步,不把空白或待登记当作未开工/未完成。</p>
|
||
<h3>结项归档成果目录与阶段日期</h3>
|
||
<p>作为《结项资料归档》的一部分,按阶段和成果逐项提供有效入口及日期;可参照以下字段。项目选择单工作表 Excel 时,在同一表中逐项登记;其他格式按项目明确要求执行。</p>
|
||
<div class="table-wrap"><table class="template"><thead><tr><th>栏目</th><th>参考字段</th></tr></thead><tbody>
|
||
<tr><td>阶段管理</td><td>阶段名称、开始日期、完成日期、当前状态、起止决定及依据;进行中时完成日期留空。</td></tr>
|
||
<tr><td>成果与入口</td><td>成果名称、文件名/入口用途、版本/对象、成果状态、完整可点击路径/地址及类型。</td></tr>
|
||
<tr><td>提交与确认</td><td>成果提交、正式采用、真人确认日期及记录、确认人、来源、范围/条件;实际工程发生日期另列。</td></tr>
|
||
<tr><td>说明与变化</td><td>缺项与待办、实际后续安排、正式路径与原交接映射;已有包内资料沿有效索引,不重复展开。</td></tr>
|
||
</tbody></table></div>
|
||
<h3>阶段记录:正式成果及确认记录</h3>
|
||
<ul>
|
||
<li><strong>最终成果:</strong>每项成果独立列出。
|
||
<ul>
|
||
<li>成果名称。</li>
|
||
<li>真人完成并确认的最终版本。</li>
|
||
<li>文件位置;通过链接交付或成果中含有链接时,记录链接地址即可。</li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>真人确认:</strong>每项确认独立列出,并关联对应最终成果。
|
||
<ul>
|
||
<li>确认人。</li>
|
||
<li>确认时间。</li>
|
||
<li>对应成果及版本。</li>
|
||
<li>确认结论。</li>
|
||
<li>确认范围与附带条件。</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<h3>阶段记录:过程记录</h3>
|
||
<ul>
|
||
<li><strong>任务与输入:</strong>分别列任务要求、主责真人角色、输入基线和交付时间。</li>
|
||
<li><strong>逐任务汇总:</strong>每个任务单列成果(应交、已交、版本与位置)、完成情况和真人确认情况,并关联原任务记录。</li>
|
||
<li><strong>完成与时间:</strong>分别列已完成项、未完成项、原计划完成时间、当前计划完成时间及提交后真人确认的实际完成时间;提交与确认时间分别保留,改期不覆盖原计划。</li>
|
||
<li><strong>历史资料:</strong>分别列旧版成果、草稿、历史确认与版本替代关系,保留原资料。</li>
|
||
<li><strong>评审与修订:</strong>每条意见、修改、退回原因与处理结论分别记录。</li>
|
||
<li><strong>延期、阻塞与风险:</strong>每个事项单列,子项分别写原因、影响范围、责任人、原计划与当前计划日期、必须完成的阶段、真人确认和阶段结束提醒情况;跨阶段引用原记录并持续显示在项目层。</li>
|
||
<li><strong>中心决定:</strong>每次推进、补充、退回或暂缓决定单列,子项分别写决定人、时间、依据、适用范围和理由。</li>
|
||
<li><strong>版本放行:</strong>测试不通过而放行时,分条关联原测试结论、项目/产品双方核实结论、版本、放行范围与条件。</li>
|
||
<li><strong>Bug 双方确认:</strong>逐项列问题、对象/版本、实际处置状态、中心及产品各自确认人/时间/结论/条件、来源与后续安排;过程分歧和最终确认分开。</li>
|
||
<li><strong>阶段与关闭:</strong>实际启用/结束或关闭决定日期及依据、状态同步、有效成果锁定和停止重复催办情况;群总结及实际发送结果另记。</li>
|
||
<li><strong>下一步:</strong>每项任务或待办单列,子项分别写主责真人角色、期限、依赖和承接安排。</li>
|
||
</ul>
|
||
<div class="note"><strong>成果确认与推进决定分开保存。</strong>真人对最终成果的确认保留在正式成果确认记录中;中心是否推进、为什么推进以及后续安排列入过程记录。阶段 6 的测试成果确认保留为对应正式确认,测试不通过后的核实与放行决定列入过程记录。</div>
|
||
<div class="note"><strong>确认的是任务结果和推进条件。</strong>真人角色对专业工作与提交负责,中心真人负责人对推进决定负责;角色 Agent 的参与方式不成为阶段完成条件。</div>
|
||
<a class="back" href="#top">返回顶部 ↑</a>
|
||
</section>
|
||
</main>
|
||
<footer>Codex 多角色项目推进总流程图 · V2.1 · 2026-10-20 编制<br>依据《流程更新》截至 2026-10-20 的已确认规则及本轮实施口径整合。固定路径维护当前流程,历史由 Git 保留;仓库更新与配置部署、在途项目采用分别办理。</footer>
|
||
</body>
|
||
</html>
|