可观测性决定AI故障排查 | AI生成和翻译
问题： 对于硬件/软件/日常故障排除，是编写完整的故障描述和提示对AI辅助更重要，而软件问题可以交给Claude Code/Hermes去检查源代码吗？
答案：
是的。关键区别在于可观测性。
对于软件问题，像Claude Code或Hermes这样的AI代理可以直接访问“真实数据”：
源代码
日志
堆栈跟踪
Git历史
测试
运行时环境
它们可以做到：
读取代码
↓
跟踪执行路径
↓
找到bug位置
↓
修改代码
↓
运行测试
示例：
Bug：
用户上传20MB图片时API返回500。
Agent可以：
- grep端点
- 检查控制器
- 检查中间件
- 复现
- 打补丁
Agent拥有证据。
对于硬件/机械/日常生活中的问题，AI通常没有直接传感器。
示例：
“电脑无法开机”
AI无法看到：
- 主板LED状态
- 线缆连接
- 电源行为
- 气味/噪音
- 物理损坏
- 准确的BIOS画面
因此质量很大程度上取决于故障报告。
一个好的硬件提示本质上就是一个调试工单。
结构：
1. 目标
应该发生什么？
2. 实际行为
实际发生了什么？
3. 时间线
什么时候开始的？
4. 环境
硬件/软件/版本/位置
5. 近期变化
故障前有什么变化？
6. 证据
照片、视频、日志、测量数据
7. 已尝试的实验
哪些有效/失败了？
8. 约束
有哪些工具可用？
示例：
不好的提示：
我的电脑无法启动。帮帮我。
AI几乎没有任何信息。
好的提示：
问题：
台式电脑通电但无显示。
硬件：
- MSI MAG B760M Mortar WiFi 主板
- Intel i9-13900KF
- RTX 4070
- DDR5 32GB
- Corsair 750W 电源
时间线：
正常工作了2年。
昨天搬动电脑后，不再显示。
症状：
- CPU风扇转动
- GPU风扇短暂转动
- EZ Debug LED：
CPU灯灭
DRAM灯亮
测试：
1. 移除GPU，尝试集成显卡
2. 重新插拔内存
3. 尝试单根内存条
4. 清除CMOS
问题：
根据这些症状，最可能的故障顺序是什么？
现在AI可以像工程师一样推理：
DRAM灯亮 + 重新插拔失败
↓
检查内存兼容性
↓
检查主板插槽
↓
检查内存训练
↓
可能CPU内存控制器
对于机械/现实世界问题，同样的原则适用。
示例：
不好的：
车子有噪音。
好的：
汽车：
丰田卡罗拉2018款
噪音：
- 金属咔哒声
- 只在左转时出现
- 超过40km/h消失
- 压到坑后开始出现
问题：
我应该首先检查哪些部件？
现在AI可以进行差异诊断。
一般模式：
软件调试：
AI直接获取原始数据
（代码/日志）
硬件调试：
人类必须充当传感器
（描述/照片/视频）
一个有用的思维模型：
软件Agent：
AI
|
源代码
|
bug
硬件：
AI
|
人类观察
|
物理系统
|
故障
对于硬件，提示不仅仅是沟通，它是数据采集层。
这类似于机器学习：
坏的提示 = 坏的数据集
好的提示 = 高质量的训练样本
输入表示越好，诊断结果越好。
一个强大的工作流程是：
物理问题
↓
收集证据
↓
编写结构化故障报告
↓
向AI询问假设排序
↓
执行最便宜/最安全的测试
↓
更新证据
↓
重复
这基本上是将软件调试方法论应用到物理世界中。
AI生成和翻译，但整理分享仍需精力。如果觉得有帮助，欢迎
捐助支持。
微信：@lzwjava
·
X: @lzwjava ·
打个招呼 👋