Appearance
按问题找方案（V10）
不需要先判断“这是 UI、通信、线程还是架构问题”。先找一句最像你现在处境的话。
先分任务，再决定看多少代码、问多少问题、跑多少验证。
1. 只是想知道现在怎么工作的
例如：阈值在哪判断、按钮会不会下发设备、配置从哪里读、当前是 SING 还是 RUN。
text
Read-Only Trace
→ owner / caller / sink
→ 关键证据
→ 结论
→ END2. 只是改一个很小的东西
文案、颜色、字号、Margin、列宽、已有 Style：
text
Fast / MicroPatch
→ 最小 Diff
→ V0 / V1不要为了一个 Label 重新做 UI/架构设计和全量测试。
进入：功能修改最小流程
3. 改阈值、连续次数、报警或停机规则
先固定：
text
Trigger / Condition / Action / Reset / Record / NonGoals再明确 Information / Advisory / AlarmOnly / InterlockFault。
进入：行为与告警语义
4. 只改一个数字，但 UI/MES/设备总不一致
先判断：
text
DisplayOnly
DomainConstraint
ExperimentalChange正式约束只沿：
text
UI → Domain/Application → MES/API → DeviceApply → FocusedTests进入：业务约束跨层传播
5. 以前正常，最近改完才坏
text
RegressionFix
→ known-good
→ changed files
→ relevant method/config/protocol diff
→ behavior delta“当前代码看起来可疑”不等于本次回归根因。
进入：Bug / 回归定位
6. 日志很多，不知道从哪一条开始看
不要只看最后一条 Error。
text
对齐时间戳
→ 建关键事件时间线
→ 找第一个异常点
→ 向前找触发上下文
→ Evidence / Inference / Unknown多源日志可以同时包含 UI 操作、App State、TX/RX、设备错误、MES、存储等。
进入：日志与时间线诊断
7. 问题偶发，重试一下又好了
优先保存：
text
时间戳 + 状态 + TX/RX + 第一个异常点尽量转成 Fake/Replay。只有“重试恢复”时保持 SuspectedTransient，不要直接宣布网络/设备瞬态是根因。
8. 串口、TCP、SCPI、Modbus 有问题
- 只查一条命令路径 → Read-Only；
- 明确局部规则修改 → Execution；
- 新设备/新协议关键规则未知 → Discovery；
- 现场偶发 → Raw + Timeline + Replay；
- 重连/Session 冲突 → 生命周期与 Session Owner。
9. 第一次能运行，第二次启动失败 / 端口占用
检查：
text
Owner / Create / Start / Stop / Cancellation / Dispose / Recreate重点找第二 Session、旧 receive loop、重复 Timer、重复事件订阅和未传播 Cancellation。
进入：线程与资源生命周期
10. UI 卡顿、CPU 高、内存增长、越跑越慢
先量化：多久出现、CPU/内存多少、UI 延迟多少、Stop 要多久。
text
Baseline
→ narrow hotspot
→ one change
→ same scenario re-test进入：性能与长稳诊断
11. 界面像调试器，实验人员看不懂
text
OperatorSummary
= 发生了什么 + 当前后果 + 下一步动作
DiagnosticDetail
= 原始协议 + 错误码 + 堆栈 + 时间线进入：操作员界面与维护诊断
12. 原始值、换算值和单位对不上
检查：
text
RawValue / EngineeringValue / Conversion
ThresholdBasis / Aggregation / LoggedUnit进入：测量值语义
13. 临时放开限制做边界试验
text
engineering override
→ 窄入口
→ 正式规则默认保持
→ 明确恢复方式如果实验涉及真实高风险设备状态，还需 Hardware Safety / HITL。
14. 想让 AI 直接连真机验证
先区分软件验证、Fake/Replay、真机只读、真机状态改变。
默认：
text
HardwareAction: ForbiddenByDefault高压、运动、阀门、继电器、加热、气路等高风险动作即使授权仍保持 HITL。未执行时写 HardwarePending。
进入：真实设备操作安全
15. 编译通过了，但功能还是不对
Build 只证明能编译。
检查任务范围、Behavior Contract、跨层约束、设备动作和 Verification Level。
16. AI 每改一点就跑一大堆测试，太慢
text
V0 静态
V1 局部构建
V2 设备/通信/数据 focused
V3 状态/联锁/workflow
V4 发布/fullFocused First；0 tests matched 不算通过。
进入：测试与回归
17. 新功能自己也没想清楚
这时才真正进入 Discovery：
text
Facts → Agent 查
Decisions → 用户定
Frontier → 当前阻塞问题
Deferred → 不阻塞当前版本进入：需求发现与拆解
18. 要写设计方案、研制总结、说明书、验收资料
先区分文档类型，再按证据等级写。不能确认的内容保持 Unverified / DesignOnly / HardwarePending。
进入：技术文档工程
19. 还是不知道属于哪一种
text
$host-computer-dev
请先判断我的任务属于 Read-Only / Fast / Execution / Discovery。
如果是 Execution，再判断 MicroPatch / BehaviorPatch / RegressionFix / ExperimentalChange。
我的问题：
【自然语言描述】
能从代码、配置、Git、日志和材料确认的事实请你自己查。
只有真正会改变业务结果的决策再问我。
涉及真实设备状态改变时先说明动作和风险，不要自动执行。材料按需补
第一轮通常只要：现象、期望、发生时间、是否以前正常、已有材料。有需要再补日志、截图、协议、Raw、Git 版本、代码和设备信息。
AI 能从仓库确认的事实，不需要用户重复整理。
相关入口
一句话原则
小问题走短路，日志先找第一个异常点，回归先看时间差，性能先测基线，业务未知才 Discovery，真机动作独立受安全授权约束。