25 KiB
25 KiB
云效全流程角色与触发节点沟通话术
本文是异常处理和精细交接使用的详细版。日常操作优先读取
simple-role-commands.md，使用“记录需求、开始分析、开始开发、提交测试、测试完成、发布成功、验收通过”等短口令。
目录
- 使用规则
- 通用话术骨架
- 项目管理员与流程负责人
- 产品负责人
- 需求分析人员
- 设计人员
- 交付负责人
- 技术负责人
- 开发人员
- 代码评审人员
- 测试负责人和测试人员
- 缺陷修复人员
- 运维与发布负责人
- 业务验收人员
- 集成桥接负责人
- 异常和催办话术
- 节点交接清单
1. 使用规则
这套话术用于让不同角色把真实业务事件准确告诉Codex，再由Codex审计、规划、执行获批修改、验证或形成报告。默认使用yunxiao-requirement-lifecycle。
每次沟通至少提供：
- 精确项目名和需求编号。
- 当前角色、当前状态和刚刚发生的真实事件。
- 关联任务、仓库、分支、MR、测试计划、缺陷或流水线执行ID；没有就明确写“无”。
- 希望Codex采用的权限：
audit、plan、apply、test或document。 - 期望停在哪个状态，不要只说“继续流转”。
权限含义：
audit：只核查和报告，不修改云效。plan：只输出修改方案和影响，不执行。apply：只修改话术中明确列出的项目、工作项或规则。test：使用隔离测试资产触发并收集证据。document：只形成说明、记录或报告。
必须遵守：
- 标题、需求编号、分支名或标签不能代替云效正式关联。
- 首次提交不代表真实开始开发；人工“开始处理”是效能主口径，分支关联只是自动兜底。
已修复只表示交给测试复测，不是缺陷关闭。- test部署成功不等于测试通过，更不等于生产发布完成。
- 发布成功后停留
发布完成，必须有产品或业务验收才能进入已关闭。 - 未明确授权时，不改生产流水线、不直接推送保护分支、不删除规则或测试资产。
- 项目仍为
stage_tasks时使用R/TK规则；只有迁移门禁通过后才使用完整oneos_delivery链路。
2. 通用话术骨架
2.1 请求执行
使用 yunxiao-requirement-lifecycle。
权限：【audit/plan/apply/test/document】
项目：【精确项目名】
流程模型：【未知/stage_tasks/oneos_delivery】
我的角色：【角色】
需求：【需求编号+标题】
当前状态：【状态】
刚发生的事件：【真实事件】
相关资产：【任务/MR/分支/测试计划/缺陷/流水线执行ID；没有写无】
期望结果：【目标状态或需要生成的资产】
请先核查当前状态和正式关联，再执行授权范围内动作；输出实际动作、触发结果、证据、未完成项和下一责任人。不要用手工改状态冒充自动化通过。
2.2 只核查为什么没有流转
使用 yunxiao-requirement-lifecycle，权限=audit。
项目：【项目名】，需求：【编号】，当前状态：【状态】。
我已执行：【事件】，相关对象：【对象编号或链接】；等待了【秒数】仍未流转。
请按事件、当前状态、标签位置、正式关联、规则启用、执行账号、执行日志、后继规则和异步窗口逐项诊断。不要直接替我改状态。
2.3 请求修改规则
使用 yunxiao-requirement-lifecycle，权限=apply。
只允许修改项目【项目名】中的规则【精确规则名/控制ID】，目标是【目标】。
修改前备份触发、条件、动作、顺序、启用状态和执行账号；一次只改一条，保存后重新打开核对，并用隔离需求做正向和负向测试。禁止修改生产流水线及无关规则。
3. 项目管理员与流程负责人
ADM01 项目首次审计或接管
触发：新项目接入、规则无人维护或准备复制到另一个项目。
使用 yunxiao-requirement-lifecycle，权限=audit。
请审计项目【项目名】，先判断是stage_tasks、oneos_delivery还是迁移中。盘点工作流状态、标签、工作项类型、全部自动化规则、执行账号、前后端仓库、dev/develop、Testhub、缺陷状态、test/prod流水线、发布证据和验收门禁。
输出当前—目标差距、规则控制ID映射、风险、P0-P3实施顺序和不能自动化的人工门禁。不要修改线上配置。
完成证据：项目画像、规则清单、模型判断、缺口和迁移阶段齐全。
ADM02 迁移到OneOS终态模型
触发：准备从阶段任务切换到交付主任务模型。
使用 yunxiao-requirement-lifecycle，权限=plan。
项目【项目名】准备迁移到oneos_delivery。请检查待测试、发布中、发布失败状态，交付主任务识别方式，开发/测试/发版任务工作流，A03/A06/A08/A09幂等与负责人，多仓库MR门禁、Testhub分包、生产证据和L01/L02状态。
只有十项迁移门禁全部通过才给出停用旧R/TK规则清单；否则保留现网主链，只列安全可做项和回滚方案。
完成证据：迁移门禁逐项结论，而不是笼统“可以迁移”。
ADM03 规则变更后回归
触发：新建、修改、启停任何生命周期规则。
使用 yunxiao-requirement-lifecycle，权限=test。
项目【项目名】刚修改规则【规则名/控制ID】。请创建或复用隔离测试需求，验证事件【事件】、源状态【状态】、目标状态【状态】，并增加错误状态、无正式关联、部分MR、重复回调或后继连锁等负向场景。
结果只能记录为通过、异步通过、未触发、误触发或阻塞，并附执行日志和回滚入口。
ADM04 定期治理
触发：季度检查、状态/标签重命名、新增仓库或人员离职。
使用 yunxiao-requirement-lifecycle，权限=audit。
请对项目【项目名】执行运行治理检查：规则执行账号和权限、失败日志、状态/标签重命名影响、新增仓库Webhook、多仓库MR覆盖、超过7天无活动分支、回调签名/幂等/重试、L01/L02以及生产和验收证据分离。
输出需要立即修复、计划修复和仅观察三类清单。
4. 产品负责人
PO01 新建并确认需求
触发：需求范围、负责人、优先级和验收标准已明确。
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需要建立需求【标题】。范围：【范围】；不包含：【排除项】；负责人：【姓名】；优先级：【级别】；目标迭代：【迭代】；验收标准：【标准】。
请先查重，再创建或完善产品类需求。若项目为oneos_delivery，校验唯一【交付】主任务；若仍为stage_tasks，不要擅自创建主任务。完成后告诉我需求编号、正式关系、当前状态和下一责任人。
PO02 批准进入分析或快轨待开发
触发：需求确认后决定正常分析，或低风险小改走快轨。
正常路径：
项目【项目名】需求【编号】已确认，批准进入分析。使用 yunxiao-requirement-lifecycle，权限=apply。请核查范围、负责人和验收标准齐全，再按当前流程模型触发分析入口；不要跳过缺失信息。
快轨路径：
项目【项目名】需求【编号】批准快轨到待开发，批准人【姓名】，原因【原因】，验收标准【标准】。使用 yunxiao-requirement-lifecycle，权限=apply。请确认快轨边存在、唯一交付主任务已同步且没有循环风险；缺少任一条件就停止并报告。
PO03 需求范围变更
触发：开发或测试中修改范围。
使用 yunxiao-requirement-lifecycle，权限=plan。
项目【项目名】需求【编号】当前【状态】，拟变更：【新增/删除内容】；原因：【原因】；受影响资产：【开发任务/MR/用例/缺陷/发布范围】。
请先做影响分析，列出需要重开或新增的任务、MR、用例和验收项，以及是否应回退需求状态。未经我确认不要直接改状态或删除已有证据。
PO04 产品验收通过并关闭
触发：生产发布完成，业务验收通过。
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】当前为发布完成。验收人【姓名】，验收时间【时间】，验收环境【生产】，验收结果【通过】，证据【链接/附件/记录】。
请核查生产发布证据与需求范围一致，并确认不存在未关闭验收项；满足后执行已关闭并回报审计证据。不得用流水线成功替代本次验收。
PO05 验收不通过
使用 yunxiao-requirement-lifecycle，权限=plan。
项目【项目名】需求【编号】生产验收不通过。问题：【问题】；证据：【证据】；影响：【影响】。
请创建或关联可追踪缺陷/改进任务，建议应回到的真实状态和责任人；未经批准不要直接关闭需求或覆盖原发布记录。
5. 需求分析人员
BA01 开始分析
项目【项目名】需求【编号】由我开始分析，实际开始时间【时间】。使用 yunxiao-requirement-lifecycle，权限=apply。请核查当前状态和我的关联任务，将分析任务改为处理中并确认需求进入分析中；如果项目为oneos_delivery，则按主任务权威方向同步，避免双向循环。
BA02 分析完成
项目【项目名】需求【编号】分析已完成。产物：【需求说明/流程/字段/边界链接】；未决项：【无或列表】；验收口径：【口径】。
使用 yunxiao-requirement-lifecycle，权限=apply。请先检查分析任务非零且全部完成、产物可访问、未决项已处理，再推进分析完成；回报触发的是原生规则、桥接还是人工门禁。
6. 设计人员
UX01 开始设计
项目【项目名】需求【编号】开始设计，设计负责人【姓名】，原型地址【地址】，实际开始时间【时间】。使用 yunxiao-requirement-lifecycle，权限=apply。请核查正式关联设计任务和当前状态，再更新设计任务为处理中并确认需求进入设计中。
UX02 设计完成并交接开发
项目【项目名】需求【编号】设计完成。原型版本【版本】；设计稿【链接】；交互说明【链接】；响应式范围【范围】；已确认人【姓名】；遗留项【无或列表】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查设计任务和交付物后完成设计阶段，并检查是否只创建一组正确的开发任务。不要因为标题含“开发”就视为已正式关联。
完成证据：设计任务已完成、需求到设计完成；后继开发任务创建成功后才到待开发。
7. 交付负责人
DL01 创建或核查唯一交付主任务
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】需要建立【交付】主任务，负责人【姓名】。请先按正式关系和交付标签查重；不存在才创建，存在一条则复用，存在多条则停止并列出冲突。主任务必须正式关联需求，不能只靠标题前缀。
DL02 阶段同步异常
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】需求【编号】状态【需求状态】，交付主任务【任务编号】状态【任务状态】，两者不一致。
请判断权威方向、检查Y01-Y16、来源防重和执行日志，说明应补偿哪个对象。不要同时双向写入造成循环。
8. 技术负责人
TL01 拆分开发任务
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】已到待开发。请按以下范围拆分开发任务：前端【范围/负责人/仓库】，后端【范围/负责人/仓库】，其他【范围】。每条任务必须正式关联需求和交付主任务、标签=开发、状态=待处理，并记录目标dev/develop分支。查重后创建，禁止重复任务。
TL02 仅前端或仅后端需求
项目【项目名】需求【编号】只涉及【前端/后端】，不涉及【另一端】。使用 yunxiao-requirement-lifecycle，权限=apply。请只创建实际需要的开发任务，并把不涉及的仓库明确记为不适用；不要用缺少另一端MR阻塞，也不要把未盘点仓库默认为已完成。
TL03 开发完成门禁核查
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】需求【编号】准备判定开发完成。相关仓库：【列表】；开发任务：【列表】；MR：【列表及目标分支】。
请确认所有非取消开发任务完成、所有相关MR正式双关联并合并到真实dev/develop；任一仓库未完成都保持开发中。输出缺口，不要手工改成开发完成。
9. 开发人员
DEV01 真实开始开发并创建分支
使用 yunxiao-requirement-lifecycle，权限=apply。
我开始处理项目【项目名】需求【编号】的开发任务【任务编号】，真实开始时间【时间】，仓库【仓库名】，基线【dev/develop】，拟建分支【feature/编号或fix/编号】。
请先确认基线真实存在且任务为待处理，再从基线创建或指导创建分支，并确保分支同时正式关联需求和开发任务。完成后核查需求=开发中、任务=处理中；不要用首次提交时间覆盖真实开始时间。
DEV02 提交代码并创建MR
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】，开发任务【任务编号】，仓库【仓库】，分支【分支】，目标分支【dev/develop】。改动摘要：【摘要】；本地验证：【命令和结果】。
请先拉取并检查冲突，再按仓库规范提交、推送并创建MR；MR必须正式关联需求和开发任务。不要直接推保护分支，不要因为提交成功就把开发标为完成。
DEV03 多仓库部分完成
项目【项目名】需求【编号】目前仅仓库【仓库A】的MR【编号】已合并，仓库【仓库B】仍在开发。使用 yunxiao-requirement-lifecycle，权限=audit。请确认需求和交付主任务仍保持开发中，并检查是否存在“部分MR导致提前完成”的误触发规则。
10. 代码评审人员
REV01 评审要求修改
项目【项目名】MR【编号】评审不通过，需要修改：【问题列表】。使用 yunxiao-requirement-lifecycle，权限=document。请把评审结论关联到需求【编号】和开发任务【编号】，确认MR保持未合并、开发任务保持处理中、需求保持开发中。
REV02 MR合并后核查
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】MR【编号】已合并到【dev/develop】，关联需求【编号】、开发任务【编号】。请等待异步窗口后核查任务状态；再汇总同需求所有仓库和MR。只有全部相关任务和MR完成才允许需求进入开发完成，并确认测试任务只创建一条。
11. 测试负责人和测试人员
QA01 建立测试任务和用例范围
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】开发已完成，目标迭代【迭代】，测试负责人【姓名】。请查重后创建或复用唯一【测试】任务，并将测试计划按需求编号建立独立用例包。范围：【功能/接口/权限/兼容/回归】；不适用：【列表】。正式关联需求、主任务和测试计划后进入待测试。
QA02 test部署成功，开始测试
项目【项目名】需求【编号】的test部署成功，流水线【名称】，执行ID【ID】，环境【test】，部署时间【时间】。使用 yunxiao-requirement-lifecycle，权限=apply。请校验执行ID、范围和重复回调，再允许测试任务和需求进入测试中。明确记录：本事件不能推进发布完成。
QA03 用例失败并提交缺陷
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】，测试计划【计划】，用例【用例ID】执行失败。环境【环境】；前置条件【条件】；步骤【步骤】；实际结果【实际】；期望结果【期望】；证据【截图/日志】；严重程度【级别】。
请查重后创建或关联缺陷，并把缺陷与原用例、需求正式关联。保持用例未通过、测试任务和需求测试中；不要把创建缺陷当作测试完成。
QA04 缺陷复测通过
项目【项目名】缺陷【编号】已在环境【环境】复测，原用例【用例ID】重新执行通过，证据【证据】，复测人【姓名】，时间【时间】。
使用 yunxiao-requirement-lifecycle，权限=apply。请将原用例更新为通过，并把缺陷进入项目真实关闭态；随后重新核查本需求是否仍有未执行、阻塞、失败用例或未关闭缺陷。
QA05 缺陷复测失败
项目【项目名】缺陷【编号】复测失败，原用例【用例ID】仍未通过。实际结果【结果】；证据【证据】。
使用 yunxiao-requirement-lifecycle，权限=apply。请重开缺陷或转回项目真实处理中状态，保持原用例未通过、需求测试中，并通知原修复负责人。不要保留“已修复/已关闭”。
QA06 测试验收完成
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】申请完成测试。测试计划【计划】；用例包【范围】；执行统计【通过/失败/阻塞/未执行】；缺陷清单【编号+状态】；测试负责人【姓名】。
请按TC01-TC03和DF01-DF03核查。只有全部范围用例已执行并通过、失败用例已复测、缺陷由测试关闭时，才完成测试任务并推进需求测试完成；否则列出阻塞项。
12. 缺陷修复人员
BUG01 接收缺陷并开始修复
使用 yunxiao-requirement-lifecycle，权限=apply。
我接收项目【项目名】缺陷【编号】，关联需求【编号】、原用例【ID】，开始修复时间【时间】，仓库【仓库】，拟用分支【fix/缺陷编号】。
请核查缺陷、需求和用例的正式关联，再把缺陷转入真实处理中状态；分支和MR同时关联缺陷、需求及对应开发任务。
BUG02 修复完成交给测试
项目【项目名】缺陷【编号】已修复。分支【分支】；MR【编号】；合并目标【dev/develop】；验证结果【结果】；部署环境【test/尚未部署】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查代码和部署证据后把缺陷改为已修复并交给测试复测。不要关闭缺陷，不要把原失败用例改为通过。
13. 运维与发布负责人
OPS01 test部署回报
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】test流水线【名称】执行【成功/失败】，执行ID【ID】，提交/MR范围【范围】，时间【时间】。
请核查本次执行关联的需求和幂等记录。成功只允许测试开始；失败保持原状态并记录原因。不要触发生产发布完成。
OPS02 创建迭代发版任务
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】迭代【迭代名/ID】准备发版，计划窗口【时间】，负责人【姓名】，本批需求【编号列表】，生产流水线【名称】。
请查重后创建或复用唯一【发版】任务，正式关联迭代和本批需求，并生成发布范围与回滚项。需求未测试完成或范围不一致时停止，不进入发布中。
OPS03 开始生产发布
项目【项目名】发版任务【编号】批准开始生产发布。审批人【姓名】；窗口【时间】；生产流水线【名称】；本批需求【列表】；回滚方案【链接】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查全部需求测试完成、范围一致和审批证据，再进入发布中。只操作明确的生产发布，不修改流水线定义。
OPS04 生产发布成功
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】生产流水线【名称】执行成功，执行ID【ID】，环境【prod】，完成时间【时间】，发布范围【需求/MR/版本】，证据【链接】。
请验证签名、时间戳、执行ID幂等和范围，推进发版任务及本批需求到发布完成并停留，通知产品验收。禁止自动进入已关闭。
OPS05 生产发布失败或重试
失败：
项目【项目名】生产流水线【名称】执行失败，执行ID【ID】，失败阶段【阶段】，原因【原因】，影响需求【列表】，回滚结果【结果】。
使用 yunxiao-requirement-lifecycle，权限=apply。请记录失败证据并推进到发布失败；不得伪造成功或关闭需求。
重试：
项目【项目名】发版任务【编号】批准从发布失败重试，批准人【姓名】，新执行ID【ID】，已修正原因【说明】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查发布失败→发布中流转边、幂等键和范围后开始重试，保留原失败记录。
14. 业务验收人员
ACC01 验收通过
我是业务验收人【姓名】。项目【项目名】需求【编号】已在生产环境按验收项【列表】验证通过，时间【时间】，证据【链接/附件】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查身份、发布完成状态和证据范围后关闭需求，并保留验收记录。
ACC02 验收不通过
我是业务验收人【姓名】。项目【项目名】需求【编号】生产验收不通过，失败项【列表】，实际结果【结果】，证据【证据】。
使用 yunxiao-requirement-lifecycle，权限=plan。请建立可追踪问题清单，分析应回到测试、开发还是重新发布，并指定下一责任人；不要关闭需求。
15. 集成桥接负责人
INT01 回调未生效或重复
使用 yunxiao-requirement-lifecycle，权限=audit。
桥接控制【A03/A06/A08/A09/其他】，项目【项目名】，需求【编号】，事件ID【ID】，时间戳【时间】，回调结果【未生效/重复/失败】，日志摘要【摘要】。
请核查签名、时间窗、防重放、幂等键、当前状态、权限、重试和审计日志。不要绕过校验直接补写状态；给出安全重试或人工回退方案。
INT02 幂等补偿
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】控制【控制ID】需要补偿，原事件ID【ID】，期望对象【任务/状态】，当前对象【实际】。已确认原操作未成功且不存在重复对象。
请再次查询幂等键和正式关系，只补偿缺失动作；完成后输出新旧事件关联、对象ID和重复检查证据。
16. 异常和催办话术
状态长时间不动
项目【项目名】需求/任务【编号】在【状态】停留【时长】，最后真实事件【事件】，负责人【姓名】，关联资产【列表】。使用 yunxiao-requirement-lifecycle，权限=audit。请判断是业务未完成、自动化未触发还是异步失败，并给出下一责任人和最小恢复动作；不要直接跳状态。
状态被提前推进
项目【项目名】需求【编号】从【源状态】意外进入【目标状态】，时间【时间】。使用 yunxiao-requirement-lifecycle，权限=audit。请检查后继规则、全部关联项口径、部分MR、未复测缺陷、test/prod混用和L01/L02，定位真实触发规则并给出回滚建议。未经确认不要回退状态。
任务重复创建
项目【项目名】需求【编号】出现重复【交付/开发/测试】任务：【任务列表】。使用 yunxiao-requirement-lifecycle，权限=audit。请检查幂等键、正式关系和重复回调，确定保留项及合并/取消方案。未经授权不要删除任务。
17. 节点交接清单
每次角色交接都让Codex确认以下内容：
- 项目、需求、任务和流程模型准确。
- 源状态与目标状态明确。
- 事件真实发生，且正式关联可见。
- 当前责任人和下一责任人明确。
- 交付物、代码、用例、缺陷或发布证据可访问。
- 正向条件全部满足，负向阻塞项为零。
- 自动化结果与人工准备动作分开记录。
- 异步等待后重新核查状态和执行日志。
- 没有误触发后继规则或重复创建。
- 回滚入口、人工回退和未完成事项已记录。
Codex的节点回报统一使用：
项目：
流程模型：
工作项：
源状态 → 实际状态：
本次真实事件：
执行动作：
触发方式：原生规则/桥接/人工门禁/未触发
验证结果：通过/异步通过/未触发/误触发/阻塞
证据：
未完成项：
下一责任角色：
允许的下一动作：
回滚入口：