Appearance
模板与 AI 开发能力库
模板的作用是减少遗漏，不是把所有任务变成填表。V10 的第一步不是“选一个最长模板”，而是先判断当前是在查现状、做小改、改运行规则、查回归、做临时实验，还是仍需需求发现。
最短开场白
如果你还不知道任务属于哪一类，只用这一段：
text
$host-computer-dev
请先判断这个任务属于 Read-Only / Fast / Execution / Discovery。
如果是 Execution，再判断是 MicroPatch / BehaviorPatch / RegressionFix / ExperimentalChange。
我的问题或目标：
【填写】
能从代码、配置或 Git 直接确认的事实请你自己查；只有会改变最终业务结果的决策再问我。这不是要求每个任务都先写计划。任务明确时应直接进入对应短路径。
1. 先选最接近的任务
| 你现在要做什么 | 推荐路径 |
|---|---|
| 只是想知道当前代码怎么工作 | Read-Only Trace |
| 改文案、颜色、布局小细节 | Fast / MicroPatch |
| 阈值、连续次数、报警/停机规则已经明确 | Execution / BehaviorPatch |
| 以前正常，最近改后异常 | RegressionFix / Temporal Regression |
| 临时放开限制做边界测试 | ExperimentalChange |
| 日志很多，不知道哪个错误最早 | Timeline Analysis |
| UI 卡顿、CPU/内存持续增长 | Performance / Long-run |
| 需要连接真实高压、运动、阀门等设备 | Hardware Safety / HITL |
| 新项目、新流程、自己也没想清 | Discovery |
兼容旧链接： 早期页面中的“现有功能增量修改、WPF 界面优化、实时曲线、曲线控件选型、通信接收与数据保存、状态机补齐、回退、AI 修改后质量门”等入口现在统一落到本页。它们不再各维护一套固定流程，请按当前任务选择下面的 V10 短路径或专项页面。
2. 最短 Prompt：只查现状
text
$host-computer-dev
只分析当前实现，不修改代码。
我想确认：
【例如：停机窗口的电流判断是单帧还是连续多帧？】
请只追踪最短调用链，给出：
1. 当前行为；
2. 关键代码/配置位置；
3. 结论依据。
不要构建、测试、写修改计划。3. 最短 Prompt：明确小改
text
$host-computer-dev
这是一个明确的小修改，请走 Fast / MicroPatch。
目标：
【例如：把“负载电流”改成“充电电流”】
要求：精确定位直接展示位置，不加载额外 UI 设计流程，不做无关重构，按 V0/V1 做最小验证。4. BehaviorPatch：运行规则已经明确
text
$host-computer-dev
这是一个明确的行为修改，不需要重新做完整需求分析。
Trigger：
Condition：
Action：
Reset：
Record：
NonGoals：
请先核对代码事实，再按最小范围实现，并按影响选择 V2/V3 focused 验证。涉及报警后果时额外明确：
text
Information / Advisory / AlarmOnly / InterlockFault详细说明见 行为与告警语义。
5. RegressionFix：以前正常，现在异常
text
$host-computer-dev
这是一个近期回归，请先做 Temporal Regression，不要先改代码。
当前现象：
以前正常的版本/目录/commit：
最近改动：
可用日志：
先确定 known-good，再看 changed files 和最相关 method/config/协议差异；没有差异证据时，不要把“看起来可疑”的旧代码写成回归根因。如果只是回退到旧版本恢复，应写 RolledBackToKnownGood，不要自动写成 RegressionFixed。
6. ExperimentalChange：临时边界测试
text
$host-computer-dev
我要做一次临时边界测试。
临时目标：【例如：暂时放开 1500 Hz 上限】
优先 developer/engineering override 或窄入口覆盖；正式 Domain/MES/持久化规则默认保持；写清恢复方式，不把实验条件写成正式规格。7. Discovery：新项目或业务规则未定
text
$host-computer-dev
这是新项目/新主流程，目前业务规则还没有完全想清。
已有目标：
已有设备/资料：
使用人员：
已知约束：
请进入 Discovery：事实优先自己查；只问会改变最终业务结果的问题；用 Decision Tree / Frontier 分轮推进；Blocking Unknowns 清零后立即进入 Execution。8. 测量值修改模板
text
RawValue：
EngineeringValue：
Conversion：
ThresholdBasis：
Aggregation：
LoggedUnit：不要把原始电压、换算电流、显示值、判定值和日志值混为一谈。详细说明见 测量值语义。
9. 日志时间线模板
text
现象：
异常时间范围：
是否以前正常 / known-good：
日志源：
请输出：
1. 关键时间线；
2. 第一个异常点；
3. Evidence / Inference / Unknown；
4. 如果是通信问题，区分 Transport / Protocol / Mixed；
5. 下一组最有区分力的证据。详细说明见 日志与时间线诊断。
10. 性能 / 长稳模板
text
场景：
Baseline：
- CPU：
- Working Set：
- UI 延迟/刷新：
- Queue/IO/GC（有则填）：
目标：
【例如：60 min 内存不持续增长；UI p95 < 50 ms】
要求：先找第一个主要热点，一次只改一个瓶颈，使用相同场景前后对比，不做无证据全局重构。详细说明见 性能与长稳诊断。
11. 真实设备验证模板
text
SoftwareReady：
Fake/Replay Evidence：
需要的真实设备动作：
风险等级：
人工授权/现场条件：
期望记录的 Hardware Evidence：未经明确授权，不自动执行改变真实设备状态的命令。没有真机证据时写 HardwarePending。详细说明见 真实设备操作安全。
12. Rules / Context / Skill / Tool 怎么分
| 层级 | 放什么 |
|---|---|
| Rules | 每次都必须遵守的工程边界 |
| Context | 当前项目稳定业务术语与概念关系 |
| Skill | 一类任务如何完成，例如 Bug、功能修改、文档工程 |
| Tool / MCP | Git、构建、测试、日志、数据库只读等执行能力 |
text
CONTEXT.md = 项目稳定业务语言
.agent-memory = 项目历史事实和修改记录
ADR = 长期重要设计取舍Fast MicroPatch 默认不加载这些全部内容。详细说明见 项目 Context、Memory 与 ADR。
架构决策记录 ADR
ADR 不是每次改代码都写。只有下面三项同时满足时才值得记录：
- 决定以后较难逆转；
- 没有上下文时，后来的人会觉得这个设计很奇怪；
- 它来自一个真实取舍，而不是普通实现细节。
推荐简化模板：
markdown
# ADR-00X：决策标题
## 背景
为什么需要做这个决定？
## 决策
最终选择什么？
## 备选方案
考虑过哪些方案？为什么没有选？
## 影响
带来哪些收益、代价和长期约束？
## 证据
相关需求、测试、故障记录或代码位置。适合的例子：
- 为什么测试窗口内高压健康检查返回缓存数据；
- 为什么“应用设备/自检”阶段高压目标保持 0 V；
- 为什么示波器恢复必须复用当前 SCPI client，而不能建立第二会话。
不适合的例子：颜色调整、CSV 列名、一次性文案、普通局部 Bug。
13. Review 清单
AI 返回后检查：
- 任务类型是否分对；
- 是否修改承诺之外的文件或业务；
- 验证等级是否匹配；
NoTestsMatched是否误写成 TestPassed；EnvironmentBlocked是否误写成业务失败；- 回归是否先比较 known-good；
- ExperimentalChange 是否可恢复；
- AlarmOnly 是否被误升级成停机；
- 真机未验证内容是否明确标注
HardwarePending； - 结论是否区分 Evidence / Inference / Unknown。
14. 常用入口
一句话原则
模板是缺信息时的最小脚手架，不是每个任务都必须填完的表。任务越明确，模板越短；风险越高，证据越强。