games-development-ai/.agents/skills/execution-plan-slicing.md

name, description

name	description
execution-plan-slicing	当写或评审多单元执行 plan、或感到「每到下阶段前面阶段的工作都要返工」时使用:辨别横切关注面 vs 纵切成果切片、诊断返工信号、原地换轴重组、「设计 HOW 移交/执行契约必留」判据,及换轴必查七坑。

执行 plan 切分轴 —— 横切关注面 vs 纵切成果切片

一份多单元的执行 plan,工作单元按什么轴切,决定它能不能照着走。切错轴,执行时每推进一个单元都要回头补前一个,表现为"每到下个阶段,前面阶段的工作都要重做"。

两种切分轴

轴	怎么切	适合	风险
横切关注面(facet)	按活动类型 / 架构面切单元(框架、实例、校验、标准、门……)	给"设计怎么落地"建结构索引——每个面对应设计 SoT 一节	当执行序列用会返工
纵切成果切片(slice)	按可独立交付的成果切单元,每片自带它要的全部关注面	执行序列——按什么顺序一步步推到上线	难在找准"什么算一个完整成果"

横切答"设计有哪几个面",纵切答"按什么顺序交付"。同一批工作可以两种视图并存,但执行只能照纵切走。

什么时候横切会返工(诊断信号)

• 一个交付成果的目标和它的实现手段被切到了不同单元(目标挂 A、手段在 B/C)。做 A 时手里没有实现工具,必须回头做 B/C 才能推进。
• 一个真实成果纵向穿过多个关注面——要框架 + 实例 + 校验 + 标准 + 门一起到位才算交付,而它们分散在不同单元。
• 主观信号:推进时反复感到"每到下个阶段,前面阶段的工作要重做"。

依赖 ≠ 返工:依赖是 A 完成后 B 才开始、A 不回改(健康);返工是做 B 时发现 A 没做够、回头改 A(切分错)。横切单元之间常是后者伪装成前者。

换轴动作(重组,不推翻)

1. 横切结构不作废,降为"设计面对账":保留一张"单元 → 切片"映射表,作切片落地时下钻设计 SoT 的索引。横切的架构一致性(同口径同契约)由设计 SoT + 机器门保证,对账表只做映射。
2. 执行按纵切切片走:每片自带框架 / 实例 / 校验 / 标准 / 门,做完即交付、不回头。完成度回填对账表。
3. 切片按价值排序;切片间真实依赖要标实,别把"晚做"误写成"无强依赖可并行"——若 B 用到 A 在某里程碑才建成的基础设施,那就是实依赖,画依赖边、不画"可并行"。
4. 三层文档定位:设计 SoT(怎么设计)→ 执行序列 SoT(按什么顺序)→ 切片细化 plan(具体实现单元 / 文件 / 测试)。换轴产出的是中间层;每个切片开工前据设计 SoT 产一份它的细化 plan 再交付。

设计 HOW 移交、执行契约必须留(换轴最易丢的判据)

换轴压缩 WU 详细时,要分清两类细节,只有第一类能移交、第二类必须留:

• 设计 HOW(移交设计 SoT):架构形态、协议选型、能力矩阵、ADR——回答"为什么这么设计"。本就该在设计 SoT,执行 plan 重复一份只会双维护漂移。换轴时移交,靠"单元 → 切片"对账表的指针下钻。
• 执行契约(必须留在切片,或在切片细化 plan 承接、指针不悬空):迁移链路、灰度 flag、对照门槛、幂等、在途任务处理、配额扣退、切换门槛、回滚触发——回答"按计划执行时必须遵守什么、不做就出事"。它们不是设计,设计 SoT 的通用协议层不覆盖这种执行特定编排;压掉就丢了安全约束。

判据一句话:这条细节是"执行时要照着做、不做会出事"(回滚 / 幂等 / 在途)→ 执行契约,留切片;还是"架构为什么这么设计"(形态 / 协议 / 矩阵)→ 设计 HOW,移交设计 SoT。 换轴时逐 WU 过一遍,别把执行契约当设计细节一起压掉。

