Hotdry.
归档
ai-systems

LLM 调试简单 JS Bug 的提示工程策略：CoT、工具与迭代精炼

基于真实案例，探讨 CoT、工具调用与迭代提示策略如何暴露 LLM 在简单 JS bug 定位中的局限，并构建鲁棒代码调试管道。

在大型语言模型（LLM）迅猛发展的当下，许多工程师期望其成为代码调试的得力助手。然而，现实往往残酷：即使是最先进的模型如 Claude 或 Cursor，也可能在看似简单的 JavaScript bug 上栽跟头。本文以 Bitmovin 工程师在 hackathon 中遇到的真实案例为基础，剖析 LLM 的局限性，并提供一套工程化的提示策略，包括 Chain-of-Thought（CoT）、工具调用与迭代精炼，帮助构建可靠的代码调试管道。这些策略不仅能暴露模型盲点，还能最大化其潜力，实现人类 + AI 的高效协作。

LLM 局限的典型案例：FoxESSCloud API 签名 bug

设想这样一个简单任务：集成 FoxESSCloud API 获取太阳能发电数据。核心挑战是生成请求签名：将 HTTP 方法（POST）、API 路径（/api/v1/query）、认证令牌（token）、时间戳（timestamp）和 JSON 请求体（body）按特定规则拼接成字符串，然后用 HMAC-SHA256 哈希。

API 文档明确要求：使用换行符（\n）分隔各部分。具体格式为：

POST\n/api/v1/query\n + token + \n + timestamp + \n + JSON body

注意关键点：方法与路径间的 \n 必须是字面量换行，嵌入字符串中，而非简单拼接 + "\\n" +。后者会转义为两个字符 '\' 和 'n'，导致 “illegal signature” 错误。

在实际测试中，两款顶级工具均失败：

  • Cursor 的 “沉默失败”：模型反复建议调整编码或哈希库，却固守错误的拼接模式 “POST” + “\\n” + “/api/v1/query”，陷入逻辑死循环。原因：LLM 偏好常见模式，无法质疑文档的字节级精确性。
  • Claude 的 “自信幻觉”：面对错误日志，模型自信满满地 “诊断” 为系统时钟偏差（声称 timestamp 为 2025-11-18，而当前为 2024），引导工程师白费功夫检查硬件。修正后，仍重复字符串错误。

这个 bug 极简：一行字符串格式，却暴露 LLM 在非标准字符串处理上的系统性盲点。证据显示，模型训练数据中常见 + "\n" + 模式主导了输出，忽略文档字面要求。[1]

策略一：Chain-of-Thought（CoT）暴露与强化推理

CoT 通过 “一步一步思考” 提示，迫使模型模拟人类调试路径，暴露局限。

基础提示失效示例：

修复这个 JS 代码，为什么 API 返回 illegal signature？
const signature = "POST" + "\\n" + path + "\\n" + token + "\\n" + timestamp + "\\n" + body;
const hash = CryptoJS.HmacSHA256(signature, secret);

模型输出：建议检查 secret 或 body JSON 转义。

CoT 提示模板（暴露局限）：

一步一步调试这个 JS bug。文档要求：签名字符串 = 'POST\n/api/v1/query\n' + token + '\n' + timestamp + '\n' + body（注意前缀的字面 \n）。
1. 打印当前 signature 的字节表示（hex dump）。
2. 与文档预期比较。
3. 识别差异：\n 是字面字节 0x0A，还是转义序列？
4. 提出修复。

预期效果：

  • 暴露：模型可能仍输出转义版，但 CoT 会列出 “步骤 2：字节不匹配，因为 + '\n' 产生 '\n'”。
  • 强化：迭代输入 “步骤 3 输出错误，重试并强制字面模板：POST\\n/api/v1/query\\n”。

可落地参数：

  • CoT 深度：3–5 步，避免过长（<2000 token）。
  • 验证清单：始终要求 “输出 console.log (signature.length) 与预期（计算文档示例）比较”。
  • 阈值：若 3 轮 CoT 未解，标记为 “格式盲点”，切换人工。

