调试提示词模式
带完整上下文喂错误，并先要假设再要修复。
提示词工程进阶
为什么
GitHub 2024 调查发现 92% 的美国受访者用 AI 编程工具生成测试用例，73% 的开源受访者用 AI 工具编程或写文档。仅贴错误行使模型猜测。
给错误 + 堆栈 + 相关代码 + 已试内容，得真实假设与针对性修复而非投机补丁。
何时使用
错误非显然或首次修复失败时用。 简单明确任务不必过度工程化提示词，一行指令足矣。
如何做
1. 贴完整错误 + 堆栈。
2. 通过 @file 含相关文件。
3. 说明已试内容（避免重复建议）。
4. 问："最可能原因是什么？先解释再修复。"
5. 批准假设后要最小修复。
示例
错误："TypeError: Cannot read 'id' of undefined at router.ts:42"
@file src/api/router.ts @file src/data/books.ts
已试：检查 books 非空。
问："最可能原因？再最小修复。"
假设："books[req.params.id] 在 id 未找到时 undefined → 用可选链 + 404 守卫。"
常见问题
- ⚠仅贴错误行：模型猜测 — 含堆栈 + 代码。
- ⚠跳过假设：直接修复掩盖错误根因。
- ⚠错误：超出 token 限制（400 Bad Request） → 拆分提示、摘要前文或切换更大上下文模型。
最佳实践
- ✓始终含堆栈与相关文件。
- ✓修复前要假设以捕获错误根因。
- ✓用具体指标衡量结果（节省时间、缺陷率、测试覆盖率），使实践可被论证和改进。
常见问题解答
什么是调试提示词模式？
带完整上下文喂错误，并先要假设再要修复。 它可帮助开发者快速理解 调试提示词模式 的核心价值与适用场景。
如何开始使用调试提示词模式？
开始使用 调试提示词模式，建议先掌握以下要点：贴完整错误 + 堆栈。
调试提示词模式 的常见误区有哪些？
使用 调试提示词模式 时常遇到的问题包括：仅贴错误行：模型猜测 — 含堆栈 + 代码。；跳过假设：直接修复掩盖错误根因。；错误：超出 token 限制（400 Bad Request） → 拆分提示、摘要前文或切换更大上下文模型。。
调试提示词模式 的最佳实践是什么？
调试提示词模式 的最佳实践包括：始终含堆栈与相关文件。；修复前要假设以捕获错误根因。；用具体指标衡量结果（节省时间、缺陷率、测试覆盖率），使实践可被论证和改进。。
如何深入学习调试提示词模式？
从官方文档入手，再在 GitHub 上搜索真实示例；先在小实验仓库验证模式，再应用到生产代码。