Claude编程提示词包：调试、重构与架构评审

让下面每条提示词都奏效的四条约束

在给出提示词之前，先说说它们共有的规则。把这些加进任何编程提示词，带来的改善往往比换模型更大。

说明你的版本。 训练数据总是偏向于被写得最多的那个大版本，而这往往不是你正在用的那个。我们用的是[框架][版本]，[语言][版本]能避免大多数过时的回答。

限制改动范围。 你要的是修复，得到的却常常是重构。尽量少改动，保留现有结构和命名，并列出你改动的每一行及一句话原因是这份文档里最有用的一句话。

先要排序假设，再要方案。 被问「哪里出了问题」的模型会给你一个以结论形式呈现的猜测。被要求给出排序原因和低成本验证方法的模型，会给你一份调试计划。

要求说明失败模式。 这可能会破坏什么，这是在修复原因还是症状？能揪出AI辅助中代价最高的那类情况：让症状消失、缺陷却还留在那里的改动。

调试

1. 排序假设

这是错误信息、相关代码，以及我已经排除的可能性。先别给我修复方案。按可能性列出四个最可能的原因，并为每一个给出成本最低、能确认或排除它的检查方法。错误信息：[粘贴]。代码：[粘贴]。已排除：[列表]。技术栈：[语言、框架、版本]。

2. 间歇性bug

这个问题会间歇性出现，频率大约[频率]，出现条件是[条件]。列出可能导致这种特定症状的间歇性故障类别：时序、顺序、资源耗尽、外部依赖、运行间的状态泄漏、时钟或时区、缓存。针对每一种，说明代码中哪些地方支持或反驳它，以及我应该记录什么日志来区分它们。代码：[粘贴]。

3. 本地能跑

这段代码本地能跑，在[环境]里却失败。列出所有可能导致这种特定症状的环境差异类别：配置、环境变量、版本、文件系统与大小写敏感性、时区与语言环境、网络与DNS、权限、资源限制，以及构建或打包差异。按症状的可能性排序，并给出每一项的诊断命令。

4. 在我采用修复方案之前先解释它

解释这个修复为什么有效，它没有修复什么，以及它可能带来什么破坏。如果真正的原因在别处，而这只是症状补丁，请直接说明。

代码审查

5. 审查一份diff

以严格审查者的标准审查这份diff。按优先级分类：正确性错误、安全问题、未处理的失败模式、竞态条件，然后才是风格。每个发现都要给出严重程度、具体行号，以及它在这个代码库中（而非泛泛而言）为什么重要。不要评论格式。如果diff本身没问题，就直说，不要硬凑发现。约定：[描述]。Diff：[粘贴]。

6. 安全专项检查

专门审查这段代码的安全问题：注入、身份验证与授权漏洞、不安全的反序列化、代码或日志中的密钥、未经验证就传入敏感操作的输入，以及依赖风险。每一项都要给出具体的攻击路径，而不是只报出类别名称。清楚说明在没有看到[部署方式、认证层、数据敏感度]的情况下你无法评估什么。

7. 失败模式审计

针对这段代码里的每一次外部调用，说明它变慢时、失败时、返回意外数据时，以及部分成功时会发生什么。目前哪些情况没有被处理，哪些会悄无声息地出错？

最后这一条比一般性审查能挖出更多真实的生产问题，因为它问的正是那些没人写过测试的路径。

重构与架构

8. 重构计划

为[描述]提出一个分步的重构计划。约束条件：[x]的公共API不能变，我们持续部署，所以每一步都必须能独立发布，并且每一步之后测试都必须通过。每一步都要给出改动内容、风险、验证方法，以及回滚方法。按风险从低到高排序。先不要写代码。

9. 为另一方辩护

在[背景和约束]下，我打算选[方案A]而不是[方案B]。请为B给出最有力的论证。B要成立，我们的约束条件需要满足什么，这里有没有符合的？不要下结论说两者都成立。

10. 弄清楚你接手了什么

这是主要的源文件。请给出：入口点、从请求到响应的数据流、哪些状态是共享的以及在哪里被修改、外部依赖以及每个依赖不可用时会发生什么，以及根据复杂度和耦合度判断最可能有bug的三个区域。请明确说明哪些是你根据我提供的内容无法判断的。

最后这条指令很关键。模型会根据文件名去描述一个你没有粘贴的文件的行为。强制要求列出明确的未知项，能告诉你该去读哪些代码。

测试

11. 你不会想到要写的测试

为这个函数写测试用例，重点关注我可能没考虑到的输入：边界值、空值和null、Unicode、超大数值、并发调用，以及实现中的任何隐含假设。每个测试都要说明它在检验哪个假设。函数：[粘贴]。

12. 检验测试套件本身

这是一个函数和它现有的测试。哪些行为没有被覆盖到？具体来说：错误路径、边界值、参数之间的相互影响，以及实现做了但没有测试断言的任何事情。不要重写现有测试。

第二条价值更高，却很少被用到。覆盖率百分比告诉你的是哪些行被执行了，而不是哪些行为真正被固定验证了，而这两者之间的差距，正是回归问题藏身的地方。

第二意见模式

整套提示词包里杠杆效应最强的习惯，也是唯一需要一个以上模型的习惯。

先从一个模型那里拿到答案，然后切换，把它交出去：

另一位工程师针对这个问题提出了这个解决方案。找出它的问题：边缘情况下的正确性、并发、错误处理、在[规模]下的性能，或者是否漏掉了更简单的方案。如果它确实是稳妥的，就直说，不要硬造反对意见。问题：[粘贴]。提出的方案：[粘贴]。

两种结果都有用。要么第二个模型发现了一个真实漏洞，让你在合并之前就知道了；要么它在被要求提出反对意见的情况下依然认同，这本身就是有意义的确认。用同一个模型反复迭代得不到这两种结果中的任何一种，因为模型审查自己的输出时，大多只会认同自己。

把它用在那些一旦出错代价高昂的决定上：schema变更、并发修复、任何涉及认证或资金的地方，而不是日常工作。参见并排比较模型、在对话中途切换模型和用多个模型编写和调试代码，了解完整的工作流。

需要留意的地方

臆造的API。 自信地给出实际不存在的方法名、参数和配置键，对于最近有变动的库尤其常见。这些签名看起来会很像那么回事。在基于任何不熟悉的东西继续构建之前，先查证真实文档。

没有置信度信号。 一个正确的修复和一个隐蔽出错的修复，给出的语气笃定程度是一样的。语气说明不了任何问题。

悄悄扩大改动范围。 这正是第二条约束存在的原因。

安全表演。 在代码里指出漏洞类别是有用的第一步筛查，但它不是一次审计，模型也不了解你的威胁模型、部署方式或数据敏感度。

把你每周都会用到的提示词存在一个能随手复制粘贴的地方，并把固定约束放进项目的指令里，这样它们就会自动应用到该项目下的每一次对话。