中心下发任务，真人交付结果
按八个阶段推进项目

V2.1：补齐排期、成果确认、归档和结项规则

编制日期：2026-10-20。本版依据 YT42-Test2《流程更新》截至 2026-10-20 的已确认规则，在 V2.0 八阶段结构上补充阶段汇报、需求交接、工时与周期评估、预排期维护、成果查看、Bug 双方确认、完整归档及关闭后的登记要求。

沿用真人角色组织执行、提交专业结果，中心真人负责人决定推进的分工。项目中的人名、型号、日期、工时、问题数量、单次放行和豁免决定留在项目记录中；其他项目依据自身需求、授权和有效基线执行。

历史对照：V1.0 原流程文档（Git 历史）。模板来源：文档模板参考。旧文档中的过程节点用于历史对照；各项目按已确认采用的流程版本执行；本页展示 V2.1 的任务与结果要求。

下发任务 → 真人执行 → 提交结果 → 中心确认

这个循环适用于每项任务和阶段收口。同一阶段可有多项任务，每项任务只有一个主责真人角色。单项任务被接受后，可启动依赖已经满足的后续任务；跨阶段推进须取得中心真人负责人明确决定；已有条件授权的，条件实际满足后按原范围执行并登记依据，不重复申请同一批准。推进不把未交或待确认成果改写为已完成。

执行过程由真人角色负责

• 中心不要求角色逐步汇报，也不对每一项内部评审、操作或细节设置单独的 Agent 核实任务。必要的专业检查仍由真人角色组织完成。
• 任务交付渠道不强制限定为 Etunel 角色会话。只需真人角色实际收到任务，并让最终提交和中心决定可追踪；工具显示已发送不等于真人已接收或任务已完成。
• 真人角色可直接开展必要的线下沟通与专业协作。使用多个角色 Agent 时，其跨角色任务、问题和结论仍由中心中继，不开放成员 Agent 直连。
• 只有影响任务完成的阻塞、跨任务依赖冲突或需要中心决定的变更，才在执行中提交中心。专业角色能够在既定任务范围内解决的问题，由其自行处理。
• 必要的专业结论、授权和验收结果随成果一并提交；中心依据结果判断，不把这些工作再次拆成逐项确认回路。

中心按结果确认

• 中心 Agent 将提交内容与下发的完成条件对应，整理已完成项、缺失项、成果与版本、专业结论、必要授权、依赖和剩余风险，交中心真人负责人决定。
• 请求中心真人确认成果前，逐项提供本次范围涉及的全部有效文件名、版本、确认用途及可点击完整地址，或直接展示对应文件。已有索引可引用，但须能定位本次涉及的各份文件；不能只给总目录、摘要或中心确认记录。
• 沿已有成果身份和真实入口交接；包内内容可引用有效索引，缺项和可访问范围如实说明。只补入口时不重复申请已有效的结果确认，不编造路径或声称尚未提供的文件已供查看。
• 可读可用和专业结论由有权真人确认。Agent 无法访问成员磁盘或共享目录，只说明本端访问失败，不据此判定未提交、文件不存在或成果不兼容；不把 Agent 下载、解包、截图或重算哈希设为固定推进前置。
• 中心可以针对影响完成判断的缺口提出补充要求，说明缺什么、影响什么；不要求证明全部工作过程或重复提交同一有效资料。
• 中心真人负责人决定推进时，明确接受的结果、版本和适用范围。退回或暂缓时，明确原因、待处理事项、责任角色及下一步。
• 测试结论与版本放行决定分别记录。测试不通过时，项目、产品双方真人可共同确认核实，以核实结论作为版本放行依据；保留原测试结论，并记录版本、未通过项、影响、放行条件及双方确认。外部验收结果和预算授权仍由有权角色确认。
• 文件或需求有差异时，由有权真人明确采用内容、对象、版本和影响范围。当前文件同步、过去审阅对象和差异对既有结论的影响分别记录，不补造历史审阅事实。
• 同一成果、版本和范围的有效确认继续沿用。只有实质变化、用途超出原范围或出现相反证据时，才补充相应结果和确认；尚未完成或未经真人确认的材料只进入过程记录。

一个项目使用一个持续的中心贯穿生命周期。使用 Etunel 时，其运行时继续负责投递、队列、重试、去重、会话授权和文件传输，本流程不另设软件机制。钉钉仅用于已授权的辅助通知，通知不替代任务提交、批准、验收或项目事实记录。

中心主动提交阶段成果汇总