治理约束(别制造影子 SoT)

• canonical 唯一性门:同 topic 至多一份 canonical。换轴原地重构现有 plan、不新建第二份;文件名保留(防止引用它的活档死链);旧主轴内容降为对账小节(留痕、不删)。
• frontmatter supersedes 记"自身旧主轴版",git 留演进痕。

换轴时必查的七坑(双评审 + 执行核查实证)

• 过时口径搬运 → 假前置门:旧 plan 的某些状态可能已被设计 SoT 推翻(例:plan 写"协议定级待创始人拍",而设计 SoT 已三处明写"定级已冻")。照搬就把已就绪的执行项错挂成"等决策",制造不存在的阻塞。换轴时逐项核对设计 SoT 的当前状态,别信旧 plan 的措辞。
• 对账表漏面:横切有几个面,对账表就要覆盖几个(例:声称"八面"却只列六面,漏掉的面在换轴里掉落)。
• 元叙述:执行 SoT 别写"本文回答 X 不回答 Y、读本文你会知道……"这类教读者怎么读的话——直陈内容(散文红线,见 ../../AGENTS.md §6 第 12 条)。
• 评审状态漂移:重构时 frontmatter 的评审状态要对齐当前这一版,别把旧版的"已过评审"字面带过来误导读者与机器门。
• 执行契约被当设计细节压掉:换轴压缩时把“按计划执行必须遵守的约束”(迁移 / 灰度 / 回滚 / 幂等 / 在途 / 配额)误当设计 HOW 一起移交,执行到具体切片时丢了安全约束。判据见上节;换轴后逐 WU 核对执行契约有没有活的归宿(留切片 or 细化 plan 指针不悬空)。
• 可验证判据停在“有判据”、没钉死阈值:写完成判据时,判据里的数值边界(收敛环追加轮数上限、达标 delta 阈值、灰度门槛、基建线最小验收)要么当场钉死,要么明写“细化 plan 未填此值不得开跑”。只写“达到同等过门率 / 不无限调 / 加显式上限”而不给数,机器和人都判不了,等于没判据。
• 依赖图把排队顺序画成依赖边:切片按价值串行 ≠ 切片间有数据依赖。串行排队若用实线箭头画,读者会误读成阻塞依赖、把本可并行准备的切片错误串死。排队顺序与硬前置依赖用不同线型(实线 = 硬前置,虚线 = 排队 / 供给)并加图例。

来源

2026-06-26 plan①《生成引擎统一执行计划》换轴:横切 WU-A..F(框架 / 实例 / 八面 / 采标准 / 控制面 / 验收门)→ 纵切三切片(便宜档达标上线 / tier2 go/no-go / A11 调整回路)+ 基建线 + 已冻协议基线。触发 = 创始人 catch 两点:"每到下个阶段前面阶段的工作都要重做"(返工信号)、"主线是方案计划?没有执行计划吗?"(缺执行序列这个中间层)。双评审(Opus + Codex 末轮)揪出假前置门 / 对账漏面 / 元叙述 / 评审状态漂移四坑;落档后创始人再 catch“按计划执行会不会丢设计细节”,核出第五坑——切片一的便宜档灰度迁移契约 11 项(执行契约)被当设计细节一起压掉,补回切片一,并立“设计 HOW 移交 / 执行契约必须留”的判据。末轮 Codex 四维度专项评审(重连完整产出)再揪两坑补成第六、七坑——可验证判据未钉阈值(n=5 追加轮数上限、auto-vs-golden delta、基建线最小验收都曾停在“有判据无数值”)、依赖图把价值排队画成实线依赖边(易被误读成阻塞、串死本可并行的切片)。

相关:feature-design-doc.md(设计文档怎么写)、wave-close-checklist.md(收口同步纪律)、../workflows/ai-development-protocol.md(plan 在协议中的位置)、../rules/engineering-conventions.md(canonical 唯一性门 §10)。