Appearance
模板组合包（V10）
组合包不是“必须按顺序跑完的工作流”。V10 的原则是：先判断当前任务，再只拿真正需要的模板。 一个按钮文案可能只需要一句目标和 V0；新项目才需要需求、设计、测试等较完整组合。
1. 先选任务包
| 当前任务 | 推荐组合 |
|---|---|
| 只查当前实现 | Read-Only Trace 包 |
| 文案、样式、局部显示 | Fast / MicroPatch 包 |
| 阈值、连续次数、报警后果 | BehaviorPatch 包 |
| 以前正常、最近改坏 | RegressionFix 包 |
| 临时边界试验 | ExperimentalChange 包 |
| 新项目/新主流程尚未想清 | Discovery / 新项目包 |
| 串口/TCP/协议故障 | Communication Evidence 包 |
| 新页面/复杂交互 | UI Design 包 |
| 方案、总结、说明书、验收 | Technical Documentation 包 |
如果一个任务从简单变复杂，可以升级组合；不需要一开始把所有包一起加载。
2. Read-Only Trace 包
适合：
- “现在是 SING 还是 RUN？”
- “这个阈值在哪里判断？”
- “按钮最终调用哪个设备方法？”
- “这个日志值从哪里来的？”
只需要：
text
问题
+ target keyword/member
+ 最短调用链
+ CurrentBehavior / Evidence / Unknowns默认不需要：
text
需求模板
设计模板
构建
单测
修改记录入口：AI 辅助读懂 C# 项目。
3. Fast / MicroPatch 包
适合明确的小修改。
最小输入：
text
Target:
NonGoals:执行：
text
精确定位
→ 最小 Diff
→ V0/V1不默认加载完整 UI 设计、CONTEXT、ADR、全局 Memory，也不默认全 solution build/test。
入口：功能修改最小流程。
4. BehaviorPatch 包
适合：
- 15 A 改 16 A；
- 连续 5 次才触发；
- Alarm 改为 AlarmOnly；
- 磁盘不足只提示不阻断；
- 停机窗口/测试窗口规则变化。
核心模板只有六行：
text
Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:如果涉及测量值，再加：
text
RawValue:
EngineeringValue:
Conversion:
ThresholdBasis:
Aggregation:
LoggedUnit:验证按风险走 V2/V3 focused，不需要重新写完整 PRD。
5. RegressionFix 包
用户出现“以前正常、昨天改后异常”时，不先列一堆概率根因。
最小证据包：
text
CurrentSymptom:
KnownGood:
RecentChanges:
Logs/Replay:调查顺序：
text
known-good
→ changed files
→ relevant method/config/protocol diff
→ behavior delta
→ 必要时才生成可证伪假设
→ 最小修复
→ 同一反馈信号验证如果重试后自己恢复，记录 SuspectedTransient，不要直接写 RootCauseConfirmed。
入口：Bug / 回归定位。
6. ExperimentalChange 包
适合：
- 临时放开频率上限；
- 工程模式试更大范围；
- 现场做一次边界实验。
模板：
text
ExperimentalGoal:
TemporaryOverride:
FormalRulesToKeep:
Verification:
RestorePlan:优先窄入口、engineering override 和明确恢复方式。除非用户确认正式规格改变，否则不把实验条件同步写入 Domain、MES 和持久化规则。
入口：功能修改最小流程。
7. Discovery / 新项目包
只有业务规则真的未定时才展开。
推荐组合：
text
问题定义 / 用户场景
→ Decision Tree / Frontier
→ Requirement Delta / 第一版需求
→ 必要总体设计
→ 必要详细设计
→ Vertical Slices
→ 验收基线其中：
text
事实 → Agent 查
决策 → 用户定Blocking Unknowns 清零后应进入 Execution，不为了模板完整继续采访。
8. Communication Evidence 包
通信问题不应该只靠代码猜。
优先收集：
text
协议原文
原始 TX/RX
时间戳
正常样例
异常样例
超时/重试
连接状态
设备侧现象然后选择反馈方式：
text
Parser test
→ Fake
→ Replay
→ 日志时间线
→ 必要时真机入口：通信证据包、串口/TCP 通信任务。
9. UI Design 包
只有新页面、复杂交互、信息架构或操作流程变化才使用完整 UI 包。
推荐：
text
用户角色
高频任务
页面职责
关键状态
操作流程
设备状态/占用
异常/告警表现
ViewModel/Service 边界
V1–V3 验收纯文案、颜色、Margin、列宽不使用这套完整组合，直接 MicroPatch。
10. Technical Documentation 包
先识别文档类型：
text
设计方案
详细设计
研制总结
使用说明
测试/验收报告
需求规格
接口协议再使用：
text
Source Materials
+ Evidence Map
+ 当前文档 Profile
+ Figures/Tables
+ Review Checklist不把所有正式文档强行写成长段落，也不把只有设计证据的内容写成“经测试通过”。
入口：技术文档工程。
11. 验证包独立选择
模板组合和验证深度是两个维度。
text
V0 静态
V1 affected build
V2 focused fake/replay/test
V3 workflow/state/interlock
V4 release/full所以：
- MicroPatch 通常 V0/V1；
- BehaviorPatch 常见 V2/V3；
- 发布才默认 V4；
- 0 tests matched 不是 TestPassed；
- EnvironmentBlocked 和代码失败分开写。
入口：AI 开发验证体系。
12. 使用原则
- 先分任务再选包，不要先挑最长模板。
- 事实由 Agent 查，业务决策才问用户。
- 包可以升级，不要求从一开始就最重。
- 验证不能省，但验证强度可以很轻。
- 长期知识按 Context / Memory / ADR 分层。
- 小任务不为了“沉淀”制造额外文档。
最短入口
如果还不知道选哪个包：
text
$host-computer-dev
请先判断我的任务属于 Read-Only / Fast / Execution / Discovery；
如果是 Execution，再判断 MicroPatch / BehaviorPatch / RegressionFix / ExperimentalChange。
我的问题：
【填写】更多模板见 模板中心。
一句话原则
模板是按需工具箱，不是必须逐项打卡的流程表。