Obsidian/工具学习/车机诊断员 Agent/02-工作流卡片.md

车机诊断员 Agent 工作流卡片

目标

把零散的故障描述、日志与代码整理成可追踪、可验证、经人工审核的 Markdown 故障报告。

输入与输出

输入： 故障描述、复现时间、日志、代码版本、已执行测试。

输出： 时间线、跨层调用链、首个状态偏差、根因候选、证据与反证、置信度、验证方案、人工审批记录。

执行步骤

1. 接收并检查材料

• MUST 确认故障现象、发生时间、复现步骤、期望结果、软件版本和日志范围。
• MUST 缺少关键材料时列出缺失项并请求补充。
• 无法补齐时，进入人工审核，仅输出“证据不足的初步报告”。

2. 建立统一时间线

• MUST 统一时区、时间格式和设备时钟偏差。
• MUST 保留原始时间戳和日志来源，禁止只保留改写后的描述。

3. 提取关键事件

• MUST 提取语音命令、业务调用、蓝牙状态、错误码、超时、重试和回调。
• SHOULD 去重噪声日志，但必须保留首次异常前后的上下文。

4. 还原跨层调用链

• MUST 按“应用 -> 系统服务 -> HAL -> Linux 驱动/控制器”排列调用与状态变化。
• MUST 标注每一跳的输入、输出、返回值和状态，不能把缺失链路当成成功链路。

5. 定位首个状态偏差

• MUST 找到“期望状态”与“实际状态”第一次分离的位置。
• 无法定位时，MUST 标明证据缺口和未知项，转人工审核并输出初步报告。

6. 生成根因候选

• MUST 为每个候选列出支持证据、反证、未知项和置信度。
• MUST 明确区分“日志事实”“代码事实”和“分析推测”。
• MUST NOT 在无证据时断言硬件损坏或单一模块负责。

7. 设计验证方案

• SHOULD 优先使用只读日志、状态查询、可回退配置和最小复现实验。
• MAY 建议增加日志、编写单元测试或模拟异常回调。
• MUST NOT 未经批准执行代码修改、刷机、实车操作或破坏性命令。

8. 人工审核与审批

• MUST 由工程师审核证据链、根因置信度和验证风险。
• 涉及代码修改、刷机或实车验证时，MUST 获得人工明确批准后才能执行。

9. 输出报告

• MUST 输出 Markdown 报告，包含摘要、时间线、调用链、首个偏差、根因候选、验证方案、风险、结论和待办。
• MUST 给每条关键结论附上证据来源；证据不足时不得标记为最终结论。

失败处理

失败场景	处理方式
缺少日志、时间或版本	列出缺失项并请求补充；无法补齐则输出初步报告
多设备时间不一致	记录偏差依据并校准；无法校准则标记时间线不确定
跨层链路中断	标出最后一个已证实节点和下一段证据缺口
根因候选冲突	同时保留候选、反证和区分它们的验证实验
工具解析失败	保留原始文件，不覆盖源数据，转人工解析
验证存在安全风险	停止自动执行，提交人工审批

人工兜底触发条件

• 关键材料无法补齐，或无法定位首个状态偏差
• 日志与代码版本不匹配，证据相互冲突
• 涉及车辆安全、隐私数据、硬件操作或生产环境
• 需要修改代码、刷机、实车验证或不可回退操作
• 根因置信度不足以支持最终结论

验收清单

• 输入材料完整性有结论
• 时间线和跨层调用链可追踪
• 首个状态偏差有证据定位
• 事实、推测、未知项明确分离
• 每个根因候选含证据、反证与置信度
• 验证方案优先非破坏性操作
• 高风险动作存在人工审批点
• Markdown 报告结构完整