本阶段任务均取得所需真人完成确认后，中心 Agent 须主动在中心持续聊天提交汇总。成果已交但必要确认未齐，或仍有未完成、延期、拟承接事项需要中心判断时，同样提交汇总；成果、版本、确认或遗留发生实质变化时补充说明。仅更新本地记录不算已向中心真人汇报。

中心决定后，沿原任务登记决定人、日期、范围、条件和下一步。带遗留推进仍保留未完成状态；阶段八保留业务结项结论和其他必要确认。尚无决定时，阶段安排保持待决定。

每次阶段交接发送一条群总结

• 中心真人明确同意推进，或已有条件授权实际满足后，将上一阶段总结与下一阶段安排合成一条发送；等待决定时，先在中心持续聊天汇报，不提前写已进入下一阶段。
• 阶段八明确结项关闭后发送一次结项总结，说明最终成果、实际关闭结论，以及仍需跟进的遗留、责任和已确认安排。
• 首次须由中心真人确认发送账号、目标群和通知范围；账号或群变更时重新确认。在已确认范围内执行，不因每次交接重复申请同一授权。
• 先更新事实记录，再发送。写清已确认成果、未完成／待确认事项、实际推进决定，以及下一阶段已确认任务、负责人和期限；未知写待确认，不把通用职责写成本轮已派任务。
• 每条信息及子条目单独换行，用直接、自然的语言保留责任人、时间、条件和实际状态；总结及发送结果留在阶段过程记录，避免同一交接重复发送。
• 通过已确认的项目通知入口执行。请求已接受、投递成功和已读分别记录，不能代替真人接收、完成或验收；失败不阻塞主任务，结果未知时不盲目重发。

正式成果只留最终版与确认记录

正式成果区

• 保存各真人角色完成并确认后的全部有效成果及配套资料，包括文档、固件、硬件资料及其他约定产出。正式区须有有效原件／成果包，或真实完整外部入口及对应确认；不能仅放概括目录或中心确认记录，就称全部资料已归档。
• 每项成果只登记一个最终有效版本，并保留该版本对应的真人确认记录。
• 正式成果条目只列成果名称、最终版本、文件位置或链接地址；确认记录分条列出确认人、确认时间、对应成果与版本、确认结论及范围和条件。
• 未完成项、待确认材料、候选固件、草稿及旧版不登记为最终正式成果；中心 Agent 整理、生成或收到文件均不等于真人确认。
• 同一文件或连贯成果包可以承载多个结果，不为凑齐名称另造文件。文件名含“草稿”“预览”时，正式状态以有效真人确认和实际采用决定为准，保留确认对象及原提交来源。
• 成果文件正文按真人确认的最终版本保存，不因记录分区而删改成果内容。

过程记录区

• 旧版成果、草稿和对应的历史确认保留在过程记录中，不删除历史资料，不覆盖旧文件。
• 任务要求、输入基线、完成情况、评审意见、修订过程、退回原因、风险、延期、阻塞及下一步分条保存。
• 中心的推进、退回、暂缓、版本放行和豁免决定保存为过程记录，关联最终成果与必要真人确认。
• 成果实质变化后，新版经真人完成并确认，再替换正式成果区的当前条目；旧版、旧确认与替代关系转入过程记录留存。
• 各阶段已约定的《变更记录》《流程闭环总结》等交付文档，真人完成并确认后的最终文件仍是正式成果；其草稿与编写过程放入过程记录。

成果中的链接

• 正式成果通过链接交付，或成果中含有相关链接时，记录链接地址即可。
• 外部成果登记真实完整入口、用途、版本及对应确认，不强制下载或复制全部外部文件，也不要求另作链接摘要或截图。
• 项目已明确授权本地复制归档时，将已取得且确认有效的原件及配套资料按阶段、成果分类复制到正式区，保留原交接资料、历史入口和路径映射；目录、索引及汇总改指正式位置。
• 复制或补地址日期单独记录，不替换原提交、采用、确认、实际完成或阶段起止日期；归档位置变化不重新申请已有有效确认。
• 成果对应的真人确认仍单独保留；链接内容的核实由真人角色负责，不因留档增加中心逐项核实任务。

所有阶段记录都分条展示

• 每个阶段按“正式成果及确认记录”和“过程记录”两个栏目展示，分开登记。
• 一项成果单列一条；每项确认、决定、待办和风险分别列条目，不打包成一个自然段。
• 同一事项的时间、责任人、内容、影响和下一步分别列子项，便于阅读和跟进。
• 阶段结束时，只把最终成果及确认列入正式成果小结；延期提醒、未决项和后续安排列入过程记录。

