370 lines
53 KiB
HTML
370 lines
53 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.0</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.0</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.0:根据项目实施反馈调整任务流转</h2>
|
||
<p><strong>编制日期:2026-09-30。</strong>本版依据本次已确认的优化要求编写:中心按阶段下发任务;真人角色自行组织执行;完成后提交任务完成情况和结果性资料;中心依据结果决定是否推进。保留八阶段,并按审阅意见合并业务需求文档、将风险纳入立项资料、以链接提供缺陷信息、记录延期成果、增加项目与产品双方核实后的版本放行方式,区分内部与外部验收。</p>
|
||
<div class="note"><strong>本次原位更新流程文档至 V2.0。</strong>V1.0 原文通过 Git 历史保留,现有 Skill、Hook 未随本文件同步。本版文档不表示这些运行配置已经部署,也不自动迁移在途项目。具体项目采用 V2.0、运行规则同步和部署,按后续明确决定执行。</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>
|
||
<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>
|
||
</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>测试结论与版本放行决定分别记录。测试不通过时,项目、产品双方真人可共同确认核实,以核实结论作为版本放行依据;保留原测试结论,并记录版本、未通过项、影响、放行条件及双方确认。外部验收结果和预算授权仍由有权角色确认。</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="records">
|
||
<div class="kicker">八阶段共同采用的留档规则</div>
|
||
<h2>正式成果只留最终版与确认记录</h2>
|
||
<h3>正式成果区</h3>
|
||
<ul>
|
||
<li>只保存各真人角色完成并确认后的最终成果,包括文档、固件、硬件资料及其他约定产出。</li>
|
||
<li>每项成果只登记一个最终有效版本,并保留该版本对应的真人确认记录。</li>
|
||
<li>正式成果条目只列成果名称、最终版本、文件位置或链接地址;确认记录分条列出确认人、确认时间、对应成果与版本、确认结论及范围和条件。</li>
|
||
<li>未完成项、待确认材料、候选固件、草稿及旧版不登记为最终正式成果;中心 Agent 整理、生成或收到文件均不等于真人确认。</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>
|
||
</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>
|
||
<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>各阶段开始时,中心说明本阶段必须完成、后续阶段处理、当前不需要的内容。任务只覆盖当前必需项;后续资料不提前成为当前阶段的完成条件。</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>归档完整、复盘完成、遗留有承接,业务确认结项,中心真人负责人决定关闭。</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>规划引用阶段 2《立项资料》中的风险内容,不另造风险成果或《产品资料整合》。计划可同步业务,同步回执不增加批准条件。</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>硬件真人开始设计前取得实际外设、关键器件规格书及结构板框图;缺失只影响相应硬件任务,需上游协调时向中心提出具体缺口。</li>
|
||
<li>底层提供可消费的 BSP/PSP,应用层负责合版。统一固件与硬件候选就绪后即可组织联调;联调问题关闭后提交最终提测版。</li>
|
||
<li>设计确认、接口协调、自测及联调由真人角色自行完成,中心不逐步核实。最终版本与软硬件匹配关系随结果提交,由技术负责人给出专业结论。</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>返工产生新测试结果时,重新完成阶段 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 汇总资料完整性、验收结论、业务结项确认和遗留承接;</li><li>中心真人负责人决定结项关闭或退回补充,留下决定与后续责任安排。</li></ul></div>
|
||
</div>
|
||
<div class="detail"><h3>保留的结果要求</h3><ul>
|
||
<li>正式成果归档只保留各真人角色完成并确认的最终版及对应确认记录,沿用已验收版本;有链接的成果只记链接地址。</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>
|
||
<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>
|
||
<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>每项成果独立列出。
|
||
<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>
|
||
</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.0 · 2026-09-30 编制<br>固定路径维护当前文档,V1.0 原文通过 Git 历史保留。运行规则同步、配置部署及在途项目采用另行确认。</footer>
|
||
</body>
|
||
</html>
|