Appearance
案例 C：从项目记录沉淀 AI 工作流
案例 C 关注经验怎样进入下一次任务。这里保留的是当时真实发生的纠偏过程，不把历史过程改写成一条“从一开始就完美”的故事。
按当前 V10 重读本案例： 历史上有些任务用了较完整的输入和分析流程；今天不再把这些步骤当成所有任务的固定前置。先做 Intent Gate，小任务走短路，根因未知才升级调查，只有真正可复用的经验才进入长期规则。
五类任务，今天应该从不同入口开始
| 任务 | 当时容易出现的 AI 行为 | V10 当前起点 | 主要入口 |
|---|---|---|---|
| 查询现状 | 为了回答一个问题先解释整个项目 | Read-Only Trace，只追最短调用链 | 读懂现有 C# 项目 |
| 功能修改 | 根据一句需求跨文件改代码，或反过来先做过长影响分析 | MicroPatch / BehaviorPatch，按语义决定范围 | 功能修改最小流程 |
| Bug 定位 | 根据异常文字猜根因并顺手修复 | Temporal Regression / Feedback Ladder | AI 辅助 Bug 定位 |
| UI 修改 | 按截图批量生成 XAML | UI MicroPatch 或复杂交互设计 | WPF 开发流程 |
| 回退与验收 | 说“已修复”并列一组通用测试 | 先确定可信状态，再匹配 V0–V4 | 回归测试与验收清单 |
同一套 Prompt 不适合所有任务，但这也不意味着每种任务都要一张完整模板。V10 先问：为了证明当前结论，最少还需要什么？
一次 Bug 调查如何变成可复用流程
原始现象
界面显示的电流状态偶尔与实际采集值不一致。现象出现在运行一段时间后，重新打开页面又可能恢复。
AI 初判
AI 根据“状态不一致”优先怀疑阈值判断，并准备修改比较条件。这个判断可能成立，但当时没有证据说明错误发生在采集、解析、状态映射还是 UI 刷新。
人工纠偏
调查改为沿时间线取证：
- 保存同一时刻的原始报文、解析值、业务状态和界面显示。
- 对比错误出现前最后一次正常状态，确认最早发生分叉的位置。
- 检查后台值是否被旧任务覆盖，UI 是否收到过期通知。
- 在根因未确定前，不改阈值、不重构状态模型。
按 V10，这对应：
text
Observed Symptom
→ Timeline
→ First Anomaly
→ Evidence / Inference / Unknown
→ 必要时 1–3 个可证伪假设如果用户同时明确“旧版本正常、新版本异常”，还应先做 known-good diff，而不是把当前代码里第一个看起来不合理的位置当成回归根因。
最终证据
该记录能证明的是调查范围从“猜阈值”缩小到了可比较的四层数据。若缺少原始日志或稳定复现条件，具体根因仍应标为待核实，EvidenceGrade 只能停留在 C/D，而不能写成已经修好。
功能修改不再要求固定“最小输入表”
历史上我们曾要求已有功能修改至少提供：用户动作、现象、期望、页面、数据来源、禁区、验证环境、回退点等。这个做法能减少误改，但对简单任务成本过高。
V10 改成分级：
MicroPatch
通常只需要：
text
Target
ExpectedChange
NonGoals（有必要时）其余事实由 Agent 从代码确认。
BehaviorPatch
使用六行契约：
text
Trigger
Condition
Action
Reset
Record
NonGoalsRegressionFix
优先补：
text
当前异常
known-good
大概从什么时候开始
已有日志 / Git / 配置差异Discovery
只有业务结果仍存在真正未知时，才用 Decision Tree / Frontier 问用户。
因此，“字段没填满”本身不是阻塞条件；会改变实现结果的未知才是 Blocking Unknown。
UI 与曲线任务沉淀出的规则
- 截图只能证明视觉目标，不能证明状态、数据源或设备行为。
- 纯文案、Margin、列宽、现成样式属于 UI MicroPatch，不自动展开完整页面设计。
- 复杂交互才需要页面职责、状态、数据源和异常分支。
- 曲线数据必须标明单位、采样时刻和无效值策略。
- 实时曲线要有点数或时间窗口上限，并用实际性能基线判断是否需要优化。
- 双 Y 轴只在量纲或数值范围确实冲突时使用，并清楚标识归属。
- 修改共享资源前先查引用；局部差异优先局部覆盖。
这些规则进入了页面与图表案例，但不会升级成“所有 WPF 项目必须如此”的绝对要求。
什么时候把经验写进哪里
V10 不再把“有价值的经验”全部塞进 Skill。
| 内容 | 推荐位置 |
|---|---|
| 只对当前项目有效的已知坑、修复事实 | .agent-memory |
| 稳定业务术语 | CONTEXT.md |
| 难逆、非显然、经过真实取舍的长期决策 | ADR |
| 多项目都重复出现的工程方法 | Skill / reference |
| 单次聊天过程、普通 MicroPatch | 通常不沉淀 |
例如“通信异常要保留足够证据”可以进入通用 Skill；但某台设备某固件版本特有的错误码，更适合当前项目 Memory。
一条规则进入 Skill 前至少问三件事
- 它是否在多个任务/项目中重复出现，或者单次失败代价很高？
- 它能否写成明确的触发条件和动作，而不是一句泛泛口号？
- 加入后会减少返工，还是只给小任务增加步骤？
第三点尤其重要。V10 的目标不是“把规则越积越多”，而是保持净增益。
流程索引
01 Read-Only Trace只是查现状就到结论为止。02 功能修改MicroPatch / BehaviorPatch / ExperimentalChange。03 Bug / Regression证据、时间线、known-good 和最小修复。04 日志时间线找第一个异常点，不只看最后一条 Error。05 验证按 V0–V4 匹配风险。06 Skill 沉淀只有长期净增益规则才进入 Skill。
本案例现在最值得保留的结论
经验沉淀的目标不是保存更多过程，而是让下一次任务更快分对类型、找到更强证据、避免重复踩坑。
历史过程可以保留作为证据，但当前推荐方法以 V10 权威页面为准。