正式成果区和过程记录区分别对应阶段目录中的 正式成果/ 与 过程记录/；阶段记录.md 按两个栏目分条展示。阶段 4、8 由中心真人负责人组织完成的成果也须经对应真人确认后，才登记最终版。

项目、阶段与任务分别记录

• 项目层：记录当前阶段、整体进度和当前需要处理的事项；未按期完成的事项持续列出原计划、当前有效计划、未完成原因、影响范围及必须完成的阶段。整体进度用阶段状态和关键成果说明，百分比须有已确认的计算依据。项目计划主表由中心按实际回报维护，Markdown 项目进度同步摘要；不另建一套重复任务。
• 阶段层：逐项汇总本阶段每个任务的成果、完成及确认情况，分别列负责人、应交与已交成果、版本与位置、时间、缺口、下一步和任务原记录入口。未完成和待确认情况归入过程栏目。
• 任务层：按可独立确认的交付结果或同一负责人的内聚任务包，一项一份 Markdown；前部维护现状，后部按时间追加接收、提交、退回、确认、改期等关键历史，不记录角色内部每一步操作。
• 跨阶段：同一事项沿用所属阶段的原记录，涉及阶段引用，项目层持续跟进；完成或明确处置后保留历史，承接后仍需跟进的继续显示。
• 三类时间：原计划保留首次确认期限，当前计划保留最新经确认的有效期限，每次改期保留旧值、新值、原因和真人决定；实际完成时间是任务提交后经对应真人明确确认完成的时间。提交时间另记，未确认写“尚未确认完成”，取消或豁免不写为实际完成。
• 线下确认：接受中心真人明确转述的线下接收和确认事实，保留实际确认人、真实时间、对象与版本、结论、范围和条件，以及转述人、来源和补录时间；不新增截图、审批单或重复确认。
• 阶段管理日期：开始取中心真人实际启用该阶段的日期，完成取明确结束／进入下一阶段的决定日期，第八阶段取明确关闭日期。进行中时完成日期留空；工程开工、测试、验收发生日期另记，不用管理日期计算工程提前／延期或总人时。
• 提交与接收：本人明确已通过其他渠道提交时据实登记，入口未给、接收可用未确认及验收结论未取得分别说明，不因本聊天无附件回退成未提交。队列待投递不推翻线下已完成事实，也不按队列等待时长判定工程延期。
• 记录更新顺序：先更新原任务，再同步阶段摘要、项目进度及适用成果索引；需要决定或通知时，使用已更新的事实。未知不填零、不造时间、负责人、地址、专业结论或签名。
• 易读排版：标题后用一句话说明现状，各栏目分条、字段加粗、留出空行，详细历史置后；链接使用明确名称，未知信息如实标明。

每阶段都以提交结果和中心决定收口

各阶段开始时，中心说明本阶段必须完成、后续阶段处理、当前不需要的内容。任务只覆盖当前必需项；后续资料不提前成为当前阶段的完成条件。阶段结束或需要中心判断安排时，先按阶段汇报要求提交成果、确认、遗留和有效入口，再取得推进决定。

业务真人角色主责；产品真人角色参与需求对齐。

产品真人角色主责；业务、技术负责人、实现与测试真人角色按实际需要参与。

技术负责人真人组织方案与接口收口；测试真人主责编制《测试计划》。

中心真人负责人组织；技术负责人、产品及执行真人角色提供任务、依赖、工期和资源评估。

硬件、嵌入式底层、嵌入式应用层真人分别负责各自任务；技术负责人给出整体集成与可提测结论。

测试真人负责测试执行、缺陷信息维护与独立质量结论；修复工作由相应实现真人角色主责。

项目组织验收；内部验收任务交对应真人角色，外部验收结果由产品／业务确认。平台结果由产品确认，客户结果由业务确认。

中心真人负责人组织；各真人角色提交归档和复盘输入；业务保留结项确认职责。

变更、阻塞、豁免与留档

成果与过程分开留档，记录逐条展示

