我用过的最好的 AI Prompt——老张私藏的那些
我用过的最好的 AI Prompt——老张私藏的那些
适读人群：AI应用开发者、日常重度使用AI的人 | 阅读时长：约15分钟 | 核心价值：不是大而全的清单，是真正用烂了的那些
有人问我：你每天用AI，最核心的提示词是什么？
这个问题我一直没有认真回答过，因为我觉得"分享Prompt"这件事容易流于形式——把一大堆Prompt堆在那里，看起来很干货，其实大部分人看完也不会用。
但这篇我想认真写。不是给你一个清单，而是把我真正用烂了的几个Prompt说清楚：它们用在什么场景，为什么这样设计，以及我是怎么进化到这个版本的。
先说一个前提
Prompt没有"最好"，只有"最适合你的工作场景"。我下面分享的这些，都是高度适配我日常工作的。你用的时候可能需要根据自己的实际情况调整，而不是直接复制粘贴就期待有同等效果。
另外，我用的模型主要是Claude和GPT-4系列，不同模型对同一个Prompt的响应会有差异。我会标注这些Prompt在哪个模型上效果更稳定。
一、代码 Review Prompt
这是我用得最频繁的一个，基本上每天都在用。
使用场景： 在进行代码合并之前、自己写完一段不确定的逻辑之后、或者接手别人的代码快速扫一遍的时候。
Prompt：
你是一个有10年经验的高级工程师，专注于代码质量和可维护性。
请对以下代码进行Review，重点关注：
1. 潜在的Bug和边界条件（特别是空值、并发、异常处理）
2. 性能问题（不必要的循环、N+1查询、内存泄漏风险）
3. 可读性和可维护性问题
4. 安全风险（SQL注入、XSS、敏感数据暴露等）
输出格式：
- 用"严重"/"警告"/"建议"三个级别标注每个问题
- 每个问题给出具体的代码位置和修复建议
- 最后给一个整体评分（1-10）和一句话总结
不需要称赞代码好的地方，专注于找问题。
代码：
[粘贴代码]为什么这样设计：
有几个关键选择。
"不需要称赞好的地方"这一句非常重要。没有这句话，AI会花大量篇幅说"这段代码写得很清晰"、"命名规范很好"，这些废话我不需要。加上这句之后，输出会直接得多。
三个级别的分类是我调试出来的。最开始我只让它"找问题"，输出来的东西会把严重Bug和代码风格问题混在一起，很难分辨优先级。分了级别之后，我一眼就能知道先看哪个。
这个Prompt在Claude上效果特别稳定，GPT-4也可以，但Claude对安全类问题的覆盖更全面一些。
二、RAG 调试 Prompt
做RAG系统的人应该都知道一个痛苦：检索出来的内容明明是对的，但最终答案就是不对，或者检索根本没召回应该召回的内容。调这个问题非常耗时。
这个Prompt是我专门为调试RAG问题设计的，在我做项目的时候救了我很多次。
使用场景： RAG系统效果不符合预期，需要定位问题在检索还是生成阶段，或者要改进检索策略的时候。
Prompt：
我在构建一个RAG系统，遇到了效果问题，需要你帮我做系统性诊断。
系统配置：
- 向量模型：[填写，例如：text-embedding-ada-002]
- 向量数据库：[填写，例如：Pinecone / Chroma / Milvus]
- chunk策略：[填写，例如：按段落，最大512 token，overlap 50]
- 召回数量：top-k = [填写]
- 生成模型：[填写]
问题描述：
[描述你遇到的问题，例如：用户问"XX"，系统给出的答案是"XX"，但正确答案应该是"XX"]
请按以下框架帮我分析：
**第一步：判断问题阶段**
这是检索问题（召回内容不对）还是生成问题（内容召回对了但答案不对）？给出你的判断和依据。
**第二步：检索层诊断**（如果是检索问题）
- 可能的chunk策略问题
- 可能的embedding模型对这类查询的局限
- 查询改写的可能方向
- 混合检索（向量+关键词）是否适用
**第三步：生成层诊断**（如果是生成问题）
- prompt中上下文注入方式的可能问题
- 指令遵循的可能问题
- 模型对这类问题的已知局限
**第四步：给出3个具体的可测试改进方案**
每个方案说明：改什么、预期改善什么、如何验证效果。为什么这样设计：
RAG调试最大的问题是"不知道从哪里下手"。这个Prompt强制建立了一个诊断框架：先定位问题阶段，再在对应阶段深挖。避免了把检索问题当生成问题修，或者反过来。
"3个具体的可测试改进方案"这个要求很关键，带着"如何验证"的要求，能逼出更工程化的建议，而不是停留在理论层面。
三、技术文档写作 Prompt
我写过很多技术文档，包括API文档、架构设计文档、部署文档。这个Prompt是我在写内部技术文档时用的主力Prompt。
使用场景： 需要把一段技术设计或者代码逻辑转化成清晰的文档的时候。
Prompt：
你是一个技术写作专家，熟悉软件工程文档规范。
我需要你把下面的[代码/技术描述/架构说明]转化成一份清晰的技术文档。
目标读者：[填写，例如：后端工程师，了解基础的分布式系统概念，但不熟悉这个具体系统]
文档要求：
- 先说"是什么"和"为什么这样设计"，再说"怎么用"
- 不要在文档里解释读者应该已经知道的基础概念（例如读者是工程师，不需要解释什么是HTTP）
- 所有示例代码必须可以直接运行，不用伪代码
- 有反直觉或者容易出错的地方，用"注意"块特别标注
- 语言简洁，不要有废话，每个句子都应该传递信息
输入材料：
[粘贴代码或技术描述]为什么这样设计：
"先说是什么和为什么，再说怎么用"这个顺序是我觉得最重要的原则。大部分技术文档直接开始说"步骤一：安装……步骤二：配置……"，完全不告诉读者这个东西解决什么问题。让AI默认按这个顺序组织，输出质量会高很多。
"不要解释读者已知的概念"这一条也很重要，不然你会得到满篇的基础概念解释。
四、复杂问题分析 Prompt
这个Prompt我用来分析技术决策、架构选型、或者任何有多个维度需要权衡的问题。这是我用得第二频繁的Prompt。
使用场景： 面对一个没有标准答案的技术选型或架构决策问题，需要系统性地把各维度想清楚的时候。
Prompt：
我需要做一个技术决策，请帮我做系统性分析。
问题描述：
[描述你的决策问题和背景]
我的约束条件：
- 团队规模：[填写]
- 技术栈：[填写]
- 时间窗口：[填写，例如：需要在3个月内上线]
- 预算限制：[如果有]
- 其他硬性约束：[填写]
请按以下结构分析：
**1. 拆解决策维度**
这个问题有哪些核心的决策维度？（例如：可扩展性、开发速度、运维成本、技术成熟度）
**2. 主要方案对比**
列出2-4个可行方案，对每个方案：
- 核心优势（针对我的约束条件）
- 主要风险（针对我的约束条件）
- 我的团队采用这个方案的关键前提是什么？
**3. 你的推荐**
基于以上分析，你推荐哪个方案？说清楚推荐的前提假设。
如果你无法推荐，说清楚需要哪些额外信息才能推荐。
**4. 3个月后需要重新评估的信号**
如果选了你推荐的方案，什么情况出现意味着当初的判断是错的，需要重新考虑？为什么这样设计：
"你的推荐"这个要求强制AI给出立场，而不是一直说"这个方案有优点也有缺点……"。我一开始没有这一条，得到的分析全是墙头草，没有用。
"3个月后需要重新评估的信号"这个是我认为设计得最巧妙的一条。它让AI倒过来想：如果推荐的方案是错的，错误信号会以什么形式出现？这个角度往往能暴露出一个决策里最核心的假设。
五、错误信息诊断 Prompt
这个相对简单，但非常实用。专门用来快速定位错误。
使用场景： 遇到报错，特别是不熟悉的堆栈或者第三方库的错误。
Prompt：
我遇到了以下错误，请帮我诊断。
错误信息：
[粘贴完整的错误堆栈]
我的代码上下文：
[粘贴相关代码片段，20-50行左右]
环境信息：
- 语言/框架版本：[填写]
- 最近的改动：[填写，例如：刚升级了xxx库的版本，或者刚添加了xxx功能]
请直接给出：
1. 最可能的根本原因（一句话）
2. 验证这个原因的方法（一步）
3. 修复方案（具体代码）
如果有多个可能原因，按可能性从高到低列出，不要超过3个。为什么这样设计：
"最近的改动"这一项是关键。80%的Bug都和最近的改动有关。告诉AI这个上下文，诊断准确率会提升很多。
"不要超过3个"这个限制很重要，不然你会得到一个包含15种可能性的列表，完全没有优先级。
几个使用Prompt的meta原则
最后说几个我认为比具体Prompt更重要的原则：
给越多的上下文约束，得到的输出越有用。 "帮我Review代码"和上面那个完整的Review Prompt，输出质量差太远了。
不要害怕Prompt写得很长。 很多人觉得Prompt要简短，这是误解。只要每一行都有信息量，长Prompt完全没问题。
好的Prompt是迭代出来的，不是一次设计出来的。 我上面每个Prompt都是用了几十次之后改出来的当前版本。你拿来用之后，根据你的实际效果再调整。
记录你的Prompt版本。 当你把一个Prompt改得效果变好了，记下来。当你改坏了，你知道往回看哪里。