设计评审与任务拆分（V10）

内容类型：开发准入与任务切片难度：进阶适合：新项目、大功能、跨模块或高风险设计阅读时间：约 12 分钟

设计评审的目标不是给每次提交增加一道手续，而是确认：当前设计是否足以安全实施，任务切片是否能形成可验证闭环，是否还有真正会改变结果的 Blocking Unknowns。

1. 先判断是否需要正式设计评审

需要：

• 新项目第一阶段；
• 新子系统/新设备接入；
• 状态机、联锁、多设备协调；
• 协议/数据库/公共接口重大变化；
• 大范围迁移或发布级改造。

通常不需要：

• UI MicroPatch；
• 明确的 DisplayOnly 修改；
• 已有 stable seam 内的局部 Bug；
• 用户已经给出完整实施规格的 Execution；
• Temporal Regression 调查阶段；
• 临时 ExperimentalChange。

这些使用 Compact Brief / Behavior Contract 即可。

2. 评审先看“行为和边界”，不是文档是否齐全

检查项	通过标准
Blocking decisions	会改变业务结果的问题已确认
NonGoals	本次明确不做的内容存在
系统边界	软件、设备、操作员、外部系统职责清楚
State / Side-effect owner	关键状态和副作用有明确 owner
行为语义	Trigger / Condition / Action / Reset / Record 清楚
设备安全	危险动作有后端保护和 HITL 边界
数据/协议兼容	需要兼容的历史数据、协议、配置已识别
验证	Verification Level 与风险匹配

不要求为了“评审完整”把 UI、通信、数据、状态机、线程五套详细设计全部写完；只评审本次范围。

3. 三种任务卡强度

A. MicroPatch

无需正式任务卡：

Target
NonGoals
AffectedFile/Owner
VerificationLevel

B. BehaviorPatch / Existing Feature

使用短契约：

Target
CurrentBehavior
Trigger / Condition / Action / Reset / Record
NonGoals
AffectedScope
VerificationLevel

C. New subsystem / High-risk cross-module

才使用完整任务卡：

TaskId:
Goal:
SourceRequirement:
Dependencies:
AllowedScope:
ForbiddenScope:
Inputs:
BehaviorContract:
ExpectedOutputs:
VerificationLevel:
FocusedEvidence:
Hardware/HITL:
RollbackOrRecovery:
BlockingUnknowns:

4. 拆任务按“可验证行为闭环”，不是按文件类型

不推荐机械拆成：

先改 Model
→ 再改 Service
→ 再改 ViewModel
→ 再改 XAML

这样中间阶段经常没有可观察价值。

更好的切片：

一个用户/设备行为
→ 最小跨层实现
→ focused verification
→ 下一个行为

例如新设备接入可以按：

1. Fake/协议样本能完成一次查询
2. 真实通信 Session 能连接/断开
3. UI 能显示在线状态
4. 参数应用闭环
5. 故障/恢复闭环
6. 真实设备验收

每一步都能回答“这一步已经证明了什么”。

5. 不要为了任务小而过度碎片化

好的任务切片：

• 目标单一；
• 行为可以独立观察；
• 修改范围足够聚焦；
• 验证成本可控；
• 失败时容易定位。

不好的切片：

• 每改一个方法就建任务；
• 一个功能被拆成十几个没有独立价值的中间步骤；
• 为了形式每一步都 build/test；
• 一个两行 UI 修改也写完整设计卡。

6. 验证等级决定任务验收，不是“每任务全构建”

类型	默认验证
V0	Diff / static
V1	affected build，必要 focused test
V2	focused test / Fake / Replay
V3	workflow/state/interlock smoke
V4	release/full checkpoint

任务卡只写本次真正需要的证据。

例如：

VerificationLevel: V2
AffectedBuild: DeviceControl.App
FocusedTest: PowerSupplyLimitTests
Replay: Protocol capture #3
HardwareVerification: HardwarePending

比“编译测试通过”更可追溯。

7. RegressionFix 不在设计评审阶段猜根因

用户说“昨天正常、今天异常”时：

known-good
→ changed files
→ behavior delta
→ evidence

先找时间差异，不先组织架构评审，更不要为了“顺便优化”把回归修复变成重构任务。

8. ExperimentalChange 要单独标记恢复方式

临时测试任务至少写：

ExperimentalScope
OfficialRulePreserved: Yes/No
EntryPoint
RestoreMethod
Verification

如果只是临时放宽边界，不把正式验收基线同步改掉。

9. 什么情况下需要 Rollback/Recovery

强制关注：

• 数据/schema 迁移；
• 部署；
• 协议兼容；
• 真实设备危险动作；
• 大范围架构变更；
• 不可逆外部写操作。

普通可逆源码小改依赖 Git 即可，不必每张任务卡都写一套复杂回滚流程。

10. 开发准入门

当前范围满足以下条件即可进入实现：

• BlockingUnknowns 为空；
• 目标和 NonGoals 清楚；
• affected scope 有合理边界；
• 高风险副作用和设备动作已识别；
• Verification Level 已确定；
• 需要 HITL 的操作已明确。

不要求所有未来任务一次性拆完。可以完成当前 Frontier/阶段后继续细化后续。

11. 推荐开发顺序

新项目通常优先：

最小业务闭环
→ Fake/Simulation
→ 稳定 seam
→ UI/Workflow
→ 真实设备
→ 高风险异常恢复
→ 发布验证

已有项目则优先：

current behavior / owner
→ target behavior
→ minimal change surface
→ focused verification

对应能力

项目	内容
新项目编排	00-project-orchestrator、02-system-designer
已有功能	08-feature-updater
回归	09-bug-investigator / 10-bug-fixer
验证	11-regression-guardian、12-test-designer
验证体系	AI 开发验证体系
最小修改	功能修改最小流程

一句话原则

正式设计评审只服务真正需要它的复杂工作；任务按可验证行为闭环切片，而不是把每个小改都包装成完整项目流程。