功能修改最小流程：从 MicroPatch 到 BehaviorPatch

内容类型：最小执行流程难度：基础适合：需要在现有项目中安全修改功能的开发者阅读时间：约 10 分钟前置：能定位当前功能的大致入口

“最小流程”不等于所有修改都先填一张完整表。V10 的原则是：先分清任务语义，再使用最小足够流程。

1. 第一步不是写 Plan，而是分流

情况	走什么	默认动作
只是问当前代码怎么工作	Read-Only Trace	查最短调用链，给结论，不改代码
改文案、颜色、字号、列宽、简单提示	Fast / MicroPatch	精确定位 → 修改 → V0/V1
改阈值、连续次数、报警/停机、状态后果	Execution / BehaviorPatch	6 行行为契约 → 实现 → focused 验证
“以前正常，最近改后异常”	RegressionFix	known-good 对比优先
“先临时放开，我做边界测试”	ExperimentalChange	优先临时覆盖，可恢复
新业务流程仍有关键未知	Discovery	先把阻塞业务问题问清楚

2. Read-Only Trace：只查现状不要启动修改任务

典型问题：

这个值在哪判断？
配置从哪个目录读？
停机窗口是 SING 还是 RUN？
是一帧越限还是连续多帧？

Agent 应该：

精确符号/关键词
→ 直接 caller/callee
→ 必要配置/测试
→ 结论 + 关键位置

默认不 build/test、不建任务记录、不加载 UI/架构/文档专家。

3. MicroPatch：纯展示小改不要被流程拖慢

适合：

• “负载电流”改为“充电电流”；
• 按钮字体从 17px 改为 14px；
• 表格列宽、Margin、颜色；
• 两行范围提示；
• 复用已有紧凑按钮样式。

推荐流程：

rg 精确定位
→ 检查是否纯 DisplayOnly
→ 修改
→ git diff --check
→ 需要时构建受影响项目
→ END

UI MicroPatch Bypass

这类任务默认：

• 不自动加载大型外部 UI Skill；
• 不读全局 Memory、CONTEXT.md、ADR；
• 不写完整 Plan；
• 不默认跑全套 UnitTests。

如果调查中发现它其实影响业务校验、状态机、设备动作，再升级为 Execution。

4. 一个数字先判断：DisplayOnly 还是 DomainConstraint

例如“过流保护最大值从 15 A 改为 16 A”，看起来只是一个数字，但可能同时存在：

UI 提示
参数页校验
Domain/Application 校验
MES 参数校验
设备应用前校验
测试

V10 不全仓库乱搜，而是固定检查一次：

UI → Domain/Application → MES/API → DeviceApply → FocusedTests

• 如果只是文字展示：DisplayOnly，不要改业务逻辑；
• 如果正式限制也变化：DomainConstraint，再沿上述链路同步。

5. BehaviorPatch：运行规则用 6 行行为契约

涉及阈值、连续次数、状态切换、告警和停机时，先写：

Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:

这不是文档负担，而是防止“需求一句话、实现自己猜”的最小语义锁。

5.1 连续 N 次判断必须说清五件事

出现“连续 5 次”“连续 N 帧”“防抖”“平均”时，快速确认：

Consecutive?          是否必须连续
ResetOnGood?          正常一次是否清零
InvalidSamplePolicy?  无效帧如何处理
ReportOnce?           一个窗口是否只报一次
ResetBoundary?        下一轮什么时候复位

如果用户已经明确，就直接实现；只有这些答案会改变业务结果且当前不清楚时才提问。

5.2 报警、故障和提示分级

类型	控制后果
InterlockFault	报警 + 停止/阻断
AlarmOnly	报警/记录，流程继续
Advisory	提示操作员，不改变主流程；是否需要确认由具体场景决定
Information	仅展示

比如“停机窗口残余电流连续 5 帧超限，只报警不停止试验”必须明确属于 AlarmOnly，不能沿用旧的故障停机路径。

6. 测量值任务：Raw 和工程量不能混

