构建高效AI辅助调试工作流：上下文优先于粘贴错误

Full translation

完整中文译文

错误信息出现了。你把它复制粘贴给 ChatGPT，得到一个泛泛而谈的答案，然后白白浪费 20 分钟。我们完全可以做得更好。

问题出在哪？大多数人只是把 AI 当成搜索引擎的替代品，而不是调试搭档。下面介绍如何真正把 AI 融入工作流，让它在问题进入生产环境之前就发现异常。

真正有效的配置

在本地安装以下工具（无需云服务）：

# Ollama for local LLM (runs on your machine)
brew install ollama
ollama pull neural-chat

# Or use your existing API if you prefer
export OPENAI_API_KEY=your_key_here

在项目中创建一个 .debug 目录：

.debug/
├── error-context.md
├── logs/
└── snapshots/

第一步：捕获上下文，而不只是错误

出现故障时，不要只截取错误信息，还要收集上下文：

# Create a debug snapshot
echo "## Error at $(date)" > .debug/error-context.md
echo "### Stack Trace" >> .debug/error-context.md
your-app-command 2>&1 | tee -a .debug/error-context.md

# Add recent changes
echo "### Recent Commits" >> .debug/error-context.md
git log --oneline -5 >> .debug/error-context.md

# Add environment
echo "### Environment" >> .debug/error-context.md
env | grep -E "NODE|PYTHON|DB_" >> .debug/error-context.md

这个文件将成为 AI 的输入，其中包含了 AI 帮助你所需的全部信息。

第二步：提出正确的问题

错误的问法：“为什么会出现这个错误？”

正确的问法：“根据这些上下文，最近发生的哪些变更可能导致了这个问题？我应该先检查什么？”

# If using local AI
cat .debug/error-context.md | ollama run neural-chat "Analyze this error with context. What's the most likely cause? What do I test first?"

# If using API
curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{  
    "model": "gpt-4",
    "messages": [{
      "role": "user",
      "content": "'"`cat .debug/error-context.md`""'

Dont give me generic debugging steps. Tell me specifically what changed that caused this."
    }]
  }'

区别在于：你问的不是“哪里出错了”，而是“根据你看到的信息，最快的修复方法是什么”。

第三步：先验证，再相信

AI 可能会非常自信地给出错误答案。因此，需要增加一个验证步骤：

# Before you apply the fix, test it in isolation
# Example: if AI says "check your DB connection"
npm test -- --grep "database.*connection"

# Or reproduce with minimal code
cat > .debug/test-hypothesis.js << 'EOF'
// Test only the thing AI suggested
const db = require('./db');
db.connect().then(() => {
  console.log('Connection works');
  process.exit(0);
}).catch(err => {
  console.error('Connection fails:', err.message);
  process.exit(1);
});
EOF

node .debug/test-hypothesis.js

如果修复方案在隔离环境中有效，再把它应用到实际代码中。如果无效，你也有证据可以反驳这个建议，并继续排查。

真实案例：悄无声息的缓存 Bug

你的 API 返回了过期数据。你检查 Redis，一切正常；再检查代码，也没发现问题。非常经典。

你的调试文件捕获了以下信息：

带有时间戳的确切响应
最近一次重构的内容（移动了缓存失效逻辑）
问题发生时的服务器日志

你问 AI：“上周二，我把缓存失效逻辑移到了另一个函数中。时间戳表明，数据是在我修改之后被缓存的。我漏掉了什么？”

AI 回答：“你可能还在旧位置执行缓存失效操作。检查一下是否存在两套缓存实现。”

你用 grep 搜索，找到了。只用了 30 秒，而不是 30 分钟。

真正有帮助的工具

本地方案（隐私性更好、速度更快）：

Ollama + neural-chat：免费，在你的机器上运行
LM Studio：带 GUI 的封装工具，更容易使用

API 方案（能力更强）：

Claude（Anthropic）：最擅长理解奇怪的边缘情况
GPT-4：速度快，适合快速提问
Sonnet（Claude 3.5）：处理大多数 Bug 时的理想平衡点

选一个，然后坚持使用。你会逐渐掌握如何向它提出更好的问题。

收集上下文（30 秒）
带着上下文询问 AI（1 分钟）
验证假设（2～5 分钟）
应用修复方案，或者继续深入排查

无聊吗？是的。有效吗？同样是的。

真正神奇的并不是 AI，而是上下文。大多数人只给了 AI 所需信息的 5%，所以得到的答案才会如此泛泛。给它 95% 的信息，建议具体到什么程度可能会让你大吃一惊。

想了解更多构建高效开发工作流的实用技巧？可以看看 LearnAI Weekly——它分享的是真正能帮助你更快交付的策略，而不只是炒作。

对于后续处理，你可以考虑屏蔽此人和/或举报滥用行为。