生成一份真正可用的调试提示词，核心在于锁定路径、分层动作、并绑定验证结果。具体而言，需把握以下六个关键要点：一、在开头明确标注物理或逻辑场景；二、指定执行人角色及其工具链；三、首检动作必须具备物理可测性；四、按照现象→定位→验证→修复四个阶段进行拆解；五、每一步骤均包含工具型号、命令路径、预期返回字符串；六、禁用模糊动词，每条指令以动词开头且参数精确。

你可能曾尝试通过百小应生成一份可直接嵌入开发文档、供新人理解、让测试人员复现、并被运维团队验证的调试过程提示词。然而，每次输出的结果往往要么过于笼统（例如“检查配置”或“重启服务”），要么遗漏关键动作（未明确说明在哪些日志中搜索什么关键词），又或者将硬件操作与软件命令混用在一起——这些问题的根源在于提示词未能锁定调试路径、细化动作层级、并绑定可验证的结果。

锁定调试路径与角色身份

第一步：在提示词的开头，必须明确说明调试发生的物理或逻辑位置。例如，可以写为“【嵌入式设备固件升级失败】”或“【Docker容器内Python服务HTTP 503】”。若不指定具体场景，百小应会默认采用通用排查流程，从而跳过如串口波特率或容器网络模式等关键锚点。

第二步：明确指定执行人的角色，例如“由产线工程师在现场使用串口助手操作”或“由SRE在K8s集群中执行kubectl debug”。角色决定了工具链和权限边界；如果仅写为“技术人员”，输出内容可能会将ssh和adb命令混用。

第三步：强制绑定一个不可省略的首检动作，比如“必须从第一步开始执行：用万用表测量TP1点电压值”。这一步严禁使用“查看日志”这类动作，因为日志可能为空；必须是物理可测、仪器可读、且结果具有明确阈值的操作。

分层拆解调试动作颗粒度

方法一：按“现象→定位→验证→修复”四阶递进

① 现象层：从用户视角描述故障的直观表现，比如“烧录后设备无法进入BOOT模式，LED常灭，无USB枚举”。这句话必须包含可观测的信号（如LED状态、USB行为），避免使用“启动异常”这类模糊表述。

② 定位层：限定唯一工具、唯一命令及唯一参数，例如“使用stlink-v3连接，运行st-util --log-level 3，在终端输入‘monitor reset halt’”。此处的“--log-level 3”不可省略，否则无法查看JTAG握手失败的细节。

③ 验证层：要求输出可进行比对的原始数据，比如“截取st-util终端的前20行日志，并标出‘Failed to read memory’所在的行号及地址值”。若不标明行号，新手难以快速定位上下文。

④ 修复层：提供带有版本号的固件包名称及校验方式，例如“替换./firmware/v2.4.1.bin，执行sha256sum ./firmware/v2.4.1.bin确认值为a7f9e3d…”。若不写入sha256sum指令，产线可能会误刷旧版本v2.4.0的固件包。

嵌入可验证的硬参数

在提示词末尾添加一句：“输出的每条调试步骤必须包含以下三项，缺一不可：① 工具型号（如ST-Link V3、Wireshark v4.2.3）；② 命令完整路径（如/opt/stlink/bin/st-flash）；③ 预期返回特征字符串（如‘Successfully erased’或‘Timeout waiting for ACK’）”。

若不加这一步，百小应可能会输出“使用st-flash烧录”这类笼统的指令，新手根本不清楚需要安装哪个版本、命令存放在哪里、以及如何判断操作是否成功。它甚至可能混淆Windows下的st-flash.exe与Linux下的st-flash。

将“预期返回特征字符串”写入提示词，相当于为AI设置了一个校验开关——它必须从训练数据中调取真实的报错片段，而非编造“烧录成功”之类的信息。

禁用模糊动词与自由发挥空间

在提示词中明确声明：“删除所有‘尝试’‘建议’‘可以’‘可能’‘一般’等字眼；禁止出现‘检查相关配置’或‘确认是否正常’这类无效指令；每条步骤必须以动词开头（如‘接驳’‘短接’‘执行’‘捕获’‘比对’）”。

卡死这一步后，百小应便无法输出“建议先检查电源”这类无用信息，而只能写出“使用万用表红表笔接VCC引脚，黑表笔接GND，读数应为3.3V±0.1V”这样的精确指令。

【注意：若你实际使用的是3.0V供电芯片，但未在提示词中明确电压值，百小应会按常见的3.3V芯片逻辑输出，从而导致新人做出误判】。