涉及示波器、电流、电压、温度、传感器时，至少确认：

项	要确认什么
RawValue	仪器原始读取是什么
EngineeringValue	用户看到的工程量是什么
Conversion	两者如何换算
ThresholdBasis	阈值和哪一层数据比较
Aggregation	峰值、均值、RMS、连续帧还是其它
LoggedUnit	故障日志最终记录什么单位

例如 CH2 原始峰值是 V，通过 0.005 V/A 换算为 A。如果用户要求“记录未换算原始值”，日志应写成“原始 CH2 峰值（V）”，不要称为“原始电流（A）”。

7. ExperimentalChange：边界测试不要永久改正式规则

用户说：

先去掉 1500 Hz 限制，我先做边界测试。

默认优先：

1. 工程/开发配置开关；
2. 本地 override；
3. 窄入口临时覆盖；
4. 明确恢复方法。

正式 Domain、MES、持久化规则默认保持不变。

只有用户明确说“以后正式规格就取消这个上限”，才升级为正式 DomainConstraint / BehaviorPatch。

8. Advisory：只提醒不阻断

典型：启动试验前检查磁盘剩余空间，低于 5 GB 提醒，但不能影响测试。

标准语义：

check exception → 记录/忽略 → continue
condition true   → warning → continue

如果具体业务要求操作员确认，再显式增加 acknowledge；确认动作不是 Advisory 的默认含义。

不要因为一个提示性功能意外引入新的启动失败点。

9. Execution Lane 的 Implementation Brief 不超过 10 行

需求已经明确时，不再重复一份几十行 Plan。

推荐格式：

目标：
行为契约：
影响层：
不改：
验证：

用户已经给出完整方案时，Agent 只核对代码事实，不重新做需求访谈。

10. 验证强度独立选择

等级	示例
V0	纯文案、静态显示
V1	XAML、普通局部代码
V2	设备、MES、存储、共享约束
V3	状态机、告警后果、联锁、并发
V4	发布/广泛兼容

典型选择：

• 改按钮文字：V0；
• XAML 布局：V1；
• 15 A → 16 A 且涉及 MES/设备应用：V2 focused；
• InterlockFault → AlarmOnly：V3 focused + Workflow Smoke；
• 正式发布：V4。

不要把“所有修改都全量测试”当成安全。更好的做法是让验证与实际影响范围一致。

11. 可直接复制的 Prompt

小 UI 修改

$host-computer-dev
这是现有页面内的小 UI 修改：把“负载电流”改为“充电电流”。
请按 MicroPatch 处理，只改操作员可见文案；如果发现它会影响业务字段或设备逻辑，再告诉我。

运行规则修改

$host-computer-dev
把停机窗口残余电流判断改成连续 5 帧达到阈值才报警。
任意正常帧清零，同一停机窗口只报一次，下一窗口复位。
只报警，不停止试验；报警中记录 5 帧原始 CH2 峰值和单位。

临时边界测试

$host-computer-dev
我准备做边界测试，想临时放开重复频率上限。
请优先采用可恢复的工程测试覆盖，不要默认永久修改正式 MES 和领域规则。

12. 什么时候升级到完整 Discovery / Design

下面任一项仍然不清楚，而且答案会改变业务结果时，再升级：

• 谁在什么场景使用；
• 主流程先后顺序；
• 状态如何切换；
• 故障后如何恢复；
• 安全联锁是否停止；
• 协议/Schema/兼容策略；
• 多个实现方向对应不同业务含义。

不是“改了多个文件”就自动变成 Discovery。

13. 完成前检查

• 修改范围是否仍然符合本任务；
• 是否把提示误做成阻断；
• 是否把 AlarmOnly 误接入故障停机；
• Raw/工程量和单位是否一致；
• 临时实验修改是否可恢复；
• 测试是否 focused，而不是无理由全量；
• Git Diff 是否出现计划外文件。

下一步

如果是回归或 Bug，进入调查流程 生成回归清单 返回 Skill 说明