• 中心维护项目概览、项目进度、阶段记录和成果索引，按正式成果和过程记录分区、分条更新。
• 正式成果目录及当前成果索引只登记真人完成并确认的最终成果及对应确认，不混入任务状态、草稿、旧版或推进决定。
• 中心 Agent 在过程记录中登记经真人确认的延期事项；阶段结束时分条提醒待交成果、责任人、约定日期与影响，交付后更新对应条目。
• 任务、输入基线、提交过程、退回、阻塞、中心决定和下一步进入过程记录；旧版、草稿及历史确认也在过程记录中保留。
• 外部链接成果登记真实完整入口及对应确认，不强制重复下载；本地已取得有效资料的复制归档按项目授权办理，保留来源与映射，不能只用概括目录代替有效成果。
• 同一有效成果不重复制作或确认；新版经真人确认后更新最终成果条目，旧版移入过程记录并保留替代关系，不删除历史。
• 不适用、未执行、失败、延期和豁免分别说明；未验证内容不写为通过。模拟材料和真实结果分开，模拟完成不代表发布、客户验收或生产就绪。

预算、采购、对外承诺和暂停／取消等业务授权仍由业务负责；产品只确认明确授权范围内的具体资源／排期事项，中心真人统筹项目总排期与协调。中心真人负责项目推进与成果豁免，不能借推进决定代替其他必要授权。

任务与阶段记录的分条格式

各栏目均用列表逐条填写，一条表达一个事项；有多个字段时逐项列子条目。不要求复杂 JSON，不增加独立审批文件。

中心聊天中的阶段成果汇报

• 概况：项目、阶段、汇报日期、全部确认完成／部分完成／已交待确认、本次需决定事项。
• 成果：逐项列任务／成果、主责真人、必需／选填、实际状态、已交版本与全部有效文件入口、确认人／时间／范围／条件。
• 遗留：逐项列状态、责任、原计划／当前计划、原因／依赖、影响、必须完成阶段和补齐或承接建议；选填未交、豁免／取消分别说明。
• 时间与记录：任务提交、确认后实际完成、阶段管理日期分别记；引用完整原记录，突出改期和相对上次汇报的实质变化。
• 请中心决定：接受哪些结果、推进／补充／退回／暂缓或结项关闭、遗留处理建议；决定未取得时写待明确。

角色工时与研发／测试衔接记录

项目预排期：八列格式

模板预排日期保持为空。实际编制时按本项目真实工作填写，不套用其他项目日期、任务数量或工时；未知写待评估／待确认。下表只展示列结构。

每项任务唯一主责真人、完成条件、原估／当前估和改期依据沿原任务记录维护；参与人数不再乘工时。“实际执行情况”按真实回报登记进展、时间、成果／版本／入口、确认、偏差及下一步，不把空白或待登记当作未开工／未完成。

结项归档成果目录与阶段日期

作为《结项资料归档》的一部分，按阶段和成果逐项提供有效入口及日期；可参照以下字段。项目选择单工作表 Excel 时，在同一表中逐项登记；其他格式按项目明确要求执行。

阶段记录：正式成果及确认记录

• 最终成果：每项成果独立列出。
  • 成果名称。
  • 真人完成并确认的最终版本。
  • 文件位置；通过链接交付或成果中含有链接时，记录链接地址即可。
• 真人确认：每项确认独立列出，并关联对应最终成果。
  • 确认人。
  • 确认时间。
  • 对应成果及版本。
  • 确认结论。
  • 确认范围与附带条件。

阶段记录：过程记录

• 任务与输入：分别列任务要求、主责真人角色、输入基线和交付时间。
• 逐任务汇总：每个任务单列成果（应交、已交、版本与位置）、完成情况和真人确认情况，并关联原任务记录。
• 完成与时间：分别列已完成项、未完成项、原计划完成时间、当前计划完成时间及提交后真人确认的实际完成时间；提交与确认时间分别保留，改期不覆盖原计划。
• 历史资料：分别列旧版成果、草稿、历史确认与版本替代关系，保留原资料。
• 评审与修订：每条意见、修改、退回原因与处理结论分别记录。
• 延期、阻塞与风险：每个事项单列，子项分别写原因、影响范围、责任人、原计划与当前计划日期、必须完成的阶段、真人确认和阶段结束提醒情况；跨阶段引用原记录并持续显示在项目层。
• 中心决定：每次推进、补充、退回或暂缓决定单列，子项分别写决定人、时间、依据、适用范围和理由。
• 版本放行：测试不通过而放行时，分条关联原测试结论、项目／产品双方核实结论、版本、放行范围与条件。
• Bug 双方确认：逐项列问题、对象／版本、实际处置状态、中心及产品各自确认人／时间／结论／条件、来源与后续安排；过程分歧和最终确认分开。
• 阶段与关闭：实际启用／结束或关闭决定日期及依据、状态同步、有效成果锁定和停止重复催办情况；群总结及实际发送结果另记。
• 下一步：每项任务或待办单列，子项分别写主责真人角色、期限、依赖和承接安排。