在代理的远程现场担任操作员 | AI生成和翻译
问题：对于软件缺陷，像Claude Code这样的智能体可以直接读取源代码，因此简短的提示即可。对于硬件/机械/日常生活问题，更好的方法是完整描述事情经过并仔细撰写提示，因为机器人本身无法检查任何东西？
答案：是的——原因是一个基于第一性原理的问题，即智能体能使用什么工具。
软件场景：智能体拥有对问题状态（代码仓库）的读写工具。它可以执行grep、运行二进制文件、检查堆栈跟踪、二分定位提交记录。你的提示只需将其指向正确的入口点——智能体通过迭代（读取文件→假设→测试→重复）自行填补信息缺口。每次迭代提示成本低，因此无需预先加载所有信息。
硬件/机械/日常生活场景：大语言模型没有任何传感器。它无法查询你冰箱的内核日志，无法测量主板电压，也无法看到自行车车架的裂缝。你是它唯一的输入输出设备。这改变了最优提示策略，体现在两个方面：
-
一次性预先提供所有可测量信息——因为每次往返都要你付出实际行动（拧螺丝、用万用表测量、等待噪音再次出现），而不是廉价的工具调用。所以需要提供：症状、准确时间线、环境（温度、湿度、负载）、事发前的变化、错误代码/照片/声音、你已尝试的操作及结果。
-
但依然应是一个诊断循环，而不是一次性的”提示并祈祷”——模式不是”写一次完美提示”，而是”充当智能体的远程操作员”。结构如下：
- 你提供症状
- 机器人提出2-3个按可能性排序的假设，外加一个用于区分它们的经济测试
- 你执行该测试，报告结果
- 重复此过程
这模拟了实际的诊断决策树（如修理工或医生），而不是单次检索查询。人们常犯的错误是（a）倾倒所有信息，期望一次性得到最终答案，无需后续跟进；或（b）仅给出一个模糊症状（”我的笔记本很慢”），期待奇迹发生——两者都会浪费回合，因为机器人要么被无关细节淹没，要么不得不先问5个澄清问题才能开始。
硬件/物理问题的实用提示模板：
设备/系统：<精确型号，例如"MacBook Pro M3 Max 2024">
症状：<精确描述，例如"从睡眠唤醒后30秒内风扇满速运转">
时间线：<问题何时开始，哪些因素发生了变化>
环境：<环境温度、电源来源、负载情况>
已尝试操作：<操作 -> 结果，逐个列出>
错误代码/日志/照片：<直接粘贴原始内容，不要转述>
要求：列出最可能的两大原因并按可能性排序，以及区分它们的最经济测试方法
最后一行是与软件提示的关键区别——你明确要求的是下一步物理操作，因为机器人无法替你执行。
参考：
AI生成和翻译，但整理分享仍需精力。如果觉得有帮助，欢迎
捐助支持。
微信：@lzwjava
·
X: @lzwjava ·
打个招呼 👋