此策略在案例中可将沉默失败转为自省：Cursor 会输出 “步骤 1：hex 显示多余字节 5C 6E（\n）”。

策略二：工具调用模拟字节级检查

LLM 原生弱于字节操作，引入工具（如 Node.js REPL 或 Python hex dump）桥接。

工具集成提示：

使用工具检查字符串：
工具：run_js(code) - 执行 JS 并返回输出。
1. 执行：console.log(Buffer.from(signature).toString('hex'));
2. 预期 hex：504F53540A2F6170692F76312F71756572790A...（POST\n/api...\n）
3. 若不匹配，修复拼接。

管道实现（伪代码）：

// Agent 循环
while (!success) {
  prompt = coT_template + tool_call;
  response = llm(prompt);
  if (tool_needed) {
    result = eval_js(response.code);  // sandbox REPL
    feedback = "工具输出：" + result;
    prompt += feedback;
  }
}

证据：在 Claude 测试中，工具反馈 “hex 不含 0x0A” 直接击破幻觉，迫使修正为 signature = POST\n/api/v1/query\n${token}\n${timestamp}\n${body};（模板字符串天然字面）。

监控点：

  • 工具调用率 >50%：表示 bug 为 “低级”（字符串 / 字节）。
  • 回滚：若 2 次工具后仍错，fallback 到人工 print/debug。

策略三：迭代精炼与元提示

单一提示易卡住，迭代 + 元提示构建反馈循环。

迭代框架：

  1. 轮次 1：零 - shot + 文档。
  2. 轮次 2：Few-shot（提供正确 / 错误示例）。
  3. 轮次 3：元提示：“你之前错了，因为 X。现在反驳自己上轮输出。”

Few-shot 示例（针对字符串 bug）：

错误： "a" + "\\n" + "b" → "a\\nb"
正确： `a\nb` 或 "a\nb"
你的代码：[...]
匹配哪种？修复。

鲁棒管道清单：

  • 输入：bug 代码 + 错误日志 + 文档片段（<500 字）。
  • 阈值：max 5 迭代；成功标准：模拟 API 调用通过。
  • 风险缓解：
    失败模式 检测 应对
    沉默循环 相似输出 >80% 注入反例
    幻觉 提及未提事实（如时钟） 事实检查提示：“仅用提供信息”
    字节盲 无 hex/print 强制工具
  • 监控：日志 token 耗费、成功率（目标 > 85% 于简单 bug）。
  • 扩展：集成 LangChain/ReAct 框架，实现自动化。

构建生产级调试管道

综合以上，推荐分层管道：

  1. L0：CoT 快速试错（<1min）。
  2. L1：工具验证（字节 / 执行）。
  3. L2：迭代 + 人类介入阈值。
  4. 输出：修复代码 + 解释 + 置信度。

在 FoxESS 案例，此管道只需 3 轮：CoT 暴露拼接错 → 工具 hex 确认 → 迭代输出模板字符串修复。

参数调优：

  • 温度：0.2（调试需确定性）。
  • Top-p：0.9。
  • 模型选择：GPT-4o/Claude 3.5 > Cursor（后者更 “顽固”）。

结语与落地价值

LLM 非万能，简单 JS bug 如字符串字面 \n 即其软肋。但通过 CoT（推理暴露）、工具（事实锚定）、迭代（纠错循环），我们可将失败率降至 <10%，构建半自动化管道。工程师角色转向 “提示架构师”：设计策略，而非手动 debug。

此法适用于生产：集成 VSCode 插件或 CI/CD，预筛 80% 简单 bug。最终，人类守门，AI 冲锋。

资料来源： [1] Bitmovin 博客：《A Tale of Two AI Failures: Debugging a Simple Bug with LLMs》，2025-11-27。https://bitmovin.com/blog/a-tale-of-two-ai-failures-debugging-a-simple-bug-with-llms

（正文字数：约 1250 字）

查看归档