feat: 按 V2.1 更新中心 Skill、流程图与项目记录模板

This commit is contained in:
liyun committed 2026-10-20 18:46:19 +08:00
1 parent 98541d682b
commit 206aabc06c
26 files changed
+592 -83

No files matched your search

+139 -27
View File
@@ -5,7 +5,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="color-scheme" content="light">
<link rel="icon" href="data:,">
<title>Codex 多角色项目推进总流程图|V2.0</title>
<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}
@@ -20,7 +20,7 @@
<body>
<header class="hero" id="top">
<div class="hero-inner">
<div class="eyebrow">CODEX · 多角色项目流程 · V2.0</div>
<div class="eyebrow">CODEX · 多角色项目流程 · V2.1</div>
<h1>中心下发任务,真人交付结果<br>按八个阶段推进项目</h1>
<p>真人角色负责组织和完成工作,提交完成情况与结果性资料。中心整理结果,由中心真人项目负责人决定进入下一环节、补充、退回或暂缓。</p>
<span class="badge">保留八阶段</span><span class="badge">真人角色负责执行与提交</span><span class="badge">中心真人负责人决定推进</span>
@@ -29,12 +29,13 @@
<main class="wrap">
<section class="section" id="version">
<div class="kicker">版本与适用范围</div>
<h2>V2.0:根据项目实施反馈调整任务流转</h2>
<p><strong>编制日期:2026-09-30。</strong>本版依据本次已确认的优化要求编写:中心按阶段下发任务;真人角色自行组织执行;完成后提交任务完成情况和结果性资料;中心依据结果决定是否推进。保留八阶段,并按审阅意见合并业务需求文档、将风险纳入立项资料、以链接提供缺陷信息、记录延期成果、增加项目与产品双方核实后的版本放行方式,区分内部与外部验收。</p>
<div class="note"><strong>当前流程基线为 V2.0。</strong>V1.0 原文通过 Git 历史保留,仓库中的 <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.0 的项目按本版任务与结果流转执行。</p>
<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="#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="#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>
<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>
@@ -47,7 +48,7 @@
<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>
<p>这个循环适用于每项任务和阶段收口。同一阶段可有多项任务,每项任务只有一个主责真人角色。单项任务被接受后,可启动依赖已经满足的后续任务;跨阶段推进须取得中心真人负责人明确决定;已有条件授权的,条件实际满足后按原范围执行并登记依据,不重复申请同一批准。推进不把未交或待确认成果改写为已完成。</p>
<div class="note"><strong>成果不能如期交付时:</strong>真人角色可提交中心真人负责人确认,说明待交成果、延期原因、影响及计划交付时间。真人确认后,由中心 Agent 记录待交项、责任人、新交付时间和确认决定;在每个阶段结束时提醒中心真人负责人及相关责任角色,直至交付或另有明确处理决定。是否推进由中心真人负责人依据实际影响决定,延期成果仍记为未交付。</div>
<div class="table-wrap"><table>
<caption>谁负责什么</caption>
@@ -70,9 +71,13 @@
<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>
@@ -80,15 +85,48 @@
<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>正式成果条目只列成果名称、最终版本、文件位置或链接地址;确认记录分条列出确认人、确认时间、对应成果与版本、确认结论及范围和条件。</li>
<li>未完成项、待确认材料、候选固件、草稿及旧版不登记为最终正式成果;中心 Agent 整理、生成或收到文件均不等于真人确认。</li>
<li>同一文件或连贯成果包可以承载多个结果,不为凑齐名称另造文件。文件名含“草稿”“预览”时,正式状态以有效真人确认和实际采用决定为准,保留确认对象及原提交来源。</li>
<li>成果文件正文按真人确认的最终版本保存,不因记录分区而删改成果内容。</li>
</ul>
<h3>过程记录区</h3>
@@ -102,7 +140,9 @@
<h3>成果中的链接</h3>
<ul>
<li>正式成果通过链接交付,或成果中含有相关链接时,记录链接地址即可。</li>
<li>不另行复制链接内容、编写链接摘要、截图或重复下载资料作为留档要求。</li>
<li>外部成果登记真实完整入口、用途、版本及对应确认,不强制下载或复制全部外部文件,也不要求另作链接摘要或截图。</li>
<li>项目已明确授权本地复制归档时,将已取得且确认有效的原件及配套资料按阶段、成果分类复制到正式区,保留原交接资料、历史入口和路径映射;目录、索引及汇总改指正式位置。</li>
<li>复制或补地址日期单独记录,不替换原提交、采用、确认、实际完成或阶段起止日期;归档位置变化不重新申请已有有效确认。</li>
<li>成果对应的真人确认仍单独保留;链接内容的核实由真人角色负责,不因留档增加中心逐项核实任务。</li>
</ul>
<h3>所有阶段记录都分条展示</h3>
@@ -115,12 +155,15 @@
<p class="small">正式成果区和过程记录区分别对应阶段目录中的 <code>正式成果/</code> 与 <code>过程记录/</code>;<code>阶段记录.md</code> 按两个栏目分条展示。阶段 4、8 由中心真人负责人组织完成的成果也须经对应真人确认后,才登记最终版。</p>
<h3>项目、阶段与任务分别记录</h3>
<ul>
<li><strong>项目层:</strong>记录当前阶段、整体进度和当前需要处理的事项;未按期完成的事项持续列出原计划、当前有效计划、未完成原因、影响范围及必须完成的阶段。整体进度用阶段状态和关键成果说明,百分比须有已确认的计算依据。</li>
<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>
@@ -129,18 +172,18 @@
<section class="section" id="overview">
<div class="kicker">八阶段总览</div><h2>每阶段都以提交结果和中心决定收口</h2>
<div class="note"><strong>正常顺序:</strong>业务需求 → 产品定义 → 方案设计 → 项目规划 → 嵌入式软硬件实现 → 测试验证 → 内部/外部验收 → 复盘结项。测试不通过时,可安排修复、复验,也可由项目、产品双方真人核实后作出版本放行结论;验收问题回到受影响环节处理,不要求从头重启。</div>
<p>各阶段开始时,中心说明本阶段必须完成、后续阶段处理、当前不需要的内容。任务只覆盖当前必需项;后续资料不提前成为当前阶段的完成条件。</p>
<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="#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>归档完整、复盘完成、遗留有承接,业务确认结项,中心真人负责人决定关闭。</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>
@@ -205,16 +248,28 @@
<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>相关真人角色完成各自评估,中心真人负责人组织形成《项目计划》《角色分工》《项目状态内部记录》,随结果保留技术结构结论、产品授权范围内具体资源/排期事项的确认及必要业务授权。</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>产品只确认对象、权限依据和范围明确的资源/排期事项,不笼统承担全项目、其他专业或工厂周期;相关专业分别提供实际评估。预算、采购或对外承诺由业务批准。已提交的有限输入按原范围登记,不扩大为全部资源已落实。</li>
<li>角色分工写明每项任务的唯一主责、协作、人员变化和交接。相关执行角色只接收本角色任务所需的计划与资料。</li>
<li>规划引用阶段 2《立项资料》中的风险内容,不另造风险成果或《产品资料整合》。计划可同步业务,同步回执不增加批准条件。</li>
</ul></div>
<div class="gate"><strong>进入阶段 5:</strong><ul><li>计划的技术结构及问题任务已有结论,产品确认资源排期,必要业务授权完成,首批依赖就绪任务可执行;</li><li>中心真人负责人决定推进。</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>
@@ -232,9 +287,12 @@
<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>
@@ -245,7 +303,7 @@
<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>测试自行组织策略、执行、缺陷协调和独立复验,提交《功能测试报告》及约定提供的选填资料,缺陷信息可提供链接,不提交缺陷清单文件;</li><li>给出通过/不通过结论、实际覆盖范围和风险。</li></ul></div>
<div class="pane"><h3>中心依据什么确认</h3><ul><li>中心 Agent 整理本次测试结果、被测版本与质量条件;</li><li>中心真人负责人明确确认或退回测试结果。</li><li>测试不通过时,由项目、产品双方真人确认核实,核实结论可作为版本放行依据;</li><li>中心据此记录放行及阶段推进决定。</li></ul></div>
</div>
@@ -258,7 +316,7 @@
<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 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>
@@ -275,8 +333,9 @@
<div class="detail"><h3>保留的结果要求</h3><ul>
<li>测试真人直接向产品真人交付已完成并确认的最终测试报告及已提供的提测佐证;中心正式成果记录沿用最终版及确认。链接资料只记链接地址,不收转大文件;产品接收情况列入过程记录。</li>
<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>
@@ -289,17 +348,39 @@
<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 汇总资料完整性、验收结论、业务结项确认和遗留承接;</li><li>中心真人负责人决定结项关闭或退回补充,留下决定与后续责任安排。</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>《结项资料归档》包含各阶段成果目录、有效完整入口、适用版本、阶段管理起止及依据,成果提交、采用和确认日期分别记录。汇总纳入第八阶段正式成果,不另造一类交付要求。</li>
<li>成果汇总和《结项报告》按项目已确认格式或模板编制;单工作表 Excel 可作为汇总参考,不强制其他项目使用相同工作表数量、字段粒度或报告栏目。模板中已有内容和日期依据真实记录填写,缺少工时、迭代、评审或签名时保留未知,不按文件数量推算。</li>
<li>过程资料另行归档:旧版、草稿、历史确认、变更过程、项目进度、产品接收情况及其他过程记录均保留,不混入最终正式成果记录。</li>
<li>复盘基于事实说明目标完成、计划偏差、协作与质量问题、经验和改进措施。改进项写入流程闭环总结,明确责任人和跟进安排,不另设正式成果。</li>
<li>业务依据归档、复盘和遗留承接确认结项或提出补充;中心记录这一结论后决定关闭。业务不重复批准已由产品确认的平台结果。</li>
<li>本阶段不安排冒烟、发布验证或其他测试,不要求重做发布固件。发现新的实现或质量问题,回到相应阶段处理。</li>
<li>结项必需项完成后锁定四类结项成果;仍有延期成果时,提交中心真人负责人明确补齐或承接安排后再决定是否关闭,未交资料保留待交状态。按安排跟进遗留与改进项,结项不表示后续改进已经全部实施。</li>
</ul></div>
<div class="gate"><strong>项目关闭:</strong><ul><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>
@@ -315,17 +396,18 @@
<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>
<li>不适用、未执行、失败、延期和豁免分别说明;未验证内容不写为通过。模拟材料和真实结果分开,模拟完成不代表发布、客户验收或生产就绪。</li>
</ul>
<p class="small">预算、采购、对外承诺和暂停/取消等业务授权仍由业务负责;授权范围内的资源排期由产品确认。中心真人负责项目推进与成果豁免,不能借推进决定代替其他必要授权。</p>
<p class="small">预算、采购、对外承诺和暂停/取消等业务授权仍由业务负责;产品只确认明确授权范围内的具体资源/排期事项,中心真人统筹项目总排期与协调。中心真人负责项目推进与成果豁免,不能借推进决定代替其他必要授权。</p>
<a class="back" href="#top">返回顶部 ↑</a>
</section>
@@ -339,6 +421,34 @@
<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>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</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>每项成果独立列出。
@@ -368,6 +478,8 @@
<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>
@@ -375,6 +487,6 @@
<a class="back" href="#top">返回顶部 ↑</a>
</section>
</main>
<footer>Codex 多角色项目推进总流程图 · V2.0 · 2026-09-30 编制<br>固定路径维护当前文档,V1.0 原文通过 Git 历史保留。中心 Skill 源文件已同步,安装、配置部署及在途项目采用按明确授权执行。</footer>
<footer>Codex 多角色项目推进总流程图 · V2.1 · 2026-10-20 编制<br>依据《流程更新》截至 2026-10-20 的已确认规则及本轮实施口径整合。固定路径维护当前流程,历史由 Git 保留;仓库更新与配置部署、在途项目采用分别办理。</footer>
</body>
</html>